Software Engineering

Third Stage-2023

Prepared by Dr. Ali Aliedani

 Definitions
• Engineering is the use of scientific principles to design and build machines, structures, and other items,
including bridges, tunnels, roads, vehicles, and buildings.

• Software is the collection of computer programs, procedure rules and associated documentation and data.

Software includes:
(i) Instructions (computer programs).
(ii) Data structures.
(iii) Documents.
Types of software
Computer software is often divided into two categories:
1. System software. This software includes the operating
system and all utilities that enable the computer to function.
2. Application software. These consist of programs that do real
work for users
CLASSES OF SOFTWARE
Software is classified into the following two classes:
1. Generic Software. Generic software is designed for a broad customer market whose requirements are very common,
fairly stable, and well-understood by the software engineer.
2. Customized Software. Customized products are those that are developed for a customer where domain,
environment, and requirements are unique to that customer and cannot be satisfied by generic products.

Software Engineering is the application of methods and scientific

knowledge to create practical cost-effective solutions for the design,
construction, operation and maintenance of software.
SOFTWARE CHARACTERISTICS
1. Most software is custom-built, rather than assembled from existing components.
2.Software is developed or engineered; it is not manufactured in the classical sense.
3. Software is flexible. We all feel that software is flexible. A program can be developed to do almost anything.
4. Software doesn’t wear out. There is a well-known “bath-tub curve” in reliability studies for hardware products
 SOFTWARE CRISIS
It is often the case that software products:
● Fail to meet user requirements.
● Expensive.
● Difficult to alter, debug, and enhance.
● Often delivered late.
● Use resources non-optimally.

Factors are Contributing to the Software Crisis

● Larger problems,
● Poor project management
● Lack of adequate training in software engineering,
● Increasing skill shortage,
● Low productivity improvements
Software Crisis from the Programmer’s Point-of-View Software Crisis form the User’s Point-of-View
❖ Problem of compatibility. ● Software cost is very high.
❖ Problem of portability. ● Hardware goes down.
❖ Problem in documentation. ● Lack of specialization in development.
❖ Problem of piracy of software. ● Problem of different versions of software.
❖ Problem in coordination of work of different ● Problem of views.
people. ● Problem of bugs
❖ Problem of proper maintenance

Examples
1- Y2K problem:
It was simply the ignorance about the adequacy or otherwise of using only last two digits of the year.
The 4-digit date format, like 1964, was shortened to 2-digit format, like 64.

2- Ariane 5
It took the European Space Agency 10 years and $7 billion to produce Ariane 5, a giant rocket capable of hurling a pair
of three-ton satellites into orbit with each launch and intended to give Europe overwhelming supremacy in the
commercial space business.
The rocket was destroyed after 39 seconds of its launch, at an altitude of two and a half miles along with its payload of
four expensive and uninsured scientific satellites.
 Why study software engineering
1- To acquire skills to develop large programs
- Handling exponential growth in complexity with size
- Systematic techniques based on abstraction (modelling) and decomposition.
2- Learn systematic techniques of:
- specification, design, user interface development, testing, project management, maintenance, etc.
- appreciate issues that arise in team development
3- To acquire skills to be a better programmer
- Higher productivity
- Better quality programs
 Some Terminologies
● Deliverables and Milestones
Different deliverables are generated during software development. The examples are source code, user manuals,
operating procedure manuals etc.
The milestones are the events that are used to ascertain the status of the project. Finalization of specification is a
milestone. Completion of design documentation is another milestone. The milestones are essential for project
planning and management.
● Product and Process
Product: What is delivered to the customer, is called a product. It may include source code, specification document,
manuals, documentation etc. Basically, it is nothing but a set of deliverables only.
Process: Process is the way in which we produce software. It is the collection of activities that leads to (a part of) a
product. An efficient process is required to produce good quality products.
● Productivity
Productivity is defined as the rate of output, or production per unit of effort, i.e. the output achieved with regard to
the time taken but irrespective of the cost incurred.
Hence most appropriate unit of effort is Person Months (PMs), meaning thereby number of persons involved for
specified months. So, productivity may be measured as LOC/PM (lines of code produced/person month).
NEXT…..

SOFTWARE-DEVELOPMENT LIFE-CYCLE MODELS

The software-development life-cycle is used to facilitate the development of a large software product in a
systematic, well-defined, and cost-effective way
 SOFTWARE-DEVELOPMENT LIFE-CYCLE MODELS

