SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

SDLC Models
SDLC, which stands for Software Development Life Cycle, is like a set of rules
that software companies follow when working on a software project. It's a step-
by-step plan that explains how to develop, maintain, replace and make
improvements to software. The main goal of this process is to make sure the
software is high quality and to make the whole development process better.
The following figure is a graphical representation of the various stages of a typical
SDLC.

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis
The first step in the SDLC is 'requirement analysis.' Team members gather info
from customers, sales, research, and industry experts. This info helps plan the
project and determine its practicality and cost-effectiveness. In the planning
stage, we ensure quality and identify risks, choosing the best approach with
minimal risk.
Stage 2: Defining Requirements
After we've analyzed the requirements, the next step is to create a clear document
that lists all the things the product needs to do. This document is called 'SRS'
(Software Requirement Specification), and it contains everything the product
should have from the start to the end of the project.

DIPAK KUMAR SAHOO 1

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Stage 3: Designing the Product Architecture

The SRS (Software Requirement Specification) is a guide for architects to plan
the product. After listing the requirements in the SRS, different design options
are documented in the DDS. Project stakeholders review the DDS (Design
Document Specification) considering risks, product strength, usability, and
resources to select the best design. The chosen design outlines how product parts
work together, communicate, and includes detailed component descriptions.
Stage 4: Building or Developing the Product
In this SDLC phase, the product development begins. Developers write code
following the DDS plan. Careful design makes coding easier. They adhere to
company guidelines and use software tools like compilers. They use high-level
programming languages (C, C++, etc.) based on the software type.
Stage 5: Testing the Product
In most modern software development models, testing happens throughout the
entire development process. However, this stage specifically focuses on testing
the product. During this stage, any problems or errors in the product are identified,
documented, fixed, and then tested again. This process continues until the product
meets the quality standards set in the SRS.
Stage 6: Deployment in the Market and Maintenance
Post-testing, products are released gradually to the market. Initial releases may
involve small groups with User Acceptance Testing. Feedback determines if
improvements are needed before broader releases. Continuous maintenance
serves existing users. Different software development models guide these steps
in the software development process.
Following are the most important and popular SDLC models followed in the
industry:
➢ Waterfall Model
➢ Iterative Model
➢ Prototyping Model
➢ Evolutionary Model
➢ Spiral Model
➢ V-Model
➢ RAD
➢ Agile Model
➢ Big Bang Model

DIPAK KUMAR SAHOO 2

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Waterfall Model
The Waterfall Model is one of the first and simplest methods for creating
software. It's like a step-by-step approach where each phase of the project must
finish before the next one begins. There's no overlap, and it's very structured. In
the past, it was quite popular for big, well-defined projects, especially in the field
of information technology.
Even though it's not as widely used today, it's still important because it serves as
the foundation for many other software development models. The Waterfall
Model is ideal when you have a clear idea of what your project needs and you
want to be sure about the results. It's best for projects with a long timeline and
little room for mistakes.
Waterfall Model – Design
The Waterfall approach was one of the earliest and widely used models in
Software Engineering to make sure projects went smoothly. It breaks down the
entire software development process into distinct phases. In the Waterfall model,
each phase's results are used as the starting point for the next phase in a step-by-
step sequence.
The picture below shows the various stages of the Waterfall Model.

DIPAK KUMAR SAHOO 3

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

The Waterfall model is a classic way to develop software, and it's like following
a recipe. It has several phases that need to be completed one after the other.
➢ Requirement Gathering and Analysis: First, we figure out what the
software needs to do by talking to the people who will use it. Everything
we learn is written down in a document.
➢ System Design: Next, we create a detailed plan for how the software will
look and work. This plan includes things like how the different parts of the
software will fit together.
➢ Implementation: After the plan is ready, we start writing the actual code
for the software. We also test each small piece to make sure it works
correctly.
➢ Testing: Once all the pieces are done, we put them together to test the
whole software. We want to be sure it works as expected and doesn't have
any problems.
➢ Deployment: When testing is complete, and we're confident the software
is good to go, we release it for people to use.
➢ Maintenance: Even after releasing the software, we keep an eye on it. If
any issues come up, we fix them, and sometimes we even make the
software better with updates.
The Waterfall model is like a step-by-step journey. Each phase depends on the
one before it, and there's no jumping ahead. It's a simple and structured way to
create software.
Features of the Waterfall Model:
The Waterfall Model has some key features:
➢ Step-by-Step: It's like a series of steps. Each part of the project is finished
before moving on to the next one.
➢ Lots of Documents: This approach relies on a lot of written documents to
make sure everyone understands the project and its goals.
➢ Quality Control: At every step, there's a focus on testing and making sure
the final product matches what the stakeholders want.
➢ Careful Planning: The Waterfall Model involves careful planning. They
figure out exactly what needs to be done, how long it will take, and what
they'll deliver.
The Waterfall Model is great for big, complicated projects where everything
needs to be well-organized. It helps make sure things are done on time, on budget,
and with high quality, which makes customers happy.

DIPAK KUMAR SAHOO 4

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Advantages of the Waterfall Model:

The Waterfall Model is a simple and idealistic way of making software. It's like
the foundation for many other ways of making software. Here are some reasons
people like it:
➢ Easy to Understand: It's really easy to get how it works.
➢ One Step at a Time: In this model, you finish one part before moving to
the next.
➢ Clearly Defined Stages: Each step is crystal clear, so you know what to
do.
➢ Milestones: You can easily see when you've reached important points in
the project.
➢ Lots of Documentation: Everything you do is well-documented, which is
like taking notes.
➢ Good Habits: It encourages good practices like planning before creating
and designing before coding.
➢ Small and Clear Projects: It's good for small projects where you already
know what you need.
So, the Waterfall Model is great when you have a small and clear project that you
can do one step at a time, and you want everything well-documented.
Disadvantages of the Classical Waterfall Model:
The Classical Waterfall Model has several problems that make it not so great for
real projects. Instead, people use variations based on this model. Here are some
of the main issues with the Classical Waterfall Model:
➢ No Way to Fix Mistakes: It assumes everything goes perfectly with no
mistakes, so there's no way to correct errors.
➢ Can't Handle Changes: It assumes all customer needs are known at the
start, but real needs often change. It's hard to adjust once the project has
started.
➢ No Overlapping: It says one phase must finish before the next starts, but
that doesn't work well in real projects where things need to overlap for
efficiency.
➢ Not Flexible: It's rigid and doesn't adapt to changing needs. Once a phase
is done, it's tough to go back or make changes.
➢ Limited Input: Stakeholders are involved at the beginning but not always
later in the project.
➢ Late Error Discovery: Testing happens late, so errors aren't found until
the end, which can be costly.

DIPAK KUMAR SAHOO 5

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ Takes a Long Time: It can take a while because each step has to be done
before moving on, leading to delays and higher costs if things change.
➢ Not for Complex Projects: It's not great for complex projects with many
parts and connections."
In real projects, people often choose models that handle these issues better.
Applications of Classical Waterfall Model:
The Waterfall Model is often used in specific situations:
➢ Large-Scale Projects: It's great for big projects where you need a
structured plan to finish on time and on budget.
➢ Safety-Critical Systems: In fields like aerospace and medicine, where
errors can be dangerous, it's a good choice.
➢ Government and Defense: It's commonly used in government and
defense projects to make sure everything is done correctly and on schedule.
➢ Projects with Clear Needs: It works well when you already know exactly
what the project should do because it follows a clear sequence.
➢ Stable Requirements: If the project's requirements won't change, this
model is a good fit because it doesn't allow changes once a phase is
finished.

Iterative Model
In the Iterative Model, you begin with some software specifications and create
the first version of the software. If changes are needed, a new version is made in
the next iteration. Each release in this model has a fixed period called an iteration.
This model lets you go back to previous phases to make improvements. The
project's final output is updated at the end of the Software Development Life
Cycle (SDLC) process.

DIPAK KUMAR SAHOO 6

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

The various phases of Iterative model are as follows:

➢ Requirement Gathering & Analysis: This is where we gather what
customers need and check if it fits the budget. Then, we move on to the
next step.
➢ Design: We design the software using different diagrams like flowcharts
and diagrams to plan how it will work.
➢ Implementation: Here, we write the code, turning the design into actual
software.
➢ Testing: We test the software using various methods to find and fix any
issues.
➢ Deployment: The software is put into action in its working environment.
➢ Review: After deployment, we review the software to make sure it works
as expected. If there are issues, we go back to the first step.
➢ Maintenance: If there are bugs or new features needed, we do
maintenance, like fixing problems and adding updates.
Advantages of Iterative Model:
➢ Testing and fixing issues is simpler in smaller steps.
➢ Different parts of the project can be developed simultaneously.
➢ It's adaptable to changing project needs.
➢ Risks are discovered and addressed during each step.
➢ Less time spent on paperwork, more on planning.

DIPAK KUMAR SAHOO 7

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Disadvantages of Iterative Model:

➢ Not suitable for small projects.
➢ Requires more resources.
➢ Frequent design changes due to unclear requirements.
➢ Changing requirements can lead to going over budget.
➢ Project completion date can't be fixed due to changing needs.
Iterative Model Application:
Iterative development is used in specific situations in the software industry:
➢ Clear System Requirements: When all system requirements are well-
defined.
➢ Evolutionary Functionalities: Major requirements are set, but some
features might change over time.
➢ Time Constraints: Projects needing quick deployment to the market.
➢ New Technology: When a new technology is used, learned during the
project.
➢ Limited Resources: Skill sets are scarce and planned to be contracted for
specific phases.
➢ High-Risk Features: Projects with uncertain or changing high-risk
features.

Prototyping Model
The prototype model involves creating a basic version of the software before the
final development. It's like a rough draft and may have limited features,
reliability, and performance. It's useful when customers don't have all the details
about what they want. The model keeps improving through customer feedback,
and the final product is built based on an approved prototype.
Prototyping is a widely used approach in software development when customers
are uncertain about project requirements. It starts with interviews and a basic
paper model, then evolves based on customer input, repeating until a satisfactory
version is achieved. It allows customers to see progress early in the project and
ensures the final product meets their needs.

DIPAK KUMAR SAHOO 8

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Prototype Model Steps:

➢ Gather Requirements: Collect the project requirements.
➢ Make Quick Decisions: Decide on what the prototype should include.
➢ Create a Prototype: Build a basic working version.
➢ User Evaluation: Let users assess the prototype.
➢ Refine the Prototype: Improve it based on user feedback.
➢ Develop the Final Product: Once the prototype is accepted, develop the
complete product.
Advantages of Prototype Model:
➢ Reduces Risk: Minimizes the chance of misunderstanding user
requirements.
➢ Adaptable: Suitable for projects with changing or unclear requirements.
➢ Visibility: Helps management monitor the progress.
➢ Early Marketing: Supports early product marketing.
➢ Saves Costs: Lowers maintenance costs.

DIPAK KUMAR SAHOO 9

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ Early Error Detection: Identifies errors at an early stage.

Disadvantages of Prototype Model:
➢ Final Product: An unstable prototype may become the final product.
➢ Customer Collaboration: Requires extensive customer involvement.
➢ Costly: Can be costly for customers.
➢ Committed Customer: Needs a committed customer throughout.
➢ Project Uncertainty: Difficult to complete if the customer withdraws.
➢ Niche Focus: May be too specific to appeal to a broad market.
➢ Uncertain Duration: Project duration is uncertain.
➢ Hasty Fixes: May lead to hasty coding without proper analysis, design,
evaluation, and feedback.
➢ Costly Tools: Prototyping tools can be expensive.
➢ Special Requirements: Requires special tools and techniques.
➢ Time-Consuming: The process can be time-consuming.

Evolutionary Model
The Evolutionary model is like a mix of the Iterative and Incremental models in
software development. Instead of delivering everything at once, it's done in
smaller, gradual steps over time. This model is good for products that might
change due to user feedback. It divides the work into smaller parts, delivers them
one by one, and gathers user feedback for each part. This way, the customer can
verify their requirements and make changes as needed, which makes them more
confident in the project's progress. It's a solution to speed up delivery and adapt
to changing needs.

DIPAK KUMAR SAHOO 10

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Application of Evolutionary Model:

➢ Large Projects: Useful in big projects where you can work on parts one
by one.
➢ Core Features: When the customer wants to use the essential parts rather
than waiting for the full software.
➢ Object-Oriented Development: It's great for object-oriented software
where you can split it into smaller units.
Conditions for Implementation:
➢ Clear Customer Needs: The customer's requirements should be well-
explained.
➢ Small Changes: Mainly small changes, not major ones.
➢ Time Availability: Some time should be available, not rushed.
➢ High Risk: There's risk, and you need to meet targets regularly.
➢ Learning Curve: Useful when dealing with new technology that needs
time to learn.
Advantages:
➢ User Testing: Users can try out a partly built system.
➢ Reduced Errors: The core parts get thoroughly tested.

DIPAK KUMAR SAHOO 11

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Disadvantages:
➢ Complex Splitting: Sometimes it's tricky to divide the problem into
acceptable versions for incremental delivery.

Spiral Model
The Spiral Model is a significant Software Development Life Cycle model,
resembling a spiral with multiple loops. The number of loops, or phases, can vary
based on project risks. It provides a systematic and iterative approach to software
development, covering requirements, design, implementation, testing, and
maintenance.
The spiral model combines prototyping's iterative nature with the structured
aspects of the linear sequential model. It allows for the rapid development of
software in incremental releases, starting with models or prototypes and
progressing to complete system versions during later iterations.

The Spiral Model is divided into four parts in each cycle:

➢ Objective Setting: Start by identifying the cycle's purpose, possible ways
to achieve goals, and any constraints.
➢ Risk Assessment and Reduction: Calculate alternatives based on goals
and constraints, focusing on project risks.

DIPAK KUMAR SAHOO 12

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ Development and Validation: Develop strategies to address uncertainties

and risks, using activities like benchmarking, simulation, and prototyping.
➢ Planning: In each Spiral Model cycle, there are four steps: Review and
decide whether to move to the next phase, make plans for that phase,
develop solutions for the most critical risks, and address remaining project
risks. This model is adaptable, allowing different approaches, and includes
reviews at the end of each cycle. It's suitable for both new development
and improvements to existing projects.
When to Use Spiral Model:
➢ When frequent deliveries are needed.
➢ For large projects.
➢ When requirements are complex and unclear.
➢ When changes can occur at any time.
➢ Especially for large, high-budget projects.
Advantages:
➢ Thorough risk analysis.
➢ Suitable for large and mission-critical projects.
Disadvantages:
➢ Can be expensive.
➢ Requires specific expertise in risk analysis.
➢ Not ideal for smaller projects.

V-Model
The V-Model, short for Verification and Validation Model, is a structured
approach to software development. It follows a sequential path similar to the
waterfall model, but it emphasizes testing alongside development. Verification
checks if the development process meets requirements (static analysis), while
validation checks if the software functions properly (dynamic analysis).
In the V-Model, there are Verification phases (on one side) and Validation phases
(on the other), connected by the coding phase, forming a V shape.

DIPAK KUMAR SAHOO 13

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Verification Phases:
➢ Business Requirement Analysis: Understand customer needs.
➢ System Design: Analyze the proposed system based on user requirements.
➢ Architecture Design: Select architecture and perform integration testing.
➢ Module Design: Break the system into modules with detailed designs.
➢ Coding Phase: Develop the code, optimize it, and perform code reviews.
Validation Phases:
➢ Unit Testing: Test individual units or modules.
➢ Integration Testing: Verify communication between modules.
➢ System Testing: Ensure the system meets expectations.
➢ Acceptance Testing: Test the software in the user environment.
The V-Model is suitable when requirements are clear, and it works best for small
to medium-sized projects with well-defined requirements. It's a good choice when
you have technical experts available.
Advantages:
➢ Easy to understand.
➢ Testing is planned before coding, saving time.
➢ Less chance of defects.
➢ Ideal for small projects with clear requirements.

DIPAK KUMAR SAHOO 14

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Disadvantages:
➢ Very rigid and inflexible.
➢ Not suitable for complex projects.
➢ No early software prototypes.
➢ Changes require updating test and other documents.

RAD (Rapid Application Development)

RAD, or Rapid Application Development, is a software development approach
that focuses on quick, high-quality results. It involves gathering requirements
through workshops, creating prototypes for user testing, and reusing software
components. A set schedule ensures design improvements for the next version.
It's less formal and emphasizes team communication.
The various phases of RAD are as follows:
➢ Business Modelling: Define how information flows in the business, such
as data sources, processing, and users.
➢ Data Modelling: Refine collected data into entities and their attributes,
defining their relationships.
➢ Process Modelling: Transform data objects to enable business functions,
like adding or retrieving data.
➢ Application Generation: Use automated tools for software construction.
➢ Testing & Turnover: Test new components and ensure full interface
functionality.

DIPAK KUMAR SAHOO 15

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

When to use RAD Model:

➢ You need to create a project quickly (in 2-3 months).
➢ Your requirements are well-defined.
➢ Technical risks are low.
➢ Your budget allows for automatic code generation tools.
Advantages of RAD:
➢ Flexibility for change: This model allows for easy adjustments.
➢ Adaptability to changes: It can accommodate changing requirements.
➢ Rapid delivery: It focuses on delivering high-priority functions quickly.
➢ Reduced development time: It speeds up the development process.
➢ Increased reusability: Components can be reused in different projects.
Disadvantages of RAD:
➢ Skilled designers needed: It requires experienced designers.
➢ Not suitable for all apps: RAD may not work for all types of applications.
➢ Unsuitable for smaller projects: It's better for larger projects.
➢ High technical risk: It's not ideal for high-risk situations.
➢ Requires user involvement: Users need to be actively involved in the
process.

Agile Model
Agile, derived from the word "agility," represents a flexible approach to software
development. The Agile process model is about breaking a project into smaller
pieces, using iterations that don't require extensive long-term planning. It starts
with defining the project's scope and requirements. These iterations, lasting one
to four weeks each, involve planning, analyzing, designing, coding, and testing.
They aim to reduce risk and speed up project delivery.

DIPAK KUMAR SAHOO 16

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

The Agile model consists of several phases:

➢ Requirements gathering: This phase involves defining project
requirements, estimating the time and effort needed, and assessing
technical and economic feasibility.
➢ Designing the requirements: Collaborate with stakeholders to define
project requirements. Use tools like user flow diagrams or high-level UML
diagrams to plan new features and integrate them into the existing system.
➢ Construction/iteration: Once requirements are clear, designers and
developers start building the project. They aim to deliver a functional
product that undergoes multiple improvements, starting with basic
features.
➢ Testing: Quality Assurance examines the product's performance and
identifies any bugs.
➢ Deployment: The product is released into the user's work environment.
➢ Feedback: After product release, feedback is collected and used to make
necessary improvements.
Agile Testing Methods:
➢ Scrum: A method focused on managing tasks in team-based development.
It involves three key roles:
❖ Scrum Master: Leads the team, arranges meetings, and removes
obstacles.
❖ Product Owner: Manages the product backlog, prioritizes tasks, and
distributes functionality.
❖ Scrum Team: Organizes and manages work to complete the sprint or
cycle.
➢ eXtreme Programming (XP): Ideal for projects with changing
requirements or performance uncertainties.
➢ Crystal: Comprises three key concepts:
❖ Chartering: Involves forming the development team, feasibility
analysis, and planning.
❖ Cyclic delivery: Updates the release plan and delivers integrated
products.
❖ Wrap-up: Deploys and concludes the project based on the user
environment.
➢ Dynamic Software Development Method (DSDM): A rapid application
development strategy involving active user involvement and team
decision-making. Techniques include time boxing, MoSCoW rules, and
prototyping.

DIPAK KUMAR SAHOO 17

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ Feature Driven Development (FDD): Focuses on designing and building

features incrementally.
➢ Lean Software Development: Follows "just in time production"
principles to speed up software development and reduce costs. It involves
seven phases, including:
❖ Eliminating Waste
❖ Amplifying learning
❖ Defer commitment (deciding as late as possible)
❖ Early delivery
❖ Empowering the team
❖ Building Integrity
❖ Optimize the whole
When to use the Agile Model:
➢ When changes are needed often.
➢ When a skilled and experienced team is available.
➢ When the customer can engage with the software team regularly.
➢ For small-sized projects.
Advantages of Agile Method:
➢ Frequent product deliveries.
➢ Direct communication with clients.
➢ Efficient design that meets business requirements.
➢ Allows changes anytime.
➢ Reduces total development time.
Disadvantages of Agile Model:
➢ Lack of formal documents can lead to confusion and misinterpretation of
crucial decisions by different team members.
➢ Maintenance of completed projects can be challenging due to the lack of
proper documentation when developers move to other projects.

Big Bang Model

In this model, developers work without a set process. They start with resources
and effort but may not meet the customer's requirements since those are often
undefined. This approach suits small projects, like academic or practical ones,
where one or two developers can work together.

DIPAK KUMAR SAHOO 18

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

When to use Big Bang Model:

The Big Bang Model is used for small projects, such as academic or practical
ones, especially when the development team is small, requirements are uncertain,
and there's no fixed release date from the customer. It's a simple approach but
may not be suitable for larger, more complex projects.
Advantages:
➢ Doesn't need extensive planning.
➢ It's a simple and easy-to-understand model.
➢ Requires minimal resources.
➢ Easy for project management.
➢ Offers flexibility for developers to work.
Disadvantages:
➢ High risks and uncertainty due to unclear requirements.
➢ Not suitable for large or complex projects.
➢ Lack of clarity in requirements can lead to high expenses.

DIPAK KUMAR SAHOO 19

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Software Project Management

Software Project Management (SPM) is a proper way of planning and leading
software projects. It is a part of project management in which software projects
are planned, implemented, monitored, and controlled.
What is Need for Software Project Management?
Software development, a non-physical product, is a relatively new business
stream with limited experience. Most software is customized to meet client needs.
Frequent tech advancements hinder knowledge transfer. Business constraints
elevate project risks, necessitating efficient management. Organizations must
ensure quality, cost control, and timely delivery, making project management
vital for integrating user needs, budget, and time constraints.
Different Types of Management in SPM
➢ Conflict Management: Conflict management is the process to restrict the
negative features of conflict while increasing the positive features of
conflict. The goal of conflict management is to improve learning and group
results including efficacy or performance in an organizational setting.
Properly managed conflict can enhance group results.
➢ Risk Management: Risk management is the analysis and identification of
risks that is followed by synchronized and economical implementation of
resources to minimize, operate and control the possibility or effect of
unfortunate events or to maximize the realization of opportunities.
➢ Requirement Management: It is the process of analyzing, prioritizing,
tracking, and documenting requirements and then supervising change and
communicating to pertinent stakeholders. It is a continuous process during
a project.
➢ Change Management: Change management is a systematic approach to
dealing with the transition or transformation of an organization’s goals,
processes, or technologies. The purpose of change management is to
execute strategies for effecting change, controlling change, and helping
people to adapt to change.
➢ Software Configuration Management: Software configuration
management is the process of controlling and tracking changes in the
software, part of the larger cross-disciplinary field of configuration
management. Software configuration management includes revision
control and the inauguration of baselines.
➢ Release Management: Release Management is the task of planning,
controlling, and scheduling the build-in deploying releases. Release

DIPAK KUMAR SAHOO 20

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

management ensures that the organization delivers new and enhanced

services required by the customer while protecting the integrity of existing
services.
Aspects of Software Project Management
The list of focus areas it can tackle and the broad upsides of Software Project
Management is:
➢ Planning: The software project manager lays out the complete project’s
blueprint. The project plan will outline the scope, resources, timelines,
techniques, strategy, communication, testing, and maintenance steps. SPM
can aid greatly here.
➢ Leading: A software project manager brings together and leads a team of
engineers, strategists, programmers, designers, and data scientists. Leading
a team necessitates exceptional communication, interpersonal, and
leadership abilities. One can only hope to do this effectively if one sticks
with the core SPM principles.
➢ Execution: SPM comes to the rescue here also as the person in charge of
software projects (if well versed with SPM/Agile methodologies) will
ensure that each stage of the project is completed successfully. measuring
progress, monitoring to check how teams’ function, and generating status
reports are all part of this process.
➢ Time management: Abiding by a timeline is crucial to completing
deliverables successfully. This is especially difficult when managing
software projects because changes to the original project charter are
unavoidable over time. To assure progress in the face of blockages or
changes, software project managers ought to be specialists in managing
risk and emergency preparedness. This Risk Mitigation and management
is one of the core tenets of the philosophy of SPM.
➢ Budget: Software project managers, like conventional project managers,
are responsible for generating a project budget and adhering to it as closely
as feasible, regulating spending, and reassigning funds as needed. SPM
teaches us how to effectively manage the monetary aspect of projects to
avoid running into a financial crunch later on in the project.
➢ Maintenance: Software project management emphasizes continuous
product testing to find and repair defects early, tailor the end product to the
needs of the client, and keep the project on track. The software project
manager makes ensuring that the product is thoroughly tested, analyzed,
and adjusted as needed. Another point in favor of SPM.

DIPAK KUMAR SAHOO 21

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Downsides of Software Project Management

Numerous issues can develop if a Software project manager lacks the necessary
expertise or knowledge. Software Project management has several drawbacks,
including resource loss, scheduling difficulty, data protection concerns, and
interpersonal conflicts between Developers/Engineers/Stakeholders.
Furthermore, outsourcing work or recruiting additional personnel to complete the
project may result in hefty costs for one’s company.
➢ Costs Are High: Invest in project management tools, software, and
services for Software Project Management strategies. Implementation is
costly and time-consuming. Training and experts might be necessary.
Stakeholders often request additional features, increasing project expenses.
Consider these factors before budgeting for project management initiatives
to ensure successful software project delivery within financial constraints.
➢ Complexity Will Be Increased: Software project management is intricate,
with potential for overcomplication causing confusion and delays. Strong,
specific expressions can create a challenging work atmosphere. Larger
projects are more demanding, especially without a dedicated team. Cross-
functional team members may struggle, increasing project complexity and
hindering progress.

DIPAK KUMAR SAHOO 22

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ Overhead In Communication: When hiring software project

