The “Lifecycle” of Software.

1. The “Lifecycle” of Software. Chapter 5

2. Lifecycle Models • Many different lifecycle models • Waterfall • Spiral • Exploratory Programming • Opportunistic development

3. Waterfall Model Stakeholders Needs Analysis System Requirements Analysis Architecture Design Detailed Design Coding And Testing System Testing

4. Alternatives to the Waterfall Model • The “Waterfall” model can mislead: boundaries between phases are not always distinct, nor are the “activies” in the phases strictly exclusive. • The Waterfall model is not the only model there is!

5. The spiral model • The “Sprial” model suggests that activities might be repeated: that is, during the software lifecycle there are several “waterfall” model cycles. • The software is finished only when a predefined level or risk has been satisfied!

6. Spiral http://www.stsc.hill.af.mil/crosstalk/2001/05/boehm.html

7. Exploratory programming • Exploratory programming is for the development of programs in environments where the requirements are volatile or there are no expert “customers” • As the requirements are explored using code, when a satisfactory product is achieved, the project is complete.

8. Develop Software Criteria Build Software System Use It Deoiver It Is it adequate Exploratory Programming

9. Opportunistic development • Opportunistic development is driven more by a business model, in which allocated resources drive the rate of development and activities. • Many times, resources are put on the most difficult problems first, leading to the nickname “hardest-part-first” development.

10. The Phases of Development • The phases of development are not exclusive. For instance, design can legitimately happen during the requirements phase. • Ideally, though, the activities reserved to other phases are kept to a minimum • The general phases are: requirements, specification, design, coding, and testing. (Maintenance is not included in this discussion, but be aware that it exists!)

11. Requirements • During the requirements phase, activities revolve around the definition of the problem. • These activities usually include interviews with end-users, recording requirements information, exploration of any existing workflows or systems, use-case identification, and so on.

12. Specification • The specification phase involves translating the information from the requirements phase into a more structured form. • In addition, analysis usually takes place, which systematically explores the requirements for conflicts, or identifies missing or incorrect requirements. • The output of this phase is information suitable for partitioning into a design (and testing!)

13. Design • During design, a software architecture is developed, and the specified requirements are partitioned into the design. • The architecture can be developed formally (as in the case of SA/SD), or can be laid down based on experience acquired from developing similar systems. • The output from this phase is module specifications suitable for development of code.

14. Code • The coding phase translates the design (and as a result, the specification), into executable code. • The output from the coding phase is code suitable for testing. Typically, this means that it compiles, links, and satisfactorily passes a subset of sets, sometimes called a “smoke test.”

15. Testing • Testing compares the developed code to the requirements and specifications, using a set of specifically designed tests. • The problems found during testing (defects, or “bugs”), are turned back over to the development team for correction, then the test activity begins again with the next release.

16. Software inspection • One of the best ways to catch software defects is to find them before they are “built into” the system. • Software inspection provides a method for doing this. • Simply put, software inspection uses “many eyes” to check work as it is released for production.

17. Inspection works • It has been demonstrated many times that software inspection traps defects early in the process. • Inspection can be used on every software artifact: requirements, specifications, design, code, and even tests.

18. The participants and the procedure • Author: Producer of software artifact (code, specification, design, test, whatever). • Inspectors: Critical reviewers of artifact. • Recorder: Records comments from inspectors. • Moderator: Keeps the discussion “on topic”.

19. The participants and the procedure (cont’d) • Inspectors take turn critiquing a page, module, function, or whatever has been agreed upon as a “unit”. Recorder records inspectors comments. • Author may ask for elaboration or points, moderator make sure discussion doesn’t “escalate”. • Next instructor critiques the same page, and so on until all instructors have critiqued the “unit”. • The cycle begins again with the next page (or “unit.”)

20. Inspection is expensive • Inspection is “expensive” in resources. • Time is required to prepare the materials, study the materials, and attend the review. • Other activities must halt while the inspection activities occur.

21. What can an individual do? • In the event that an entire “formal” inspection is prohibitive (four people minimum), alternative forms exist. • Work with another engineer to perform a scaled-down version of the inspection. • This can work if both engineers are experienced in inspection, and have a good handle on their ego, as well as a sensitivity to the other person’s feelings!

22. Maintenance Throughout the Lifecycle • “Maintenance” is “corrective” action: in essence, updating documents (and code) to fix defects. • The “defects” may be a changed requirement, design element, or test. • These changes can have an impact on may software artifacts, so they need to be updated, or “maintained.”

23. Debugging • Debugging can reveal problems that are really ‘bugs’ in the specification: it behaves exactly as specified, but it is wrong! • Inspections can also be considered “debugging”, and can also uncover design flaws, specification flaws, and so on.

24. Configuration management • Configuration management is not just version control! • Configuration management outlines how a change moves through a review process, how changes to documents are made, and how changed documents are distributed! • This make sure every group has a chance to assess the impact of a change before it is made!

25. Managing a Development Lifecycle • Fundamental questions pop up during software development: Are we on track? Do we have enough people? What are the current issues and problems? • A few simple tools can help with some of these basic questions, and any software engineer can put these together at any time.

26. Progress reports • Progress reports can be prepared by the individual or team to outline basic ‘status’. • These reports contain basic information essential to management: what was done this week, what is planned for next, and what obstacles have been encountered.

27. Dividing effort among the phases • Knowing how effort escalates during the development process, and knowing how this effort relates to the calendar is important for managers! • Remember, schedule is calendar-days, while effort is man-months (or weeks, or whatever.) • A man-month might well fit into a week: four engineers working for one-week (schedule) is a man-month (effort).