Process Models

PSP: The personal software process is focused on individuals to improve their performance. The PSP is an
individual process, and it is a bottom-up approach to software process improvement. The PSP is a prescriptive
process, it is a more mature methodology with a well-defined set of tools and techniques.
Key Features of PSP :
 Process-focused: PSP is a process-focused methodology that emphasizes the importance of following a
disciplined approach to software development.
 Personalized: PSP is personalized to an individual’s skill level, experience, and work habits. It recognizes that
individuals have different strengths and weaknesses, and tailors the process to meet their specific needs.
 Metrics-driven: PSP is metrics-driven, meaning that it emphasizes the collection and analysis of data to
measure progress and identify areas for improvement.
 Incremental: PSP is incremental, meaning that it breaks down the development process into smaller, more
manageable pieces that can be completed in a step-by-step fashion.
 Quality-focused: PSP is quality-focused, meaning that it emphasizes the importance of producing high-
quality software that meets user requirements and is free of defects.
Advantages :
 Improved productivity: PSP provides a structured approach to software development that can help
individuals improve their productivity by breaking down the development process into smaller, more
manageable steps.
 Improved quality: PSP emphasizes the importance of producing high-quality software that meets user
requirements and is free of defects. By collecting and analyzing data throughout the development process,
individuals can identify and eliminate sources of errors and improve the quality of their work.
 Personalized approach: PSP is tailored to an individual’s skill level, experience, and work habits, which can
help individuals work more efficiently and effectively.
 Improved estimation: PSP emphasizes the importance of accurate estimation, which can help individuals
plan and execute projects more effectively.
 Continuous improvement: PSP promotes a culture of continuous improvement, which can help individuals
learn from past experiences and apply that knowledge to future projects.
Disadvantages :
 Time-consuming: PSP can be time-consuming, particularly when individuals are first learning the
methodology and need to collect and analyze data throughout the development process.
 Complex: PSP can be complex, particularly for individuals who are not familiar with software engineering
concepts or who have limited experience in software development.
 Heavy documentation: PSP requires a significant amount of documentation throughout the development
process, which can be burdensome for some individuals.
 Limited to individual use: PSP is designed for individual use, which means that it may not be suitable for
team-based software development projects.
TSP: TSP is a team-based process. It is focused on team productivity. Basically, it is a top-down approach. The
TSP is an adaptive process, and process management methodology.
Key Features of TSP :
 Team-focused: TSP is team-focused, meaning that it emphasizes the importance of collaboration and
communication among team members throughout the software development process.
 Process-driven: TSP is process-driven, meaning that it provides a structured approach to software
development that emphasizes the importance of following a disciplined process.
 Metrics-driven: TSP is metrics-driven, meaning that it emphasizes the collection and analysis of data to
measure progress, identify areas for improvement, and make data-driven decisions.
 Incremental: TSP is incremental, meaning that it breaks down the development process into smaller, more
manageable pieces that can be completed in a step-by-step fashion.
 Quality-focused: TSP is quality-focused, meaning that it emphasizes the importance of producing high-
quality software that meets user requirements and is free of defects.
 Feedback-oriented: TSP is feedback-oriented, meaning that it emphasizes the importance of receiving
feedback from peers, mentors, and other stakeholders to identify areas for improvement.
Advantages of TSP :
 Improved productivity: TSP provides a structured approach to software development that can help teams
improve their productivity by breaking down the development process into smaller, more manageable steps.
 Improved quality: TSP emphasizes the importance of producing high-quality software that meets user
requirements and is free of defects. By collecting and analyzing data throughout the development process,
teams can identify and eliminate sources of errors and improve the quality of their work.
 Team collaboration: TSP promotes team collaboration, which can help teams work more efficiently and
effectively by leveraging the skills and expertise of all team members.
 Improved estimation: TSP emphasizes the importance of accurate estimation, which can help teams plan
and execute projects more effectively.
 Continuous improvement: TSP promotes a culture of continuous improvement, which can help teams learn
from past experiences and apply that knowledge to future projects.
Disadvantages of TSP :
 Time-consuming: TSP can be time-consuming, particularly when teams are first learning the methodology
and need to collect and analyze data throughout the development process.
 Complex: TSP can be complex, particularly for teams that are not familiar with software engineering
concepts or who have limited experience in software development.
 Heavy documentation: TSP requires a significant amount of documentation throughout the development
