Module Overview

This module introduces participants to the different phases of Software

Development Lifecycle. In this module, participants will also explore the different
software development models.

Overview of Software Engineering

Let us understand what Software Engineering stands for. The term is made of
two words, software and engineering.

Software is more than just a program code. A program is an executable code,

which serves some computational purpose. Software is considered to be collection of
executable programming code, associated libraries and documentations.
Software, when made for a specific requirement is called software product.

Engineering on the other hand, is all about developing products, using well-
defined, scientific principles and methods.

Software engineering is an engineering branch associated with development of

software product using well-defined scientific principles, methods and procedures.
The outcome of software engineering is an efficient and reliable software product

Software evolution
The process of developing a software product using software engineering
principles and methods is referred to as Software Evolution. This includes the
initial development of software and its maintenance and updates, till desired
software product is developed, which satisfies the expected requirements.

Process Of Software Evolution:

Evolution starts from the requirement gathering process. After which
developers create a prototype of the intended software and show it to the users to
get their feedback at the early stage of the software product development. The
users suggest changes, on which several consecutive updates and maintenance keep on
changing too. This process changes to the original software, till the desired
software is accomplished.

Even after the user has the desired software in hand, the advancing
technology and the changing requirements force the software product to change
accordingly. Re-creating software from scratch and to go one-on-one with the
requirement is not feasible. The only feasible and economical solution is to update
the existing software so that it matches the latest requirements.

Software Evolution Laws

Lehman has given laws for software evolution. He divided the software into
three different categories:

- Static-type (S-type)
- Practical-type (P-type)
- Embedded-type (E-type)

Static-type (S-type) - This is a software, which works strictly according to

defined specifications and solutions. The solution and the method to achieve it,
both are immediately understood before coding. The s-type software is least
subjected to changes hence this is the simplest of all. For example, calculator
program for mathematical computation.

Practical-type (P-type) - This is a software with a collection of procedures.

This is defined by exactly what procedures can do. In this software, the
specifications can be described but the solution is not obviously instant. For
example, gaming software.
 Embedded-type (E-type) - This software works closely as the requirement of
real-world environment. This software has a high degree of evolution as there are
various changes in laws, taxes etc. in the real-world situations. For example,
online trading software

E-TYPE software evolution

 Lehman has given eight laws for E-Type software evolution -
 Continuing change - An E-type software system must continue to adapt to the
real-world changes, else it becomes progressively less useful.
 Increasing complexity - As an E-type software system evolves, its
complexity tends to increase unless work is done to maintain or reduce it.
 Conservation of familiarity - The familiarity with the software or the
knowledge about how it was developed, why was it developed in that particular
manner etc., must be retained at any cost, to implement the changes in the system.
 Continuing growth- In order for an E-type system intended to resolve some
business problem, its size of implementing the changes grows according to the
lifestyle changes of the business.
 Reducing quality - An E-type software system declines in quality unless
rigorously maintained and adapted to a changing operational environment.
 Feedback systems- The E-type software systems constitute multi-loop, multi-
level feedback systems and must be treated as such to be successfully modified or
improved.
 Self-regulation - E-type system evolution processes are self-regulating
with the distribution of product and process measures close to normal.
 Organizational stability - The average effective global activity rate in an
evolving E-type system is invariant over the lifetime of the product.

Software paradigms
Software paradigms refer to the methods and steps, which are taken while
designing the software. There are many methods proposed and are implemented. But,
we need to see where in the software engineering concept, these paradigms stand.
These can be combined into various categories, though each of them is contained in
one another:
Programming paradigm is a subset of Software design paradigm which is further
a subset of Software development paradigm.

Software Development Paradigm:

This paradigm is known as software engineering paradigms; where all the
engineering concepts pertaining to the development of software are applied. It
includes various researches and requirement gathering which helps the software
product to build. It consists of –
 Requirement gathering
 Software design
 Programming

Software Design Paradigm:

This paradigm is a part of Software Development and includes –
 Design
 Maintenance
 Programming

Programming Paradigm
This paradigm is related closely to programming aspect of software
development. This includes –
 Coding
 Testing
 Integration
