Unit-2

Software process and Process

Models & Choices
Software Development Life Cycle
• SOFTWARE DEVELOPMENT LIFECYCLE (SDLC) is a systematic process for building
software that ensures the quality and correctness of the software built.
• Life Cycle model take care that order of activities performed on a software
product from its inception to retirement.
• Different life cycle models may map the basic development activities to phases in
different ways. Thus, no matter which life cycle model is followed, the basic
activities are included in all life cycle models though the activities may be carried
out in different orders in different life cycle models. During any life cycle phase,
more than one activity may also be carried out.
Need of SDLC
• Development of software product in a systematic and disciplined
manner

• Clear understanding among team members about when and what to

do

• Each phase defines entry and exit criteria for every phase.
Phases of SDLC Require
ment
Analysi
s
Mainte
Design
nance

Deploy
Coding
ment

Testing
Software Development Life Cycle (SDLC):Requirement
Analysis
• During this phase, all the relevant information is collected from the customer to develop a
product as per their expectation. Any ambiguities must be resolved in this phase only.
• Business analyst and Project Manager set up a meeting with the customer to gather all the
information like what the customer wants to build, who will be the end-user, what is the
purpose of the product.
• Before building a product a core understanding or knowledge of the product is very
important.
• Once the requirement gathering is done, an analysis is done to check the feasibility of the
development of a product. In case of any ambiguity, a call is set up for further discussion.
• Once the requirement is clearly understood, the SRS (Software Requirement Specification)
document is created. This document should be thoroughly understood by the developers and
also should be reviewed by the customer for future reference.
Software Development Life Cycle (SDLC): Design
• This stage involves the design of the entire system and its elements.
• There are two kinds of design, high-level design and low-level design.
• According to their definitions, a high-level design (HLD) is the overall plan of the system,
while a low-level design (LLD) is a design of its components. Failure at this phase certainly
result cost overruns and total collapse at worst.
• The system and software design documents (SDD) are prepared as per the requirement
specification document. There are two kinds of design documents developed in this
phase:
Software Development Life Cycle (SDLC):Design
- High-Level Design (HLD)
o Brief description and name of each module
o An outline about the functionality of every module
o Interface relationship and dependencies between modules
o Database tables identified along with their key elements
o Complete architecture diagrams along with technology details
- Low-Level Design(LLD)
o Functional logic of the modules
o Database tables, which include type and size
o Complete detail of the interface
o Addresses all types of dependency issues
o Listing of error messages
• Complete input and outputs for every module
Software Development Life Cycle (SDLC):Coding
• Once the system design phase is over, the next phase is coding.
• In this stage of SDLC the actual development starts, and the product is built.
• In the coding phase, tasks are divided into units or modules and assigned to the various
developers for writing codes as per the chosen programming language.
• It is the longest phase of the Software Development Life Cycle process.
Software Development Life Cycle (SDLC): Testing
• Testing starts once the coding is complete and the modules are released for testing.
• In this phase, the developed software is tested thoroughly, and any defects found are
assigned to developers to get them fixed.
• During this phase, QA and testing team may find some bugs/defects which they
communicate to developers.
• The development team fixes the bug and send back to QA for a re-test.
• This process continues until the software is bug-free, stable, and working according to the
business needs of that system.
Software Development Life Cycle (SDLC): Deployment
• At this stage, the goal is to deploy the software.
• When the software is completed and has no bugs, it is shipped to the market for
beta testing.
• The support team collects feedback of the first users, and if any bugs come up, the
development team fixes them. After that, the final version is rolled out.
Software Development Life Cycle (SDLC):Maintenance
• Once the software system is deployed, and customers start using the developed
system, following 3 activities occur:
- Bug fixing - bugs are reported because of some scenarios which are not tested at
all
- Upgrade - Upgrading the application to the newer versions of the Software
• Enhancement - Adding some new features into the existing software
Importance of SDLC
• It provides visibility for the engaged parties
• It allows to control the project
• Predictable deliveries throughout an entire development process
• Eliminating risks like going over budget or deadline breach
• The process goes on until all the requirements are met
SDLC Models
• There are various software development life cycle models defined and designed which are
followed during software development process. These models are also referred as "Software
Development Process Models". Each process model follows a Series of steps unique to its type,
in order to ensure success in process of software development.

• Following are the most important and popular SDLC models (which will discuss in this syllabus)
followed in the industry:
1. SDLC: Waterfall Model
2. SDLC: Prototype Model
3. SDLC: Spiral Model
4. SDLC: Evolutionary Development Models
5. SDLC: Iterative Enhancement Models.
Waterfall Model
• The classical waterfall model is intuitively the most obvious way to develop
• software. Though the classical waterfall model is elegant and intuitively obvious,
• it is not a practical model in the sense that it can not be used in actual software
• development projects. Thus, this model can be considered to be a theoretical
• way of developing software. But all other life cycle models are essentially derived
• from the classical waterfall model. So, in order to be able to appreciate other life
• cycle models it is necessary to learn the classical waterfall model.
Waterfall Model
• Classical waterfall model divides the life cycle into a set of phases.
• This model considers that one phase can be started after completion of the previous
phase.
• That is the output of one phase will be the input to the next phase.
• Thus the development process can be considered as a sequential flow in the waterfall.
• It is not a practical model in the sense that it can not be used in actual software
development projects. Thus, this model can be a theoretical way of developing software.
But all other life cycle models are essentially derived from the classical waterfall model.
So, in order to be able to appreciate other life cycle models it is necessary to learn the
classical waterfall model.
• Here the phases do not overlap with each other. The different sequential phases of the
classical waterfall model are shown in the below figure:
• All these phases are cascaded to each other in
which progress is seen as flowing steadily
downwards (like a waterfall) through the phases.
• The next phase is started only after the defined set
of goals are achieved for previous phase and it is
signed off, so the name "Waterfall Model". In this
model phases do not overlap.
Activities undertaken during feasibility study
• At the time of feasibility study project managers or team leaders have a rough
understanding that what is to be done.
• This is done based on different input and output data to be produced by the
system.
• It is studied processing is needed to be done on these data.
• After overall understanding, different possible solutions are investigated in terms
of resources required, cost of development, development time.
• Based on this analysis they pick the best solution and determine whether the
solution is feasible financially and technically. They check whether the customer
budget would meet the cost of the product and whether they have sufficient
technical expertise in the area of development.
Activities undertaken during Requirement
Analysis and specification
• The aim of the requirements analysis and specification phase is to understand the
exact requirements of the customer and to document them properly. This phase
consists of two distinct activities, namely
i. Requirements gathering and analysis, and
ii. Requirements specification
• The goal of the requirements gathering activity is to collect all relevant information
from the customer regarding the product to be developed.
• This is done to clearly understand the customer requirements so that
incompleteness and inconsistencies are removed.
• The goal of the requirements gathering activity is to collect all relevant information
from the customer regarding the product to be developed. This is done to clearly
understand the customer requirements so that incompleteness and
inconsistencies are removed.
Activities undertaken during Requirement
Analysis and specification
• The requirements analysis activity is begun by collecting all relevant data
regarding the product to be developed from the users of the product and
from the customer through interviews and discussions.
• After all ambiguities, inconsistencies, and incompleteness have been
resolved and all the requirements properly understood, the requirements
specification activity can start. During this activity, the user requirements
are systematically organized into a Software Requirements Specification
(SRS) document.
Activities undertaken during Design
• 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.
• In technical terms, during the design phase the software architecture is derived
from the SRS document. Two distinctly different approaches are available: the
traditional design approach and the object-oriented design approach.
Activities undertaken during Coding and Unit
Testing
• The purpose of the coding and unit testing phase (sometimes called the
implementation phase) of software development is to translate the software design
into source code. Each component of the design is implemented as a program
module.
• The end-product of this phase is a set of program modules that have been
individually tested.
• During this phase, each module is unit tested to determine the correct working of
all the individual modules.
• It involves testing each module in isolation as this is the most efficient way to
debug the errors identified at this stage.
Activities undertaken during integration and
system testing
• Integration of different modules is undertaken once they have been coded and unit tested.
• During the integration and system testing phase, the modules are integrated in a planned
manner.
• The different modules making up a software product are almost never integrated in one shot.
• Finally, when all the modules have been successfully integrated and tested, system testing
is carried out.
• The goal of system testing is to ensure that the developed system conforms to its
requirements laid out in the SRS document.
• System testing usually consists of three different kinds of testing activities:
• α – testing: It is the system testing performed by the development team.
• β – testing: It is the system testing performed by a friendly set of customers.
• acceptance testing: It is the system testing performed by the customer himself after the
product delivery to determine whether to accept or reject the delivered product .
Activities undertaken during Maintenance
• Maintenance involves performing any one or more of the following three kinds of
activities:
• Correcting errors that were not discovered during the product development phase.
This is called corrective maintenance.
• Improving the implementation of the system and enhancing the functionalities of the
system according to the customer’s requirements. This is called perfective
maintenance.
• Porting the software to work in a new environment. For example, porting may be
required to get the software to work on a new computer platform or with a new
operating system. This is called adaptive maintenance.
Waterfall Model Application
• Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use
of Waterfall model is most appropriate are:

· Requirements are very well documented, clear and fixed.

· Product definition is stable.
· Technology is understood and is not dynamic.
· There are no ambiguous requirements.
· Ample resources with required expertise are available to support the product.
· The project is short.
 Pros & Cons of Waterfall Model
Pros Cons
Simple and easy to understand and use No working software is produced until late during the life cycle.

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

Phases are processed and completed one at a time. Not a good model for complex and object-oriented projects.
Works well for smaller projects where requirements are very well
Poor model for long and ongoing projects.
understood.
Not suitable for the projects where requirements are at a moderate to
Clearly defined stages. high risk of changing. So risk and uncertainty is high with this process
model.

Well understood milestones. It is difficult to measure progress within stages.

Easy to arrange tasks. Cannot accommodate changing requirements.

Process and results are well documented. Adjusting scope during the life cycle can end a project.

Integration is done as a "big-bang. at the very end, which doesn't allow

identifying any technological or business bottleneck or challenges
early.
Prototype Model
• The Prototyping model is suitable for projects, which either the customer requirements or
the technical solutions are not well understood.
• This risks must be identified before the project starts. This model is especially popular for
the development of the user interface part of the project.
• In this process model, the system is partially implemented before or during the analysis
phase thereby giving the customers an opportunity to see the product early in the life
cycle.
• The process starts by interviewing the customers and developing the incomplete high-
level paper model.
• This document is used to build the initial prototype supporting only the basic functionality
as desired by the customer.
• Once the customer figures out the problems, the prototype is further refined to eliminate
them. The process continues till the user approves the prototype and finds the working
model to be satisfactory.
Prototype Model
• This is a valuable mechanism for gaining better understanding of the
customer’s needs:
• how the screens might look like
• how the user interface would behave
• how the system would produce outputs
• The developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, the form that the human-
machine interaction should take etc.
 Build Prototype

Requirements Customer Evaluation ofCustomer satisfied

Gathering Prototype
Quick Design Design

Refine Requirements Implement

Test

Maintain
Prototype Model
· Basic Requirement Identification: This step involves understanding the very basics product
requirements especially in terms of user interface. The more intricate details of the internal
design and external aspects like performance and security can be ignored at this stage.
· Developing the initial Prototype: The initial Prototype is developed in this stage, where the very
basic requirements are show cased and user interfaces are provided. These features may not
exactly work in the same manner internally in the actual software developed and the
workarounds are used to give the same look and feel to the customer in the prototype
developed.
· Review of the Prototype: The prototype developed is then presented to the customer and the other important
stakeholders in the project. The feedback is collected in an organized manner and used for
further enhancements in the product under development.
Prototype Model
· Revise and enhance the Prototype: The feedback and the review comments are discussed during
this stage and some negotiations happen with the customer based on factors like, time and
budget constraints and technical feasibility of actual implementation. The changes accepted are
again incorporated in the new Prototype developed and the cycle repeats until customer
expectations are met.
Prototype Model: Advantages
• The customers get to see the partial product early in the life cycle. This ensures a greater level of
customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing the
quality of the software.
• The developed prototype can be reused by the developer for more complicated projects in the
future.
• Flexibility in design.
Prototype Model: Disadvantages
• Costly w.r.t time as well as money.
• There may be too much variation in requirements each time the prototype is evaluated by the
customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for the developers to accommodate all the changes demanded by the
customer.
• There is uncertainty in determining the number of iterations that would be required before the
prototype is finally accepted by the customer.
• After seeing an early prototype, the customers sometimes demand the actual product to be
delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal solutions.
• The customer might lose interest in the product if he/she is not satisfied with the initial
prototype.
Spiral Model
• 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 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.
Spiral Model
• Each phase of Spiral Model is divided into four quadrants as shown in the above figure. The functions of
these four quadrants are discussed below-
1. 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.
2. 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 is identified and the risks are
resolved using the best possible strategy. At the end of this quadrant, Prototype is built for the best
possible solution.
3. 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.
4. 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.
Spiral Model
• 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.
• Prototyping Model also support 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
Prototyping Model.
• In each phase of the Spiral Model, the features of the product dated and analyzed and the risks at
that point of time are identified and are resolved through prototyping. Thus, this model is much
more flexible compared to other SDLC models.
Spiral Model as Meta Model
• The Spiral model is called as a Meta Model because it subsumes all the
other SDLC models. For example, a single loop spiral represents
the Iterative Waterfall Model.
• The spiral model incorporates the stepwise approach of the Classical
Waterfall Model.
• The spiral model uses the approach of 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.
Spiral Model: Advantages
• 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.
Spiral Model: Disadvantages
• 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.
• Too much dependable on Risk Analysis: The successful completion of the project is very much
dependent on Risk Analysis. Without very highly experienced expertise, it is going to be a failure to
develop a project using this model.
• Difficulty in time management: As the number of phases is unknown at the start of the project, so
time estimation is very difficult.
•
Iterative Enhancement Model
• In 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 in order 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.
Iterative Model design
• Iterative process starts with a simple implementation of a subset of the software requirements and
iteratively enhances the evolving versions until the full system is implemented. At each iteration,
design modifications are made and new functional capabilities are added. The basic idea behind this
method is to develop a system through repeated cycles (iterative) and in smaller portions at a time
(incremental).
Iterative Model design
•"During software development, more than one iteration of the software development cycle may be in
progress at the same time." and "This process may be described as an "evolutionary acquisition" or
"incremental build" approach."