The software-development life-cycle is used to facilitate the development of a large software product in a
systematic, well-defined, and cost-effective way.

1- Build & Fix Model

● Product is constructed without specifications or any attempt at design

❖ Ad hoc approach and not well defined Simple two-phase model.

❖ Suitable for small programming exercises of 100 or 200 lines
❖ Code soon becomes unfixable & enhanceable
❖ No room for structured design
❖ Maintenance is practically not possible
2- WATERFALL MODEL

1. Feasibility Study. The purpose of this phase is to

produce a feasibility study document that evaluates
the costs and benefits of the proposed application.
● A definition of the problem.
● Determination of technical and economic viability.
● Alternative solutions and their expected benefits.
● Required resources, costs, and delivery dates in each
proposed alternative solution.

2. Requirement Analysis and Specification. This phase exactly tells the requirements and needs of
the project.
o The requirements describe the “what” of a system, not the “how.”
o The resultant document is known as the software requirement specification (SRS)
document.
An SRS document must contain the following:
● Detailed statement of problem.
● Functional requirements of the software system.
● Constraints on the software system.
3. Design and Specification. The goal of the design phase is to transform the requirements specified in the SRS document
into a structure that is suitable for implementation in some programming language.
4. Coding and Module Testing. Coding and module testing is the phase in which we actually write programs using a
programming language.
5. Integration and System Testing. During the integration and system testing phase, the modules are integrated in a planned
manner. During each integration step, the partially integrated system is tested and a set of previously planned modules are
added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out.
6. Delivery and Maintenance.
• We define maintenance as the set of activities that are performed after the system is delivered to the customer.

Iterative Waterfall Model

• The main change brought about by the iterative waterfall
model to the classical waterfall model is in the form of
providing feedback paths from every phase to its preceding
phases.
• There is no feedback path to the feasibility stage. This is
because once a team having accepted to take up a project,
does not give up the project easily due to legal and moral
reasons.
 Advantages of Waterfall Model
The various advantages of the waterfall model include:
❖ It is systematic and sequential.
❖ It has proper documentation.

Problems of waterfall model

❑ It is difficult to define all requirements at the beginning of a project

❑ This model is not suitable for accommodating any change
❑ A working version of the system is not seen until late in the project’s life
❑ Incremental delivery not supported
❑ Phase overlap not supported: For most real life projects, it becomes difficult to follow the rigid phase sequence prescribed
by the waterfall model.
❑ Error correction unduly expensive: In waterfall model, validation is delayed till the complete development of the software.
❑ Limited customer interactions: This model supports very limited customer interactions.
❑ No support for risk handling and code reuse: It becomes difficult to use the waterfall model in projects that are susceptible
to various types of risks, or those involving significant reuse of existing development artifacts.
 3 V-Model
• V-model is a variant of the waterfall model.
• In this model verification and validation activities are carried out throughout the development life cycle, and
therefore the chances bugs in the work products considerably reduce.
• There are two main phases—development and validation phases.
When to use V Model
•Natural choice for systems requiring high reliability:
–Embedded control applications, safety-critical software
•All requirements are known up-front
•Solution and technology are known

Disadvantages of V-model

•Does not support overlapping of phases

•Does not handle iterations or phases
•Does not easily accommodate later changes to requirements
•Does not provide support for effective risk handling

Validation is the process of checking whether the specification captures the customer's needs,
while verification is the process of checking that the software meets the specification
 4. PROTOTYPING MODEL
• This model suggests building a working prototype of the system, before
development of the actual software. A prototype is a toy and crude
implementation of a system.
• It is advantageous to use the prototyping model for development
of the graphical user interface (GUI) part of an application.

Strengths of the prototyping model

This model is the most appropriate for projects that suffer from
technical and requirements risks.

Weaknesses of the prototyping model

• The prototype model can increase the cost of development for
projects that are routine development work and do not suffer
from any significant risks.
• Even when a project is susceptible to risks, the prototyping
model is effective only for those projects for which the risks can
be identified upfront before the development starts.
5 Incremental Development Model
• This life cycle model is sometimes referred to as the successive versions
model and sometimes as the incremental model.
❑ Waterfall: single release
❑ Iterative: many releases (increments)
–First increment: core functionality
–Successive increments: add/fix functionality
–Final increment: the complete product
❑ Each iteration: a short mini-project with a separate lifecycle
–e.g., waterfall

