SDLC

SOFTWARE DEVELOPMENT LIFE CYCLE

Presented by – Supriya Satapathy

Agenda:
• What is Software Engineering?
• Introduction of SDLC
• SDLC Phases
• SDLC Models
What is Software Engineering?
• The term software engineering is composed of two words, software and engineering.

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

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

• So, we can define software engineering as an engineering branch associated with the
development of software product using well-defined scientific principles, methods and
procedures. The outcome of software engineering is an efficient and reliable software
product.
Introduction to SDLC:
LIFE CYCLE MODEL:
• A software life cycle model (also called process model) is a descriptive and diagrammatic
representation of the software life cycle. A life cycle model represents all the activities
required to make a software product transit through its life cycle phases.

• It also captures the order in which these activities are to be undertaken. In other words, a
life cycle model maps the different 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.
SDLC phases :
SDLC Phases:
1. Planning and Requirement Analysis
2. Requirement Analysis
3. Designing the Software
4. Building or Developing the Software
5. Testing the Software
6. Deployment or Maintenance
1. Planning and Requirement Analysis (Feasibility study)

• Main aim of feasibility study: determine whether developing the product

– financially worthwhile
– technically feasible.
• First roughly understand what the customer wants:
– different data which would be input to the system,
– processing needed on these data,
– output data to be produced by the system,
– various constraints on the behavior of the system.
• Work out an overall understanding of the problem.
• Formulate different solution strategies.
• Examine alternate solution strategies in terms of:
• resources required,
• cost of development, and
• development time.
2. Requirements Analysis and Specification:

• Aim of this phase:

– understand the exact requirements of the customer,
– document them properly.
• Consists of two distinct activities:
– requirements gathering and analysis
– requirements specification.

• Collect all related data from the customer:

– analyze the collected data to clearly understand what the customer wants,
– find out any inconsistencies and incompleteness in the requirements,
– resolve all inconsistencies and incompleteness.
• Gathering relevant data:
– usually collected from the end-users through interviews and discussions.
– For example, for a business accounting software: interview all the accountants of the
organization to find out their requirements.
• The data you initially collect from the users:
– would usually contain several contradictions and ambiguities:
– each user typically has only a partial and incomplete view of the system.
• Ambiguities and contradictions:
– must be identified
– resolved by discussions with the customers.
• Next, requirements are organized:
– into a Software Requirements Specification (SRS) document.
3. Designing the Software:

• Design phase transforms requirements specification:

– into a form suitable for implementation in some programming language.
• In technical terms:
– during design phase, software architecture is derived from the SRS document.
• Two design approaches:
– traditional approach,
– object oriented approach.
4. Coding and implementation:

• Purpose of implementation phase (coding and unit testing phase):

– translate software design into source code.
• During the implementation phase:
– each module of the design is coded,
– each module is unit tested
• tested independently as a stand alone unit, and debugged,
– each module is documented.
• The purpose of unit testing:
– test if individual modules work correctly.
• The end product of implementation phase:
– a set of program modules that have been tested individually.
[Link] the Software:

• After all the modules have been successfully integrated and tested:
– system testing is carried out.
• Goal of system testing:
– ensure that the developed system functions according to its requirements
as specified in the SRS document.
• Different modules are integrated in a planned manner:
– modules are almost never integrated in one shot.
– Normally integration is carried out through a number of steps.
• During each integration step,
– the partially integrated system is tested.
6. Maintence:
• Maintenance of any software product:
– requires much more effort than the effort to develop the product itself.
– development effort to maintenance effort is typically 40:60.
• Corrective maintenance:
– Correct errors which were not discovered during the product development phases.
• Perfective maintenance:
– Improve implementation of the system
– enhance functionalities of the system.
• Adaptive maintenance:
– Port software to a new environment,
• e.g. to a new computer or to a new operating system.
SDLC Models:
• Waterfall Model

• Iterative Model

• Agile Model

• Incremental Process Models

• The RAD Model

• Prototyping Model

• V- Model

• Spiral Model

• Agile and Scrum Model

