Download UNIT-5 - Department of Computer Science and Engineering, SACET

Chapter - 1
Software Project Management
Introduction
• Software project management is an activity crucial to the
success of software projects.
• Software products are more complex entities in which defects
are mostly discovered during development.
• Software changes are limited to changes in programs and the
volume of change depends on understanding requirements of
customers and developers.
• In the current scenario, people working on a project to develop
software are geographically distributed; hence, proper
coordination and communication management is required
among them.
Introduction
• Due to the lack of domain knowledge certain tools are needed
for project size estimation, planning, software development,
and so on.
• Quality software can only be produced if a systematic process
and appropriate techniques are followed for the development
of software.
• It is observed that several software projects run behind
schedule, over budget, and fail to meet the customer
requirements.
• In a software company, many software projects run
concurrently; they share resources and their activities are
synchronized for optimal use of resources.
Goal of SPM
• Development of quality software is the primary objective of
software project management.
• The goal of software project management is to enable a group
of people to work efficiently on a project, using a systematic
process, in order to produce a quality software product.
• Software project management uses a more established and
specialized approach as compared to general project
management.
Project Management Essentials
• Project management is an integrated environment where
various entities are interconnected and performed together to
produce a quality software product.
• There are four essential elements of effective software project
management:
– Project
– People
– Process
– Product
• Effective software project management focuses on these
elements to fulfill the customer needs.
Project Management Essentials
People
Process
Software
project
management
Product
Project
Figure 3.1: Software project management essentials
Project
• A project is a temporary endeavor with defined starting and
ending deadlines, roles and responsibilities, conditions,
budgets and plans, undertaken to accomplish aim and
objectives.
• Each project has a unique purpose even if there are multiple
projects in a single domain.
• Projects are basically temporary in nature due to their
flexibility to change.
• Uncertainties are involved in a software project.
• Requires resources (hardware, software, and human
resources), typically from different areas.
Project
• A successful project always satisfies the project constraints
expected by the customer.
• Project constraints are defined in the project scope, which
defines the work products to be produced in a project using
processes.
• The most common constraints that are employed on the project
scope are project cost, time, and quality.
• Project stakeholders must agree upon the defined project
scope.
• The main focus of project management is to satisfy the
customer through production of quality products.
People
• People (or stakeholders) in a project are those who are either
involved in or are affected by the project.
• Each person in the project has certain roles and responsibilities
according to their skill sets.
• They should be motivated, trained, rewarded, deployed, and
retained as and when required to improve their capabilities.
• Poor management sometimes leads to project failures.
People Involved in Project
•
•
•
•
•
•
•
•
•
Senior Managers
Project Managers
Programmers
Support Staff
Customers
End Users
Project Sponsors
Competitors
Suppliers
Process
• A software process describes the characteristics and
organization of activities in order to produce software.
• The general activities of software processes include
– Definition
– Development
– Implementation
• The selection of an appropriate software process model
according to the project is a challenge for the project manager.
• Process models ultimately affect the product quality.
Product
• A product is the final outcome of a project.
• It is produced with an effective project management process.
• The project manager must determine the requirements and the
expected outcomes at the beginning of the project.
• Project scope of the product must be clearly defined, which
helps us to produce a quality product.
• Project scope is refined into discrete functional units and the
development schedule is planned for each functional units.
• The quality of the product also depends on the process being
used for product development.
Project Management
• Project management is the application of knowledge,
skills, tools, and techniques for performing project
activities in order to satisfy the expectations of the
stakeholders from a project.
• Project management is necessary to find the pitfalls
and create outlets to avoid the unintended
consequences of the project.
• Software project management is the key to successful
delivery of software projects as per customers’
expectations.
Project Management Knowledge Areas
• The knowledge areas are the competencies of the process,
practice, tools, and techniques that the project managers must
have for managing the projects.
• The main knowledge areas for project management are:
–
–
–
–
–
–
–
–
–
Scope
Time
Cost
Quality
People
Communications
Risk,
Procurement
Project Integration Management
Project Management Knowledge Areas
• Each of these knowledge areas has some processes for its
execution in order to achieve an effective project management
program.
• Project management skills include:
– General Management
– Human Resource Management
– Procurement Management
– Communication Management
– Risk Management.
• Project management tools and techniques assist in carrying out
the activities of project managers.
Project Failures
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Inability to clearly understand customer needs
Lack of user involvement
Unrealistic expectations
Lack of top management support
Incomplete requirements and specifications
Lack of resources (hardware, software, and people)
Lack of good planning
Technical incompetence
Changing business needs and requirements
Changes are managed poorly
Lack of best practices
The chosen technology changes
Ill-defined responsibility of team members
Lack of communication among team members
Project Success
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Strong support from the top management
A sound methodology for the project
Tactical and technical leadership by competent people
User involvement in each activity
Experienced project manager
Clearly defined business goals
Clearly defined project scope
Feedback mechanism
Sufficient resource allocation
Adequate communication channels
Troubleshooting capabilities
Reliable estimates
Clearly specified deadlines
Parties sticking to the commitment
Project Management Team
• The people who work together on a project are referred to as a
team.
• A team is a cohesive group of one or more related roles and/or
subordinate teams that collaborate to perform a cohesive set of
tasks.
• The achievement in the project depends on the collective effort
of top-level management, the project manager, and the
members of the project team.
• Teamwork refers to a group of people working together in
order to achieve a common goal.
• Software work products are the results of teamwork.
Project Management Team
• They require skill, knowledge, and tact on the part of the leader.
• There must be a strong communication channel among team
members.
• Organizations must develop a culture of team building.
• Attitudes, interaction patterns, skills possessed by members,
methods used to work on tasks, and individual contributions all
contribute to the team culture.
• Every team may be different from the others in the way it handles its
tasks.
• A project management team typically consists of Project Manager ,
Configuration Manager , Metrics Analyst, Process Engineer, Quality
Engineer, Scheduler, Technical Leader and so on.
• The team performs the overall (administrative) management and risk
management for a single project.
Team Structures
• A team structure could consist of a number of teams, each with
a team leader.
• Each team and its members have an identified expertise or
skill that is needed to complete the tasks.
• Usually, the team is headed by the project manager.
• There are three types of team structure:
– Chief Programmer Team Structure
– Hierarchical Team Structure
– Egoless Team Structure
Chief Programmer Team Structure
• Chief programmer team structure Consists of :
– A Chief Programmer,
– Programmers,
– Backup Programmers
– A Programming Librarian
• It is a centralized automatic structure in which all information
passes through the chief programmer.
• The chief programmer breaks down the task into small tasks
and assigns them to the programmers and team members.
• After the completion of each task, he verifies and integrates
the work products.
Chief Programmer Team Structure
Chief programmer
Back-up
programmer
Librarian
Programmers
(a) Structure
(b) Communication path
Figure 3.2: Chief programmer team structure
Hierarchical Team Structure
• Hierarchical Team Structure Consists of:
– Programmers
– Database Manager
– Network Administrators
– Testers and so on
• The project manager is responsible for handling the
project activities.
• There will be senior programmers or project leaders
who report to the project manager.
• The senior programmers or project leaders will then be
responsible to the project team members.
• The project manager will coordinate with the project
leaders to solve the problems relating to the project.
Hierarchical Team Structure
Project manager
Senior
programmers
Junior programmers
(a) Structure
(b) Communication path
Figure 3.3: Hierarchical team structure
Egoless Team Structure
• The egoless team structure is also known as the
democratic team structure.
• It does not enforce any formal team hierarchy
• The manager provides the administrative leadership.
• Leadership rotates among different team members at
different times, which becomes the responsibility of the
individual with the abilities that are currently needed.
• The democratic organization structure leads to higher
morale and job satisfaction.
• Consequently, it suffers from less manpower turnover.
• People are in different knowledge areas and have
different experience levels.
• Here, everybody can communicate with everybody.
Egoless Team Structure
(a) Structure
(b) Communication path
Figure 3.4: Egoless team structure
Project Organization
• There are several methods for allocating tasks
to a team in an organization.
• Typical structures are
– Project Format,
– Functional Format
– Matrix Format
Project Format
• The project development staff members are divided based on
the project for which they work.
• Each project has its own team and all the necessary resources.
• The project team is assigned to start and finish the project.
• It will be responsible for planning, requirement analysis,
design, development, testing, deployment, and maintenance.
• The project manager has the decision-making authority. The
longevity of the team depends on the project duration.
Project Format
Top management
Project
team 1
Project
team 2
...
Figure 3.5: Project format
Project
team n
Functional Format
• Teams are made on the basis of functional competency to
which they belong.
• Different teams perform different tasks of the project and the
work products pass from team to team till the completion of
the project.
• For example, requirement analysis will be performed by the
requirement team, design by the design team, and so on.
Functional Format
Top management
Functional groups
Project progress
Planning
Project team 1
Analysis
Project team 2
Design
.
.
.
Coding
Testing
Deployment
Maintenance
Figure 3.6: Functional format
Project team n
Matrix Format
• It is a multidimensional structure which takes the best of the
project format and the functional format.
• The functional structure is designed for each project and it
then proceeds in the project format.
• Each development project is assigned to a project manager.
• The project manager participates in most of the activities of
product development.
• People with similar specialization are pooled for work
assignments.
• Each specialist may have to work under several managers to
perform his job.
Matrix Format
Top management
Product
manager 1
Analysis
Design
Coding
Testing
Sub
projects
Sub
projects
Sub
projects
Sub
projects
Product
manager 2
Product
manager n
Figure 3.7: Matrix format
Maintenance
Sub
projects
Project Manager
• Is the person who has the overall responsibility for the
successful planning, execution, monitoring, control, and
closure of a project.
• The project manager is responsible for making decisions,
handling risks, and minimizing uncertainty in product
development.
• Project managers use project management software to organize
their tasks and workforce.
• Project manager is the one who tackles all the project-related
issues at both development and customer site.
• During project management, project manager coordinates and
communicates with upper-level managers and lower-level
engineers working on the project.
Project Manager’s Activities
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Defining project scope, goals, and deliverables that support the business goals
Project planning and sequencing
Planning resources and budget
Identifying and resolving the issues and conflicts within the project team
Developing schedules, project timelines, and milestones
Time and cost estimation
Developing and delivering proposals, documentation, and presentations
Identifying and resolving risks
Monitoring and reporting progress reports
Team leadership to coach, mentor, motivate, and supervise the stakeholders
Strategic planning and influencing
Business relationships for project success
Performing scalability, interoperability, and portability analysis
Controlling quality and defining parameters to achieve a quality product
Conducting project postmortems and preparing a recommendations report in order to identify
the successful and unsuccessful project elements
Developing best practices and tools for project execution and management
Managing the client relationship
Project Manager’s Roles and Skills
• Role
– Leader
– Manager
– Facilitator
– Mentor
• Skills
– Personal Skills
– Technical Skills
– Managerial Skills
– Adoptive Skills
Project Life Cycle
• A project life cycle is a collection of project phases.
• A typical project life cycle has four major phases,
– Initiation
– Planning
– Execution
– Closure
• A project must successfully complete each project phase
before proceeding to the next phase.
Project Life Cycle
Project success
and review
Project
closing
Monitoring
and control
Project
initiation
Project life cycle
Project
execution
Figure 3.8: Project life cycle
Project
definition
Project
planning
Detailed planning
Project Initiation
• Project is initiated by defining its purpose and scope, the
justification for initiating it, and the solution to be
implemented.
• Once the project is confirmed, a project team is formally
introduced that will work on the client's project.
• A project plan is developed that defines the critical aspects of
the project.
• This project plan focuses on the identification of stakeholders,
assumptions, contingencies, and risks.
• Business objectives are set with minor and major milestones
and success criteria for the project.
Project Planning
• The planning phase is considered the most important phase in the
project life cycle.
• A more detailed project plan with resource requirements, financial
issues, quality parameters, and acceptance criteria is defined.
• This phase minimizes the time, cost, confusion, and rework during
the execution of the project.
• It defines the project activities to be performed, the products that
will be produced, and how these activities will be carried out and
managed.
• This phase also defines the major tasks.
• It more accurately estimates the time, resources, and cost required
and provides a framework for management review and control.
Project Execution
• In this phase, the deliverables are physically built and
presented to the customer for acceptance.
• Project management processes are undertaken to monitor and
control the construction of deliverables in the project.
• These processes include time, cost, quality, change, risks
issues, suppliers, customers, and communication management.
• Once all the deliverables have been produced and the customer
has accepted the final solution, the project is ready for closure.
Project Closure
• It is the last major phase of the project life cycle .
• The project closure phase puts emphasis on releasing the final
deliverables to the customer, handing over the project
documentation to the business, terminating supplier contracts,
releasing project resources, and communicating the closure of
the project for all stakeholders.
• The organization records the lessons learned in the project,
which will help the future project teams.
Project v/s Product Life Cycle
• Project life cycle and product life cycle both are separate
processes used in every organization.
• Project is executed to produce a product and product is the
outcome of a project.
• The product life cycle starts with a business plan with
several ideas or features to be incorporated in the software
product.
• Software product is then developed and installed in
customer site for operation.
• During its operational life, it goes through maintenance
activities and finally it is reengineered on modern platform.
• The project life cycle goes through a series of phases to
develop the product.
• Project life cycle defines the tasks to be accomplished in
each phase and a team is responsible for each phase defined.
Project v/s Product Life Cycle
Concep
t
Initiating
Product
development
Plannin
g
Operation and
maintenance Retiremen
t
Executing
Product life
cycle
Closing
Project life cycle
Task
Control
Progress and monitoring
Development
process
Figure 3.9: Relationship between project life cycle and product life cycle
Project Management Process
• The project management process concentrates on planning and
managing a series of activities that need to be accomplished
within a specific time and a budget.
• Coordination among all these activities requires a systematic
process for the success a project.
• Project management processes govern project management
activities, such as project feasibility, quality, timeliness,
budget, efficiency, and resource mobilization.
• The main focus of the project management process is to
execute the development process in an optimal manner.
Project Management Process
• The project management process is a series of actions directed
toward a particular result.
• The Project Management Book of Knowledge (PMBOK)
defines five project management process groups:
– Initiating,
– Planning,
– Executing,
– Monitoring and Controlling,
– Closing.
• Each of the five project management process groups is
characterized by the completion of a certain task in the project.
• Team members complete each phase of the project
management process before beginning the next phase.
Software Configuration Management
• Software configuration management is concerned with
identification, tracking, and change of control of software
configuration.
• Software configuration management (SCM) or configuration
management (CM) is the discipline of identifying the configuration
of a system at any time for the purpose of systematically controlling
changes to the configuration throughout the system life cycle.
• The purpose of CM is to establish and maintain the integrity of a
software product throughout software the development life cycle.
• The CM process improves product visibility, product protection,
product control, customer confidence, and team communication.
• A systematic CM process reduces rework, confusions, and project
risks
Software Configuration Management
• The project management process provides a systematic
CM plan and monitors the status of the SCM process.
• The configuration management officer (CMO)
implements and maintains the CM process according to
the CM plan.
• The CMO coordinates, supports, and performs the CM
activities and reports to the project manager.
• The Configuration Control Board (CCB) approves and
disapproves the changes to be performed in the product.
• The CCB consists of technical and administrative
representatives for configuration planning and
execution.
• The approved changes are performed through the
development process.
Software Configuration Management
Configuration
management process
Planning data
Project
management
process
CM plan
Work products,
change requests
Status reports and audits
results
Approved change
requests, controlled work
products
Product development process
Figure 3.10: Software configuration management process
Software Configuration Management
• The CM process consists of the following four
activities
– Configuration identification
– Configuration change control
– Configuration status accounting
– Configuration auditing
Configuration
identification
Configuration
change control
Configuration
status accounting
Configuration
audits
Figure 3.11: Configuration management activities
Configuration Identification
• A software configuration item (SCI) or configuration item (CI) is a
work product that is designated for configuration management.
• The SCI activity identifies items to be controlled, establishes
identification schemes for the items and their versions, and
establishes the tools and techniques to be used in acquiring and
managing controlled items.
• The work products in SCI may include plans, process descriptions,
requirements, design data and models, product specifications, source
codes, compilers, product data files, etc.
• The status of the CIs at a given point in time is called baseline.
• Each new baseline is the sum total of an older baseline plus a series
of approved changes done on the CI.
• A baseline together with all approved changes to the baseline
represents the current configuration.
Configuration Change Control
• The purpose of software configuration change control (CC) is to
manage changes during the software life cycle.
• The activities of CC are to identify what changes to make, the
authority for approving changes, and support for the implementation
of those changes.
• The outcome of CC is useful in measuring change traffic, breakage,
and aspects of rework.
• A change request (CR) for changes to software configuration items
may be originated by anyone at any point in the software life cycle
and may include a suggested solution and requested priority.
• The CRs are usually recorded on the software change request (SCR)
form.
• Once an SCR is received, a technical evaluation is performed to
determine the extent of modifications that would be necessary
should the change request be accepted.
• An established authority, Configuration Control Board (CCB), will
evaluate the technical and managerial aspects of the change request
and accept, modify, reject, or defer the proposed change.
Configuration Status Accounting
• The software configuration status accounting records and
reports the information needed for effective management of
the software configuration.
• It is the bookkeeping process of each release for CIs.
• The CI are identified, collected, and maintained for the
status accounting.
• The reported information can be used by the development
team, the maintenance team and for project management
and quality assurance activities.
• A database is maintained for providing the status accounting
of configuration requests.
• This procedure involves tracking what is in each version of
software and the changes that lead to this version.
• It keeps a record of all the changes made to the previous
baseline to reach the new baseline.
Configuration Auditing
• Configuration auditing determines the extent to
which an item satisfies the required
functionalities.
• Configuration audit is performed to evaluate the
conformance of software products and processes
to applicable regulations, standards, guidelines,
plans, and procedures.
• Auditing is performed according to a well-defined
process consisting of various auditor roles and
responsibilities.
• Expertise of people is required and some
automated tools also support the planning and
conduct of an audit process.
Risk Management
• Risk is an unfavorable situation that may lead to an
undesirable outcome.
• Potential problems or losses are also called risks. Risk may
include product estimation, business issues, customer, process,
technology, development environment, and project planning.
• Risk management is a proactive approach for minimizing the
uncertainty and potential problems associated with a project by
providing insights to support informed decision making.
• It is an ongoing activity from the initiation to the retirement of
a software product.
Risk Management
• Software risk management is necessary for the
following reasons:
– To reduce the rework caused by missing, erroneous, or
ambiguous requirements, design, or code, which
typically consumes 40–50% of the total cost of
software development
– To avoid software project disasters, including overrun
of budgets and schedules, defect-ridden software
products, and operational failures
– To stimulate a win-win software solution where the
customer receives the product they need and the
vendor makes the profits they expect.
– To keep provision for the detection and prevention
mechanisms of risks.
Risk Categories
• Risks basically threaten the project, product, and hence the
business.
• There are basically three categories of risk occurrence:
– Project Risks
– Products Risks
– Business Risks
Risk Management Activities
• Some risks have great effect and some risks
may be tolerated.
• Risks must be analyzed to find their potential
and remedial actions.
• The risk management process includes the
following activities:
– Risk Identification
– Risk Analysis
– Risk Planning
– Risk Monitoring and Control
Risk Management Activities
Risk
identification
Risk analysis
and
evaluation
Risk
planning
Risk
monitoring
and control
Potential risks
Risk
influences
Risk
resolution
plan
Risk
assessment
Figure 3.11: Risk Management Process
Risk Identification
• Potential risks are identified with their consequences,
effects, sources, root causes, and categories.
• The output of this activity is a list of project-specific
risks that have the potential of compromising the
project's success.
• There are various types of risks that may arise.
–
–
–
–
–
–
Requirements Risks
Technology Risks
Organizational Risks
Tools Risks
Human Resources Risks
Estimation Risks and so on.
Risk Identification Techniques
• Brainstorming is a preferred technique because of its
flexibility and capability of generating a wide and diverse
range of risks.
• Risk identification is performed on the basis of historical
data, theoretical analysis, empirical data and analysis,
informed opinions of the project team and other experts,
and the concerns of stakeholders.
• Other techniques are:
–
–
–
–
–
–
Interviewing
Reporting
Decomposition
Assumption analysis
Critical Path Analysis
Utilization of Risk Taxonomies
Risk Analysis
• Each risk is analyzed independently by examining the
identified risk and assessing its impact, probability, risk
exposure, and seriousness.
• The list of risks is then grouped and prioritized/ranked based
on the results of risk analysis.
• Risk prioritization helps in resource allocation and
management.
– RE = Probability (UO) x Loss (UO), where RE is risk
exposure and UO is unexpected outcome.
Risk Planning
• Once the risks are identified and prioritized, an
appropriate risk management plan is developed
for modifying the risks.
• General risk management strategies are
– Risk Avoidance
– Risk Minimization
– Risk Acceptance
– Risk Transfer
Risk Monitoring and Control
• Risk monitoring and control ensures new risks are
detected and managed.
• Risk action plans are implemented to reduce the impact
of risks.
• Policies and standards compliances are regularly
carried out and the standard performance is reviewed to
identify the opportunities for improvement.
• The monitoring process provides assurance that
appropriate controls have been taken for the
organization’s activities and that the procedures are in
place.
• If needed, changes are made in the organizational
environment to cope with risks.
Summary
•
•
•
•
•
•
•
•
•
Effective project management is the key to project success and organizational growth.
There are four essential elements of software project management: project, people,
process, and product.
The project manager is a person who has the overall responsibility for project success.
There are three types of team structure: chief programmer, hierarchical, and egoless
team structures.
A project life cycle is a collection of project phases: initiation, planning, execution, and
closure.
It has five project management process groups: initiating, planning, executing,
monitoring and controlling, and closing.
The configuration management process consists of four activities: configuration
identification, configuration change control, configuration status accounting, and
configuration audits.
Risk management is a proactive approach for minimizing the uncertainty and potential
problems associated with a project by providing insights to support informed decision
making.
The risk management process includes risk identification, risk analysis, risk planning,
and risk monitoring and control.
Chapter - 4
Project Planning and Estimation
Introduction
• A successful project is possible only through good project
planning.
• Project planning concentrates on estimating resources, time,
budgets, and monitoring and controlling the activities of
project management.
• At the beginning of project planning, all the project
constraints, such as staff and other requirements, overall
budget, starting and ending dates, schedule, etc., are defined
and the project manager has their details.
• During project planning, future estimates are planned for an
effective project management.
67
Introduction
• The project plan provides the basis for performing and
managing the activities of a software project and addresses the
commitment to stakeholder’s resource constraints and
capabilities of the software project.
• A bad project management plan leads to project failures and
sometimes projects are cancelled.
• The main goal of the project plan is to establish a pragmatic
strategy for controlling, tracking, and monitoring a project.
• A typical project plan includes project scope, project estimates,
schedule, requirements, risk management plan, control
strategy, and various other plans.
68
Project Planning Activities
• The project planning activities include both business-level and technicallevel planning.
• Business-level planning addresses the relationships with the customer.
• Includes the project and business objectives, proposal writing, analysis
and inclusion of functional requirements, product demand and its scope,
and legal issues.
• Technical-level planning focuses on performing the technical activities.
• concentrates on technical issues, such as selection of the development life
cycle model, planning documentation methods and tools, risk
management planning, estimations, financial planning, resource allocation
and management, team structuring and organization, software
development life cycle plan, documentation plan, configuration
management plan, quality assurance plan, transition plan, and so on.
69
Project Planning Activities
• A project plan includes various activities related to project
management.
• A general project plan includes the following project planning
activities, beginning with project initiation to project
completion.
– Defining business objectives
and project scope
– Project estimations
– Project scheduling
– Resource planning
– Financial planning
– Staffing-level planning
– Development planning
– Project monitoring and control
plan
– Risk management planning
– Quality assurance planning
– Configuration management
planning
– Miscellaneous plans
70
Project Planning Activities
• Defining business objectives and project scope:
– Business objective gives a clearly defined target that will
be achieved through proper planning by the team.
– Project scope defines the parameters of the project with
constraints for what the project will attempt to do.
– The need for product development and its demand in the
market must be stated.
– A proposal is written that will work as a contract for the
project.
– Functional requirements are analysed to prepare a good
project plan.
– Legal issues, such as patent, copyright, liability, warranty
etc., Must be specified well in advance.
71
Project Planning Activities
• Project estimations:
– Project estimation includes cost, size, duration, project
complexity, and resource requirements.
– The cost involves both
 direct cost (i.e. efforts made directly on the project; for
example, time spent on developing the code, testing, etc.) and
 indirect cost (i.e. the amount spent on telephone, Internet,
etc.).
– Estimation of size is the basis of project delivery and other
estimations.
– Some projects are very simple to develop and other projects are
so complex that they may take considerable amount of time for
development.
– Project complexity determines the project duration and resource
requirements.
72
Project Planning Activities
• Project scheduling:
– It emphasizes defining the start and completion time for each
task in the project.
– The tasks are decomposed into manageable pieces that can be
easily developed within the stipulated time and constraints.
– There are various tools and techniques used for project
scheduling, such as:
 Work Breakdown Structures (WBS),
 Activity Network Diagram (AND),
 PERT-CPM,
 Gantt charts, and so on.
