CHAPTER 3

MANAGING SOFTWARE PROJECT

Software Metrics
Terminologies
• Measure: Quantitative indication of the extent, amount, dimension, or size of some
attribute of a product or process.
• Metrics: The degree to which a system, component, or process possesses a given attribute.
Relates several measures (e.g. average number of errors found per person hour)
• Indicators: A combination of metrics that provides insight into the software process, project or
product
• Direct Metrics: Immediately measurable attributes (e.g. line of code, execution speed, defects
reported)
• Indirect Metrics: Aspects that are not immediately quantifiable (e.g. functionality, quantity,
reliability)
• Faults:
– Errors: Faults found by the practitioners during software development
– Defects: Faults found by the customers after release

Metric Classification
• Processes
– Activities related to production of software
• Products
– Explicit results of software development activities.
– Deliverables, documentation, by products
• Project
– Inputs into the software development activities
– hardware, knowledge, people

Process Metrics
• Process metrics are collected across all projects and over long periods of time. Their intent
is to provide a set of process indicators that lead to long-term software process
improvement.
• Focus on quality achieved as a consequence of a repeatable or managed process.
• Strategic and Long Term.
• Statistical Software Process
Improvement (SSPI). Error
Categorization and Analysis:
– All errors and defects are categorized by origin
 – The cost to correct each error and defect is recorded
– The number of errors and defects in each category is computed
– Data is analyzed to find categories that result in the highest cost to the organization
– Plans are developed to modify the process

Project Metrics
• Project metrics enable a software project manager to assess the status of an ongoing
project, track potential risks, uncover problem areas before they go “critical,” adjust work
flow or tasks, and evaluate the project team’s ability to control quality of software work
products.
• Project metrics on most software projects occurs during estimation.
• Metrics collected from past projects are used as a basis from which effort and time
estimates are made for current software work.Production rates represented in terms of
models created, review hours, function points, and delivered source lines are measured.
• These metrics are used to minimize the development schedule by making the adjustments
necessary to avoid delays and mitigate potential problems and risks.
• Project metrics are used to assess product quality on an ongoing basis and, when necessary,
modify the technical approach to improve quality.

Product Metrics
• Focus on the quality of deliverables
• Product metrics are combined across several projects to produce process metrics
• Metrics for the product:
– Measures of the Analysis Model
– Complexity of the Design Model
– Internal algorithmic complexity
– Architectural complexity
– Data flow complexity
– Code metrics

Software Measurement
• Direct Measures (internal attributes)
– Cost, effort, LOC, speed, memory
• Indirect Measures (external attributes)
– Functionality, quality, complexity, efficiency, reliability, maintainability

Size Oriented metrics

• Size-oriented software metrics are derived by normalizing quality and/or productivity
measures by considering the size of the software that has been produced.
• simple size-oriented metrics for each project:
– Errors per KLOC (thousand lines of code)
 – Defects per KLOC
– $ per KLOC
– Pages of documentation per KLOC
– Errors per person-month
– KLOC per person-month
– $ per page of documentation

Function-Oriented metrics
• Function-oriented software metrics use a measure of the functionality delivered by the
application as a normalization value.
• The most widely used function-oriented metric is the function point (FP).
• Computation of the function point is based on characteristics of the software’s information
domain and
complexity.
Object-Oriented Metrics
• Object-Oriented Metrics Conventional software project metrics (LOC or FP) can be used to
estimate object-oriented software projects.
• However, these metrics do not provide enough granularity for the schedule and effort
adjustments that are required as you iterate through an evolutionary or incremental
process.

Use-Case–Oriented Metrics
• Like FP, the use case is defined early in the software process, allowing it to be used for
estimation before significant modeling and construction activities are initiated.
• Use cases describe (indirectly, at least) user-visible functions and features that are basic
requirements for a system. The use case is independent of programming language.
• Because use cases can be created at vastly different levels of abstraction, there is no standard
“size” for a
use case.
• Without a standard measure of what a use case is, its application as a normalization
measure (e.g., effort expended per use case) is suspect.

COCOMO Model (Empirical Process Model)

• Stands for Constructive Cost Model
• As with all estimation models, it requires sizing information and accepts it in three forms:
object points, function points, and lines of source code
• Application composition model - Used during the early stages of software engineering
when the following are important
– Prototyping of user interfaces
– Consideration of software and system interaction
– Assessment of performance
 – Evaluation of technology maturity
• Early design stage model – Used once requirements have been stabilized and basic
software architecture has been established
• Post-architecture stage model – Used during the construction of the software

Organic, Semidetached and Embedded software projects

