Managing software project, software engineering

Unit-3
Managing Software
Project

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

Why Measure Software?
• Determine quality of the current product or
process
• Predict qualities of a product/process
• Improve quality of a product/process

Example Metrics
• Defects rates
• Errors rates
• Measured by:
– individual
– module
– during development
• Errors should be categorized by origin, type, cost

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

Product vs. Process
• Process Metrics-
– Insights of process paradigm, software engineering tasks, work
product, or milestones.
– Lead to long term process improvement.
• Product Metrics-
– Assesses the state of the project
– Track potential risks
– Uncover problem areas
– Adjust workflow or tasks
– Evaluate teams ability to control quality

Process Metrics
• Focus on quality achieved as a consequence of a repeatable
or managed process. Strategic and Long Term.
• Statistical Software Process Improvement (SSPI). Error
Categorization and Analysis:
All errors and defects are categorized by origin
The cost to correct each error and defect is recorded
The number of errors and defects in each category is computed
Data is analyzed to find categories that result in the highest cost to the
organization
Plans are developed to modify the process
• Defect Removal Efficiency (DRE). Relationship between
errors (E) and defects (D). The ideal is a DRE of 1:
)/( DEEDRE +=

Project Metrics
• Used by a project manager and software team to adapt
project work flow and technical activities. Tactical and Short
Term.
• Purpose:
− Minimize the development schedule by making the
necessary adjustments to avoid delays and mitigate
problems
− Assess product quality on an ongoing basis
• Metrics:
− Effort or time per SE task
− Errors uncovered per review hour
− Scheduled vs. actual milestone dates
− Number of changes and their characteristics
− Distribution of effort on SE tasks

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

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

Size Oriented Metrics
• Size of the software produced
• Lines Of Code (LOC)
• 1000 Lines Of Code KLOC
• Effort measured in person months
• Errors/KLOC
• Defects/KLOC
• Cost/LOC
• Documentation Pages/KLOC
• LOC is programmer & language dependent

LOC Metrics
• Easy to use
• Easy to compute
• Can compute LOC of existing systems but
•cost and requirements traceability may be lost
• Language & programmer dependent

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

Function Point Metrics
• 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

Compute Function Points
• FP = Total Count * [0.65 + 0.01*∑(Fi)]
• 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

Function Point Analysis
A simple example:
inputs
3 simple X 3 = 6
4 average X 4 = 16
1 complex X 6 = 6
outputs
6 average X 5 = 30
2 complex X 7 = 14
files
5 complex X 15 = 75
inquiries
8 average X 4 = 32
interfaces
3 average X 7 = 21
4 complex X 10 = 40
Unadjusted function points 240

Value Adjustment Factors
F1. Data Communication
F2. Distributed Data Processing
F3. Performance
F4. Heavily Used Configuration
F5. Transaction Role
F6. Online Data Entry
F7. End-User Efficiency
F8. Online Update
F9. Complex Processing
F10. Reusability
F11. Installation Ease
F12. Operational Ease
F13. Multiple Sites
F14. Facilitate Change

Function Point Analysis
Continuing our example . . .
Complex internal processing = 3
Code to be reusable = 2
High performance = 4
Multiple sites = 3
Distributed processing = 5
Project adjustment factor = 17
Adjustment calculation:
Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)]
= 240 X [0.65 + ( 17 X 0.01)]
= 240 X [0.82]
= 197 Adjusted function points

Compute Function Points Example-1
Study of requirement specification for a project has produced
following results:
Need for 7 inputs, 10 outputs, 6 inquiries, 17 files and 4 external
interfaces.
Input and external interface function point attributes are of average
complexity and all other function points attributes are of low
complexity
Determine adjusted function points assuming complexity adjustment
value is 32.
•Total count = 233
•Fp = 226.01

GTU- May, Dec 2013
Compute the function points for the given data set
Inputs = 8
Outputs = 12
Inquiries= 4
Logical files = 41
Interfaces = 1
Value adjustment factor ∑Fi= 41
•Total count = 525
•Fp = 556.5

A system has 12 external inputs, 24 external outputs, fields
30 different external queries, manages 4 internal logical
files, and interfaces with 6 different legacy systems (6 EIFs).
All of these data are of average complexity and assume
that all complexity adjustment values are average.
Compute FP for the system.

Compute the function points for the given data set
Inputs = 32
Outputs = 60
Inquiries= 24
Logical files = 8
Interfaces = 2
Assume that all complexity adjustment values are average

Software Project Estimation
Decomposing
• 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, decomposing the problem, re-
characterizing it as a set of smaller problems.
• Before an estimate can be made, the project planner
must understand the scope of the software to be built
and generate an estimate of its "size."

Software Project Estimation
• Software Sizing
• Problem based Estimation
– LOC based
– FP based
• Process based Estimation
• Estimation with Use-cases

Introduction
• Before an estimate can be made and decomposition
techniques applied, the planner must
– Understand the scope of the software to be built
– Generate an estimate of the software’s size
• Then one of two approaches are used
– Problem-based estimation
• Based on either source lines of code or function point estimates
– Process-based estimation
• Based on the effort required to accomplish each task

Approaches to Software
Sizing
• Function point sizing
– Develop estimates of the information domain characteristics (Ch. 15 –
Product Metrics for Software)
• Standard component sizing
– Estimate the number of occurrences of each standard component
– Use historical project data to determine the delivered LOC size per
standard component
• Change sizing
– Used when changes are being made to existing software
– Estimate the number and type of modifications that must be
accomplished
– Types of modifications include reuse, adding code, changing code,
and deleting code
– An effort ratio is then used to estimate each type of change and the
size of the change

Problem-Based Estimation
1) Start with a bounded statement of scope
2) Decompose the software into problem functions that can each
be estimated individually
3) Compute an LOC or FP value for each function
4) 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)
5) Combine function estimates to produce an overall estimate for
the entire project

(continued)
• In general, the LOC/pm and FP/pm metrics should be computed by
project domain
– Important factors are team size, application area, and complexity
• LOC and FP estimation differ in the level of detail required for
decomposition with each value
– For LOC, decomposition of functions is essential and should go into
considerable detail (the more detail, the more accurate the estimate)
– For FP, decomposition occurs for the five information domain
characteristics and the 14 adjustment factors
• External inputs, external outputs, external inquiries, internal logical files,
external interface files
pm = person month

(continued)
• For both approaches, the planner uses lessons learned to
estimate an optimistic, most likely, and pessimistic size value
for each function or count (for each information domain
value)
• Then the expected size value S is computed as follows:
S = (Sopt + 4Sm + Spess)/6
• Historical LOC or FP data is then compared to S in order to
cross-check it

Process-Based Estimation
Obtained from “process framework”Obtained from “process framework”
application
functions
framework activitiesframework activities
Effort required to
accomplish
each framework
activity for each
application
function

1) Identify the set of functions that the software needs to
perform as obtained from the project scope
2) Identify the series of framework activities that need to be
performed for each function
3) Estimate the effort (in person months) that will be required
to accomplish each software process activity for each
function

(continued)
4) Apply average labor rates (i.e., cost/unit effort) to the effort
estimated for each process activity
5) Compute the total cost and effort for each function and
each framework activity
6) Compare the resulting values to those obtained by way of
the LOC and FP estimates
• If both sets of estimates agree, then your numbers are
highly reliable
• Otherwise, conduct further investigation and analysis
concerning the function and activity breakdown
This is the most commonly used of the two estimation techniques (problem and process)

Techniques
a) Source lines of Code (SLOC)
b) Function Point (FP)
c) Constructive Cost Model (COCOMO)

SOLC
• The project size helps determine the resources, effort,
and duration of the project.
• SOLC is defined as the source lines of code that are
delivered as part of the product.
• The effort spent on creating the source lines of code is
expressed in relation to thousand lines of code (KLOC).
• This technique includes the calculation of lines of code,
documentation of pages, inputs, outputs, and
components of a software program.
• The SLOC technique is language-dependent. The effort
required to calculate

COCOMO
• Stands for COnstructive COst MOdel
• Introduced by Barry Boehm in 1981
• Became one of the well-known and widely-used estimation
models in the industry
• It has evolved into a more comprehensive estimation model
called COCOMO II
• COCOMO II is actually a hierarchy of three estimation models
• As with all estimation models, it requires sizing information
and accepts it in three forms: object points, function points,
and lines of source code

COCOMO Models
• 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.

Project Scheduling & Tracking
• Software project scheduling is an action that
distributes estimated effort across the
planned project duration by allocating the
effort to specific software engineering tasks.

Scheduling Principles - 1
• Compartmentalization
– the product and process must be decomposed into a manageable
number of activities and tasks
• Interdependency
– tasks that can be completed in parallel must be separated from
those that must completed serially
• Time allocation
– every task has start and completion dates that take the task
interdependencies into account

• Effort validation
– project manager must ensure that on any given
day there are enough staff members assigned to
completed the tasks within the time estimated in
the project plan
• Defined Responsibilities
– every scheduled task needs to be assigned to a
specific team member

• Defined outcomes
– every task in the schedule needs to have a defined
outcome (usually a work product or deliverable)
• Defined milestones
– a milestone is accomplished when one or more
work products from an engineering task have
passed quality review

Effort Distribution
• general guideline - 40-20-40 rule
• 40% or more of all effort allocated to analysis and
design tasks
• 40% of effort allocated to testing
• 20% of effort allocated to programming
• characteristics of each project dictate the
distribution of effort

48
Project Effort Distribution
Generally accepted guidelines are:
02-03 % planning
10-25 % requirements analysis
20-25 % design
15-20 % coding
30-40 % testing and debugging

Project types:
• concept development projects
– initiated to explore some new business concept or
application of new technology
• new application development
– undertaken due to specific customer request
• application enhancement
• application maintenance
• reengineering
– rebuild existing legacy system

Software Project Types - 1
• Concept development
– initiated to explore new business concept or new application of
technology
• New application development
– new product requested by customer
• Application enhancement
– major modifications to function, performance, or interfaces
(observable to user)

Software Project Types - 2
• Application maintenance
– correcting, adapting, or extending existing
software (not immediately obvious to user)
• Reengineering
– rebuilding all (or part) of a legacy system

Scheduling
Scheduling of a software project does not differ greatly from scheduling of any multitask
engineering effort.
Two project scheduling methods:
- Program Evaluation and Review Technique (PERT)
- Critical Path Method (CPM)
Both methods are driven by information developed in earlier project planning activities:
- Estimates of effort
- A decomposition of product function
- The selection of the appropriate process model
- The selection of project type and task set
Both methods allow a planer to do:
- determine the critical path
- time estimation
- calculate boundary times for each task
Boundary times:
- the earliest time and latest time to begin a task
- the earliest time and latest time to complete a task
- the total float.

Tracking the Schedule
he project schedule provides a road map for a software project manager.
defines the tasks and milestones.
everal 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
roject manager takes the control of the schedule in the aspects of:
- project staffing
- project problems
- project resources
- reviews
- project budget

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

Risk Categorization – Approach #1
• Project risks
– They threaten the project plan
– If they become real, it is likely that the project schedule will
slip and that costs will increase
• Technical risks
– They threaten the quality and timeliness of the software to
be produced
– If they become real, implementation may become difficult
or impossible
• Business risks
– They threaten the feasibility of the software to be built
– If they become real, they threaten the project or the
product

• Sub-categories of Business risks
– 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

• 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

Reactive vs. Proactive Risk Strategies
• Reactive risk strategies
– "Don't worry, I'll think of something"
– The majority of software teams and managers rely on this
approach
– Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the problem
rapidly (fire fighting)
– Crisis management is the choice of management techniques
• Proactive risk strategies
– Steps for risk management are followed
– Primary objective is to avoid risk and to have a emergency
plan in place to handle unavoidable risks in a controlled and
effective manner

Steps for Risk Management
1) Identify possible risks; recognize what can go wrong
2) Analyze each risk to estimate the probability that it will
occur and the impact (i.e., damage) that it will do if it does
occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and
catastrophic
4) Develop a contingency plan to manage those risks having
high probability and high impact

Background
• Risk identification is a systematic attempt to specify threats to the project
plan
• By identifying known and predictable risks, the project manager takes a first
step toward avoiding them when possible and controlling them when
necessary
• Generic risks
– Risks that are a potential threat to every software project
• Product-specific risks
– Risks that can be identified only by those a with a clear understanding of
the technology, the people, and the environment that is specific to the
software that is to be built
– This requires examination of the project plan and the statement of scope
– "What special characteristics of this product may threaten our project
plan?"

Known and Predictable Risk Categories
• Product size – risks associated with overall size of the software to be
built
• Business impact – risks associated with constraints imposed by
management or the marketplace
• Customer characteristics – risks associated with sophistication of the
customer and the developer's ability to communicate with the customer
in a timely manner
• Process definition – risks associated with the degree to which the
software process has been defined and is followed
• Development environment – risks associated with availability and
quality of the tools to be used to build the project
• Technology to be built – risks associated with complexity of the system
to be built and the "newness" of the technology in the system
• Staff size and experience – risks associated with overall technical and
project experience of the software engineers who will do the work

Background
• Risk projection (or estimation) attempts to rate each risk in
two ways
– The probability that the risk is real
– The consequence of the problems associated with the risk,
should it occur

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

Risk Mitigation, Monitoring,
and Management

Background
• An effective strategy for dealing with risk must consider
three issues
(Note: these are not mutually exclusive)
– Risk mitigation (i.e., avoidance)
– Risk monitoring
– Risk management and contingency planning
• Risk mitigation (avoidance) is the primary strategy and is
achieved through a plan
– Example: Risk of high staff turnover

Seven Principles of Risk
Management• Maintain a global perspective
– View software risks within the context of a system and the business
problem that is is intended to solve
• Take a forward-looking view
– Think about risks that may arise in the future; establish contingency
plans
• Encourage open communication
– Encourage all stakeholders and users to point out risks at any time
• Integrate risk management
– Integrate the consideration of risk into the software process
• Emphasize a continuous process of risk management
– Modify identified risks as more becomes known and add new risks as
better insight is achieved
• Develop a shared product vision
– A shared vision by all stakeholders facilitates better risk identification
and assessment
• Encourage teamwork when managing risk
– Pool the skills and experience of all stakeholders when conducting risk
management activities

Managing software project, software engineering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Managing software project, software engineering

Similar to Managing software project, software engineering (20)

More from Rupesh Vaishnav

More from Rupesh Vaishnav (10)

Recently uploaded

Recently uploaded (20)

Managing software project, software engineering

Editor's Notes