Unit - III Software

Project Management
 3.1 The management spectrum- 4P's 04 marks
• The Management Spectrum in software engineering refers to the four key dimensions
that influence software project management. These are known as the 4 P’s:
• ✅ 1. People
• People are the most critical element of a software project.
• The success or failure of a project largely depends on the team.
• It involves:Selection and organization of teams
• Clear roles and responsibilities
• Motivation, training, and communication
• Key roles: Project manager, developers, testers, stakeholders, etc.
• ✅ 2. Product
• Refers to the software to be built, including its goals, scope, and requirements.
• It defines what is to be done.
• Includes:Product objectives
• Requirements gathering
• Functions and feature
✅ 3. Process
• Refers to the framework or model used to build the product.
• Ensures systematic and disciplined development.
• Examples: Waterfall, Agile, Spiral, etc.
• A good process helps:Improve quality
• Reduce risks
• Ensure timely delivery
✅ 4. Project
• The actual activity of developing the product using the right people,
process, and within time and cost constraints.
• It involves:
• Planning
• Scheduling
• Monitoring and control
• Project management tools and techniques are used here.
State importance of “Function point “ and “lines of code” in concerned with project estimation
04 marks
Currently two metrics are popularly being used widely to estimate size: lines of code (LOC) and function point (FP).
1. Lines of Code (LOC)
• LOC is the simplest among all metrics available to estimate project size.
• This metric is very popular because it is the simplest to use.
• Using this metric, the project size is estimated by counting the number of source instructions in the developed
program. Obviously, while counting the number of source instructions, lines used for commenting the code and the
header lines should be ignored.
2. Function Point (FP):
• The conceptual idea behind the function point metric is that the size of a software product is directly dependent on
the number of different Functions or features it supports. A software product supporting many features would
certainly be of larger size than a product with less number of features. Each function when invoked reads some
input data and transforms it to the corresponding output data.
• For example, the issue book feature of a Library Automation Software takes the name of the book as input and
displays its location and the number of copies available. Thus, a computation of the number of input and the
output data values to a system gives some indication of the number of functions supported by the system.
• Albrecht postulated that in addition to the number of basic functions that a software performs, the size is also
dependent on the number of files and the number of interfaces.
State and describe two metrics of project size estimation Metrics for
project Size Estimation 04 marks

• Metrics for project Size Estimation

[Link] of Code
[Link] is the simplest among all metrics available to estimate project size. This metric is very popular because it
is the simplest to use.
Using this metric, the project size is estimated by counting the number of source instructions in the
developed program while counting the number of source instructions, lines used for commenting the code
and the header lines should be ignored.
Estimation is dependent on programming language. For different programming language lines of code will
vary.
2. Function Point metric: Measures the functionality provided to the user, based on inputs, outputs, user
interactions, files, and interfaces.
Purpose: Estimates project size by analyzing what the software does, not how it is coded.
Components:
External Inputs (EI)
External Outputs (EO)
External Inquiries (EQ)
Internal Logical Files (ILF)
External Interface Files (EIF)
Advantages:
Independent of programming language
Focuses on user requirements
Disadvantages:
Requires experience to calculate accurately
Slightly complex process
To compute Function Point the following relationship is used: FP =count total[0.65+0.01∑(Fi)]
Define Project Cost Estimation. 02 MARKS
Software cost estimation is the process of predicting the effort required to develop a software system.
Project cost estimating is the process of predicting the total cost of the tasks, time, and resources
required to deliver a project's scope of work.
There are three approaches of project estimation, they are:
i) Heuristic
ii) Analytical
iii) Empirical
Describe following project cost estimation approaches
i) Heuristic
ii) Analytical
iii) Empirical 06 /MARKS

1. The heuristic approach relies on rules of thumb or past experience to