• Organic: A development project can be considered of organic type, if the project deals with
developing a well understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar types of
projects.
• Semidetached: A development project can be considered of semidetached type, if the
development consists of a mixture of experienced and inexperienced staff. Team members
may have limited experience on related systems but may be unfamiliar with some aspects
of the system being developed.
• Embedded: A development project is considered to be of embedded type, if the software
being developed is strongly coupled to complex hardware, or if the stringent regulations on
the operational procedures exist.
The basic COCOMO model gives an approximate estimate of the project parameters. The basic
COCOMO estimation model is given by following expressions:
Effort = a1 x (KLOC)a2 PM (person Month)

Time of Development = b1 x (Effort) b2 Months

Where, a1,a2,b1,b2 are constants for each category of software products

Estimation of Effort
Organic: Effort = 2.4
(KLOC) 1.05 PM Semi-
detached: Effort = 3.0 (KLOC)
1.12
PM Embedded: Effort =
1.20
3.6 (KLOC) PM
Estimation Time of
Development

Organic: Time of Development = 2.5 (Effort) 0.38 Months

Semi-detached: Time of Development = 2.5 (Effort)
0.35
Months Embedded: Time of Development
0.32
= 2.5 (Effort) Months

Example:
Assume that the size of an organic s/w product has been estimated to be 32,000 lines of source
code. Assume that the average salary of software be Rs. 15,000/- month. Determine the effort
required to develop the software product and the nominal development time.
Effort= 2.4 x (32) 1.05 = 91 PM
Time of development = 2.5 x (91) 0.38
= 14 months Cost= 14 x 15,000 = Rs.
2,10,000/-

Risk Management
• A risk is a potential problem – it might happen and it might not
• Conceptual definition of risk
– Risk concerns future happenings
– Risk involves change in mind, opinion, actions, places, etc.
– Risk involves choice and the uncertainty that choice entails
• Two characteristics of risk
Uncertainty – the risk may or may not happen, that is, there are no 100% risks (those, instead, are
called constraints)
Loss – the risk becomes a reality and unwanted consequences or losses occur

Categories of risk
• Project risks
– They threaten the project plan
– If they become real, it is likely that the project schedule will slip and that costs will increase
• Technical risks
– They threaten the quality and timeliness of the software to be produced
– If they become real, implementation may become difficult or impossible
• Business risks
– They threaten the feasibility of the software to be built
– If they become real, they threaten the project or the product
• Known risks
– Those risks that can be uncovered after careful evaluation of the project plan, the
business and technical environment in which the project is being developed, and other
reliable information sources (e.g., unrealistic delivery date)
• Predictable risks
– Those risks that are deduced from past project experience (e.g., past turnover)
• Unpredictable risks
– Those risks that can and do occur, but are extremely difficult to identify in advance

Sub-Categories of risk
• Market risk – building an excellent product or system that no one really wants
• Strategic risk – building a product that no longer fits into the overall business strategy for the
 company
• Sales risk – building a product that the sales force doesn't understand how to sell
• Management risk – losing the support of senior management due to a change in focus or a
change in people
• Budget risk – losing budgetary or personnel commitment

Risk Identification
• One method for identifying risks is to create a risk item checklist.
• The checklist can be used for risk identification and focuses on some subset of known and
predictable risks in the following generic subcategories:
• Product size—risks associated with the overall size of the software to be built or modified.
• Business impact—risks associated with constraints imposed by management or the marketplace.
• Stakeholder characteristics—risks associated with the sophistication of the stakeholders and
the
developer’s ability to communicate with stakeholders in a timely manner.
• Process definition—risks associated with the degree to which the software process has
been defined and is followed by the development organization.
• Development environment—risks associated with the availability and quality of the tools to
be used to build the product.
• Technology to be built—risks associated with the complexity of the system to be built and the
“newness”
of the technology that is packaged by the system.
• Staff size and experience—risks associated with the overall technical and project experience
of the software engineers who will do the work.

Risk Estimation / Risk Projection

Risk Projection Steps
• Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low, 10-high)
• Explain the consequences of the risk
• Estimate the impact of the risk on the project and product
• Note the overall accuracy of the risk projection so that there will be no misunderstandings

Risk Mitigation, Monitoring, and Management

• Risk mitigation (proactive planning for risk avoidance)
• Risk monitoring (assessing whether predicted risks occur or not, ensuring risk aversion steps
are being properly applied, collect information for future risk analysis, attempt to
determine which risks caused which problems)
• Risk management and contingency planning (actions to be taken in the event that
mitigation steps have failed and the risk has become a live problem)
• The goal of the risk mitigation, monitoring and management plan is to identify as many
potential risks as possible.
• When all risks have been identified, they will then be evaluated to determine their
probability of occurrence,
• Plans will then be made to avoid each risk, to track each risk to determine if it is more or
less likely to occur, and to plan for those risks should they occur.
• It is the organization’s responsibility to perform risk mitigation, monitoring, and management in
order to

produce a quality product.

• The quicker the risks can be identified and avoided, the smaller the chances of having to
face that particular risk’s consequence.
• The fewer consequences suffered as a result of good RMMM plan, the better the product,
and the smoother the development process.

