SW Lifecycle 1

Software Development

Life Cycle Models

Intro to Development 2

Unless otherwise expressly stated, all original material of whatever nature created by John F. Dooley and included in this web site and any related pages, including the site's archives, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

SW Lifecycle 3

References

• McConnell, Rapid Development, Microsoft Press, 1996.

• Spolsky, Joel on Software, Apress, 2004.• Rainwater, Herding Cats, Apress, 2002.• Brooks, The Mythical Man-Month, Addison-

Wesley, 1995.• Dooley, Software Development and Professional

Practice, 2011.

SW Lifecycle 4

Process References

• From McConnell, chapters 6 & 7.• Spolsky, chapters 5 though 10.• Rainwater, chapter 4,• Brooks, chapters 16 and 17, • Robert C. Martin, C++ Newsletter, March, April,

and June, 1999, and• Dooley, chapter 2…

SW Lifecycle 5

The Software Life Cycle

• Every program - no matter what size has1. Conception2.Requirements/Exploration/Modeling3.Design4.Coding and Debugging5.Testing6.Release7.Maintenance/Software Evolution8.Retirement

SW Lifecycle 6

the life cycle

• these phases may overlap• they may merge• for small programs you may not even realize you’re

doing one or more of them• but every one of them is done for every program

written.

SW Lifecycle 7

Life Cycle Models• Every life cycle model

is a variation on two fundamental types– Do a complete life cycle,

steps 2-7, and (sometimes) start again

– Do a partial life cycle, usually steps 3-5, creating a prototype and then do it again as new or clarified requirements are created.

1.Conception

2.Requirements/ Exploration/Modeling

3.Design

4.Coding and Debugging

5.Testing

6.Release

7.Maintenance/Software Evolution

8.Retirement

SW Lifecycle 8

Code and Fix “Model”

(Prayer optional)Release

Product

Code andFix

Conceptual Development

SW Lifecycle 9

Code and Fix Model

• Often used instead of project management• No formal requirements, documentation, QA,

testing, etc.• Works okay for quick, disposable tasks

(e.g. proof of concept) - no maintenance• Works well for single person projects• VERY DANGEROUS model for anything larger

SW Lifecycle 10

Classic Waterfall Model

Release &Maintenance

Conceptual Development

RequirementsAnalysis

Architectural Design

DetailedDesign

Coding &Unit Test

SystemTesting

SW Lifecycle 11

Classic Waterfall Model

• Works well for:– Known requirements AND known technologies– Weak or inexperienced staff (lots of structure)

– High quality requirements (must have!)

• Problems:– Very rigid if used religiously

– Nearly impossible to define requirements adequately

– Few signs of ongoing progress– No useful data on progress until implementation phase

– Most useful for new products

• I have never seen a classic waterfall work in practice.

SW Lifecycle 12

Waterfall with FeedbackConceptual Development

RequirementsAnalysis

Architectural Design

DetailedDesign

Coding &Unit Test

SystemTesting

SW Lifecycle 13

Spiral Life Cycle Model

• First incremental delivery model.• Developed by Boehm, 1988.• Focuses on addressing major risk areas for a

project (requirements, architecture, etc.)• Each “mini-project” addresses one or more risk

areas, then start the next mini-project• A.k.a. the cinnamon roll model :-)

SW Lifecycle 14

SW Lifecycle 15

Spiral Model

• Is often combined with other life cycle models within each mini-project

• Pros– Handles risk very well

• Cons– Very complicated– Hard to define and resolve many mini-projects– Hard to stay focused on overall project goals

SW Lifecycle 16

Iterative development

The best practice is to iterate and deliver incrementally, treating each iteration as a closed-end "mini-project," including complete requirements, design, coding,integration, testing, and internal delivery. On the iteration deadline, deliver the (fully-tested, fully-integrated) system thus far to internal stakeholders. Solicit their feedback on that work, and fold that feedback into the plan for the next iteration.