estimate costs. These rules are often derived from previous similar
projects or industry standards.
• Features:
• Uses pre-defined formulas or ratios (e.g., cost per line of code, cost per
function point).
• Simple and quick to apply.
• Best suited for early-stage estimates.
• Example:
• “If developing 1000 lines of code costs ₹50,000 in a previous project,
then 2000 lines may cost ₹1,00,000.”
There are two classes of heuristic estimation techniques based on mathematical
modeling:
1. Single Variable Model: This model estimates the project cost or effort using only one
primary variable — usually the size of the software, like Lines of Code (LOC) or Function
Points (FP).
A single variable estimator model takes the following form:
Estimated Parameter = c1 * ed1
e= characteristic which already have been calculated.
Estimated parameter is the dependent parameter to be estimated. The dependent
parameters
to be estimated could be effort, duration, staff size etc.
c1 and d1 are constants- calculated from past projects.
COCOMO is one of this type of models example.
[Link] Model: This model estimates cost or effort based on multiple variables,
such as size, complexity, team experience, technology, and other cost drivers.
It has the following form
Estimated Resources = c1 * e1d1 + c2 * e2d2 + - - - -
e1 and e2 are the basic independent characteristics of the software
ii) Analytical Approach: The analytical approach estimates costs by breaking the
project down into components or tasks, analyzing each part in detail, and
summing up individual costs.
Features:
• Based on detailed specifications and technical parameters.
• Involves calculation of effort, time, and resources required for each task.
• More accurate than heuristic, but time-consuming.
• Example:
• Calculate effort for design, coding, testing, and documentation separately,
then multiply by the labor rate for each activity.
• ii) Empirical Approach :The empirical approach uses data from past projects and applies statistical or
mathematical models to estimate project cost.
• Features:
• Data-driven and objective.
• Uses models like COCOMO, SLIM, or regression analysis.
• Highly reliable when sufficient historical data is available.
• Example:
• Using the COCOMO model, which estimates effort (in person-months) based on project size (in KLOC -
thousands of lines of code) and other cost drivers.

Two popular empirical estimation techniques are:

1. Expert judgment technique
2. Delphi cost estimation.
 Project cost estimation using COCOMO (Constructive Cost Model)
• The COCOMO (Constructive Cost Model) is a software cost estimation model that predicts development
effort, schedule, and cost based on project attributes.
• It comes in three levels of increasing complexity: Basic, Intermediate, and Detailed. Each level refines the
estimation process by incorporating more detailed cost factors and drivers.
COCOMO Model Types:
1. Basic COCOMO:
• Provides a rough estimate of effort and cost.
• Based only on the size of the software (in KSLOC).
• Ignores factors like personnel experience or tools.
2. Intermediate COCOMO:
• It refines the basic model by considering 15 cost driver attributes that influence the project, such as product,
hardware, personnel, and project factors. These cost drivers are used to adjust the effort estimate.
3. Detailed COCOMO:
• Extension of Intermediate COCOMO.
• Includes cost drivers and effort estimates for each phase of the software life cycle:
-Requirements
-Design
-Coding
-Testing
• Offers the most detailed and accurate estimation.
 Types of Projects in COCOMO
1. Organic: Small, simple software with experienced teams and stable
environment
[Link]-Detached: Medium-size, moderate complexity software
[Link]:Complex, real-time, high-reliability systems with hardware
constraints
Calculate using COCOMO model
i)Effort
ii)Project duration
iii)Average staff size
If estimated size of project is 200 KLOC using organic mode. 06 marks

• What's given in the problem The estimated size of the project is

200KLOC .The project mode is organic.
• Helpful information For the organic mode, the COCOMO constants are:
a = 2.4 b = 1.05 c = 2.5 d = 0.38
Calculate using COCOMO model 1)Effort, 2)Project duration
(Development time), 3)Average staff size , 4)Productivity ..If
estimated size of project is 400 KLOC using Embedded mode.
 COCOMO II (Constructive Cost Model II)
• COCOMO II (Constructive Cost Model II) is an advanced version of the original COCOMO
model, developed by Barry Boehm to estimate the cost, effort, and time of modern
software projects. It supports object-oriented development, reuse, iterative models, and
modern tools.
Key Features of COCOMO II
• Estimates are based on size (in KSLOC or Function Points), scale factors, and cost drivers.
• Suitable for modern software processes like agile, spiral, and incremental models.
• Provides better support for reuse, automation tools, and complex architectures.

Types of COCOMO II Models

[Link] Composition Model
[Link] Design Model
[Link]-Architecture Model
• Sub-Models of COCOMO II
1. Application Composition Model:
Used in the early stage (when software is being composed using
existing components, prototypes, or CASE tools).
• Size is measured in Object Points (OP).
[Link] Design Model:-
Used once requirements are roughly known.
Size measured in Unadjusted Function Points (UFP) or converted into
KLOC.
PM(Effort)= A×(Size)E×∏EMi
[Link]-Architecture Model:-Used after complete architecture is
[Link] detailed: considers 17 effort multipliers and 5 scale
factors.
PM(Effort) =A×(Size)E×∏EMj
 Risk Analysis And Management
