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
