UNIT V

By
Vinoth C
Department of CSE
NIT Trichy
UNIT V Project Management and Maintenance

Software Project Management - S/W cost estimation - Function point

models - COCOMO model – Project Scheduling - S/W maintenance.
Software Project Management:
Software Project Management:
• Software project management involves planning, organizing, coordinating,
and controlling activities and resources to ensure the successful
completion of software projects within scope, budget, and schedule
constraints.
• It encompasses a range of activities aimed at managing the entire
software development process from initiation to delivery.
• Software project management includes:
• Project Planning
• Resource Management
• Risk Management
• Communication Management
• Quality Management
• Project Planning: This involves defining project objectives, scope, deliverables, timelines,
resource requirements, and risk management strategies. Project planning lays the foundation
for the successful execution of the project and ensures alignment with stakeholder expectations.
• Resource Management: Resource management involves identifying and allocating human,
financial, and technical resources needed to execute the project. It includes tasks such as team
formation, skill assessment, resource scheduling, and budget allocation to optimize resource
utilization and productivity.
• Risk Management: Risk management aims to identify, assess, mitigate, and monitor risks
that may impact the success of the project. It involves analyzing potential threats and
opportunities, developing risk mitigation plans, and monitoring risk factors throughout the
project lifecycle to minimize negative impacts and capitalize on opportunities.
• Communication Management: Effective communication management ensures that
stakeholders are informed, engaged, and aligned throughout the project. It involves
establishing communication channels, defining reporting structures, facilitating meetings, and
resolving conflicts to foster collaboration and transparency among project stakeholders.
• Quality Management: Quality management focuses on ensuring that the software meets
the specified requirements, standards, and user expectations. It includes activities such as
quality planning, quality assurance, and quality control to identify, prevent, and address quality
issues throughout the development process
Software as an Evolutionary Entity
• " Software as an Evolutionary Entity" refers to the concept that
software systems are not static work of art but rather dynamic
entities that continuously evolve and adapt over time.
• This concept reflects the understanding that software undergoes
ongoing changes, enhancements, and refinements throughout its
lifecycle to meet changing user requirements, technological
advancements, and environmental factors.
Cont…
• Several key aspects characterize software as an evolutionary entity:
• Iterative Development: Software development often follows iterative or
incremental approaches, where software is developed, released, and then
improved through subsequent iterations based on feedback and changing
requirements. Each iteration builds upon the previous ones, allowing the
software to evolve gradually.
• Continuous Improvement: Software undergoes continuous improvement
through maintenance activities such as corrective, adaptive, perfective,
and preventive maintenance. These activities address defects, adapt the
software to new environments, enhance existing features, and proactively
prevent future issues, ensuring that the software remains relevant and
reliable over time.
• Feedback Loops: Feedback loops are integral to the evolution of software.
Feedback from users, stakeholders, and the software itself (e.g., through
monitoring and analytics) provides valuable insights that drive
improvements and inform future development efforts. Agile
methodologies emphasize the importance of short feedback loops to
enable rapid adaptation and learning.
• Technological Advancements: Software evolves in response to
technological advancements, including changes in hardware platforms,
operating systems, programming languages, frameworks, and
development tools. Software must adapt to new technologies to
leverage their benefits, remain compatible with evolving environments,
and stay competitive in the market.
• User Requirements: User needs and requirements evolve over time due
to changes in business objectives, market demands, regulatory
requirements, and user preferences. Software must evolve accordingly
to address these changing requirements and continue to provide value to
users.
• Environmental Changes: Software operates within dynamic
environments influenced by factors such as organizational changes,
market conditions, industry trends, and competitor actions. Software
must adapt to these environmental changes to remain effective and
relevant.
Project Management

The Product
• Before planning a project, product objectives and scope must be defined.
• Alternative solutions should be considered, and technical and
management constraints identified.
• These factors help estimate cost, assess risks, break down tasks, and
create a manageable schedule.
• Stakeholders define objectives (overall goals) and scope (data, functions,
and behaviors).
• Alternative solutions are evaluated based on deadlines, budget, personnel
availability, and technical constraints.
The Process
• A software process provides a framework for project planning.
• Framework activities apply to all projects and include task sets,
milestones, work products, and quality assurance.
• Umbrella activities like software quality assurance, configuration
management, and measurement apply throughout the process.

