The purpose of this phase is to design software to satisfy the computer procedure as specified in the Phase 3, "Sub-System Design." Several events occur during this phase:

• Processing and data requirements are evaluated.

• A software strategy is defined to satisfy the requirements.

• Software is designed, complete with specifications to represent processing logic.

• The computer operating environment is defined and evaluated.

• A Computer Run Book is assembled containing the design specifications suitable for review.

In some situations, it may be necessary to execute Phase 4-II to implement a modification to only a single program or module. In this instance, the program number or MD number can be used in the project/phase key.

The formal deliverable resulting from Phase 4-II is a "Computer Run Book" consisting of design and operating specifications for the software. This is reviewed with DP Operations, Systems Engineering, Data Resource Management, and Systems Resource Management for clarity and viability.

Following Phase 3, control over the design and development of software is turned over to the Software Engineer. Because of this delineation of responsibility, the Software Engineer must have a clear understanding of the sub-system. This implies that a knowledgeable Software Engineer can exert influence over the Systems Engineer to prepare specifications correctly. This eliminates the problem of accepting vague or incomplete specifications from the sub-system designer.

The difference between Phase 4-II and 5 is the difference between engineering and manufacturing. Whereas, Phase 4-II is concerned with the design of computer software, Phase 5 is concerned with actually developing the program according to specifications. This can be performed by either manually writing software according to the rules of a particular language or the execution of an application development aid, such as a program generator, report writer or fourth generation language. As such, Phase 5 is dependent on the method of implementation as specified in Phase 4-II

The separation of the programming activities between Phases 4-II and 5 provides project flexibility and a more efficient utilization of programming resources. At the same time, this division of effort assures a complete design prior to program implementation where additional resources, primarily the computer, are utilized. This approach also lends itself readily to using senior programmers to specify the programs, and less experienced programmers to code and test the programs under supervision or implement using automated programming tools.

Because ISEM recognizes that there are many ways to implement software, it is programming language/tool/technique independent. This is why it can comfortably coexist with various approaches to software engineering. This is also why systems engineering should be considered a prerequisite to software engineering. Without adequate systems specifications, software can only be prepared based on unsubstantiated assumptions, speculation and conjecture. It simply will be counterproductive.

The principal objective of Phase 4-II is to define and synchronize processing within the computer procedure. To do this, the computer procedure design must express two things:

• Processing Flow - this is an expression of how programs will be executed, from start to end. Consequently, dependencies between programs are defined. Such program dependencies reflect sequential, iterative, and parallel processing.

• Data Flow - how data moves within a procedure is expressed by how inputs, outputs and files are used to process the data in the various programs. Here, data is expressed in terms of how it is created, updated, and referenced.

Failure to define such detail will result in processing inconsistencies later.  

DBEM INTERFACE

During Phase 2 (System Design), the primary logical files of the system were defined. This triggered a DBEM project where the logical files were merged into the enterprise data base. Data Base Administration thereby devised a physical design to implement the logical files. The net result are physical file layouts for inclusion in programming.

During Phase 3 (Sub-System Design), external computer files, such as input transaction files and output data files, were identified for implementation by Data Base Administration. In other words, by Phase 4-II all of the major computer files should have been defined and implemented by the DBA. However, during Phase 4-II, the Software Engineer may define the need for working files to pass data between programs. This is also communicated to the DBA who must implement the physical files accordingly.

What this highlights is that in a pristine "PRIDE" environment, the Software Engineer is the recipient of the file layouts, not the creator. This approach to data base design promotes integration between applications. Instead of the System/Software Engineers designing a data base to suit the requirements of their application, the data base is implemented by Data Resource Management who is responsible for implementing the data requirements of the enterprise on a global basis.

In the absence of a viable Data Resource Management organization, implementation of the physical files defaults to the Software Engineer.  

PHASE 4-II DELIVERABLES

The formal deliverable resulting from Phase 4-II is the "Computer Run Book." This document serves two purposes:

1. It contains the specifications and designs required to manufacture software in Phase 5.

2. It will be used as reference documentation by DP Operations when the software goes into production.

Within the Computer Run Book are two graphics:

Computer Procedure Flowchart

The computer procedure design is graphically represented by the Computer Procedure Flowchart. As with all ISEM flowcharts, the diagram shows the lowest level of detail in the system hierarchy: programs. Each program is represented on the flowchart with its appointed inputs, outputs, files and timing. A Table of Files can accompany the flowchart which shows how the various files are used in the programs: either "C" Created, "U" Updated, "R" Referenced, or combinations of all three.