process, which can be burdensome for some teams.
 Requires discipline: TSP requires teams to follow a disciplined approach to software development, which
can be challenging for some teams who prefer a more flexible approach.
 Cost: TSP can be costly to implement, particularly if teams need to invest in training or software tools to
support the methodology.
DIFFERENCE:
PSP TSP

PSP is a project management process that

TSP is a project management process that defines how to
defines how to manage a project in a face-to-
manage a project in a virtual environment.
face environment.

PSP is more formal and structured than TSP. TSP is less formal and structured than PSP.

PSP is based on the waterfall model. TSP is based on the agile model.

PSP is more suited for large projects. TSP is more suited for small projects.

PSP projects are typically completed in one

TSP projects are typically completed in multiple phases.
phase.

PSP is a high-level language and it is easy to TSP is a low-level language and it is difficult to learn and
learn and use. use.

PSP is a structured language and it is easy to TSP is an unstructured language and it is difficult to read
read and write. and write.

PSP programs are written in English and they TSP programs are written in assembly language and they
are easy to understand. are difficult to understand.

PSP is a portable language and it can be run on TSP is a platform-dependent language and it can be run
any platform. only on specific platforms.

PSP is an interpreted language and it does not TSP is a compiled language and it needs to be compiled
need to be compiled. before it can be run.

PSP is a free language and it can be TSP is a commercial language and it is not available for
downloaded from the internet. free.

PSP is an open-source language and it is TSP is a closed-source language and it is not available to
available to everyone. everyone.

TSP, on the other hand, is an iterative and incremental

PSP is a linear process model that is completed
process model that allows for feedback and changes at
in a sequential manner.
each stage of the process.
What is the SDLC Waterfall Model?
The waterfall model is a software development model used in the context of large, complex projects, typically
in the field of information technology. It is characterized by a structured, sequential approach to project
management and software development.
The waterfall model is useful in situations where the project requirements are well-defined and the project goals
are clear. It is often used for large-scale projects with long timelines, where there is little room for error and the
project stakeholders need to have a high level of confidence in the outcome.
Features of the SDLC Waterfall Model
1. Sequential Approach: The waterfall model involves a sequential approach to software development,
where each phase of the project is completed before moving on to the next one.
2. Document-Driven: The waterfall model relies heavily on documentation to ensure that the project is
well-defined and the project team is working towards a clear set of goals.
3. Quality Control: The waterfall model places a high emphasis on quality control and testing at each
phase of the project, to ensure that the final product meets the requirements and expectations of the
stakeholders.
4. Rigorous Planning: The waterfall model involves a rigorous planning process, where the project scope,
timelines, and deliverables are carefully defined and monitored throughout the project lifecycle.
5. Overall, the waterfall model is used in situations where there is a need for a highly structured and
systematic approach to software development. It can be effective in ensuring that large, complex
projects are completed on time and within budget, with a high level of quality and customer satisfaction.
Importance of SDLC Waterfall Model
1. Clarity and Simplicity: The linear form of the Waterfall Model offers a simple and unambiguous
foundation for project development.
2. Clearly Defined Phases: The Waterfall Model’s phases each have unique inputs and outputs,
guaranteeing a planned development with obvious checkpoints.
3. Documentation: A focus on thorough documentation helps with software comprehension, upkeep,
and future growth.
4. Stability in Requirements: Suitable for projects when the requirements are clear and steady, reducing
modifications as the project progresses.
5. Resource Optimization: It encourages effective task-focused work without continuously changing
contexts by allocating resources according to project phases.
6. Relevance for Small Projects: Economical for modest projects with simple specifications and minimal
complexity.
Phases of SDLC Waterfall Model – Design
The Waterfall Model is a classical software development methodology that was first introduced by Winston W.
Royce in 1970. It is a linear and sequential approach to software development that consists of several phases
that must be completed in a specific order.
The Waterfall Model has six phases which are:
1. Requirements: The first phase involves gathering requirements from stakeholders and analyzing them to
understand the scope and objectives of the project.
2. Design: Once the requirements are understood, the design phase begins. This involves creating a detailed
design document that outlines the software architecture, user interface, and system components.
3. Development: The Development phase include implementation involves coding the software based on the
design specifications. This phase also includes unit testing to ensure that each component of the software is
working as expected.
4. Testing: In the testing phase, the software is tested as a whole to ensure that it meets the requirements and
is free from defects.
5. Deployment: Once the software has been tested and approved, it is deployed to the production
environment.
6. Maintenance: The final phase of the Waterfall Model is
maintenance, which involves fixing any issues that arise after the
software has been deployed and ensuring that it continues to meet the
requirements over time.
Applications of SDLC Waterfall Model
 Large-scale Software Development Projects: The Waterfall Model
