Software Engineering

Chapter Two
Software processes

1
The software process
Software process: organizing a structured set of activities
to develop software systems.
Many different software processes but all involve the
following activities:

◦ Specification – defining what the system should do;

◦ Design and implementation – defining the organization of
the system and implementing the system;
◦ Validation – checking that it does what the customer wants;
◦ Evolution – changing the system in response to changing
customer needs.

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
Waterfall Model
Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance

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

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, state charts.

The specification and design activities are heavily time consuming.

6
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

7
When to use the Waterfall Model
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.

8
V-Shaped SDLC Model
A variant of the Waterfall that
emphasizes the verification and
validation of the product.
Testing of the product is
planned in parallel with a
corresponding phase of
development

9
V-Shaped Steps
Project and Requirements Planning – Production, operation and maintenance –
allocate resources provide for enhancement and corrections
System and acceptance testing – check the
entire software system in its environment
Product Requirements and Specification
Analysis – complete specification of the
software system
Integration and Testing – check that modules
interconnect correctly
Architecture or High-Level Design –
defines how software functions fulfill the
design Unit testing – check that each module acts as
expected

Detailed Design – develop algorithms for

each architectural component Coding – transform algorithms into software

10
V-Shaped Strengths
Emphasize planning for verification and validation of the product in
early stages of product development
Each deliverable must be testable
Project management can track progress by milestones
Easy to use

11
V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in requirements
Does not contain risk analysis activities

12
When to use the V-Shaped Model
Excellent choice for systems requiring high reliability – hospital patient
control applications
All requirements are known up-front
When it can be modified to handle changing requirements beyond
analysis phase
Solution and technology are known

13
Structured Evolutionary Prototyping
Model
Developers build a prototype during the requirements phase
Prototype is evaluated by end users
Users give corrective feedback
Developers further refine the prototype
When the user is satisfied, the prototype code is brought up to the
standards needed for a final product.

14
15
Structured Evolutionary Prototyping
Steps
A preliminary project plan is developed
An partial high-level paper model is created
The model is source for a partial requirements specification
A prototype is built with basic and critical attributes
The designer builds
◦ the database
◦ user interface
◦ algorithmic functions

The designer demonstrates the prototype, the user evaluates for

problems and suggests improvements.
This loop continues until the user is satisfied

16
Structured Evolutionary Prototyping
Strengths
Customers can “see” the system requirements as they
are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulates awareness of
additional needed functionality

17
Structured Evolutionary Prototyping
Weaknesses
Tendency to abandon structured program
development for “code-and-fix” development
Bad reputation for “quick-and-dirty” methods
Overall maintainability may be overlooked
The customer may want the prototype delivered.
Process may continue forever (scope creep)

18
When to use
Structured Evolutionary Prototyping
Requirements are unstable or have to be clarified
As the requirements clarification stage of a
waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-
oriented development.

19
Rapid Application Model (RAD)
Requirements planning phase (a workshop utilizing
structured discussion of business problems)
User description phase – automated tools capture
information from users
Construction phase – productivity tools, such as code
generators, screen generators, etc. inside a time-box.
(“Do until done”)
Cutover phase -- installation of the system, user
acceptance testing and user training

20
RAD Strengths
Reduced cycle time and improved productivity with
fewer people means lower costs
Time-box approach mitigates cost and schedule risk
Customer involved throughout the complete cycle
minimizes risk of not achieving customer
satisfaction and business needs
Focus moves from documentation to code.
Uses modeling concepts to capture information
about business, data, and processes.

21
RAD Weaknesses
Accelerated development process must give quick
responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.

22
When to use RAD
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized

23
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.

24
Incremental Development

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

25
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.

26
Incremental Model Strengths
Each release delivers an operational product
Customer can respond to each build
Uses “divide and conquer” breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced

27
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.

28
When to use the Incremental Model
Risk, funding, schedule, program complexity, or need for
early realization of benefits.
Most of the requirements are known up-front but are
expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development schedules
On a project with new technology

29
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!).

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

30
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

31
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

32
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.

33
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.

34
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.

35
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.

36
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.

37
Spiral Model Strengths
Provides early indication of insurmountable risks,
without much cost
Users see the system early because of rapid prototyping
tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently

38
Spiral Model Weaknesses
Time spent for evaluating risks too large for small or low-risk projects
Time spent planning, resetting objectives, doing risk analysis and
prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development phase
activities
May be hard to define objective, verifiable milestones that indicate
readiness to proceed through the next iteration

39
When to use Spiral Model
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of
potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)

40
Agile Development

41
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.

42
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.

43
What is an agile method? (2)
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

44
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.

45
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.

46
XP Practices (1-6)
1. Planning game – determine scope of the next release by combining
business priorities and technical estimates
2. Small releases – put a simple system into production, then release
new versions in very short cycle
3. Metaphor – all development is guided by a simple shared story of
how the whole system works
4. Simple design – system is designed as simply as possible (extra
complexity removed as soon as found)
5. Testing – programmers continuously write unit tests; customers
write tests for features
6. Refactoring – programmers continuously restructure the system
without changing its behavior to remove duplication and simplify

47
XP Practices (7 – 12)
7. Pair-programming -- all production code is written with two
programmers at one machine
8. Collective ownership – anyone can change any code anywhere in
the system at any time.
9. Continuous integration – integrate and build the system many
times a day – every time a task is completed.
10. 40-hour week – work no more than 40 hours a week as a rule
11. On-site customer – a user is on the team and available full-time to
answer questions
12. Coding standards – programmers write all code in accordance
with rules emphasizing communication through the code

48
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.

49
Is / Isn’t: Misinterpreting 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

50
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 level
a good idea
the heart of agile software development

51
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.

52
 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 .

53
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.

54
Thank You!
Q?

55