Software cost estimation and project management Flashcards
1
Q
What are the issues with measuring success relative to the original estimation?
A
Sometimes companies
- estimate too low timescales
- are underresourced and over-promised
- estimate too high timescales
- are overresourced
- get it just right
2
Q
Describe Boehm’s cone of uncertainty
A
- Describes the evolution of the amount of best case uncertainty during a project.
- Early on in a project, there’s large variance so estimations are often incorrect
- As the project progresses, variance reduces and our estimation ability improves
- When we get very close to the project delivery date, the variance is so small that we can near perfectly estimate when it will be finished.
3
Q
What is project success and failure defined by?
A
- Context (budget, costings, type of company)
- Culture
- estimation skill
- development skill
- or an external body may determine if a project is a failure or success
4
Q
What is an EQF score:
A
An estimation quality factor is a technique used to determine the quality of your estimation.
5
Q
What does a project’s EQF score tell us?
What is an EQF of 0 considered to be?
What is an EQF of 3 considered to be?
What is an EQF of 10 considered to be?
A
- If it’s high it tells us your good at estimating
- If it’s low it tells your bad at estimating
- If the EQF score is 0, you’re perfect at estimating
- An EQF of 10 is considered to be good
6
Q
Calculate the EQF score for this project:
* Project completes in 14 weeks
* Estimates: 20,10,15,12,12
A
- Differences: 6,4,1,2,2
- Average deviation: ((6/14) + (4/14) + (1/14) + (2/14) + (2/14)) / 5 = 0.214
- EQF = 1/Average = 4.67
7
Q
What is the issue with EQF?
A
It doesn’t show or consider estimation bias
8
Q
What does estimation bias show?
A
Estimation bias as a measure for a number of estimates shows if the estimator in generally over or under estimates.
9
Q
What does it mean if an estimator has an estimation bias of 0?
A
It means that the over estimate the same amount of time as they underestimate
10
Q
What does a positive or negative estimation bias tell us:
A
A positive estimation bias tells us that the estimator generally overestimates
a negative estimation bias tells us the estimator generally underestimates
11
Q
What are the effects of over and under estimating project duration?
A
- overestimation leads to waste and over-resourcing
- underestimations lead to more project overruns and money may be lost in the form of contract penalty clauses
12
Q
What would EQF scores of 3 and 22 be classed as?
A
Organisation A has a fairly poor EQF around 3 (which means a typical error of around 30% in there estimation values)
Organisation B has a lot higher performance in terms of estimation and seems to have a successful estimation technique (EQF 22).
13
Q
What is the difference between calculating the bias and calculating the bias percentage?
Note: In the exam, it will ask for the bias to be calculated this means the bias percentage.
A
Bias percentage is just the normalised figure of the bias:
Bias = mean(estimates) - actual value
Bias percentage = (mean(estimates) - actual value) / actual value
14
Q
Give the (percentage) bias of the following project:
* Estimates: 20,10,15,12,12
* Actual value: 14
A
- Bias = (13.8-14)/14 = -0.0143 or - 1.43%
- We can see that the estimates are fairly unbiased overall, but only slightly optimistic (overall the estimation was under the actual)
15
Q
When do you bother calculating bias?
A
- if the EQF is good, you’re not bothered about bias
- If the EQF is bad, you calculate it to see if there’s a pattern to your estimates
16
Q
What does the eqf and bias tell you about your process for estimating project duration?
A
- if your EQF is bad and your bias is 0, then your process for estimation is random or all over the place
- if your EQF is bad and your bias is largely negative or largely positive, it means there’s a fault in your process that’s causing either great under or great over estimation
17
Q
What are some attributes that effect estimations?
A
-When the estimation is made: early estimations are more erroneous than later ones
-management pressure: can create low estimates because management has pushed for that
-inexperienced developers
-lack of design (makes it harder to estimate)
-quality of specification (more detail, means the estimate for how long it takes is more accurate)
18
Q
What is sandbagging?
A
giving more time or resources than is actually needed just in case they are needed (but most likely aren’t)
19
Q
What criticisms or flaws were made by the rise and fall of the chaos report about the standish chaos report?
A
- The Chaos Report’s criteria is overly narrow and not reflective of real-world success factors, such as delivering business value or user satisfaction.
- The Standish Group’s methods were opaque, data findings are based on is not published, making it hard to validate their findings.
- Bias Toward Small Projects: Later iterations showed smaller projects had higher success rates, leading some to argue the report undervalued the benefits and challenges of large-scale innovation.
- you have to look at the raw data to see if companies were actually successful
20
Q
What are the general engineering principles?
A
Specification: What should it do? How should we specify?
Design: How should it do it? General approach
Implementation: Implement the design as product
Quality control: Test/analyse the product
Modify/enhance: Improve the product, fix problems
21
Q
What are the software engineering activities?
A
Software Engineering activities
* Requirements analysis
* Software design/implementation: Patterns, Actor model, AOP
* Software testing and analysis: Program slicing
* Software Management: Scheduling, quality assurance, workflow
22
Q
What are the 6 steps of the software engineering process?
A
- Specification
- Design
- Development
- Verification
- Validation
- Management
23
Q
What are the 4 software engineering components?
A
- Software specification: customers and engineers define the software and it’s operational constraints
- software development: SOLID and OO patterns
Actor model, futures (concurrency) - Software validation: Software (and specification) is checked against requirements
- Software evolution: Software modified to meet new customer and market requirements
24
Q
What are some ways we can improve design and implementation?
A
- Using OO object patterns
- Improve concurrency modelling (Actor modelling and futures)
- Conform to software principles such as SOLID and DRY
- Use Agile approaches like pair programming
25
What should there be a test for?
- There should be a test for every requirement in the specification
26
What should tests be designed to do:
They should be designed to:
- Test core functionality
- Expose software failure
27
What are some types of testing:
- Path testing
- Boundary testing
- partition testing
- module testing
- beta testing
28
What are the advantages and disadvantages of having chat gpt create a product specification?
Advantage
- is that it very quickly can create a list of specifications
- it writes them clearly
- it has good coverage of core requirements
Disadvantage:
- it doesn't understand what it's producing
- any innovations are just pirated from existing products
29
Why did the report refer to the Chaos report as “one sided” in its reporting?
- A case study shows that organisation Y obtains unrealistically low success rates for cost and functionality forecasts
- Realistically the organisation has a higher project success rate, but the one-sidedness of the chaos report makes the success figures a lot lower.
- Standish success rates don’t give an accurate indication of true estimation for an unbiased best-in-class organisation.
30
What is the meaning of the term f/a and how does it relate to project failure or success when looking at project time taken and also functionality delivered.
F is the forecasted value in terms of budget and time and A is the actual time or budget for the project
- they closer the f/a value is to 1, the more successful the chaos report determines the project to be
31
Describe the constraint triangle:
Software products have 3 constraints:
- Cost, time and quality
- You can adjust any two but you can't have improve all 3 factors at once
32
What are the constraint trade offs in the constraint triangle:
- increasing the cost may not always result in less time or an increase in quality
- increasing time may not always increase quality (as the time may not be used well)
33
Where do costs arise in projects?
- staffing: more people/developers cost more
- hours per person per day
- using bought in software
- outsourcing
- hardware
34
How can a project reduce delivery time?
- employ more people to work on it
- buy more external software
- get staff to work more hours
35
Will employing more people to work on a project improve delivery time?
- Yes if software components are dependent so can be worked on in parallel/ simultaneously by different people/groups of people
- No as people working longer hours will make more mistakes, which need fixing.
36
What is the 20-80 rule?
The 20-80 rule states that 80% of results come from 20% of the causes.
Focus on the most critical tasks or use cases first. Usually, a small number of features or requirements (the 20%) will deliver the most value (the 80%).
37
Which stage of the development cycle can be signficantly improved by adding more staff?
- The testing stage as it's a very scalable process
- increasing testing staff reduces the test cycle time, this increases cost but reduces time and hopefully improves quality
38
Will adding more time, improve product quality?
Yes, but only if:
- time is spent doing testing and quality assurance and not adding more functionality
- if software development is progressive not regressive
39
What is regressive development?
- jumping between finding a bug, fixing it and then creating more bugs
- It's hard to modify code without introducing more bugs
40
What are testing cycles and what features should they have to be successful?
Period of time where testing is carried out.
- Need to be short enough to keep development flowing
- need to be long enough to test all components
- testing should be overlapped with bug fixing
41
Why do things go wrong in project management?
- Poor schedule monitoring (progress needs to be constantly checked)
- Poor analysis of slippage
- milestones aren't fine grained enough (means small)
42
What methods can be used when the project manager notices the team is not on track to deliver the product on time due to slippage?
- Strategy 1: Reschedule to push back the delivery date, using the same team
- Strategy 2: Trim the task to ensure completion on the same date (use a triage to determine the trim)
43
What is Schedule Slippage assumption 1?
That only task A out of task A, B and C was underestimated task A
44
What is Schedule Slippage assumption 2?
That all tasks were underestimated so we need 6 extra people to complete on time
45
What do you do if you can't add more time to a project?
You reduce the requirements on the project: known as trimming the project
46
What occurs during triaging a project?
Feature triage takes place: defining requirements into must do, good to do and nice to do
- testing and debug triage: must fix, good to fix and nice to fix
- splitting software into critical, usable and desirable
- completing the must do, must fix or critical first and then seeing what can be completed if there's still time before the deadline
47
If a task is partitionable, what does this allow?
tasks that are partitionable can be divided into parts and more people can be added to work on the parts simultaneously
48
What is one way to partition a task/design and what must be true for this to be able to take place?
- Class by class
- Low coupling between classes
- allows for several people to work on each class separately and simultaneously
49
What does partitioning a task improve?
It helps improve scheduling: can be generated
50
In practice what do most engineers/project managers do in regard with estimation and why is this?
They underestimate how long a task will take to do
- Lack of experience
- not accounting for contingency
- pressure from management
- Assuming everyone is as skilled as them
51
How can developers or project managers make their estimates more realistic/fail proof?
- Multiply their estimates by 2 or 3
- sandbag risky activities
- Keep a record of the forecast against actual performance
52
How can expectations be managed if the project is not going to be delivered on time?
- give bad news as it happens
- give management alternative plans
- put in place a plan to trim the task
- explain how reducing time could lead to a bad outcome
53
What do you need to take into account when adding more staff to a project?
calculate how much effort is needed for 3 or 4 people compared to 2 people:
- Covering time and cost for training them
- Effort needed for communication increases as n(n-1)/2
- e.g. 3*(3-1)/2 = 3 times as much effort as 2
- 4*(4-1)/2 = 6 times as much effort as 2
- as project size increases, 1 person tasks may not always scale when increasing the number of people.
54
What methods can be used to cut down communication overhead between people in a team?
- Using a hub approach: central storage of communication
- shared specification or design documentation
55
What does Brookes law state?
Adding manpower to a late software project makes it later
- doesn't apply to on time or highly decoupled projects
56
What has cost estimation research taught us?
to move away from coding estimation to functional estimation (move away from language or environment but towards functionality of the code)
57
What are some cost estimation approaches?
- Expert estimation (wisdom of crowds/groups to tease out product difficulties)
- Poker Planning (example of expert estimation)
- Work breakdown structure
- Formal estimation (e.g. COCOMO, FPA)
58
Describe what Work breakdown structure is?
- It's an estimation approach involving breaking down programs into use cases
- Then noting what each use case requires in terms of coding
- Then adding up how long the whole project will take, counting the time each use case will take
59
Describe what Poker planning is?
1. Each team member is given cards with numbers on
2. Project manager introduces the project, team discusses assumptions and risk
3. each member picks a card as estimate, they hide their cards, then everyone shows them at the same time
4. Lowest and highest estimation member are asked to justify their decision
5. Discuss then go back to step 3, until a consensus is reached
60
Who is Poker planning commonly used by?
Agile developers and SCRUM teams
61
What are the benefits of Poker planning?
- it reduces anchoring (people setting too high or too low estimates, as they have to justify their estimate)
- the team give less biased estimates as they can't see others estimates before they show theirs / and everyone has to explain their decision
- uses combined knowledge of the group to get the final estimate
62
What did a study discover about Poker Planning?
K.Molokken-Ostvold and N.C. Haugen study found estimates were less optimistic and more accurate than ones obtained through individual estimates
63
How is software productivity measured?
- Lines of source code per month written
- document pages (how long requirements are)
- function points
- object points
64
Describe the KLOC method?
Measures software productivity
- easy to measure once written
- difficult to estimate how many will be produced for a project
65
Why is KLOC not a good measure of software productivity?
- could be many lines of code written but the code is still bad quality
- this doesn't guarantee project delivery
- language dependency, different languages produce different amounts of LOC
66
What are function points?
- a unit to express the size and functionality delivered by a software application
- focuses on the software's functionality from users perspective
67
What are the 5 components of function point analysis (FPA)?
- External inputs: user inputs into the system
- external outputs: outputs delivered to the user
- external inquiries: user initiated requests that result in responses without modifying data
- internal logic files: data maintained in the system (e.g. databases, files)
- External interface files: data used or referenced by the system but maintained outside of it e.g. external APIs or data files
68
How is function point analysis (FPA) calculated?
1) identify the components
2) assign complexity weights to each component
3) multiply the number of components by their corresponding complexity weight and sum them
4) adjust value by VAF factor (environment and technical) value adjustment factor for final estimation
69
What are the advantages of function point analysis?
- more accurate the KLOC (lines of code)
- very scalable for projects of varying sizes
- Not language dependent
70
What are the disadvantages of function point analysis?
- Time consuming, requires a lot of work
- doesn't focus on algorithm complexity
71
What are object points?
- used to estimate size/complexity of a software application
- Object Points measures functionality of the application visible to users, such as UI components, reports, or screens.
72
What are the 3 types of objects in object points?
- screens (input and output)
- reports (more complex calculations)
- 3GL components (code level objects written in 3rd generation languages: python, java)
73
How are object points analysed?
- each object point is given a complexity rating: low medium, high
- a weighted sum is calculated based on the count multiplied by the complexity weight
- raw object points may be adjusted based on environment
74
What are the limitations of object points?
- assigning complexity level is subjective
- only suited to applications with significant user interaction
75
What is the constructive cost modelling method? (COCOMO)
- developed by Boehm, it's a algorithmic cost modelling method for estimating software projects
- creates a model to estimate staffing, duration and cost
76
What is the input and outputs of the COCOMO method?
inputs
- project design model
- staff available
- hardware and CASE tools involved
- project nature
outputs
- size of system (LOC or FP)
- project schedules
- cost and staffing estimation
77
What is algorithmic cost modelling?
- Assumes there's a mathematical relationship between size of project and effort (staff) required
- uses data from past projects to produce model
- accounts for variations in input factors
78
What is the formula for team size?
Team Size = Effort (Person-Months) / Project Duration (in months)
so for a 12 month project with 123 person-months
123/12 = 10 people (approx)
