Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Lecture 4

Download as pdf or txt
Download as pdf or txt
You are on page 1of 16

Software

Engineering
Lecture 4

Dr. Sarah Ayyad


Faculty of engineering, Mansoura university
● Real software processes are interleaved sequences of
technical, collaborative, and managerial activities with the
overall goal of specifying, designing, implementing, and
Process testing a software system.

Activities ● The four basic process activities of specification,


development, validation, and evolution are organized
differently in different development processes.
● In the waterfall model, they are organized in sequence,
whereas in incremental development they are interleaved.
1. Software specification

▪ Software specification or requirements engineering is the process of understanding and


defining what services are required from the system and identifying the constraints on the
system’s operation and development.

▪ Requirements engineering is a particularly critical stage of the software process as errors at


this stage inevitably lead to later problems in the system design and implementation.

▪ The requirements engineering process aims to produce an agreed requirements document


that specifies a system satisfying stakeholder requirements.

▪ Requirements are usually 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.
1. Software specification
▪ There are four main activities in the requirements engineering process:

Feasibility Requirements Requirements Requirements


study elicitation and specification validation
analysis
1. Software specification
▪ Feasibility study
Is it technically and financially feasible to build the system?
▪ Requirements elicitation and analysis
This is the process of deriving the system requirements through observation of existing systems,
discussions with potential users and procurers, task analysis, and so on.
▪ Requirements specification
The activity of translating the information gathered during the analysis activity into a document that
defines a set of requirements. Two types of requirements may be included in this document. User
requirements are abstract statements of the system requirements for the customer and end-user;
system requirements are a more detailed description of the functionality to be provided.
▪ Requirements validation
Checking the requirements for realism, consistency, and completeness. During this process, errors
in the requirements document are inevitably discovered. It must then be modified to correct these
problems.
1. Software specification
2. Software design and implementation

▪ The implementation stage of software development is the process of converting a system


specification into an executable system. It always involves processes of software design and
programming.

▪ Sometimes this involves separate activities of software design and programming. However,
if an agile approach to development is used, design and implementation are interleaved.

▪ A software design 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.
General model of the design process
General model of the design process

1. Architectural design, where you identify the overall structure of the system, the principal
components (sometimes called sub-systems or modules), and their relationships.

2. Interface design, where you define the interfaces between system components.

3. Component design, where you take each system component and design how it will operate.
This may be a simple statement of the expected functionality to be implemented, with the
specific design left to the programmer.

4. Database design, where you design the system data structures and how these are to be
represented in a database. Again, the work here depends on whether an existing database is to
be reused or a new database is to be created.
3. Software Validation

▪ Software validation or, verification and validation (V&V) is intended 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

1. Development testing: The components making up the system are tested by the people
developing the system. Each component is tested independently, without other system
components. Components may be simple entities such as functions or object classes, or
may be coherent groupings of these entities.
2. System testing: System components are integrated to create a complete system. This
process is concerned with finding errors that result from unanticipated interactions
between components.
3. Acceptance testing: This is the final stage in the testing process. The system is tested with
data supplied by the system customer. Acceptance testing may also reveal requirements
problems where the system’s facilities do not really meet the user’s needs.
Testing phases in a plan-driven software process

This is sometimes called the V-model of development


4. Software Evolution

▪ The flexibility of software systems is one of the main reasons why more and more software
is being incorporated in large, complex systems.

▪ The costs of maintenance are often several times the initial development costs,
maintenance processes are sometimes considered to be less challenging than original
software development.
Coping with
Changes
Coping with Changes
▪ Change is inevitable in all large software projects. Therefore, whatever software process model
is used, it is essential that it can accommodate changes to the software being developed.

▪ Change adds to the costs of software development because it usually means that work that has
been completed has to be redone. This is called rework.

▪ There are two 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.
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.
Thanks!
Do you have any questions?

Sarah_Ayyad@mans.edu.eg

CREDITS: This presentation template was created by Slidesgo, including


icons by Flaticon, infographics & images by Freepik and illustrations by
Stories

You might also like