• COCOMO Model
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
cannot 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.
Classical waterfall model divides the
life cycle into the following phases as
shown in fig
Iterative Waterfall Model:
• To overcome the major
shortcomings of the classical
waterfall model, we come up with
the iterative waterfall model.
• Here, we provide feedback paths
for error correction as & when
detected later in a phase. Though
errors are inevitable, but it is
desirable to detect them in the
same phase in which they occur.
If so, this can reduce the effort to
correct the bug.
• Errors should be detected
• in the same phase in which they are introduced.
• For example:
• if a design problem is detected in the design phase itself,
• the problem can be taken care of much more easily
• than say if it is identified at the end of the integration and system testing phase.
• Reason: rework must be carried out not only to the design but also to code and test phases.
• The principle of detecting errors as close to its point of introduction as possible:
– is known as phase containment of errors.
• Iterative waterfall model is by far the most widely used model.
– Almost every other model is derived from the waterfall model.
• Irrespective of the life cycle model actually followed:
– the documents should reflect a classical waterfall model of development,

– comprehension of the documents is facilitated.

 Prototyping Model:

• A prototype is a toy implementation of

the system.
• Before starting actual development,
– a working prototype of the system should
first be built.
• A prototype is a toy implementation of a
system:
– limited functional capabilities,
– low reliability,
– inefficient performance.
 Reasons for developing a prototype:
• Illustrate to the customer:
– input data formats, messages, reports, or interactive dialogs.

• Examine technical issues associated with product development:

– Often major design decisions depend on issues like:
• response time of a hardware controller,
• efficiency of a sorting algorithm, etc.
• The third reason for developing a prototype is:
– it is impossible to ``get it right'' the first time,
– we must plan to throw away the first product
• if we want to develop a good product.
• Start with approximate requirements.
• Carry out a quick design.
• Prototype model is built using several short-cuts:
– Short-cuts might involve using inefficient, inaccurate, or dummy functions.
• A function may use a table look-up rather than performing the actual computations.
• The developed prototype is submitted to the customer for his evaluation:
– Based on the user feedback, requirements are refined.
– This cycle continues until the user approves the prototype.
• The actual system is developed using the classical waterfall approach.
• Requirements analysis and specification phase becomes redundant:
– final working prototype (with all user feedbacks incorporated) serves as
an animated requirements specification.
• Design and code for the prototype is usually thrown away:
• However, the experience gathered from developing the prototype helps
a great deal while developing the actual product.
• Even though construction of a working prototype model involves
additional cost --- overall development cost might be lower for:
– systems with unclear user requirements,
– systems with unresolved technical issues.
• Many user requirements get properly defined and technical issues get
resolved:
– these would have appeared later as change requests and resulted in
incurring massive redesign costs.
 Advantages: Disadvantages:
• Reduce the risk of incorrect user requirement • An unstable/badly implemented prototype
often becomes the final product.
• Good where requirement are
changing/uncommitted
• Require extensive customer collaboration
• Regular v isible process aids management – Costs customer money
– Needs committed customer
• Support early product marketing
– Difficult to finish if customer withdraw. May
• Reduce Maintenance cost. be too customer specific

• Errors can be detected much earlier as the system is • Difficult to know how long the project will last.
made side by side.
• Easy to fall back into the code and fix without
proper requirement analysis, design, customer
evaluation, and feedback.

• Prototyping tools are expensive.

• Special tools & techniques are required to build

a prototype.

• It is a time-consuming process.
 Incremental Model:
• Incremental Model is a process of software
development where requirements divided
into multiple standalone modules of the
software development cycle.
• In this model, each module goes through
the requirements, design, implementation
and testing phases.
• Every subsequent release of the module
adds function to the previous release. The
process continues until the complete
system achieved.
When we use the Incremental Model?

• When the requirements are superior.

• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product, You can
develop prioritized requirements first.
 Advantages Disadvantages
• Errors are easy to be recognized. • Need for good planning
• Easier to test and debug • Total Cost is high.
• More flexible. • Well defined module interfaces
are needed.
• Simple to manage risk because it
handled during its iteration.
• The Client gets important
functionality early.
 Evolutionary Model:
• Evolutionary model is a combination of
Iterative and incremental model of
software.
• Incremental model first implemented a
few basic features and delivered to the
customer. Then build the next part and
deliver it again and repeat this step until
the desired system is fully completed.
• In Evolutionary model, the software
requirement is first broken down into
several modules.
• Such models are applied because the
requirements often change. So, the end
product will be unrealistic, for a complete
version is impossible due to tight market
deadlines.
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.
Necessary Conditions for Implementing this Model
• Customer needs are clear and been explained in deep to the developer
team.
• There might be small changes required in separate parts but not a major
change.
• As it requires time, so there must be some time left for the market constraints.
Risk is high and continuous targets to achieve and report to customer
repeatedly.
• It is used when working on a technology is new and requires time to learn.
 Advantages: Disadvantages:

• Management complexity is more.

• Risk analysis is better.
• Not suitable for smaller projects.
• It supports changing environment.
• Can be costly to use.
• Initial operating time is less.
• Highly skilled resources are
• Better suited for large mission- required for risk analysis.
critical projects.
• During the life cycle software is
produced early which facilitates
customer evaluation and
feedback.
 Spiral Model:
• Each loop of the spiral represents a phase of the
software process:
– the innermost loop might be concerned with
system feasibility,
– the next loop with system requirements definition,
– the next one with system design, and so on.
• There are no fixed phases in this model, the phases
shown in the figure are just examples.
• The team must decide:
– how to structure the project into phases.
• Start work using some generic model:
– add extra phases
• for specific projects or when problems are
identified during a project.
• Each loop in the spiral is split into four sectors
(quadrants).
 Objective Setting:
• First Quadrant:
• Identify objectives of the phase,
• Examine the risks associated with these objectives.
– Risk:
• any adverse circumstance that might hamper successful completion of a

software project .
• Find alternate solutions possible.
• Second Quadrant:
• For each identified project risk,
– a detailed analysis is carried out.
• Steps are taken to reduce the risk.
• For example, if there is a risk that the requirements are inappropriate:
– a prototype system may be developed.
• Third quadrant:
– develop (prototype) and validate the next level of the product.

• Fourth quadrant:
– review the results achieved so far with the customer and plan the next iteration
around the spiral.
• With each iteration around the spiral:
– progressively more complete version of the software gets built.

Spiral Model as a meta model:

• Subsumes all discussed models:
– a single loop spiral represents waterfall model.
– uses an evolutionary approach --
• iterations through the spiral are evolutionary levels.
– enables understanding and reacting to risks during each iteration along the spiral.
– uses:
• prototyping as a risk reduction mechanism
• retains the step-wise approach of the waterfall model.
When to use Spiral Model?

• When deliverance is required to be frequent.

• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
 Advantages Disadvantages

• High amount of risk analysis • Can be a costly model to use.

• Useful for large and mission-critical • Risk analysis needed highly
projects. particular expertise.
• Customers can see the • Doesn't work well for smaller
development of the product at the
early phase of the software projects.
development
• As the number of phases is
• The Spiral Model provides for unknown at the start of the project,
regular evaluations and reviews, time estimation is very difficult.
which can improve communication
between the customer and the • The Spiral Model can be complex,
development team.
as it involves multiple iterations of
• The Spiral Model allows for multiple the software development process.
iterations of the software
development process, which can
result in improved software quality
and reliability.
 The RAD Model (Rapid Application Development):
• RAD is an adaptive software development
model based on prototyping and quick
feedback with less emphasis on specific
planning.
• The RAD approach prioritizes development
and building a prototype, rather than
planning.
• RAD involves parallel development.
• RAD model phases:

Communication phase (requirement

gathering)
Planning phase
Modeling phase
Construction phase
Deployment phase
Details of RAD model:
• Time: Rapid application development is incremental software
development process model that allows usable systems to be built in as
little as 60-90 days. The RAD model used for information systems
development.
• Model Phases( five phases): Business modeling • Data modeling • Process
modeling • Application generation • Testing and turnover.
• Business Modeling: The information flow among business functions is
defined by answering questions like what information drives the business
process, what information is generated, who generates it, where does the
information go, who process it and so on. It involves user role and specify
the data requirement(product data , customer data., etc..).
• Data Modeling: Create backend and database schema. The information
collected from business modeling is refined into a set of data objects
(entities) that are needed to support the business. The attributes (character
of each entity) are identified and the relation between these data objects
(entities) is defined.
• Process Modeling: The data object defined in the data modeling phase
are transformed to achieve the information flow necessary to implement a
business function. Processing descriptions are created for adding,
modifying, deleting or retrieving a data object.
• Application Generation: Automated tools are used to facilitate
construction of the software.
• Testing and Turn over: Many of the programming components have
already been tested since RAD emphasis reuse. • This reduces overall
testing time. But new components must be tested and all interfaces must
be fully exercised.
• Development model based on RAD: Agile software development • Joint
Application Development (JAD) • Scrum • Extreme Programming (XP)
When to use RAD Model?
• When the system should need to create the project that modularizes in a
short span time (2-3 months).
• When the requirements are well-known.
• When the technical risk is limited.
• When there's a necessity to make a system, which modularized in 2-3
months of period.
• It should be used only if the budget allows the use of automatic code
generating tools.
 Advantages Disadvantages