73
Project Planning Activities
• Resource planning:
– Usually multiple projects run in an organization.
– Each project manager will try to reserve the resources in advance
according to the project schedule and functional requirements.
– The resources can be hardware, software, and people. Most of
the organizations start recruiting people in advance.
74
Project Planning Activities
• Financial planning:
– Every project is concerned with financial plans.
– These plans provide the assurance that the project has the funds
to accomplish its objectives.
– A cost estimation process is used to determine how money will
be spent in software project management.
– A cost-benefit analysis is carried out to estimate the budget for
personnel expenses, purchase orders, automated items, and
purchase of other items.
75
Project Planning Activities
• Staffing-level planning:
– Staffing-level planning organizes the team and accurately
estimates the number of personnel required for the project.
– A module-wise estimation is done to avoid resource conflicts.
– Due to the lack of engineers, organizations may use their skills
and expertise in multiple projects.
• Development planning:
– A software project is developed as a series of technical activities,
such as analysis, design, coding, testing, verification and validation,
deployment, documentation, training, maintenance, and so on.
– The project plan provides details on who will perform which task,
how it will be performed, what support tools are required, and
various such activities.
– The software development life cycle is also chosen before
proceeding to development planning.
76
Project Planning Activities
• Project monitoring and control plan:
– The project monitoring plan assesses the progress of a project as
to whether it is moving in the right direction or not.
– This plan helps in controlling the execution of activities.
– The project is monitored according to the project schedule for
cost, time, efforts, and defects.
• Risk management planning:
– The risk management plan assures that problems are discovered
in early stages and appropriate strategy has been made to handle
the risk.
– While managing risks, the cost, quality, and schedule estimates
should be within constraints.
– Most organizations put their efforts to minimize risks.
77
Project Planning Activities
• Quality assurance planning:
– Product milestones are rigorously tested to find uncovered
defects.
– Quality assurance aims to prevent errors and assures that the
delivered product exhibits high quality.
– There are some standards that provide certain guidelines and
procedures to produce a quality product.
78
Project Planning Activities
• Configuration management planning:
– The configuration management plan encompasses the discipline
that addresses identifying and controlling changes to the work
products.
– The configuration management plan includes configuration
identification, configuration change control procedure,
monitoring and tracking changes, and auditing of the changes.
• Miscellaneous plans:
– There are various miscellaneous plans, such as process tailoring,
special testing plan, verification and validation plan, tools and
environment plan, delivery plan, and maintenance plan.
79
Software Metrics and Measurements
• Software metric is the unit of measurement of software
product, project, and process attributes.
• Software metrics are the measures that are used to quantify
products, processes, and projects.
• Measuring software process or project provides a foundation
to predict the parameters of project planning.
• Effective use of metrics helps to measure product quality,
manage projects, and assess processes.
• Metrics provide necessary information for monitoring the
progress of the project.
80
Software Metrics and Measurements
• There are three types of metrics used in software projects:
– Product metrics,
– Process metrics,
– Project metrics.
• Product metrics:
– Product metrics are used to measure product characteristics
such as product quality factors, such as reliability,
maintainability, defects, and product operational
characteristics.
81
Software Metrics and Measurements
Process metrics:
– Process metrics assess the effectiveness of software
processes and ensure conformance of standards and
guidelines.
– Process metrics provide some attributes that help to
improve the process maturity.
Project metrics:
– Project metrics are used to monitor the project plan, track
progress, and estimate the project attributes.
– It measures the size, cost, efforts, schedule, and risks.
– Generally, projects are assessed on the basis of past project
experiences and data.
82
Project Size Estimation
• Size measurement is the initial step for estimating the other
attributes of software.
• It is a direct measurement, which is based on the problem size.
• Programs written in any programming language have some size,
whether the program is an assembly code, a high-level language
code, a GUI code, or a component of a programming language.
• There are various units of size measurement, such as
– Lines of code (LOC),
– Function point (FP),
– Token count (TC),
– Fuzzy logic sizing,
– Object point (OC),
– Standard component sizing, and many more.
83
Project Size Estimation
Lines of Code
– A line of code (LOC) metric is based on the measurement of the
source lines of the code in a program.
– It is simply measured by counting the program header,
declarations, executable, and non-executable lines in the source
program.
– Comments lines, blank lines, and header lines are usually not
considered during the LOC measurement.
– LOC is generally counted in kilo (thousand) line of codes
(KLOC) per person-month (PM).
84
Project Size Estimation
Lines of Code
– Size measurement of the source lines helps to measure
 Defects per KLOC,
 Errors per KLOC,
 Dollars per KLOC,
 Pages of documentation per KLOC, and so on.
