CS 458 - Week 8 Lecture 1 - 2016-10-11
back to Jalote Ch. 4
* top-down estimation approaches DO tend to replace
the problem of effort estimation (typically person/months)
with the problem of SIZE estimation (typically KLOC)
* bottom-up estimation, then?
* first divide the project into tasks
* then obtain estimates for each task
* from the estimates of the different tasks,
get the overall estimate
* also called activity-based estimation
* SOMETIMES -- when a project's software architecture
is sufficiently familiar --
can have a bottom-up "shortcut" approach as follows:
* determine the major "modules" in the software
to be built
* each "module" is then classified as
* simple
* medium
* complex
* then, for each of these classifications,
an AVERAGE effort for coding/unit-testing
is determined
* then --
(number of simple modules * avg effort for simple
+ (number of medium modules * avg effort for medium)
+ (number of complex modules * avg effort for complex)
* procedure for this flavor of bottom-up approach:
1. identify the modules in the system,
classify each as simple, medium, or complex
2. determine/decide the average coding effort
that will be needed for a simple, a medium,
and a complex module
3. get the total coding effort estimate using
(number of simple modules * avg effort for simple
+ (number of medium modules * avg effort for medium)
+ (number of complex modules * avg effort for complex)
4. using the effort distribution for similar
projects, estimate the effort for other
tasks, and the total effort
5. refine the estimates based on project-specific
factors
* Project Schedule and Staffing
* remember Brooks!
people and months are NOT completely interchangeable!
BUT there is a range of reasonable possibilities
within that
(if you keep the caveats in mind...!)
* no simple equation between effort and
schedule works WELL,
but there are some heuristics available...
IBM Federal Systems Division study:
M in calendar months,
E in person-months,
M = 4.1 * (E ^ .36)
COCOMO 81: ("organic" project)
M = 2.5 * (E ^ .38)
for a 50 person-month project:
* IBM Fed: 4.1 * (50 ^ .36) -> 16.8 months
* COCOMO 81: 2.5 * (50 ^ .38) -> 11.1 months
100 person-month:
... 21.5 months, and 14.3 months
* this might be useful as a "reality check"
or a warning not to expect to get a lot shorter
than these estimates;
* another approach for medium-sized projects:
a rule of thumb called the square-root check:
* suggests that the proposed schedule can be
around the square root of the total effort
in person months
...can be met IF SUITABLE resources are assigned
to the project;
50 PM above? suggests 7 months...! hmm!
* but, from a macro estimate, one can then
attempt tp determine a schedule for the project's
major milestones
* also consider manpower ramp-up
(Rayleigh curve) --
fewer needed at beginning and end,
more in the middle; <-- peak team size (PTS) needed
somewhere near the middle;
* and there are various estimates
for %'s for phases;
(Brooks said 33% for planning;)
another from Jalote suggests 25% of the schedule
for design,
COCOMO 81 says 19% for an "organic" project
Jalote suggests 50% for the "build" stage,
COCOMO 81 suggests 62%,
(and if you combine Brooks' coding AND
component-and-early-system-test,
thats 1/6 + 1/4 ~= 42%)
Jalote suggests 25% for "integration and system test",
COCOMO 81 suggests 18%
(and Brooks "systems test, all components in hand",
was 25%)
* Quality Planning
* HARD to quantify "quality"; (even harder than
quantifying cost and schedule)
* so -- quality goals are often specified in terms
of acceptance criteria;
(one form of these could be acceptance tests,
I think;)
Sometimes quality goals are based on number
of defects found during acceptance testing,
OR during the first X months after release,
etc.
* a QUALITY PLAN is a set of quality-related activities
a project plans to do the achieve its quality goals
* after Exam 1:
* what is a defect?
* defect injection
* risks, risk management