Software Engineering

BTECH – CSE (3rd Semester )

Unit-1

Presented By
DEEPTI GOUR
 2

UNIT 1
Topic Covered SDLC MODELS
o System Fundamental o Waterfall Model
o Elements & Features o Itertative Waterfall Model
o System Types o Prototype Model
o Pysical & Conceptual System o RAD Model
oOpen & Close System o Evolutionary Model
o“Man Made” System – IS/ Computer oIncremental, Spiral , WinWin and
Based system Concurrent Model
oSDLC Overview oAgile Model
oGenric SDLC oConculsion
oPhases of SDLC
oFlow of SDLC
 3

System
The Term System
may be defined as an orderly arrangement of a set of
interrelated and interdependent element that operate collectively
to accomplish some common purpose or goal. For example –
human body is a system, consisting of various parts such as
head, heart, hands, legs and so on. The various body parts are
related by mean of connecting networks of blood vessels and
nerves and the system has a main goal of “living”.
 4

System Elements
A system is group of interrelated Elements are :
components working together toward a o Input & Output
common goal by accepting inputs and o Processor
producing outputs in an organized o Control & Feedback
transformation process. – Components
o Enviorment
and their attribution
o Boundary & Interface
• Systems structure: relationship
between components
• Subsystems – Environment and
Boundary
– Input and Output

SAD by Elias.M.Awad
 5

Characteristics of System

Common Goal
Organized
Interdependence
Intergation & Interface
Equifinality
Entropy
 6

Types of System

1. Physical or abstract,
2. Open or closed, and
3. “Man – Made” information systems
 7
Genric SDLC

SDLC is the acronym of Software Development Life Cycle. It is also called

as Software development process. The software development life cycle
(SDLC) is a framework defining tasks performed at each step in the
software development process.

The SDLC is a framework that describes the activities performed at each

stage of a software development project.
• SDLC process is used by the software industry to design, develop and
test high quality software. It aims to produce the quality software that
meets or exceeds customer expectations, reaches completion within time
and budget.
 8

Planning ,
Requirement &
Analysis

Feasibility Study &

Deployment Design
(Implementation &
Maintenance)

Coding or
Development

Testing
 9
1. Planning, Requirement & Analysis : is the most important and fundamental stage in
SDLC.
• It is performed by the senior members of the team with inputs from the customer, the
sales department, market surveys and domain experts in the industry.
• Planning for the quality assurance requirements and identification of the risks associated
with the project is also done in the planning stage.

2. Feasibility Study & Design : Requirements step is to clearly define and document the
product requirements and get them approved from the customer or the market analysts.
This information is then used to plan the basic project approach and to conduct product
feasibility study in the economical, operational and technical areas.
• This is done through an SRS (Software Requirement Specification) document which
consists of all the product requirements to be designed and developed during the project
life cycle.
• Usually more than one design approach for the product architecture is proposed and
documented in a DDS (Design Document Specification.)
• This DDS is reviewed by all the stakeholders and based on various parameters as risk
assessment, design modularity , budget and time constraints , the best design approach is
selected for the software.
 10
3. Code or Development: In this stage of SDLC the actual development starts and the
product is built. The programming code is generated as per DDS during this stage. •
Developers have to follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers etc are used to generate
and implement the code.

4. Testing : This stage is usually a subset of all the stages as in the modern SDLC
models, the testing activities are mostly involved in all the stages of SDLC. • However
this stage refers to the testing only that stage of the software where defects are
reported, tracked, fixed and retested, until the software reaches the quality standards
defined in the SRS.

5. Implementation & Maintenance : Once the software is tested and no bugs or errors
are reported then it is deployed.
• Then based on the feedback, the software may be released as it is or with
suggested enhancements in the target segment.
• After the software is deployed then its maintenance starts.
 11

Reasons for choosing SDLC Models

• Provides the base for project planning, estimating & scheduling.
• Provides framework for standard set of terminologies, activities &
deliverables.
• Provides mechanism for project tracking & control.
• Increases visibility of project progress to all stakeholders.
 Waterfall Model 12
Requirement
Gathering & Analysis Dr. Winston W. Royce at the Lockheed Software Technology Center - 1970

System Design

Coding

Implementation

Testing

Deployment

Maintenance
 13

The Waterfall Model also referred to as a linear-sequential life

cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed fully before the next phase
can begin. It is basically used for the project which is small and
there are no uncertain requirements.

Requirements. Potential requirements, deadlines and guidelines

for the project are analyzed and placed into a formal requirements
document, also called a functional specification. This stage of
development defines and plans the project without mentioning
specific processes.
✖ Analysis. The system specifications are analyzed to generate 14
product models and business logic to guide production. This is
also when financial and technical resources are audited for
feasibility.

✖ Design. A design specification document is created to outline

technical design requirements, such as the programming
language, data sources, architecture and services.

✖ Coding and implementation. To develop & create source code

using the different models, logic and requirement
specifications designated in the prior phases. Typically, the
system is coded in smaller components, or units, before being
put together.
 15
Testing. This is when Module (component, Unit, Module &
Integration), system, & quality assurance quality test identify issues
(code problems) that must be resolved. This may cause a forced
repeat of the coding stage for debugging phase. If the system
passes integration and testing, the waterfall continues forward.

Implementation : The product or application is detailed functional

and is deployed to a live environment.

Maintenance. Corrective, adaptive and perfective maintenance is

carried out indefinitely to improve, update and enhance the product
and its functionality. This could include releasing updates and new
versions.
 16
Prototype Model
Requirement Gathering

Quick Decision

Refine
Build Prototype
Requirement

Customer
Evaluation of
Prototype

Design

Implementation

Testing

Maintenance
 17
Steps of Prototype Model
1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. User Evaluation
5. Prototype Refinement
6. Engineer Product (Design , Implementation , Testing & Maintenance )
Advantage of Prototype Model
o Reduce the risk of incorrect user requirement
o Good where requirement are changing/uncommitted
o Regular visible process aids management
o Support early product marketing
o Reduce Maintenance cost.
o Errors can be detected much earlier as the system is made side by side.
 18
Disadvantage of Prototype Model
o An unstable/Not Refine model also implemented prototype often becomes
the final product.
o Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
o Difficult to know how long the project will last.
o Easy to fall back into the code and fix without proper requirement analysis,
design, customer evaluation, and feedback.
o Prototyping tools are expensive.
o Special tools & techniques are required to build a prototype.
o It is a time-consuming process.
Evolutionary Process Model 19

Evolutionary process model

resembles the iterative
enhancement model. The
same phases are defined for
the waterfall model occurs
here in a cyclical fashion. This Module – 3
model differs from the Mod.-1 Mod. -2
• Design to
iterative enhancement model Implementation
• Design to
in the sense that this does not • Design to Implementation
Implementation
require a useful product at the
end of each cycle. In
evolutionary development,
requirements are
implemented by category
rather than by priority.
 Incremental Model 20

Build M1
Design & Coding Implementation
(Development) Testing
& Maintenance

Build M2
Design & Coding Implementation
Testing
Requirement (Development) & Maintenance
Analysis

Build M3 Implementation
Design & Coding
Testing & Maintenance
(Development)

Build N…. Design & Coding

Testing
Implementation
(Development) & Maintenance
 21
1. Requirement analysis: In the first phase of the incremental model, the software analysis
expertise identifies the requirements. And the system functional requirements are
understood by the requirement analysis team. To develop the software under the
incremental model, this phase performs a crucial role.

2. Design & Development: In this phase, the design of the system functionality and the
development method are finished with success. When software develops new practicality, the
incremental model uses style and development phase.

3. Testing: In this Model - testing phase checks & analysis the performance of each existing
function as well as additional functionality. (various methods are used to test the behavior – Test
Case, Test Scheduler, Test Schema & Activity Diagram))

4. Implementation: Implementation phase enables the coding phase of the development

system. It involves the final coding that design in the designing and development phase and
tests the functionality in the testing phase. (Here number of the product module working is
enhanced and upgraded up to the final system product)

When Incremental SDLC – Requirement Superior , Large Project, Long time , Customize
Requirement for Quick Release )
✖ Advantage of Incremental
Model 22
✖ Disadvantage of
Incremental Model
✖ Errors are easy to be
recognized.
✖ Need for good planning
✖ Easier to test and debug
✖ Total Cost is high.
✖ More flexible.
✖ Well defined module
✖ Simple to manage risk
interfaces are needed.
because it handled during
its iteration.
✖ The Client gets important
functionality early.
 23
