|
Nexbridge Glossary Page
This section provides a list of our glossary and dictionary of terms.
- Advocates
- People and capabilities within companies are often misunderstood.
Advocates promote understanding and effective communication.
- Allocated Baseline
- The initial, approved specifications governing the development of
configuration items that are part of a higher level configuration item. Each
specification defines the functional characteristics that are allocated from
those of the higher level configuration item, establishes the tests required
to demonstrate achievement of its allocated functional characteristics,
delineates necessary interface requirements with other associated
configuration items, and establishes design constraints, if any [IEEE1993b].
- Allocated Configuration
Identification
- The approved allocated baseline plus approved changes.
- Auditing
- An element of configuration management that consists of independent
examinations of work products and activities to assess compliance with
designated criteria. For example, see configuration
audit and software baseline audit.
- Back-Sourcing
- The reacquisition of business functions from an external company. This is
commonly done to regain specific aspects of control over how the
back-sourced business functions operate.
- Baseline
-
- A specification or product that has been formally reviewed and agreed
upon, thereafter serves as the basis for further development, and can be
changed only through formal change control procedures [IEEE1993b].
- A document or a set of such documents formally designated and fixed at
a specific time during the lifecycle of a configuration item [IEEE1993b].
- Block Change Concept
- Once a product baseline is established, the accumulation and simultaneous
implementation of a number of routine software changes to minimize the
number of interim versions and related documentation [MIL973].
- Build
- An operational version of a system or component that incorporates a
specified subset of the capabilities that the final product will provide [IEEE1993b].
- Change
- The process of evolution of ideas, practices, processes, and systems.
Without change, there would be little point to computers.
- Change Control
- The process and procedures to identify, document, review, and authorize
any changes to the software under configuration management [ISO1991a].
See also configuration control.
- Change History
- A description of how and why a revision of an item differs from its
predecessors.
- CMM Level 1 [SEI1993a]
- At CMM Level 1, the software process is an amorphous entity – a black
box – and visibility into the project's processes is limited. Since the
staging of activities is poorly defined, managers have an extremely
difficult time establishing the status of the project's progress and
activities. Requirements flow into the software process in an uncontrolled
manner, and a product results. Software development is frequently viewed as
black magic, especially by managers who are unfamiliar with software.
- CMM Level 2 [SEI1993a]
- At CMM Level 2, the customer requirements and work products are
controlled, and basic project management practices have been established.
These management controls allow visibility into the project on defined
occasions. The process of building the software can be viewed as a
succession of black boxes that allows management visibility at transition
points as activity flows between project milestones. Even though management
may not know the details of what is happening in the box, the products of
the process and checkpoints for confirming that the process is working are
identified and known. Management reacts to problems as they occur.
The key process areas at Level 2 focus on the software project's concerns
related to establishing basic project management controls. The key process
areas for CMM Level 2 are:
- CMM Level 3 [SEI1993a]
- At CMM Level 3, the internal structure of the project's defined software
process is visible. The internal structure represents the way the
organization's standard software process has been applied to specific
projects. Both managers and engineers understand their roles and
responsibilities within the process and how their activities interact at the
appropriate level of detail. Management proactively prepares for risks that
may arise. Individuals external to the project can obtain accurate and rapid
status updates because defined processes afford great visibility into
project activities.
The key process areas at Level 3 address both project and organizational
issues, as the organization establishes an infrastructure that
institutionalizes effective software engineering and management processes
across all projects. The key process areas for Level 3 are:
- CMM Level 4 [SEI1993a]
- At CMM Level 4, the defined software processes are instrumented and
controlled quantitatively. Managers are able to measure progress and
problems. They have an objective, quantitative basis for making decisions.
Their ability to predict outcomes grows steadily more precise as the
variability in the process grows smaller.
The key process areas at Level 4 focus on establishing a quantitative
understanding of both the software process and the software work products
being built. The key process areas at this level are:
- CMM Level 5 [SEI1993a]
- At CMM Level 5, new and improved ways of building the software are
continually tried, in a controlled manner, to improve productivity and
quality. Disciplined change is a way of life as inefficient or defect-prone
activities are identified and replaced or revised. Insight extends beyond
existing processes and into the effects of potential changes to processes.
Managers are able to estimate and then track quantitatively the impact and
effectiveness of change.
The key process areas at Level 5 cover the issues that both the
organization and the projects must address to implement continuous and
measurable software process improvement. The key process areas for Level 5
are:
- Coercion
- The worst form of team behavior, coercion involves the convincing of
participants to take action using active or passive threats. Pointing out
that executing a task in a specific way is going to reflect in a performance
review is a very common coercion tactic.
- Coexistence
- Once a team moves out of a purely confrontational posture, admission of
others' value starts the team down the path of coexistence. Coexistence
means that the team members get along with each other, and respect each
other's values and opinions. Teams in this mode can get stuck into a
non-productive posture by viewing themselves as purely a social club.
- Collaboration
- Collaborative behavior begins when team members work actively with each
other to solve or perform their tasks. There is a key recognition at this
point that skills to perform a given task may require more than one person.
- Computer Program Configuration Item (CPCI)
- A configuration item for computer software. (This term is deemed
obsolete [IEEE1993b].)
- Computer Software Configuration Item (CSCI)
- A configuration item for computer software [DOD2167a].
- Configuration
- The functional and physical characteristics of hardware or software as set
forth in technical documentation or achieved in a product [IEEE1993b].
- Configuration Audit
- See functional configuration audit and physical
configuration audit.
- Configuration Control
- An element of configuration management that consists of the systematic
proposal, justification, evaluation, coordination, approval or disapproval
of proposed changes, and the implementation of approved changes in the
configuration of a configuration item (CI) after the configuration
baseline(s) has been established for the CI [MIL973].
See also change control.
- Configuration Identification
-
- An element of configuration management that consists of selecting the
configuration items for a system and recording their functional and
physical characteristics in technical documentation [IEEE1993b].
- The current approved technical documentation for a configuration item
as set forth in specifications, drawings, associated lists, and
documents referenced therein [IEEE1993b].
- Configuration Item (CI)
-
- An aggregation of hardware or software or both that is designated for
configuration management and treated as a single entity in the
configuration management process [IEEE1993b].
- A work product that is placed under configuration management and
treated as a single entity [Paulk1993a].
- Configuration Management (CM)
- A discipline that applies technical and administrative direction and
surveillance over the lifecycle of items to:
- Identify and document the functional and physical characteristics of
configuration items.
- Control changes to configuration items and their related
documentation.
- Record and report information needed to manage configuration items
effectively, including the status of proposed changes and implementation
status of approved changes.
- Audit configuration items to verify conformance to specifications,
drawings, interface control documents, and other contractual
requirements [MIL973].
The four key elements of configuration management are:
- Configuration identification.
- Configuration control.
- Configuration status accounting.
- Auditing.
- Configuration
Management Library System
- The tools and procedures to access the software baseline library [Paulk1993a].
- Configuration Status
Accounting
- An element of configuration management that consists of the recording and
reporting of information needed to manage a configuration effectively. This
information includes a listing of the approved configuration identification,
the status of proposed changes to the configuration, and the implementation
status of approved changes [IEEE1993b].
- Confrontation
- In virtually all environments there is confrontation. It becomes
unmanageable when the conflict seems to be the sole outcome of the team
interactions. Confrontation, in some organization can be useful in
energizing people to actively participate. However, like wine, too much can
be very detrimental.
- Co-operation
- Co-operative teams are ones where members are actually working with each
other in a supportive capacity. This must be built on a sound foundation of
coexistence otherwise the co-operation will be transient. People know whom
to turn to for advice. Tasks are typically assigned to and performed by
distinct team members.
- Co-ownership
- Teams take on co-ownership characteristics when members realize that all
tasks belong to the team and that their individual roles are in support of
the team. Team members actively take on responsibility and accountability
for not only their tasks, but for the team itself.
- Data Configuration Management
- The discipline of managing the data control permitting your transaction
data to operate and be presented. This can include data such as, but not
limited to: charts of accounts; project codes; part numbers; and corporate
division identifiers.
- Defect Prevention - CMM Level 5 [SEI1993a]
- The purpose of Defect Prevention is to identify the causes of defects and
prevent them from recurring. The software project analyzes defects,
identifies their causes, and changes its defined software process, as is
described in Integrated Software Management. Process changes of general
value are transitioned to other software projects, as is described in
Process Change Management.
- Deltas
- A technique to store versions by storing only the differences between
versions as opposed to storing each version in its entirety. Forward deltas
store the oldest version in its entirety and later versions as deltas.
Reverse deltas store the most recent version in its entirety and previous
versions as deltas.
- Development
- A group or groups of technology specialists involved in the creation of
products and/or services. These groups can be both internal to an
organization and external vendors and suppliers.
- Developmental Configuration
- The software code and associated documentation that define the evolving
configuration of a computer software configuration item between the
allocated baseline and the product baseline.
- Developmental
Configuration Management
- The application of technical and administrative direction to designate and
control the developmental configuration. Developmental configuration
management is under the developing organization's control [Paulk1993a].
- Digital Nervous System
- A collection of technology and infrastructure allowing information to flow
freely and immediately throughout a corporation[Gates1999a].
- Dynamic Library
- A library used to hold newly created or modified software entities. This
library is controlled by the programmer [IEEE1993a].
- Engineering Change
- An alteration in the configuration of a configuration item or other
designated item after formal establishment of its configuration
identification [IEEE1993b].
- Engineering Change Proposal (ECP)
- A proposed engineering change and the documentation by which the change is
described and suggested [IEEE1993b].
- Enterprise Resource Planning (ERP)
- Typically refers to the integration of all aspects of business functions
within a company. This usually starts with financial and cost accounting,
then extends to the integration of all functions.
- Environment Configuration Management
- The discipline of managing how software and hardware are configured and
operated through the use of parameters, physical and logical structure, and
connections.
- Expectation
- The results users are expecting or depending on from the products and
services they use. These can be created through many factors including
business need, market forces, government regulation.
- Functional Baseline
- The initial, approved technical documentation for a configuration item. It
prescribes all necessary functional characteristics, the tests required to
demonstrate achievement of specified functional characteristics, the
necessary interface characteristics with associated configuration items, the
configuration item's key functional characteristics and its key lower level
configuration items, if any, and design constraints [IEEE1993b].
- Functional Configuration Audit (FCA)
- An audit conducted to verify that the development of a configuration item
has been completed satisfactorily, that the item has achieved the
performance and functional characteristics specified in the functional and
allocated configuration identification, and that its operational and support
documents are complete and satisfactory [IEEE1993b].
- Functional
Configuration Identification
- The approved functional baseline plus approved changes.
- Integrated Software Management
- CMM Level 3 [SEI1993a]
- The purpose of Integrated Software Management is to integrate the software
engineering and management activities into a coherent, defined software
process that is tailored from the organization's standard software process
and related process assets, which are described in Organization Process
Definition. This tailoring is based on the business environment and
technical needs of the project, as described in Software Product
Engineering. Integrated Software Management evolves from Software Project
Planning and Software Project Tracking and Oversight at Level 2.
- Intergroup Coordination - CMM Level 3
[SEI1993a]
- The purpose of Intergroup Coordination is to establish a means for the
software engineering group to participate actively with the other
engineering groups so the project is better able to satisfy the customer's
needs effectively and efficiently. Intergroup Coordination is the
interdisciplinary aspect of Integrated Software Management that extends
beyond software engineering; not only should the software process be
integrated, but the software engineering group's interactions with other
groups must be coordinated and controlled.
- Organization Process
Definition - CMM Level 3 [SEI1993a]
- The purpose of Organization Process Definition is to develop and maintain
a usable set of software process assets that improve process performance
across the projects and provide a basis for cumulative, long-term benefits
to the organization. These assets provide a stable foundation that can be
institutionalized via mechanisms such as training, which is described in
Training Program.
- Organization Process Focus - CMM
Level 3 [SEI1993a]
- The purpose of Organization Process Focus is to establish the
organizational responsibility for software process activities that improve
the organization's overall software process capability. The primary result
of the Organization Process Focus activities is a set of software process
assets, which are described in Organization Process Definition. These assets
are used by the software projects, as is described in Integrated Software
Management.
- Out-Sourcing
- The movement of business functions from an internal department to an
external company. This is commonly done so that companies can concentrate on
their core business and take advantage of the economy of scale available to
an external provider servicing many clients.
- Peer Reviews - CMM Level 3 [SEI1993a]
- The purpose of is to remove defects from the software work products early
and efficiently. An important corollary effect is to develop a better
understanding of the software work products and of the defects that can be
prevented. The peer review is an important and effective engineering method
that is called out in Software Product Engineering and that can be
implemented via Fagan-style inspections [Fagan1986a],
structured walkthroughs, or a number of other collegial review methods [Freedman1990a].
- Physical Configuration Audit (PCA)
- An audit conducted to verify that a configuration item, as built, conforms
to the technical documentation that defines it [IEEE1993b].
- Planning
- The process of defining project execution plans to create or deploy
products and/or services.
- Process Change Management - CMM
Level 5 [SEI1993a]
- The purpose of Process Change Management is to continually improve the
software processes used in the organization with the intent of improving
software quality, increasing productivity, and decreasing the cycle time for
product development. Process Change Management takes the incremental
improvements of Defect Prevention and the innovative improvements of
Technology Change Management and makes them available to the entire
organization.
- Processes of the Line™
- The processes that directly impact your front-line operations. These
represent customer interaction points, your public face, or even your
Internet presence. Failures of Processes of the Line™ can have disastrous
effects on your bottom line.
- Product Baseline
- The initial, approved technical documentation defining a configuration
item during the production, operation, maintenance, and logistic support of
its lifecycle. It prescribes all necessary physical characteristics of a
configuration item, the selected functional characteristics designated for
production acceptance testing, and the production acceptance tests [IEEE1993b].
- Product Configuration
Identification
- The approved product baseline plus approved changes.
- Products and Services
- Things we create or use which have value.
- Programmer's Library
- A library used to hold newly created or modified software entities. This
library is controlled by the programmer [IEEE1993a].
- Quantitative Process
Management - CMM Level 4 [SEI1993a]
- The purpose of Quantitative Process Management is to control the process
performance of the software project quantitatively. Software process
performance represents the actual results achieved from following a software
process. The focus is on identifying special causes of variation within a
measurably stable process and correcting, as appropriate, the circumstances
that drove the transient variation to occur. Quantitative Process Management
adds a comprehensive measurement program to the practices of Organization
Process Definition, Integrated
Software Management, Intergroup
Coordination, and Peer Reviews.
- Relationships
- The key gap between developers and users. Relationships are what breaks
down when communication isn't effective or when needs are not communicated
or satisfied.
- Release
- A configuration management action whereby a particular version of software
is made available for a specific purpose [DOD2167a].
- Reluctance
- Hesitation or reluctance sets in when users are rebuffed or are told that
changes cannot be made because the specifications have been locked down.
Developers also become reluctant to have an open dialog with users for fear
of new issues being raised.
- Requirements Management - CMM Level 2
[SEI1993a]
- The purpose of Requirements Management is to establish a common
understanding between the customer and the software project of the
customer's requirements that will be addressed by the software project. This
agreement with the customer is the basis for planning (as described in Software
Project Planning) and managing (as described in Software
Project Tracking and Oversight) the software project. Control of the
relationship with the customer depends on following an effective change
control process (as described in Software
Configuration Management).
- Resentment
- With repeated rebuff, and repeated issues coming up, both developers and
users will inevitably develop resentment. Signs of this are users saying,
"IT just isn't listening to us" and developers saying "Those
users cannot make up their minds."
- Resistance
- Both users and developers become resistant to change after many change
failures. Without adequate preparation, including training, even the best of
systems will be met with resistance for fear that the mistakes of the past
will be made again. Developers become resistant to making changes because of
continual rewrites from wildly divergent specifications.
- Responsiveness
- Responsive behavior is characterized by being able to meet or have met
real needs, and to communicate or understand needs in a timely fashion.
- Results
- Results are the measurable outcome developers. The results of the planning
process are crucial to defining what products and/or services can be
provided. Results not only include actual products and services, but also
include the plans and baselines.
- Revision
- A version that supersedes an earlier version, typically, to correct errors
as opposed to a version that is an alternative version [Whitgift1991a].
See also variant.
- Revolt
- At the end of the road of rigidity is revolt. At this point, users will go
to outside or different sources for their products. They will change
vendors, throw out products, including hardware. It is very easy to get to
this point, very quickly, if the relationship decay is unchecked.
- Rigidity
- Rigidity sets in, as an extension to resistance, when users simply refuse
to take new systems. Developers start using phrases like "The
specification is frozen. We're not accepting any new changes." Another
form of this comes across as apathy. Users will say "Yeah,
whatever" when new systems are planned for deployment.
- Scenario Planning
- Scenario plans are the frame of reference for alerting decision makers
that a change has occurred requiring action or decision.
- SCM Group
- A collection of departments, managers, and individuals who are responsible
for coordinating and implementing software configuration management for a
project [Paulk1993a].
- Service Level Agreements (SLA)
- These are agreements between suppliers and customers, or between operating
units of a company, to provide business services under specific terms.
Whether explicit or implied, SLAs form the basis of all operating aspects of
a company. Failure to deliver on known or unknown SLA commitments cause
chaos within companies.
- Software Baseline Audit
- An audit by the SCM group to verify that a software baseline conforms to
the documentation that defines it [Paulk1993a].
- Software Baseline Library
- The contents of a repository for storing configuration items and the
associated SCM records [Paulk1993a].
- Software Configuration Control Board (SCCB)
- A group responsible for evaluating and approving or disapproving proposed
changes to configuration items and for ensuring implementation of approved
changes [Paulk1993a].
Configuration control boards can be hierarchical.
- Software Configuration Management
- The discipline of managing how software in modified and built through
techniques including source code control, revision control, object build
tracking, and release construction. Configuration management applied to
software systems. SCM involves identifying the configuration of the software
at given points in time, systematically controlling changes to the
configuration, and maintaining the integrity and traceability of the
configuration throughout the software lifecycle [Paulk1993a].
- Software Configuration
Management - CMM Level 2 [SEI1993a]
- The purpose of Software Configuration Management is to establish and
maintain the integrity of the products of the software project throughout
the project's software life cycle. Software Configuration Management is an
integral part of most software engineering and management processes.
- Software Product Engineering -
CMM Level 3 [SEI1993a]
- The purpose of Software Product Engineering is to consistently perform a
well-defined engineering process that integrates all the software
engineering activities to produce correct, consistent software products
effectively and efficiently. Software Product Engineering describes the
technical activities of the project, e.g., requirements analysis, design,
code, and test.
- Software Project Planning - CMM
Level 2 [SEI1993a]
- The purpose of Software Project Planning is to establish reasonable plans
for performing the software engineering and for managing the software
project. These plans are the necessary foundation for managing the software
project (as described in Software Project
Tracking and Oversight). Without realistic plans, effective project
management cannot be implemented.
- Software Project Tracking and
Oversight - CMM Level 2 [SEI1993a]
- The purpose of Software Project Tracking and Oversight is to establish
adequate visibility into actual progress so that management can take
effective actions when the software project's performance deviates
significantly from the software plans.
- Software Quality Assurance - CMM
Level 2 [SEI1993a]
- The purpose of Software Quality Assurance is to provide management with
appropriate visibility into the process being used by the software project
and of the products being built. Software Quality Assurance is an integral
part of most software engineering and management processes.
- Software Quality Management - CMM
Level 4 [SEI1993a]
- The purpose of Software Quality Management is to develop a quantitative
understanding of the quality of the project's software products and achieve
specific quality goals. Software Quality Management applies a comprehensive
measurement program to the software work products described in Software
Product Engineering.
- Software Subcontract
Management - CMM Level 2 [SEI1993a]
- The purpose of Software Subcontract Management is to select qualified
software subcontractors and manage them effectively. It combines the
concerns of Requirements Management, Software
Project Planning, and Software
Project Tracking and Oversight for basic management control, along with
necessary coordination of Software
Quality Assurance and Software
Configuration Management, and applies this control to the subcontractor
as appropriate.
- Specification Change Notice (SCN)
- A document used in configuration management to propose, transmit, and
record changes to a specification [IEEE1993b].
- Subject Matter Experts (SME)
- These are people which specific expertise in a given area. Nexbridge
continually maintains our pool of experts in a variety of industries and
technologies.
- Technology Change Management -
CMM Level 5 [SEI1993a]
- The purpose of Technology Change Management is to identify beneficial new
technologies (i.e., tools, methods, and processes) and transfer them into
the organization in an orderly manner, as is described in Process
Change Management. The focus of Technology Change Management is on
performing innovation efficiently in an ever-changing world.
- Training Program - CMM Level 3 [SEI1993a]
- The purpose of Training Program is to develop the skills and knowledge of
individuals so they can perform their roles effectively and efficiently.
Training is an organizational responsibility, but the software projects
should identify their needed skills and provide the necessary training when
the project's needs are unique.
- Users
- A group or groups of people who depend on products and services they buy,
sell, or use. These groups can range from a traditional sales and marketing
organization within a software products company, to cashiers in remote
divisions of a company, to an international user's group, or even to a
global marketplace.
- Variant
- A version that is an alternative of another version. For example, variants
allow a configuration item to meet conflicting requirements [Whitgift1991a].
Also called variation. See also revision.
- Version
- An instance of a configuration item. Once a version is baselined it cannot
be changed without creating a new version.
- Version Control
- A means to identify and manage configuration items as they change over
time, usually provided by a software tool designed for configuration
management [Ingram1993a].
- Version Description Document (VDD)
- A document that accompanies and identifies a given version of a system or
component. Typical contents include an inventory of system or component
parts, identification of changes incorporated into this version, and
installation and operating information unique to this version [IEEE1993b].
- Watchdogs
- Customers who engage the services of others often do not see the internal
capabilities or constraints under which their suppliers operate. Watchdogs
ensure that the long-term interests of the user community are being served.
- Work Product
- Any artifact from defining, maintaining, or using a software process [Paulk1993a].
- Zero
Latency Enterprise (ZLE)
- Latency refers to the amount of delay between data capture and usefulness
to an organization. Zero latency means that as data is captured, the
enterprise can immediately obtain benefit from that data.
- Zero latency means that as data appears, it is immediately
propagated across your computer systems within the same transaction. In
a zero latent enterprise, the data is present on all relevant systems by
the end of the transaction.
- Positive latency means that it takes time for data to show up
in different systems. This is the result of data collected by an
application, being extracted and used to update other systems in
periodic batches. The time between the initial data capture and the
availability on those other systems is a measure of latency.
- Negative latency means that data is in your system before it
actually has effect to the corporation. In a limited scope ZLE
organization, data is captured but requires a subsequent process to be
executed to take effect. The measure of negative latency is the time
until the data participates in the ZLE. This type of data is crucial to
consider if your front-end systems do not participate in your ZLE.
See also: Digital Nervous System.
- Zero Latency Mesh, Zero Latent Mesh (ZLM)
- The evolving interconnection of companies to supply goods and services in
a timely manner using principles, practices, and processes of the Zero
Latency Enterprise, applied to the Global economy[Becker2001a].
|