Need of Software Engineering
The need of software engineering arises because of higher rate of change in
user requirements and environment on which the software is working. Following are
some of the needs stated:
 Large software - It is easier to build a wall than a house or
building,likewise, as the size of the software becomes large, engineering has to
step to give it a scientific process.

 Scalability- If the software process were not based on scientific and

engineering concepts, it would be easier to re-create new software than to
scale an existing one.

 Cost- As hardware industry has shown its skills and huge

manufacturinghas lower down the price of computer and electronic hardware. But,
cost of the software remains high if proper process is not adapted.

 Dynamic Nature- Always growing and adapting nature of the software

hugely depends upon the environment in which the user works. If the nature of
software is always changing, new enhancements need to be done in the existing one.
This is where the software engineering plays a good role.

 Quality Management- Better process of software development provides

better and quality software product.

Characteristics of good software

A software product can be judged by what it offers and how well it can be
used. This software must satisfy on the following grounds:
 Operational
 Transitional
 Maintenance
Well-engineered and crafted software is expected to have the following
characteristics:

Operational:
This tells us how well the software works in operations. It can be
measured on
 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety

Transitional
This aspect is important when the software is moved from one platform
to another:
 Portability
 Interoperability : is the ability of different systems,
devices, applications or products to connect and communicate in a coordinated way,
without effort from the end user.
Ex: two of the same electronic health record systems exchanging patient information
between two different doctors'offices.
 Reusability
 Adaptability

Maintenance
 This aspect briefs about how well the software has the capabilities to
maintain itself in the ever-changing environment:
 Modularity
 Maintainability
 Flexibility
 Scalability
In short, Software engineering is a branch of computer science, which uses
well-defined engineering concepts required to produce efficient, durable, scalable,
in-budget, and on-time software products.

Software Development Life Cycle:

SDLC for short, is a well-defined, structured sequence of stages in software
engineering to develop the intended software product.
SDLC provides a series of steps to be followed to design and develop a
software product efficiently. SDLC framework includes the following steps:

Communication
This is the first step where the user initiates the request for a
desired software product. The user contacts the service provider and tries to
negotiate the terms, submits the request to the service providing organization in
writing.

Requirement Gathering
This step onwards the software development team works to carry on the
project. The team holds discussions with various stakeholders from problem domain
and tries to bring out as much information as possible on their requirements. The
requirements are contemplated and segregated into user requirements,
system requirements and functional requirements. The requirements are
collected using a number of practices as given –
 studying the existing or obsolete system and software,
 conducting interviews of users and developers,
 referring to the database or
 collecting answers from the questionnaires.
Feasibility Study
After requirement gathering, the team comes up with a rough plan of
software process. At this step the team analyzes if a software can be designed to
fulfill all requirements of the user, and if there is any possibility of software
being no more useful. It is also analyzed if the project is financially,
practically, and technologically feasible for the organization to take up. There
are many algorithms available, which help the developers to conclude the
feasibility of a software project.

System Analysis
At this step the developers decide a roadmap of their plan and try to
bring up the best software model suitable for the project. System analysis includes
understanding of software product limitations, learning system related problems or
changes to be done in existing systems beforehand, identifying and addressing the
impact of project on organization and personnel etc. The project team analyzes the
scope of the project and plans the schedule and resources accordingly.

Software Design
Next step is to bring down whole knowledge of requirements and analysis
on the desk and design the software product. The inputs from users and information
gathered in requirement gathering phase are the inputs of this step. The output of
this step comes in the form of two designs; logical design, and physical design.
Engineers produce meta-data and data dictionaries, logical diagrams, data-flow
diagrams, and in some cases pseudo codes.

Coding
 This step is also known as programming phase. The implementation of
software design starts in terms of writing program code in the suitable programming
language and developing error-free executable programs efficiently.

Testing
An estimate says that 50% of whole software development process should
be tested. Errors may ruin the software from critical level to its own removal.
Software testing is done while coding by the developers and thorough testing is
conducted by testing experts at various levels of code such as module testing,
program testing, product testing, in-house testing, and testing the product at
user’s end. Early discovery of errors and their remedy is the key to
reliable software.