Advantages
Error reduction: The core modules are used by the customer from the beginning and therefore these get tested
thoroughly. This reduces chances of errors in the core modules of the final product, leading to greater reliability of
the software.
Incremental resource deployment: This model obviates the need for the customer to commit large resources at one
go for development of the system. It also saves the developing organisation from deploying large resources and
manpower for a project in one go.
 6 Evolutionary Model
>In the incremental development model, complete
requirements are first developed and the SRS document
prepared.
>In contrast, in the evolutionary model, the requirements, plan
, estimates, and solution evolve over the iterations, rather than
fully defined and frozen in a major up-front specification
effort before the development iterations begin.

Advantages
• Effective elicitation of actual customer requirements
• Easy handling changes requests

Disadvantages
• Feature division into incremental parts can be non-trivial: For many development projects, especially for small-
sized projects, it is difficult to divide the required features into several parts that can be incrementally implemented and
delivered.
• Ad hoc design: Since at a time design for only the current increment is done, the design can become ad hoc without
specific attention being paid to maintainability and optimality
 7 RAPID APPLICATION DEVELOPMENT (RAD)
• This model has the features of both prototyping and evolutionary models.
• In this model prototypes are constructed, and incrementally the features are developed and delivered to the customer. But
unlike the prototyping model, the prototypes are not thrown away but are enhanced and used in the software construction

The major goals of the RAD model are as follows:

 To decrease the time taken and the cost incurred to develop software systems.
 To limit the costs of accommodating change requests.
 To reduce the communication gap between the customer and the developers.

Applicability of RAD Model

• Customized software: is developed for one or two customers only by adapting an existing software.
• Non-critical software: the developed product is usually far from being optimal in performance and reliability. In this
regard, for well understood development projects and where the scope of reuse is rather restricted, the iterative waterfall
model may provide a better solution.
• Large software: Only for software supporting many features (large software) can incremental development and delivery
be meaningfully carried out.
Application characteristics that render RAD unsuitable
• Generic products (wide distribution): software products are generic in nature and usually have wide distribution. For
such systems, optimal performance and reliability are imperative in a competitive market.
• Lack of similar products: If a company has not developed similar software, then it would hardly be able to reuse much
of the existing artifacts.
• Monolithic entity: For certain software, especially small-sized software, it may be hard to divide the required features
into parts that can be incrementally developed and delivered.
• Generic products (wide distribution): software products are generic in nature and usually have wide distribution. For
such systems, optimal performance and reliability are imperative in a competitive market.
====================================================
RAD versus iterative waterfall model
• In the iterative waterfall model, all the functionalities of a software are developed together. On the other hand, in
the RAD model the product functionalities are developed incrementally through heavy code and design reuse.
RAD versus evolutionary model
• In RAD each increment results in essentially a quick and dirty prototype, whereas in the evolutionary model each
increment is systematically developed using the iterative waterfall model. Also in the RAD model, software is
developed in much shorter increments compared the evolutionary model.
 6 Evolutionary Model
>In the incremental development model, complete
requirements are first developed and the SRS document
prepared.
>In contrast, in the evolutionary model, the requirements, plan
, estimates, and solution evolve over the iterations, rather than
fully defined and frozen in a major up-front specification
effort before the development iterations begin.

Advantages
• Effective elicitation of actual customer requirements
• Easy handling changes requests

Disadvantages
• Feature division into incremental parts can be non-trivial: For many development projects, especially for small-
sized projects, it is difficult to divide the required features into several parts that can be incrementally implemented and
delivered.
• Ad hoc design: Since at a time design for only the current increment is done, the design can become ad hoc without
specific attention being paid to maintainability and optimality
 7 RAPID APPLICATION DEVELOPMENT (RAD)
• This model has the features of both prototyping and evolutionary models.
• In this model prototypes are constructed, and incrementally the features are developed and delivered to the customer. But
unlike the prototyping model, the prototypes are not thrown away but are enhanced and used in the software construction

The major goals of the RAD model are as follows:

 To decrease the time taken and the cost incurred to develop software systems.
 To limit the costs of accommodating change requests.
 To reduce the communication gap between the customer and the developers.

Applicability of RAD Model