General Model of Design Process
1. Architectural design: where you identify the overall structure of the system, the 24

principal components (sometimes called sub-systems or modules), their

relationships, and how they are distributed.

2. Interface design: define the interfaces between system components. This interface
specification must be unambiguous. With a precise interface, a component can be used
without other components having to know how it is implemented. Once interface
specifications are agreed, the components can be designed and developed concurrently.

3. Component design: 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. Alternatively, it may be a list of changes to be
made to a reusable component or a detailed design model. The design model may be
used to automatically generate an implementation.

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.
 25
Generic Stages of Testing in SDLC

Module/Component/
Unit Testing Acceptance Testing
System Testing
+
(Few Integration T )

1. Development / Module / Unit / Component testing : Module making up the system are
tested by the people developing the system. Each component/Module/Unit 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. Test automation tools, such as JUnit (Massol
and Husted, 2003), that can re-run component tests when new versions of the component are created,
are commonly used.
Functional or Non-Functional Requirements – Testing Resources Like Performance Testing , Structural
Testing etc - here Components – Project Test Plan , Specification & Unit Implementation )
 26
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 and component interface problems. It is also
concerned with showing that the system meets its functional and non-functional
requirements, and testing the emergent system properties. For large systems, this
may be a multi-stage process where components are integrated to form subsystems
that are individually tested before these sub-systems are themselves integrated to
form the final system. (also called Beta Testing )

3. Acceptance testing: This is the final stage in the testing process before the
system is accepted for operational use. The system is tested with data supplied by
the system customer rather than with simulated test data. Acceptance testing may
reveal errors and omissions in the system requirements definition, because the real
data exercise the system in different ways from the test data. Acceptance testing
may also reveal requirements problems where the system’s facilities do not really
meet the user’s needs or the system performance is unacceptable. (Also called
Alpha Testing)
Various Testing Phases in Plan –Driven 27
 28
Spiral Model (Boehm’s Spiral Model )

A risk-driven software process framework (the spiral model) was proposed by Boehm (1988). Each loop in the
spiral represents a phase of the software process. The spiral model combines change avoidance with change
tolerance.
 29
Requirements Elicitation & Analysis Phases

1. Requirements discovery ( process of

interacting with all Users – Stockholders of the
system to discover their requirements

2. Requirements classification and organization

(this activity takes the unstructured collection of
requirements, groups related requirements, and
organizes them into coherent clusters – identify
the subsystem & all integration)

3. Requirements prioritization and negotiation

Inevitably, when multiple users / stakeholders are
involved, requirements will conflict.

4. Requirements specification The requirements are

documented and input into the next round of the spiral.
Formal or informal requirements documents may be
produced.
 30
Functional Requirements :
(User Requirements & System Requirements )
In the functional requirements
specification of a system should be
both complete and consistent.
Completeness means that all services
required by the user should be
defined.

Consistency means that requirements

should not have contradictory
definitions.

In practice, for large, complex

systems, it is practically impossible to
achieve requirements consistency and
completeness.
 31
Non Functional Requirements
As the name suggests, are requirements that are not directly concerned with the specific services
delivered by the system to its users. They may relate to emergent system properties such as reliability,
response time, and store occupancy.

Alternatively, they may define constraints on the system implementation such as the capabilities of I/O
devices or the data representations used in interfaces with other systems.

Non-functional requirements, such as performance, security, or availability, usually specify or constrain

characteristics of the system as a whole. Non-functional requirements are often more critical than
individual functional requirements.
32
33
 34
SRS

The software requirements document

(sometimes called the software requirements
specification or SRS) is an official statement of
what the system developers should implement.
It should include both the user requirements for
a system and a detailed specification of the
system requirements.

Different Users – for SRS & their roles

 35

Verification & Validation

Software testing is a process of verification and Validation. Verification is to ensure
that product quality is maintained. The product is free from defects, whereas Validation is
more about market research and acceptance.

For instance, the primary reason Google Lens failed was that Google lens was a software
integrated with many functionalities and was heavy on quality.
Thanks