• This model is flexible for change. • It required highly skilled designers.

• In this model, changes are • All application is not compatible
adoptable. with RAD.
• Each phase in RAD brings highest • For smaller projects, we cannot
priority functionality to the use the RAD model.
customer.
• On the high technical risk, it's not
• It reduced development time. suitable.
• It increases the reusability of • Required user involvement.
features.
 V- Model:
• The V-model is named after its shape,
which resembles the letter “V.” In the V-
model, we divide the software
development life cycle into phases and
each phase is associated with a
corresponding testing phase. The left-
hand side of the V represents the
verification phase while the right-hand
side represents the validation phase.
• The development of each step is directly
associated with the testing phase. The
next phase starts only after completion of
the previous phase i.e., for each
development activity, there is a testing
activity corresponding to it.
 V-Model Verification Phases:
• The verification phase refers to the practice of evaluating the product
development process to ensure the team meets the specified requirements.
• The verification phase includes several steps:
• In the requirement analysis step, the team comes to understand the product
requirements as laid out by the customer.
• In the system analysis step, the system engineers analyze and interpret the business
requirements of the proposed system by studying the user requirements document.
• In the software architecture design stage, the team selects the software architecture
based on the list of modules, the brief functionality of each module, the interface
relationships, dependencies, database tables, architecture diagrams, technology
detail and more. The integration testing model is developed in this phase.
• In the module design stage, the development team breaks down the system into
small modules and specifies the detailed design of each module, which we call low-
level design.
• Then, we begin coding. The development team selects a suitable programming
language based on the design and product requirements.
 V-Model Validation Phases:
• The validation phase involves dynamic analysis methods and testing to ensure the
software product meets the customer’s requirements and expectations. This phase
includes several stages includes:
• During the unit testing stage, the team develops and executes unit test plans to identify
errors at the code or unit level. This testing happens on the smallest entities, such as
program modules, to ensure they function correctly when isolated from the rest of the
code.
• The integration testing stage involves executing integration test plans developed during
the architectural design step in order to verify that groups created and tested
independently can coexist and communicate with each other.
• The system testing stage involves executing system test plans developed during the
system design step, which are composed by the client’s business team. System testing
ensures the team meets the application developer’s expectations.
• The acceptance testing step is related to the business requirement analysis part of the
V-model and involves testing the software product in the user environment to identify
compatibility issues with the different systems available within the user environment.
Acceptance testing also identifies non-functional issues like load and performance
defects in the real user environment.
 Principles of V-Model:
• The V-model emphasizes the importance of testing and quality assurance
throughout the entire development process.
• INTEGRATE TESTING THROUGHOUT DEVELOPMENT
Testing is not just an activity that happens at the end of the development process.
Instead, testing is integrated into every stage of the development lifecycle, from
requirements gathering to deployment.
• PLAN TESTING IN PARALLEL WITH DEVELOPMENT
Each stage of the development process has a corresponding testing phase. Testing
activities are planned in parallel with development activities so that the necessary
resources are available to support testing.
• PREVENT DEFECTS
The V-model emphasizes the importance of preventing defects rather than simply
identifying and fixing them after they’ve been discovered.
 • COMBINE DEVELOPMENT AND TESTING
In the V-model, development and testing are not separate activities. Instead,
they are closely integrated and collaboration between developers and testers
is critical for ensuring that the software meets the required quality standards.
When to use?
•Where requirements are clearly defined and fixed.
•The V-Model is used when ample technical resources are available with technical expertise.
•Small to medium-sized projects with set and clearly specified needs are recommended to use
the V-shaped model.
•Since it is challenging to keep stable needs in large projects, the project should be small.
 Advantages: Disadvantages:
• High risk and uncertainty.
• This is a highly disciplined model • It is not a good for complex and
and Phases are completed one at object-oriented projects.
a time.
• It is not suitable for projects where
• V-Model is used for small projects requirements are not clear and
where project requirements are contains high risk of changing.
clear.
• This model does not support iteration
• Simple and easy to understand and of phases.
use.
• It does not easily handle concurrent
• This model focuses on verification events.
and validation activities early in the • Inflexibility: The V-Model is a linear
life cycle thereby enhancing the and sequential model, which can
probability of building an error-free make it difficult to adapt to
and good quality product. changing requirements or
unexpected events.
• It enables project management to
track progress accurately. • Time-Consuming: The V-Model can
be time-consuming, as it requires a
lot of documentation and testing.
 Agile Model(swift or versatile):
• The Agile Model is an iterative and incremental
approach to software development that is designed
to be flexible, adaptive, and customer-focused. The
Agile Model emphasizes collaboration, continuous
improvement, and rapid prototyping to deliver high-
quality software products.

• The Agile Model values individuals and interactions,

working software, customer collaboration, and
responding to change, making it a highly effective
and efficient method for software development.

• Agile methods break tasks into smaller iterations, or

parts do not directly involve long term planning. The
project scope and requirements are laid down at
the beginning of the development process.
• Each iteration is considered as a short time "frame" in the Agile process model,
which typically lasts from one to four weeks. The division of the entire project into
smaller parts helps to minimize the project risk and to reduce the overall project
delivery time requirements. Each iteration involves a team working through a full
software development life cycle including planning, requirements analysis,
design, coding, and testing before a working product is demonstrated to the
client.
• Following are the phases in the Agile model are as follows:

i. Requirements gathering
ii. Design the requirements
iii. Construction/ iteration
iv. Testing/ Quality assurance
v. Deployment
vi. Feedback
• SDLC Agile Model Phases
• Below are the Phases of the Agile Model in Software Engineering and a
detailed explanation of what each phase involves.
i. Requirements gathering (Plan): In this phase, the team works closely with
the customer to identify the product requirements.
ii. Design the requirements: The team designs a solution that meets the
customer’s needs.
iii. Develop/ iteration: The team creates the product in small iterations or
sprints.
iv. Testing: This phase checks the product’s quality and ensures that it
meets the requirements.
v. Deployment: The product is released to the customer in this phase.
vi. Review: The team evaluates the product’s performance and
incorporates feedback from the customer to improve the product in this
final phase.
When to use the Agile Model?
• When frequent changes are required.
• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with a software team all the
time.
• When project size is small.
• When new changes are needed to be implemented. The freedom agile gives
to change is very important. New changes can be implemented at very little
cost because of the frequency of new increments that are produced.
• To implement a new feature the developers need to lose only the work of a
few days, or even only hours, to roll back and implement it.
• Unlike the waterfall model in agile model very limited planning is required to
get started with the project. Agile assumes that the end users’ needs are ever
changing in a dynamic business and IT world. Changes can be discussed and
features can be newly effected or removed based on feedback. This
effectively gives the customer the finished system they want or need.
 Advantages: Disadvantages:

• Frequent Delivery • Due to the shortage of formal

documents, it creates confusion
• Face-to-Face Communication and crucial decisions taken
with clients. throughout various phases can be
misinterpreted at any time by
• Efficient design and fulfils the different team members.
business requirement.
• Due to the lack of proper
• Anytime changes are documentation, once the project
acceptable. completes and the developers
allotted to another project,
• It reduces total development
maintenance of the finished
time.
project can become a difficulty.
 Scrum Model:
• Scrum is an agile framework for developing, delivering, and sustaining complex
products, with an initial emphasis on software development, although it has been
used in other fields including research, sales, marketing and advanced
technologies. It is designed for teams of ten or fewer members, who break their work
into goals that can be completed within time-boxed iterations, called sprints, no
longer than one month and most commonly two weeks. The Scrum Team track
progress in 15-minute time-boxed daily meetings, called daily scrums. At the end of
the sprint, the team holds sprint review, to demonstrate the work done, and sprint
retrospective to improve continuously.
• Scrum is a lightweight, iterative and incremental framework for managing complex
work. The framework challenges assumptions of the traditional, sequential approach
to product development, and enables teams to self-organize by encouraging
physical co-location close online collaboration of all team members, as well as daily
face-to-face communication among all team members and disciplines involved.
• A key principle of Scrum is the dual recognition that customers will change their
minds about what they want or need (often called requirements volatility) and that
there will be unpredictable challenges—for which a predictive or planned
approach is not suited.
Who is in the Scrum?
• In rugby, the forwards are involved in the scrum. In software development,
three roles are defined in the scrum framework:
• The scrum team does the work. It is the individuals who are working together
in the sprints to produce the products.
• The scrum master is part of the scrum team makes sure the team works in
compliance with the scrum rules. This is not a manager.
• The product owner represents the customer. This role prioritizes the backlog
and coordinates the scrum teamwork. The product owner is a role similar to
project manager in more traditional project management frameworks.
Scrum Methodology & Process :
• Scrum is executed in temporary blocks that are short and periodic, called
Sprints, which usually range from 2 to 4 weeks, which is the term for feedback
and reflection.
• The process has as a starting point, a list of objectives/ requirements that
make up the project plan.
• Sprint:
• A Sprint is a time box of one month or less.
• A new Sprint starts immediately after the completion of the previous Sprint.
• Release: When the product is completed, it goes to the Release stage. •
Sprint Review: If the product still has some non-achievable features, it will
be checked in this stage and then passed to the Sprint Retrospective
stage.
• Sprint Retrospective: In this stage quality or status of the product is
checked.
• Product Backlog: A product backlog is a registered list of work for the
development team. It is driven from the roadmap and its requirements.
According to the prioritize features the product is organized. The essential
task is represented at the top of the product backlog so that the team
member knows what to deliver first.
• Sprint Backlog: Sprint Backlog is divided into two parts Product assigned
features to sprint and Sprint planning meeting.
What is Project?

• A project is a group of tasks that need to complete to reach a clear result.

• A project also defines as a set of inputs and outputs which are required to
achieve a goal. Projects can vary from simple to difficult and can be
operated by one person or a hundred.
• Projects usually described and approved by a project manager or team
executive. They go beyond their expectations and objects, and it's up to
the team to handle logistics and complete the project on time. For good
project development, some teams split the project into specific tasks so
they can manage responsibility and utilize team strengths.
• A project is well-defined task, which is a collection of several operations
done in order to achieve a goal (for example, software development and
delivery).
What is software project management?
• Software in project management is dedicated to the planning,
scheduling, resource allocation, execution, tracking, and delivery of
software.
• A Software Project is the complete procedure of software development
from requirement gathering to testing and maintenance, carried out
according to the execution methodologies, in a specified period of time
to achieve intended software product.
 Need of software project management:
• The image shows triple constraints for software
projects. It is an essential part of software
organization to deliver quality product, keeping
the cost within client’s budget constrain and
deliver the project as per scheduled. There are
several factors, both internal and external, which
may impact this triple constrain triangle. Any of
three factor can severely impact the other two.
• Therefore, software project management is
essential to incorporate user requirements along
with budget and time constraints.
 Software Project Manager:
• A software project manager is a person who undertakes the responsibility of
executing the software project.
• Software project manager is thoroughly aware of all the phases of SDLC that
the software would go through.
• Project manager may never directly involve in producing the end product but
he controls and manages the activities involved in production.
• A project manager closely monitors the development process, prepares and
executes various plans, arranges necessary and adequate resources, maintains
communication among all team members in order to address issues of cost,
budget, resources, time, quality and customer satisfaction.
 Software Project Managers Responsibilities:
• Managing People:
❖Act as project leader
❖communication with stakeholders
❖Managing human resources
❖Setting up reporting hierarchy etc.
• Managing Project:
❖Defining and setting up project scope
❖Managing project management activities
❖Monitoring progress and performance
❖Risk analysis at every phase
❖Take necessary step to avoid or come out of problems
❖Act as project spokesperson
• Planning: The software project manager puts together the blueprint for the entire
project. The project plan will define the scope, necessary resources, timeline,
procedure for execution, communication strategy, and steps required for testing
and maintenance.

• Leading: A software project manager assembles and leads the project team,
which consists of developers, analysts, testers, graphic designers, and technical
writers. Heading up a team requires excellent communication, people, and
leadership skills.