management staff, new recruits join your organization, potentially
impacting company culture. Keep the team small to minimize
communication challenges. Large teams can lead to excessive
communication overhead. For sizable projects, prioritize software project
managers skilled in effective communication with diverse stakeholders.
➢ Lack Of Originality: Software project managers sometimes limit creative
freedom, prioritizing processes or tight deadlines. This can hinder
innovative thinking. Balancing creativity and project planning is essential.
While a team may develop code faster without dedicated personnel,
specialists can enhance innovation and expedite goal achievement in
Software Project Management.

Project Planning
Once a project is found to be possible, computer code project managers undertake
project designing. Project designing is undertaken and completed even before any
development activity starts. Project designing consists of subsequent essential
activities:
Estimating the subsequent attributes of the project:
➢ Project size:
What’s going to be downside quality in terms of the trouble and time
needed to develop the product?
➢ Cost:
What proportion is it reaching to value to develop the project?
➢ Duration:
However long is it reaching to want complete development?
➢ Effort:
What proportion effort would be required?
The effectiveness of the following designing activities relies on the accuracy of
those estimations.
➢ Planning force and alternative resources
➢ Workers organization and staffing plans
➢ Risk identification, analysis, and abatement designing
➢ Miscellaneous arranges like quality assurance plan, configuration,
management arrange, etc.

DIPAK KUMAR SAHOO 23

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Precedence Ordering Among Project Planning Activities:

The different project connected estimates done by a project manager have already
been mentioned. The below diagram shows the order during which vital project
coming up with activities is also undertaken. It may be simply discovered that
size estimation is that the 1st activity. It’s conjointly the foremost basic parameter
supported that all alternative coming up with activities square measure dispensed,
alternative estimations like the estimation of effort, cost, resource, and project
length also are vital elements of the project coming up with.

Sliding Window Planning:

Effective project planning is essential to prevent schedule delays, which can lead
to client dissatisfaction, team morale issues, and even project failure. However,
project planning can be complex, especially for large projects, as parameters like
scope and resources may change. To address this, some project managers adopt
a phased approach, known as window planning. Starting with an initial plan, they
refine it in sequential stages as their knowledge and project details improve over
time. This iterative process allows for more accurate and confident planning,
minimizing the risk of unrealistic commitments and enhancing project success.

Metrics For Project Size Estimation such as LOC and FP

Project size estimation is a crucial aspect of software engineering, as it helps in
planning and allocating resources for the project. Here are some of the popular
project size estimation techniques used in software engineering:

DIPAK KUMAR SAHOO 24

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ Expert Judgment: In this technique, a group of experts in the relevant

field estimates the project size based on their experience and expertise.
This technique is often used when there is limited information available
about the project.
➢ Analogous Estimation: This technique involves estimating the project
size based on the similarities between the current project and previously
completed projects. This technique is useful when historical data is
available for similar projects.
➢ Bottom-up Estimation: In this technique, the project is divided into
smaller modules or tasks, and each task is estimated separately. The
estimates are then aggregated to arrive at the overall project estimate.
➢ Three-point Estimation: This technique involves estimating the project
size using three values: optimistic, pessimistic, and most likely. These
values are then used to calculate the expected project size using a formula
such as the PERT formula.
➢ Function Points: This technique involves estimating the project size based
on the functionality provided by the software. Function points consider
factors such as inputs, outputs, inquiries, and files to arrive at the project
size estimate.
➢ Use Case Points: This technique involves estimating the project size based
on the number of use cases that the software must support. Use case points
consider factors such as the complexity of each use case, the number of
actors involved, and the number of use cases.
Each of these techniques has its strengths and weaknesses, and the choice of
technique depends on various factors such as the project’s complexity, available
data, and the expertise of the team.
Estimation of the size of the software is an essential part of Software Project
Management. It helps the project manager to further predict the effort and time
which will be needed to build the project. Various measures are used in project
size estimation. Some of these are:
➢ Lines of Code
➢ Number of entities in ER diagram
➢ Total number of processes in detailed data flow diagram
➢ Function points
Lines of Code (LOC): As the name suggests, LOC counts the total number
of lines of source code in a project. The units of LOC are:
➢ KLOC- Thousand lines of code

DIPAK KUMAR SAHOO 25

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ NLOC- Non-comment lines of code

➢ KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of the same kind.
The experts use it to predict the required size of various components of software
and then add them to get the total size.
It’s tough to estimate LOC by analyzing the problem definition. Only after the
whole code has been developed can accurate LOC be estimated. This statistic is
of little utility to project managers because project planning must be completed
before development activity can begin.
Two separate source files having a similar number of lines may not require the
same effort. A file with complicated logic would take longer to create than one
with simple logic. Proper estimation may not be attainable based on LOC.
The length of time it takes to solve an issue is measured in LOC. This statistic
will differ greatly from one programmer to the next. A seasoned programmer can
write the same logic in fewer lines than a newbie coder.
Advantages:
➢ Universally accepted and is used in many models like COCOMO.
➢ Estimation is closer to the developer’s perspective.
➢ Both people throughout the world utilize and accept it.
➢ At project completion, LOC is easily quantified.
➢ It has a specific connection to the result.
➢ Simple to use.
Disadvantages:
➢ Different programming languages contain a different number of lines.
➢ No proper industry standard exists for this technique.
➢ It is difficult to estimate the size using this technique in the early stages of
the project.
➢ When platforms and languages are different, LOC cannot be used to
normalize.
Number of entities in ER diagram: ER model provides a static view of
the project. It describes the entities and their relationships. The number of entities
in ER model can be used to measure the estimation of the size of the project. The
number of entities depends on the size of the project. This is because more entities
needed more classes/structures thus leading to more coding.
Advantages:

DIPAK KUMAR SAHOO 26

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ Size estimation can be done during the initial stages of planning.

➢ The number of entities is independent of the programming technologies
used.
Disadvantages:
➢ No fixed standards exist. Some entities contribute more to project size than
others.
➢ Just like FPA, it is less used in the cost estimation model. Hence, it must
be converted to LOC.
Total Number of Processes in Detailed Data Flow Diagram: Data
Flow Diagram (DFD) represents the functional view of software. The model
depicts the main processes/functions involved in software and the flow of data
between them. Utilization of the number of functions in DFD to predict software
size. Already existing processes of similar type are studied and used to estimate
the size of the process. Sum of the estimated size of each process gives the final
estimated size.
Advantages:
➢ It is independent of the programming language.
➢ Each major process can be decomposed into smaller processes. This will
increase the accuracy of the estimation
Disadvantages:
➢ Studying similar kinds of processes to estimate size takes additional time
and effort.
➢ All software projects are not required for the construction of DFD.
Function Point Analysis: In this method, the number and type of functions
supported by the software are utilized to find FPC (function point count). The
steps in function point analysis are:
➢ Count the number of functions of each proposed type.
➢ Compute the Unadjusted Function Points (UFP).
➢ Find the Total Degree of Influence (TDI).
➢ Compute Value Adjustment Factor (VAF).
➢ Find the Function Point Count (FPC).
The explanation of the above points is given below:
Count The Number of Functions of Each Proposed Type: Find the number of
functions belonging to the following types:

DIPAK KUMAR SAHOO 27

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ External Inputs: Functions related to data entering the system.

➢ External Outputs: Functions related to data exiting the system.
➢ External Inquiries: They lead to data retrieval from the system but don’t
change the system.
➢ Internal Files: Logical files maintained within the system. Log files are
not included here.
➢ External Interface Files: These are logical files for other applications
which are used by our system.
Compute the Unadjusted Function Points (UFP): Categorise each of the five
function types like simple, average, or complex based on their complexity.
Multiply the count of each function type with its weighting factor and find the
weighted sum. The weighting factors for each type based on their complexity are
as follows:
Function Type Simple Average Complex
External Inputs 3 4 6
External Output 4 5 7
External Inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface 5 7 10
Files
Find Total Degree of Influence: Use the ’14 general characteristics’ of a
system to find the degree of influence of each of them. The sum of all 14 degrees
of influence will give the TDI. The range of TDI is 0 to 70. The 14 general
characteristics are: Data Communications, Distributed Data Processing,
Performance, Heavily Used Configuration, Transaction Rate, On-Line Data
Entry, End-user Efficiency, Online Update, Complex Processing Reusability,
Installation Ease, Operational Ease, Multiple Sites and Facilitate Change.
Each of the above characteristics is evaluated on a scale of 0-5.
Compute Value Adjustment Factor (VAF): Use the following formula
to calculate VAF
VAF = (TDI * 0.01) + 0.65
Find the Function Point Count: Use the following formula to calculate
FPC
FPC = UFP * VAF
Advantages:

DIPAK KUMAR SAHOO 28

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ It can be easily used in the early stages of project planning.

➢ It is independent of the programming language.
➢ It can be used to compare different projects even if they use different
technologies (database, language, etc).
Disadvantages:
➢ It is not good for real-time systems and embedded systems.
➢ Many cost estimation models like COCOMO use LOC and hence FPC
must be converted to LOC.

COCOMO Model
COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e
number of Lines of Code. It is a procedural cost estimate model for software
projects and is often used as a process of reliably predicting the various
parameters associated with making a project such as size, effort, cost, time, and
quality. It was proposed by Barry Boehm in 1981 and is based on the study of 63
projects, which makes it one of the best-documented models.
The key parameters which define the quality of any software products, which are
also an outcome of the COCOMO are primarily Effort & Schedule:
• Effort: Amount of labor that will be required to complete a task. It is
measured in person-months units.
• Schedule: Simply means the amount of time required for the completion
of the job, which is, of course, proportional to the effort put in. It is
measured in the units of time such as weeks, and months.
Different models of COCOMO have been proposed to predict the cost estimation
at different levels, based on the amount of accuracy and correctness required. All
of these models can be applied to a variety of projects, whose characteristics
determine the value of the constant to be used in subsequent calculations.
These characteristics pertaining to different system types are mentioned below.
Boehm’s definition of organic, semidetached, and embedded systems:
➢ Organic – A software project is said to be an organic type if the team size
required is adequately small, the problem is well understood and has been
solved in the past and also the team members have a nominal experience
regarding the problem.
➢ Semi-Detached – A software project is said to be a Semi-detached type if
the vital characteristics such as team size, experience, and knowledge of
the various programming environment lie in between that of organic and

DIPAK KUMAR SAHOO 29

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Embedded. The projects classified as Semi-Detached are comparatively

