A GENERIC MODEL

FOR

SOFTWARE DEVELOPMENT PROCESS

ALI BEHFOROOZ

Every software product begins with a problem statement. In some development environment the system engineers/system analysts will develop a document called Software Requirement Specification and handed to development team. In Smaller development environment the development team starts with the problem statement and must extract the requirement specification from the problem statement, from asking questions and from studying the problem domain.

A software product initiate with a problem statement (or client needs) and terminates with a deliverable system. There are many steps in between that we try to formalize.

Before we start stating the steps in this process it is important to understand that any software development process is, by necessity, a repetitive process not a sequential process. That is, although we call them step 1, step 2,..., step n but we may have to revisit any step at any time. With this in mind we state the different steps and the product of each step.

To develop the SRS document from the problem statement and other sources of knowledge available to us. We must understand the problem statement, we must acquire knowledge about the problem domain and we must ask a lot of questions from the client and uses until we can clearly write the specification for the software product we are asked to build. In the case that the SRS is already developed by the system engineers or system analysts we must try to understand, to verify and validate this document. For the development of the SRS we can use any of the following format. Each format may fit a given problem better, therefore, the selection of the format is somewhat problem dependent and also the decision of the team. The first part of the document is common in all 4 formats. Table 1 shows the common content of the SRS. Tables 2(a) to 2(d) give the different format for the remaining part of the SRS document.

Table 1

Software Requirement Specification Outline

Table of Contents for parts 1 and 2

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definition, Acronyms, or Abbreviations

1.4 References

1.5 Overview

2. General Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

2.4 General Constraints

2.5 Assumptions

3. Specific Requirements

This part is organized in Tables 2 (a) to (d)

Table 2 (a)

Table of Contents for Section 3 of SRS

First Recommendation

3. Specific Requirements

3.1 Functional Requirements

3.1.1 Functional Requirement 1

3.1.1.1 Introduction

3.1.1.2 Inputs

3.1.1.3 Processing

3.1.1.4 Outputs

3.1.2 Functional Requirement 2

. . .

3.1.n Functional Requirement n

3.2 External Interface Requirements

3.2.1 User Interfaces

3.2.2 Hardware Interfaces

3.2.3 Software Interfaces

3.2.4 Communications Interfaces

3.3 Performance Requirements

3.4 Design Constraints

3.4.1 Standards Compliance

3.4.2 Hardware Limitations

. . .

3.5 Attributes

3.5.1 Security

3.5.2 Maintainability

. . .

3.6 Other Requirements

3.6.1 Data Base

3.6.2 Operations

3.6.3 Site Adaptation

. . .

Table 2 (b)

Table of Contents for Section 3 of SRS

Second Recommendation

3. Specific Requirements

3.1 Functional Requirements

3.1.1 Functional Requirements 1

3.1.1.1 Specification

3.1.1.1.1 Introduction

3.1.1.1.2 Inputs

3.1.1.1.3 Processing

3.1.1.1.4 Outputs

3.1.1.2 External Interfaces

3.1.1.2.1. User Interfaces

3.1.1.2.2 Hardware

Interfaces

3.1.1.2.3 Software

Interfaces

3.1.1.2.4 Communication

Interfaces

3.1.2 Functional Requirement 2

. . .

3.1.n Functional Requirement n

3.2 Performance Requirements

3.3 Design Constraints

3.4 Attributes

3.4.1 Security

3.4.2 Maintainability

. . .

3.5 Other Requirements

3.5.1 Data Base

3.5.2 Operations

3.5.3 Site Adaptation

. . .

Table 2 (c)

Table of Contents for Section 3 of SRS

Third Recommendation

3. Specific Requirements

3.1 Functional Requirements

3.1.1 Functional Requirements 1

3.1.1.1 Introduction

3.1.1.2 Inputs

3.1.1.3 Processing

3.1.1.4 Outputs

3.1.1.5 Performance Requirements

3.1.1.6 Design Constraints

3.1.1.6.1 Standards

Compliance

3.1.1.6.2 Hardware

Limitations

. . .

3.1.1.7 Attributes

3.1.1.7.1 Security

3.1.1.7.2 Maintainability

. . .

3.1.1.8 Other Requirements

3.1.1.8.1 Data Base

3.1.1.8.2 Operations

3.1.1.8.3 Site Adaptation

. . .

3.1.2 Functional Requirement 2

. . .

3.1.n Functional Requirement n

3.2 External Interface Requirements

3.2.1 User Interfaces

3.2.1.1 Performance Requirements

3.2.1.2 Design Constraints

3.2.1.2.1 Standards