is often used for large-scale software development projects, where
a structured and sequential approach is necessary to ensure that
the project is completed on time and within budget.
 Safety-Critical Systems: The Waterfall Model is often used in the development of safety-critical systems,
such as aerospace or medical systems, where the consequences of errors or defects can be severe.
 Government and Defense Projects: The Waterfall Model is also commonly used in government and
defense projects, where a rigorous and structured approach is necessary to ensure that the project meets
all requirements and is delivered on time.
 Projects with well-defined Requirements: The Waterfall Model is best suited for projects with well-
defined requirements, as the sequential nature of the model requires a clear understanding of the project
objectives and scope.
 Projects with Stable Requirements: The Waterfall Model is also well-suited for projects with stable
requirements, as the linear nature of the model does not allow for changes to be made once a phase has
been completed.

V-MODEL: The V-Model is a software development life cycle (SDLC) model that provides a systematic and
visual representation of the software development process. It is based on the idea of a “V” shape, with the
two legs of the “V” representing the progression of the software development process from requirements
gathering and analysis to design, implementation, testing, and maintenance.

V-Model Design
1. Requirements Gathering and Analysis: The first phase of the V-Model is the requirements gathering
and analysis phase, where the customer’s requirements for the software are gathered and analyzed to
determine the scope of the project.
2. Design: In the design phase, the software architecture and design are developed, including the high-
level design and detailed design.
3. Implementation: In the implementation phase, the software is built based on the design.
4. Testing: In the testing phase, the software is tested to ensure that it meets the customer’s
requirements and is of high quality.
5. Deployment: In the deployment phase, the software is deployed and put into use.
6. Maintenance: In the maintenance phase, the software is maintained to ensure that it continues to
meet the customer’s needs and expectations.
7. The V-Model is often used in safety: critical systems, such as aerospace and defence systems, because
of its emphasis on thorough testing and its ability to clearly define the steps involved in the software
development process.

The following illustration depicts the different phases in a V-Model of the SDLC.
Verification Phases:It involves a static analysis technique (review) done without executing code. It is the
process of evaluation of the product development phase to find whether specified requirements are met.
There are several Verification phases in the V-Model:
Business Requirement Analysis:This is the first step of the designation of the development cycle where
product requirement needs to be cured from the customer’s perspective. in these phases include proper
communication with the customer to understand the requirements of the customers. these are the very
important activities that need to be handled properly, as most of the time customers do not know exactly
what they want, and they are not sure about it at that time then we use an acceptance test design planning
which is done at the time of business requirement it will be used as an input for acceptance testing.
System Design:Design of the system will start when the overall we are clear with the product requirements,
and then need to design the system completely. This understanding will be at the beginning of complete
under the product development process. these will be beneficial for the future execution of test cases.
Architectural Design:In this stage, architectural specifications are comprehended and designed. Usually,
several technical approaches are put out, and the ultimate choice is made after considering both the technical
and financial viability. The system architecture is further divided into modules that each handle a distinct
function. Another name for this is High-Level Design (HLD).
At this point, the exchange of data and communication between the internal modules and external systems
are well understood and defined. During this phase, integration tests can be created and documented using
the information provided.
Module Design:This phase, known as Low-Level Design (LLD), specifies the comprehensive internal design for
every system module. Compatibility between the design and other external systems as well as other modules
in the system architecture is crucial. Unit tests are a crucial component of any development process since they
assist in identifying and eradicating the majority of mistakes and flaws at an early stage. Based on the internal
module designs, these unit tests may now be created.
Coding Phase:The Coding step involves writing the code for the system modules that were created during the
Design phase. The system and architectural requirements are used to determine which programming language
is most appropriate.The coding standards and principles are followed when performing the coding. Before the
final build is checked into the repository, the code undergoes many code reviews and is optimized for optimal
performance.
Validation Phases:It involves dynamic analysis techniques (functional, and non-functional), and testing done
by executing code. Validation is the process of evaluating the software after the completion of the
development phase to determine whether the software meets the customer’s expectations and
requirements. So, V-Model contains Verification phases on one side of the Validation phases on the other side.
The verification and Validation phases are joined by the coding phase in a V-shape. Thus, it is called V-Model.
There are several Validation phases in the V-Model:
Unit Testing:Unit Test Plans are developed during the module design phase. These Unit Test Plans are
executed to eliminate bugs in code or unit level.
Integration testing:After completion of unit testing Integration testing is performed. In integration testing, the
modules are integrated and the system is tested. Integration testing is performed in the Architecture design
phase. This test verifies the communication of modules among themselves.
System Testing:System testing tests the complete application with its functionality, inter-dependency, and
communication. It tests the functional and non-functional requirements of the developed application.
User Acceptance Testing (UAT):UAT is performed in a user environment that resembles the production
environment. UAT verifies that the delivered system meets the user’s requirement and the system is ready for
use in the real world.
Design Phase:
 Requirement Analysis: This phase contains detailed communication with the customer to understand their