less familiar and difficult to develop compared to the organic ones and
require more experience and better guidance and creativity. Eg: Compilers
or different Embedded Systems can be considered Semi-Detached types.
➢ Embedded – A software project requiring the highest level of complexity,
creativity, and experience requirement fall under this category. Such
software requires a larger team size than the other two models and also the
developers need to be sufficiently experienced and creative to develop such
complex models.
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
Basic Model –
E= a(KLOC)b
time= c(Effort)d
Person required = Effort/ time
The above formula is used for the cost estimation of for the basic COCOMO
model, and also is used in the subsequent models. The constant values a,b,c, and
d for the Basic Model for the different categories of the system:
Software Projects a b c d
Organic 2.4 1.05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
The effort is measured in Person-Months and as evident from the formula is
dependent on Kilo-Lines of code. The development time is measured in months.
These formulas are used as such in the Basic Model calculations, as not much
consideration of different factors such as reliability, and expertise is taken into
account, henceforth the estimate is rough.
Intermediate Model – The basic COCOMO model assumes that the effort is
only a function of the number of lines of code and some constants evaluated
according to the different software systems. However, in reality, no system’s
effort and schedule can be solely calculated on the basis of Lines of Code. For
that, various other factors such as reliability, experience, and Capability. These
factors are known as Cost Drivers and the Intermediate Model utilizes 15 such
drivers for cost estimation. Classification of Cost Drivers and their Attributes:
Product Attributes –

DIPAK KUMAR SAHOO 30

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

➢ Required software reliability extent

➢ Size of the application database
➢ The complexity of the product
➢ Run-time performance constraints
➢ Memory constraints
➢ The volatility of the virtual machine environment
➢ Required turnabout time
➢ Analyst capability
➢ Software engineering capability
➢ Applications experience
➢ Virtual machine experience
➢ Programming language experience
➢ Use of software tools
➢ Application of software engineering methods
➢ Required development schedule
Detailed Model – Detailed COCOMO incorporates all characteristics of the
intermediate version with an assessment of the cost driver’s impact on each step
of the software engineering process. The detailed model uses different effort
multipliers for each cost driver attribute. In detailed COCOMO, the whole
software is divided into different modules and then we apply COCOMO in
different modules to estimate effort and then sum the effort. The Six phases of
detailed COCOMO are:
➢ Planning and requirements
➢ System design
➢ Detailed design
➢ Module code and test
➢ Integration and test
➢ Cost Constructive model
Advantages of the COCOMO model:
➢ Provides a systematic way to estimate the cost and effort of a software
project.
➢ Can be used to estimate the cost and effort of a software project at different
stages of the development process.
➢ Helps in identifying the factors that have the greatest impact on the cost
and effort of a software project.
➢ Can be used to evaluate the feasibility of a software project by estimating
the cost and effort required to complete it.

DIPAK KUMAR SAHOO 31

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

Disadvantages of the COCOMO model:

➢ Assumes that the size of the software is the main factor that determines the
cost and effort of a software project, which may not always be the case.
➢ Does not take into account the specific characteristics of the development
team, which can have a significant impact on the cost and effort of a
software project.
➢ Does not provide a precise estimate of the cost and effort of a software
project, as it is based on assumptions and averages.

Halstead’s Software Science

Halstead’s complexity measurement was developed to measure a program
module’s complexity directly from source code, with emphasis on computational
complexity.
The Halstead’s measures are based on four scalar number derived directly from
a program’s source code:
➢ n1 is number of distinct operators.
➢ n2 is number of distinct operands.
➢ N1 is total number of distinct operators.
➢ N2 is total number of distinct operands.
From these numbers, five measures are derived:
Measure Symbol Formula
Program length N N = N1 + N2
Program vocabulary N n = n1 + n2
Volume V V = N * (log2 n)
Difficulty D D = (n1 / 2) * (N2 / 2)
Effort E E=D*V

Halstead’s uses certain measures such as program length, program vocabulary,

volume, difficulty, and effort for the given algorithm. By this Halstead’s is trying
to show that the program length can be calculated, volume of algorithm can be
estimated. The above given table shows how actually this measure can be
obtained.
The Halstead’s measures are applicable to operational system and to development
efforts once the code has been written. Thus, using Halstead’s measurement
experimental verification can be performed in software science.
Program Length:

DIPAK KUMAR SAHOO 32

 SOFTWARE DEVELOPMENT LIFE CYCLE AND PROJECT MANAGEMENT

The length of a program is total usage of operators and operands in the program.
Length (N) = N1 + N2
Program Vocabulary:
The Program vocabulary is the number of unique operators and operands used in
the program.
Vocabulary (n) = n1 + n2
Program Volume:
The Program Volume can be defined as minimum number of bits needed to
encode the program.
Volume (V) = N log2 n
Length Estimation:
N = n1 log2 n1 + n2 log2 n2
Guideline For Calculating Operands and Operators:
➢ All the variables and constants are considered as operands.
➢ Local variables with same name, if occurring in different functions are
counted as unique operand.
➢ Function calls are considered as operators.
➢ The looping statements, do … while, while, for, are operators. The
statements if, if … else, are operators. The switch … case statements are
considered as operators.
➢ The reserve worlds, returns, default, continue, break, sizeof are all
operators.
➢ The brackets, commas, semicolons, are operators.
➢ The unary and binary operators are considered as operators. The & is
considered as operator.
➢ In arrays, array name and index are considered as operands and [ ] is
considered as
➢ operator.
➢ All hash directives can be ignored.
➢ Comments are not considered.
➢ In Goto statement, goto is considered as operator and label as operand.

DIPAK KUMAR SAHOO 33