• Customized software: is developed for one or two customers only by adapting an existing software.
• Non-critical software: the developed product is usually far from being optimal in performance and reliability. In this
regard, for well understood development projects and where the scope of reuse is rather restricted, the iterative waterfall
model may provide a better solution.
• Large software: Only for software supporting many features (large software) can incremental development and delivery
be meaningfully carried out.
Application characteristics that render RAD unsuitable
• Generic products (wide distribution): software products are generic in nature and usually have wide distribution. For
such systems, optimal performance and reliability are imperative in a competitive market.
• Lack of similar products: If a company has not developed similar software, then it would hardly be able to reuse much
of the existing artifacts.
• Monolithic entity: For certain software, especially small-sized software, it may be hard to divide the required features
into parts that can be incrementally developed and delivered.

====================================================
RAD versus iterative waterfall model
• In the iterative waterfall model, all the functionalities of a software are developed together. On the other hand, in
the RAD model the product functionalities are developed incrementally through heavy code and design reuse.
RAD versus evolutionary model
• In RAD each increment results in essentially a quick and dirty prototype, whereas in the evolutionary model each
increment is systematically developed using the iterative waterfall model. Also in the RAD model, software is
developed in much shorter increments compared the evolutionary model.
8 SPIRAL MODEL
❑ The spiral model focuses on identifying and eliminating high-risk problems by careful process design, rather than
treating both trivial and severe problems uniformly.
❑ It is used when experimenting on technology, trying out new skills, and when the user is not able to offer requirements
in clear terms.
❑ It is also useful when the requirements are not clear and when the solution intended has multi-users, multi-functions,
multi-features, multi-location applications to be used on multiple platforms, where seamless integration, interfacing,
data migration, and replication are the issues.

Objective Setting (First Quadrant)

• Identify objectives of the phase,
• Find alternate solutions possible.

Risk Assessment and Reduction (Second Quadrant)

• For each identified project risk,
• a detailed analysis is carried out.
• Steps are taken to reduce the risk.
For example, if there is a risk that requirements are
inappropriate: A prototype system may be developed.

Development and Validation (Third quadrant)

develop and validate the next level of the product.
Review and Planning (Fourth quadrant):
• review the results achieved so far with the customer and plan the next iteration around the spiral.

9 Agile Model
The Manifesto for Agile Software Development is based on twelve principles:
1. Customer satisfaction by early and continuous delivery of valuable software.
2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
 9.1 Scrum
• Scrum is based on the idea of adding value to a software product in an iterative manner.
• These iterations are called sprints, and they culminate in software that is potentially releasable.
• All work is prioritized on the product backlog and, at the start of each sprint, the development team commits to the work
that they will complete during the new iteration by placing it on the sprint backlog.
• The unit of work within Scrum is the story (A user story is an informal, general explanation of a software feature written
from the perspective of the end user
 Scrum Framework
1.Roles : Product Owner, ScrumMaster, Team
•Product Owner
–Acts on behalf of customer to represent their interests.
❖ Defines the features of the product
❖ Decide on release date and content
❖ Prioritize features according to market value
❖ Adjust features and priority every iteration, as needed
❖ Accept or reject work results.
• Scrum Master (aka Project Manager)
❖ Represents management to the project
❖ Removes impediments
❖ Ensure that the team is fully functional and productive
❖ Enable close cooperation across all roles and functions
❖ Shield the team from external interferences
•Development Team
Typically 5-10 people .
 2- Scrum Events
• The Sprint: The heart of Scrum is Sprint, a time-box of one month or less during which a "Done", usable and potentially
releasable product increment is developed.
❑Sprints consist of the Sprint Planning Meeting, Daily Scrum, the development work, the Sprint Review
and the Sprint Retrospective.
• Canceling The Sprint:
❑ A Sprint can be canceled before the Sprint time-box is over. Only the product owner has the authority to cancel the
Sprint.
• Sprint Planning Meeting:
❑ The work to be done in Sprint is planned during the Sprint Planning Meeting
❑ Sprint Planning meeting consist of two parts.
✓ Part 1: What will be done this Sprint?
✓ Part 2 : How will the chosen work get done?

• Daily Scrum:
❑The daily scrum is a 15-minute time-boxed event for the team to synchronize activities for the next 24 hours
❑During the meeting, each Development Team member explains:

✓What has been accomplished since the last meeting?

✓What will be done before the next meeting?
✓What obstacles are in the way?
• Sprint Review:
❑ A sprint review is held at the end of the Sprint to inspect increment and adapt the product Backlog if needed
• Sprint Retrospective:

❑ The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements
to be enacted during the next Sprint.