Software Engineering Lecture 2: Software Life Cycles

Software Engineering Lecture 2: Software Life Cycles

Stefan Hallerstede Århus School of Engineering

25 August 2011

1

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

2


3

Developing Software

Question: How to develop software?

4


5

Developing Software Code & Fix

?

SOFTWARE

6


?

code

SOFTWARE

6


?

code

fix

SOFTWARE

6


?

code

fix

SOFTWARE

6


?

code

fix

SOFTWARE

6


7

Software Process From The Internet (Source: xkcd)

8

What Do We Expect Of A Software Process?

I

What is the aim of having one?

I

What is a good software process?

9

What Do We Expect Of A Software Process?

I

What is the aim of having one?

I

What is a good software process?

I

What is good software? Correctness

Reliability

Efficiency

Integrity

Usability

Maintainability

Testability

Flexibility

Portability

Reusability

Interoperability

9


10


11

The Waterfall Model Sequential1

1

Winston W. Royce (1970) Managing the Development of Large Software Systems. IEEE WESCON 12

The Waterfall Model Sequential1

Royce notes that this process often cannot be followed in practice. 1


The Waterfall Model Iterative1

Instead it is common to iterate between development phases.

1


The Waterfall Model V-Model2

2

Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE 13

The Waterfall Model V-Model2 Requirements

Acceptance testing

Analysis

System testing

Architectural design

Integration testing

Detailed design Unit testing Coding

2


The Waterfall Model V-Model2 Requirements

Acceptance testing

Analysis

System testing


Integration testing

Detailed design Unit testing Coding

The V-Model emphasises the need for testing matching the development phases.

2


Iterative Development The Spiral Model3

3

Barry W. Boehm (1988) A Spiral Model of Software Development and Enhancement. Computer 21(5), IEEE

14


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


14


3


14


The Spiral Model takes into account: risk analysis

3



The Spiral Model takes into account: risk analysis and project management

3



15

Incremental Delivery I

System is not delivered as a whole but in small increments

I

Customer is involved in decision on increments

Requirements specification Final system Assign requirements to increments

Design system architecture

Develop system increment

Validate increment

Integrate increment

Validate system

16

Component-Based Software Engineering Requirements specification

I I

Component analysis

Requirements modification

System design with reuse

Development and integration

System validation

Targeted at reuse Process stages adapted to this aim: I

I

I

I

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

I

Is this a reasonable approach?

I

When could it be used? 17

Software Design Process Without Reuse I

Turn requirements specification into an executable system

I

Interleaved model of design from architecture to algorithms

Requirements specification

Implementation Design activities


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

I

Can this be used with incremental delivery?

18


19

Agile Processes Agile Manifesto4

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: I

Individuals and interactions over processes and tools

I

Working software over comprehensive documentation

I

Customer collaboration over contract negotiation

I

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

Agile Processes Unified Process5

Core Workflows: Organisation along time PHASES Organisation along content

Inception

Elaboration

Construction

Transition

Business modeling Requirements Analysis and Design Implementation Test Deployment 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 Process5

Core Workflows: Organisation along time PHASES Organisation along content

Inception

Elaboration

Construction

Transition

Business modeling Requirements Analysis and Design Implementation Test Deployment 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

Six fundamental best practices:6 1. Develop software iteratively.

6

Ian Sommerville (2007) Software Engineering, 8th edition. Addison-Wesley. 22


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



Six fundamental best practices:6 1. Develop software iteratively. 2. Manage requirements.

6



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



Six fundamental best practices:6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures.

6



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



Six fundamental best practices:6 1. Develop software iteratively. 2. Manage requirements. 3. Use component-based architectures. 4. Visually model software.

6



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



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



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



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



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



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



23

Agile Processes Two Popular Examples

I

Extreme Programming: Leverage developer creativity and minimise administrative overhead keywords: small releases, simple design, write tests first, refactoring, pair programming, continuous integration, coding standards

I

Scrum: Self-organising autonomous teams implement product increments in parallel keywords: sprint, product backlog, prioritised requirements

24

Agile Processes Extreme Programming7

7

Kent Beck (2000) Extreme Programming Explained. Embrace Change. Addison Wesley 25

Agile Processes Scrum8

8

Ken Schwaber, Mike Beedle (2002) Agile software development with Scrum. Prentice Hall. 26


27

Summing Up Advantages And Disadvantages Of Different Software Processes9

Waterfall vs Spiral vs Agile

9

Eric J. Braude, Michael E. Bernstein (2011) Software Engineering – Modern Approaches. Wiley. 28

The Waterfall Process I

Advantages I I I

I

Simple and easy to use Easy to allocate resources Works well for smaller projects or when requirements are well understood

Disadvantages I I I I

Requirements must be known upfront Late feedback by users Lack of parallelism Inefficient use of resources

29

The Spiral Process I

Advantages I I I

I

Risks are managed early and throughout the process Software evolves as the project progresses Planning is built into the process

Disadvantages I I

Complicated to use May be overkill for small projects

30

The Agile Process I

Advantages I I I

I

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 I I I

Problematical for large application Problematical for large teams Documentation output is questionable

31