– Size estimation is performed by decomposing a problem into
manageable modules.
– Small-size modules can easily be predicted for LOC counting.
– The overall project size is the sum of the sizes of all modules in
the project.
85
Project Size Estimation
Example of LOC
/* This program finds a substring in a given start = atoi(argv[2]);
string */
end = atoi(argv[3]);
strncpy(temp,argv[1]+start,end);
#include<stdio.h>
temp[end]='\0';
#include<conio.h>
printf("entered string : %s\n ",argv[1]);
#include <string.h>
printf("\nsubstring : %s ",temp);
}
void main(int argc,char * argv[])
else
{
char *temp;
printf("incorrect arrgument ");
int start, end ;
getch();
clrscr();
}
if(argc==4)
{
LOC = LOC counted as 17.
Figure 4.1: A program to find a substring in a string
86
Project Size Estimation
Lines of Code : Disadvantages
– The value of LOC measurement varies with the programmer,
programming language, and the project complexity.
– Every programmer has different technical skills, programming
styles, and logical ability. Therefore, the LOC value may differ
during estimation.
– Different programming languages have their different
programming techniques. The actual number of the source lines
may vary in programs.
– LOC only considers the source code. But some projects are
highly complex and they need much effort at the design and
analysis phases.
87
Project Size Estimation
Lines of Code : Disadvantages
– LOC is not suitable for component or reuse- based
programming technologies where the components are
considered as the unit of measurement.
– Also, it is very difficult to accurately estimate the project
size from the requirement specification or project nature.
– There is a lack of standard tools for counting the source
lines.
– The quality of code is the main focus for quality software,
which is poorly considered during size measurement.
88
Project Size Estimation
Function Point Analysis
– To overcome the limitations of the LOC-based measurement,
Alan Albrecht proposed another size estimation technique called
the function point (FP) analysis.
– The size of the project is estimated on the basis of functions or
services requested by the customer in the requirement
specification.
– It is a structured technique that decomposes systems down into
smaller components so that they can be better understood and
analysed.
– It relies on the product features delivered to the customer.
– The actual number of function points can be verified at the end
of each stage of a project.
89
Project Size Estimation
Function Point Analysis : Advantages
– FP measurement is programming language independent and
programmer independent.
– It does not have any constraint specific to the hardware,
procedural or non-procedural languages.
– It is very easy to predict the function points in the final product
from the requirement specification.
– More accurate estimates are possible in the early stages of
software development.
– An important aspect of FP is the consideration of user’s view
through requirement specification or problem description along
with developers view during requirement decomposition for the
FP analysis.
90
Project Size Estimation
Function Point Analysis
– FP-based estimations are based on the following five information
domain values and their complexities in a particular project.
 Number of inputs
 Number of outputs
 Number of inquiries
 Number of internal logical files
 Number of external interfaces
– The value of each of these five information domains is collected and a
subjective evaluation is performed to categorize them as simple,
average, and complex.
91
Project Size Estimation
Function Point Analysis
– There are certain weights assigned at each complexity level to
the information domains:
Information domain
Weights
Simple
Average
Complex
Number of inputs
3
4
6
Number of outputs
4
5
7
Number of inquiries
3
4
6
Number of internal logical files
7
10
15
Number of external interfaces
5
7
10
Table 4.1: Information domains and their weights
92
Project Size Estimation
Function Point Analysis: Method
1. Calculate the unadjusted function point (UFP).
 It is calculated by simply counting the value of each
information domain and multiplying it by an
appropriate weight at its complexity level.
2. Compute the complexity adjustment attributes (CAA).
 The CAAs are complexity attributes (14) that can vary
from project to project. They are computed using the
following relationship:
CAA = [0.65 + 0.01 × ∑ CAAi], where CAA is the
complexity adjustment attributes.
3. Then, compute FP = UFP × CAA.
93
Project Size Estimation
Example 4.1
Compute the FP value for the grade calculation of students.
Assume that it is an average complexity size project. The
information domain values are as follows: number of inputs =
13, number of outputs = 4, number of inquiries = 2, number of
external files = 5, number of interfaces = 2. The total value of
complexity adjustment attributes is 13.
94
Project Size Estimation
Solution 4.1:
Calculation of UFP for average complexity size project:
= (Number of inputs) × 4 + (Number of outputs) × 5 + (Number of
inquiries) × 4 + (Number of files) × 10 + (Number of interfaces) × 7
= 13 × 4 + 4 × 5 + 2 × 4 + 5 × 10 + 2 × 7 = 175
Compute CAA, which has the value = 13
= 0.65 + 0.01 × (13 × 3)
= 0.65 + 0.01 × 39
= 1.04
Compute FP = UFP × CAA
= 175 × 1.04 = 182
Thus, the total value of FP is 182.
95
Project Size Estimation
Function Point Analysis: Benefits
• It accurately estimates the project cost, project duration,
and project staffing size.
• It is helpful to monitor the productivity level of a project.
• It is also useful in managing change of scope and in
communicating the functional requirements.
• The FP computation is useful to find other metrics, such
as project defect per FP, cost per FP, FP per hour
productivity, and so on.
96
Project Size Estimation
Feature Point Metric
• The feature point metric is an extension of the function points that
includes the algorithmic complexity of the software.
• An algorithm is a step-wise procedure with defined rules which are
designed to solve a significant computational problem.
• For example, a sine routine can be considered as an algorithm. Each
algorithm is assigned a weight ranging from 1 (elementary) to 10
(sophisticated algorithms).
• The feature point metric is the weighted sum of algorithms plus the
function points.
• It is especially useful for systems with a few inputs/outputs and a
high algorithmic complexity, such as mathematical software, CAD,
AI, discrete simulations, and military applications.
97
Effort Estimation
• Effort estimation predicts how much time is required to complete a
project, how much it costs, and how many engineers are required for
completing the project.
• The effort estimation is important for cost-benefit determination,
project scheduling, and monitoring and control.
• The effort estimation is a continuing activity that starts with project
proposal.
• More accurate estimates are possible as the project proceeds, i.e.,
during the feasibility study, requirement analysis, design, and
subsequent phases.
• There are various factors that affect cost estimation such as,
capability of engineers, product complexity, product size,
availability of delivery time, required reliability, and the level of
technology.
98
Effort Estimation Approaches
The top-down approach
• The top-down approach estimates the project cost globally by
estimating the system level costs of the overall project size.
• The system level cost includes the cost of resources for product
development, configuration management, quality assurance,
integration, installation, and deployment.
• It requires minimum project details and it is usually faster and easier
to adopt.
• This approach does not consider other technical requirements for
specific modules.
• In case of underestimation or overestimation, an inaccurate result of
effort estimate may be produced that may lead to an under-budget or
over-budget project.
99
Effort Estimation Approaches
The bottom-up approach
• In the bottom-up approach, the cost of individual modules is
estimated and then all these costs are integrated to estimate the
overall project cost.
• This approach can produce more accurate estimate due to the
consideration of discrete parts for estimation.
• It is more stable as estimation errors in modules can be rectified and
balanced. But someone may overlook the system-level costs, such as
quality assurance cost, configuration management cost, etc.
• Size estimate is the primary need for both top-down and bottom-up
approaches.
100
Effort Estimation Techniques
• There are different techniques for effort estimation. Some of
the most popular estimation techniques are
– Estimation by analogy,
– Delphi estimation,
– Algorithmic cost modelling, and
– Analytical techniques
101
Effort Estimation Techniques
Estimation by analogy
• The estimation-by-analogy technique is based on the experiences of
the past projects.
• The estimation-by-analogy method involves an expert for finding
the analogous situations so as to give his opinion.
• This technique follows a top-down estimation approach.
• The project to be assessed is characterized on certain factors that
become the basis for finding similar or analogous projects which
have been completed and their efforts are known.
• Then the proposed project is compared with the previously
completed similar projects.
• These effort values are then used with some adjustments to estimate
the efforts for the proposed project.
102
Effort Estimation Techniques
Estimation by analogy: Problems
• The estimators have to determine how best they can
characterize the projects in terms of application domain, the
number of inputs, the number of distinct entities referenced,
the number of screens, and so on.
• Another problem after project characterization is to determine
similarity: how much confidence we can place in the analogies
and how many projects need to be compared.
• A few analogies might lead to maverick projects being used
and too many analogies might lead to dilution of the effect of
the closest analogies.
• Lastly, it is very difficult what variables should be considered
to estimate the new projects with known effort values from the
analogous projects.
• Means and weighted means can give more influence to the
closer analogies.
103
Effort Estimation Techniques
Delphi estimation
• Delphi cost estimation is a group consensus technique that relies on
expert judgment and follows the top-down estimation approach with
certain features of the bottom-up approach.
• The coordinator interacts with experts for providing necessary
information and documents.
• The estimators go through the requirement document and make their
estimates anonymously.
• The coordinator compiles the estimation reports and distributes a
summary of the estimation responses.
• The estimation report specifies any unusual characteristic noted by
the estimators.
• The coordinator can call a group meeting of experts to discuss
points if the estimates vary widely.
• The estimation is iterated for as many rounds as appropriate for an
accurate estimate.
104
Effort Estimation Techniques
Delphi estimation: Benefits
• The experts use their experiences of the past projects to assess the
factors in the proposed project.
• Each expert applies their distinguished expertise and knowledge to
assess the project.
• There is less chance for bias due to group consensus.
• There are rare chances of bias if only a few experts, maybe one or
two, are involved in the estimation process.
Delphi estimation: Problems
• The team may take pain in gathering some information that may not
be useful for estimation in the proposed project.
• This method is very difficult to quantify.
• It is hard to document the factors used by the experts or expert
groups.
105
Effort Estimation Techniques
Algorithmic cost models
• Algorithmic cost models use size estimation model, which is based
upon certain project parameters.
• The value of these parameters depends on the project type:
– Organic projects are very simple and can be developed with a small-size team.
The team should have good application experience and should be familiar with
the application environments. A simple data processing system is a good
example of the organic category.
– Embedded projects are very complex and have stringent constraints, for
example, flight control system for aircraft.
– Semidetached projects are intermediate in size and complexity. The team
should have mixed experience to meet the mix of rigid and less-than-rigid
requirements. A transaction processing system with fixed requirements for
terminal hardware and database software is an example of the semi-detached
category.
106
Effort Estimation Techniques
COCOMO Model
• COCOMO (COnstructive COst MOdel) is an algorithmic cost
estimation technique proposed by Boehm, which works in a bottomup manner.
• It is designed to provide some mathematical equations to estimate
software projects.
• These mathematical equations are based on historical data and use
project size in the form of KLOC.
• The COCOMO model uses a multivariable size estimation model
for effort estimation.
• A multivariable model depends on several variables, such as
development environment, user involvement, memory constraints,
technique used, etc.
107
Effort Estimation Techniques
COCOMO Model
• A single variable model is based only upon the size of the project,
which is given as
Effort = a × Size b
• The constants a and b are derived from the historical data of the past
projects in the organizations.
• The values of a and b in COCOMO model vary across the three
categories of projects: organic, semidetached, and embedded, as
shown in Table 4.2.
Project category
a
b
Organic
3.2
1.05
Semidetached
3.0
1.12
Embedded
2.8
1.20
Table 4.2: The values of a and b constants
108
Effort Estimation Techniques
COCOMO Model
• COCOMO estimation is a family of hierarchical models, which
includes
– Basic,
– Intermediate, and
– Detailed COCOMO models.
• Each of the models initially estimates efforts based on the total
estimated KLOC.
109
Effort Estimation Techniques
Basic COCOMO Model
• The basic COCOMO model estimates effort in a function of the
estimated KLOC in the proposed project.
• The basic COCOMO model is very simple, quick, and applicable to
small to medium organic-type projects. It is given as follows:
Development effort (E) = a × (KLOC) b
Development time (T) = c × (E) d
• Where a, b, c, and d are constants and these values are determined
from the historical data of the past projects.
• The development time (T) is calculated from the initial development
effort (E).
110
Effort Estimation Techniques
Basic COCOMO Model
• The values of c and d for organic-, semidetached-, and
embedded-type projects are shown in Table 4.3.
Project category
c
d
Organic
2.5
0.38
Semi-detached
2.5
0.35
Embedded
2.5
0.32
Table 4.3: The values of c and d constants
111
Basic COCOMO Model
• Example 4.2
Assume that a system for simple student registration in a
course is planned to be developed and its estimated size is
approximately 10,000 lines of code. The organization is
proposed to pay Rs. 25000 per month to software
engineers. Compute the development effort, development
time, and the total cost for product development.
112
Basic COCOMO Model
Solution 4.2:
• The project can be considered an organic project. Thus, from
the basic COCOMO model,
Development effort (E) = 3.2 × (10) 1.05 = 35.90 PM
Development time (T) = 2.5 × (35.90) 0.38 = 9.747 months
• Total product development cost = Development time ×
Salaries of engineers
= 9.747 × 25000
= Rs. 2,43,675
113
Effort Estimation Techniques
Intermediate COCOMO Model
• Boehm has introduced 15 cost drivers, considering the various
aspects of product development environment.
• These cost drivers are used to adjust the project complexity for
estimation of effort and these are termed as effort adjustment factors
(EAF).
• These cost drivers are classified as computer attributes, product
attributes, project attributes, and personnel attributes.
• The intermediate COCOMO model computes software development
effort as a function of the program size and a set of cost drivers.
• The intermediate COCOMO model estimates the initial effort using
the basic COCOMO model. Then the EAF is calculated as the
product of 15 cost drivers.
114
Effort Estimation Techniques
Intermediate COCOMO Model
• Total effort is determined by multiplying the initial effort with the
total value of EAF. The computation steps are summarized below.
• Development effort (E):
–Initial effort (Ei) = a × (KLOC) b
–EAF= EAF1 × EAF2 ×... × EAFn
–Total development effort (E)= Ei × EAF
• Development time (T) = c * (E) d
115
Intermediate COCOMO Model
Cost drivers
Cost drivers
Product attributes
Software reliability (RELY)
Size of database (DATA)
Product complexity (CPLX)
Hardware attributes
Run-time performance constraints (TIME)
Memory storage constraints (STORE)
Virtual machine volatility (VIRT)
Required turnabout time (TURN)
Personnel attributes
Analyst capability (ACAP)
Applications experience (AEXP)
Programmer capability (PCAP)
Virtual machine experience (VEXP)
Programming language experience (LEXP)
Project attributes
Modern programming practices (MODP)
Use of software tools (TOOL)
Development schedule (SCHED)
Very
low
Low
Ratings
Nominal
High
0.75
0.70
0.88
0.94
0.85
1.00
1.00
1.00
1.15
1.08
1.15
1.40
1.16
1.30
1.65
-
0.87
0.87
1.00
1.00
1.00
1.00
1.11
1.06
1.15
1.07
1.30
1.21
1.30
1.15
1.66
1.56
-
1.46
1.29
1.42
1.21
1.14
1.19
1.13
1.17
1.10
1.07
1.00
1.00
1.00
1.00
1.00
0.86
0.91
0.86
0.90
0.95
0.71
0.82
0.70
-
-
1.24
1.24
1.23
1.10
1.10
1.08
1.00
1.00
1.00
0.91
0.91
1.04
0.82
0.83
1.10
-
Very high
Extr
a
high
116
Intermediate COCOMO Model
Example 4.3
Suppose a library management system (LMS) is to be designed for an
academic institution. From the project proposal, the following five major
components are identified:
Online data entry 1.0 KLOC
Data update
2.0 KLOC
File input and output
1.5 KLOC
Library reports
2.0 KLOC
Query and search
0.5 KLOC
The database size and application experience are very important in this
project. The use of the software tool and the main storage is highly
considerable. The virtual machine experience and its volatility can be kept
low. All other cost drivers have nominal requirements. Use the COCOMO
model to estimate the development effort and the development time.
117
Intermediate COCOMO Model
Solution 4.3:
The LMS project can be considered an organic category project. The total
size of the modules is 7 KLOC. The development effort and development
time can be calculated as follows:
Development effort
Initial effort (Ei)
= 3.2 × (7) 1.05 =
24.6889 PM
EAF = 1.16 × 0.82 × 0.91 × 1.06 × 1.10 × 0.87 = 0.8780
Total effort (E) =
Ei * EAF
=
24.6889 × 0.8780
=
21.6785 PM
Development time (T) =
2.5 × (E) 0.38 month
=
2.5 (21.6785) 0.38 month
=
8.0469 month
118
Effort Estimation Techniques
Detailed COCOMO Model
• The detailed COCOMO model inherits all the features of the intermediate
COCOMO model for the overall estimation of the project cost.
• The detailed COCOMO model uses different effort multipliers (cost
drivers) for each phase of the project.
• Phase-wise effort multipliers provide better estimates than the intermediate
model.
• The detailed COCOMO model defines five life cycle phases for effort
distribution:
– plan and requirement,
– system design,
– detailed design,
– code and unit test, and
– integration and test.
119
Effort Estimation Techniques
Detailed COCOMO Model
• In the detailed COCOMO model, effort is calculated as a
function of size in terms of KLOC and the value of a set of
cost drivers according to each phase of the software life cycle.
• If the project size varies majorly from the value taken in the
phase-wise distribution, then interpolation formula can be
applied to find the more appropriate percentage value.
• The detailed COCOMO model illustrates the importance of
recognizing different levels of predictability at each phase of
the development cycle.
120
Detailed COCOMO Model
Table 4.4: Phase-wise distribution of the development effort and time
Project type and size
Plan and
requirement
System
design
Detailed
design
Code and unit
test
Integration and
test
Percentage-wise distribution of the development effort
Organic (2 KLOC)
6
16
26
42
16
Organic (32 KLOC)
6
16
24
38
22
Semi-detached (32 KLOC)
7
17
25
33
25
Semi-detached (128 KLOC)
7
17
24
31
28
Embedded (128 KLOC)
8
18
25
26
31
Embedded (320 KLOC)
8
18
24
24
34
Percentage-wise distribution of the development time
Organic (2 KLOC)
10
19
24
39
18
Organic (32 KLOC)
12
19
21
34
26
Semi-detached (32 KLOC)
20
26
21
27
26
Semi-detached (128 KLOC)
22
27
19
25
29
Embedded (128 KLOC)
36
36
18
18
28
Embedded (320 KLOC)
40
38
16
16
30
121
Detailed COCOMO Model
Example 4.4
Compute the phase-wise development effort for the problem
discussed in Example 4.3.
122
Detailed COCOMO Model
Solution 4.4:
There are five components in the organic project discussed in Example 4.3:
online data entry, data update, file input and output, library reports, query
and search. The estimated effort (E) is 21.6785 PM. The total size is 7
KLOC, which is between 2 KLOC and 32 KLOC. Thus, the actual
percentage of effort can be calculated as follows:
Plan and requirement (%) = 6 + (6 - 6) / (32 - 2) × 7
= 6%
Effort
= 0.06 × 21.6785 PM
= 1.30071 PM
System design
= 16 + (16 - 16) / (32 - 2) × 7= 16%
Effort
= 0.16 × 21.6785 PM
= 3.46856 PM
Detailed design
= 24 + (26 - 24) / (32 - 2) × 7 = 25%
Effort
= 0.25 × 21.6785 PM
= 5.419625 PM
Code and unit test
= 38 + (42 - 38) / (32 - 2) × 7 = 39%
Effort
= 0.39 × 21.6785 PM
= 8.454615 PM
Integration and test
= 22 + (16 - 22) / (32 - 2) × 7 = 24%
= 0.24 × 21.6785 PM
= 5.20284 PM
123
Effort Estimation Techniques
COCOMO I Model
• The basic, intermediate, and detailed COCOMO models are in the
category of COCOMO I and these are collectively known as
COCOMO 81.
• The COCOMO I models were developed to estimate the effort,
schedule, and cost of a software project.
• The three variations of COCOMO I use different types of
parameters for estimation.
• These models are helpful to produce repeatable estimations.
• It is unable to deal with exceptional conditions, such as exceptional
teamwork, exceptional people involved in the estimation process,
etc.
• Rough sizing of projects and inaccurate cost driver rating will result
in an inaccurate estimation.
124
Effort Estimation Techniques
COCOMO II Model
• COCOMO II is an extension to the original COCOMO 81 model.
• Since the development of COCOMO 81, software development techniques
have changed.
• These changes have changed the development processes from linear to
spiral and one-go to incremental way for developing simple to complex
projects.
• Programming techniques and technologies have moved from conventional
to component-based software development.
• Thus, a new, enhanced COCOMO II model was proposed to overcome the
limitations of COCOMO 81.
• It consists of sub-models, each one providing unique features for project
planning and design process. These sub-models are called
– The applications composition model,
– Early design model,
– Post-architecture model, and
– Reuse model.
125
Effort Estimation Techniques
Application Composition Model
• The application composition model is best suitable for prototyping projects
and projects where there is extensive reuse of components.
• It involves prototyping efforts to resolve unexpected risks related to GUI,
device interaction, performance, or technology maturity.
• The estimation is based on the standard estimates of the developer
productivity in object points/months and the use of CASE tools to support
development.
• The effort estimation in an application is computed as follows:
Effort (E) = (∑AP × (1 - %reuse/100))/ PROD
• ∑AP is the sum of application points in the system to be developed. PROD is
the productivity of programmers from the historical data rated on some scale.
• The PROD for the past projects is rated as very low = 4, low = 7, nominal =
13, high = 15, and very high = 50. Effort (E) will be measured in personmonths (PM). %reuse is the percentage of reusable components that will be
reused in the application.
126
Effort Estimation Techniques
Early Design Model
•
•
•
•
•
The early design model is used when requirements are available but design has
not yet commenced.
It involves exploration of an alternative architecture or concept of operation.
The estimation formula based on simple COCOMO is given as follows:
Effort (E) = A × Size B × EAF
A and B are constants. The value of A is fixed at 2.94 from a large data set.
The value of B varies with the project size and it can range from 1.1 to 1.24,
depending on the project complexity, process maturity level, development
flexibility, risk resolution processes, and cohesion of the development team in
an organization.
EAF is the effort adjustment factor based on seven characteristics of projects
and processes such as, product reliability and complexity (RCPX), reuse
required (RUSE), platform difficulty (PDIF), personnel capability (PERS),
personnel experience (PREX), schedule (SCED) and support facilities (FCIL).
127
Effort Estimation Techniques
Post-Architecture Model
• This model is used once the system architecture has been designed
and sufficient information is available for the development and
maintenance of the system.
• Estimation is determined using the estimation formula of early
design model as follows:
Effort (E) = A × Size B × EAF
• SLOC or FP can be used for determining the project size.
• There are 17 instead of 7 multiplicative cost drivers.
128
Effort Estimation Techniques
Post-Architecture Model: Multiplicative cost drivers
Cost drivers
Attributes
Category
Required system reliability
RELY
Product
Product complexity
CPLX
Product
Required level of documentation
DOCU
Product
Database size
DATA
Product
Percentage of reusable components
RUSE
Product
Execution time constraint
TIME
Computer
Development platform volatility
PVOL
Computer
Memory constraints
STOR
Computer
Analysts capability
ACAP
Personnel
Personnel continuity
PCON
Personnel
Programmer capability
PCAP
Personnel
Programmer experience in application
PEXP
Personnel
Analyst experience in project domain
AEXP
Personnel
Language and tool experience
LTEX
Personnel
Use of software tools
TOOL
Project
Development schedule
SCED
Project
Multisite working
SITE
Project
129
Effort Estimation Techniques
Post-Architecture Model
• The following five factors determine the project’s scaling exponent
B. The value of these factors is added (for example, here it is 16)
and their value in percentage (i.e. .16) is added to 1.01 to get a value
of 1.17.
Precedentedness
--New project
--Rated low (4)
Development flexibility
--No client involvement
--Rated very high (1)
Architecture/risk resolution
--No risk analysis carried out --Rated very low (5)
Team cohesion
--New team
--Rated nominal (3)
Process maturity
--Process in control
--Rated nominal (3)
130
Effort Estimation Techniques
Reuse Model
• The reuse model focuses on system development with reuse.
• It helps to monitor the progress of reuse-based development and
guides to the investment for producing reusable assets and reusing
them in development.
• The cost of system development with reuse involves the cost
incurred in design, implementation, generalization, testing,
documentation, library support, and integration of reusable assents.
• The level of reuse in a system is defined as the total size of the
system divided by the size of the reusable components in the
system.
• The level of reuse can be used to monitor reuse and to estimate the
cost, time, quality, and productivity.
131
Effort Estimation Techniques
Reuse Model
• The cost of system development can be assessed by the cost of
system development with reuse and without reuse.
• The cost of software can be measured as:
Total cost (CS)
= Cost of the reused software + Cost of the software
without reuse
= (Relative cost of the reused software ×
Reused software) + (Relative cost of the
software without reuse × Software without reuse)
= (CR × Rѕ ) + (CRW × (1- Rѕ ))
= (CR × Rѕ )+ (1× (1- Rѕ ))
= 1+ Rѕ (CR - 1)
132
Effort Estimation Techniques
Analytical techniques
• Halstead has proposed analytical estimation technique based upon
certain assumptions about the project.
• From the science of Halstead, the length and volume of code can be
measured. The length of a code is used to measure the length of the
source code program. It is defined as follows:
N = N1 + N2
• Where N1 is the total number of operator occurrences, and N2 is the
total number of operand occurrences.
• The volume metric is used to measure the amount of storage space
required for the program. It is defined as:
V = N log (n1 + n2)
• Where n1 is the number of distinct operators, and n2 is the number
of distinct operands that occur in a program.
• Analytical estimation is manly useful for estimating software efforts
in maintenance, scheduling, and reporting projects.
133
Staffing and Personnel Planning
• Project managers fix the staff requirement early in the project because
multiple projects may be running in the organization.
• The number of staff varies at different times as the project progresses.
• The staff requirement increases during the system design, detailed
design, coding, and testing times.
• The staff requirement decreases during integration, deployment and
training, and documentation.
• Norden in 1958 analysed several research and development projects
and studied the staffing patterns in the software development cycle.
• He observed that the staffing pattern can be approximated by the
Rayleigh distribution curve as shown in Figure 4.2 and the Rayleigh
curve can represented by the equation:
E = K/t²d × t × e-t²/2t²d
134
Staffing and Personnel Planning
E
Effort per unit
time
E = K/t²d × t × e-t²/2t²d
K
(Total effort
area)
td
Time
Figure 4.2: The Rayleigh curve
• The Rayleigh curve
represents the relationship
between effort (E) and time
(td) at any point of time.
• E indicates the staffing
requirement at any particular
time during the duration of
the project.
• K is the total area under the
curve, which represents the
total effort requirements for
the project. td is the time at
which the curve reaches its
maximum value.
135
Staffing and Personnel Planning
• In 1976, Putnam subsequently analysed various army projects using
the Rayleigh curve for determining the personnel level of effort
required in the software life cycle
• Putnam found that td in Norden’s equation is the time when a project
reaches the testing and integration and deployment stage.
• After observing a large number of projects, Putnam derived the
following expression for the personnel level effort pattern in any
project:
S = Ck K1/3 t4/3d
• Where S is the product size in KLOC and Ck represents the
technological aspects that may affect productivity.
• K is the total effort in person-month required yearly and td represents
the time taken from project initiation to product deployment.
136
Staffing and Personnel Planning
• Staffing level estimation is used to determine the personnel
level requirement in different tasks and phases of the
development cycle.
• Personnel planning concentrates on estimating and allocating
the right person to the right task at the right time during project
execution.
• The personnel requirement is determined by dividing the total
effort by the development time.
• The project manager then recruits the required personnel in the
project. Thereafter, the team is composed and responsibilities
are allocated to the team members corresponding to their
skills.
137
Project Scheduling and Milestones
• A project schedule is built to answer what tasks will be
accomplished when, how, and by whom.
• In project scheduling, the overall effort and staff are
distributed across the project duration for each task in the
project.
• PMI’s PMBOK defines the project schedule as the planned
dates for carrying out the scheduled activities and the planned
dates for meeting the schedule milestones
• A schedule milestone is an end point of a task while
performing an activity in the process.
138
Project Scheduling and Milestones
• Project scheduling activities
– Task identification
– Work breakdown structure
– Task interdependency
– Time allocation
– Resource allocation
– Monitoring, tracking, and control
139
Project Scheduling and Milestones
Task Identification
• Task identification focuses on identifying all the activities and tasks
before considering the delivery dates and resource constraints.
• The tasks are decided based upon the nature of the project, which
can be a new development project, reengineering project,
enhancement project, etc.
• There are various factors that influence the project tasks, such as
project size, project staff, project complexity, mission criticality,
reengineering factors, number of potential users, requirements
stability, and the maturity of technology.
• Task identification begins with the mission and vision of the project.
Top-down and bottom-up approaches can be used for the preparation
of the task list.
140
Project Scheduling and Milestones
Task Identification: Example
Mission critical system
T1 Mission critical system
T1.1 Risk analysis
T1.2 Prototype construction
T1.3 Requirement analysis
T1.4 Design
T1.4.1 System architecture
T1.4.2 System design
T1.4.2.1 Input design
T1.4.2.2 Database design
T1.4.2.3 Output design
T1.4.3 Detailed design
T1.5 Coding
T1.6 Testing
T1.6.1 Unit test
T1.6.2 Integration test
T1.6.3 System test
T1.6.3.1 Stress testing
T1.6.3.2 Performance testing
T1.6.3.3 Volume testing
T1.6.3.4 Security testing
T1.6.4 Acceptance testing
T1.7 Deployment
141
Project Scheduling and Milestones
Work Breakdown Structure
• The work breakdown structure (WBS) shows the project details of
tasks, making it easier to understand and communicate them
throughout the project life cycle.
• The WBS represents a hierarchical breakdown of a project into
elements.
• The total work of the project is divided into manageable elements
with increasing levels of detail.
• The upper levels of the WBS are typically major deliverables of the
project.
• The lower levels are the refinements of the upper level.
• A properly structured WBS helps to improve the accuracy of cost
estimates by estimating the costs of the lower-level elements.
• It provides a mechanism for performance measurement and control
level by level.
142
Project Scheduling and Milestones
Work Breakdown Structure for Mission Critical System
Mission critical system
Risk
analysis
Prototype
construction
System
architecture
Input
design
System
design
Output
design
Requirement
analysis
Detailed
design
Database
design
Design
Unit
testing
Stress
testing
Testing
Deployment
Integration
testing
Acceptance
testing
Coding
System
testing
Performance
testing
Figure 4.4: Work breakdown structure
Recovery
testing
143
Project Scheduling and Milestones
Task interdependency
• Task interdependency represents the dependency relationship
or the sequence of tasks between a pair of activities.
• WBS is converted into an activity network diagram (AND) that
shows the task interdependency in the project.
• The activity network diagram is designed using
– Project Evaluation and Review Technique (PERT)
– Critical Path Method (CPM).
144
Project Scheduling and Milestones
PERT-CPM Method
• PERT is a network-based representation of tasks or activities
to determine the task interdependency.
• It represents the precedence or parallel relationships among the
tasks in a project.
• A PERT diagram has the following construction rules:
– Each task or activity is represented as a node in boxes.
– Arrow shows the dependencies between tasks or activities.
– There is a start node, which has only an outgoing arrow,
and an end node, which has only incoming arrows.
– An arrow pointing to a node comes from its predecessor
activity, which must be completed before a task can begin.
145
Project Scheduling and Milestones
PERT-CPM Method
– Arrows pointing out of a task box go to its successor tasks,
which cannot start until at least this task is complete.
– For example, T1 is the predecessor of T2 in the following
diagram. T2 cannot start until T1 is completed.
Predecessor
T1
Task 1
Time duration
Successor
T2
Task 2
146
Project Scheduling and Milestones
• Based upon the details of WBS and the sequence of activities,
an activity network diagram is drawn which shows the
sequence of serial and parallel activities in the project.
• There is no cycle in the activity network diagram.
• The expected completion time in days is shown inside the
nodes, along with the activities.
• The duration of the project is equal to the longest path from
the start to the finish node of the network.
• A path in the network diagram is one of the routes following
the arcs from the start to the finish node.
• The length of a path is the sum of the expected estimated
durations of the activities on the path.
147
Project Scheduling and Milestones
Example: Activity network diagram
Input
design, 6
Start, 0
Architectural
design, 10
Output
design, 6
Database
design, 13
Finish, 0
Detailed
design, 18
Figure 4.5: Activity network diagram
148
Project Scheduling and Milestones
PERT-CPM Method
• The duration of the project must be at least the length of the longest
path.
• Thus, the estimated project duration equals the length of the longest
path through the project network.
• This longest path is called the critical path.
• For larger projects, it may be helpful to determine the following
values for each activity:
– Earliest Start time (TES): It is the earliest time an activity may
begin after allowing the preceding activities to finish. Earliest
start time (TES) = max (TEF of immediate predecessors).
– Earliest Finish time (TEF): It is the earliest time an activity may
finish after allowing the preceding activities to finish. Earliest
finish time (TEF) = TES + Activity duration.
• TES and TEF are calculated in the forward pass through the network
diagram.
149
Project Scheduling and Milestones
PERT-CPM Method
• Sometimes activities take longer than the expected time duration that may
delay project completion.
• So, to determine how much late an activity can start or finish without
delaying project completion as:
– Latest Start time (TLS): It is the latest time an activity may begin
without delaying project completion. Latest start time (TLS) = TLF Activity duration.
– Latest Finish time (TLF): It is the latest time an activity may finish
without delaying project completion. Latest finish time = TLF = min
(TLS of immediate successors).
– Slack time (TS): The slack time for an activity is the difference between
its latest finish time and its earliest finish time. Slack time (TS) = TLF
– TEF = TLS – TES.
• The backward pass through the network diagram is made starting with the
final activities and moving backward in time toward the initial activities to
calculate TLS and TLF.
150
Project Scheduling and Milestones
PERT-CPM Method
TES = 10
TEF = 16
Input
design, 6
TES== 00
TEF== 00
Start, 0
TLS = 0
TLF = 0
TES = 0
TEF = 10
Architectural
design, 10
TLS = 0
TLF = 10
TLS = 17
TLF = 23
TES = 10
TEF = 23
Database
design, 13
TLS = 10
TLF= 23
TES = 10
TEF= 28
Detailed
design, 18
TES = 23
TEF = 29
Output
design, 6
TLS = 23
TLF = 29
TES = 29
TEF = 29
Finish, 0
TLS = 29
TLF = 29
TLS = 11
TLF = 29
Figure 4.6: PERT with the critical path
151
Project Scheduling and Milestones
PERT-CPM Method
• There are some activities having no slack and other activities have
slack time. The critical path then is the path through the network in
which none of the activities have slack.
• Each activity with zero slack is on the critical path through the
project network such that any delay along this path will delay
project completion.
• The critical path is shown in Figure 4.6 with dark arrows in the
network diagram.
• The critical path is:
Start node > Architectural design > Database design > Output design > Finish node
152
Project Scheduling and Milestones
PERT-CPM Method
• Advantage:
– PERT is useful to determine the expected project completion
time, the probability of completion before a specified date, and
the start and end dates.
– It helps to find the critical path activities that directly influence
the completion time.
• Limitation:
– The time estimates for activities are somewhat subjective and
depend on judgment.
– If there is little experience in performing an activity, the time is
fixed only by an educated guess.
153
Project Scheduling and Milestones
Time allocation
• The project time can be estimated based on certain
assumptions and the experience of estimating the likely
estimates of the activities in the project.
• Therefore, the estimation of time duration for a project
includes three time estimates:
– Optimistic time (TO): It is the shortest time in which the
activity can be completed.
– Most likely time (TM): It is the completion time having the
highest probability.
– Pessimistic time (TP): It is the longest time that an activity
might require.
154
Project Scheduling and Milestones
Time allocation
• The expected time for each activity can be approximated using
the following weighted average:
Expected time (T) = (TO + 4 × TM + TP)/6
• This expected time might be displayed on the network diagram
along with the activities in boxes.
• The variance for each activity is determined as:
[(TP - TO)/6]2
• The variance in the total project durations is the sum of the
variances of the activity duration on the critical path.
• This is helpful for project managers in determining the
completion time of the project.
155
Project Scheduling and Milestones
Resource allocation
• A Gantt chart is a horizontal bar chart that provides a graphical
illustration of a project schedule.
• It is commonly used for scheduling the tasks, allocating the
resources, and tracking the progress of projects.
• Drawing a Gantt chart requires tasks, duration of the tasks, and
resources requirements to complete the tasks. Gantt charts are also
useful for monitoring the progress of the project.
• In a Gantt chart, activities are generally shown vertically on the lefthand side and the horizontal bar indicates the start date, end date,
and duration of each activity.
156
Project Scheduling and Milestones
Resource allocation
Task name
Duration Start
(days)
date
Architectural
10
20/01/11
design
Input
6
2/01/11
design
Database
13
31/01/11
design
Detailed
18
31/02/11
design
Output
6
13/02/11
design
End date Jan
20
30/01/11
Jan
30
Feb
12
Feb
18
25/01/11
12/02/11
11/02/11
18/03/11
Figure 4.7: Gantt chart for software design
157
Project Scheduling and Milestones
Monitoring, Tracking, and Control
• There are several methods for monitoring, tracking, and controlling
the project activities.
• Some automated tools such as Microsoft Project, SMART, etc., are
also used for monitoring the projects.
• The most popular methods used for project monitoring and tracking
are
– Review meetings,
– Cost-schedule milestone graphs,
– Status reporting,
– Earn value methods, and so on.
158
Project Scheduling and Milestones
Monitoring, Tracking, and Control
• Review meetings
– Review meetings are conducted to ensure that the planned schedule is
executed within time and appropriate resources.
– Project managers conduct review meetings regularly to check the status
of all the tasks specified in the Gantt chart.
• Status reporting
– In status reporting, each member of the project records the status of
their assigned tasks.
– The project manager calls periodical project status meetings and each
member reports the current status of the tasks.
– The problems faced by the team members are discussed in the status
meeting. The project status meeting is generally called weekly or
quarterly.
159
Project Scheduling and Milestones
Monitoring, Tracking, and Control
• Cost-schedule milestone graph
– The cost-schedule milestone graph is a graphical representation
of the progress of a project.
– The project progress is measured monthly or at the interval
decided by the project manager through the cost estimated
against the planned schedule.
– At each milestone, the actual cost is compared with the schedule.
A variation represents the fluctuation in the planned cost and
planned schedule.
160
Project Scheduling and Milestones
Monitoring, Tracking, and Control
• Earn value analysis
– The earn value analysis is a quantitative analysis to determine the
progress of a project.
– Each task is given an earn value, i.e., the effort decided during project
planning in the ratios of the project size.
– The earn value of each task is summed and thus it is the total cost that
is estimated.
– This value is compared with the actual cost reported in the costschedule or status reporting document.
– The project manager can find the progress of the project and the
deviation in the cost or schedule.
161
Miscellaneous Plans
 Planning for the development life cycle
 Configuration management plan
 Risk management plan
 Quality assurance plan
 System testing plan
 Deployment plan
162
Summary
• Project planning is necessary for devising resources and budgets, for
monitoring and controlling the activities of project management.
• Software metrics are used to measure products, processes, and projects.
• There are various units of size measurement, such as lines of code (LOC),
function point (FP), token count (TC), fuzzy logic sizing, object point
(OC), standard component sizing, etc.
• The most popular estimation techniques are estimation by analogy, Delphi
estimation, algorithmic cost modelling, and analytical technique. Project
scheduling is an important responsibility performed by project managers in
order to complete the project in a successful manner.
• Each activity and process of project development is planned before
execution.
• These plans are the selection of the development life cycle, configuration
management plan, risk management plan, quality assurance plan, system
testing plan, and deployment plan.
163