The Project
• Software projects are conducted in a planned and controlled manner to
manage complexity.
• Many projects face delays, overruns, or failures due to poor
management.
• Success factors include identifying warning signs, understanding critical
success factors, and adopting a common-sense approach.
People in Software Projects

• People are the most important factor in software success.

• Stakeholders include:
• Senior managers – define business objectives.
• Project managers – plan, organize, and control the work.
• Practitioners – deliver technical work.
• Customers – specify software requirements.
• End users – interact with the final product.
• Team leaders should have motivation, organization, and innovation
skills.
• Effective project managers solve problems, take charge, reward
initiative, and build strong teams.
Software Team Structures
• Team structure depends on project complexity, team size, and
management style.
• Common team structures:
• Closed paradigm – Hierarchical structure, effective for routine projects.
• Random paradigm – Loosely structured, ideal for innovation-driven projects.
• Open paradigm – Mix of hierarchy and innovation, suitable for complex
projects.
• Synchronous paradigm – Teams work independently with minimal
communication.
• Chief Programmer Team: Led by a senior engineer, with technical
staff and backup support.
• Effective teams have trust, balanced skills, and clear communication
• Toxic team environments arise from poor coordination, unclear roles,
or repeated failures.
Agile Teams
• Agile development emphasizes small, motivated teams, minimal
documentation, and iterative delivery.
• Agile teams are self-organizing and make technical decisions
autonomously.
• Daily meetings help in adapting the approach for software
increments.
Coordination and Communication in Software Projects
• Large projects require effective coordination and communication.
• Formal communication includes documentation and structured
meetings.
• Informal communication allows real-time problem-solving and
collaboration.
Software Project Scope
• Scope defines the boundaries of a project, including:
• Context – How software fits into a larger system.
• Information objectives – Data inputs and outputs.
• Function and performance – How the software processes data.
• Unclear scope leads to project risks and failure.
Problem Decomposition

• Also called Partitioning or Elaboration.

• Complex problems are divided into smaller, manageable problems.
• Functions, data objects, and processes are broken down to ease
planning.
• Example: A word processor’s scope includes editing, spell check, page
layout, and document production.
Software Process Selection

• Teams must select a suitable process model based on:

• Customer needs
• Product characteristics
• Project environment
• Process models include sequential, incremental, evolutionary, and
concurrent models.
• Project planning begins with aligning product and process
requirements.
Managing Software Projects

• Recognizing warning signs of project failure:

• Misunderstanding customer needs.
• Poorly defined scope.
• Unmanaged changes.
• Rapid technology changes.
• Unrealistic deadlines.
• Lack of skilled personnel.
• Avoidance of best practices.
Common-Sense Approach to Project Management

• Start on the right foot – Understand the problem and build the right team.
• Maintain momentum – Keep team motivation high and avoid unnecessary
bureaucracy(i.e. Excessively complicated administrative procedure).
• Track progress – Use work products and technical reviews to measure
success.
• Make smart decisions – Use existing components, avoid risks, and allocate
extra time for complex tasks.
• Conduct postmortem analysis – Review lessons learned, collect project
metrics, and document findings.
The W5HH Principle

• Developed by Barry Boehm for effective project management:

• Why? – Assess the business justification for development.
• What? – Define tasks required for the project.
• When? – Establish a project timeline and milestones.
• Who? – Assign responsibilities to team members.
• Where? – Identify organizational roles beyond software teams.
• How? – Determine management and technical strategies.
• How much? – Estimate required resources.
SOFTWARE COST ESTIMATION
• ESTIMATION FOR SOFTWARE PROJECTS
• Software cost components
• Hardware and software costs.
• Travel and training costs.
• Effort costs (the dominant factor in most projects)
• The salaries of engineers involved in the project;
• Social and insurance costs.
• Effort costs must take overheads into account
• Costs of building, heating, lighting.
• Costs of networking and communications.
• Costs of shared facilities (e.g library, staff restaurant, etc.).
Costing and pricing