Compliance

3.2.1.2.2 Hardware

Limitations

. . .

3.2.1.3 Attributes

3.2.1.3.1 Security

3.2.1.3.2 Maintainability

. . .

3.2.1.4 Other Requirements

3.2.1.4.1 Data Base

3.2.1.4.2 Operations

3.2.1.4.3 Site Adaptation

. . .

3.2.2 Hardware Interfaces

3.2.3 Software Interfaces

3.2.4 Communications Interfaces

Table 2 (d)

Table of Contents for Section 3 of SRS

Fourth Recommendations

3. Specific Requirements

3.1 Functional Requirement 1

3.1.1 Introduction

3.1.2 Inputs

3.1.3 Processing

3.1.4 Outputs

3.1.5 External Interfaces

3.1.5.1 User Interfaces

3.1.5.2 Hardware Interfaces

3.1.5.3 Software Interfaces

3.1.5.4 Communication Interfaces

3.1.6 Performance Requirements

3.1.7 Design Constraints

3.1.8 Attributes

3.1.8.1 Security

3.1.8.2 Maintainability

. . .

3.1.9 Other Requirements

3.1.9.1 Data Base

3.1.9.2 Operations

3.1.9.3 Site Adaptation

. . .

3.2 Functional Requirement 2

. . .

3.n Functional Requirement n

The SDP document will be revised as we progress and will be used to manage the development of the software product. We may use the outline stated in table 3 as the table of content for developing the SDP document. The input to this step is the SRS document (maybe partially completed) and the output is the SDP document.

Table 3

TABLE OF CONTENTS

SOFTWARE DEVELOPMENT PLAN

I. INTRODUCTION

A. Summary of the contents of the SDP document

B. Scope and purpose of the document

C. System level project description

1. System description (summary level)

2. Contract summary

3. Technical performance management

issues/constraints/challenges

4. Software architecture/configuration

D. Software subsystem description

1. Deliverable software products

2. Nondeliverable tools and development facilities

II. RESOURCE AND SCHEDULE ESTIMATES

A. Resource profiles

1. Summary

2. Detailed allocation by products

B. Schedules

1. Summary Schedules

2. Detailed Schedules by Products

III. ORGANIZATION AND STAFFING

A. Responsibilities Defined

B. Linked to cost account

IV. WORK BREAKDOWN STRUCTURES, WORK PACKAGES AND COST ACCOUNTS

V. TECHNICAL MANAGEMENT AND CONTROL

A. Change management

B. Risk containment

C. Cost and schedule control

D. Issue resolution

VI. STANDARDS AND PROCEDURES

A. Development methodologies

VII. REVIEWS, AUDITS AND WALKTHROUGHS

A. Schedules

B. Procedures/criteria

C. Responsibilities

VIII.THE DEVELOPMENT ENVIRONMENT

IX. TECHNICAL PERFORMANCE MEASUREMENTS

X. DOCUMENTATION

XI. VERIFICATION AND VALIDATION

XII. MAINTENANCE

XIII.HUMAN FACTORS

XIV. DELIVERY, INSTALLATION AND ACCEPTANCE

XV. APPENDICES AND REFERENCES

We need to study a couple of different system/software architecture and prepare a trade-off study to select the best architecture for the system being developed. Certain elements of the architecture may be dictated by the client. In that case we must build the architecture around the client's needs.

The input to this document are system architecture, the SRS document and some of the software design tools as shown in the following table.

Table 4

Software Design Tools

Data Dictionary

Abstract descriptions of problem space in terms of:

Function and performance

. Timing Diagrams (real-time)

. Data and information flow

. Control flow

. Information models

. Objects/attributes/operations

. Flow diagrams

. Structure charts

. Hierarchical Input/Output Process (HIPO) charts

. Block diagrams

. Risk analysis charts

. Operational timelines

Information compression tools

. Decision tables

. Test requirement matrix

. Timing diagrams

. Traceability matrix

Support rationale tools

. Trade-off matrices

. Operational timelines

. Risk Analysis Charts

Realization tools

. PDL/Pseudocode/Structured English

. Flow diagrams

. Warnier diagrams

The output of step 4 is the detailed design of each components of the system. Table 5 gives the table of content of the SDS document. This table of content is more in line with structured design approach. This table can be modified to be used for an Object-oriented analysis and design approach.

Table 5

SDS TABLE OF CONTENTS

1.0 Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions Acronyms

2.0 References

3.0 Decomposition Description

3.1 Component or Module 1 Preliminary Description (Functional)

3.2 Component or Module 2 Preliminary Description

(Functional)

.

.

.

