Software Life Cycle. Management of what to do in what order

Software Life Cycle Management of what to do in what order

Software Life Cycle (Definition) The sequence of activities that take place during software development. Examples: code development quality assurance (QA) changing client requirements management intervention redevelopment QA again etc.

Typical Life Cycle (at the worst short-lived companies) Management (1. Imagines printer software.) Sales (2. Sells copy machine software.) Software Development Quality Assurance (QA) (3. Develops really cool walking/talking AI that will operate fax machines.) (4. Unsure what code does, but tests for bugs and agrees product will properly toast bread.) Customer (5. Sues.)

Need Communication and Control Model from one company where I worked. (And the basis of many early.coms.) brainstorm idea Developers requirements match code developed QA developers tell management about product Management pass buck to sales Sales convince customers we have a good product Customer

Problems? Mostly works, but 1. QA has no real feedback. By definition the code does what the developers say it will. Just minor bug control. 2. Development does whatever they want (fun). 3. Management only manages sales, not developers or QA. 4. What if Development didn t do a good job of anticipating market needs? Are they business majors?

Can You Suggest a Better Model? Developers QA Management Sales Customer Try it

Classic Waterfall Model An idealized linear model in roughly 5 steps. Analyze Specify Design Build Test

Waterfall Picture Analyze Specify Design Build Test Also called throw-it-over-the-wall model.

Waterfall Details 1. Analyze (management, marketing, sometimes development) consult with client, or brainstorm use case diagrams ensure useful 2. Specify (development management, QA) set requirements document communication between management and developers break up into modules for each developer (sometimes part of the Design stage)

Waterfall Details (cont.) 3. Design (development, dev management, QA) functional specification document class diagram sequence diagram (if necessary) 4. Build (development) write code ensure modularity, flexibility ensure high cohesion, low connectivity implementation document (when done) use case scenarios for QA (for your detailed piece) 5. Test (QA, development) ensure reliable

Design Stage Has Many Review Steps Reviews facilitate communication between developers and developers boss (nail down expectations). Functional Spec Review This is the functionality I will code. Parrot use case diagram in code-like terms. Design Document Review Here s how I ll really do this in detail. Includes class diagram. Implementation Document Review Despite what I said, this is the way it really worked. Includes class diagram. Post-Mortem Review This is what worked well or did not work well. Lessons for next time. Reviews go by many different names

Other Stages Have Many Steps But as software developers we are primarily concerned with Design steps. Take business courses for other stages.

Advantages of Waterfall Model Easy to understand. Easy to implement. Commonly used. Easy to modify. Many government and big business contracts require you to use and document this approach.

Problems With Waterfall Model Many criticisms of the standard waterfall model, including 1. Problems are not discovered until Test stage. 2. Requirements must be completely specified before the software is designed - requirement changes make the model unstable. 3. Design and coding often turn up requirements inconsistencies, missing components, and unexpected development needs. 4. System performance cannot be tested until the system is almost coded. Linear and uni-directional. Can t go backwards.

Alternative: Prototyping Model A big failure of waterfall is that changes in requirements muck up everything. Solution: build a prototype. Or a quick mock up, or partial implementation Show it to the customer. Revise requirements. Repeat.

Prototyping Model Picture Specify (Requirements) Quick Design Revise Requirements Build Prototype not satisfied Show Customer satisfied Full Design the rest is the same

Two Types of Prototypes 1. Throw away prototype. 2. Re-usable prototype. Modularity a must! Advantages, disadvantages? Speed for prototype vs. speed for final product. Time is money

Problems With Prototype Model When do you stop iterating? picky customers are never satisfied. Solution: Can set arbitrary time limits on each iteration. 1 week. Difficult for big products. The prototype can be too big a job. Solution: Rapid throwaway. Quick and dirty prototypes. Not re-useable.

Iterative Model Standard operating system software approach. 1. Develop software and release to public. 2. Using customer s experiences, improve, redesign, re-implement, re-release. 3. Iterate, and keep releasing with new and better functionality. Modularity is essential! Why?

Iterative Model Picture Analyze Specify Design Build Test Sometimes also includes the prototype model. Deliver

Iterative Advantages/Disadvantages Advantages 1. incorporates the customer s feedback naturally. 2. changing requirements are incorporated at two levels. 1. prototyping 2. new releases 3. generate excitement/buzz with limited beta release. Disadvantages annoy customer with poor releases.

Spiral Model Developed by Boehm, 1988. Iterative. Rarely used exactly. Frequently used to some extent.

Spiral Model Picture increasing cost 4. Evaluate 1. Analyze risks commitment partition 3. Engineer: Design Implement QA 2. Specify requirements

Spiral Advantages 1. Works with any of the previous models. 2. Naturally incorporates changes in requirements. 3. Good model for handling risk. Can do high risk in first loop (so bail early if necessary). Lower risk items later.

Spiral Model Is Vague! (Disadvantage) Doesn t indicate what the result of each loop should be. A final product? An increasingly refined product? Partial products, slowly integrated? Doesn t indicate when to end. Probably should happen in risk assessment. (uncommon) (common) (common) So with inexperienced hands, costs can blossom.

Object-Oriented Process Just the above models with OO practices. Heavier use of UML to guide the above models. Attempt to reuse components.

OO Process and Reusability VERY DIFFICULT. (true reusability hard to achieve) Still maturing. One idea: 1. Identify potentially reusable classes/packages. 2. Set these aside into a possibly reusable library 3. When a new customer s project is started, identify those classes in the library that might be reused. 4. If they can be, then generalize/improve these classes so that they really are modular and reusable. 5. Pass on the cost of generalization to the new customer (who will see it as a cost savings because you don t have to develop from scratch!)

Many Other Life Cycle Models Clean Room Process Emphasis on defect prevention rather than correction. Use mathematical proofs to show each part of the code is correct. Invented by IBM. Defect Prevention Process Etc. whenever something doesn t work, find the root cause and suggest an improvement to the life cycle process