|
|
|
||||||||||
|
|
|
|
|
|
|
|
+ NASA Home
+ IVV Home
|
|
|
|
|
|
|
 |
|
|
|
|
GLOSSARY AND DEFINITIONS
Activity - The activity data indicates
what high level task was occurring at the time a defect was discovered (e.g.
"Testing"). This data is usually available at the time a defect record is
opened.
History Date - Date in which history event occurred
or was recorded.
Change Control Board - Change Control Board (CCB)
information indicates the date of and notes for CCB meetings. The CCB makes
decisions related to the implementation of changes.
Code Review - The code review flag indicates
whether or not a code review was conducted as a result of a defect. The value
is either 'Y' indicating that a code review had occurred or 'N' indicating that
a code review had not occurred.
Class - A template from which objects can be
created.
Close Reason - The general reason for the
closure of the error report. For instance: fixed, duplicate, obsolete or
reject.
Cost - Relative cost for the fix (i.e., high, medium,
low)
CSCI - Term applied to the design level incorporating
products that often having similar functions or capabilities. The term CSCI can
be synonymous with sub-system but the definition may vary from project to
project.
CSC - Computer Software Component. CSCIs are comprised
of logical groups of CSCs. This design element generally is comprised of files,
which make up an executable.
Defect Close - This field identifies when a
defect record was closed in a project's defect tracking system.
Defect Data - The MDP repository contains defect
data, which is the data, contained within a error report. Error reports
describe the changes made to software due to a problem in the software. Defect
data is also referred to as error data or problem data in MDP.
Defect History - Defect history refers to
the attributes of a defect that represent the dynamic qualities of a defect
record throughout its life cycle. The defect history can be used to identify a
defect's state changes (open,close,etc.) as well as other information gathered
about a defect during these states. Defect history attributes typically have
associations to dates.
Defect Open - This field identifies when a
defect record was originally added to a project's defect tracking system.
Sometimes synonymous with New and Submitted. Defect State Change - A defect record can go though a variety of different states throughout its life cycle. These state change behaviors can vary from project to project. Typical Defect States
Defect Status - Defect status indicates the
state of a defect record at the time it was stored in the data repository. In
most cases the value will be 'C' indicating that a defect was closed for one
reason or another.
Defect Type - The defect type classifies a
defect. In most cases a defect type will be something like "sw-bug" or
"Software Bug". Defect type data is usually available in the latter portion of
a defect's life cycle (Resolution through Close).
Deferred on - The date the
error report was deferred. However, the date is not so important as it is an
indicator that a deferral occurred.
Design Level - Design levels
indicate a product's role in the product hierarchy. Design level can vary from
project to project based upon a project's definition of each level in the
product hierarchy. CSCI is one example of a design level.
Design Review - The design
review flag indicates whether or not a design review was conducted as a result
of a defect. The value is either 'Y' indicating that a design review had
occurred or 'N' indicating that a design review had not occurred.
Est-Fix-Hours - The number of
man hours it took to implement the fix. The quality of this data varies by
project.
Est-SLOC-Count - The number
of SLOC involved in the fix. This can include changed SLOC or new SLOC.
Fix-Hours - The actual number of
man hours the fix took to implement.
How Found - The phase in which,
the error was found. For instance: Inspection, Test, Operations, etc.
IV&V - An acronym for Independent
Verification & Validation.
Language - Language refers to the
programming language used to generate the source code.
LOC - An acronym for Lines Of
Code.
Metrics - Metrics are measurements
of software attributes. For example, Total Lines of Code is a measurement of
the number of lines of code (executable statements, comments and blank lines)
for a given module.
Mode - The mode the system was
operating in. For instance, Development, Operations, Test
Module - Term applied to the lowest level
functional unit from which metrics can be generated. In most cases this refers
to code specific items such as functions but the real world implementation can
vary between projects and programming languages (e.g. functions, modules,
subroutines).
ODC - Orthogonal Defect Classification
Priority - This value quantifies the necessity
for this defect to be resolved where 1 has the highest priority (critical) to 3
for lowest priority. For example, priority 1 generally means that there is a
critical need for the resolution of a defect where priority 3 generally means
that the development or maintenance can delay the change.
Problem-Type - Specific reason for closure of
error report.
Product - A product is an entity to which defect
data and metrics data can be associated. In most cases products will be
synonymous with code related items such as functions and systems/sub-systems.
Product Hierarchy - A product hierarchy is
the relationship between different design levels of products. Product
hierarchies may differ between projects and programming languages as the levels
at which different levels of products are defined differently for different
projects and different programming languages. An example of a product hierarchy
would be the relationship exhibited by a C++ class owning different functions
where the class would be defined as a higher design level than the functions. Project - The Metrics Data Program gathers and generates its repository data on a per-project basis. Each project in the database consists of product data, product metrics data and the associated error data. A project as it exists in the repository may represent either an entire set of data from a real world project or a subset of such data. Current the projects in the MDP database are as follows:
Requirement - A statement of the required
functionality of a software component.
Requirements/Products Relationship Report - This
report lists product ids and any requirement ids that the products are
associated to.
Severity - This value quantifies the impact of a
defect on functionality with 1 being most severe to 5 being least severe. For
example, severity 1 generally means that a defect caused an loss of
functionality without a workaround where severity 5 generally means that the
impact is superficial and did not cause any major disruptions to functionality.
SLOC-Count - The actual number of SLOC changed
or added.
Static Defect Data - The term static defect
data applies to defect attributes that do not have associations to specific
dates in the repository.
Target Products - Target products are
products that may have caused a defect or have been changed as a result of a
defect. The MDP repository uses the target product data to make a direct
association between a defect record and modules. Target product data is
typically available in the latter portion of a defect's life cycle (Resolution
through Close). Metric value descriptions:
|