Integration
Software may need to be integrated with the libraries, databases, and
other program(s). This stage of SDLC is involved in the integration of software
with outer world entities.

Implementation
This means installing the software on user machines. At times, software
needs post-installation configurations at user end. Software is tested for
portability and adaptability and integration related issues are solved during
implementation.

Operation and Maintenance

This phase confirms the software operation in terms of more efficiency
and less errors. If required, the users are trained on, or aided with the
documentation on how to operate the software and how to keep the software
operational. The software is maintained timely by updating the code according to
the changes taking place in user end environment or technology. This phase may face
challenges from hidden bugs and real-world unidentified problems.

Diiferent types of software development life cycle model

1) Waterfall model
2) Agile Model
3) Iterative Model
4) V-Model
5) Spiral Model
6) Big bang model

Different Phases of software develoment life cycle model:

1) Requirement Analysis
a) Communication
b) Requirement Gathering
c) Feasibility Study
d) System Analysis
2) Design
e) Software Design
3) Development
f) Coding
4) Testing
g) Testing
5) Deployement
h) Integration
i) Implementaion
6) Maintainanace
j) Operation and Maintainanace
Waterfall Model
1) Requirement gathering and analysis: Business requirements are gathered in
this phase. This phase is the main focus of the project managers and stake holders.
Meetings with managers, stake holders and users are held in order to determine the
requirements like; Who is going to use the system? How will they use the system?
What data should be input into the system? What data should be output by the
system? These are general questions that get answered during a requirements
gathering phase.
Analysis is performed to:
- Conduct in depth analysis of the proposed project
- Evaluate for technical feasibility
- Discover how to partition the system
- Identify which areas of the requirements need to be elaborated
from the customer
- Identify the impact of changes to the requirement
- Identify which requirements should be allocated to which
components.

Finally, a Requirement Specification document is created which serves

the purpose of guideline for the next phase of the model. The testing team follows
the Software Testing Life Cycle and starts the Test Planning phase after the
requirements analysis is completed.

2) Design: In this phase the system and software design is prepared from
the requirement specifications which were studied in the first phase. System Design
helps in specifying hardware and system requirements and also helps in defining
overall system architecture.
Activities in this phase - Perform Architectural Design for the software,
Design Database (If applicable), Design User Interfaces, Select or Develop
Algorithms (If Applicable), Perform Detailed Design.
The system design specifications serve as input for the next phase of
the model.

3) Implementation / Coding: On receiving system design documents, the work

is divided in modules/units and actual coding is started.
Activities in this phase - Create Test Data, Create Source, Generate Object
Code, Create Operating Documentation, Plan Integration, Perform Integration
Since, in this phase the code is produced so it is the main focus for the
developer. This is the longest phase of the software development life cycle.

4) Testing: After the code is developed it is tested against the

requirements to make sure that the product is actually solving the needs addressed
and gathered during the requirements phase. During this phase all types of
functional testing like integration testing, system testing, acceptance testing are
done as well as non-functional testing are also done.
Activities in this phase - Plan Verification and Validation, Execute
Verification and validation Tasks, Collect and Analyze Metric Data, Plan Testing,
Develop Test Requirements, Execute Tests

5) Deployment: After successful testing the product is delivered / deployed

to the customer for their use.
As soon as the product is given to the customers they will first do the beta
testing. If any changes are required or if any bugs are caught, then they will
report it to the engineering team. Once those changes are made or the bugs are
fixed then the final deployment will happen.

6) Maintenance: The process does not stop once it is completely implemented

and installed at user place; this phase undertakes development of new features,
enhancements etc. The software is maintained timely by updating the code according
to the changes taking place in user end environment or technology.This phase may
face challenges from hidden bugs and real-world unidentified problems.

Advantages of waterfall model:

• This model is simple and easy to understand and use.
• It is easy to manage due to the rigidity of the model – each phase has
specific deliverables and a review process.
• In this model phases are processed and completed one at a time. Phases
do not overlap.
• Waterfall model works well for smaller projects where requirements are
very well understood.

