Class 1a Software Processes

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

Software Engineering
Software processes

Software Engineering 2011
Department of Computer Science Ben-Gurion university
Software Engineering, 2011 Software Processes
2
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
3
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
4
Waterfall Model

Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
5
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
6
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.
7
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
8
Users of a requirements document

9
The Waterfall process
characterization:

Figure out what
Figure out how
Then do it
Verify was done right
Hand product to customer
Perfect requirement definition?

10
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

11
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

Doesnt accommodate prototyping, reuse, etc
12
Evolutionary development

Validation
Final
version
Development
Intermediate
versions
Specification
Initial
version
Outline
description
Concurr ent
activities
13
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
14
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.
15
Incremental Development Version I

Validate
increment
Develop system
increment
Design system
architecture
Integrate
increment
Validate
system
Define outline
requirements
Assign requirements
to increments
System incomplete
Final
system
16
Incremental Development Version I

( build )
1,2,...,n

17
Incremental Development Version
II

n
18
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.
19
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.
20
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!).

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=
108

Increment Iterate
fundamentally means add onto. fundamentally means change.
repeating the process on a new
section of work.
repeating the process on the same
section of work
repeat the process (, design,
implement, evaluate),
repeat the process (, design,
implement, evaluate),
21

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

23
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.
24
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.
25
(R)UP phase model

Phase it erat ion
Incept ion Elaborat ion Const ruct ion Transit ion
26
(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.
27
(R)UP phases and iterations
Picture taken from: http://www.ibm.com/developerworks/webservices/library/ws-soa-term2/
28
(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.
29
(R)UP good practice
Develop software iteratively
Manage requirements
Use component-based architectures
Visually model software
Verify software quality
Control changes to software
30
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.
31
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.
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
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.
33
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.
34
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.
35
Agile Development
36
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.
37
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
38
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
39
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.

40
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.
41
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.
42
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.
43
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.

44
Is / Isnt: Misconstruing the message
1. Agile SD is cheating

2. Agile SD requires the best developers

3. Agile SD is hacking

4. Agile SD wont work for all projects
45
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
46
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.
47
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.
48
4. Agile wont work for all projects.
Right. (Business isnt 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.

Class 1a Software Processes

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Class 1a Software Processes

Uploaded by

Copyright:

Available Formats

Based on presentation by Mira Balaban Department of Computer Science Ben-Gurion university

Based on slides of:

Software Engineering, 2011 Software Processes

You might also like