Software

Process
Software Engineering
1 Presented By Dr. Huda Amin
Information Systems
[email protected]
Software Engineering - H.A.
 What is the difference between software
2
engineering and computer science?
Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities
of developing and delivering useful software.
Some knowledge of computer science is essential for
software engineers in the same way that some knowledge
of physics is essential for electrical engineers.

Software Engineering - H.A.

3 Software Process

Software Engineering - H.A.

 Software Process
4

 A software process is a set of related activities that leads to

the production of a software product.

 There are many different software processes but all must

include four activities that are fundamental to software
engineering:
1. Software specification The functionality of the software and constraints
on its operation must be defined.
2. Software design and implementation The software to meet the
specification must be produced.
3. Software validation The software must be validated to ensure that it
does what the customer wants.
4. Software evolution The software must evolve to meet changing
customer needs. Software Engineering - H.A.
 Process Descriptions
5

 They include
 Sub-activities such as requirements validation, architectural
design, unit testing, etc.
 Supporting process activities such as documentation and
software configuration management.
 The ordering of these activities.
 Products, which are the outcomes of a process activity. For
example, the outcome of the activity of architectural design
may be a model of the software architecture.
Software Engineering - H.A.
 Process Descriptions cont’d
6

 They include
 Roles, which reflect the responsibilities of the people involved in
the process. Examples of roles are project manager, configuration
manager, programmer, etc.
 Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a
product produced.
◼ For example, before architectural design begins, a pre-condition may
be that all requirements have been approved by the customer; after
this activity is finished, a post-condition might be that the UML models
describing the architecture have been reviewed.
Software Engineering - H.A.
 Software Processes Categories
7

 Software processes are categorized as either

 Plan-driven processes are processes where all of the process activities
are planned in advance and progress is measured against this plan.
 In agile processes, which will be discussed later in details, planning is
incremental and it is easier to change the process to reflect changing
customer requirements.
 Each approach is suitable for different types of software. Generally, you need to
find a balance between plan-driven and agile processes.
 For some systems, such as critical systems, a very structured development process is
required. For business systems, with rapidly changing requirements, a less
formal, flexible process is likely to be more effective.

Software Engineering - H.A.

8 Perspective Software Process Models
Waterfall Model
Incremental Development
Reuse-Orient Software Engineering
(Follows linear workflow)

Software Engineering - H.A.

 The Waterfall Model
9

 The first published model of the software development

process was derived from more general system
engineering processes (Royce, 1970).
 This model is known as the ‘waterfall model’ or
software development life cycle (SDLC).
 This model is a plan-driven process
 You must plan and schedule all of the process activities
before starting work on them.
Software Engineering - H.A.
 Waterfall Model
10

The result of each phase is one or

The following phase should not start
more documents
During that are
design, approvedwith
problems
until the previous phase has
(‘signed off’)
requirements are identified. During
finished.
coding, design problems are found
and so on. (feedback)

Software Engineering - H.A.

 Advantages
11

 Advantages

 Simple and easy to understand and implement.

 Easy to manage: Each phase documents make the

process visible so managers can monitor progress
against the development plan.

 Phases are clearly defined and completed one at

a time.
Software Engineering - H.A.
 Disadvantages
12

 Disadvantages

 Costs of producing and approving documents.

 No working software is produced until late stages.

 There is no chance to change customer requirements

(contract).

 High amount of risk.

 It takes a lot of time to produce the final software product.

Software Engineering - H.A.

 When to use waterfall model
13

 The waterfall model should only be used when

 The requirements are very well understood from the
beginning
 The requirements are unlikely to change during system
development.
 The delivery time is not a problem.

 Not suitable for projects with changing

requirements and fast delivery.
Software Engineering - H.A.
 Incremental Development
14

 The system is developed as a series of versions

(increments), with each version adding functionality to
the previous version.

 Incremental development is based on the idea of

developing an initial implementation, exposing this to
user comment and evolving it through several versions
until an adequate system has been developed.

Software Engineering - H.A.

15

Each increment or version of the

Generally, the early increments of
system incorporates some of the
the system include the most
functionality that is needed by the
important or most urgently required
customer.
functionality.

Software Engineering - H.A.

 Important benefits, compared to the waterfall model
16

1. The cost of accommodating changing customer

requirements is reduced. .
◼ The amount of analysis and documentation that has to be redone
is much less than is required with the waterfall model.

Software Engineering - H.A.

 Important benefits, compared to the waterfall model
17

2. The customer can evaluate the system at a relatively early stage in

the development to see if it delivers what is required. If not, then
only the current increment has to be changed and, possibly, new
functionality defined for later increments.
◼ It is easier to get customer feedback on the development work that has
been done. Customers can comment on demonstrations of the software
and see how much has been implemented.
◼ Customers find it difficult to judge progress from software design
documents.
◼ Easier to manage risk because risk pieces are identified and handled
during its iteration.
Software Engineering - H.A.
 Important benefits, compared to the waterfall model
18

3. More rapid delivery and deployment of useful software to

the customer is possible, even if all of the functionality has not
been included.
 Customers are able to use and gain value from the software
earlier than is possible with a waterfall process.

Software Engineering - H.A.

19

 Incremental development in some form is now the most

common approach for the development of application
systems. This approach can be either plan-driven, agile,
or, more usually, a mixture of these approaches.
 In a plan-driven approach, the system increments are
identified in advance; if an agile approach is adopted, the
early increments are identified but the development of later
increments depends on progress and customer priorities.

Software Engineering - H.A.

 From a management perspective, the incremental
approach has two problems:
20

1. The process is not visible.

 Managers need regular deliverables to measure progress.
 If systems are developed quickly, it is not cost-effective to
produce documents that reflect every version of the system.

2. System structure tends to degrade as new increments are

added.
 Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.
Software Engineering - H.A.
 Large Systems
21

 The problems of incremental development become

particularly acute for large, complex, long-lifetime systems,
where different teams develop different parts of the
system.
 Large systems need a stable framework or architecture
and the responsibilities of the different teams working on
parts of the system need to be clearly defined with respect
to that architecture. This has to be planned in advance
rather than developed incrementally.
Software Engineering - H.A.
 Reuse-Oriented Software Engineering
22

 This approach is based on the existence of a

significant number of reusable components.

 The system development process focuses on

integrating these components into a system rather
than developing them from scratch.

 These components are called (COTS or commercial

off-the-shelf systems).
Software Engineering - H.A.
 Types of Software Components
23

 There are three types of software component that may

be used in a reuse-oriented process:
1. Web services that are developed according to service
standards and which are available for remote invocation.
2. Collections of objects that are developed as a package to
be integrated with a component framework such as .NET or
J2EE.
3. Stand-alone software systems that are configured for use
in a particular environment (COTS).
Software Engineering - H.A.
24

Component
Requirements analysis: Given The
modification: the requirements
requirementsare specification, a
analyzed using
System
search design
is made for with reuse: The
components framework
to implement ofspecification.
the system is
information
Developmentabout the components
and integration: that havethat
Software been
thatdiscovered.
cannot be
designed
Usually, or
therethen an
is no existing
exact matchframework is
and thethe reused.
componentsThe designers
may betake
They are
externally modified
procured istodeveloped,
reflect the that
available
and components.
components and
usedinto account the
onlymodifications
provide components that are reused and organize the
Where
COTS systemssome of
are are the functionality
impossible,
integrated therequired.
to create component analysis
the new system. System
framework to cater for this. Some new software may have to be
activity may beinre-entered
integration, this model, to search
may be for alternative
part of thesolutions.
development
designed if reusable components are not available.
process rather than a separate activity.

Software Engineering - H.A.

 Advantages & Disadvantages
25

 Advantages
 Reduces the amount of software to be developed and so
reducing cost and risks.
 leads to faster delivery of the software.

 Disadvantages
 Requirements compromises are inevitable and this may lead to a
system that does not meet the real needs of users.
 Some control over the system evolution is lost as new versions of
the reusable components are not under the control of the
organization using them.
Software Engineering - H.A.
26 Coping with Change
Change is inevitable in all large software projects:
• Business changes lead to new and changed system
requirements.
• New technologies open up new possibilities for improving
implementations.
• Changing platforms require application changes.

Software Engineering - H.A.

 Rework
27

 There are two related approaches that may be used to

reduce the costs of rework:
1. Change avoidance:
 where the software process includes activities that can
anticipate possible changes before significant rework is
required. For example, a prototype system may be developed
to show some key features of the system to customers. They can
experiment with the prototype and refine their requirements
before committing to high software production costs.
Software Engineering - H.A.
 Rework
28

 There are two related approaches that may be used to

reduce the costs of rework:
2. Change tolerance:
 where the process is designed so that changes can be
accommodated at relatively low cost. This normally involves
some form of incremental development. Proposed changes may
be implemented in increments that have not yet been developed.
If this is impossible, then only a single increment (a small part of
the system) may have to be altered to incorporate the change.
Software Engineering - H.A.
 Two Ways of “coping with change” and Changing
System Requirements
29

1. System prototyping:
 where a version of the system or part of the system is developed