Disadvantages of waterfall model:

• Once an application is in the testing stage, it is very difficult to go
back and change something that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to
high risk of changing.

10 requirement - client: water fall model

Requirement gathering and Analysis - 10 req
Design - 10 req
Coding - 10 req
Testing - 10 req
Deployement - 10 req
Maintainanace

10 requirement - client: Iterative model

Requirement gathering and Analysis - (1st iteration - first 3 req)(2nd
iteration - next 3 req)(3rd iteration - 4 req)
Design - 10 req - (1st iteration - first 3 req) (2nd iteration - next 3 req)
(3rd iteration - 4 req)
Coding - 10 req - (1st iteration - 3 req)(2nd iteration - next 3 req)(3rd
iteration - 4 req)
Testing - 10 req - (1st iteration - 3 req)(2nd iteration - next 3 req)(3rd
iteration - 4 req)
Verify -
Deployement - 10 req
Maintainanace

ITERATIVE MODEL:

In the Iterative model, iterative process starts with a simple implementation of a

small set of the software requirements and iteratively enhances the evolving
versions until the complete system is implemented and ready to be deployed.

An iterative life cycle model does not attempt to start with a full specification
of requirements. Instead, development begins by specifying and implementing just
part of the software, which is then reviewed to identify further requirements. This
process is then repeated, producing a new version of the software at the end of
each iteration of the model.
 1. Requirement gathering & analysis: In this phase, requirements are gathered
from customers and check by an analyst whether requirements will fulfil or not.
Analyst checks that need will achieve within budget or not. After all of this, the
software team skips to the next phase.

2. Design: In the design phase, team design the software by the different
diagrams like Data Flow diagram, activity diagram, class diagram, state transition
diagram, etc.

3. Coding: In the implementation, requirements are written in the coding

language and transformed into computer programmes which are called Software.

4. Testing: After completing the coding phase, software testing starts using
different test methods. There are many test methods, but the most common are white
box, black box, and grey box test methods.

5. Verify: The verify phase is where the software is estimated and checked as
per the current requirement. Then, further requirements are reviewed discussed and
reviewed to propose for an update in the next iteration.

6. Deployment: After completing all the phases, software is deployed to its

work environment.

7. Maintenance: In the maintenance phase, after deployment of the software in

the working environment there may be some bugs, some errors or new updates are
required. Maintenance involves debugging and new addition options.

The key to a successful use of an iterative software development lifecycle is

rigorous validation of requirements, and verification & testing of each version of
the software against those requirements within each cycle of the model. As the
software evolves through successive cycles, tests must be repeated and extended to
verify each version of the software.

The advantages of the Iterative and Incremental SDLC Model are as follows −

Some working functionality can be developed quickly and early in the life
cycle.

Results are obtained early and periodically.

Parallel development can be planned.

Progress can be measured.

Less costly to change the scope/requirements.

Testing and debugging during smaller iteration is easy.

Risks are identified and resolved during iteration; and each iteration is an
easily managed milestone.

Easier to manage risk - High risk part is done first.

With every increment, operational product is delivered.

Better suited for large and mission-critical projects.

The disadvantages of the Iterative and Incremental SDLC Model are as follows −
 More resources may be required.

More management attention is required.

System architecture or design issues may arise because not all requirements
are gathered in the beginning of the entire life cycle.

Not suitable for smaller projects.

Highly skilled resources are required for risk analysis.

Spiral Model:

The spiral model combines the idea of iterative development with the
systematic, controlled aspects of the waterfall model. This Spiral model is a
combination of iterative development process model and sequential linear
development model i.e. the waterfall model with a very high emphasis on risk
analysis. It allows incremental releases of the product or incremental refinement
through each iteration around the spiral.

Spiral Model - Design

The spiral model has four phases. A software project repeatedly passes
through these phases in iterations called Spirals.