3.n Component or Module n Preliminary Description

(Functional)

4.0 Component Detail Design Descriptions

4.1 Component or Module 1

4.1.1 Structure

4.1.2 Function

4.1.3 Interfaces

4.1.4 Program Interrupts

4.1.5 Timing and Sequencing

4.1.6 Sequential Control Feature

4.1.7 Storage Allocation

4.1.8 Object Code (After Acceptance Test Complete)

4.1.9 Application Data

4.1.10 Detailed Design Descriptions (As Rationale)

4.2 Component or Module 2

4.2.1 Structure

. ....

. ....

. ....

4.2.10 Detailed Design Descriptions (As Rationale)

4.3 Component or Module 3

4.3.1 Structure

. ....

. ....

. ....

4.3.10 Detailed Design Descriptions (As Rationale)

4.4 ....

. ....

. ....

. ....

. ....

. ....

. ....

4.n Component or Module n

4.n.1 Structure

. ....

. ....

. ....

4.n.10 Detailed Design Descriptions (As Rationale)

.

5.0 Quality Assurance

5.1 Test Plans and Procedures

5.2 Test Cases

5.3 Test Cross Reference Matrix

6.0 Preparation For Delivery

7.0 Traceability

8.0 Appendices

8.1 Program Design Language

8.2 Software Parameter Estimation Update

8.3 Mathematical Formulas and Algorithms Not Documented In SRS

Section 2 should contain only those references that must be used in conjunction with the SDS to understand and use the document.

Section 3 describes the rationale for the partitioning of the software product and shows, perhaps by means of graphics, the allocation of specific SRS requirements among several software components that make up the software product. Each module is described in terms of the functions it performs and its interfaces to other components. External interfaces are, of course, also described in the SRS and in Section 3. If all external interfaces has been allocated to one component of the software product then exhaustive interface details would appear in that component description.

Section 4 is a detailed description of each component in the format shown below:

Structure: Internal organization of the component including any sub-allocations occurring as a result of component decomposition into sub-components.

Function: Specific functions allocated to the component with additional detail as required including requirements derived by step-wise refinements of functions allocated to the component and secondary requirements spawned by top level requirements.

Interfaces: Interface details including message structures, protocols, rates, etc.

Program Interrupts: Generated or invoked interrupts priorities and other related interrupt information.

Timing and Sequencing: Repetition rates, deadlines, and other timing considerations and constraints are to appear in this section.

Sequential Control Features: Control details are covered in this section depicting the order of processing, precedence enforcement, etc.

Storage Allocations: Describes allocation of memory to components for both process and data.

Source Code: Many specifications place listings for the delivered code in a separately bound appendix. Initially, this section is, of course, left blank. With this section included we should have all the documentation needed to maintain the software product.

Application Data: Data required to deploy the software product in the application area including all the files, records and fields needed for the application.

Detailed Design Description/Rationale: Design description including operational use and operator interactions for all modes of operation. The results of trade-studies and a summary of audit/review items that influenced design decisions are also included as part of the rationale.

Section 5 covers quality assurance issues. The quality assurance provisions and measures to be applied to the given product are defined in this section in detail. The test plan for the individual components and for the software product as a whole is covered in Section 5.1. Section 5.2 describes the specific test cases including expected results that will be used to exercise components and products. Section 5.3 describes, in a matrix like format, how each requirement assigned to the software product will be tested.

Section 6 describes the acceptance test phase in detail. The scenario by which the software product will be installed and acceptance tested along with specific acceptance criteria is documented in this section.

Section 7 is also best presented in a matrix like format showing where each SRS requirement is implemented in the design. As in the test cross reference matrix, this matrix can serve as a check list for quality assurance reviews.

Section 8 contains very important information. Section 8.1 is the realization of the design in pseudocode, program design language, flow charts, etc. This section is the principle input to the coding process. Ideally, it needs only to be converted into language statements. Some practitioners use special compilers to convert program design language directly into executable code thereby by-passing the traditional coding step. Section 8.2 contains updates or revisions to estimates of software parameters made earlier in project history. Such parameters as size, complexity, and resource requirements (labor months, calendar time, CPU, primary and secondary memory) should be tracked through the project on a continuing basis. Section 8.3 should document those algorithms and equations implemented in the software product but are not documented elsewhere.

This step should be done along side with step 4. As we discuss the design of each component and each requirement of the system we must provide test plan and test cases for them.

