CS 435 - Week 8 Lecture 1 - 2014-03-11

*   PLANNING a software project - Jalote Chapter 4

*   Jalote's view: planning is THE most important
    project *management* activity

    ...and as a general rule/classically, it tends
    to get short shrift;

    *   Brooks agrees on the important of planning
        as well -- see MMM Chapter 2's suggested
	planning heuristic;

*   2 basic objectives:
    *   establish reasonable cost, schedule, and quality
        goals for the project,
    *   to draw out a plan to deliver the project goals

*   Jalote then defines "project success" to be MEETING
    the project's cost, schedule, and quality goals;
    *   ...at least, ideally!

*   one reason for goals? to know when (and even that)
    you have succeeded...!
*   another advantage of detailed planning - it allows
    for more effective/practical monitoring of progress,
    and of control of the project;

*   "inputs" to the planning activity? include:
    *   certainly includes the requirements!
        (I'd think the SRS would be part of this;)

    *   maybe the software architecture, if that is
        yet known;

*   "outputs" of the planning activity:
    *   the overall PROJECT MANAGEMENT PLAN document
        that establishes the project GOALS in terms
	of cost, schedule, and quality

        *   also DEFINES the plans for
            managing RISK,
	    MONITORING the project,
   	    etc.
   *   the DETAILED PLAN (often ref'd to as the
       DETAILED PROJECT SCHEDULE), specifying:
       *   the tasks to be performed to meet those goals
       *   WHO will perform them
       *   their SCHEDULE

*   note that planning can also include
    identifying HIGH-PRIORITY potential risks,
    and how they might be mitigated

*   and it can also include a plan for how the
    plan will be monitored...!

EFFORT ESTIMATION

...if from the requirements specifications,
   the estimate approach can produce estimates
   that are within 20% of the actual effort
   about 2/3 of the time,
   that's considered "good" for an estimating approach

two CATEGORIES of effort estimation approaches:
top-down, bottom-up
*   top-down: try to estimate the project's overall
    size, and then estimate the effort needed from there;

*   bottom-up: divide the project into tasks,
    estimate the effort needed for each task to estimate
    the overall effort;

TOP-DOWN...
*   figure out the size, determine the effort needed
    from that;

*   IF past productivity on similar projects
    is known, you can use that as the estimation
    function;

    IF productivity is P KLOC/PM
                         KLOC = 1000-lines-of-(debugged)-code
			 PM = Person Month

    then one quick-n-sleazy effort estimate could
    be:

    SIZE / P person-months

    (where SIZE is -- gulp -- 1000-lines-of-code...)

    *   this can only POSSIBLY be reasonable 
        IF the current project is similar in
	size and type to the set of projects
	from which the productivity P is derived;

*   the above is rather limited for the cases it
    can help with;

*   a slightly more general function:

    (that is evidently used at times!)

    EFFORT = a * (SIZE^b)
    where a and b are constants 
    determined via regression analysis applied
    to data about similar projects performed in
    the past;

    *   Watson and Felix ([81] from 1977)
        found that, for 60+ IBM Federal Systems Division
	projects,
	ranging from 4000- 467,000 lines of *delivered*
	source code,
	that for SIZE given in KLOC,
	the total effort P in person-months
	can be estimated using the equation:

	EFFORT = 5.2 * (SIZE^.91)
	(a = 5.2, b = .91)

*   COCOMO -
    (NOTE: what the text calls "COCOMO" is now
    called COCOMO 81,
    and the "newer" COCOMO is called COCOMO II)

    COnstructive COst MOdel <-- Boehm

    in COCOMO 81,
    *   you get an initial estimate, the NOMINAL
        ESTIMATE, based on the equation for an
	organic project:

	EFFORT = 3.9 * (SIZE ^ .91)

        (EFFORT in PM, SIZE in KLOC)

    *   BUT -- you then TWEAK the nominal estimate
        by ESTIMATING the rating for each of 15 COST
	DRIVER ATTRIBUTES,
	and then grab the multiplying factor for that
	rating of that attribute for each attribute

	*   these ratings are a small, qualitative
	    set --
	    very low, low, nominal, high, very high