Risk Mitigation
• To mitigate this risk, you would develop a strategy for reducing turnover. Among the
possible steps to be taken are:
• Meet with current staff to determine causes for turnover (e.g., poor working conditions,
low pay, and competitive job market).
• Mitigate those causes that are under your control before the project starts.
• Once the project commences, assume turnover will occur and develop techniques to ensure
continuity when people leave.
• Organize project teams so that information about each development activity is widely dispersed.
• Define work product standards and establish mechanisms to be sure that all models and
documents are developed in a timely manner.
• Conduct peer reviews of all work (so that more than one person is “up to speed”).
• Assign a backup staff member for every critical technologist.

Risk Monitoring
• The project manager monitors factors that may provide an indication of whether the risk is
becoming more or less likely.
• In the case of high staff turnover, the general attitude of team members based on project
pressures, the degree to which the team has jelled, inter-personal relationships among
team members, potential problems with compensation and benefits, and the availability of
jobs within the company and outside it are all monitored.
• In addition to monitoring these factors, a project manager should monitor the effectiveness
of risk mitigation steps.
• The project manager should monitor work products carefully to ensure that each can stand
on its own and that each imparts information that would be necessary if a newcomer were
forced to join the software team somewhere in the middle of the project.

Risk Management
• Risk management and contingency planning assumes that mitigation efforts have failed and
 that the risk has become a reality.
• If the mitigation strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team.
• In addition, you can temporarily refocus resources (and readjust the project schedule) to
those functions that are fully staffed, enabling newcomers who must be added to the team
to “get up to speed.” Those individuals who are leaving are asked to stop all work and
spend their last weeks in “knowledge transfer mode.”

Project Scheduling
• Software project scheduling is an action that distributes estimated effort across the
planned project duration by allocating the effort to specific software engineering tasks.
• It is important to note, however, that the schedule evolves over time.
• During early stages of project planning, a macroscopic schedule is developed.
• This type of schedule identifies all major process framework activities and the product
functions to which they are applied.

Scheduling Principles
• Compartmentalization
The product and process must be decomposed into a manageable number of activities and tasks
• Interdependency
Tasks that can be completed in parallel must be separated from those that must completed
serially
• Time allocation
Every task has start and completion dates that take the task interdependencies into account
• Effort validation
Project manager must ensure that on any given day there are enough staff members
assigned to completed the tasks within the time estimated in the project plan
• Defined Responsibilities
Every scheduled task needs to be assigned to a specific team member
• Defined outcomes
Every task in the schedule needs to have a defined outcome (usually a work product or
deliverable)
• Defined milestones
A milestone is accomplished when one or more work products from an engineering task
have passed quality review

Scheduling
 • Scheduling of a software project does not differ greatly from scheduling of any multitask
engineering effort.
• Therefore, generalized project scheduling tools and techniques can be applied with little
modification for software projects.
• Program evaluation and review technique (PERT) and the critical path method (CPM) are
two project scheduling methods that can be applied to software development.
• Both techniques are driven by information already developed in earlier project planning
activities: estimates of effort, a decomposition of the product function, the selection of the
appropriate process model and task set, and decomposition of the tasks that are selected.
• Both PERT and CPM provide quantitative tools that allow you to
(1) Determine the critical path—the chain of tasks that determines the duration of the project
(2) Establish “most likely” time estimates for individual tasks by applying statistical models
Calculate “boundary times” that define a time “window” for a particular task

Project Tracking
• The project schedule provides a road map for a software project manager.
• It defines the tasks and milestones.
• Several ways to track a project schedule:
– conducting periodic project status meeting
– evaluating the review results in the software process
– determine if formal project milestones have been accomplished
– compare actual start date to planned start date for each task
– informal meeting with practitioners
• Project manager takes the control of the schedule in the aspects of:
– project staffing
– project problems
– project resources
– reviews
– project budget

Software Project Planning

• The objective of software project planning is to provide a framework that enables the
manager to make reasonable estimates of resources, cost, and schedule.
• In addition, estimates should attempt to define best-case and worst-case scenarios so that
project outcomes can be bounded. Although there is an inherent degree of uncertainty, the
software team embarks on a plan that has been established as a consequence of these
 tasks.
• Therefore, the plan must be adapted and updated as the project proceeds.

Task Set for Project Planning

1. Establish project scope.
2. Determine feasibility.
3. Analyze risks.
4. Define required resources.
a. Determine required human resources.
b. Define reusable software resources.
c. Identify environmental resources.
5. Estimate cost and effort.
a. Decompose the problem.
b. Develop two or more estimates using size, function points, process tasks, or use cases.
c. Reconcile the estimates.
6. Develop a project schedule.
a. Establish a meaningful task set.
b. Define a task network.
c. Use scheduling tools to develop a time-line chart.
d. Define schedule tracking,mechanisms.