Download Software Processes - The Department of Computer Science

Software Engineering
Software processes
Software Engineering 2011
Department of Computer Science Ben-Gurion university
Based on presentation by Mira Balaban Department of Computer Science Ben-Gurion university
Based on slides of:
Igor Potapov: http://www.csc.liv.ac.uk/~igor/COMP201
Ian Sommerville: http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/Presentations/index.html
Kent Beck and Ward Cunningham
Amir Tomer: http://webcourse.cs.technion.ac.il/234321/Winter2004-2005/en/ho.html
Alistair Cockburn
The Software Process
 A structured set of activities required to develop a
software system
 Specification
 Analysis, design and implementation.
 Validation
 Evolution
 A software process model is an abstract
representation of a process
 It presents a description of a process from some particular
perspective
Software Engineering, 2011
Software Processes
2
Software Development Approaches
 Generic Software Process Models
1. The waterfall model (Linear Sequential Model)
 Separate and distinct phases of specification and development
2. Evolutionary development
 Specification, development and testing are interleaved
 Formal systems development (example - ASML)
 A mathematical system model is formally transformed to an
implementation
Software Engineering, 2011
Software Processes
3
Waterfall Model
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
Software Engineering, 2011
Software Processes
4
Waterfall model phases
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
The drawback of the waterfall model is the difficulty of
accommodating change after the process is underway
Software Engineering, 2011
Software Processes
5
Waterfall model Requirement and Design
Artefacts produced in the requirements and Design phases
 SRS -Software Requirements specification document
 SRS might include:
 User usage stories (scenarios) – Use cases.
 Static analysis – class diagrams.
 Behavioural analysis – sequence diagrams, statecharts.
The specification and design activities are heavily time
consuming.
Software Engineering, 2011
Software Processes
6
The requirements document

The requirements document is the official statement of
what is required of the system developers.

Should include both a definition of user requirements and a
specification of the system requirements.

It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather than
HOW it should do it
Software Engineering, 2011
Software Processes
7
Users of a requirements document
Software Engineering, 2011
Software Processes
8
The Waterfall process characterization:






Figure out what
Figure out how
Then do it
Verify was done right
Hand product to customer
Perfect requirement definition?
Software Engineering, 2011
Software Processes
9
Waterfall model problems
 Inflexible partitioning of the project into distinct stages
 Difficult to respond to changing customer requirements
This model is only appropriate when the requirements are
well-understood
Waterfall model describes a staged development process
 Based on hardware engineering models
 Change during development is unlikely
 Widely used in large systems: military and aerospace
industries
Software Engineering, 2011
Software Processes
10
Why Not a Waterfall
Because software is different :
• No fabrication step
• Program code is another design level
• Hence, no “commit” step – software can always be changed…!
• No body of experience for design analysis (yet)
• Most analysis (testing) is done on program code
• Hence, problems not detected until late in the process
• Waterfall model takes a static view of requirements
• Ignore changing needs
• Lack of user involvement once specification is written
• Unrealistic separation of specification from the design
• Doesn’t accommodate prototyping, reuse, etc
Software Engineering, 2011
Software Processes
11
Evolutionary development
Concurr ent
activities
Outline
description
Software Engineering, 2011
Specification
Initial
version
Development
Intermediate
versions
Validation
Final
version
Software Processes
12
Characteristics of Evolutionary Development
 Modern development processes take evolution as
fundamental, and try to provide ways of managing, rather
than ignoring, the risk.
 System requirements always evolve in the course of a
project.
 Specification is evolved in conjunction with the software –
No complete specification in the system development
contract. Difficult for large customers.
 Two (related) process models:
 Incremental development
 Spiral development
Software Engineering, 2011
Software Processes
13
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 prioritised 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.
Software Engineering, 2011
Software Processes
14
Incremental Development – Version I
Define outline
requirements
Develop system
increment
Design system
architecture
Assign requirements
to increments
Integrate
increment
Valida te
increment
Valida te
system
Final
system
System incomplete
Software Engineering, 2011
Software Processes
15
‫‪Incremental Development – Version I‬‬
‫דרישות‬
‫אימות‬
‫ניתוח‬
‫אימות‬
‫הנדסת מערכת‬
‫ארכיטקטורה‬
‫אימות‬
‫תכן מפורט‬
‫מימוש‬
‫מימוש‬
‫הקמת‬
‫מימוש‬
‫מבנה (‪)build‬‬
‫‪1,2,...,n‬‬
‫מימוש‬
‫שילוב‬
‫בדיקות‬
‫הפעלה מבצעית‬
‫מסירה‬
‫פרישה‬
‫‪Software Processes‬‬
‫‪16‬‬
‫פיתוח‬
‫אחזקה‬
‫‪Software Engineering, 2011‬‬
‫‪Incremental Development – Version II‬‬
‫מבנה ‪1‬‬
‫ניתוח‬
‫מבנה ‪2‬‬
‫ניתוח‬
‫תכן‬
‫מבנה ‪n‬‬
‫מימוש‬
‫ושילוב‬
‫ניתוח‬
‫תכן‬
‫תכן‬
‫מימוש‬
‫ושילוב‬
‫מסירה‬
‫מסירה‬
‫מימוש‬
‫ושילוב‬
‫קבוצת ניתוח‬
‫קבוצת תכן‬
‫קבוצת מימוש‬
‫מסירה‬
‫‪Software Processes‬‬
‫‪17‬‬
‫‪Software Engineering, 2011‬‬
Incremental Development –
Advantages
 Customer value can be delivered with each increment
