1

SOFTWARE
ENGINEERING
Lecture 3 : Chapter 2 – Software Processes
(cont.)
 2

Process Activities
• The four basic process activities are:
1. Specification
2. Development
3. Validation
4. Evolution
• They are organized differently in different development
processes
o In the waterfall model, they are organized in sequence
o whereas in incremental development they are interleaved.

• Type of software, people, and organizational structures

involved controls how these activities are carried out.
 3

1. Software Specification
• Also called REQUIREMENTS ENGINEERING, functions
are:
• Understanding and defining system required services
• identifying the constraints on the system’s operation and development.
• produce an agreed requirements document that specifies a system
satisfying stakeholder requirements.
• critical stage of the software process
• errors at this stage inevitably lead to later problems in the system
design and implementation
• Requirements are presented at two levels of detail:
• End-users and customers: need a high-level statement of the
requirements
• System developers: need a more detailed system specification.
 4

Requirements Engineering activities

1. Feasibility study:
• Possibility of implementation according to the current technology
• Cost study within budget
• Must be cheap and quick
• Output: decision to continue or not
2. Requirements elicitation and analysis:
• Collecting information through observations, discussions, analysis and so
on
• Output: understand the system to be specified
3. Requirements specification:
• Translating collected information into a set of requirements
• Output: requirements document with user and system requirements
4. Requirements validation:
• checks the requirements for realism, consistency, and completeness
• Discovering problems
• Output: correct final version
 5

The requirements engineering process

 6

2. Software design and implementation

1. Architectural design:
• overall structure of the system
• principal components (sub-systems or modules)
• their relationships
• how they are distributed
2. Interface design:
• define the interfaces between system components
• interface specification must be unambiguous
3. Component design:
• Design operation of each system component
• simple statement of the expected functionality or list of changes to be made to a
reusable component
• design model may be used to automatically generate an implementation
4. Database design:
• design the system data structures
• Their representation in a database
• Programming is a personal activity and there is no general process
that is usually followed.
 7

A general model of the design process

 8

3. Software Validation
• Also known as verification and validation (V&V) aims to
show that a system both conforms to its specification and
that it meets the expectations of the system customer.
• Program testing, where the system is executed using
simulated test data, is the principal validation technique.

Stages of testing
 9

Testing process stages

1. Development testing:
• Components are tested individually by system developers
• Components may be simple entities (functions or object classes) or
may be coherent groupings of these entities
• New component versions can be automatically tested by tools like
“JUnit”
2. System testing: (integrating system components)
• Finding errors that result from unanticipated interactions between
components and component interface problems.
• Test if system meets its functional and non-functional requirements
• Testing the emergent system properties
Note: for large systems:
• Components are integrated into subsystems to be tested
• Subsystems are integrated to form final system
 10

Testing process stages

3. Acceptance testing: (for operational use)
• Uses real customer data not simulated
• May result in errors and omissions in the system requirements definition
• reveal requirements problems
• Decide whether performance is accepted or not.
 11

4. Software Evolution
• Accepted software leads to hardware manufacturing
which is hard and expensive to be changed
• Software should accept changes more easily
• Software maintenance is a boring and dull activity.
• But it’s never less important than software development
which is an interesting one.
• Figure in the next slide shows that software is continually
changed over its lifetime in response to changing
requirements and customer need.
 12

System Evolution
 13

Coping with change

• What is rework?
Rework means that the process that has been completed
must be redone because:
1. System response to external pressure or management priorities
changes lead to changing requirements
2. New technologies leads to new design and implementation
possibilities.
• Rework adds to the cost of software development.
• Two approaches to reduce the cost:
1. Change avoidance: include specialized change activities
2. Change tolerance: implement changes in undeveloped increments
• Ways of coping with changes are : prototyping, incremental
delivery and Boehm’s spiral model.
 14

1. Prototyping
• What is a prototype:
A prototype is an initial version of a software system that is used to:
 Demonstrate concepts
 try out design options
 find out more about the problem and its possible solutions
• Benefits of a prototype:
 Costs are controlled
 system stakeholders can experiment with the prototype early in the software
process.
 In the requirements engineering process, a prototype can help with the
elicitation and validation of system requirements.
 In the system design process, a prototype can be used to explore particular
software solutions and to support user interface design
• Prototypes do not have to be executable to be useful. Paper-based
mock-ups of the system user interface can be effective in helping
users refine an interface design and work through usage scenarios.
 15

2. Incremental development
• Some increments of the system are delivered to the customer
and deployed for use in an operational environment.
• customers identify, in outline, the services to be provided by the
system and arrange them according to priority.
• The highest-priority services are implemented and delivered
first via an increment providing a sub-set of the system
functionality.
• During development, further requirements analysis for later
increments can take place
• But requirements changes for the current increment are not
accepted.
• Once an increment is completed and delivered,customers can
put it into service.
 16

Incremental delivery advantages

1. Customers can use the early increments as prototypes
2. Customers do not have to wait until the entire system is
delivered before they can gain value from it.
3. The process maintains the benefits of incremental
development in that it should be relatively easy to
incorporate changes into the system.
4. As the highest-priority services are delivered first and
increments then integrated, the most important system
services receive the most testing so they are less likely
to encounter software failures.
 17

Incremental delivery disadvantages

1. Common facilities that are needed by all increments are
hard to identify as requirements are not defined in
detail.
2. Iterative development can also be difficult when a
replacement system is being developed.
3. There is no complete system specification until the final
increment is specified. This requires a new form of
contract, which large customers such as government
agencies may find difficult to accommodate.
 18

Heavy weight model

• Traditional models are plan driven in which work starts
with gathering of requirements and documentation of
complete set of requirements.
• Heavyweight models are traditional models such as
waterfall, prototype, incremental and spiral.
• These models are considered as heavyweight because
it involves heavy documentation.
 19

Boehm’s Spiral Model - heavyweight model

o Process is represented as a spiral rather than as a

sequence of activities with backtracking.

o Each loop in the spiral represents a phase in the process.

o No fixed phases such as specification or design - loops in

the spiral are chosen depending on what is required.

o Risks are explicitly assessed and resolved throughout the

process.
o This was the motivation behind developing the Spiral Model - Risk
 20

Boehm’s Spiral Model of the Software Process

 21

Spiral Model Sectors

o Objective setting
o Specific objectives for the phase are identified.
o Risk assessment and reduction
o Risks are assessed and activities put in place to reduce the key
risks.
o Development and validation
o A development model for the system is chosen which can be
any of the generic models. Development takes place.
o Planning
o The project is reviewed and the next phase of the spiral is
planned.
 22

Spiral Model Usage

o Spiral model has been very influential in helping people

think about iteration in software processes and
introducing the risk-driven approach to development.

o In practice, however, the model is rarely used as

published for practical software development.
 23

Key points

• Understand the principles of software engineering

• Understand what we mean by a software process

• Note the two major classifications of processes and note also

that there are numerous hybrid classifications within these.

• Software processes are the activities involved in producing a

software system.

• Software process models are abstract representations of these

processes.
 24

Key points

• Requirements engineering is the process of developing a

software specification.
• Design and implementation processes are concerned with
transforming a requirements specification into an
executable software system.
• Software validation is the process of checking that the
system conforms to its specification and that it meets the
real needs of the users of the system.
• Software evolution takes place when you change existing
software systems to meet new requirements. The
software must evolve to remain useful.