Spiral model is one of the most important Software Development Life Cycle
models, which provides support for Risk Handling. In its diagrammatic
representation, it looks like a spiral with many loops. The exact number of loops
of the spiral is unknown and can vary from project to project. Each loop of the
spiral is called a Phase of the software development process. The exact number of
phases needed to develop the product can be varied by the project manager depending
upon the project risks. As the project manager dynamically determines the number of
phases, so the project manager has an important role to develop a product
using the spiral model.

The Radius of the spiral at any point represents the expenses(cost) of the
project so far, and the angular dimension represents the progress made so far in
the current phase.

Each phase of the Spiral Model is divided into four quadrants as shown in the
above figure. The functions of these four quadrants are discussed below-

Objectives determination and identify alternative solutions: Requirements are

gathered from the customers and the objectives are identified, elaborated, and
analyzed at the start of every phase. Then alternative solutions possible for the
phase are proposed in this quadrant.

Identify and resolve Risks: During the second quadrant, all the possible
solutions are evaluated to select the best possible solution. Then the risks
associated with that solution are identified and the risks are resolved using the
best possible strategy. At the end of this quadrant, the Prototype is built for the
best possible solution.

Develop next version of the Product: During the third quadrant, the
identified features are developed and verified through testing. At the end of the
third quadrant, the next version of the software is available.

Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so far developed version of the software. In the end, planning for the
next phase is started.

Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful completion
of a software project. The most important feature of the spiral model is handling
these unknown risks after the project has started. Such risk resolutions are easier
done by developing a prototype. The spiral model supports coping up with risks by
providing the scope to build a prototype at every phase of the software
development.

The Prototyping Model also supports risk handling, but the risks must be
identified completely before the start of the development work of the project. But
in real life project risk may occur after the development work starts, in that
case, we cannot use the Prototyping Model. In each phase of the Spiral Model, the
features of the product dated and analyzed, and the risks at that point in time are
identified and are resolved through prototyping. Thus, this model is much more
flexible compared to other SDLC models.

Why Spiral Model is called Meta Model?

The Spiral model is called a Meta-Model because it subsumes all the other
SDLC models. For example, a single loop spiral actually represents the Iterative
Waterfall Model. The spiral model incorporates the stepwise approach of the
Classical Waterfall Model. The spiral model uses the approach of the Prototyping
Model by building a prototype at the start of each phase as a risk-handling
technique. Also, the spiral model can be considered as supporting the Evolutionary
model – the iterations along the spiral can be considered as evolutionary levels
through which the complete system is built.

Advantages of Spiral Model:

Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development model to
follow due to the risk analysis and risk handling at every phase.
Good for large projects: It is recommended to use the Spiral Model in large
and complex projects.
Flexibility in Requirements: Change requests in the Requirements at later
phase can be incorporated accurately by using this model.
Customer Satisfaction: Customer can see the development of the product at the
early phase of the software development and thus, they habituated with the system
by using it before completion of the total product.

Disadvantages of Spiral Model:

Complex: The Spiral Model is much more complex than other SDLC models.
Expensive: Spiral Model is not suitable for small projects as it is
expensive.

V-Model - Design
Under the V-Model, the corresponding testing phase of the development phase
is planned in parallel. So, there are Verification phases on one side of the ‘V’
and Validation phases on the other side. The Coding Phase joins the two sides of
the V-Model.

Verification: It involves static analysis technique (review) done without

executing code. It is the process of evaluation of the product development phase to
find whether specified requirements meet.
 Validation: It involves dynamic analysis technique (functional, non-
functional), testing done by executing code. Validation is the process to evaluate
the software after the completion of the development phase to determine whether
software meets the customer expectations and requirements.

V-Model - Verification Phases

There are several Verification phases in the V-Model, each of these are
explained in detail below.

Business Requirement Analysis

This is the first phase in the development cycle where the product
requirements are understood from the customer’s perspective. This phase involves
detailed communication with the customer to understand his expectations and exact
requirement. This is a very important activity and needs to be managed well, as
most of the customers are not sure about what exactly they need. The acceptance
test design planning is done at this stage as business requirements can be used as
an input for acceptance testing.

System Design
Once you have the clear and detailed product requirements, it is time
to design the complete system. The system design will have the understanding and
detailing the complete hardware and communication setup for the product under
development. The system test plan is developed based on the system design. Doing
this at an earlier stage leaves more time for the actual test execution later.

