1

SOFTWARE ENGINEERING
LECTURE 2 – SOFTWARE PROCESSES
 Contact Information
2

 Instructor

Dr. Mohamed Nabil Elkawkagy

 E-Mail:

[email protected]

 Office Hours:

Sunday 11-12
Thursday 10-12
 Objectives
3

 Understand the concepts of software processes and software process

models;

 Know the fundamental process activities of software requirements

engineering, software development, testing, and evolution;
 The software process
4

 A set of related activities that leads to the production of a

software product.
 The software processes are:
 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.
 Software process descriptions
5

 Process descriptions may also include:

 Products, which are the outcomes of a process activity;

 Roles, which reflect the responsibilities of the people
involved in the process;
 Pre- and post-conditions, which are statements that are
true before and after a process activity has been
performed or a product produced.
 Plan-driven and agile processes
6

 software processes are categorized as

 Plan-driven processes
 Processes where all of the process activities are planned
in advance and progress is measured against this plan.
 Agile processes,
 Planning is incremental and it is easier to change the
process to reflect changing customer requirements.
 Software process models
7

• Plan-driven model. Separate and

The waterfall model distinct phases of specification and
development.

• Specification, development and validation are

Incremental development
interleaved. May be plan-driven or agile.

Reuse-oriented software • The system is assembled from existing

engineering components. May be plan-driven or agile.

In practice, most large systems are developed using a process that incorporates elements
from all of these models.
 The waterfall model
8
 Waterfall model phases
9

 There are separate identified phases in the

waterfall model:
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance

 The main drawback of the waterfall model is that a

phase has to be complete before moving onto the
next phase.
 Waterfall model problems
10

 Inflexible partitioning of the project into distinct

stages makes it difficult to respond to changing
customer requirements.
 This model is only appropriate when the requirements are
well-understood and changes will be fairly limited during
the design process.
 Few business systems have stable requirements.

 The waterfall model is mostly used for large systems

engineering projects where a system is developed at
several sites.
Incremental development

Specification, development, and validation activities are

interleaved rather than separate, with rapid feedback across
activities.

11
 Incremental development benefits
12

The cost of 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.

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.

More rapid delivery and deployment of useful software to the
customer is possible.
 Customers are able to use and gain value from the software

earlier than is possible with a waterfall process.

 Incremental development problems
13
(Drawbacks)
 The process is not visible.
 Managers need regular deliverables to measure progress.
 System structure tends to degrade as new increments are added.
 Time and money is spent to improve the software. Incorporating further
software changes becomes increasingly difficult and costly.
 The problems of incremental development become difficult for large,
complex, long-life time systems, where different teams develop different
parts of the system.
 Large systems need a stable architecture and the responsibilities of the
different teams working on parts of the system need to be clearly defined
with respect to that architecture.
 Reuse-oriented software engineering
14

 System are integrated from existing components.

 Although the initial requirements specification stage and the validation
stage are comparable with other software processes, the intermediate
stages in a reuse-oriented process are different.
 The intermediate process stages are:
 Component Analysis
 Requirements Modification
 System Design With Reuse
 Development And Integration
 Reuse is now the standard approach for building many types of business
system
 Reuse-oriented software engineering

15

Given the requirements specification,

a search is made for components to The requirements are analyzed using

implement that specification. Usually, information about the components that

there is no exact match and the have been discovered. They are then

components that may be used only modified to reflect the available

provide some of the functionality components. Where modifications are

required. impossible, the component analysis

activity may be re-entered to search for
alternative solutions.
 Reuse-oriented software engineering

16

the framework of the system is

designed or an existing framework is
reused. The designers take into Software that cannot be externally
account the components that are procured is developed, and the reuse
reused and organize the framework components are integrated to create the
to cater for this. Some new software new system. System integration, may
may have to be designed if reusable be part of the development process
components are not available. rather than a separate activity.
 Reuse-oriented software engineering
17

 Advantage
 It reduce the amount of software to be developed and so reducing
cost and risks.
 It usually also leads to faster delivery of the software.
 Disadvantage
 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 specification
18

 The process of establishing what services are required and the

constraints on the system’s operation and development.
 Requirements engineering process
 Feasibility study
 Is it technically and financially feasible to build the system?

 Requirements elicitation and analysis

 What do the system stakeholders require or expect from the system?

 Requirements specification
 Defining the requirements in detail

 Requirements validation
 Checking the validity of the requirements
 The requirements engineering process
19

 Check if the identified user needs

will be satisfied using current software
and hardware technologies.
 The proposed system will be cost-effective
from a business point of view and
if it can be developed within existing budget constraints.
 It should be relatively cheap and quick.
 The result should inform the decision of whether or not to go ahead with a more
detailed analysis.
 The requirements engineering process
20

This is the process of deriving the

system requirements through observation
of existing systems, discussions with
potential users, task analysis.
 This may involve the development of one or more system models and prototypes.
 These help you to understand the system to be specified.
 The requirements engineering process
21

 It translate the information gathered

during the analysis activity into a document
that defines a set of requirements.
 Two types of requirements included in this document: -
 User requirements are abstract statements of the system requirements for the
customer and end-user of the system;
 System requirements are a more detailed description of the functionality to be
provided.
 The requirements engineering process
22

 During this process, errors in the requirements document are discovered.

 It must then be modified to correct these problems.
 Software design and implementation
23

 The process of converting the system specification into an executable system.

 Software design
 It is a description of the structure of the software to be implemented,
 The data models and structures used by the system,
 The interfaces between system components and, sometimes, the algorithms
used.
 Implementation
 Translate this structure into an executable program;
 The activities of design and implementation are closely related and may be
interleaved.
 A general model of the design process
24
 Software validation
25

 Verification and validation (V & V) involves checking and review

processes and system testing.

 System testing involves executing the system with test cases that are

derived from the specification of the real data to be processed by

the system.
 Stages of testing
26

 Development or component testing

 Individual components are tested independently;
 Components may be functions or objects or coherent groupings of
these entities.
 System testing
 Testing of the system as a whole. Testing of emergent properties is
particularly important.
 Acceptance testing
 Testing with customer data to check that the system meets the
customer’s needs.
 Software evolution process
27

 Software is flexible and can change.

 As requirements change through changing business circumstances, the
software that supports the business must also evolve and change.
 Conclusion
28

 Software processes are the activities involved in producing a software

system. Software process models are abstract representations of these
processes.
 General process models describe the organization of software processes.
 Examples of these general models include the ‘waterfall’ model,
incremental development, and reuse-oriented development.
 Requirements engineering is the process of developing a software
specification.
 Conclusion
29

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

 Thanks for your attention