locke@rnms1.paradyne.com (Richard Locke) (08/18/89)
In article <16019@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >johnk@opel.UUCP (John Kennedy) writes: >> It is not uncommon to generate NCSL (Non-Commentary Source Lines) for >> purposes of productivity. >I assume this intended "productivity measurement". And sure, it's not >uncommon...but it's still wrong. [what's wrong deleted] I completely agree that counting lines of code (LOC) to measure a programmer's productivity is invalid. However, a lot of the literature suggests that there is a meaningful relationship between LOC and time to complete a project. We're now in the detailed design phase of a project. Management wants a "the code will be completed on" date from us when the design is "completed". (I know that the design and code stages are iterative, but I'm not sure management wants to hear about it 8^)) The project primarily involves modifications to an existing system, with a few additions. I'm toying with the idea of trying to estimate the LOC that we'll change + the LOC we'll create. Given this number, I'd then plug it into one of the estimating models (Pressman in "Software Engineering" gives a few, as I recall) and come up with with a time. I would then compare this number with the numbers we'll be generating on a "per work item" basis as part of our "normal" design and scheduling process. I have no idea as to how the numbers might come out, and I understand that the estimating models require one to make some subjective assessments about the project. SO, my question is this: Anyone done this type of thing before? If so, what kind of numbers did you get, and how accurate were they? What estimating model did you use, and how much effort did it take (to use the model)? Any comments at all would be appreciated. (E-mail or post at your discretion; I'll post a summary of responses.) -- Dick Locke AT&T Paradyne Corporation {uunet,peora}!pdn!locke Mail stop LG-133 Phone: (813) 530-8241 P.O. Box 2826 Largo, FL 34649-2826 USA