(from “How Agile Projects Succeed,” at http://www.adaptionsoft.com/on_time.html)

SW Lifecycle 17

Prioritize Requirements/Features

In this practice, you tend to rank all features by business value. In each iteration, you plan to build the highest-priority remaining features. The finished system consists only of high-ROI features. And should the project be cancelled early, the system is robust and fully integrated, and may contain enough business-critical functionality to pay back your development investment so far.

(from “How Agile Projects Succeed,” at http://www.adaptionsoft.com/on_time.html)

SW Lifecycle 18

The Basic Rule

“Your project, the whole project, has a binary deliverable. On the scheduled completion day, the project has either delivered a system that is accepted by the user, or it hasn’t. Everyone knows the result on that day.

The object of building a project model is to divide the project into component pieces, each of which has this same characteristic: Each activity must be defined by a deliverable with objective completion criteria. The deliverables are demonstrably doneor not done.”

Tom DeMarco, “Controlling Software Projects”, 1982.

SW Lifecycle 19

The key to iterative development…

“Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some.” (from Robert Fulghum ‘All I Really Need to Know I learned in Kindergarten’, 1988)

or in the software development world,

analyze some and design some and code some and test some every day.

SW Lifecycle 20

Evolutionary Prototyping

• a.k.a. Incremental Prototyping• prioritize requirements as you get them.• Refine using customer and testing feedback until

the customer accepts product• Good for changing requirements, or a poorly

understood application area• Sounds suspiciously like an agile model

SW Lifecycle 21

Evolutionary Prototyping

Happy

NotDone Yet

Release

Initial Concept & Requirements

Refine Design & Prototype

Quick Design

Build Prototype

Final Testing

Customer Evaluation, new/updated Requirements

SW Lifecycle 22

Evolutionary Prototyping

• Recognizes that it’s very hard to plan full project from the start and that feedback is the critical element of good analysis and design.

• Risky, but has good track record

SW Lifecycle

Evolutionary Prototyping

• Pros: – improved progress visibility, – good customer and end user input to

requirements• Cons:

– danger of unrealistic schedule, budget, and progress expectations;

– possibility of bad design, – possibility of low maintainability; – may have lots of re-work. (yes, but refactoring

is good!)23

SW Lifecycle 24

Lightweight (aka Agile) Models

• Lightweight - less documentation and fewer process controls

• small to mid-sized projects (10K - 100K LOC)• small teams (<20 developers)• all agile models are iterative

SW Lifecycle 25

Extreme Programming (XP)

• circa 1995• Useful for small teams (~10)• Relies on

– Heavy customer involvement (on site customer required)

– Continuous Unit Testing (Test Driven Development) and reviews

– Pair programming– Short release cycles and frequent releases

SW Lifecycle 26

• Features of eXtreme Programming:

• Planning

• User stories are written.

• Release planning creates the schedule.

• Make frequent small releases

• The project is divided into iterations

• Iteration planning starts each iteration.

• Move people around

• A stand-up meeting starts each day.

• Fix XP when necessary

SW Lifecycle

• Designing

• Simplicity, simplicity, simplicity

• Choose a system metaphor

• Use CRC cards for design sessions.

• Refactor whenever and wherever possible.

27

SW Lifecycle 28

• Coding

• The customer is always available

• Code must be written to agreed standards

• Code the unit test first

• All production code is pair programmed

• Integrate often

• Use collective code ownership

• Leave optimization till last.

• No overtime

SW Lifecycle

• Testing

• All code must have unit tests

• All code must pass all unit tests before it can be released.

• When a bug is found tests are created.

• Acceptance tests are written by the on-site customer and run often and the scores are published.

29

SW Lifecycle 30

Scrum

• Scrum is an agile process • uses short iterations to develop incremental

products.• Core practices:

– Small Teams– Frequent Builds– Loosely-coupled design– Constant Testing– Iteration Controls (time-boxing)

SW Lifecycle 31

How Scrum Works

• Scrum is characterized by the sprint– 30-day iteration– ScrumMaster runs daily ScrumMeetings

• the three questions:– What have you completed since the last Scrum

meeting?– What got in your way of completing this work?– What will you do between now and the next Scrum

meeting?

SW Lifecycle 32

Sprint Rules

• Total focus—no unwanted diversions allowed• NO interruptions/changes from the outside• New work may be uncovered by the team

– and only by the team– it is added to the sprint backlog

SW Lifecycle 33

SW Lifecycle 34

the overall agile process

• Get a first set of requirements (using paper prototypes and/or use cases/scenarios)

• Prioritize the requirements• Decide on our iteration cycle (Usually about 3-5

weeks; you should use 1 or 2 weeks)• Decide on which requirements will be in this next

iteration cycle.• Take the requirements and create a high-level

design of the product.

SW Lifecycle

• Assign requirements to design components.• reduce the design components to a set of tasks• decompose the tasks into smaller tasks• estimate the time it will take to write each of the

smaller tasks. If any task estimate is longer than one day (8 hours), break the task up into pieces until you get down to a set all of whom have estimates <= 8 hours.

35

SW Lifecycle

• pick the list of high-priority tasks that fit into one iteration cycle. If this doesn't include all the requirements designated for that iteration, then move some to the next iteration.

• Write and test the code for all the tasks for the current iteration.

• Release the current iteration to the customer, who should run acceptance tests on it.

• Fix any bugs found in the acceptance tests.• Go back to step 4 and start again.• When you've finished all your planned iterations,

OR you've reached your deadline, then release the product.

36

SW Lifecycle 37

Questions to Ask when deciding on a Process:

• Consider:– How well-known and stable are your

requirements?– How big is the project? (How many features?)– How well-known and stable is your

architecture?– What are your reliability needs?– Will there be many versions of your product?– How much risk do you expect?– How constrained is the schedule?

• Is there a drop-dead date?

SW Lifecycle 38

More Questions to Ask...

– Will midcourse corrections be likely?– Does the customer need visible progress?– Does your management need visible progress?– How sophisticated is your team with respect to

the life cycle you pick?– How big is your team?

• See the table on pages 156-7 (McConnell - Rapid Development)