+-----------------------------------------------------------------------+
| > **Department of Energy**                                            |
| >                                                                     |
| > **Electronic Commerce**                                             |
+-----------------------------------------------------------------------+
|                                                                       |
+-----------------------------------------------------------------------+
| > **EC-Web Project Plan**                                             |
|                                                                       |
| **May 1997**                                                          |
|                                                                       |
| **FINAL**                                                             |
|                                                                       |
| **U. S. DEPARTMENT OF ENERGY**                                        |
|                                                                       |
| **Assistant Secretary for Human Resources and Administration**        |
|                                                                       |
| **Office of Procurement Operations**                                  |
|                                                                       |
| **Office of Information Management**                                  |
|                                                                       |
| ![](media/image1.wmf)                                                 |
+-----------------------------------------------------------------------+

Title Page

Document Name: EC-Web

> Project Plan

Publication Date: May 1997

Contract Number: DE-AC01-95AD34277

Project Number: 5004

Prepared by: Jill Schwartz

Kevin Shaver

Approval:

Andy Yocke, HR-43.1

U.S. DEPARTMENT OF ENERGY

Assistant Secretary for Human Resources and Administration

Office of Procurement Operations

Office of Information Management

**TABLE OF CONTENTS**

*[Chapter]{.underline} [Page]{.underline}*

1\. INTRODUCTION 1-1

> 1.1 Current Environment 1-2
>
> 1.2 Previous Activities 1-3
>
> 1.3 Project Goal and Objectives 1-4
>
> 1.4 User Groups 1-7
>
> 1.5 Product Overview 1-8
>
> 1.6 Project Scope 1-10
>
> 1.7 Major Milestones 1-12

2\. PROJECT ORGANIZATION 2-1

> 2.1 Development Model 2-1
>
> 2.2 Project Team 2-5
>
> 2.3 Roles and Responsibilities 2-5
>
> 2.4 Problem Escalation 2-8

3\. MANAGEMENT APPROACH 3-1

> 3.1 Management Priorities 3-1
>
> 3.2 Project Tracking and Control 3-1
>
> 3.2.1 Status Reporting 3-2
>
> 3.2.2 Stage Exits (Project Checkpoints) 3-2
>
> 3.3 Assumptions, Constraints, and Dependencies 3-4
>
> 3.4 Risk Management 3-5
>
> 3.5 Project Estimates 3-7
>
> 3.5.1 Size Estimates 3-7
>
> 3.5.2 Time Estimates 3-7
>
> 3.6 Staffing Plan 3-7
>
> 3.6.1 Required Skills 3-8
>
> 3.6.2 Resource Loading Chart 3-11
>
> 3.7 Master Schedule/Project Deliverables 3-11

4\. TECHNICAL APPROACH 4-1

> 4.1 Programming Languages 4-3
>
> 4.2 Security 4-4
>
> 4.3 Hardware/Software Requirements 4-4
>
> 4.4 Configuration Management 4-4
>
> 4.5 Change Control Process 4-5
>
> 4.6 Testing Strategy 4-5
>
> 4.7 Quality Assurance 4-6
>
> 4.8 Defect Prevention 4-7
>
> 4.9 Training 4-7
>
> 4.10 Documentation 4-7

**1. INTRODUCTION**

The Department of Energy Electronic Commerce Task Force was formed to
assist the Department with achieving the presidential target of January,
1997 to implement Electronic Commerce/Electronic Data Interchange
(EC/EDI) to the maximum extent possible within the small purchase
process. Having successfully met that target date, the EC Task Force is
revisiting the agency\'s long-term strategy for expanding upon EC/EDI
activities throughout the agency. It has been determined that WWW-based
technologies and incorporating an Intranet/Internet approach for
enhancing the existing EC/EDI infrastructure will provide DOE with a
foundation to maximize its current architecture and move forward with
the future. This Project Plan details CDSI\'s approach for assisting DOE
with fulfilling the DOE vision for conducting electronic commerce.

**Foreword**

The purpose of this document is to present Computer Data Systems Inc.\'s
(CDSI) plan for managing the software development of an Electronic
Commerce World Wide Web (EC-Web)-based business system for the
Department of Energy (DOE) Procurement Office of Special Projects and
Management Systems. The intent of this document is to identify
information about the EC-Web project including deliverables, schedules,
risks, dependencies, assumptions, estimates, project teams, and change
management. This plan will:

Provide a general description about the DOE Electronic Commerce system
being developed

Identify schedules and activities to be performed to develop and manage
the product

Identify resources for adequately staffing the EC team

Provide a basis for management and the EC Team to successfully track and
control the project

Establish a common information source with consolidated data referencing
the project

Establish schedule baselines and a detailed work breakdown structure

The EC-Web Project has been divided into three phases:

> ! **Phase I**: System Development Phase, May 1997 - March 1998
>
> ! **Phase II**: System Deployment and Enhancement Phase, April 1998 -
> December 1999
>
> ! **Phase III**: Ongoing Operation and Maintenance Phase, January
> 2000 - ongoing

Phase I encompasses the design, development, integration, testing and
acceptance of EC-Web. Phase II incorporates the installation and
national deployment of the system, the expansion of the vendor outreach
program, the introduction of a system support infrastructure, and system
and EDI enhancements for the infrastructure. Phase III will provide for
the ongoing operation, support, and maintenance required for EC-Web.

This project plan provides details for each stage included in Phase I:
Planning, Preparation, Software Design, Programming and Integration,
System Testing and Acceptance. The EC-Web project plan may require
addenda and adjustments at the conclusion of each stage of development.
Any modifications to this project plan will be documented accordingly in
the Preface section of this project plan. A separate Project Plan will
be written for Phase II and Phase III.

**Background**

Over the past 2-1/2 years, the DOE EC program has progressed from a
pilot program evaluation of EC technologies and procurement systems to
the DOE selection of an EC architecture, infrastructure, procurement
system, and EDI gateway services.

The DOE Electronic Commerce Task Force has analyzed the results of a
one-year pilot program that was conducted at various locations
throughout the agency. By executing a System Evaluation Plan, the EC
Task Force has analyzed various procurement applications to assess the
ability of each application to meet the Department requirements as
defined by a DOEwide standardization task force. The procurement
application that was selected for agency-wide evaluation is the Small
Purchasing System (SPS), which is under development in-house by the
Pittsburgh Energy Technology Center (PETC). The gateway selected to
provide EDI capability to SPS is Government Acquisition Through
Electronic Commerce (GATEC), which was developed by Lawrence Livermore
National Laboratory (LLNL).

**1.1 Current Environment**

The current EC environment comprises four integrated but separate
elements:

! automated procurement system

! financial system

! electronic commerce gateway

! centralized communications hub that allows the gateway to interconnect
to commercial Value-Added-Networks (VANS).

The current DOE EC implementation includes the Pittsburgh Energy
Technology Centers (PETC) Small Purchasing System (SPS) integrated with
the University of California\'s Lawrence Livermore National Laboratory
(LLNL) \"GATEC Lite\" EDI gateway and hub technology, coupled with VAN
Telecommunications contracts and agreements. The current environment
also includes the integration of the Departmental Integrated
Standardized Core Accounting System (DISCAS) via an interactive
interface.

SPS is developed with ORACLE RDBMS utilizing SQL/NET client-server. The
SPS executables are housed on a Windows NT server, and the database
engine is a SCO UNIX implementation with Windows 3.1, 95, and NT
Clients. DISCAS is a departmental accounting system that contains
various levels of financial and budget information. DISCAS is developed
with TurboIMAGE DBMS. DISCAS is running on the Hewlett-Packard MPE/IX
operating system. GATEC hardware is the mechanism that translates SPS
data into ANSI X12 format, and provides the vehicle to transmit
procurement data to DOE\'s trading partners.

Currently, DOE is rolling out the SPS/DISCAS/GATEC implementation to the
five major DOE procurement sites so that each site may begin processing
small purchasing in an automated manner. This project, EC-Web,
introduces the long-term strategy for replacing the present procurement
application with a web-based procurement application for DOE\'s
electronic commerce long-term solution.

**1.2 Previous Activities**

The following list highlights the progression of the DOE EC project to
date:

! Conducted EC pilot programs at various DOE field sites to compare
commercial off-the- shelf (COTs) products

! Conducted DOEwide conference to compare procurement applications with
a system evaluation criteria

! Selected PETC\'s Small Purchasing System, the procurement application
to be deployed throughout DOE.

! Conducted gateway evaluation criteria to select best gateway to
integrate with SPS.

! Selected GATEC for gateway services and hub services

! Formed Purchasing Standardization Task Force to define procurement and
financial requirements and define one DOEwide process for small
purchases.

! Developed strategy to integrate SPS,GATEC, DISCAS, and incorporate
end-user requirements.

! Tested integrated system

! Developed short-term plan for deploying integrated system to selected
DOE field sites.

! Developing long-term plan for deploying Web-based EC system throughout
DOE.

For this past year, the focus of the DOE EC project has been to migrate
the procurement application, SPS, from a VAX/VMS platform to a
client/server environment. The GATEC software that was originally
developed for the Air Force, was modified by LLNL to meet DOE\'s
requirements. The new GATEC gateway software, GATEC-Lite version 1.0,
has been integrated with the client/server version of SPS to create the
DOE EDI-enabled automated procurement environment.

Both of these components were then integrated into the DOE departmental
accounting system for the pilot of an interactive interface between the
financial application and the procurement application.

In addition to establishing one DOE centralized gateway from SPS to
LLNL, the Hub Services offered by LLNL have also been integrated within
the present DOE EC infrastructure to allow DOE to pilot the LLNL Hub
Services such as connections to Gatec Certified Value Added Networks
(VANS), DOE Vendor Registration processes, transaction archival and
transaction routing capabilities.

To address the functional requirements of SPS, the Purchasing
Standardization Task Force (PSTF) Committee, comprising representatives
throughout DOE, was formed to standardize the automated procurement
environment by identifying end-user requirements and by defining one
standardized process flow for the procurement process.

To address the functional requirements for the financial process,
another committee was formed comprising financial representatives
throughout DOE to standardize the process for obligating funds for a
small purchase procurement.

**1.3 Project Goal and Objectives**

**Goal**