There are two different testing done on any software product, one is called unit testing and the other one is called test and integration. Unit testing is generally done by the programmer and its intention is to show that the program written is working and producing the right output. The main objective of the test and integration process is to show the software product does not work and does not fit in its place. In other words, the test and integration people are to find as many failure causing faults in the system as possible. The test plan that we generate at this step is based on the SRS document and based on the acceptance criteria specified in the SRS. The test plan is to be used by the test and integration people to make the system ready for delivery.

The general table of content of a test plan will include the following. In this table Module refers to a large segment of a software system.

Module Test Plan Outline

1. Identifier

2. Introduction

3. Module Test Approach Description and Objectives

4. References

5. Criteria For Pass/Fail

6. Approach

7. Criteria for Halting/Continuing Testing

8. Tasks to be Performed

9. Schedule

10. Test Products (documents)

10.1. Test Design Specification Document

10.1.1. Module Test Identifier

10.1.2. Features to be Tested

10.1.3. Testing Approach to be employed

10.1.4. Test Case List

10.1.5. Module Pass/Fail Criteria

10.2. Module Test Case Specification Document (including expected results)

10.2.1. Identifier

10.2.2. Unit Description

10.2.3. Input

10.2.4. Output

10.2.5. Environment

10.2.6. Special Procedures

10.2.7. Precedence and Dependencies

10.2.8. References

10.3. Module Test Case Procedures Document (including operator and test director scripts)

10.3.1. Identifier

10.3.2. Purpose

10.3.3. Special Requirements

10.3.4. Procedure

10.4. Module Test Log Document

10.4.1. Identifier

10.4.2. Test Environment

10.4.3. Tests Results

10.4.4. References

10.5. Module Anomaly Document

10.5.1. Test Incident Identifier

10.5.2. Summary of the Incident

10.5.3. Incident Description

10.5.4. Impact of the Incident on the Project

10.6. Module Test Summary Document

10.6.1. Test Summary Report Identifier

10.6.2. Summary and Conclusions

10.6.3. Variances

10.6.4. Comprehensive Assessment

10.6.5. Summary of Results

10.6.6. Evaluation

10.6.7. Summary of Activities

10.6.8. Approvals

11. Test Environment Description

12. Responsibilities, Staffing, Training

13. Risk Assessment and Containment

If we follow this process, the programmer at this point needs to convert the software design, which is specified in a specific design language such as psuedocode, into code using a programming environment. Note that we did not use the phrase "programming Language" because these days we have programming environment that is a combination of a programming language, graphic interface, a form of browser, library, etc.

Each programmer is given a piece of the system with its own specification to program. When the programming is done the programmer must show to the test and integration people that the program developed by him/her is certifiable. That is, as far as test and integration people are concern, the program is working correctly.

A set of documents generally forms the backbone of the test process. A discussion of the contents of each of these documents should provide insight into the tasks that the Test and Integration team must perform to effect system testing. The set of documents arrived at test and integration stage includes the following: Test Criteria document, test and integration plan, software development plan, and software test plan. For each module we will develop the following document during test and integration: test anomaly, test cases, test case procedures, and test log documents.

Prior to or concurrent with establishing a test plan, however, the Test and Integration team must establish a system acceptance criteria with the client/customer. The importance of this task cannot be overstated. These criteria for acceptance will be used to judge whether the system meets the customer's needs. Acceptance test criteria will usually be found in the system specification or mission statement. It is frequently a contractual agreement and often made part of the fee structure. That is failure to comply with acceptance criteria can result in reduced profit or even in financial penalties.

In addition to function and performance criteria (a specific transaction must be performed a given number of times under specific conditions) there are acceptance criteria involving start up and shut down sequences of a system, recovery of the system from various types of failure, human factors criteria based on the interface between operator/user and the system (often through software), disaster recovery criteria, error message criteria, criteria based on how the system handles various overload conditions (stress testing), criteria based on how well the system handles attempts by unauthorized users to penetrate the system, etc.

As system requirements are partitioned and allocated to hardware components, software components and to operators the acceptance criteria is implicitly allocated as well. For example, part of an acceptance criteria associated with a requirement for recognizing and handling an overload condition may be allocated to one of the software components.

The Test and Integration Plan describes the tasks, schedules, approach, resources and tools for integrating and testing software and other components of the system. The purpose of system testing is to detect differences between measured performance of a system and required performance as described in the requirements specification of a system through exercising a sequence of test scenarios. Measured performance should be conducted in an environment that matches, as closely as possible, the operational environment. Test scenarios should be as close as possible to operational timelines in every detail.

The Test and Integration Plan describes the scope of the testing, the approach to be taken, resources required (including people, test beds, test drivers), test scaffolds, schedules, documentation requirements, test databases or files, etc. A system test and integration plan answers questions such as: what is being tested? What are pass/fail criteria? When will each test occur? What is needed in the way of an environment to effect the testing? What features must be tested? What features will not be tested? What documentation is required? and What are the responsibilities of individuals and organizations, etc. Table 7 is a generic outline for a system test and integration plan.

Table 7

Test and Integration Plan Outline

1. Test and Integration Plan Identification

2. Introduction

3. test and integration Description and Objectives

4. References

5. Criteria for Pass/Fail

6. Approach to Test and Integration

7. Criteria for Halting Tests and Resuming Tests

8. Tasks to be Performed

9. Schedule

10. Build Plan and Specification

11. Test Environment Description (diagrams, sketches)

12. Responsibilities, Staffing, Training

13. Risk Assessment and Containment

Section 1 refers to any unique identifier assigned to project documentation. Section 2 summarizes the project and orients the reader to the extent that the document can stand alone. Section 3 provides a general overview of the plan for testing the entire system and defines test objectives for all testing levels. Section 4 provides pertinent references such as development plans, quality assurance plans configuration management plans, relevant policies and applicable standards. Section 5 describes pass/fail criteria derived from or traced to acceptance criteria. Section 6 describes the general approach to all levels of testing and integration of the system. Major testing activities, techniques and tools used to test designated groups of features are also described. The approach is described in enough detail to permit identification of major testing tasks and estimation of required resources and the schedule to perform the tasks. The minimum degree of coverage or comprehensiveness required is also described. Techniques used to judge the degree of comprehensiveness of the testing effort (for example determining which statements have been executed and how often), are specified. Additional completion criteria (for example frequency of failure occurrence) are described. Techniques for tracing requirements are specified. Significant constraints on testing such as test item availability, testing resource availability and testing deadlines are identified.

Section 7 defines the criteria for halting or suspending all or portions of the testing activity and the criteria for resuming testing. The purpose is to reduce "wheel spinning" in the test process. It also defines criteria and ground rules for regression testing. Regression testing refers to tests executed after a fault is found and corrected. Section 8 describes the individual tasks that must be performed. These tasks should be developed from and be consistent with the project work breakdown structure. Section 8 is the basis for updating estimates for the time and labor required for testing.

Section 9 presents a top level testing schedule identifying the major test milestones such as when acceptance test criteria are agreed to, beginning of module test, significant Build tests and demonstrations, delivery of all major system components for test, and development of the test environment. Section 10 describes in overview the subsystem test plan and specification. This document focuses on the specifics of the incremental integration of modules into subsystems and the testing performed at each stage of the integration process.

Section 11 describes in detail the test environment including all test bed configurations, additional hardware and software requirements, tools, adjunct test software, floor space, operator terminals, training and maintenance requirements, etc. Section 12 identifies the test director and other participants in the test and integration process including those individuals or groups responsible for managing, designing, preparing, executing, witnessing tests, checking and resolving issues. The test director is responsible for conducting the test. The groups may include developers, testers, operators, user representatives, technical support staff, data administration staff and quality support staff. Staffing and training needs are also included in this section.

Section 13 contains a risk assessment and containment plan for the Test and Integration phase. A likely occurrence is late delivery of a module or test tool. The risk assessment should identify those with a high likelihood of being late and develop "work arounds" so that schedules can be maintained.

A check list for test and integration plan preparation would include confirming that:

--Test scenarios match operational timelines exactly.

--All system and subsystem requirements are covered comprehensively.

--The test environment itself matches the operational environment.

--Plans for the test environment development or procurement is consistent with the system development schedule and the test and integration schedule.

--Both contractor and customer are in agreement with the

testing approach and acceptance criteria.

--Adequate acceptance tests performed on modules that are

certified for inclusion in a Build are fully planned.

--All efforts have been made to minimize regression testing by

reducing as much as possible dependency of one Build on

another.

--Provision has been made to assure that all test cases are

completed and documented in time to execute the tests they

were designed for.

--The test and integration plan call for a systematic test in

logical order of all module, subsystem and system

requirements against a well defined set of test cases.

--The plan includes a method for documenting the performance

of all tests in a test log; identifying and reporting any

events, anomalies or discrepancies; and a procedure for

tracking problems from symptom to closure.

In following these steps we can use any of the software development life cycle models we want. The variations of the Water Fall model can be used. Also, the Spiral model many be used. I personally prefer the spiral model because it forces to perform risk analysis as we progress toward completion of the system.

Following a formal development process similar to the one discussed here has the following advantages:

1. Everything done has been documented. Every step has as its input one or more additional document and as its output will produce one or more document.