Software Processes

Software Engineering
Software processes
What / who / why is Process
?Models
 What: Go through a series of predictable steps--- a road map that
helps you create a timely, high-quality results.
 Who: Software engineers and their managers, clients also. People
adapt the process to their needs and follow it.
 Why: Provides stability, control, and organization to an activity that
can if left uncontrolled, become quite chaotic. However, modern
software engineering approaches must be agile and demand ONLY
those activities, controls and work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the
software that you are building. One process might be good for
aircraft avionic system, while an entirely different process would be
used for website creation.
 How to ensure right: A number of software process assessment
mechanisms that enable us to determine the maturity of the
software process. However, the quality, timeliness and long-term
viability of the software are the best indicators of the efficacy of the
process you use.
2
Software Engineering, 2011 Software Processes
2
Definition of Software Process
A framework for the activities, actions, and
tasks that are required to build high-quality
software.
SP defines the approach that is taken as software

is engineered.
Is not equal to software engineering, which also

encompasses technologies that populate the
process– technical methods and automated tools.
3
3
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
4
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
5
Waterfall Model
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
6
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
7
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.
8
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
9
Users of a requirements
document
Specify the requirements and
System read them to check that they
meet their needs.hey
T
customers
specify changes to the
requirements
Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process
Use the requirements to

System
engineers understand what system is to
be developed
System test Use the requirements to

engineers develop validation tests for
the system
System Use the requirements to help

maintenance understand the system and
engineers the relationships between its
parts
10
The Waterfall process
:characterization
 Figure out what

 Figure out how
 Then do it
 Verify was done right
 Hand product to customer
 Perfect requirement definition?
11
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
12
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
13
Evolutionary development
Concurr ent
activities
Initial
Specification
version
Outline Intermediate
Development
description versions
Final
Validation
version
14
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
15
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.
16
Incremental Development –
Version I
Define outline Assign requirements Design system

requirements to increments architecture
Develop system Valida te Integrate Valida te

increment increment increment system
Final
system
System incomplete
17
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.
18
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.
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 fundamentally means
.”“change .”“add onto
repeating the process on repeating the process on
the same section of . a new section of work
work
 http://www.stickyminds.com/BetterSoftware/magazine.asp?
repeat the process (,
fn=cifea&id=108 repeat the process (,
design, implement, design, implement,
, evaluate) , evaluate)
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
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
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.
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.
24
UP phase model(R)
Phase iteration
Inception Elaboration Construction Transition
25
UP phases(R)
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.
26
(R)UP phases and iterations
Picture taken from: http://www.ibm.com/developerworks/webservices/library/wssoaterm2/
27
UP(R)
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.
28
UP good practice(R)
Develop software iteratively
Manage requirements
Use component-based architectures
Visually model software
Verify software quality
Control changes to software
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.
30
Spiral model (Boehm 87)
Objective setting Risk assessment and reduction
Specific objectives for the Risks are assessed and activities
phase are identified. put in place to reduce the key
risks.
Planning Development and validation
The project is reviewed and the A development model for the
next phase of the spiral is system is chosen which can be
planned. any of the generic models.
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.
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.
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.
34
Agile Development
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.
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
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
38
Summary of Principles of agile
methods
39
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.
40
Problems with incremental
development (from a waterfall
eye…)
 Management problems
 Progress can be hard to judge and problems hard to find
because there is no documentation to demonstrate what has
been done.
 Contractual problems
 The normal contract may include a specification; without a
specification, different forms of contract have to be used.
 Validation problems
 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.
41
”.Agile techniques are “cheating. 1
· 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
42
Agile only works with the best. 2
.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.
43
Agile is hacking. (Hacker. 3
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.
44
.Agile won’t work for all projects. 4
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.
45

Software Processes

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Processes

Transféré par

Droits d'auteur :

Formats disponibles

Software Engineering

SP defines the approach that is taken as software

Is not equal to software engineering, which also

The drawback of the waterfall model is the

Artefacts produced in the requirements and Design

The specification and design activities are heavily time

 Should include both a definition of user

 It is NOT a design document. As far as

Use the requirements

Use the requirements to

System test Use the requirements to

System Use the requirements to help

 Figure out what

This model is only appropriate when the requirements

Waterfall model describes a staged development process

Define outline Assign requirements Design system

Develop system Valida te Integrate Valida te

tend to receive the most testing.

Applicability claims in the literature:

 The first increment delivers one slice of

functionality through the whole system.

slice of functionality through the whole system.

 The first iteration delivers enough of

Inception Elaboration Construction Transition

Software Development History:

 Agile methods intend to develop systems

 Every project needs at least one

 Each experienced and competent person

 With that skill mix, agile techniques have

Hackers: “...talk to each other when they are stuck”

Hackers: “...avoid planning”

Hackers: “...management caves in out of fear”

Agile is an attitude prioritizing:

Not every team

Vous aimerez peut-être aussi