1. Introduction to Software Engineering
   1. Introduction
   2. Some Definitions
   3. Some Size Factors
   4. Quality and Productivity Factors
   5. Managerial Issues
2. Planning a Software Project
   1. Introduction
   2. Defining the Problem
      1. Goals and Requirements
   3. Developing a Solution Strategy
   4. Planning the Development Process
      1. The Phased Life-Cycle Model
      2. Milestones, Documents, and Reviews
      3. The Cost Model
      4. The Prototype Life-Cycle Model
      5. Successive Versions
   5. Planning an Organizational Structure
      1. Project Structure
      2. Programming Team Structure
      3. Management By Objectives
   6. Other Planning Activities
      1. Planning for Configuration Management and Quality Assurance
      2. Planning for Independent Verification and Validation
      3. Planning Phase-Dependent Tools and Techniques
      4. Other Planning Activities
3. Software Cost Estimation
   1. Introduction
   2. Software Cost Factors
      1. Programmer Ability
      2. Product Complexity
      3. Product Size
      4. Available Time
      5. Required Level of Reliability
      6. Level of Technology
   3. Software Cost Estimation Techniques
      1. Expert Judgement
      2. Delphi Cost Estimation
      3. Work Breakdown Structures
      4. Algorithmic Cost Models
   4. Staffing-Level Estimation
   5. Estimating Software Maintenance Costs
4. Software Requirements Definitions
   1. Introduction
   2. The Software Requirements Specification
   3. Formal Specification Techniques
      1. Relational Notations (Implicit Equations/Recurrence Relations/Algebraic Axioms/Regular Expressions)
      2. State-Oriented Notations (Decision Tables/Event Tables/Transition Tables/Finite-State Mechanisms/Petri Nets)
   4. Languages and Processors for Requirements Specification
      1. PSL/PSA
      2. RSL/REVS
      3. Structured Analysis and Design Technique (SADT)
      4. Structured System Analysis (SSA)
      5. GIST
5. Software Design
   1. Introduction
   2. Fundamental Design Concepts
      1. Abstraction
      2. Information Hiding
      3. Structure
      4. Modularity
      5. Concurrency
      6. Verification
      7. Aesthetics
   3. Modules and Modularization Criteria
      1. Coupling and Cohesion
      2. Other Modularization Criteria
   4. Design Notations
      1. Data Flow Diagrams
      2. Structure Charts
      3. HIPO Diagrams
      4. Procedure Templates
      5. Pseudocode
      6. Structured Flowcharts
      7. Structured English
      8. Decision Tables
   5. Design Techniques
      1. Stepwise Refinement
      2. Levels of Abstraction
      3. Structured Design
      4. Integrated Top-Down Development
      5. Jackson Structured Programming
   6. Detailed Design Considerations
   7. Real-Time and Distributed System Design
   8. Test Plans
   9. Milestones, Walkthroughs, and Inspections
   10. Design Guidelines
6. Implementation Issues
   1. Structured Coding Techniques
      1. Single Entry, Single Exit Constructs
      2. Efficiency Considerations
      3. Violations of Single Entry, Single Exit
      4. Data Encapsulation
      5. The Goto Statement
      6. Recursion
   2. Coding Style
   3. Standards and Guidelines
   4. Documentation Guidelines
      1. Supporting Documents
      2. Program Unit Notebooks
      3. Internal Documentation
7. Modern Programming Language Features
   1. Introduction
   2. Type Checking
   3. Separate Compilation
   4. User-Defined Data Types
   5. Data Abstraction
   6. Scoping Rules
   7. Exception Handling
   8. Concurrency Mechanisms
8. Software Maintenance
   1. Introduction
   2. Enhancing Maintainability during Development
   3. Managerial Aspects of Software Maintenance
   4. Configuration Management
   5. Source-Code Metrics
   6. Other Maintenance Tools and Techniques

5.7 Test Plans

A test plan prescribed various kinds of activities that will be performed to demonstrate that the software product meets its requirements.

There are four types of tests that a software product must satisfy: functional tests, performance tests, stress tests, and structural tests. Functional tests and performance tests are based on the requirements specifications; they are designed to demonstrate that the system satisfies its requirements. Therefore, the test plan can be only as good as the requirements, which in turn must be phrased in quantified, testable terms.

Functional test cases specify typical operating conditions, typical input values, and typical expected results.

Performance tests should be designed to verify response time (under various loads), execution time, throughput, primary and secondary memory utilization, and traffic rates on data channels and communication links. Performance tests will often indicate processing bottlenecks to be addressed during system testing and tuning.

It is particularly important that the expected results of each test be specified prior to system implementation and actual testing.

Stress tests are designed to overload a system in various ways. The purposes of stress testing are to determine the limitations of the system and, when the system fails, to determine the manner in which the failure is manifest.

Structural tests are concerned with examining the internal processing logic of a software system. The goal of structural testing is to traverse a specified number of paths through each routine in the system to establish thoroughness of testing.

5.8 Milestones, walkthroughs, and inspections

The two major milestones during software design are the Preliminary Design Review (PDR) and the Critical Design Review (CDR).

The major goal of PDR is to demonstrate that the externally observable characteristics and architectural structure of the product will satisfy the customer’s requirements. Functional characteristics, performance attributes, external interfaces, user dialogues, report formats, exception conditions and exception handling, product subsets, and future enhancements to the product should all be reviewed during the PDR.

Chapter Six: Implementation issues

Introduction

The primary goal of implementation is to write source code and internal documentation so that conformance of the code to its specifications can be easily verified, and so that debugging, testing, and modification are eased.

6.1 Structured coding techniques

The goal of structured coding is to linearize control flow through a computer program so that the execution sequence follows the sequence in which the code is written.

6.1.1 Single entry, single exit constructs

A modified version of the Bohm-Jacopini theorem can be stated as follows: Any single entry, single exit program segment that has all statements on some path from the entry to the exit can be specified using only sequencing, selection, and iteration.

A sufficient set of single entry; single exit constructs for specifying control flow in algorithms is:

• Sequencing: S1; S2; S3;
• Selection: if B then S1 else S2;
• Iteration: while B do S;

6.4.3 Internal documentation

Table 6.3: Typical format of subprogram and compilation unit prologues

Name of author:

Date of compilation:

Function(s) performed:

Algorithms used:

Author/date/purpose of modifications:

Parameters and modes:

Input assertion:

Output assertion:

Global variables:

Side effects:

Major data structures:

Calling routines:

Called routines:

Timing constraints:

Exception handling:

Assumptions:

Table 6.4 Commenting conventions

1. Minimize the need for embedded comments by using:
1. Standard prologues
2. Structured programming constructs
3. Good coding style
4. Descriptive names from the problem domain for user-defined data types, variables, formal parameters, enumeration literals, subprograms, files, etc.
5. Self-documenting features of the implementation language, such as user-defined exceptions, user-defined data types, data encapsulation, etc.
2. Attach comments to code that:
1. Perform major data manipulations
2. Simulate structured control constructs using goto statements
3. Use problem domain terminology in the comments.
4. Use blank lines, borders, and indentation to highlight comments.
5. Place comments to the far right to document changes and revisions.
6. Don’t use long, involved comments to document obscure, complex code. Rewrite the code.
7. Always be sure that comments and code agree with one another, and with the requirements and design specifications.

8.1 Quality Assurance

Quality assurance is “a planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical requirements.” (IEE83)

Topics in a Software Quality Assurance Plan include (BUC79):

1. Purpose and scope of the plan
2. Documents referenced in the plan
3. Organizational structure, tasks to be performed, and specific responsibilities as they relate to product quality
4. Documents to be prepared and checks to be made for adequacy of the documentation
5. Standards, practices, and conventions to be used
6. Reviews and audits to be conducted
7. A configuration management plan that identifies software product items, controls and implements changes, and records and reports changed status
8. Practices and procedures to be following reporting, tracking, and resolving software problems
9. Specific tools and techniques to be used to support quality assurance activities
10. Methods and facilities to be used to maintain and store controlled versions of identified software
11. Methods and facilities to be used to protect computer program physical media
12. Provisions for ensuring the quality of vendor-provided and subcontractor-developed software
13. Methods and facilities to be used in collecting, maintaining, and retaining quality assurance records

9.1 Enhancing maintainability during development

Table 9.1 Development activities that enhance software maintainability

• Analysis activities
• Develop standards and guidelines
• Set milestones for the supporting documents
• Specify quality assurance procedures
• identify likely product enhancements
• Determine resources required for maintenance
• Estimate maintenance costs
• Architectural Design Activities
• Emphasize clarity and modularity as design criteria
• Design to ease likely enhancements
• Use standardized notations to document data flow, functions, structure, and interconnections
• Observe the principles of information hiding, data abstraction, and top-down hierarchical decomposition
• Detailed Design Activities
• Use standardized notations to specify algorithms, data structures, and procedure interface specifications
• Specify side effects and exception handling for each routine
• Provide cross-reference directories
• Implementation Activities
• Use single entry, single exit constructs
• Use standard indentation of constructs
• Use simple, clear coding style
• Use symbolic constants to parameter use routines
• Provide margins on resources
• Provide standard documentation prologues for each routine
• Follow standard internal commenting guidelines
• Other activities
• Develop a maintenance guide
• Develop a test suite
• Provide test suite documentation

9.2 Managerial aspects of software maintenance

Change request processing can be described by the following algorithm:

—-

Project Legacy

1. Project Description
2. Initial expectations
3. Current status of the project
4. Remaining areas of concern
5. Activities/time logs
6. Technical lessons learned
7. Managerial lessons learned
8. Recommendations to future projects