1. Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun Differences between software engineering and civil engineering –Frequency of failure ( Fault Tolerance) –Attitudes toward failure –discrete v.s. continuous (state explosion) –maintenance June 5, 2000

2. Economic Aspects Issues to be considered in selecting the most economic coding technique –Training cost –Project staff learning curve –Long-term maintenance consequence

3. Maintenance Aspects Includes all changes to the product once the client has agreed that it satisfies the specification document. Figure 1.2 Maintenance is classified into two major types: corrective maintenance and enhancement (perfective maintenance and adaptive maintenance) The breakdown of maintenance effort (time) –Corrective maintenance: 17.5% –Perfective maintenance: 60.5% –Adaptive maintenance: 18% Preventive maintenance (or software reengineering): Changes made to computer programs so that they can be more easily corrected, adapted, and enhanced (Pressman, 1997)

4. Specification and Design Aspects Figures 1.4 and 1.5 Distribution of software faults among software life-cycle phases –Specification: 1.9 faults/page –Design: 0.9 faults/page –Code: 0.3 faults/page The earlier we correct a software fault, the better Techniques for requirements specifications and design are critical

5. Team Programming Aspects Interface problems among code components Communications problems among team members Software Engineering is a discipline whose aim is the production of fault-free software that is delivered on time, within budget, and satisfied the user’s needs.

6. The Object-Oriented Paradigm Structured paradigm: structured systems analysis, structured design, structured programming, and structured testing Problems of the structured paradigm: (1) unable to scale up; (2) maintenance problems The differences between the structured paradigm and the OO paradigm The advantages of the OO paradigm from the perspective of software maintenance Regression fault. A fault inadvertently introduced into one part of a product as a consequence of making an apparently unrelated change to another part of the product. Figure 1.6

7. Terminology Program: an autonomous piece of code Product: an nontrivial piece of software System: hardware-software combination Software production: (1) software development, and (2) software maintenance Methodology: a collection of techniques Paradigm: a model or a pattern Both methodology and paradigm refer to “a collection of techniques” in the text An object includes attributes and methods

8. The Software Process Requirements Specification Design Implementation Integration Maintenance Retirement

9. Testing Verification validation

10. Preliminary Definition Client Developers software Development Internal Software Contract Software User

11. Requirements Phase Determine exactly what the client needs –The functionality of the product and the constraints (cost, deadline, reliability, usability, and so forth) This preliminary investigation is sometimes called concept exploration. Rapid prototyping –Build a quick design that focuses on a representation of those aspects of the software that will be visible to the client, e.g., input approaches and output formats Requirements phase testing –The software quality assurance (SQA) group verifies with the client that final version of the rapid prototype is totally satisfactory

12. Specification Phase Describes the functionality of the product and lists any constraints that the product must satisfy. Precisely what the product is supposed to do. Potential problems of the specifications: ambiguous, incompleteness, contradictory (inconsistent) Estimation and planning follows The software project management plan (SPMP) Specification phase testing –Look for ambiguities, incompleteness, and contradictions of the specifications –Specifications review (SQA group, the client, and the specification team) –Traceability: It is possible to trace every statement in the specification document back to a statement made by the client team during the requirements phase

13. Design Phase Determine how the product is to be built (i.e., a solution to the problem to be solved) –Decide on the internal structure of the product (decomposition into modules with well-defined interfaces) –Design algorithms and select data structures –Output of the design phase: architectural design and detailed design –Record the design decisions Design phase testing –Checking whether the design agrees with the specification document and whether the specifications are reflected in some part of the design –Design review: design team and SQA group (the client is usually not involved) –Focuses on logic faults, interface faults, exception handling, and conformance to the specifications

14. Implementation Phase The component modules of the design are coded (implemented) Test cases are documented: expected results and actual output Implementation phase testing –The modules are tested while they are implemented (desk checking) Code review (code inspection)

15. Integration Phase Combine the modules and determine whether the product as a whole functions correctly Integration phase testing –Top-down or bottom-up integration testing –Integration testing focuses on testing the module interfaces (number, order, and type of the arguments) Product testing –The product as a whole is checked against the specifications (functionality and constraints) –Check whether the source code and all other types of documentation are complete and internally consistent

16. Integration Phase (2) Acceptance testing –The software is delivered to the client, who tests the software on the actual hardware, using actual data as opposed to test data –Alpha testing: Conducted at the developer’s site by the client –Beta testing: Conducted at one or more client sites by the user(s) of the product

17. Maintenance Phase Any changes made after the product has been accepted by the client Maintenance is an integral part of the software process and should be taken into consideration throughout the entire development process Maintenance phase testing –The required changes have been correctly implemented –No other inadvertent changes were made (regression testing)

18. Retirement Reasons of the retirement of a software product –No more cost effective –Increased interdependencies –Documentation not adequately maintained –New hardware/environment –Others