Architectural Design
Architectural specifications are understood and designed in this phase.
Usually more than one technical approach is proposed and based on the technical and
financial feasibility the final decision is taken. The system design is broken down
further into modules taking up different functionality. This is also referred to as
High Level Design (HLD).

The data transfer and communication between the internal modules and
with the outside world (other systems) is clearly understood and defined in this
stage. With this information, integration tests can be designed and documented
during this stage.

Module Design
In this phase, the detailed internal design for all the system modules
is specified, referred to as Low Level Design (LLD). It is important that the
design is compatible with the other modules in the system architecture and the
other external systems. The unit tests are an essential part of any development
process and helps eliminate the maximum faults and errors at a very early stage.
These unit tests can be designed at this stage based on the internal module
designs.

Coding Phase
The actual coding of the system modules designed in the design phase is
taken up in the Coding phase. The best suitable programming language is decided
based on the system and architectural requirements.

The coding is performed based on the coding guidelines and standards.

The code goes through numerous code reviews and is optimized for best performance
before the final build is checked into the repository.

V-Model - Validation Phases

The different Validation Phases in a V-Model are explained in detail
below.
 Unit Testing
Unit tests designed in the module design phase are executed on the code
during this validation phase. Unit testing is the testing at code level and helps
eliminate bugs at an early stage, though all defects cannot be uncovered by unit
testing.

Integration Testing
Integration testing is associated with the architectural design phase.
Integration tests are performed to test the coexistence and communication of the
internal modules within the system.

System Testing
System testing is directly associated with the system design phase.
System tests check the entire system functionality and the communication of the
system under development with external systems. Most of the software and hardware
compatibility issues can be uncovered during this system test execution.

Acceptance Testing
Acceptance testing is associated with the business requirement analysis
phase and involves testing the product in user environment. Acceptance tests
uncover the compatibility issues with the other systems available in the user
environment. It also discovers the non-functional issues such as load and
performance defects in the actual user environment.

The V-model is an SDLC model where execution of processes happens in a

sequential manner in a V-shape. It is also known as Verification and Validation
model.

The V-Model is an extension of the waterfall model and is based on the

association of a testing phase for each corresponding development stage. This means
that for every single phase in the development cycle, there is a directly
associated testing phase. This is a highly-disciplined model and the next phase
starts only after completion of the previous phase.

The advantages of the V-Model method are as follows −

This is a highly-disciplined model and Phases are completed one at a time.

Works well for smaller projects where requirements are very well understood.

Simple and easy to understand and use.

Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.

The disadvantages of the V-Model method are as follows −

High risk and uncertainty.

Not a good model for complex and object-oriented projects.

Poor model for long and ongoing projects.

Not suitable for the projects where requirements are at a moderate to high
risk of changing.

Once an application is in the testing stage, it is difficult to go back and

change a functionality.
 No working software is produced until late during the life cycle.

Big Bang Model :

The Big bang model is an SDLC model that starts from nothing. It is the
simplest model in SDLC (Software Development Life Cycle) as it requires almost no
planning. However, it requires lots of funds and coding and takes more time. The
name big bang model was set after the “Great Big Bang” which led to the development
of galaxies, stars, planets, etc. Similarly, this SDLC model combines time,
efforts, and resources to build a product. The product is gradually built as the
requirements from the customer come, however, the end product might not meet the
actual requirements.

Design :

The product requirements are understood and implemented as they arrive. The
complete modules or at least the part of the modules are integrated and tested. All
the modules are run separately and the defective ones are removed to find the
cause. It is a suitable model where requirements are not well understood and the
final release date is not given.

Pros of Big Bang Model :

There is no planning required for this.

Suitable for small projects
Very few resources are required.
As there is no proper planning hence it does not require managerial staffs
Easy to implement
Very much flexible for the developers working on it

Cons of Big Bang Model :

Not suitable for large projects.

Highly risky model and uncertain
Might be expensive if requirements are not clear
Poor model for ongoing projects