It is the goal of this project to provide DOE with a fully-functional,
web-based system that can be deployed to DOE Headquarters, field sites,
and program offices, inclusive of the functional requirements defined by
the PSTF. By accomplishing the following objectives, the goal can be
obtained. Each defined objective can be gauged with the corresponding
measure of success that follows:

**Objective 1**: Ensure the selection of the development environment
that will provide the framework for developing a web-based electronic
commerce infrastructure.

*Measure of Success*: Analyze results from prototype by using defined
evaluation selection criteria and select the development environment:
database engine, web server, development tools, etc.

**Objective 2:** Develop one operational web-based DOE-wide automated
procedure application.

*Measure of Success*: The development of EC-Web, the procurement
application to be deployed throughout the agency.

**Objective 3:** Redevelop, modify, and/or install the LLNL gateway
capable of supporting DOEwide X12 activities, including routing,
translating, and distributing data. Integrate the Electronic Commerce
Communications Infrastructure to handle e-mail-based EDI transactions by
utilizing existing Perl Scripts.

*Measure of Success*: The integration of the LLNL gateway with the
EC-Web Application.

**Objective 4:** Provide proper channels for DOE\'s Vendor Community to
easily conduct business with DOE via EDI. Integrate EC-Web with process
for Automatic Registration and Tracking of Vendors.

*Measure of Success*: Providing a web-based system integrated with a
vendor registration process to accept the registration (838s), and
modifications (838Cs), support EDI Vendors, and track trading partner
information required for completing a small purchase.

**Objective 5:** Streamline and Standardize the Procurement Process,
Financial Process, and the Distribution Process. Identify one standard
DOE baseline system and freeze requirements.

*Measure of Success*: Development of EC-Web and acceptance of the
functionality by comparison to the Cross Reference Matrix.

**Objective 6:** Convert from the manual procurement process to the
automated procurement system for daily use by the DOE staff. Develop a
Conversion Plan for converting from the manual process to an automated
operational environment.

*Measure of Success*: Document and execute operational and support plans
focusing on end-user procedures and the process flow of documents for
using EC-Web.

**Objective 7**: Educate buyers and contracting officials on EDI.

*Measure of Success*: Execute an introductory EDI class.

**Objective 8**: Train end-users on EC-Web.

*Measure of Success*: Develop and document two training programs: HQ
training program for the prototype and a DOEwide training program
refined from lessons-learned during the prototype.

**Objective 9:** Incorporate the use of EDI X12 Standards for improving
internal and external exchanges of data via multiple platforms. Select
and implement a singular standard and specification mapping that will
meet procurement and financial needs both internal and external to DOE.

*Measure of Success*: Mandate and adopt the specification mapping by
EC-Web, the gateway (GATEC), VANs, VASs, and the Trading Partner
community.

**Objective 10:** Develop a deployable web-based small purchasing system
that can be utilized throughout the agency thaat performs the following
functions.

*Functional* Prepare/send a requisition to a procurement office.

*Requirement:*

*Measure of Success*: Have a procurement application that can
demonstrate the creation of a requisition showing approvals, funds
reservation, and status updates. The procurement application should have
the capability to route requisitions for approval, provide parallel
routing, select multiple approval paths and levels, and report the
status of requisitions.

*Functional* Issue a solicitation.

*Requirement:*

*Measure of Success*: Have a procurement application that can
demonstrate the creation of a solicitation, Request for Quotation (840),
from one or multiple requisitions, select specific vendors for bidding,
broadcast a bid, adhere to ANSI X12, compile multiple requisitions into
one solicitation, and the capability to issue a solicitation to multiple
and/or directed vendors.

*Functional* Receive a Quote.

*Requirement*

*Measure of Success*: Receive a Reply to Request for Quotation (843) by
importing incoming bids and processing bid evaluations for review and
selection to build a Purchase Order.

*Functional* Make an Award.

*Requirement*

*Measure of Success*: Have a procurement application that can provide an
automated process for converting a bid into a purchase order and
supporting the creation and issuance of a Purchase Order/Award (850),
create corresponding Public Award Notices (836) and send 836s to all
bidders, and convert multiple bids into a purchase order.

*Functional* Record receipt of goods and services.

*Requirement*

*Measure of Success*: Have inventory control checking and reporting
requirements implemented to complete the procurement process.

**Objective 11:** Develop a web-based system capable of supporting the
existing Trading Partner Community that uses VANS registered with the
LLNL Hub.

*Measure of Success*: Ability to adequately provide support for the
vendors doing EDI-based procurements.

**Objective 12:** Establish connectivity to Trading Partners and Service
Providers (VANs) and incorporating services to support the agency.
Integrate EC-Web with the LLNL Hub.

*Measure of Success*: Modify existing LLNL VAN Agreements to incorporate
DOE\'s functional requirements.

**Objective 13:** Interface with the financial system DISCAS by
providing electronic and interactive feeds for maintaining accurate
balances for procurement obligations and payment information.Ensure that
EC-Web functionality includes certification of funds available

*Measure of Success*: Have the procurement application demonstrate the
capability of completing the process of funds reservation and obligation
in DISCAS, generating a CFA number from DISCAS back directly into the
procurement application, reconciliation to the amount of the
reservation, and to provide creation of the flat files in ASCII format
specified in the DISCAS Requirements Document.

**1.4 User Groups**

EC-Web will be developed for the benefit of all DOE users that have any
involvement with the life cycle of a small purchase procurement,
including but not limited to:

HQ, Office of Procurement Operations

Program Offices

Field Sites

Finance

The primary end-user community will comprise:

Requisitioners

Buyers

Managers

Division Chiefs

Funding Managers

Buyers

Lead Buyers

Contracting officials

**1.5 Product Overview**

The following list provides a high level illustration of the
functionality that will be contained within the product:

processing requisitions

automated routing of documents to approvers, special approvers, and
funding managers

interactive interfaces to DISCAS for funds reservation/obligation

forwarding to buyers for complete life cycle processing: including
creating solicitations, bid evaluation, purchase order processing, and
invoice processing

interact with system users via a commercial Internet browser

interact with DOE Trading Partners via the LLNL Hub and its respective
VANs

comply to ANSI X12 standards for conducting EDI Database

The basic concept of operations for the procurement application is that
each user of the system will have internet access and will use a
commercially available web-browser running on a local workstation and
will securely access a central procurement server. The user will access
the EC-Web application via a web browser Secure Socket Layer (SSL)
service. Once securely attached to the server, additional user
authentication and database access controls will be utilized to support
DOE procurement security requirements.

The EC-Web application will enforce the business rules for processing
requisitions, manager approvals, request-for-quotations (solicitations),
bid evaluations, and issue an award. The EC-Web application utilizes an
HP Virtual Terminal Service to provide an interactive reservation and
obligation with the DOE DISCAS financial accounting system.

REQUISITION

Each requisition will have unique routing capability based on user
selection of the appropriate approval path. Approve/decline checkboxes
will be supplied for each Approving Official. It is envisioned that
separate in-boxes will be used to move documents through the document
process flow.

SOLICITATION

Upon successful approval of a requisition, the buyer will have the
capability to create a solicitation from one and/or multiple
requisitions. One-to-one Request for Quote transactions will be written
to a flat file that will be passed from the EC-Web application to the
GATEC Gateway. The file will then be translated into a valid 840, ANSI
X12 DoD 3010 implementation convention transaction set enclosed in a
secure E-mail envelope and mailed to the LLNL Hub for further
transmission to the VAN, and then to the vendor. The vendor will
generate a Functional Acknowledgement (997) when reading the 840, and
the 997 will flow back to the Gateway via E-mail. The gateway will open,
translate the 997, and match up the Gateway Tracking Database against
the issuing RFQ issued by GATEC. The gateway will match the transaction
identifier with the original RFQ number before presenting it to EC-Web.

The gateway will track the time and date of issuance of the original 840
and provide an E-mail notification to the issuing buyer if receipt by
the vendor has not been successful. The buyer will have the capability
to review the status of all outstanding RFQs at any time.

The buyer will have the capability to issue solicitations to several
vendors or a predetermined list of vendors. GATEC will issue multiple
one-to-one transactions as a single buyer action, and the gateway will
handle each transaction as an independent one-to-one 840.

The buyer will have the capability to issue one-to-public 840s, in which
case a solicitation is sent to all VANs responsible for dispersing to
their respective vendors. The Gateway will transmit a public RFQ to the
Hub, where copies of the RFQ will be made for each VAN. Each VAN will
have a special address to receive PUBLIC RFQs, and the hub will receive
a 997 back from each VAN that will be matched against the originating
RFQ. Notification will occur if a VAN does not respond within a
specified period. Transaction Statuses will be tracked and E-mail will
be used to provide feedback for problems.

AWARD

EC-Web will provide the decision tools for the buyer to prepare an
award. There will be an interactive interface to the DISCAS financial
system by using a Virtual Terminal Emulation for reservation and
obligation processing of financial data pertinent to each transaction.
Upon the successful completion of a reservation/obligation, the
Certification Funds Availability (CFA) number will be supplied back to
EC-Web, indicating a successful interface. In the event that the
reservation/obligation process is not successful, an error code will be
supplied back to the buyer and/or system administrator. Each error code
will have a corresponding predefined error message associated with it.
In the event that the reservation/obligation could not be processed
because the HP3000 is down, the interface program will retransmit for a
preset time.

[An award will not be able to be processed if a CFA number is not
generated or if the reservation/obligation process is not
successful]{.underline}. The award will be passed to the Gateway which
will make an entry in a local gateway table that will match the PO
number against the transaction identification issued it by the
translator. The gateway will translate the flatfile award into the
equivalent ANSI X12 850, place it into an E-mail envelope, and send it
to the Hub. The Hub will determine whether it is a direct transaction,
archive and readdress it and transmit it to the VAN, and on to the
vendor. The 997 process will be matched to the entry in the local
Gateway table. Statuses will be checkable and E-mail messages will be
generated if 997s are not received within a preset timeframe.

When an award is issued as a result of a one-to-one solicitation, no
public award summary (836) will be issued. When a one-to-several 840 is
issued, each losing bidder will receive an 836. For public RFQs, the
gateway will issue an 836 to public for each VAN. Each VAN will
acknowledge receipt of the 836.

The interface between the Gateway Services and procurement application
will need to be modified from interfacing with SPS, to interfacing with
EC-Web. The Gateway Services software (GATEC-Lite V1.0) will be used for
translation from flat file to/from ANSI X12 and for workflow monitoring.

EC HUB

The hub services will remain exactly the same as the present
architecture. The Hub Services performed at LLNL will be for VAN
connections, E-mail protocol conversion, vendor registration,
transaction archival, and transaction routing. The detailed information
pertinent to vendor registration will reside within the EC-Web. The hub
will be the central E-mail handling and distribution center and will
communicate with the VANS. Vendor Registration will also be handled by
the Hub. The Hub will not open the E-mail unless it is a Vendor
Registration. Short utilities can be written to search information on
all 840s that pass through the Hub. Each Vendor Registration will be
processed in the Hub-resident database and a registration confirmation
is returned to the vendor. The gateway will forward to EC-Web the
registration confirmation and a copy of the valid registration.

**1.6 Project Scope**

The scope of work covered in this proposal encompasses the development,
implementation, and support of a Web-based procurement application,
Electronic Commerce/Electronic Data Interchange (EC/EDI) Gateway
Services, and communication services. This configuration will support
the DOE small procurement process and establish a platform for
Departmental EC activities.

CDSI proposes the development of a World Wide Web-based small purchasing
system that will allow DOE to meet PSTF requirements, automate secure
DOE-wide small purchasing, and transition DOE to an EC environment that
will support future technology and vendor markets. Additional benefits
of this solution include positioning DOE to continue to make automation
advances in the procurement arena (e.g., large contracting).

EC-Web Phase I will include the baseline functional requirements as
approved by DOE. Functional areas that will not be automated in Phase I
include: automated shipping and receiving interfaces, automated credit
card processing and reconciliation, interactive updates to DISCAS for
invoicing, electronic payments, and electronic funds transfer.

**Table 1. EC-WEB Components and Corresponding Requirements**

We have organized the scope of work into five EC-Web project components
that will meet DOE business needs. The chart below identifies each
component followed by its associated requirements and its ID Association
from the detailed work breakdown structure.

+------------+------------------+--------------+----------+-----------+
| WWW        | BACK-END RDBMS   | DOE GATEWAY  | MODULES  | LEGACY    |
|            |                  |              |          | SYSTEM    |
|            |                  |              |          |           |
|            |                  |              |          | I         |
|            |                  |              |          | NTERFACES |
+============+==================+==============+==========+===========+
| Web-based  |                  |              |          |           |
| Front-end  |                  |              |          |           |
| for        |                  |              |          |           |
| Requ       |                  |              |          |           |
| isitioners |                  |              |          |           |
| 137        |                  |              |          |           |
+------------+------------------+--------------+----------+-----------+
| Web-based  | Comply with      | Application  | Routing  | DISCAS    |
| Front-end  | Procurement      | Program      | Module   | Program   |
| for buyers | Staff Functional | Interfaces   | 143      | Interface |
| to issue   | Requirement      | (API):       |          | 151       |
| sol        | Document 73      |              |          |           |
| icitations |                  | Procurement  |          |           |
| and        |                  | Application, |          |           |
| c          |                  | Grants       |          |           |
| alculation |                  | Application, |          |           |
| of bids    |                  |              |          |           |
| 161        |                  | Other DOE    |          |           |
|            |                  | a            |          |           |
|            |                  | pplications. |          |           |
|            |                  | 187          |          |           |
+------------+------------------+--------------+----------+-----------+
| Web-based  | Database         | Transaction  | I        | HP 3000   |
| Front-end  | structures and   | set Auditing | nternet/ | Data      |
| for buyers | relationships    | and tracking | Intranet | Comm      |
| to issue   | for Purchasing,  | 222          | Commu    | unication |
| Purchase   | Vendor and       |              | nication | interface |
| Orders 169 | Financial Fields |              | 197      | 178       |
|            | already defined  |              |          |           |
|            | 88               |              |          |           |
+------------+------------------+--------------+----------+-----------+
| Interface  | Interface to     | ANSI X12     | Noti     | Res       |
| to RDBMS   | webserver via    | Translation  | fication | ervation, |
| via CGI    | CGI Scripting    | 188          | 217      | O         |
| Scripting  | 179              |              |          | bligation |
| 179        |                  | 840,843,850, |          | File      |
|            |                  | 997,824,194: |          | Spec      |
|            |                  | 224          |          | ification |
|            |                  |              |          | 155       |
+------------+------------------+--------------+----------+-----------+
| Web        | Establish rules  | EDI Gateway  | M        | Funds     |
| browsers   | for compliance   | Perl Script  | essaging | Control   |
| 198        | checking 196     | process 180  | 217      | in        |
|            |                  |              |          | tegration |
|            |                  |              |          | 154       |
+------------+------------------+--------------+----------+-----------+
| Front End  | Requisition,     | Translation  | S        | Security  |
| Screens:   | Solicitation,    | Mapping: 194 | canning, | 109       |
|            | PO, field        |              | data     |           |
| R          | validation 134   | DOD 3010     | entry,   |           |
| equisition |                  | Im           | faxing,  |           |
| 75         |                  | plementation | imaging, |           |
|            |                  | Convention   | printing |           |
| So         |                  | 190          | 187      |           |
| licitation |                  |              |          |           |
| 76         |                  |              |          |           |
|            |                  |              |          |           |
| Financial  |                  |              |          |           |
| Interface  |                  |              |          |           |
| 77         |                  |              |          |           |
|            |                  |              |          |           |
| Bid        |                  |              |          |           |
| Evaluation |                  |              |          |           |
| 78         |                  |              |          |           |
|            |                  |              |          |           |
| PO 79      |                  |              |          |           |
|            |                  |              |          |           |
| Invoice 81 |                  |              |          |           |
|            |                  |              |          |           |
| System     |                  |              |          |           |
| Admin. 82  |                  |              |          |           |
|            |                  |              |          |           |
| Reporting  |                  |              |          |           |
| 83         |                  |              |          |           |
+------------+------------------+--------------+----------+-----------+
| Security   | Approval         | Inter        | Security |           |
| 110        | Processes 143    | net/Intranet | 110      |           |
|            |                  | Services 198 |          |           |
+------------+------------------+--------------+----------+-----------+
| WWW        | Bid Evaluation   | Security 110 |          |           |
| Technology | 161              |              |          |           |
| platform   |                  |              |          |           |
| 61         |                  |              |          |           |
+------------+------------------+--------------+----------+-----------+
|            | Funds            | E-mail (PEM, |          |           |
|            | Certification &  | S-MIME) 225  |          |           |
|            | Funds Control    |              |          |           |
|            | 151              |              |          |           |
+------------+------------------+--------------+----------+-----------+

**1.7 Major Milestones**

Following are the major EC-Web project milestones and their estimated
completion dates. The activities detail is provided in the EC-Web
project work breakdown structure (WBS). Additional schedule and
deliverables information is provided in the master schedule, section
3.7.

+-------------------------------------------------------+--------------+
| **Milestone**                                         | **Target     |
|                                                       | Date**       |
+-------------------------------------------------------+--------------+
| > Exit Planning Stage                                 | 05/07/97     |
+-------------------------------------------------------+--------------+
| > Exit Preparation Stage                              | 06/16/97     |
+-------------------------------------------------------+--------------+
| > Exit Software Design Stage                          | 08/05/97     |
+-------------------------------------------------------+--------------+
| > Exit Programming and Integration Stage              | 11/28/97     |
+-------------------------------------------------------+--------------+
| > Exit System Testing and Acceptance Stage            | 03/16/98     |
+-------------------------------------------------------+--------------+
| > **Exit System Development Phase**                   | 03/30/98     |
+-------------------------------------------------------+--------------+
| > Exit Installation/Deployment Stage                  | 03/31/98     |
+-------------------------------------------------------+--------------+
| > Exit Program Development Stage                      | 12/01/99     |
+-------------------------------------------------------+--------------+

**2. PROJECT ORGANIZATION**

**2.1 Development Model**

The development of EC-Web will follow the DOE Software Engineering
Methodology (SEM). The SEM is the lifecycle methodology standard for all
DOE system development projects that integrates project management,
software engineering and Quality Assurance processes. Additional
information about the SEM Development Model can be researched via the
U.S. Department of Energy Software Management and Quality Assurance Home
Page at http://www.hr.doe.gov/sem/smpqa_01.htm. The lifecycle model can
be used as-is or tailored for any software development project.
Tailoring of the SEM lifecycle for this project includes conscious
modifications to several stages, including modification to the number
and types of expected documents. Listed below are the specific
deviations from the SEM medium system model that CDSI has decided to
take with the understanding that these deviations will not increase the
risk associated with the successful completion of this project.

**Documentation Standards**

The documentaiton for EC-Web will be compliant with IEE standards as
follows:

! ANSI/IEEE Guide to Software Requirements Specifications

! IEEE Guide to Software Design Descriptions

! IEEE Standard for Software User Documentation

**Planned Deviations - Stages**

These changes reflect customization to the Software Engineering
Methodology for a Intranet/Internet software development project.

  -----------------------------------------------------------------------
  SEM Reference     SEM Methodology Stages   EC-Web Methodology Stages of
  Numbers                                    Development
  ----------------- ------------------------ ----------------------------
  3.1 through 3.10  Planning                 Planning

  4.1 through 4.11  Requirements Definition  Preparation

  5.1 through 5.12  Functional Design        Software Design

  6.1 through 6.12  System Design            

  7.1 through 7.12  Programming              Programming and Integration

  8.1 through 8.7   Software Integration and 
                    Testing                  

  9.1 through 9.9   Installation and         System Testing and
                    Acceptance               Acceptance

                                             Installation and Deployment
  -----------------------------------------------------------------------

! The Planning Stage will contain no deviations from the SEM lifecycle
methodology standard for EC-Web.

! The Requirements Definition Stage has been renamed as the Preparation
Stage. This was a conscious decision since the Preparation Stage will
emphasize the determining of the development environment components that
will be used in the Design Stage.

! The Functional Design Stage and the System Design Stage will be
combined within the Software Design Stage. This distinction will assist
with the management of the project specific to the software design.

! The Programming Stage will be combined with the Software Integration
Stage and will be called Programming and Integration Stage.

! However, the Testing Stage will not be combined into the Programming
and Integration Stage. Rather, the Software Integration and Testing
Stage will be System Testing and Acceptance Stage.

! The Installation Stage will be combined with the Installation and
Deployment Stage.

**Project Plan Revisions**

Each Stage will have an In-Stage Assessment, and Stage Exit. This
Project Plan will be revised, as needed, at the end of each stage. The
impact of any changes will be evaluated accordingly, and the Stage Exit
process will be used as the vehicle to secure approval of the revised
plan.

**Planned Deviations - Deliverables**

Each deliverable and work product will be reviewed by an independent
Quality Assurance Analyst to ensure compliance with applicable
standards.

Planned deviations in deliverables will be as shown in the table on the
following page.

+--------------+----------+---------------+--------------------------+
| SEM          | EC-Web   | Deliverables  |                          |
| Methodology  | Met      |               |                          |
| Stages       | hodology |               |                          |
|              | Stages   |               |                          |
|              | of       |               |                          |
|              | Dev      |               |                          |
|              | elopment |               |                          |
+==============+==========+===============+==========================+
|              |          | EC-Web        | Deviations from SEM Work |
|              |          |               | Products                 |
|              |          | Planned Work  |                          |
|              |          | Products      |                          |
+--------------+----------+---------------+--------------------------+
| Planning     | Planning | ! Proposal    | ! Prototype instead of   |
|              |          |               | Feasibility Study        |
|              |          | ! Project     |                          |
|              |          | Plan          |                          |
|              |          |               |                          |
|              |          | ! WBS         |                          |
|              |          |               |                          |
|              |          | ! Quality     |                          |
|              |          | Assurance     |                          |
|              |          | Plan          |                          |
+--------------+----------+---------------+--------------------------+
| Requirements | Pre      | ! Acquisition | ! No deviations          |
| Definition   | paration | and           |                          |
|              |          | Installation  |                          |
|              |          | Plan          |                          |
|              |          |               |                          |
|              |          | ! Detailed    |                          |
|              |          | Process Flow  |                          |
|              |          |               |                          |
|              |          | ! Concept of  |                          |
|              |          | Operations    |                          |
|              |          |               |                          |
|              |          | ! Functional  |                          |
|              |          | Requirement   |                          |
|              |          | Document      |                          |
|              |          |               |                          |
|              |          | !             |                          |
|              |          | Configuration |                          |
|              |          | Mgmt Strategy |                          |
+--------------+----------+---------------+--------------------------+
| Functional   | Software | ! Design      | ! No deviations          |
| Design       | Design   | Entities      |                          |
|              |          | /Dependencies |                          |
|              |          |               |                          |
|              |          | ! Logical     |                          |
|              |          | Model         |                          |
|              |          |               |                          |
|              |          | ! Table       |                          |
|              |          | Structures    |                          |
|              |          |               |                          |
|              |          | ! Database    |                          |
|              |          | Schema        |                          |
|              |          |               |                          |
|              |          | ! Functional  |                          |
|              |          | Design        |                          |
|              |          | Document      |                          |
|              |          |               |                          |
|              |          | ! Screen      |                          |
|              |          | Designs       |                          |
|              |          |               |                          |
|              |          | ! Cross       |                          |
|              |          | Reference     |                          |
|              |          | Matrix        |                          |
|              |          |               |                          |
|              |          | ! Security    |                          |
|              |          | Plans         |                          |
|              |          |               |                          |
|              |          | ! Training    |                          |
|              |          | Plan          |                          |
|              |          |               |                          |
|              |          | ! System      |                          |
|              |          | Te            |                          |
|              |          | st/Acceptance |                          |
|              |          | Plan          |                          |
|              |          |               |                          |
|              |          | ! Conversion  |                          |
|              |          | Plan          |                          |
|              |          |               |                          |
|              |          | ! Programming |                          |
|              |          | S             |                          |
|              |          | pecifications |                          |
+--------------+----------+---------------+--------------------------+
| System       |          |               |                          |
| Design       |          |               |                          |
+--------------+----------+---------------+--------------------------+
| Programming  | Pro      | ! Site        | ! Field Site             |
|              | gramming | Installation  | Installation Plan (Will  |
|              | and      | Plan          | be completed in the      |
|              | Int      |               |                          |
|              | egration | ! Software    | Software Design Stage)   |
|              |          |               |                          |
|              |          | ! System      |                          |
|              |          | Documentation |                          |
|              |          | Draft         |                          |
+--------------+----------+---------------+--------------------------+
| Software     |          |               |                          |
| **I          |          |               |                          |
| ntegration** |          |               |                          |
| and Testing  |          |               |                          |
+--------------+----------+---------------+--------------------------+
| Software     | System   | ! Test        | ! ANSI X12 Mappings will |
| Integration  | Testing  | Results       | be delivered as an       |
| and          | and      |               | additional               |
| **Testing**  | Ac       | ! Operational |                          |
|              | ceptance | System        | work product             |
| Installation |          |               |                          |
| and          |          | ! System      | ! SEM does not           |
| Acceptance   |          | Documentation | incorporate EDI          |
|              |          |               | Methodology              |
+--------------+----------+---------------+--------------------------+
|              | Inst     |               |                          |
|              | allation |               |                          |
|              | and      |               |                          |
|              | De       |               |                          |
|              | ployment |               |                          |
+--------------+----------+---------------+--------------------------+

! The Planning Stage has two additional deliverables: Project Proposal
and the detailed Work Breakdown Structure (WBS).

! In lieu of a Feasibility Statement in the Planning Stage, a prototype
will be developed in the Preparation Stage that will provide feasibility
assertions derived from the evaluation criteria for the selection of the
development environment.

! The Analysis of Benefit and Cost will not be produced in the Planning
Stage.

! The Field Site Installation Plan will be completed in the Software
Development Stage rather than the Programming and Integration Stage due
to issues that require resolution prior to that stage.

**2.2 Project Team**

The following chart defines the project team for the EC-Web project.

+-----------------------------------------------------------------------+
| # Development Team Services and Support Approvers                     |
+-----------------------------------------------------------------------+
| Project Manager Independent Consultants User Point of Contact         |
+-----------------------------------------------------------------------+
| Configuration Manager Documentation Specialist Technical Monitor      |
+-----------------------------------------------------------------------+
| Senior Systems Analyst Trainer Client Representative                  |
+-----------------------------------------------------------------------+
| Senior Lead Developer Security Specialist Quality Assurance           |
+-----------------------------------------------------------------------+
| Senior DataComm Engineer LAN Engineer                                 |
+-----------------------------------------------------------------------+
| Senior Programmer/Analyst (1) Acceptance Tester Project Manager\'s    |
| Manager                                                               |
+-----------------------------------------------------------------------+
| Programmers (2) LLNL Hub Operations System Owner                      |
+-----------------------------------------------------------------------+

**2.3 Roles and Responsibilities**

The following chart defines the roles and responsibilities of the
members of the project team and their function at stage exit.

> *Note: Due to staffing fluctuations, if a particular person is unable
> to fulfill his/her responsibilities, it will be the responsibility of
> the manager overseeing that area to ensure a replacement, with
> appropriate skills and experience, on a timely basis.*

+-----------+---------------+--------+------------------------+-------+
| **Role**  | **Name**      | **     | **Project              | **    |
|           |               | Org.** | Development**          | Stage |
|           |               |        |                        | Exit  |
|           |               |        | **Responsibility**     | Funct |
|           |               |        |                        | ion** |
+===========+===============+========+========================+=======+
| System    | Steve         | HR-53  | Verifies developers\'  | Ap    |
| Owner     | Mournighan    |        | understanding of the   | prove |
|           |               |        | application purpose    |       |
|           |               |        | and design. Has        |       |
|           |               |        | overall responsibility |       |
|           |               |        | and accountability for |       |
|           |               |        | system and data. Helps |       |
|           |               |        | resolve conflict.      |       |
+-----------+---------------+--------+------------------------+-------+
| User      | Ellen         | HR-53  | In representing the    | Ap    |
| Point of  | Colligan      |        | procurement and        | prove |
| Contact   |               | C      | finance user           |       |
| (POC)     | Juanita       | R-50.1 | community, acts as the |       |
|           | Delair        |        | single point of        |       |
|           |               |        | contact for approving  |       |
|           |               |        | functional             |       |
|           |               |        | requirements project   |       |
|           |               |        | deliverables and       |       |
|           |               |        | changes. Resolves      |       |
|           |               |        | conflicts.             |       |
+-----------+---------------+--------+------------------------+-------+
| Client    | Andy Yocke    | HR-43  | Reviews project        | Ap    |
| Repres    |               |        | deliverables.          | prove |
| entative/ |               |        | Represents the         |       |
|           |               |        | field\'s interests and |       |
| Technical |               |        | ensures that the       |       |
| Monitor   |               |        | organization\'s        |       |
|           |               |        | information needs are  |       |
|           |               |        | met.                   |       |
+-----------+---------------+--------+------------------------+-------+
| Quality   | Andy Bicocchi | Q      | Reviews and approves   | Ap    |
| Assurance |               | uality | project deliverables   | prove |
| Contact   |               |        | from QA perspective.   |       |
|           |               | Assur. | Reviews plans and      |       |
|           |               |        | deliverables for       |       |
|           |               | CDSI   | compliance with        |       |
|           |               |        | applicable standards.  |       |
|           |               |        | Provides guidance and  |       |
|           |               |        | assistance on SEM      |       |
|           |               |        | process matters.       |       |
+-----------+---------------+--------+------------------------+-------+
| Project   | Bob Miller    | CDSI   | Provides support and   | Ap    |
| M         |               |        | guidance to the        | prove |
| anager\'s |               |        | project manager and    |       |
| Manager   |               |        | team, ensures project  |       |
|           |               |        | staffing. Resolves     |       |
|           |               |        | conflict across        |       |
|           |               |        | organizations.         |       |
|           |               |        | Facilitates            |       |
|           |               |        | communications.        |       |
+-----------+---------------+--------+------------------------+-------+
| Project   | Kevin Shaver  | CDSI   | Responsible for daily  | Co    |
| Manager   |               |        | planning and control   | nduct |
|           |               |        | of the project.        |       |
|           |               |        | Coordinates resolution |       |
|           |               |        | of issues. Manages and |       |
|           |               |        | coordinates technical  |       |
|           |               |        | effort. Performs       |       |
|           |               |        | adequate and timely    |       |
|           |               |        | staffing. Provides     |       |
|           |               |        | regular and timely     |       |
|           |               |        | communications.        |       |
|           |               |        | Prepares and           |       |
|           |               |        | administers project    |       |
|           |               |        | plans. Tracks and      |       |
|           |               |        | reports progress.      |       |
+-----------+---------------+--------+------------------------+-------+
| Senior    | Jill Schwartz | CDSI   | Responsible for        | Su    |
| Systems   |               |        | Functional             | pport |
|           |               |        | Requirements,          |       |
| Analyst   |               |        | Training, Support,     |       |
|           |               |        | Operation,             |       |
|           |               |        | Documentation, EDI.    |       |
|           |               |        | Acts as single point   |       |
|           |               |        | of contact for DOE     |       |
|           |               |        | user points of contact |       |
|           |               |        | for finance and        |       |
|           |               |        | procurement.           |       |
+-----------+---------------+--------+------------------------+-------+
| Sr. Lead  | Paul Walker   | CDSI   | Designs user interface | Su    |
| Developer |               |        | for the application.   | pport |
|           |               |        | Writes or delegates    |       |
|           |               |        | the writing of all     |       |
|           |               |        | programs related to    |       |
|           |               |        | the application.       |       |
+-----------+---------------+--------+------------------------+-------+
| (Senior)  | Bill Luch     | CDSI   | Designs user interface | Su    |
| Pr        |               |        | for the application.   | pport |
| ogrammers |               |        | Acts as primary author |       |
|           |               |        | of Design document.    |       |
|           |               |        | Writes or delegates    |       |
|           |               |        | the writing of all     |       |
|           |               |        | programs related to    |       |
|           |               |        | the application.       |       |
+-----------+---------------+--------+------------------------+-------+
| P         | Mark Bohler   | CDSI   | Assists the            | Su    |
| rogrammer |               |        | Designer/Programmer in | pport |
|           |               |        | writing programs.      |       |
+-----------+---------------+--------+------------------------+-------+
| Conf      | Kevin Shaver  | CDSI   | Prepares the           | Su    |
| iguration |               |        | Configuration          | pport |
|           |               |        | Management Plan.       |       |
| Manager   |               |        | Handles configuration  |       |
|           |               |        | management activities. |       |
+-----------+---------------+--------+------------------------+-------+
| In        | Ellen         | HR-53  | Conducts testing of    | Su    |
| dependent | Colligan      |        | the application at all | pport |
| Tester    |               |        | stages of development. |       |
+-----------+---------------+--------+------------------------+-------+
| A         | Ellen         | HR-53  | Evaluates the          | Su    |
| cceptance | Colligan      |        | application for        | pport |
| Tester    |               | C      | overall operability    |       |
|           | Juanita       | R-50.1 | and ease of user       |       |
|           | Delair        |        | interface at           |       |
|           |               | HR     | acceptance.            |       |
|           | Michael       | -561.1 |                        |       |
|           | Raizen        |        |                        |       |
+-----------+---------------+--------+------------------------+-------+
| Docu      | Marsha        | CDSI   | Writes the user and    | Su    |
| mentation | Proctor       |        | programmer manuals.    | pport |
| S         |               |        |                        |       |
| pecialist |               |        |                        |       |
+-----------+---------------+--------+------------------------+-------+
| Trainer   | CDSI DOE      | CDSI   | Assists in the         | Su    |
|           | Contract      |        | development of the     | pport |
|           |               |        | Training Plan. Trains  |       |
|           |               |        | EC-Web users.          |       |
+-----------+---------------+--------+------------------------+-------+
| LAN       | John Li       | CDSI   | Provides internal      | Su    |
| Engineer  |               |        | consulting,            | pport |
|           |               |        |                        |       |
|           |               |        | testing, and support.  |       |
+-----------+---------------+--------+------------------------+-------+
| DataComm  | Jay Rosansky  | CDSI   | Provide gateway,       |       |
| Engineer  |               |        | scripting, security,   |       |
|           |               |        | and ANSI X12           |       |
|           |               |        | translation            |       |
+-----------+---------------+--------+------------------------+-------+
| Security  | Jay Rosansky  | CDSI   | Provides guidance in   | Su    |
|           |               |        | the development of the | pport |
|           |               |        | Computer Security      |       |
|           |               |        | Protection Plan.       |       |
+-----------+---------------+--------+------------------------+-------+
| Security  | Frances       | HR-53  | Reviews for compliance | Su    |
|           | Woodward      |        | with DOE policy        | pport |
+-----------+---------------+--------+------------------------+-------+

**2.4 Problem Escalation**

Problem situations are to be resolved in an orderly and timely manner.
The severity of the problem will dictate the persons responsible for
resolving and the time period allowed for sufficient resolution. If no
decision is made about the conflict in the amount of time stated, the
project manager will proceed forward at risk, but will notify the System
Owner and Technical Monitor of impact of risk.

**Project Manager** Resolves conflicts within the development team that
revolve around the functional aspects of the application (3 business
days). Enforces policies/procedures that must be implemented. Consults
with the senior area manager to resolve difficult problems (3 business
days).

**User POC** Resolves conflict among the development team and the
primary users in determining the priority of requirements when resources
are limited (7 business days).

**System** Resolves conflict among the development team, user POC,
project

**Owner** manager in situations where differences about project scope or

> schedule occur or where funding issues arise (7 days).

**3. MANAGEMENT APPROACH**

**3.1 Management Priorities**

The project team is committed to meeting the project objectives and will
priorities activities in the most efficient manner to meet or exceed
predetermined milestones and deadlines.

> ! The highest priority is to develop a product that meets or exceeds
> the baseline system.
>
> ! The next priority is to minimize new software development time by
> maximizing the use of available software design and development tools
> and when the opportunity exists, to reuse existing software that has
> already been developed for the DOE EC environment.
>
> ! This is followed closely by delivery of the tested and operational
> system on the planned delivery date.
>
> ! The next priority is to have in place a plan that provides a quick
> deployment strategy that will maximize the capabilities of the
> internet to allow for field site rollout in a short period of time.

**3.2 Project Tracking and Control**

The complete project schedule will be detailed within status reports.
The actual completions will be tracked against what was planned. The
Project Manager will put all line items (activities, tasks, and
subtasks) of the development lifecycle stages on the weekly status
report with a deliverable date corresponding to each task, as the work
begins for a given line item.

! Structured walkthroughs of deliverables will be conducted with both
DOE and the CDSI EC Team to ensure high content quality and removal of
defects.

! In Progress Reviews will be conducted with CDSI Corporate.

! In Stage Assessments will be conducted with an independent Quality
Control Analyst for quality assurance verification.

! Stage Exits will be conducted with DOE to review the deliverables in
the stage, and to address issues and revise the project plan.

! Electronic Commerce Conference Calls will be conducted with DOE to
update field sites and headquarters EC Task Force members of progress.

In the event a problem is encountered within the development of the
project, the issue will be reported in a Issue/Resolution Log. This log
will consist of the description of the problem, the date the problem was
reported, the person who reported the problem, the name of the person
responsible for overseeing the resolution of the problem, a detailed
explanation for overcoming the issue including the resolution and
resolution date.

**3.2.1 Status Reporting**

**As required**

In addition to all formally scheduled meetings, informal meetings will
occur throughout the entire project on an as-needed basis; that will be
determined by either a cognizant EC Task Force Members or the CDSI EC
Team.

**Weekly**

The Project Manager will update the status report on a weekly basis to
provide the approvers information about recent completions,
accomplishments, and efforts expended. The Project Manager will discuss
the progress of the EC-Web project for each scheduled EC Task Force
Conference Call meeting between the CDSI EC Team, the system owner, the
client representative, and the DOE Field Site Representatives. The CDSI
development team will also meet weekly to discuss issues and progress.

In addition to these weekly means of reporting status, the project
manager will be available to answer questions about the progress of the
application throughout this project.

**Monthly**

All of the above information will be summarized in the Technical Status
Report (TSR). The TSR is the official reporting mechanism for the System
Development organization. It will be prepared monthly, and will be
distributed according to the standard distribution list and Technical
Monitor.

**3.2.2 Stage Exits (Project Checkpoints)**

Each stage will conclude with a formal checkpoint called a stage exit.
When a stage has been successfully "exited,\" this will indicate that
all the deliverables due to date have been completed, all outstanding
issues have been addressed.

CDSI proposes that periodic checkpoints be establish to confirm CDSI is
complying with the proposed Delivery Schedule approved by DOE. Further,
each stage of development will include an In-Stage Assessment conducted
by a CDSI Quality Assurance Consultant to verify that all draft and
final deliverables due to date have been completed, all outstanding
issues have acceptable action plans, and there is a sound plan for the
remainder of the project. The checkpoint process will consist of a
meeting of CDSI key personnel and designated DOE representatives to
present and review the completed objectives. The project's designated
approvers and any affected functional areas involved in the project must
provide a written position of concur/non-concur at each stage
checkpoint.

The checkpoints and corresponding completion dates are listed as
follows.

**Checkpoint Date Description**

! May 7: Exit Planning Stage. Identify selected development environment
(web server, database server, and Development tools). Present Project
Plan and detailed WBS.

! June 16: Exit Preparation Stage. Present Concept of Operations with
detailed process flow of "how" system will operate. Indicated that all
resources are in place to begin application design and development

! June 30: Prototype Requisition screens and present EC-Web application
screen design for DOE field approval.

! July 16: EC-Web Screen Development completed - Provide demonstration
of developed EC-Web screens. Demonstration to be performed at DOE Proc
Ops office accessing development environment at Quince Orchard.

! August 5: Exit Software Design Stage. Marks the completion of
applications design and program specifications. Actual coding will
begin. This date will signal that all is right on track for EC-Web. A
technical design and program specification presentation will made.

! October 12: Present EC-Web Requisition and Approval Modules.

! October 20: Demonstrate EC-Web Solicitation, receipt of bids, and bid
evaluation

processes.

! November 18: Demonstrate EC-Web system end-to-end small purchase
process with a automated financial interface.

> ! November 28: Exit Programming and Integration Stage. Present System
> Documentation

! February 2: DOE Procurement operations begin live purchasing. Present
results of End-to-End Test Plan and present operational system.

! March 16: Begin expansion of operational mode to additional end-users,
field sites, program offices. Exit System Testing and Acceptance Stage.

**3.3 Assumptions, Constraints, and Dependencies**

**End-User Assumptions**

It is assumed that each end user is required to have Netscape Navigator
3.0 web browser clients or equivalent to access EC-Web. Further, it is
assumed that each end user\'s client has TCP/IP access to the EC-WEB
server. It is also assumed that each end users can print from web
browser client.

**Gateway Assumptions**

It is assumed that the EDI gateway will have TCP/IP access to LLNL EC
HUB. LLNL will be available for consultation, if needed, regarding the
EDI Gateway program, scripts, translation workbench, and translation
engine. Additionally, LLNL will be available to participate in testing
the gateway to Hub communications and services.

**DISCAS Assumptions**

The EC-Web server has Network Virtual Terminal (NVT) access to every
DISCAS systems.

**Security Assumptions**

It is assumed that the EC Security Plan and DISCAS Security Plan will be
approved by the DOE Field Sites if adequate risks and specific
countermeasures are adequately identified.

**Requirement Assumptions**

It is assumed that the Functional Requirements Document will be used as
the basis for determining how all the end-users expect the system to
operate.

**Dependencies**

This project is dependent upon LLNL supporting DOE, gateway
functionality if required, Hub Services as related to the VAN's and
DOE's Trading Partners, and LLNL's support of tracking and archiving EDI
documents consistent with the SPS-GATEC implementation. The success of
this project is dependent upon LLNL's availability to support all
migrations from the GATEC-SPS implementation to the EC-Web-GATEC
implementation as defined throughout this project. This project is
dependent upon the continued successful operation of the LLNL Hub and
LLNL's ability to revise VAN agreements representing DOE's business
practices. The success of this project is dependent upon hiring the
appropriate resources in a timely manner.

**3.4 Risk Management**

**Risk Category: Technological Risk**

There is currently no existing Web-based application that has the
functionality of the required system. The basic functionality of each
piece of this system has been demonstrated in pieces in other systems.
The technological risks are associated with integrating the pieces. The
Web server must have flexible and controlled access to the database. The
Web server/Database/OS must have flexible interaction with external
processes. The Web server OS and EDI Gateway OS must support standards
based secure E-mail for message transfer. The Web server OS must support
scripted Network Virtual Terminal (NVT) sessions.

**Risk Mitigation:** **Technological**

The Web server, Database, and OS will be selected to minimize these
risks. The Web server and Database will be evaluated on the ability of
the Web server to provide powerful and controlled access to the
database. The Web server, Database, and OS will be selected based on
their ability to integrate with each other and external programs.
Particularly, the OS must support some form of standards based secure
SMTP E-mail that is also supported on the EDI Gateway platform.

CDSI maintains a Certified Business Partnership with ORACLE inc. The
services

available incorporates all aspects of the ORACLE business strategy.
Business Re-Engineering,

DataBase Designs, Applications Programming, Systems Programming, Network
Integration,

and Training can be provided for both short and long term projects. CDSI
in conjucntion

with ORACLE personnel will accomplish the technical solutions necessary
in the most

demanding environments. As certain situations and requirements arise,
CDSI and/or Orcale will provide; on-site, remote, and telephone support
may established at any given location, nationwide.

CDSI is an authorized Lotus Notes Reseller in partnership with IBM.
Lotus Developers and

Consultants are valuble resources to design and implement Lotus Notes
installations.

CDSI maintains a skilled staff of experience Lotus Notes programmers and
designers to

accomadate a variety of requirements. This alliance ensures that our
clients will received

the latest and optimal solutions. This midigates the risk associated
with any situations

that may occur.

**Risk Category: Performance Risk**

It is possible that end user response time will be unacceptably slow or
that connectivity to either the DISCAS system will be unacceptably slow.
This could be due to the EC-Web server being overloaded or network
utilization problems within the DOE business network.

**Risk Mitigation: Performance**

The user application uses the Hyper Text Transfer Protocol (HTTP). The
HTTP provides efficient use of network bandwidth. The DOE HQ network is
based on 10MB Ethernets connected by high speed back bones. It is not
anticipated that this application will create a bandwidth capacity
problem within this network.

The remote sites access the HQ DOE network by a variety of WAN
technologies and data rates. HTTP is often used over moderate capacity
links without performance problems. If a performance problem exists that
is attributed to network utilizations problem of the remote site,
increasing that site capacity may be required.

Server load estimates will be made based on current purchasing volume
and the estimated DOE users. Hardware will be selected that has
demonstrated the capability to handle similar loads in other systems.
Hardware will also be selected based on its scaleability.

**Risk Category: Staffing**

The present vacancies for the position of Lead Software Developer,
Senior Programmer, and to mid-level Programmers present a high risk to
the project timeline.

**Risk Mitigation: Staffing**

Presently recruiting and staffing measures are being implemented via
headhunters, CDSI in-house Human Resources Department, job recruiting
fairs, and newspaper advertisements. Every effort will be made to
adequately staff this project with exceptionally qualified resources.

**Risk Category: Aggressive Project Timeline**

The project timeline is very aggressive and requires coordination
between DOE approvers and the DOE field sites.

**Risk Mitigation: Aggressive Project Timeline**

CDSI providing schedules in advance via the WBS for timeframes,
deadlines, deliverable presentations, and meetings. This will provide
DOE with a clear understanding of their involvement so that DOE can plan
the use of resources to review submitted documentation and deliverables
in a timely manner.

**3.5 Project Estimates**

**3.5.1 Size Estimates**

Estimates for the EC-Web project were determined by analyzing the
project requirements that are known to date. This included the current
project objectives and information gathered during the last three years
of working on this project and documenting the requirements, concept of
operations, integration and interfacing requirements and the
cross-reference matrix. Surveys analyzing historical data pertinent to
the procurement lifecycle have also been conducted to assist with
completing the size estimation: such as number of procurements annually,
number of requisitioners, number of buyers, number of credit card users,
number of line items per requisition, number of lines per purchase
order, and the number of documents needed for one life cycle of a small
purchase procurement. Should there be a change in requirements, the size
estimates will be revisited and reconsolidated.

**3.5.2 Time Estimates**

The size estimated was used to project the time required for developing
the web-based procurement application, based on skill/experience levels
as defined in the Staffing Plan section. They were also provided to the
functional areas using the defined functional baseline to support in
estimating activities for the project. Specific to the software
development, prototypes were configured in the EC Test Bed environment
and communicated to experts for additional independent estimates. The
resulting resource allocation chart represents a best effort to achieve
a combination of optimum resource utilization and early project
delivery. At the completion of the Preparation Stage of the project, the
estimate of total person hours will be updated and validated against the
target completion dates.

**3.6 Staffing Plan**

Figure 2 depicts the CDSI EC project team staffing profile and
hierarchy. The staff will consist of the following positions:

! 1 PTE - Project Manager

! 1 FTE - Senior System Analyst

! 1 FTE - Senior Lead Developer

! 1 FTE - Senior Programmer

! 1 FTE - Senior Developer/Communication Specialist

! 1 PTE - Senior System Engineer

! 2 FTE - Mid-level Programmers

! 1 PTE - Quality Assurance Consultant

! Matrix of Trainer, Tech Writer, Clerical, Graphics Artist

Figure 2. CDSI EC Project Team Organization Chart

<table>
<colgroup>
<col style="width: 9%" />
<col style="width: 5%" />
<col style="width: 4%" />
<col style="width: 5%" />
<col style="width: 5%" />
<col style="width: 4%" />
<col style="width: 5%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 6%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 6%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 6%" />
<col style="width: 4%" />
</colgroup>
<tbody>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="4" rowspan="2"><p>CDSI VP</p>
<p>Gene Kelly</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="4" rowspan="2"><p>CDSI DOE Contract Manager</p>
<p>Woody Hopkins</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="4"><p>CDSI DOE Data</p>
<p>Engineering Services</p>
<p>Bob Miller</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="4" rowspan="2"><p>Project Manager</p>
<p>Kevin Shaver</p></td>
<td></td>
<td colspan="3" rowspan="2"></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td colspan="4"><p>Sr. System Analyst</p>
<p>Jill Schwartz</p></td>
<td></td>
<td></td>
<td colspan="4"></td>
<td></td>
<td></td>
<td colspan="4"><p>Sr. Lead Developer</p>
<p>(Open)</p></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td colspan="2"><p>Sr. Developer</p>
<p>Communications Specialist</p>
<p>Jay Rosansky</p></td>
<td></td>
<td colspan="2">Sr. System Engineer</td>
<td></td>
<td colspan="2"><p>Tech Writer</p>
<p>Clerical</p>
<p>Graphic Arts</p></td>
<td></td>
<td></td>
<td colspan="2"><p>Mid Level</p>
<p>Progrmmr</p>
<p>(Open)</p></td>
<td></td>
<td colspan="2"><p>Mid Level Progrmmr</p>
<p>(Open)</p></td>
<td></td>
<td></td>
<td colspan="2"><p>Senior Progrmmr</p>
<p>(Open)</p></td>
</tr>
</tbody>
</table>

**3.6.1 Required Skills**

The **Project Manager PTE,** Kevin Shaver, will provide overall
technical expertise for the project and act as liaison to DOE
Management/CDSI Management. Further responsibilities will include
providing e-mail subject matter expertise, cost containment and
management/accountability of budgeted project dollars, project staffing,
and hardware/software procurement. He will be the key resource for
overseeing the day-to-day system development, and tracking software
development progress via Cross-Reference Matrixes. Further
responsibilities will include participation in the analysis and
selection of development environment, security, and will be
participating in system design issues and decisions, and EDI-compliance
of EC-Web. The **Project Manager/Planner** must be capable of developing
a project plan using a bottoms-up approach. This person must be able to
coordinate the activities of several persons who will provide the WBS
detail, project estimates, and dependencies. This person must be able to
work closely with the system owner on resolving issues and concerns
across organizations.

The **Senior Systems Analyst FTE**, Jill Schwartz must be capable of
interviewing end-users, capturing user wants and needs and translating
them into system requirements. This person must also be able to perform
an analysis of the requirements and develop a conceptual system
architecture.

The **Senior Lead Developer** must be able to produce the Design
Specification document and program an application based on the
Requirements Specification document and the Design document. This
position needs very little supervision. The Designer/Programmer is
responsible for delegating program assignments to the Programmer.

The **Programmers** must be able to program and unit test specific
modules of an application and using the Design Specification document.
This position needs to take direction from the Designer/Programmer.

The **Independent Tester** must be able to review the Requirements
Specification document and the Design document to determine testability
of functions described therein. The Tester must be able to design and
execute a System Test and Acceptance Plan based on the Requirements
Specification document. This position will work independently from the
development team to ensure an objective review of the products as they
are being delivered.

The **LAN Engineer, PTE,** John Li, must be able to document
requirements for the system to be installed on the PR LAN, install the
application, and write and execute a test plan that will determine
adherence to LAN response time standards for the HRIS system.

The **Documentation Specialist** must be able to write the EC-Web User
Manual in a Windows-based word processing package. This person must be
able to execute the application in order to capture screens for
placement into the manual. The Documentation Specialist must be able to
create the EC-Web User Manual with little supervision from the Project
Manager/Analyst.

The **Trainer** must be able, based on knowledge gained in the study of
the EC-Web User Manual, to prepare and execute a Training Plan for
approximately twenty users of the EC-Web application. The Trainer will
be assisted by the development team as needed.

The **Configuration Manager,PTE,** Kevin Shaver, must be able to write a
Configuration Management Plan (CMP) that identifies the project items
that will be placed under formal change management and the method by
which change against these items will be managed. This person must also
be able to execute the CMP, managing all changes from the Design through
Installation stages.

The **Acceptance Tester**, Ellen Colligan, must test the application
separately from the development team, as an advisor to the client. This
person must utilize the EC-Web User Manual to determine if *all the
processes* in the application are functioning correctly according to
that manual, and principles of user friendliness. This person will
perform his or her duties with very little assistance from the
development team in order to maintain objectivity.

The following chart depicts the roles and responsibilities of the
present CDSI EC team from a functional and technical perspective.

An additional chart will be developed that will merge the DOE and CDSI
project organizational hierarchy into one flow chart and depict the
roles and responsibilities for DOE and CDSI.

Figure 3. CDSI EC Project Team Functional Responsibilties

<table>
<colgroup>
<col style="width: 12%" />
<col style="width: 10%" />
<col style="width: 5%" />
<col style="width: 8%" />
<col style="width: 9%" />
<col style="width: 5%" />
<col style="width: 8%" />
<col style="width: 9%" />
<col style="width: 9%" />
<col style="width: 9%" />
<col style="width: 9%" />
</colgroup>
<tbody>
<tr class="odd">
<td></td>
<td></td>
<td colspan="4"><p>SHAVER</p>
<p>Project Management</p></td>
<td></td>
<td colspan="2"><p>BICOCCHI</p>
<p>Quality Assurance</p></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td colspan="2"><strong>FUNCTIONAL</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="2"><strong>TECHNICAL</strong></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td colspan="2" rowspan="2"><p>SCHWARTZ</p>
<p>Sr. Systems Analyst</p></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="2" rowspan="2"><p>ROSANSKY</p>
<p>Lead Datacom</p></td>
<td></td>
<td colspan="2" rowspan="2"><p>Lead Developer</p>
<p>To Be Named</p></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td colspan="2">Functional Requirements</td>
<td></td>
<td colspan="2">Program Management</td>
<td></td>
<td colspan="2">Security</td>
<td></td>
<td colspan="2">Design</td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td colspan="2">Testing</td>
<td></td>
<td colspan="2">Acquisition Installation</td>
<td></td>
<td colspan="2">GATEC Gateway</td>
<td></td>
<td colspan="2">Programming</td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td colspan="2">Support</td>
<td></td>
<td colspan="2">Configuration Management</td>
<td></td>
<td colspan="2">COMM</td>
<td></td>
<td colspan="2">System Administration</td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td colspan="2">Operations</td>
<td></td>
<td colspan="2">Quality Assurance</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="2">System Maintenance</td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td colspan="6" rowspan="6"></td>
</tr>
<tr class="even">
<td colspan="2">Training</td>
<td></td>
<td colspan="2"></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td colspan="2">Documentation</td>
<td></td>
<td colspan="2"></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td colspan="2">Application/Business Rules</td>
<td></td>
<td colspan="2"></td>
</tr>
</tbody>
</table>

**3.6.2 Resource Loading Chart**

A Resource Loading Chart will be submitted as part of the formal
response to the task assignment modification. This will be supplied in
the form of the CDSI Resource Planning Elements (RPE) system.

**3.7 Master Schedule/Project Deliverables**

+-------------------+--------+--------------------------+-------------+
| Stage of          | Stage  | Deliverable              | Deliverable |
| Development       | Comp   |                          | Completion  |
|                   | letion |                          | Date        |
| SYSTEM            | Date   |                          |             |
| DEVELOPMENT PHASE |        |                          |             |
+===================+========+==========================+=============+
| PLANNING STAGE    | 05     | Proposal                 | 02/01/97    |
|                   | /07/97 |                          |             |
|                   |        | EC-Web Project Plan      | 02/24/97    |
|                   |        |                          |             |
|                   |        | In-Progress Review       | 02/26/97    |
|                   |        | (CDSI)                   |             |
|                   |        |                          | 03/01/97    |
|                   |        | WBS                      |             |
|                   |        |                          | 03/01/97    |
|                   |        | Quality Assurance Plan   |             |
|                   |        |                          | 03/03/97    |
|                   |        | In Stage Assessment (QA) |             |
|                   |        |                          | 05/07/97    |
|                   |        | Exit Planning Stage      |             |
|                   |        | (DOE)                    |             |
+-------------------+--------+--------------------------+-------------+
| PREPARATION STAGE | 06     | Select Development       | 03/07/97    |
|                   | /14/97 | Environment              |             |
|                   |        |                          | 03/17/97    |
|                   |        | Acquisition and          |             |
|                   |        | Installation Plan        | 05/15/97    |
|                   |        |                          |             |
|                   |        | Functional Requirements  | 06/09/97    |
|                   |        | Doc.                     |             |
|                   |        |                          | 05/16/97    |
|                   |        | Concept of Operations    |             |
|                   |        |                          | 06/10/97    |
|                   |        | Configuration Mgmt       |             |
|                   |        | Strategy                 | 06/13/97    |
|                   |        |                          |             |
|                   |        | In Stage Assessment (QA) | 06/16/97    |
|                   |        |                          |             |
|                   |        | In-Progress Review       |             |
|                   |        | (CDSI)                   |             |
|                   |        |                          |             |
|                   |        | Exit Preparation Stage   |             |
|                   |        | (DOE)                    |             |
+-------------------+--------+--------------------------+-------------+
| SOFTWARE DESIGN   | 08     | Design                   | 07/01/97    |
| STAGE             | /05/97 | Entities/Dependencies    |             |
|                   |        |                          | 07/01/97    |
|                   |        | Logical Model            |             |
|                   |        |                          | 07/01/97    |
|                   |        | Table Structures         |             |
|                   |        |                          | 07/01/97    |
|                   |        | Database Schema          |             |
|                   |        |                          | 07/15/97    |
|                   |        | Functional Design        |             |
|                   |        | Document                 | 07/16/97    |
|                   |        |                          |             |
|                   |        | Screen Designs &         | 07/15/97    |
|                   |        | Demonstration            |             |
|                   |        |                          | 07/31/97    |
|                   |        | Cross Reference Matrix   |             |
|                   |        |                          | 07/31/97    |
|                   |        | In-Progress Review       |             |
|                   |        | (CDSI)                   | 07/21/97    |
|                   |        |                          |             |
|                   |        | DISCAS Security Plan     | 07/31/97    |
|                   |        |                          |             |
|                   |        | EC-Web Security Plan     | 07/31/97    |
|                   |        |                          |             |
|                   |        | Training Plan            | 07/31/97    |
|                   |        |                          |             |
|                   |        | System Test/Acceptance   | 08/04/97    |
|                   |        | Plan                     |             |
|                   |        |                          | 08/04/97    |
|                   |        | Conversion Plan          |             |
|                   |        |                          | 08/05/97    |
|                   |        | Programming              |             |
|                   |        | Specifications           |             |
|                   |        |                          |             |
|                   |        | In-Stage Assessment (QA) |             |
|                   |        |                          |             |
|                   |        | Exit Software Design     |             |
|                   |        | Stage (DOE)              |             |
+-------------------+--------+--------------------------+-------------+
| PROGRAMMING AND   | 11     | Site Installation Plan   | 09/30/97    |
| INTEGRATION STAGE | /30/97 |                          |             |
|                   |        | In-Progress Review       | 10/20/97    |
|                   |        | (CDSI)                   |             |
|                   |        |                          | 11/15/97    |
|                   |        | Mappings                 |             |
|                   |        |                          | 11/18/97    |
|                   |        | Software                 |             |
|                   |        |                          | 11/18/97    |
|                   |        | System Documentation     |             |
|                   |        | (draft)                  | 11/21/97    |
|                   |        |                          |             |
|                   |        | In-Stage Assessment (QA) | 11/28/97    |
|                   |        |                          |             |
|                   |        | Exit                     |             |
|                   |        | Programming/Integration  |             |
|                   |        | Stage                    |             |
+-------------------+--------+--------------------------+-------------+
| SYSTEM TESTING    | 03     | Test Results             | 02/02/98    |
| AND ACCEPTANCE    | /15/98 |                          |             |
| STAGE             |        | Operational System       | 02/03/98    |
|                   |        |                          |             |
|                   |        | In-Stage Assessment (QA) | 02/16/98    |
|                   |        |                          |             |
|                   |        | System Documentation     | 02/27/98    |
|                   |        | (final)                  |             |
|                   |        |                          | 03/02/98    |
|                   |        | In-Progress Review       |             |
|                   |        | (CDSI)                   | 03/16/98    |
|                   |        |                          |             |
|                   |        | Exit Testing/Acceptance  |             |
|                   |        | Stage (DOE)              |             |
+-------------------+--------+--------------------------+-------------+
| Exit Phase        | 03     |                          |             |
|                   | /30/98 |                          |             |
+-------------------+--------+--------------------------+-------------+

**4. TECHNICAL APPROACH**

In anticipation of this effort and in response to DOE direction, CDSI
has begun analyzing EC-Web development technologies and services. To
date, the CDSI EC Team has conducted a market analysis including
identifying different products, tools, modules, and interfaces that are
either sold as custom off-the-shelf (COTs) applications, plug-ins,
separate modules, development tools, or a complete suite of integrated
products. The table shown on the following page identifies the various
products, tools, models, and interfaces that are being considered for
use in the development of the EC system.

  ------------- -- -------------- -- ------------- -- -------------- -- -----------------
  Visual J++                                                            Oracle

  NetDynamics      Lotus/Domino      Lotus Script     Notes/Domino      Notes (Unix or
                                                                        NT)

  Lotus                                                                 

  Visual Basic,    Netscape          PL/SQL           Oracle Web        MS SQL Server (NT
  etc.                                                Server            only)

  C++                                                                   

  Oracle Tools     MS                Java             Net Dynamics      

  LiveWire                                                              

                   O\'Reilly         VB/Active X      MS products       

                                                                        

                                                                        

                                                                        

  Development      Web Server        Application      Middleware        DBMS (HW/OS)
  Tools                                                                 
  ------------- -- -------------- -- ------------- -- -------------- -- -----------------

In the preparation phase, three development platforms illustrated above
are assembled and are evaluated while recruiting activities being put in
place to staff this project. Specifically, the development environment
will be defined, configured, and documented in a Concept of Operations
document to be reviewed and approved by DOE. The analysis will be
conducted by installing each option in a test-bed environment and
performed hands-on analysis. To prepare for this analysis, CDSI has
obtained evaluation copies of the identified software suites and using
the DOE HQ SPS implementation hardware to configure the development
environment. This includes Pentium development work stations, the Compaq
Proliant database server, and the Compaq Pro Signia file server. The SPS
configuration includes Windows NT and SCO Unix operating system as well
as Oracle RDBMS v7.x and user licenses.

Although it has been determined that the SPS hardware configuration will
meet the requirements for the development environment platforms, it is
anticipated that there will be additional costs associated with
assembling the development environment. A Acquisition and Installation
Strategy will be presented listing the projects hardware and software
cost associations as well as detailing a plan for installing and
configuring the development environment.

Once the preparation phase has been completed, the CDSI team will be
prepared to move into the remaining phases. The design, development, and
testing phases will proceed as defined. However, the deployment phase,
including training, support, and vendor outreach are specific to the DOE
Headquarters Procurement Operation Division. Once the Division is
on-line, the DOE EC program leadership will need to determine further
deployment and training schedules.

**4.1 Programming Languages**

Several options are being explored for the proposed programming language
for the development of EC-Web: Lotus Notes 4.5 and Domino, Lotus Script,
C, C++, and Java. In addition to the programming language options, Lotus
Notes also provides several templates that can be modified for various
applications. The programming tools incorporated in the features
available within the Notes and Domino suites may be suitable for forms
creation. The object oriented software development tools within Notes
and Domino can also be utilized. The routing requirements of EC can be
accomplished by utilizing the Workflow applications within Notes. Domino
can provide the Web Development tools to create and customize the WWW
interfaces necessary for EC. Intranet development and integration can
also be accomplished by the Domino development tools. Domino
applications can be accessed directly by any standard WWW browser.
CGI-BIN scripting will accommodate the unique requirements that may
occur between the data base and external systems.

Another option is Oracle EC and Webserver which is the Oracle suite
consisting of Oracle Workflow, Oracle WebServer and additional modules
that complement the main suite of applications. Oracle provides
templates that may be modified and customized for particular
requirements. Oracle Developer 2000 incorporates utilities and tools to
program complex SQL statements with the assistance of simple GUI
interfaces. The new 5GL programming toolkits are integrated within the
Oracle suite of applications. Oracle Webserver provides the development
facilities to design and create large complex data bases integrated to
WWW. Intranet development and integration will be accomplished by
implementing the HTML and Java design tools.

**4.2 Security**

Security is a critical component of conducting Electronic Commerce
effectively. Several measures will be implemented to protect the
integrity of the DOE EC System, the EC-Web procurement application, and
the financial system, DISCAS.

Separate security plans identifying risks associated with the system and
detailed countermeasures that will be in place to minimize security risk
will be documented in the EC Security Plan and the DISCAS Security Plan.

Both Security Plans should be acknowledged and approved by the DOE
Headquarters and Field Sites before implementation of the EC system.

**4.3 Hardware/Software Requirements**

Specific hardware/software requirements will be finalized in the
Preparation Stage, upon the completion of defining the software
development environment. Each end user is required to have a Netscape
browser or equivalent, that will be necessary for accessing EC-Web.
Hardware/software requirements will be detailed in the Acquisition and
Installation Plan.

**4.4 Configuration Management**

Software Configuration Management activities will begin within the
Software Design Stage and continue throughout the System Enhancement
Stage that will occur when the system is operational. All CM activities
will commence upon the approval of the Functional Requirements Document
scheduled for preparation and approved within the Preparation Stage by
April 7, 1997. The Software Configuration Management Guide (SCMG) will
be used as a guide for managing the software product life cycle for this
project. The following CM activities will have procedures in place for
each stage of this project:

Identification of software configuration items

Change control procedures for software configuration items

Auditing

Status Accounting

**4.5 Change Control Process**

A Configuration Management Plan (CMP) will be developed to control
changes directly affecting the procurement application software and
documentation during the initiation, development, and operation phases
of the EC system. Every effort will be made to ensure that changes will
not compromise the data or system integrity.

The Functional Requirements Document and System Design Document will be
used as tools to baseline the system. All future changes and
modifications requiring further development that may change the baseline
will be changed only via the formal change control procedures
established.

A Change Control Board (CCB) will be formed and will evaluate and
approve proposed engineering changes and ensure the implementation of
the approved changes.

Any requirements added after the Preparation and Design Stage will
require mutual agreement on the part of the CCB and any respective
approvers. Any impact on the scheduled deliverable dates will be
addressed prior to incorporating the change. Change initiation, logging,
evaluation, and approval procedures will be detailed in the CMP.

**Ellen Colligan,** The person authorized to request
modifications/additions to the baseline

**POC** requirements.

**Kevin Shaver,** The person that will receive modification requests and
coordinate a

**Project Manager** project-wide impact assessment for determining the
scope of effort and time estimate for implementing change.

**Steve Mournighan,** The person authorized to review modification
requests and the impact

**System Owner** assessment, and approve or disapprove the
implementation.

All approved changes and their impact on the project schedule and budget
will be reviewed at each Stage Exit and the Project Plan will be
adjusted accordingly.

**4.6 Testing Strategy**

Because of the intricate interfaces and components of the entire EC
system, a detailed Test Plan will be used for verifying the accuracy of
data and flow of documents throughout the system. The System Testing and
Acceptance Stage will be used to execute the Test Plan that will
incorporate the following activities:

Component Testing

Integration Testing

System Testing

Acceptance Testing

The Test Plan will be produced in the early part of the Programming and
Integration Stage. Component and integration testing will be included in
the programmer's individual work plans.

System testing will include testing for functionality and operation of
the system in its intended production environment. \'Live Buys\' will be
issued as a measurement of success for the system test.

The System Test Plan will include the generation and execution of test
case scenarios, mappings to ANSI X12 requirements, and tracking and
reporting of defects. Acceptance testing will include testing of
end-user functionality. Acceptance testing conducted on the operational
system will determine if the system is acceptable by DOE.

**4.7 Quality Assurance**

Quality Assurance for this project will include an In-Stage Assessment
(ISA) conducted near the end of each stage of development. The ISA is
the DOE standard to assure that the established system development and
project management processes and procedures are being followed
effectively, and exposures and risks to the current plan are identified
and addressed.

The Quality Assurance Consultant, Andy Bicocchi will provide quality
assurance support throughout the duration of the project. Andy will
provide a position at each stage exit based upon his ongoing involvement
in the project.

A Software Quality Assurance Plan (SQAP) will be delivered in the
Planning Stage of this project and will provide a foundation for
managing the software quality assurance activities for the System
Development Phase.

This position will work independently from the development team to
ensure objective audits of the work products as they are being developed
and objective reviews of project management processes and stage
checkpoints.

This Software Development Plan will be used as a guide by the Quality
Assurance Consultant. Quality Assurance for EC-Web will include audits
for quality and validity of current draft deliverables and selected work
products within each stage of development. Each In-Stage assessment will
be documented and associated with a risk category of low, medium, or
high, on the project schedule, determined by the Quality Assurance
Consultant. Issues will be documented in an In-Phase Review Report, that
will be used to track pending and resolved issues or concerns.

**4.8 Defect Prevention**

In addition to removing defects from program code and system
documentation during the various levels of testing, several steps will
be taken at every stage of development to prevent defects from being
introduced in the first place. These steps will include:

! Document deliverables: All documents will be subjected to peer reviews
by the CDSI EC Team to help ensure both completeness and accuracy of
technical content. In addition, document drafts will be provided to DOE
for review and comment as soon as practical, to allow for early
feedback.

! Program code: All program modules will be subjected to Structured
Walkthroughs and/or code inspections to help remove design and coding
defects before test execution.

! Project plans: All project plans will undergo peer reviews and/or
Structured Walkthroughs to help ensure all project activities have been
accounted for, and to promote early alignment with other persons or
organizations upon whom this project has a dependency.

! Test cases: All test cases will be inspected by the EC Test Team to
help ensure they are measurable, complete, and appropriate for the
function or system scenario to be tested.

**4.9 Training**

A formal training structure will be developed combining classroom style
training, independent end-user training via manuals and on-line help,
and train-the-trainer programs. Several topics will be covered within
the training program; including EC-Web training, Electronic Commerce
training, and overview for EDI. Each training class will have
documentation and instructions guiding end-users where to obtain
additional information as needed.

System Administration Training will also be conducted for each field
sites system administrator. It is envisioned that a separate training
class will be held based upon roles and responsibilities within the
procurement application. For example, Requisitioners will have different
training classes than Funding Managers.

**4.10 Documentation**

The traditional system documentation as prescribed by the SEM is planned
to be produced for this project. Planned documentation includes:

! User\'s Guide

! Programmer's Reference Manual

! System Administration Manual

! Database Administration Manual

! Operations and Support Manual

Refer to the Master Schedule/Project Deliverables for additional
documentation that is planned for this project.