CS 458 - Week 7 Lecture 1 - 2016-10-04

*   starting in-class discussion of Jalote Chapter 4 - 
    Planning a Software Project

*   Weeks of programming can save you hours of planning...!

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

*   Jalote's defn of project success MAY be a bit strong...?!
    "A project succeeds if it meets its cost, schedule, AND quality
    goals"...!

*   a plan can ALSO help in monitoring a project's status --
    maybe you can see a crisis developing in time to
    do something about it;

    (and hopefully can MODIFY the plan if it is proving to
    be unrealistic...)

*   EFFORT estimation...
    *   what is considered "good" for an effort estimate?
        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 to be a "good" estimating
	approach;

    *   text talks about top-down and bottom-up	
        estimation approaches;

    *   MANY factors can affect the effort needed for 
        a project --

	interestingly (oddly?), in estimation,
	it is often considered to be the SIZE that
	is the primary factor that controls the
	project;

	^ but some approaches DO include means for
	including some of the other factors as well;

        *   in many top-down estimation approaches,
	    the idea is: use the estimated SIZE to
	    determine the estimated EFFORT

	    (considers the effort as a FUNCTION of
	    project size)

        *   one approach: IF past productivity on
	    SIMILAR projects is known,
	    P KLOC/PM  <- P 1000-lines-of-code/person-month

	    then you estimate the size (in KLOC),

	    and effort can be estimated as
	    
            SIZE/P person-months

        *   another: more general:

	    EFFORT = a * (SIZE ^ b)

            ...SIZE is given in KLOC (1000-lines-of-code)
	    ...(effort is usually in person-months)

	    ...where a and b are constants
            ...where do you GET these constants?

	       *   sometimes you use REGRESSION ANALYSIS
	           applied to PREVIOUS projects;

               *   example: Watson and Felix (1977)
	           analyzed 60+ projects at the
		   IBM Federal Systems Division,
		   4000 - 467,000 lines of delivered source code

		   a = 5.2
		   b = 0.91

		   EFFORT = 5.2 * (SIZE ^ 0.91)

*   COCOMO (actually COCOMO 81 and COCOMO II)
    *   Boehm
    *   COnstructve COst MOdel

    *   start with COCOMO 81 (the one described in the text)

        start with an INITIAL/NOMINAL estimate:

	(based on the nature of the project --
	for an "organic" project, that is determined using:

	EFFORT = 3.9 * (SIZE ^ .91)

        *   THEN this provides a means for tweaking/adjusting
	    this initial/nominal estimate,

	    based on 15 different COST DRIVER ATTRIBUTES,
	    each with a rating scale, which is QUALITATIVE:

	    very low, low, nominal, high, very high

             ...and for each rating for each cost driver attribute,
	     there is a table with a MULTIPLYING factor
	     provided;

        *   attribute: RELIABILITY

	    very low   low	nominal	 high	very high

            0.75       0.88     1.0      1.15   1.4

	    ...very high reliability expected? 
            *   multiplying the initial estimate by
	        1.4 increases the effort estimate;

	    ...very low reliability expected? 
            *   multiplying the initial estimate by
	        0.75 decreases the effort estimate;

        *   ...and you do this for all 15 of the
	    cost driver attributes;

        *   Jalote:
	    *   the multiplying factors for all 15
                cost drivers are MULTIPLIED
		to get the EAF (effort adjustment factor)

		...and the final estimate is obtained
		by multiplying the initial estimate
		by the EAF

        *   the cost factors are listed on Jalote p. 72

*   once you HAVE this effort estimate,
    *   COCOMO 81 - use this to determine the
        effort distribution among the phases

	small? perhaps: 16% product design
	                26% detailed design
			42% code & unit test
			16% integration & test

	large?		16%, 23%, 36%, 25%