The flowchart expresses both the processing flow and data flow of the procedure, which is similar to the Sub-System Flowchart. How the flowchart is drawn, horizontally or vertically, is irrelevant. All that is important is that the graphic express the dependencies between programs, inputs, outputs, and files. This is useful for expressing design issues as well as for production purposes.

Software Structure Diagram

This refers to a graphic used to express the internal processing logic of either a program or module. It is a generic graphic that can take many forms and use different symbols and notation. It is totally dependent on the selected method of implementation for software. If a particular programming technique or tool observes certain graphical conventions, then the diagram is prepared according to these conventions. However, there may be occasions where the method of implementation does not require a graphical explanation. Instead, software specifications need to be conveyed in some other manner (perhaps textual). In this event, a Software Structure Diagram may not be necessary. As such, the diagram is considered optional.  

THE PHILOSOPHY OF SOFTWARE ENGINEERING

The design of software is a highly complex and technical issue. It cannot be performed well using unorganized means. The key to success is to treat software development as a science as opposed to an art-form. To be recognized as a legitimate science, there must be some governing principles. To begin with, there are three basic objectives to Software Engineering:

1. To produce reliable programs that will perform according to specifications.

2. To produce programs that are easy to maintain and modify.

3. To implement programs in the most practical, efficient and cost effective manner possible.

These objectives are essentially no different than any other engineering discipline. As such, Software Engineering implies organization and discipline.

Whereas Systems Engineering is concerned with an Information System in its entirety, regardless of its physical implementation, Software Engineering pertains only to the programming of the computer. As such, Software Engineering is considered a subset of Systems Engineering. In order to effectively implement Software Engineering, it presupposes a viable Systems Engineering function is in place to provide the necessary specifications required for Software Engineering to implement (such as the work performed during Phases 1, 2 and 3). While Systems Engineering is geared towards business issues and an overall system design, Software Engineering is oriented to technical issues and software design. In situations where the Systems Engineering function is not implemented, Software Engineering is forced to compensate by trying to deduce the business specifications, a talent for which they are not necessarily suited.  

THE NEED FOR STRUCTURE

Structuring software is performed more for the human being, rather than the computer. The machine itself does not care. It will process the instructions whether the software is organized or not. Therefore, there are primarily three reasons for structuring software:

1. DESIGN CORRECTNESS - to prove that software reflects its design. This is verified during testing. As such, a design structure becomes a "roadmap" for testing software.

2. MAINTAINABILITY - to simplify the implementation of changes and corrections to the software. A well structured program minimizes the need to depend upon the author of the software.

3. MODULARITY - to divide a complex program into smaller units so that different parts can be designed and developed separately. This is useful from a Project Management perspective. Modularity also promotes software re-usability; where software components can be shared between applications. The exchange of program code expedites project development.

It is a common misconception that the purpose of techniques such as "structured programming" is to produce an efficient program. In reality, many software design techniques sacrifice efficiency for maintainability.

Structuring software can take many forms:

• Graphical - structure charts, block diagrams, decision tables, function charts, or some other programming technique.

• Textual - pseudo-code or organizing source code to reflect a design.

• Specifications - developing and maintaining requirements to suit a specific application development aid, such as a program generator, report writer, or fourth generation language.

• Combinations of the above.

The objective therefore is to select a software engineering tool or technique that produces uniform results and is easy to implement. This may require a compendium of techniques, as opposed to just one.  

SOFTWARE IS HARD

Although "software" is considered the opposite of "hardware," it exhibits some very "hard" characteristics. If it were truly "soft" it would be universally applicable to any computer. Obviously it is not. This is why there are different versions of software for different computers. It is highly uncommon to find software that will perform the same way on different computers without any modification. This implies that software is a physical construct, not logical. Therefore, software is hardware dependent.

Before selecting a software approach, the Software Engineer must consider the target platform where the software is to execute. There are many variables about the computer to consider before making a software design decision; for example:

1. Operating System considerations:

   Memory - Virtual or restricted to a specific size.

   Communications - providing either a single-user or multi-user environment.

   Program execution - single serial execution or parallel execution (multitasking).

   Utilities - for sorting, file backup, data base, etc.

   Compilers - languages supported. Also, linker restrictions.

   Application support - screen handling, TP monitors.

