The “Lifecycle” of Software. Chapter 5
Lifecycle Models • Many different lifecycle models • Waterfall • Spiral • Exploratory Programming • Opportunistic development
Waterfall Model Stakeholders Needs Analysis System Requirements Analysis Architecture Design Detailed Design Coding And Testing System Testing
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!
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!
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.
Develop Software Criteria Build Software System Use It Deoiver It Is it adequate Exploratory Programming
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.
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!)
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.
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!)
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.
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.”
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.
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.
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.
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”.
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.”)
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.
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!
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.”
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.
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!
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.
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.
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).