CSSE3002 Lecture Notes - Lecture 12: Entire Function, Arms Industry, Boeing
28 Jun 2018
School
Department
Course
Professor
Software Estimation Further Techniques
Makes estimates for user stories for release plan and sprint plan (e.g. planning poker etc as
techniques) – quite accurate for initial stage estimation
Estimation is only accurate if it is actually measured before
-Figure out what is the size
-How long do you usually take to build something?
-Calculate how long you need to build something of that size
Estimation
-Planning poker is effective because it is done as a team
-Different people contribute different skill to create the estimate
-If it is a small team, everyone does the estimate meanwhile large teams will have a
sub team that does the estimate
-If estimate is done by project manager, it is probably not really accurate
-Different roles should be in the sub team, so that people can contribute to different
parts of the development and come up with a reasonable estimate
-People usually want more than developers can deliver
-Estimates are done because need to know the budget (prioritisation need to be done
so that if reaches budget, the less important parts can be ignored)
-Estimates can be given in a range (e.g. 9-15 months) and the refine the estimate as
more info is given/going into development
-Range is done with: best case, worst case, average case
Estimation Guidelines
-Process for creating estimate
-A group of people share valuable opinions
-Historical data: look at past projects and estimate with the size, similarity and
duration
-Statistical analysis: collect formal data, tracks how well the past estimation is done
Software Size Measures
-Measure time(easy), how long does it take
-Hard to measure a task
-Measuring software
oSyntactic: measure lines of code (simple, easy to measure and automate
hence commonly used)
oSemantic: function points (abstraction, unit of functionality)
find more resources at oneclass.com
find more resources at oneclass.com
Lines of Code
-Problem: language dependent (100k lines of C is different with 100k lines of java)
-Need a counting standard (formatting style, doesn’t count comments)
Function points
-Abstract representation
-Functionality relates with inputs and outputs
-Function to accept data, function to display results, function for external query
-Calculating: functions points (4 times external inputs plus 5 times external outputs…)
-Weighting for complexity: e.g. basic login vs complex validation for login (minus 25%
for simple things and plus 50% for complex things)
-VAF: multiplier for the entire function points (e.g. huge number of transaction?
Distributive across multiple servers that needs to be coordinated?)
-Drawback:
oit is very subjective because different people could give different points
ocan’t automate
oold system, new types of user interface etc hence have to count them
differently
another approach is to use parametric models, which based on formula around time
-how much effort required: how many people by how many months
-assumption – following a simple 3-tier architecture – either a GUI or web-based
interface
-estimation – estimate on design, how many classes are there on entity model
-every entity class represents a thing in the system
-how productive is the team determines the effort required to produce all the classes?
-need to know how long it takes for developers to do stuffs (typical industry average)
-e.g. internet banking example: 9 entity classes, small system – find out how long it
takes -simple estimation technique
-COCOMO 2 – cost complexity modelling – use huge amount of data from defence
industry to come out an estimate
o3 sub models – for 3 different stages (early estimation with little information,
more information, and even more information for higher accuracy)
oTwo basic assumptions: application composition – experienced company and
staff, mostly using reusable stuffs
oApplication development – build everything from start
find more resources at oneclass.com
find more resources at oneclass.com
Document Summary
Makes estimates for user stories for release plan and sprint plan (e. g. planning poker etc as techniques) quite accurate for initial stage estimation. Estimation is only accurate if it is actually measured before. Calculate how long you need to build something of that size. Planning poker is effective because it is done as a team. Different people contribute different skill to create the estimate. If it is a small team, everyone does the estimate meanwhile large teams will have a sub team that does the estimate. If estimate is done by project manager, it is probably not really accurate. Different roles should be in the sub team, so that people can contribute to different parts of the development and come up with a reasonable estimate. People usually want more than developers can deliver. Estimates are done because need to know the budget (prioritisation need to be done so that if reaches budget, the less important parts can be ignored)