so system functionality is available earlier.
 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.
Software Engineering, 2011
Software Processes
18
Incremental Development – Problems
 Lack of process visibility.
 Systems are often poorly structured.
 Applicability claims in the literature:
 For small or medium-size interactive systems.
 For parts of large systems (e.g. the user interface).
 For short-lifetime systems.
Software Engineering, 2011
Software Processes
19
Incremental means adding, iterative
means reworking (by Alistair Cockburn)
 Incremental development is a staging and scheduling strategy in which the various
parts of the system are developed at different times or rates and integrated as they are
completed. The alternative is to develop the entire system with a big bang integration at
the end.
 Iterative development is a rework scheduling strategy in which time is set aside to
revise and improve parts of the system. The alternative development is to get it right the
first time (or at least declare that it is right!).
Iterate
Increment
fundamentally means “change”.
fundamentally means “add onto”.
repeating the process on the same
section of work
repeating the process on a new
section of work.
repeat the process (, design,
repeat the process (, design,
implement, evaluate),
implement, evaluate),
 http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=108
Software Engineering, 2011
Software Processes
20
Incremental Development

The first increment delivers one slice of
functionality through the whole system.

The second increment delivers another
slice of functionality through the whole system.

The third increment delivers the rest of
the system
Software Engineering, 2011
Software Processes
21
Iterative Development
 \
 The first iteration delivers enough of
feature 1 to evaluate what is correct
and what needs revision.
 After the second iteration, some revised
parts still need improvement.
 The third iteration produces the final
and stable feature
Software Engineering, 2011
Software Processes
22
Incremental & iterative - summary
 Iterative model - This model iterates requirements, design, build and test phases




again and again for each requirement and builds up a system iteratively till the
system is completely build.
Incremental model - It is non integrated development model. This model
divides work in chunks and one team can work on many chunks. It is more
flexible.
Spiral model - This model uses series of prototypes in stages,
the development ends when the prototypes are developed into functional
system. It is flexible model and used for large and complicated projects.
Evolutionary model - It is more customer focused model. In this model the
software is divided in small units which is delivered earlier to the customers.
V-Model - It is more focused on testing. For every phase some testing activity
are done.
Software Engineering, 2011
Software Processes
23
The (Rational) Unified Process
 A modern process model derived from the work on the
UML.
 Normally described from 3 perspectives
 A dynamic perspective that shows phases over time;
 A static perspective that shows process activities;
 A practice perspective that suggests good practice.
Software Engineering, 2011
Software Processes
24
(R)UP phase model
Phase iteration
Inception
Elaboration
Software Engineering, 2011
Cons truction
Software Processes
25
Transition
(R)UP phases
 One cycle consists of four phases:
 Inception
 Establish the business case for the system.
 Elaboration
 Develop an understanding of the problem domain and the system
architecture.
 Construction
 System design, programming and testing.
 Transition
 Deploy the system in its operating environment.
Software Engineering, 2011
Software Processes
26
(R)UP phases and iterations
Picture taken from: http://www.ibm.com/developerworks/webservices/library/ws-soa-term2/
Software Engineering, 2011
Software Processes
27
(R)UP
 In each phase many different workflows (like management,




environment, design, implementation workflow, etc.) can be
addressed simultaneously.
At the end of each cycle some kind of prototype or artifact
are produced.
The phases can be repeated many times (i.e. iterations),
producing one or many prototypes or artifacts.
During the cycles the requirements are stable which offers
possibilities to plan the development process for this cycle.
Between the cycles the requirements change.
Software Engineering, 2011
Software Processes
28
(R)UP good practice
 Develop software iteratively
 Manage requirements
 Use component-based architectures
 Visually model software
 Verify software quality
 Control changes to software
Software Engineering, 2011
Software Processes
29
Spiral Development
 Process is conceived 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.
Software Engineering, 2011
Software Processes
30
Spiral model (Boehm 87)
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.
Planning
The project is reviewed and the
next phase of the spiral is
planned.
Software Engineering, 2011
Development and validation
A development model for the
system is chosen which can be
any of the generic models.
Software Processes
31
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.
Software Engineering, 2011
Software Processes
32
Agile Methods
Result from dissatisfaction with the overheads involved in design
methods.
Software Development History:
During the 1970s, it was discovered that most large software development
projects failed.
 During the 1980s, many of the reasons for those failures began to be
recognized.
 In the 1990s, experiments and measurements were used to validate individual
methods to prevent failure.
 The current decade is characterized by complete processes to improve
success.

Software Engineering, 2011
Software Processes
33
Project Failure – the trigger for Agility
 One of the primary causes of project failure was the
