| Term |
Definition |
| Agency Architecture |
Any portion of the Enterprise Architecture that is developed, used, and maintained solely by an individual agency within USDA. |
| Architectural Artifacts |
The relevant documentation, models, diagrams, depictions, and analyses, including a baseline repository and standards and security profiles. |
| Artifact |
An abstract representation of some aspect of an existing or to-be-built system, component, or view. Examples of individual artifacts are a graphical model, structured model, tabular data, and structured or unstructured narrative. Individual artifacts may be aggregated. |
| Common Enterprise Architecture |
Any portion of the Enterprise Architecture developed collaboratively or shared by two or more agencies within USDA. |
| Current Architecture |
The current, or "As-Is" state of an enterprise's architecture; consists of two major elements - business and design architectures. The design architectures include Data, Applications, and Technology architectures. |
| Enterprise Architecture |
A strategic information asset base, which defines the business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to the changing business needs. It is a representation or blueprint. |
| Federal Architecture |
In reality this is the combination of all Departmental architectures of the Federal government. For the purpose of this document it refers to the portions (down to service components or data sets) of the Federal architecture that are developed in common or shared by the Department of Agriculture and one or more other Departments. Entire architectures such as the Federal Health Architecture and the National Wildland Fire Architecture may also be shared. |
| Federal Enterprise Architecture Framework (FEAF) |
An organizing mechanism for managing development, maintenance, and facilitated decision making of a Federal Enterprise Architecture. The Framework provides a structure for organizing Federal resources and for describing and managing Federal Enterprise Architecture activities. |
| Federal Enterprise Architecture Reference Models |
Set of classification schemes that can be used to group artifacts within the Federal, Departmental, and Agency architectures in a consistent manner across the federal government. |
| Standards |
A component of the architecture framework. Standards are a set of criteria (some of which may be mandatory), guidelines, models, and best practices. Standards are approved by industry, federal, and USDA wide bodies. Examples include:
- Security standards
- Technology standards (software, hardware, etc.)
- Data standards
- Standard processes
- Standard application packages
- System development standards (including naming conventions)
|
| Target Architecture |
The target, or "To-Be" state of an enterprise's architecture; consists of the Business, Data, Applications, and Technology architectures. However, the target architecture represents future capabilities and technologies that result from design enhancements to support the evolving business needs of the Department. |
Return to Top
 Configuration Management Addendum
