Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

COMP319 > Software cost estimation and project management > Flashcards

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Describe Boem’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 a lot of variance so estimations are largely incorrect
  • As we progress through the project, the variance reduces and our ability to estimate correctly 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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is project success and failure defined by?

A
  • Context (budget, costings, type of company)
  • Culture
  • Sales driven estimation or development driven estimation
  • estimation skill
  • development skill
  • or an external body may determine where a project is a failure or success
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What is an EQF score:

A

An estimation quality factor is a technique used to determine the quality of your estimation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What does a project’s EQF score tell us?

What is an EQF of
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is the issue with EQF?

A

It doesn’t show or consider estimation bias

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What would EQF scores of 3 and 22 be classed as?

A

We can see organisation A has a fairly poor EQF around 3 (which means a typical error
of around 30% in there estimation values). Also organisation A has a positive bias of 7% in their estimates. This would indicate a tendency to over estimate project time. This could lead to projects being over resourced and costing for projects being consistently over estimated.
Organisation B has a lot higher performance in terms of estimation and seems to have a successful estimation technique (EQF 22). Also organisation B has a very small bias, this would imply that the estimation tends to be not effected by external pressures.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What does the eqf and bias tell you about you process for estimating project duration?

A
  • if your EQF is bad and your bias is 0, then you’re 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

What criticisms or flaws were made by the rise and fall of the chaos report about the standish chaos report?

A
  • Definition of Success: The Chaos Report’s criteria (time, budget, and scope) were criticized as overly narrow and not reflective of real-world success factors, such as delivering business value or user satisfaction.
  • Data Transparency: Critics argued that the Standish Group’s methods were opaque, 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
Manufacture/Implementation: Implement the design as product
Quality control: Test/analyse the product
Modify/enhance: Improve the product, fix problems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

What are the 6 steps of the software engineering process?

A
  • Specification
  • Design
  • Development
  • Verification
  • Validation
  • Management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

What are the software engineering activities?

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

What are some ways we can improve design and implementation?

A

Using previous design approaches (object patterns)
- Improve concurrency modelling (Actor modelling and futures)
- Conform to software principles such as SOLID and DRY
- Use Agile approaches like pair programming

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

What should there be a test for?

A
  • There should be a test for every requirement in the specification
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

What should tests be designed to do:

A

They should be designed to:
- Test core functionality
- Expose software failure

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

What are some types of testing:

A
  • Path testing
  • Boundary testing
  • partition testing
  • module testing
  • beta testing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

What are the advantages and disadvantages of having chat gpt create a product specification?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Why did the report refer to the Chaos report as “one sided” in its reporting?

A
  • The case studies show that organisation Y obtains unrealistically low success rates for the individual cost and functionality forecasts owing to the definitions’ one-sidedness.
  • 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 accuracy of cost and functionality in the case of an unbiased best-in-class organisation.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

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.

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Describe the constraint triangle:

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

What are the constraint trade offs in the constraint triangle:

A
  • 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
Q

Where do costs arise in projects?

A
  • staffing: more people/developers cost more
  • hours per person per day
  • using bought in software
  • outsourcing
  • hardware
34
Q

How can a project reduce delivery time?

A
  • employ more people to work on it
  • buy more external software
  • get staff to work more hours
35
Q

Will employing more people to work on a project improve delivery time?

A
  • 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
Q

What is the 20-80 rule?

A

The 20-80 rule (aka Pareto Principle) states that 80% of results come from 20% of the causes. A small percentage of effort generates the majority of the outcomes.

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
Q

Which stage of the development cycle can be signficantly improved by adding more staff?

A
  • 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
Q

Will adding more time, improve product quality?

A

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
Q

What is regressive development?

A
  • jumping between finding a bug, fixing it and then creating more bugs
  • It’s hard to modify code without introducing more bugs
40
Q

What are testing cycles and what features should they have to be successful?

A

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
Q

Why do things go wrong in project management?

A
  • Poor schedule monitoring (progress needs to be constantly checked)
  • Poor analysis of slippage (resulting in remedy of adding manpower)
  • milestones and granularity : fine grained means small milestones - easier to monitor progress/see if these are being completed
42
Q

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?

A
  • 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
Q

What is Schedule Slippage assumption 1?

A

That only task A out of task A, B and C was underestimated task A, so we only need 2 extra people to complete on time

as if it took 3 people to do task A in 2 months, it will take 6 people to do task A in 1 month