•In incremental model the whole requirement is divided into various builds. During each iteration, the
development module goes through the requirements, design, implementation and testing phases. Each
subsequent release of the module adds function to the previous release. The process continues till the
complete system is ready as per the requirement.

•The key to 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 have to be
repeated and extended to verify each version of the software.
Iterative Model Application
•Like other SDLC models, Iterative and incremental development has some specific applications in
the software industry. This model is most often used in the following scenarios:
• Requirements of the complete system are clearly defined and understood.
· Major requirements must be defined; however, some functionalities or requested enhancements
may evolve with time.
· There is a time to the market constraint.
· A new technology is being used and is being learnt by the development team while working on the
project.
· Resources with needed skill set are not available and are planned to be used on contract basis for
specific iterations.
· There are some high-risk features and goals which may change in the future.
 Pros Cons
Some working functionality can be developed quickly
More resources may be required.
and early in the life cycle.
Although cost of change is lesser, but it is not very suitable for changing
Results are obtained early and periodically.
requirements.
Parallel development can be planned. More management attention is required.
System architecture or design issues may arise because not all
Progress can be measured.
requirements are gathered in the beginning of the entire life cycle.
Less costly to change the scope/requirements. Defining increments may require definition of the complete system.
Testing and debugging during smaller iteration is easy. Not suitable for smaller projects.
Risks are identified and resolved during iteration; and
Management complexity is more.
each iteration is an easily managed milestone.
Easier to manage risk - High risk part is done first. End of project may not be known which a risk is.
With every increment operational product is delivered. Highly skilled resources are required for risk analysis.
Issues, challenges & risks identified from each
increment can be utilized/applied to the nextProjects progress is highly dependent upon the risk analysis phase.
increment.
It supports changing requirements.
Initial Operating time is less.
Better suited for large and mission-critical projects.
During life cycle software is produced early which
facilitates customer evaluation and feedback.
Evolutionary Model
• Evolutionary model is a combination of Iterative and Incremental model of software development
life cycle. Delivering your system in a big bang release, delivering it in incremental process over
time is the action done in this model. Some initial requirements and architecture envisioning need
to be done.
• It is better for software products that have their feature sets redefined during development
because of user feedback and other factors. The Evolutionary development model divides the
development cycle into smaller, incremental waterfall models in which users are able to get access
to the product at the end of each cycle.
• Feedback is provided by the users on the product for the planning stage of the next cycle and the
development team responds, often by changing the product, plan or process. Therefore, the
software product evolves with time.

• All the models have the disadvantage that the duration of time from start of the project to the
delivery time of a solution is very high. Evolutionary model solves this problem in a different
approach.
Evolutionary Model
• Evolutionary model suggests breaking down of work into smaller chunks, prioritizing them and then
delivering those chunks to the customer one by one.
• The number of chunks is huge and is the number of deliveries made to the customer.
• The main advantage is that the customer’s confidence increases as he constantly gets quantifiable
goods or services from the beginning of the project to verify and validate his requirements.
• The model allows for changing requirements as well as all work in broken down into maintainable
work chunks.

Specification Initial version

Outline
description Intermediate
Development
versions

Validation Final version

Application of Evolutionary Model:
• It is used in large projects where you can easily find modules for
incremental implementation. Evolutionary model is commonly used
when the customer wants to start using the core features instead of
waiting for the full software.
• Evolutionary model is also used in object-oriented software
development because the system can be easily portioned into units in
terms of objects.
Advantages and Disadvantages
• Advantages:
• In evolutionary model, a user gets a chance to experiment partially developed system.
• It reduces the error because the core modules get tested thoroughly.
• Disadvantages:
• Sometimes it is hard to divide the problem into several versions that would be acceptable to
the customer which can be incrementally implemented and delivered.