Defination: A risk is a probality that some adverse cicumstances will occour.
• Risk is an expectation of loss, a potential problem that may or may not occur
in the future.
• It is generally caused due to lack of information, control or time.
• A risk is a potential problem – it might happen and it might not
• Two characteristics of risk
• Uncertainty – the risk may or may not happen, that is, there are no 100%
risks (those, instead, are called constraints)
• Loss – the risk becomes a reality and unwanted consequences or losses
occur
 Risk Management Process
• Risk Management is concerned with indentfying the risks and drawing
up the plans to minimize their effect on project.
• A risk is a probality that some adverse cicumstances will occour:
[Link] Risk affect the schedule or resources
[Link] risk affect the quality or performance of the software being
developed.
[Link] risk affect the organization development of software.
• Risk Management Process contains following phases-
• [Link] Identification: Identify Project, product and business risk.
• [Link] analysis: Assess the consequences of these risks.
• [Link] Planning: Draw up the plans to minimize the effect of risk.
• [Link] Monitoring:Monitor the risk throughout the project.
• Define proactive and reactive risk strategy. 2 Marks
[Link] risk strategies: Reactive risk strategy follows that the risks have to
be tackled at the time of their occurrence.
• No precautions are to be taken as per this strategy.
• They are meant for risks with relatively smaller impact.
• More commonly, the software team does nothing about risks until something
goes wrong. Then, the team flies into action in an attempt to correct the
problem rapidly. This is often called a fire-fighting mode.
2. Proactive risk strategies
• It follows that the risks have to be identified before start of the project.
• They have to be analysed by assessing their probability of occurrence, their
impact after occurrence, and steps to be followed for its precaution.
 List and Expalin Types of Risk in Software Engineering 02 marks.
[Link] Risk: Related to project management and execution.
• Examples: unrealistic deadlines, scope creep, poor resource
[Link] of the project.
[Link] Risk: Related to technology and technical aspect.
Examples: new or untested technology, performance issues, integration
challenges.
[Link] Risk: Related to business goals and financial viability.
• Examples: changing business priorities, budget cuts, market changes.
[Link] Risk: Related to day-to-day operations and processes.
• Examples: staff turnover, process inefficiencies, infrastructure failure.
[Link] Risk: Related to software vulnerabilities and data protection.
• Examples: hacking, data breaches, insecure code.
[Link] Risk: Related to delays in project timeline.
• Examples: dependency delays, unexpected complexities.
 Describe RMMM Strategy. 4M
--
RMMM (Risk Mitigation, Monitoring, and Management) strategy is a
structured software engineering process for proactively identifying, assessing,
and managing risks throughout a project's lifecycle to minimize negative
impacts on cost, schedule, and quality.

--It involves identifying potential risks, developing plans to reduce their

impact (mitigation), continuously watching for developing risks (monitoring),
and implementing contingency plans for risks that cannot be fully avoided
(management).
• Key Components of the RMMM Strategy
1. Risk Mitigation:
• This involves proactively taking steps to reduce the likelihood of a risk occurring or to lessen its potential
impact if it does.
• Examples:
• Avoidance: Using proven technologies to prevent technical risks.
• Reduction: Employing rigorous testing procedures to decrease the impact of software defects.
• Contingency Planning: Developing alternative plans for risks that are not fully mitigated.
2. Risk Monitoring:
• This stage focuses on continuously tracking identified risks .
• Activities: Regularly reviewing the risk list, checking for new risks, and assessing the effectiveness of
mitigation efforts.
[Link] Management:
• This encompasses the overarching process of dealing with risks that occur, particularly those that weren't
fully mitigated.
• Activities: Implementing contingency plans, addressing issues as they arise, and documenting the outcomes
of the risk management process to inform future projects.
State and describe any four basic project
scheduling principles. 04 marks
• Here are the principles of Project scheduling in detail:
1. Compartmentalization: Divide the project into smaller, more manageable activities and tasks, often using a
Work Breakdown Structure (WBS). This makes the project easier to estimate, assign, and track.
[Link]: Identify the relationships and sequences between tasks.
• Determine which tasks must be completed before others can begin (sequential tasks), and which can be done
simultaneously (parallel tasks).
[Link] Allocation: Assign a realistic start and completion date to each task. Consider both full-time and part-
time efforts when calculating durations.
[Link] Validation: Ensure you have the necessary resources, such as the correct number of people,
equipment, and materials, available for each task.
[Link] Responsibilities: Assign each task to a specific team member to ensure accountability.
[Link] Outcomes and Milestones: Each task must have a clear and defined output, or deliverable.
[Link] and Monitoring: Regularly monitor progress against the schedule to identify any deviations.
 Project Scheduling Techniques- CPM &
