song@berault.ics.uci.edu (Xiping Song) (04/13/91)
A design methodology is supposed to be able to help in improving the quality of software. After one chooses a methodology and uses it to design a software, there is any way in which he/she can evaluate how effectively the methodology have helped the project? --Song
jls@rutabaga.Rational.COM (Jim Showalter) (04/16/91)
%A design methodology is supposed to be able to help in improving %the quality of software. After one chooses a methodology and uses it %to design a software, there is any way in which he/she can evaluate how %effectively the methodology have helped the project? The only way I know of is to have a shadow project do the same software in a different methodology and contrast the result (along several axis, such as cost, time, maintainability, bugginess, etc). I know of several cases in which this was done by companies wishing to get some real numbers about the merits of functional vs object-oriented approaches: in all the cases I'm aware of the object-oriented projects came out on top even though they had to learn a new methodology (and sometimes a new language) as part of the process. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *
dlw@Atherton.COM (David Williams) (04/20/91)
In article <28062E7B.25315@ics.uci.edu>, song@berault.ics.uci.edu (Xiping Song) writes: A design methodology is supposed to be able to help in improving the quality of software. After one chooses a methodology and uses it to design a software, there is any way in which he/she can evaluate how effectively the methodology have helped the project? --Song Well you can use metrics to determine how you are doing. Of course this assumes you have been collecting them on your existing projects or have some way of determining where you were at with previous projects. You might look at some factors like time to completion, amount of effort spent doing redesign during the project, defect density, customer satisfaction upon delivery, evaluation of whether or not the delivered project met the requirements using the new methodology vs the degree of requirements matching of previous projects. Check out the SEI approach to understanding where you are in terms of process maturity and start monitoring yourself as you try new techniques. Finally, use a gut reaction...how does it feel to you once you've completed your project using the new methodology? Did you feel more productive? Can your metrics back this feeling up? David Williams--------------------------------------------------------------------- #define flame_sheild "I know you are, but what am I?" --------------------------------------------------------------------- David Williams -- dlw@atherton.com -- (408) 734-9822 x291 Atherton Technology -- The CASE Repository/IPSE 1333 Bordeaux Drive Sunnyvale, CA 94089 AIX,SunOS,Ultrix,VMS *