SlideShare a Scribd company logo
1 of 70
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
Compute Function Points
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
Compute Function Points Example-2
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
Compute Function Points Example-3
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 Function Points Example-4
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
Problem-Based Estimation
(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
Problem-Based Estimation
(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
Process-Based Estimation
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
Process-Based Estimation
(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)
Empirical Estimation
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.
Basic CoCoMo Model
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
Scheduling Principles - 2
• 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
Scheduling Principles - 3
• 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
Task network
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
Risk Management
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
Risk Categorization – Approach #1
• 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
Risk Categorization – Approach #2
• 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
Risk Identification
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
Risk Projection (Estimation)
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

More Related Content

What's hot

Software Engineering (Project Planning & Estimation)
Software Engineering (Project Planning &  Estimation)Software Engineering (Project Planning &  Estimation)
Software Engineering (Project Planning & Estimation)ShudipPal
 
SRS(software requirement specification)
SRS(software requirement specification)SRS(software requirement specification)
SRS(software requirement specification)Akash Kumar Dhameja
 
Chapter 01 software engineering pressman
Chapter 01  software engineering pressmanChapter 01  software engineering pressman
Chapter 01 software engineering pressmanRohitGoyal183
 
extreme Programming
extreme Programmingextreme Programming
extreme ProgrammingBilal Shah
 
Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Fadhil Ismail
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGSaqib Raza
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riportDilip Prajapati
 
Flow oriented modeling
Flow oriented modelingFlow oriented modeling
Flow oriented modelingramyaaswin
 
Software development life cycle (SDLC)
Software development life cycle (SDLC)Software development life cycle (SDLC)
Software development life cycle (SDLC)Simran Kaur
 
Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville,  Software Engineering, 9th Edition Ch1Ian Sommerville,  Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1Mohammed Romi
 
Requirement specification (SRS)
Requirement specification (SRS)Requirement specification (SRS)
Requirement specification (SRS)kunj desai
 
Software requirement and specification
Software requirement and specificationSoftware requirement and specification
Software requirement and specificationAman Adhikari
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process ModelsAtul Karmyal
 
Requirements engineering activities
Requirements engineering activitiesRequirements engineering activities
Requirements engineering activitiesSyed Zaid Irshad
 

What's hot (20)

Software Engineering (Project Planning & Estimation)
Software Engineering (Project Planning &  Estimation)Software Engineering (Project Planning &  Estimation)
Software Engineering (Project Planning & Estimation)
 
SRS(software requirement specification)
SRS(software requirement specification)SRS(software requirement specification)
SRS(software requirement specification)
 
Chapter 01 software engineering pressman
Chapter 01  software engineering pressmanChapter 01  software engineering pressman
Chapter 01 software engineering pressman
 
extreme Programming
extreme Programmingextreme Programming
extreme Programming
 
Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Software System Engineering - Chapter 1
Software System Engineering - Chapter 1
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riport
 
Flow oriented modeling
Flow oriented modelingFlow oriented modeling
Flow oriented modeling
 
Software development life cycle (SDLC)
Software development life cycle (SDLC)Software development life cycle (SDLC)
Software development life cycle (SDLC)
 
Staffing level estimation
Staffing level estimation Staffing level estimation
Staffing level estimation
 
Coda file system
Coda file systemCoda file system
Coda file system
 
Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville,  Software Engineering, 9th Edition Ch1Ian Sommerville,  Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1
 
Requirement specification (SRS)
Requirement specification (SRS)Requirement specification (SRS)
Requirement specification (SRS)
 
Software requirement and specification
Software requirement and specificationSoftware requirement and specification
Software requirement and specification
 
Software requirements
Software requirementsSoftware requirements
Software requirements
 
Rad model
Rad modelRad model
Rad model
 
Software design
Software designSoftware design
Software design
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
 
Activity diagram
Activity diagramActivity diagram
Activity diagram
 
Requirements engineering activities
Requirements engineering activitiesRequirements engineering activities
Requirements engineering activities
 

Viewers also liked

IoT Consumer Research Report
IoT Consumer Research ReportIoT Consumer Research Report
IoT Consumer Research ReportGreg Kahn
 
Project Management and Process
Project Management and ProcessProject Management and Process
Project Management and ProcessMuhammad Rehman
 
Different types of wbs structures
Different types of wbs structuresDifferent types of wbs structures
Different types of wbs structuressanddrap
 
5 Basic Phases of Project Management
5 Basic Phases of Project Management 5 Basic Phases of Project Management
5 Basic Phases of Project Management Project Insight
 
Function point analysis introduction
Function point analysis introductionFunction point analysis introduction
Function point analysis introductionTechcanvass
 
Work breakdown Structure
Work breakdown StructureWork breakdown Structure
Work breakdown StructureNicola2903
 
Cost estimation using cocomo model
Cost estimation using cocomo modelCost estimation using cocomo model
Cost estimation using cocomo modelNitesh Bichwani
 
Work breakdown structure
Work breakdown structureWork breakdown structure
Work breakdown structureCOEPD HR
 
Role of Project Manager ... in nutshell
Role of Project Manager ... in nutshellRole of Project Manager ... in nutshell
Role of Project Manager ... in nutshellSamir Paralikar
 
Chapter 4 software project planning
Chapter 4 software project planningChapter 4 software project planning
Chapter 4 software project planningdespicable me
 
Line of Code (LOC) Matric and Function Point Matric
Line of Code (LOC) Matric and Function Point MatricLine of Code (LOC) Matric and Function Point Matric
Line of Code (LOC) Matric and Function Point MatricAnkush Singh
 
Functional point analysis
Functional point analysisFunctional point analysis
Functional point analysisDestinationQA
 

Viewers also liked (20)

Software Metrics
Software MetricsSoftware Metrics
Software Metrics
 
IoT Consumer Research Report
IoT Consumer Research ReportIoT Consumer Research Report
IoT Consumer Research Report
 
Function Points
Function PointsFunction Points
Function Points
 
Project Management and Process
Project Management and ProcessProject Management and Process
Project Management and Process
 
Different types of wbs structures
Different types of wbs structuresDifferent types of wbs structures
Different types of wbs structures
 
Software project management 3
Software project management 3Software project management 3
Software project management 3
 
Software project management
Software project managementSoftware project management
Software project management
 
5 Basic Phases of Project Management
5 Basic Phases of Project Management 5 Basic Phases of Project Management
5 Basic Phases of Project Management
 
Function Points
Function PointsFunction Points
Function Points
 
Function point analysis introduction
Function point analysis introductionFunction point analysis introduction
Function point analysis introduction
 
Cocomo
CocomoCocomo
Cocomo
 
Work breakdown Structure
Work breakdown StructureWork breakdown Structure
Work breakdown Structure
 
Phases of a Project
Phases of a ProjectPhases of a Project
Phases of a Project
 
Cost estimation using cocomo model
Cost estimation using cocomo modelCost estimation using cocomo model
Cost estimation using cocomo model
 
Work breakdown structure
Work breakdown structureWork breakdown structure
Work breakdown structure
 
Role of Project Manager ... in nutshell
Role of Project Manager ... in nutshellRole of Project Manager ... in nutshell
Role of Project Manager ... in nutshell
 
Cocomo
CocomoCocomo
Cocomo
 
Chapter 4 software project planning
Chapter 4 software project planningChapter 4 software project planning
Chapter 4 software project planning
 
Line of Code (LOC) Matric and Function Point Matric
Line of Code (LOC) Matric and Function Point MatricLine of Code (LOC) Matric and Function Point Matric
Line of Code (LOC) Matric and Function Point Matric
 
Functional point analysis
Functional point analysisFunctional point analysis
Functional point analysis
 

Similar to Managing software project, software engineering

Project Matrix and Measuring S/W
Project Matrix and Measuring S/WProject Matrix and Measuring S/W
Project Matrix and Measuring S/WAkash Maheshwari
 
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation modelsSe 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation modelsbabak danyal
 
Software Metrics - Software Engineering
Software Metrics - Software EngineeringSoftware Metrics - Software Engineering
Software Metrics - Software EngineeringDrishti Bhalla
 
OOSE Unit 2 PPT.ppt
OOSE Unit 2 PPT.pptOOSE Unit 2 PPT.ppt
OOSE Unit 2 PPT.pptitadmin33
 
Pressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsPressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsSeema Kamble
 
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERICCOCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERICSneha Padhiar
 
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERICCOCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERICSneha Padhiar
 
SOFTWARE ESTIMATION COCOMO AND FP CALCULATION
SOFTWARE ESTIMATION COCOMO AND FP CALCULATIONSOFTWARE ESTIMATION COCOMO AND FP CALCULATION
SOFTWARE ESTIMATION COCOMO AND FP CALCULATIONSneha Padhiar
 
Software process and project metrics
Software process and project metricsSoftware process and project metrics
Software process and project metricsIndu Sharma Bhardwaj
 
Unit2 - Metrics.pptx
Unit2 - Metrics.pptxUnit2 - Metrics.pptx
Unit2 - Metrics.pptxrituah
 
project planning components.pdf
project planning components.pdfproject planning components.pdf
project planning components.pdfsaman Iftikhar
 
Cost estimation techniques
Cost estimation techniquesCost estimation techniques
Cost estimation techniqueslokareminakshi
 
5_6134023428304274682.pptx
5_6134023428304274682.pptx5_6134023428304274682.pptx
5_6134023428304274682.pptxgamingpro22
 
Software Measurement and Metrics.pptx
Software Measurement and Metrics.pptxSoftware Measurement and Metrics.pptx
Software Measurement and Metrics.pptxubaidullah75790
 
chapter FP Analysis .pptx
chapter FP Analysis .pptxchapter FP Analysis .pptx
chapter FP Analysis .pptxtowexib993
 

Similar to Managing software project, software engineering (20)

Software metrics
Software metricsSoftware metrics
Software metrics
 
Project Matrix and Measuring S/W
Project Matrix and Measuring S/WProject Matrix and Measuring S/W
Project Matrix and Measuring S/W
 
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation modelsSe 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models
 
Software Metrics - Software Engineering
Software Metrics - Software EngineeringSoftware Metrics - Software Engineering
Software Metrics - Software Engineering
 
OOSE Unit 2 PPT.ppt
OOSE Unit 2 PPT.pptOOSE Unit 2 PPT.ppt
OOSE Unit 2 PPT.ppt
 
Pressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsPressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metrics
 
Software engineering
Software engineeringSoftware engineering
Software engineering
 
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERICCOCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
 
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERICCOCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
COCOMO FP COST ESTIMATION TECHNIQUES:NUMERIC
 
SOFTWARE ESTIMATION COCOMO AND FP CALCULATION
SOFTWARE ESTIMATION COCOMO AND FP CALCULATIONSOFTWARE ESTIMATION COCOMO AND FP CALCULATION
SOFTWARE ESTIMATION COCOMO AND FP CALCULATION
 
Software process and project metrics
Software process and project metricsSoftware process and project metrics
Software process and project metrics
 
Unit2 - Metrics.pptx
Unit2 - Metrics.pptxUnit2 - Metrics.pptx
Unit2 - Metrics.pptx
 
project planning components.pdf
project planning components.pdfproject planning components.pdf
project planning components.pdf
 
Cost estimation techniques
Cost estimation techniquesCost estimation techniques
Cost estimation techniques
 
5_6134023428304274682.pptx
5_6134023428304274682.pptx5_6134023428304274682.pptx
5_6134023428304274682.pptx
 
Software metrics
Software metricsSoftware metrics
Software metrics
 
Software Measurement and Metrics.pptx
Software Measurement and Metrics.pptxSoftware Measurement and Metrics.pptx
Software Measurement and Metrics.pptx
 
chapter FP Analysis .pptx
chapter FP Analysis .pptxchapter FP Analysis .pptx
chapter FP Analysis .pptx
 
Bai giang-spm-13feb14
Bai giang-spm-13feb14Bai giang-spm-13feb14
Bai giang-spm-13feb14
 
Algorithmic Software Cost Modeling
Algorithmic Software Cost ModelingAlgorithmic Software Cost Modeling
Algorithmic Software Cost Modeling
 

More from Rupesh Vaishnav

Software maintenance and configuration management, software engineering
Software maintenance and  configuration management, software engineeringSoftware maintenance and  configuration management, software engineering
Software maintenance and configuration management, software engineeringRupesh Vaishnav
 
Software design, software engineering
Software design, software engineeringSoftware design, software engineering
Software design, software engineeringRupesh Vaishnav
 
Software coding & testing, software engineering
Software coding & testing, software engineeringSoftware coding & testing, software engineering
Software coding & testing, software engineeringRupesh Vaishnav
 
Software as a service, software engineering
Software as a service, software engineeringSoftware as a service, software engineering
Software as a service, software engineeringRupesh Vaishnav
 
Requirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRequirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRupesh Vaishnav
 
Quality assurance and management, software engineering
Quality assurance and management, software engineeringQuality assurance and management, software engineering
Quality assurance and management, software engineeringRupesh Vaishnav
 
Intoduction to software engineering part 2
Intoduction to software engineering part 2Intoduction to software engineering part 2
Intoduction to software engineering part 2Rupesh Vaishnav
 
Intoduction to software engineering part 1
Intoduction to software engineering part 1Intoduction to software engineering part 1
Intoduction to software engineering part 1Rupesh Vaishnav
 
Advanced topics in software engineering
Advanced topics in software engineeringAdvanced topics in software engineering
Advanced topics in software engineeringRupesh Vaishnav
 

More from Rupesh Vaishnav (9)

Software maintenance and configuration management, software engineering
Software maintenance and  configuration management, software engineeringSoftware maintenance and  configuration management, software engineering
Software maintenance and configuration management, software engineering
 
Software design, software engineering
Software design, software engineeringSoftware design, software engineering
Software design, software engineering
 
Software coding & testing, software engineering
Software coding & testing, software engineeringSoftware coding & testing, software engineering
Software coding & testing, software engineering
 
Software as a service, software engineering
Software as a service, software engineeringSoftware as a service, software engineering
Software as a service, software engineering
 
Requirement analysis and specification, software engineering
Requirement analysis and specification, software engineeringRequirement analysis and specification, software engineering
Requirement analysis and specification, software engineering
 
Quality assurance and management, software engineering
Quality assurance and management, software engineeringQuality assurance and management, software engineering
Quality assurance and management, software engineering
 
Intoduction to software engineering part 2
Intoduction to software engineering part 2Intoduction to software engineering part 2
Intoduction to software engineering part 2
 
Intoduction to software engineering part 1
Intoduction to software engineering part 1Intoduction to software engineering part 1
Intoduction to software engineering part 1
 
Advanced topics in software engineering
Advanced topics in software engineeringAdvanced topics in software engineering
Advanced topics in software engineering
 

Recently uploaded

Mine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxMine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxRomil Mishra
 
Crushers to screens in aggregate production
Crushers to screens in aggregate productionCrushers to screens in aggregate production
Crushers to screens in aggregate productionChinnuNinan
 
Risk Management in Engineering Construction Project
Risk Management in Engineering Construction ProjectRisk Management in Engineering Construction Project
Risk Management in Engineering Construction ProjectErbil Polytechnic University
 
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...Sumanth A
 
Novel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsNovel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsResearcher Researcher
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfManish Kumar
 
CS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfCS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfBalamuruganV28
 
Python Programming for basic beginners.pptx
Python Programming for basic beginners.pptxPython Programming for basic beginners.pptx
Python Programming for basic beginners.pptxmohitesoham12
 
Immutable Image-Based Operating Systems - EW2024.pdf
Immutable Image-Based Operating Systems - EW2024.pdfImmutable Image-Based Operating Systems - EW2024.pdf
Immutable Image-Based Operating Systems - EW2024.pdfDrew Moseley
 
Artificial Intelligence in Power System overview
Artificial Intelligence in Power System overviewArtificial Intelligence in Power System overview
Artificial Intelligence in Power System overviewsandhya757531
 
List of Accredited Concrete Batching Plant.pdf
List of Accredited Concrete Batching Plant.pdfList of Accredited Concrete Batching Plant.pdf
List of Accredited Concrete Batching Plant.pdfisabel213075
 
"Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ..."Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ...Erbil Polytechnic University
 
Research Methodology for Engineering pdf
Research Methodology for Engineering pdfResearch Methodology for Engineering pdf
Research Methodology for Engineering pdfCaalaaAbdulkerim
 
Correctly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleCorrectly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleAlluxio, Inc.
 
Internship PPT ukai thermal power station .pptx
Internship PPT ukai thermal power station .pptxInternship PPT ukai thermal power station .pptx
Internship PPT ukai thermal power station .pptxmalikavita731
 
11. Properties of Liquid Fuels in Energy Engineering.pdf
11. Properties of Liquid Fuels in Energy Engineering.pdf11. Properties of Liquid Fuels in Energy Engineering.pdf
11. Properties of Liquid Fuels in Energy Engineering.pdfHafizMudaserAhmad
 
Class 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm SystemClass 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm Systemirfanmechengr
 
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTIONTHE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTIONjhunlian
 
OOP concepts -in-Python programming language
OOP concepts -in-Python programming languageOOP concepts -in-Python programming language
OOP concepts -in-Python programming languageSmritiSharma901052
 
Work Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvWork Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvLewisJB
 

Recently uploaded (20)

Mine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptxMine Environment II Lab_MI10448MI__________.pptx
Mine Environment II Lab_MI10448MI__________.pptx
 
Crushers to screens in aggregate production
Crushers to screens in aggregate productionCrushers to screens in aggregate production
Crushers to screens in aggregate production
 
Risk Management in Engineering Construction Project
Risk Management in Engineering Construction ProjectRisk Management in Engineering Construction Project
Risk Management in Engineering Construction Project
 
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
 
Novel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsNovel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending Actuators
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
 
CS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfCS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdf
 
Python Programming for basic beginners.pptx
Python Programming for basic beginners.pptxPython Programming for basic beginners.pptx
Python Programming for basic beginners.pptx
 
Immutable Image-Based Operating Systems - EW2024.pdf
Immutable Image-Based Operating Systems - EW2024.pdfImmutable Image-Based Operating Systems - EW2024.pdf
Immutable Image-Based Operating Systems - EW2024.pdf
 
Artificial Intelligence in Power System overview
Artificial Intelligence in Power System overviewArtificial Intelligence in Power System overview
Artificial Intelligence in Power System overview
 
List of Accredited Concrete Batching Plant.pdf
List of Accredited Concrete Batching Plant.pdfList of Accredited Concrete Batching Plant.pdf
List of Accredited Concrete Batching Plant.pdf
 
"Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ..."Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ...
 
Research Methodology for Engineering pdf
Research Methodology for Engineering pdfResearch Methodology for Engineering pdf
Research Methodology for Engineering pdf
 
Correctly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleCorrectly Loading Incremental Data at Scale
Correctly Loading Incremental Data at Scale
 
Internship PPT ukai thermal power station .pptx
Internship PPT ukai thermal power station .pptxInternship PPT ukai thermal power station .pptx
Internship PPT ukai thermal power station .pptx
 
11. Properties of Liquid Fuels in Energy Engineering.pdf
11. Properties of Liquid Fuels in Energy Engineering.pdf11. Properties of Liquid Fuels in Energy Engineering.pdf
11. Properties of Liquid Fuels in Energy Engineering.pdf
 
Class 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm SystemClass 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm System
 
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTIONTHE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
 
OOP concepts -in-Python programming language
OOP concepts -in-Python programming languageOOP concepts -in-Python programming language
OOP concepts -in-Python programming language
 
Work Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvvWork Experience-Dalton Park.pptxfvvvvvvv
Work Experience-Dalton Park.pptxfvvvvvvv
 

Managing software project, software engineering

  • 2. 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
  • 3. Why Measure Software? • Determine quality of the current product or process • Predict qualities of a product/process • Improve quality of a product/process
  • 4. Example Metrics • Defects rates • Errors rates • Measured by: – individual – module – during development • Errors should be categorized by origin, type, cost
  • 5. 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
  • 6. 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
  • 7. 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 +=
  • 8. 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
  • 9. 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
  • 10. Types of Measures • Direct Measures (internal attributes) – Cost, effort, LOC, speed, memory • Indirect Measures (external attributes) – Functionality, quality, complexity, efficiency, reliability, maintainability
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. Compute Function Points Example-2 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
  • 22. Compute Function Points Example-3 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.
  • 23. Compute Function Points Example-4 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
  • 24. 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."
  • 25. Software Project Estimation • Software Sizing • Problem based Estimation – LOC based – FP based • Process based Estimation • Estimation with Use-cases
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. Problem-Based Estimation (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
  • 30. Problem-Based Estimation (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
  • 31. 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
  • 32. Process-Based Estimation 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
  • 33. Process-Based Estimation (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)
  • 35. Techniques a) Source lines of Code (SLOC) b) Function Point (FP) c) Constructive Cost Model (COCOMO)
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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.
  • 41.
  • 42.
  • 43. 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.
  • 44. 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
  • 45. Scheduling Principles - 2 • 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
  • 46. Scheduling Principles - 3 • 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
  • 47. 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. 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
  • 49. 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
  • 50. 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)
  • 51. 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
  • 53. 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.
  • 54. 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
  • 56. 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
  • 57. 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
  • 58. Risk Categorization – Approach #1 • 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
  • 59. Risk Categorization – Approach #2 • 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
  • 60. 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
  • 61. 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
  • 63. 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?"
  • 64. 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
  • 66. 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
  • 67. 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
  • 69. 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
  • 70. 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

Editor's Notes

  1. Total count=233 Fp=226.01
  2. Total count=233 Fp=226.01
  3. Total count=233 Fp=226.01
  4. Total count=233 Fp=226.01
  5. Total count=233 Fp=226.01
  6. Total count=233 Fp=226.01
  7. Total count=233 Fp=226.01
  8. Total count=233 Fp=226.01
  9. Total count=233 Fp=226.01