44
Q

What is Schedule Slippage assumption 2?

A

That all tasks were underestimated so we need 6 extra people to complete on time

45
Q

What do you do if you can’t add more time to a project?

A

You reduce the requirements on the project: known as trimming the project

46
Q

What occurs during triaging a project?

A

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
Q

If a task is partitionable, what does this allow?

A

tasks that are partitionable can be divided into parts and more people can be added to work on the parts simultaneously

48
Q

What is one way to partition a task/design and what must be true for this to be able to take place?

A
  • Class by class
  • Low coupling between classes
  • allows for several people to work on each class separately and simultaneously
49
Q

What does partitioning a task improve?

A

It helps improve scheduling: can be generated

50
Q

In practice what do most engineers/project managers do and why is thi?

A

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
Q

How can developers or project managers make their estimates more realistic/fail proof?

A
  • Multiply their estimates by 2 or 3
  • sandbag risky activities
  • Keep a record of the forecast against actual performance
52
Q

How can expectations be managed if the project is going to be delivered on time?

A
  • 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
Q

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:

A
  • 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
Q

What methods can be used to cut down communication overhead between people in a team?

A

Using a hub approach: central storage of communication
- shared specification or design documentation
- here communication overhead increases by N instead of N^2

55
Q

What does Brookes law state?

A

Adding manpower to a late software project makes it later
- doesn’t apply to on time projects
- doesn’t apply to highly decoupled projects (easy to scale projects)

56
Q

What has cost estimation research taught us?

A

Moving away from coding estimation to functional estimation (move away from language or environment but towards functionality of the code)

57
Q

What are some cost estimation approaches?

A
  • 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
Q

Describe what Work breakdown structure is?

A
  • 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
Q

Describe what Poker planning is?

A
  1. Each member of the planning team is given a pack of card 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
Q

Who is Poker planning commonly used by?

A

Agile developers and SCRUM teams

61
Q

What are the benefits of Poker planning?

A
  • 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
Q

What did a study discover about Poker Planning?

A

K.Molokken-Ostvold and N.C. Haugen study found estimates were less optimistic and more accurate than ones obtained through the simple combination of individual estimates for the same tasks.

63
Q

How is software productivity measured?

A
  • Lines of source code per month written
  • object code instructions produced
  • document pages (how long requirements are)
  • function points
  • object points
64
Q

Describe the KLOC method?

A

This is used for measuring software productivity
- easy to measure once written
- difficult to estimate how many will be produced for a project

65
Q

Why is KLOC not a good measure of software productivity?

A
  • 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
Q

What are function points?

A
  • a standardised unit of measure to express the size and functionality delivered by a software application
  • focuses on the software’s functionality from users perspective
67
Q

What are the 5 components of function point analysis (FPA)?

A
  • 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
Q

How is function point analysis (FPA) calculated?

A

1) identify the components
2) assign complexity weights to each component (simple, average, complex)
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

69
Q

What are the advantages of function point analysis?

A
  • more accurate the KLOC (lines of code)
  • very scalable for projects of varying sizes
  • Not language dependent
70
Q

What are the disadvantages of function point analysis?

A
  • Time consuming, requires a lot of work
  • doesn’t focus on algorithm complexity
71
Q

What are object points?

A
  • used to estimate size/complexity of a software application
  • Object Points measure the features and functionality of the application that are visible to users, such as UI components, reports, or screens.
72
Q

What are the 3 types of objects in object points?

A
  • screens (input and output)
  • reports (more complex calculations)
  • 3GL components (code level objects written in 3rd generation languages: python, java)
73
Q

How are object points analysed?

A
  • 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
Q

What are the limitations of object points?

A
  • subjectivity in assigning the complexity level
  • only suited to applications with significant user interaction
75
Q

What is the constructive cost modelling method? (COCOMO)

A
  • developed by Boehm, it’s a algorithmic cost modelling method for estimating software projects
  • creates a model to estimate staffing, duration and cost
76
Q

What is the input and outputs of the COCOMO method?

A

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
Q

What is algorithmic cost modelling?

A

Assumes there’s a mathematical relationship between
- size of project and effort (staff) required
- uses data from several other projects to produce this model
- accounts for variations in input factors

78
Q

What is the formula for team size?

A

Team Size = Effort (Person-Months) / Project Duration (in months)

so for a 12 month project with 123 person-months
123/12 = 10 people (approx)

COMP319 (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions