.

(3) Function Point Metrics

Function point metrics provide a standardized
method for measuring the various functions of a software
application.
Function point metrics, measure functionality
from the users point of view, that is, on the basis of what
the user requests and receives in return. Information
domain values:
Number of user inputs Distinct input from user

Number of user outputs Reports, screens, error

messages, etc.
Number of user inquiries On line input that
generates some result
Number of files Logical file (database)

Number of external interfaces Data

files/connections as interface to other systems Formula to
count FP is FP = Total Count * [0.65 + 0.01*(Fi)]
Where, Total count is all the counts times a weighting
factor that is determined for each organization via
empirical data. Fi (i=1 to 14) are complexity adjustment
values.
Value Adjustment Factors (Fi): F1. Data CommunicationF4.
Heavily Used Configuration F7. End-User Efficiency

F10. Reusability F13. Multiple Sites

Example:
A simple example:

inputs

outputs

files

inquiries

8average

interfaces

F2. Distributed Data Processing F5. Transaction RoleF8.

Online UpdateF11. Installation Ease

F14. Facilitate Change

F3. PerformanceF6. Online Data Entry F9. Complex

Processing F12. Operational Ease

3simple X3=9 4average X 4 =16 1 complex X 6 = 6

 6average X 5 =30

2complex

5 complex

X 7 =14 X15=75 X 4 =32

X 7 = 21 X 10 = 40 Unadjusted function points 243

F09. Complex internal processing =3 F10. Code to be

reusable =2 F03. High performance =4 F13. Multiple sites
=3 F02. Distributed processing =5 Project adjustment
factor =17

Adjustment calculation:Adjusted FP = Unadjusted FP X

[0.65 + (adjustment factor X 0.01)]

. = 243 X [0.65+( 17 X0.01)]

. = 243 X [0.82]

. = 199.26 Adjusted function points

(4) Software Project Estimation

. Software project estimation is a form of problem
solving, and in most cases, the problem to be solved (i.e.,
developing a cost and effort estimate for a software
project) is too complex to be considered in one piece.
. Estimation of resources, cost, and schedule for a
software engineering effort requires experience, access to
good historical information (metrics), and the courage to
commit to quantitative predictions when qualitative
information is all that exists.
. Software project estimation is a form of problem
solving, and in most cases, the problem to be solved is too
complex to be considered in one piece.
. For this reason, you should decompose the problem,
characterizing it as a set of smaller (and hopefully, more
manageable) problems. Software Sizing Fuzzy
logic sizing:
. This approach uses the approximate reasoning
techniques that are the cornerstone of fuzzy logic.
. To apply this approach, the planner must identify the
type of application, establish its magnitude on a
qualitative scale, and then refine the magnitude within the
original range. Function point sizing:

The planner develops estimates of the information domain

characteristics.Standard component sizing:Software is
composed of a number of different standard components
that are generic to a particular

application area.

Change sizing:
This approach is used when a project encompasses
the use of existing software that must be modified in some
way as part of a project.
The planner estimates the number and type (e.g.,
reuse, adding code, changing code, and deleting code) of
modifications that must be accomplished. Problem-
Based Estimation
Start with a bounded statement of scope

Decompose the software into problem functions that

can each be estimated individually
Compute an LOC or FP value for each function

Derive cost or effort estimates by applying the LOC

 or FP values to your baseline productivity metrics (e.g.,
LOC/person-month or FP/person-month)
Combine function estimates to produce an overall
estimate for the entire project

(5) COCOMO Model (Empirical

Process Model)
. Stands for Constructive Cost Model

. As with all estimation models, it requires sizing

information and accepts it in three forms: object points,
function points, and lines of source code
. Application composition model - Used during the
early stages of software engineering when the following
are important

Prototyping of user interfaces

Consideration of software and system

interaction

Assessment of performance

Evaluation of technology maturity

. Early design stage model Used once
requirements have been stabilized and basic software
architecture has been established
. Post-architecture stage model Used during the
construction of the software Organic,
Semidetached and Embedded software
projects
. Organic: A development project can be considered
of organic type, if the project deals with developing a well
 understood application program, the size of the
development team is reasonably small, and the team
members are experienced in developing similar types of
projects.
. Semidetached: A development project can be
considered of semidetached type, if the development
consists of a mixture of experienced and inexperienced
staff. Team members may have limited experience on
related systems but may be unfamiliar with some aspects
of the system being developed.
. Embedded: A development project is considered to
be of embedded type, if the software being developed is
strongly coupled to complex hardware, or if the stringent
regulations on the operational procedures exist. The basic
COCOMO model gives an approximate estimate of the
project parameters. The basic COCOMO estimation model
a2
is given by following expressions: Effort = a1 x (KLOC)
PM (person Month) Time of Development = b1 x (Effort)
b2
MonthsWhere, a1,a2,b1,b2 are constants for each
category of software products Estimation of Effort
1.05
Organic: Effort = 2.4 (KLOC) PM
1.12
Semi-detached: Effort = 3.0 (KLOC) PM
1.20
Embedded: Effort = 3.6 (KLOC) PM

Estimation Time of Development

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

Months Months

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

(6) Software Project Planning

. The objective of software project planning is to
provide a framework that enables the manager to make
reasonable estimates of resources, cost, and schedule.
. In addition, estimates should attempt to define best-
case and worst-case scenarios so that project outcomes
can be bounded. Although there is an inherent degree of
uncertainty, the software team embarks on a plan that has
been established as a consequence of these tasks.
. Therefore, the plan must be adapted and updated as
the project proceeds. Task Set for Project
Planning 1. Establish project scope.2. Determine
feasibility.3. Analyze risks.4. Define required resources. a.
Determine required human resources. b. Define reusable
software resources. c. Identify environmental resources. 5.
Estimate cost and effort.a. Decompose the problem.b.
Develop two or more estimates using size, function points,
process tasks, or use cases. c. Reconcile the estimates. 6.
Develop a project schedule.a. Establish a meaningful task
set.b. Define a task network.c. Use scheduling tools to
develop a time-line chart. d. Define schedule tracking
 mechanisms.

(7) Project Scheduling

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

. CompartmentalizationThe product and process must

be decomposed into a manageable number of activities
and tasks
. InterdependencyTasks that can be completed in
parallel must be separated from those that must
completed serially
. Time allocationEvery task has start and completion
dates that take the task interdependencies into account
. Effort validationProject manager must ensure that on
any given day there are enough staff members assigned to
completed the tasks within the time estimated in the
project plan
. Defined ResponsibilitiesEvery scheduled task needs
to be assigned to a specific team member
. Defined outcomesEvery task in the schedule needs to
have a defined outcome (usually a work product or
 deliverable)
. Defined milestonesA milestone is accomplished when
one or more work products from an engineering task have
passed quality review Scheduling

Scheduling of a software project does not differ

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

(8) Project Tracking

. The project schedule provides a road map for a
software project manager.
. It defines the tasks and milestones.

. Several ways to track a project schedule:

 conducting periodic project status meeting

evaluating the review results in the software

process

determine if formal project milestones have

been accomplished

compare actual start date to planned start

date for each task

informal meeting with practitioners

. Project manager takes the control of the schedule in
the aspects of:

project staffing

project problems

project resources

reviews

project budget (9) Risk

Management
. A risk is a potential problem it might happen and it
might not
. Conceptual definition of risk

1 Risk concerns future happenings

2 Risk involves change in mind,

opinion, actions, places, etc.

3 Risk involves choice and the

uncertainty that choice entails
. Two characteristics of riskUncertainty the risk may
or may not happen, that is, there are no 100% risks (those,
instead, are called constraints)Loss the risk becomes a
reality and unwanted consequences or losses occur
Categories of risk
Project risks

1 They threaten the project plan

2 If they become real, it is likely that

the project schedule will slip and that costs will
increase
Technical risks

1 They threaten the quality and

timeliness of the software to be produced

2 If they become real, implementation

may become difficult or impossible
Business risks

1 They threaten the feasibility of the

software to be built

2 If they become real, they threaten

the project or the product
Known risks

Those risks that can be uncovered after careful

evaluation of the project plan, the business and

technical environment in which the project is being

developed, and other reliable information

sources (e.g., unrealistic delivery date)

Predictable risks Those risks that are deduced from

past project experience (e.g., past turnover)
 Unpredictable risks Those risks that can and do occur,
but are extremely difficult to identify in advance

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

. One method for identifying risks is to create a risk

item checklist.
. The checklist can be used for risk identification and
focuses on some subset of known and predictable risks in
the following generic subcategories:
. Product sizerisks associated with the overall size of
the software to be built or modified.
. Business impactrisks associated with constraints
imposed by management or the marketplace.
. Stakeholder characteristicsrisks associated with the
sophistication of the stakeholders and the developers
ability to communicate with stakeholders in a timely
manner.
. Process definitionrisks associated with the degree
 to which the software process has been defined and is
followed by the development organization.
. Development environmentrisks associated with the
availability and quality of the tools to be used to build the
product.
. Technology to be builtrisks 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 experiencerisks associated with the
overall technical and project experience of the software
engineers who will do the work.

(10) Risk Estimation / Risk

Projection Risk Projection Steps
Establish a scale that reflects the perceived
likelihood of a risk (e.g., 1-low, 10-high)
Explain the consequences of the risk

Estimate the impact of the risk on the project

and product
Note the overall accuracy of the risk projection
so that there will be no misunderstandings Risk
Mitigation, Monitoring, and Management

Risk mitigation (proactive planning for risk

avoidance)
Risk monitoring (assessing whether predicted
risks occur or not, ensuring risk aversion steps are being
properly applied, collect information for future risk
analysis, attempt to determine which risks caused which
problems)
Risk management and contingency planning
(actions to be taken in the event that mitigation steps
have failed and the risk has become a live problem)
The goal of the risk mitigation, monitoring and
management plan is to identify as many potential risks as
possible.
When all risks have been identified, they will
then be evaluated to determine their probability of
occurrence,
Plans will then be made to avoid each risk, to
track each risk to determine if it is more or less likely to
occur, and to plan for those risks should they occur.
It is the organizations responsibility to perform
risk mitigation, monitoring, and management in order to
produce a quality product.
The quicker the risks can be identified and avoided,
the smaller the chances of having to face that particular
risks consequence.
The fewer consequences suffered as a result of good
RMMM plan, the better the product, and the smoother the
development process. Risk Mitigation

To mitigate this risk, you would develop a strategy for

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

The project manager monitors factors that may

provide an indication of whether the risk is becoming more
or less likely.
In the case of high staff turnover, the general
attitude of team members based on project pressures, the
degree to which the team has jelled, inter-personal
relationships among team members, potential problems
with compensation and benefits, and the availability of
jobs within the company and outside it are all monitored.
In addition to monitoring these factors, a project
manager should monitor the effectiveness of risk
mitigation steps.
The project manager should monitor work products
carefully to ensure that each can stand on its own and that
each imparts information that would be necessary if a
newcomer were forced to join the software team
somewhere in the middle of the project. Risk
Management
Risk management and contingency planning
assumes that mitigation efforts have failed and that the
risk has become a reality.
If the mitigation strategy has been followed, backup
is available, information is documented, and knowledge
has been dispersed across the team.
In addition, you can temporarily refocus resources
(and readjust the project schedule) to those functions that
are fully staffed, enabling newcomers who must be added
to the team to get up to speed. Those individuals who
are leaving are asked to stop all work and spend their last
weeks in knowledge transfer mode.