Glossary

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.

User Acceptance Testing

The phase of a procedure or process where users get to test out
new capabilities prior to release to production. This phase is crucial to Extremely Available Computing practices. Without it, there is no certification that the delivered product matches the business need.

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.

Nexbridge Inc.

One thought on “Glossary”

Leave a Reply Cancel reply

Bringing DevOps to Legacy Platforms