quickly to check the customer’s requirements and the feasibility of
some design decisions. This supports change avoidance as it allows
users to experiment with the system before delivery and so refine
their requirements. The number of requirements change proposals
made after delivery is therefore likely to be reduced.
2. Incremental delivery:
 where system increments are delivered to the customer for comment
and experimentation. This supports both change avoidance and
change tolerance. It avoids the premature commitment to requirements
for the whole system and allows changes to be incorporated into later
increments at relatively low cost.

Software Engineering - H.A.

 Prototyping
30

 A prototype is an initial version of a software system

that is used to demonstrate concepts, try out design
options, and find out more about the problem and its
possible solutions.
 Rapid, iterative development of the prototype is
essential so that costs are controlled and system
stakeholders can experiment with the prototype early
in the software process.
Software Engineering - H.A.
 Prototyping in Requirements Engineering Process
31

 A software prototype can be used in a software development

process to help anticipate changes that may be required:
1. In the requirements engineering process, a prototype can help
with the elicitation and validation of system requirements.
 Allows users to get new ideas for requirement, propose new system
requirements
 Reveals errors and omissions in the requirements (incorrect or
incomplete requirements)

Software Engineering - H.A.

 Prototyping in System Design Process
32

 A software prototype can be used in a software development process to

help anticipate changes that may be required:
2. In the system design process, a prototype can be used to explore
particular software solutions and to support user interface design.
 Checks the feasibility of a proposed design
◼ For example, a database design may be prototyped and tested to check that it
supports efficient data access for the most common user queries

 Support user interface design process

◼ Because of the dynamic nature of user interfaces, textual descriptions and diagrams
are not good enough for expressing the user interface requirements. Therefore, rapid
prototyping with end-user involvement is the only sensible way to develop graphical
user interfaces for software systems.

Software Engineering - H.A.

 The Process of Prototype Development
33

Software Engineering - H.A.

 Prototypes
34

 May involve leaving out functionality

 Prototype should focus on areas of the product that
are not well-understood

 Error checking and recovery may not be included in

the prototype;

 Focus on functional rather than non-functional

requirements such as reliability and security

Software Engineering - H.A.

 Prototypes
35

 Prototypes should be discarded after development as

they are not a good basis for a production system:
 It may be impossible to tune the system to meet non-
functional requirements
 Prototypes are normally undocumented
 The prototype probably will not meet normal
organizational quality standards
 Problems: It is impossible to know how long it will take. There
is no way to know the no of iterations will be required.
Software Engineering - H.A.
 Incremental Delivery
36

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

 As new increments are completed, they are integrated with

existing increments so that the system functionality improves
with each delivered increment.
Software Engineering - H.A.
 Incremental Development vs. Delivery
37

 Incremental development
 Develop the system in increments and evaluate each increment
before proceeding to the development of the next increment by
exposing it to customers for comment, without actually delivering
it and deploying it in the customer’s environment

 Incremental delivery
 Deploy an increment for use by end-users
 More realistic evaluation about practical use of software
 Difficult to implement for replacement systems as increments have
less functionality than the system being replaced.
Software Engineering - H.A.
38

Software Engineering - H.A.

 Incremental Delivery Advantages
39

1. Customers can use the early increments as prototypes and gain experience
that informs their requirements for later system increments. Unlike
prototypes, these are part of the real system so there is no re-learning
when the complete system is available.
2. Customers do not have to wait until the entire system is delivered before
they can gain value from it. The first increment satisfies their most critical
requirements so they can use the software immediately.
3. As the highest-priority services are delivered first and increments then
integrated, the most important system services receive the most testing.
This means that customers are less likely to encounter software failures in
the most important parts of the system.

Software Engineering - H.A.

 Incremental Delivery Problems
40

1. Most systems require a set of basic facilities that are used by

different parts of the system.
 As requirements are not defined in detail until an increment is to be
implemented, it can be hard to identify common facilities that are
needed by all Increments.
2. The essence of iterative processes is that the specification is
developed in conjunction with the software. However, this
conflicts with the procurement model of many organizations,
where the complete system specification is part of the system
development contract.
 In the incremental approach, 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.
Software Engineering - H.A.
 Is it the best approach?
41

 There are some types of system where incremental

development and delivery is not the best approach.
 These are very large systems where development may
involve teams working in different locations

 Some critical systems where all the requirements must

be analyzed to check for interactions that may
compromise the safety or security of the system

Software Engineering - H.A.

 Reference
42

 Sommerville, I., “Software Engineering”, 9th Edition,

Adison-Wesley.

Software Engineering - H.A.

43 Thanks for Listening
Any Questions!

Software Engineering - H.A.