UNIT V - PROJECT MANAGEMENT

Estimation – FP Based, LOC Based, Make/Buy Decision, COCOMO II - Planning – Project Plan, Planning Process, RFP
Risk Management – Identification, Projection, RMMM - Scheduling and Tracking –Relationship between people and
effort, Task Set & Network, Scheduling, EVA - Process And Project Metrics.

5.SOFTWARE PROJECT MANAGEMENT

Effective software project management focuses on the four P’s: People (stakeholders), product, process,
and project.
Stake holder: Stakeholder is a one who affected by the system. Including management, developer,
engineers, customers and end users.
1. Estimation
2. Scheduling
3. Risk management
5.1 Software project estimation: (cost,time,effort)
 Software cost, time and effort estimation never be exactly done till we finish the project.
 Many factors can affect the estimation (human, technical, environmental, political).
Various methods:
1. Decomposition method(LOC,FP)
2. Empirical estimation model(COCOMO)
3. Automated tools
Decomposition method:
1. LOC based estimation(Line Of Code)
2. FP based estimation(Function Points)

5.1.1 LOC based estimation:

 Line of code is a metric used to measure the size of software for estimation mainly by counting the
 number of lines needs to be written in the source code.
 It’s mainly used for small sized projects where it applies to most accurately.
 SLOC is directly proportional to the effort needed to build an application.
 There are 2 types of measures for lines of code: physical and logical.
 Physical SLOC is measured by counting the number of lines including, blank lines, and
comments.
 Logical SLOC is based on number of statements which then depend on technology and
language being used.
Programming language Vs LOC
Language LOC

C 100
C++ 85
JAVA 50

Calculating Total LOC

Modules LOC
Of a project
Login 85
Connectivity 50
Client page 50
Server page 50
Total LOC 235
 S=Sopt+4Sm+Spes
6
Sopt : Optimistic Size
Sm : Medium size
Spes: Pessimistic size

Guidelines for counting LOC:

 Each counted line must contain only one source statement.
  Count all delivered executable statements.
 Count data definitions once.
 Do not count lines that contain only comments
  Do not count debug or temporary code
 Count all the invocations or inclusions of the macros
 Translate the number of lines of code to assembly language equivalent lines so that comparisons
can be made across the projects.
Advantages:
 Widely used and accepted.
  Allows the comparison of size & productivity across development groups.
 It relates to the end product directly.
 Easiest way of measurement upon project completion.
Disadvantages:
  Difficult to measure LOC in the early stages of a new product.
 Source instructions vary with coding languages, design methods and with programmer’s ability.
 No industry standard for measuring LOC.
 LOC cannot be used for normalizing if platforms and languages are different.
 The only way to predict LOC for a new app to be developed is through the reference from similar
software application.


5.1.2 FP Based estimation:

 Function point is software metric used to measure the functions that software must
 provide to the user.
 The benefit of using function point over SLOC is that it is independent of the
developer’s experience and technology or programming language being used.
 It begins by identifying functional user requirements and categorizing each one of them into
outputs, inquiries, inputs, internal files and external files.
 Next, the function is identified for its complexity and it is assigned a number referring to function
 points.
 Each of these functions must map to a user requirement.
 At last each functional point is converted into LOC in order to calculate cost and effort.

FP=UFP*TCF
FP: Function points/Adjusted Function points
UFP: Unadjusted function points
TCF: Technical complexity factor/Complexity Adjustment Factor/Value Adjustment Factor
Guidelines for counting function points:

  Count number of functions in each category.

  Apply complexity weight factors.

  Apply Environmental factors.

  Calculate complexity adjustment factor.

  Compute adjusted functional points.

 Convert to LOC.
Advantages of function point analysis.
 It can be applied early in the software development life cycle.
 It is independent of the programming language, technology, techniques.
 It provides a reliable relationship to effort.
  Creation of more function points can define productivity goal as opposed to LOC.
 Productivity of projects written in different languages can be measured.
 They can be counted early and often.
 It considers environmental factors.
Disadvantages of function point analysis.
 It needs subjective evaluations with a lot of judgment involved.
  Many effort and cost models are based on LOC, so function points need to be converted.
  Less research data is available on function points as compared to LOC.
 It is performed after creation of design specifications.

5.1.3 Empirical estimation model (COCOMO)
 It is most widely used software estimation model in the world.
 It will predict the effort and duration of the project.
Three different models:
1. The basic model
2. The intermediate model
3. The detailed model
(i)The basic model
 Computes software development effort and cost as a function of programme size expressed in
terms of lines of code(LOC).
Three modes of projects:
Mode Project size Nature of project Deadline
Organic 2-50 KLOC Small sized, Not tight
experienced
developers
Semi-detached 50-300 KLOC Medium size, Medium
average
experienced
developers
Embedded Above 300KLOC Large size, less Tight
experienced
developers
 Basic COCOMO equation:

Effort (E) = ab(KLOC)bb persons months

Development time (D) = cb(E)db months

Average staff size(P) = (E\D) persons
Productivity = (KLOC/E) kloc/ persons months

Project
ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Merits of Basic Cocomo model:
Basic COCOMO model is good for quick, early, rough order of magnitude estimates of software project.
Limitations :
1. The accuracy of this model is limited because it does not consider certain factors for cost estimation of
software. These factors are hardware constraints, personal quality and experiences, modern techniques
and tools.
2. The estimates of COCOMO model are within a factor of 1.3 only 29% of the time and within the factor of
2 only 60% of time.

(ii)The intermediate model

 Computes effort as a function as a function of programme size and a lot of cost drivers that includes
subjective assessment of product attributes, hardware attributes , personal attributes and project
attributes.
 The basic model is extended to consider a set of cost driver(15 cost drivers) attributes grouped into 4
categories to adjust the cost
 Product Attributes
 Hardware attributes
 Personnel attributes
 Project attributes
 The basic model is only for quick and rough estimation
Intermediate COCOMO equation
Effort (E)=ai(KLoC)(bi) * EAF
Development time (D) = ci(KLOC)di
Average staff size(P) = (E\D) persons

Project
ai bi ci di

Organic 3.2 1.05 2.5 0.38

Semi detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
EAF( effort adjustment factor):

Ratings

Very Extra
Cost Drivers Very Low Low Nominal High High High

Product attributes

Required software reliability 0.75 0.88 1.00 1.15 1.40 -

Size of application database 0.94 1.00 1.08 1.16 -

Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65

Hardware attributes

Run-time performance constraints - - 1.00 1.11 1.30 1.66

Memory constraints - - 1.00 1.06 1.21 1.56

Volatility of the virtual machine environment - 0.87 1.00 1.15 1.30 -

Required turnabout time - 0.87 1.00 1.07 1.15 -

Personnel attributes

Analyst capability 1.46 1.19 1.00 0.86 0.71 -

Applications experience 1.29 1.13 1.00 0.91 0.82 -

Software engineer capability 1.42 1.17 1.00 0.86 0.70 -

Virtual machine experience 1.21 1.10 1.00 0.90 - -

Programming language experience 1.14 1.07 1.00 0.95 - -

Project attributes

Application of software engineering methods 1.24 1.10 1.00 0.91 0.82 -

Use of software tools 1.24 1.10 1.00 0.91 0.83 -

Required development schedule 1.23 1.08 1.00 1.04 1.10 -

 These 15 attributes get a 6-point scale ranging from “very low” to “extra high”. These ratings can be viewed
as:

Very Low Nominal High Very Extra

Low high high
Merits:
1. This model can be applied to almost entire software product for easy and rough cost estimation during early
stage.
2. It can also be applied at the software product component level for obtaining more accurate cost estimation.
Limitations:
1. The effort multipliers are not dependent on phases.
2. A product with many components is difficult to estimate.

(iii) Detailed COCOMO Model

 The detailed model uses the same equation for estimation as the intermediate Model.
 This approach reduces the margin of error in the final estimate.
 But detailed model can estimate the effort (E), duration (D), and person (P) of each of development phases,
subsystem and models.
 The 5 phases are used,
 Requirements planning
 System Design
 Detailed design
 Code and unit test
 Integrate and test
Effort E = ai (KLOC)bi * EAF
Development time D = ci (E)di
Total Effort Ep = µpE person-month
Total Development time Dp = pD month
Average staff size(P) = E/D persons
P = KLOC/E EAF

Requirements Code and unit Integrate and

System Design Detailed design
Mode planning test test

Life Cycle Phase value for effort

Organic 0.06 0.16 0.26 0.14 0.16
Semi-detached 0.07 0.17 0.25 0.33 0.25
Embedded 0.08 0.18 0.25 0.26 0.31
Life Cycle Phase value for development
Organic 0.10 0.19 0.24 0.39 0.18
Semi-detached 0.20 0.20 0.21 0.02 0.26
Embedded 0.36 0.36 0.18 0.18 0.28

5.1.4 Make/Buy Decision:

 In many Software Applications areas, it is often more Cost effective to acquire rather than develop
Computer Software.
 Software Engineering Managers are faced with a Make or Buy Decision that can be further complicated by
a number of acquisition options such as:
 Purchase or buy the software.
 Reuse existing partially built components to construct the system.
 Build the system from scratch
  Contract the software development to an outside vendor.
Decision Tree:
It is a technique for making Make/Buy decision.

Expected cost = ∑ path probability * Estimated cost

Expected Costbuild = 0.30 (380,000) +0.70 (450,000) = $429,000
Expected Costreuse =0.40 (275,000)+ 0.60 [0.20 (310000) +0.80 (490,000)] = $382,000
Expected Costbuy = 0.70 (210,000) + 0.30 (400,000) = $267,000
Expected Costcontract = 0.60(350,000) + 0.40 (500,000) = $410,000
Based on the Probability and Projected Costs the Lowest Expected Cost is BUY option.
 Outsourcing
Outsourcing is a process in which Software engineering activities are contracted to a third party who does
the work at lower cost and at higher quality.
 Software work within the company is reduced to contract management activity.
 Outsourcing is often a financial decision.
 Acquisition of software (or components) from a source outside the organization
 Advantages:
Cost saving: It can usually be achieved by reducing own resources (people & infrastructure).
Accelerated development: Since some part of software gets developed simultaneously by a third
party, the overall development process gets accelerated.
 Disadvantages:
 Company loses some control over the software and bears the risk of putting its fate in hands of a
third party.
 The trend of outsourcing will be continued in software industry in order to survive in competitive
world.

5.2 Project Planning Process:

 The objective of software project planning is to provide a framework that enables the manager to make
reasonable estimates of resources, cost, and schedule.
 The plan must be adapted and updated as the project proceeds.

In the following sections, each of the actions associated with software project planning is discussed.
Software scope and feasibility:
 Software scope describes the functions and features that are to be delivered to end users; the data that are
input and output; the “content” that is presented to users as a consequence of using the software; and the
performance, constraints, interfaces, and reliability that bound the system.
 Scope is defined using one of two techniques:
1. A narrative description of software scope is developed after communication with all stakeholders.
2. A set of use cases is developed by end users.
 Functions described in the statement of scope (or within the use cases) are evaluated and in some cases
refined to provide more detail prior to the beginning of estimation.
Software feasibility has four solid dimensions:
Technology—Is a project technically feasible? Is it within the state of the art? Can defects be reduced to
a level matching the application’s needs?
Finance—Is it financially feasible? Can development be completed at a cost the software organization, its
client, or the market can afford?
Time—Will the project’s time-to-market beat the competition?
Resources—Does the organization have the resources needed to succeed?
 Putnam and Myers correctly suggest that scoping is not enough. Once scope is understood, you must
work to determine if it can be done within the dimensions just noted. This is a crucial, although often
overlooked, part of the estimation process.

5.2.1 Project Plan:

 Project plan is the most time-consuming project management activity.
 Continuous activity from initial concept throughout the system delivery. Plans must be regularly
revised as new information becomes available.
 Various different types of plan may be developed to support the main software project plan that is
concerned with schedule and budget.

 Milestone = end-point of a specific, distinct software process activity or task (for each milestone a
report should be presented to the management)
 Deliverable = project result delivered to the client In order to establish milestones the phases of
the software process need be divided in basic activities/tasks.
Project Plan Structure
1.Introduction
 Project objectives – constraints (budget, time, etc.)
2.Project organization
 People involved, roles
3.Risk analysis
 Projects risks, Risk reduction strategies
4.Resource requirements:Hardware and software
5.Work breakdown
 Activities, milestones, deliverables
6.Project schedule (3W: What activity, when, who)
 Activities dependencies, activities time, allocate people to activities
7.Monitoring and reporting mechanisms
 What management reports and when
 Monitoring mechanism used
 Revise plan, update schedule

5.3 Risk management:

Risk: A risk is defined as a potential problem or uncertainty which may occur or may not occur in a software
project.
Risk management:.
 Risk management involves anticipating risks that might affect the project schedule or the
quality of the software being developed, and then taking action to avoid these risks.
Software risk:
Uncertainty (which may or may not happen)
Loss (if it occurs it provides some loss)
Risk strategy:
Reactive: Proactive:
Action that is taken after the Risk is occurred. Plan is established and risk is predicted/
When This reactive strategy fails, Project is in identified before it occurs.
danger.

Categories of risk:
1. Project risks threaten the project plan. That is, if project risks become real, it is likely that the project
schedule will slip and that costs will increase.
 Project risks identify potential budgetary, schedule, personnel (staffing and organization), resource,
stakeholder, and requirements problems and their impact on a software project.
2. Technical risks threaten the quality and timeliness of the software to be produced. If a technical risk
becomes a reality, implementation may become difficult or impossible. Technical risks identify potential
design, implementation, interface, verification, and maintenance problems
3. Business risks threaten the viability of the software to be built and often jeopardize the project or the
product. Candidates for the top five business risks are
 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 policy of the
company.
 Sales risk: Building a product that the sales force doesn’t understand how to sell.
 Management Risk: Loosing the support of senior management due to a change in focus or a
change in people.
 Budget risks: Loosing budgetary or personnel commitment
4. Known risks are those that can be uncovered after careful evaluation of the project plan. (e.g.,
unrealistic delivery date, lack of documented requirements or software scope, poor development
environment).
5. Predictable risks are extrapolated from past project experience
(e.g., staff turnover, poor communication with the customer, dilution of staff effort as ongoing
maintenance requests are serviced).’
6. Unpredictable risks are the joker in the deck. They can and do occur, but they are extremely difficult to
identify in advance.
Seven Principles of Risk Management
1. Maintain a global perspective: view software risks within the context of a system in which it is a
component and the business problem that it is intended to solve.
2. Take a forward-looking view: think about the risks that may arise in the future (e.g., due to changes in
the software); establish contingency plans so that future events are manageable.
3. Encourage open communication if someone states a potential risk, don’t discount it. If a risk is
proposed in an informal manner, consider it. Encourage all stakeholders and users to suggest risks at any
time.
4. Integrate- a consideration of risk must be integrated into the software process.
5. Emphasize a continuous process the team must be vigilant throughout the software process, modifying
identified risks as more information is known and adding new ones as better insight is achieved.
6. Develop a shared product vision if all stakeholders share the same vision of the software, it is likely
that better risk identification and assessment will occur.
7. Encourage teamwork -the talents, skills, and knowledge of all stakeholders should be pooled when
Risk management process:
The risk management process is an iterative process that continues throughout the project.
i. Risk identification
ii. Risk projection
iii. Risk refinement
iv. Risk mitigation, monitoring and mitigation
 Fig: The Risk Management Process

RISK IDENTIFICATION
 Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule,
resource loading, etc.).
 It is a process of Identifying the risks that could cause major threat to the software engineering
process, the software being developed, or the development organization.
 By identifying known and predictable risks, the project manager takes a first step toward avoiding them
when possible and controlling them when necessary.
There are two distinct types of risks
 Generic risks:
- Generic risks are a potential threat to every software project.
 Product-specific risks.
- Product-Specific risks can be identified only by those with a clear understanding of the technology,
the people, and the environment that is specific to the software that is to be built.
Risk item Checklist
- 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.
 People risks- Risks that are associated with the people in the development team.
 Process definition- risks associated with the degree to which the software process has been defined
and is followed by the development organization.
 Development environment(Tool Risk)- 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.
Assessing Overall Project Risk
1. Have top software and customer managers formally committed to support the project?
2. Are end users enthusiastically committed to the project and the system/ product to be built?
3. Are requirements fully understood by the software engineering team and its customers?
4. Have customers been involved fully in the definition of requirements?
5. Do end users have realistic expectations?
6. Is the project scope stable?
7. Does the software engineering team have the right mix of skills?
8. Are project requirements stable?
Risk Components and Drivers
The risk components are defined in the following manner:
 Performance risk-the degree of uncertainty that the product will meet its requirements and be fit for its
intended use.
 Cost risk-the degree of uncertainty that the project budget will be maintained.
 Support risk-the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.
 Schedule risk-the degree of uncertainty that the project schedule will be maintained and that the product will
be delivered on time.

(ii) Risk Projection( Risk Estimation):

Risk projection, also called risk estimation, attempts to rate each risk in two ways.
(1) The likelihood or probability that the risk is real
(2) The consequences of the problems associated with the risk, should it occur.
Risk Projection Steps:
1. Establish a scale that reflects the perceived likelihood of a risk.
2. Delineate the consequences of the risk.
3. Estimate the impact of the risk on the project and the product.
4. Assess the overall accuracy of the risk projection so that there will be no misunderstandings.

Developing a Risk Table:

A risk table provides you with a simple technique for risk projection.2 A sample risk table is illustrated in
Figure below

Fig, Sample risk table prior to sorting

Next, the impact of each risk is assessed.
The categories for each of the four risk component: performance, support, cost, and schedule are averaged to
determine an overall impact value.
 Fig, Risk and Management Concern
The overall Risk Exposure RE is determined using the following relationship
RE = P *C
where P is the probability of occurrence for a risk, and
C is the cost to the project.
Example
Assume that the software team defines a project risk in the following manner:
Risk identification: Only 70 percent of the software components scheduled for reuse will, in fact, be integrated
into the application. The remaining functionality will have to be custom developed. Risk probability: 80
percent (likely).
Risk impact: Sixty reusable software components were planned. If only 70 percent can be used, 18 components
would have to be developed from scratch (in addition to other custom software that has been scheduled for
development). Since the average component is 100 LOC and local data indicate that the software engineering
cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 _ 100 _ 14 _
$25,200.
Risk exposure: RE _ 0.80 _ 25,200 _ $20,200.

(iii) Risk Refinement:

It is possible to refine the risk into a set of more detailed risks, each somewhat easier to mitigate,
monitor, and manage.
One way to do this is to represent the risk in Condition-Transition Consequence (CTC) format.
Given that <condition> then there is concern that (possibly) <consequence>

(iv) Risk Mitigation, Monitoring, And Management:

Risk Mitigation( Risk Avoidance):
- Risk Mitigation covers efforts taken to reduce either the probability or consequences of a threat.
- Risk mitigation measures can be directed towards reducing the severity of risk consequences,
reducing the probability of the risk materializing, or reducing the organizations exposure to the
risk.
Risk monitoring and control:
- It is the process of identifying, analyzing, and planning for newly discovered risks and managing
identified risks.
Risk Management:
- It is the identification, assessment, and prioritization of risks.

THE RMMM PLAN

- The Risk Mitigation, Monitoring and Management, RMMM, plan documents all work performed as part
of risk analysis and is used by the project manager as part of overall project plan.
- Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps
commence.
- A risk management strategy can be included in the software project plan, or risk management steps can
be organized into a separate RMMM plan.
- Some software teams do not develop a formal RMMM document. Rather, each risk is documented
individually using a Risk Information Sheet (RIS).
- The RIS is maintained using a database system.

5.4 Project scheduling and Tracking:

Software scheduling is defined as an action that distributes the estimated effort across the planned project
duration by allocating the effort to specific software engineering task.
Project scheduling principles:
1. Compartmentalization- The project must be compartmentalized into a number of manageable
activities and tasks. To accomplish compartmentalization, both the product and the process are
refined.
2. Interdependency- The interdependency of each compartmentalized activity or task must be
determined. Some tasks must occur in sequence, while others can occur in parallel.
3. Time allocation- Each task to be scheduled must be allocated some number of work units (e.g.,
person-days of effort).
 4. Effort validation- . Every project has a defined number of people on the software team. As time
allocation occurs, you must ensure that no more than the allocated number of people has been
scheduled at any given time.
5. Defined responsibilities- Every task that is scheduled should be assigned to a specific team
member.
6. Defined outcomes- Every task that is scheduled should have a defined outcome.
7. Defined milestones- Every task or group of tasks should be associated with a project milestone.
Project scheduling methods:
 Program evaluation and review technique (PERT)
 critical path method (CPM)
They 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. Interdependencies among tasks may be defined using a task
network. Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product
as a whole or for individual functions.

5.4.1 Relationship between People and Effort:

 In small software development project a single person can analyze requirements, perform design, generate
code, and conduct tests.
 As the size of a project increases, more people must become involved.
 There is a common myth among the software managers that by adding more people in the project, the
deadline can be achieved. But this is not true- as by adding more people in the project, first we need to train
them for the tools and technologies that are getting used in the project and only those people can teach the
new people who are already working. Thus during teaching or training the time will be simply wasted and
there won’t be the progress in the project.
 The Putnam-Norden-Rayleigh (PNR) Curve provides an indication of the relationship between effort
applied and delivery time for a software project.
 The curve indicates a minimum value to that indicates the least cost for delivery (i.e., the delivery time that
will result in the least effort expended). As we move left to (i.e., as we try to accelerate delivery), the curve
rises nonlinearly.
 Although it is possible to accelerate delivery, the curve rises very sharply to the left of td. In fact, the PNR
curve indicates that the project delivery time cannot be compressed much beyond 0.75td. If we attempt
further compression, the project moves into “the impossible region” and risk of failure becomes very high.
 The PNR curve also indicates that the lowest cost delivery option, to 2td. The implication here is that
delaying project delivery can reduce costs significantly. Of course, this must be weighed against the
business cost associated with the delay.
 The software equation is derived from the PNR curve and demonstrates the highly nonlinear relationship
between chronological time to complete a project and human effort applied to the project.
 The number of delivered lines of code (source statements), L, is related to effort and development time by
the equation:

 Where, E is development effort in person-months, P is a productivity parameter and t is the project duration
in calendar months.
 Rearranging this software equation, an expression for development effort E:

5.4.2 Task Set:

 The work that a software team performs is achieved through a set of tasks that enable to define, develop,
and ultimately support computer software.
 A task set is a collection of software engineering work tasks, milestones, work products, and quality
assurance filters that must be accomplished to complete a particular project.
 In order to develop a project schedule, a task set must be distributed on the project time line.
 The task set will vary depending upon the project type and the degree of rigor with which the software
team decides to do its work.
Various types of project are,
1. Concept development - initiated to explore new business concept or new application of technology
2. New application development - new product requested by customer
3. Application enhancement - major modifications to function, performance, or interfaces (observable to user)
4. Application maintenance - correcting, adapting, or extending existing software (not immediately obvious
to user)
5. Reengineering - rebuilding all (or part) of a legacy system
Various Factors Affecting Task Set are,
 Size of project
 Number of potential users
 Mission criticality
 Application longevity
 Requirement stability
 Ease of customer/developer communication
 Maturity of applicable technology
 Performance constraints
 Embedded/non-embedded characteristics
 Project staffing
 Reengineering factors
Example for Task Set
The task sets for Requirements gathering action for a simple project may include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
5.4.3 Task Network
 Task networks (activity networks) are graphic representations can be of the task interdependencies and can
help define a rough schedule for particular project
 Program evaluation and review technique (PERT) and critical path method (CPM) ) are quantitative
techniques that allow software planners to identify the chain of dependent tasks in the project work
breakdown structure (WBS) that determine the project duration time.
 Timeline (Gantt) charts enable software planners to determine what tasks will be need to be conducted at a
given point in time (based on estimates for effort, start time, and duration for each task).
 The best indicator of progress is the completion and successful review of a defined software work product.
 Time-boxing is the practice of deciding a priori the fixed amount of time that can be spent on each task.
When the task's time limit is exceeded, development moves on to the next task (with the hope that a
majority of the critical work was completed before time ran out).

 Concept scoping determines the overall scope of the project.

 Preliminary concept planning establishes the organization’s ability to undertake the work implied by the
project scope.
 Technology risk assessment evaluates the risk associated with the technology to be implemented as part of
the project scope.
 Proof of concept demonstrates the viability of a new technology in the software context.
 Concept implementation implements the concept representation in a manner that can be reviewed by a
customer and is used for “marketing” purposes when a concept must be sold to other customers or
management.
 Customer reaction to the concept solicits feedback on a new technology concept and targets specific
customer applications.

5.4.4 Time-Line Charts

 A time-line chart, also called a Gantt chart, is generated.
 A time-line chart can be developed for the entire project.
 Alternatively, separate charts can be developed for each project function or for each individual working on
the project.
 It depicts a part of a software project schedule that emphasizes the concept scoping task for a word-
processing (WP) software product.
 All project tasks (for concept scoping) are listed in the left-hand column.
 The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the
calendar, task concurrency is implied.
 The diamonds indicate milestones.
 In most of the projects,after generation of timeline chart the project tables are prepared.
 In project tables all the tasks are listed along with actual start and actual end dates and related information.

5.4. 5 Tracking the schedule:

 The project schedule becomes a road map that defines the tasks and milestones to be tracked and controlled
as the project proceeds.
 Tracking techniques are used by experienced project managers.
Tracking can be accomplished in a number of different ways:
 Conducting periodic project status meetings in which each team member reports progress and
problems
 Evaluating the results of all reviews conducted throughout the software engineering process
 Determining whether formal project milestones have been accomplished by the scheduled date
 Comparing the actual start date to the planned start date for each project task listed in the resource
table.
  Meeting informally with practitioners to obtain their subjective assessment of progress to date and
problems on the horizon.
 Using earned value analysis to assess progress quantitatively
The project managers sometimes use a project scheduling and control technique called time-boxing. The time-
boxing strategy recognizes that the complete product may not be deliverable by the predefined deadline. A
“box” is put around each task. When a task hits the boundary of its time box (plus or minus 10 percent), work
stops and the next task begins. By the time the time-box boundary is encountered, it is likely that 90 percent of
the task has been completed. The remaining 10 percent, although important, can (1) be delayed until the next
increment or (2) be completed later if required.

5.4.6 Earned value analysis:

• Earned Value Analysis (EVA) is an industry standard method of measuring a project's progress at any
given point in time, forecasting its completion date and final cost, and analyzing variances in the schedule
and budget as the project proceeds.
• It compares the planned amount of work with what has actually been completed, to determine if the cost,
schedule, and work accomplished are progressing in accordance with the plan.
• Earned Value Management measures progress against a baseline.
It involves calculating,
1)Planned Value(PV)-The Planned cost of the total amount of work scheduled to be performed by the
milestone date.
2)Actual Cost(AC)-Planned cost of the total amount of work scheduled to be performed by the milestone date.
3)Earned Value(EV)-The planned (not actual) cost to complete the work that has been done.
4)Budget At Completion(BAC)-The total budget for the project.
PV=Planned Completion(%)*BAC
EV=Actual Completion(%)*BAC
5)Schedule Variance(SV)-A comparison of amount of work performed during a given period of time to what
was scheduled to be performed.
 SV<0 – project is behind the schedule
 SV>0 - project is ahead of the schedule
 SV=0 - project is on schedule
SV=EV-PV
6)Cost Variance(CV)-A comparison of the budgeted cost of work performed with actual cost.
 CV<0 – project is over budget
 CV>0 – project is under budget
 CV=0 – project is on budget
CV=EV-AC
7)Schedule Performance Index(SPI)-Schedule efficiency
 SPI<1.0 – project is behind the schedule
 SPI>1.0 - project is ahead of the schedule
 SPI=1.0 - project is on schedule
SPI=EV/PV
8)Cost Performance Index(CPI)-Cost Efficiency
 CPI<1.0 – project is over budget
 CPI>1.0 – project is under budget
 CPI=1.0 – project is on budget
CPI= EV/AC
5.5 Process and Project Metrics:
- Measurement is a management tool that provides the project manager and software team in making
decisions that will lead to successful project.
- Measurement can be applied to the software process with the intent of improving it on a continuous basis.
- Measurement can be used throughout a software project to assist in estimation, quality control, productivity
assessment, and project control.
- Reason for measuring includes.
 To determine status with respect to plans
 To understand the relationship between processes and products
 To improve product quality and process performance.
Metric:
It is a system or standard of measurement.
Types of Metrics:
Process metrics
Project metrics
Product metrics

5.5.1 Process metrics:

It is used to improve the efficiency of an existing process used in software development and maintenance.
Example:
o Defect detection percentage
o Defect density
o Time to fix the defect
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.
Project metrics enable a software project manager to
(1) assess the status of an ongoing project,
(2) track potential risks,
(3) uncover problem areas before they go “critical,”
(4) adjust work flow or tasks, and
(5) evaluate the project team’s ability to control quality of software work products
- In the below diagram, process sits at the center of a triangle connecting three factors that have a profound
influence on software quality and organizational performance.
- The skill and motivation of people has been shown [Boe81] to be the single most influential factor in
quality and performance.
- The complexity of the product can have a substantial impact on quality and team performance.
- The technology (i.e., the software engineering methods and tools) that populates the process also has an
impact.
 Fig, Determinants for software quality and organizational effectiveness.
The process triangle exists within a circle of environmental conditions that include the development
environment (e.g., integrated software tools), business conditions (e.g., deadlines, business rules), and customer
characteristics (e.g., ease of communication and collaboration).
The process uses 2 different types of metrics for itys data.
(i) Private Metrics:
 Private metrics are those metrics that are collected by individual software professionals.
 Sometimes individual software engineers might be sensitive about the metrics they have
collected on an individual basis. Hence these data should be private to the individual and serve as
an indicator for the individual only.
Example:
 A test engineer can keep the defect rates found in a week or errors found during development as
a private metric.
 A IT professional may keep number of new technologies he studied as a private metric.
(ii) Public metrics:
 Public metrics has more meaning than private metrics.
 Public metrics can be computed depending upon private metrics that an individual made it as
public.
 Public metrics are concerned more with project team and not as an individual.
Example:
Project-level defect rates per month ,effort of an engineer, calendar times etc.
5.5.2 Project Metrics:
 Project Metrics are used by a project manager and a software team to adapt project workflow and
technical activities.
 Metrics collected from past projects are used as a basis from which effort and time estimates are made
for current software work.
 As a project proceeds, measures of effort and calendar time expended are compared to original estimates
(and the project schedule).
 The project manager uses these data to monitor and control progress.
 As technical work commences, other project metrics begin to have significance.
 Production rates represented in terms of models created, review hours, function points, and delivered
source lines are measured.
 In addition, errors uncovered during each software engineering task are tracked.
 As the software evolves from requirements into design, technical metrics are collected to assess design
quality.
2 Main Objective of Project metric:
 i. First, These metrics are used to minimize the development schedule by making the adjustments
necessary to avoid delays and mitigate potential problems and risks.
ii. Second, project metrics are used to assess product quality on an ongoing basis and, when
necessary, modify the technical approach to improve quality.
As quality improves, defects are minimized, and as the defect count goes down, the amount of rework required
during the project is also reduced. This leads to a reduction in overall project cost.

5.5.3 Product Metrics:

- It describe the characteristics of the project such as size, compatibility, design features, performance and
quality level.
Example:
KLOC,
Function point complexity

5.5.4 Software Measurement:

Software Measurement can be categorized in two ways:
1. Direct Measure
2. Indirect Measure
Direct Measure Indirect Measure
 Here, one metric does not depend on This indirect metric relies on more than one
any other attribute or metric measure.
 Direct measures of the software process Indirect measures of the product include
functionality, quality, complexity, efficiency,
include cost and effort applied.
reliability,& maintainability.
 Example:
- lines of code (LOC) produced,
execution speed,
- memory size, and
- defects reported over some set
period of time.
Types of Software Measurements Includes,
1. Size Oriented Metrics
2. Function Oriented Metrics
3. Object Oriented Metrics
4. Use case oriented Metrics
1. Size Oriented Metrics:
The size oriented metrics are those metrics, which are computed keeping size of the software as main
consideration.
- The size of the software are usually expressed in terms of KLOC ( Kilo Line Of Code ).
- Size-oriented software metrics are derived by normalizing quality and/or productivity measures by
considering the size of the software that has been produced.
- The following table lists each software development project that has been completed over the past few
years and corresponding measures for that project.
 Fig, Size-oriented metrics
From the table, for project alpha:
12,100 lines of code were developed with 24 person-months of effort at a cost of $168,000.
In order to develop metrics that can be assimilated with similar metrics from other projects, you can choose
lines of code as a normalization value. From the rudimentary data contained in the table, a set of simple size-
oriented metrics can be developed for each project:
• Errors per KLOC (thousand lines of code)
• Defects per KLOC
• $ per KLOC
• Pages of documentation per KLOC
In addition, other interesting metrics can be computed:
• Errors per person-month
• KLOC per person-month
• $ per page of documentation
2.Function oriented metric:
 It’s a metric which gives the degree of functionality delivered by a software system. Since
‘functionality’ cannot be measured directly; an indirect measurement is done by computing Function-
Point ( FP ).
 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
FP can be computed by completing the table shown in the next slide and then applying some formulae.
Function-Oriented Metrics to compute function points (FP), the following relationship is used:
FP = count total x [0.65+0.01xΣ(Fi)]
Drawbacks of FP and LOC estimation:
Conventional software project metrics (LOC or FP) can be used to estimate object oriented software projects.
However, these metrics do not provide enough granularities for the schedule and effort adjustments that are
required as you iterate through an evolutionary or incremental process.
3.Object-Oriented Metrics:
Lorenz and Kidd [Lor94] suggest the following set of metrics for OO projects.
Number of scenario scripts:
- A scenario script is a detailed sequence of steps that describe the interaction between the user and the
application.
- Each script is organized into triplets of the form {initiator, action, participant}
Here, initiator is the object that requests some service (that initiates a message),
action is the result of the request, and
participant is the server object that satisfies the request.
Number of key classes:
Key classes are the “highly independent components”.
They are defined early in object-oriented analysis.
number of such classes is an indication of the amount of effort required to develop the software and also an
indication of the potential amount of reuse to be applied during system development.
Number of support classes:
Support classes are required to implement the system.
support classes can be developed for each of the key classes.
Examples might be user interface (GUI) classes, database access and manipulation classes, and computation
classes.
Average number of support classes per key class:
In general, key classes are known early in the project. Support classes are defined throughout.
If the average number of support classes per key class were known for a given problem domain, estimating
(based on total number of classes) would be greatly simplified.
Number of subsystems.
A subsystem is an aggregation of classes that support a function that is visible to the end user of a system.
Once subsystems are identified, it is easier to lay out a schedule.
4.Usecase Oriented Metrics:
Use cases6 are used widely as a method for describing customer-level or business domain requirements that
imply software features and functions.
use case is also a normalization measure similar to LOC or FP.
Like FP, the use case is also defined early in the software process.
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.
he number of use cases is directly proportional to the size of the application in LOC.
Because use cases can be created at vastly different levels of abstraction, there is no standard “size” for a use
case.

5.5.5 Metrics For Software Quality:

Measuring Quality:
Measures of software are quality,8 correctness, maintainability, integrity, and usability.
Correctness:
- Correctness is the degree to which the software performs its required function.
- The most common measure for correctness is defects per KLOC, where a defect is defined as a verified
lack of conformance to requirements.
- Eg, For quality assessment purposes, defects are counted over a standard period of time, typically one
year.
Maintainability:
- Maintainability is the ease with which a program can be corrected if an error is encountered, adapted if
its environment changes, or enhanced if the customer desires a change in
- requirements.
- There is no way to measure maintainability directly.
- A simple time-oriented metric is mean-time-to-change (MTTC),
Integrity:
- This attribute measures a system’s ability
- to withstand attacks (both accidental and intentional) to its security.
- Attacks can be made on all three components of software: programs, data, and documentation.
- To measure integrity, two additional attributes must be defined: threat and security.
- Threat is the probability an attack of a specific type will occur within a given time.
- Security is the probability that the attack of a specific type will be repelled(go away).
- Integrity of a system can then be defined as:
- Integrity _ _ [1 _ (threat _ (1 _ security))]
Usability:
- Usability is an attempt to quantify ease of use.
- It is measured in terms of the characteristics
Defect Removal Efficiency:
- A quality metric that provides benefit at both the project and process level is defect removal efficiency
(DRE).
- DRE is defined in the following manner:

where E is the number of errors found before delivery of the software.

D is the number of defects found after delivery.
The ideal value for DRE is 1. That is, no defects are found in the software.

- DRE can also be used within the project to assess a team’s ability to find errors before they are passed to
the next framework activity or software engineering action.
- When used in this context, we redefine DRE as

- where Ei is the number of errors found during software engineering action i,

Ei+ 1 is the number of errors found during software engineering action.