1、 GEIA STANDARD Data Management GEIA-859 AUGUST 2004 GOVERNMENT ELECTRONICS AND INFORMATION TECHNOLOGY ASSOCIATION GEIA-859 A Sector of the Electronic Industries Alliance ANSI/GEIA-859-2004 Approved: August 04, 2004 NOTICE EIA Engineering Standards and Publications are designed to serve the public in
2、terest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards and Public
3、ations shall not in any respect preclude any member or nonmember of GEIA from manufacturing or selling products not conforming to such Standards and Publications, nor shall the existence of such Standards and Publications preclude their voluntary use by those other than GEIA members, whether the sta
4、ndard is to be used either domestically or internationally. Standards and Publications are adopted by GEIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, GEIA does not assume any liability to any patent owner, nor does it assume any obligation what
5、ever to parties adopting the Standard or Publication. This GEIA Standard is considered to have International Standardization implications, but the ISO/IEC activity has not progressed to the point where a valid comparison between the GEIA Standard and the ISO/IEC document can be made. This Standard d
6、oes not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. (F
7、rom Standards Proposal No. 4888, formulated under the cognizance of the G-33 Data and Configuration Management Committee.) Published by 2004 Government Electronics and Information Technology Association Standards they described procedures that were adapted to efficient paper-based management of pape
8、r deliverables. This standard is intended to articulate contemporary DM principles and methods that are broadly applicable to management of electronic and non-electronic data in both the commercial and government sectors. Development of this standard began in August 2000 when the Electronic Industri
9、es Alliances (EIA) G-33 Committee on Data and Configuration Management initiated task PN 4888 to develop a consensus standard for data management. This is the first release of the standard. Contributors to this standard are identified in Annex A. GEIA-859 2 Introduction Scope Data is information (e.
10、g., concepts, thoughts, opinions) that has been recorded in a form that is convenient to move or process. Data can be tables of values of various types (numbers, characters, and so on). Data can also take more complex forms such as engineering drawings and other documents, pictures, maps, sound, and
11、 animation. For the purposes of this standard, commercial and government enterprises concern themselves with three broad types of data. Table 1 lists them, indicates how each is used, and provides examples. Table 1. Types of Data Type Usage Examples Product Collaboration Cost, schedule, and performa
12、nce data Scientific data such as written notes and observation of phenomena Engineering drawings and models, parts catalogs, software applications and their components, operational and maintenance instructions, and training materials Business Collaboration Plans and schedules, financial information,
13、 inventory status, and human resource information Operational Transactional records exchange Orders, issues, receipts, bills of lading, and invoices Data management, from the perspective of this standard, consists of the disciplined processes and systems that plan for, acquire, and provide stewardsh
14、ip for product and product-related business data, consistent with requirements, throughout the product and data life cycles. Thus, this standard primarily addresses product data and the business data intrinsic to collaboration during product acquisition and sustainment. It is recognized, however, th
15、at the principles articulated in this standard also have broader application to business data and operational data generally. It is also recognized that the data addressed by this standard is subject to data administration, metadata management, records management, and other processes applied at the
16、enterprise level, and that these principles must be applied in that enterprise context. Data has many purposes, including stating requirements, providing proof of achievement, establishing a basis for long-term product support, and many others. Deliverable data (customer-accessible information) repr
17、esents only a small fraction of the project data. In general, a vast amount of design, development, fabrication, and manufacturing data remains the intellectual property of the developer/producer. Further, the value of data is not limited to its use in support of a particular product: data may have
18、a life cycle longer than that of the product it describes. For instance, data from previous projects forms part of the foundation for new product and process design. Data also supports the enterprise in GEIA-859 3 process redesign and quality. Thus data is essential to competitive position. An enter
19、prises data if not properly safeguarded can also be misused by a competitor to the competitors advantage. For these reasons, data is an integral part of an enterprises intellectual assets and overall enterprise knowledge. Overview This standard comprises nine fundamental data management principles (
20、Figure 1). Principles are high-level descriptive statements about high-quality DM; they establish what high-quality DM looks like. Each principle has a set of enablers, which provide the mechanisms of DM. Figure 1. Data Management Principles 1. Define the ne enterprise enterpri e relevant scope ant
21、scope of data data management management2. Plan for, acquire, and provide data responsive to 2. an f r, acquire, and pro ide dat responcustomer requirements.customer nts.3. Develop DM processes to fit the context and 3. lop D proces t e ontex and business environment in which they will be performed.
22、bu ne environ nt in w h t ey ill be perf d.4. Identify data products and views so that their dentif dat produc and v hat heir requirements and attributes can be controlled.require and at ibutes c n be ntrolled.5. Control data, repositories, data products, data views, 5. ont l dat repositories uc da
23、ewand metadata using an approved change control and m ada using an appro ed change control process. proc6. Establish and maintain an identification process for 6. tablish and m intain an identification p ocess f r intellectual property, proprietary, and competitivellec ual propert propriet and c pet
24、 -sensitive data.ns e da7. Retain data commensurate with value.7. Retain data co nsurate w th lue.8. Continuously improve data management.ntinuous improve da nage ntFeedbackFeedbac9. Effectively integrate data management and egr da ana and knowledge managementkno e mana ementTwo different viewpoints
25、, corresponding to product and data life cycles, are important to DM. Product data (and related business data) is normally acquired or created as part of the development of a new product or similar initiative. This is the project perspective. Principle 2, which addresses the planning for and acquisi
26、tion of data, and Principle 4, which deals with the identification of products, views, and related data elements, are written primarily from the perspective of the individual project. The remaining principles apply at both the project and enterprise levels. Principle 9 relates DM to knowledge manage
27、ment (KM). The degree to which the DM principles in this standard apply to a product varies over the products life cycle. Similarly, they vary in applicability over the data life cycle. Some principles may not apply during every phase of either life cycle. GEIA-859 4 This standard addresses the func
28、tions of DM but not how to organize for DM. Each enterprise, for valid reasons, locates the functions of DM within enterprise elements that make sense within its own enterprise environment. This standard is not intended for use as a compliance document or an evaluation mechanism for DM projects. It
29、is intended for use as a source and reference document for either purpose. Appropriate application of the functions and principles in this standard enables the user to plan and implement a DM program for a product, project, or enterprise. Terminology During creation of this standard, significant eff
30、ort went into using neutral terms wherever possible. Neutral terms used in this standard are provided in the glossary (Annex B). There is no intent to express preference for any particular terminology set. When planning and documenting a DM program, other aliases may be substituted for the neutral t
31、erminology. Three particular sets of terms deserve special mention. The first of these is the pair of terms “program” and “project.” In practice, the term “program” is often used to represent an undertaking that is larger in scope than a “project,” but such is not universally the case. This standard
32、 consistently uses the term “project.” Second, this standard introduces some new neutral terminology used here in the context of DM for the first time. Where the terms are introduced for the first time, they are explained in context. The most important of these are probably the terms “data view,” “d
33、ata view description,” and “bill of data” (also called a bill of information). Data normally has and will be a byproduct or the result of engineering, management, and other work efforts. Historically, before the widespread availability of electronic databases, a data product generally resulted from
34、locating, assembling, and presenting existing information in the format that a customer had specified. Because the technical work had to be done anyway, and its results recorded anyway, the cost of data of a data product was in locating, assembling, and presenting it. Given the effort and cost invol
35、ved, it made sense to describe the result as a product. Over time, there was an increasing recognition that the imposition of customer-specified formats often increases cost without creating equivalent value, prompting a move to utilize supplier formats whenever possible. More recently, manual effor
36、t is being replaced by electronic extraction from an existing database, and the cost of retrieving, packaging, and even “personalizing” the data is much smaller. Further, what gets captured is a snapshot of data as seen from a particular perspective, at a particular point in time. Products become vi
37、ews of the data in the repository. A “data view,” a generalization of the concept of a data product, includes the visual presentation of data by technologies such as digital images, geographical GEIA-859 5 information systems, graphical user interfaces, multidimensional tables and graphs, virtual re
38、ality, three-dimensional presentations, and animation.*The “data view description” provides the agreed-to content, preparation assumptions, intended use information, and (where applicable) format for a data view. The data product format can be specified in a data item description (DID), in an extens
39、ible markup language (XML) style sheet, or by other means. The list of data views to be provided in accordance with a contract is a bill of data, an example of which is a contract data requirements list (CDRL). A bill of data is a two-way concept: a supplier may need data from the buyer in order to
40、perform under a contract. Further, in an integrated trading partner environment, both trading partners may obtain views of data, as provided for in a bill of data, from a single data repository. Finally, references to terms such as the “enterprise,” “organization,” “performing activity,” “developing
41、 activity,” or “producing activity” refer to the enterprise that is responsible for performing DM. It could be a commercial entity or a government agency. References to the customer should be interpreted as the activity that specifies requirements. A customer may be external to the developing and pr
42、oducing enterprise; may be an internal customer such as marketing, management, or the using department; or may even be a supplier in a conventional sense. References ANSI/EIA Standard 649, Configuration Management. EIA Standard 836, Configuration Management Data Interchange and Interoperability. Soc
43、iety of Aerospace Engineers Standard AS9034, Process Standard for the Storage, Retrieval, and Use of Three Dimensional Type Design Data. *The term “data product” is ubiquitous, and the concept of a “data view” is entering the data management vocabulary. At the risk of some ambiguity, this standard r
44、etains the term “data product” until the concept of a “data view” becomes more widely accepted. However, data product is used in a generalized sense. GEIA-859 6 GEIA-859 7 1.0 Principle: Define the Enterprise Relevant Scope of Data Management Different enterprises come to different conclusions regar
45、ding the scope of DM. Traditionally, DM has been thought of as including five functions (see Table 1-1). Table 1-1. Common Functions of Traditional Data Management Function Tasks Identification and definition Develop and maintain standard data requirement descriptions Review life cycle of project or
46、 program to determine needs Identify data requirements Ensure completeness and eliminate duplication Provide support to program and enterprise management Acquisition and preparation Prepare internal data, as identified and prescribed above Ensure that supplier data requirements are negotiated and or
47、dered Ensure that externally developed data meet requirements for internal use Control Implement controls for import and export of data Implement controls for safeguarding intellectual property Implement controls for configuration management Implement prescribed forms/formats/screens for authorizati
48、on and use requests Prepare and maintain master inventory lists Ensure the appropriate marking of data (e.g., for proprietary data rights, classification, and records management) Maintain the current and historical metadata about data status and disposition (approval/disapproval, etc.) Document cont
49、rol processes Disposition Establish and document records, custodians, and project-unique records management requirements Establish a plan for use of a document repository, whether physical or online Publish and make documents available Archiving Create physical or digital files with appropriate archived information Create project files for decision-tracking histories Submit archival packages to higher and more general archiving facilities (internal or external) that specialize in data retention Note: The functions in this table are distilled from GEIA data management panel experience