2. Input/Output considerations

   Transaction processing speed.

   Peripherals used to support data transmission, conversion, and storage.

   1. File size limitations.

   2. Supported access methods.

3. Application development tools

   Programming aids for development and testing.

   Performance monitors.

In many cases, the production machine will be the same as the development machine. In other words, the specifications for the targeted platform may be assumed. In any event, the operating environment must be weighed against the application's requirements as detailed in the Phase 3 "Sub-System Design Manual." Depending on the company's overall direction in computing, one of Software Engineering's objectives may be to develop software to accommodate machine portability. This can influence the method of implementation tremendously.  

SOFTWARE STRUCTURE

There are basically two types of computer software:

• SYSTEM SOFTWARE concentrates on the basic operational needs of the hardware and is represented by the operating system. The expression itself, "System" Software, is perhaps a misnomer in that it has nothing to do with Information Systems. Instead, it is only concerned with operating the computer.

• APPLICATION SOFTWARE is concerned with instructing the computer to perform special tasks within an information system.

Although ISEM is oriented to the production of application software, the concepts embodied in the methodology are equally valid for building an operating system (or any other product).

In ISEM terminology, the following definitions are used in relation to software:

1. A COMPUTER PROCEDURE consists of one or more programs linked together and executed in a prescribed sequence.

   Conceptually, all computer procedures could consist of a single program. But the functionality of the program would probably dictate a program too large for the computer to effectively implement. Because of this, the Computer Procedure represents a collection of programs dedicated to a specific purpose.

2. A PROGRAM is a set of machine processable instructions that performs a specific task within a computer procedure.

   If desired, a program can be divided into smaller, easier to manage sections of software that are commonly referred to as MODULES, SUBROUTINES, or OBJECTS. These types of components typically represent re-usable software code. The difference between a program and its subordinate components is that a program is executable by the operating system and is controllable at the command level, while modules and subroutines are not. As such, modules and subroutines rely on other modules and subroutines to form a whole program.

METHODS OF IMPLEMENTATION

When designing software, the Software Engineer considers the method of implementation. Obviously, there are many ways to produce a program:

• Manually writing an unstructured program.

• Manually writing a structured program (modular, object oriented, or otherwise).

• Assembling a program through re-usable code.

• Using computer utility programs (such as to perform a sort).

• Through a commercially available software package.

• Generating a program through such tools as code generators, report writers, fourth generation languages (interpreters), etc.

• Combinations of the above.

Any of these approaches are satisfactory. Ultimately, the Software Engineer must consider three things:

1. Project requirements - this includes delivery schedules and operating budget. It also includes an analysis of the skills and proficiencies required to build a certain type of program.

2. Application requirements - batch, interactive, real-time, etc. require different programming tactics. Consideration must also be given to complexity and performance. In addition, hardware specifications as mentioned earlier are considered.

3. Maintenance requirements - to implement changes and corrections to software later on.

Obviously, there will be trade-offs between the three considerations. It is important that the Software Engineer devise a software strategy that is practical to implement. All of this will have a bearing on the techniques and tools required to implement the programs, along with the type of programming languages to be used; either a Machine Language, Assembly Language, Procedural Language, or Non-Procedural Language (specification driven interpreter).  

METHODS OF PROCESSING

During Phase 4-II the Software Engineer must be reminded of the basic processing concepts as defined in ISEM:

1. There are three basic processing constructs:

   Sequence - representing consecutive steps in processing.

   Iteration - representing repetition until a condition is met.

   Choice - representing a selected path based on a prescribed criteria.

   The Software Engineer will use any one of these constructs, or combinations, in designing the processing flow. This can be used to express concurrent processing, where two programs within the procedure are executing simultaneously. This does not imply a detached process; there must be some form or program dependency. Rather, it means that one program can be used to initiate another, which will then run simultaneously with others.

   It must be remembered that as a procedure starts, it continues from program-to-program, until it reaches a conclusion within the specified procedure time frame. This does not mean that a procedure will have only one start or one end; in fact, it can have multiple ways of starting and multiple ways of ending.

2. All processing involves the use of transactions, which may represent:

   • How data is collected for storage.

   • How a report, screen or other forms of output is requested.