extended period of time it took to develop a
system.
 Costs escalated and requirements changed.
 Agile methods intend to develop systems more quickly
with limited time spent on analysis and design.
Software Engineering, 2011
Software Processes
34
Agile Development
Software Engineering, 2011
Software Processes
35
What is an Agile method? (1)





Focus on the code rather than the design.
Based on an iterative approach to software
development.
Intended to deliver working software quickly.
Evolve quickly to meet changing requirements.
There are claims that agile methods are probably best suited to
small/medium-sized business systems or PC products.
Software Engineering, 2011
Software Processes
36
What is an agile method? (2)
 Agile proponents believe:
 Current software development processes are too
heavyweight or cumbersome
 Too many things are done that are not directly related to software
product being produced
 Current software development is too rigid
 Difficulty with incomplete or changing requirements
 Short development cycles (Internet applications)
 More active customer involvement needed
Software Engineering, 2011
Software Processes
37
What is an agile method? (3)
 Agile methods are considered
 Lightweight
 People-based rather than Plan-based
 Several agile methods
 No single agile method
 Extreme Programming (XP) most popular
 No single definition
 Agile Manifesto closest to a definition
 Set of principles
 Developed by Agile Alliance
Software Engineering, 2011
Software Processes
38
Summary of Principles of agile methods
Principle
Description
Customer involvement
The customer should be closely involved throughout the
development process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of the system.
Incremental delivery
The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process
The skills of the development team should be recognised and
exploited. The team should be left to develop their own ways of
working without prescriptive processes.
Embrace change
Expect the system requirements to change and design the system
so that it can accommodate these changes.
Maintain simplicity
Focus on simplicity in both the software being developed and in
the development process used. Wherever possible, actively work
to eliminate complexity from the system.
Software Engineering, 2011
Software Processes
39
What are the Agile Methodologies?
eXtreme Programming has received the most attention,
but here is a list:
 XP
 SCRUM
 DSDM
The Crystal Family
ASD
FDD
dX (agile RUP)
 Open Source
 Agile Modeling
 Pragmatic Programming




Since Larman is based on (R)UP, dX might be interesting.
Software Engineering, 2011
Software Processes
40
eXtreme Programming
 Development and delivery of very small increments of
functionality.
 Relies on constant code improvement, user
involvement in the development team and pair wise
programming.
 Emphasizes Test Driven Development (TDD) as part of
the small development iterations.
Software Engineering, 2011
Software Processes
41
Claimed Problems with agile methods





It can be difficult to keep the interest of customers who are
involved in the process.
Team members may be unsuited to the intense
involvement that characterizes agile methods.
Prioritising changes can be difficult where there are
multiple stakeholders.
Maintaining simplicity requires extra work.
Contracts may be a problem as with other approaches to
iterative development.
Software Engineering, 2011
Software Processes
42
Problems with incremental
development (from a waterfall eye…)

Management problems


Contractual problems


The normal contract may include a specification; without a
specification, different forms of contract have to be used.
Validation problems


Progress can be hard to judge and problems hard to find because there
is no documentation to demonstrate what has been done.
Without a specification, what is the system being tested against?
Maintenance problems

Continual change tends to corrupt software structure making it more
expensive to change and evolve to meet new requirements.
Software Engineering, 2011
Software Processes
43
Is / Isn’t: Misconstruing the message
1. Agile SD is cheating
2. Agile SD requires the best developers
3. Agile SD is hacking
4. Agile SD won’t work for all projects
Software Engineering, 2011
Software Processes
44
1. Agile techniques are “cheating”.
·
·
·
·
·
·
Hire good people;
Seat them close together to help each other out;
Get them close to the customers and users;
Arrange for rapid feedback on decisions;
Let them find fast ways to document their work;
Cut out the bureaucracy.
This is:
cheating
stacking the deck
a good idea
the heart of agile software development
Software Engineering, 2011
Software Processes
45
2. Agile only works with the best developers.
 Every project needs at least one experienced and competent
lead person. (Critical Success Factor)
 Each experienced and competent person on the team
permits the presence of 4-5 “average” or learning people.
 With that skill mix, agile techniques have been shown to
work many times.
Software Engineering, 2011
Software Processes
46
3. Agile is hacking. (Hacker interpretations
are available & inevitable.)
Hackers: “...spend all their time coding”
Agilists: ...test according to project priorities,
recheck results with users often.
Hackers: “...talk to each other when they are stuck”
Agilists: ...talk to each other and customers as
a matter of practice.
Hackers: “...avoid planning”
Agilists: ...plan regularly
Hackers: “...management caves in out of fear”
Agilists: ...expect management to provide priorities,
& participate jointly project adjustments.
Software Engineering, 2011
Software Processes
47
4. Agile won’t work for all projects.
Right. (Business isn’t fair).
Agile is an attitude prioritizing:
Project evaluation based on delivered code.
Rapid feedback.
People as a value center.
Creativity in overcoming obstacles.
Not every team
... values the Agile value set.
... can set up the needed trust and communication.
Software Engineering, 2011
Software Processes
48