• Estimates are made to discover the cost, to the developer, of

producing a software system.
• There is not a simple relationship between the development cost
and the price charged to the customer.
• Broader organizational, economic, political and business
considerations influence the price charged.
Software productivity

• A measure of the rate at which individual engineers involved in

software development that produce software and associated
documentation.
• Not quality-oriented although quality assurance is a factor in
productivity assessment.
• Essentially, we want to measure useful functionality produced per
time unit.
Productivity measures
• Size related measures based on some output from the software
process. This may be lines of delivered source code, object code
instructions, etc.
• Function-related measures based on an estimate of the functionality
of the delivered software. Function-points are the best known of this
type of measure.
Measurement problems

• Estimating the size of the measure (e.g. how many function points).
• Estimating the total number of programmer months that have
elapsed.
• Estimating contractor productivity (e.g. documentation team) and
incorporating this estimate in overall estimate.
Lines of code(LOC)
• The measure was first proposed when programs were typed on cards
with one line per card;
• How does this correspond to statements as in Java which can span
several lines or where there can be several statements on one line.
Productivity comparisons
• The lower level the language, the more productive the programmer
• The same functionality takes more code to implement in a lower-level
language than in a high-level language.
• The more verbose the programmer, the higher the productivity
• Measures of productivity based on lines of code suggest that programmers
who write verbose code are more productive than programmers who write
compact code.
Function Point model
• Function points
• Based on a combination of program characteristics
• external inputs and outputs;
• user interactions;
• external interfaces;
• files used by the system.
• A weight is associated with each of these and the function point
count is computed by multiplying each raw count by the weight
and summing all values.
Cont..

• The function point count is modified by complexity of the project

• FPs can be used to estimate LOC depending on the average number of
LOC per FP for a given language
• LOC = AVC * number of function points;
• AVC is a language-dependent factor varying from 200-300 for assemble
language to 2-40 for a 4GL;
• FPs are very subjective. They depend on the estimator
• Automatic function-point counting is impossible.
•
COCOMO model
• An empirical model based on project experience.
• Well-documented, ‘ independent‘ model which is not tied to a
specific software vendor.
• Long history from initial version published in 1981 (COCOMO-81)
through various instantiations to COCOMO 2.
• COCOMO 2 takes into account different approaches to software
development, reuse, etc.
 COCOMO 81
Project complexity Formula Description

Well-understood applications developed by

Simple PM = 2.4 (KDSI)1.05 ×M
small teams.

More complex projects where team

Moderate PM = 3.0 (KDSI)1.12 × M members may have limited experience of
related systems.

Complex projects where the software is part of

a strongly coupled complex of hardware,
Embedded PM = 3.6 (KDSI)1.20 ×M
software, regulations and operational
procedures.
COCOMO 2
• COCOMO 81 was developed with the assumption that a waterfall
process would be used and that all software would be developed
from scratch.
• Since its formulation, there have been many changes in software
engineering practice and COCOMO 2 is designed to accommodate
different approaches to software development.
COCOMO 2 models
• COCOMO 2 incorporates a range of sub-models that produce increasingly
detailed software estimates.
• The sub-models in COCOMO 2 are:
• Application composition model. Used when software is composed from
existing parts.
• Early design model. Used when requirements are available but design has not
yet started.
• Reuse model. Used to compute the effort of integrating reusable
components.
• Post-architecture model. Used once the system architecture has been
designedand more information about the system is available.
USE of COCOMO II models
Application composition model
• Supports prototyping projects and projects where there is extensive
reuse.
• Based on standard estimates of developer productivity in application
(object) points/month.
• Takes CASE tool use into account.
• Formula is
• PM = ( NAP (1 - %reuse/100 ) ) / PROD
• PM is the effort in person-months,
• NAP is the number of application points and PROD is the productivity.
Early design model
• Estimates can be made after the requirements have been agreed.
• Based on a standard formula for algorithmic models
• PM = A ´ SizeB ´ Mwhere
• M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´SCED;
• A = 2.94 in initial calibration, Size in KLOC, B varies from 1.1 to 1.24 depending on
novelty of the project, development flexibility, risk management approaches and the
process maturity.
Multipliers
• Multipliers reflect the capability of the developers, the non-functional
requirements, the familiarity with the development platform, etc.
• RCPX - product reliability and complexity;
• RUSE - the reuse required;
• PDIF - platform difficulty;
• PREX - personnel experience;
• PERS - personnel capability;
• SCED - required schedule;
• FCIL - the team support facilities.
The reuse model
• Takes into account black-box code that is reused without change and
code that has to be adapted to integrate it with new code.
• There are two versions:
• Black-box reuse where code is not modified. An effort estimate (PM) is
computed.
• White-box reuse where code is modified. A size estimate equivalent to the
number of lines of new source code is computed. This then adjusts the size
estimate for new code.
Reuse model estimates
• For generated code:
• PM = (ASLOC * AT/100)/ATPROD
• ASLOC is the number of lines of generated code
• AT is the percentage of code automatically generated.
• ATPROD is the productivity of engineers in integrating this code.
• When code has to be understood and integrated:
• ESLOC = ASLOC * (1-AT/100) * AAM.
• ASLOC and AT as before.
• AAM is the adaptation adjustment multiplier computed from the costs of
changing the reused code, the costs of understanding how to integrate the
code and the costs of reuse decision making.
Post-Architecture level
• Uses the same formula as the early design model but with 17 rather
than 7 associated multipliers.
• The code size is estimated as:
• Number of lines of new code to be developed;
• Estimate of equivalent number of lines of new code computed using the
reuse model;
• An estimate of the number of lines of code that have to be modified
according to requirements changes.
The exponent term
• This depends on 5 scale factors .Their sum/100 is added to 1.01
• A company takes on a project in a new domain. The client has not defined the process to be used and has
not allowed time for risk analysis. The company has a CMM level 2 rating.
• Precedenteness - new project (4)
• Development flexibility - no client involvement - Very high (1)
• Architecture/risk resolution - No risk analysis - V. Low .(5)
• Team cohesion - new team - nominal (3)
• Process maturity - some control - nominal (3)
• Scale factor is therefore 1.17.
Multipliers
• Product attributes
• Concerned with required characteristics of the software product being developed.
• Computer attributes
• Constraints imposed on the software by the hardware platform.
• Personnel attributes
• Multipliers that take the experience and capabilities of the people working on the project into account.
• Project attributes
• Concerned with the particular characteristics of the software development project.
Project Scheduling

• Scheduling Principles
• compartmentalization—define distinct tasks
• interdependency—indicate task interrelationship
• effort validation—be sure resources are available
• defined responsibilities—people must be assigned
• defined outcomes—each task must have an output
• defined milestones—review for quality
The relation ship between effort and delivery
time
Time-Line Charts (Gantt Charts)
Used to visualize a software project schedule.
Created after defining tasks (via work breakdown structure).
Inputs: task duration, effort, start date, and assigned personnel.
Shows:
• Tasks as horizontal bars.
• Concurrency if bars overlap.
• Milestones as diamonds.
Can be created:
For the entire project
or
For each team/function/member.
Tracking the Schedule

• Project managers use both qualitative and quantitative methods:

• Periodic team meetings to report progress/issues.
• Review results of software engineering deliverables.
• Check if milestones are met as scheduled.
• Compare actual vs. planned dates.
• Informal meetings for subjective feedback.
• Use Earned Value Analysis (EVA) for quantitative progress.
Time Line Chart
Project Control
•If everything is on track: light control.
•When problems arise: active control is needed (reassign staff, change schedule).
•Goal: resolve issues quickly to prevent cascading delays.
Time-Boxing Technique
• Used under tight deadlines.
• Break the project into increments.
• Define fixed duration (time-boxes) for each task.
• Once a time-box ends (±10% threshold), move to the next task—even
if unfinished.
• Remaining work:
• Completed in future increments, or
• Deferred if not immediately essential.
• Prevents getting stuck on one task, promoting progress.
Executing the timeboxing process model
Earned Value Analysis (EVA)
Earned Value Analysis (EVA) in software engineering is a quantitative
technique used to measure project progress and performance, particularly in terms
of cost, schedule, and scope
A quantitative method to assess project progress.
Key Metrics:
• BCWS – Budgeted Cost of Work Scheduled
Planned effort for tasks scheduled to be done by a point in time.
• BAC – Budget at Completion
Total planned effort = Sum of all BCWS.
• BCWP – Budgeted Cost of Work Performed
Planned effort for tasks actually completed by that time.
• ACWP – Actual Cost of Work Performed
Real effort spent on completed tasks.
 Performance Indicators
