Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
28Activity
0 of .
Results for:
No results containing your search query
P. 1
Measures and Metrics in Process and Project Domains

Measures and Metrics in Process and Project Domains

Ratings: (0)|Views: 2,048 |Likes:
Published by api-3852528
SEMESTER V
SEMESTER V

More info:

Published by: api-3852528 on Oct 19, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/18/2014

pdf

text

original

Department of Information Technology
IF355 - SQM
ACADEMIC YEAR
:
2005 \u2013 2006
SEMESTER / YEAR
:
V / III
DEPARTMENT
:
INFORMATION TECHNOLOGY
COURSE NAME
:
SOFTWARE QUALITY MANAGEMENT
COURSE CODE
:
IF 355
UNIT - 5
Measures and Metrics in Process and Project Domains
Contents:
\u2022Metrics for Software Quality
\u2022Integrating metrics within Software Engineering
Process
\u2022Metrics for Small Organizations
1
Department of Information Technology
IF355 - SQM
\ue000 Measurements in the physical world can be categorized in two
ways:
\ue001 Direct measures (e.g., the length of a bolt)
\ue001 Indirect measures (e.g., the \u201c quality\u201d of bolts produced, measured by
counting rejects).
o
Software metrics can be categorized into:
\ue001 Direct measures of the software engineering process include cost and
effort applied.
\ue001Direct measures of the product include lines of code (LOC) produced,
execution speed,
\ue001 Memory size and defects reported over some set period of time.

Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintain ability, and many other \u201c \u2014 abilities\u201d

o
Advance establishments:
\ue000 The cost and effort required building software, the number of lines of

code produced, and other direct measures are relatively easy to collect, as long as specific conventions for measurement are established in advance.

\ue000 However, the quality and functionality of software or its efficiency or
maintainability are more difficult to assess and can be measured only
indirectly.
\ue000We have already partitioned the software metrics domain into process,

project, and product metrics. We have also noted that product metrics that are private to an individual are often combined to develop project metrics that are public to a software team.

\ue000Project metrics are then consolidated to create process metrics that

are public to the software organization as a whole. But how does an organization combine metrics that come from different individuals or projects?

2
Department of Information Technology
IF355 - SQM
\ue000 To illustrate, we consider a simple example. Individuals on two
different project teams record and categorize all errors that they find
during the software process.
\ue000 Mdi-vidual measures are then combined to develop team measures.
Team a found 342 errors during the software process prior to release.
Team B found 184 errors.
\ue000 All other things being equal, which team is more effective in
uncovering errors throughout the process? Because we do not know
the size or complexity of the projects, we cannot answer this question.
\ue000 However, if the measures are normalized, it is possible to create
software metrics that enable comparison to broader organizational
averages.
o
Size-Oriented Metrics:
\ue000 Size-oriented software metrics are derived by normalizing quality
and/or productivity measures by considering the size of the software
that has been produced.
\ue000 If a software organization maintains simple records, a table of size-
oriented measures, such as the one shown in Figure, can be created.
\ue000 The table lists each software development project that has been
completed over the past few years and corresponding measures for
that project.
\ue000 Referring to the table entry (Figure 4.4) for project alpha: 12,100 lines

of code were developed with 24 person-months of effort at a cost of $168,000. It should be noted that the effort and cost recorded in the table represent all software engineering activities (analysis, design, code, and test), not just coding.

\ue000 Further information for project alpha indicates that 365 pages of
documentation were developed, 134 errors were recorded before the3

Activity (28)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Deepakshi Rawat liked this
Christina John liked this
Jerome Beh liked this
Christina John liked this
Dooshima Mhambe liked this
Muthu Pandi liked this
Praveen Kanwar liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->