From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.42.197.134 with SMTP id ek6mr59394236icb.6.1416017519972; Fri, 14 Nov 2014 18:11:59 -0800 (PST) X-Received: by 10.50.112.137 with SMTP id iq9mr197332igb.1.1416017519878; Fri, 14 Nov 2014 18:11:59 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!r10no2901524igi.0!news-out.google.com!c9ni14081igv.0!nntp.google.com!h15no458887igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 14 Nov 2014 18:11:59 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:9:1100:e95:4d48:a052:fd6a:d4c2; posting-account=XrU4OgoAAADEPkoULFhRQzFYU74OGc9X NNTP-Posting-Host: 2601:9:1100:e95:4d48:a052:fd6a:d4c2 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: software metrics From: rriehle@itu.edu Injection-Date: Sat, 15 Nov 2014 02:11:59 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:23348 Date: 2014-11-14T18:11:59-08:00 List-Id: On Wednesday, March 8, 1995 12:15:51 PM UTC-8, Patrizia Sgubbi wrote: > Hi I am working on a graduation paper about software metrics. more > precisely, I am articulating my work in 3 phases. The first is just a > review of existing techniques, starting from the basic papers towards > modern object-oriented approaches. In the second phase I have to find a > way to apply metrics to a special case: formal specifications. I am > examinating the design phase of a software project in different > versions, as about ten groups of students have written them. The > language adopted is Larch. This design phase follows an analysis phase > developed using Z language. > I am not interested about the implementation level. My final goal would > be to develop a tool which automatically takes larch scripts as inputs > and gives as output an estimation of their quality. >=20 > IMPORTANT: I am looking for papers about software metrics in general and = more > specifically about software metrics in Object oriented environment and > software metrics applied to formal specification or software metrics > related to analysis and design phase of the software life cycle. >=20 >=20 > Any suggestion? >=20 > Please e-mail to > sgubbi@cs.unibo.it >=20 >=20 > Thank you all, > Patrizia >=20 >=20 > --------------------------------------------------------------------- > - Patrizia Sgubbi "... like a true nature's child -=09 > - e-mail: sgubbi@cs.unibo.it " we were born, born to be wild..." - > - tel: --39/-51/372917 (Steppenwolf) - > --------------------------------------------------------------------- >=20 > -- > --------------------------------------------------------------------- > - Patrizia Sgubbi "... like a true nature's child -=09 > - e-mail: sgubbi@cs.unibo.it " we were born, born to be wild..." - > - tel: --39/-51/372917 (Steppenwolf) - > --------------------------------------------------------------------- Quite a few books have been written on this topic. The question we need to= ask is, "What do we mean by metrics?" =20 We have metrics for processes, for products, for performance, etc. That lea= ds to the question, "What do we want to measure?" =20 Consider the product metrics. In the world of physical engineering, we ha= ve design metrics based on the laws of physics. In software, we need to in= vent those metrics. In physical engineering, we have "sensitivity" metric= s that involve gradual changes; software tends to be discrete. Gradual cha= nges, while possible, are not quite the same. A single bit with a zero ins= tead of a 1 can crash an otherwise robust design. In physical engineering, we can easily design to tolerances. Not so easy (= but still possible) in software engineering. Do you want to study design = metrics? In process metrics, we have a large number of things we can measure. Often= overlooked, but of vital importance in modern software engineering is the = area of risk metrics. How do we measure the various kinds of risks? How d= o we learn from past risks? In my software risk management course, I emph= asis Bayesian probability as one of the tools for moving toward Level Five = in the CMM/CMMi scale. It is an exciting area of risk management (OK, only= exciting for a really boring person such as me). What do we measure? Size? Progress? Performance? Failure rate? Defect= rate? Project activities and targets? SLOC ratios? Function point rat= ios? Customer satisfaction (seldom really measured by technologists)? Am= ount of time and money for adaptation? Conformity to standards? On and o= n and on? What kind of metrics of value to you on any given project, for any given so= ftware product? Important!! Metrics are no good unless they allow you to make decisions ba= sed on those metrics. A lot of metrics are what I call "Hmmmmmmmmmmmmm" me= trics. You gather all those numbers, look at them and say, "Hmmmmmmmmmmm!"= If the metrics program does not lead to valuable decision-making, you ha= ve wasted your time. Hope this is helpful. Richard Riehle, PhD, International Technological University, San Jose, CA