• Schedule Performance Index (SPI) = BCWP / BCWS
Efficiency of schedule adherence
SPI ≈ 1 → On track

• Schedule Variance (SV) = BCWP - BCWS

Ahead or behind schedule?

• Cost Performance Index (CPI) = BCWP / ACWP

Budget efficiency
CPI ≈ 1 → On budget

• Cost Variance (CV) = BCWP - ACWP

Cost overrun or saving

• % Scheduled for Completion = BCWS / BAC

• % Completed = BCWP / BAC

EVA is like "early-warning radar"—it reveals issues before they become project crises.
Software Maintenance:
• Software maintenance refers to the process of modifying, updating,
and enhancing existing software applications to meet changing user
requirements, adapt to new environments, fix defects, and
improve performance.
• It is an essential phase in the software development lifecycle that
occurs after the initial development and deployment of a software
system.
Software maintenance activities can include:-
1. Corrective Maintenance: This involves fixing defects, errors, or bugs
identified in the software during its operational use. Corrective
maintenance aims to ensure the proper functioning and reliability of the
software.
2. Adaptive Maintenance: Adaptive maintenance involves modifying the
software to adapt to changes in the environment, such as new hardware
configurations, operating systems, or third-party dependencies. It ensures
that the software remains compatible and functional in evolving
technological landscapes.
3. Perfective Maintenance: Perfective maintenance focuses on improving
the software's performance, efficiency, and user experience. It may involve
enhancing existing features, optimizing algorithms, or adding new
functionalities to meet evolving user needs and expectations.
4. Preventive Maintenance: Preventive maintenance aims to proactively
identify and address potential issues or risks in the software before
they impact its operation. It involves activities such as code refactoring,
documentation updates, and performance monitoring to prevent future
problems and ensure the long-term stability of the software.
Software Maintenance

1. When does maintenance start?

Software maintenance starts ” right after the software is released”.
- Within a few days, users report bugs.
- Some users soon request changes to suit their environment.
- Later, new users who didn’t need the software before now see its
value and ask for improvements.
2. What challenges does maintenance bring?

You’ll quickly see:

- A long list of bugs to fix.
- Requests for updates and new features.
- The list keeps growing and can “overwhelm the team”.
- Over time, “more time and money” are spent on maintaining
software than building new applications.
- In fact, “60–70% of resources” often go into maintenance.
3. Why is so much maintenance needed?

- Many programs in use today are “10–15 years old”.

- Even if they were written well at that time, the focus was on “saving
space” and “keeping code short”.
- These programs have been moved to new systems, updated, and
changed often “without proper planning”.
- This leads to “messy code”, “bad design”, and “poor
documentation”—all of which make maintenance harder.
4. What makes it harder?

“People leave”: The original developers may not be around anymore.

- Over the years, many different developers may have made changes.
- Now, “no one fully understands”how the system works.
5. Why is change always expected?
- Change is a “natural part” of software.
- So, we need to have good ways to
• “evaluate”,
• “control”
• “apply” changes.
6. What is maintainability?
- Maintainability means how “easy it is to fix, update, or improve”
a software system.
- It’s a key goal in software engineering.
7. What makes software maintainable?
- Good modular design: Each part of the software does one thing well.
- Use of design patterns: Makes the structure easy to understand.
- Clear coding standards: Makes the code self-explanatory.
- Quality assurance: Bugs are caught early during testing.
- Future-proof thinking: Developers write the code as if someone else will
maintain it later.