Software Life Cycle Models/Processes CMSC 345 Software EngineeringFall 05 Section 0301
Objectives • To introduce the general phases of the software development life cycle • To introduce the software process model concept • To describe different generic process models and their pros and cons
The Software Process • A structured set of activities required to develop a software system. These activities include: • Requirements (Specification) • Design • Implementation (Coding) • Testing (Validation) • Maintenance (Evolution) • A software process model is an abstract representation of a process.
Requirements The process of establishing • what services are required of the system • the constraints on the system’s operation and development Requirements are the what part
Software Design The process of converting the system specification (requirements) into a software structure that realizes that specification Design is the How part
Implementation • Translating a design into a program and removing errors from that program • Programming is a personal activity - there is no generic programming process. • Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process. • The activities of design and implementation are closely related and generally are interleaved.
Testing • Verification and validation is intended to show that a system conforms to its specification and meets the requirements of the system customer. • Involves checking and review processes and system testing • System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.
System Maintenance • Software is inherently flexible and can change (as opposed to hardware). • In the past, there has been a demarcation between development and evolution (maintenance). This is increasingly irrelevant as fewer and fewer systems are completely new. • Software engineering should be thought of as an evolutionary process where software is continually changed over its lifetime in response to customer needs.
Software Process Models • The Waterfall model • Separate, non-overlapping phases of specification and development • Evolutionary development • Specification and development are interleaved • Reuse-based development • The system is assembled from some (most likely) or all existing components
Waterfall Model Pros and Cons Pros Cons
Evolutionary Development Two general types: • Exploratory development • Objective is to work with the customers to evolve a final system from an initial outline specification. Process starts with the well-understood requirements. • Prototyping (throw-away?) • Objective is to understand the system requirements. Process starts with the poorly understood requirements.
Evolutionary Development Pros and Cons Pros Cons
Prototyping Pros and Cons Pros Cons
Question Should a prototype be evolved into the final system or thrown away?
Reuse-oriented Development • Based on systematic reuse where systems are integrated from existing components or COTS (commercial-off-the-shelf) systems • This approach is becoming more important, but there is still limited experience with it.
Reuse-oriented Development Pros and Cons Pros Cons
Process Iteration • System requirements ALWAYS evolve in the course of a project. So, process iteration where earlier stages are reworked is always part of the process, especially for large systems. • Iteration can be applied to any of the generic process models. • Examples of two iterative approaches: • Incremental development • Spiral development
Incremental Development • Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. • User requirements are prioritized and the highest priority requirements are included in early increments. • Once the development of an increment is started, the requirements are frozen, though requirements for later increments can continue to evolve.
Incremental Development Advantages • Customers do not have to wait until the entire system is delivered until they can gain value from it. • Early increments act as a prototype to help elicit requirements for later increments. • Lower risk of overall project failure • The highest priority system services tend to receive the most testing.
Spiral Development • Process is represented as a spiral rather than as a sequence of activities with backtracking • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required • Risks are explicitly assessed and resolved throughout the process.
Spiral Model Sectors • Objective setting • Specific objectives for the phase are identified • Risk assessment and reduction • Risks are assessed and activities put in place to reduce the key risks • Development and validation • A development model for the system is chosen which can be any of the generic models • Planning • The project is reviewed and the next phase of the spiral is planned
Efficient Lots of “just in time” Adjust to circumstances (Re)Plan regularly Lots of person-to-person comm. Adaptively cut fat in the process Hacking Giant Energy Up Front (GEUF) Only XP (XP is one alternate) Plan-less People sitting in isolation rigid adherence Good agile developmentIs / DoesIsn’t / Doesn’t Agility *can* Be heavier or lighter, depending on circumstances Use various requirements techniques (e.g., use cases, stories, features) In agile development we value following the principles over following specific practices !
(Never forget this!) Lighter-agile vs. Heavier-agile : Light is good, but has limits. # people needed Heavy methodology more people Light methodology fewer people Problem Size
Contents • Agile methodologies • What is XP? • Risk: the basic problem and how XP address risks • Basic principles • Basic activities • Practices
Agile alliance • February 2001 – group of 17 people • www.AgileAlliance.org • Agile word • The manifesto • Principles and recommendations
Methodology • Software development methodology – the set of conventions the team adopts • Methodology can be lightened • By getting running software out for examination sooner • By increasing the richness of the communication channels • Light delivers more quickly and with reduced cost
Light methodologies • XP • Adaptive Software Development • Scrum • Crystal • Feature Driven Development • DSDM (Dynamic System Development Method)
Why “extreme” XP takes commonsense principles and practices to extreme levels. • If code reviews are good, we'll review code all the time (pair programming). • If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
Why “extreme”-2 • If design is good, we'll make it part of everybody's daily business (refactoring). • If simplicity is good, we'll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work). • If architecture is important, everybody will work defining and refining the architecture all the time (metaphor).
Why “extreme”-3 • If integration testing is important, then we'll integrate and test several times a day (continuous integration). • If short iterations are good, we'll make the iterations really, really short—seconds and minutes and hours, not weeks and months and years (the Planning Game).
XP promises • To reduce project risk, • To improve responsiveness to business changes, • To improve productivity throughout the life of a system, • To add fun to building software in teams All at the same time.
What Is XP? XP is a • lightweight, • efficient, • low-risk, • flexible, • predictable, • scientific, and • fun way to develop software.
Innovation of XP • Putting all proven practices (for the implementation strategy and for the management strategy) under one umbrella • Making sure they are practiced as thoroughly as possible. • Making sure the practices support each other to the greatest possible degree.
Risk: The Basic Problem • Schedule slips • Project canceled • System goes sour • Defect rate • Business misunderstood • Business changes • False feature rich • Staff turnover
How does XP address risks? • Schedule slips • short Release cycles - a few months at most, • Iterations of customer requested features - one- to four-week. • Tasks - one- to three-day • implementing the highest priority features first
How does XP address risks?-2 • Project canceled • XP asks the customer to choose the smallest release that makes the most business sense. • System goes sour • comprehensive suite of tests, which are run and re-run after every change. • XP always keeps the system in prime condition.
How does XP address risks?-3 • Defect rate - XP tests from the perspective of • programmers - writing tests function-by function • customers - writing tests program-feature-by-program-feature. • Business misunderstood • customer to be an integral part of the team.
How does XP address risks?-4 • Business changes • XP shortens the release cycle, so there is less change during the development of a single release. • False feature rich • only the highest priority tasks are addressed. • Staff turnover • programmers accept responsibility for estimating and completing their own work • human contact among the team