requirements and expectations. This stage is known as Requirement Gathering.
 System Design: This phase contains the system design and the complete hardware and communication
setup for developing the product.
 Architectural Design: System design is broken down further into modules taking up different
functionalities. The data transfer and communication between the internal modules and with the outside
world (other systems) is clearly understood.
 Module Design: In this phase, the system breaks down into small modules. The detailed design of modules
is specified, also known as Low-Level Design (LLD).
Testing Phases:
 Unit Testing: Unit Test Plans are developed during the module design phase. These Unit Test Plans are
executed to eliminate bugs at the code or unit level.
 Integration testing: After completion of unit testing Integration testing is performed. In integration testing,
the modules are integrated, and the system is tested. Integration testing is performed in the Architecture
design phase. This test verifies the communication of modules among themselves.
 System Testing: System testing tests the complete application with its functionality, interdependency, and
communication. It tests the functional and non-functional requirements of the developed application.
 User Acceptance Testing (UAT): UAT is performed in a user environment that resembles the production
environment. UAT verifies that the delivered system meets the user’s requirement and the system is ready
for use in the real world.

When to Use of V-Model?

 Traceability of Requirements: The V-Model proves beneficial in situations when it’s imperative to create
precise traceability between the requirements and their related test cases.
 Complex Projects: The V-Model offers a methodical way to manage testing activities and reduce risks
related to integration and interface problems for projects with a high level of complexity and
interdependencies among system components.
 Waterfall-Like Projects: Since the V-Model offers an approachable structure for organizing, carrying out,
and monitoring testing activities at every level of development, it is appropriate for projects that use a
sequential approach to development, much like the waterfall model.
 Safety-Critical Systems: These systems are used in the aerospace, automotive, and healthcare industries.
They place a strong emphasis on rigid verification and validation procedures, which help to guarantee that
essential system requirements are fulfilled and that possible risks are found and eliminated early in the
development process.

What is the Incremental Process Model?

First, a simple working system implementing only a few basic features is built and then that is delivered to the
customer. Then thereafter many successive iterations/ versions are implemented and delivered to the
customer until the desired system is released.
Types of Incremental Model
1. Staged Delivery Model
2. Parallel Development Model
1. Staged Delivery Model
Construction of only one part of the project at a time.

2. Parallel Development Model

Different subsystems are developed at the same time. It
can decrease the calendar time needed for the
development, i.e. TTM (Time to Market) if enough
resources are available.
When to use the Incremental Process Model
1. Funding Schedule, Risk, Program Complexity, or need for early realization of benefits.
2. When Requirements are known up-front.
3. When Projects have lengthy development schedules.
4. Projects with new Technology.
 Error Reduction (core modules are used by the customer from the beginning of the phase and then
these are tested thoroughly).
 Uses divide and conquer for a breakdown of tasks.
 Lowers initial delivery cost.
 Incremental Resource Deployment.
5. Requires good planning and design.
6. The total cost is not lower.
7. Well-defined module interfaces are required.
Characteristics of Incremental Process Model
1. System development is divided into several smaller projects.
2. To create a final complete system, partial systems are constructed one after the other.
3. Priority requirements are addressed first.
4. The requirements for that increment are frozen once they are created.

Advantages of the Incremental Process Model

1. Prepares the software fast.
2. Clients have a clear idea of the project.
3. Changes are easy to implement.
4. Provides risk handling support, because of its iterations.
5. Adjusting the criteria and scope is flexible and less costly.
6. Comparing this model to others, it is less expensive.
7. The identification of errors is simple.
Disadvantages of the Incremental Process Model
1. A good team and proper planned execution are required.
2. Because of its continuous iterations the cost increases.
3. Issues may arise from the system design if all needs are not gathered upfront throughout the program
lifecycle.
4. Every iteration step is distinct and does not flow into the next.
5. It takes a lot of time and effort to fix an issue in one unit if it needs to be corrected in all the units.

