A03_PPML_PWS_Final.docx

GlossaryDraft - Source Selection Sensitive

GlossaryDraft - Source Selection Sensitive

DRAFT

Performance Work Statement (PWS) for the

Procurement Process Model Library (PPML)

June 28, 2017 Attachment 01

January 26, 2017 Incorporating Change 3, June 16, 2017

Table of Contents

PPML PERFORMANCE WORK STATEMENT

1.0. INTRODUCTION. The Defense Procurement and Acquisition Policy Directorate’s Program Development and Implementation Office requires the development of a PPML to facilitate the reuse of procurement business process models that DoD components already own. The need is to avoid the expense of developing new models that duplicate the functional capabilities of existing models.

2.0. BACKGROUND

2.1. The Defense Procurement and Acquisition Policy Directorate released a document entitled “Strategic Plan for Defense Wide Procurement Capabilities (A Functional Strategy),” Version 2.0, on September 25, 2014. This functional strategy lays the ground work for enhancements in electronic systems in support of procurement functions called for in Section 862 of the National Defense Authorizations Act for Fiscal Year 2013. The strategy states that:

“…DoD is pursuing a mixed technology solution enabling the use of commercial applications where such applications fully meet specific business needs, combined with government developed capabilities built with commercial tools to meet the documented DoD and component unique requirements to ensure interoperability and end to end process integrity within the department.”

2.2. Pursuant to this strategy, the DoD procurement enterprise objectives for the PPML are to (a) Minimize the costs of providing a capability to reuse process models (e.g., capital costs, labor costs) compared to the acquisition of new process models that duplicate existing models; (b) Maximize the reuse of process models developed at government expense to which the government has unlimited rights; and (c) Encourage the improvement of existing process models.

3.0. SCOPE

3.1. The Contractor shall provide the personnel, management and materials necessary to produce a PPML software application that can support all procurement activities in the DoD Procurement Enterprise, which includes contracting activities in the Uniformed Services (Army, Navy and Marine Corps, and Air Force) and all DoD Agencies and Activities (the DoD 4th Estate).

3.2. The PPML system will be a web-service application within an enterprise procurement hosting environment. It will provide an open source platform for contracting officers and systems developers to register procurement business process models that they have developed and used. In turn, this collection of procurement process models will be made available to subscribers of the PPML free of charge.

3.3. The elements, or artifacts, of process models will be included, such as documentation, test plans, images, data files and executable modules. Any proprietary artifact that can be run directly by a computer’s hardware with no further processing will not be registered. However, non-executable representations of proprietary artifacts, such as images or text, can be registered.

3.4. Enterprise-wide licenses will be issued to subscribers of the PPML. It is envisioned that a libre license approach will be used. With a libre license, the owner of the rights to a resource grants subscribers the freedom to read it, to learn from or with it; to copy, adapt and use it for any purpose; and to share derived works for the benefit of the community.[footnoteRef:1] [1: For examples of libre licenses, see http://www.gnu.org/licenses/licenses.html accessed July 11, 2017.

3.5. The place of performance will be the contractor’s facilities. The period of performance will be 12 months from the date of award for the base year and each of the option years.

3.6. Exclusive of any rights asserted by commercial licenses, the Government will have unlimited rights in the technical data and software developed under the contract, pursuant to DFARS 252.227-7022, Government Rights (Unlimited).

4.0 OBJECTIVES.

4.1. The DoD procurement enterprise objectives for the PPML are to:

· Minimize the costs of providing a capability to reuse process models (e.g., capital costs, labor costs) compared to the acquisition of new process models that duplicate existing models.

· Maximize the reuse of process models developed at government expense to which the government has unlimited rights.

· Encourage the improvement of existing process models.

· Identify DoD-class best practices models

4.2. The objectives for the PPML are to provide subscribers with the capability to:

· View a large selection of proven process models.

· Easily search for, find, and download the process models they want.

· Personalize their searches for process models.

· Efficiently register their process models using metadata tagging.

· Access process models that they could not ordinarily find or afford.

· Obtain the process models they wish to use (e.g., via unrestricted licenses).

· Register or obtain process models more conveniently by allowing them to register, discover and download:

· Anytime (i.e., 24 hours a day and 7 days a week).

· Anywhere that the subscribers have access to the Internet (e.g., at home, at work, and while traveling).

· Minimize risks associated with registering and downloading over the Internet.

5.0 GOALS AND CONSTRAINTS

5.1. Artifacts will be validated prior to their registration against standards established by a governance board.

5.2. Artifacts will be relevant to appropriate Procure-to-Pay (P2P) Level 1 and 2 objects documented in the DoD Business Enterprise Architecture (BEA).

5.3. Key properties of artifacts will be visible and can be edited and altered in implementation.

5.4. Data from business process management tools can be exported in Business Process Model Notation (BPMN) format.

5.5. The initial release of the system will be deployed in a government specified computer environment accessible as a web service to registered subscribers.

6.0. REQUIREMENTS. The contractor shall develop the PPML to achieve the functional requirements at Enclosure 1, the software requirements specifications at Enclosure 2 and shall:

6.1. Plan, analyze, design, develop, test, produce, document, maintain configuration control, establish and maintain network security, and launch a PPML software application using open-source software, which may be supplemented with contractor-developed software in the event available open-source software cannot meet all the system requirements. The Government will have unlimited rights to any contractor-developed software funded under the contract.

6.2. Design the PPML in iterative stages and conduct formal design reviews at the completion of each stage as specified in this paragraph. The design descriptions from these stages shall be reported in accordance with the Contract Data Requirement List (CDRL) at Attachment aa of the contract:

6.3. Provide documentation of the design as specified in this paragraph and deliver the design documentation in accordance with the CDRL at Attachment aa of the contract:

6.4. Provide support for the planning, design and conduct of systems and operational tests to verify the effectiveness of the application design to meet the system requirements. Develop test plans, data, scripts, and tools that exercise the application at the user and system integration levels. Version and maintain all test artifacts in order to perform repeatable and reliable testing. Create test data in all testing environments. Test software code in the development environment to validate the software code functionality, identify potential software defects, and confirm code behavior. Test reports shall be provided in accordance with the CDRL at Attachment aa of the contract:

6.5. Support initial data conversion required to upload a designated initial collection of process models into the PPML. Prepare a Data Conversion Guidance Document that provides procedures for process model owners to upload their process models.

6.6. Provide support for the launch and operation of the application in the DoD procurement enterprise computing environment, including web-based training, on-line help support, troubleshooting support and software corrective changes (fixing bugs). Provide for on-going software maintenance to include adapting to new requirements, perfecting or improving existing functions and enhancing applications with (minor) new functions or features. Provide software user’s manuals.

6.7. Provide monthly performance reports to the government program manager detailing recent accomplishments, issue status, current risks, schedule status, and budget/cost status in a format established post-award by the Government. These reports will be subject to modifications based on need and program growth/requirements.

6.8. Table 1 contains a requirements summary.

Table 1. PPML PWS Requirements Summary

7.0. OPTION

The Government may elect to exercise an optional contract line item number for the contractor to develop, test and establish PPML interfaces with existing external systems specifically identified by the Government. The purpose of these interfaces is to enable the PPML to access process models from multiple systems’ model repositories. However, each system will typically use a different metadata structure to annotate process models and different technologies for storing them. This makes it difficult to retrieve and reuse process models from external repositories. The interface will function as an interoperability layer that implements the appropriate mechanisms and a uniform interface for accessing multiple heterogeneous data sources.

8.0. DELIVERABLES

Table 2. Deliverables

9.0. GOVERNMENT FURNISHED INFORMATION. The Government will furnish a designated collection of process models in varying formats for purposes of initial data conversion and software and database testing concurrent with contract award. Government property will not be furnished.

10.0 QUALITY ASSURANCE. The Contractor shall:

9.1. Perform work that conforms to the scope of project and meets the requirements under this PWS. Performing inspections; identify, correct and prevent problems/defective software; address customer complaints, and improve the quality of software over the life of the contract.

9.2 The Government reserves the right to perform inspections and surveillance to evaluate the Contractor’s compliance to the contract terms and performance of the requirements in the PWS. The Government will make every effort to ensure that the surveillance methods described below are conducted in an objective, fair, and consistent manner.

9.3. Contract Discrepancy Report (CDR). In the event of unsatisfactory contractor performance, the Contracting Officer’s Representative or Contracting Officer will issue a CDR that will explain the circumstances and findings concerning the incomplete or unsatisfactory service. The contractor shall acknowledge receipt of the CDR and respond in writing as to how he/she shall correct the unacceptable performance and avoid a recurrence. The Government will review the contractor's corrective action response to determine acceptability and will use any completed CDR as part of an overall evaluation of Contractor performance when determining present or future contractual actions.

11.0. ORGANIZATIONAL CONFLICTS OF INTEREST.

The Contractor shall acknowledge that it is familiar with Federal Acquisition Regulation (FAR) Subpart 9.5, Organizational and Consultant Conflicts of Interest, and agree to avoid, neutralize or mitigate such conflicts of interest in accordance with the principles set forth in the FAR. If the performance requires the Contractor (to include subcontractors) to supply technical support related to systems or projects with which the Contractor is already directly concerned, either by prime or subcontract, the Contractor shall immediately inform the Contracting Officer. The PWS may be withdrawn if a conflict is found. The Contractor shall not undertake performance of any PWS requirements which requires it to supply technical support regarding such systems until the notice is given, and written consent to proceed is issued by the Contracting Officer.

ENCLOSURE 1. PPML FUNCTIONAL REQUIREMENTS

1.0. PPML Process Model Requirements

a. The PPML will describe reusable process models by the attributes of granularity, variability, and articulation.

(1) Granularity describes how many problems or solution alternatives a process model addresses. The simplest models only offer a singular solution to a single well defined problem. As the granularity increases the model addresses multiple problems, and/or may offer alternative solutions to those problems.

(2) Variability and visibility are key properties of process models. A model can be invariable, which means it cannot be altered. These models are called black-box models, since their internals cannot be seen and are not modifiable. A white-box models is created with the expectation that model consumers will edit and alter its implementation. White-box models also typically include development artifacts such as requirements, models, and build files. There are two other variations, clear-box models and gray-box models.

(a) Clear-box models expose implementation details, such as models, code fragments, or other documentation, but they cannot be modified. These details are exposed solely to help the consumer better understand the inner workings of the model, so that the consumer can use the model more efficiently.

(b) Gray-box models expose and allow modification only to a subset of the model’s artifacts, usually through the parameters on the model.

(3) Articulation describes the degree of completeness of the artifacts in providing the solution. Models whose artifacts specify and implement a solution along with supporting documents such as requirements, use cases, testing artifacts, and so on, have more articulation.[footnoteRef:2] [2: See Object Management Group (OMG) Reusable Asset Specification (RAS), November 2005, page 8.]

b. The PPML will describe reusable process models by their types of packaging. A process model package is a collection of artifact files plus relevant extensible markup language (XML) schemas. A process model may employ any of the following packaging scenarios:

(1) Packaged bundled as an archive file.

(2) Packaged unbundled.

(3) Artifacts may remain in their place of origin.

(4) Artifacts may be moved to another location when “packaged.”[footnoteRef:3] [3: Ibid, page 8.]

c. In the PPML, a model will be designated as a record. A record will contain one or more datasets. A dataset will contain descriptive data elements. This taxonomy scheme is based on the World-Wide Web Consortium (W3C) Data Catalog Vocabulary (DCAT), as depicted in Figure 1.[footnoteRef:4] [4: See http://www.w3.org/TR/2014/REC-vocab-dcat-20140116/ accessed May 11, 2016.]

Figure 1. PPML Metadata Structure

d. The metadata[footnoteRef:5] for a PPML process model will be specified using the W3C DCAT taxonomy scheme, as shown in Figure 2. The data elements are defined in the Glossary. [5: Data about data is metadata. Data about metadata is meta-metadata, or metamodel. Data about metamodel is meta-metamodel.]

(1) Metadata will be provided by the subscriber who is registering the process model, or it may be extracted automatically from a process model’s artifacts when adding a process model to the library. Typically, each process model has a name and a textual description. The origin of a process model represents the organization that contributed the process; an author and a date of the model’s creation are stored for reference purpose.

(2) Process models need to be characterized by means of a comprehensive classification. This classification will be the P2P Level 1 and 2 objects documented in the DoD BEA. The classification of a process model will be extendable to subscribers’ desires, where applicable.

Figure 2. PPML Taxonomy Scheme

2.0. System Architecture

a. The PPML will utilize an architecture such as that illustrated in Figure 3, which was developed by Eid-Sabbagh, et. al.[footnoteRef:6]. This architecture comprises a presentation layer, a functional layer, and a database layer. All functionality will be provided through a Web subscriber interface. [6: Rami-Habib Eid-Sabbagh, Matthias Kunze, and Mathias Weske, “An Open Process Model Library”, Hasso Plattner Institute at the University of Potsdam.]

Figure 3. Conceptual Architecture of the PPML

b. Model management will provide features for stored process models, e.g., inspecting a model, adding, updating, or removing it, uploading representations to a process model, and downloading a collection of process models including their representations.

c. The search engine will provide all features that are required to capture data for indexing and provide a search subscriber interface and has access to all data stored in the process library.

d. Authorization will hold subscriber authentication credentials, subscriber ephemeral data, and subscriber authorizations in the form of granted roles.

3.0. The PPML Actors

Actors are people and interfacing systems that interface with the PPML System. PPML has the actors shown in Table 2. Figure 4 shows the PPML actor model.

Table 3. PPML Actors

Figure 4. PPML Actor Model

4.0. PPML System Business Rules

The following business rules define the interaction between subscribers and external interfacing systems and the PPML System.

a. Classification Taxonomy. Upon registration, owners of the process models will classify them by the P2P Level 1 and 2 objects documented in the DoD BEA.

b. Structured Representation Formats. Any process model that contributors can provide will be accepted. Any structured representation formats, e.g., xpdl, pnml, epml, bpmn, xml, and unstructured information, e.g., txt, ppt, pdf, xls that can describe a process model, such as text documents, bitmap pictures of process models, and diagrams drawn in Power Point or Visio, will be permitted.

c. Data Standards. Process model owners identify the data standards used in the process models upon their registration. This identification is included as a data element in the metadata for the dataset(s) contained within the model.

d. Proprietary Rights. The artifacts of process models are included in the model registration, such as documentation, test plans, images, data files and executable modules. Any proprietary artifact that can be run directly by a computer’s hardware with no further processing is not registered. However, non-executable representations of proprietary artifacts, such as images or text, can be registered.

e. Licensing. Enterprise-wide licenses are issued to subscribers of the PPML. A libre license approach is used. With a libre license, the owner of the rights to a resource grants subscribers the freedom to read it, to learn from or with it; to copy, adapt and use it for any purpose; and to share derived works for the benefit of the community.

f. Metadata Management. Metadata will be provided to describe a model. This comprises the metadata taxonomy scheme shown in Figure 2.

g. Subscriber Interfaces. Intuitive subscriber interfaces will be provided that guide subscribers of the library and provide contributors the capability to easily add a new process model to the library, upload their representations, and quickly fill in metadata.

h. Data Entry. The process model and its metadata elements are entered through a web input screen, comma-separated values file import, or an XML transaction.

i. Search Queries. Text-based indexing and search for process inscriptions will be provided.

j. Access Control. Access control will provide registration and specific rights for reading and writing, groups, and communities. Subscribers will have access to library services to search within the library, download a process model, create a new process model, and update an existing one.

k. System Administration. An administrator will be responsible for maintaining the system, controlling access, adding new subscribers, and assisting with any subscriber problems.

5.0 Process Model Management Use Cases

Process model management use cases define interaction by subscribers and the system to keep the data up to date and correct. These interactions are depicted in the diagram in Figure 5 and described in Table 3.

Figure 5. Process Model Management Use Case Diagram

Table 4. Process Model Management Use Cases

6.0. System Administration Use Cases

The system administration use cases shown in Table 4 describe interactions necessary to maintain the system and its subscribers, including setting up system properties, and maintaining subscribers.

Table 5. PPML System Administrator Use Cases

7.0. Queries and Reports

a. There will be multiple types of online queries either standalone or available as part of a customized report generation utility. The ability to run a query will be determined by the subscriber’s access.

(1) A subscriber will have the capability to send any query result to a printer.

(2) A subscriber will have the capability to send any query result to a file.

(3) When query results are sent to the printer or to a file, the date the query was run will be displayed on the printout and in the file.

b. The subscriber will be able to query all registered process models for any element of the metadata taxonomy scheme shown in Figure 2.

8.0. Metrics and Subscriber Feedback

a. Metrics for assessing the volume and efficiency of online transactions will be established using the appropriate data elements for electronic collections found in Section 7.7 of ANSI/NISO Z39.7-2013.[footnoteRef:7] [7: American Standards Institute(ANSI)/National Information Standards Organization (NISO) Z39.7-2013, “Information Services and Use: Metrics and Statistics for Libraries and Information Providers – Data Dictionary.]

b. A mechanism will be established for obtaining online feedback from subscribers on the usefulness of models downloaded from the library.

PPML Functional Requirements

ENCLOSURE 1

ENCLOSURE 2. PPML SOFTWARE REQUIREMENTS SPECIFICATIONS

1.0. Process Model Management Use Cases

Process model management use cases define interaction by users and the system to keep the data up to date and correct. These interactions shall be as depicted in in Table 5.

Use Case Name Brief Description

Table 6. Process Model Management Use Case Descriptions

1.1. Use Case: Manage Subscribers

Brief Description

The purpose of this use case is to capture the data required to identify and authenticate the credentials of a subscriber.

a. Subscribers will be required to register for a specific role. There are two basic roles, process owner and non-process owner.

b. Subscribers will have an authority-to-edit, security assurance, or read-only credentials.

c. Subscriber credentials will only be visible to the individual subscriber holding the credential, the System Administrator and the Librarian.

d. Contractors require the validation of a cognizant procuring contracting officer (PCO) or contracting officer’s representative (COR) as a prerequisite for registration.

e. Subscribers will be issued a license which defines their credentials and the terms and conditions for use of the process models registered in the PPML.

The use case begins when a prospective subscriber requests access to the PPML.

Flow of Events

Basic Flow

Alternate Flow – Cancel Registration

This flow alters step 3 of the basic flow

Special Requirements There are no special requirements.

Preconditions The prospective subscriber must be a government employee or a contractor employee affiliated by a government contract.

Post-Conditions

Post Condition 1: System adds new Subscriber Data Record

This occurs on success of the basic flow. A new “subscriber” is entered into the database with a single history record and no corrections.

Post Condition 2: Cancelled

This occurs on all Alternate Flow – Cancel Submission. The system shall not save a new record into the database.

1.2. Use Case: Create Initial Process Model Data

Brief Description The purpose of this use case is to capture the data for a single process model and store the “draft” record into the system database. A “draft” record shall be validated before it is released to the data base (see Submit a Process Model Use Case).

While in “draft” mode, a process model shall not be visible to other users, nor shall it be included in reports. It shall be only visible to the owners of the draft process model, until it has been formally submitted into the system.

The use case shall begin when a process model owner requests to add a new process model. The user shall enter the process model data in data capture screens and save the record.

Flow of Events

Basic Flow

Alternate Flow – Cancel Submission

This flow alters step 3 of the basic flow

Preconditions The process model owner must be an Authority-to-Edit actor.

Post-Conditions

Post Condition 1: System adds new Process Model Data Record

This occurs on success of the basic flow. A new “draft” process model is entered into the database with a single history record and no corrections.

Post Condition 2: Cancelled

This occurs on all Alternate Flow – Cancel Submission. The system shall not save a new record into the database.

1.3. Use Case: Submit Process Model

The purpose of this use case is to formally submit the process model data record into the system. The effect of submission is that a unique process model is created, and the process model is visible to others and shall appear in reports.

This use case works against a “draft” record already in the system. Using the given record, the process owner and the librarian validate the record against the business rules, and makes the record visible to reports and other users.

Flow of Events

Basic Flow

Alternate Flow – Validation Errors

This flow alters step 2 of the basic flow.

The system returns to the Create Initial Process Model Data use case for correction.

Preconditions The process owner and the librarian must be an Authority-to-Edit actor.

Post-Conditions

Post Condition 1: System adds new Process Model

This occurs on success of the basic flow. A new process model is entered into the database with a single history record and no corrections. It has a new and unique process model name. The process model name cannot be used again for other programs. An audit record is saved, capturing the user that performed the addition, the time at which it took place, and the data that was saved. For the Authority-to-Edit process owner, the new process model shall use the process model owner’s organization for the responsible organization.

Post Condition 2: Nothing happens

This occurs on all Alternate Flow – Validation Errors. The system shall not create a new process model. The use case returns to the “Create Initial Process Model Data” use case.

1.4. Use Case: Add Process Model Update Record

The goal of this use case is to capture a change to a process model as recorded by the process model owner. This is in contrast to a correction, where the process model data maintained is inaccurate.

A process model update record captures the appearance of process model for a point in time. One cannot add historical records prior to the last point in time record. Only the current point-in-time record may be modified.

Flow of Events

Basic Flow

Alternate Flow – Validation Errors

This flow alters step 4 of the basic flow.

The use case returns to step 3 of the basic flow.

Alternate Flow – Cancel Submission

This flow alters step 3 or 5 of the basic flow.

Preconditions The user must be an Authority-to-Edit actor associated with the process model’s current Responsible Organization, or the Authority-to-Edit actor serving as the librarian.

Post-Conditions

Post Condition 1: System adds a new point in time record.

This occurs on success of the basic flow. The system adds a new point-in-time snapshot to the database, and adds an audit record showing the user making the change, the date and time of the change, and the values captured in the change.

Post Condition 2: Update Cancelled

This occurs on alternate flow cancel submission. The system shall add an audit record showing the person cancelling the submission, and the date/time of the occurrence.

Extension Points

Extension Point: Add Historical Update

This occurs on step 2 of the basic flow. Instead of bringing up the current point-in-time process model data, the user may choose a specific point-in-time record to edit.

1.5. Use Case: Correct an Inaccurate Process Model Data Record

The goal of this use case is to correct the current process model record. The subscriber shall find a model record, request to correct the record, make corrections to the record data, and save the corrections.

A point-in-time record may be corrected no more than N days after the record was last edited in the system (added or corrected).

Flow of Events

Basic Flow

Alternate Flow – Validation Errors

This flow alters step 4 of the basic flow.

The use case returns to step 3 of the basic flow.

Alternate Flow – Cancel Submission

This flow alters step 3 of the basic flow.

Preconditions The subscriber must be an Authority-to-Edit actor associated with the process model’s current Responsible Organization, or an Authority-to-Edit actor associated with the librarian. The point-in-time record must be within 30 days (a system configurable period) of its last edit (add, update, or correction).

Post-Conditions

Post Condition 1: System replaces point-in-time record with correction.

This occurs on success of the basic flow. The system replaces the current point-in-time snapshot with the new, updated snapshot. The system shall keep a link from the new corrected snapshot with the older, obsolete version. The system adds an audit record showing the subscriber making the change, the date and time of the change, and the values captured in the change.

Post Condition 2: Update Cancelled

This occurs on alternate flow cancel submission. The system shall add an audit record showing the person cancelling the submission, and the date/time of the occurrence.

Extension Point: Correct Historical Record

This occurs on step 2 of the basic flow. Instead of bringing up the current point-in-time process model data, the subscriber may choose a specific point-in-time record to correct.

1.6. Use Case: Retire Process Model

The process model owner may retire a model when the owner does not intend to maintain the model for further use. A model may be retired if the process it reflects becomes obsolete and the owner has no need to continue using the model by creating a newer version of it.

Flow of Events

Basic Flow

Alternate Flow – Cancel Submission

This flow alters step 3 of the basic flow.

Preconditions The subscriber must be an Authority-to-Edit actor associated with the process model’s current Responsible Organization, or an Authority-to-Edit actor associated with the librarian.

Post-Conditions

Post Condition 1: System replaces point-in-time record with correction.

This occurs on success of the basic flow. The system adds a new point-in-time record with values indicating retirement.

Post Condition 2: Update Cancelled

This occurs on alternate flow cancel submission. The system shall add an audit record showing the person cancelling the submission, and the date/time of the occurrence.

There are no extension points.

Query and Report Use Cases

The query and report use cases shown in Table 6 describe interactions to find process models and to summarize accumulated process model data.

Table 7. Query and Report Use Cases

1.7. System Administration Use Cases

The system administration use cases shown in Figure 6 and Table 7 describe interactions necessary to maintain the system and its subscribers, including setting up system properties, and maintaining subscribers.

Figure 6. Systems Administration Use Case Diagram

Table 8. System Administration Use Cases

1.8. Queries and Reports

a. There shall be multiple types of online queries either standalone or available as part of a customized report generation utility. The ability to run a query shall be determined by the subscriber’s access.

(1) A subscriber shall have the capability to send any query result to a printer.

(2) A subscriber shall have the capability to send any query result to a file.

(3) When query results are sent to the printer or to a file, the date the query was run shall be displayed on the printout and in the file.

b. Metrics shall be established and reported to the Librarian for assessing the volume and efficiency of online transactions using the appropriate data elements for electronic collections found in Section 7.7 of ANSI/NISO Z39.7-2013.[footnoteRef:8] [8: American Standards Institute(ANSI)/National Information Standards Organization (NISO) Z39.7-2013, “Information Services and Use: Metrics and Statistics for Libraries and Information Providers – Data Dictionary.]

c. A mechanism shall be established for obtaining online feedback from subscribers on the usefulness of models downloaded from the library.

2.0. Entry of Process Models and Metadata

The process model and its metadata elements shall be entered through a web input screen, comma-separated values file import, or an XML transaction. Table 8 shows the specifications governing each data element:

Meta-Metamodel (describes Library)

Values:

Full Title = (PROCUREMENT) PROCESS LIBRARY (PPML) SYSTEM Short Title = PPML SYSTEM

Values:

The 5-character CAGE Code, 6-character Defense Activity Address Code (DoDAAC) or 9-digit Dunn and Bradstreet Universal Number System (DUNS) Number of the entity

Meta-Metadata (metamodel)(describes records in the Library)

Values:

· CREATE PURCHASE REQUISITION

· DEVELOP PROCUREMENT STRATEGY

· AWARD PROCUREMENT INSTRUMENT

· ADMINISTER PROCUREMENT INSTRUMENT

· PERFORM RECEIPT, ACCEPTANCE AND RETURN

· MANAGE PROCUREMENT ENTITLEMENT

· MANAGE DISBURSEMENTS

· PERFORM PROCUREMENT INSTRUMENT CLOSEOUT

Values:

· CURRENT

· PROPOSED

· SUPERCEDED

Metadata (describes data elements in the dataset)

Values:

The 5-character CAGE Code, 6-character DoDAAC or 9-digit DUNS Number of the entity

Values:

· CREATE PURCHASE REQUISITION

· DEVELOP PROCUREMENT STRATEGY

· AWARD PROCUREMENT INSTRUMENT

· ADMINISTER PROCUREMENT INSTRUMENT

· PERFORM RECEIPT, ACCEPTANCE AND RETURN

· MANAGE PROCUREMENT ENTITLEMENT

· MANAGE DISBURSEMENTS

· PERFORM PROCUREMENT INSTRUMENT CLOSEOUT

Values:

· CURRENT

· PROPOSED

· SUPERCEDED