• Execution: The person who manages software projects will supervise the
successful execution of each stage of the project. This includes monitoring
progress, conducting frequent team check-ins, and creating status reports.
• Time management: Staying on schedule is crucial to the successful
completion of any project. This can be particularly challenging with the
management of software projects because changes to the original plan are
almost guaranteed as the project evolves. Software project managers must
be experts in risk management and contingency planning to ensure
progress in the face of roadblocks or changes.

• Budget: Like traditional project managers, professionals who manage

software projects are tasked with creating a budget for a project and
sticking to it as closely as possible, moderating spending and reallocating
funds when necessary.

• Maintenance: Project management in software encourages constant

product testing to discover and fix bugs early, adjust the end product to the
customer’s needs, and keep the project on target. The software project
manager ensures the product is properly and consistently tested, evaluated,
and adjusted accordingly
 Project Estimation:
• Estimation is the process of finding an estimate, or approximation, which is a
value that can be used for some purpose even if input data may be
incomplete, uncertain, or unstable.
• For an effective management accurate estimation of various measures is a
must. With correct estimation managers can manage and control the project
more efficiently and effective.
• Estimation determines how much money, effort, resources, and time it will take
to build a specific system or product.
• The four basic steps in Software Project Estimation are −
• Estimate the size of the development product.
• Estimate the effort required in project in person-months or person-hours.
• Estimate the project duration.
• Estimate the project cost.
• Estimation determines how much money, effort, resources, and time it will
take to build a specific system or product. Estimation is based on −
• Past Data/Past Experience
• Available Documents/Knowledge
• Assumptions
• Identified Risks
• The effort estimation is expressed in units of person-months (PM).
• Person Month is a measurement unit for effort in software engineering.
 Line Of Code (LOC/SLOC):
• A line of code (LOC) is any line of text in a code that is not a comment or
blank line, and also header lines, in any case of the number of statements or
fragments of statements on the line.
• LOC clearly consists of all lines containing the declaration of any variable,
and executable and non-executable statements.
• As Lines of Code (LOC) only counts the volume of code, you can only use it
to compare or estimate projects that use the same language and are
coded using the same coding standards.
• Example 1:

void selSort(int x[], int n) {

//Below function sorts an array in
ascending order
int i, j, min, temp;
for (i = 0; i < n - 1; i++) {
min = i;
for (j = i + 1; j < n; j++)
if (x[j] < x[min])
min = j;
temp = x[i];
x[i] = x[min];
x[min] = temp;
}
}
 Formula:
• Total Effort = Total LOC/Productivity
• Effort = Total Effort/No of Developers
• Total Cost = Total Effort*Labor Rate
OR
• Cost Per LOC = Labor Rate/Productivity
• Total Cost = Total LOC * Cost Per LOC
• Total Effort = Total Cost/Labor Rate
Question:
Functional Count/Functional Point Analysis:

• A Function Point (FP) is a unit of measurement to express the amount of

business functionality, an information system (as a product) provides to a
user.
• FPs measure software size. They are widely accepted as an industry
standard for functional sizing.
• Functions There are two types of functions −
• Data Functions
• Transaction Functions
• Data Functions There are two types of
data functions −
• Internal Logical Files
• External Interface Files
• Data Functions are made up of
internal and external resources that
affect the system.
• Transaction Functions There are three
types of transaction functions.
• External Inputs
• External Outputs
• External Inquiries
• Transaction functions are made up of
the processes that are exchanged
between the user, the external
applications and the application
being measured.
 COCOMO Model:
1. COnstructive COst MOdel was introduced by Dr. Barry Boehm’s.
2. It is used to estimate the development efforts which are involved in a project.
COCOMO is based upon the estimation of lines of code in a system and the
time.
3. COCOMO has also considered the aspects like project attributes, hardware,
assessment of produce, etc.
4. The COCOMO model has basically two parameters like Effort calculation and
Development time to define the quality of any software product
• Efforts calculation: Efforts can be calculated by the number of persons
required to complete the task successfully. It is calculated in the unit
person-month.
• Development time: the time that is required to complete the task. It is
calculated in the unit of time like months, weeks, and days. It depends on
the effort calculation, if the number of persons is greater then definitely the
development time is low.
• There are various types of models of cocomo that have been proposed to
check the correctness of the software products and to calculate the cost
estimations at the different levels.
• Software projects under COCOMO model strategies are classified into 3
categories,
[Link]
[Link]-detached and
[Link].
• Organic:
A software project is said to be an organic type if-
• Project is small and simple.
• Project team is small with prior experience.
• The problem is well understood and has been solved in the past.
• Requirements of projects are not rigid, such a mode example is payroll
processing system.
• Examples of this type of projects are simple business systems, simple
inventory management systems, and data processing systems.
• Semi-Detached Mode:
A software project is said to be a Semi-Detached type if-
• Project has complexity.
• Project team requires more experience, better guidance and creativity.
• The project has an intermediate size and has mixed rigid requirements
such a mode example is a transaction processing system which has fixed
requirements.
• It also includes the elements of organic mode and embedded mode.
• Few such projects are- Database Management System(DBMS), new
unknown operating system, difficult inventory management system.
• Embedded Mode:
A software project is said to be an Embedded mode type if-
• A software project has fixed requirements of resources .
• Product is developed within very tight constraints.
• A software project requiring the highest level of complexity, creativity, and
experience requirement fall under this category.
• Such mode software requires a larger team size than the other two
models.
• For Example: ATM, Air Traffic control.
Types of COCOMO Models :
 Basic COCOMO Model :
• The first level, Basic COCOMO can be used for quick and slightly rough
calculations of Software Costs.
• It requires to calculate the efforts which are required to develop in three
modes of development that are organic mode, semi-detached mode, and
embedded mode.
The basic COCOMO estimation model is given by the following expressions:
E = a x (KLOC)b
D = c x (Effort)d
P = effort/time
Where, E is effort applied in person-months.
D is development time in months.
P is the total no. of persons required to accomplish the project.
• The constant values a,b,c, and d for the Basic Model for the different
categories of the system.

QUESTION:
Consider a software project using semi-detached mode with 300 Kloc. Find
out effort estimation, development time, and person estimation.
Consider a software project using semi-detached mode with 30,000 line of
code. Find out effort estimation, development time, and person
estimation.
 Intermediate COCOMO Model:
• Intermediate COCOMO model is an extension of the Basic COCOMO model
which includes a set of cost drivers into account in order to enhance more
accuracy to the cost estimation model as a result.
• The estimation model makes use of a set of “cost driver attributes” to compute
the cost of the software.
• The estimated effort and scheduled time are given by the relationship:
Effort (E) = a*(KLOC)b *EAF (PM)
D = c x (Effort)d
The values of a and b in the case of the intermediate model are as follows:
• Where, E = Total effort required for the project in Person-Months (MM). KLOC
= The size of the code for the project in Kilo lines of code.
a, b = The constant parameters for the software project.
EAF = It is an Effort Adjustment Factor, which is calculated by multiplying the
parameter values of different cost driver parameters. For ideal, the value is
1.
• Classification of Cost Drivers and their attributes:
The cost drivers are divided into four categories
o Product attributes
• Required software reliability extent
• Size of the application database
• The complexity of the product

o Hardware attributes
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time
• Personal attributes –

• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
• Project attributes –

• Use of software tools

• Application of software engineering methods
• Required development schedule

EXAMPLE: Consider a software project having 30,000 line of code which is an

embedded software with area hence reliability is high. Find out effort
estimation, development time, and person estimation.
Detailed/Advanced COCOMO model :
• The model incorporates all qualities of both Basic COCOMO and
Intermediate COCOMO strategies on each software engineering process.
• The model accounts for the influence of the individual development phase
(analysis, design, etc.) of the project. It uses multipliers for each phase of the
project .it is a complex mode.
• It includes more factors that influence the software projects and give more
accurate estimations. In this, the whole software is divided into different
modules and then we apply COCOMO in different modules to estimate
effort and then sum the effort. For instance, detailed COCOMO will perform
cost estimation in each development phase of the Waterfall Model
• The Six phases of detailed COCOMO are:
• Planning and requirements
• System design
• Detailed design
• Module code and test
• Integration and test
• Cost Constructive model
• In the Detailed COCOMO Model, the cost of each subsystem is estimated
separately. This approach reduces the margin of error in the final estimate.
• Advantages of COCOMO Model
1. COCOMO is transparent, one can see how it works unlike other models
such as SLIM
2. Drivers are particularly helpful to the estimator to understand the impact
of different factors that affect project costs.
3. COCOMO Provides ideas about historical projects.
4. The COCOMO model is easy to estimate the total cost of the project.
5. The drivers are very helpful to understand the impact of the different
factors that affect project crises.