What are Evolutionary Process Models?

The evolutionary model is based on the concept of making an initial product and then evolving the software
product over time with iterative and incremental approaches with proper feedback. In this type of model, the
product will go through several iterations and come up when the final product is built through multiple
iterations. The development is carried out simultaneously with the feedback during the development. This
model has a number of advantages such as customer involvement, taking feedback from the customer during
development, and building the exact product that the user wants. Because of the multiple iterations, the
chances of errors get reduced and the reliability and efficiency will increase.
Types of Evolutionary Process Models
1. Iterative Model
2. Incremental Model
3. Spiral Model
Iterative Model
In the iterative model first, we take the initial
requirements then we enhance the product over
multiple iterations until the final product gets
ready. In every iteration, some design
modifications were made and some changes in
functional requirements is added. The main idea
behind this approach is to build the final product
through multiple iterations that result in the final product being almost the same as the user wants with fewer
errors and the performance, and quality would be high.

Incremental Model
In the incremental model, we first build the project with
basic features and then evolve the project in every
iteration, it is mainly used for large projects. The first step is
to gather the requirements and then perform analysis,
design, code, and test and this process goes the same over
and over again until our final project is ready.

Spiral Model
The spiral model is a combination of waterfall and iterative
models and in this, we focused on risk handling along with
developing the project with the incremental and iterative
approach, producing the output quickly as well as it is good for
big projects. The software is created through multiple iterations
using a spiral approach. Later on, after successive development
the final product will develop, and the customer interaction is
there so the chances of error get reduced.

Advantages of the Evolutionary Process Model

1. During the development phase, the customer gives feedback regularly because the customer’s
requirement gets clearly specified.
2. After every iteration risk gets analyzed.
3. Suitable for big complex projects.
4. The first build gets delivered quickly as it used an iterative and incremental approach.
5. Enhanced Flexibility: The iterative nature of the model allows for continuous changes and refinements
to be made, accommodating changing requirements effectively.
6. Risk Reduction: The model’s emphasis on risk analysis during each iteration helps in identifying and
mitigating potential issues early in the development process.
7. Adaptable to Changes: Since changes can be incorporated at the beginning of each iteration, it is well-
suited for projects with evolving or uncertain requirements.
8. Customer Collaboration: Regular customer feedback throughout the development process ensures
that the end product aligns more closely with the customer’s needs and expectations.
Disadvantages of the Evolutionary Process Model
1. It is not suitable for small projects.
2. The complexity of the spiral model can be more than the other sequential models.
3. The cost of developing a product through a spiral model is high.
4. roject Management Complexity: The iterative nature of the model can make project management and
tracking more complex compared to linear models.
5. Resource Intensive: The need for continuous iteration and customer feedback demands a higher level
of resources, including time, personnel, and tools.
6. Documentation Challenges: Frequent changes and iterations can lead to challenges in maintaining
accurate and up-to-date documentation.
7. Potential Scope Creep: The flexibility to accommodate changes can sometimes lead to an uncontrolled
expansion of project scope, resulting in scope creep.
8. Initial Planning Overhead: The model’s complexity requires a well-defined initial plan, and any
deviations or adjustments can be time-consuming and costly.

Selection Process Parameters for a Software Life Cycle Model

Selection Process parameters plays an important role in software development as it helps to choose the best
suitable software life cycle model. Following are the parameters which should be used to select a SDLC.
1. Requirements characteristics :
 Reliability of Requirements
 How often the requirements can change
 Types of requirements
 Number of requirements
 Can the requirements be defined at an early stage
 Requirements indicate the complexity of the system
2. Development team :
 Team size
 Experience of developers on similar type of projects
 Level of understanding of user requirements by the developers
 Environment
 Domain knowledge of developers
 Experience on technologies to be used
 Availability of training
3. User involvement in the project :
 Expertise of user in project
 Involvement of user in all phases of the project
 Experience of user in similar project in the past
4. Project type and associated risk :
 Stability of funds
 Tightness of project schedule
 Availability of resources
 Type of project
 Size of the project
 Expected duration for the completion of project
 Complexity of the project
 Level and the type of associated risk