3. Systems communicate through data.

   • In Phase 2, primary files were defined and related to the various sub-systems. In Phase 3, external physical files were defined to implement input transaction files and output data files. During Phase 4-II, the Software Engineer specifies the computer working files to pass data between programs.

   • These additional file requirements are communicated to Data Base Administration for implementation.

For additional information on "Methods of Processing," consult the methodology overview.  

TIMING REFINEMENTS

As the computer procedure is decomposed into programs, timing is refined to express when each program is executed within the procedure and how fast it must be performed. The timing for the overall procedure is expressed in terms of:

• Offset - when the procedure is to begin within the time frame of the sub-system.

• Response Time - the speed by which the procedure must execute.

However, at the Program level "Offset" and "Response Time" is refined and takes on new meaning:

• Offset - when the program is to begin within the time frame of the computer procedure.

• Response time - the speed by which the program must execute.

The objective here is to synchronize the timing of the programs. Offset and Response Time, therefore, will not necessarily be the same as specified for the overall computer procedure. As an example, assume that a computer procedure has a response time of one hour. Let's also assume that the procedure can be executed with three sequential programs. The timing of the three programs could possibly be defined as:

This is a simple example; computer procedures can obviously be much more complicated than this. Yet, it demonstrates the synchronization of the three programs. Timing at this level also provides insight into the type of responsiveness which the computer must have during processing.

One last note, the accumulated response time of the programs must not exceed the response time specified for the overall computer procedure.  

SOFTWARE RE-USABILITY

When software is decomposed into its basic components, it can be treated like any other re-usable resource. This means that objects such as modules and subroutines can be uniquely distinguished and re-used in other applications. However, sharing must be designed and built into the software. For example, if modules and subroutines are used for nothing more than to subdivide a program, then the opportunity to share software will be missed. But if these software building blocks are constructed properly, they can be re-used elsewhere, thereby saving time during other application development projects.

Designing re-usable components is dependent on the software design technique in use. Some techniques lend themselves to re-usability better than others. A standard and consistent approach obviously provides uniformity.

Regardless of the selected design technique, these components can be cataloged and cross-referenced in the IRM where their relationships can be analyzed. When properly defined, the Software Engineer can:

• Search and locate modules and subroutines for inclusion in a program.

• Perform an "impact analysis" to study the effect of modifying an existing module to incorporate additional functions.

TESTING

The testing of software is just as important as its design. The intent is to validate the design of the product. During ISEM, design is performed top-down, from system down to programs; testing, on the other hand is performed bottom-up, from the program up to the system. During Phase 5, "Software Manufacturing," the program will be produced and tested individually (unit test). In Phase 6, all of the programs in the computer procedure will be tested as a whole (string test). In Phase 7, the procedures are tested for sub-system conformity (parallel test). Test criteria, therefore, should be established during the design phases for use during testing.

During Phase 3, the Test Criteria for the overall sub-system is established. Similarly, in Phase 4-II, the Test Criteria for the computer procedure and each program is established. The test criteria should specify the conditions by which the software can be validated for correctness. Although the Test Criteria is posted to the computer procedure narrative, it is referenced during both Phase 5 and 6.  

ENVIRONMENTAL ISSUES

In preparing for Phase 5 "Software Manufacturing" it is important to identify both the Development and Production operating environments, which may or may not reside on the same computer. This is important for change control purposes; when moving from a test mode to production. There are obviously many ways of establishing computer directories/libraries. However, consideration must be given to the following areas:

• TEST versus PRODUCTION versions - Separation can be based on either:

  • Separate directories on the same disk drive.

  • Separate disk drives on the same computer.

  • Separate computers.

• RELEASE number - This can either represent a formal release number, such as REL100, REL110, REL120, etc. or based on the EFFECTIVE DATE of the resource; for example; 19940101 (year/month/day).

• "PRIDE" SYSTEM STRUCTURE NUMBER - Following the System\Sub-System\Computer Procedure\Program format.

  NOTE: Since a sub-system consists of only one computer procedure, the need for expressing the computer procedure level may not be necessary.

• SHARED resources - where re-usable resources such as files, modules and subroutines, are truly shared between systems, then they should be separated from the system hierarchy (non-re-usable items should be maintained under the appropriate system directory).

Obviously, the actual setup of a directory/library is based on machine capabilities and performance considerations. However, establishing such a development/production environment offers many benefits:

• It isolates the programs and modules along with associated test files during development.

