estimation techniques and software metrics
DESCRIPTION
Software Eng Subject / Tiu & MarkTRANSCRIPT
SOFTWARE PROJECT MANAGEMENT
How Bad are Our Projects?
Only 34 percent of all projects succeed. The average project has a 43 percent
cost overrun.
Why Projects FAIL
Overlooked one or more of the crucial elements of project management. Risk engineering and management Human resource management Effort and cost estimation Project monitoring Tracking and control Time and financial management Proper use of project management tools
What is Project Management? Did you say:
People skills Software
What is Software Project Management?
Encompasses a set of activities that are performed during the phases of a typical software development project.
Software Project Manager
Manage Software Projects
Software Project Manager
Continuously ensure that the software product is developed according to: The client’s business
requirements Within allocated time Within allocated budget
Elements of Software Project Management
The project itself The people working on the project The process used to produce the project
deliverables The final product delivered to the client
Common Mistakes why Projects FAIL
Project managers begin without knowing what the project is.
Project managers do not have a plan. Project managers do not break the
project down to manageable pieces.
Project Plan
Is an important deliverable that must be developed carefully.
Once written, the plan must be executed by the project manager.
People involved should be well-versed Progress must be closely monitored by
the manager
People
Engaging the proper people to perform the prescribed tasks according to the project plan is important.
Training people on the proper use of tools and techniques is essential.
Communication and reporting must be well-defined to ensure frictionless environment.
Transparent and continuous monitoring of people involved is critical for the early detection of problem symptoms.
Process and Phases
Must be understood and defined because they determine deliverable and the efforts involved in their execution.
An appropriate software life cycle model must be adapted for the project
The development team needs to be knowledgeable regarding that model.
Project Management Activities Project management activitiesDuring project start-up
Estimation Staffing Resource acquisition Training
Developing the work plan: activities, schedule, resources, and budget allocation
During project execution
Quality assurance control Reporting and tracking Metrics collection Risk monitoring and mitigation Configuration management Process Improvement
Budget control Schedule control Requirements control Verification and validation Documentation Problem resolution Subcontractor management
During project closeout
Product acceptance Staff reassignment User training Product installation
Archiving Post-mortem evaluation and
assessment Integration and conversion
ESTIMATION TECHNIQUES AND SOFTWARE METRICS
Good day.. (^_^)
Estimation
One of the most critical activity during project startup
Estimate the effort needed to complete the project
Affects many resource aspects (financial and human)
Must be realistic and accurate
Common Problems
Underestimation Project milestones cannot be met What to do? Leads to low employee morale, decline in
reputation, and a stressful work environment
Overestimation Lead to losing the bid
ESTIMATION TECHNIQUE #1:
Informal approaches One or more expert opinions Experiences from peers Opinions of hired consultants
ESTIMATION TECHNIQUE #2:
Decomposition Process Break down the project into functional
components Ask potential developers of these
components to provide their own estimates based on prior experiences
MACRO-LEVEL ESTIMATION
Consider the software product as a whole
MICRO-LEVEL ESTIMATION
Decompose the product into smallest possible components
Estimate for those components Requires more time to produce, but
accurate estimates are produced
CATEGORIES
Black box-based / Requirements-based ET Estimations are obtained once the software
project scope is clearly defined in terms of the required functionalities
Function points and use case points estimation techniques
Based on projected size of the final SW product in terms of lines of code (LOC) COCOMO technique
How to solve a problem?
When we have a problem that consists of two particular aspects, we should consider taking care about each aspect separately. Once the first of problems is solved, we can turn to another. After that, everything left is to check whether the particular solutions work well together with greater problem.
Back to measuring application complexity …
The analysis based on function points can be compared to slicing the problem into smaller parts.
Function Points (to simplify)
FP is a standard method for quantifying the software deliverable based upon the user view, where:
User is any person or thing that communicates or interacts with the software at any time
User View is the Functional User Requirements as seen by the user
Functional user requirements describe what the software shall do, in terms of tasks and services.
Five Functional Components
INTERNAL LOGIC FILES (ILF) Files created and maintained within the
application EXTERNAL INTERFACE FILES (EIF)
Files that are owned and are exchanged by other systems
EXTERNAL INPUTS (EI) Inputs that affect the control flow and internal
logic of the application leading to the creation and maintenance of data
EXTERNAL OUTPUTS (EO) Data leaving the application to different devices,
files or external systems EXTERNAL INQUIRIES (EQ)
Simple user queries resulting in responses
How to perform Function Points Analysis?
Basically people solve problems by dividing them into smaller parts.
Instead of trying to evaluate the application as a whole, we need to rate each of the selected groups.
How exactly to do it?
We need to classify the complexity of each category.
Function Points Analysis (FPA) We have three possibilities.
Then, the whole “problem” is to sum the values. A total of them represents the number of
application’s function points.
COMPONENTCOMPLEXITY
SIMPLE AVERAGE COMPLEX
External Input 3 4 6
External Output 4 5 7
User Inquiry 3 4 6
External Interface File 7 10 15
Internal Logic File 5 7 10
Function Point Metrics
SIMPLE AVERAGE COMPLEX
Weight Factor
How many?
Produc
t
Weight Factor
How
many?
Produc
t
Weight Factor
How many?
Produc
t
External Input 3 1 3 4 2 8 6 1 6
External Output 4 3 12 5 0 0 7 1 7
User Inquiry 3 1 3 4 1 4 6 0 0
External Interface File 7 0 0 10 0 0 15 3 45
Internal Logic File 5 0 0 7 0 0 10 1 10
TOTAL 18 12 68
NO. of FPs 18 + 12 + 68 = 98 function points
CASE STUDY
STOCK CONTROL SYSTEM – estimating the time needed to develop this application
Let's imagine a company which sells goods on the phone - if agents call the customers, customers call the agents, and so on - business operates successfully, but there comes a time for putting the whole in order. There occurs a need for developing a system able to control the whole stock, from orders to payments. Our thing is to estimate how complex such system can be and - after that - try to predict how long it would take to develop it.
HELP??.. :’(
At first, we should pay attention to the functionality – what exactly the system should be able to do.
Then, let us group functions into five categories.
Let math do the last thing. (^_^)
Let’s predict every function’s complexity is simple …
Category Multiplier Weight Factor
External Inputs 4 3
External Outputs 4 4
External InQuiries 3 3
Internal Logic Files 4 5
4 * 3 + 4 * 4 + 3 * 3 + 4 * 5 = 57 [Function Points]How long it takes to produce 57 function
points? 57 * 8 = 456 [hours]
The answer? - The estimate for developing the application would take about 456 hours of work.
Technical factors affecting complexity of software projects
Reliable backup and recovery needed Data communications needed Distributed functions required Performance required Heavily used configuration Real-time data entry needed Ease of use
Technical factors affecting complexity of software projects
Real-time update needed Complexity of the interfaces Complexity of the processing Reusability Ease of installation Multiple sites Easy to change
USE CASE POINTS
AND COCOMO
Use Case Points
Use Case Points
introduced by Gustav Kamer in 1993 Extension of the FP method based on
the use cases existing in the use case model of a software system
Categories of actors:
Simple – are other systems that communicate with your software via a pre-defined API. Complex – has more than 10 transactions
Categories of actors:
Average - can either be human beings interacting in a well defined protocol, or they could be systems that interact through a more complex or flexible API.
Categories of actors:
Complex - users who interact with the software through a
graphical user interface are complex actors
- users who interact with the system in unpredictable
ways
Categories of use cases:
Simple – at most 3 transactions Average – has 4 to 7 transactions Complex – has more than 7
transactions
Unadjusted Actor Weight (UAW)
sum of complexity values assigned to each actor
sum of all actor weights
e.g.
Unadjusted Use Case Weight (UUCW)
sum of complexity values assigned to each use case
e.g.
Unadjusted Use Case Point (UUCP)
the unadjusted size of the overall system
UUCP= UAW + UUCWe.g.
UUCP = 560 + 40=600
Adjusted Use Case Points (AUCP)
total effort to develop a system in respect to the different factors impacting Technical Complexity Factor and Environmental Factor
AUCP = (UAW + UCCW * TCF * EF)
Technical Complexity Factor- Sum of all the weighted values
computed for each of the 13 technical factors which are mainly related to the product and its complexity in terms of functional and non-functional requirements.
TCF = 0.6 + (0.01 * TF)
e.g.TCF = 0.6 + (0.01 * 42)
= 1.02
Environmental Factor- related to the people, process and
project aspects of the software
EF = 1.4 - (-0.03 * EF)
e.g.EF = 1.4 + (-0.03 * 17.5) = 1.4 + (-0.03 * 17.5) = 0.89
COCOMO
Constructed Cost Model(COCOMO)
introduced by Barry Boehm in 1981 provides an estimate of the effort in
person-months needed to develop a software product
Based on the estimation of the size of the software in terms of the number of lines of codes
Types of Software
1. Organic Products-are relatively small and simple
2. Semi-detached-are average in size and simplicity
3. Embedded- complex in the sense that they must
meet the constraints of their embedding environment and interfaces, including software and hardware
3 Versions of COCOMO
Basic- provides an estimate of the effort as a
function of an estimate of the program size.-the development effort and the
development duration are calculated on the basis of the estimated DSI.
E = a * Sizeb
D = c * Ed
P = E/D
Intermediate-The same basic equation for the
model is used, but fifteen cost drivers are rated on a scale of 'very low' to 'very high' to calculate the specific effort multiplier and each of them returns an adjustment factor which multiplied yields in the total EAF (Effort Adjustment Factor).
E = a * Size * EAF
Detailed-computes effort as a function of
program size and a set of cost drivers weighted according to each phase of the software lifecycle.
4 phases of Detailed COCOMO1. Requirements Planning and
Product design2. Detailed Design3. Code and Unit Test4. Integration and Test
Thank you.. :P
By : wa lng.. :D