Software Development Models: Waterfall and Spiral Sung Hee Park Department of Mathematics and Computer Science Virginia State University August 21, 2012

Announcements  (tentative) Course web page:  SoftwareDesignAndDevelopment SoftwareDesignAndDevelopment  Project teams should be formed by next week.  Last time, course motivation. software crisis, software development tasks.

= = = =Template follows= = = =  Short title (up to 40 characters):  Long title:  Contact person and their contact information:  Project description (paragraph):  Project deliverables:  Expected impact of the project:  Required skills of the team engaging in the project:  URLs to follow for additional information:  Type of project (web site, video, audio, computer security, data structure, game, database,...):

Discussion: Your Programming/System Development Experience  What is the biggest project you’ve been a part of?  How many lines of code was it (or other complexity measure) ?  Did you sit and think and draw a few diagrams before you started to code?  If it was a team project, how was your team experience?

Do We Need a Software Process Model?  Designing simple software (such as homework assignments) has two steps  1 Analysis - we think!  2 Design - we code!  However, in this class we consider software which is more complex  In terms of size of development team, having actual customers, and lines of code.

The Two-Step Methodology Has Benefits  All steps are creative  Programmers are happy doing them, unlike beaurocratic activities  Customers are happy to pay programmers to do this

But It Doesn’t Scale  Bigger development team means task needs to split up, in a way that they can be easily composed to form the resulting system  How do we ensure we know what the customer meant when they asked for feature X? How do we ensure we give them only what they pay for?  What about cross-cutting concerns, such as security, accountability, performance, upgradeablily etc?

What is a Software Process Model?  It determines the order of the stages involved in software development and evolution  It provides the answer to the following two questions?  What shall we do next?  How long shall we continue to do it?  First software process model: waterfall model

Software Process Models  Waterfall Model  Spiral Model  Agile Software Development Model

Waterfall Model

Additional Steps Are Necessary  System Requirements  Software Requirements  Analysis  Software Architecture  Design (Coding)  Testing  Maintenance

Good and Bad in the Waterfall Model?  The Good  Simple!!!  Plenty of documentation, which is good (allows for management of project)  In use since the 50s, and still in use for very large custom, built from scratch software projects.  The Bad  Testing is towards the end of the model, and it may expose fundamental problems, requiring rework  Customer is not involved

Questions  How can we do better? What model do you propose?

Evolutionary development  Exploratory development  Objective is to work with customers and to Evolutionary development evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.  Throw-away prototyping  Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

Evolutionary Development

Problems with Evolutionary development  Problems  Lack of process visibility;  Systems are often poorly structured;  Special skills (e.g., in languages for rapid prototyping) may be required.  Applicability  For small or medium-size interactive systems;  For parts of large systems (e.g., the user interface);  For short-lifetime systems.

The Spiral Model

The Spiral Model is Flexible  A series of iterations where  A system is prototyped  Risk is considered  Various documents are produced  At the end of each iteration you consider what you’ve accomplished and what is left to be done.

Agile Software Development Models  Some similarities to the spiral model  Trades-off long-term planning for quick adaptability  Proven to work on smaller software projects accomplished by small teams (<10 collocated developers)

Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Twelve principles underlie the Agile Manifesto:  1 Customer satisfaction by rapid, continuous delivery of useful software  2 Working software is delivered frequently (weeks rather than months)  3 Working software is the principal measure of progress  4 Even late changes in requirements are welcomed  5 Close, daily cooperation between business people and developers  6 Face-to-face conversation is the best form of communication (co- location)  7 Projects are built around motivated individuals, who should be trusted  8 Continuous attention to technical excellence and good design  9 Simplicity  10 Self-organizing teams  11 Regular adaptation to changing circumstances

Individual Presentations  Prepare quick (5-10 minute) presentations for next week on a particular agile method  SCRUM  Lean Software Development  Extreme Programming (XP)  Open Unified Process  Getting Real  etc.  Use google (or you other favorite way to obtain information) to teach us and convince us why a particular model is good.  Make slides, but not too many (generally, < 5)  Aim for clarity!!!! Don’t put up anything in a slide that you do not understand.