1 Software Engineering Lecture 2: Software Life Cycles Stefan Hallerstede Århus School of Engineering 25 August 2011
2 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
3 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
4 Developing Software Question: How to develop software?
5 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
6 Developing Software Code & Fix? SOFTWARE
6 Developing Software Code & Fix? code SOFTWARE
6 Developing Software Code & Fix? code fix SOFTWARE
6 Developing Software Code & Fix? code fix SOFTWARE
6 Developing Software Code & Fix? code fix SOFTWARE
7 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
Software Process From The Internet (Source: xkcd) 8
9 What Do We Expect Of A Software Process? What is the aim of having one? What is a good software process?
9 What Do We Expect Of A Software Process? What is the aim of having one? What is a good software process? What is good software? Correctness Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reusability Interoperability
10 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
11 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
The Waterfall Model Sequential 1 1 Winston W. Royce (1970) Managing the Development of Large Software Systems. IEEE WESCON 12
The Waterfall Model Sequential 1 Royce notes that this process often cannot be followed in practice. 1 Winston W. Royce (1970) Managing the Development of Large Software Systems. IEEE WESCON 12
The Waterfall Model Iterative 1 Instead it is common to iterate between development phases. 1 Winston W. Royce (1970) Managing the Development of Large Software Systems. IEEE WESCON 12
The Waterfall Model V-Model 2 2 Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 13
The Waterfall Model V-Model 2 Requirements Acceptance testing Analysis System testing Architectural design Integration testing Detailed design Unit testing Coding 2 Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 13
The Waterfall Model V-Model 2 Requirements Acceptance testing Analysis System testing Architectural design Integration testing Detailed design Unit testing Coding The V-Model emphasises the need for testing matching the development phases. 2 Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 13
Iterative Development The Spiral Model 3 3 Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 14
Iterative Development The Spiral Model 3 1. Objective setting Definition of objectives for the phase Identification of risks and planning of alternative strategies 2. Risk assessment and reduction Analyse risks, and choose or adapt development model 3. Development and validation 4. Planning Review project Decide whether to continue with spiral Draw up plan for next phase 3 Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 14
Iterative Development The Spiral Model 3 3 Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 14
Iterative Development The Spiral Model 3 The Spiral Model takes into account: risk analysis 3 Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 14
Iterative Development The Spiral Model 3 The Spiral Model takes into account: risk analysis and project management 3 Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 14
15 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
16 Incremental Delivery System is not delivered as a whole but in small increments Customer is involved in decision on increments Requirements specification Assign requirements to increments Final system Design system architecture Develop system increment Validate increment Integrate increment Validate system
17 Component-Based Software Engineering Requirements specification Component analysis Requirements modification System design with reuse Development and integration System validation Targeted at reuse Process stages adapted to this aim: Component analysis: Search for component matching best the requirements Requirements modification: Modify requirements to reflect available component System design with reuse: Designers incorporate components to be reused, development of new software only if reuse is not possible Development and integration: Missing pieces of software are implemented, and reused components integrated Is this a reasonable approach? When could it be used?
18 Software Design Process Without Reuse Turn requirements specification into an executable system Interleaved model of design from architecture to algorithms Requirements specification Implementation Design activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design System architecture Software specification Interface architecture Component specification Data structure specification Algorithm specification Design products Can this be used with incremental delivery?
19 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
Agile Processes Agile Manifesto 4 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. 4 Kent Beck, et al. (2001) Manifesto for Agile Software Development. 20
21 Agile Processes Unified Process 5 Core Workflows: Organisation along time Organisation along content Business modeling Requirements Analysis and Design Implementation Test Deployment PHASES Inception Elaboration Construction Transition Preliminary Iterations Iter#1 Iter#2 Iter#n Iter#n+1 Iter#n+2 Iter#m Iter#m+1 ITERATIONS Supporting Workflows: Configuration and Change Management, Project Management, Environment 5 Philippe Kruchten (2004) The rational unified process: an introduction, 3rd ediiton. Addison-Wesley.
21 Agile Processes Unified Process 5 Core Workflows: Organisation along time Organisation along content Business modeling Requirements Analysis and Design Implementation Test Deployment PHASES Inception Elaboration Construction Transition Preliminary Iterations Iter#1 Iter#2 Iter#n Iter#n+1 Iter#n+2 Iter#m Iter#m+1 ITERATIONS Supporting Workflows: Configuration and Change Management, Project Management, Environment 5 Philippe Kruchten (2004) The rational unified process: an introduction, 3rd ediiton. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. Plan increments of the system based on customer priorities and develop and deliver the highest priority system features early in the development process. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. Explicitly document the customer s requirements and keep track of changes to these requirements. Analyse the impact of changes to the system before accepting them. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. Structure the system architecture into components and rely on reusable software components. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software. Use graphical UML models to present static and dynamic views of the software. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley. 22
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software. 5. Verify software quality. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software. 5. Verify software quality. Ensure that the software meets the organisational quality standards. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software. 5. Verify software quality. 6. Control changes to software. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software. 5. Verify software quality. 6. Control changes to software. Manage changes to the software using a change management system and configuration management procedures and tools. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
22 Agile Processes Unified Process Six fundamental best practices: 6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software. 5. Verify software quality. 6. Control changes to software. 6 Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley.
23 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
24 Agile Processes Two Popular Examples Extreme Programming: Leverage developer creativity and minimise administrative overhead keywords: small releases, simple design, write tests first, refactoring, pair programming, continuous integration, coding standards Scrum: Self-organising autonomous teams implement product increments in parallel keywords: sprint, product backlog, prioritised requirements
25 Agile Processes Extreme Programming 7 7 Kent Beck (2000) Extreme Programming Explained. Embrace Change. Addison Wesley
Agile Processes Scrum 8 8 Ken Schwaber, Mike Beedle (2002) Agile software development with Scrum. Prentice Hall. 26
27 Contents Naive Software Development Code & Fix Towards A Software Process Software Process Models Traditional Process Models Alternative Process Models Agile Process Models Agile Development Methods Two Examples Concluding Remarks
Summing Up Advantages And Disadvantages Of Different Software Processes 9 Waterfall vs Spiral vs Agile 9 Eric J. Braude, Michael E. Bernstein (2011) Software Engineering Modern Approaches. Wiley. 28
29 The Waterfall Process Advantages Simple and easy to use Easy to allocate resources Works well for smaller projects or when requirements are well understood Disadvantages Requirements must be known upfront Late feedback by users Lack of parallelism Inefficient use of resources
30 The Spiral Process Advantages Risks are managed early and throughout the process Software evolves as the project progresses Planning is built into the process Disadvantages Complicated to use May be overkill for small projects
31 The Agile Process Advantages The project always has demonstrable results Developers tend to be more motivated Customers are able to provide better requirements because they can see the evolving product Disadvantages Problematical for large application Problematical for large teams Documentation output is questionable