1. Slide 2.1 CHAPTER 2 THE SOFTWARE PROCESS

2. Slide 2.2 Overview l Client, Developer, and User l Requirements Phase l Specification Phase l Design Phase l Implementation Phase l Integration Phase l Maintenance Phase l Retirement l Problems with Software Production: Essence and Accidents

3. Slide 2.3 The Software Process l The software process is the way we produce software. It incorporates the –life-cycle model –CASE tools –The individuals building the software

4. Slide 2.4 Terminology l Systems analysis –Requirements + specifications phases l Operations mode –Maintenance l Design –Architectural design, detailed design l Client, developer, user l Internal software development l Contract software development (outsourcing)

5. Slide 2.5 Testing Phase? l There is NO testing phase separately l Testing is an activity performed throughout software production l Verification –Performed at the end of each phase l Validation –Performed before delivering the product to the client

6. Slide 2.6 Documentation Phase? l There is NO documentation phase separately l Every phase must be fully documented before starting the next phase –Postponed documentation may never be completed –The responsible individual may leave –The product is constantly changing—we need the documentation to do this –The design (for example) will be modified during development, but the original designers may not be available to document it

7. Slide 2.7 Requirements Phase l Assumption –The software being considered is economically justifiable l Concept exploration –Determine what the client needs, not what the client wants –Determine what constraints exist »Deadline »Reliability »Object code size (e.g., for small embedded systems) »Cost l Functionality of the product is successively refined and analyzed for technical feasibility and financial justification

8. Slide 2.8 Requirements Phase Testing l Frequently, the clients do not know exactly what they need l Rapid prototyping is often used to solve this problem – Rapid prototype - a software that is quickly put together that incorporates much of the functionality of the target product –Does not show the aspects generally invisible to the client –More on this in Chapter 10

9. Slide 2.9 Software Quality Assurance (SQA) l The role of SQA group –Ensures that the delivered project is what the client ordered and that the product has been developed correctly l SQA group is involved from the beginning of software development l Moving Target Problem –The client changes the requirements during development –Keeps changing his/her mind!

10. Slide 2.10 Requirements Phase Documentation l Rapid prototype with the records of discussion, OR l Requirements document –Must be thoroughly checked by the client, users and the development team –Finally, SQA checks it

11. Slide 2.11 Specification Phase l Specifications document (“specifications”) –Explicitly describes the functionality of the product –Specifies the inputs and the outputs –Legal contract document –Must not have phrases like “suitable”, “enough”, “optimal,” or “98% complete”

12. Slide 2.12 Specification Phase (contd) l Specifications must not be –Ambiguous –Incomplete –Contradictory l Once the specifications have been signed off –The Software Product Management Plan (SPMP) is drawn up –This is the earliest possible time for the SPMP –Shows the tasks, which members of the development team are involved in each task, and deadlines for completing each task

13. Slide 2.13 Specification Phase (contd) l SPMP –Includes the deliverables (what the client is going to get) and the milestones (when the client gets them) –Describes the software process, life-cycle model, structure of development team, project responsibilities, managerial objectives and priorities, techniques and CASE tools used, detailed schedules, budgets, resource allocations –The most important in SPMP are time and cost estimates

14. Slide 2.14 Specification Phase Testing l Traceability of specification document –Must be able to trace every statement in the spec. document to a statement made by the client during the requirements phase l Review –To determine if the specs are correct –Spec team and client participate with SQA member being the chair l Check the SPMP by SQA group

15. Slide 2.15 Specification Phase Documentation l Specification document (specifications) l SPMP

16. Slide 2.16 Design Phase l Specification—what l Design—how l Retain design decisions –When a dead-end is reached –For the maintenance team –Ideally, the design should be open-ended l Architectural design –Decompose the product into modules l Detailed design –Design each module: data structures, algorithms

17. Slide 2.17 Design Phase Testing l Traceability –Every part of the design can be linked to a statement in the specification document l Review –By the design team and the SQA group (no client)

18. Slide 2.18 Design Phase Documentation l Design –Architectural design –Detailed design

19. Slide 2.19 Implementation Phase l Implement the detailed design in code

20. Slide 2.20 Implementation Phase Testing l Code Review –The programmer explains the code to the review team, which includes a SQA member l Test cases –Informal testing (desk checking) –Formal testing (SQA)

21. Slide 2.21 Implementation Phase Documentation l Source code –Must have suitable comments l Test cases (with expected output)

22. Slide 2.22 Integration Phase l Combine the modules and check the product as a whole l Modules can be integrated –All at once or one at a time –Top to bottom in the module interconnection diagram or bottom to top

23. Slide 2.23 Integration Phase Testing l Product testing –By the integration team and SQA l Acceptance testing –By the client –The software is delivered to the client, who tests it on the actual hardware using actual data

24. Slide 2.24 Integration Phase Documentation l Commented source code l Test cases for the product as a whole

25. Slide 2.25 COTS Software l Commercial off-the-shelf (COTS) –“Shrink-wrapped software” l Nowadays, COTS software is often downloaded over the Internet –“Click-wrapped software” l Alpha testing – alpha version to selected possible clients l Beta testing – beta version (corrected alpha version) testing -> final version

26. Slide 2.26 Maintenance Phase l Maintenance –Any change once the client has accepted the software l The most money is devoted to this phase l The problem of lack of documentation

27. Slide 2.27 Maintenance Phase Testing l Must make sure that the new changes have been implemented correctly l Regression testing –Testing the modified product against previous test cases

28. Slide 2.28 Maintenance Phase Documentation l Record of all changes made, with reasons l Regression test cases

29. Slide 2.29 Retirement l Good software is maintained l Sometimes software is rewritten from scratch –Software is now unmaintainable because »A drastic change in design has occurred »The product must be implemented on a totally new hardware/operating system »Documentation is missing or inaccurate »Hardware is to be changed—it may be cheaper to rewrite the software from scratch than to modify it l True retirement is a rare event

30. Slide 2.30 Process-Specific Difficulties l Does the product meet the user’s real needs? l Is the specification document free of ambiguities, contradictions, and omissions?

31. Slide 2.31 Inherent Problems of Software Production l Hardware has inherent limits l So does software l No Silver Bullet [Fred Brooks, 1986] –Complexity –Conformity –Changeability –Invisibility l Aristotelian categories –Essence: difficulties inherent in the nature of s/w –Accidents: difficulties encountered in development

32. Slide 2.32 Complexity l Software is far more complex than hardware –Traditional abstraction will not work –We cannot understand the whole, so we cannot understand any part –Management is difficult –Maintenance is a nightmare (documentation, too)

33. Slide 2.33 Conformity l Type 1: Existing gold refinery l Type 2: New gold refinery

34. Slide 2.34 Changeability l Software is easier to change than hardware l Pressure to change –Reality –Useful software –Easier to change –Software has a long lifetime (~15 yrs) compared to hardware (~4 yrs)

35. Slide 2.35 Invisibility l Software is invisible and unvisualizable l Complete views are incomprehensible l Partial views are misleading l However, all views can be helpful

36. Slide 2.36 Is There a Silver Bullet? l What about –High-level languages –Time sharing –CASE tools l These are useful but do not solve the intrinsic problems l We have experienced –6% annual productivity increase l But, no “silver bullet” (order-of-magnitude increase) is possible l Read Chapter 2 (except sections on CMM)