What is Configuration Management (CM)?
CM is a management control activity that
- provides visibility and control of a system's performance, functional,
and physical attributes;
- verifies that a product performs as intended, and is identified and documented
in sufficient detail to support its projected life cycle.
CM Facilitates
orderly management of product information and product changes for such beneficial purposes as to,
- revise capability;
- improve performance, reliability, or maintainability;
- extend life;
- reduce cost;
- reduce risk and liability;
- or correct defects.
CM Functions
- Configuration Management Planning
- Configuration Identification
- Configuration Control
- Configuration Status Accounting
- Configuration Auditing
Return to Top
Configuration Management Planning Function
Plan Configuration Identification
- Determine criteria for identifying configuration items and identifying baselines.
- Determine when configuration items and baselines should be identified.
- Determine who shall perform configuration identification.
- Determine the steps, techniques, and tools for performing configuration identification.
Plan Configuration Control
- Determine the composition and responsibilities of the configuration control board.
- Determine the criteria for placing a configuration item under configuration control.
- Determine the contents of a change request form.
- Determine the criteria for deciding who shall evaluate the impact of a proposed change.
- Determine the criteria for deciding who shall evaluate the implementation
of an authorized change.
- Determine the steps, techniques, and tools for performing configuration control.
Plan Configuration Status Reporting
- Determine when (or how often) configuration statuses shall be reported.
- Determine who shall report configuration status.
- Determine to whom configuration status shall be reported.
- Determine the steps, techniques, and tools for performing configuration status reporting.
Plan Configuration Auditing
- Determine the criteria for performing configuration audits.
- Determine who shall perform the configuration audits.
- Determine what shall be verified during a configuration audit.
- Determine what shall be reported as a result of a configuration audit.
- Determine who shall receive the configuration audit reports.
- Determine the steps, techniques, and tools for performing configuration auditing.
Return to Top
CM Management
Planning Activities
- Define environment.
- Select tools, techniques and methods suitable for the environment.
- Plan implementation.
- Integrate CM within Enterprise defined processes.
- Prepare procedures.
- Perform training.
- Measure performance.
Return to Top
Configuration Identification (CID) Function
The CM Function that reviews processes and products to validate compliance with requirements, and to verify that products have achieved their required attributes and conform to released product definition information.
CID Activities
- Define product structure and select sub-elements to be managed.
- Assigning unique identifiers to configuration documentation, HW and SW
products.
- Select configuration document types & formats.
- Define product attributes, interfaces, details in configuration documentation.
- Conduct review and coordination of configuration documentation and if required,
obtain customer review and approval.
- Establish release process; release configuration documentation, authorizing
use.
- Assign serial and lot numbers, as necessary to differentiate individual
units and groups of units, respectively.
- Ensure marking or labeling of products and documentation with applicable identifiers enabling correlation between the product, configuration documentation and associated data.
- Establishing and maintaining CM library
- Supporting engineering data analysis
- Providing engineering data packages
- Baselining configuration documentation when approved
Return to Top
Configuration Control (CC) Function
The CM function which ensures that changes to a baseline are properly identified, documented, evaluated for impact, approved by an appropriate level of authority, incorporated into product, verified and released
CC Activities
- Identify need for change or variance.
- Document each request for change or variance and assign identifiers.
- Evaluate each change and variance, coordinating with affected areas of
responsibility.
- Classify each request and establish effectiveness.
- Disposition each request, obtaining required approvals.
- Plan change implementation.
- Implement change and verify reestablished consistency of product, documentation,
operation and maintenance information, services and training.
Return to Top
Configuration Status Accounting (CSA) Function
The CM function of creating and organizing the knowledge base necessary for the performance of configuration management
CSA Activities
Capture and report information about:
- Product configuration status;
- Configuration documentation;
- Current baselines;
- Historic baselines;
- Change requests;
- Change proposals;
- Change notices;
- Variances;
- Warranty data/history;
- Replacements by maintenance action;
- Configuration verification and audit status/action item closeout.
Return to Top
Configuration Audit (CA) Function
The CM function verifying that a product has achieved consistency and accuracy of its product requirements, and product configuration information
Two types of audits
- Functional Configuration Audit
- Physical Configuration Audit
Functional Configuration Audit (FAC)
- A formal audit to validate that the CI
- Has been completed satisfactorily;
- Has achieved the performance and functional characteristics specified in
the Requirements and Design documentation;
- Operation and support documents are complete.
Physical Configuration Audit (PCA)
A technical examination of a designated CI to verify that the CI "As-Built" conforms to the technical documentation which defines the CI
CA Activities
- Verify product within normal course of process flow.
- Assure consistency of release information and production/modification information.
- Conduct formal audit when required.
- Review performance requirements, test plans, results, other evidence to
determine product performs as specified, warranted & advertised;
- Perform physical inspection of product and design information; assure
accuracy, consistency & conformance with acceptable practice;
- Record discrepancies; review to close out or determine action; record
action items;
- Track action items to closure via status accounting;
System Engineering
An interdisciplinary approach that encompasses the entire technical effort, and evolves into and verifies an integrated and life cycle balanced set of system people, products, and process solutions that satisfy customer needs.
System
An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.
Product
Anything that is used or produced to satisfy a need, for example:
- facilities, systems, hardware, software, firmware, data, processes, materials,
or services.
Baseline
An agreed to description of the attributes of a product, at a point in time, which serves as a basis for defining change.
Types of Baseline
- Requirements Baseline
- Design Release Baseline
- Product Configuration Baseline
- Additional Operation and Disposal Phase Baselines
Change
Any alteration to a product or its released configuration documentation.
Effecting a change may involve modification of the product, product information
and associated interfacing products.
Product Life Cycle
A generic term relating to the entire period of conception, definition, build,
distribution, operation and disposal of a product.
Product Life Cycle
- Apply identification rules to document representations and files.
- Use business rules based on data status for change management and archiving
of data.
- Maintain data-product relationships.
- Apply disciplined version control.
- Assure accurate data transmittal.
- Provide controlled access.
Return to Top
Process Models
Generic Change Control Process 1 (WORD
31.5K)
Change Identification Process Model (WORD
36.5K)
Change Evaluation and Coordination Process Model
(WORD
37K)
Change Implementation and Verification
Process Model (WORD 43K)
Generic Change Control Process 2 (WORD 29K)
Process Steps
- Change Initiation
- Change Logging and Distribution
- Change Evaluation
- Merit Decision
- CCB Scheduled
- CCB Members and Stakeholders Prepare for CCB
- CCB Conducted
- Change Determination
- CMS Distributes Work Directive
- Change Implementation
- Change Verification
- Approve Release
- Release to Production and Update CM Baseline
Return to Top
http://www.ocio.usda.gov/e-arch/glossary/glossary.html
Last Modified:
12/15/2005
|
|
 |
 |
 |
 |
|
Program |
|
|
|
Enterprise Architecture
Glossary/Addendum |
|
 |
 |
|
|
