Home
About Us
Products
Process Models
SE Resources
Commentary
Contact us
|
|
|
Breaking News!
A new blog ... visit OnCenter, Roger Pressman's running commentary on the world at large
A new edition ... the 6th edition of Software Engineering is available now
A first novel ... Roger Pressman's first novel is a technothriller -- The Aymara Bridge
A new training curriculum! RSP&A has partnered with QAI to develop a comprehensive Internet-based software engineering curriculum.
A redesigned Web site ... we've done a major redesign and added many new features
|
|
|
|
|
|
|
|
|
|
|
Reference Library
Process and Project Metrics
|
|
This page provides access to a variety of downloadable papers that
address process and project metrics issues. The following topics are considered:
Management
Process Metrics
SPC Metrics Program
A System for Measuring Function Points [PDF]
Evelina Lamma, Paolo Mello and Fabrizio Riguzzi
This paper presents a system for measuring the Function Point software
metric from specifications expressed in the form of an Entity Relationship (ER)
diagram and a Data Flow Diagram (DFD). As a first step towards the implementation
of the system, the informal Function Point counting rules have been translated into
rigorous rules expressing properties of the ERDFD. Prolog was chosen for the
implementation because of its declarativity and maintainability. Thanks to its
relational representation, it was possible to directly represent the input ER-DFD
with Prolog facts.
Software Measurement Process - Part #1 - An Introduction [PDF]
Peter Baxter
This article introduces ISO/IEC 15939 software measurement process. Measurement-
related actions are listed. The four measurement activities: establish capability,
plan measurement, perform the measurement process, and evaluate measurement are
illustrated.
Software Metrics [PDF]
Everald E. Mills
This paper discusses commonly used software metrics. This paper also reviews
the metrics by constructing models of the software development process.
Software Metrics and Risk [PDF]
Norman Fenton and Martin Neil
Most software metrics activities are carried out for the purposes of risk
analysis of some form or another. Yet traditional metrics approaches, such as
regression-based models for cost estimation and defects prediction, provide little
support for managers wishing to use measurement to analyze and minimize risk.
Significant improvements can be achieved by using causal models that require no
new metrics. The new approach, using Bayesian nets, provides true decision-support
and risk analysis potential.
Software Metrics Capability Evaluation Guide [DOC]
Faye Budlong and Judi Peterson
This guide covers the following: it defines a metrics capability evaluation
method that deals specifically with defining a customer's metrics capability, it
presents metrics capability questionnaires that help gather metrics capability data,
it outlines a metrics capability evaluation report that provides the basis for
developing a metrics customer project plan, it provides a metrics customer profile
form used to determine the initial information required to prepare for a metrics
capability evaluation, and it provides a customer organization information form
that helps guide the STSC in gathering cultural information about the organization
that will help with developing and implementing the metrics customer project plan.
Back to the top
A Metrics - Based Study of Software Evolution - Some Results from FEAST/1 [PDF]
M.M. Lehman and J.F. Ramil
This slide presentation on the Feedback Evolution, and Software Technology
(FEAST/1) includes the following topics: the FEAST hypothesis, FEAST results,
metrics of software evolution-some desired features, implications for the control
of software evolution, and metrics in software evolution management.
Beyond the Personal Software Process: Metrics Collection and Analysis for the Differently Disciplined [PDF]
Philip M. Johnson, Hongbing Kou, Joy Agustin, Christopher Chan, Carleton Moore, Jitender Miglani, Shenyan Zhen and William E.J. Doane
Pedagogies such as the Personal Software Process (PSP) shift metrics definition,
collection, and analysis from the organizational level to the individual level. The
authors research suggests that this "PSP adoption problem" may be due to two
problems: the high overhead of PSP-style metrics collection and analysis, and the
requirement that PSP users "context switch" between product development and process
recording. This paper overviews the authors initial PSP experiences, their first
attempt to solve the PSP adoption problem with the LEAP system, and their current
approach called Hackystat.
On Building an Effective Measurement System for OO Software Process, Product and Resource Tracking [PDF]
Sita Ramakrishnan, Tim Menzies, M. Hasslinger, P. Bok, H. Mccarthy, B. Devakadadcham and D. Moulder
This paper reports on an ongoing object oriented software measurement experiment
which has been set up to monitor and evaluate team-based projects building OO
software. The process, called the Software Assessment Through Ongoing Profile
Sheets (SATOPS) which relies on manual form entries for recording measurement data
in a project management framework is being automated using JAVA. The automated
tracking of software process and resource activities will improve the metrics
data collection and analysis phase.
Process - Oriented Metrics for Software Architecture Adaptability [PDF]
Lawrence Chung and Nary Subramanian
This paper proposes a framework, POMSAA (Process- Oriented Metrics for Software
Architecture Adaptability), which aims to provide numeric scores representing the
adaptability of a software architecture as well as the intuitions behind these scores.
In this framework, the intuitions behind the architectural adaptability scores are
traced back to the "whys" of the architecture, namely, the requirements for which
the architecture exists in the first place. POMSAA achieves the needed tracing by
adopting the NFR Framework, which is a process-oriented qualitative framework for
representing and reasoning about non-functional requirements (NFRs). In this paper
the authors show how POMSAA can be used to calculate adaptability metrics for an
architecture of a software system, how it helps detect weaknesses and strategic
strengths in the architecture, how it helps to understand the reasons for the
weaknesses/strengths and how to make improvements (that will help improve the
metrics), and how to recalculate the metrics for the new architecture fast and
intuitively.
Software Process Improvement: Management Commitment, Measures, and Motivation [PDF]
J.W.E. Greene
This paper on the software process improvement (SPI) begins with an introduction
about SPI. Other topics include: measures for process improvement, background to the
measures, management measures, the software control office, the development control
office, the purchasing control office, meeting the key process areas, U.S. control
office experience, and measures and motivation.
Using Process Metrics to Enhance Software Fault Prediction Models [PDF]
Greg Kaszycki
This paper discusses EMERALD which is a software risk assessment tool developed
to be used internally at Nortel Networks, but is now commercially available. Process
data significance levels were measured to determine the accuracy of the model.
Back to the top
Creating a Metrics Program
Software Productivity Center Inc.
The Software Productivity Center's 8-step metrics program. All 8 steps and other
links can be found on the
Software Productivity Center's Metrics Page.
Creating a Metrics Program
Step 1: Document the Software Process [PDF]
Software Productivity Center Inc.
A software development process is simply the procedures that are followed to
transform specified requirements into a software product. The objective of this
step is to document these procedures so they can be applied consistently across
projects. Procedures for documenting the process, actions required for step 1, and
an example are given.
Creating a Metrics Program
Step 2: State the Goals [PDF]
Software Productivity Center Inc.
Step 2 is to state the goals of the metrics program. The goals will ultimately
determine which data to measure. A table that lists some of the goals that commonly
drive metrics programs, actions required for step 2, and an example are given.
Creating a Metrics Program
Step 3: Define Metrics Required to Reach Goals [PDF]
Software Productivity Center Inc.
Step 3 is to choose which software metrics will help achieve the goals of the
metric program. This section analyzes each of the eight goals outlined in Step 2.
The goals will be converted into a set of metrics by applying the Basili GQM
(Goals/Questions/Metrics) model. Actions required for step 3, and an example are
given.
Creating a Metrics Program
Step 4: Identify Data to Collect [PDF]
Software Productivity Center Inc.
Step 4 is to identify the data that needs to be collected for each metric
selected in the preceding step. In this step, each of the metrics is expanded
into a set of raw data to collect. Actions required for step 4, and an example are
given.
Creating a Metrics Program
Step 5: Define Data Collection Procedures [PDF]
Software Productivity Center Inc.
Step 5 is to decide where to find the raw data identified in Step 4, and how to
collect it. Actions required for step 5 are given.
Creating a Metrics Program
Step 6: Assemble a Metrics Toolset [PDF]
Software Productivity Center Inc.
Step 6 is to identify and configure tools which are necessary to support the
metrics program. Each tool is described and an example is given. Actions required
for step 6, and an example are given.
Creating a Metrics Program
Step 7: Create a Metrics Database [PDF]
Software Productivity Center Inc.
Step 7 is to define and create the metrics database for the storage and
retrieval of the software measurement data. Actions required for step 7 are given.
Creating a Metrics Program
Step 8: Define the Feedback Mechanism [PDF]
Software Productivity Center Inc.
Step 8 is to outline the procedures necessary to enable good internal
communication about the metrics data, the program goals, and the changes to the
development process. Actions required for step 8, and an example are given.
Back to the top
| |