> As you can see by how long it took me to respond, things have been
> busy. The project I've been working on since early last year is
> starting field trials on a real well next week, so I've been pretty
> much buried in last minute adjustments and documentation for the
> past month. I just finished the 120 page detailed
> the design/implementation spec yesterday. My partner on project is
> taking the spec with him to the field for further revisions, so I
> have a week of lower-intensity stuff to do, hence my return here.

BDW> Aren't you supposed to write the SRS and SDD BEFORE you write
BDW> the code? :-) 

RJ>What are these abbreviations?  (I haven't had my coffee yet... :-)

That's the language of software engineering.  Here's some more along the 
same line:

Professional Practice Guidelines:
The Use of Computer Software Tools 
by Professional Engineers and the Development of Computer Software 
Affecting Public Safety and Welfare
1993 

2. SOFTWARE ENGINEERING MODEL

Software engineering is usually part of the overall computer system 
engineering process, and is also closely linked to the hardware 
engineering process. The system and hardware engineering processes 
provide inputs to the software engineering process (see Figure 1 for an 
overview of the computer system engineering process). The software 
engineering processes can be categorized as development, verification, 
and support processes with well defined inputs and outputs. The intent 
of these processes is to achieve the required outputs through a 
comprehensive sequence of development and verification steps. Table 1 
summarizes the software engineering processes and their products, while 
Figure 2 provides an overview of the software development and 
verification processes. 

Figure 1 will be uploaded later. We apologize for the inconvenience.

Table 1 - Software Engineering Processes and Products


Process Product Acronym 
DEVELOPMENT   
Software Requirements Definition Software Requirements Specification SRS 
Software Design Software Design Description SDD 
Code Implementation Source Code  
VERIFICATION   
Requirements Review Requirements Review Report RRR 
Design Review Design Review Report DRR 
Code Review Code Review Report CRR 
Unit Testing Unit Test Procedures UTP 
 Unit Rest Report UTR 
System Integration Testing System Integration Test Procedures SITP 
 System Integration Test Report SITR 
Validation Testing Validation Test Procedures VTP 
 Validation Test Report VTR 
SUPPORT   
Planning Software Development Plan SDP 
 Standards and Procedures Handbook SPH 
Configuration Management Releases  
 Approved Change Requests Status Reports  
Training Training Records  

Software development involves software requirements definition, software 
design and code implementation; verification of the development process 
outputs is performed after each of these steps have been completed. In 
practice, this sequential model is not followed exactly, since there is 
feedback to preceding processes, and iterations are required. But 
feedback and iteration must be performed in conformance with the 
established development process. 

Figure 2 will be uploaded later. We apologize for the inconvenience.

Each release of the software throughout its lifetime must satisfy all 
requirements as if the sequential model had been followed exactly. 

2.1 Functional Requirements 

It is essential that engineers specify the user requirements that must 
be met by the system in sufficient detail and in a quantifiable manner. 
Functional requirements that cannot be verified, or are inadequately 
defined, ambiguous or unfeasible, will lead to the development of an 
inadequate software product. Engineers should consider any past 
experience with other similar systems to determine requirements, and 
specify requirements in terms of quality characteristics and sub 
characteristics (see Appendix A). They should prioritize these 
characteristics according to the importance of the application, so that 
any conflicting requirements can be managed during development. 

2.2 Conceptual Design 

This process is undertaken once functional requirements have been 
determined. It involves breaking the functional requirements down into 
subsystems, which are then mapped to hardware architecture and software 
components. Software can be either pre developed, off-the-shelf 
software, software to be developed, or a combination of both. 

2.3 Development Processes 

The development processes are: 

software requirements definition; 
software design, and 
code implementation. 
Engineers should define completely the development process and outputs 
for a specific software engineering project in a software development 
plan (SDP) and a standards and procedures handbook (SPH). Development 
should proceed according to the SDP and the SPH. Development processes 
do not apply to off-the-shelf software, but verification and maintenance 
processes do. 

2.3.1 Software Requirements Definition 

This process involves the analysis of the software's functional and 
conceptual design requirements, and all other requirements related to 
the specific environment in which it will operate. Engineers should 
determine these requirements by developing a software requirements 
specification (SRS). The SRS presents an external view of the software 
by providing a complete "black box" description of its behaviour. To 
help ensure that software design decisions are not artificially 
constrained, internal design details are not included in the SRS. The 
SRS does, however, document all necessary software design constraints, 
which may limit the developer's choice of solutions. 

2.3.2 Software Design 

This process involves developing a detailed software design that defines 
a software's architecture. It interfaces with any predeveloped software 
included in a software design description (SDD) that satisfies the 
requirements in the SRS and is compatible with the conceptual design. 
The SDD is a representation of the software design. When developing an 
SDD, engineers should describe the design in sufficient detail that no 
further refinement of the tasks, databases, inter-task communications, 
libraries, module structure and interfaces, data structures, and 
databases is required in the code. 

2.3.3 Code Implementation 

In this process, the design specified in the SDD is translated into 
debugged source code, and all databases using the programming 
language(s) selected for development are initialized. 

2.4 Verification Processes 

The verification processes are: 

software requirements review; 
software design review; 
code review; 
unit testing; 
system integration testing, and 
validation testing. 
Engineers should completely define the verification processes and 
outputs for a specific software engineering project in the SDP and the 
SPH. For each verification process, they should produce a report to 
record the methods they have used and process results. They should 
perform verification according to the SDP and the SPH, and can add or 
delete verification processes depending on the criticality of the 
application. 

2.4.1 Software Requirements Review 

This process involves a technical review of the SRS against the 
functional requirements and conceptual design. It verifies that the 
requirements specified in the SRS are complete, adequate, unambiguous, 
feasible, verifiable and consistent with the intended application. 

2.4.2 Software Design Review 

This process is a technical review that determines whether the design 
described in the SDD meets the intent of the functional requirements, 
conceptual design and SRS. 

2.4.3 Code Review 

This process involves the verification of whether the code fulfills the 
design specified in the SDD, and whether it complies with coding 
standards specified in the SPH. 

2.4.4 Testing Processes 

Testing processes involve preparing, verifying and implementing test 
procedures that specify the environment in which the code is tested, the 
steps to be followed by the tester, the set of inputs, the execution 
conditions, and the expected results. Engineers should specify the 
procedures for each testing process in the SPH. 

2.4.5 Unit Testing 

In the unit testing process, modules and programs are tested to ensure 
that they behave as specified by the SDD. Each module and program is 
tested singly, as well as their interfaces, and integrated sets of 
modules and programs (subsystems). 

2.4.6 System Integration Testing 

This process involves testing subsystems integrated with predeveloped 
software and hardware in a systematic manner to ensure that they behave 
as specified by the SRS. Its objectives are to find any errors in the 
software, hardware and predeveloped software interfaces, and in the 
handling of stress conditions, timing, fail-safe features, error 
conditions and error recovery. 

2.4.7 Validation Testing 

This process involves testing the integrated system to ensure that it 
meets functional and conceptual design requirements. It is the final 
verification step before the software is turned over to the user. 

2.5 Software Management Framework 

The software management framework consists of four main components: 

planning; 
configuration management; 
training, and 
quality assurance. 

2.5.1 Planning 

In the planning process, all software engineering tasks expected to be 
performed during the software's life cycle are defined in terms of how 
and when they are to be performed, and who is to perform them. To focus 
planning, engineers should use a model of the software's life cycle with 
these tasks mapped to it. At the start of the project, they should 
identify and document all development, verification and support 
processes, and all project-specific standards and procedures. They 
should also develop an organizational structure to meet the requirements 
of personnel participating in software engineering processes and to 
ensure that work is carried out objectively and effectively. This should 
include establishing estimates, schedules, budgets and resource 
requirements that support the effort required to develop procedures, 
support tools and facilities. The inputs to this process are the 
functional requirements, conceptual design, all umbrella project plans, 
and quality system standards and procedures. The outputs are the SDP and 
SPH. These documents are necessary prerequisites for software project 
management. 

2.5.2 Configuration Management 

Configuration management involves identifying the configuration of a 
software system at discrete points in time, to ensure that the correct 
version of each process output is being used at any point in time. It 
also includes controlling all changes made to the software, ensuring 
that new configuration items are developed and verified with the same 
rigor as the original items, and analyzing detected errors to improve 
software continuously according to adopted standards and procedures. 
Inputs to the process include all items that fall under configuration 
management, including the SDP and SPH, and all software change requests. 
The outputs of this process include the controlled version of all 
project documents, software releases, approved change requests, and 
software configuration status reports. This process is applicable to any 
developed or procured software. 

2.5.3 Training 

Training helps ensure that the personnel involved in software 
engineering projects have the necessary skills to perform their tasks, 
and are completely conversant with the procedures and standards that 
affect their work. 

2.5.4 Quality Assurance 

This process consists of systematic management reviews and quality 
audits, which assure that processes, products and services in the 
software engineering process conform to their established and intended 
requirements, and to their established plans, standards and procedures. 
The quality assurance function should be performed by a second party, 
rather than the software developers and verifiers. It can be performed 
by an outside quality assurance organization, or internally as a 
separate quality function dedicated purely to the project. 


___-------------------------------------------------------------

þ CMPQwk 1.42 999

--- Maximus/2 3.01