• Physically locating resources is simplified since it mirrors the contents of the IRM. Although any name can be applied to a file, use of the IRM numbering conventions should be encouraged. For example, PC based files could be expressed as: TS0102.CMD MD-90023.OBJ ID-90032.RC TS010201.EXE MD-90023.DLL ID-90032.IPF TS010201.C FD-92300.TRN ID-90021.HLP TS010202.COB FD-90135.DAT OD-93020.LST

• From a Quality Assurance point of view, this is useful for comparing designs as recorded in the IRM with the actual components.

• It greatly assists change control by being able to copy components from one directory to another (from development to production).

• Although such a directory/library strategy should be in place prior to design, it is confirmed during Phase 4-II.

DEVELOPMENT VERSUS PRODUCTION MACHINES

Developing systems and software on a separate machine from the production environment overcomes the problem of contention for machine time and improves speed (both for developers and production jobs). However, it can present a problem when incompatible operating systems and compilers are used. In this situation, the development organization has a couple of options:

1. Perform Phases 1 through 4-II on the development machine and perform Phases 5 and 6 on the target production machine.

2. Perform Phases 1 through 6 on the development machine. This will result in tested software that complies to the rules of the development machine's compiler. The source code is then moved to the production machine where it may have to be modified to suit the rules of the production machine's compiler. In other words, the testing and debugging steps of Phases 5 and 6 may have to be repeated.

CONTROL LANGUAGE

Between the software design and the development/production environment strategy, the Software Engineer should be able to develop pertinent control language statements for executing the programs. This can take many forms depending on the computer's operating system; some examples:

• Job Control Language (JCL)

• Digital Command Language (DCL)

• Executive Control Language (ECL)

• CLISTS

• CL (Control Language)

• PC Command Files (.CMD and .BAT)

These control language statements are to be prepared during Phase 4-II and made available to the Phase 5 programmer.  

SKILLS & PROFICIENCIES

Following the design of the software and the identification of the operating environment, the Software Engineer should be able to define the skills and proficiencies needed to produce the software in Phase 5. For example, the Software Engineer should be able to identify the degree of knowledge regarding:

• Hardware

• Operating System considerations

• Programming Languages

• Techniques and tools for software design and development.

This is useful for selecting and/or recruiting personnel for Phase 5 assignments. Also, it will highlight the need for additional training.  

MOVING TO PHASE 5

As mentioned, the formal deliverable resulting from Phase 4-II is the "Computer Run Book." Contained within this document are important design decisions for the programmer to implement in Phase 5, including:

• Program dependencies specifying execution sequence.

• Processing logic for each program.

• Final input/output formats including additional processing messages identified during design of the software.

• File layouts.

• Operating environment considerations including pertinent command language statements.

• Required skills and proficiencies needed to perform the work.

PHASE 4-II REVIEW

Phase 4-II represents a major technical review phase and serves two purposes: to critique the software design, and; to evaluate the software for use in production. Because of this, different types of people participate in the review.

• SYSTEMS ENGINEERING evaluates the software design in terms of whether it will effectively implement the sub-system design as developed in Phase 3.

• DP OPERATIONS evaluates the design in terms of how it will operate in production. In this respect, operations acts as the end-user who will be responsible for implementing the design.

• DATA RESOURCE MANAGEMENT assures that all of the physical data requirements have been satisfied.

Activity C - Prepare File Layouts

Data Base Administration delivers to Software Engineering the completed file layouts for use in the software. This includes the primary files as expressed earlier in ISEM, along with the external and internal working files for the computer.

Activity D - Define Operating Requirements

Software Engineering defines both the Development and Operating environments for the software. This includes where the software will be produced and tested versus where it will perform when put into production.

Other operating issues are evaluated at this time, such as the operating costs of the software, performance considerations, backup/recovery, etc.

Software Engineering also prepares pertinent control language statements to control the execution of the programs.

Software Engineering then prepares the final Computer Run Book which is reviewed in detail with Quality Assurance for adherence to standards. Revisions are implemented as required.

Activity E - Phase 4-II Review

Software Engineering conducts a review of the "Computer Run Book" with Systems Engineering, DP Operations, Data Resource Management, Systems Resource Management, and Project Management. The run book consists of:

• Phase Cover Page
• Table of Contents
• Computer Procedure Flowchart
• Computer Procedure Discussion
• Test Criteria
• Software Structure Diagram
• Program Specification
• Module Specification (optional)
• Data Resource Layouts
• Phase Review Checklist