PERT
• CPM (Critical Path Method) and PERT (Program Evaluation Review
Technique) are project management techniques.
• Both are used for planning, scheduling, and controlling complex projects.
• They help in identifying the minimum time required to complete a project.
CPM
• Developed in the 1950s by DuPont.
• Focuses on deterministic (fixed) activity times.
• Identifies the longest path (critical path) in the project.
• Helps in calculating project duration and resource allocation.
 Program Evaluation Review
Technique (PERT)
• Developed by the U.S. Navy in the 1950s.
• Deals with probabilistic activity times (optimistic, pessimistic, most likely).
• Useful for projects with uncertain activity durations.
• Focuses on risk management and project time estimation.
Critical Path Method (CPM) Goal
• The goal of the Critical Path Method (CPM) is to determine the critical
path of a schedule in order to focus resources more efficiently. The
method helps Program Managers (PM):

• Understand which tasks are on the critical path to determine a

completion date.
• How best to manage tasks around the critical path to meet the
scheduled end date.
• Focus on preventing schedule slips.
Benefits of Using the Critical Path Method (CPM)

• Improves Planning: CPM helps plan for the future by comparing

expected progress to actual progress. The data from current projects
can be used to help plan for future projects.
• Helps with resource loading: CPM helps project managers put tasks in
order of importance, which gives them a better idea of how and
where to use resources.
• Highlights bottlenecks: When projects get stuck, valuable time is lost.
Using a network diagram to show project dependencies will help you
figure out which tasks can and can’t be done simultaneously so that
you can plan your schedule accordingly.
• Determining the Critical Path
• The Critical Path is determined when analyzing a project’s schedule or
network logic diagram and uses the Critical Path Method (CPM). The
CPM provides a graphical view of the project, predicts the time
required for the project, and shows which activities are critical to
maintaining the schedule.
• Critical Path Method (CPM) Development Steps
• The seven (7) steps in the CPM are:
• Step 1: List of all activities required to complete the project (see Work
Breakdown Structure (WBS)),
• Step 2: Determine the sequence of activities
• Step 3: Draw a network diagram
• Step 4: Determine the time that each activity will take to completion
• Step 5: Determine the dependencies between the activities
• Step 6: Determine the critical path
• Step 7: Update the network diagram as the project progresses
 PERT
• A software engineering PERT chart example includes nodes for events like
"Requirements Gathering" or "Deployment" connected by arrows
representing tasks, with time estimates for each task to identify
dependencies and the project's critical path.
• For instance, a software project's PERT chart might show a sequence:
"Requirements" -> "Design" -> "Coding" -> "Testing" -> "Deployment," where
a delay in "Coding" directly impacts the final "Deployment" date because
they lie on the critical path.
• Components of a Software Engineering PERT Chart
• Nodes (Events/Milestones): Represent key points in the project, such as the
start or completion of a phase like "Coding Complete" or the final "Product
Launch".
• Arrows (Tasks/Activities):The actual work to be done, connecting the nodes
and showing the sequence of tasks.
• Dependencies: Arrows show that one task cannot begin until another is
finished, like "Coding" requiring "Design" to be done first.
• Time Estimates: Each task arrow has a duration, often using three estimates
—optimistic, pessimistic, and most likely—to calculate a weighted average
time.
• Critical Path:The sequence of tasks that determines the shortest project
duration. Any delay on the critical path delays the entire project.
A Basic Software Project PERT Chart Example
Here's how a PERT chart could map out a new application's release:
CPM & PERT
Project Tracking --Timeline charts,
Gantt chart
• In software engineering, a timeline chart (most often a Gantt chart) is
a project management tool that visualizes project tasks, milestones,
and their dependencies over a specific time period.
• It uses horizontal bars to represent tasks, showing their start and end
dates, duration, and overall progress.
• Timeline charts are essential for tracking software development
progress, managing resources, identifying bottlenecks, and
communicating the project schedule to stakeholders
Prepare Macro Timeline chart for 20 days of Hotel Management
system (6 days a week) consider broad phase of SDLC.
04 Marks
Gantt Chart:
• In software engineering, a Gantt chart is a visual project management
tool that displays tasks as horizontal bars on a timeline, showing their
duration, start and end dates, dependencies, and assigned team
members.
• It provides a clear roadmap for the Software Development Life Cycle
(SDLC), allowing teams to plan, coordinate, and track progress,
identify dependencies, manage milestones, and ensure timely
delivery of quality software products.
Gantt Chart for Software Project: