Project management 02112009

Software ProjectSoftware Project
ManagementManagement

ProverbsProverbs
Below are 20 project management proverbs that show you
what can go wrong
 You cannot produce a baby in one month by impregnating nine
women
 The same work under same conditions will be estimated
differently by ten different estimators or by one estimator at ten
different times
 The most valuable and least used word in a project manager’s
vocabulary is “NO”
 You can con a sucker into committing to an unreasonable
deadline, but you can’t bully him into meeting it
 The more ridiculous the deadline, the more it costs to try to meet
it.
 The more desperate the situation, the more optimistic the situate.
 Too few people on a project can’t solve the problems – too many
create more problems than they solve

ProverbsProverbs
 You can freeze the user’s specs but he won’t stop expecting
 Frozen specs and the abominable snowman are alike: They are
both myths, and they both melt when sufficient heat is applied
 The conditions attached to a promise are forgotten, and the
promise is remembered
 What you don’t know hurts you
 A user will tell you anything you ask about – nothing more
 Of several possible interpretations of a communication, the least
convenient one is the only correct one
 What is not on paper has not been said
 No major project is ever installed on time, within budget, with the
same staff that started it.
 Project progress quickly until they become 90% complete, then
they remain at 90% complete forever
 If a project content is allowed to change freely, the rate of
change will exceed the rate of progress

ProverbsProverbs
 No major system is ever completely debugged: attempts to
debug a system inevitably introduce new bugs that are even
harder to find
 Project team detest progress reporting because it vividly
demonstrates their lack of progress
 Parkinson and Murphy are alive and well – in your project

What’s a project?What’s a project?
 Projects are different from ordinary work. They are
intended to change things
 Projects have a timeframe with a beginning and an
end
 Projects have to be planned
 Projects use resources and need a budget
 Projects require evaluation – the criteria for
evaluation need to be established from the beginning
 Projects have an outcome, which is not necessarily
known at the outset
 The outcome is very often a “product” of some kind
 At the end of a project, decisions need to be taken
about whether to use or institutionalize the outcome
 Projects involve people

What’s a project?What’s a project?
 Projects are designed to promote change and innovation.
They provide opportunities to test possible innovations in
protected environment without taking the decision to
change established practice until it can be shown that the
new ideas work.
 Project Planning
◦ Projects don’t just happen; they need to be planned. They usually
come in addition to normal work or in a limited period where the
project participants are released from their usual duties. They need to
be completed within set deadlines and have a limited budget
 Software development methodologies are concerned with “what”
you have to do to be successful, a project management
methodology is concerned with “how” you do things. In this
sense, the software development methodology is more of
strategic approach to IT project delivery and project management
methodology is used at an operational level

Introduction – Project ManagementIntroduction – Project Management
What Does Project Management Mean?
Project management is the discipline[1]
of planning,
organizing, and managing resources to bring about the
successful completion of specific project goals and objectives.
The primary challenge of project management is to achieve
all of the project goals[5]
and objectives while honoring the
preconceived project constraints.[6]
Typical constraints are
scope, time, and budget.[2]
The secondary—and more
ambitious—challenge is to optimize the allocation and
integration of inputs necessary to meet pre-defined
objectives.

Project Management ProcessProject Management Process

What’s a Project Manager?What’s a Project Manager?
What does the project manager do?
Why doesn't the project manager do
some of the work?
Why don't we make our top
specialist the project manager?
Why does the project manager need
a support team?
Isn't this all an unnecessary
overhead for the project?

A project manager is a professional in
the field of project management. Project
managers can have the responsibility of
the planning, execution, and closing of
any project, typically relating to
construction industry, architecture,
computer networking, telecommunications
or software development.

Bear in mind that the
Project Manager needs
to achieve this without
direct control over the
participants. The Project
Manager will not have
power over the
leadership, nor the
internal and external
contributors. Even in the
project team there may
be loaned staff, part-
timers and sub-
contractors who will have
their prime loyalties
elsewhere.

Qualities of an Excellent ManagerQualities of an Excellent Manager
.
Inspires a shared vision Creativity
Good communicator Structure
Integrity Intuition
Enthusiasm Knowledge
Empathy Commitment
Competence Being Human
Ability to delegate tasks Versatility
Cool under pressure Lightness
Team Building Skills
Discipline / Focus
Problem Solving Skills
Big Picture, Small Actions

Project Management – Art or Skill?Project Management – Art or Skill?
.
Can people be trained to be a PM, or are the skills needed for project
management something one has innately and cannot really be taught?
• For a PM, the “right stuff” has two components to it. As with most
professions, project management requires a technical skill set that one can
learn through training, but it also requires a particular set of behavioral traits
that present a challenge to training programs.
•The behavioral component can come with experience, but not everybody has
the personal qualities that make them prime prospects.
•Organizations need to understand this if they are to develop strong project
management.

Project Management – Art or Skill?Project Management – Art or Skill?
.
Technical Skills
• Project Planning
• Assessing Project Status
• Managing Risk
Behavioral skills: the art of project management
•The capacity to anticipate
• Attention to detail
• The ability to persuade others
These capabilities constitute a kind of “art” in a project manager’s bag
of talents. They are in part inherent personal qualities, in part the
product of relevant experience, and only in part teachable

Software Project Manager
 Many of the same skills as their counterparts in other
industries
 Extensive background in Software Development
 Degree in Computer Science, Information Technology or
any other related field and will typically have worked in the
industry as a software engineer
 To be skilled in lightweight, adaptive methodologies such
as Agile,XP.
 Familiar with Software Development Life Cycle (SDLC)
 In depth knowledge of requirements solicitation,
application development, logical and physical database
design and networking
 PMP certified??

Responsibilities
The specific responsibilities of the Project Manager vary
depending on the industry, the company size, the company
maturity, and the company culture. However, there are
some responsibilities that are common to all Project
Managers, noting[2]
:
 Developing the project plan
 Managing the project stakeholders
 Managing the project team
 Managing the project risk
 Managing the project schedule
 Managing the project budget
 Managing the project conflicts

 The concept, objectives, approach and justification of the
project are properly defined, agreed and communicated.
 Management-level planning maps out an overall
management plan from which resources, acquisitions and
sub-contracts can be identified, costed and put in place.
The business case will be re-assessed to ensure the
original assumptions and justification hold true. At this
stage, many of the detailed management processes will be
defined and instigated.
 A project will pass through several stages or phases, each
with a different objective and deliverable. Typically the
phases will require different skills, structures and resource
levels. It is normal to plan, estimate and resource each
phase separately (albeit overlapping the preliminary work
to avoid stoppages).

 Planned benefits will be assessed and monitored
throughout the project - optimizing benefit should be the
prime goal of the project manager.
 Quality requirements and approaches will be defined and
agreed during the project start-up. Typically there will be
rules that apply to the routine work of the team plus
specified quality audits at the end of the phases.
 Risks will be assessed at the start of the project.
Contingency plans and avoiding action will be defined as
appropriate. The risk management process will pro-actively
monitor risks throughout the project. Risk assessments
and plans will be modified as appropriate.
 All participants will be encouraged to communicate
potential issues for resolution. The issues management
process will ensure they are considered and addressed.

 The scope of the project and specific changes to the
solution will be controlled through a management process
with appropriate balances and controls - focused on
achieving optimum overall benefit.
 Versions of all deliverables will be controlled (whether
temporary working papers or permanent outputs) through
a configuration management process.
 A documentation management process will ensure all
information is available to all those who require it, and is
subject to careful control over authorship, reviews and
updates.
 An effective team will be nurtured through appropriate
initiation, training, communications, and social events.
 Organisational change issues will be assessed early in the
project, leading to a course of communications, events and
other activities to ensure all parties affected by the change
are ready and willing to change.

 The needs to communicate outside the team with other parts of
the organisation, customers, suppliers, and other parties will be
assessed. A course of communications will be defined and
actioned.
 Large projects inevitable require a process to handle expenditure
on subcontractors, equipment, software, and facilities. Project
accounting will monitor and control expenditure - both as a
routine management activity and as part of the overall focus on
delivering optimum benefits.
 Where sub-contractors are involved, there will be a management
process to agree and monitor contracts.
 At the end of the project, there will be several activities to
transition work, processes and deliverables to line operation. The
team also need to ensure filing and documentation is in good
order, leaving behind sufficient detail for the operation of the
system, audits concerning the project, and as a baseline for
future maintenance and development. People, equipment and
facilities need to be demobilised.

 After the live solution has settled down, it is normal to organise a
Post Implementation Review to measure the success of the
project, to see what further improvements can be made, and to
learn lessons for the future.

Project DefinitionProject Definition
Why, What, How?
 How does a project get started?
 How do you know what it is supposed to achieve?
 How do you know what approach is required?
 How do you know that it is a good idea in the first place?
 How will you know if you succeeded?
Business Needs Project Definition Project Execution

The RFP processThe RFP process
.
An RFP is a document containing a detailed list of technology and
business requirements for a given project. This document is typically
sent to a targeted group of vendors to solicit their proposals to work on
your project.
Is There a Difference Between an RFP, an RFI, and an RFQ?
RFI (Request for Information): This document, used for planning, is
akin to a fact sheet. In the case of very small projects, this document
will be used for decision making as well.
RFQ (Request for Quote): This document is most appropriate if you
need to get the pricing on a fairly commoditized product, such as email
or Web hosting. Use an RFQ if you've already prepared your
requirements and you will be making your decision based on a
quantitative analysis of the bidder's pricing proposal.

.
RFP (Request for Proposal): This document is more complex to
prepare than either an RFI or an RFQ. It often involves a much more
complex set of evaluation criteria, based not only on price, but on the
total cost of ownership and the fit of the solution to the organization's
goals and objectives.
When Does My Organization Need an RFP?
An RFP is usually drafted at the end of the requirements-gathering
phase of a project. RFPs are typically most valuable in large, complex,
or high-impact projects. Small projects with budgets under $10,000
usually do not need to go through a formal RFP process unless the
projected impact is anticipated to be substantial. If you have a much
smaller or simpler project, you may wish to consider an informal
process instead of a formal RFP process.

.
Formal RFP Informal Process
Projected budget Greater than $10,000 Less than $10,000
Projected timeframe Several months Several weeks
Impact on
organization
Moderate/high Low/moderate
Variations in solution
space
Broad range of
solutions/options
Narrow range of
solutions/options
Approximate
document length
20-plus pages 10 or fewer pages
Approximate level of
detail
Highly detailed Overview/summary

.
Why Do I Need an RFP?
RFPs are an extremely valuable tool to ensure that vendors deliver the exact
solutions that you need. An RFP provides value in the following ways:
• Internal alignment: forces your agency to lay out your perceived needs
before involving a vendor.
• More accurate proposals: allows vendors to clearly understand your needs
so they can provide you with more accurate estimates of costs and time
frames.
• Comparable solutions: ensures that each vendor receives the same set of
requirements and thus yields a similar and comparable set of proposed
solutions.

.
Prerequisites for a Successful RFP Process
The RFP process can be fairly complex, involving multiple
stakeholders both inside and outside of your organization. Since it also
involves a significant investment, both in "human" and financial terms,
it can also be a very high-profile activity. Therefore, it is highly
recommended that you complete the following prerequisites before
embarking on this process:
• Identify organizational goals and objectives.
• Identify stakeholders.
• Identify project objectives.

.
Additional Guidelines
Other points to consider when preparing an RFP:
• An RFP is not an agreement. An RFP represents a list of
requirements only; it should not be confused with a job offer. For this,
you will need a written contract, which details the terms and conditions
the involved parties have agreed to follow.
• Vendors should bear the costs of the proposal. Any expenses
incurred in preparing a proposal should be borne solely by the
contractor responding to the RFP, not the RFP originator ("Owner").
• Submitted proposals should become the property of the Owner.
It should be documented in the RFP that the Owner reserves the right
to accept or reject any or all responses to an RFP, even if all of the
stated requirements are met. Owners should also reserve the right to
use concepts or ideas contained in any submitted proposal without
incurring liability

EstimationEstimation
.
The variety of software projects being carried out
today is enormous. Some of them succeed while
others
fail. One key reason for failure of projects is lack
of proper estimation or the use of inappropriate
estimation techniques. While there are many
estimation techniques developed for projects each
of them
have their own advantages and disadvantages.
No estimation technique can be considered a
silver bullet
for all the projects.

.
Software Project Estimation
Project Scope
• Business Functionality addressed through the application system
• Various modules of the application
• Platform, language and database used
• Tools used as part of the application
•Performance and other execution capacity attributes of the
system
• Interface with other systems in the environment
 Software Environment
• Operating system (including the version)
• Technology platform
• Programming language
• File system
•Database system (if applicable)
• Interfaces to other environments (if applicable)

.
Software Environment (contd’)
• Hardware
• Communication System (if applicable)
• Architecture of the application system
•Performance and other scalability expectations from the software
system
 Team Experience
• Ability to understand clearly the scope
• Technical expertise on the development platform
• Project management expertise
• Quality procedures and processes
•Software testing skills

.
Software Development Tools
• Design tools
• Build tools
• Tools to review code according to standards
•Online documentation
•Tools to develop repeatable test scenarios
• Configuration tools

Estimation QuestionsEstimation Questions
• How much effort is required to complete an activity?
• How much calendar time is needed to complete an activity?
• What is the total cost of an activity?
•Project estimation and scheduling are interleaved management
activities
Software Cost Components
• Hardware & Software Costs
• Travel & Training Costs
• Effort costs (dominant factor)
 Salaries of engineers
 Social & Insurance costs
• Overhead Costs
 Building heating & lighting
 Networking &
Communications
 Shared facilities (library,
staff & restaurant etc.)

Estimation Costing & PricingEstimation Costing & Pricing
•Estimates are made to discover the cost, of developing the software
system
•There is no simple relationship between the development cost and
the price charged to the customer
•Broader organizational, economic, political and business
considerations influence the price charged
Pricing Factors
• A development organization may quote a low price because it wishes
to move into a new segment of the software market
• Accepting a low profit on one project may give the opportunity of
more profit later.
• The experience gained may allow new products to be developed.

Pricing Factors
• If an organization is unsure of its cost estimate, it may increase its
price by some contingency over and above its normal profit.
• Developers in financial difficulty may lower their price to gain a
contract.
• It is better to make a smaller than normal profit or break even than to
go out of business.
Contractual Terms & Requirements volatility
• A customer may be willing to allow the developer to retain ownership
of the source code and reuse it in other projects.
• The price charged may then be less than if the software source code
is handed over to the customer.
• If the requirements are likely to change, an organization may lower
its price to win a contract.
• After the contract is awarded, high prices can be charged for
changes to the requirements.

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

Measurement Problems
• Estimating the size of the measure (e.g. how many function points)
• Estimating the total number of programmer months have elapsed
• Estimating contractor productivity
• E.g. Documentation team and
• Incorporating this estimate in overall estimate
Lines of Code (LOC)
• What’s a line of code?
• What programs should be counted as part of the system

Productivity Comparisons
• The more verbose the programmer, the higher the productivity?
But measures of productivity based on LOC suggest that
programmers who write verbose code are more productive than
programmers who write compact code (!)
• The lower-level the language, the more productive the programmer?
Same functionality takes more code to implement in a lower-
level language than in a high-level language

Factors affecting productivity

Quality and Productivity
All metrics based on volume/unit time are
flawed because they do not take quality into
account.
Productivity may generally be increased at the cost
of quality.
It is not clear how productivity/quality metrics
are related.
If requirements are constantly changing then an
approach based on counting lines of code is not
meaningful as the program itself is not static.

Estimation Techniques
There is no simple way to make an accurate estimate
of the effort required to develop a software system
Initial estimates are based on inadequate
information in a user requirements definition;
The software may run on unfamiliar computers or
use new technology;
The people in the project may be unknown.
Project cost estimates may be self-fulfilling
The estimate defines the budget and the product
is adjusted to meet the budget.

Changing Technologies
Changing technologies may mean that previous
estimating experience does not carry over to new
systems
Distributed object systems rather than mainframe
systems;
Use of Web services;
Use of ERP or database-centered systems;
Use of off-the-shelf software;
Development for and with reuse;
Development using scripting languages;
The use of CASE tools and program generators

Top-Down and Bottom-up estimation
Any of these approaches may be used top-down or
bottom-up.
Top-down
Start at the system level
Assess the overall system functionality and how
this is delivered through sub-systems.
Bottom-up
Start at the component level and estimate the
effort required for each component.
Add these efforts to reach a final estimate.

Top-Down estimation
Usable without knowledge of the system architecture and the
components that might be part of the system.
Takes into account costs such as integration, configuration
management and documentation.
Can underestimate the cost of solving difficult low-level technical
problems.
Bottom-up estimation
Usable when the architecture of the system is known and
components identified.
This can be an accurate method if the system has been designed in
detail.
It may underestimate the costs of system level activities such as
integration and documentation.

Identification of Project
Factors
1
Identification of Input
Parameters of COCOMO,
Use Case Point
Estimation
2
Correlation of Project
Factors with Estimation
input parameters
3
Identification of projects
for which COCOMO, Use
Case Point, Wide Band
Delphi provide best
estimation results
4

Identification of Project Factors
• It is very important to identify the project characteristics or factors
since the correlation of these project factors or characteristics with
input parameters of estimation techniques is necessary to find out
which estimation techniques provide better estimation results for which
type of projects.
• Project Factors
 Project Duration & Complexity
• People Factors
 Customer Interaction with Project team
 User Interaction with Developed System
 Domain expertise of Project Development team
 Team Size
 Development team distribution

• Technology Factors
 Technical expertise of team members
 Usage of sophisticated tools
 Usage of reusable components
 Platforms involved in the project
 Programming languages used
• Process Factors
 Documentation Required

.Many people have referred to estimation as a "black art.“
Elements of a Successful Estimate
• A sound estimate starts with a Work Breakdown Structure (WBS)
• A WBS is a list of tasks that, if completed, will produce the final product
• The project can be broken down by feature, by project phase (requirements
tasks, design tasks, programming tasks, QA tasks, etc.)
• Or combination of above
• Once WBS is created, the team must create an estimate of the effort required
to perform each task
• The most accurate estimates are those that rely on prior experience
• Team members should review previous project results and find how long
similar tasks in previous projects took to complete
• Sources of delays in the past should be taken into account when making
current estimates

.
• The goal of estimation is not to predict the future. Instead, it is to gauge
an honest, well-informed opinion of the effort required to do a task from
those people in the organization who have the most applicable training
and knowledge.
• If two people widely disagree on how long a task will take, it's likely that the
source of that disagreement is that each person made different assumptions
about details of the work product or the strategy for producing it.
Assumptions Make Estimates More Accurate
•The team should hold a brainstorming session to try to identify as many
assumptions as possible. The bigger the list of assumptions, the lower the
overall risk for the project.
• Identifying assumptions is a skill that improves with experience

.
Questions to help lead the discussion to identify the assumptions:
1.Are there project goals that are known to the team but not written in any
documentation?
2.Are there any concepts, terms, or definitions that need to be clarified?
3.Are there standards that must be met but will be expensive to comply with?
4.How will the development of this project differ from that of previous projects?
Will there be new tasks added that were not performed previously?
5.Are there technology and architecture decisions that have already been
made?
6.What changes are likely to occur elsewhere in the organization that could
cause this estimate to be inaccurate?
7.Are there any issues that the team is known to disagree on that will affect the
project?

.
3-point estimation
It Takes Three to Make Good Estimates
3-point estimation assumes that there is
uncertainty on costs, efforts and duration.
This uncertainty can not be handled by the
traditional single estimation point.

.
3-point estimation

.
3-point estimation
The three-point estimation technique is based on statistical methods, and in
particular, the normal distribution. Three-point estimation is the preferred
estimation technique for information systems (IS) projects. In the three-point
estimation there are three figures produced for every estimate:
• a = the best-case estimate
• m = the most likely estimate
• b = the worst-case estimate
Based on the assumption (possibly unwarranted) that a double-triangular
distribution governs the data, several estimates are possible. These values are
used to calculate an E value for the estimate and a standard deviation (SD)
where:
• E = (a + 4m + b) / 6
• SD = (b − a)/6

Estimation - DelphiEstimation - Delphi
.
Delphi
Delphi is a place in Greece, which was supposed to
confer predictive powers to the person. A temple was
built there and virgin girls were appointed there to
answer questions about the future – these were called
Oracles. Oracle’s prophecies were considered
prophetic or at least wise counsel. This technique,
taking cue from the above legend, is drawing wise
counsel (Oracle) from senior and experienced
software developers for preparing estimates for
software development projects.

.
Delphi
Under this method of software estimation, the project
specifications would be given to a few experts and their
opinion taken. The actual number of experts chosen would
depend on their availability. A minimum of three is normally
selected to have a range of values.
Now this method has the following steps –
1. Selection of experts
2. Briefing to the experts
3. Collation of estimates from experts
4. Convergence of estimates and finalization

.
Delphi
Selection of experts
Now the experts are selected who have these attributes, namely,
1. They have software development experience
2. They have worked and possess knowledge in the application domain at
hand
3. They may be from within the organization or from without the organization
4. PM should be part of estimation team
5. Good practice to have a moderator other than PM for this estimation method
It is necessary to select at least three experts so that there is a range. The
actual number of experts selected can depend on the –
1. Complexity of the project – more complex more experts
2. Availability of experts who have the domain knowledge
3. The competition and the necessity of winning over competition – if we
perceive stiff competition and expecting the margins to be low, we need to get
more expert advice

.
Delphi
Briefing the experts
The experts need to be briefed about the project. This may
happen independently or in a meeting. The following
aspects need to be briefed –
1. Objectives of the estimation
2. Explanation of the project vision & scope
3. Competition and its nature in the project bidding
4. Timelines for completing the estimate and deliverables
expected from the experts
5. Any clarifications asked by the experts

.
Delphi
Collation of estimates received from the experts
The experts are expected only to give just to give one
figure for software development effort and optionally
software size. This is their best guess or hunch. Each of
these Oracles (experts) would give their opinion. Then
these opinions were tabulated as shown in the below table.
Name of Expert Size Effort
Expert 1 A X
Expert 2 B Y
Expert 3 C Z
Expert n K L

.
Delphi
Convergence of estimates and finalization
Once we collate the estimates, we can decide how to converge these estimates. Now
the convergence is achieved in two ways –
1. An average is derived using either the arithmetical average or statistical Mode from
the opinions offered by the experts
2. The extreme estimates (the highest figure estimate and the lowest figure estimate) are
interchanged – that is –
a. The highest estimate is given to the expert who gave the lowest figure
estimate
b. The lowest estimate is given to the expert who gave the highest figure
estimate
3. They are requested to review the estimate and give their opinion on it and if
necessary to revise their original estimate
4. This may bring about convergence between the extremes. The an average estimate
can be derived using either the arithmetical average or statistical Mode from the opinions
offered by the experts
Now this estimate (after achieving the convergence or deriving the average) would be
made use of for our purposes.

.
Delphi
Merits of Delphi Technique
1. Very useful when the organization does not have any in-house experts with the
domain knowledge or the development platform experience to come out with a quick
estimate
2. Very quick to derive an estimate
3. Simple to administer and use
Demerits of Delphi Technique
1. This is too simplistic
2. It may be difficult to locate right experts
3. It may also be difficult to locate adequate number of experts willing to participate in
the estimation
4. The derived estimate is not auditable
5. It is not possible to determine the causes of variance between the estimated value
and the actual values
6. Only size and effort estimation are possible – schedule would not be available.

Estimation – Wideband Delphi ScriptEstimation – Wideband Delphi Script
.

.
Delphi
Moderator leads the meeting, which consists of the following activities-
•The moderator explains the Wideband Delphi method to any new estimators.
• If any team member has not yet read the vision and scope document and
supporting documentation, the moderator reviews it with the team. (If this
happens, the meeting should be expected to take an extra half-hour to hour.)
•The moderator reviews the goal of the estimation session with the team, and
checks that each team member is sufficiently knowledgeable to contribute.
•The team discusses the product being developed and brainstorms any
assumptions.
•The team generates a task list consisting of 10/20 major tasks. These tasks
represent the top level of the work breakdown structure additional detail can be
generated later and/or discussed in the assumptions. This high-level task list is
the basis for the estimates that are going to be created.
•The team agrees on the units of estimation (days, weeks, pages, etc.).

.
Delphi
Each estimate
should
be made in terms
of effort,
not calendar time.
This means that if
the unit
of estimation is
"days," then
the estimate
should be for
the total number of
person-days spent.

.
Delphi
Estimation Session

.
Delphi
The wideband Delphi method is becoming increasing popular, especially
when there is no historical cost data available to aid in other estimation
techniques

COCOMOCOCOMO (Constructive Cost Model)(Constructive Cost Model)
Boehm postulated that any software development project
can
be classified into one of the following three categories based
on the development complexity:
 Organic
 Semidetached
 Embedded
For classification of the product in above categories Boehm
considered the characteristics of the product, development
team and development environment
Data processing programs – Application programs
Utility programs – Compilers, Linkers etc.
System programs – Operating systems
For Nominal Effort Estimation

COCOMOCOCOMO
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. S/W development
takes place in a familiar, stable environment. Similar to previously
developed projects. Relatively small and requires little innovation.
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. Its intermediate between Organic and Embedded.
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 exists. S/W
development involves tight, inflexible constraints and interface
requirements. The product requires great innovation.

COCOMOCOCOMO
COCOMO has three different models that reflect the
complexity
 The Basic Model
 The Intermediate Model
 The Detailed Model

COCOMOCOCOMO
COCOMO: Some Assumptions
The Primary cost driver is the number of
Delivered Source Instructions (DSI) developed by
the project
COCOMO estimates assume that the project will
enjoy good management by both the developer
and the customer
Assumes the requirements specification is not
substantially changed after the plans and
requirements phase

COCOMOCOCOMO
Input parameters of COCOMO
 First, the nominal development effort is estimated as a
function of product’s size in thousands of delivered source
instructions and the project’s development mode
 Second, COCOMO goes on to identify a set of effort
multipliers in the form of cost drivers.
 After weighing these cost drivers, COCOMO multiplies the
individual weights to obtain a final product
 This product is in turn multiplied with nominal effort to
obtain the estimated development effort.
In essence, the input parameters of COCOMO Estimation are-
 Software development effort multipliers or cost drivers
 The project features which determine if projects are Organic,
Semi-detached or Embedded

COCOMOCOCOMO
Additionally, classification is based on various features of the
project-
 Organizational understanding of product objectives
 Experience in working with related software systems
 Need for software conformance with pre-established
requirements
 Need for software conformance with external interface
specifications
 Concurrent development of associated new hardware and
operational procedures
 Need for innovative data processing architectures,
algorithms
 Premium on early completion
 Product size range

COCOMOCOCOMO
Boehm – software cost estimation should be done through
three stages – Basic COCOMO, Intermediate COCOMO, and
complete COCOMO
Basic COCOMO model
 KLOC is the estimated size of the software product expressed in Kilo lines
of code
 a1,a2, b1, b2 are constants for each category of software products
 Tdev is the estimated time to develop the software, expressed in months
 Effort is the total effort required to develop the software product,
expressed in person months (PM)

COCOMOCOCOMO
Every line of source text should be calculated as one LOC
irrespective of the actual number of instructions on that line.
Thus, if a single instruction spans several lines (say n lines),
it is considered to be nLOC.
Estimation of development effort
Mode Effort Schedule
Organic E=2.4*(KDSI)
1.05
TDEV=2.5*(E)
0.38
Semidetached E=3.0*(KDSI)
1.12
TDEV=2.5*(E)
0.35
Embedded E=3.6*(KDSI)
1.20
TDEV=2.5*(E)
0.32
A COCOMO man-month consists of 152 hours of working time
KDSI is the Thousand Delivered Source Instructions
TDEV is the Development Duration

COCOMOCOCOMO
Intermediate Model estimates the software
development effort by using 15 cost driver
variables besides the size variable used in
BASIC COCOMO

 After estimating the nominal development effort, COCOMO
estimation technique identifies software development effort
multipliers (cost drivers) under four different categories
COCOMOCOCOMO
Product Attributes
Required S/W reliability (RELY)
Data Base Size (DATA)
Product Complexity (CPLX)
Project Attributes
Use of modern programming
practices (MODP)
Use of software tools (TOOL)
Required development schedule
(SCED)
Computer Attributes
Execution time constraint(TIME)
Main storage constraint (STOR)
Virtual machine volatility(VIRT)
Computer turnaround
time(TURN)
Personnel Attributes
Analyst capability (ACAP)
Application experience (AEXP)
Programmer capability (PCAP)
Virtual machine experience
(VEXP)
Programming language
experience (LEXP)

COCOMOCOCOMO
Intermediate COCOMO
Mode Effort Schedule
Organic E=EAF*3.2*(KDSI)
1.05
TDEV=2.5*(E)
0.38
Semi- E=EAF*3.0*(KDSI)
1.12
TDEV=2.5*(E)
0.35
detached
Embedded E=EAF*2.8*(KDSI)
1.20
TDEV=2.5*(E)
0.32
•The Intermediate Model use an Effort Adjustment Factor (EAF) and slightly
different coefficients for the effort equations than the Basic model.
•The Effort Adjustment Factor is simply the product of the Effort Multipliers
corresponding to each of the cost drivers for your project.

COCOMOCOCOMO
Example of Intermediate COCOMO
Consider a database system for an office automation project. The
requirements document shows 4 modules needed-
Sizes are estimated as follows-
Data entry 0.6 KDSI
Data update 0.6 KDSI
Query 0.8 KDSI
Report gen 1.0 KDSI
---------------------------------
System Size 3.0 KDSI

COCOMOCOCOMO
Example of Intermediate COCOMO
The project is judged to be ORGANIC (so a=3.2, b=1.05)
The Manager rates project details as follows-
Characteristic Level EAF
Complexity High 1.15
Storage High 1.06
Experience Low 1.13
Programmer
Capabilities
Low 1.17
Person Months for the project
PM = (1.15*1.06*1.13*1.17)*3.2*(3.0)^1.05
PM = 1.61*3.2*3.17
PM = 16.33

COCOMOCOCOMO
Duration and Staffing
Once an estimate is obtained for effort (person months), a manager
must determine how many persons to put on the job. This will
ultimately determine the calendar – time duration of the project.
People and months are not interchangeable
More people does not mean proportionately less calendar time.
More people complicate communications and this complexity
translates into a project slowdown-
The Model:
Organic Duration = 2.5*EFFORT ^0.38
Semi Detached Duration = 2.5*EFFORT^0.35
Embedded Duration = 2.5*EFFORT^0.32

COCOMOCOCOMO
Duration and Staffing
We had 16.33 person months estimated for the database project.
The project was judged ORGANIC
DURATION = 2.5 * (16.33) ^ 0.38
DURATION = 2.5 * (2.89)
DURATION = 7.23 months
How many people to hire?
16.33 person months / 7.23 = 2.26 persons

COCOMOCOCOMO
Solution
What Project Type ? SEMI-DETACHED
Screen Drawing 2.00 KDSI
Object-base Management 3.50 KDSI
Algebra/Numerical methods 1.75 KDSI
Total Size 7.25 KDSI
Effort PM = EAF*3.0*(SIZE)^1.12
PM = (1.05*1.30*1.21*1.11*0.70*1.14)*3.0*(7.25)^1.12
PM = 1.46*3.0*9.19
PM = 40.25
Project Duration D = 2.5*(PM)^0.35
D = 2.5*(40.25) ^0.35
D = 2.5*3.64
D = 9.10

COCOMOCOCOMO
Staffing P = PM/D
P = 40.25/9.10
P = 4.42

COCOMOCOCOMO
Effort versus product size

COCOMOCOCOMO
Development time versus size

Function PointFunction Point
Development time versus size

How big is it? Well……. It depends on how you count.
 How big is the software? How big is it compared to other projects?
 How much effort is it going to take to build the software?
 How does our quality compare to other projects?
 How productive are we compared to other projects?
Size is fundamental to all these metrics. In order to answer the questions, we
need to be able to measure size in a standardized way that allows us to
compare ourselves against other projects and external benchmarks
So how should we measure size? The LOC measure is frequently rejected because
it does not seem to adequately address the functionality, complexity, and
technology involved and may cause the wrong organizational behavior
LOC measures the physical length of the software itself. When well specified, it
is a reliable measurement. However, with visual and nonprocedural languages,
such as Visual Basic, it frequently misses the mark. Moreover, it is always
lacking in representing the size of the functionality of a system. Consequently,
we need some other size measurements as well.

Measuring Functionality
One issue with using LOC, or any physical size measurement, as a
measure of productivity is that it has little to do with problem being solved
and more to do with the software development technology itself.
Customers want solutions and care little for the language or technology
used to create them
Consider what strategy you might use to size a system, based on
what it needs to do rather than how it does it internally.
One possible way would be to count the inputs, outputs, interfaces, and
databases in a system. This is the function point (FP) approach, once you
add inquiries as well.

Function Point Basics
 On a conceptual level, function point analysis helps define two abstract
levels of data – data at rest and data in motion
 Data in motion
Data in motion is handled via transactional function types or simple
transactions. All software applications will have numerous elementary
processes or independent processes to move data. Transactions (or
elementary processes) that bring data from outside the application
domain (or application boundary) to inside that application boundary are
referred to as external inputs (EI).
Transactions (or elementary processes) that take data from a resting
position (normally on a file) to outside the application domain (or
application boundary) are referred as either an external outputs (EO) or
external inquiries (EQ)
 Data at rest
Data at rest that is maintained by the application in question is classified
as internal logical files (ILF). Data at rest that is maintained by another
application in question is classified as external interface files (EIF).

Types of Function Point Counts:
 Development Project Function Point Count
 Enhancement Project Function Point Count
 Application Function Point Count

Function Point Counting Process
1.Determine Type of Function Point Count
2.Determine the application boundary
3.Identify and rate transactional function types to
determine their contribution to the unadjusted
function point count
4.Identify and rate data function types to
determine their contribution to the unadjusted
function point count
5.Determine the value adjustment factor (VAF)
6.Calculate the adjusted function point count

FPA Steps for Transactional Function Types:
Each transaction must be an elementary process. An elementary process
is the smallest unit of activity that is meaningful to the end user in the
business. It must be self-contained and leave the business in consistent
state
Application Documentation
FPA Rules
Transaction Model
Data Model
Transaction Rules
Functional Complexity
Tables of Weight
T1. Identify Transactions
T2. Type of Transactions (EO, EI &
EQ)
T3. Number of DET’s and FTR’s
T4. Determine Low, Avg and High
T5. Values Determined
T6. All transactions are summed to
obtain of UFP for Transactions

FPA Steps for Files:
Application Documentation
FPA Rules
Transaction Model
Data Model
File Rules
Functional Complexity
Tables of Weight
T1. Identify Files
T2. Type of File (ILF or EIF)
T3. Number of DET’s and RET’s
T4. Determine Low, Avg and High
T5. Values Determined
T6. All files are summed to obtain
of UFP for files

 Primary goals of FPA is to evaluate a system’s capabilities from user’s
point of view
 From user’s perspective a system helps them do their job by providing 5
basic functions.
 Two of these address the data requirements of an end user and are
referred to as data functions. The remaining three address the user’s need
to access data and are referred to as transactional functions-
Data Functions
 Internal Logical Files (ILF)
 External Interface Files (EIF)
Transactional Functions
 External Inputs (EI)
 External Outputs (EO)
 External Inquiries (EQ)

 Internal Logical Files - The first data function allows users to utilize
data for which they are responsible to maintain. For example, a pilot may
enter navigational data through a display in the cockpit prior to departure.
The data is stored in a file for use and can be modified during the mission.
Therefore, the pilot has the responsibility to maintain the file that contains
the navigational information. Logical groupings of data in a system,
maintained by an end user, are referred to as internal logical files (ILF).
 External Interface Files - The second data function a system provides
an end user is also related to logical groupings of data. In this case, the
user is not responsible for maintaining the data. The data resides in
another system and is maintained by another user or system. The user of
the system being counted requires this data for reference purposes only.
For example, it may be necessary for a pilot to reference position data
from a satellite or ground-based facility during flight. The pilot does not
have the responsibility to update data at these sites but must reference it
during the flight. Groupings of data from another system that are used
only for reference purposes are defined as external interface files (EIF).


The remaining functions address the user's capability to access the
data contained in ILFs and EIFs. This capability includes
maintaining, inquiring, and outputting of data. These are referred
to as transactional functions.
 External Input - The first transactional function allows a user to
maintain ILFs through the ability to add, change, and delete the data. For
example, a pilot can add, change, and delete navigational information
prior to and during the mission. In this case the pilot is utilizing a
transaction referred to as an external input (EI). An external input gives
the user the capability to maintain the data in ILF's through adding,
changing, and deleting its contents.
 External Output - The next transactional function gives the user the
ability to produce outputs. For example, a pilot has the ability to
separately display ground speed, true air speed, and calibrated air speed.
The results displayed are derived using data that is maintained and data
that is referenced. In function point terminology, the resulting display is
called an external output (EO).

 External Inquiries - The final capability provided to users through a
computerized system addresses the requirement to select and display
specific data from files. To accomplish this, a user inputs selection
information that is used to retrieve data that meets the specific criteria. In
this situation there is no manipulation of the data. It is a direct retrieval of
information contained on the files. For example, if a pilot displays terrain
clearance data that was previously set, the resulting output is the direct
retrieval of stored information. These transactions are referred to as
external inquiries (EQ).
In addition to the five functional components described above, there
are two adjustment factors that need to be considered in Function
Point Analysis.

 Identifying RET’s, DET’s and FTR’s
All of the components are rated based upon DET’s and either RET’s or FTR’s
Component RET’s FTR’s DET’s
External Inputs (EI)  
External Outputs (EO)  
External Inquiries (EQ)  
External Interface Files (EIF)  
Internal Logical Files (ILF)  

 Transaction DET’s
◦ External Inputs: Data Input Fields, Error Messages, Calculated Values,
Buttons
◦ External Outputs: Data Fields on a Report, Calculated values, Error
messages, and Column Headings that are read from an ILF. Like an EQ
and EO can have an input side and output sides
◦ External Inquiries: Input side – field used to search by, the click of the
mouse. Output side – displayed fields on a screen
 DET’s for GUI
◦ In GUI applications, a data element is information that is stored on an internal
logical file or that is used to invoke a transaction
◦ Radio Buttons – are treated as data element types. Within a group of, a frame,
radio buttons the user has the option of selecting only one radio button; so only one
data element type is counted for all the radio buttons contained in the frame

 Check Boxes: differ from radio buttons in that more than one check box
can be selected at a time. Each check box, within a frame, that can be
selected should be treated as a data element
 Command Buttons: may specify an add, change, delete or inquire action.
A button, like OK, may invoke several different types of transactions
For example, a simple application to track distributors could have fields
for Distributor Name, Address, City, State, Zip, Phone Number, and Fax
Number. This would represent seven fields or (seven data elements) and
the add command button would represent the eighth data element. In
short, the “add” external input represent a one external input with eight
data elements, the “change” external input represents another external
input with eight (seven data elements plus the “change” command
button), and the “delete” external input represents the last external input
with eight data elements (seven fields plus the “delete” command
button).

 Display of graphical images or icons – A display of a graphical image is
simply another data element. An inventory application, for example, may
contain data about parts. It may contain part name, supplier, size, and
weight and include a schematic image of the part. This schematic is
treated as a single data element.
 Sound Bytes - Many GUI applications have a sound byte attached. This
represents one data element. The number of notes played is simply
recursive information. If the length of the sound byte increases, then the
data element remains one. For example, you can play the “Star Spangled
Banner” for two seconds or four seconds, but you’ll still count the sound
bytes as one data element. The longer it is played the more recursive
information it has.
 Photographic Images - A photographic image is another data element,
and is counted as one. A human resource application may display
employee name, start date, etc. and a photograph of the employee. The
photograph is treated the same as employee name or employee start
date. The photograph is stored and maintained like any other piece of
information about the employee.

 Messages –
There are three types of messages that are generated in a GUI
application: error messages, confirmation messages and
notification messages. Error messages and confirmation messages
indicate that an error has occurred or that a process will be or have been
completed. They are not an elementary or independent process alone, but
they are part of another elementary process. A message that would state,
“zip code is required” would be an example of an error message. A
message that would state, “are you sure you want to delete customer” is
an example of a confirmation message. Neither type of message is treated
as a unique external output, but each is treated as a data element for the
appropriate transaction.

On the other hand, a notification messages is a business type
message. A notification is an elementary process, has some meaning
to the business user and is independent of other elementary processes. It
is the basis of processing and a conclusion being drawn. For example, you
may try to withdraw from an ATM machine more money than you have in
your account and you receive the dreaded message, “You have insufficient
funds to cover this transaction.” This is the result of information being
read from a file regarding your current balance and a conclusion being
drawn. A notification message is treated as an External Output.

External Inputs: External Inputs (EI) - is an elementary process in which
data crosses the boundary from outside to inside. This data is coming
external to the application. The data may come from a data input screen
or another application. The data may be used to maintain one or more
internal logical files. The data can be either control information or
business information. If the data is control information it does not have to
maintain an internal logical file.
If an external input adds, changes and deletes (maintains) information on
an internal logical file, then this represents three external inputs. External
inputs (especially change & delete) may be preceded by an external
inquiry (see the section on external inquiries). Hence a full function screen
is add, change, delete and inquiry

 Rating: Like all components, EI’s are rated and scored. The rating is
based upon the number of data element types (DET’s) and the file types
referenced (FTR’s). DET’s and FTR’s are discussed earlier. The table below
lists both the level (low, average or high) and appropriate score (3, 4 or
6).
EI’s can be business data, control data and rules base data.
Business data: Customer Name, Address, Phone, and so on and so forth
Control information changes or alters the state (or behavior) of the
application. Control information specifies how, what, and when data will be
processed

 External Outputs (EO)- an elementary process in which derived data
passes across the boundary from inside to outside . Additionally, an EO
may update An ILF. The data creates reports or output files sent to other
applications. These reports and files are created from information
contained in one or more internal logical files and external interface files.
 Rating: The ratings is based upon the number of data elements (DET’s)
and the file type referenced (FTR’s). The rating is based upon the total
number of unique (combined unique input and output sides). DETs and
FTRs were discussed earlier in this section. The table below lists both the
level (low, average or high) and appropriate score (4, 5 and 7)

 External Outputs (EO)- examples – Unlike other components EO’s almost
always contain business data. Rule based data and control based ‘outputs’
are almost always considered External Inquiries. This is true due to the
fact that rule data and control type data is not derived (or derivable)
Notification messages are considered EO’s. A notification message differs
from an error message. A notification message is an elementary process,
while an error message (or confirmation message) is part of an
elementary process. A notification message is a result of some business
logic processing. For example, a trading application may notify a broker
that the customer trying to place an order does not have adequate funds
in their account
Derived Data displayed in textual fashion (rows and columns) and graphical
format is an example of two external outputs

 Special issues and concerns
1. When to count DET’s for Report Headings: Report headings are
counted when they are dynamic. That is, if report headings are being read
from an internal logical file they should be counted as DET’s
2. Can an External Output have an input side?: Since the input side is
not stand-alone (independent or an elementary process) it should be
considered as part of the entire external output. The FTR’s and DET’s used
to search should be combined with unique outside DET’s and FTR’s for at
grand total FTR’s and DET’s for the entire EO. In short, an external output
can have an input side.
3. Can an External Output update an Internal Logical File?: An
external output can update an internal logical file, but it is incorrect to say
that an external output can maintain an internal logical file. The update is
part of the elementary process of the external output. An external input
maintains data on and ILF file. The maintain process is an elementary
process alone. The definition for maintaining is discussed in the internal
logical file and external input sections of this book.

 External Inquiries (EQ)- an elementary process with both input and
output components that result in data retrieval from one or more internal
logical files (ILFs) and external interface files. The input process does not
update or maintain any FTR’s (Internal Logical Files or External Interface
files) and the output side does not contain derived data
 Transactions between applications should be referred to as interfaces.
You can only have an external output or external inquiry of data external
to your application. If you get data from another application and add it to
a file in your application, this is a combination get and add (external
inquiry and external input)

 External Inquiries (EQ)- examples – EQ’s can contain business data,
control data and rules based data
Business Applications: An example of Business data is customer names,
addresses, phone number, so on and so forth. An example for Rules Data
is a table entry that tells how many days a customer can be late before
they are turned over for collection
Drop Down List (a listing of customers by name) would be an example for an
EQ
A screen full of customer address information would be an example of an EQ
Reset (or restore) functionality where all the modified fields are reset to their
saved values. The key to understanding this an external query is the
“reset to their saved values”. Clearly a table is being read

 Special issues and concerns
1. Can an External Inquiry not have an input side?: Even though it may
not be visible all external inquiries have an input side. In cases where the
input side is not readily visible is referred to as an implied inquiry
2. Can an External Inquiry Update an Internal Logical File?: Like an
external output, an external inquiry may update an internal logical file,
but it is incorrect to say that an external inquiry can maintains an internal
logical file. The update is part of the elementary process of the external
inquiry. The definition for maintaining is discussed in the internal logical
file and external input sections of this book. The only component that
maintains an internal logical file is an external input.

 Internal Logical Files (ILF)- a user identifiable group of logically related
data that resides entirely within the application boundary and is
maintained through External Inputs. An internal logical file has the
inherent meaning it is internally maintained, it has some logical structure
and it is stored in a file.
 Rating: Like all components, ILF’s are rated and scored. The rating is
based upon the number of data elements (DET’s) and the record types
(RET’s). DET’s and RET’s were discussed earlier. The table below lists both
the level (low, average or high) and appropriate score (7, 10 or 15).

 External Interface Files (EIF)- a user identifiable group of logically related
data that is used for reference purposes only. The data resides entirely
outside the application boundary and is maintained by another
applications external inputs. The external interface file is an internal
logical file for another application. An application may count a file as
either a EIF or ILF not both. An interface has to be developed to get the
data and it is stored in a file
 Rating: The rating is based upon the number of data elements (DET’s)
and the record types (RET’s).

 General System Characteristics (GSC): Describe and define the concepts
necessary to rate GSC’s to determine the overall Value Adjustment Factor.
 The Value Adjustment Factor (VAF) is based on 14 general system
characteristics that rate the general functionality of the application being
counted. Each characteristic has associated descriptions to determine the
degrees of influence
0 Not present, or no influence
1 Incidental Influence
2 Moderate Influence
3 Average Influence
4 Significant Influence
5 Strong Influence throughout

Function Points
These characteristics are really “implementation difficulty” factors.

Function Points
1. Data Communications

Function Points
2. Distributed Data Processing

Function Points
3. Performance

Function Points
4. Heavily Used Configuration

Function Points
5. Transaction Rate

Function Points
6. Online Data Entry

Function Points
7. End-User Efficiency
• Navigational aids (for example, function keys, jumps, dynamically generated
menus)
• Menus
• Online help and documents
• Automated cursor movement
• Scrolling
• Remote printing (via online transactions)
• Preassigned function keys
• Batch jobs submitted from online transactions
• Cursor selection of screen data
• Heavy use of reverse video, highlighting, colors underlining, and other
indicators
• Hard copy user documentation of online transactions
• Mouse interface
• Pop-up windows.
• As few screens as possible to accomplish a business function
• Bilingual support (supports two languages; count as four items)
• Multilingual support (supports more than two languages; count as six items)

Function Points
7. End-User Efficiency

Function Points
8. Online Update

Function Points
9. Complex Processing
Complex processing is a characteristic of the application. The following
components are present.
• Sensitive control (for example, special audit processing) and/or application
specific security processing
• Extensive logical processing
• Extensive mathematical processing
• Much exception processing resulting in incomplete transactions that must
be processed again, for example, incomplete ATM transactions caused by
TP interruption, missing data values, or failed edits
• Complex processing to handle multiple input/output possibilities, for
example, multimedia, or device independence

Function Points
9. Complex Processing

Function Points
10. Reusability

Function Points
11. Installation Ease

Function Points
12. Operational Ease

Function Points
13. Multiple Sites

Function Points
14. Facilitate Change
The application has been specifically designed, developed, and supported to
facilitate change.
The following characteristics can apply for the application:
• Flexible query and report facility is provided that can handle simple
requests; for example, and/or logic applied to only one internal logical file
(count as one item).
• Flexible query and report facility is provided that can handle requests of
average complexity, for example, and/or logic applied to more than one
internal logical file (count as two items).
• Flexible query and report facility is provided that can handle complex
requests, for example, and/or logic combinations on one or more internal
logical files (count as three items).
• Business control data is kept in tables that are maintained by the user with
online interactive processes, but changes take effect only on the next
business day.
• Business control data is kept in tables that are maintained by the user with
online interactive processes, and the changes take effect immediately
(count as two items).

Function Points
14. Facilitate Change

Function Points
Tabulating:

Functional Complexity - The first adjustment factor considers the
functional complexity for each unique function. Functional complexity is
determined based on the combination of data groupings and data
elements of a particular function. The number of data elements and
unique groupings are counted and compared to a complexity matrix that
will rate the function as low, average, or high complexity. Each of the five
functional components (ILF, EIF, EI, EO, and EQ) has a unique complexity
matrix. Table 2 is the complexity matrix for external outputs.
1-5 DETs 6-19 DETs 20+ DETs
0 or 1 FTR L L A
2 or 3 FTRs L A H
4+ FTRs A H H
Complexity UFP
L (Low) 4
A (Average) 5
H (High) 7
Table 2: External Output Matrix.

Function name
Function
Type
Record
Element Types*
Data Element
Type
File Types
Referenced
Unadjusted
Function Points
Navigational data ILF 3 36 N/A 10
Positional data EIF 1 3 N/A 5
Navigational data add EI N/A 36 1 4
Navigational data
change
EI N/A 36 1 4
Navigational data
delete
EI N/A 36 1 4
Ground speed display EO N/A 3 20 7
Air speed display EO N/A 3 20 7
Calibrated air speed
display
EO N/A 3 20 7
Terrain clearance
display
EQ N/A 1 1 3
Total unadjusted count 51
* Functional complexity for data functions is based on record element types. Data complexity for transactional functions is based on
file types referenced. All complexity values have been assumed for this example.
Table 3: Function Point Count by Function.

•DET: a data element type is a unique user recognizable, non-repeated field.
For example, an account number that is stored in multiple fields is counted
as one DET.
•RET: A record element type is a user recognizable subgroup of data
elements within an ILF or EIF
• FTR: A file type referenced is
 An internal logical file read or maintained by a transactional function
or
 An external interface file read by a transactional function

Function Points
Counting Function Points – As per IFPUG Function Point Analysis
 The system’s functionality is decomposed into components of inputs,
outputs, external interface files (maintained by another system), internal
data files (maintained by this system), and inquiries;
 Each component’s difficulty is rated as simple, average or complex;
 A complexity rating is given to each component based on its type and
difficulty as shown in the table-

Function Points
 The unadjusted function points (UFPs) are counted by summing all of the
complexity ratings
 A value adjusted factor (VAF) is calculated based on the complexity of the
overall system
 The adjusted function point (AFP) count is calculated by multiplying VAF
by the UFPs
 The complexity ratings represent the relative implementation effort. For
example, from the FPA viewpoint, an average interface to an external file
is harder to implement than an average inquiry, hence, the weighting for
the average interface is 7 versus 4 for the average inquiry. That is, the
external interface file requires 1.75 times more effort than the inquiry.
 VAF – based on 14 general system characteristics (GSCs), each is rated
on a scale of 0 to 5. With 0 meaning no influence (or not present) and 5
meaning that characteristic has an extensive influence throughout the
project.

Function Points
 AFPs = UFPs * (0.65 + 0.01 * VAF)
Converting Function Points to Physical Size
The primary purpose of the gearing factors is to convert function
points to lines of code, based on the implementation language
 The only issue with converting FPs to LOC is which gearing factor to pick.
You could choose the average, the maximum, the minimum, the median,
The David Consulting Group (DSG) number, or the Jones number. DSG
data is preferable because they are newer and have more data points.
 After that, hopefully, we would have some experience with past projects
to guide us. If not, and unless we had more insight into the ease of using
the language for this specific system, then we would start with the
average, use a range to demonstrate the potential variance, and factor it
into our risk management plan

Function Points Pros & Cons
 Technology Independent
 Effective early (requirements phase) in the software life cycle
 Well-documented and specified
 Supported by standards and an international users group
 Backed by substantial data that supports the methodology
 Reasonably reliable and accurate
 Useful in negotiations with users and management, and
 Insightful for understanding the source of effort
Function point do have their issues-
 They are semantically difficult. Many of the terms and factors are from
1970s and 1980s and are difficult to understand in the context of today’s
systems
 They include many steps
 There are no tools available that count function points
 There can be significant subjectivity in adjustment factors

Project ManagementProject Management
Activities in Software Project Management
 Project Planning
 Project Scheduling
 Risk Management
 Managing people

Project Management - PlanningProject Management - Planning
 Project Planning
◦ The biggest single problem that afflicts software developing is that of
underestimating resources required for a project
◦ Developing a realistic project plan is essential to gain an understanding
of the resources required, and how these should be applied
 Types of plan:
◦ Software Development Plan – The central plan, which describes how
the system will be developed
◦ Quality assurance Plan – Specifies the quality procedures and
standards to be used
◦ Validation Plan – Defines how a client will validate the system that
has been developed.
◦ Configuration Management Plan – Defines how the system will be
configured and installed.
◦ Maintenance Plan – Defines how the system will be maintained
◦ Staff Development Plan – Describes how the skills of the participants
will be developed

Project Management TheoryProject Management Theory
 Since the earliest days of the computer software industry
managing of software development projects has been
fraught with uncertainty and risk
◦ What methods are appropriate for the management of software
development projects?
◦ What theoretical aspects of project management can be applied
to the software environment?
◦ What gaps exist in current project management methods that
should be closed to meet these new needs?

Project Management TheoryProject Management Theory

Software EstimationSoftware Estimation
 Measurement in software is not always easy. How do you predict
how long it will take to build a system using tools and techniques
you’ve never used before?
 Just envisioning the software that will be developed to meet a set
of requirements may be difficult, let alone trying to determine the
building blocks and how they will mortared together.
 Many characteristics of the software seem difficult to measure.
How do you measure quality or robustness? How do you measure
the level of complexity?
 How do you measure the complexity of a program? What does
complexity even mean?
 How do you measure productivity? If someone can write 100 lines
of code in two hours to program a function, but the software has
five bugs in it, is it reasonable productivity? And what is that
productivity? Better yet, if someone else can program the same
function in one line of code, in one hour, what is their
productivity? Whose productivity is better?

 Software Measurement is difficult – it is abstract and
difficult to visualize and touch. It is also a relatively new
discipline: we are still learning
 Measurement Models
◦ The key to “making the unmeasureable measurable” is models
◦ Models makes measurement possible
◦ Text Models
Text models tend to be least effective, but the most common. It is
difficult to adequately describe complex situations and dynamics using
just words
Text Model for Software Development
Effort: The time required to develop a product, expressed as
increments of staff development time (e.g. staff months / hours). In
general effort is a function of size and results in cost

◦ Text Models
Text models tend to be least effective, but the most common. It is
difficult to adequately describe complex situations and dynamics using
just words
Text Model for Software Development
Features: The requirements of the product to be developed
Size: The magnitude of the product to be developed. In general, size is
a function of features
Defects: The incompleteness of the product. In general, defects are a
function of size and schedule.
Schedule: The total development time; completion times for principal
milestone. In general, schedule is a function of effort and resources.
Resources: The number of developers applied to the product
development

Diagrammatic Model of Software
Development

Algorithmic Model

Gearing Factors

Gearing
Factors

Measuring ComplexityMeasuring Complexity
Technical skill is mastery of complexity while creativity is a
mastery of simplicity
Be as simple as possible, but no simpler.
Structural Complexity
Structural complexity looks at the design and structure of the
software itself. Simplicity in design beings in the concepts of
modularity, loose coupling, and tight cohesion.
Simplicity in structure brings in the concepts of simple control
flows and simple interfaces

Measuring ComplexityMeasuring Complexity
Structural Complexity Metrics
Metric Definition
Size Typically measures LOC or function points
Cyclomatic
Complexity
Measures the control flow within a module
Halstead’s
Complexity
Measures number of “operators” and “operands” in
the code
Information flow Measures the flow of data into and out of modules
System
Complexity
Measures the complexity of the entire system in
terms of maintainability and / or overall design
Object-Oriented
Structural metrics
Measures the different structure of object-oriented
programs (versus functionally designed programs)

Estimating EffortEstimating Effort
We categorize estimation methodologies as:
 Expert Opinion
 Using Benchmark Data
 Analogy
 Proxy points
 Custom Models
 Algorithmic Models

 Expert Estimation
There are two approaches to expert estimation methodologies – activity
decomposition and system decomposition. One looks at the tasks to be
performed, while the other looks at the components and modules of the
system
Typically, the work gets divided into 6 areas of responsibilities
Requirements, Design, Coding & Unit Testing, System Testing, Project
Management & Administration, and Training and Documentation.
System Decomposition – you decompose the system into lower level
modules, estimate the effort associated with each module and total the
estimates. A variation of this approach is function block estimation
method. It is based on the concept of having an average size for
function blocks (or components) and having an average size for sub
function blocks (or modules).

 The Wideband Delphi
The Wideband Delphi estimation method is a consensus-based
estimation technique for estimating effort. It derives from the
Delphi Method which was developed in the 1940s at the RAND
Corporation as a forecasting tool. It has since been adapted
across many industries to estimate many kinds of tasks, ranging
from statistical data collection results to sales and marketing
forecasts.
Barry Boehm and John A. Farquhar originated the Wideband
variant of the Delphi method in the 1970s. They called it
"wideband" because, compared to the existing delphi method, the
new method involved greater interaction and more
communication between those participating.

The Wideband Delphi
 Boehm's original steps from this book were:
 Coordinator presents each expert with a specification and an
estimation form.
 Coordinator calls a group meeting in which the experts discuss
estimation issues with the coordinator and each other.
 Experts fill out forms anonymously.
 Coordinator prepares and distributes a summary of the estimates
 Coordinator calls a group meeting, specifically focusing on having
the experts discuss points where their estimates vary widely
 Experts fill out forms, again anonymously, and steps 4 to 6 are
iterated for as many rounds as appropriate.

You can understand a data file by considering that-
 A set of characters (or numbers) form a data element
 A set of data elements constitute a record
 A set of records form a file
 If CRUD (Create, Read, Update and Delete) factor applies to a file
in the system, it is likely to be an ILF, and if it is read only, the
file is an EIF

Project management 02112009

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (13)

Similar to Project management 02112009

Similar to Project management 02112009 (20)

More from Manish Chaurasia

More from Manish Chaurasia (20)

Recently uploaded

Recently uploaded (20)

Project management 02112009