sevis ii: a way ahead

SEVIS II: A Way Ahead

Whitemarsh Information Systems Corporation2008 Althea Lane

Bowie, Maryland 20716 Tele: 301-249-1142

Email: [email protected]: www.wiscorp.com


Table of Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.0 Whitemarsh Information Systems Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.0 Activities between March 2009 and Early October 2009 . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.0 Activities Between October 2009 and October 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.0 Activities During November and December 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.0 Activities during the Fall of 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.0 A Way Ahead for SEVIS II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.1 Integrated Work Through Metadata Management System . . . . . . . . . . . . . . . . . 136.2 End-to-End Methodology and WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.3 Data Management as Linking Critical Path Component . . . . . . . . . . . . . . . . . . . 316.4 Specification Iterative Development and Convergence Through Prototyping. . . 346.5 Waterfall and Iterative Methodology Implementation Approach . . . . . . . . . . . . 37

7.0 SEVIS II Way Ahead Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.1 RFP Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2 Development Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.3 Operations and Maintenance Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A01 Letter01 One of Four_Evaluation of the Accomplishment of the SEVIS IVV

SOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A02 Letter02 Two of Four_Evaluation of the Technical Process of IV&V Tracing

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A03 Letter03 Three of Four_SEVIS II Data Management Documents Inventory on

Burke Consortium Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A04 Letter04 Four of Four_Weekly Summaries of Data Management IVV Work at

Burke Consortium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53A05 SEVIS II Data Management IV&V Concerns_With Consequences . . . . . . . . . . 54A06 Data Management Issues_2009_05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A07 Data Management IVV Architecture and Concept of Operations . . . . . . . . . . . . 56A08 Data Model Evaluation September 29 2009 Data Models . . . . . . . . . . . . . . . . . 57A09 DMConcern_Reference Data_OPR Document_03 . . . . . . . . . . . . . . . . . . . . . . . 58A10 SEVIS II Data Management Analysis_02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Whitemarsh Information Systems CorporationCopyright, 2011, All Rights Reserved

ii


A11 Business Events and History_Whitepaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60A12 DMConcern_Reference Data_Whitepaper_02 . . . . . . . . . . . . . . . . . . . . . . . . . . 61A13 OPR_Business Transaction History_20090720 . . . . . . . . . . . . . . . . . . . . . . . . . . 62A14 OPR_Data Management Four Problem Areas_04_24_09 . . . . . . . . . . . . . . . . . . 63A15 OPR_Data Management_DM Maturity Review_04_24_09 . . . . . . . . . . . . . . . . 64A16 OPR_Data Management_Use Case Review_04_24_09 . . . . . . . . . . . . . . . . . . . 65A17 OPR_Data Management_WBS DM Review_05_15_09_ . . . . . . . . . . . . . . . . . . 66A18 Requirements Process Sessions, Data Models, and Data Management QA

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A19 Wayne Smith Proposal_2010_10_07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68A20 Paul Martindale Letter_2010_12_06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A21 Data Management IV&V_2011_11_29 Architecture and Concept of Operations70A22 Metabase System Data Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A23 Whitemarsh DHS/ICE Presentation on RFP Development . . . . . . . . . . . . . . . . . 72A24 Whitemarsh Methodology WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A25 Data Management Documents Created by Whitemarsh vs documents obtained by

DHS/ICE from IV&V Contractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74A26 Text of Email that identified the quantity of Whitemarsh work products

accomplished on SEVIS II for DHS/ICE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75A27 Revised Business Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76A28 Revised Reference Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A29 Manufacturing Project Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A30 Whitemarsh Project Methodology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A31 Modeling Data and Designing Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80A32 Metabase Rationale and Knowledge Worker Framework With Meta Models

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81A33 Gorman_At Burke_Documents List_Computer Directory Listing . . . . . . . . . . . 82


iii


Figures

Figure 1. Traditional approach to methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 2. Iterative requirements development through prototyping. . . . . . . . . . . . . . . . . . . . . . . 21Figure 3. Parallel implementation starting at the end of the Conceptual Specification phase. . . 21Figure 4. Continuous flow model with metadata management system at its core. . . . . . . . . . . . 26Figure 5. Package Development Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 6. Package work product interactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figure 7. Product development life cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figure 8. Illustration of the need to make changes across functional area products. . . . . . . . . . 31Figure 9. Integration of work products with data models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figure 10. Illustration of the life cycle cost components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 11. Interrelationship between Metabase System and Clarion business information system

generator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figure 12. Overall methodology flow to create functional area product prototypes. . . . . . . . . . 36Figure 13. Approach to best use of SEVIS II A Way Forward materials . . . . . . . . . . . . . . . . . . 38


iv


Tables

Table 1. Knowledge Worker Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Table 2. Business Information System Functions addressed by the Knowledge Worker

Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Table 3. Top level Whitemarsh methodology phases and tasks. . . . . . . . . . . . . . . . . . . . . . . . . . 20Table 4. Multiple contractor approach to SEVIS II Requirements through Production Phases. . 24Table 5. Methodology Phases and Involved Metabase Modules . . . . . . . . . . . . . . . . . . . . . . . . 25Table 6. Cross reference among business information system work product . . . . . . . . . . . . . . . 33Table 7. Attachment documents support for SEVIS II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


v


Executive Summary

This report, SEVIS II: a Way Ahead is provided to the Program Management Office byWhitemarsh Information Systems Corporation in support of the development of a way forwardfor the SEVIS II database and information system. This report is based on the following:

! Adverse finding reports and other documents created by Whitemarsh between March2009 and early October 2009

! Four Whitemarsh after-action letters sent to American Systems Corporation.

! Revisions of several key documents critical to the successful completion of SEVIS II.

! Whitemarsh strategy for the creation of operational functional prototypes as thefoundation for an implementation RFP

! Whitemarsh letter that identifies the need for a set of robust PMO activities in support ofa successful implementation of SEVIS II.

The sections of this report are:

! Whitemarsh Information Systems Corporation

! Activities between March 2009 and early October 2009.

! Activities between October 2009 and October 2010

! Activities during November and December 2010

! Activities during the Fall of 2011

! Way ahead for SEVIS II

! Way ahead recommendations for SEVIS II

! Attachments

The first five Sections take only about 10 pages as the goal of these sections is to merely identifythe problems known to the Data Management IV&V.. The next 30 pages focus on the way aheadby applying the lessons learned and setting these lessons learned squarely inside tools,


1


techniques, methodologies, courses, seminars, and workshops that, if followed will all likelyassure the success of this next round of SEVIS II..

The main body of the report contains references to specific attachments and subsectionswithin the attachments. The general approach to the activity sections is to present the eventschronologically with references to attachments so that the events and their import can beunderstood.

That SEVIS II failed to be successfully implemented is well known. The reasons for thisfailure are also well known and the strategies to prevent the failure were well known.Whitemarsh recognized the high likelyhood of failure and made immediate recommendations toprevent failure during the first several weeks after Whitemarsh started its data managementIV&V engagement. Two recommendations were provided to the IV&V contractor. First that alldeliverables be stored as database records in a metadata database so that there could be completeintegration, interoperability, and non-redundancy across all work product deliverables.Whitemarsh offered to provide its metadata management system, Metabase at no cost to theIV&V contractor for just that purpose. This would have enabled end-to-end traceability acrossall delivered work products.

Second, all use cases should have, in conjunction with the already developed data model,been code-generated into function-based operational prototypes. Such prototypes could havebeen completed within 10% extra of the funds allocated to use-case discovery and formulation.Not only would this have provided immediate, hands-on feedback of use cases to the SEVP andState Department teams, it would have enabled quick and almost continuous advancement of theoverall state of SEVIS II system specifications in an integrated, interrelated and non-redundantmanner. At the conclusion of these operational prototype developments and evolutions, SEVIS IIwould have had a comprehensive, stable and thoroughly end-user reviewed and revisedimplementable specification that could have been used for implementation.

John Zachman, known for the Information System Architecture framework that isemployed throughout the Federal Government, and is the basis for the key Federal CIO referencemodels is often quoted as follows:

“Someday, you are going to wish you had all those models, Enterprise wide,horizontally and vertically integrated at an excruciating level of detail.”

This became painfully true in the case of this round of SEVIS II implementation.


2


1.0 Whitemarsh Information Systems Corporation

Whitemarsh Information Systems Corporation has been serving the data management needs ofboth industry and government for 30 years. Founded in 1981, Whitemarsh is a State ofMaryland corporation located in Bowie, a suburb of Washington, D.C.

Whitemarsh’s clients come from a wide variety of industries, including both federal andstate governments.

Whitemarsh's founder, Michael M. Gorman, has been involved in data managementfull-time since 1969. Mr. Gorman, is a charter member of DM32.2 (started as X3H2). DM32.2is the American National Standards Institute (ANSI) International Committee on InformationTechnology Standards (INCITS) Technical Committee on Database Languages. Mr. Gorman hasbeen the committee’s secretary since 1978, and as such is a co-author of all the ANSI databaselanguage standards, which primarily are SQL.

The Whitemarsh product line is designed to help organizations achieve enterprisedatabase. From 1981 to the present, every Whitemarsh Database project has been a success.That's because of active client participation, quality estimates, and careful monitoring andtracking to ensure that forward progress is the norm.

The Whitemarsh product line has been developed through a single, unified, andintegrated product organizational structure that causes all the training, consulting, softwareproducts and methodologies to be closely aligned. It includes, for example, the engineering,architecture, methodology, courses and seminars for an entire data management program isavailable from Whitemarsh.

Whitemarsh through Mr. Gorman, has brought database and DBMS to over 30 Federalagencies including HUD, USDA, Army, Navy, Air Force, EPA, Energy, Commerce, Office ofPersonnel Management, DHS/ICE, Freddie Mac, and USGS; worked with state governmentsincluding California, Delaware and the Ohio Supreme Court; and worked with industrial clientsincluding Bank of America, Hartford Insurance, CareFirst, Du Pont, Hershey, and Mars.

For clients, Whitemarsh designed, developed and installed database designs, dataarchitectures, and management information systems dealing with finance, housing, justice, courtmanagement, manufacturing, public safety, inventory management, logistics, human resources,environment, education, and national defense.

The Whitemarsh website, www.wiscorp.com, contains an extensive list of clients andtheir use of Whitemarsh products, a set of downloadable data management oriented materialsincluding Short Papers, and Metabase System documents and descriptions, and finally,collections of documents related to:

! Enterprise Database! Database Objects! Database Design! Database Management Systems (DBMS)! Database Projects

! Metabase System! Data Quality! Process Modeling! General Topics


3


2.0 Activities between March 2009 and Early October 2009

DHS ICE had an IV&V contract with Burke Consortium, hereinafter referred to as IV&VContractor. In turn, Burke Consortium had a subcontract with American Systems, which, in turn,had a contract with Whitemarsh Information Systems Corporation (hereinafter referred to asWhitemarsh) to perform the data management IV&V services. Whitemarsh worked 100% of thetime at the offices of Burke Consortium under the daily and direct supervision of the IV&VTeam Lead. The SEVIS II implementation contractor, Booz Allen Hamilton (BAH) ishereinafter referred to as Implementor.

The IV&V contract that DHS ICE had with Burke Consortium was from the DHS ICEOCIO Systems Development Division (SDD) SEVIS II Project Manager, and the contractnumber was HSHQDC-06-D-00065-HSCETC-08-J-00020.

The Whitemarsh effort at the IV&V Contractor’s office extended from late March, 2009through the end of the first week of October, 2009. The assignment ended when the IV&Vcontractor indicated to American Systems that there was no need for a data managementconsultant on the project.

During the six months of data management IV&V work, Whitemarsh generated 19Adverse Findings documents and two document collections of daily and weekly activity logreports. See Attachment A3. None of these 21 documents, were, to the best of Whitemarsh’sunderstanding, provided to DHS/ICE PMO except one. It was an OPR (Observed Potential Risk)document regarding Business Event Management. The names and descriptions of the 19 AdverseFindings documents are listed in Attachment 3.

After the Data Management IV&V effort concluded in early October, 2009, Whitemarshsent an email to DHS/ICE stating that it hoped that the various adverse findings documentshelped in the PMO’s deliberations. It was subsequently learned by Whitemarsh during thesecond half of October 2009 that some of those documents were obtained by DHS/ICE from theIV&V contractor. 15 documents were provided by a member of the DHS/ICP PMO toWhitemarsh upon written request in December 2010. Six of the 15 documents obtained byDHS/ICE are not listed in Attachment 1. Thus, only 9 of the 19 adverse findings documents wereprovided to DHS/ICE by the IV&V contractor. Column 2 from Attachment 25 indicates which ofthe 19 documents were obtained by DHS/ICE from the IV& V Contractor. When the Entry Id ismarked by “—“ it means that the document was not in the list contained in Attachment 3.

The first Adverse Findings document was a 20 page matrix (Entry 1 from AttachmentA3) that contained an analysis of the January 2009 data models. It was developed so that theImplementor could make early corrections prior the development of significant quantities ofsoftware.

During the beginning of the IV&V assignment, Whitemarsh developed an DataManagement IV&V Architecture and Concept of Operations document. See Entry 2, from withinAttachment A3 and also Attachment A3). This 60 page document was developed over a threeweek period and was to be submitted, reviewed, revised, and once approved, set into motion bythe PMO of DHS/ICE. This IV&V work plan enabled a detailed analysis of the various SEVIS II


4


data models, an analysis of the data model effects on a number of other Implementor workproducts, and the use of data models as a way to support detailed traceability among the workproducts.

The IV&V contractor was required to develop bi-monthly IV&V status reports. The firstdocument that was to contain Data Management IV&V material was for 30 April, 2009. 18specific items were created and a new section for the IV&V report was created. This new sectionwas however excluded by the IV&V contractor from the submitted document. See Entry 4 fromwithin Attachment #3. This document was not obtained by DHS/ICE.

During late May, 2009, the Implementor submitted a Data Management Plan. See Entry 5within Attachment A3. This document was not obtained by DHS/ICE. A review of thatdocument was created and it contained over 30 items, 13 of which were “red.” The overall planwas judged to be “red.”

During May, 2009, a review of the Data Conversion Plan was undertaken. See Entry 6from within Attachment A3. This document was not obtained by DHS/ICE. Over 30 items werenoted. They were all in the “orange” category.

During the first half of June, 2009, and extensive analysis was conducted on the Product6 Use Cases. See Entry 7 from within Attachment A3.This document was not obtained byDHS/ICE. A total of 16 different use cases were analyzed and each analysis contained several subsections of analysis including data management, data conversion, System RequirementsDocument, System Design Document.

During the middle of June, a Data Management Concerns document was created thatlisted and described 11 SEVIS II areas. See Entry 8 from within Attachment 3. This documentwas not obtained by DHS/ICE. These included: Batch, SQL Views, DBMS Backup andRecovery, Performance Tuning, Logical and Physical Reorganization, Data Security, ReferenceData Management, Data Warehousing and Business Intelligence (a.k.a., reporting), Data Qualityand Integrity management, and User Acceptance Testing.

During June, the Help Desk Plan was reviewed. See Entry 9 from within Attachment 3. This document was not obtained by DHS/ICE. While the overall content of the Help Desk Planwas deemed acceptable, it was clearly stated that the Help Desk staff’s materials should mainlybe drawn from a comprehensive metadata database of all SEVIS II specification, implementationartifacts, and operations user guides and manuals. These suggestions were excluded from theIV&V document review that was submitted by the IV&V contractor to DHS/ICE.

During late June, an extensive data management concerns analysis was undertaken andthe I-17 document was employed as the example for all the data management issues. See Entry10 from within Attachment A3. This document was not obtained by DHS/ICE. The analysiscontained in this document focused on business event history and the key analysis areas wereaudit trails, history and business transactions, reference data management, business rulemanagement, and end-user reporting.

During late June, a four page document was created that listed and briefly described the18 data management issues that needed to be addressed by the Implementor. See Entry 11 fromwithin Attachment A3, and see Attachment A5. It was expected that there would be several day


5


meeting with the Implementor to discuss these issues with the presumption that corrections, asappropriate, would be accomplished by the Implementor. The IV&V contractor, howeverprevented the presentation of all 18 items. Only 5 issues were allowed to be presented. Theactual one-page document that was allowed to be shown the Implementor is Attachment A6.

During late June, a Communications Plan was reviewed. See Entry 12 within AttachmentA3. This document was not obtained by DHS/ICE. The findings and recommendationsdeveloped by Whitemarsh related to the manner of the development of findings, minutes, actionsitems, and recommendations. The results of this analysis was not included in the IV&V reviewdocument submitted DHS/ICE.

From late June through mid August, a very extensive and thorough analysis and reviewwas undertaken of the SEVIS requirements documents related to the proper capture, storage, andretrieval of event histories. See Entry 13 from Attachment A3, and see Attachment A11 andA13. This was a SEVIS II showstopper. The SEVIS II data model was glaringly lacking when itcame to the proper capture of SEVIS event histories. This issue was so consequential that theWhitemarsh demanded that it be allowed to directly present this issue to DHS/ICE. The requestwas disallowed. Instead, a two page OPR was permitted to be sent to DHS/ICE with theassumption that if there was interest, a request for further information would be forthcoming.Whitemarsh understands that this issue was not included in IV&V report to DHS/ICE.

From late June through mid August, a lesser analysis and review was undertaken of allthe different types of reference data involved in SEVIS II. See Entry 14 from Attachment A3,and Attachments A09 and A12. The critical issue with the SEVIS II data model was that it wasnot addressing reference data in any comprehensive way. It is Whitemarsh’s understanding thatthis issue was not communicated by the IV&V contractor to DHS/ICE.

During the middle of August, a short and informal white paper was created discussed theissues surrounding the process of requirements analysis especially as it related to datamanagement. See Entry 15 from Attachment 3, and Attachment A18. It had been expected thatthese observations and recommended solutions to the problems would be communicated toDHS/ICE.

During the middle of August, a multiple-page check list for evaluating external datasources involved with SEVIS II was developed. See Entry 16 from Attachment A3. Thisdocument was not obtained by DHS/ICE. The objective of this check list was to guide evaluatorsin the assessment of the completion of external data source interfaces in terms of data structureand processes for both importing and exporting.

During late August, a multiple-page check list for evaluating the delivery of a collectionof data models for SEVIS II was developed. See Entry 17 from Attachment A3. This documentwas not obtained by DHS/ICE. This document brought forward all the previously existing datamodel evaluations accomplished to date. The objective of this check list was to guide evaluatorsin the assessment of the data models that were expected to be delivered by the Implementorduring the month of September.

During late September, a 100 page document was created that identified and cataloguedall the reference data that was associated with SEVIS II. See Entry 18 from Attachment A3.


6


This document was not obtained by DHS/ICE. This large document identified reference dataaccording the strategy set out in Entry 14 from Attachment 3 and Attachment 9. The objective ofthis document was to provided the Implementor a comprehensive check list of all the referencedata that had to be address for the successful implementation of SEVIS II.

During the first week of October, a 55 page analysis of the SEVIS II data models wascompleted. See Entry 19 of Attachment 3, and Attachment A08. Whitemarsh was instructed thatthis analysis had to be completed in just one work week. The data models were assessed againstthe previously created data model check list that described in Entry 17 of Document #3. To havefully created a thorough analysis and to understand the full implications against all the existinguse cases would have taken several additional months. This analysis was cross-referenced into13 different data management issues that were identified at the end of Attachment 08.

3.0 Activities Between October 2009 and October 2010

Immediately after the end of the Whitemarsh Data Management IV&V engagement, four afteraction letters were created for American Systems. These four American Systems letters areAttachments 1, 2, 3, and 4. The four letters are:

! Attachment 1: An overall review of the IV&V effort that has been accomplished on the SEVIS IIeffort.

! Attachment 2: A specific review of the Technical Activities Development Process part of theIV&V Effort.

! Attachment 3:An enumeration and brief description of 21 different Data Management IV&Vdocuments that were created by Whitemarsh during this effort.

! Attachment 4: Weekly summaries including citations of developed documents/materials ofWhitemarsh IV&V efforts.

The first American Systems letter, Attachment A01, sets out a list of IV&V activities containedin the IV&V work plan that had been submitted to DHS/ICE and set into motion: This set ofactivites are:

1. Project Management Activitiesa. Project Managementb. Technical and Operational Documentation

2. Technical Activitiesa. Task Managementb. Acquisition Processc. Project Supply Processd. Development Process


7


i. Planning /Concept Activityii. Requirements Activityiii. Design Activityiv. Development/Implementation Activityv. Test Activityvi. Installation and Checkout

e. Operations Processf. Maintenance Process

An analysis of the IV&V bimonthly reports showed that the only activities that wereaccomplished were those associated with Project Management. While there were no explicitactivities associated with data management, it is clear that these would exist as a threadthroughout the Technical Activities. The Data Management IV&V Architecture and Concept ofOperations document (see Attachment A07) served to guide the activities regarding theassessment of data models during the six months of Whitemarsh data management IV&Vactivities.

The second American Systems letter, Attachment A02, details across seven pages theoverall approach to conducting the Technical set of IV&V Activities. This letter focused on theflawed approach taken by the Implementor to the development of the implementationspecifications of SEVIS II. The Implementor chose an iterative methodology approach ratherthan a waterfall methodology approach. This choice set the project up for failure. That wasbecause as SEVIS II was being implemented for early SEVIS II functional area products (e.g. anI-17), requirements for later SEVIS II functional area products were still being created. Evenmore problematic was the fact that two of the later-most products would have significant changeeffects on functional area products that had been implemented as production-class softwaremuch earlier. Both database and functional process changes discovered in the later SEVIS IIfunctional area products required changes in the architecture, design, and implementation ofalready developed production software. This issue is addressed in greater detail in Section 6.2,End-to-End Methodology and WBS.

The solution to the methodology impedance mismatch is well known and has beensuccessfully accomplished over many years. These problems and proposed methodology changesolutions were communicated to the IV&V contractor within the first month of Whitemarsh’swork as the Data Management IV&V contractor. Attachment A18 documents many of theseissues. Attachment A24, initially published almost 30 years before the start of this project,precludes the very problems that SEVIS II encountered. Whitemarsh has books, papers,methodologies, and Metabase System software that prevents these problems from arising.

The third American Systems letter, Attachment A03, identifies, as best recollectedthrough notes developed at Whitemarsh offices, the identification and descriptions of all theWhitemarsh work products created during its six months of Data Management IV&V. A33contains the file names and directory references to all the documents created for SEVIS II byWhitemarsh as these files existed on the IV&V contractor’s computers. If DHS/ICE obtained all


8


the directories and files that were on the IV&V computers then all the Whitemarsh documentsshould be on those hard drives.

Attachment A25 contains the identification and description of six (6) additionaldocuments that were created by Whitemarsh. These additional six documents along with nine (9)others were obtained by DHS/ICE from the IV&V contractor. That leaves 10 IV&V documentsthat were created by Whitemarsh that were not obtained by DHS/ICE from the IV&V contractor.

Whitemarsh was precluded through explicit instructions from the IV&V contractor fromproviding these work products to American Systems as they were created . According to theIV&V Contractor’s American System Subcontract, these documents were required to bereviewed by American Systems and were required to be submitted concurrently to DHS/ICE andto the IV&V contractor.

The fourth American Systems letter, Attachment A04, presents the weekly summaries ofthe data management IV&V activities that were accomplished from late March 2009 through thefirst week of October, 2009. Each summary generally identifies the activities performed, workproducts worked on or created, and any problems or issues that surfaced.

During the week of October 13, Whitemarsh sent an email to DHS/ICE that thanked themfor enabling Whitemarsh to work on the SEVIS II effort. The email is Attachement 26. Theemail concluded with:

Regrettably, my assessment of the current set of data models is that they do not exhibit thenecessary levels of quality and integrity that will enable SEVP to definitively defend SEVIS IIoutputs. While the data management challenges seem complex, a coordinated integrated effortfrom all parties can overcome these challenges and establish data stability and creditability withinthe user communities.

4.0 Activities During November and December 2010

During the Summer of 2010, Whitemarsh was tasked by another client to develop a strategy forcreating a comprehensive and completely valid RFP that could be issued to potential businessinformation system developers.

The objective of work that would precede the issuance of the RFP would create a verydetailed specification that would contain all the information necessary to enable accurate bids byimplementors. Further, it would ensure that when the business information system wasconstructed, it would be correct on its first implementation.

This Whitemarsh task resulted in an award to the client should the Federal agency thatrequested the development of the strategy desire to have RFPs developed for the implementationof business information systems.

Whitemarsh contacted DHS/ICE and offered to present this strategy to the SEVIS IIteam. A session was held in early December. The strategy is contained in Attachment A19. Thisstrategy was sent to DHS/ICE in early October 2010. Attachment A19 identifies the process andwork products created during such an effort. The presentation that was delivered to DHS/ICE is


9


contained in A23 and was presented in summary form at an early December 2010 meeting atDHS/ICE.

Whitemarsh understands that DHS/ICE employed the OneSpring Corporation to developvisual-based requirements for SEVIS II. Whitemarsh met for several hours with a key member ofthe OneSpring staff and inquired about the work products and process that OneSpring wouldemploy on such an effort. It is similar only partially with what was proposed in Attachment A19.Specifically, Whitemarsh understands that OneSpring deliverables related to only Section 2.3,Function Models, and a very narrow component of Section 4, Prototyping. Whitemarsh furtherunderstands from the interviewed OneSpring staff member that the OneSource deliverables,while integrated one with another are not part of a larger metadata management system databasethat is essential for the successful implementation of SEVIS II. Whitemarsh understands,however, that these deliverables can be exported into a CSV format and with appropriate import-programming could be included in the Metabase System database.

A key set of Whitemarsh deliverables from Attachment A19 would have included acomplete database design, and operational functional prototypes would be running from an SQLengine, for example, Oracle so that staff from the SEVP and the Department of State could seeand react to these code-generated prototypes and through the iterations set out in AttachmentA19 causes at least three cycles of to that Attachment A10 deliverables. This is clearly shown inAttachment A23.

Subsequent to the presentation, Whitemarsh, upon learning of the DHS/ICE approach tothe next cycle of SEVIS II implementation, created a followup letter that set out theopportunities and risks with the adopted DHS/ICE approach. This letter is Attachment A20.

5.0 Activities during the Fall of 2011

During the Summer of 2011, Whitemarsh contacted DHS/ICE and indicated that it was creatingupdated versions of three documents that were created in support of SEVIS II. The threedocuments were:

! Business Event Histories! Reference Data Management! Data Management IV&V Architecture and Concept of Operations

A revised version of the Business Event Histories document is now published as a Whitemarshdocument and is Attachment 27. Removed from this Whitemarsh paper are references to theactual requirements from the SEVIS II Requirements Document. That is contained inAttachment A11. Other changes include references into other Whitemarsh materials that supportthe full creation of Business Event Histories. Included with this document is a “commercial”example.


10


The revised version of Reference Data Management, A28, has also been published. LikeBusiness Event Histories, it too has been “commercialized.”

The revised version of Data Management IV&V Architecture and Concept of Operationscontains the largest quantity of changes. It is Attachment 21. This document now is about 85pages of content, and contains a much more detailed check list for accomplishing DataManagement IV&V. This document is much more aligned with the Whitemarsh methodologyand its Metabase Systems for metadata management.

During an exchange of emails with Paul Martindale, Alen Fetterer was task by DHS/ICEto provide support to Whitemarsh in obtaining documents that would assist in the developmentof this Way Ahead report. Specifically requested was the work breakdown structures employedby the Implementor during SEVIS II. The only WBS that was able to be retrieved and providedwas the 2nd WBS that was used by the Implementor. This is a “What and When” WBS. Ingeneral, there are three classes of WBSs, which are:

! What and When! When and How! Who and When

A detailed analysis of the 2nd Implementor WBS focuses almost exclusively on “what” workproducts are in terms of their names and “when” they will be delivered. It is close to impossibleto understand “how” a work product will be created. That is left entirely to the reader to surmise.

Complicating the evaluation of almost all the Implementor’s delivered work products isthat each work product was essentially a stand-alone document. These work products were notintegrated, with other work products, nor were older work products updated and resubmitted asthey became outdated due to requirements changes or discovered later-on document problems.What was required was a comprehensive metadata management system and database that wouldhave taken in all the delivered work products as they were being developed by theImplementor’s staff in such a way that the deliverables created and turned into DHS/ICE weremerely reports. Thereafter, the metadata database could be queried, updated, and evolved in sucha way that all the SEVIS II specifications, end to end, would have been current, integrated,interoperable, and non redundant.

The second type of WBS, When and How, was the form of the first WBS. Readers wereable to understand just how a given work product would be created and when it would bedelivered. This type of WBS is necessary to understand the validity and appropriateness of thework products delivered, and also to understand whether the resource estimates for staffing anddurations are credible.

An analysis of the first Implementor WBS showed that there were many repetitions ofessentially the same work steps. These repetitions occurred as the SEVIS II effort proceededfrom Requirements through Implementation for each of the SEVIS II function area products. So,while the Implementor’s first WBS contained many pages, its content was unremarkable.


11


In a Data Management IV&V document that neither made it to the list in Attachment 3nor in the set of documents obtained by DHS/ICE from the IV&V contractor, a detailed analysiswas made of the projected resources and duration estimates of the Implementor’s work for thecreation of the later functional area products use cases. This analysis showed that the resourceestimates were way under what experience was then showing. This analysis was possible onlybecause the first WBS provide by the Implementer was in a When and How form.

The final type of WBS is Who and When. This is needed whenever there are multiplestaff from different organizations involved in efforts like SEVIS II. This WBS was not generatedby the Implementor. It appeared to have been the responsibility of the DHS/ICE PMO.

Upon reflection, all three WBS types are needed to have a complete picture. In additionto these three WBSs, the IV&V WBS needs to be integrated within it as well. Only when all thenecessary and sufficient WBSs are integrated can a true picture of the accomplishment of SEVISII be portrayed. Attachment A29 describes the process of building complex WBSs. AttachmentA22, page 30, contains the entity-relationship model for Project Management module from theWhitemarsh Metabase System. Stored through this data model is all the metadata to fully supportcomplex projects such as SEVIS II.

6.0 A Way Ahead for SEVIS II

A successful way ahead for the SEVIS II project requires the following five items.

! Integrated work teams that operate from a single SEVIS II metadata database thatcontains all SEVIS II work products in an integrated, interoperable, and non redundantmanner. This addresses the John Zachman quote at the end of the Executive Section.

! An end-to-end methodology, work breakdown structure, and project management that isintegrated–as metadata–with all the other SEVIS II work products.

! An appreciation for and integration of data management as the critical-path linkingmechanism across all work products.

! An approach for specification-evolution through function prototyping that is based out ofthe metadata management system through the use of business information systemgenerators.

! Adoption of the waterfall approach coupled with functional prototyping that eliminatesthe waterfall problems in advance, and thereafter, the use of the iterative and paralleltracks of implementation that is based on the functional prototype created and metadatamanagement system supported SEVIS II specifications.


12


Each of these is briefly discussed below and contains references into the Attachments and othermaterials that support these way ahead recommendations.

6.1 Integrated Work Through Metadata Management System

A metadata management system is a software-based information system that has a highlyengineered database. The schema of the database maps onto the engineering of a collection ofproducts that are to be stored in the metadata database. Because the metadata managementsystem is just like any other data-centric information system, it has a data model, a processmodel, presentation layer, reporting mechanisms, at the like. Thus, all metadata managementsystems are build through traditional common-sense techniques of requirements, architecture,design, implementation, operations, and evolution. Ideally, the data engine for any metadatamanagement system is based on SQL and reporting is accomplished through commonly availablethird-party report writers like Crystal Reports from SAP.

The Whitemarsh Metabase System is a kind of metadata management system and isbased on the following rationale.

No one would ever question why a business needs it's finance books. Well, the metadatamanagement system database is the business's information systems' books. If you cannot run agood business without the former, you cannot run good information systems environment withoutthe latter.

In the development of large data processing projects dealing with enterprise-wide, indispensablebusiness functions, documentation of the design requirements and resulting information systemspecifications is seldom accomplished such that it is timely, accurate, or complete. That isdisastrous for the following three reasons:

! Only the momentous facts that are remembered are recorded.

! As systems are specified, the lower-level design details are redundantly developed, oftenin conflicting manners.

! As system components are maintained, the efforts are crippled because of theundocumented business knowledge that is essential to understanding the component.

Amelioration of these three important problems starts with organizations adopting formalmethods for performing analysis and design. Formal methods are only measurably productiveand repeatable if they are very detailed and proceduralized. Such detail, however, dehumanizesknowledge workers, who, in turn, are certain to generate protests about being production workerson an assembly line, which, by the way, is worthwhile only when all of its products are the same.


13


In contrast, to the production line, business information system designs are unique assemblies oflarge sets of components, many of which are similar in design.

Designing business information systems is not an activity for the production worker;rather, it is an activity for a knowledge worker. While there is clearly procedure to bothactivities, designing an information system requires individualized applications of creativity,human factors techniques, and rule making. Accordingly, requiring the robot-like use of a fullydetailed methodology cannot result in responsive information system designs. Work plans mustbe drawn from proven techniques against which metrics have been captured and honed over theyears.

Building a business information system, once it is designed in sufficient detail, is largelya rote application of computer language coding. There are a number of quality and robust codegenerators that can use the metadata for a business information system design to producecomputer code that is competitive in performance to a human coded application. There is, ofcourse, no comparison between human coding costs and code generator costs.

To fully respond to the three problems cited above, knowledge workers should have thefreedom to create their own analysis and design work products for data and processes withinstrictures dealing with format, time, quality, and resources. These work products must be placedinto a metadata management system database, or metabase.

"Metabase" is a crafted term from "metadata database." The metabase term has been usedby Whitemarsh since 1981 in reference to the many different metadata database systems thatWhitemarsh has built for its clients. The metabase, containing these products in fixed formatsand sequences, can be accessed by code generators (both human and computerized) to build thebusiness information system. If the generator is quick enough, a fully functional version of thebusiness information system design can be live-tested a short time later. As design flaws arefound, the metabase's data can be changed and the business information system regenerated. Inshort, an interactive design process, in which the metabase is the empowering component.

Traditionally, it is not uncommon to expend 20 percent of a total systems developmentlifecycle on requirements and design. The remaining 80 percent is expended on building, testing,and documentation. Once implemented, 500 percent more is spent over a system's lifecycle forchanges, fixes, and evolutions, also in a 20/80 ratio. The overall total is 600 percent. If, withcode generators, the 80 percent is reduced to effectively zero, there must also be a profoundreduction in the 500 percent of original system creation resources that needs to be allocated tolifecycle maintenance.

The metabase system functional modules include:

! Missions, Organizations, and Functions! Resource Life Cycles! Information Needs! Database Objects! Business Information Systems and Business Events! Data Modeling


14


‚ Data Elements‚ Specified Data Models‚ Implemented Data Models‚ Operational Data Models‚ View Models

! Document and Form! Project Management! Requirements Management! Use Cases

Modules of the Metabase System that have been designed but not yet implemented are:

! Data Integrity Rule Specification and Binding! User Acceptance Tests! Wire Frames

The following is a partial list of benefits attained through the use of a metabase. A metabase will:

! Assist top management in identifying the resources required to build an informationsystem.

! Provide discipline and control for the design process.

! Provide a structured approach to conceptual design.

! Enhance the application development process through the utilization of prior work.

! Provide a management facility for monitoring database projects.

! Allow for the non-redundant storage of data definitions and business policies thatproduce greater consistency throughout the enterprise.

The data models for each of the function modules is provided in Attachment A22. Because theengine for the Metabase System is an SQL-based engine, any programming language with SQLaccess through ODBC can be employed to create new Metabase System functional modules. TheMetabase System’s schema is an open, explicit SQL schema.

The Whitemarsh Metabase System was built to according to the business informationsystem requirements expressed in the Knowledge Worker Framework. This framework is styledafter the Zachman framework but is highly tuned to meet the needs of business informationsystem architecture, engineering, development and evolution. The framework is depicted inTable 1.


15


Attachment A32, Metabase Rationale and Knowledge Worker Framework With MetaModels describes the Metabase System within the context of the Knowledge WorkerFramework.

Knowledge Worker Framework

Perspective MissionDatabaseObject

BusinessInformationSystem

BusinessEvent

BusinessFunction Organizations

Scope Businessmissions

Major businessresources

BusinessinformationSystems

Interfaceevents

Majorbusinessscenarios

Organizations

Business Missionhierarchies

Databasedomains, andresource lifecycles

Informationsequencing, hierarchies,and use cases

Eventsequencingandhierarchies

Businessscenariosequencingandhierarchies

Organizationcharts, jobs and descriptions

System Policy hierarchies

Data elementsspecified datamodels andidentified databaseobjects

Informationsystem designs

Invocationprotocols,input andoutput data,and messages

Bestpractices,qualitymeasures andaccomplishmentassessments

Job roles, responsibilities, and activityschedules

Technology Policyexecutionenforcement

Implementeddata modelsand detaileddatabaseobjects

Informationsystemsapplicationdesigns

Presentationlayerinformationsysteminstigators

Activity sequences toaccomplishbusinessscenarios

Procedure manuals, tasklists, qualitymeasures andassessments

Deployment Installed businesspolicy andprocedures

Operationaldata models

Implementedinformationsystems

Client &serverwindowsand/or batchexecutionmechanisms

Officepolicies andprocedures toaccomplish activities

Daily schedules,shift andpersonnelassignments

Operations Operating business

View datamodel, XMLdata models

Operatinginformationsystems

Start, stop, andmessages

Detailedprocedure basedinstructions

Daily activityexecutions, andassessments

Table 1. Knowledge Worker Framework


16


The reason for this framework, its data models and for its complete end-to-end metadataintegration is because through an analysis of 13 large scale Federal business information systemstudied by the GAO enable the classification of observed errors and their allocation to majorbusiness information systems set within the context of the Knowledge Worker Framework’scolumns and rows. This is shown in Table 2.

Business Information SystemFunction Addressed by theKnowledge Worker Framework

Framework’s columns and rows Percent of Errorsfrom the GAO Studyreviews

Building and Employing EnterpriseArchitecture Models:

Scope and Business Rows, all columns. About 41%

Creating and Evolving InformationSystems Plans

System Row, all columns About 5%

Architecture and Engineering of DataModels:

Technology Row, database object column. Less than 2%

Performing Reverse Engineering ofLegacy Systems and Databases:

Operations, Deployment, Technology andSystem Rows. Database Objects Column

Less than 2%

Forward Engineering Manufacture ofNew Systems and Databases:

Operations, Deployment, Technology andSystem Rows. Database Objects Column.

Less than 2%

Employment Errors: Systems through Operations Rows.Operations and Functions Columns.

About 49%

Table 2. Business Information System Functions addressed by the Knowledge WorkerFramework

6.2 End-to-End Methodology and WBS

The methodology that is needed for the SEVIS II project has to be very comprehensive. It mustnot only address the three types, that is, What and When, When and How, and Who and When, itmust also address all the fundamentally different project types. These include hardware,networks and networking, infrastructure software, and of course business information systemdevelopment. Each of these are different project types and would likely be represented both bytheir own framework and work breakdown structure.

This report focuses entirely on the business information system developmentmethodology that is needed by SEVIS II. Other DHS/ICE organizations need to focus on theseother different project types. The phases of the Whitemarsh data-centric business informationsystem development methodology are:

! Preliminary Analysis


17


! Conceptual Specification! Binding! Implementation! Conversion and Deployment! Production and Administration

The complete work breakdown structure is provided in Attachment A24. The key activities foreach phase and page numbers for the start of the WBS for that activity is provided in the Table 3.

Task Id Task Name or Category Page

1 Preliminary Analysis Phase 1

1.01 Form project team, plan phase, & estimate project 1

1.02 Create initial database project requirements description 2

1.03 Create mission description model 3

1.04 Create business information systems plan 7

1.05 Create preliminary analysis phase report 13

1.06 Create preliminary analysis presentation 14

1.07 Conduct phase review 14

2 Conceptual Specification Phase 15

2.01 Form project team, plan phase, and revise project plan 15

2.02 Create logical database of business requirements 15

2.03 Specify physical database of business requirements 29

2.04 Analyze interrogation requirements 40

2.05 Specify system control requirements 42

2.06 Validate cross product of data integrity and data transformation models 44

2.07 Create cross-product validation presentation 45

2.08 Conduct subphase review 45

2.09 Validate through prototyping 45

2.10 Consolidate logical database changes 48

2.11 Create conceptual specification phase report 48

2.12 Create conceptual specification phase presentation 49


18




3 Binding Phase 51


3.02 Review conceptual specification phase for completeness and revise as necessary 51

3.03 Remedy any data availability and quality problems 51

3.04 Determine Impact on Corporate Business Model 51

3.05 Evaluate, select and/or procure DBMS packages 54

3.06 Evaluate, select and/or procure metadata repository packages 59

3.07 Determine Implementation Strategy 62

3.08 Prepare binding phase report 66

3.09 Create binding phase presentation 67


4 Implementation Phase 69


4.02 Create or revise logical database 69

4.03 Create or revise physical database 70

4.04 Create or revise critical interrogation subsystems 75

4.05 System control implementation 78

4.06 Develop or revise ancillary supports 80

4.07 Plan and conduct system quality tests (system quality test) 83

4.08 Create implementation phase report 85

4.09 Create implementation phase presentation 85


5 Conversion & Deployment Phase 86


5.02 Review prior phase for completeness and revise as necessary 86

5.03 Secure, install and test all equipment 86


19



5.04 Conduct all training 86

5.05 Convert all data 87

5.06 Create conversion and deployment report 87

5.07 Create conversion and deployment review presentation 87


5.09 Prepare estimate for production and administration phase 87

5.10 Prepare project production & administration phase funding 87

5.11 Present for funding review 87

6 Production and Administration Phase 89


6.02 Database system production 89

6.03 Develop interrogation subsystems 90

6.04 Application Optimization Assessment 92

6.05 Determine database system maintenance policy 96

6.06 Perform standard system maintenance 97

6.07 Perform emergency maintenance 103

6.08 Accomplish database system revision 103

6.09 Perform enterprise database audit 108

Table 3. Top level Whitemarsh methodology phases and tasks.

Figure 1 illustrates the traditional Waterfall methodology that was essentially employed by thefirst attempt of SEVIS II. The scale at the bottom for this figure and also for Figures 2, and 3 areillustrative and could well be weeks or months depending on the size of the project. By“essentially” it is meant that the phases were undertaken for each of the major SEVIS IIproducts. The critical failure in the approach was that as the products were developed,production software was being created. It was often the case that modified requirements, finallyunderstood requirements, or even forgotten requirements caused the need for earlieraccomplished specifications, database design, and software to be modified. Clearly this causedtime and resource problems during the effort.


20


In contrast, the Whitemarsh approach is different in one critical way: It is based onprototyping requirements through functional area prototyping such that the creation of anyproduction-class software is not started until all the SEVIS II functional area products arethoroughly prototyped and iterated. This strategy causes all the requirements to be “teased out.” In Figure 2, all the functional prototypes are designed and prototyped during each of the “D”symbols. Thus, through this approach “real” implementation is not started until “V1.” When the“V1" implementation is started, Figure 3 would likely be adopted. As with the other figures, thescale at the bottom is illustrative and depends entirely on the size of the project.

The approach illustrated in Figure 3 supports the ability of DHS/ICE to accomplishparallel implementation of different SEVIS II functionality by different contractors. That’sbecause there exists at that point, 100% of the requirements along with a complete databasedesign, operational prototypes, and a metabase of very detailed, integrated specifications. Table4 sets out the different methodology phases and describes the contracting approach that can beapplied to each. The Whitemarsh Metabase System serves a prominant role in each of thesemethodology phases. That’s because it’s the database into which all the specifications are stored,interrelated, made integrated, are non redundant, are updated, and serve as the basis forgenerating the SEVIS II specification reports required by DHS/ICE’s PMO. Table 5 that followsimmediately after Table 4 identifies the phases during which certain metabase modules areemployed and identifies how the metadata created, stored, and modified. “White” entities fromthese metadata data model pages (See A22 and the pages ciited for each metabase systemmodule E-R diagrams cited in Table 5) are entered through that named module. “Grey” entities

Figure 1. Traditional approach to methodology.


21


from those pages represent metadata that is used in that module for context and to ensurecomplete end-to-end traceability.

Figure 2. Iterative requirements development through prototyping.

Figure 3. Parallel implementation starting at the end of the Conceptual Specification phase.


22


WhitemarshMethodology

Phase

Contractor Approach

PreliminaryAnalysis

Ideal would be a single contractor or at least a few contractor with specialists that aretogether a highly cohesive team. It would consists of Business Analysts, Data Modelers,and for infrastructure, a Metabase Administrator to store, report and ensure interoperabilityof all delivered work products that are stored in the Metabase System database.

ConceptualSpecification

Multiple contractors would be clearly possible. One for the subphases: Logical Database,and multiple for the Physical Database and multiple for Interrogation, finally, one forSystem Control. There would be a specialized team just for functional prototypegeneration, demonstration and results feedback. That is because the business informationsystem generator is a highly specialized product and is best accomplished by experts in thatproduct.

As in above, there would have to be a highly cohesive matrixed management team and allwork products would be stored in the Metabase System database to ensure cohesion,coupling, integration, interoperability, and non redundancy.

Binding This phase is best accomplished by a single team that is staffed and/or headed by a DBMSvendor or certainly a database and application specialists in that DBMS. That is becauseSEVIS II is a multiple conflicting architecture system with Internet, batch, client/server,and various report writing components that will likely push the implementation in onedirection or another. As with the other phases, the Metabase System will play a key rolebecause the selection of and binding to a particular DBMS will likely affect components inthe conceptual design, especially in the Physical Database, Interrogation, and SystemControl areas.

Implementation Multiple contractors. There can exist multiple contractors at this stage because theactivities will be mainly focused in implementation of already designed components. Whilethe teams will have to focus on Logical Database, Physical Database, Interrogation, SystemControl, each team will have to have “representatives” to a joint working group to ensurequality and integrity across all these subphases and these subphase work products willaffect one anohter. As with other phases, the Metabase System team will ensure that allwork products are properly stored, integrated, and interoperable to ensure end-to-endtraceability. Also accomplished in this phase are ancillary supports and a full developmentof all integration and system testing. A separate group or contractor for integration andsystem testing would likely be advised to ensure that all requirements that have beendeveloped initially or that have been discovered and/or evolved over time are truly met bythe SEVIS II system prior to its entering into the conversion and deployment phase.

Conversion andDeployment

This phase concentrates on all required hardware and network support procurement,installation, and testing. It further concentrates on all data conversion from SEVIS I andany other sources of data from external systems. It also includes the building of allreference data that is needed for production operations. This phase also accomplishes allsystem and integration testing, stress testing, and the myriad of all System Controlactivities. Finally, this phase accomplishes all system and end-user training and theestablishment of all hotline support. In short, all the activities that are necessary before theProduction On status is set. The main role played by the Metabase System in this phase is


23



Phase

Contractor Approach

to be the repository from which all on-line end-user help is provided, all bug reports areentered, and from which all end-user and system documentation is produced.

Production andAdministration

The production and administration phase is really divided into three main subphases:production operations, on-going evolution and maintenance, and overall system auditing.The main role played by the Metabase System in this phase is to record and manage allSEVIS II modification requests and to be able to support the research necessary tounderstand, engineer, and monitor the accomplishment of all SEVIS II changes. It is at thispoint that SEVIS II transforms itself from a project based methodology to a release basedmethodology as depicted in Figure 2.

Table 4. Multiple contractor approach to SEVIS II Requirements through Production Phases.


Phase

Involved Metabase System Modules and Metadata with AttachmentA22 PDF Page Numbers

PreliminaryAnalysis

Data Elements (22)Database Objects (21)Document and Form (25)Information Needs AnalysisMission, Organization, Function and Position (28)Project Management (30)Requirements Management (31)Resource Life Cycle Analysis (32)


Business Information Systems and Business Events (20)Data Elements (22)Data Integrity RulesDatabase Objects (21)Implemented Data Model (26)Mission, Organization, Function and Position (28)Operational Data Model (29)Project Management (30)Requirements Management (31)Resource Life Cycle Analysis (32)Specified Data Model (33)Use Cases (34)

Binding Business Information Systems and Business Events (20)Implemented Data ModelOperational Data Model (29)Project Management (30)


24



Phase

Involved Metabase System Modules and Metadata with AttachmentA22 PDF Page Numbers

Implementation Business Information Systems and Business Events (20)Implemented Data Model (26)Operational Data Model (29)Project Management (30)Use Cases (34)User Acceptance Tests (35)View Data Model (36)Wire Frames (37)

Conversion andDeployment

Business Information Systems and Business Events (20)Operational Data Model (29)Project Management (30)Use Cases (34)User Acceptance Tests (35)View Data Model (36)

Production andAdministration

Business Information Systems and Business Events (20)Data Elements (22)Data Integrity RulesDatabase Objects (21)Implemented Data Model (26)Mission, Organization, Function and Position (28)Operational Data Model (29)Project Management (30)Requirements Management (31)Resource Life Cycle Analysis (32)Specified Data Model (33)Use Cases (34)User Acceptance Tests (35)View Data Model (36)Wire Frames (37)

Table 5. Methodology Phases and Involved Metabase Modules

SEVIS II was divided into functional area products. Whether the next implementationeffort will be similarly divided is not known. Regardless, it is very likely that each iteration willbe treated as a different encapsulated project. What must be prevented therefore is the creation ofstove-pipe deliverables. Figure 4 illustrates this strategy. It is called continuous flow. At thecenter of each cycle is the metabase management system and database that can be used byvarious teams. This same strategy is especially valuable once SEVIS II has been implemented.That is because the effort will have been transformed from a project-centric effort for theimplementation of individual functional area products as illustrated in Figure 3 to one in which


25


many different small to medium changes will be occurring across multiple functional areaproducts.

The Metabase System needs to be a critical path componet of all phases of SEVIS IIdevelopment. That is because as each of the SEVIS II functional area products proceed througheach design iteration, for example, a “D2," there may be other SEVIS II functional area productsproceeding through a design iteration at the same time. This is illustrated in Figure 5, which wasdeveloped from the Implementor’s first WBS. Figure 5 identifies the major work productsdeveloped. Each work product, that is, data dictionary, use case, wire frame, activity diagram orlogical data model was accomplished with a different technology. The only way to achieveintegration was hard, manual, error prone work. It was this first WBS that illustrated both Whatand How.

The approach is reasonable except for two things:

! The data modeler was not a critical path member of every requirements team. Rather hewas an “outsider” who participated infrequently.

! There was no metadata database into which the work products for a given functional areaproducts was stored and integrated with the specifications of all the other work products.This resulted in stove-pipe work products that were not integrated, interrelated nor non-redundant.

With the introduction of work on multiple functional area products, as is illustrated in Figure 6,the problem of functional area products integration became more difficult because each team wasunable to either reuse components from work on other “packages” within a given functional areaproduct. If one team disagreed with another team, there was no automatic recognitionmechanism, that is, the Metabase System and database, that would make the differences moreeasily seen. Without that common mechanism, differences were discovered only thoughlaborious walk throughs and detailed specification documentation.

SEVIS II functional area products proceeded through a traditional life cycle as illustratedin Figure 7. During each phase, requirements, design, testing, and documentation, work productswere being created through various tools. Each tool was different. Thus, each work productbecame a standalone stovepipe that was not integrated one work product across the developmentphases, nor across functional area products.


26


Finally, the inevitable happened. Prior work products from different functional areaproducts needed to be updated. This is illustrated in Figure 8. For all the reason cited above,changes were time consuming, resource intensive, error prone, and expensive.

Figure 4. Continuous flow model with metadata management system at its core.


27


With the Metabase System, it’s core metadata database holds both the shared and uniquemetadata about all the SEVIS II work products for each If the Metabase System and its databaseis commonly available to all the SEVIS II team members there will be a greater probability theywill reuse each others work products whenever possible.

Use Case

Activity Diagram

Wire Frames

Data Dictionary

01 Package Development Life Cycle

Logical Data Model

Figure 5. Package Development Life Cycle


28


Package N

Package N + 1

Package N + 2

Package N = 3

02 Iterative Product – Package Life Cycle

Iterative Updating of Prior Package* Use Cases, * Activity Diagrams, * Wire Frames, * Logical Data Model

Progre

ssio

n of P

acka

ges th

rough P

roduct

Figure 6. Package work product interactions.


29


DesignComponent designUI DesignEx Interface DesignSecurity Design Infrastructure DesignPhysical DM DesignSource to Target Mapping

Requirements (See Package)

Testing* Develop & User test* Integration testing* Test Build* Test Execution

03 Product Development Life Cycle

Documentation

Figure 7. Product development life cycle.


30


6.3 Data Management as Linking Critical Path Component

A central failing in the first implementation attempt of SEVIS II was the failure to recognize thecentrality of data management. The basis for this is set out in the first several sections ofAttachment A21. The main reason why data models are at the center of SEVIS II is for tworeasons:

! SEVIS II is data centric, not computer software process centric.! SEVIS II’s data is employed across many of its functional area products.

There is an additional and even more important reason. It’s that many of the SEVIS II workproducts from Requirements through Training and Help and every work product in between

Product N

Product N + 1

Product N + 2

Product N + 3

04 Iterative Product Life Cycle

Iterative Updating of Prior Product and then Packages within Products* Use Cases, * Activity Diagrams, * Wire Frames, * Test Components, * Logical Data Model* Design Components (UI, Ex Interface, Security, Infrastructure, PhyDM, Data Mapping)

Progre

ssio

n of P

roduct

Dev

elopm

ent

Figure 8. Illustration of the need to make changes acrossfunctional area products.


31


touches data specifications in some way. This is illustrated in Figure 9. The data models are thusthe common specification thread that interlaces the work products.

There also exists an integration across work products. While this is clearly implied fromFigure 4, and indirectly illustrated in Figure 9, it is further illustrated in Table 6. Theinterrelationships between the work products and the data models, and among the work productsis set out in significant detail in Attachment A21.

Data Element Model

Concepts Data Model

Logical Data Model

Physical Data Model

SQL View Data Model

XML Interface

Model

Data Architecture Reference Model

Business Requirements

External Quality Standards

Database Objects

Work Breakdown Structure

Business Rules

External Data Interface

Requirements

Resource Life Cycles

Business Information

Systems

Value Domains and

Management

User Acceptance

TestsUse Cases

Missions, Organizations and Functions

Information Needs

Database Domains

Figure 9. Integration of work products with data models.


32


Business InformationSystem Work Products

Interrelationships Among Business Information System Components

1 2 3 4 5 6 7 8 9 10 11 12 13 14

1. Business InformationSystems

na U U U U U U U U U U U

2. Business Requirements U na U U U U U U U U U U U U

3. Business Rules U U na U U U U U U

4. Database Domains na U U U

5. Database Objects U U U na U U U U

6. External Data InterfaceRequirements

U U U U na U U U U U U U

7. External Qualitystandards

U U U na U U U

8. Information Needs na U U U U U

9. Mission OrganizationFunctions

U U U U U na U U U

10. Resource Life Cycles U U U U U na U U U

11. Use Cases U U U U U U U U na U U

12. User Acceptance Tests U U U U U U na U U

13. Value Domains andManagement

U U U U U U U na U

14. Work BreakdownStructure

U U U U U U U U U U U U U na

Table 6. Cross reference among business information system work product


33


6.4 Specification Iterative Development and Convergence ThroughPrototyping.

The most important value achieved through the approach to iterative requirements developmentas illustrated in Figure 2 is a significant overall reduction in life cycle costs associated withbusiness information system development. The cost components are presented in Figure 10.

The factors that greatly influence costs are the “4 units” in the first line of this figure, and in thefact that there’s a life cycle multiplier of 5 in the second line of this figure. To dramaticallyreduce life cycle costs two things must happen:

! Reduce the cost associated with the “4 units”! Reduce the quantity evolution and maintenance cycles

These are both greatly affected through the use of iterative prototyping as shown in Figure 2.That is because the first implementation is likely to be more correct if it is design iteration 3, 4,or 5. The second life cost factor is reduced because the implementation design is significantlymore mature when it begins the first real implementation cycle and thus does not have to proceedthrough as many major revision cycles. This was best illustrated by a membership management

Requirements analysisand

Functional Design(Data Model

&Functional Model)

Detailed DesignCode & Unit Test

System TestDeployment

DocumentationTraining

1 Unit 4 Units+ = 5 Units

1st ImplementationTotal Costs

+

5 *

1st ImplementationTotal Costs for Evolution and Maintenance

Total Life Cycle Costs=

Figure 10. Illustration of the life cycle cost components


34


system that was created for an international membership organization. There were severaliterative design cycles, and each was accomplished through the use of a business informationsystem generator. When the system was implemented, it remained unchanged except for minoritems for seven full years.

The process for accomplishing functional area based prototypes through a businessinformation system generator is illustrated in Figure 11. A more thorough presentation of thisapproach is provide in Attachment 31, Short Paper #6, Modeling Data and Designing Databases.

The overall process for generating functional area prototypes is provided in Figure 12. The stepsare taken from the Whitemarsh methodology and the work products are stored in the MetabaseSystem database. The process of actually generating the prototype is accomplished during Step3.10. The Metabase System database, at that point will contain sufficient metadata to generateSQL DDL, which, in turn, will be fed into the Clarion business information system generator.Within a few minutes, a complete working prototype exists for that SEVIS II functional area.Thereafter it is reviewed with the functional teams, iterated, and re-generated until the functionalarea teams are satisfied. Focus here is two fold:

! Database design to contain the SEVIS II data! SEVIS II work flow model

This process has been shows to be quite successful over the past 15 years.

Figure 11. Interrelationship between Metabase System and Clarion business information systemgenerator.


35


3.1Identify,

analyze, and specify relevant

missions

3.5Create first level scope model of overall effort.

3.6Analyze and

specify database domains

3.4Identify analyze,

and specify relevant existing

data sources, formats, and

reports

3.7Discover and

specify database objects

3.8Discover and specify data

elements

3.9Discover and

specify subjects, entities,

attributes, and relationships

3.2Identify

analyze, and specify relevant organizations

3.3Identify


functions

3.10Publish, review,

and revise model of data via prototype

generation.

Figure 12. Overall methodology flow to create functional area productprototypes.


36


6.5 Waterfall and Iterative Methodology Implementation Approach

The approach contained in this Way Ahead report is a hybrid approach that employs thewaterfall strategy through the Conceptual Specification phase. Thereafter, the Iterative approachwherein multiple and parallel SEVIS II functional area products can proceed throughimplementation independently. That is because all the necessary interactions among thefunctional area products will have been addressed through the functional prototypes.

7.0 SEVIS II Way Ahead Recommendations

This Way Ahead report contains the following:

! An analysis of the work accomplished by Whitemarsh, the Data Management IV&Vduring the time period, late March 2009 through early October 2009. This was containedin Sections 2.0 through 5.0 and occupies the first 10 pages.

! A Way Ahead approach that can be employed by the DHS/ICE PMO in Section 6.0 andcontains 25 pages.

! A set of recommendations that are presented through three SEVIS II stages and describethe how the attached documents can be used to accomplish these recommendations. Thissection contains over 20 pages.

! An extensive set of Attachments that provides significant detail to various sections of thisreport. These attachments contain about 600 pages.

In summary, these materials are engineered so that they can be executed. Backing up thesedocuments are books, seminars, workshops, software. Thus, these are “practice” materials thatcan be adopted and executed. Key among these documents are A19, the Wayne Smith Proposal,and A20, the Paul Martindale Letter.

Figure 13 illustrates the SEVIS II stages that can best employ these materials from withinthe PMO. These stages are:

! RFP stage where the various implementation RFPs are created and evaluated.

! Development stage wherein the various SEVIS II functional area products are developed.

! Operations and Maintenance stage wherein the various SEVIS II functional area productsare evolved and maintained through out the SEVIS II life cycle.


37


Table 4 presents the identification of these three stages, the Attachments (with names) that canbe employed during this stage from within the PMO, and brief description the material can playduring that stage.

SEVIS II Key Stages

RFP Stage

Development Stage

Operations and Maintenance Stage

Data-Centric Methodology and all supporting books,

courses, etc.

Metabase System and Database Server for all Business

Information System Work Products

Contractor DHS/ICE PMOSEVIS II

User Community

IV&V Data-Centric WBS and supporting

materials

Support Comprehensive User and System Documentation

Stores BIS Work Product Deliverables During Development and Operations and Maintenance, Plus Earned Value Reporting

Supports PMO or IV&V Contractor Content, Form and Fitness Assessments against RFP, Proposal, and

Support for RFP Development and Proposal Evaluation

Support for evaluating content and fitness for all deliverables

Governs and controls all O&M, Plus comprehensive support for all user and system documentation

Figure 13. Approach to best use of SEVIS II A Way Forward materials


38


SEVIS II Key Stages and the Employment of Materials that can provide Support

Attachment Role Played

7.1 RFP Stage

A05 SEVIS II DataManagement IV&VConcerns_WithConsequences

This document identified just five (5) of the critical failings in the development ofSEVIS II. Only some had to do with data management. These were: Mappingsamong artifacts (work products), Audit trails, History, and Business Transactions,Reference Data management, Business Rules, and End-user Reporting. Theseconcerns need to be transformed into Requirements within certain classes ofrequirements. Given that they are and are all loaded as Requirements into theMetabase System’s database, then they can be tracked as they are beingaccomplished.

A06 Data ManagementIssues 2009_05

This document identified all 18 of the critical data management issues that needed tobe addressed by SEVIS II. This document needs to be turned into Requirementsand/or Whitepaper that is part of the RFP package. Each issue contains a Finding,Evidence, and Consequence. This document needs to be examined along with theRevised Data Management IV&V document to ensure that all these issues areexamined via the proposed work plan of the Implementor, and are properlyaccomplished in each of the work product deliverables.

A07 Data ManagementIVV Architecture andConcept of Operations

This document was the original Data Management IV&V document. It was clearthat the Implementor had no work plan and/or resources to build SEVIS II such thatit could be audited according to the Data Management IV&V document. It wouldtherefore appear critical that this document be transformed into IV&V Requirementsand that all potential implementors know that these are their assessment tests as work products are being accomplished. Actually, the Revised version of thisdocument should be used because it has been updated and all the work products cancaptured and reside the Metabase database such that they can be retrieved andreported according to DHS/ICE deliverables requirements.

A08 Data ModelEvaluation September 292009 Data Models

This more than 50 page document identifies and details via assessment and likelymitigation strategies all the data management failings observed during the sixmonths that Whitemarsh performed IV&V work. Page 52 of this documentsummarizes all the observed data management problems into 13 different categories.With each category is the Issue Id reference that details the problem.

Each of these assessments and mitigations need to be turned into Requirements insuch a way that the RFP bidders fully understand the types of issues that have to beaddressed in all the data models that are created in SEVIS II.

A10 SEVIS II DataManagement Analysis_02

This document is a single page version of A05, which in turn is a high level versionof A06. It was created so that the 18 different data management issues could beaddressed by the Implementor.

A11 Business Events andHistory_Whitepaper

This 25 page White paper details a show stopper for SEVIS II. The fact that theSEVIS II database would not adequately handle business event tracking likelyeliminated the SEVIS II database being able to be used as a source of data for


39




judicial proceedings. This document not only describes this issue, but also identifiesthe 55 different Requirements from the Requirements document that supports theapproach set out in the paper. This paper was revised to fix some “bugs” in thedesign and now exists as A27. This Whitepaper or a revised version needs to beprovided in the RFP package so that the Implementor can have an appreciation forthe nature of the database that must be created and set into operational status.

A12 DMConcern_ReferenceData_Whitepaper_02

This 13 page paper describes the situation regarding reference data that exists withinthe SEVIS II database. There were six different cases that had to be addressed. Thispaper contains a strategy to accomplish reference data management. The approachtaken by SEVIS II was inadequate to meet the SEVIS II requirements. This paperneeds to become a White paper and be part of the RFP package. This paper wasrevised and now exists as A28. This paper was also used to catalog all the differentuses of Reference data from the various SEVIS II use cases. SEVIS II reference dataneeds to be addressed in a manner similar to that described in this paper. ThisWhitepaper or a revised version needs to be provided in the RFP package so that theImplementor can have an appreciation for the nature of the reference data approachthat must be accomplished and set into operational status.

A18 RequirementsProcess Sessions, DataModels, and DataManagement QA

This 5 page document describes the problems that commonly existed during variousrequirements sessions. This paper needs to be reviewed and key contents turned intoRequirements that must be addressed by the RFP respondents. The requirementsmust then be stored in the Metabase system so that accomplishing theserequirements can be tracked. This essential content of this paper lead to A19, WyineSmith proposal, ane the Short Paper #6 from the Whitemarsh website. TheWhitemarsh book, Strategy for Successful Development of Business InformationSystems, details an approach that has been successful over the past 20+ years.

A19 Wayne SmithProposal_2010_10_07

This paper was based on a number of items. First, Short Paper #6 from theWhitemarsh website, the Whitemarsh book, Strategy for Successful Development ofBusiness Information Systems, the Metabase System, a winning proposal to theFederal Government, the very extensive Whitemarsh data-centric methodologyWBS (A24), and over 20 years of continuous successful experience and evolutionsof these strategies. The ultimate objective of this approach is to provide via theSEVIS II implementation RFP a completely working SEVIS II system – but inprototype form. It would contain a fully developed Mission, Organization, Function,Use Cases, data models, and operational prototypes of all of SEVIS II’sfunctionality. The processes for this are very well known and thoroughly proven. Once these are developed and the RFP issued, the SEVIS II project’simplementation essentially begins at the end of the Conceptual Specification Phase.See Figures 2 and 3. The majority of the WBS tasks from Phases 1 and 2 from theWBS set out in A24 will have been accomplished.

A20 Paul MartindaleLetter_2010_12_06

This letter was written to the SEVIS II PMO in support of the strategy set out by theSEVIS II Program Manager. That strategy was to bring on a series of contractorswho would accomplish the bulk of SEVIS II work. The letter identifies the issues


40




that would affect this strategy and identifies solutions to these issues. This letteridentifies four issues that need to become part of the fabric of the SEVIS II PMO.Without addressing these issues, what was a single large integration contractor’sfailure may well become multiple small integration contractor failures. The resultwill, however, be the same: No deployable SEVIS II.

This letter also references a number of other documents, some of which are part ofthis report and others are available from the Whitemarsh website.

The letter concludes with eight distinct recommendations that should beaccomplished prior to the issuance of a SEVIS II implementation RFP.

A21 Data ManagementIVV_2011_11_29Architecture and Conceptof Operations

This document, now 90 pages represents a completion of the data managementIV&V document in A07. This document is not the WBS for accomplishing theSEVIS II project. That, but only with respect to SEVIS II software and databasearchitecture, engineering, implementation, deployment, and evolution is set out inA24. Rather, this document sets out the rationale for and process steps for evaluatingthe work products created during all six Whitemarsh methodology (A24) phases ofthe SEVIS II. That is, from Preliminary Analysis through Production andAdministration. It is strongly advised that this document be a component of the RFPpackage that is provided to all requesters so that they can know and appreciate thesteps that will be undertaken evaluate the quality of their deliverables.

The process models within this document assess and evaluate the work productscalled for by the Whitemarsh WBS. These IV&V work products also map onto theMetabase System data models.

A22 Metabase SystemData Models

A key to the success of SEVIS II is integrated, interoperable, and non redundantspecifications. This enables end-to-end traceability. These specifications start withrequirements and proceed through the specifications for data models, business rules,and business information systems. In the previous cycle of SEVIS II, thesespecifications existed only as paper documents produced through a number ofdifferent technologies such as Word, Visio, and Erwin. These specifications werenot integrated, interoperable, nor non redundant.

Metabase System stored specifications begin with project plans, and exist for almostevery class of work product across the entire Whitemarsh WBS. These database-centric specifications become the interlinking mechanism among all work products,across all SEVIS II contractors, and among all users of the SEVIS II community.See Figure 9 and Table 6.

The RFP should contain Metabase System overview documents and the winningvendor should be advised that the work products stored in the Metabase Systemdatabase are the medium for storing and transmitting deliverables to DHS/ICE forSEVIS II. The standard reports access the metadata and produce the actual DHS/ICEdeliverables in paper/pdf format. After a review by DHS/ICE, corrections to the


41




work products are made through the Metabase System and thereafter deliverable-reports are regenerated.

These specifications exist within missions, organizations, and functions that are therationale, involved organizations, and processes of SEVIS II. A failing that started atthe very beginning of the past effort of SEVIS II was the lack of a metadatamanagement system and database that would not only contain all thesespecifications but would enable end-to-end currentness, and would support thegeneration of the “reports” necessary to support the PMO, and the myriad of SEVISII users from Universities, Camps, Au Pair families, the Department of State, theSEVP office, and the like.

The data models that represent the high level specifications of the necessary workproducts within SEVIS II. Once a work product is stored in the Metabase System itis integrated with all the other work products, and can be reported to the PMOthrough report writers such as Crystal Reports. The Metabase System’s database ismanaged by an SQL engine such as Oracle. The metadata database would reside onDHS/ICE servers and the Metabase System would be accessible through the Internetthrough a facility equivalent to Citrix. The Metabase data models are:

! Business Information System and Business Events! Data Integrity Rules: Specification and Binding! Data Elements! Database Objects! Document and Form! Implemented Data Model! Information Needs Analysis! Mission Organization, Function, and Position! Operational Data Model! Project Management! Requirements Management! Resource Life Cycle Analysis! Specified Data Model! Use Cases! User Acceptance Tests! View Data Model! Wire Frames

The data model diagrams show two classes of meta-entities: “white,” and “grey.”The white entities are those that represent data that is entered through that namedmodule. The grey entities are those whose data is entered through a different modulebut is needed in the named module for the purposes of traceability across the entireSEVIS II specification. that are through a different module.

The only modules that are still in development are: Data Integrity Rules, User


42




Acceptance Testing, and Wire Frames.

A23 WhitemarshDHS/ICE Presentation onRFP Development

This presentation was delivered to DHS/ICE in early December. It was reviewed insummary fashion during the DHS/ICE meeting called by the DHS/PMO. Thispresentation focused on only one of the five data management practice areas neededwithin the enterprise: Iterative Requirements Development. The presentation sets outthe traditional methodology, the problems associated with traditional methodology, areplacement methodology, and how the replacement methodology resolves thetraditional methodology problems. The presentation then sets out milestones,candidate staffing, and required hardware and software. The presentation continues with citations of where these strategies have been used. The presentation concludeswith a comparison of approaches along with a summary and benefits.

The presented strategy is fully documented, fully operational and has been refinedover the past 20 years. It has NEVER failed. More importantly, it has increaseproductivity, increased quality, decreased risk, and reduced cost over traditionalmethodologies.

Slide 7 shows the percents of errors that GAO discovered in its audit of 13 multi-hundred million dollar IT efforts. The overwhelming majority of the errors occureither at the very beginning of a project or after the IT project delivers operationalsystems. Slide 8 shows the percent of errors at 41 percent during the first two rows.Almost half of all the surface occur after an IT system has become operational.

The approach espoused in this presentation and in Whitemarsh materials directlyaddress these errors. Simply put, the source of the errors is the same. Immature anduntested requirements. The slides of this presentation set out a time-tested strategythat is focused directly on ensuring that requirements are fully developed,thoroughly tested through prototyping, and that SEVIS II’s first implementation isreally design four, five or six. Achieving this causes the majority of errors thatsurface when an IT project becomes operational to disappear. A11 and A12 andtheir revisions of A27 and A28 are clear examples of not paying careful attention toalready documented requirements.

Had the previous attempt of SEVIS II been thoroughly prototyped before even thefirst line of production code was created, the push back from the SEVIS IIcommunity regarding the first real delivery of SEVIS II production software wouldnot have occurred. The approach set out in this presentation and in A18, A19 andA20 would have enabled SEVIS II to be successful.

A24 WhitemarshMethodology WBS

This almost 150 page document sets out the detailed processes to accomplish thearchitecture, engineering, implementation, deployment and production andadministration of a business information system like SEVIS II. This methodologydoes not address areas outside business information systems such as hardware,network, and infrastructure software such as operating systems and databasemanagement systems. WBSs have to be developed for each of these and integrated


43




with this WBS. A29 Manufacturing Project Plans addresses the strategy fordeveloping comprehensive WBS. The six phases in the Whitemarsh methodologyare identified and described in Table 4. The metadata specifications created duringthese phases that are stored in the Metabase System database is set out in Table 5.

A27 Revised BusinessEvent Management

This paper is a revision of A11. It omits the references to Requirements as thisversion of the paper was turned into a Whitemarsh Short Paper. Deleted as wellwere any references to DHS/ICE and SEVIS II. This paper was widely reviewed andas a consequence of several feedback emails corrections were made.

This paper should be joined with A11 and once revisions are made to make themmore specific to DHS/ICE and SEVIS II, the paper should be part of the RFPpackage.

A28 Revised ReferenceData Management

This paper is a revision of A12. It omits the references to Requirements as thisversion of the paper was turned into a Whitemarsh Short Paper. Deleted as wellwere any references to DHS/ICE and SEVIS II. This paper was widely reviewed andas a consequence of several feedback emails corrections were made.

This paper should be joined with A12 and once revisions are made to make themmore specific to DHS/ICE and SEVIS II, the paper should be part of the RFPpackage.

A29 ManufacturingProject Plans

The Whitemarsh WBS is for data-centric business information systems. As such isinsufficient for the total needs of SEVIS II. Other WBSs need to be created forhardware, PMO involvement, IV&V activities, and the like. These multiple WBSsthen need to be combined into one large WBS for the entire SEVIS II program.

This paper sets out a strategy and a set of high-level data models that achieve thisobjective. At the present time, the Whitemarsh Project Management Overview (seeAttachment A30), and the Project Management metadata model does notaccommodate a multiple WBS approach. Changes to both would likely take onlyone staff month.

Once modified, multiple WBSs would be able to be integrated and employed tomanage the entire SEVIS II work plan. This modification should be accomplishedbefore the issuance of an RFP and when the contractor is selected, their work planshould be mapped to and incorporated within the SEVIS II work plan.


44




A30 Whitemarsh ProjectMethodology Overview

This paper sets out the overall strategy through which complex project planning canbe accomplished. There are two features that distinguish this approach. First it isentirely data-centric. That is because project management “data” is merely anotherclass of metadata. Second, through the Whitemarsh Metabase Module for ProjectManagement, work products can be directly linked to Project Management data.This, when work-accomplishment time-tickets are entered enable truly valid earned-value reports.

As stated above, modifications need to be made to this paper and to the ProjectManagement module of the Metabase System to enable it to represent multipleWBSs. Again, this can likely be achieved in just a single staff month of effort.

A31 Modeling Data andDesigning Databases

This paper presents a more detailed description of the steps contained in the A19paper, Wayne Smith Proposal. This paper represents the essential steps from theWhitemarsh WBS phases, Preliminary Analysis and Conceptual Design. This paperalso serves as an example and “Executive Overview” of the Whitemarsh book,Strategy for Successful Development of Business Information Systems.

It is very strongly recommended that before an implementation contract is awardedthat would correspond to Whitemarsh phases, Binding and Implementation, that theactivities contained in this paper, the book and the Whitemarsh methodology phases,Preliminary Analysis and Conceptual Design be complete. If this is done, theimplementation contractor will have all the deliverables from these two phases, thecomplete set of metadata from the metabase for these two phases (See Table 4 and5), and a complete set of operational functional prototypes to review and be able tobase their implementation proposal upon these foundational items.

Such an approach would be clear departure from the previous attempt of SEVIS IIwherein the contractor was essentially starting from step 1 of the PreliminaryAnalysis phase. The previous attempt was however fatally flawed –from the start–for all the reasons previously set out in this report.

A32 Metabase Rationaleand Knowledge WorkerFramework With MetaModels

This paper contains an overview and rational for the existence of the MetabaseSystem including setting it squarely within the Knowledge Worker framework. Thispaper also contains entity-relationship diagrams of the Metabase System datamodels. These models are a repeat of those presented in Attachment A22.

7.2 Development Stage

A11 Business Events andHistory Whitepaper

This paper and its revised successor paper, A27 should be used by theImplementation contractor as one of the documents appropriate for guiding thisaspect of the SEVIS II database design. While this paper was created as part of thedata management IV&V effort it was never staffed by the SEVIS II community,especially the SEVP. The approach needs to be verified and the solution needs to be


45




thoroughly prototyped before it becomes a key set of structures within the SEVIS IIdatabase.

A12 DMConcern_Reference DataWhitepaper_02

This paper, like A11 along with its revised version in A28 should be used by theImplementation contractor as one of the documents appropriate for guiding thisaspect of the SEVIS II database design. While this paper was created as part of thedata management IV&V effort it was never staffed by the SEVIS II community,especially the SEVP. The approach needs to be verified and the solution needs to bethoroughly prototyped before it becomes a key set of structures within the SEVIS IIdatabase.

A19 Wayne SmithProposal 2010_10_07

The strategy of contained in this paper should have been accomplished during theprior SEVIS II stage. Without all these activities being accomplished, it is likely thatthe next round of SEVIS II implementation will succumb to a similar set ofproblems that plagued the first attempt of SEVIS II implementation. That is,immature, unfolding, and evolving requirements. Immature requirements is a Thistype of problem, endemic in virtually all business information system efforts, mustbe “designed out” from the very first step of formal implementation. The approachset out in this attachment is a proven approach to achieve this objective. AttachmentA31 provides a next level of detail to this approach.

A20 Paul MartindaleLetter_2010_12_06

This letter focuses on the set of problems that are likely to beset a multi-contractorapproach. With a single implementor contractor approach there is only a single pointof failure: The single contractor. With a multi-contractor approach, the problems aremultiplied because the DHS/ICE PMO essentially becomes the integrating agentover a collection of independent contractors, each governed by their own DHS/ICEcontract. This should present a real challenge to contracting and to the integration,and interdependence of multiple contractors all working together. Failures by onecontractor may well affect the bid, work products, and work schedule of a differentcontractor. How would these problems be addressed. A solution would be for thePMO of DHS/ICE to take ownership of all Metabase System stored MetabaseSystem stored accepted work poducts and make whatever changes are neededthereafter.

While the Metabase System would enable the integration of work products frommultiple contractors, it would not resolve any conflicts among the contractors as towhich contractor is responsible for changes, how the changes are accomplished, orwhen accomplished, how and when other affected work products from differentcontractors would be completed.


This document should be used on a day to day basis by the DHS/PMO to examineand grade all deliverables related to data management and to a lesser extent theSEVIS information system work product deliverables.

Similar documents should be created for each of the other deliverable classes suchas the technical architecture, engineering and deployment of the SEVIS information


46




system work product, the actual data that is brought into SEVIS II from SEVIS I andfrom external data sources, for hardware, operating systems and other infrastructuresoftware, networks, training, on-line help, and the like. For example, one of thedocuments reviewed by Whitemarsh was the Help Desk Plan (See A03, item 9).Best recollection of this document indicates that a strategy was set out on how tointegrate SEVIS II work product deliverables that were hoped to have been stored inthe Metabase System database into Help Desk operations.

If all the IV&V plans are engineered and if they are provided to the implementationcontractors, these contractors will know, in advance exactly how their work productswill be evaluated.

If further, project management metadata is integrated then earned value reports willbe easy to produce.


This document contains the ER diagrams for all current metadata models in theMetabase. Given that the work product set expands, so too will the set of metadatamodels. The schemas of these new metadata models can be hypothesized from theexisting set of SEVIS I work product deliverables for hardware, infrastructuresoftware, and the like. Creation of Metabase System modules will thereafter take atmost one staff month for each such module. The reason these modules can becreated so quickly is due the use of the business information system generated oremployed by Whitemarsh. It is the same generator that Whitemarsh uses for thegeneration of all functional prototypes.

A23 WhitemarshDHS/ICE Presentation onRFP Development

This document was described in previous section, and would guide the developmentof work products not already accomplished by contractors during the RFP Stage. Ifthis is the case, it is unlikely that the RFP will contain sufficiently detailed andevolved architecture, engineering, and specifications that would enable proposers tobe able to create credible and reliable bids.


This document can be used as the basis for following along the development ofSEVIS II information system. This WBS needs to be enhanced with WBSs fromother areas such as hardware, infrastructure software, and the like. Given that all thedeveloped WBSs are interrelated, the the DHS/ICE PMO will be able to accuratelytrack the progress of SEVIS II. DHS/ICE’s PMO needs to take ownership of theintegrated WBSs and to evolve and maintain it as SEVIS II is created.

A27 Revised BusinessEvent Management

Given that this document is employed as an operational prototype during the RFPstage, and as a consequence is advanced to a state of maturity, then it, in its revisedstate, would be used to evaluate the implementor work products in this area.

A28 Revised ReferenceData Management

Given that this document is employed as an operational prototype during the RFPstage, and as a consequence is advanced to a state of maturity, then it, in its revisedstate, would be used to evaluate the implementor work products in this area.

A29 Manufacturing This document provides the overall strategy for integrating work plans. The


47




Project Plans Whitemarsh project management module is being enhanced to directly take inWBSs and support the intersection of one WBS to another. A key characteristic ofthe Whitemarsh project management system is that individual projects can begenerated from the selection of project templates. For example, generating a projectfor training development, an update system modification, the development of newdatabase tables and supporting infrastructures. As projects are accomplished,deliverables-based time tickets can be entered and earned value reports generated.

Given that the DHS/ICE PMO is to operate as the overall SEVIS II Integrationcontractor, then it assumes complete responsibility of integrating work plans, workproducts, selecting contractors and the like. An examination of Figures 3, 4, and 9along with Table 10 and parts of A20, the Paul Martindale letter, pages 4 through 6set out the work efforts that the DHS/ICE PMO needs to undertake.

A30 Whitemarsh ProjectMethodology Overview

This document provides an overview of the engineering and architecture of theapproach Whitemarsh believes is appropriate for SEVIS II. This document, coupledwith A29, Manufacturing Project Plans and A24 along with WBS documents createsto support other classes of work products such as hardware, networks, networkingsupport, and infrastructure software.

7.3 Operations and Maintenance Stage


This document in its enhanced form derived from its use in the Development Stagewill guide the evaluation of work products that are delivered by various SEVIS IIimplementation contractors.


This document, as it would be modified during the RFP stage and DevelopmentStage would contain the data model diagrams for all the work product deliverablesthat are stored in the Metabase System database. The Metabase System databasewould contain all the specifications of all the SEVIS II work products and asmodifications are required and accomplished the overall process that would befollowed is illustrated in Figure 4.


This document, as modified through the addition of other WBSs that would becreated in support of the RFP Stage and the Development Stage, would be used bythe DHS/ICE PMO to engineer and monitor ongoing modifications of the deliveredand operating SEVIS II.

Table 7. Attachment documents support for SEVIS II.


48


Attachments

A01 Letter01 One of Four_Evaluation of the Accomplishment of the SEVIS IVV SOWA02 Letter02 Two of Four_Evaluation of the Technical Process of IV&V TracingA03 Letter03 Three of Four_SEVIS II Data Management Documents Inventory on Burke

Consortium ComputerA04 Letter04 Four of Four_Weekly Summaries of Data Management IVV Work at Burke

ConsortiumA05 SEVIS II Data Management IV&V Concerns_With ConsequencesA06 Data Management Issues_2009_05A07 Data Management IVV Architecture and Concept of OperationsA08 Data Model Evaluation September 29 2009 Data ModelsA09 DMConcern_Reference Data_OPR Document_03A10 SEVIS II Data Management Analysis_02A11 Business Events and History_WhitepaperA12 DMConcern_Reference Data_Whitepaper_02A13 OPR_BusinessTransactionHistory_20090720A14 OPR_Data Management Four Problem Areas_04_24_09A15 OPR_Data Management_DM Maturity Review_04_24_09A16 OPR_Data Management_Use Case Review_04_24_09A17 OPR_Data Management_WBS DM Review_05_15_09_A18 Requirements Process Sessions, Data Models, and Data Management QAA19 WayneSmithProposal_2010_10_07A20 Paul Martindale Letter_2010_12_06A21 Data Management IVV_2011_11_29 Architecture and Concept of OperationsA22 Metabase System Data ModelsA23 Whitemarsh DHS/ICE Presentation on RFP DevelopmentA24 Whitemarsh Methodology WBSA25 Data Management Documents Created by Whitemarsh vs documents obtained by

DHS/ICE from IV&V ContractorA26 Text of Email that identified the quantity of Whitemarsh work products accomplished on

SEVIS II for DHS/ICE.A27 Revised Business Event ManagementA28 Revised Reference Data ManagementA29 Manufacturing Project PlansA30 Whitemarsh Project Methodology OverviewA31 Modeling Data and Designing DatabasesA32 Metabase Rationale and Knowledge Worker Framework With Meta ModelsA33 Gorman_AtBurke_Documents List_Computer Directory Listing


49


A01 Letter01 One of Four_Evaluation of the Accomplishment of the SEVISIVV SOW


51

Whitemarsh Information Systems Corporation2008 Althea Lane Bowie, Maryland 20716

Voice: 301-249-1142 Fax: 301-249-8955Email: [email protected] Web: www.wiscorp.com

October 13, 2009

Mr. Shawn O’RourkeVice PresidentAmerican Systems814 Greenbrier Circle, Suite-EChesapeake, VA 23320

Dear: Mr. O’Rourke:

This letter is the first of four letters that provides an overall assessment of the IV&V on the DHS ICESEVIS II effort. The four letters are:

! An overall review of the IV&V effort that has been accomplished on the SEVIS II effort.

! A specific review of the Technical Activities Development Process part of the IV&V Effort.

! An enumeration and brief description of 21 different Data Management IV&V documents thatwere created by Whitemarsh during this effort.

! Weekly summaries including citations of developed documents/materials of Whitemarsh IV&Vefforts.

DHS ICE has an IV&V contract with Burke Consortium, hereinafter referred to as IV&V Contractor. Inturn, Burke Consortium had a subcontract with American Systems, who, in turn had a contract withWhitemarsh Information Systems Corporation (hereinafter referred to as Whitemarsh) to perform the datamanagement IV&V services. Whitemarsh worked 100% of the time at the offices of Burke Consortiumunder the daily and direct supervision of the IV&V Team Lead.

The IV&V contract that ICE has with Burke Consortium is from the DHS ICE OCIO SystemsDevelopment Division (SDD) SEVIS II Project Manager, and the contract number isHSHQDC-06-D-00065-HSCETC-08-J-00020.

The life cycle of IV&V of the SEVIS II project is divided into two general activity categories:

! Project Management Activities

Whitemarsh Information Systems Corporation

1

Whitemarsh Letter to American Systems in Regards to IV&V Effectiveness

! Project Management! Technical and Operational Documentation

! Technical Activities! Task Management! Acquisition Process! Project Supply Process! Development Process

! Planning /Concept Activity! Requirements Activity! Design Activity! Development/Implementation Activity! Test Activity! Installation and Checkout

! Operations Process! Maintenance Process

In order to perform the IV&V activities cited above, the following IV&V efforts need to be performed:

! Attend various meetings during which SEVIS II artifacts are created, presented, and/or reviewed.

! Intensely study SEVIS II produced artifacts to understand their architecture and engineering.

! Perform independent studies of artifacts to determine their adequacy and fitness of purpose.

! Develop findings and create mitigation alternatives including cost and effectiveness of themitigation strategies.

! Alert the Development Contractor and the Government as soon as possible of adverse findingsand mitigation strategies to ensure that scarce SEVIS II project resources are not wasted.

With respect to the first class of activities, Project Management, it appears that an adequate IV&V effortis being performed. There have been extensive findings over the past year, and extensiverecommendations have been made to the government dealing with project management. Thus, in largemeasure, the five IV&V efforts immediately cited above but only with respect to the ProjectManagement Activities are being accomplished.

There is, however, one exception. An extensive review of the work breakdown structure from a technicalcontent viewpoint shows that while the overall process presented in the WBS is adequate, there aresignificant collections of database project centric tasks that are missing. Findings about these missing taskcollections were developed but were not presented to either the Development Contractor nor theGovernment when they first available in advance of the May 2009 IV&V report.

As to the bulk of the IV&V activities, that is those dealing with Technical Activities, these have largely


2


not been performed during the past year. The reason appears to have been because there has not been staffassigned to the IV&V effort capable of performing technical analysis and findings, and because even ifthe staff was present, the Development Contractor has not delivered sufficient artifacts to perform aTechnical IV&V effort.

Starting in the end of March 2009, I was assigned to the IV&V effort as a data management expert. Inaddition to being a data management expert, I have also extensive experience in system architecture andengineering of systems similar to SEVIS II.

Almost immediately I began to notice a significant quantity of data management issues and constructed aseries of adverse findings. However, I was prevented by the IV&V Contractor from providing you theseadverse findings, and in turn, you were not able to provide those adverse findings to the Government aswas required by your subcontract with the IV&V Contractor.

A second and even more critical issue exists with respect to Technical IV&V efforts. The DevelopmentContractor has not created and/or not made available, the necessary and sufficient artifacts to perform theSEVIS II Technical IV&V activities as required in the IV&V Contractor’s SOW. The most critical set ofartifacts that has not been provided are those dealing with tracing through the complete life cycle ofrequirements analysis, development, and testing. Consequently, the goals and objectives of the IV&VTechnical Activities cannot be accomplished.

There are two mitigation strategies available for this problem. First, have the Government force theDevelopment Contractor to develop the traceability artifacts, or second, have the IV&V Contractordevelop and then employ the artifacts in the IV&V SOW’s required traceability tasks. If the firstmitigation strategy is required by the Development Contractor, I would presume that their contract mayhave to be modified because the Development Contractor states that these artifacts are not contractdeliverables. This would almost certainly result in both increased costs and a lengthened deliveryschedule.

If the second mitigation strategy is undertaken, IV&V costs would not likely increase if the IV&VContractor employed an end-to-end metadata management system to load, integrate, and report all the keyDevelopment Contractor’s SEVIS II related artifacts. In addition, there would be an increase in theoverall quality of the IV&V work.

The reason costs would not increase is because while the Development Contractor’s existing artifactswere not intended to be either efficient or effective for an IV&V effort, these artifacts could be loadedinto a metadata management system. With a sophisticated metadata management system, the tracingactivities and findings could be accomplished in a more efficient and effective manner, and would bemore easily modified and then re-reported as changes occur in SEVIS II’s artifacts.

During the American Systems contract with Burke Consortium, a very sophisticated metadatamanagement systems was proposed to be used. It must be stated, however, that it required some level ofmodification. Those changes were estimated to be one staff month of effort. Had those modifications been


3


performed during April or May 2009, the requirements through data model tracing would have beencompleted by the end of June or at the latest the end of July.

Use of this metadata management system was prohibited by the IV&V Contractor on the grounds that itwas the Development Contractor’s obligation to both produce the traceability artifacts and to alsoaccomplish the tracing. It was stated that the only obligation of the IV&V Contractor was to note that thetracing was done and to verify that it was correct.

As it now stands, no tracing has been performed because the artifacts do not exist and the DevelopmentContractor is not contractually required to produce them. Consequently, there have been no significantIV&V Technical Activities in the area of traceability on this SEVIS II project. There have been, however,isolated adverse data management findings produced, but these have been prevented by the IV&VContractor from being delivered to you and, in turn, from you to the Government.

Regards,

Michael M. Gorman,President


4


A02 Letter02 Two of Four_Evaluation of the Technical Process of IV&VTracing


52



October 13, 2009



This letter is the second of four letters that provides an overall assessment of the IV&V on the DHS ICESEVIS II effort. The four letters are:





This second letter provides an assessment of the development process technical IV&V activities on theDHS ICE SEVIS II effort. DHS ICE has the SEVIS II development contract with Booz Allen Hamilton,hereinafter referred to as the Development Contractor.

DHS ICE has an IV&V contract with Burke Consortium, hereinafter referred to as IV&V Contractor. Inturn, Burke Consortium has a subcontract with American Systems, who, in turn has a contract withWhitemarsh Information Systems Corporation (hereinafter referred to as Whitemarsh) to perform the datamanagement IV&V services. Whitemarsh worked 100% of the time at the offices of Burke Consortiumunder the daily and direct supervision of the IV&V Team Lead.

The IV&V contract that ICE has with Burke Consortium is from the DHS ICE OCIO SystemsDevelopment Division (SDD) SEVIS II Project Manager, and the contract number isHSHQDC-06-D-00065-HSCETC-08-J-00020.


1

Whitemarsh Letter to American Systems in Regards to Technical Activities Development Process

As stated in the first letter, the life cycle of IV&V of the SEVIS II project is divided into two generalactivity categories: Project Management Activities and Technical Activities. The first letter provided anoverall overview of these six Technical Activities which were:

! Task Management! Acquisition Process! Project Supply Process! Development Process! Operations Process! Maintenance Process

Within the Technical Activities, the first three processes are either already accomplished, or as in the caseof Project Supply Process, was provided for informational purposes only. The last two of these technicalactivities, that is, Operations and Maintenance, are outside the scope of this letter. Consequently, theremainder of this paper addresses the content of the Development Process by mainly addressing whetherit is being accomplished. The development phase key activities are:

! Planning /Concept Activity! Requirements Activity! Design Activity! Development/Implementation Activity! Test Activity! Installation and Checkout

The three most critical sets of activities are requirements, design, and development and/orimplementation. If these are accomplished incorrectly or without the ability to fully verify and validatethem against SEVIS II requirements, there is little hope that the overall project will be successful.Consequently, most of the remaining focus of this letter is on those three critical development processactivities.

SEVIS II has been divided into about 12 distinct functional “products.” Products 1 through 4 are the coreproducts that result in the creation of the database and the conversion of the data from SEVIS I. Products5, 6, and 7 mainly create “new records” and support the interactive update of either migrated or newlycreated data. Products 8 through 12 are focused on reporting and on the development of SEVIS IIsupporting administrative and system maintenance processes.

SEVIS II is being accomplished through an iterative approach rather than through a Waterfall approach.Under the waterfall approach, the full set of requirements across all the SEVIS II product would have befully identified and vetted prior to any system design and implementation activities.

Instead, the Development Contractor proposed and undertook an iterative methodology with a workbreakdown structure engineered to have a number of feedback and system artifact evolution loops withineach of the products to ensure that requirements across a single Product were consistent. As the


2


requirements phase for each product is completed, that product proceeds into design, development andtesting.

There are, however, no explicit feedback loops from one product backwards to an earlier product. Thus,inexact or inappropriate work done in an earlier product that is identified through requirements analysisperformed during a later Product causes the need for requirements, design, and development rework ofthat earlier product. This is an inherent risk of the iterative approach.

This inherent risk can only be mitigated through a very fast requirements-based prototyping effort acrossthe first seven products so that the time and cost effects from inexact and maturing requirements can beminimized. If a very fast requirements-based prototyping effort had been accomplished within four to sixmonths, that is been completed by February 2009 for all the Products, there would have been more thanenough resources to cycle through all the Products repairing and adjusting requirements implications priorto undertaking a single full development cycle.

However, that did not happened. It appears that requirements for all the Products will not be fully vettedbefore the early part of 2010. And, while requirements are being discovered for a current Product,production class software is being developed for earlier Products. Thus, any changes that are theconsequence of Product 6, 7, and 5 will have costly implications on the software created for Products 1through 4.

Within a few weeks of data management IV&V work on SEVIS II, Whitemarsh saw these methodologybased problems and communicated them and their implications to the IV&V Team Lead. No action, ofwhich I am aware has been taken to present to the Government the full implications of this very seriousmethodology problem.

Because of the multi-product versus waterfall approach, the importance of and the obligations imposed onIV&V are especially heightened. If the IV&V activities are not deep and thorough; if adverse findings arenot immediately published; and/or if there are not immediate mitigation strategies produced, the effectson schedule and cost are greatly exacerbated.

In virtually every activity within the development process there is a traceability step. The importance oftraceability is independent of whether the SEVIS II project is accomplished through a waterfall or aniterative approach. Consequently, the need to trace artifacts from Requirements all the way through toTesting is essential to a successful IV&V of SEVIS II. The Development Contractor’s SEVIS II workbreakdown structure, even though invalid in substantive data management aspects, was engineered todevelop sets of artifacts that could be traced. That is, there could be a tracing from:

! Requirements to Use Case Activities! Use Case Activities to Use Case Data Elements! Use Case Activities to Wire Frame Components! Use Case Data Elements to Logical Data Model Tables and Columns! Logical Data Model Tables and Columns to Physical Data Model Tables and Columns


3


! Physical Data Model Tables and Columns to Software System Process Flow Diagrams! Wire Frame Components to Software System Modules! Requirements to Test Cases! Software System Modules to Test Cases

Subject matter experts, given these traceable artifacts, would be able to know and to certify that SEVIS IIwas engineered and built as required.

As to the first level of traceability, Requirements to Use Case Activities, it was only after the majority ofthe use cases from Product 6 was accomplished, Products 1 through 4 having been already designed,coded, and well into testing, did the Development Contractor begin to cite the requirements in the usecases. Neither the IV&V Contractor nor the SEVIS II client was able to trace from requirements to usecases within Products 1 through 4.

Recently, during testing of Products 1 through 4 there was push back from the client because it becameclear that the demonstrated software did not appear to meet the client’s understanding of the requirements.Had the tracings existed and had been reviewed by the client, these push backs might have been avoided.The push backs occurred in the Summer of 2009. The software was started in the late Winter of 2008. Theconsequence of the push back has been a refinement of the Development Contractor’s understanding ofrequirements, the design of the system, and the software that had been previously constructed. It is notclear as to who pays for these changes and the effects on the project’s schedule.

As to the second level of traceability, Use Case Activities to Use Case Data Elements, while therequirements are now being identified within the use case steps, what is not being done is the allocation ofuse case data elements to the use case steps. Hence there is no traceability from use case steps to use casedata elements. Such tracing can be guessed and surmised, but not verified. An obvious mitigation wouldbe for the Development Contractor to include a data element table within each use case step that bothcites the use case data elements and also whether the data element’s values are inserted, modified, deleted,or selected.

As to the third level of traceability, Use Case Activities to Wire Frame Components, there is no obvioustraceability. That is because the citation of the use case step is not annotated on the Wire Framecomponents. You are therefore not able to easily or even at all know if the Wire Frames accurately reflectthe use cases. When both are reviewed in the same requirements meetings, attendees are constantly goingfrom one set of documents to the other trying to make sense of the alleged interconnections.

As to the fourth level of traceability, Use Case Data Elements to Logical Data Model Tables andColumns, there is zero traceability from the use case data elements to the database tables and columns.This essentially means that the SEVIS II’s database design cannot be verified as conforming to therequirements.

The Development Contractor states that since the traceability from the use case data elements to thedatabase’s tables and columns was not a contract deliverable, it does not have to be produced. That may


4


be true, but it fatally cripples the IV&V process because the software is downstream from the database’stables and columns. Testing is reflective of both the database’s design and the constructed software.Given a failure to have use case data elements included in each use case step, and the failure to have usecase data element mappings to both the database’s tables and columns and the wire frames, verifying thatSEVIS II’s database and/or software conforms to requirements is very problematic.

The IV&V Contractor’s SOW clearly states that the tracing is to be performed based on the materializedtrace artifacts. Since none essentially exist, the IV&V Contractor must either create candidate tracings forthe Development Contractor to verify, or not do the tracing. The alternative, an unverified databasedesign should be presumed to be completely unacceptable.

The IV&V Contractor’s data management expert proposed the use of a metadata management system toaccomplish the tracing. In addition, the key analysis component in every tracing analysis is verification.Simply put, not only must the IV&V Contractor note that the tracing exists but also must “verify” that itis both accurate and correct. Even with this metadata management system, the first four levels of tracingwill take about three staff months. Without this metadata management system, the tracing could takeupwards of a full staff year.

As to the fifth level of traceability, Logical Data Model Tables and Columns to Physical Data ModelTables and Columns, the process should be relatively simple as this transformation process should beclose to automatically accomplishable by any quality data modeling tool set.

As to the sixth level of traceability, Physical Data Model Tables and Columns to Software SystemProcess Flow Diagrams, this level of traceability requires that the physical data model tables and columnsbe able to be loaded into the software development environment that is employed by the DevelopmentContractor. Since the IV&V has no visibility into that environment, it is impossible to know if this tracingis possible, that it has been done, or that is can be independently verified and validated.

As to the seventh level of traceability, Wire Frame Components to Software System Modules, this levelof traceability is similar to the one above. Again, the IV&V has no visibility into the softwaredevelopment environment and so it would be unable to verify that traceability exists, has been done, orcorrectly accomplishes the required mapping.

As to the eighth level of traceability, Requirements to Test Cases, this level of traceability is actually thefirst of the two final steps. By this time in the SEVIS II development process, the majority of the fundsand time will have been expended. Any errors found here will likely have serious implications on all theprevious traceability steps, and the developed SEVIS II database and software components represented bythose trace steps. The test cases, when demonstrated, represent the operational accomplishment of therequirements.

Essentially, the execution of the early Products software, was a demonstration SEVIS II according to therequirements-based processes implied by the test cases. The U.S. Department of State reacted negatively


5


to these demonstrations. To my knowledge there has not been any formal findings from these negativereactions.

The real issue here is not that there was a misunderstanding of what the SEVIS II requirements wereunderstood to mean by the Development Contractor, but that these software demonstrations representedthe first real tangible evidence of development, that is, real SEVIS II operational screens. These wereunable to be shown until some 12 months after the start of the project. Up until this time, there effectivelywas no traceability that could be shown and reacted to by the U.S. Department of State.

Had there been tracings across the eight levels, and had there been a very fast requirements-basedprototyping as described above, this reaction by the U.S. Department of State might not have occurred.Or, if it occurred, would have happened in a matter of weeks instead of a half-year.

As to the ninth level of traceability, Software System Modules to Test Cases, is similar to the previousone in that is more refined. This level presumes the existence of the first seven levels and represents onelast step. If the previous levels exist, the test cases should be assessed only to the extent that they are bothcomprehensive and correct.

While is has been stated in virtually all the IV&V Period Reports that tracings do not exist across theproducts for the various levels, what has not been communicated to the Government has been the effect ofnot having these levels of traces. The implications are that none of the IV&V Technical Activities, asrequired by the IV&V Contractor’s SOW, have been accomplished. This has been reported a number oftimes to the IV&V Team Lead through conversations, emails and analyses. Mitigation strategies havebeen proposed but have been rejected 100% of the time by the IV&V Team Lead. The IV&V Team Leadhas acknowledged these facts and has asserted several times that because the Development Contractor’stracings have not been provided to the IV&V Contractor that the IV&V Contractor is absolved from itsresponsibility in this area.

Whenever the Development Contractor has been pressured to deliver comprehensive and detailedtracings, there has been significant resistance. The question naturally arises, why? One reason may bebecause the Development Contractor does not have a comprehensive metadata management environmentinto which all the tracings can be recorded, reported, and evolved. It is understood that the use casedocuments are in MS/Word; the data models are accomplished in MS/Visio; and the data models areaccomplished in CA’s ERwin. It is not known what software development environment is beingemployed to design and develop the software. Given that there is no comprehensive metadatamanagement environment, the ability to create, store, report, and evolve all these tracings is veryproblematic.

Had there been a single metadata management system for the complete set of SEVIS II requirements,design, database, and software engineering artifacts, and had there been a very fast requirements-basedprototyping environment, not only would the production of the levels of tracings been “standard reports,”but the probability of having misunderstood requirements based software would have been close to non-existent. That is because there could have been a much more intensive interaction between the


6


Government and the Development Contractor, and because there could have been operational prototypeswithin a few weeks of closing off a set of use cases versus six or more months.

The levels of tracings would have immediately surfaced an analytical form of requirementsmisunderstandings on the part of the Development Contractor, and the prototypes would have surfaced amore visual and “physical” form of requirements misunderstandings. Together these misunderstandingswould have been able to be corrected well in advance of any software design, development, testing, anddemonstration. It is a well accepted adage that errors found in requirements and design cost dollars torepair while errors found in operational software cost tens of thousands of dollars to repair.

Based on the requirements sessions that have occurred over the past four months, the likelihood ofmisunderstood requirements, and thus, inappropriately developed database designs and software isvirtually certain. By whom and when will these be discovered? And, how much and how long will thesemisunderstandings take to repair? The underlying causes of these problems can be fixed, and if fixed, willlikely prevent significant additional expenditures of resources to mitigate them.

Regards,



7


A03 Letter03 Three of Four_SEVIS II Data Management Documents Inventoryon Burke Consortium Computer


53



October 13, 2009



This letter is the third of four letters that provides an overall assessment of the IV&V on the DHS ICESEVIS II effort. The four letters are:





This third letter document provides an enumeration and characterization of the 21 different documentscreated during the tenure the Data Management IV&V consultant. DHS ICE has the SEVIS IIdevelopment contract with Booz Allen Hamilton, hereinafter referred to as the Development Contractor.

DHS ICE has an IV&V contract with Burke Consortium, hereinafter referred to as IV&V Contractor. Inturn, Burke Consortium had a subcontract with American Systems, who, in turn had a contract withWhitemarsh Information Systems Corporation (hereinafter referred to as Whitemarsh) to perform the datamanagement IV&V services.

The IV&V contract that ICE has with Burke Consortium is from the DHS ICE OCIO SystemsDevelopment Division (SDD) SEVIS II Project Manager, and the contract number is HSHQDC-06-D-00065-HSCETC-08-J-00020.


1

Whitemarsh Letter to American Systems with Enumeration and Description of Produced Documents

Whitemarsh worked 100% of the time at the offices of Burke Consortium under the daily and directsupervision of the IV&V Team Lead.

The contract between IV&V Contractor and the Government requires five kinds of deliverables:

! Statement of Work as to how the IV&V Contractor was to accomplish its IV&V activities (a.k.a,SOW)

! IV&V Bi-monthly reports (a.k.a, IV&V Report)

! Observed Potential Risks (OPR) that are to be delivered to the Government as the risks areobserved (a.k.a, OPR)

! Weekly Status Reports (a.k.a, Weekly)

! Anomaly Reports (from Section 7 of the IV&V Contractor’s Statement of Work) that are toreport to the Government any situation and/or condition that deviates from best practice asdiscovered. (a.k.a, Anomaly)

Each document description in the table that follows this letter includes the document’s approximate date,its title and document type characterization, size and/or pages, and brief description.

Regards,



2

Enumeration and Description of Documents Produced in Support of Data Management IV&V Activities for the DHS ICE SEVIS II Project.

SEVIS II Data Management Documents Created by Michael M. Gorman (Whitemarsh through American Systems) that are Resident on the “H”Drive of Burke Consortium, Inc’s Computer Assigned to Michael M. Gorman

Id ApproximateDate

Title (Best Recollection)and Deliverable Type

Size/Pages Description

1 Early April Data Model AnalysesType: Anomaly

57 items across 4 datamodels, 20 pages

The January 2009 functional data models were examined for quality andcomprehensiveness. A total of over 55 areas of concern were identifiedand described. This analysis was started on day 2 of the DataManagement IV&V assignment.

2 Mid April Data Management IV&VArchitecture and Conceptof OperationsType: SOW

60+ pages The data management I&V Process identified the specific items that arecreated during the SEVIS II process that need to undergo analysis fordata management issues. Each item is cross referenced to five layers ofdata models that are accomplished in quality database projects. Eachitem is supported by a detailed work breakdown structure of activitiesthat ultimately lead to a determination of risk each item.

3 Mid May Data Management IssuesType: Anomaly

18 distinct items In preparation for the May IVV report, a white paper was created thatidentified 18 data management issues that were not being satisfactorilyaddressed in SEVIS II. Each item was identified, described and theconsequences set out if the items were not addressed.

4 Late May Data Management Sectionfor the May 30 IV&V Bi-Monthly ReportType: IV&V Report

18 subsections to a DataManagement Section

A separate data management section for the May 30 IV&V report wascreated. It addressed the 18 items above and each was identified,described and a recommendation was engineered.

5 Late May Data Management PlanReviewType: Review

30 distinct comments An analysis of the data management plan was created against theDevelopment Contractor’s May 2009 data management plan. Thisanalysis had over 30 items, of which 13 items were red and almost allthe others were orange. The overall plan was “red.”


3



Id ApproximateDate



6 Late May Data Conversion PlanReviewType: Review

About 30 specific items A analysis of the data conversion plan was created against the May 2009data conversion plan put forward by the Development Contractor. Thisanalysis contained about 35 “medium” (orange) issues.

7 Early June Product 6 Use CaseAnalyses re DataManagementType: Anomaly

16 Analyzed use caseswith about 5 sections ofanalysis for eachanalyzed case

The use cases for Product 6 (EV Management) were examined in detaildealing with data management, data conversion, System RequirementsDocument, System Design Document. Each such use case was examinedfor comprehensiveness and for attention to integrity and quality.

8 Mid June IV&V Data ManagementConcernsType: Anomaly

11 Items that are ofsignificance to SEVIS II

An overall list of data management concerns related to SEVIS II wascreated that needed priority attention within the project. Issues dealt withBatch, SQL Views, DBMS Backup and Recovery, Performance Tuning,Logical and Physical Reorganization, Data Security, Reference DataManagement, Data Warehousing and Business Intelligence (a.k.a.,reporting), Data Quality and Integrity management, and UserAcceptance Testing

9 Mid June Help Desk Plan ReviewType: Review

Multi-page This short document presents an analysis of the help desk plan andidentifies areas where the plan could be improved so that it couldemploy data management artifacts and SEVIS II data directly into theoverall help desk effort. This document was developed during the HelpDesk Plan review but was never incorporated into the IV&V reviewdocument.


4



Id ApproximateDate



10 Late June Analysis of DataManagement concernsemploying the I-17 as theexample.Type: Anomaly

Multi-page This 13 page document presents the findings of the research into theneed for a comprehensive and detailed approach to the capture ofbusiness event history within SEVIS II. The key areas that wereaddressed were: Mappings among the SEVIS II work products, AuditTrails, History and Business Transactions (that became Business EventHistory), Reference Data Management, Business Rule Management, andEnd User Reporting.

11 Late June SEVIS II DataManagement Concernswith Consequences andConclusionsType: Anomaly

Multi-page This 4 page document presents five of the 18 data management issuesthat were presented to the Development Contractor to determine theirapproach to resolving these items. It had been hoped that all 18 itemswould be discussed but only five were allowed to be presented by theIV&V Contractor’s CEO. Additionally, only two hours was allowed forthe presentation, questions, and answers.

12 Late June Communications PlanReviewType: Review

Multi-page This short document presented a number of issues that existed in theCommunications Plan that was under review. Items addressed related toa more effective manner of developing findings, minutes, andrecommendations resulting from the many SEVIS II meetings. Materialfor this document was developed from my 30+ years experience as theSecretary of the ANSI H2 Technical Committee on Database Languagesthat standardized the SQL Language. This document was developedduring the Communications Plan review but was never incorporated intothe IV&V review document.

13 Late June Business Event History OPR and 20+ page white A two-page OPR (observed potential risk) and a very extensive 20+


5



Id ApproximateDate



through Mid August

Type: OPRType: Anomaly

paper includingillustrative solution

page white paper was created to address one of the most critical SEVISII data management issues: Business Event Transactions. The whitepaper presented a comprehensive set of requirements from the FRD, anallocation of the 55 FRD identified and listed requirements on this singletopic to Products 6 Use Cases, and an illustrated approach that cansuccessfully handle SEVIS II Business Event History transactionmanagement.

14 Late Junethrough Mid August

Reference DataType: OPRType: Anomaly

OPR and 15 + page white paper includingillustrative solution

A two-page OPR (observed potential risk) and two white papers werecreated. The first white paper is 7 pages and is high level. The secondwhite paper is extensive 15+ page white paper was created to addressone of the most critical SEVIS II data management issues: ReferenceData. Six reference data cases were cited and illustrated how they existin SEVIS II. The effects from not addressing this type of reference datais also included in the white papers. The detailed white paper containsan illustrated solution for the Reference Data problem. A seventh casehas been created for Parameter-data such as critical dates, durationsbetween events, and the like that are to be set by and possibly changedover the life time of SEVIS II.

15 Mid August Requirements ProcessOptimization StrategyType: Anomaly

Multi-page white paper This document analyzes the current requirements analysis process. It hasbeen clearly stated by the SEVP business owner that the requirementsprocess is not working in an efficient and effective manner. This paperanalyzes the overall process and sets out mitigation strategies that helpthe overall process and especially the needs of data management.


6



Id ApproximateDate



16 Mid August Interfaces QualityAssurance Check ListType: Anomaly

Multi-page listing ofevaluation items.

A multipage check list of items that need to be assessed for the completelife cycle of every interface between outside sources and the SEVIS IIsystems. Built in concert with the ICE interfaces agreement documentand also similar documents from the U.S. Department of Justice and theDoD Architecture Framework documents. This document will enable areliable and repeatable process for assessing SEVIS II interfaces, whichexceeds 10.

17 Late August Data Model QualityAssurance ChecklistType: Anomaly

Multi-page This document brings forward all the data management problems thathave been observed since March 23, 2009. This document was createdin anticipation of the existence of a complete new set of data models sothat the data model assessment done by early April could be brought upto date. The document contains 8 sections: March/April DataManagement Problems, May 2009 Data Management Plan problems,May 2009 Data Management IV&V problems, Business Event Historyissues, Reference Data document issues, Parameters Issues, DAMA’sDM-BOK key assessment areas, and the Data Management IV&VArchitecture and Concept of Operations document sections. Each ofthese sections identifies the data management problems that wereidentified and cataloged when the referenced documents were created.


7



Id ApproximateDate



18 LateSeptember

Analysis of Use Case DataElements across all theSEVIS II Products (1, 2, 3,4, 6, & 7)Type: Anomaly

100 pages Identification of all use case data elements in terms of Reference Data,Master Data, and Parameter Data. Each use case data element ischaracterized by the Reference Data case to which it belongs so that thedata models can be properly assessed in regards to whether theyproperly address the data requirements of the use case data element.

19 Early October Analysis of September 29Delivery of SEVIS II dataModelsType: Anomaly

55 pages This 55 page document contains the analysis of the delivered set of datamodels from the Development Contractor to the IV&V. These datamodels were evaluated against 144 previously identified adversefindings and data management best practices and guidelines.

The 144 item checklist that was used to accomplish the data modelevaluation was developed from two sources. The first source was theApril through August adverse findings documents that I previouslycreated. The second source was the Data Management Association'sBook of Knowledge (DAMA DM-BOK). There were 113 items in thefirst set of documents and 31 items from the DAMA DM-BOK.

The final outcome of the Booz Allen Hamilton data model evaluationwas a 55 page document. Of the 144 evaluation items, 83 were unique;sixty-one were duplicate because they were reported multiple times inthe April through August adverse findings documents, or were also inthe DAMA DM-BOK. Of the 83 unique items, 55% continue to be"red," another 29% continue to be "orange," and only 12% are green.


8



Id ApproximateDate



20 Currentthrough10/9/09

Daily Activity LogType: Weekly

35 pages A daily log of activities since starting the data management IV&Vassignment at Burke Consortium.

21 Currentthrough10/9/09

Weekly Status ReportsType: Weekly

32 weekly status reports. Weekly status reports to BCI staff. By direction, these only list titles ofactivities. Recently, these have included “Notes” at the end pointing outdata management issues that highlighted from the various otherdocuments.


9


A04 Letter04 Four of Four_Weekly Summaries of Data Management IVVWork at Burke Consortium


54



October 13, 2009



This letter is the fourth of four letters that provides an overall assessment of the IV&V on the DHS ICESEVIS II effort. The four letters are:





This fourth letter provides a set of weekly summaries of my effort as the Data Management IV&VConsultant. DHS ICE has the SEVIS II development contract with Booz Allen Hamilton, hereinafterreferred to as the Development Contractor. DHS ICE has an IV&V contract with Burke Consortium,hereinafter referred to as IV&V Contractor. In turn, Burke Consortium had a subcontract with AmericanSystems, who, in turn had a contract with Whitemarsh Information Systems Corporation (hereinafterreferred to as Whitemarsh) to perform the data management IV&V services. The IV&V contract that ICEhas with Burke Consortium is from the DHS ICE OCIO Systems Development Division (SDD) SEVIS IIProject Manager, and the contract number is HSHQDC-06-D-00065-HSCETC-08-J-00020. Whitemarshworked 100% of the time at the offices of Burke Consortium under the daily and direct supervision of theIV&V Team Lead.

The contract between IV&V Contractor and the Government requires five kinds of deliverables:Statement of Work as to how the IV&V Contractor was to accomplish its IV&V activities, Bi-monthly


1

Whitemarsh Letter to American Systems with Weekly IV&V Summaries

reports, Observed Potential Risks (OPR) that are to be delivered to the Government as the risks areobserved, Weekly Status Reports, and finally, Anomaly Reports (from Section 7 of the IV&VContractor’s Statement of Work) that are to be reported to the Government about any situation and/orcondition that deviates from best practice on an as discovered basis.

The weekly summaries provided in this letter were derived from daily summaries organized by week thatreside on the “H” drive on the computer that is assigned to me to use at Burke Consortium, Inc. Formalweekly reports were provided by Whitemarsh to the IV&V Team Lead.

Delivered to the IV&V Team lead were formal reviews of documents provided by the DevelopmentContractor to the Government (a.k.a., Reviews).

Delivered as well were whole sections directly related to data management for the May 31st IV&V bi-monthly report (a.k.a., IV&V Report). Whitemarsh’s was excluded from contributing to the July andSeptember bi-monthly IV&V reports to the Government.

Only one of the Whitemarsh created Observed Potential Risk (OPR) reports was delivered to theGovernment (a.k.a., OPR).

Finally, a number of documents were created and provided to the IV&V Team Lead as “Anomaly”reports (a.k.a., Anomaly). All these “Anomaly” reports were described in the Weekly Status Reports andmade available to the IV&V Team Lead.

The daily work notes that describe the Whitemarsh IV&V activities are contained in a single 40 pagedocument and cover weekly reporting periods from Wednesday through Tuesday (Weekly). These dailysummaries cover the period, March 23 through October 9. 2009.

19 of the 21 documents produced by Whitemarsh during this period are identified in the table that followsaccording to a classification scheme that parallels that required of the IV&V Contractor by theGovernment, and are classified as: SOW, Reviews, IV&V Report, OPR, Anomaly, and Weekly.

Week Ending Date(Tuesday)

Weekly Summary

3/24/09 Reviewed SOW, a number of the Development Contractor’s data management focuseddocuments, and began analysis of the January 2009 data models in four functional areas.Devised strategy for discovering and recording problems contained in the data modelsinto an Excel spread sheet. Asked the IV&V Team Lead when we would meet with theDevelopment Contractor to review obvious data model problems.

3/31/09 Reviewed contractual documents, the Functional Requirements documents, and began torecord very obvious problems that existed. Recorded problems from each data model ontothe Excel spread sheet. Concluded development of the 20 pages of data model problemsBegan to draft an outline for the data management Section of the bi-monthly IV&V


2



Weekly Summary

report.

4/7/09 Met with Senior Software Engineer of the IV&V Contractor for about 90 minutes toreview all the data management problems that were discovered. Again requested that therebe able to meet with the Development Contractor data management staff. Developed anoverall data management IV&V diagram that had data models as the center and all theSEVIS II project components that either contributed to the data models or were directlyaffected by the data models. Created a cross-tabs matrix showing the involvement checks.Began the development of the Data Management IV&V Architecture and Concept ofOperations document that would guide my daily activities after being integrated into theproject’s engineering, architecture and development environment. Document Produced:#1 Data Model Analysis (Anomaly).

4/14/09 Worked on the development of the Data Management IV&V Architecture and Concept ofOperations document. The document exceeds 40 pages. Sent the document out for reviewby a set of data management best practice experts. Received good reviews andsuggestions on its improvement. Document Produced: #2 Data Management IV&VArchitecture and Concept of Operations (SOW).

4/21/09 Finally met the Development Contractor’s data management team lead. Had a very frankdiscussion about working relationship. He seemed totally surprised that there was interestin working with the Development Contractor in the identification, and resolution of datamanagement issues rather than just include the issues in the periodic IV&V reports.Indicated to him that my goal was to have nothing to report because all the issues wereresolved. The Development Contractor’s Data Management team lead indicated thatwould be a very big change.

4/28/09 Very carefully read the SEVIS II work breakdown structure document and noted anumber of very specific data management task omissions. Began the development of afour topic Observed Potential Risk (OPR) document that would be sent to ICE on thefindings to date. Directed by the IV&V Team Lead to break the four topics into separateOPR short papers of no more than two pages in length. Again read the FunctionalRequirements document cover to cover to better understand the issues.

5/5/09 Began to sketch changes to the Metabase’s data models so that Data Management IV&Vtask generated analysis work products could have a much higher quality and integration.Received the Development Contractor’s April 2009 SEVIS II data models. There waslittle to no change from the Development Contractor’s January SEVIS II data models.Hence almost all the identified problems remain. Attended a data model review meeting atthe Development Contractor’s facility. Indicated afterwards that the data models wereinadequate in regards to Reference Data, event dates, statuses, and the recording ofchange-event histories. Indicated that the data models could not be certified as conformingto requirements because of a lack of traces back to the requirements. The DevelopmentContractor finally seems to recognize that a data modeler should be attending therequirements meetings.


3



Weekly Summary

5/12/09 Was directed by the IV&V Team Lead to shorten the Data Management Architecture andConcept of Operations documents because the document was too detailed and technical.Drafted a Power Point presentation on the content and process of the Data ManagementArchitecture and Concept of Operations. Had hoped to be allowed to present this to theGovernment so they could realize value for their funds.

5/19/09 Began the development of a complete set of data management issues for inclusion in theIV&V bi-monthly report. Completed the development of 18 topics including findings,evidence, and consequences. Proposed that there would be a whole section for DataManagement IV&V as it is such a critical issue. Key questions arose on the requirementsand design process employed by the Development Contractor. Created a set of detailedprocess diagrams and offered to explain it to rest of the IV&V Team. None wereinterested in how the Development Contractor’s requirements and design process worked.#3 Document Produced: Data Management Issues (Anomaly).

5/26/09 Completed the review of the Development Contractor’s Data Management Plan.Identified over 30 issues. About half were “red.” Accomplished a review of theDevelopment Contractor’s Data Conversion Plan. There were about 30 issues. Created acomplete draft of the Data Management Section for the IV&V bi-monthly report.Document Produced: #4 Data Management IVV Report Section (IV&V Report)

6/2/09 Spent significant time including DAMA’s DMBOK (over 400 pages) citations into theData Management section for the IV&V report so that “recognized” industry best practicestandards could be referenced. Was directed by the IV&V Team Lead to remove the entireData Management’s section of 18 critical data management findings. Read the ICEEnterprise System’s Assurance Plan. Identified adverse findings regarding theDevelopment Contractor’s data management approach. None were allowed to be includedin the IV&V bi-monthly report. During a requirements meeting, the U.S. Department ofState raised key data management issues relating to business transactions and referencedata. These were issues that were noted in the first week of work. Documents Produced:#5 Draft of Data Management Plan Review (Review), #6 Data Conversion Plan Review(Review).

6/9/09 Made final modifications to the Development Contractor’s Data Management Plan byidentifying and describing key missing sections critical to the success of SEVIS II. Metwith the IV&V Contractor’s CEO and the IV&V Team Lead about all the different datamanagement deficiencies that were uncovered as early as the first of April and questionedwhy those were not communicated to the Government. Discussed the consequence of theTeam Lead’s unilateral removal of two-thirds of all the negative findings from thereviewed Development Contractor’s Data Management Plan. Developed a framework andstrategy for evaluating use cases from Products 1, 2, 3, and 4. Proceeded to analyze the 16use cases. Analyzed the use cases in regards to the Development Contractor’s materialsfrom their Data Management Plan, System Requirements Document, the SystemDevelopment Document, various Data Model Diagrams, History and Audit Trails,Reporting, System Design Document, Wire Frames, and Test Cases. Document


4



Weekly Summary

Produced: #7 Use Case Analyses for Product 6 (Anomaly).

6/16/09 Developed a complete set of findings and was directed by the IV&V Team lead to createan executive summary in support of just five of the 18 issues into key findings that wouldcause a meeting with the Development Contractor. Created a series of documents aboutdata management issues. Was instructed by the IV&V Contractor’s CEO that thedocument could be no longer than one page. Per direction from the IV&V Team Lead, reduced the Data Management IV&V Architecture and Concept of Operations documentsto just address Logical and Physical Data Models. This removes a major integratingmechanism, ISO 11179 Data Elements. Received instructions from the IV&V Team Leadto make the key issues document into a series of OPRs. Document Produced:#8 IV&VData Management Concerns (Anomaly).

6/23/09 Performed an in-depth analysis of the newly issued Integrated Master Schedule (IMS).Observed that the IMS still has significant data management task issues. These issueswould have possibly been addressed if the Data Management Section of the IV&V bi-monthly report had been included as a number of the issues addressed deficiencies in theIMS. There is no strategy in the System Design Document (SDD) to address businessrules that would permit definition, redundancy elimination, ensuring no conflict, and thelike. The SDD does not adequately address business transactions in terms of theiridentification, storage, and playing back. Department of State again raised the issue ofhistory in the requirements meetings. The Development Contractor indicated that historyis an issue that will be addressed much later in the SEVIS II project. On direction, sent arequest to the Development Contractor project lead for a data management issues meeting.The five key issues are: Value Domain Management, Business Rule Management,[Business Event] History, Audit Trails, and User Acceptance Tests. There were lowerlevel issues that needed to be addressed as well including generalized data structures,unverifiable database designs, database to software tracings, backup and recovery, logicaland physical database reorganization. Developed a scenario example for all these keyissues. Began the development of an IV&V data management concerns paper. DocumentProduced: #9 Help Desk Plan Review (Review).

6/30/09 Made changes to the Data Management IVV Architecture and Concept of Operationsdocument. Received reviews from Senior Software Engineer of the IV&V Contractor andmade appropriate corrections. Participated in the data management issues meeting at theDevelopment Contractor’s facility. Was directed to only address 5 issues out of the 18identified. Meeting results were: Mappings from Use Cases to Data Models are beingdone informally by the Development Contractor’s data modeler. No time schedule for anydeliveries. Audit trails are only being done from a database recovery point of view. TheDevelopment Contractor does not believe there is a requirement for business event historyin SEVIS II and that it will be addressed in Product 9 and 10. Reference DataManagement has been declared complete by the Development Contractor. Business Rulesare to be accomplished in the user-interface layer through program logic. TheDevelopment Contractor’s data modeler however disagrees with that Reference Data isacceptably addressed. Reporting is to be addressed through the development of standard


5



Weekly Summary

reports. Outcome of the meeting at IV&V Contractor is that two OPRs will be created:Business Event History, and Reference Data Management. Began research into thecomplete identification of all the requirements from the Functional RequirementsDocument that address Business Event History. Began to create the Business EventHistory white paper. Assessed the IMS in regards to work accomplished (earned valuemanagement) and the time available for Products 9 and 10. The time available is whollyinadequate to the presumed effort. Received review of the Business Event History paperfrom Senior Software Engineer of the IV&V Contractor and made correctionsaccordingly. Document produced: #10 Analysis of Data Management Concernsemploying the I-17 as the example (Anomaly), #11 Data Management IV&V Concernswith Consequences and Conclusions (Anomaly), # 12 Communications Plan Review(Review).

7/7/09 Continued development of the Reference Data paper including setting out the six differentclasses of reference data and citing how the existing May 2009 data models will just notwork. Received additional guidance from the IV&V Contractor’s CEO and the IV&VTeam Lead on the engineering and content of the Business Event History OPR. Theexample suggested by the IV&V Contractor’s CEO to be used in the OPR was just nothelping. After review, it seems clear that the real issue is that the Development Contractorhas just not understood the over 35 specific requirements that focus on SEVIS II businessevent history. Redrafted the white paper to clearly cite the business event historyrequirements and how these were not being addressed in the Product 6 use cases. Thedirection of the OPR is that the requirements in this area must be revisited by SEVP andthe Department of State to ensure that the Development Contractor sees the need toaddress them in the database’s design and the architecture of the software.

7/14/09 Attended batch processing meetings. This whole area is critical to the project. This type ofprocessing highlights a critical failing of the database’s design, that is, no natural-business-data-based unique keys. All the keys are surrogate keys. That is likely to cripplebatch processing. Drafted a new version of the Reference Data OPR. Began an FRDsearch for Reference Data requirements. There are just 17. Had final review of theBusiness Event History OPR. Found more FRD requirements. There are now about 55.Began changes to the Business Event History white paper to bring it back in line with itsOPR. Department of State has indicated that the Product 2 software (DS-3036) isunusable. Seems that its design was changed without review from the Department ofState.

7/21/09 Reviewed the Development Contractor’s revised Data Management Plan. All the criticalchanges that needed to be made to make the database’s design valid were not corrected.SEVP is clearly not happy with the Development Contractor’s approach to requirementsengineering. The Business Owner from the Government stated emphatically that SEVIS IImust be able to re-materialize whole sequences of business events because of the need tosupport Justice Department court cases. It was clear from the Development Contractor’sreaction that they only see the need to record the data necessary to replay database-table-based changes rather than over-time integrated multiple table collections. Clearly no


6



Weekly Summary

context information (who, what, when, where, why, and how) is part of the SEVIS IIdatabase’s design for business event contexts. Received a final review of the BusinessEvent History OPR from the IV&V Contractor’s CEO and the IV&V Team Lead. TheOPR was watered down by the IV&V Contractor’s CEO to be “may and might” versus“can and will.” Voiced concern that once submitted it will be ignored. Created a VISIOdiagram of a set of Business Event History context collection database tables that willminimize any changes to the existing database design. Wanted the OPR and the whitepaper to be sent to the Government. Only the OPR was allowed to be sent. Was told bythe IV&V Team Lead that the Government would not read it because it was too technicaland too long. Document Produced: #13 Business Event History OPR (OPR).

7/28/09 Continued the redrafting of the Business Event History white paper. Continued revision ofthe Reference Data OPR. Presented to the IV&V Contractor’s CEO and the IV&V TeamLead that there are six reference data cases and that the database can only handle Case 1.Presented to the IV&V Contractor’s CEO and the IV&V Team Lead that use case dataelements are not well defined and some contain embedded values in their names.Suggested that we need to work with the Development Contractor to suggest ways toimprove the Requirements gathering process. Was told explicitly by the IV&V TeamLead that working with the Development Contractor was impossible until “issuesexploded.”

8/4/09 Again revised the Reference Data OPR to make sure that it was two pages. AttendedProduct 7 requirements session in which the Government’s Business Owner that SEVIS IIhad the requirement to be able to track all related business event actions throughout thedatabase. The Development Contractor completely re-engineered the Integrated MasterSchedule so that it was not Product centric but was time and phase centric. Redrafted theIMS quick guide that I had developed several weeks earlier that enabled me to follow theprogress being reported in the Integrated Product Team meetings. Drafted an analysis ofthe Development Contractor’s database table and column cross reference that wasprovided for just one use case by the Development Contractor’s data modeler. Indicatedthat using Excel to accomplish this cross reference would be a very inefficient and errorprone. Document Produced: #13 Business Event History white paper (Anomaly).

8/11/09 After a review of the Reference Data OPR, the IV&V Contractor’s CEO decided that theReference Data OPR would not be submitted because the existing data models did notclearly identify the problem. It would have to be delayed until a new set of data modelsarrived in the Fall to prove that Reference Data is not being adequately addressed. TheIV&V Team Lead indicated that until a SEVIS “train wreak” happened, that ICE, SEVP,and the Department of State would not pay any attention to the Reference Data and/or theBusiness Event History OPR. Documents Produced: #14 Reference Data OPR (OPR),Reference Data white paper (Anomaly).


7



Weekly Summary

8/18/09 During an IPT meeting, it because clear that there was confusion regarding the existingdata models. The Development Contractor’s data modeler was on vacation that wholeweek. Rather than have the discussion focus on incorrect understandings, I suggestedwhat the data models actually “said.” Followed up the suggestion with an email toDevelopment Contractor’s requirements team lead providing a more detailed explanationof the data models and several alternative strategies to accomplish what the IPT meeting’sdiscussion was about. Was instructed by the IV&V Team Lead that it was whollyimproper of me to have communicated with the Development Contractor’s requirementsteam lead. Began the development of a refined approach to deal with data managementissues within the context of requirements meetings. The developed strategy wouldincrease requirements development velocity and quality while at the same time reduce riskand cost. Drafted and sent email about this to IV&V Team Lead. Document Produced:#15 Requirements Process Optimization Strategy (Anomaly).

8/25/09 Refined the requirements development strategy at IV&V Contractor’s CEO request into asingle short paper. Was told by the IV&V Team Lead that it was impossible toaccomplish as nobody would listen. Began to review the Interface Control Agreement(ICA) template. It was clear that the two existing ICA documents did not follow the ICEtemplate and differed significantly from each other. Since IV&V Team would have toreview more than a dozen ICA documents, a study of just what should be in such adocument was begun. Developed a comprehensive topical outline that both meets theneeds and conforms to the ICE requirements. From a requirements meeting, it is clearthat the Batch Processing ICA will have to have separate sections for each businesstransaction type. Researched the existing EDS model for SEVIS I Batch Processing andthat’s exactly how it was done. The Government’s Business Owner’s presentation clearlysupported the critical need for the Business Event History data model strategy that iscontained in the Business Event History white paper. Document Produced: # 16Interfaces Quality Assurance Checklist (Anomaly).

9/1/09 Began to work on a data model evaluation checklist because a new set of data modelswere to be received during the next week. The check list was engineered to contain all thepreviously identified data model errors and issues that since the last week of Marchincluding the Data Management Plan, the Data Management Issues, the drafted DataManagement IVV Report section, etc.


8



Weekly Summary

9/8/09 Provided the drafted ICA check list to the IV&V Senior Software Engineer for his review.Received excellent suggestions and made revisions accordingly. Subsequently received anemail from the IV&V Team Lead that instructed me to not involve the IV&V SeniorSoftware Engineer any more without explicit permission. Asked the IV&V SeniorSoftware Engineer if he objected and he indicated that he was as surprised at getting theemail. Began the development of a complete list of all use case data elements that areeither Reference Data, Parameter Data, or Master Data so that the list could be employedduring the data model evaluations. This document addresses all the use cases fromProducts 1, 2, 3, 4, 6, and 7 (up until 9/23/09). Document produced: #17 Data ModelQuality Assurance Check list (Anomaly).

9/15/09 Continued the identification of the use case data elements for Reference Data, ParameterData, and Master Data. Developed an analysis of the problems that will occur if schools,organizations, and groups are not properly designed within the Development Contractor’sSeptember 2009 SEVIS II data models that are to support Products 6 and 7. Therequirements meeting on just this issue brought out the intricate nuances that had to beaddressed. During a pre-requirements meeting time, when only the DevelopmentContractor’s data modeler and I were on the phone, I indicated that there is a network datastructure for schools in the Development Contractor’s June 2009 SEVIS II data modelsthat could be used to map the movement of schools within different organizationalconstructions. I was told by the Development Contractor’s data modeler that it was goingto be deleted from the September 2009 data models. I suggested to him that it reallyshould stay and be extended. During the requirements meetings it became clear that theDepartment of State and SEVP handle organizations and groups differently. This wouldseem to be a problem as there is only one database and one set of tables for the school,organization, and group data. The requirements on groups, schools and organizations willhave an effect on existing software and possibly the database design. Developed atechnical note to the IV&V Team Lead indicating why network data structures are criticalto being able to track the history of school, group, and organization changes.

9/22/09 Continued the identification of the use case data elements for Reference Data, ParameterData, and Master Data. The document will likely approach 100 pages. Attended a 10 hourrequirements meeting. The Government’s Business Owner indicated that the Product 7use cases cannot be completed until all the external system interfaces are understood anddesigned. That includes the Batch processing interface. There was also a lengthydiscussion of indicators and counters. It will be critical to understand how the database’sdesign and software will handle the re-creation and/or auditing of the values associatedwith indicators and counters in the event of system failure or the doubting of specificvalues. The SEVP Business Owner is working on a SEVIS II business terms glossary andthe development of a single set of all use case data elements across all the use cases that isconsistent and non-redundant. During the identification of the use case data elements, it isclear that some use cases from Product 1 and 7, and Product 2 and 6 should have identicaluse case data elements. They do not.

9/29/09 Almost completed the identification of the use case data elements for Reference Data,


9



Weekly Summary

Parameter Data, and Master Data. Without a tool such as the Metabase System, evolutionand maintenance of this 100 page document given revised and/or new use cases is goingto be very difficult. Indicated this in my status report. Received the September datamodels. A quick glance indicates that significant problems appear not to have beenresolved from the Development Contractor.

10/6/09 Completed the identification of the use case data elements for Reference Data, ParameterData, or Master Data. Across all the uses cases but without the elimination of duplicates,the final counts are likely to be 4500 business data elements, about 1000 Reference Dataelements, and about 750 Parameter Data elements. That’s a total count of about 6500. Toaccomplish a certification of the data models from the use case data elements, about 1800staff hours will be required. If a tool like the metabase system was employed, it wouldtake about 400 staff hours. Modification of the metabase system to allow for use case todatabase table and column mapping would take about 200 staff hours. Without themapping, it is impossible to certify that the database design conforms to requirements. It isthen impossible to certify that the software, training, and testing conform to requirements.Developed a data model evaluation results document. There are 144 distinct items thatwill be assessed in regards the received data models.

Completed two passes on the assessment of the SEVIS II data models that were providedto the IV&V Contractor on September 29. Of the 144 issues, there are 103 that are unique.The 41duplicates are items that have been reported more than once to the IV&V TeamLead. Of the 103 issues, 59 (57%) are “red.” 31 are “orange” because there was notenough information to classify them either as red or green. The majority of these itemswill likely be “red.” There are 10 “green” items. The remaining 2 items are legitimately“orange” because they have been partially accomplished. An issue is classified as “red”because it represents a significant failure in meeting SEVIS II business requirements andwill likely cause both a change in the database’s design and in the existing and underdevelopment software. During the remaining three days, mitigation strategies will beidentified for each issue.

Document Produced: #18 Analysis of Use Case Data Elements Across all the SEVIS IIProducts (1, 2, 3, 4, 6, and 7) (Anomaly).

10/13/09Document Produced: #19 Analysis of the September 29 Delivery of SEVIS II DataModels (Anomaly).

Regards,



10


A05 SEVIS II Data Management IV&V Concerns_With Consequences


55

1

SEVIS II Data Management Analysis 6/11/2009

This IVV report focuses on the data management aspects of SEVIS II. An analysis of the data management artifacts started late in March and continued until the date of this report. Examined were the January, March, and May data models, the Data Management Plan, the Data Conversion Plan, the Functional Requirements Document, the System Requirements Document, and the System Design Document. These were all examined individually and in conjunction, one with the other. Produced as a consequence of this analysis was a 20+ page data model issues document, a 30+ issues Data Management Plan review document, a 30+ issues Data Conversion Plan review document, 30+ pages of use case analyses, and a May 2009 IVV Report Data Management Section that contained 18 recommendations. In addition to these analyzed documents, attendance at several dozen Requirements meetings provided additional understanding the overall SEVIS II requirements. The table that follows identifies, briefly describes, and sets out the likely consequences from these SEVIS II data management issues. At the end of this report are the recommendations related to substantiating these data management issues or causing them to be amended. SEVIS II Data Management

Issue

Description Likely Consequences

Mappings Among the Artifacts

There is no end-to-end evidence from requirements to use cases to wireframes to system requirements to system design that interlinks their common thread, the database’s tables and columns.

The requirements expressed in the FRD, the use cases, and the verbal requirements expressed during meetings cannot be verified through the database designs. Thus, the software will have to undergo a very long and detailed user acceptance test period. Errors found then will be significantly more time consuming and expensive to resolve than if they were discovered through mapping analyses.

Audit Trails, History, and Business Transactions

Despite 37 distinct requirements in the FRD for comprehensive and very sophisticated audit trails, history, and business transactions, there is no evidence in the researched documentation that SEVIS II has an approach to support these requirements.

The ability will likely not exist to track the history of all the school, organization, visa, fees, and person SEVIS II business events required by the FRD and expressed as required in virtually every requirements meeting. Fixing the database once any significant quantity of software has been constructed will be very time consuming, expensive, will likely require a whole new round of audit trails, history, and business transactions centric requirements determination, and may likely require a complete re-importation of the SEVIS I data and the reapplication of all SEVIS II business transactions subsequent to the FOC date.

Reference Data Management

The treatment of reference data within SEVIS II will not allow value and meaning migration and mapping across time.

Reference data values and meanings for those will change over time. It will be essential to be able to map old values to new values, and to map changed meanings. Otherwise the contextual meanings of entered data will not be preserved.

Business Rule There is no evidence of any It will be inevitable that different software

2

SEVIS II Data Management

Issue

Description Likely Consequences

Management centralized approach to business rule definition and then business rule execution binding in order to prevent redundancy and conflicts across the SEVIS II database and software.

modules within SEVIS II will update the same data under different rules causing unreliable and unrepeatable results. If business rules are defined and bound only within the application software, users who have direct access to the SQL language will be able to compromise the integrity of the database because there will be no DBMS-based controls to prevent malicious or mistaken updates.

End User Reporting

The current database design has a number of table structures that preclude easy end-user ad hoc reporting.

The myriad of SEVIS II end-users at DHS, the Department of State, and other authorized end users will either have to have intimate knowledge of the database and possess sophisticated programming skills, or the SEVIS II project will have to create and maintain an additional SEVIS II database especially designed for end-user reporting through ad hoc query languages and report writers. If the former, SEVIS II will not be an easy to use system. If the later, a large and costly additional SEVIS II reporting system’s effort will have to occur to effect an easy to use reporting environment.

Recommendations

1. Mappings: Provide the evidence through any appropriate means to validate that mappings exist from functional requirements through to software so that the database’s design can be verified and validated as conforming to SEVIS II requirements.

2. Audit Trails et al: Provide a detailed approach that can be studied, verified, and validated by the IVV and the SEVIS community (e.g., SEVP and Department of State) to accomplish the 37 FRD requirements with respect to audit trails, history, and business transactions. Include in the approach an estimate of the resources required to create and maintain such an environment as it relates to the existing set of database tables and columns, software, and SEVIS I to SEVIS II data conversion.

3. Reference Data Management: Provide a detailed approach that can be studied, verified, and validated by the IVV and the SEVIS community (e.g., SEVP and Department of State) that comprehensively addresses the need to evolve, maintain, and map reference data across the life span of SEVIS II.

4. Business Rule Management: Provide a detailed approach that can be studied, verified, and validated by the IVV and the SEVIS community (e.g., SEVP and Department of State) that enables the once-only creation of business rules, and an approach to distributing, binding, and testing business rule execution to ensure non-redundancy and the elimination of conflict.

5. End User Reporting: Provide a detailed approach that can be studied, verified, and validated by the IVV and the SEVIS community (e.g., SEVP and Department of State) that ensures that an end-user ad hoc reporting environment can be created and maintained. Include in the approach an estimate of the resources required to create and maintain such an environment.


A06 Data Management Issues_2009_05


56

1

Data Management Issues I. Database Component Development and Management Related 1. Topic: Data Model Adequacy Finding: The Data Models cannot be determined to be adequate for the project. Evidence: No traceability documents exist among any of the key SEVIS documents. Thus, it

cannot be ascertained if the data implied by Government Forms, FRD, SRD, Use Cases and Wireframes are adequately mapped. For example, while use cases reference data elements, database tables only have columns. Thus, you cannot cross reference use case data elements with database table columns.

Consequence: Without end-to-end traceability with respect to database and the software, tracing of and fulfillment of requirements cannot be certified.

2. Topic: Value Domain Management Finding: There is no evidence of an adequate treatment of value domain within individual

columns or across columns that have common value domains. Evidence: The value domain centric data model tables are inadequate to handle restricted

value domains on a per column basis, common deployment across columns, value domain value progression, and value domain change mapping. There are not value-domain based test plans.

Consequence: Without sophisticated value domain management it will be difficult for SEVIS to know if many of its critical policies are being followed in an orderly manner. It will be further difficult to migrate value domains from set of values to another especially when the count of values changes.

3. Topic: Discussion Recording into Use Cases Finding: Requirements meetings minutes do not exist. Requirements statements from

SEVIS users are not recorded into Use Cases. Evidence: There are no minutes or change logs between one iteration of a use case with

another Consequence: Expressed requirements such as history and audit trails are not making it into the

use cases. Consequently they are not in the wire frames, nor the database design. Hence they cannot be in the software, and from there not in the user acceptance tests.

2

4. Topic: Database Comments Finding: There appears to be an inadequate approach to the understanding of and capture

of “comments.” Evidence: There is no detailing in the WBS that cites how and what is being captured during

the Requirements Phase tasks for Packages. There does not seem to be any agreed-to strategy for the definition of comments that is then applied consistently across all the database tables.

Consequence: “Comments” is a database column that appears in different database tables. If there can be a structured set of comments that can be picked by end users, they should be. That’s because with fixed values there can be analysis and reporting. It is likely that comments exist within higher levels of overarching comment categories. These too can be employed for reporting and query purposes. If a fixed choice is not sufficient the user could then pick “other” and enter a free form comment.

5. Topic: Reporting Database Finding: There are no documents on the process of building and refreshing a reporting

database. Evidence: The kickoff meeting presentation did not address the most critical issues related to

the development of a reporting database. The WBS (tasks 3512 – 3623) do not seem to address the critical issues regarding reporting database design, or the frequency or method of reporting database refreshing.

Consequence: There is going to be a need for a reporting database. How this will be created is yet to be determined. Is it to be a set of Star Schemas or a traditional set of ER-model based tables. What resources will be needed to determine, design, and implement this reporting database? How often will it be refreshed? How will the determined resource requirements be folded into the existing set of SEVIS II operational schedules?

6. Topic: Batch Processing Finding: There are no documents on the process of Batch Processing. Evidence: The Batch WBS based schedule does not expect to start until late 2009. The likely

effect of batch on the database designs is unknown. The WBS does not offer any hint as to the issues that will be addressed.

Consequence: Batch processing will impose a whole new paradigm for business transaction management. Each batch transaction needs to be defined. How they are committee has to be engineered. How batch and on-line processing will interact needs to be carefully assessed.

3

7. Topic: Database Component Use Cross Referencing Finding: There are no documents on the process of Database Component Use Cross

Referencing. Evidence: There are no WBS tasks other than a cursory indicated that “updates” will occur

as to how cross package and cross product analysis and change will be conducted. Consequence: A number of use cases reference the same “data elements.” Since data elements

are not cross referenced to database tables and columns, it is impossible to fully judge the impact of different use cases on actual database data. Use cases also change over time, both within a product and across products. Without a database-centric cross referencing capability there cannot be a comprehensive assessment of the impact of for example, use cases, wire-frames, software modules, business rules, value domains, and the various types of batch interfaces.

II. History and Transaction Management Related 8. Topic: History and Auditability Finding: There are no project released documents that describe the approach for SEVIS II

updating history. Evidence: There are no project released documents that identify business transactions, the

capture of business transaction metadata within given rows and across collections of rows. There is no specification of the database data that is captured commonly across all business transactions and/or uniquely for each business transaction. There are no formally identified and defined use cases that address history and auditability. There does not appear to be a strategy to capture the names or Ids of the specific database columns that change in any given transaction. What changed, and from what value to what new value appears to be a responsibility of the end-user determination.

Consequence: It will be very difficult if not also impossible to follow SEVIS II business data changes within the database.

9. Topic: Business Transaction Management Finding: There is no evidence in the data models that recognize the requirements meetings

expressed need for business transaction creation, storage, reporting, and tracing. Evidence: The WBS is completely silent on these issues. No tasks planned, resources

allocated, and the like. Consequence: Without a formal definition of all the SEVIS II transactions and the capturing of

all the data from across all the business transaction related database tables and supporting metadata (data about the transaction) and the retention of that data onto a persistent record that can be queried and reported there cannot be an audit trail of all the actions against the database.

4

10. Topic: Recording Statuses and Status Changes Finding: There is an insufficient quantity of statuses and supporting data for changed

database data. Evidence: The WBS is silent on this issue. Additionally, during Requirements Phase use

case discussions, this issue is glossed over. Consequence: Without attention paid to both single status changes and families of status

changes, and without the proper quantity of metadata for each status change, that is date, by whom, and for what reason supplemented by comments, it will be impossible to understand all the different statuses that SEVIS II data proceeds through. Missing as well appears to be the identification of the columns that have changed values that in combination would cause the status to change from one value to the next.

III. Data Management Component Testing 11. Topic: User Acceptance Tests Finding: There are no documents that address User Acceptance Tests as it related to Data

Management Issues Evidence: The WBS is completely silent on these issues. No tasks planned, resources

allocated, and the like. Consequence: Without data management issue tests such as those associated with the creation,

and evolution of value domains, the migration and mapping among changed value domains, the assurance that value domains outside the boundaries of managed valued cannot be employed, or the choice of “out of sequence” values cannot be employed. Other UATs that are database related include Transaction Management, Transaction rollback, database recovery, database backup, and DBMS Performance Testing. All these have to be tested before deployment so that adequate resources for hardware can be deployed as well.

12. Topic: Testing of Data Management Components Finding: There are no materials in the Testing Plan that address data management issues. Evidence: The WBS is completely silent on these issues. No tasks planned, resources

allocated, and the like. Consequence: Key data management issues such as value domain management, audit trails,

backup & recovery, transaction commits, roll-backs, and logical & physical database reorganization are not being addressed in requirements, use cases, database design, and user acceptance testing. There is therefore no way to completely know the total requirements (FRD) and whether the requirements are being met.

5

IV. Database Management System Related 13. Topic: DBMS Schema Based Assertions, Constraints, and Stored Procedures Finding: There is no evidence of the identification, development, and incorporation of

Assertions et al as SQL Schema Objects Evidence: The WBS does not contain any tasks that support the creation of assertions,

constraints, or stored procedures. Consequence: DBMS Schema Based Assertions, Constraints, and Stored Procedures are

analogous to views in that they represent processes that are to be performed by the DBMS directly instead of being accomplished by SEVIS II software application logic. Thus, Assertions, Constraints, and Stored Procedures are defined once and bound to the DBMS schema as objects that are invoked when certain conditions exist. Such conditions can be status changes, or certain database actions such as any update, particular inserts, database update errors, and the like. These DBMS Schema Based Assertions, Constraints, and Stored Procedures reduce design, programming, testing, and documentation time. They also increase quality in that they only have to be changed once to have the change instantly applicable by all processes that are to employ the schema object.

14. Topic: SQL Views Finding: There is no SQL view data model. Evidence: The WBS does not contain any tasks that support the creation of SQL views, nor

have there been any View deliverables. Consequence: Without a view model a very significant quantity of the database commands have

to be directly programmed into the SEVIS II application. If these are in SQL views then this logic only has to be defined, debugged, and documented once. Additionally, it can enhance the performance of the application system by letting the database server perform all this database selection, navigation and presentation logic. Views also enable a more sophisticated form of value-based security that would be based on value supplied to variables that are involved in the view’s Where-clause logic. If views were defined as an entire set of data for a given business transaction, Security, Assertions, Triggers, et al could be “attached’ to the views. This would make SEVIS development less costly and less difficult. It would make testing easier as tests could be created especially for views and once tested the software systems that employ the views would have smaller test foot-prints. If there is an alternative to the view model it needs to be ascertained if that alternative is constructed such that it offers the same benefits as do views. For example, that it cannot be avoided by all SQL-based run-unit access mechanisms. It can include both row and column security. It can automatically

6

kick off assertions, constraints, and stored procedures. 15. Topic: SQL based Security Finding: There are no documents that identify any SQL-based security. Evidence: The WBS does not contain any tasks that support the creation of SQL based

security. Consequence: The security of SEVIS data is clearly role and organization based. While there is a

top-level document that identifies these roles and organization there is no mapping to use cases, database tables, columns within the tables, nor Where clauses that would enable or prohibit specific row or row-collections to be accessed. If the security were layered on top of views, the security definition, implementation, and maintenance process would much simpler and less costly to define and to maintain.

16. Topic: DBMS-based Backup, Recovery, and Transaction Management Finding: There are no documents that address Backup, Recovery, and Transaction

Management Evidence: The WBS is completely silent on these issues. No tasks planned, resources

allocated, and the like. Consequence: The DBMS processes of Backup, Recovery, and Transaction Management all

consume resources and take significant clock-time. As the database grows, more and more time and computing resources will have to be devoted to these efforts. There are different strategies for transaction management that either takes shorter time but with a corresponding longer time for transaction roll-back and database recovery in the event of a crash, or transaction management strategies that take a long time but with a corresponding shorter time for transaction roll-back and database recovery. A key issue is how these processes are defined, tested, and folded into the overall schedule for the operation of SEVIS II.

17. Topic: DBMS-based Performance Testing Finding: There are no documents that address DBMS-based Performance Testing Evidence: The WBS is completely silent on these issues. No tasks planned, resources

allocated, and the like. Consequence: As time progresses, database performance degrade. The degradation is not linear.

After a while the “extra” room set aside in the various components that make up the actual DBMS design of the database exhaust and sub-optimal structures are appended. After a while, there are many layers of suboptimal structures and the database application slowly becomes unacceptably slow. At that point, a physical

7

database re-organization will be required. That takes considerable computer resources and clock time. Work tasks need to be included to assess the degradation of operational performance, and to take remediation steps before the responsiveness of SEVIS II becomes an issue. Both the assessment processes and the database performance tuning tasks need to be included in the overall operational schedule of SEVIS II.

18. Topic: Logical and Physical Database Reorganization Finding: There are no documents that address Logical and Physical Database

Reorganization Evidence: The WBS is completely silent on these issues. No tasks planned, resources

allocated, and the like. Consequence: Logical and physical database reorganization is different from logical and

physical data model reorganization. The former means that the database is up and running and the SEVIS II program is operation. The latter means that the data model are not yet complete, the application systems are not finished and SEVIS II has not yet been deployed. Logical and physical database reorganization is a naturally required component of any running database application. Logical database reorganization means that some aspect of the database’s design has changed and the change has to be accomplished. If the database is accessed directly through database tables as opposed to views, then almost any logical database reorganization involves application program changes. To mitigate against these changes SEVIS II change scenarios should exist so that mitigation strategies can be incorporated into the logical data model, physical data model, and SEVIS II application program logic.


A07 Data Management IVV Architecture and Concept of Operations


57

1

Data Management IVV Architecture and Concepts of Operation

4/22/2009

1.0 Overview In a large scale data-centric environment, there are a number of factors in the determination of an overall success. Among these are:

Project Management which includes the overall project’s architecture, engineering and deployment with special focus on requirements, schedule, and costs.

Data Management which includes data architecture, modeling, engineering, and deployment along with evolution and maintenance.

Hardware Management which includes computing and network hardware architecture, engineering and deployment along with evolution and maintenance.

Software Management which includes software application, engineering and deployment along with evolution and maintenance.

The focus of this paper is Data Management. To that end, the objectives of this paper are to:

Set out an overall contextual diagram for data management environment as it relates to a large scale data-centric project such as SEVIS II.

Briefly define each of the components of this data management environment.

Briefly describe how the components are interrelated one with the other through the core data model component.

Illustrate these data management component interconnects through the use of a scenario.

Set out a proposed Data Management IVV process, assessment, deliverables, and reporting strategy built upon these data management components.

2.0 Data Management Contextual Environment

2

There are two major classes of components in the data management contextual environment:

Data Models Interrelated Components

The data models component consists of six classes of data models, which are all interrelated one to the other. The objective of these six models is to significantly increase semantic interoperability, increase re-use, eliminate redundancy, and reduce the overall cost of project specification, implementation, and maintenance. The effect of having these six models is a way to decrease overall project risk while at the same time increasing quality. The consequence of not having these models is the converse of these objectives and effects. Table 1 enumerates and briefly describes each of these six data model classes. These six data model classes have real, practical, and existence implications for enterprises. To wit: The Y2K data debacles were a direct consequence of enterprise failure to have these six data models within a non-redundant, unambiguous and integrated data model management environment. Most recently, the NASA 1999 Mars Climate Orbiter crash was directly tied to fact that one organization was computing with “metric” unit measurements and another was computing with “English” unit measurements. The existence of a Data Element Model semantics capstone would have controlled data specifications, implementations, and operations would have surfaced this semantic disconnect.

Data Model Class

Description Key Components

Data Element Data Model

A model of the data elements employed throughout the SEVIS II environment independent of any deployment context. The data elements defined in this model are the basis of the semantics employed by contextual facts. That is, facts specified in, for example, containers such as entities, tables, DBMS tables, screens, or reports. Data Elements are thus defined-once and its semantics are deployed many times across all these different containers.

The key components of the data element data model include: Concepts, Conceptual Value Domain, Value Domain, Data Element Concepts, Data Element Classifications, and Data Elements.

3

Data Model Class


Concepts Data Model

A concepts data model is a data model of a specific concept, represented as a container such as student, school, organization, or address. These containers (e.g., student or school) must be specified before they can be implemented in one or more different database collections of tables that ultimately become operational through a DBMS such as Oracle. Concept data models are not data models of databases. Rather, they are data models of concepts within and across functional areas. Concept data models are independent of database engineering. Attributes of the entities from within these specified concept data models are deployments of the semantics of data elements from within the Data Element data models.

The key components of the concepts data model include: Subjects, entities, attributes, primary and foreign keys, and attribute assigned value domains.

Logical Data Model

A data model is a data model of a database that is independent of any given database management system (DBMS) such as Oracle. In this state, that is, independent of any particular DBMS it is termed “logical.” Most commonly these database models are precisely defined in third-normal-form. Columns of the tables from within these to be implemented data models are deployments of a single attribute of an entity from a concepts data model.

The key components of the data element data model include: Schema, table, column, primary and foreign keys, and column assigned value domains.

Physical Data Model

A data model is a data model of a database that is bound to a specific database management system (DBMS) such as Oracle. In this state, that is, dependent upon a particular DBMS and upon the performance requirements of a particular software application, this data model is termed “physical.” These data models are the operational data models that are bound to application software systems through view data models. These data models are often not in third normal form as a way to meet needed performance requirements. DBMS Columns from the DBMS tables from within these operational data models are deployments of a single column of a table from a logical data model.

The key components of the data element data model include: DBMS Schema, DBMS table, DBMS column, primary and foreign keys, and DBMS column assigned value domains.

View Data Model A view data model is a data model of the interface between a physical data model and one or more application software systems. View data models are bound to

The key components of the data element data model include: Views, view columns, data integrity clauses, selection clauses, and inter-DBMS

4

Data Model Class


the particular DBMS through which they are defined. View data models enable application systems to select, employ, and update databases according to their physical data models without having to include physical data model details within the application systems.

table relationship processing clauses.

XML Data Model An XML data model is a data model of data that is both DB MS and application software system independent. The structure of XML data is expressed through an XML schema that is employed to then understand the contents of XML data records. XML schemas are created through special software applications. XML data streams are created by source application software systems and are subsequently read and processed by target application software systems.

The key components of the data element data model include: XML Schema, and XML element.

Table 1. Data Model Classes and Brief Descriptions The interrelated components are the components that relate to one or more of the data models in some fashion. Figure 1 presents the overall data management contextual model. Table 2 enumerates, defines, and interrelates each of these Figure 1 components. Figure 1 shows that the core of the data management environment is the data model environment. Within this environment there are six distinct data models. For example, the Data Element model captures the once-only identification, specification, and definition of data elements that may be represented as database table columns in many different database tables. Similarly, there may be concept data models, for example, for students, schools, organizations, or addresses. These concept data models can be deployed in one or more logical database models, which, in turn are operationally deployed in one or more DBMS specific physical data models. Each of these six data model classes serve a special purpose and is interrelated with the other data models in some integrity-enhancing and work-saving manner. Again, Table 2 provides definitions and interrelationships. Figure 1 shows a left-side set of one-to-many relationships going “down.” This relationship supports two meanings. The first is the mapping of an individual component of a model, and the second is the mapping of a whole collection from within a data model. In the Data Element model there can be individual data elements such as Person First Name, and there can be collections of data elements within a specific data element concept collection, for example, Person Related Information such as Person Identifier, Person Birth Date, Person First Name, Person Middle Name, and Person Last Name.

5

In the first type of left-side one-to-many relationship, the individual data element, Persons First Name would be semantically mapped to zero, one, or more attributes within different entities. For example, to Employee First Name, to Customer Contact First Name, or to Causality Insurance Contract First Name. In the second type of “left-side” relationship, a whole collection of data elements can be mapped to a whole collection of attributes across one or more entities. For example, all the Data Elements within a Data Element Concept collection called Biographic Data Elements might be mapped to the entity, Person Information, or to the entity, Customer Contact Information. In this case, the mapping of the data elements, Person Identifier, Person First Name, etc., is mapped to a corresponding set of attributes within one or more entities. On the right-side of Figure 1, there is also a set of one-to-many relationships. This set, like the left-side one-to-many relationships has two meanings: individual component, and whole collections. The meanings of the right-side one-to-many relationship are different from the left-side one-to-many. The first type of right-side relationship, the mapping of an individual component is not one-to-many, but one-to-one. Thus, an individual DBMS Column, for example, EmpFrstNam can be inherited from only one higher level component, for example, the single column, EmployeeFirstName. The second type of right-side relationship, the mapping of collections can be one-to-many. That is, one collection can map to one set of columns within one table of a single Logical Data Model while another collection from the same Physical Data Model can be mapped to a different collection within a different Logical Data Model. Hence, the collections can be seen as “from” one Physical Data Model to zero, one, or more Logical Data Models. The Interrelated Components, for example, Business Requirements are shown in Figure 1 because there is a one-to-many relationship between those components and zero, one or more of the data models. When two or more interrelated components are interrelated with one or more of the data models, there may be a type of relationship between those two interrelated components. For example, there is a business requirement to capture student addresses. Additionally, there is a use case through which a student’s address is captured. Apart from the obviousness of the interrelationship, the fact that there is a common data structure, Student Address, serves to indicate that because of this common data structure there is an interrelationship between the two interrelated components. Again, Table 2 provides definitions and interrelationships. 3.0 Data Management Components Each of the components in the data management environment, listed in alphabetical order, is defined in Table 2. The columns in this table are: Component Name, Component Description, and Component Benefit. Ultimately, when a component has merit or has in

6

interrelationship impact from the point of view of the overall SEVIS application and/or the SEVIS database, its existence, design, engineering, and implementation needs to be assessed within the overall data management IVV effort. There are six data model components that are defined in Table 2. These are the six interrelated data model depicted in the center of Figure 1. The data models from Figure 1 that are defined in Table 2 are not accomplished in isolation. They result from an initial and then on-going analysis of the data model involved component. That is, Business Requirements, Business Rules, and the like. These involved components are graphically depicted around the data model environment core of Figure 1. As each of these involved components are developed, reviewed, and evolved, the effect of those activities must be reflected in one or more of the six data models.

Figure 1. Data Management IVV Environment.

7

Data Management Components Component Name

Component Description Component Benefit


Business Requirements are the identification, specification, and definition of the components that must exist in the ultimate SEVIS II solution delivered by the contractor.

The benefit from having Business Requirements is that they form the foundation upon which all components of SEVIS II are engineered, implemented, and maintained. Business requirements will evolve over time, thus, it’s important to be able to track the initial and evolved requirements. It is unrealistic to initially have all requirements because new and/or revised requirements are discovered all during the project’s architecture, engineering, and implementation.

Business Rules

Business Rules are assertions of truth-states in the database. Each includes its identification, name, description, and exact specification of data-based rules that must either be true or that, after the execution of an information system based process, results in a state of truth.

The benefit from having Business Rules is their effect on two classes of control: data and process. Almost invariably, business rules depend on existing data, reference or control data, or data that is determined as a consequence of a process’s execution. Almost all business rules are mappable to data, whether persistent or temporary. Business rules are almost always discovered during design sessions, and use case walk-thrus. As business rules are discovered, the various data models need to be concurrently examined to determine whether the database can support the rules. Since every business rule has a process component, a key component of each rule is the specification of the process and a determination of where that rule is bound. That is, bound into the data model component (e.g., Data Element, or DBMS column), a low-level application component, a mid-level application process, or in the user presentation layer. Because of this multiplicity of possible bindings, business rules need to be centrally defined and managed. This central definition and decentralized binding minimizes redundant and/or conflicting definition while maximizing performance from the choice of the most appropriate binding layer.

CDRL (Contract Deliverable Requirements Line)

Contract Deliverable Requirements Lines (CDRL) are the identification, name, and detailed specification of deliverables from the contract effort.

The benefit from having CDRLs is that these become formal deliverables of the contract. All other components of the project that are reflected in the CDRL need to be identified and mapped to the CDRL. If reviews of a CDRL result in revisions, then, as the components are changed, the CDRL can be revised into a new version. When a CDRL is created it should also be specified as a product that is produced in the WBS.


Work Breakdown Structure is the hierarchical representation of two classes of effort: What, and How.

The benefit from having Work Breakdown Structures (WBS) is that they represent a breakdown of the actual work to be performed by

8



(WBS) The “what” type of WBS contains an action phrase and a noun phrase that together describes what is to be done, and the name of the product addressed. The products produced should all be derivable from CDRL items. WBS lines are able to have multiple predecessors and successors. Consequently, the WBS is really a network. The second class of WBS, the “how WBSs” are tuned not to the contract’s deliverables but to the actual techniques employed to accomplish the deliverable. Both the “What” WBS and the “How” WBSs need to be interlinked.

participant organizations. WBSs are different from a work-based methodology WBS (work breakdown structures). These WBSs provide a significantly increased level of detail as to how a particular step of a WBS and/or a CDRL is created. Consequently, WBSs and methodology-based WBSs should be interlinked as a given methodology-based WBS may be invoked or accomplished in more than one place within a WBS. An example of that is a review. Such reviews are required in a number of different WBS elements. Defining them over and over in a methodology-based WBS would be a waste of time. Hence these methodology-based WBS should be invoked when needed.

Data Model: Concepts Data Model

Data Model: Concepts Data Models are the data models of structures of data that are to be presented in a standard way throughout the various database models of the SEVIS II database. These models are standardized in terms of meaning, granularity, precision, and implied timeliness. For the sake of distinguishing Concept Data Models from Logical and Physical data models, its three key components are Subject, Entity, and Attribute.

The benefit from having Concepts Data Model is that data structures that commonly occur throughout a collection of data models can be standardized with respect to column names, value domains, definitions and the like. Concept data models, given that they exist separately, enable the quick discovery of their contained component use within database logical and physical data models. Even when logical and physical data model components have different names, the fact that data components across the concepts, logical, physical, and view data models are all interrelated enables the discovery of items that are named the same but are semantically different, or items that are named differently but are semantically the same. The ultimate objective is “define once use many times.” Achieving this objective starts with the Data Element Model and continues through the Concepts, Logical, Physical, View, and XML models.

Data Model: Data Element Model

Data Model: Data Element Models contain the identified and formally defined business facts that are captured and stored in the SEVIS II database in a context independent manner. Captured too are the encompassing semantic contexts of these data elements including allowed and disallowed

The benefit from having a Data Element Model is that it identifies and defines the individual business facts within the SEVIS environment independent of their specific operational deployed context. For example, the data element, Person First Name, may be on many different forms, end-user screens, and even columns within different database tables. Despite its multiple deployments, Person First Name would be defined only once.

9



value domain concepts and the actual allowed value domains.

Thus, the name, definition, and semantics for Person First Name exist only once. This enables business fact name, definition, and semantics consistency across all the SEVIS II databases, tables, and column. Further, such standardization enhances the level of interoperability between SEVIS II data and other external data sources. Data elements, properly identified and defined enable consistent semantics to be implemented within the total set of attributes, columns, and database management system (DBMS columns. Data elements additionally enable quick and effective cross reference among the fields in screens, the variables in programs, and the columns in database tables.

Data Model: Logical Data Model

Data Model: Logical Data Models are models of databases that are DBMS independent. Every logical database consists of a schema, a collection of tables, columns for those tables, primary and foreign keys, and in certain cases, alternate primary keys that enforce row uniqueness. For the sake of distinguishing Logical Data Models from Concept and Physical data models, its three key components are Schema, Table, and Column.

The benefit from having a Logical Data Model is that it represents well defined database models, almost always in third normal form. When a data model is in third normal form it is precise with respect to purpose, modularity, and update. Properly accomplished, Logical Data Models enable quick and easy traceability to individual requirements, precise components within use cases, business rule, user acceptance tests, and business requirements. Every column in the logical model should be traceable back to an attribute in the conceptual model, and also to a data element from the data element model. Because of the significant interrelationships between various data management components and specific columns within tables of the Logical Data Model, there can be a quick enumeration of, for example, all the specific use case aspects that are related to one column, or a quick enumeration of all the different components, for example business rules, use cases, user acceptance tests, and business requirements that are all related to the column, or the different columns and tables associated with a given aspect of a use case.

Data Model: Physical Data Model

Data Model: Physical Data Models are database models that are bound to the requirements of a particular DBMS. Physical data models are the basis for interconnecting a software application system to a specific

The benefit from having a Physical Data Model is that it represents the database schema that interacts with application systems that service the various SEVIS II user communities. A Physical Database Model may or may not be in third normal form. When a data model is not in third normal form, the complexity of the application system update logic

10



database. For the sake of distinguishing Physical Data Models from Concept and Logical data models, its three key components are DBMS Schema, DBMS Table, and DBMS Column.

increases to handle the redundant data represented in each non-third-normal-form table. Decreased however is the quantity of computer processing resources required to join rows of data from disconnected tables. A Physical Data Model commonly encapsulates processes that control the proper selection of specific values from within enumerated value domains, required or optional values, allowed value magnitudes, and triggered processes that may execute as a consequence of certain value. A key objective of a highly engineered Physical Data Model is the reduction in the size and complexity of the application program logic that exists within on-line presentation layer programs, batch interface programs, and any large-scale application programs that processes large volumes of data.

Data Model: SQL View Data Model

Data Model: SQL View Data Models are specialized schema objects that are employed by application information systems to obtain and/or put data to a database. Views can be quite complex and are employed mainly to remove database logic from the application system and put that logic into a independent schema component that is managed by the DBMS such as Oracle.

The benefit from having a View Data Model is significant. First of all, it represents a DBMS schema-based object that is the formal definition of the database’s data interface between an application program and the SEVIS database. Consequently, there can be database design changes that do not directly affect application programs. This is a measure of data independence between the DBMS and the application programs. Second of all, views enable physical databases to perform much faster as application-based data navigation and relation processing logic can be moved to the server and be optimized by the DBMS. Third, Views can perform application-based value-based functions on data prior to the data being stored in a database. Not only are business rules moved from the application layer, they are completely managed by the DBMS. That enhances the overall security and control. Fourth, Views enable row-based security and column-based security. This too can be moved from the application layer, to the DBMS layer which enhances security and control. The bottom-line based benefit from Views is that they maximize the DBMSs control over database data and at the same time reduce the size of the application layer. Applications therefore are

11



smaller to design, quicker to write, are easier to debug, and when changes are needed, the changes can be done in one place, that is, to the View, with an immediate effect on all the applications that employ the View.

Data Model: XML Interface Model

Data Model: XML Interface Models represent a specialized construction of importable or exportable data with respect to the SEVIS II system. Each XML data stream is defined through an XML Schema. Both XML schemas and XML data streams are independent of the software applications that create and/or use them. XML Schemas and XML data streams are DBMS represented in plain ASCII text.

The benefit from having an XML Interface Model is that it represents a method of importing and exporting data between the DBMS and the application layer in a technology-independent manner. That is because the complete content of an XML schema and XML-based instances of data is represented in ASCII. Traditionally, the DBMS and applications have to be inter-connected in some manner for data to be entered into the database via the DBMS. With XML, data can be created by some non-connected application, shipped to the SEVIS environment and then processed by a SEVIS captive application. Because the XML environment is not directly connected to the SEVIS DBMS environment, extra information has to be incorporated into the XML schema and data streams so that the SEVIS XML processing application can completely understand the XML data’s context.

Evolution Scenarios

Evolution scenarios represent typical data and systems model requirements changes that inevitably happen early in the post-implementation time frame and then less frequently thereafter.

The benefit from having these typical evolution scenarios is the ability to assess the robustness of the data model environment components and the various interrelated component reactions to typical requirements change scenarios. Each impact analysis scenario has to be identified and set out in terms of changes and the data and systems “reaction” to such changes has to be evaluated in terms of cost and schedule.

External Interface Requirements

External Interface Requirements are the specifications of an interface between SEVIS II and some external data source. Example include E-Verify, CLAIMS 3, FTTTF, and Pay-Gov. Each interface essentially consists of a fully defined data model that defines every field in the interface to the extent that a software module can be created to read the records represented by the interface and take appropriate action against the SEVIS II database. Such actions can be to insert, delete, or modify SEVIS II

The benefit from having External Interface Requirements is that they can be mapped to the appropriate database model components such as Data Elements, DBMS columns, or View columns. The External Interface Requirements can be mapped to the actual External Interfaces and their processes via the mapped to data model components.

12



database records. External Interfaces

External Input Interfaces are the specifications of the data that must be brought into the SEVIS II system’s environment and thus ultimately to the database. These interfaces must embrace insertions, deletions, and modifications of SEVIS II data. In the case of deletions, the data may not actually be deleted, but be marked as no-longer current.

The benefit from having External Interfaces is that both the submitting organizations and the DHS organization can ingest, modify, and delete significant quantities of SEVIS II information. Given that these interfaces are interrelated to the actual interface software via appropriate data model components, any changes in the interface can be quickly investigated to determine the effect on the application software, or if the external interface is manifest as XML, then the effects can be indentified in the XML Schemas and thus the XML data streams.


External Quality Standards are de jure and de facto standards through which data management products and/or processes can be judged. There are data model standards published by the DHS, and the Federal CIO Council Data Architecture Subcommittee, i.e., the Data Performance Model. There are more formal standards published by ISO, for example the Data Element metadata standard ISO 11179, and SQL related standards published by ANSI/INCITS. There are also XML related standards set out by the WC3 and implemented for use by the U.S. Department of Justice, that is, NIEM. The United States Department of the Navy has created significant documents on the definition and use of XML. Finally, there are defined data management maturity models, one for organization and process, and the other for data interoperability.

The benefit from having External Quality Standards is straight forward. They provide independent mechanisms for judging the completeness and quality of the form of any given data model component product instance. An External Quality Standard cannot provide a foolproof or complete assessment of the quality of the content of a product, however. Rather it can provide indicators of quality and/or completeness. The DHS data modeling standards can provide an assessment as to whether its requirements as to the quality of a data model is being followed in regards to naming, definitions and the like. The Federal CIO Council Data Architecture Subcommittee documents including the Data Performance Plan enables an assessment of the concept data model components including the mapping of every attribute within the concept data model entities to ISO 11179 Data Elements. The ISO Standard 11179 enables assessment of the adequacy and completeness of the metadata associated with data elements. Included in this class of assessment are Concepts, Conceptual Value Domains, Data Element Concepts, Value Domains including mapping among equivalent values, Data Element Classifications, and Administrative Information (for Stewardship). The ISO/ANSI SQL standard enables the assessment of SQL data structures and languages employed in database designs and application program access. Use of an SQL Validator will ensure that there is maximum use of portable SQL components in the case where the SEVIS database

13



and application layer is moved from Oracle to some other SQL-based DBMS. In the event that an Oracle-only SQL component and/or syntax is employed, the SQL standards enable the identification of those components and syntax and the classification of them as a portability risk. The U.S. Department of Justice’s NEAM documents along with XML engineering documents created, for example by the U.S. Navy, enable an analysis of the names and engineering of XML schemas and XML data streams so as to ensure maximum interoperability conformity to existing sets of Federal XML-based XML schema models. Finally, there are two other quality assessment mechanisms that have received wide review: the Data Management Maturity Model (DM3), and the Levels Conceptual Interoperability Model (LCIM). Both models have common measures of achieved quality, that is, the five levels of CMMI. Both models generally describe the achieved levels achieved in the same CMMI way. The models are focused on different aspects of data management. The DM3 is focused on determining the level of maturity of organizations and processes involved in creation and management of data management component deliverables. In contrast, the LCIM is focused on determining the interoperability aspects (that is, both values and semantics) of the data. These two assessments, DM3 and LICM each form a dimension with a 1 to 5 scale. On the “z” dimension is a general sequence of data models (Data Element through View) and interrelated components (e.g., Business Rules, and Value Domains) that occur as a consequence of an increase in maturity level (and an increase in the quality of the component). Collectively, these seven external quality standards enable the creation of a very accurate picture of the SEVIS data environments. What is especially interesting about the seven quality standards enumerated here is that while they all overlap, none compete. The overlap is in terms of data management component deliverables (i.e., Data

14



Element, Concept Data Model, or Business Rule) that, when examined, cause the determination of an overall level of quality.

Hardware Systems

Hardware Systems are the broad characterizations of where databases are to reside. This includes the identification of the networks through which the databases are accessed.

The benefit from having Hardware Systems identified is that they can be employed as the target of deployed databases and application systems.

On-line Interfaces

On-line Interfaces are the identification, specification, and interaction between a presentation layer model and database models of either the XML or SQL View variety. For Service Oriented Application models, the data interface is likely in an XML format as opposed to a client-server model that directly connects the presentation layer screen the application system processing layer.

The benefit from having On-line Interfaces is that the specifications of these interfaces, that is, the various data cells that exist on the interfaces can be mapped to the appropriate items within the various data model components. Over time, as an on-line interface proceeds from requirements to specifications to implementation, the mapping will likely change from a higher level to a lower level and from a more general to a more specific item within a data model component. For example, mappings would be changed from Data Elements to View columns, or from a Use Case as a whole to a specific component within a Use Case. Regardless of the level of the mapping, the various On-line interfaces will be able to be cross-referenced one to the other via the data model component mappings. Interactions will also be able to be seen from these interfaces to use cases, business requirements, value domains, business rules, and the like.

Software Systems

Software Systems are the broad characterizations of the application systems that are executing to capture, update, and report SEVIS II data.

The benefit from having Software Systems is somewhat similar to the identification and cataloging of the hardware systems. Software systems can be additionally detailed into their specific components, and those that deal with SEVIS database data can be mapped to the appropriate data model component.

Use Cases Use Cases are highly engineered pseudo-process models that clearly define the behavior of the users and software systems, and also the responses provided by the DBMS as it takes in, modifies, or provides data back out to users. Use cases are detailed to the level such that a programmer can interpret the process intent and write an application system module without semantic and/or process misunderstanding. Use cases should be considered

The benefit from having Use Cases is that they present behavior based scenarios of the use of the SEVIS database to accomplish the SEVIS requirements. Because use cases directly identify database data, mappings can be created between one use case and another to identify redundancy and possible conflict. Mappings can also be made between the detailed data and process aspects of use cases and business requirements, deployments of use cases in software and hardware, external interfaces, value domains, business rules, WBS, and CDRLS.

15



approved only after all the behavior is specified and all the application system and database reactions to the behavior have been determined to be acceptable. Until use cases are approved, software systems should not be written.

User Acceptance Tests

User Acceptance Tests are stylized user-application system interaction scripts that can be exercised to the extent that fully informed users can determine that all the SEVIS II requirements have been met and all use cases are satisfactorily performed.

The benefit from having User Acceptance Tests (UAT) is that these are the ultimate mechanisms through which the DHS will determine that it has received the SEVIS II system that was specified for purchase. Because of all the different data models (Data Elements through to View and to XML), and because of the interrelationships of the Data Model Components (Business Requirements through to External Quality Standards and to On-line Interfaces), the User Acceptance tests can be very comprehensive and very telling. Most everything contained in Figure 1 can be related to every component in Figure 1 and thus can be assessed individually and in collections as to meeting or not meeting the objectives of the SEVIS contract. Once SEVIS II is deployed these UATs can be turned into User Performance Tests and can be employed for end-user and back-office user training and proficiency testing.

Value Domains and Management

Value Domains and Management relates to the allowed, disallowed, or other defined collections of values and interconnection of values that represent discrete choices (Gender = Male, Female, unknown), or sequenced states such as Applied, Reviewed, Accepted, Rejected, Appealed. Included as well are the mappings across time of evolved and/or changed value domains. Value domains commonly stand alone and are allocated to data elements, or to attributes, columns, or DBMS columns. In all cases of value domain allocation, the allocations must be such that semantics conflicts are prohibited.

The benefit from having Value Domains and Management is that value domains represent materialized aspects of value-based policy determinations. For example, a policy may be established that there are three values for Gender: Male, Female, and Unknown. Not only is the policy that there are gender values, but that the quantity is just three, that the value representations of that policy decision is Male, Female, and Unknown, and that for each value there is a formal meaning that makes the values distinguishable one from the other. Almost every database column that has a restricted value domain, that is when the quantity of unique values is significantly fewer than the quantity of the rows, policies must be set into place that determine the quantity of the values, the values themselves, and the meaning of the values. Established also must be the organizations and procedures to establish the values.

16



As these organizations accomplish their value domain establishment procedures, their findings must be incorporated into appropriate data model components. While it is most common that these decisions and values are incorporated in the Data Element model, they are mainly bound (that is, enforced) from within DBMS column, view columns, and application software system logic. Over time, these restricted values will not only change from one value to the other as in Male to M, but the quantity of unique values may also change from three to five to some other number. When each change occurs, the value domain management configuration management and impact analysis meetings must occur, analyze the problem at hand, make recommendations for not only the change but also for the recasting of the old value set into a new value set. In the accomplishment of a change from an old value set to a new value set, careful consideration must be given to the impact of the changes onto prior determinations and decisions. All value change management processes and decisions must be recorded and interrelated to the various components that employ the new value domains such as business requirements, use cases, user acceptance tests, external data interface requirements, business rules, on-line interfaces, and software systems.

Table 2. Data Management Component Definitions 4.0 Data Management Component Interrelationships Table 3 provides a cross reference between an interrelated data model (e.g., Logical Data Model) and an involved component (e.g., Business Rules). The intention of Table 3 is that, for example, a Data Element “knows about” or must take into account zero, one or more Business Rules. Table 4 provides a cross reference between involved components and other involved components. The intention of Table 4 is that, for example, a Business Rule “knows about” or must take into account zero, one or more Business Requirements.

17

The assessment strategy of the involvement of both Table 3 and Table 4 is set out in the Data Management WBSs that are provided in Section 6. The implication of the interrelationships is that when a given Involved Component (e.g., Business Rules) is presented for review, the interrelated data models (e.g., Data Elements) need to be assessed to determine whether there has been a complete specification. As a presentation of an involved component is underway, the effect on the interrelated data model must be determined. For example, it is not uncommon that during the walk through of a use-case that a large quantity of data evaluation and value setting discussions surface. If the data model steward is present at these sessions then the implication of the data impact issues can be quickly identified, researched, and the impact discussed. Once a use-case walk-thru is concluded the write-up of the walk-thru would naturally have a set of data and process impact statements.

Involved Component

Interrelated Data Model

Data Element

Concepts Data

Model

Logical Data

Model

Physical Data

Model

View Data

Model

XML Data

Model Business Requirements

Business Rules CDRL (Contract Deliverable Requirements Line)

Work Breakdown Structure (WBS)

Evolution Scenarios External Interface Requirements

External Interfaces External Quality Standards

Hardware Systems

On-line Interfaces

Software Systems Use Cases User Acceptance Tests

Value Domains and Management

Table 3. Interrelationship between Data Models and Involved Components.

18

Involved

Component Backward Reference from Involved Component to Column 1 Item

1 2 3 4 5 6 7 8 9 10 11 12 13 14 1. Business Requirements

NA

2. Business Rules

NA

3. CDRL (Contract Del Req Line)

NA

4. Work Breakdown Structure (WBS)

NA

5. Evolution Scenarios

NA

6. External Interface Requirements

NA

7. External Interfaces

NA

8. External Quality Standards

NA

9. Hardware Systems

NA

10. On-line Interfaces

NA

11. Software Systems

NA

12. Use Cases NA

13. User Acceptance Tests

NA

14. Value Domains and Management

NA

Table 4. Interrelationship between Involved Components and Involved Components.

5.0 Data Management IVV Example Scenario The following is an example scenario of how a data management IVV activity would occur for the evaluation of a work product. The product in question is Product 5 (Student Self Management). The data models in hand were dated January 8, 2009. Thus, while these data models are likely not current, they are the only data models in possession by the IVV team. These data models do address School, Organization, Person, and Application.

19

During the presentation of the Product 5 Use Case, a number of issues were presented. The following is a subset of those that seem to have an impact on the data models:

The ability to record the change in status of an application and to maintain the history of those status changes.

The ability to record the change in status of an organization and/or school, and to

maintain the history of those status changes.

The enumeration of various statuses including what each exactly means, how it was created, and how it is supported by regulation and/or law.

The recording of statuses, that is, how or what determines a status, when it was

determined, how it is recorded, when it can change, and the like.

The specification of relationships between core SEVIS II data instances. That is, between organizations, schools, applicants, students, exchange visitors, and the like.

The formal specification of Business Rules that clearly specify, for example, the

status issues, under what conditions the business rules are executed, the consequence of success and failure, and the like.

How Business rules are discovered, recorded, specified, prototyped, formally

presented, accepted or rejected, and upon acceptance, the impacts on data models, system/process models, and data values is determined.

Where Business rules are bound. That is, in the presentation layer, application

layer, or DBMS layer. Under what conditions is this determined and then finally resolved. When Business Rules are determined to be bound into multiple places, how it is determined that the business rules are implemented in the same way, are tested, and finally are documented.

The ability for an applicant to see history. Is the history that is seen complete or a

subset? Under what rules is this determined and implemented? At the end of the use case presentation it is presumed that the following occurs:

A use-case presentation finding document that identifies all the issues raised and how each issue was resolved is created.

The findings document is sent to all involved for acceptance and/or revision.

The stewards of the affected data models and involved components (e.g., business rules, requirements, external interfaces, and user acceptance tests) are tasked to

20

formally determine the impacts from the use-case findings.

Impact statements are circulated to all involved parties for review.

Accepted impact findings that result in SEVIS II changes are drafted into SEVIS II change requirements.

6.0 Data Management IVV WBS and Deliverables The actual involvement of the six data models depicted in Figure 1 to the involved components of Figure 1 is set out in Section 6.1 of the Data Management WBS provided in this section. Section 6.2 of this section provides an Involved Component’s interaction with a data model. Section 6.3 of this section provides an Involved Component’s interaction with another Involved Component. Each of the WBSs within this section:

Identifies the materials needed for the assessment. Sets out the high-level assessment steps. Determines the findings and create draft assessment report Present the findings and revise draft assessment report Create final report and deliver to Government

The Data Management IVV WBSs are the complete list of both the data models (six), and the involved areas (fourteen). Table 3 provides the cross reference between data models and Involved Component. Table 4 provides the cross reference among Involved Components. Section 6.1 focuses on the work steps for constructing the individual data models (e.g., Data Elements, Concepts, or Logical Data Model) in context with involved components (e.g., Business Requirements, Business Rules, External Interfaces, or User Acceptance Tests). Section 6.1 focuses on the work steps involved with the development, review, and evolution of a data model with respect to an involved component (e.g., Business Requirements, Business Rules, External Interfaces, or User Acceptance Tests). Section 6.2 focuses on the work steps involved with the development, review, and evolution of an involved component (e.g., Business Requirements, Business Rules, External Interfaces, or User Acceptance Tests) with respect to the involved data models (e.g., Data Elements, Concepts, or Logical Data Model). Section 6.3 focuses on the work steps involved with the development, review, and evolution of an involved component (e.g., Business Requirements, Business Rules, External Interfaces, or User Acceptance Tests) with respect to other involved components that likely have been determined earlier in the system development process. Hence all the references are “backwards” references. For example, that a given business rule identifies the business requirement that it fulfills, or that a task within the work breakdown

21

structure identifies that business requirements, or business rules, etc., have to be properly addressed. It is proper to include all three sets rather than just the data models set because when an involved area is presented or examined, it has an effect on a data model component that consequently needs to be assessed and/or examined. Similarly, when a data model is developed and subsequently assessed, the contents of the data model must reflect on the content of one or more Involved Component. Finally, when an involved component is addressed it must take into account one or more predecessor involved components. The WBS listings in Sections 6.1, 6.2, and 6.3 presume the existence of capable data architects, modelers, and engineers as well as the appropriate staff for each of the involved components. Hence there are few to no details about “how” each of the tasks and/or assessments is accomplished. Without such a presumption, the quantity of tasks within each of the sections would take many pages. The ultimate objective is that assessments can be performed and valid conclusions drawn about content, completeness and quality about the data models, the involved components, the interactions between the data models and the involved components, and the interaction among the involved components. 6.1 Data Model Assessments 6.1.1 Data Model: Data Element Model Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of data element models 1.1.1. Review requirements documents 1.1.2. Review scope and business problem related documentation 1.1.3. Identify the data elements that are to be defined and captured 1.1.4. Identify the meta-artifacts appropriate to the evaluation of data element

models 1.2. For each data element:

1.2.1. Identify components, that is, concept, conceptual value domain, value domain, data element concept, data element classification, and data element.

1.2.2. Identify the definitions for each data element model component 2. Perform the assessment

2.1. Assess each data element model against involved component 2.1.1. Assess the adequacy of each data element with respect to the Business

Rules. 2.1.1.1.Assess whether all implied business rules implied data elements are

reflected in an appropriate data element model 2.1.1.2.Assess whether all data element models are reflected in business rules.

2.1.2. Assess the adequacy of each data element model with respect to the Business Evolution Scenarios.

22

2.1.2.1.Assess whether every data element model is addressed by at least one business evolution scenario.

2.1.2.2.Assess whether every data element is designed appropriately so that it can respond to the scenario

2.1.3. Assess the adequacy of each data element with respect to the External Quality Standards.

2.1.3.1.Assess whether every data element is properly comports to Part 3 of the ISO 11179 for data element metadata.

2.1.3.2.Assess whether every data element is properly comports to Part 5 of the ISO 11179 for data element metadata.

2.1.3.3.Assess the Data Management Maturity Model level appropriate for the concept data model as it relates to process and organization.

2.1.3.4.Assess the Data Interoperability Maturity Model level appropriate for the concept data model as it relates to process and organization.

2.1.4. Assess the adequacy of each data element model with respect to the Use Cases.

2.1.4.1.Assess whether there is a sufficient set of use cases to account for all the data elements.

2.1.4.2.Assess whether every data element is addressed by at least one use case.

2.1.5. Assess the adequacy of each data element model with respect to the Value Domain Management.

2.1.5.1.Assess whether the set of value domains for every data element is defined unambiguously, clearly, distinctly, and not-overlapping.

2.1.5.2.Assess whether every data element that is to have a restricted value domain is identified and is correctly addressed by the appropriate set of properly configured value domain management metadata.

2.2. Assess data element meta-artifacts 2.2.1. Assess the completeness of each meta-artifact

2.2.1.1.Assess that all concepts are identified and are properly constructed 2.2.1.2.Assess that all conceptual value domains are identified and are

properly constructed. 2.2.1.3.Assess that all value domains of conceptual value domains are

identified and are properly constructed. 2.2.1.4.Assess that all data element concepts, which are the proper joining of

contextual conceptual value domains and contextually employed concepts are identified and are properly constructed.

2.2.1.5.Assess that all data elements, which are the proper joining of contextual data element concepts and contextually employed value domains are identified and are properly constructed.

2.2.2. Assign the risk level associated with each meta-artifact not properly constructed.

3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government

23

6.1.2 Data Model: Concepts Data Model Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of concept data models 1.1.1. Review requirements documents 1.1.2. Review scope and business problem related documentation 1.1.3. Identify the data-based concepts that are to be defined and captured 1.1.4. Identify the meta-artifacts appropriate to the evaluation of concept data

models 1.2. For each concept:

1.2.1. Identify components, that is, subjects, entities, attributes and relationships 1.2.2. Identify the definitions for each concept data model component

2. Perform the assessment 2.1. Assess each concept data model against involved component

2.1.1. Assess the adequacy of each concept data model with respect to the Business Requirements.

2.1.1.1.Assess whether all implied business requirement concepts are reflected in an appropriate concept data model

2.1.1.2.Assess whether all concept data models are reflected in business requirements

2.1.2. Assess the adequacy of each concept data model with respect to the Business Evolution Scenarios.

2.1.2.1.Assess whether every concept data model is addressed by at least one business evolution scenario.

2.1.2.2.Assess whether every concept data model is designed appropriately so that it can respond to the scenario

2.1.3. Assess the adequacy of each concept data model with respect to the External Quality Standards.

2.1.3.1.Assess whether every data concept data model is properly reflected in a CIO DAS data model that may exist.

2.1.3.2.Assess whether every CIO DAS data model that may be appropriate within the SEVIS II collection of concept data models is properly defined.



2.1.4. Assess the adequacy of each concept data model with respect to the Use Cases.

2.1.4.1.Assess whether there is a sufficient set of use cases to account for all the concept data models.

2.1.4.2.Assess whether every concept data model is addressed by at least one use case.

24

2.1.4.3.Assess whether the use case is sufficiently detailed to fully address all the entities, attributes, and relationships of the relevant concept data model.

2.1.5. Assess the adequacy of each concept model with respect to the Value Domain Management.

2.1.5.1.Assess whether the set of value domains for every attribute is defined unambiguously, clearly, distinctly, and not-overlapping.

2.1.5.2.Assess whether every attribute that is to have a restricted value domain is identified and is correctly addressed by the appropriate set of properly configured value domain management metadata.

2.1.5.3.Assess that every attribute value domain does not semantically conflict with a data element value domain.

2.2. Assess concept data model meta-artifacts 2.2.1. Assess the completeness of each meta-artifact

2.2.1.1.Assess that all subjects are identified and are properly constructed 2.2.1.2.Assess that all entities within subjects are identified and are properly

constructed. 2.2.1.3.Assess that all entity super and subtypes are identified and are properly

constructed. 2.2.1.4.Assess that all entity attributes are identified and are properly

constructed. 2.2.1.5.Assess that all attributes are mapped to data elements 2.2.1.6.Assess that appropriate attributes are properly constrained by value

domain assignments. 2.2.1.7.Assess that all intra-subject entity relationships are identified and are

properly constructed. 2.2.1.8.Assess that all inter-subject entity relationships are identified and are

properly constructed. 2.2.1.9.Assess that the entity’s primary key exclusively consists of business-

fact-data and enables the selection of one and only one row given that the entity was an implemented DBMS table.

2.2.1.10. Assess that the collections of entity attributes are sufficient to reflect the implied policy of the entity.

2.2.1.11. Assess that the collection of entity attributes are sufficient for the entity’s instance infrastructure.

2.2.1.12. Assess that the collection of entity attributes are sufficient for history and for auditability.


3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.1.3 Data Model: Logical Data Model Assessment 1. Identify artifacts that bear on the assessment

25

1.1. Identify the appropriate set of logical data models 1.1.1. Review requirements documents 1.1.2. Review scope and business problem related documentation 1.1.3. Identify the logical data models that are to be defined and captured 1.1.4. Identify the meta-artifacts appropriate to the evaluation of logical data

models 1.2. For each logical data model:

1.2.1. Identify components, that is, schemas, tables, columns, and relationships 1.2.2. Identify the definitions for each logical data model component

2. Perform the assessment 2.1.Assess each logical data model against involved component

2.1.1. Assess the adequacy of each logical data model with respect to the Business Requirements.

2.1.1.1.Assess whether all implied business requirement logical data models are reflected in an appropriate logical data model

2.1.1.2.Assess whether all logical data models are reflected in business requirements

2.1.2. Assess the adequacy of each logical data model with respect to the Business Rules.

2.1.2.1.Assess whether all implied business rules implied logical data model components are reflected in an appropriate logical data model

2.1.2.2.Assess whether all logical data model components are reflected in business rules.

2.1.3. Assess the adequacy of each logical data model with respect to WBS. 2.1.3.1.Assess whether all implied WBS logical data models are reflected in

an appropriate logical data model 2.1.3.2.Assess whether all logical data model components are reflected in one

or more of the WBS elements 2.1.4. Assess the adequacy of each logical data model with respect to the

Business Evolution Scenarios. 2.1.4.1.Assess whether every logical data model is addressed by at least one

business evolution scenario. 2.1.4.2.Assess whether every logical data model is designed appropriately so

that it can respond to the scenario 2.1.5. Assess the adequacy of each logical data model with respect to the

External Quality Standards. 2.1.5.1.Assess whether the facilities defined within every logical data model is

properly drawn from at most ISO ANSI Standard for entry level SQL:1992.

2.1.5.2.Assess whether every logical data model that may be appropriate within the SEVIS II collection of logical data models is properly defined through the use of DHS ICE logical data modeling standards.



26

2.1.6. Assess the adequacy of each logical data model with respect to the Use Cases.

2.1.6.1.Assess whether there is a sufficient set of use cases to account for all the logical data models.

2.1.6.2.Assess whether every logical data model is addressed by at least one use case.

2.1.6.3.Assess whether the use case is sufficiently detailed to fully address all the tables, columns, and relationships of the relevant logical data model.

2.1.7. Assess the adequacy of each logical data model with respect to the Value Domain Management.

2.1.7.1.Assess whether the set of value domains for every column is defined unambiguously, clearly, distinctly, and not-overlapping.

2.1.7.2.Assess whether every column that is to have a restricted value domain is identified and is correctly addressed by the appropriate set of properly configured value domain management metadata.

2.1.7.3.Assess that every column value domain does not semantically conflict with an attribute value domain.

2.2. Assess logical data model meta-artifacts 2.2.1. Assess the completeness of each meta-artifact

2.2.1.1.Assess that all schemas are identified and are properly constructed 2.2.1.2.Assess that all tables within the schemas are identified and are

properly constructed. 2.2.1.3.Assess that all table super and subtypes are identified and are properly

constructed. 2.2.1.4.Assess that all columns are identified and are properly constructed. 2.2.1.5.Assess that all columns are mapped to attributes 2.2.1.6.Assess that appropriate columns are properly constrained by value

domain assignments. 2.2.1.7.Assess that all columns contain the appropriate integrity constraints

that are supported by assertions and triggers 2.2.1.8.Assess that all stored procedures are properly identified, designed,

coded and tested to meet integrity requirements. 2.2.1.9.Assess that all table relationships are identified and are properly

constructed. 2.2.1.10. Assess that the table’s primary key exclusively consists of

business-fact-data and enables the selection of one and only one row given that the table was an implemented DBMS table.

2.2.1.11. Assess that the collections of table columns are sufficient to reflect the implied policy of the table.

2.2.1.12. Assess that the collection of table columns are sufficient for the table’s instance infrastructure.

2.2.1.13. Assess that the collection of table columns are sufficient for history and for auditability.

2.2.1.14. Assess keys and relationships. 2.2.1.14.1. Assess whether primary key is a surrogate key or natural key.

27

2.2.1.14.2. Assess that one and only one row is selected if a natural key 2.2.1.14.3. Assess that one and only one row of business data is selected if

a surrogate key. 2.2.1.14.4. Assess whether there a unique constraint comprised of natural

data if row uniqueness is enforced through a surrogate key. 2.2.1.14.5. Ensure that the specification of referential integrity and

referential actions correctly matches the business requirements for data retention and deletion.


3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.1.4 Data Model: Physical Data Model Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of physical data models 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the physical data models that are to be defined and captured. 1.1.4. Identify the meta-artifacts appropriate to the evaluation of physical data

models. 1.2. For each physical data model:

1.2.1. Identify components, that is, DBMS schemas, DBMS tables, DBMS columns, and DBMS relationships.

1.2.2. Identify the definitions for each physical data model component 2. Perform the assessment

2.1. Assess each physical data model against involved component 2.1.1. Assess the adequacy of each physical data model with respect to the

Business Requirements. 2.1.1.1.Assess whether all implied business requirement physical data models

are reflected in an appropriate physical data model. 2.1.1.2.Assess whether all physical data models are reflected in business

requirements. 2.1.2. Assess the adequacy of each physical data model with respect to the

Business Rules. 2.1.2.1.Assess whether all implied business rules implied physical data model

components are reflected in an appropriate physical data model 2.1.2.2.Assess whether all physical data model components are reflected in

business rules. 2.1.3. Assess the adequacy of each physical data model with respect to the

CDRL. 2.1.3.1.Assess whether all implied CDRL physical databases are reflected in

an appropriate physical data model

28

2.1.3.2.Assess whether all physical data model components are reflected in one or more of the CDRL elements

2.1.4. Assess the adequacy of each physical data model with respect to WBS. 2.1.4.1.Assess whether all implied WBS physical data models are reflected in

an appropriate physical data model 2.1.4.2.Assess whether all physical data model components are reflected in

one or more of the WBS elements 2.1.5. Assess the adequacy of each physical data model with respect to the

Business Evolution Scenarios. 2.1.5.1.Assess whether every physical data model is addressed by at least one

business evolution scenario. 2.1.5.2.Assess whether every physical data model is designed appropriately so

that it can respond to the scenario. 2.1.5.3.Assess whether the change/evolution strategy for a physical data

model is properly coordinated with XML, view, and software systems change strategies.

2.1.6. Assess the adequacy of each physical data model that is to be populated by with respect to the External Interface Requirements.

2.1.6.1.Assess whether every physical data model that is to be populated by external data is addressed by at least one external interface requirement.

2.1.6.2.Assess whether every physical data model that is to be populated by external data is designed appropriately so that it can respond to the external interface requirement.

2.1.7. Assess the adequacy of each physical data model that is to be populated by with respect to the External Interfaces.

2.1.7.1.Assess whether every physical data model that is populated by external data is addressed by at least one external interface.

2.1.7.2.Assess whether every physical data model that is to be populated by external data is designed appropriately so that it can respond to the external interface.

2.1.8. Assess the adequacy of each physical data model with respect to the External Quality Standards.

2.1.8.1.Assess whether the facilities defined within every physical data model is properly drawn from an Oracle DBMS facility that is at most ISO ANSI Standard for entry level SQL:1992.

2.1.8.2.Assess whether every physical data model that may be appropriate within the SEVIS II collection of physical data models is properly defined through the use of DHS ICE physical data modeling standards.



2.1.9. Assess the adequacy of each physical data model with respect to the Hardware Systems.

29

2.1.9.1.Assess whether the hardware systems environment on which the physical database is to be located has the most efficient and effective architecture for the performance needs of the physical model.

2.1.10. Assess the adequacy of each physical data model with respect to the On-line Interfaces.

2.1.10.1. Assess whether the on-line interfaces are engineered to make the maximum efficient and effective use of the physical data model.

2.1.11. Assess the adequacy of each physical data model with respect to the Software Systems.

2.1.11.1. Assess whether the software systems environment on which the physical database is to be located has the most efficient and effective architecture and deployment strategy for the performance needs of the physical model.

2.1.12. Assess the adequacy of each physical data model with respect to the Use Cases.

2.1.12.1. Assess whether there is a sufficient set of use cases to account for all the logical data models.

2.1.12.2. Assess whether every physical data model is addressed by at least one use case.

2.1.12.3. Assess whether the use case is sufficiently detailed to fully address all the tables, columns, and relationships of the relevant logical data model.

2.1.12.4. Assess whether the use cases properly specify the functions by organization and that the allowed access to the column in terms of read, write, select, and update are completely specified.

2.1.13. Assess the adequacy of each physical data model with respect to the User Acceptance Tests.

2.1.13.1. Assess whether the tests adequately test Inserts, Deletes, and Modifies for every physical data model DBMS table.

2.1.13.2. Assess whether referential integrity has been sufficiently defined to correctly model Restrict, Set Null, and Cascade.

2.1.13.3. Assess whether every Referential Action is properly engineered and tested.

2.1.13.4. Assess whether every value domain management action correctly executes and provide end-user violation messages that are clear, unambiguous, and helpful to the end user.

2.1.13.5. Assess whether every inappropriate and/or out-of-bounds value for every physical data model database column is appropriately trapped.

2.1.14. Assess the adequacy of each physical data model with respect to the Value Domain Management.

2.1.14.1. Assess whether the set of value domains for every DBMS column is defined unambiguously, clearly, distinctly, and not-overlapping.

2.1.14.2. Assess whether every DBMS column that is to have a restricted value domain is identified and is correctly addressed by the appropriate set of properly configured value domain management metadata.

30

2.1.14.3. Assess that every DBMS column value domain does not semantically conflict with a column value domain.

2.2. Assess physical data model meta-artifacts 2.2.1. Assess the completeness of each meta-artifact

2.2.1.1.Assess that all DBMS schemas are identified and are properly constructed

2.2.1.2.Assess that all DBMS tables within the schemas are identified and are properly constructed.

2.2.1.3.Assess that all DBMS table super and subtypes are identified and are properly constructed.

2.2.1.4.Assess that all DBMS columns are identified and are properly constructed.

2.2.1.5.Assess that all DBMS columns contain the appropriate integrity constraints that are supported by assertions and triggers

2.2.1.6.Assess that all stored procedures are properly identified, designed, coded and tested to meet integrity requirements.

2.2.1.7.Assess that all DBMS columns are mapped to columns 2.2.1.8.Assess that appropriate DBMS columns are properly constrained by

value domain assignments. 2.2.1.9.Assess that all DBMS table relationships are identified and are

properly constructed. 2.2.1.10. Assess that the DBMS table’s primary key exclusively consists of

business-fact-data and enables the selection of one and only one. 2.2.1.11. Assess that the collections of DBMS table columns are sufficient

to reflect the implied policy of the DBMS table. 2.2.1.12. Assess that the collection of DBMS table columns are sufficient

for the DBMS table’s instance infrastructure. 2.2.1.13. Assess that the collection of DBMS table columns are sufficient

for history and for auditability. 2.2.1.14. Assess keys and relationships.

2.2.1.14.1. Assess whether primary key is a surrogate key or natural key. 2.2.1.14.2. Assess that one and only one row is selected if a natural key 2.2.1.14.3. Assess that one and only one row of business data is selected if

a surrogate key. 2.2.1.14.4. Assess whether there a unique constraint comprised of natural

data if row uniqueness is enforced through a surrogate key. 2.2.1.14.5. Ensure that the specification of referential integrity and

referential actions correctly matches the business requirements for data retention and deletion.

2.2.1.15. Assess the SQL DDL Scripts 2.2.1.15.1. Ensure that the SQL scripts for reference data match the value

domain requirements 2.2.1.15.2. Ensure that the SQL scripts for security roles match the

security requirements as it relates to the use cases, named user roles, organizations, and extent of permission to read, write, update, and select data.

31

2.2.1.15.3. Ensure that the SQL scripts for primary key sequence value specifications match the primary key requirements

2.2.1.15.4. Ensure that the SQL scripts for tables, columns and appropriate key specifications match the DBMS table requirements

2.2.1.15.5. Ensure that the SQL scripts for triggers and other stored procedures match the data integrity constraints


3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.1.5 Data Model: SQL View Data Model Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of view data models 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the view data models that are to be defined and captured. 1.1.4. Identify the meta-artifacts appropriate to the evaluation of view data

models. 1.2. For each view data model:

1.2.1. Identify components, such as, views, view columns, select and join clauses.

1.2.2. Identify the definitions for each view data model component. 2. Perform the assessment

2.1. Assess each view data model against involved component 2.1.1. Assess the adequacy of each view data model with respect to the Business

Rules. 2.1.1.1.Assess whether all implied business rules implied view data model

components are reflected in an appropriate view data model 2.1.1.2.Assess whether all view data model components are reflected in

business rules. 2.1.2. Assess the adequacy of each view data model with respect to the Business

Evolution Scenarios. 2.1.2.1.Assess whether every view data model is addressed by at least one

business evolution scenario. 2.1.2.2.Assess whether every view data model is designed appropriately so

that it can respond to the scenario. 2.1.2.3.Assess whether the change/evolution strategy for a view data model is

properly coordinated with XML, physical data model, and software systems change strategies.

2.1.3. Assess the adequacy of each view data model that is to be populated by with respect to the External Interface Requirements.

32

2.1.3.1.Assess whether every view data model that is to be populated by external data is addressed by at least one external interface requirement.

2.1.3.2.Assess whether every view data model that is to be populated by external data is designed appropriately so that it can respond to the external interface requirement.

2.1.4. Assess the adequacy of each view data model that is to be populated by with respect to the External Interfaces.

2.1.4.1.Assess whether every view data model that is populated by external data is addressed by at least one external interface.

2.1.4.2.Assess whether every view data model that is to be populated by external data is designed appropriately so that it can respond to the external interface.

2.1.5. Assess the adequacy of each view data model with respect to the External Quality Standards.

2.1.5.1.Assess whether the facilities defined within every physical data model is properly drawn from an Oracle DBMS facility that is at most ISO ANSI Standard for entry level SQL:1992.

2.1.5.2.Assess whether every physical data model that may be appropriate within the SEVIS II collection of physical data models is properly defined through the use of DHS ICE physical data modeling standards.



2.1.6. Assess the adequacy of each view data model with respect to the Hardware Systems.

2.1.6.1.Assess whether the hardware systems environment on which the view database is to be located has the most efficient and effective architecture for the performance needs of the view data model.

2.1.7. Assess the adequacy of each view data model with respect to the On-line Interfaces.

2.1.7.1.Assess whether the on-line interfaces are engineered to make the maximum efficient and effective use of the view data model.

2.1.8. Assess the adequacy of each view data model with respect to the Software Systems.

2.1.8.1.Assess whether every view data model is properly interfaced with one or more application information systems.

2.1.8.2.Ensure that every information system has SEVIS II database access only through a view data model.

2.1.9. Assess the adequacy of each view data model with respect to the Use Cases.

2.1.9.1.Assess whether the use cases adequately specify the complete set of Inserts, Deletes, and Modifies.

2.1.9.2. Assess whether every value domain management action correctly executes and provide end-user violation messages that are clear, unambiguous, and helpful as specified in one or more use cases.

33

2.1.9.3.Assess whether every inappropriate and/or out-of-bounds value for every physical data model database column is appropriately trapped as specified in a use case.

2.1.10. Assess the adequacy of each view data model with respect to the User Acceptance Tests.

2.1.10.1. Assess whether the tests adequately test Inserts, Deletes, and Modifies for every view data model DBMS table.

2.1.10.2. Assess whether referential integrity has been sufficiently defined to accomplish the behavior defined within the view data model.


2.1.10.4. Assess whether every inappropriate and/or out-of-bounds value for every physical data model database column is appropriately trapped.

2.1.10.5. Asses whether the view-based derived and compound columns, selects, nested selects, and the defined classes of joins are properly defined and product the pre-defined expected results.

2.1.11. Assess the adequacy of each view data model with respect to the Value Domain Management.

2.1.11.1. Assess whether the set of value domains for every view column defined within the physical data model is employed appropriately within the view.

2.1.11.2. Assess whether every view column that has a corresponding DBMS column restricted value domain is identified and is correctly addressed by the appropriate set of properly configured value domain management metadata.

2.2. Assess view data model meta-artifacts 2.2.1. Assess the completeness of each meta-artifact

2.2.1.1.Assess that all views are identified and are properly constructed 2.2.1.2.Assess that all view columns are identified and are properly

constructed. 2.2.1.3.Assess that all view columns are mapped to DBMS columns 2.2.1.4.Assess that all view columns contain the appropriate integrity

constraint clauses 2.2.1.5.Assess that all selects, nested selects, joins, renames, derived and

compound data view columns are properly constructed. 2.2.2. Assign the risk level associated with each meta-artifact not properly

constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.1.6 Data Model: XML Interface Model Assessment 1. Identify artifacts that bear on the assessment

34

1.1. Identify the appropriate set of XML interface models 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the XML interface models that are to be defined and captured. 1.1.4. Identify the meta-artifacts appropriate to the evaluation of XML interface

models. 1.2. For each XML interface model:

1.2.1. Identify components, such as, XML schema, XML element, and XML attributes.

1.2.2. Identify the definitions for each XML interface model component. 2. Perform the assessment

2.1. Assess each XML data model against involved component 2.1.1. Assess the adequacy of each XML data model with respect to Business

Requirements. 2.1.1.1.Assess that all the business requirements that state or imply the use of

XML are properly reflected in the XML data model. 2.1.2. Assess the adequacy of each XML data model with respect to Business

Rules. 2.1.2.1.Assess that all the business rules that state or imply the use of XML

are properly reflected in the XML data model 2.1.3. Assess the adequacy of each XML data model with respect to the CDRL.

2.1.3.1.Assess whether all implied CDRL physical databases are reflected in an appropriate XML data model

2.1.3.2.Assess whether all XML data model components are reflected in one or more of the CDRL elements

2.1.4. Assess the adequacy of each XML data model with respect to WBS. 2.1.4.1.Assess whether all implied WBS XML data models are reflected in an

appropriate XML data model 2.1.4.2.Assess whether all XML data model components are reflected in one

or more of the WBS elements 2.1.5. Assess the adequacy of each XML data model with respect to the Business

Evolution Scenarios. 2.1.5.1.Assess whether every XML data model is addressed by at least one

business evolution scenario. 2.1.5.2.Assess whether every XML data model is designed appropriately so

that it can respond to the scenario. 2.1.5.3.Assess whether the change/evolution strategy for an XML data model

is properly coordinated with view, physical data model, and software systems change strategies.

2.1.6. Assess the adequacy of each XML data model that is to be populated by with respect to the External Interface Requirements.

2.1.6.1.Assess whether every XML data model that is to be populated by external data is addressed by at least one external interface requirement.

2.1.6.2.Assess whether every XML data model that is to be populated by external data is designed appropriately so that it can respond to the external interface requirement.

35

2.1.7. Assess the adequacy of each XML data model that is to be populated by with respect to the External Interfaces.

2.1.7.1.Assess whether every XML data model that is populated by external data is addressed by at least one external interface.

2.1.7.2.Assess whether every XML data model that is to be populated by external data is designed appropriately so that it can respond to the external interface.

2.1.8. Assess the adequacy of each XML data model with respect to the External Quality Standards.

2.1.8.1.Assess whether the facilities defined within every XML data model is properly drawn from an established set of conventions from within the W3C.

2.1.8.2.Assess whether every XML data model that may be appropriate within the SEVIS II collection of XML data models is properly defined through the use of DHS ICE XML data modeling standards.

2.1.8.3.Assess whether every XML data model that may be appropriate within the SEVIS II collection of XML data models is properly defined through the use of OCIO Council for XML data modeling standards.

2.1.8.4.Assess whether every XML data model that may be appropriate within the SEVIS II collection of XML data models is properly defined through the use of U.S. Department of Justice NEAM XLM data modeling standards.



2.1.9. Assess the adequacy of each XML data model with respect to the Software Systems.

2.1.9.1.Assess whether every XML data model is properly interfaced with one or more application information systems as may be appropriate.

2.1.9.2.Ensure that every appropriate information system has SEVIS II database access only through a XML data model.

2.1.10. Assess the adequacy of each XML data model with respect to the Use Cases.

2.1.10.1. Assess whether the use cases adequately specify the required XML Schema and that the XML Schema appropriately maps to the DBMS Data Model.

2.1.11. Assess the adequacy of each XML data model with respect to the User Acceptance Tests.

2.1.11.1. Assess whether the tests adequately test Inserts, Deletes, and Modifies for every XML data model DBMS table.


2.1.11.3. Assess whether every inappropriate and/or out-of-bounds value for every XML data model database column is appropriately trapped.

36

2.1.12. Assess the adequacy of each XML data model with respect to the Value Domain Management.

2.1.12.1. Assess whether the set of value domains for every XML element is defined unambiguously, clearly, distinctly, and not-overlapping.

2.1.12.2. Assess whether every XML element that is to have a restricted value domain is identified and is correctly addressed by the appropriate set of properly configured value domain management metadata.

2.1.12.3. Assess that every XML element value domain does not semantically conflict with a DBMS column value domain.

2.2. Assess XML data model meta-artifacts 2.2.1. Assess the completeness of each meta-artifact

2.2.1.1.Assess that all XML schemas are identified and are properly constructed

2.2.1.2.Assess that all XML elements within the schemas are identified and are properly constructed.

2.2.1.3.Assess that all XML elements are mapped to DBMS columns 2.2.1.4.Assess that appropriate XML elements are properly constrained by

value domain assignments. 2.2.1.5.Assess that the collections of XML elements are sufficient to reflect

the implied policy of the mapped to one or more DBMS tables. 2.2.1.6.Assess that the collection of XML elements are sufficient to present

the information necessary for updating a DBMS table’s instance infrastructure.

2.2.1.7.Assess that the collection of XML elements are sufficient to present the information necessary for updating a DBMS table’s history and for auditability.


3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2 Involved Component to Data Model Assessments 6.2.1 Business Requirements Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of business requirements documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the business requirements that are defined and captured. 1.1.4. Identify the business requirement related data components

1.2. For each business requirement development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Concepts Data Model, Logical

Data Model, Physical Data Model, and XML Data Model

37

1.2.2. Identify the description for each interrelated business requirement data model component.

2. Perform the assessment. 2.1.Assess each Business Requirements interrelated data model

2.1.1. Assess the adequacy of each concept data model with respect to the business requirement.

2.1.1.1.Assess whether all the implied concept data model components, that is, Subject, Entity, Attribute, Assigned Value Domain, and Relationship from the business requirement have been addressed in one or more aspects of the concept data model.

2.1.1.2.Assess concept data model components, that is, Subject, Entity, Attribute, Assigned Value Domain, and Relationship with respect to the specific business requirement are sufficiently specified.

2.1.1.3.Assess whether every Subject, Entity, Attribute, Assigned Value Domain, and Relationship is called for by one or more business requirement.

2.1.2. Assess the adequacy of each logical data model with respect to the business requirement.

2.1.2.1.Assess whether all the implied logical data model components, that is, Schema, Table, Column, Assigned Value Domain, and Relationship from the business requirement have been addressed in one or more aspects of the logical data model.

2.1.2.2.Assess logical data model components, that is, Schema, Table, Column, Assigned Value Domain, and Relationship with respect to the specific business requirement are sufficiently specified.

2.1.2.3.Assess whether every Schema, Table, Column, Assigned Value Domain, and Relationship is called for by one or more business requirement.

2.1.3. Assess the adequacy of each physical data model with respect to the business requirement.

2.1.3.1.Assess whether all the implied physical data model components, that is, DBMS schema, DBMS tables, and DBMS columns from the business requirement have been addressed in one or more aspects of the physical data model.

2.1.3.2.Assess physical data model components, that is, DBMS Schema, DBMS Table, DBMS Column, Assigned Value Domain, and Relationship with respect to the specific business requirement are sufficiently specified.

2.1.3.3.Assess whether every DBMS Schema, DBMS Table, DBMS Column, Assigned Value Domain, and Relationship is called for by one or more business requirement.

2.1.4. Assess the adequacy of each XML data model with respect to the business requirement.

2.1.4.1.Assess whether all the implied XML data model components, that is, XML schema, XML elements and supporting XML structures from the

38

business requirement have been addressed in one or more aspects of the XML data model.

2.1.4.2.Assess XML data model components, that is, XML schema, XML elements and supporting XML structures with respect to the specific business requirement are sufficiently specified.

2.1.4.3.Assess whether every XML schema, XML elements and supporting XML structures is called for by one or more business requirement.


3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.2 Business Rules Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of business rule documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the business rules that are defined and captured. 1.1.4. Identify the business rule related data components.

1.2. For each business rule development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Data Element Model, Logical

Data Model, Physical Data Model, and View Data Model 1.2.2. Identify the description for each interrelated Business Rules data model

component. 2. Perform the assessment

2.1.1. Assess the adequacy of each data element model with respect to the business rule.

2.1.1.1.Assess whether all the implied data element model components, that is, Value Domains, and Data Elements from the business rule have been addressed in one or more aspects of the data element model.

2.1.1.2.Assess data element model components, that is, Value Domains, and Data Elements with respect to the specific business rule are sufficiently specified.

2.1.1.3.Assess whether every Value Domain and Data Element is called for by one or more business requirement.

2.1.2. Assess the adequacy of each logical data model with respect to the business rule.

2.1.2.1.Assess whether all the implied logical data model components, that is, Column, and Assigned Value Domain from the business rule have been addressed in one or more aspects of the logical data model.

2.1.2.2.Assess logical data model components, that is, Column, and Assigned Value Domain with respect to the specific business rule is sufficiently specified.

39

2.1.2.3.Assess whether every Column and Assigned Value Domain is called for by one or more business requirement.

2.1.3. Assess the adequacy of each physical data model with respect to the business requirement.

2.1.3.1.Assess whether all the implied physical data model components, that is, DBMS columns and Assigned Value Domains from the business rule have been addressed in one or more aspects of the physical data model.

2.1.3.2.Assess physical data model components, that is, DBMS Column, and Assigned Value Domain with respect to the specific business rules are sufficiently specified.

2.1.3.3.Assess whether the business rule use of DBMS columns are appropriate with respect to data type, allowed operation, and if appropriate SQL functions.

2.1.3.4.Assess whether business rule stored procedure implementations are correctly engineered and result in unambiguous messages provided the end user or up through the application system calling sequence.

2.1.3.5.Assess whether every DBMS Column and Assigned Value Domain is called for by one or more business requirement.

2.1.4. Assess the adequacy of each View data model with respect to the business requirement.

2.1.4.1.Assess whether all the implied View data model components, that is, view and view columns from the business rule have been addressed in one or more aspects of the XML data model.

2.1.4.2.Assess View data model components, that is, view and view columns with respect to the specific business rule are sufficiently specified.

2.1.4.3.Assess whether the business rule use of view columns are appropriate with respect to allowed functionality of views.

2.1.4.4.Assess whether business rule stored procedure implementations are correctly engineered and result in unambiguous messages provided the end user or up through the application system calling sequence.

2.1.4.5.Assess whether every view and view column is called for by one or more business requirement.

2.1.5. Assess the adequacy of each XML data model with respect to the business requirement.

2.1.5.1.Assess whether all the implied XML data model components, that is, XML schema, XML elements and supporting XML structures from the business rule have been addressed in one or more aspects of the XML data model.

2.1.5.2.Assess XML data model components, that is, XML schema, XML elements and supporting XML structures with respect to the specific business rule are sufficiently specified.

2.1.5.3.Assess whether every XML schema, XML elements and supporting XML structures is called for by one or more business requirement.


40

3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.3 CDRL (Contract Deliverable Requirements Line) Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of CDRL documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the CDRLs that are defined and captured. 1.1.4. Identify the CDRL related data components.

1.2. For each CDRL development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Physical Data Model, and XML

Data Model 1.2.2. Identify the description for each interrelated CDRL data model


2.1. Assess the adequacy of each physical data model with respect to the CDRL. 2.1.1. Assess whether all the implied physical data model components have been

delivered in terms of components, digital instances, and documentation. 2.2. Assess the adequacy of each XML data model with respect to the CDRL

2.2.1. Assess whether all the implied XML data model components have been delivered in terms of components, digital instances, and documentation..

2.3. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.4 Contract Work Breakdown Structure (WBS) Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of WBS documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the WBSs that are defined and captured. 1.1.4. Identify the WBS related data components.

1.2. For each WBS development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Logical Data Model, Physical

Data Model, and XML Data Model 1.2.2. Identify the description for each interrelated WBS data model component.

2. Perform the assessment 2.1. Assess the adequacy of each logical data model with respect to the WBS.

41

2.1.1. Assess whether all the implied logical data model components have been delivered in terms of components, digital instances, and documentation.

2.2. Assess the adequacy of each physical data model with respect to the WBS. 2.2.1. Assess whether all the implied physical data model components have been

delivered in terms of components, digital instances, and documentation. 2.3. Assess the adequacy of each XML data model with respect to the WBS

2.3.1. Assess whether all the implied XML data model components have been delivered in terms of components, digital instances, and documentation..

2.4. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.5 Evolution Scenarios Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of Evolution Scenario documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Evolution Scenarios that are defined and captured. 1.1.4. Identify the Evolution Scenarios related data components.

1.2. For each Evolution Scenario development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Data Element Model, Concept

Data Model, Logical Data Model, Physical Data Model, View Data Model, and XML Data Model

1.2.2. Identify the description for each interrelated Evolution Scenarios data model component.

2. Perform the assessment 2.1. Assess the adequacy of each data element model with respect to the Evolution

Scenarios. 2.1.1. Assess whether each evolution scenario adequately encompasses the

activities to accomplish changes required in the data element model in terms of data element model components changed, resources required, and the assessment of the impact of change on the concept, logical, physical, view, and XML data models.

2.2. Assess the adequacy of each concept data model with respect to the Evolution Scenarios.

2.2.1. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes required in the concept data model in terms of subject, entity, attribute, and relationships changed, resources required, and the assessment of the impact of change on the logical, physical, view, and XML data models.

2.2.2. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes in regards to ancestor data models, that is,

42

the data element model as a consequence of changes to the concept data model.

2.3. Assess the adequacy of each logical data model with respect to the Evolution Scenarios.

2.3.1. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes required in the logical model in terms of schema, table, column, and relationship components changed, resources required, and the assessment of the impact of change on the physical, view, and XML data models.

2.3.2. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes in regards to ancestor data models, that is, the concept model and data element model as a consequence of changes to the logical data model.

2.3.3. 2.4. Assess the adequacy of each physical data model with respect to the Evolution

Scenarios. 2.4.1. Assess whether each evolution scenario adequately encompasses the

activities to accomplish changes required in the physical data model in terms of DBMS schema, DBMS table, DBMS column, and relationship components changed, resources required, and the assessment of the impact of change on the view, and XML data models.

2.4.2. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes in regards to ancestor data models, that is, the logical data model, concept data model and data element model as a consequence of changes to the physical data model.

2.5. Assess the adequacy of each view data model with respect to the Evolution Scenarios.

2.5.1. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes required in the view data model in terms of view and view column components changed, and resources required.

2.5.2. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes in regards to ancestor data models, that is, the physical data model, logical data model, concept data model and data element model as a consequence of changes to the view data model.

2.6. Assess the adequacy of each XML data model with respect to the Evolution Scenarios.

2.6.1. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes required in the XML data model in terms of XML Schema and XML Element components changed, and resources required.

2.6.2. Assess whether each evolution scenario adequately encompasses the activities to accomplish changes in regards to ancestor data models, that is, the physical data model, logical data model, concept data model and data element model as a consequence of changes to the XML data model.

2.7. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report

43

4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.6 External Interface Requirements Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of External Interface Requirements documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the External Interface Requirements that are defined and captured. 1.1.4. Identify the External Interface Requirements related data components.

1.2. For each External Interface Requirements development, review, or evolution effort:

1.2.1. Identify the relevant components, that is, Physical Data Model, View Data Model, and XML Data Model

1.2.2. Identify the description for each interrelated External Interface Requirements data model component.

2. Perform the assessment 2.1. Assess the adequacy of each physical data model with respect to the External

Interface Requirements 2.1.1. Assess whether the external interface is sufficiently identified and

specified to the level that an Extract, Transform, and Load process can be expertly constructed.

2.1.2. Assess whether there is sufficient detail to the external interface to unambiguously address issues related to granularity of both sides of the interface, precision of the various values for the data fields, and an exact matching of the values for any data fields that is to be imported.

2.1.3. Assess whether there is sufficient information to be able to fill out audit trail information and to be able to back out data once it has been imported.

2.2. Assess the adequacy of each view data model with respect to the External Interface Requirements.

2.2.1. Assess whether the external interface is sufficiently identified and specified to the level that a set of views can be constructed to directly import the data from a connected source.

2.2.2. Assess whether there is sufficient detail to the external interface to unambiguously construct views that that address the granularity of both sides of the interface, precision of the various values for the data fields, and an exact matching of the values for any data fields that is to be imported.

2.2.3. Assess whether there is sufficient information to be able to fill out audit trail information built into views.

2.3. Assess the adequacy of each XML data model with respect to the External Interface Requirements.

2.3.1. Assess whether the external interface is sufficiently identified and specified to the level that a set of XML Schemas can be constructed to process data that is exported from external sources.

44

2.3.2. Assess whether there is sufficient detail to the external interface to unambiguously construct XML schemas that that address the granularity of both sides of the interface, precision of the various values for the data fields, and an exact matching of the values for any data fields that is to be imported.

2.3.3. Assess whether there is sufficient information to be able to fill out audit trail information built into the XML schemas.

2.4. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.7 External Interfaces Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of External Interface documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the External Interface that are defined and captured. 1.1.4. Identify the External Interface related data components.

1.2. For each External Interface development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Physical Data Model, View Data

Model, and XML Data Model 1.2.2. Identify the description for each interrelated External Interface data model


2.1. Assess the adequacy of each physical data model with respect to the External Interfaces.

2.1.1. Assess whether a sample of data from an external interface can be loaded in a test environment.

2.1.2. Assess whether the loaded test data conforms to the external interface requirements.

2.1.3. Assess whether DBMS column values are out of semantic range with expected value domains.

2.1.4. Assess whether all required DBMS column values are valued and all relationships among rows are as expected.

2.1.5. Assess the completeness of the content-based DBMS column values 2.1.6. Assess the completeness of the infrastructure-based DBMS column

values. 2.1.7. Assess the completeness of the audit-trail-based DBMS column values.

2.2. Assess the adequacy of each view data model with respect to the External Interfaces.

2.2.1. Assess whether the external interface performs as expected with the views when there is a direct-connect data transfer between two software systems.

2.2.2. Assess whether there is sufficient information to be able to fill out audit trail information built into views.

45

2.3. Assess the adequacy of each XML data model with respect to the External Interfaces.

2.3.1. Assess whether the external interface performs as expected with the XML data streams when there is a received set of data that has been exported via an XML format.

2.3.2. Assess whether there is sufficient information to be able to fill out audit trail information built into XML data..

2.4. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.8 External Quality Standards Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of External Quality Standards documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the External Quality Standards that are defined and captured. 1.1.4. Identify the External Quality Standards related data components.

1.2. For each External Quality Standards related product development, review, or evolution effort:

1.2.1. Identify the relevant components, that is, Data Element Model, Concepts Data Model, Logical Data Model, Physical View Data Model, and XML Data Model

1.2.2. Identify the description for each interrelated External Quality Standards data model component.

2. Perform the assessment 2.1. Assess the components of the Data Element Model against required metadata

components from ISO 11179 standard (Part 3) for data element metadata. 2.2. Assess the components of the Concepts Data Model against the required

metadata for the U.S. Federal Government CIO Council’s Data Performance Plan 2.3. Assess the components of the Logical Data Model against ISO ANSI SQL 1992

Entry Level. 2.4. Assess the components of the Physical Data Model against Oracle 10g but not to

contain any SQL facility and/or syntax that exceeds ISO ANSI SQL 1992 Entry Level without a specific waver.

2.5. Assess the components of the View Data Model against ISO ANSI SQL 1992 Entry Level.

2.6. Assess the components of the XML Data Model against W3C guidelines, the U.S. Department of Justice’s NEAM model, and the XML Guidelines published by the U.S. Department of the Navy.


46

6.2.9 Hardware Systems Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of Hardware System documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Hardware Systems that are to be employed for SEVIS II. 1.1.4. Identify the Hardware Systems related data components.

1.2. For each Hardware Systems on which databases are to be deployed: 1.2.1. Identify the relevant components, that is, Physical Data Model, and View

Data Model. 1.2.2. Identify the description for each interrelated Hardware Systems data

model component. 2. Perform the assessment

2.1. Assess the hardware characteristics of the computing environment onto which the actual databases will be located.

2.1.1. Assess the size of computer memory for buffer management purposes. 2.1.2. Assess the speed and size of hardware disks for overall throughput. 2.1.3. Assess the ability of the DBMS to spread parts of the database onto

different physical devices. 2.1.4. Assess the ability of the DBMS to adequately perform backup and

recovery. 2.1.5. Assess whether there is sufficient computer memory and disk space to

handle the size, volume, and performance requirements for views. 2.1.6. Assess whether the sizes for all views can be adequately handled by the

DBMS. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.10 On-line Interfaces Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of On-line Interface documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the On-line Interface that are defined and captured. 1.1.4. Identify the On-line Interface related data components.

1.2. For each On-line Interface related product development, review, or evolution effort:

1.2.1. Identify the relevant components, that is, Physical Data Model, View Data Model

47

1.2.2. Identify the description for each interrelated On-line Interface data model component.

2. Perform the assessment 2.1. Assess the mapping between the On-Line Interface and the physical data model

to ensure the maximum efficiency. 2.2. Assess the data fields on the On-Line Interface to ensure that there are no out-of-

bounds values that result in value misinterpretation by the end user. 2.3. Assess the creation and releasing of database locks for SEVIS II business

transactions that ensure a high degree of data integrity with a minimum of lockout and zero deadlock.

2.4. Assess the appropriate use of Views to ensure that the maximum database operations are performed on the server as opposed to execution on the client machine.

2.5. Assess whether the on-line interfaces properly map to their inherited artifact requirements, use cases.

2.5.1. Identify the use case components that must relate to the given on-line interfaces.

2.5.2. Determine if the identified use case components are properly associated to appropriate items within the on-line interface.

2.6. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.11 Software Systems Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of Software Systems documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Software Systems that are defined and captured. 1.1.4. Identify the Software Systems related data components.

1.2. For each Software Systems related product development, review, or evolution effort:

1.2.1. Identify the relevant components, that is, Physical Data Model, View Data Model, and XML Data Model

1.2.2. Identify the description for each interrelated Software Systems data model component.

2. Perform the assessment 2.1. Assess the adequacy of each physical data model with respect to the Software

Systems 2.1.1. Assess whether every DBMS column from every table is addressed

through an insert, update, or possibly delete by at least one module of a software system.

48

2.1.2. Assess whether every identified business rule is properly accomplished by one or more appropriate modules of a software system.

2.1.3. Assess whether every value domain value for every restricted value domain DBMS column is properly addressed by one or more appropriate modules of a software system.

2.1.4. Assess whether all user acceptance tests are properly addressed by one or more appropriate modules of a software system.

2.1.5. Assess whether all use cases are completely and properly addressed by one or more appropriate modules of a software system.

2.1.6. Assess whether all data updates are properly recorded on a re-processable audit train.

2.1.7. Assess whether all data updates are able to be properly backed out as may be allowed by a use case.

2.2. Assess the adequacy of each view data model with respect to the Software Systems.

2.2.1. Assess whether every view column from every view is addressed through an insert, update, or possibly delete by at least one module of a software system..

2.2.2. Assess whether every identified business rule is properly accomplished by one or more appropriate modules of a software system.

2.2.3. Assess whether every value domain value for every restricted value domain DBMS column is properly addressed by one or more appropriate modules of a software system.

2.2.4. Assess whether all user acceptance tests are properly addressed by one or more appropriate modules of a software system.

2.2.5. Assess whether all use cases are completely and properly addressed by one or more appropriate modules of a software system.

2.2.6. Assess whether all data updates are properly recorded on a re-processable audit train.


2.3. Assess the adequacy of each XML data model with respect to the Software Systems.

2.3.1. Assess whether an XML data package is properly constructed by the appropriate software system according to the XML Schema.

2.3.2. Assess whether an XML data package is properly read and the appropriate updates are made to the database by the appropriate software system according to the rules set out in the XML Schema.

2.4. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.12 Use Cases Assessment

49

1. Identify artifacts that bear on the assessment 1.1. Identify the appropriate set of Use Case documents

1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Use Cases that are defined and captured. 1.1.4. Identify the Use Cases related data components.

1.2. For each Use Cases related product development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Data Element, Concept data

Model, Logical Data Model, Physical Data Model, View Data Model, and XML Data Model

1.2.2. Identify the description for each interrelated Use Cases data model component.

2. Perform the assessment 2.1. Assess the adequacy of each data element model with respect to the Use Cases

2.1.1. Assess whether every user case implied data element is properly constructed in the data element model.

2.1.2. Assess whether each data element is properly supported by defined data element data model components of Concepts, Conceptual Value domain, Value Domain, and Data Element Classifications.

2.2. Assess the adequacy of each concept data model with respect to the Use Cases 2.2.1. Assess whether every user case implied concept data model components

are properly constructed in the concept data model, that is, Subjects, Entities, Attributes, and Assigned Value Domains.

2.3. Assess the adequacy of each logical data model with respect to the Use Cases 2.3.1. Assess whether every user case implied logical data model components

are properly constructed in the concept data model, that is, Schemas, Tables, Columns, and Assigned Value Domains.

2.4. Assess the adequacy of each physical data model with respect to the Use Cases 2.4.1. Assess whether every DBMS column from every table is addressed

through an insert, update, or possibly delete by at least one component and/or section of a use case.

2.4.2. Assess whether every identified business rule is properly accomplished by one or more appropriate modules of a use case.

2.4.3. Assess whether every value domain value for every restricted value domain DBMS column is properly addressed by one or more appropriate modules of a use case.


2.5. Assess the adequacy of each view data model with respect to the Use Cases. 2.5.1. Assess the adequacy of each view data model with respect to the Use

Cases 2.5.2. Assess whether every view column from every table is addressed through

an insert, update, or possibly delete by at least one component and/or section of a use case.

2.5.3. Assess whether every identified business rule is properly accomplished by one or more appropriate modules of a use case.

50

2.5.4. Assess whether every value domain value for every restricted value domain DBMS column is properly addressed by one or more appropriate modules of a use case.


2.6. Assess the adequacy of each XML data model with respect to the Use Cases. 2.6.1. Assess whether an XML data package is specified in sufficient detail as to

be unambiguous. 2.6.2. Assess whether an XML data package is specified in sufficient detail to

ensure that it can be unambiguous properly read and the appropriate updates are made to the database.

2.7. Assess whether the use cases properly specify the functions by organization, and that the allowed access to the column in terms of read, write, select, and update are completely specified.

2.8. Assess whether use case restricted value domain data elements are properly accomplished

2.8.1. Assess whether there is sufficient use case logic to ensure that only an appropriate set of restricted value domain data element values are presented.

2.8.2. Assess whether sufficient data element based metadata is requested and properly set in support of a restricted value domain choice.

2.9. Assess whether business transactions are properly set for this use case. 2.9.1. Assess whether the business transaction properly identified. 2.9.2. Assess whether there sufficient metadata captured for each business

transaction. 2.9.3. Assess whether the logical database tables identified for the proper capture

of a business transaction. 2.10. Assess whether business transaction history is properly set for this use

case. 2.10.1. Assess whether the relevant tables associated with a business transaction

history are properly identified. 2.10.2. Assess whether there sufficient metadata captured for each business

transaction history. 2.10.3. Assess whether the logical database tables identified for the proper

retrieval of a business transaction history. 2.10.4. Assess whether the history destination tables are properly identified for the

capture of business transaction history. 2.11. Assess whether use cases properly map to source requirements

2.11.1. Identify the requirements that relate to the given use case. 2.11.2. Determine if the identified requirements are properly associated to

appropriate items within the use case. 2.12. Assign the risk level associated with each meta-artifact not properly

constructed. 3. Determine the findings and create draft assessment report. 4. Present the findings and revise draft assessment report. 5. Create final report and deliver to Government.

51

6.2.13 User Acceptance Tests Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of User Acceptance Test documents 1.1.1. Review requirements documents, including for example, Business

Requirements, Functional Requirements Document, WBS, CDRLs, External Interface Requirements, On-line Interfaces, and Use Cases

1.1.2. Review scope and business problem related documentation. 1.1.3. Identify a complete set of User Acceptance Test with respect to the

documents above. 1.1.4. Ensure that every User Acceptance Test is unambiguously specified, is

bounded by a well-defined set of start-up date, User Acceptance Test steps, and well-defined outcomes.

1.1.5. Ensure that every User Acceptance Test has unambiguous criteria for pass or fail.

1.1.6. Identify the User Acceptance Test related data components. 1.2. For each User Acceptance Test related product development, review, or

evolution effort: 1.2.1. Identify the relevant components, that is, Physical Data Model, View Data

Model, and XML Data Model 1.2.2. Identify the description for each interrelated User Acceptance Test data

model component. 2. Perform the assessment

2.1. Assess the adequacy of each physical data model with respect to User Acceptance Tests

2.1.1. Assess whether every DBMS column from every table is addressed through an insert, update, or possibly delete by at least one component and/or section of a User Acceptance Test.

2.1.2. Assess whether every identified business rule is properly accomplished by one or more appropriate modules of a User Acceptance Test.

2.1.3. Assess whether every value domain value for every restricted value domain DBMS column is properly addressed by one or more appropriate modules of a User Acceptance Test.

2.1.4. Assess whether all data updates are able to be properly backed out as may be allowed by a User Acceptance Test.

2.2. Assess the adequacy of each view data model with respect to User Acceptance Tests.

2.2.1. Assess the adequacy of each view data model with respect to User Acceptance Tests

2.2.2. Assess whether every view column from every table is addressed through an insert, update, or possibly delete by at least one component and/or section of a User Acceptance Teste.

2.2.3. Assess whether every identified business rule is properly accomplished by one or more appropriate modules of a User Acceptance Test.

52

2.2.4. Assess whether every value domain value for every restricted value domain DBMS column is properly addressed by one or more appropriate modules of a User Acceptance Test.

2.2.5. Assess whether all data updates are able to be properly backed out as may be allowed by a User Acceptance Test.

2.3. Assess the adequacy of each XML data model with respect to User Acceptance Tests.

2.3.1. Assess whether an XML data package is specified in sufficient detail as to be unambiguous.

2.3.2. Assess whether an XML data package is specified in sufficient detail to ensure that it can be unambiguous properly read and the appropriate updates are made to the database.

2.4. Assess whether the User Acceptance Tests properly specify the functions by organization and that the allowed access to the column in terms of read, write, select, and update are completely specified.

2.5. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.2.14 Value Domains and Management Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of Value Domain Management documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Value Domain Management that are defined and captured. 1.1.4. Identify the Value Domain Management related data components.

1.2. For each Value Domain Management development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Data Element Model, Concept

Data Model, Logical Data Model, Physical Data Model, View Data Model, and XML Data Model

1.2.2. Identify the description for each interrelated Value Domain Management data model component.

2. Perform the assessment 2.1. Assess the adequacy of each data element model with respect to Value Domain

Management. 2.1.1. Assess whether each value domain is properly specified and that all value

domain values allowed are well defined, non-overlapping, and have been formally approved for use in the databases and enforced through the software systems.

2.1.2. Assess whether restricted value data elements are properly assigned a specific value domain.

2.2. Assess the adequacy of each concept data model with respect to Value Domain Management.

53

2.2.1. Assess whether a value domain that is assigned to an attribute is a subset of a value domain that is assigned to a data element.

2.3. Assess the adequacy of each logical data model with respect to Value Domain Management .

2.3.1. Assess whether a value domain that is assigned to an column is a subset of a value domain that is assigned to an attribute.

2.4. Assess the adequacy of each physical data model with respect to the Value Domain Management.

2.4.1. Assess whether a value domain that is assigned to a DBMS column is a subset of a value domain that is assigned to a column.

2.5. Assess the adequacy of each view data model with respect to the Value Domain Management.

2.5.1. Assess whether each view column is properly established to enforce a DBMS column’s assigned value domain.

2.5.2. Assess whether each software system module that employs a view column that represents a restricted value domain is established such that it will only allow legal values.

2.6. Assess the adequacy of each XML data model with respect to the Value Domain Management.

2.6.1. Assess whether each view column is properly established to enforce a DBMS column’s assigned value domain.

2.6.2. Assess whether each software system module that employs an XML element that represents a restricted value domain is established such that it will only allow legal values.

2.7. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3 Involved Component to Involved Component Assessments No assessments are needed on External Quality Standards because they are “outside” the actual accomplishment of project work. Business requirements are addressed as the last subsection with respect to discovering those business requirements that are not being addressed by another involved component. 6.3.1 Business Rules Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of business rule documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the business rules that are defined and captured. 1.1.4. Identify the business rule related data components.

54

1.2. For each business rule development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Business Requirements, Work

Breakdown Structure, (WBS), Evolution Scenarios, User Acceptance Tests, and Value Domains and Management

1.2.2. Identify the description for each interrelated Business Rules component. 2. Perform the assessment

2.1. Assess whether each business rule is properly mapped to a business requirement. 2.2. Assess whether each business rule is an implementation of an appropriate WBS

task. 2.3. Assess whether each business rule is properly addressed in an evolution scenario

that might address its evolution and/or modification. 2.4. Assess whether each business rule is properly accounted for in one or more user

acceptance tests. 2.5. Assess whether each business rule that addresses restricted value domains is

properly addressed by value domains and management. 2.6. Assign the risk level associated with each meta-artifact not properly constructed.

3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3.2 CDRL (Contract Deliverable Requirements Line) Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of CDRL documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the CDRLs that are defined and captured. 1.1.4. Identify the CDRL related data components.

1.2. For each CDRL development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Hardware Systems, On-line

Interfaces, Software Systems, and User Acceptance Tests. 1.2.2. Identify the description for each interrelated CDRL component.

2. Perform the assessment 2.1. Assess whether each CDRL is properly identified as a procured item within

appropriate hardware systems. 2.2. Assess whether each CDRL is properly identified as a procured item within

appropriate software systems. 2.3. Assess whether each CDRL is properly identified as a procured item within

appropriate user acceptance tests. 2.4. Assign the risk level associated with each meta-artifact not properly constructed.


55

6.3.3 Contract Work Breakdown Structure (WBS) Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of WBS documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the WBSs that are defined and captured. 1.1.4. Identify the WBS related data components.

1.2. For each WBS development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Business Requirements,

Business Rules, Evolution Scenarios, External Interface Requirements, External Interfaces, External Quality Standards, Hardware Systems, On-line Interfaces, Software Systems, Use Cases, User Acceptance Tests, and Value Domains and Management

1.2.2. Identify the description for each interrelated WBS component. 2. Perform the assessment

2.1. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing business requirements.

2.2. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing business rules.

2.3. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing evolution scenarios.

2.4. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing external interface requirements.

2.5. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing external interfaces.

2.6. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing external quality standards.

2.7. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing hardware systems.

2.8. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing on-line interfaces.

2.9. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing software systems.

2.10. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing use cases.

56

2.11. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing user acceptance tests.

2.12. Assess whether the WBS properly identifies and details the scope, steps, resources, durations, deliverables, and quality assessment appropriate for accomplishing value domains and management.

2.13. Assign the risk level associated with each meta-artifact not properly constructed.

3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3.4 Evolution Scenarios Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of Evolution Scenario documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Evolution Scenarios that are defined and captured. 1.1.4. Identify the Evolution Scenarios related data components.

1.2. For each Evolution Scenario development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, External Interfaces, External

Quality Standards, Hardware Systems, On-line Interfaces, Software Systems, User Acceptance Tests, and Value Domains and Management

1.2.2. Identify the description for each interrelated Evolution Scenarios component.

2. Perform the assessment 2.1. Assess whether there is a properly identified, engineered and accomplished

evolution scenario that addresses changes and the likely effects from such changes in external interfaces.

2.2. Assess whether there is a properly identified, engineered and accomplished evolution scenario that addresses changes and the likely effects from such changes in external quality standards.

2.3. Assess whether there is a properly identified, engineered and accomplished evolution scenario that addresses changes and the likely effects from such changes in hardware systems.

2.4. Assess whether there is a properly identified, engineered and accomplished evolution scenario that addresses changes and the likely effects from such changes in on-line interfaces.

2.5. Assess whether there is a properly identified, engineered and accomplished

evolution scenario that addresses changes and the likely effects from such changes in software systems.

57

2.6. Assess whether there is a properly identified, engineered and accomplished evolution scenario that addresses changes and the likely effects from such changes in user acceptance tests.

2.7. Assess whether there is a properly identified, engineered and accomplished evolution scenario that addresses changes and the likely effects from such changes in value domains and management.

2.8. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3.5 External Interface Requirements Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of External Interface Requirements documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the External Interface Requirements that are defined and captured. 1.1.4. Identify the External Interface Requirements related data components.

1.2. For each External Interface Requirements development, review, or evolution effort:

1.2.1. Identify the relevant components, that is, Evolution Scenarios 1.2.2. Identify the description for each interrelated External Interface

Requirements component. 2. Perform the assessment

2.1. Assess whether there is an appropriate evolution scenario that addresses possible changes in external interface requirements.

2.2. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3.6 External Interfaces Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of External Interface documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the External Interface that are defined and captured. 1.1.4. Identify the External Interface related data components.

1.2. For each External Interface development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Business Requirements,

Hardware Systems, On-line Interfaces, Software Systems, Use Cases, User Acceptance Tests, and Value Domains and Management

58

1.2.2. Identify the description for each interrelated External Interface component.

2. Perform the assessment 2.1. Assess whether the external interfaces properly identify and address the

appropriate business requirements. 2.2. Assess whether the external interfaces properly identify and address the

appropriate hardware systems. 2.3. Assess whether the external interfaces properly identify and address the

appropriate on-line interfaces. 2.4. Assess whether the external interfaces properly identify and address the

appropriate software systems. 2.5. Assess whether the external interfaces properly identify and address the

appropriate use cases. 2.6. Assess whether the external interfaces properly identify and address the

appropriate user acceptance tests. 2.7. Assess whether the external interfaces properly identify and address the

appropriate value domains and management. 2.8. Assign the risk level associated with each meta-artifact not properly constructed.

3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3.7 Hardware Systems Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of Hardware System documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Hardware Systems that are to be employed for SEVIS II. 1.1.4. Identify the Hardware Systems related data components.

1.2. For each Hardware Systems on which databases are to be deployed: 1.2.1. Identify the relevant components, that is, CDRL (Contract Del Req Line),

External Interfaces, External Quality Standards, On-line Interfaces, and Software Systems.

1.2.2. Identify the description for each interrelated Hardware Systems component.

2. Perform the assessment 2.1. Assess that the hardware system is properly identified by a CDRL. 2.2. Assess that the external interfaces are properly engineered to satisfactorily

perform on the selected hardware system. 2.3. Assess whether the external quality standards have properly guided the selection,

configuration and deployment of the hardware systems. 2.4. Assess whether the on-line interfaces are properly engineered to satisfactorily

perform on the selected hardware system.

59

2.5. Assess whether the software interfaces are properly engineered to satisfactorily perform on the selected hardware system.

2.6. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3.8 On-line Interfaces Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of On-line Interface documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the On-line Interface that are defined and captured. 1.1.4. Identify the On-line Interface related data components.

1.2. For each On-line Interface related product development, review, or evolution effort:

1.2.1. Identify the relevant components, that is, Business Requirements, Business Rules, Hardware Systems, Software Systems, Use Cases, User Acceptance Tests, and Value Domains and Management

1.2.2. Identify the description for each interrelated On-line Interface component. 2. Perform the assessment

2.1. Assess whether the on-line interface individual components properly identify the specific business requirements that are accomplished.

2.2. Assess whether the on-line interface individual components properly identify and accomplish the business rules.

2.3. Assess whether the on-line interface individual components properly identify and are appropriately engineered and deployed on the hardware systems to which they are assigned.

2.4. Assess whether the on-line interface individual components properly identify and are appropriately engineered and deployed on the software systems through which they are executed.

2.5. Assess whether the on-line interface individual components properly identify and are appropriately engineered and accomplish the appropriate sections of the use cases from which they are derived.

2.6. Assess whether the on-line interface individual components properly identify and are appropriately engineered and tested through the various user acceptance tests.

2.7. Assess whether the on-line interface individual components properly identify and are appropriately engineered and accomplish the necessary actions associated with value domains and management.

2.8. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government

60

6.3.9 Software Systems Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of Software Systems documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Software Systems that are defined and captured. 1.1.4. Identify the Software Systems related data components.

1.2. For each Software Systems related product development, review, or evolution effort:

1.2.1. Identify the relevant components, that is, Business Requirements, Business Rules, Evolution Scenarios, External Interface Requirements, External Interfaces, Hardware Systems, On-line Interfaces, Use Cases, User Acceptance Tests, and Value Domains and Management

1.2.2. Identify the description for each interrelated Software Systems component.

2. Perform the assessment 2.1. Assess whether the software system individual components properly identify the

specific business requirements that are accomplished. 2.2. Assess whether the software system individual components properly identify

and accomplish the business rules. 2.3. Assess whether the software system individual components properly identify and

are appropriately engineered and address the specific requirements of the different evolution scenarios that are likely within this effort.

2.4. Assess whether the software system individual components properly identify and are appropriately engineered to address the external interface requirements for this effort.

2.5. Assess whether the software system individual components properly identify and are appropriately engineered and accomplish the external interfaces to which they are assigned.

2.6. Assess whether the software system individual components properly identify and are appropriately engineered and deployed on the hardware systems to which they are assigned.

2.7. Assess whether the software system individual components properly identify and are appropriately engineered and accomplished through their executing software systems.

2.8. Assess whether the software system individual components properly identify and are appropriately engineered and accomplish the appropriate sections of the use cases from which they are derived.

2.9. Assess whether the software system individual components properly identify and are appropriately engineered and tested through the various user acceptance tests.

2.10. Assess whether the software system individual components properly identify and are appropriately engineered and accomplish the necessary actions associated with value domains and management.

61


3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3.10 Use Cases Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of Use Case documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the Use Cases that are defined and captured. 1.1.4. Identify the Use Cases related data components.

1.2. For each Use Cases related product development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Business Requirements,

Business Rules, External Interfaces, and Value Domains and Management 1.2.2. Identify the description for each interrelated Use Cases component.

2. Perform the assessment 2.1. Assess the individual sections of the use cases and identify that all the

appropriate business requirements have been addressed. 2.2. Assess the individual sections of the use case and identify from within the

business rules inventory the appropriate business rule that should be executing within this given situation.

2.3. Assess the individual sections of the use case and identify all the appropriate external interfaces to which this use case component applies.

2.4. Assess the individual sections of the use case and identify appropriate value domains and management component that applies to this given situation.

2.5. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report. 4. Present the findings and revise draft assessment report. 5. Create final report and deliver to Government. 6.3.11 User Acceptance Tests Assessment 1. Identify artifacts that bear on the assessment

1.1. Identify the appropriate set of User Acceptance Tests documents 1.1.1. Review requirements documents. 1.1.2. Review scope and business problem related documentation. 1.1.3. Identify the User Acceptance Tests that are defined and captured. 1.1.4. Identify the User Acceptance Tests related data components.

1.2. For each User Acceptance Tests related product development, review, or evolution effort:

62

1.2.1. Identify the relevant components, that is, Business Requirements, Business Rules, External Interfaces, Hardware Systems, On-line Interfaces, Software Systems, Use Cases, and Value Domains and Management

1.2.2. Identify the description for each interrelated Software Systems component.

2. Perform the assessment 2.1. Assess whether the user acceptance test has properly identified and is configured

to assess the success or failure of a business requirement. 2.2. Assess whether the user acceptance test has properly identified and is configured

to assess the success or failure of a business rule. 2.3. Assess whether the user acceptance test has properly identified and is configured

to assess the success or failure of data that is received from or exported through an external interface.

2.4. Assess whether the user acceptance test has properly identified and is configured to assess the success or failure of the adequacy and performance of the hardware system that is being tested.

2.5. Assess whether the user acceptance test has properly identified and is configured to assess the success or failure of the proper operation of on-line interfaces.

2.6. Assess whether the user acceptance test has properly identified and is configured to assess the success or failure of the proper operation of software systems.

2.7. Assess whether the user acceptance test has properly identified and is configured to assess the adequacy of accomplishing the various components of use cases.

2.8. Assess whether the user acceptance test has properly identified and is configured to assess the proper utilization of value domains and management.

2.9. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 6.3.12 Value Domains and Management Assessment 1. Identify artifacts that bear on the assessment


1.2. For each Value Domain Management development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Business Requirements,

Business Rules, Evolution Scenarios, and External Interfaces. 1.2.2. Identify the description for each interrelated Value Domain Management


2.1. Assess the adequacy of the engineering of value domains and management to accommodate the various needs implied by business requirements.

63

2.2. Assess the adequacy of the engineering of value domains and management to accommodate the various needs implied by business rules.

2.3. Assess the adequacy of the engineering of value domains and management to accommodate the various needs implied by various evolution scenarios that change quantities, values, and meanings of existing restricted value domain values.

2.4. Assess the adequacy of the engineering of value domains and management to accommodate the various needs implied by various external that may change over time thus causing changes in the quantities, values, and meanings of existing restricted value domain values.

2.5. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government

6.3.13 Business Requirements Assessment 1. Identify artifacts that bear on the assessment


1.2. For each Value Domain Management development, review, or evolution effort: 1.2.1. Identify the relevant components, that is, Business Rules, Work

Breakdown Structure, (WBS), External Interface Requirements, External Interfaces, On-line Interfaces, Software Systems, Use Cases, User Acceptance Tests, and Value Domains and Management

1.2.2. Identify the description for each interrelated business requirements component.

2. Perform the assessment 2.1. Assess whether each business requirement is addressed by one or more business

rules as may be appropriate. 2.2. Assess whether each business requirement is addressed by one or more sections

in the WBS as may be appropriate. 2.3. Assess whether each business requirement is addressed by one or more external

interface requirements as may be appropriate. 2.4. Assess whether each business requirement is addressed by one or more external

interfaces as may be appropriate. 2.5. Assess whether each business requirement is addressed by one or more on-line

interfaces as may be appropriate. 2.6. Assess whether each business requirement is addressed by one or more software

systems as may be appropriate. 2.7. Assess whether each business requirement is addressed by one or more software

systems as may be appropriate.

64

2.8. Assess whether each business requirement is addressed by one or more use cases as may be appropriate.

2.9. Assess whether each business requirement is addressed by one or more user acceptance tests as may be appropriate.

2.10. Assess whether each business requirement is addressed by one or more value domains and management as may be appropriate.


3. Determine the findings and create draft assessment report 4. Present the findings and revise draft assessment report 5. Create final report and deliver to Government 7.0 Risk Assessment To the maximum extent practical, every data management assessment includes a list of the items assessed and a rating for each item. The proposed risk assessments are: no risk (0), low (1), moderate (2), or high (3). Additionally, weighting factor multipliers of the risk assessments are: Concepts Data Model (1), Data Element Model (2), Logical Data Model (2), Physical Data Model (3), View Data Model (3), and XML Model (3). Every data component, whether it is a Data Model such as Data Element, Concepts, Logical, Physical, View, or XML, and every Interrelated Component such as Business Requirements, Use Cases, or User Acceptance Tests will be evaluated for its data or interrelated data characteristics. The evaluation strategy will conclude that the component represents one of the following five categories of product and process maturity and quality:

Effective implementation Implementation evident—not effective Implementation underway—not yet in place Respondent aware of requirement—not yet implemented Component not evident

In addition, an overall risk will be assigned to the component. The strategy for assessing risks is taken from the SEVIS program Risk Management Plan (October 8, 2008). The risk process is represented by a matrix and consists of two dimensions: likelihood, and consequence. The Likelihood dimension consists of five levels:

Remote Unlikely Likely Highly Likely Near Certainty

The consequence dimension also consists of five levels:

65

Minimal or no Impact Acceptable with Some Reduction in Margin Acceptable with Significant reduction in margin Acceptable No Remaining margin Unacceptable

The combination of these two five levels produces an overall risk as set out in the following table:

Likelihood Levels

Consequence Levels 1 2 3 4 5

5 Y Y R R R 4 G Y Y R R 3 G G G Y R 2 G G G G R 1 G G G G Y


A08 Data Model Evaluation September 29 2009 Data Models


58

1

Data Model Evaluation of September 29, 2009 Delivery

1. March and April 2009 Problems List 1.1. General Problems List

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 1 Red Value domain management. Single (#1, 2,

13)

No Assessment: There is not an adequate accounting of the different database columns that are reference data based, regardless of reference data case (1 through 5). The analysis of all the use cases through 9/23 of Products 1, 2, 3, 4, 6, and 7 identified over 700 Case 1. The duplicates which definitely exist across the use cases have not been removed. The data models “Domain” table, which is the only approach for value domain management only identifies about 50 Reference Data columns. Mitigation: An overall assessment needs to be conducted to resolve this very great discrepancy between the likely 500 or more reference data elements identified by the IV&V data management expert and those identified by the Development Contractor. A formal approach needs to be instituted that discovers and regularizes, adjudicates, and maintains all reference, master, and parameter data through all its Cases across all of SEVIS. There will need to be both formal policies and procedures but also sophisticated software created to support all types of value domain management. There needs to be a unified set of all Reference, Parameter, and Master Data elements that is thoroughly reviewed and adjudicated by the SEVIS II business owners. Supporting such analyses needs to be the use cases for creating and evolving the value sets. Finally, generic use cases need to be created that enforce proper SEVIS II system behavior and those use cases need to be referenced from wherever it is appropriate within the existing and under development use cases. Thereafter, the data models need to be modified to satisfactorily reflect the required use case data structures. Finally, every designed and implemented software module needs to be assessed for the correct design and deployment of Reference, Parameter, and Master Data elements.

2

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Reference Data Parameter and Value Domain Management; Reference Data, Parameters, and Value Domain Management See also the Reference Data whitepaper.

2 Red Value Domain Management. Multiple/Complex (#1 & 2)

No Assessment: The analysis of the use cases for Products 1, 2, 3, 4, 6, and 7 identified about 250 (duplicates across use cases have not been removed) Reference Data columns that are Case 2 or greater. None are even acknowledged to exist by the Development Contractor. Mitigation: As above, this very great discrepancy needs to be resolved. See the Reference Data whitepaper. Issue Thread: Reference Data, Parameters, and Value Domain Management

3 Red Begin and End dates for multi-policy tables (#3 & 4)

No Assessment: There are four classes of columns for every table: business data, metadata, relationship data, and uniqueness data. If the table embraces multiple policies via its sets of business data columns, there has to be a separate set of metadata for each such business data-based policy. See also Items 4 and #16. Mitigation: Each table needs to be examined and possibly re-engineered to ensure that it represents a single business policy so that its metadata, when valued, is unambiguous. Each table should have four categories of columns: Issue Thread: Status Codes and Begin and End Dates

4 Red Tables without Begin and End dates (#3 & 4)

No Assessment: While not many, some database tables are not supported by Begin and End dates. Mitigation: The tables that are missing Begin and End date columns need to be examined and if appropriate possess these columns: business data, metadata, relationship data, and uniqueness data. Especial consideration should be expended on those tables that contain more than one set of policy-based business data. Ideally, all such multi-policy tables should be factored into separate tables so that updating can be

3

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) both high quality and low risk. Issue Thread: Status Codes and Begin and End Dates

5 Red Surrogate keys versus Natural Keys (#5) No Assessment: None of the database tables have business-based database keys. That means that it will be very problematic to determine business data based uniqueness because of the lack of unique keys. This may make SEVIS II very computer-resource intensive if the only way to determine unique data is through full table scans. Mitigation: While surrogate keys are preferred because of their size and efficiency, they never substitute for supporting business-based data uniqueness. Every table should be examined to determine the strategy to ensure row uniqueness based on business data criteria. Once SEVIS I data is converted it may well be practical to iterate into the correct database columns for business-based unique keys. Issue Thread: Status Codes and Begin and End Dates; Unique Keys

6 Orange Date value setting basis. Business or Update? (#6 & 8)

Unknown Assessment: The basis for setting date values is not at all clear from any of the database column definitions. If the columns are to be business date based, there needs to be presentation layer data entry of this value. Mitigation: Issue Thread: Status Codes and Begin and End Dates

7 Red Primary & Foreign Key Referential Integrity and Actions (#9)

No Assessment: There are virtually no rationales and definitions for any of the relationships, which are a form of inter-table business rule, in the SEVIS II data model. Each relationship, which is based on a Primary-Foreign Key match, needs to be named and its process-basis purpose needs to be clearly defined. Mitigation: Each such relationship needs to be mapped back to each applicable use case to ensure completeness and to assess consistency. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

4

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 8 Orange Business Rules specification, non-

redundancy, binding, and effect. (#10) Unknown Assessment: The data model does not contain any identified business

rules other than Primary-Foreign keys. Mitigation: All the SEVIS II business rules, a form of data integrity constraint, need to be uniquely identified and sourced from the use cases that require them. Once identified and normalized across all of SEVIS II, the business rule processes need to be turned in to processes that are bound in the most appropriate layer of the SEVIS II environment. In some cases that will be the presentation layer, or the DBMS layer, or back-end application software layer. Regardless, there must be 100% uniformity and assurance that database modifications are complete, accurate, and consistent. Precise test cases need to be engineered to ensure that regardless of the binding or execution layer, the SEVIS II database environment remains 100% consistent across all its data creation, maintenance and deletion processes. Issue Thread: Business Rules; Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

9 Orange SEVIS I and SEVIS II Value Domain mappings (#11)

Unknown Assessment: The data fields from SEVIS I and SEVIS II are mapped, one to another. The state of the values mapping for restricted values fields is unknown and was not addressed by any of the data models. Mitigation: This must be definitively addressed and is part of the SEVIS I to SEVIS II data conversion process. See also the Reference Data whitepaper. Issue Thread: Reference Data, Parameters, and Value Domain Management

10 Red Subtyping rules in Physical Data Model. How known and enforced. (#12)

Yes Assessment: The subtype and super type tables no longer remain in the data model. Mitigation: None required. Issue Thread: Logical and Physical Data Model Design

11 Red Business Event history single table update (#14)

No Assessment: There are many (about 55) distinct Functional Requirements for business event tracking and history. The current

5

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) approach within these data models does not satisfactorily address the FRD requirements and the expressed requirements put forward by both the Department of State and the SEVP. Mitigation: The Business Event History white paper addresses this SEVIS II essential topic and a suggested database strategy for accomplishing business event history. Once this issue is finally resolved, there almost certainly will be changes to the data model and also to already developed software from Products 1, 2, 3, 4, and 6. The activity table needs to be replaced with an approach that mirrors the strategy contained in the Business Event History paper. SEVIS II software then needs to be modified to ensure that all SEVIS II transactions are set within context with each other. The strategy contained in the Business Event History paper requires the identification and interrelating of all business transactions. As the business transactions occur, the metadata about each transaction is captured and stored within the “actual” business transaction network of records. Taken together, this business event history approach will likely address the SEVIS II requirements that are cited in the FRD and set out in the Business Event History paper. See also the Business Event History white paper. If a strategy similar to the one set down in the Business Event History paper is not adopted it is unlikely that SEVIS II will properly record history. Issue Thread: Business Event History

12 Red Business Event history multiple table update (#14)

No Essentially this issue is a duplicate of one or more other issues. See Item #11. Issue Thread: Business Event History

13 Red Data Management Plan data element name conflicts with column names (#15)

No Assessment: Because there is no mapping from the use case data elements to the database tables, will be very problematic to resolve this issue. Mitigation: Once use case data element to database table column

6

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) mapping is complete, all the database column names need to be revisited to ensure that name are appropriate for all the use cases. Shortened names can always be created within the software environment through the use of SQL Views. It is often the case that once a database table column is fully defined, its name changes to better match the definition. See item 14. Issue Thread: Names and Definitions within Use Cases, Columns and Relationships

14 Orange Table and column technical versus business policy basis definitions (#16)

Partial Assessment: A review of the definitions associated with database table columns seem to be more technical than business based. Mitigation: Once there is a use case data element to database column mapping, and once the SEVIS II business community provides and/or revises the definitions to the use case data elements, the database table columns can and only then be properly defined. Once defined, the database table columns then need to be revisited to ensure correct names. See item 13. Issue Thread: Names and Definitions within Use Cases, Columns and Relationships

15 Red Expansion of Activity table to embrace full business event history (#17)

No Assessment: The approach present in the current data models cannot handle the full requirements for Business Event History. See also the Business Event History white paper. Mitigation: The activity table needs to be replaced with an approach that mirrors the strategy contained in the Business Event History paper. SEVIS II software then needs to be modified to ensure that all SEVIS II transactions are set within context with each other. The strategy contained in the Business Event History paper requires the identification and interrelating of all business transactions. As the business transactions occur, the metadata about each transaction is captured and stored within the “actual” business transaction network of records. Taken together, this business event history approach will likely address the SEVIS II requirements that are cited in the FRD and set out in the Business Event History paper.

7

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Business Event History

16 Red Inadequate treatment of statuses across multiple database table columns (#18)

No Assessment: Throughout the creation, review, and evolution of the use cases from Products 1, 2, 3, 4, 6, and 7 there has been an enumeration of valid values associated with a number of statuses. The use case data elements both have a variety of values and also precise status value sequencing. Mitigation: The use case data elements that address statuses need to be fully examined across all the uses cases and their status values and value interrelationships need to be identified and adjudicated across the entirety of the SEVIS II database in order to have an adequate treatment. Once accomplished there needs to be a formal change control process to manage the identification and management of status-based values. As each status value is created and/or updated, the appropriate quantity of metadata associated with that status needs to be identified, and if appropriate, also stored in the database record. Issue Thread: Status Codes and Begin and End Dates

17 Orange Business Rule execution effect binding in data model or business event history. (#19)

Unknown Assessment: Essentially this issue is a duplicate of one or more other issues. See item #8. Issue Thread: Business Event History; Business Rules

1.2. Specific Subject Area List

1.2.1. Exchange Program

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 18 Green Column names not appropriately

specialized for table (#3 & 4) Yes No comment necessary.

Issue Thread: Names and Definitions within Use Cases, Columns and Relationships

19 Green Code column names not specialized enough to understand code policy (#3 & 4)

Yes No comment necessary.

8

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Names and Definitions within Use Cases, Columns and Relationships

20 Green Ambiguous relationships starting at Exchange Visitor Program (#5)

Yes No comment necessary. Issue Thread: Logical and Physical Data Model Design

21 Green Insufficient sub-typed tables for Exchange Visitor Program (aviation) (#6)

Yes No comment necessary. Issue Thread: Reference Data, Parameters, and Value Domain Management

22 Red Inadequate value domain management for Program Series Code and Description (#8)

No Essentially this issue is a duplicate of one or more other issues. See Item #1. See also the Reference Data whitepaper. Issue Thread: Reference Data, Parameters, and Value Domain Management

23 Red Inadequate data structure for Organization. Should be network not hierarchical. (#9)

No Assessment: The data models have only one database table for all types of organizations: Organization. This table is hierarchical. Organization is to be the single table for all schools, school systems, exchange visitor sponsors, and any owner organizations. Mitigation: Hierarchically engineered organizations and schools are inappropriate for a number or reasons. First the table needs to be a network data structure in order to properly reflect history. A whitepaper has been written that addresses this very issue. Second, each organization type, that is, school systems, exchange visitor sponsors, and any owner organizations have different purposes and are related to each other for different reasons. Third, when any organization (of which ever type) is “sold” to a different organization (of which ever type), all the previous history moves with the sale. That would seem to be very inappropriate. These tables need to be re-engineered to be network structured and the SEVIS II software needs to be modified to properly process network structured data. The most critical element of the network structures is that the relationships from object to object (i.e., school or organization) proceeds from the network “assembly” table, not the “part” table.

9

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Reference Data, Parameters, and Value Domain Management

24 Orange Inadequate Primary & Foreign Keys among Organization, Person, and Country. (#10)

Partial Assessment: The primary key structure supported relationships among these three tables appear to be ambiguous. Mitigation: The tables need to be re-examined and possibly re-factored to ensure that is a proper set of all business policy-based relationships. It is almost always necessary for the subject matter experts to “walk-through” all the database tables including the relationship tables to ensure that all cases are addressed. Issue Thread: Logical and Physical Data Model Design

25 Orange Organization and Person are better linked to Address through a Linked-Role tables? (#11)

Partial Assessment: The primary key structure supported relationships among these three tables appear to be ambiguous. Mitigation: The tables need to be re-examined and possibly re-factored to ensure that is a proper set of all business policy-based relationships. It is almost always necessary for the subject matter experts to “walk-through” all the database tables including the relationship tables to ensure that all cases are addressed. Issue Thread: Logical and Physical Data Model Design

26 Red Possible missing of Linking tables? E.g., Address can have multiple communications methods. Actual location and USPS Address do not appear to be distinguished. (#12)

No Assessment: Mitigation: The linking tables that interrelate, for example, Address with other tables such as Person and Organization need to be examined to determine if all the relationships are in precise third normal form with respect to the linking-table once-removed parent. It is not clear as to whether a person’s address change doesn’t that automatically cause an organization’s address change. Issue Thread: Logical and Physical Data Model Design

27 Red Possible missing Location (Lat & Long) table? (#13)

No Assessment: It seems inappropriate for every address to be able to have a latitude and longitude.

10

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Mitigation: Some addresses are merely Post Office locations. It might seem that there should be a Location table to which addresses are related. A careful analysis needs to be undertaken to determine if a location table is needed. Issue Thread: Logical and Physical Data Model Design

28 Red Attachment table possible ambiguity (#14) No Assessment: The attachment table is likely to be associated with either an I-17 or a DS-3036. There are other similar tables such as school instruction type, calendar, session, accreditation, and the like. All of these tables are associated with organization, whether it is a school, school system, group, or an exchange visitor organization. Missing is any notion of an application that has its own metadata (who, what, when, where, why, and how) and then an associated set of dependent tables and data associated with an application (I-17 or DS-30306) instance. Mitigation: The database tables properly related to an application (I-17 or DS-30306) should be defined within the context of an application which is then associated with an organization. If this is done, an application and all its associated data can be traced through its iterations. See Item 29. Issue Thread: Logical and Physical Data Model Design

29 Red Application table. Progressions and regressions do not seem to be easily determined through data model engineering. (#15)

No Assessment: The formal table, Application, is not in the data model. There does not seem to be a unified way to trace among all the data associated with a given iteration of an application for the I-17 or the DS-3036. See Item 28. Mitigation: There seems to be a real need for an Application table that is to contain the data associated with an I-17, and/or a DS-3036. Without an application table it will be very difficult to track all the data associated with a given I-17, and/or a DS-3036 through its iterations within one overall iteration and then over time for subsequent iterations. Issue Thread: Business Event History; Logical and Physical Data

11

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Model Design

30 Red Application table. Can an attachment be associated with multiple parts of an application? (#16)

No Assessment: There seems to be the ability to connect any given attachment with an organization without it being specifically identified as to what part of an I-17 or DS-3036 is its parent. There are a number of different attachments that can be associated with an I-17, and/or a DS-3036. Mitigation: If an application table is created within the SEVIS II database then attachments can be properly associated with its host table and in turn with the specific application. Issue Thread: Business Event History; Logical and Physical Data Model Design

31 Red Possible inability to materialize an application across time. Where is the permanent business data and permanent metadata that causes the application’s creation? PDF generated? With what supporting metadata? (#17).

No Assessment: The processes necessary to materialize an application for an I-17, and/or a DS-3036 seems very problematic and computer resource intensive. Mitigation: An application table needs to be created so that all the business data associated with a given application can be materialized. Given that an application table row is associated with its Business History actual data table, all the application related record’s metadata will also be created and stored in the Business History actual data table. This will enable analysis of not only an entire application but also the metadata (who, what, when, where, why, and how) of each data record associated with the application. Included too would be any SEVPAMS acceptance or rejection of any reviewed or adjudicated data field value. Issue Thread: Business Event History; Logical and Physical Data Model Design

1.2.2. System Administration Users

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s)

32 Red Inadequate tracking of Business Event No Essentially this issue is a duplicate of one or more other issues. See

12

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) History (#2 & 5) item #11

Issue Thread: Business Event History

33 Orange Missing rules for User Account Role (#3) Unknown Assessment: The rules through which this could be assessed were not integrated with the use cases except as inferred through the identification of the Actors within each use case. Mitigation: The full set of business transactions for SEVIS II need to be identified and the roles associated with each of these business transactions with respect to a user account need to be set out. Provided then must be the strategy for defining, installing, and processing these user account role rules. Are they to all be data-centric or software centric? It is not clear where the database tables are for these rules, how the rules are loaded, accessed by end-user software and ultimately maintained. At this point the adequacy of the use case, rules, and software can be assessed. Issue Thread: Business Event History

34 Green How is a user prohibited from belonging to multiple organizations (#4)

Yes Assessment: No comment necessary. Issue Thread: Reference Data, Parameters, and Value Domain Management

35 Red User Account Role management. Where are the rules and processes (#5)

Unknown Assessment: There is insufficient information to understand how user account roles are incorporated and processed within SEVIS II. Mitigation: The key question is whether the user account roles, rules governing the roles and the processes that support acceptance, rejection and any supporting end-user messages are to be fundamentally application code level or is it data driven through intersected lists of business event transactions, users classes, and permission lists. The former will process faster but the later will be far more maintainable. Issue Thread: Reference Data, Parameters, and Value Domain Management

13

1.2.3. Payment

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 36 Orange How are partial or over payments handled?

(#3) Unknown Assessment: There do not appear to be any database columns that

would support the retention of any excess payments. Mitigation: The data model does not appear to handle this situation at all. There are no data structures that associate payment received transaction information with account receivable information. A thorough analysis of these needs to be done and the use cases implied processes need to be matched against the data model structures so that there is closure on this question. Issue Thread: Logical and Physical Data Model Design

37 Orange How are payment activities recorded in Business Event History? (#4)

Unknown Assessment: The payments database table is not directly associated with a particular I-17 or DS-3036. Rather it is associated with a request and it, in turn is associated with an Organization. Thus associating any particular payment transaction with an application will likely require complicated processes and possible “flags.” Mitigation: As with Item 36, there does not seem to be any supporting structures in the data model that will support the capture of the necessary and sufficient accounts receivable and funds received information to record business event history. Without this history there cannot be any trends analysis, or business intelligence information generated to support management reports. Consequently, the implementation of the Business Event History approach continues to be essential to the success of SEVIS II. Issue Thread: Business Event History; Logical and Physical Data Model Design

38 Orange How are large payments allocated to multiple organizations or people? (#4)

Unknown Assessment: There do not appear to be any database tables and/or columns that would support the allocation of large payments to multiple organizations (that is, schools, school systems, exchange visitor sponsors, and any owner organizations).

14

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Mitigation: As with items 36 and 37, there does not appear to be any data model support for the receipt and allocation of payments to multiple organizations, schools, and exchange visitor sponsors. Key questions exist about what to do with excess payments? How are these accounted for in the database models? Are refunds provided, and the like? Use cases, coupled with data model revisions need to address all these issues in a coordinated and integrated fashion. Issue Thread: Logical and Physical Data Model Design

1.2.4. School


39 Red All the different complexities among schools groups and organizations appear too complex to be handled by just the Organization and School tables. Are there missing tables and relationships? (#3)

No Assessment: There is fundamentally only one data structure for all classes of organizations. The database tables are not properly engineered for several reasons. First there appears to be different columns for each class of organization. That is, for an exchange visitor, school, and school system. Second, the relationship among all classes of organization is purely hierarchical rather than network. Network structures are needed to support longitudinal history analysis of an exchange visitor, school, and school system regardless of ownership. Third, the reallocation of a school from one owner to the next will then either cause the need for data redundancy to keep historical data correct or will cause the implied transference of data from a previous owner to a new owner. Mitigation: there needs to be a thorough examination of all the data elements associated with each class of organization. After a through policy analysis surrounding all the different classes of organizations including the exposition of a very precise third normal form data model, it will be likely that there will be a need to split Schools, Groups, and Organizations into separate table structures so that there can be a clear enumeration of the appropriate set of business columns for each. This will enable the identification of the proper set

15


of relationships that must exist within and across these three collections. It is recommended that at least schools and organizations be re-cast into network data structures so that there can be a proper recording of business event history across time regardless of which organization belongs to whom. See also items #11 and #23. See also the Business Event History white paper. Issue Thread: Business Event History; Logical and Physical Data Model Design

2. May 2009 Data Management Plan Problems List

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 40 Red Traceability from every Use Case data

element to a database table and column. Supported evidence from within use case steps of the mapping between the business data elements and the database table and columns. (DMP Comment #5, 18 & 19)

No Assessment: An examination of FRD requirements, discussions at requirements meetings, use cases, wireframes, and materials from the System Requirements document and the System Design document shows no explicit interrelationships at a sufficient level of detail among these SEVIS II requirements and design components. Without interrelationships at a sufficient level of detail, SEVIS II’s requirements, design, and implementation cannot be certified. The missing tracings include use case data elements to the use case steps, and business rules to both use case steps and use case data elements. Missing as well are tracings from use case artifacts to database tables and columns. Missing too are tracings from database tables and columns to software designs and to test cases. Mitigation: The materialized of traced artifacts, identified minimally within the Assessment above, at an explicit level of detail to ensure unambiguous interrelationships is absolutely essential for a project the size and complexity of SEVIS II. Without the ability to independently validate the proper allocation of use case data elements to use case steps and then from the various use case step based data elements to the various database tables and columns, and then from the database tables and columns to software designs and

16

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) test cases makes the SEVIS II database tables close to impossible to certify conformance to the business requirements. Many of the use case processes and their implied use case data elements will cause the creation of relationship table records. These relationship table rows are not explicitly identified in the use cases. This makes certification of business-based requirements incorporation within the data models doubly difficult. What is two times “close to impossible?” Worse still, if there are no trace artifacts from the database tables and columns to the wireframes, and from the wireframes to the software designs, and from the software designs to the software, and from the software to the test cases, and from the database tables and columns to the test cases, the ability to certify that the SEVIS II database models, software, and test cases becomes close to “nil.” While the lack of explicit tracing is not present through trace-centric documents, the individual artifact documents of the use cases and database tables and columns are able to be loaded into sophisticated metadata management system and materialized tracings hypothesized. Once hypothesized tracings are materialized, they could be quickly reviewed by the various Booz Allen Hamilton requirement and data management teams. Misunderstandings and errors could be quickly uncovered and fixed. It is highly likely that such independently accomplished tracings will surface a number of issues that were not thoroughly addressed during the requirements analysis and design activities. Without the use of a sophisticated metadata management system the creation, validation, and correction of the tracings would be extraordinarily laborious and error prone. Evolution and maintenance of hand-accomplished trace documents would be very tedious and subject to inadvertent errors.

17

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: End to End Mapping and Traceability

41 Red Clear mappings between the use case business rule’s employment of business data elements and database table columns. (DMP Comment #13)

No Essentially this issue is a duplicate of one or more other issues. See Item 40 Issue Thread: End to End Mapping and Traceability

42 Orange Specifications of data management constraints dealing with valid value constraints within the use cases steps and the ability to represent these valid values in the reference data tables of the data model (#13).

Unknown Assessment: There are close to zero data management integrity constraints, a form of SEVIS II business rule, in the data models. thus, missing are column and table constraints, and also missing are before and after triggers contribute to, enforce, and maintain long-term database integrity. While a number of these constraints are specified in the use cases, there is zero visibility into the data models and/or software implementations as to how or if these use-case data management constraint business rules are being implemented. Clearly missing is any sophisticated treatment of reference data within the data models. See also the Reference Data whitepaper. Mitigation:. A formal approach has to be developed to identify integrity constraints in a unified manner and to determine the most efficient and effective manner by which these integrity constraints are implemented. Alternatives include column and table constraints, table-based before and after stored procedures, view-based integrity clauses, and finally, application software based processes. Data Management integrity constraints are almost always based on reference and/or parameter based data. Not only must all value domains be identified and characterized appropriately through their different Reference Data Cases, all the different reference data values especially as these values proceed from one value state to the next need to be surfaced, as these are critical integrity constraints in the database Once this strategy is formally defined a comprehensive assessment can be conducted against the data model, the various use cases, and the SEVIS II application software designs to determine the most efficient and effective manner of accomplishing the highest level of SEVIS II database integrity and quality.

18

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Business Rules; Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; Reference Data, Parameters, and Value Domain Management.

43 Red Adequate representation of data management constraints dealing with Null and Not Null given the business data elements from the use cases. (DMP Comment #13)

No Assessment: There is a significant discrepancy between the use case based specifications of “Required” with respect to a use case data value and the representation of that “Required” statement in the database table columns. A quick check of the database table columns showed that a large number were classified as “Null allowed” versus “Null Not Allowed.” This significant discrepancy needs to be resolved by making many more of the database table columns “Null Not Allowed.” Mitigation: Once there is a thorough mapping between use case data elements and database table columns, there can be a comparative assessment of this critical database quality and integrity issue. It will be critical to discover any policy conflicts between one use case’s indication that a column’s value is optional and another indicating that the column’s value is mandatory. The use of a metadata management system that enables the reporting of use case steps by database table column will be very important during this analysis. Once the database’s table columns are properly revised to reflect Null or NotNull, the use cases and downstream application software can be assessed to ensure that the appropriate error messages are surfaced. If not, then both design and implementation remediation will be required. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

44 Red Adequate representation of data management constraints dealing with Unique Keys of natural data columns within the database tables. (DMP Comment #13)

No Assessment: There are no natural keys in the data models. This is very contrary to best practice for a number of reasons. First it will be very difficult to determine whether business data is truly unique without full table scans. Such scans will have to be built into the application software versus letting the DBMS accomplish this task

19

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) through the use of Unique Key constraints. Complicating the creation of natural keys is the existence of multiple policy-based tables. Which set of policy-based columns govern uniqueness of a given row? Of great concern is batch processing. Assuming that much of the batch processing supply data through XML data-based streams, it will be resource intensive on the part of SEVIS II to determine if XML engineered data submitted through batch is new or duplicate. Again full table scans will be required and such scans will have to be built into the application software versus letting the DBMS accomplish this task. Mitigation: Every database table needs to be examined to ensure there can be a set of columns that when their values are taken together within a “Where clause” only one data row from a database table is selected. Database tables need to be in third normal form in both the logical and physical models. If not, a high level of database quality and integrity will not be achieved especially in the area of update. The only basis for having a non-normal form table in the SEVIS II data model is that all strategies to achieve acceptable retrieval and update performance have failed. Because the SEVIS II DBMS is Oracle 11g, and because Oracle 11g has very sophisticated physical database tuning capabilities, the need to have non-normal form tables seldom ever occurs. The only commonly accepted reason for justifying non-third normal form tables is reporting. It is acceptable then to avoid extra I/O and SQL command processing and because in a specially constructed “reporting database” no updating, other than new data inserts occurs. It is possible that the identification of the unique keys will not be determinable until after the SEVIS I to SEVIS II data conversion effort.

20

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Unique Keys

45 Orange Adequate representation of data management constraints dealing with Referential Integrity and Action within the database tables. (DMP Comment #13)

No Assessment: The database models do not contain little to no justifying text for any referential integrity specifications and little to no justification text for any referential actions. The main concern here is not whether referential actions are specified because most are. It’s that there are no explanations of the meaning and impact of the referential actions. To fully understand the intentions of the existing referential actions implied by the referential integrity specifications, there should be clear business requirements specified within the use cases to support every referential integrity specification and action. Mitigation: Every referential integrity clause needs to be fully specified and the referential actions need to be fully defined. Each such definition needs to be interrelated with every use case that involves creation, modification or use and then be fully justified. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management

46 Orange Adequate mapping to the DoJ’s NIEM data model. (DMP Comment #15)

Unknown Assessment: There is no material on this item to make any assessment. Mitigation: There needs to be an acquisition of the DoJ’s NIEM data model and a thorough comparison across the following levels of precisions: 1) table names and definitions, 2) atomic and non-derived column names and definitions, 3)table row granularity, precision, and temporal qualities, 4) table key structures for both primary and unique, 5) All relationships (primary and foreign) along with all referential integrity statements and actions, 6) the complete value domain set for every reference data column that exists in the data model against both the enumerated data values, their meanings, and as appropriate, the sequencing from one value set to the next, 7) all data integrity clauses for table and column constraints, and table-based before and after stored procedures, and 8) any view based integrity clauses.

21

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Names and Definitions within Use Cases, Columns and Relationships; Conformance to ICE Data Modeling Standards

47 Red Adequate handling of reference data across all its natural six cases and for parameter and master data (DMP Comment #21)

No Assessment: An assessment of all the use cases from Products 1, 2, 3, 4, 6, and 7 (through September 23) were analyzed to identify three special types of use case data elements: reference data, parameter data, and master data. The use cases only partially identify all the different use case data elements that fall into these categories. There does not appear to be adequate treatment of these three use case data element type classes. There are no special processes identified for employing, creating sequencing, and maintaining reference, parameter and master data. It is well known best practice that each data classification requires special attention to ensure overall database integrity and quality. Mitigation: There needs to be a thorough review of the 100 page document that enumerates all the different Reference, Parameter, and Master data use case data elements to ensure that none are missing and all are correctly identified, named, and characterized by class. In regards just reference data, there are about 1,000 reference data elements (duplicates across use cases have not been removed) The Data models document enumerates only about 50. Not only must this great discrepancy be resolved, but there must be a very detailed, comprehensive and fully adjudicated set of project activities to specify and then install administrative and SEVIS II processes to create, interrelated and determine the proper processing of all reference data values. See the Reference Data white paper. See the 100 page document, Reference_ Master_Parameterized Data Identification_By Use Case. Issue Thread: Reference Data, Parameters, and Value Domain Management

48 Red Database-centric inter-relationships section No Assessment: There is close to zero explanation of the very many

22

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) of the DMP within the data model is missing. (DMP Comment #22)

relationships (Primary to Foreign Key) relationships in the SEVIS II data models. Some of the relationships are represented through formally defined relationship tables. It does not seem at all clear from the data models that the business basis for the relationship will be properly captured. Additionally, virtually none of the relationships are named or defined. Finally there is essentially no documentation that explains how or under what conditions relationships among database tables are created. Mitigation: Every relationship that exists within the SEVIS II data model needs to be formally named in both an active and passive tense, and formally defined. Once this is completed and armed with complete use case data element to database table column mappings, the use cases can be examined to ensure that there is the necessary and sufficient set of relationships (primary to foreign keys) specified in the data model. Supporting each relationship must be a formal set of defined business conditions that supports the existence of the relationship. Defined as well needs to be the referential actions supporting each relationship. Once all this is accomplished it must be reviewed by the SEVIS II business owners and subject matter experts. Issue Thread: Names and Definitions within Use Cases, Columns and Relationships; Conformance to ICE Data Modeling Standards

49 Red The data model Business Rules set out as column constraints, assertions, triggers, and stored procedures is missing. (DMP Comment #23)

No Assessment: There are no documents that address how business rules are being captured from the use cases, how they are integrated one with another, duplicates identified and eliminated, and conflicts identified and resolved. There also are no documents that identify how or if business rules are accomplished through database table based constraints, before and after stored procedures, presentation layer software, or server side business process software. There are no documents that indentify business rules across SEVIS II in any unified manner nor are there any mappings between a unified set of business rules to use cases, use case steps, and use case data elements.

23

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Mitigation: There needs to be a unified approach to business rule identification, definition, and application across all of SEVIS II. That includes both the data models and all SEVIS II application software. There needs to be a clear approach to the business rule issue, because without it, it is very likely that SEVIS II’s treatment of business rules will be very difficult to verify against business requirements, and will very likely be accomplished in a non-uniform manner across SEVIS II’s execution. Test cases need to identify the specific business rules that are being tested. Given the existence of a metadata management system, all business rules by test case and all test cases by business rules can be assessed for uniform application. IF SEVIS II user acceptance testing is to be successful, these mitigations must be in place and be employed during user acceptance test construction. Without these mitigations, user acceptance testing will take a very long time at the very best or will be impossible at the worst. Issue Thread: Business Rules

50 Red The Unique Keys for the database tables is missing. (DMP Comment #24)

No Essentially this issue is a duplicate of one or more other issues. See item #5 and 44. Issue Thread: Unique Keys

51 Red The data structures that adequately handle History are missing. (DMP Comment #25)

No Assessment: Essentially this issue is a duplicate of one or more other issues. See item #11. Issue Thread: Business Event History

52 Red The data structures that support Business Transaction Management is accomplished are missing. (DMP Comment #26)

No Assessment: Essentially this issue is a duplicate of one or more other issues. See item #11. Issue Thread: Business Event History

53 Red The section that sets [out] Business Data Configuration Management. (DMP

No Assessment: An analysis of the database tables in the SEVIS II data models show that some tables have multiple purposes but there are

24

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Comment #27) only one set of supporting metadata columns. This compromises the

integrity and the quality of the database table with respect to updating and reporting especially because in some of these tables there is only one set of begin-and-end dates and/or status codes. That makes it difficult to determine which policy is applicable to which begin-and-end dates and/or status codes. Mitigation: Database tables that conform to best practice design strategies only have one very precise business purpose. This strategy is sometimes called “Third normal form” design. Each database table needs to be examined to determine if it is single-purpose or “third normal form” and for those that are not, there can be two strategies. First, redesign the table to be in third normal form, or two, ensure that there is a sufficient quantity of metadata columns for each distinct purpose. For the purposes of database integrity and quality the first strategy conforms to best practice. Issue Thread: Logical and Physical Data Model Design; Status Codes and Begin and End Dates

54 Red There is an excessive use of Nulls especially given the business data elements specifications in the Use Cases. (DMP Comment #28)

No Essentially this issue is a duplicate of one or more other issues. See item #43. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

55 Green The referential actions for all the relationships appear to be missing from the data model. (DMP Comment #29)

Yes Assessment: This item appears to have been “mechanically” addressed. However, the bigger issues identified in item #45 and #48 needs to be addressed. Mitigation: Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

25

3. May 2009 IV&V Report Data Management Section Problems List


56 Red Data Model Adequacy. Check for comprehensive traceability between the use cases and the data model’s tables and columns. (DM IVV Section Comment #1)

No Essentially this issue is a duplicate of one or more other issues. See item #40. Issue Thread: End to End Mapping and Traceability

57 Red Consistent capture and mapping between business data elements for comments within use cases and forms and the database table columns. (DM IVV Section Comment #3)

No Assessment: The presentation of requirements during the meetings seemed to have inconsistent strategies for identifying whether comments are to be captured on a per business data field basis, per business form and/or per section of a business form. There does not seem to be unified policy that governs this issue. Mitigation: It is recommended that an examination be made to determine if there are different approaches across the use cases, and if these different approaches are based on requirements or a difference in evolving styles of comment capture. Examined also should be if it is possible to change previously recorded comments. Finally examined should be whether comments can be categorized so that they can be quickly discovered across the SEVIS II database. If the policy appears to be unevenly applied then the data models, use cases, wireframes, and already built and in-development software needs to be assessed to determine if modifications are required. Issue Thread: End to End Mapping and Traceability; Reference Data, Parameters, and Value Domain Management

58 Red Adequate data structures for status recording and status change management. (DM IVV Section Comment #5)

No Essentially this issue is a duplicate of one or more other issues. Issue Thread: Status Codes and Begin and End Dates

59 Orange Adequate employment of SQL views for proper use of business rules that are use case based versus table based. (DM IVV

Unknown Assessment: There have been no documents and/or strategy put forward that indicated if or how SQL Views are to be employed to support business rules, and various other integrity constraints.

26


Section Comment #6) Mitigation: SQL views are important in applications like SEVIS II for a number of reasons. First because complicated select clauses can be off-loaded to the server for processing, elaborate data integrity specifications can be defined within the View and thus removed from the application program, and finally because many database design changes can occur without then having to change the application program layers. Since there has been no visibility into the software structuring environment, it is not know how many, if any, of these benefits are being achieved through other means. If none or a few, the use of SQL Views is greatly encouraged. If there is no SEVIS II policy regarding views, one should be created and collections of views should be created that enable layered enforcement of business rules, the deployment of row-based security, and the implementation of server side complex-join and Where clauses. Issue Thread: Business Rules

60 Red Appropriate data structures to support history. (DM IVV Section Comment #11)

No Essentially this issue is a duplicate of one or more other issues. See item #11. Issue Thread: Business Event History

61 Red Appropriate data structures to support business event management. (DM IVV Section Comment #12)

No Essentially this issue is a duplicate of one or more other issues. See items #11. Issue Thread: Business Event History

62 Red Adequate support for value domain management. (DM IVV Section Comment #14)

No Essentially this issue is a duplicate of one or more other issues. See items # 1. Issue Thread: Reference Data, Parameters, and Value Domain Management

63 Orange Adequate data structures to support SEVIS Unknown Assessment: There have been no documents, white papers or

27


II reporting. (DM IVV Section Comment #15)

strategies produced that clearly indicate the direction for the engineering, populating, or maintaining a separate reporting database. Mitigation: There needs to be a comprehensive reporting database strategy document created that fully explains the process of data extraction from the SEVIS II on-line database. Topics covered should be whether the reporting database is to be a traditional “E-R” database or is to be a ”Star Schema” engineered database. Of especial concern is the frequency of data extraction from the main database. What load will the impose, how frequently, and the like. Issue Thread: Logical and Physical Data Model Design

64 Red Adequate inclusion of column and table constraints, before and after triggers and stored procedures. (DM IVV Section Comment #18)

No Essentially this issue is a duplicate of one or more other issues. See item #7. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

4. July – July 2009 Business Event History

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 65 Red Determine whether there are sufficient

network data structures within the data models to both record all the possible business event processes that can potentially take place.

No Essentially this issue is a duplicate of one or more other issues. See items #11. See also the Business Event History white paper. Issue Thread: Business Event History

66 Red Assess the sufficiency of the database table columns to support these data structures.

No Essentially this issue is a duplicate of one or more other issues. See items #11. See also the Business Event History white paper. Issue Thread: Business Event History

67 Red Assess whether there are supporting use cases and/or wireframes to populate these all potential business event data structures.

No Assessment: It is very clear from the use cases that Business event history is not being addressed in the majority of the use cases. Some use cases from Product 7 have identified the requirements related to

28

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) the retention of history. An examination of the use cases from Product 6 showed a great discrepancy between the requirements relevant to history and the requirements identified by the Development Contractor. The identification of Business Event History requirements and the allocation of them to use cases are contained in the Business Event History white paper. See also the Business Event History white paper. Mitigation: Once a clear policy exists for the complete and comprehensive capture of business event history as suggested in the Business Event History white paper, all the use cases starting with Product 1 need to be revisited and possibly revised. Once revised they need to be reviewed in unison to ensure that there is a consistent, repeatable, and reliable capture of both Business Event History and business data history. Once that is done, the data model for SEVIS II can be reviewed to ensure that the right data structures exist. Thereafter, the design of all the software modules can be reviewed to ensure that they are properly configured and developed. Finally, any development and user acceptance tests need to be revisited to ensure comprehensiveness and correctness. Issue Thread: Business Event History

68 Red Determine whether there are sufficient network data structures within the data models to both record the business event processes that actually take place.

No Assessment: The network data structures do not exist in two different classes. The first missing class relates to those for School and Organization. Without these, it will be very difficult to track schools and organizations across time without duplicating existing data. The data model exists today as hierarchies for schools and organizations. This prevents a school or organization from being seen from within the context of multiple owners across time. Under the current data models, all the history of people, programs, and the like associated with a given school will be “transferred” with that school when or if that school is “sold/conveyed” from one organization to another. It will be as if all the school related data occurred under the purview of the school’s organization owner. This might lead to false reporting statistics and false inferences and/or conclusions.

29

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) The second missing class relates to the business events themselves. The only data structure in the database that can attempt to capture “activities” is the single table, Activity. This table is hierarchically organized and has only two business related tables associated with it: Person and Organization. Mitigation: The resolution to this issue requires the creation of two interrelated network data structures. The first records all possible business events that can happen, and the second records the actual business events that did happen. The actual business events are related to the possible business events so that report can be produced that compare the actual with the possible. The actual business events are then related to the actual business data that was caused to be created and/or modified through the execution of the actual business events. Without these two network related data structures, the business requirements set out in the FRD and through discussions that occurred during requirements meetings cannot be fulfilled. See also the Business Event History white paper. Issue Thread: Business Event History

69 Red Assess the sufficiency of the database table columns to support these data structures.

No Assessment: Given that the database tables do not exist, clearly the columns do not exist. See also the Business Event History white paper. Mitigation: Once the data structures exist to properly capture business event data, the proper set of database columns have to be engineered to completely capture all the potential and actual business events. Issue Thread: Business Event History

70 Red Assess whether there are supporting use cases and/or wireframes to populate these actual business event data structures.

No Assessment: The majority of the use cases do not accurately reflect the set of Business Event History. See also the Business Event History white paper. Mitigation: All the use cases starting with Product 1 need to be

30

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) examined to determine if there is sufficient use case steps to properly characterize the capturing of Business Event History. Once the use case modifications are captures and reviewed across all of SEVIS II, then the software necessary to properly capture network structured data can be designed, implemented and testing. The software to properly create network structured data is quite different than just hierarchically structure data. Very careful engineering and testing needs to be accomplished before this class of software can be put into production status. Not only will there have to be specially constructed insert, modification and deletion software, there will also have to be highly engineered display software. Finally, the reporting software will have to be configured quite differently from standard hierarchy based software. Issue Thread: Business Event History

71 Red Determine whether there is a proper set of database relationships between the potential business events to actual business events to actual data.

No Assessment: Given that the database tables do not exist, clearly the relationships among these tables do not exist. See also the Business Event History white paper. Mitigation: The relationships that exist among network structured data are different than hierarchically structured data. These relationships have to be specially designed and implemented. Issue Thread: Business Event History

5. June - July 2009 Reference Data

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 72 Red Determine the data model adequacy for

each of the six reference data cases. No Assessment: The current data model only supports Case 1 of the six

types of Reference Data Cases. The six cases are: 1) Single Content Column, 2) Multiple Content Column, 3) Sequenced [columns], 4) Mapped Values [from one instance to another], 5) Discrete Values [both allowed and disallowed], and 6) Range Of Values [both allowed and disallowed]. Despite the existence of Classes 2 and 3, the data

31

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) model can only handle class 1. Classes 4, 5, and 6 can also have single or multiple columns, and mapped values subclasses. Class 4 will likely be present in virtually all the SEVIS II interfaces to other systems. Missing in addition to the data model structures to support these six classes are the policies, procedures, guidelines necessary for the proper adjudication of reference data across the entirety of the SEVIS II project. In addition to these six classes of Reference Data, there is also Master Data columns. Master Data is characterized as data that requires special attention before it is updated. Within SEVIS II this class of data can be seen as “Reviewed” or “Adjudicated” data. There are about 250 Master Data use case data elements. Duplicate Master Data Elements across contained in different use cases are included in this count. Finally, there are also parameterized data within SEVIS II so that it can be characterized as “data driven” and flexible. Both Master Data and Parameter Data can have multiple classes as can Reference Data. There are about 750 Parameter Data use case data elements. Duplicate Parameter Data Elements across contained in different use cases are included in this count. If the proposed changes in values are not accepted, the former values are not only restored but the new values cannot be employed unless and until they have been properly “Reviewed” and “Adjudicated.” Collectively, the proper treatment of Reference Data will require the addition of about 10 tables. A number of tables will be needed to handle the six classes, and the remaining tables will be needed to handle the review and adjudication of the reference data values and their mappings. See also the Reference Data whitepaper, and the 100 page Reference_ Master_Parameterized Data Identification_By Use

32

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Case paper. Mitigation: The current set of database tables structures needed to support all six cases of Reference Data and Parameter Data need to be created within the SEVIS II data model. Issue Thread: Reference Data, Parameters, and Value Domain Management

73 Red Determine whether all the reference data columns are properly identified in the data models.

No Assessment: Given that the database tables do not exist, clearly the columns do not exist. See also the Reference Data whitepaper, and the 100 page Reference_ Master_Parameterized Data Identification_By Use Case paper. Mitigation: Once all the data structures are identified, engineered, and exist, there proper set of database table columns need to be created. Issue Thread: Reference Data, Parameters, and Value Domain Management

74 Red Determine if there is appropriate referential integrity and referential actions in support of reference data employment.

No Assessment: Given that the database tables do not exist, clearly the referential integrity and referential actions in support of reference data employment do not exist. See also the Reference Data whitepaper, and the 100 page Reference_ Master_Parameterized Data Identification_By Use Case paper. Mitigation: Once all the database columns are created to support Reference Data, what is needed is all the relationships including referential integrity needs to be engineered. Created as well need to be the supporting policies, procedures, and supporting software to create and maintain all the reference data. Issue Thread: Reference Data, Parameters, and Value Domain Management

33

6. June - July 2009 Parameters

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 75 Red Determine the data model adequacy for

each business data element within a use case that could well be a parameter data value.

No Assessment: A very large majority of the parameter-based use case data elements are not directly identified within the use cases. They were however explicitly implied by the use case text. Parameter-based use case data elements are intended to provide SEVIS II its data-centric and flexibility characteristics. The vast majority of the parameter-based data are Class 2 of Reference Data (Multiple columns). There are about 750 different Parameter-based use case data elements. Duplicates that exist in this count from across the use cases have not been removed. A significant quantity of these parameter-based use case data elements could be employed to support SEVIS II business rules. As the data model now exists, only Class 1 parameter data elements can be supported. See the 100 page Reference_ Master_Parameterized Data Identification_By Use Case paper. Mitigation: The mitigation strategy is essentially the same as contained in Item 72. Issue Thread: Business Rules; Reference Data, Parameters, and Value Domain Management

76 Red Determine if there is data model adequacy for parameterized data for in support of Case 1, 2, 4, 5, and 6 of Reference Data.

No Assessment: An examination of the paper on this subject indicates that there is a very large discrepancy between the use case explicitly identified parameter-based data and those inferred from the use cases. See the 100 page Reference_ Master_Parameterized Data Identification_By Use Case paper. Mitigation: The current set of database tables structures needed to support all the cases of Reference Data and Parameter Data need to be created within the SEVIS II data model. Once all the data structures are identified, engineered, and exist, there proper set of

34

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) database table columns need to be created. Once all the database columns are created to support Reference Data, what is needed is all the relationships including referential integrity needs to be engineered. Created as well need to be the supporting policies, procedures, and supporting software to create and maintain all the reference data. Issue Thread: Reference Data, Parameters, and Value Domain Management

7. DAMA Best Practice List (DM-BOK, First Edition, 2009)

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 77 Red Section 5.2.3.1 Analyze Information

Requirements (page 92). Ensure that all logical data model components are traced back to explicit user requirements.

No Essentially this issue is a duplicate of one or more other issues. See Item #40 Issue Thread: End to End Mapping and Traceability; Conformance to DAMA DM-BOK

78 Red Section 5.2.3.2.1 Entities. Ensure that every entity contains attributes that can answer as appropriate the entity metadata questions related to who, what, when, where, why, and how.

No Essentially this issue is a duplicate of one or more other issues. See Item #40. Issue Thread: End to End Mapping and Traceability; Conformance to DAMA DM-BOK

79 Red Section 5.2.3.3. Develop and Maintain Logical Data Models (page 96). Ensure that all components can map back to business rules that ensure data quality and requirements.

No Essentially this issue is a duplicate of one or more other issues. See items #40. Issue Thread: Business Rules; Conformance to DAMA DM-BOK; End to End Mapping

80 Orange Section 5.2.3.2.1 Attributes (page 98). Ensure that entity attributes are atomic.

Yes Assessment: Since counters are not included in this data model, all columns appear to be non-derived and atomic within the business scope of the SEVIS II database. Mitigation: The counters need to be included in the use cases so that there can be the proper identification of the database tables are to be their natural homes. There will then need to be an extensive

35

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) review and analysis to ensure that their values are initialized and subsequently maintained with reliability and repeatability. Of especial concern is the ability of SEVIS II to recreate counter values from history in the event of database auditing and/or failure. Every wireframe any downstream software that is either already created or under development needs to be analyzed to ensure that the counters are properly computed. It will be necessary to identify the appropriate set of business transactions that increment or decrement counters and ensure that sufficient counter update transactions are written to a log that will support counter recreation. Issue Thread: Logical and Physical Data Model Design; Conformance to DAMA DM-BOK

81 Red Section 5.2.3.2.1 Attributes (page 98). Ensure that entity attributes are clearly named to map to business requirements, and have definitions that are clear, accurate, and complete.

No Essentially this issue is a duplicate of one or more other issues. See items #13. Issue Thread: Names and Definitions within Use Cases, Columns and Relationships; End to End Mapping and Traceability; Conformance to DAMA DM-BOK

82 Red Section 5.2.3.3.2 Domains (page 98). Ensure that all attributes that have restricted value domains are defined properly within one or more of the six reference data types.

No Essentially this issue is a duplicate of one or more other issues. See items #1. Issue Thread: End to End Mapping and Traceability; Reference Data, Parameters, and Value Domain Management; Conformance to DAMA DM-BOK

83 Red Section 5.2.3.3.3 Keys (page 99). Ensure that all entities have a primary key that is based on business data attributes.

No Essentially this issue is a duplicate of one or more other issues. See item #5. Issue Thread: Unique Keys; Conformance to DAMA DM-BOK

84 Orange Section 5.2.3.4 Physical Data Model (page 99). Ensure that the schema, tables, and columns address proper names, data type, length, and nullability via requirements,

Yes Assessment: The only exception here is Nullability, adequate keys, and proper valid value domains. This is addressed in item 43. Mitigation: See Item 43.

36

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) default values and/or NOT NULL, adequate keys, proper valid value domains, proper sub and super typed tables.

Issue Thread: Conformance to DAMA DM-BOK; Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; Logical and Physical Data Model Design; Reference Data, Parameter Data, and value Domain Management; Unique Keys.

85 Orange Section 5.2.4.1 Physical Database Design (page 102). Ensure design meets performance requirements for add/delete/update, backup & recovery, security and authentication roles, physical database partitioning.

Unknown Assessment: There have been no papers, documents or performance simulations that can attest to the adequacy of the physical design in terms of add/delete/update, backup & recovery, security and authentication roles, physical database partitioning. Of especial concern is the lack of unique keys that will ensure single row access on the basis of business data values. This lack of performance simulations with computer generated data is of real concern. Mitigation: Once there has been a SEVIS I to SEVIS II conversion there will likely be sufficient data to perform realistic simulations of It is hoped that once there is a SEVIS I to SEVIS II conversion that these performance tests can be engineered and conducted. The work plan does not appear to have tasks for this, however. Issue Thread: Logical and Physical Data Model Design; Conformance to DAMA DM-BOK

86 Red Section 5.2.4.4 Design Data Integration Services (database transaction management) (page 111). Ensure that all use case based transactions are properly designed, supported by transaction framing, save points, and transaction rollback.

No Assessment: The only materials put forward in this regard related to database reconstruction in the event of database failure. There have been no materials presented related to database transaction lockout, contention, framing, and the like. Mitigation: Every use case has to be reviewed to determine the natural boundaries for database transactions. This can only be done once there is a clear, reviewed, and accepted mapping from the use case data elements to the database table columns. This is required so that every use case can be seen in terms of tables accessed, rows created, referenced rows created that require “upstream” primary key values for use as foreign key values. Analyzed as well will have to be batch processing as that should likely require the use of save points and long transaction framing. A key issue will be the

37

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) extent to which batch-like transaction processing will interfere with on-line transactions and with report extraction processing. When the specifics of these three types of processing is fully known then detailed mitigation strategies can put into place along with any necessary modifications to already developed or in-development software. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; Conformance to DAMA DM-BOK.

87 Red Section 5.2.5.2 Review Data Model and Database Design Quality (page 114). Ensure that logical model maps to business data requirements.

No Essentially this issue is a duplicate of one or more other issues. See Item 40. Issue Thread: End to End Mapping and Traceability; Conformance to DAMA DM-BOK

88 Red Section 5.2.5.2 Review Data Model and Database Design Quality (page 114). Ensure that names and definitions are clear, practical, consistent, and complementary. Naming standards have been consistently employed.

No Essentially this issue is a duplicate of one or more other issues. See Item #108. Issue Thread: Names and Definitions within Use Cases, Columns and Relationships; Conformance to DAMA DM-BOK

89 Red Section 5.2.5.2 Review Data Model and Database Design Quality (page 114). Ensure that the Conceptual and Logical Data Models have been validated against requirements.

No Essentially this issue is a duplicate of one or more other issues. See Item #40. Issue Thread: End to End Mapping and Traceability; Conformance to DAMA DM-BOK

90 Red Section 5.2.5.2.3 Data Model Validation (page 115). Do the models match requirements?

No Essentially this issue is a duplicate of one or more other issues. See Item #40. Issue Thread: End to End Mapping and Traceability

91 Red Section 5.2.5.2.3 Data Model Validation (page 115). Is there proper transaction management established to ensure integrity and consistency.

No Assessment: Essentially this issue is a duplicate of one or more other issues. See Item #86. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; Conformance to

38

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) DAMA DM-BOK.

92 Red Section 8.2 [Reference Data] Concepts and Activities (page 173). Maintain complete lists of valid values etc. and maintain all relationships among reference data values [to support the 6 or 7 reference data cases].

No Essentially this issue is a duplicate of one or more other issues. See items #1. Issue Thread: Reference Data, Parameters, and Value Domain Management; Conformance to DAMA DM-BOK

93 Red Section 8.2.1 Reference Data (page 174). Ensure that all the reference data that needs to be cross-referenced represent the same thing for the different sets. There needs to be master sets that related one reference data set to another.


94 Red Section 8.2.1 Reference Data (page 175). Ensure that all the reference data sets that are sequenced or hierarchies properly maintained in the database.


95 Red Section 8.2.1 Reference Data (page 176). Ensure that all the reference data sets are properly adjudicated and managed through accountable authorities.


96 Red Section 8.2.12 Manage Changes to Reference … Data (page 191). Ensure that all reference data is properly configuration managed and mapped to ensure that old reference data is properly mapped to changed reference data.


97 Red Section 8.3.1 [Reference Data Summary] Guiding Principals (page 192). Ensure that reference data is organization or enterprise not application or department.


98 Red Section 8.3.1 [Reference Data Summary] Guiding Principals (page 192). Ensure that reference data is properly governed through

No Essentially this issue is a duplicate of one or more other issues. See items #1.

39

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) stewards. Issue Thread: Reference Data, Parameters, and Value Domain

Management; Conformance to DAMA DM-BOK 99 Red Section 12.1 [Data Quality Management]

Introduction (page 292). Ensure that all data model components are related to business requirements, business rules, and high data integrity.

No Essentially this issue is a duplicate of one or more other issues. See items #40 Issue Thread: End to End Mapping and Traceability; Conformance to DAMA DM-BOK

100 Orange Section 12.2.2 Develop and Promote Data Quality Awareness (page 294). Ensure that data elements (a.k.a., database table columns) are synchronized across lines of business to provide clear, unambiguous definitions, value domains and data quality rules.

Unknown Assessment: While there have been discussions with interface system partners, there does not appear to have been any cross business data element dictionaries produced that provided comparative names, definitions, value domains, granularities, temporal synchronization, and precision assessments. Mitigation: Issue Thread: Conformance to ICE Data Modeling Standards; Conformance to DAMA DM-BOK

101 Orange Section 12.2.3 Define Data Quality Requirements (page 295). Ensure that all data errors are properly identified, categorized and surfaced to data providers.

Unknown Assessment: There have been no papers produced that identify the types and kinds of error messages produced. The apparent intention is to generate user interface errors immediately upon discovery and prior to database commit. That will likely be a real problem if the data is hierarchically organized across tables that require interleaving commits. Alternatively, there could be a shadow set of virtual database tables that could simulate database commits such that data errors could be surfaced to the users. At this point, however, error processing is generally unknown. It is expected that Batch interface through XML or equivalent processes will have a data scanning exercise prior to the capture and commitment of real data transactions. Again, there have been no papers produced that identify the types and kinds of error messages produced. It is similarly expected that the other external system interfaces will generate errors in a manner similar to that of the Batch interface. As above, there have been no papers produced that identify the types

40

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) and kinds of error messages produced. Mitigation: Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; Conformance to DAMA DM-BOK.

102 Orange Section 12.2.3 Define Data Quality Requirements (page 295). Ensure that all data errors are properly supported by data integrity based business rules.

Unknown Essentially this issue is a duplicate of one or more other issues. See Item 101. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; Conformance to DAMA DM-BOK.

103 Red Section 12.2.6 Define Data Quality Business Rules (page 300). Ensure that all data values are enforced to known value sets if restricted, conform to consensus definitions, adhere to established ranges, comply with data type and length formats, is valued or not valued according to rules, has consistency among value collections within columns of a table or across tables, matches established “golden” values

No Assessment: Virtually none of the use case data elements are classified as Reference Data, Master Data, or Parameter Data especially when compared with the nearly 1800 such data elements that are identified in the document: Reference_ Master_Parameterized Data Identification_By Use Case. Mitigation: Issue Thread: Business Rules; Conformance to DAMA DM-BOK; Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; Reference Data, Parameter, and Value Domain Management

104 Red Section 12.2.6 Define Data Quality Business Rules (page 300). Ensure that all rows are unique according to business-based rules.

No Essentially this issue is a duplicate of one or more other issues. See items #5, 44, and 50. Issue Thread: Business Rules

105 Red Section 12.2.10 Manage Data Quality Issues (page 303). Ensure that all data elements (a.k.a., database columns) are complete, structurally consistent, and reasonable.

No Assessment: That is impossible to determine as there are no mappings between the use case data elements and the database table columns. For the use case data elements that are able to be “logically” mapped, sometimes the names are relatively equivalent and other times the names are quite different. For example, the Organization table is to contain all schools. Thus Org_Name, and

41

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Org_Code would likely map to School Name and School Code. The data types are similarly different. In the use case, a School Code is 9 characters while in the Organization table the data type is VarChar(20). Mitigation: Issue Thread: Logical and Physical Data Model Design; Conformance to DAMA DM-BOK

106 Red Section 12.2.10 Manage Data Quality Issues (page 303). Ensure that all rows are complete, structurally consistent, semantically consistent, and reasonable.

No Assessment: This is impossible to certify as there is an overabundance of NULL [allowed] when the use case data elements indicate that the value is required. Similarly, it is impossible to know how business data rows are to be unique as there are no Unique Keys. All the table primary keys are Surrogate Keys. Mitigation: Unique Keys Issue Thread: Conformance to DAMA DM-BOK

107 Orange Section 12.2.10 Manage Data Quality Issues (page 303). Ensure that all coherent data collections are supported by aggregate measures (e.g., means, counts, and averages) that support correctness.

Unknown Essentially this issue is a duplicate of one or more other issues. See Item #80. Issue Thread: Logical and Physical Data Model Design; Conformance to DAMA DM-BOK

8. April – June 2009 Data Management IV&V Architecture and Concept of Operations Issues 8.1 Data Model Assessments 8.1.1 Common Data Model Assessment Steps

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 108 Orange Assess whether every logical or physical

data model that may be appropriate within the SEVIS II collection of logical or physical data models is properly defined

Unknown Assessment: For all intensive purposed, there is no significant difference in the SEVIS II logical and physical data models. Hence all assessments are made against the Physical Data Model.

42

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) through the use of DHS ICE data modeling standards.

No other logical or physical data models against which this comparison can be made are available. However, when this data model is compared to the ICE Data Modeling standards, Version 2.0, December 2008, the assessment is that it is marginally acceptable. No information has been provided to know whether any of the entity names conform to the ICE Enterprise Data Model given that there are ICE Enterprise Data Model entities with the same intent. Table names and definitions are reasonable but tend to be somewhat “physical” in nature rather than to map to SEVIS II requirements. An analogous comment applies to column names and definitions. While there are many relationships (Primary to Foreign Key) few are provided any business names and virtually none are provided any definitions. The data model conforms to the ICE Data Modeling standard for domains (a.k.a., Reference Data). However the ICE standard only considers Case 1 type of Reference Data. There are a number of different Reference Data Cases that exist within SEVIS II’s data models and that must be addressed to ensure data model completeness. For Domains ((a.k.a., Reference Data) See items #1, 2, 9, 22, 42, and 47. Mitigation: Issue Thread: Logical and Physical Data Model Design; Conformance to ICE Data Modeling Standards

1. Assess the adequacy of each logical or physical data model with respect to the Value Domain Management.


109 Orange Assess whether the set of value domains for every column is defined unambiguously, clearly, distinctly, and not-overlapping.

Unknown Assessment: There have been not sets of values provided for reference data outside that which are listed in the use cases. Hence it is impossible to assess this issue. From the assessment of use case data elements as recorded in the document: Reference_

43

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Master_Parameterized Data Identification_By Use Case, it would appear that this issue cannot be “green.” Mitigation: Issue Thread: Reference Data, Parameters, and Value Domain Management

110 Red Assess whether every column that is to have a restricted value domain is identified and is correctly addressed by the appropriate set of properly configured value domain management metadata.

No Assessment: An evaluation of the data model’s Domain table with an enumeration of the restricted value domain columns shows that there are about 50 such columns throughout the data models. The document, Reference_ Master_Parameterized Data Identification_By Use Case, identifies about 1,000 reference data elements (duplicates across use cases have not been removed) from across the use cases from Products 1, 2, 3, 4, 6, and 7 (through September 23). Mitigation: Issue Thread: Reference Data, Parameters, and Value Domain Management

111 Orange Assess that every column value domain does not semantically conflict with an attribute value domain.

Unknown Assessment: This is impossible to determine as there is not a comprehensive enumeration of the value domain values (a.k.a., reference data) within the logical data model versus what exists in the physical data model. Because there does not appear to be a single document in which the value domain values are centrally defined within SEVIS II, there are discrepancies across the use case data elements for the different use cases within the different products. Mitigation: Issue Thread: Reference Data, Parameters, and Value Domain Management

2. Assess the completeness of each logical or physical data model artifact


44

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 112 Orange Assess that all schemas are identified and

are properly constructed Unknown No SQL schemas are available to perform an assessment.

Mitigation: Issue Thread: SQL Schemas

113 Orange Assess that all tables within the schemas are identified and are properly constructed.

Unknown No SQL schema tables are available to assess. Mitigation: Issue Thread: SQL Schemas

114 Green Assess that all table super and subtypes are identified and are properly constructed.

Yes None remain in the data model. Issue Thread: Logical and Physical Data Model Design

115 Orange Assess that all columns are identified and are properly constructed.

Unknown No SQL schema table columns are available to assess. Mitigation: Issue Thread: Logical and Physical Data Model Design

116 Red Assess that appropriate columns are properly constrained by value domain assignments.

No Essentially this issue is a duplicate of one or more other issues. Issue Thread: Reference Data, Parameters, and Value Domain Management

117 Red Assess that all columns contain the appropriate integrity constraints that are supported by assertions and triggers

No It is unlikely that this could even be unknown as these are based on the physical data models. Mitigation: Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

118 Orange Assess that all stored procedures are properly identified, designed, coded and tested to meet integrity requirements.

Unknown Assessment: There are no materials that identify whether stored procedures are being employed in the SEVIS II data models. Mitigation: Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

45

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 119 Red Assess that all table relationships are

identified and are properly constructed. No Assessment: It is unlikely that this could be even unknown as these

are based on the physical data models. Mitigation: Names and Definitions within Use Cases, Columns and Relationships

120 Red Assess that the collections of table columns are sufficient to reflect the implied policy of the table.

No Assessment: It is unlikely that this could be even unknown as these are based on the physical data models which, in turn, are unmapped to the use case data elements. Mitigation: Issue Thread: Logical and Physical Data Model Design

121 Red Assess that the collection of table columns are sufficient for the table’s instance infrastructure.

No Assessment: There are no Unique Keys that have been constructed from business data table columns that enable an even “unknown” assessment. Mitigation: Issue Thread: Unique Keys

122 Red Assess that the collection of table columns are sufficient for history and for auditability.

No Assessment: It is unlikely that this could be even unknown as there are based on the physical data models which, in turn, are unmapped to the use case data elements. Mitigation: Issue Thread: Business Event History

2.1. Assess keys and relationships.


123 Green Assess whether primary key is a surrogate key or natural key.

Yes Assessment: All primary keys are surrogate keys. Thus there is no business policy basis for row instance uniqueness. Mitigation:

46

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Unique Keys

124 Red Assess that one and only one row is selected if a natural key

No Assessment: There are no Unique keys, thus, it is not possible for the DBMS to detect duplicate business-data based rows. Unless there is a central table row uniqueness process, this will have to be performed within each of the different presentation layer, batch interface, and external interface processes. If that is the case, this is very problematic. Mitigation: Issue Thread: Unique Keys

125 Red Assess that one and only one row of business data is selected if a surrogate key.

No Assessment: There are no Unique keys, thus, it is not possible for the DBMS to detect duplication business-data based rows. Mitigation: Issue Thread: Unique Keys

126 Red Assess whether there a unique constraint comprised of natural data if row uniqueness is enforced through a surrogate key.

No Assessment: There are no Unique keys, thus, it is not possible for the DBMS to detect duplication business-data based rows. Mitigation: Issue Thread: Unique Keys

127 Red Ensure that the specification of referential integrity and referential actions correctly matches the business requirements for data retention and deletion.

No Assessment: There is no mapping between the use case data elements and the database tables and column. Additionally, there is no concept of either an entity or a table within the use cases. Finally, there are no referential actions specified in any of the use cases that could be employed to assess this issue. Because there are such a large quantity of uses cases of varied levels of complexity it would seem unlikely that referential action uniformity exists in the data model as a consequence of any uniform definition across all the use cases. Mitigation:

47

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; End to End Mapping and Traceability

8.1.2 Logical Data Model Unique Assessment Steps

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 128 Green Assess the components of the logical data

model against ISO ANSI SQL 1992 Entry Level.

Yes Assessment: While the SQL is “Oracle” none of the critical SQL Data Definition Language syntax will likely be Oracle unique. Mitigation: Issue Thread: ISO/ANSI SQL Standards

8.1.3 Physical Data Model Unique Assessment Steps 1. Assess the SQL DDL Scripts


129 Orange Ensure that the SQL scripts for reference data match the value domain requirements

Unknown There are no SQL scripts through which this issue can be assessed. Issue Thread: SQL Schemas

130 Orange Ensure that the SQL scripts for security roles match the security requirements as it relates to the use cases, named user roles, organizations, and extent of permission to read, write, update, and select data.

Unknown Assessment: There are no SQL scripts through which this issue can be assessed. Mitigation: Issue Thread: SQL Schemas

131 Green Ensure that the SQL scripts for primary key sequence value specifications match the primary key requirements

Yes No comment is necessary. Issue Thread: SQL Schemas

132 Orange Ensure that the SQL scripts for tables, columns and appropriate key specifications

Unknown Assessment: There are no SQL scripts through which this issue can be assessed.

48

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) match the physical data model table requirements

Mitigation: Issue Thread: SQL Schemas

133 Orange Ensure that the SQL scripts for triggers and other stored procedures match the data integrity constraints

Unknown Assessment: There are no SQL scripts through which this issue can be assessed. Mitigation: Issue Thread: SQL Schemas

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 134 Orange Assess the components of the physical data

model against Oracle 11g but not to contain any SQL facility and/or syntax that exceeds ISO ANSI SQL 1992 Entry Level without a specific waver.

Unknown Assessment: There are no SQL scripts through which this issue can be assessed. Mitigation: Issue Thread: ISO/ANSI SQL Standards

8.2.1 Business Requirements Assessment

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 135 Red Assess whether all data related business

requirements are reflected in an appropriate logical or physical data model component.

No Essentially this issue is a duplicate of one or more other issues. See Item #40 Issue Thread: Business Event History; Business Rules; End to End Mapping and Traceability; Integrity Constraints, Referential Integrity, Transaction Management, and Error Management; Unique Key; Reference Data, Parameter, and Value Domain Management

136 Red Assess whether all logical or physical data models are reflected in one or more business requirements

No Essentially this issue is a duplicate of one or more other issues. See item 136.

49

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) Issue Thread: End to End Mapping and Traceability

8.2.2 Business Rules Assessment 1. Assess the adequacy of each logical or physical data model with respect to the business rules.


137 Red Assess whether the business rule implied logical and physical data model components within tables, columns, and assigned value domains have been identified and specified.

No Assessment: It is impossible to assess this issue as there are no materials that address whether and how business rules are to be accomplished in the SEVIS II database and/or software. It is unlikely that this issue could be even “unknown” given a lack of an approach and any implementation details that should have already existed from the design and implementation artifacts from Products 1, 2, 3, and 4. Mitigation: Issue Thread: Business Rules

138 Red Assess whether the business rule use of logical or physical data model tables, columns are appropriate with respect to data type, allowed operation, and if appropriate SQL functions.

No Essentially this issue is a duplicate of one or more other issues. See item 137. Issue Thread: Business Rules

139 Red Assess whether business rule stored procedure implementations are correctly engineered and result in unambiguous determinations and/or messages provided to the end user or up through the application system calling sequence.

No Essentially this issue is a duplicate of one or more other issues. See item 137. Issue Thread: Business Rules

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) 140 Orange Assess whether the collective set of

business rules is non redundant, integrated, No Essentially this issue is a duplicate of one or more other issues. See

item 137.

50

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) bound appropriately and non-conflicting across the logical and physical data models.

Issue Thread:

8.2.10 Use Cases Assessment 1. Assess the adequacy of each physical data model with respect to the use cases


141 Orange Assess whether every column from every table is addressed through an insert, update, or possibly delete by at least one component and/or section of a use case.

Unknown Assessment: Given that there are no tracings from the use case data elements to the database tables and columns, and give that there are no tracings from the database tables and columns to the system design and implementation artifacts, it is impossible to assess this issue. However, it is unlikely that this issue could be even “unknown” given a lack of an approach and any implementation details that should have already existed from the design and implementation artifacts from Products 1, 2, 3, and 4. Mitigation: Issue Thread: End to End Mapping and Traceability

142 Red Assess whether every value domain value for every restricted value domain column is properly addressed by one or more appropriate modules of a use case.

No Assessment: Given the very wide discrepancy between the count of reference data elements in the data model’s Domain table (about 50) and those identified through an analysis of the use cases (about 1,000 without duplicates removed), it is impossible to conclude that this issue has been resolved. Issue Thread: Reference Data, Parameters, and Value Domain Management

143 Orange Assess whether all data updates are able to be properly backed out as may be allowed by a use case.

Unknown Essentially this issue is a duplicate of one or more other issues. See Item 142. Issue Thread: Integrity Constraints, Referential Integrity, Transaction Management, and Error Management.

144 Red Assess whether all use case data elements No Given that there are no tracings from the use case data elements to

51

Id Criticality Issue Resolved Assessment and Recommended Mitigation(s) are properly accounted for within the data models including for example, any relationship tables that must also be affected.

the database tables and columns, and give that there are no tracings from the database tables and columns to the system design and implementation artifacts, it is impossible to assess this issue. Additionally, the database table columns that related to a number of the relationship-based tables are not identified in the use cases. Consequently the rules that govern the creation, modification and deletion of relationship-based data can only be inferred from the use cases. If there were use case data element to database table mappings, use case steps could be cross referenced to database tables. This would provide the ability to assess this issue. However, it is unlikely that this issue could be even “unknown” given a lack of an approach and any implementation details that should have already existed from the design and implementation artifacts from Products 1, 2, 3, and 4. Mitigation: Issue Thread: Logical and Physical Data Model Design

52

Data Model Evaluate Issue Topic threads Issue Id

Business Event History 11, 12, 15, 17, 32, 37, 39, 51, 52, 60, 61, 65, 66, 67, 68, 69, 70, 71, 122, Business Rules 07, 08, 17, 42, 43, 49, 59, 75, 79, 103, 104, 137, 138, 139 Conformance to DAMA DM-BOK (Data Management Association’s Data Management Book of Knowledge)

77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107

Conformance to ICE Data Modeling Standards 46, 48, 100, 108 End to End Mapping and Traceability 40, 41, 56, 57, 77, 78, 81, 82, 87, 89, 90, 99, 135, 136, 141 Integrity Constraints, Referential Integrity, Transaction Management, and Error Management

07, 08, 42, 43, 45, 54, 55, 64, 86, 91, 101, 102, 117, 118, 127, 143

ISO/ANSI SQL Standards 128, 134 Logical and Physical Data Model Design 10, 20, 24, 25, 27, 28, 29, 30, 31, 36, 37, 38, 39, 53, 63, 80, 84, 85, 105, 107, 108, 114,

115, 120, 144 Names and Definitions: Use Cases, Tables, Columns, & Relationships

13, 14, 18, 19, 46, 48, 81, 88, 119

Reference Data, Parameter, and Value Domain Management

01, 02, 09, 21, 22, 23, 26, 34, 35, 42, 47, 57, 62, 72, 73, 74, 75, 76, 82, 92, 93, 94, 95, 96, 97, 98, 109, 110, 111, 116, 142

SQL Schemas 112, 113, 129, 130, 131, 132, 133 Status Codes and Begin and End Dates 03, 04, 05, 06, 16, 58 Unique Key 05, 44, 50, 83, 106, 121, 123, 124, 125, 126

53

Issue Duplication

Category

Overall Percent

Non Duplicate Percent

Issues by Criticality and Counts

Category Counts Issue Id

Non Duplicate 72 57 Red 56 01, 02, 03, 04, 05, 07, 10, 11, 13, 15, 16, 22, 23, 26, 27, 28, 29, 30, 31, 35, 39, 40, 43, 44, 47, 48, 49, 53, 57, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 86, 103, 105, 106, 110, 117, 119, 120, 121, 122, 124, 125, 126, 127, 137, 142, 144

31 Orange – unknown

31 6, 8, 9, 14, 33, 36, 37, 38, 42, 45, 46, 59, 63, 80, 84, 85, 100, 101, 108, 109, 111, 112, 113, 115, 118, 129, 130, 132, 133, 134, 141

02 Orange – other

02 24, 25

10 Green 10 18, 19, 20, 21, 34, 55, 114, 123, 128 , 131 Duplicate 38 n/a Various

but not applicable

45 12, 17, 32, 41, 50, 51, 52, 54, 56, 58, 60, 61, 62, 64, 65, 66, 77, 78, 79, 81, 82, 83, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 102, 104, 107, 116, 135, 136, 138, 139, 140, 143

Total 144

Legend Red A “red” characterization means that there needs to be significant needed data model design changes also existing and

underdevelopment software changes for Products 1, 2, 3, 4, and 6. Orange Unknown

A “orange” with “unknown” characterization means the there was insufficient information to determine if the issue was resolved. In most cases, it is not whether the issue ends up “red” or “green’ but whether it is “red” or ‘orange.” In general, however, in all cases of “orange,” there will likely be data model design changes and also existing and underdevelopment software changes for Products 1, 2, 3, 4, and 6. A careful analysis is required to determine just how significant these needed changes are.

Orange Other

An “orange” a different a “partial” characterization means the there some mitigation of the issue.

Green The issue has been resolved.


A09 DMConcern_Reference Data_OPR Document_03


59

1

1. IV&V Observed Potential Risk Statement Currently, SEVIS II is designed to record content data. <define column wrt UC data elements> Certain of these content columns have predefined value sets that are expected to be enforced. These columns are called reference data and are identified in the data model diagrams as “green.” There are more than 15 functional requirements (FRD, Version 1.0, 2/15/08) that address reference data. Currently, SEVIS II is not implementing best practice about properly storing, managing, and evolve the data associated with several key reference data cases. Without a comprehensive and systematic treatment of reference data, SEVIS II will be more difficult to design, program, and to test. Initial operations may be problematic, and long term evolution and maintenance will be tedious and error prone.

2. Summary Observation Discussion

Based on our independent review, there are six reference data cases. These are set out in the table below. The June 2009 SEVIS II data model’s ability to handle these six cases is set out in column four along with brief impact statements.

Case Type Description Accommodated in June 2009 SEVIS II Data Model with Impact

1 Single Content Column

A single column of reference data such as a person’s Gender (e.g., female and male), Gender.

Yes, but adjudication data is missing from all the cases. It includes the “who, what, when, where, why, and how” the reference data was identified, established, agreed upon, and evolved by SEVP and the Department of State.

2 Multiple Content Column

Multiple columns that should be treated together (e.g., Birth_Country, Birth_Country_Subdiv, Birth_Country_Subdiv_Other). <values> Try for better example. Ck within use case.

No. Values that should be managed together could be updated independently. To prevent this, software programs would have to query the end user to ensure that none of the other related reference data columns need to be changed. Software would be more complicated to design, create, and debug. A greater burden would be imposed on the end user to know all the related columns, and know, select, and/or provide their precise values. <chk use case & better example.>

3 Sequenced Single or multiple columns of reference data that proceed in a strict sequence (e.g., Saved, Draft, Initial, Active, No Show, Inactive, and Terminated). An example is the column, App_Status_Id contained in the table, SEV_Application. <ck UC>

No. Each software module would need to understand and deal with sequenced data. Alternatively, end-users will have to know the exact sequence of values and employ them properly. If software handles this, it will be more complicated, expensive to program in all this sequence logic, and problematic to evolve and maintain it.

4 Mapped Values

Single or multiple columns of reference data that have changed values and/or meanings across time, or that represent a “transformed in” value or “transformed out” value. Mapped values may also represent a reduction in the quantity of “mapped to” and/or “mapped from” values. An example is Birth_Country, Birth_Country_Subdiv,

Yes, but only partially through Case 1, single content columns. Without complete support, the interrelated value collections critical to support SEVIS II history, longitudinal reporting, and the ability to accommodate and manage external interfaces will all have to be programmed into every appropriate software module. This will impact the integrity of the database, and will increase software complexity, programming, debugging, and long-term maintenance. Show example 212e, CCD, etc. map interface to likely tables and columns (and data elements). CIP 2010

2

While there have been discussions during the requirements meetings by SEVP and the Department of State about certain values, values in succession, the mapping of old to new values, and the ability to import and export SEVIS II data across a number of external systems, there has been no formal well defined process created that deals with reference data management within SEVIS II. In summary, there needs to be a definitive and detailed set of requirements that address complete reference data identification, enumeration, mapping, and evolution in an integrated, non-redundant and non-conflicting manner. Only through such an approach can all the data elements be identified and assessed for consistency across all use cases in support of the reference data requirements presented by SEVP and the Department of State during requirements discussions.

3. Assessment

a. Maturity Evaluation: Respondent aware of requirement – Not yet implemented

b. Preliminary Estimated Risk Evaluation Risk Management Criteria Evaluation:

Likelihood is ‘Near Certainty’ (level e) Consequence is Acceptable with Some Reduction in Margin (level 2) Risk Assessment is (Y) Yellow.

c. Standard/Guidance: DAMA DMBOK, Chapter 8, Reference and Master Data Management. See also value domain management, from ISO Standard, 11179 Metadata.

4. Recommendations It is recommended that a comprehensive set of requirements be determined for reference data that embraces identification, enumeration, mapping, and evolution and maintenance and that an appropriate set of use cases be developed.

Birth_Country_Subdiv_Other) where a country like Czechoslovakia was subdivided over time into multiple countries.

codes.

5 Discrete Values

Specific enumerated values that can be additionally allowed or disallowed. There can be multiple sets of discrete values, some allowed and others disallowed. Pay.gov examples might include change reason code or corrected transaction code.

Yes, but only partially. The support is not sufficient because disallowed values cannot be specified. These disallowed values may have special meaning and have to be treated differently than allowed values. These disallowed values will have to be “hard-coded” and specially programmed. That leads to more complex programs, increased testing, and more problematic long term maintenance. <Libya is a negative value>

6 Range Of Values

Specific ranges of values that can be additionally allowed or disallowed. There can be multiple sets of value ranges, some allowed and other disallowed. An example might be: Begin Date, End Date, Effective Date

No. Neither allowed or disallowed ranges of values can be supported. This would likely only impact interfaces. For interfaces that have highly engineered valid and invalid values, the only solution will be to build value-based selection and processing logic into the software applications. This will lead to more complex programs, longer debugging, greater documentation, and over time more difficult evolution and maintenance.


A10 SEVIS II Data Management Analysis_02


60

1

SEVIS II Data Management IV&V Concerns 6/18/2009

A key focus area of IV&V has been the data management component of SEVIS II. An analysis of the data management artifacts started late in March and continued through the date of this report. Examined were the January, March, and May 2009 Data Models. Examined also were the May 2009 FADR documents for the Data Management Plan, the System Requirements Document, the System Design Document, and the Data Conversion Plan. The table that follows identifies five data management observations. Each includes a brief description and a request for assistance in addressing the observations.

SEVIS II Data

Management Observation

Description Question

Mappings Among the Artifacts

IV&V is unable to find any end-to-end evidence from the functional requirements documents to use cases to wireframes to system requirements to system designs that interlink their common thread, the database’s tables and columns.

Would you please provide IV&V with the method, processes, and if possible, the artifacts through which IV&V can verify that the data models conform to the requirements of SEVIS II?

Audit Trails, History, and Business Transactions

There are a number of distinct requirements in the FRD that identify the need for comprehensive and very sophisticated audit trails, history, and business transactions. This need has also been expressed numerous times in requirements meetings. IV&V has been unable to determine how the current data models and contents of the SRD and the SDD support these requirements.

Would you please provide IV&V with an understanding of the approach that will be employed in the SEVIS II database and supporting on-line and batch software to capture, store, and replay audit trails, history, and business transactions starting with the data conversion of SEVIS I’s data and history through to all SEVIS II business transactions?


There is a large quantity of reference data columns in the current data models. IV&V has been unable to understand an approach from the data models that will allow value and meaning migration and mappings across time.

Would you please provide IV&V with an understanding of the approach from within the SEVIS II data model and supporting reference data management software that will handle the inevitable changes to reference data values and meanings across time as it relates to on-line, batch, and through the many different SEVIS II data interfaces?

Business Rule Management

Business rules appear to be defined only within use cases as opposed to having a central definition and then decentralized binding and execution. IV&V is concerned that there could be redundancy and conflicts across the SEVIS II database and software.

Would you please provide IV&V with an understanding of how business rules are identified, and made non-redundant and not conflicting? Would you please additionally provide IV&V with the approach through which the business rules will be bound into the database and/or the on-line, batch, and interface software such that update integrity errors are minimized or eliminated?

End User Reporting

The current database design has a number of generalized and multi-use table structures that appear to preclude end-user easy-of-use reporting. IV&V is concerned that the key requirement of easy end-user reporting cannot be met.

Would you please provide IV&V with an understanding of the approach to the design of the reporting database and supporting daily data conversion software so that the SEVIS II requirement for direct end-user reporting can be accomplished in the manner expected by the SEVIS II user community?


A11 Business Events and History_Whitepaper


61

1

Data Management Concern Area Business Event Transactions and History

8/3/2009 SEVIS II is designed to record the content data about business events. It is not yet engineered to record 1) the business event transactions themselves, 2) the history of the business event transactions, and 3) the interrelationships among business event transactions. Collectively, all three are referred to as business event transactions and history. The requirements for business events and history are described in the FRD (Functional Requirements Document, V1.0, 2/15/08), and have been discussed by SEVP and the Department of State during requirements meetings. If these requirements are confirmed by the SEVP and the Department of State, additional analysis, design and rework will be required to ensure that business events and history is captured, recorded and interrelated as needed by SEVIS II. In support of this concern, this paper provides:

Introduction and Background Business Event Transactions Solution Approach Summary, Conclusions, and Way Ahead

While this paper occasionally employs the I-17 as an illustrative strawman, the issues raised are applicable to all Government forms, use case activities, batch, interface, and reporting. SEVIS II content data is created from processing the I-17, an I-20, a DS-3036, and the DS-2019. SEVIS II data is additionally created through batch and from interfaces such as the I-901, Pay.gov, and the adjudication process. 1.0 Introduction and Background This section identifies the two fundamentally different classes of data that exist and need to be addressed within systems like SEVIS II. Both data classes have to be addressed because not only does SEVIS II store traditional transactional data, it also is required to store data in support of work-flow management, history, and data sufficient to support evidence. The section proceeds to identify two sets of paired classes of database tables that need to exist within SEVIS: Current and Audit Trails, and Business Event Transactions and History. The first two relate to content, and the last two relate to context. The section continues by distinguishing two different types of SEVIS II transactions, that is, content transactions and business event transactions. This section concludes with an overview of the types of relationships that can exist within sets of content tables and sets of context tables.

2

1.1 Database Tables versus Business Object Classes There are two different data classes: database tables and business object classes. A database table represents an encapsulated data-based policy instance such as an address, or a person’s biographic information. Each table is characterized by a name, a set of columns, and if well designed, a primary key that is based on column-based business facts that, when valued, selects one and only one row (i.e., record in a table). A table is often part of a larger and more comprehensive set of business-based data known as a business object class. A business object class is almost always comprised of multiple database tables for something like Customer. There would be a customer’s basic information, customer contacts, customer addresses, customer locations, and the like. Each of these represents a table within the context of the Customer. Almost always, there is a root database table for a business object class and also subordinate database tables related to the root table through primary and foreign keys. An instance of a business object class is called a business object. Data, such as reference data, that is factored from a business object, has no effect on the fundamental specification of business object class. In SEVIS II, there are database tables like Person, Address, Communication Method, Organization, and School. These tables are all linked through primary and foreign keys that represent, for example, that an Organization had an Address, or a Person has a Communication Method. SEVIS II, however, does not have Business Object Classes. That is, there is no set of tables for the I-17, or the DS-3036, or the I-20, etc. with relationships to other relevant database tables. This means that while there are schools, organizations, addresses, or communication methods database tables, it is not easy, for example, to determine whether the organization resulted from an I-17 or a DS-3036. Nor can it be easily determined that the data was recorded through the on-line interface, batch, or through an external system interface. In short, the SEVIS II database does not support the storage, updating or reporting of business objects. The transactions executed within SEVIS II that create, update, or delete business objects exist within the context of SEVIS II’s business-based use cases. While use cases appear to be capturing business objects, the database design does not appear to store the contextual data about these business objects. Rather, it appears that the business objects are stripped of their context and are simply stored as database table data. In this paper, use cases are called business events, and the business object create, update, or delete use case actions are called business event transactions. Essentially, each SEVIS II use case is the specification of a business event transaction. Its scope, intent, and purpose is well defined. Use cases have gone through many cycles of definition and revision by functional requirements experts. Use cases lead to wireframes

3

that represent initial software design specifications. Once developed into executing software, business event transaction content data is captured through the software layer and is stored in the database. A review of the database, however, does not support the storage of the content data about 1) the business event transactions themselves, 2) the history of business event transactions, or 3) the interrelationships among business event transactions. Rather, the content data merely appears to be stored in the database as rows of data within database tables. Lost appears to be the context of the business event transactions within which the database table data was originally captured 1.2 Current and Audit Trail Data, Business Event Transactions and History Data With respect to SEVIS II database’s design, it is important to understand that there are two sets of content database tables: “Current” and “Audit Trail.” Current database tables and their implied rows are directly accessible by the SEVIS II system. Audit Trail tables are for the SEVIS II “past” data. Each audit trail table contains a full log of all data updated by SEVIS II application software on a table by table basis. It is also important to distinguish between “Business Event Transactions” and “History.” As use cases such as Create Initial I-17 execute, business event transaction metadata about the business event transaction itself also exists. This metadata consists of the “who, what, when, where, why, and how” of the business event transaction. For the I-17, the why is the I-17 itself. There is also the who that is, the person who submitted the I-17 data, the what that in a surrogate fashion represents the data that was gathered and submitted, the when (date and time of the collection) of the business event transaction, the organization as the where-from for the business event transaction, and finally, the how (that is, the on-line interface, batch, or other system interface) mechanism that was the vehicle of the business event transaction. Collectively, Business Event Transactions and History recorded data represent the context of the SEVIS II operating events. History represents the current version through time to the initial instance of an entire business event transaction. Thus, the history of an I-17 would represent its current version and, back through all the other versions for a given instance of an I-17. The pairs, content and audit trails, and business event transactions and history are complementary, not contradictory. “current and audit trails” processes record database data along with the fundament parent-child relationships among this content data in a way that is generally devoid of business events and contexts. In contrast, the “Business Event Transactions and History” processes record the data entirely within the context of the business events, the metadata about business event transactions, and the interrelationships among the business event transactions. It is finally important to note that the actual “content” data of SEVIS II does not have to be recorded twice. Instead, as business event transactions are accomplished, the contexts and their context interrelationships are created, and at the same time, both the content and audit trail data are created. The final step is that the business event transaction context

4

data points to the “content and audit trail” records. Simply put, “current and audit trails” and “history and business event transactions” represent two complementary access paths into the same set of content (that is, current and audit trail) data records. The former supports “seeing” the current and audit trail (i.e., past) data from within traditional relational database primary and foreign key relationships, and the later supports “seeing” the content data from within the business contexts and interrelationships among the business event transaction contexts. 1.3 Content and Business Event Transactions There seems to be an adequate set of Audit Trail tables, in both the May and the June data model diagram collections that identify and define the content tables for capturing both current data and “old” data. By “old,” it is presumed to mean that every time there are one or more changes to a given row of a “current” table, a copy of that row, before it is changed, is stored as a row in the appropriate audit trail table as an “old” row. In this paper, this process constitutes a “content transaction.” That is, there exists the “current” table and a “current” row, and another specially designed “old” table, hereinafter called an audit trail table that contains all the “old” rows. It is not clear in almost all of the already engineered use cases from the SEVIS II Products that there are any business rules that identify when or if audit trail records are created. It’s just presumed that it’s done with each and every update. If there are changes to two different columns in a given business event transaction, it appears that one audit trail row is created for the multiple column updates versus one audit trail row created each column update as is required in FRD requirement MC-2162. While these update issues have to be resolved, and once resolved applied in a uniform manner among all the classes of SEVIS II application software, that is, on-line, batch, direct SQL, and interface, these issues are not the key concern of this paper. The SEVIS II based application programs, whether for on-line, batch, interface, or direct-SQL appear to be designed to accomplish “content” transactions. The relationship among all the “old” rows is in two forms: a sequence based on the date and time of creation, and as sibling collections based on a “common parentage” to a “current” table row. The relationship across all rows in all the “current” tables is through technology-based primary and foreign keys (see the section, 1.4 SEVIS II Inter-Table Relationships), not through business event transaction based relationships. This paper does not focus on the adequacy of the engineering, creation and/or maintenance of content transactions. Rather, it focuses on whether there is a need for a business event transaction, and whether that need is supported through Functional Requirements Document (FRD) statements and/or discussions that occur during functional requirements meetings.

5

Within the context of this data management concern, a content transaction is distinguished from a business event transaction. A content transaction is, for example, the actual content data from an I-17 stored in the SEVIS II database, while a business event transaction data is, for example, the data about the business event transaction itself that accomplishes the capturing of I-17 content data. In terms of ontological precedence, content transactions must pre-exist business event transactions. Common to both is that each transaction type is represented by specific collections of rows across multiple database tables. Different is that content transaction collections are interrelated solely based on technical-parent-child relationships while business event transactions are interrelated on the basis of business event inter-relationships, and/or the sequence of business events within business event transaction groupings. The data for a business event transaction is the persistent data about that specific business event. For example, the “who, what, when, where, why, and how” data about each time-sequenced, business event-driven execution that comes into existence during the creation, evolution, and reporting of, for example, an I-17. With respect to the SEVIS II database design, there are many database tables that store content data. There are few, if any, database tables that store data for the business event transactions, the history of business event transactions or the interrelationships among business event transactions. 1.4 SEVIS II Inter-Table Relationships The basis of relationship among all the rows of the SEVIS II database tables is through a primary key to a foreign key architecture. Each primary key value is represented through an auto-incrementing integer value. The very next row to be created for any given table gets the next higher number, regardless of reason for the existence of the row. In database technology, this type of primary key is called a surrogate key. It is called that because it is a “surrogate” for a different set of database columns that, when their values are taken together as a row selector, only select a single row. This second type of primary key is commonly called a “natural” primary key. Tables related to the parent table each contain a “foreign key” that, when valued, contains the value of the parent table’s primary key. For example, if a Person’s primary key value is “10” and that person has five different addresses, each of those five addresses would contain a Person Id value of “10.” The Person table’s primary key (e.g., Person Id) value of “10” is the linking mechanism to the five different address rows, all of which also contain the Address column of Person Id with the value “10” Other than “this is the parent of that” there is little to no other SEVIS II business-explicit basis for relationships among the tables. If there is to be a classification of the “kind of address” for that specific person, that classification has to be created when the address is being created in context of that specific person. As an alternative to either address or person creation, an existing address and an existing person can be interrelated by retrieving an address that is to be assigned to a given person (where Person Id = “10”), and by updating that Person Id within the address table to the value “10.”

6

2.0 Business Event Transactions This section of the paper focuses on the nature of a business event transaction and whether the need for such transactions can be supported from the SEVIS II FRD and/or from requirements discussions. This section also identifies illustrative business event transactions that appear from a review of the I-17 form as shown in the SEVIS II System Design Document from June 2009. 2.1 The Need for a Business Event Transaction It is not clear from the “Current” or “Audit Trail” database table specifications that the concept of a business event transaction exists within the June 2009 SEVIS II database design. It is also not clear that the “Current” or “Audit Trail” tables associated with business event transactions are collectively identified and can be interrelated on the basis of a business event transaction. An example is all the data related to the creation, storage, adjudication, and evolution of an I-17. By “not clear,” what appears to be missing is a “business event transaction” table with the appropriate “who, what, when, where, why, or how” metadata about the business event transaction. Nor is there the ability to relate a created business event transaction to all the Current and/or Audit Trail tables that participate within the scope of that business event transaction. To accomplish this, a business event transaction table would have to be created that would have business event transaction foreign keys in every appropriate Current and/or Audit Trail table to hold the interrelating Business_Event_Transaction_Id value. Such a strategy, however, would not be sufficient. That is because business events are both hierarchical and also interrelated in a network fashion. For example, an instance of an I-17 business event transaction not only has its metadata, i.e., it’s the “who, what, when, where, why, and how,” it also has subordinate business event transactions such as school, address, location, person, petitioners. This makes a business event transactions hierarchical. Further, each of these contained business event transactions has its own business event transaction metadata. A number of business event transactions also have common ancestor business events. For example, address can have common person or organization ancestors. Other business event transactions, such as the signature (Sign) business event transaction also have common ancestor business events. Some business event transactions are even more complicated because, over time, some organizations divide and then re-group and possibly divide again. All these are examples of one event being spawned by multiple parent events.

7

Because business event transactions have multiple parents as well as multiple children, the business event transaction’s data structure has to be a network. Without a network structure, that is, with only a hierarchical data structure, data redundancy and subsequently, conflict will occur. That ultimately leads to update errors as multiple records require update when there should have only been one update. 2.2 Functional Requirements Support for Business Event Transactions Fundamentally, there are two viewpoints for this SEVIS II data management concern: technology and business. If this was purely a technical issue, the individually updated database rows, as now appears designed with the SEVIS II current and audit tables, might well be adequate. However, the requirement for business event transactions in SEVIS II appears to be much more sophisticated than can be accomplished by a simple set of current and audit trail tables. For example, within the scope of an I-17, the following issues must be addressed:

Whether all the data creation and update processes for an entire I-17 result in a single business event transaction or multiple, or nested business event transactions.

Whether all the data updates accomplished by a particular SEVIS II user over a specific period of time result in a single business event transaction or multiple, or nested business event transactions.

Whether just the updates that occur during a given on-line session result in a single business event transaction or multiple, or nested business event transactions.

Whether just the updates within a specific batch submitted data stream result in a single business event transaction or multiple, or nested business event transactions.

Whether the re-playing of the changes to a particular government form or specific SEVIS II type of data update results in a single business event transaction or multiple, or nested business event transactions.

Whether there is a difference in the definition and recording of date of creation and date of update in technical transactions versus business event transactions.

The FRD contains more than 50 history requirements, including for example: MC 2116, MC 2173, LAH 2713, JE 3112, and DQ 3316. A listing of the discovered history requirements is Attachment 1 of this paper. An analysis of the identified FRD requirements leads to the belief that a number of requirements overlap, are not integrated, or are not uniform or consistent. Consequently,

8

it is not possible to verify in any uniform manner that the SEVIS II business event transactions, their history and their interrelationships are being properly collected, and stored. Thus, business event transactions and their history may not be reportable as required. The reason that more than 50 history requirements show overlap, or are not entirely distinct or clear, may have been caused by not treating this class of requirements as a single set that was reviewed and revised as a single requirements set. Examples of the overlap include:

CER 2555, CER 2556, and JE 3110, CER 2556, JE 3073, and JE 3087, JE 3073, JE 3079, JE3110, and LAH 2706 LAH 2702, LAH 2706, and JE 3073, JE 3078, JE 3084, and CER 2549, LAH 2707, and LAH 2713 JE 3087, JE 3088, SRT 2655, and USR 2659

An examination of the approved use cases from Product 6 shows that only four unique history requirements were allocated (JE 3112, MD 2900, LAH 2713, and JE 3103.4). In contrast, through an independent IV&V effort, 42 out of the more than 50 history requirements were assigned. Attachment 2 provides the allocation of history requirements to 28 use cases from Product 6. Clearly, there is a significant difference in the history requirements allocation that should be explored and reconciled. A reason for this variance may be a difference in interpretation. However, if history requirements are not accurately allocated to the use cases as intended by the requirement owners, SEVIS II history is at risk for not being properly collected, stored, and reported as intended. Collectively, these requirements point to the need for the establishment of a fundamental set of business event transaction and history definitions, a clear set of business event transaction boundary rules, and a number of specially convened requirements sessions on a per use case basis, and thereafter a set of requirements gathering sessions across targeted use case collections to fully document a unified, consensus based set of requirements for business event transactions. Without a verifiable history requirements allocation, it is not possible to determine whether the current database meets both the history requirements of the FRD and also those presented by SEVP and the Department of State during requirements discussions. More importantly, without clear expression of requirements and subsequent reflection within the use cases and data model, SEVIS II functionality may not contain the features desired by the SEVP and the Department of State.

9

2.3 Source of Business Event Transactions A cursory examination of Product 1, Submit I-17 shows that there may be the following classes of business event transactions:

I-17 creation information School Organization Address Location Person Petitioners (a relationship type to a person?) School engagement areas (each a transaction?) Registration periods School System (and a school relationship to school system) Instructional Sites Instructional Site Addresses (and a relationship from site to address?) Designated School Officials (and a relationship type to a person?) School Accreditation Organizations (a relationship type to a reference data set?) Licenses and Certifications Types of Instructions Staff Types and Counts Student Cost Types and Costs Calendar types and key dates Academic Sessions Programs of Study

In many of the cases, each of these business event transactions involve multiple database tables, and supporting business event transaction processes that create and/or update data over periods of time. In a business event transaction determination analysis, the following is just a sample of the questions that must be asked, answers determined, and across all of SEVIS II, business event transaction granularity and definitions identified and resolved:

Is there only one business event transaction for each government form? Are there multiple business event transactions of different granularities? Which business event transactions are nested? Can multiple business event transactions span time spans? Can there be the creation of an overarching business event transaction with all

subordinate business event transactions. Can business event transactions be deleted including all its implied content

data? Can a business event transaction that is marked-for-deletion be restored? What level of business event transaction restoration granularity will there be? Can the restoration span time frames?

10

How will the impact be determined if marked for deletion business event transactions are restored but SEVIS II reports have been generated without these business event transactions in the interim?

What business processes need to be established to both technically accomplish and bureaucratically record the appropriate metadata in support of business event transactions?

This type business event transaction analysis, impact determination, and possible design and implementation changes should also occur to all the SEVIS I data prior to its conversion to SEVIS II. To accomplish that, a thorough analysis of SEVIS I history has to be undertaken and rules posited that identify, where possible, business event transactions and all nested business event transactions. If this is done, business event transactions can possibly be created and brought into the SEVIS II database from SEVIS I. An analysis similar to what would be done on the I-17 has to be accomplished for all government forms that impact the database tables. This business event transaction analysis and design has to be re-evaluated for both the data creation use cases and also all the data evolution and maintenance use cases. Critical to discern is how different business event transactions are to be interlinked as siblings, parents, ancestors (that are different from parents), and descendents. The only obvious way identified and defined business event transaction interrelationships can be verified is through a “business event transaction work flow” review that ensures that all database updates can be “replayed” in an appropriate manner and sequence. 3.0 Solution Approach The approach to a solution of business event transactions and history is described through a candidate set of solution-based activities, an assessment of the adequacy the SEVIS II’s Integrated Master Schedule from June 2009 (prior to the July 2009 rebaselining), and a high level example of a business event transaction and history solution architecture. 3.1 Candidate Solution Approach Activities The following activities seem appropriate:

Requirements owners need to determine a single set of history requirements and communicate them to Booz Allen Hamilton for incorporation within use cases.

The contractor needs to engage government personnel in a use case by use case analysis to identify business event transactions.

11

Two sets of data structures need to be constructed. The first as a network of business event transaction classes, and the second as a network of business event transaction instances. The first set represents types. It has the second as instances. The second set, when it acts as types has the SEVIS II content tables, that is, the current and audit trail database tables as instances. Each of the current and audit trail database table rows has a “Business Event Transaction Id” that acts as a foreign key back to its parent business event transaction. These two interconnected network data structures enable both a business event transaction based and a time-sequenced based replaying of SEVIS II data.

A business event transaction model needs to be built that involves data conversion from SEVIS I, new data creation within SEVIS II, and on-going data update within SEVIS II from on-line, batch, and/or interface sources.

Business event transaction based scenarios need to be constructed and reviewed by the government to ensure that clear, consistent, and coherent histories can be retrieved and employed by the various SEVIS II users.

3.2 Adequacy of the Project Schedule for Products 9 and 10 During the requirements session for the approved Product 6 use cases, the contractor requirements team stated over and over that the need to satisfy the business event transaction and history requirements is real and will be satisfied during the work for Products 9 and 10. This section assesses whether there appears to be adequate time for this type of work. The assessments that follow were made from the June 2009 Integrated Master Schedule that records the start and stop dates of already accomplished work. The current Integrated Master Schedule (IMS) from June 2009 for Product 9 (Department of State and Exchange Visitor Support) and for Product 10 (SEVP School and Student Support) durations, which would likely include support for business event transaction creation at both the Department of State and the SEVP Office seem inadequate. To determine the probability of that being true, the IMS for the first four products was examined. The table that follows provides elapsed days for the first four products by major activity type. Because the quantity of actual staff days was not examined, this analysis may only be indicative of a resource problem, not determinative.

Product Quantity of Use Cases

Major Activity Type Elapsed days from IMS

1. Submit I-17 (8/08 – 4/10)

5 Requirements 28 Design 64 Development 52 Integration & Test 159

2. Submit DS-3036 (8/08 – 4/10)


12

Product Quantity of Use Cases

Major Activity Type Elapsed days from IMS

3. Account and Program Migration (12/08 – 10/09)


4. New Account Setup (12/08 – 12/09)


6. Exchange Visitor Management (1/09 – 12/09)

26 Requirements 93 Design Not accomplished yet Development Not accomplished yet Integration & Test Not accomplished yet

From this table, a rough order of magnitude statistic was created. It takes, on a per use case average, about 10 elapsed days for requirements, about 17 elapsed days for design, about 10 elapsed days for development, and about 28 elapsed days for integration and test. Product 6 appears to have been accomplished much faster as its use cases were designed at a rate of about one every three days or three times faster. How that acceleration affects design, development, and integration and test for Product 6 is unknown. Hopefully it translates at least linearly. The elapsed days for product 9 are: Requirements time is set for 34 days. Design for is set for 40 days. Development is set for 23 days. Integration and test is set for 57 days. From the above statistic, that would imply that the durations will only support about 3 use cases to be taken through requirements, design, development, and integration and test. The elapsed days for Product 10 are: Requirements time is set for 13 days. Design for is set for 19 days. Implementation is set for 21 days. Integration and test is set for 55 days. From the above statistic, that would imply that the durations will only support about 2 use cases to be taken through design, development, and integration and test. The IMS duration allocations for Products 9 and 10 therefore appear to be significantly under scoped. This conclusion appears to be valid given the hypothesized 21 business event transactions for just the I-17. It is hoped and presumed that many of the existing use cases can be readily adapted versus recreated to accommodate business event transaction requirements. Ironically, the actual time to modify the logical and physical database design to accommodate business event transactions is likely to be just a few staff weeks. The largest quantity of time will be required to discern the business event transactions, nested business event transactions, and to determine the effect from all these business event transaction requirements on the existing set of approved use cases which, from within the SEVIS II system requirements document, are the basis for all then existing SEVIS II software requirements, design, development, and integration and testing artifacts.

13

3.3 Solution Approach Illustration The figure on the next page illustrates an approach for 1) the business event transactions themselves, 2) the history of business event transactions, or 3) the interrelationships among business event transactions. This approach contains two intersecting network data structures. The figure shows three major blocks of tables. The top block contains two classes of tables: “Type Tables” and “Instance” rows. In the top block there are three tables: Business Event Transaction Class, Business Event Transaction Class Structure, and Business Event Transaction Class Structure Type. The Business Event Transaction Class table holds rows that name each different business event transaction that can occur within SEVIS II. Most likely these are the various use cases, given that each use case is in a “third normal form” process specification. Examples of these business event transactions are set out in section, 2.3 Source of Business Event Transactions. Example instances of these use cases are enumerated below the Business Event Transaction Class table. Shortened names are provided. Organization would likely be something like “Add/Modify/Delete Organization.” The middle table, Business Event Transaction Class Structure, enables the capture of the interrelationships among business event transaction classes. This represents the contextualized history of all possible business events. A stylized set of names was created to illustrate the type of information captured in this database table. For example, “I-17 contains Organization,” or Organization requires Address. The table, Business Event Class Structure Type, provides a name to the interrelationship. In the first instance, it is “Requires” or “Is Required By.” The middle table, Business Event Transaction Class Structure, has two child-to-parent relationships with Business Event Transaction Class. This enables a network. The top relationship line is an “active” relationship. What that means is, for example, #1003, 104, 101, 2 which essentially means, I-17 contains Organization. The structure record is #1003, the I-17 Create Initial Submission is #104, and the Create Organization record is #101. Another example is #1000, 101, 103, 1 which essentially means, Organization requires Address. Read in the opposite (passive) way, Address is required by Organization. Note also that #103 Create Address is required by #102 Create School. Because address is a “child” of both Organization and School, the data structure is called a network. That’s because a network uniquely enables a child to be “owned” by multiple parents. The second block contains both “type” and “instance” tables. In this second block, the “type” tables are at the bottom of the block and are: Business Event Transaction, Business Event Transaction Structure, and Business Event Transaction Structure Type. This second set of network structures supports the storage and interrelationships among actual business event transactions. The top set of network structures supports the storage and interrelationship among all potential business event transactions.

14

#8943, #1003, Organization row for Woodward University

<content data>

Business EventTransaction Class

Business Event Tracking In Support of History

Business Event Transaction Class

Structure

Business Event Transaction Class

Structure Type

Business Event Transaction

with When, How, Where, Why, Who,

What


Structure


Structure Type

#104, I-17 Create Initial Submission

#103, Create Address

#102, Create School

#101, Create Organization

1001, 102, 103, 1School requires

Address

1000, 101, 103, 1Organization

requires Address

1003, 104, 101, 2I-17 contains Organization

1002, 101, 102, 2Organization

contains School #2, Contains, Is contained in

#1. Requires, Is required by

“Type” Tables

“Instances”

“Type” Tables

#648, 1000 Franklin StPhila, PA

#425, I-17 for Woodward Univ.

#179, 675 Union Ave

Chester, PA

#83, Woodward University, Chester

Campus1001, 5, 648, 1Woodward has Franklin Addr

1000, 5, 83, 1Woodward has

Chester Campus

1003, 5,425, 1I-17 has Woodward

1002, 83, 179, 2Chester has Union

Addr #2, Contains, Is contained in

#1. Requires, Is required by

“Instances”

#5, #1003, Woodward University <see yellow

record for actual content>

#1003, 2/1/2010, Batch Job 625, <#8943 <content record>>, Capture Organization, Rob McGuire, Woodward

University

15

The instance example here is for a strawman illustration, Woodward University. The method of reading the rows is the same as in the top. Here, once the capture of an I-17 is started, an initial first step is the capturing of the I-17’s organization, which in this case is Woodward University. Each organization is represented in the Business Event Transaction table. Note, that by represented, the actual university’s data is not contained in the Business Event Transaction table. Rather, what is contained in the Business Event Transaction table is the metadata for the actual organization. That is, the “when, how, where, why, who, and what” of that “Create Organization” business event transaction. In this specific example, Create Organization, Woodward University’s organization data is represented by the #8943 row at the bottom. It has the foreign key value #1003 back to the Woodward University business event transaction structure row that, in turn, has a foreign key value #5 back to the Business Event Transaction row, Woodward University. That row, in turn, has a foreign key #1003 back to the Business Event Transaction Class Structure row. While this approach may appear indirect and somewhat complex, it represents industry standard best practice for capturing “bills of materials.” A bill of materials is the strategy for capturing parts, assemblies, and types of assemblies. In SEVIS II, the parts are the business events, the assemblies are the contextual relationships among business events, and the type of assemblies are the various types of collections of SEVIS II business events. Two interrelated bills of materials are required because the first represents all possible business events and interrelationships, and the second represents all actual business events and relationships. Married together, reports can be produced that not only indicate what is possible and even required, but also what has actually occurred. That provides the ability to create critical reports of what actually exists and what remains missing. Through this approach what can be captured within SEVIS II are 1) the business event transactions themselves, 2) the history of business event transactions, and 3) the interrelationships among business event transactions. If this approach is adopted, the actual mechanism of its accomplishment within SEVIS II is not addressed this paper. This paper merely asserts that SEVIS II has requirements for business event transactions, interrelationships, and history, and posits an illustrative approach to capture this context information in a predominantly data-centric way rather than a predominantly software application way. 4.0 Summary, Conclusions, and Way Ahead If this approach is adopted as suggested, there will still need to be: 1) Modifications to all use cases starting at Product 1, 2) Modification of the SEVIS II database design, and 3) Modification of SEVIS II application software to capture all possible business event transactions and their interrelationships.

16

Then, as the SEVIS II application software executes from the on-line interface, batch, interfaces, and during initial conversion, the actual business event transactions, their interrelationships, and their appropriate metadata within the SEVIS II database will be able to be recorded. While clearly, this approach is not a quick-fix or a “silver bullet,” it is, however, the business case for an outline of a solution to capture of SEVIS II’s business event transactions, their interrelationships and history. This approach proposes a predominantly data-centric strategy because if history is only known within the SEVIS II’s presentation layer application software of the on-line interface, the recording of business event transactions and history via batch, via interfaces, and via initial conversion will likely require the duplication of all that on-line business event software logic into three additional classes of software (that is, batch, interfaces, and initial conversion). This could not help but take longer, cost more, and present a long term tedious and complicated SEVIS II evolution and maintenance effort.

17

Attachment 1 Audit Trails, History and Business Transactions

Functional Requirements Document Version 1.0, 15 February 2008

Id Category FRD Reference

Description

1 Application screening/certification requirements

MC 2100 Include a history tracking log that will: .1 - Provide read receipts in tracking log to verify receipt of RFE email .2 - Retain denial comments in tracking log .3 - Retain all actions for approved petitions .4 - Include all dates .5 - Be retained once school is approved or denied .7 - Have a summary of history, accessible by one click .8 - Track helpdesk tickets

2 MC 2103 Have expanded search capabilities so that: .1 - School Certification Branch (SCB) can search by appeal status .2 - Review student records by particular search criteria

3 MC 2116 Have ability to exchange work-flow based information for processing certifications and re-certifications for compliance and oversight.

4 MC 2119 Capture denial information date, basis, comments and store denial comments viewable to adjudicators and case analysts.

5 MC 2123 Maintain history of changes and requests by the provisional school

6 MC 2133 Maintain a history of all DSOs biographical information 7 MC 2135 Track DSO name changes and be able to search by all

versions of the name 8 MC 2142 Show a history of the DSO by school(s), period of time

served at the school, and roles 9 MC 2143 Show a history of the school owners, period of

ownership, school name, period of certification 10 MC 2144 Show a history of DSO actions for a given period of

time. 11 MC 2173 Maintain a persistent history of all sanctions levied on

an individual school, group, or system and maintain the compliance history while the school is Active and allow authorized SEVP users access to this information

12 MC 2186 Capture all communication between a petitioning institution and an SEVP adjudicator.

13 Create eligibility record requirements

CER -2511 Require complete, auditable history of all transactions 14 CER -2539 Move all “cancelled” records to the history repository

120 days after the status date. 15 CER -2546 Maintain a repository of all SEVIS [I] data on students. 16 CER -2549 Retain biographic data on students and dependents that

is updated in accordance with the business rules only when that data changes to include: USCIS enumerator (Student ID number), FIN, names, aliases, gender, DOB, COB, COC, Social Security Number (optional)

17 CER -2555 Maintain a transactional record of student financial information to include Student ID, School ID, status

18


Description

period code, program period code, and financial data including remarks

18 CER -2556 Maintain a transactional record of student employment and practical training information to include Student ID, School ID, status period code, program period code, employer data, beginning date, ending date, part-time or full-time indicator, type of employment/training, explanatory remarks

19 Update Student Records

USR 2611 Allow DSOs to review and make changes submitted by students and Record the date and time of the approval

20 USR 2655 Create a notification record at the transfer-in school upon submission of the transfer request that includes: - Name of the DSO that submitted the request at the transfer-out school - Phone number of the DSO that submitted the request at the transfer-out school - Effective date of the transfer - Current status of the student’s record

- Student’s biographical information from central repository

- Student history 21 USR 2659 Create a “Deactive-transfer out” record at the transfer-

out school on the effective date of the transfer that includes: - Transfer-out school ID - SEVIS ID and full name of student - Identity of the transfer-in school - History of student action at the transfer-out school

22 Life Cycle / Active History

LAH 2700 Provide more access to record history information to view authorizations for Curriculum Practical Training (CPT)

23 LAH 2702 Provide DHS user access to historical (all related) information on a particular SEVIS record

24 LAH 2706 Provide a Student History page for each Student, to include, but not limited to, the following: - Date of arrival - Place of Arrival - Passport Number - VISA number - Passport expiration date - VISA expiration date - Names of student’s dependents - All schools attended - Dates schools were attended - Transfers from and to schools - All periods when out of status - Reasons why out of status - All approved I-539 for reinstatement of status - All disapproved I-539 for reinstatement of status - All travel in and out of the USA - Changes in academic major - Criminal violations

19


Description

- OPT/CPT where student worked - Reasons why student worked in said locations - Type of work performed - Supervisor names - Description of duties - Summarized description of student’s theses - Identification of problematic thesis topics according to TAL - Pending applications other than I-539 - Date of student orientation - Current nonimmigrant status - Date of last address change - Ticket number for data fix requests - Remarks text box - Exit date

25 LAH 2707 Allow end users to track student/EV progress through visa issuance milestones

26 LAH 2713 Maintain a transactional history for each student that ties each transaction to the school, period of status, degree level, and program such that breaks in status can be determined and a student’s history during each status period can be determined by: - Assigning a period of status code and maintain a record with the code, beginning date, and ending date (when applicable), and reactivation history - Assigning an ending date for the period of status when the student’s record terminates or upon the expiration of the student’s status period where there is no change of level or transfer pending - Opening a new period of status record and assign a new period of status code when a nonimmigrant student is given “Initial” status after a break in status and verification of payment of a SEVIS I-901 fee for the new status period - Reactivating a period of status code record when a student is reinstated and recording the termination date, the reinstatement action, the reinstatement date, and deleting the ending date

27 LAH 2716 Maintain, and display with the student’s record, an activity indicator for Active student records by: - Recording the dates an activity starts and ends - Being able to calculate the amount of time an Active student record has had a given activity indicator for a given period of time, a particular program, or for a specified program level - Recording an activity indicator of “enrolled” for active records where the enrollment dates indicate a student is currently enrolled in class using the session dates to calculate the beginning and ending dates - Recording an activity indicator of “Post-completion OPT” where the PED is past and OPT is approved for a period that spans the dates on the EAD - Recording an activity indicator of “study abroad” when a DSO selects the “Study abroad” option when

20


Description

enrolling the student class using the session dates to calculate the beginning and ending dates - Recording an activity indicator of “off-campus study” when a DSO selects the “off-campus study” option during enrollment or a student has full-time CPT at a site other than the school class using the session dates to calculate the beginning and ending dates - Recording an activity indicator of “grace period” in accordance with the business rules for the nonimmigrant class for a student in a post-completion grace period - Changing the activity indicator to “Break/Vacation” where the status remains active after the expiration of the current activity period and record the end of the previous activity period as the start date for the break/vacation - Creating a flag to notify the DSO when the “Break/Vacation” activity indicator remains in place for more than 30 days for a student and the business rules indicate the student is not eligible for a vacation period - Being able to calculate the amount of time a student has had an activity indicator of “enrolled”, “off-campus study”, or “study-abroad” for a given period - Creating a flag to notify the DSO when the “Break/Vacation” activity indicator remains in place for more than 130 days - Having the ability to automatically terminate records based on the length of time a record shows a given status activity indicator

28 Initial Designation Application Requirements

IDA 2809 Record the electronic signature data for transactions as required by system specifications and business rules

29 IDA 2823 Display application information as well as history and tracking information

30 IDA 2868 Maintain a history of changes and requests by the provisionally designated institution

31 Maintain Designation Requirements

MD 2900 Include a history tracking log of case transactions that will, at a minimum: - Provide read receipts in tracking log to verify receipt of RFE email - Retain denial comments in tracking log - Retain all actions for approved petitions - Include all dates - Be retained once school is approved or denied - That can have information input and extracted from it - Have a summary of history, accessible by one click - Track helpdesk tickets

32 MD 2920 Maintain a history of all ROs biographical information 33 MD 2926 Show a history of the RO/ARO by program(s), period of

time served at the program, and roles and link to other programs with common officers – J, F, M

34 MD 2927 Show a history of the program owners, period of ownership, program name, period of designation and link to other programs with common owners/officers – J, F, M

21


Description

35 MD 2928 Show a history of RO/ARO actions for a given period of time

36 MD-2947 Maintain a persistent history of all sanctions and/or reprimands levied on a program

37 MD-2947 Track each DS-3036 Redesignation application that is submitted and maintain a detailed history on each Application

38 MD-2977 Include a complete history of Redesignation application changes, and actions taken on application

39 J1 Eligibility Requirements

JE 3075 Provide a Exchange Visitor History page for each Exchange visitor, to include, but not limited to, the following: - Date of arrival - Place of Arrival - Passport Number - VISA number - Passport expiration date - VISA expiration date - Names of EV’s dependents - All schools attended - Dates programs were attended - Transfers from and to programs - Reinstatement requests - All periods when out of status - Reasons why out of status - All travel in and out of the USA - Changes in subject field - Criminal violations - Student employment, academic training and where EV worked - Reasons why EV worked in said locations - Type of work performed - Supervisor names - Description of duties - Summarized description of student’s theses - Identification of problematic thesis topics according to TAL - Pending applications other than I-539 - Date of student orientation - Current nonimmigrant status - Date of last address change - Ticket number for data fix requests - Remarks text box - Exit date

40 JE 3078 Provide time frame for pending data fixes 41 JE 3080 Maintain one, and only one, master record of

biographical information on each exchange visitor 42 JE 3081 Track the entry and exit dates for all exchange visitors

by: - Being able to generate a travel record for exchange visitors - Flagging records for review by an authorized ECA/SEVP user where indicated by the business rules

22


Description

43 JE 3086 Retain biographic data on exchange visitor and dependents that is updated in accordance with the business rules only when that data changes to include: USCIS enumerator (Student ID number), FIN, names, aliases, gender, DOB, COB, COC, Social Security Number (optional)

44 JE 3089 Allow exchange visitors to submit requests to their ROs via SEVIS for transfers, program extensions, change of category, student employment and academic training and: - Record the date and time of the request, type of request, and request details - Require submission of an email address - Allow the RO to review requests and approve - Create a notice from the RO to acknowledge of acceptance of request

45 JE 3096 Display school/program “transfer out” information 46 JE 3103.4 History of EV action at the transfer-out program. 47 JE 3112 Maintain a transactional history for each exchange

visitor that ties each transaction to the program, period of status, and program such that breaks in status can be determined and an EV’s history during each status period can be determined

48 JE-3067 Provide more access to record history information to view any authorizations

49 JE-3068 Provide a process to allow the review of certain changes to an EV/dependent record

50 JE-3069 Provide reviewer the ability to view dates for authorized student employment and academic training

51 JE-3070 Provide users with all available information from an EV/dependent record, including updates, according to predefined criteria and rules

52 JE-3071 Provide DHS Officer and DoS officials access to historical (all related) information on a particular SEVIS record

53 JE-3079 Capture all data changes in chronological order 54 Person-centric Data

and Query Requirements

DQ 3316 Have enhanced Consular access/search capabilities including, but not limited to: - Access to historical data - Ability to search perspective visa issuances - Access to termination reason - EV skills list

55 DQ 3322 Allow RO’s to add job titles in profiles – while retaining past history

23

Attachment 2 Audit Trails, History and Business Transactions

Requirements Allocation to 28 Product 6 Use Cases

Allocation of History FRD Requirements to 28 Product 6 Use Cases Id

Use Case Title

BAH History Requirement

Allocation

IV&V History Requirement

Allocation 1 Add/Remove Exchange Visitor Program Sponsor

Alternate Responsible Officer Note: While the ROs and AROs are identified separately from PDSOs and DSOs, they are effectively the same except from different organization types. The FRD (page 4) identified them as “x/y.” Hence this analysis considers them the same only for the purposes of the allocation of history.

None MC 2133 MC 2135 MC 2144 MC 2186 USR 2655 MD 2920 MD 2926 MD 2927

2 Alternate Professor/Research Scholar JE 3112 (FRD: JE-3112)

JE 3112 JE 3075 JE 3086

3 Apply to Amend the Exchange Visitor Program Designation

None MC 2123 MC 2142 MC 2143 MC 2173 MC 2186 MD 2900

4 Apply for Exchange Visitor Program Redesignation

None MC 2123 MC 2142 MC 2144 MC 2186

5 Change EV Category JE 3112 (FRD: JE-3112)

LAH 2706 LAH 2702 LAH 2707 LAH 2713 LAH 2716 JE 3075 JE 3089 JE 3112

6 Correct Exchange Visitor Status None JE 3086 JE 3112 LAH 2706

7 Correct a Minor or Technical Infraction None JE 3112 MD 2900 JE 3075

8 Create Academic Training Record (EV in Active Status)

None JE 3086 JE 3112 CER 2556 LAH 2706

9 Create Student Employment Record (EV in Active Status)

None JE 3069 JE 3086 JE 3112 CER 2556

24


Use Case Title


Allocation


Allocation LAH 2706

10 Extend EV’s Program JE 3112 (FRD: JE-3112)

JE 3086 JE 3112

11 Form DS-2019 Add Spouse/Dependents (J1 in Active or Transfer In Status

JE 3112 (FRD: JE-3112)

JE 3068 JE 3070 JE 3075 JE 3089 JE 3112

12 Form DS-2016 Create/Update (Certificate of Eligibility for Exchange Visitor Status)

JE 3112 (FRD: JE-3112) JE 3078

CER 2511 CER 2546 JE 3078 JE 3112

13 Form DS-2019: Manage Out of Country Records (Active Status)

None LAH 2706 LAH 2716 JE 3112

14 Form DS-3037: Update Exchange Visitor Program Sponsor Information

MD 2900 MD 2900 MC 2133 MC 3135 MC 2144 MD 2920 MD 2928

15 Manage Journal None MC 2119 MD 2900 JE 3075 JE 3112 CER 2555 CER 2556 USR 2611

16 Matriculate Exchange Visitor (EV) None JE 3075 JE 3112 CER 2511 LAH 2706 LAH 2713

17 Reinstate Exchange Visitor LAH 2713 JE 3112 CER 2556 LAH 2706 LAH 2713

18 Report Exchange Visitor (EV) Participation and Update J-2 SEVIS Status

None JE 3068 JE 3070 JE 3075 JE 3089 JE 3112 CER 2549 LAH 2706

19 Request Allotment of Brochures None none 20 Request Allotment of Certificates of Eligibility

(Forms DS-2019) None MC 2113

CER 2511 21 Request Responsible Officer Replacement None MC 2133

MC 2142 MC 2186

25


Use Case Title


Allocation


Allocation 22 Request Withdrawal of Exchange Visitor Program

Designation None MC 2119

MC 2123 MC 2173 MC 2186

23 Sign Form None JE 3112 MC 2186 MD 2920 MD 2927 MD 2928 CER 2511 IDA 2823

24 Submit Annual Report None none 25 Terminate and End Program/End J-2 SEVIS Status None CER 2549

LAH 2706 JE 3089 MC 3110

26 Transfer In an Exchange Visitor None MC 3110 USR 2655 USR 2659 LAH 2706 LAH 2713 JE 3075

27 Transfer Out an Exchange Visitor JE 3103.4 MC 3110 USR 2655 USR 2659 LAH 2706 JE 3075 JE 3103.4

28 View Exchange Visitor Program Sponsor Profile None IDA 2800 IDA 2809


A12 DMConcern_Reference Data_Whitepaper_02


62

1

Data Management Concern Area Reference Data

7/10/2009 1.0 Introduction Reference data represents data-based object collection classification schemes. Each reference data value should be orthogonal in terms of its semantics. Reference data values are employed to uniquely distinguish one object collection from another. Collections of objects can be characterized in multiple ways, thus there can be multiple reference-data based characterizations. Simple reference data consists of discrete values representing single, easily distinguished meaning. Complex reference data contains multiple inter-related facts that are intrinsically related to each other, and in many situations have their values changed in lock step. An instance of reference data is almost always a row in a database table. As with all other rows, there are four kinds of columns for each table: uniqueness columns, metadata columns, content columns, and relationship columns. Uniqueness columns represent a set of values that causes the selection of just one row. Metadata columns represent the reference data’s adjudication information. That is, the information that affirms the authoritativeness of the values. This normally contains who, what, when, where, why, and how data. Content columns represent the “real” data, and for a single reference data content column that would be just the reference data value and the reference data value meaning. The final column set, relationship, represents the columns that, when valued, provide the uniqueness value for a different row in the same table (recursive relationship) or different table (child table for a parent-child relationship). In this later situation, the uniqueness column set is often called the reference data table’s primary key. Any database column that has a severely restricted value domain can be seen as reference data. Additionally, whole collections of data, that is, multiple columns within a reference data table, can also be seen as reference data. Reference data is often employed as sort fields, selection fields, and as “control breaks” for the purpose of statistical calculations. Sometimes reference data exists as single database columns, and other times reference data contains multiple columns that act as collections, in concert. On occasion, the reference data column values must “progress” from one value to the next in a strict sequence. 2.0 Reference Data Cases The six common cases for managing reference data are:

Reference Data Case

Reference Data Type

Description

1 Single Content A single column of reference data such as a person name’s

2

Reference Data Case

Reference Data Type

Description

Column Salutation (e.g., Dr. Ms, Mr.), Gender (e.g., M, F, U), or Suffix (e.g., Sr. Jr, III)


Multiple columns declared to be treated together (e.g., Part Number, Part UPC, and Part Name)

3 Sequenced Single or multiple columns of reference data that proceed in a strict sequence (e.g., Saved/Draft, Initial, Active, No Show, Inactive, and Terminated)

4 Mapped Values Single or multiple columns of reference data that have changed values and/or meanings across time, or that represent a “transformed in” value from a set of inward interface processes or “transformed out” value for a set out outward interface processes. Mapped values may also represent a reduction in the quantity of “mapped to” values from a set of “mapped from” values. The converse is also possible.

5 Discrete Values Specific enumerated values that can be additionally allowed or disallowed. There can be multiple sets of discrete values, some allowed and other disallowed.

6 Range Of Values Specific ranges of values that can be additionally allowed or disallowed. There can be multiple sets of value ranges, some allowed and other disallowed.

The first two cases are illustrated through the use of notional reference data database tables as a way to illustrate the issues that must be addressed. Solutions for the other three cases are well known but are only generally described here. Additionally, also well know but not addressed are the reference data “metadata” tables that provide “official status” support for reference data. 2.1 Single Content Columns Reference Data For simple reference data, say, Gender, two reference data tables are required: Reference Data Type and Reference Data Values. These two tables are already generalized in that they can contain the reference data for many different reference data columns that may exist in a database. For example, additional reference data columns might be: Salutation, Status Code, State Code, and Zip Code. Rather than have separate reference data tables for each they are represented within one generalized set of reference data tables.

Reference Data Type table Column type Column Name Column Meaning Example Value Uniqueness Reference Data

Identifier A unique number that causes the selection of just one row of data from the data table.

1947

Metadata Value Start Date The date the value was first able to be used.

01/01/1985

Value End Date The date the value was last able to be used

01/01/1998

Adjudication Date The date the value was determined acceptable

10/15/1984

Adjudicator The name of the organization Human Resources

3

Reference Data Type table Column type Column Name Column Meaning Example Value

Organization Name approving the value domain

Content Reference Data Column Name

The name of the column that is to contain reference data values

Gender

Relationship <not applicable for this example> Notice in the Reference Data Type table, the actual values for Gender are not present. That is because the actual values are contained in a different table, the Reference Data Values table. The columns for the Reference Data Values table are:

Reference Data Values table Column type Column Name Column Meaning Example Value Uniqueness Reference Data Value

Id A unique number that causes the selection of just one row of data from the data table.

279

Metadata <not applicable for this example>



Gender

Reference Data Column Value

A value that is allowed to exist within this specific reference data value domain.

M

Reference Data Value Meaning

The definition that is assigned to that specific reference data value.

Male

Relationship Reference Data Type Id A number that relates a row of the Reference Data Table to a row in the Reference Data Type table.

1947

With this two-table strategy, single column reference data can be easily represented. The Reference Data Type table identifies the column that is to contain the reference data. It additionally would contain the adjudication information that indicated when the values start and end. The Reference Data Values table contains as many records as needed to represent each of the values. 2.2 Multiple Content Columns Reference Data For complex reference data, where there are multiple “content” columns, the example above needs to be extended. For example, suppose the reference data is for manufactured parts, and for each part there is a Part Number, a Part UPC, and a Part Name. This data might be employed as reference data because the Part Number and a Part Name could be retrieved on the basis of the Part UPC, or the Part Number and Part UPC retrieved through a search on the Part Name. The reference data solution for this class of reference data requires four tables: Reference Data Type, Reference Data Classification, Reference Data Prime Column Value, Reference Data Additional Column Values.

4

The first table, Reference Data Type table, the adjudicator organization name would be “Manufacturing.”

Reference Data Type table Column type Column Name Column Meaning Example Value Uniqueness Reference Data

Identifier A unique number that causes the selection of just one row of data from the data table.

1947

Metadata Value Start Date The date the value was first able to be used.

01/01/1985

Value End Date The date the value was last able to be used

01/01/1998

Adjudication Date The date the value was determined acceptable

10/15/1984

Adjudicator Organization Name

The name of the organization approving the value domain

Manufacturing

Content <not applicable for this example> Relationship <not applicable for this example> The second table, Reference Data Classification is employed as a way to identify the overall classification of the type of reference data. That is, Parts Reference Data.

Reference Data Classification table Column type Column Name Column Meaning Example Value Uniqueness Reference Data

Classification Id A unique number that causes the selection of just one row of data from the data table.

575


Content Reference Data Classification Name


Parts Reference Data

Relationship Reference Data Type Id A number that relates a row of the Reference Data Table to a row in the Reference Data Type table.

1947

The third table, Reference Data Column table identifies the set of reference data columns that belong to this reference data column set. In this example, the table shows Part Number. For this example there would then be two additional records, one for Part Name, and the other for UPC Code.

Reference Data Column table Column type Column Name Column Meaning Example Value Uniqueness Reference Data Column


279




Part Number

Reference Data Value Meaning

The definition that is assigned to that specific reference data value.

The business identifier for this part.

5

Reference Data Column table Column type Column Name Column Meaning Example Value Relationship Reference Data

Classification Id A number that relates a row of the Reference Data Table to a row in the Reference Data Type table.

575

The fourth table, Reference Data Values table contains, for example, the records that contain the values for the Part Number reference data column. There would be as many different records as there are Part Numbers. What keeps the adjacency correct between the value for the Part Number and the Part Name, and Part UPC Code is the relationship column, Sibling Reference Data Value Id. Suppose, for example, that the Part Name record was stored in the third table, Reference Data Column. Suppose further that the proper value for that was: Hard Disk Controller, and that record’s Reference Data Value Id was 698. The value then in the Sibling Reference Data Value Id would be 698. That would enable the reference data management software to know that a sibling value existed and to be able to retrieve it.

Reference Data Values table Column type Column Name Column Meaning Example Value Uniqueness Reference Data Value


985


Reference Data Column Value

A value that is allowed to exist within this specific reference data value domain.

AQ-98-378

Relationship Reference Data Column Id

A number that relates a row of the Reference Data Values Table to a row in the Reference Data Columns table.

279

Sibling Reference Data Value Id

A number that relates this row of the Reference Data Values Table to the Reference Data Values row that is the values row for the sibling reference data column. The value that signifies that there are not more siblings is the “Null” value.

698

With this four-table strategy, multiple column reference data can be represented, although in a more complicated manner than single column reference data. The Reference Data Type table identifies the adjudication information. The Reference Data Classification table identifies the class of columns that are to be managed. The Reference Data Column table contains the column names that are being managed, and the Reference Data Values table not only contains the managed values but also the one-to-one relationships among the managed values in that multiple-column set.

6

2.3 Sequenced Reference Data A variation on either the single content column or the multiple content column reference data type is sequenced reference data. In the case, the reference data values must either proceed in a forward or backward strict sequence, or can skip values forward or backward. Regardless, the general approach that is most commonly applicable is that any given value must be preceded by a previous value. For example, the values, Saved/Draft, Initial, Active, No Show, Inactive, and Terminated are essentially indicators of state based on well-defined assessments of a collection rows that may exist within one table or across multiple tables. In the example, the rules may be that the Initial state cannot exist except as a successor to a Saved/Draft state. Or, that the Terminated state cannot be set without the Active state having been achieved. Some states, such as No Show, Inactive, or Terminated may exist in parallel and are only dependent on the prior state of Active. Representation of reference data sequence rules requires an additional level of sophistication the reference data tables. If these more sophisticated reference data tables exist then an application program can query an existing state, know what can only be allowed as a successor state, and if an inappropriate state change is attempted, it can be rejected. If these states are represented as data, they can be changed without having to find all the different application programs in which they have been encoded, propose and accomplish software changes, perform testing, modify user-guide documentation, and the like. With this strategy, single or multiple column reference data that is to be sequenced one set after another can be represented. The value of managing this sequence in the database is that it prevents any required encoding of a sequence in the application programs. Additionally, rules can be established and placed in the database that provides triggering information to the application program whenever any sequence “transgression” occurs. 2.4 Mapped Values Reference Data The ability to map reference data values one to another is needed for a number of different reasons. The four most common cases are:

Single or multiple content column value changes Reduced quantity of reference data values Expanded quantity of reference data values External interfaces to other application systems and databases

In the first case, single or multiple content column value changes, whenever a single or multiple content column value changes, both the previous and current values may need to be presented in order to represent history. Additionally, if the values are “changed in

7

place,” databases with millions of records and significant quantities of reference data columns can consume large quantities of computer resources to effect the data value change. For example, if the actual value (e.g. Gender = “F) is stored in the database and the value needs to be changed to “Female,” then, when the change is needed, all the records with “F” have to be retrieved and the gender column value changed to “Female.” This has two problems. First, the previous value of “F” is now lost if there hasn’t been an audit trail record created for each of the changed records, and second, there can be a significant quantity of computing resources expended for this change. If there were a million records and half were “F” then there would 1) have to be 500,000 records changed and also 500,000 audit trail records created. An alternative to this approach is to create an additional reference data valid value record for “Female” that has as its starting date and time the very same ending date and time for the “F” reference data record. What has to be in place is a method to point from the “F” reference data record to the “Female” reference data record. With this approach, none of the half-million records have to be changed. When the actual gender is needed for a person, the reference data value is retrieved. If there is an “end date” value, the “pointer” is employed to retrieve the current value for that reference data field. This technique works when there is the same quantity of valid values after a change as there was before. In the second case, reduced quantity of reference data values, several values may be replaced by a single value. Suppose there were the values: Saved, Draft, Initial, Active, No Show, Inactive, and Terminated. Suppose the new set was to combine the values Saved and Draft into just one value, Saved/Draft. In this case the two discrete values would have to point to the same new value. This approach is straight forward if the mapping is always “forward.” But if it’s backwards, it would not be known what the prior value for Saved/Draft had been. That is, either “Saved” or “Draft.” To accomplish this, an additional layer of reference data table structures and supporting processes needs to be created. In the third case, expanded quantity of reference data values, suppose the current values are: Saved/Draft, Initial, Active, No Show, Inactive, and Terminated. Suppose the new values are to be: Saved, Submitted, Preliminary Acceptance, Accepted, Active, No Show, Inactive, and Terminated. In this case, business rules need to be created or changed that enable a re-casting of the reference data values. In this situation, not only must there be additional reference data table structures, there would also have to be the identification of the business rules that would provide the unambiguous knowledge to know the conditions supporting the mapping of some of the “Saved” records to “Saved” another set to “Submitted” and so on. In the third case, where there are interfaces to external systems either for data importing or exporting, there has to be reference data value mappings from the various reference data based external system data fields to the current set of reference data. These fields

8

have to be discovered; their reference data values and meanings uncovered and then stored in into the reference data tables. In the fourth case, external interfaces to other application systems and databases, on importing, an external data record is read, its fields and values are known, and known as well are the transformed-to values. If all these values are stored in the reference data tables, the data importing programs do not have to contain all these value transformation rules. On exporting, this same general strategy applies for exporting data except in reverse. In either scenario, it is best to have the reference data tables contain all the value mappings and any necessary supporting rules for value mappings so that they are explicitly visible, are data not program based, and can be more easily changed than from within programs. 2.5 Discrete Values Reference Data Discrete values reference data simply means that the values are enumerated. If the values from 1 through 10 are to be allowed, then all 10, that is, 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10. A common capability for representing discrete values is the ability to indicate that certain discrete values are not allowed. So, if all between 1 and 4 but not 3, then the list would either contain mechanisms to express both. This capability should exist on either single content or multiple columns, and also on sequenced value and mapped value columns. 2.6 Range of Values Reference Data The immediately preceding example demonstrates the need to express ranges of values, such as 1 through 10, or 1 through 3, and 5 through 10. Negative ranges are commonly expressible as well. So, 1 through 3, not 4 through 6, and 7 through 10 would be expressible. 3.0 Reference Data Updating and Maintenance Issues related to changes to reference data values parallels the Section 2 six reference data cases. Some of the update anomalies have already been addressed above and are cited. Of overall concern is what happens to a reference data value that was once valid and through a change has now become invalid? In this situation, there will have to be a thorough examination of how the formerly valid reference data values were stored in the database. How are they discovered? Can it be automatic? Or should it ever be automatic? Regardless, how will the already stored invalid values be changed? Will prior generated reports have to be re-executed and the difference in counts and other statistical and/or financial summaries have to represented along with explanation?

9

3.1 Single Content Column The key issue with single content column value changes is whether history is to be retained or not. If not, there is no need to retain the previous value. In this case, there would be an automatic and complete recasting of one value and meaning to a different value and meaning. However, if history needs to be retained, this case immediately turns into a mapped value case where the old values are mapped to the new values. Of especial concern is whether a reference data value’s meaning has changed. If it has, and if the new meaning is to have the prior meanings retained, then again, this case immediately transforms to a mapped values case. 3.2 Multiple Content Columns The updating concerns in this case are the same as for single content columns except that the value changes are possibly tracked as collection. 3.3 Sequenced Sequenced values are inherently more complex. That’s because, for example, two additional states might have been introduced prior to a given state. All the business rules that enable an exact determination of all the states need to be very carefully examined to be assured that when the rules are executed the new set of sequenced states are able to materialized. 3.4 Mapped Values Mapped values are also inherently more complex. That is because there will be prior mappings and new mappings. Each changed mapping set has to have the same end-date and start-dates so as to avoid unmapped intervals. If the mappings change, the various statistics, especially as they relate to importing and exporting from external systems may change and need to be explained. This will be especially so in situations where the quantity of source and target mapped values have changed. 3.5 Discrete Values Discrete values are similar to single content column values except if an existing value becomes no longer valid. For example, if there were the six discrete values, 1, 2, 3, 4, 5, and 6 and under a new scheme 5 is now seen as invalid, this case transforms to a mapped value case because the value 5 now has to be mapped to either 4 or 6. Otherwise the reference data value becomes invalid and cannot remain in the database as such. If a new

10

value is allowed, it may be necessary to revisit prior business event executions to determine if previously excluded data should now be included. Similarly, if a value is no longer allowed, prior data inclusions would have to be discovered and examined to determine what to do about what now becomes invalid data. 3.6 Range Of Values Ranges of values are similar to discrete values except if an existing begin or end value becomes no longer valid. For example, if there was the existing range, 1 through 6, and the new scheme was 1 through 7 then an examination would have to be conducted to discover if previously invalided records with the value 7 and now need to be included. Similarly, if the new range was 1 through 5, then an examination of some existing records that formerly passed a range test would have to be examined to determine appropriate actions. 4.0 Recasting Data The most critical issue surrounding reference data is what to do when acceptable values change. Within the reference data community this is sometimes called “recasting.” Simply, recasting means that when a reference data value and/or meaning are changed, the understanding resulting from effectively the same queries and/or reports may also change. The three common cases are:

Single value change (with and without history). Organizational relationship change (with and without history) Meaning Change (with and without history)

For the first case, single value change (with and without history), some changes are simple and others are significantly more complex. Simple cases change, for example, the value of “F” to “Female.” In this situation, there is no recasting of the meaning of reference data value, only the value itself. SEVIS II reports that include historical data will have to be able to not only obtain reference data values via their surrogate reference data values, but also have to discover and access any changed values that are, by SEVIS reference data design represented by different reference data surrogate Id values. For the non-reporting SEVIS II database, this strategy necessarily involves having “Where” clauses constructed such that the allowed reference data values (Gender = “F” or Gender = “Female”) to be constructed. If a specially constructed reporting database is constructed, this issue may be mitigated. For the second case, organizational relationship changes (with and without history), zip codes provide a ready but simple example. Zip codes change from time to time. Some entirely new ones are added, and some existing ones are split. For example, the “city”, Hershey, PA does not really exist. It’s just a U.S. Postal Service designation. If the USPS

11

changes “Hershey, PA” to “Derry Township, PA” what happens to all the existing addresses for “Hershey, PA?” This would cause certain existing addresses that were formerly valid to now be invalid. Additionally, it might appear that Derry Township doubled in size if the report was based on its zip code. More importantly for SEVIS II is the possibility of invalid addresses that were once valid and are now stored in the SEVIS II database. How are they discovered? How are they corrected? A more critical example of organizational relationship changes would be the history of certain organizations within the SEVIS II database. Organizations can change through either acquisitions or losses. How is that history of changes reported over time? From one year to the next a given organization can take on a completely different set of statistics. If longitudinal graphs are shown, there could be some real surprises. For the third case, meaning Change (with and without history), reference data recasting can be very problematic. For example, suppose there are five values before, such as Draft, Submitted, Approved, Denied, and Terminated. Suppose the meaning of Denied is changed from the meaning, Administrative Reasons, to also be understood as Administrative and Fraud Reasons. Applications that were formerly denied for simply administrative reasons may now be seen as being denied for a very different set of reasons. While such a change can be accomplished through the reference data case, mapping, the real issue is reporting. All these cases require very careful analysis and assessment to understand the complete implications of making reference data changes. All three reference data recasting cases apply to all six of the reference data types. 5.0 SEVIS II Reference Data Architecture The SEVIS II data models have color coded the current set of reference data columns. These are the columns in “green.” The strategy employed by SEVIS II is not to store the actual data value in the record, but store the identifier of the reference-data record that contains the actual value. This is clearly a step in the right direction because when a reference data value changes for a particular column, for example, in the I-17 data element, Education Level, from “Non-Degree” to say “No-degree,” the only update that must occur is to retrieve the reference data record that contains the actual value, “Non-Degree” and to change it to “No Degree.” Immediately, all the SEVIS II data records that employ that column will then be seen as having the allowed value of “No Degree.” Under a current understanding of the SEVIS II database architecture, the current reference data strategy is not sufficient. The Reference Data cases that are handled in the current SEVIS II reference data design are indicated fourth column in the table below. Reference Data Case

Reference Data Type

Description June 2009 SEVIS II Database Design

1 Single Content Column

A single column of reference data such as a person name’s Salutation (e.g.,

Yes, but without adjudication metadata.

12

Reference Data Case

Reference Data Type

Description June 2009 SEVIS II Database Design

Dr. Ms, Mr.), Gender (e.g., M, F, U), or Suffix (e.g., Sr. Jr, III)


Multiple columns declared to be treated together (e.g., Part Number, Part UPC, and Part Name)

No

3 Sequenced Single or multiple columns of reference data that proceed in a strict sequence (e.g., Saved/Draft, Initial, Active, No Show, Inactive, and Terminated)

No

4 Mapped Values

Single or multiple columns of reference data that have changed values and/or meanings across time, or that represent a “transformed in” value from a set of inward interface processes or “transformed out” value for a set out outward interface processes. Mapped values may also represent a reduction in the quantity of “mapped to” values from a set of “mapped from” values. The converse is also possible.

Partially (only single values to single values), and without adjudication metadata.

5 Discrete Values

Specific enumerated values that can be additionally allowed or disallowed. There can be multiple sets of discrete values, some allowed and other disallowed.

Yes, but without adjudication metadata.

6 Range Of Values

Specific ranges of values that can be additionally allowed or disallowed. There can be multiple sets of value ranges, some allowed and other disallowed.

No

6.0 Necessary Mitigation Strategies The following mitigation strategies seem appropriate:

Determine from FRD requirements and from an examination of the level of sophistication required to handle reference data within SEVIS II.

Create a suitable collection of data structures that allow full reference data value and meaning tracking across all six reference data types.

Cross relate all reference data values to individual database columns to ensure consistency of creation and updating.

Ensure that all sequence reference data values (either forward or backwards) are properly engineered within SEVIS II application system logic.

Ensure that all use cases and follow on wireframes and developed software properly deploy reference data values.

13

Ensure that all reference data values are mapped back to policy, regulation, or law and are properly supported by appropriate metadata (why, why, and with what authority).

Regardless of the employed mitigation strategies, if there is not a comprehensive and highly engineered approach to reference data management, the ability for IV & V to perform its SOW’s required tasks in regard to database engineering will be severely crippled.


A13 OPR_Business Transaction History_20090720


63

1. IV&V Observed Potential Risk Statement SEVIS II is designed to record the content data related to business events. It may not yet be engineered to record 1) the business events themselves, 2) the history of the business events, and 3) the interrelationships among business events. Collectively, all three are referred to as “history” in this OPR. The requirements for history are described in the FRD (Functional Requirements Document, V1.0, 2/15/08), and have been discussed by SEVP and the Department of State during requirements meetings. If these requirements are confirmed by the business owners, additional analysis, design and rework will be required to ensure that history is captured, recorded and interrelated as needed by SEVIS II.

2. Summary Observation Discussion The FRD contains more than 50 requirements relating to history, including: MC 2116, MC 2173, LAH 2713, JE 3112, and DQ 3316. Booz Allen Hamilton has designed a database that records the content-data resulting from business events. The design also includes a set of shadow database tables that retain full logs of updated content-data. Not apparent in the database’s design is the ability to record 1) the business events themselves, 2) the history of the business events, and 3) the interrelationships among business events. SEVIS II history data includes at a minimum, the “who, what, when, where, why, and how” of each business event, and the pedagogy among the recorded business events. The data creation components of SEVIS II have both content and history data. For example, the on-line component of SEVIS II interactively creates data for the I-17, an I-20, a DS-3036, and the DS-2019. SEVIS II data is additionally created through batch and from interfaces such as the I-901, Pay.gov, and SEVPAMS. In general, all sources of data should meet content and history requirements. An examination of the approved use-cases from Product 6 shows that four unique history requirements were allocated (JE 3112, MD 2900, LAH 2713, and JE 3103.4). In contrast, through an independent IV&V effort, 42 out of the more than 50 history requirements were assigned. There appears to be a significant difference in the history requirements allocation that should be explored and reconciled. A reason for this variance may be a difference in interpretation. However, if history requirements are not accurately allocated to the use cases as intended by the requirement owners, SEVIS II history is at risk for not being properly collected, stored, and reported as intended. In summary, no single set of general requirements for history exists for SEVIS II. Without a clear expression of requirements and subsequent reflection within the use cases and data model, SEVIS II functionality may not contain the features desired by business owners.

3. Assessment a) Maturity Evaluation: Respondent aware of requirement – not yet implemented b) Risk Management Evaluation:

• Likelihood is ‘Likely’ (level c) • Consequence is ‘Minor slip in key milestones’ (level 3) • Risk Assessment is (Y) Moderate – Some disruption may occur. Additional

management attention may be needed.

1

c) Standard/Guidance: DAMA DMBOK, Chapter 10, Records Management; ISO standard 15489:2001.

4. Recommendations

It is recommended that the requirements owners determine a single set of history requirements and communicate them to Booz Allen Hamilton for incorporation within use cases and subsequently to the data model.

2


A14 OPR_Data Management Four Problem Areas_04_24_09


64

1

The observed potential risks associated are:

1. Contractor Work Breakdown Structure 2. Data Management Products Schedule 3. Data Management Components of Use Cases 4. Data Management Maturity Assessment

Each of these observed potential risks is discussed separately Contractor Work Breakdown Structure 1) IV&V Observed Potential Risk Statement

The Booz Allen Hamilton Work Breakdown Structure (WBS) as evidenced in the project’s published overall schedule does not have sufficient detail to determine if all the necessary components of data management are being addressed.

2) Summary Observation Discussion The process of evaluating the data management component of SEVIS II begins with a comprehensive WBS. From a comprehensive WBS it can be determined what factors will be involved in the determination of the overall SEVIS II data model and how the data models are functionally related to all the other SEVIS II work products. Without a comprehensive WBS it cannot be determined how the staff assigned to data management will gather their requirements from, for example, requirements meetings, use-case walk thru, business rule meetings, XML schema development, value domain management, user-acceptance test engineering and conduct, and the like. More importantly, it is not understood how the use-case discussions that surface data-based issues, sometimes called “data-stories” are reflected in the data management work products. These “data stories” relate to use cases, business rules, valid-value domains, and changes in business requirements. Finally, it is not clear how changes to application software architecture, engineering, coding, and testing are integrated with data modeling efforts. In addition to a large body of published knowledge that exists in regards to the development of data models and the integration of data management activities within application software development, there are two maturity assessment guides that contribute to an independent rating. These are: the Data Management Maturity Model (DM3) that is engineered along the lines of CMMI, and the Levels of Conceptual Interoperability Models (LCIM).

2

3) Assessment

a) Maturity Evaluation:

Process and Process Maturity and Quality: Component Not Evident CMMI Data Maturity: DM3 – 1, LCIM – 1

b) Preliminary Estimated Risk Evaluation: Likelihood: The Likelihood level of the risk is “e,” near certainty. Consequence: The Consequence Level is: 4. That is, there will be a major slip

in a Key Milestone. The Risk Assessment level is R. Consequently, the overall Risk Assessment from this observed potential risk is Red.

Risk Assessment: 4e, or Red. c) Standard/Guidance:

CMMI type organization and process: (1) DM3 materials, (2) LCIM materials.

DM IVV Architecture and Concept of Operations. ICE System Lifecycle Management (SLM) Handbook, Version 1.2. Data Reference Model (CIO Council Data Architecture Subcommittee)

4) Recommendations a) A request will be made for additional methodology and WBS documentation

regarding how Booz Allen Hamilton is going to accomplish their data management activities.

b) A request will be made to Booz Allen Hamilton for materials that will indicate how SEVIS II application architecture, engineering, and implementation activities are monitored by BAH data management staff.

c) A request will be made to Booz Allen Hamilton for materials on how the application architecture, engineering, and implementation activities are informed and how they react to required changes that occur in data management work products.

Data Management Products Schedule 1) IV&V Observed Potential Risk Statement

An examination of the CWBS and the schedule of the project plan dated 4/17/2009 provide very little ability to understand whether there has been sufficient time allocated and/or whether there are the necessary and sufficient activities to successfully accomplish a full complement of data management activities. This potential risk is substantiated by the almost 15 full pages of concerns that were clearly evident after just two weeks evaluation of the Exchange Program, School, System Administrators, and Payment data models

3

2) Summary Observation Discussion The work breakdown structure for data management is too scant to judge if there is a schedule that interacts appropriately with the other non-data-management activities in the project. The tasks for the logical database components are: Domain Model updated. Logical Data Model Requirements Logical Data Model updated Data Dictionary updated The tasks for activities associated with the physical data model and the association of the physical data model to the application software systems are: Physical Data Model Design (first and final iteration) Source to Target Mapping Design (first and final iteration)

Each of these WBS entries has no further task breakdown, no products identified, no real dependencies that would be associated with the many other products associated. Because of the sparseness of the data management WBS elements, and because it cannot be ascertained how the data management staff are integrated with the other BAH teams that are developing the system, there appears significant risk to the project.

3) Assessment

a) Maturity Evaluation: Under both these models of assessment, the existing assessment of the SEVIS II data management effort is at Level 1, which is the lowest level.

b) Preliminary Estimated Risk Evaluation:

c) Likelihood: The Likelihood level of the risk is “e,” near certainty. d) Consequence: The Consequence Level is: 4. That is, there will be a major slip


e) Risk Assessment: 4e, or Red. f) Standard/Guidance: 1) CMMI type organization and process: DM3 materials, 2)

LCIM for data interoperability: LCIM published materials. 3) DM IVV Architecture and Concept of Operations. 4) ICE System Lifecycle Management (SLM) Handbook, Version 1.2. 5) Data Reference Model (CIO Council Data Architecture Subcommittee)

4) Recommendations

4

a) A request will be made for additional methodology and WBS documentation regarding how BAH is going to accomplish their data management activities especially given the quantity of staff days allocated to the data management activities.

b) A request will be made to BAH for materials that will indicate how SEVIS II application architecture, engineering, and implementation activities are monitored by BAH data management staff.

c) A request will be made to BAH for materials on how the application architecture, engineering, and implementation activities are informed and how they react to required changes that occur in data management work products.

Data Management Components of Use Cases 1) IV&V Observed Potential Risk Statement

An examination of the use cases lead to the conclusion that they are either not business-based enough for functional users to understand whether the use cases meet functional and/or regulation requirements, or are not sufficiently detailed with respect to the technical requirements of data management.

2) Summary Observation Discussion The first risk identified above, business-based use cases, has been expressed in almost every use case review that has been attended by IVV and so it will not be addressed here other that to indicate:

It is not clear how to walk-back from the use cases to the CWBS element under which they are created, and/or walk back to elements of the Functional Requirements documents.

It is not clear how the use case implied behavior is mapped, replicated, or

changed from SEVIS I and SEVIS II.

It is not clear how the use cases map to any Federal Regulations that might govern the use case’s behavior.

As to the second risk, technology and data management based use cases, an examination of the use cases seem to be lacking a clear path to Business Rules, as opposed to data entry field level edits and validations, and other critical data management artifacts. For example in the use case, Form DS-2019: Create/Update (Certificate of Eligibility for Exchange Visitor Status), the specific business rules within Attachment A seem to be individual field value edits as opposed to independently defined as table constraints, or triggers.

5

It is not clear how and in what way the Appendix A Data Element Business Rules are applied to the various steps in the use case. It is not clear what the cross reference is between Appendix A Data Elements and the columns in the various database tables. Finally, the use case seems to be lacking for example, the appropriate database selection, and inter-table navigation logic. Without this information it is difficult to accurately evaluate the sufficiency of the use case. If there is an additional specification and documentation step between the use cases as they are currently presented and the actual software system code in which all these missing items are incorporated then maybe these documents should be referenced and attached so that a complete evaluation can be made. It is not clear how the various use cases will be turned into User Acceptance tests where a high level of the tests will be business-function and/or business transaction based and then a lower level of user acceptance tests whereby every screen field and or executed business rule will be identified and tested.

3) Assessment








regarding how BAH is going to comprehensively develop use cases such that they contain the necessary and sufficient detail to directly guide the development of computer software.

b) A request will be made to BAH for materials that will indicate how SEVIS II use cases will be employed to directly create all the user acceptance tests..

6

c) A request will be made to BAH for materials on how the application architecture, engineering, and implementation activities are informed and how they react to required changes that occur in either use cases or any changes in use cases that may affect data management work products.

Data Management Maturity Assessment 1) IV&V Observed Potential Risk Statement

The level of data management maturity cannot be accurately assessed with respect to either of the two kinds of data management maturity: 1) Organization and Process (via DM3), and 2) Levels of Conceptual Interoperability Model (LCIM).

2) Summary Observation Discussion Studies of over 100 organizations in the past 10 years in regards to data management maturity from the point of view of organization and process has produced a direct correlation between the assessed maturity level and the performance of the organization in the development and evolution of data-centric application information systems.

3) Assessment







4) Recommendations


A15 OPR_Data Management_DM Maturity Review_04_24_09


65

1



2) Summary Observation Discussion Studies of over 100 organizations in the past 10 years in regards to data management maturity from the point of view of organization and process has produced a direct correlation between the assessed maturity level and the performance of the organization in the development and evolution of data-centric application information systems.

3) Assessment







4) Recommendations


A16 OPR_Data Management_Use Case Review_04_24_09


66

1

Data Management Components of Use Cases 1) IV&V Observed Potential Risk Statement

An examination of the use cases lead to the conclusion that they are either not business-based enough for functional users to understand whether the use cases meet functional and/or regulation requirements, or are not sufficiently detailed with respect to the technical requirements of data management.

2) Summary Observation Discussion The first risk identified above, business-based use cases, has been expressed in almost every use case review that has been attended by IVV and so it will not be addressed here other that to indicate:

It is not clear how to walk-back from the use cases to the CWBS element under which they are created, and/or walk back to elements of the Functional Requirements documents.

It is not clear how the use case implied behavior is mapped, replicated, or

changed from SEVIS I and SEVIS II.

It is not clear how the use cases map to any Federal Regulations that might govern the use case’s behavior.

As to the second risk, technology and data management based use cases, an examination of the use cases seem to be lacking a clear path to Business Rules, as opposed to data entry field level edits and validations, and other critical data management artifacts. For example in the use case, Form DS-2019: Create/Update (Certificate of Eligibility for Exchange Visitor Status), the specific business rules within Attachment A seem to be individual field value edits as opposed to independently defined as table constraints, or triggers. It is not clear how and in what way the Appendix A Data Element Business Rules are applied to the various steps in the use case. It is not clear what the cross reference is between Appendix A Data Elements and the columns in the various database tables. Finally, the use case seems to be lacking for example, the appropriate database selection, and inter-table navigation logic. Without this information it is difficult to accurately evaluate the sufficiency of the use case. If there is an additional specification and documentation step between the use cases as they are currently presented and the actual software system code in which all these missing items are incorporated then maybe these documents should be referenced and attached so that a complete evaluation can be made.

2

It is not clear how the various use cases will be turned into User Acceptance tests where a high level of the tests will be business-function and/or business transaction based and then a lower level of user acceptance tests whereby every screen field and or executed business rule will be identified and tested.

3) Assessment








regarding how BAH is going to comprehensively develop use cases such that they contain the necessary and sufficient detail to directly guide the development of computer software.

b) A request will be made to BAH for materials that will indicate how SEVIS II use cases will be employed to directly create all the user acceptance tests..

c) A request will be made to BAH for materials on how the application architecture, engineering, and implementation activities are informed and how they react to required changes that occur in either use cases or any changes in use cases that may affect data management work products.



3

2) Summary Observation Discussion

Studies of over 100 organizations in the past 10 years in regards to data management maturity from the point of view of organization and process has produced a direct correlation between the assessed maturity level and the performance of the organization in the development and evolution of data-centric application information systems.

3) Assessment







4) Recommendations


A17 OPR_Data Management_WBS DM Review_05_15_09_


67

1

1) IV&V Observed Potential Risk Statement There is little evidence that the data management activities and other development activities evidenced through the WBS are sufficiently interrelated. The WBS and schedule do not provide enough detail to demonstrate that the necessary activities have been planned. There are few dependency links between other WBS elements outside data management. Consequently, it cannot be determined if sufficient time and effort has been allocated to accomplish comprehensive data management.

2) Summary Observation Discussion Evidence of this observed potential risk was drawn from the Booz Allen Hamilton Work Breakdown Structure (WBS) (SEVIS_II_IMS.mpp (dated: 5/11/09)) and participation in requirements meetings. The WBS does not have sufficient detail to determine if all the necessary components of data management are being addressed and are related back to evolving requirements. What the WBS lacks is a work plan that describes how data requirements are gathered, how they are reflected in the various data management products, and how the data management product changes are reflected in the other development products. During the requirements meetings in which the use-cases are reviewed, it is not evident from the WBS how data management work products reflect use-case discussions and findings. Data is evidenced in all the use-case discussions. Invariably, these discussions surface data-based issues, sometimes called “data-stories.” These stories relate to use cases, business rules, valid-value domains, business transaction histories, and changes in business requirements. How these “data stories” are identified, are defined, are recorded, and are reflected in the data management work products outside of and independently from use case data element level edits is absent in the WBS. The Data Management components of the WBS do not indicate how changes in the software’s architecture, engineering, coding, and testing are integrated with data management efforts, or to changes in the data management work products. Products within SEVIS generally follow the following WBS template: SPM Submit DS-3036

SPM Submit DS-3036 Requirements SPM Submit DS-3036 Design SPM Submit DS-3036 Development & Unit Testing SPM Submit DS-3036 Documentation Update SPM Submit DS-3036 Refactoring

2

The SEVIS II Data Management data management tasks exist within this template across the 12 products and within product packages. There a total of 22 data management task collection repeats (see WBS tasks: 2202, 2309, 2350, 2371, 2516, 2537, 2558, 2661, 2682, 2703, 2724, 2745, 2849, 2870, 2891, 2996, 3090, 3180, 3271, 3292, 3398, and 3419). The data management related tasks are substantively the same and are:

WBS “Data” Task Hierarchy Duration in Days

Days Offset from Start

SPM Submit DS-3036 Requirements Package

SPM DS-3036 Logical Data Model Requirements

13 7 (10/08/08)

Logical Data Model updated for SPM DS-3036

0 23

Data Dictionary updated for SPM DS-3036

0 23

Develop SPM Submit DS-3036 Use Case Specifications

5 6

Update SPM Submit DS-3036 Activity Diagrams 5 6 SPM Submit DS-3036 Design

SPM Submit DS-3036 Physical Data Model Design

8 30

SPM Submit DS-3036 Source to Target Mapping Design

8 30

SPM Submit DS-3036 Development & Unit Testing

There are no explicit data related tasks such as Valid Value creation and testing, Transaction initiation, termination, and rollback.

SPM Submit DS-3036 Data Documentation

SPM Submit DS-3036 Data Documentation update

Logical Data Model updated (Submit DS-3036)

0 35

Data Conversion Plan updated for SPM (Submit DS-3036)

0 60

Data Management Plan for SPM (Submit DS-3036)

0 90

Because of the large quantity of parallel data management development efforts, that is, 12 products and additional subdivisions within each product for packages, there is a need for work product integration and non-redundancy. However, because of the sparseness of the data management tasks and the lack of explicit WBS based task interdependence, it cannot be ascertained how the products and packages are integrated within the overall SEVIS II effort. Hence, there appears significant risk to the project. What is interesting to note in the table above is that there should be the following work products available at approximately the same time:

Use Cases

3

Activity Diagrams Logical Data Model Updated Data Dictionary Physical Data Model Source to Target [data] Mapping

That should enable all these work products to be completely integrated one with the other. For example, use cases should properly reflect the database tables and columns in a final form of the use case. The Logical Data Model should be mapped to the Physical Data Model, and the Physical Data Model should be mapped to the Source to Target Mapping. Finally, the wire-frames (not shown in the table as that is a specific software design task) should be mapped to the Physical Data Model. Since there are 22 repetitions of these task patterns, the SEVIS teams, given a fully integrated set of work products should be more than able to certify that the work products conform to the needs of the SEVIS community. The existing set of work products tell a different story, however. There is no evidence of the data management work product (Logical Data Model, Physical Data Model, and Data Dictionary) integration and mapping to the other work products, that is, to the Use Cases, the Activity Diagrams, and the Source to Target [data] Mapping. Because of this lack of integration and mapping, the SEVIS community would find it very difficult to certify functional conformance. The SEVIS community would then find it exceedingly more difficult to certify functional conformance through an examination of Test Cases that are created. Simply put, there threads across the work products upon which functional requirements can be traced.

Chalk Board WBS is insufficient Analysis of wbs (repeated often) Not all activities are presented Does not describe interaction between data and development Connection between data management and development Analysis of data modes and attendance at requirements meetings Requirements discussions not recorded for impact on data model and other work products. Therefore the risk is that information is not included.

3) Assessment

a) Maturity Evaluation: Process and Process Maturity and Quality, Component Not Evident CMMI Data Maturity: DM3 – 1, LCIM – 1

4

b) Preliminary Estimated Risk Evaluation: Likelihood is ‘Near Certainty’ (level e). Consequence is: Major slip in a Key Milestone (level 4). The Risk Assessment is (R) High -- Unacceptable, major disruption likely.

Different approach required. Priority management attention required. Risk Assessment: 4e, or Red.

c) Standard/Guidance: CMMI type organization and process:

(1) DM3 (Data Management Maturity Model) materials (2) LCIM (Levels of Conceptual Interoperability Model) materials

DM IVV Architecture and Concept of Operations. ICE System Lifecycle Management (SLM) Handbook, Version 1.2. Sections

5.1, 5.2, 6.1, 7.1 8.1, and data dictionary. Data Reference Model (CIO Council Data Architecture Subcommittee)

4) Recommendations The recommendations that follow are data-centric specializations of recommendations that have appeared in previous IVV Periodic Reports such as:

Planning: Section 4.1.3, Configuration Management of Project Data Execution: Section 4.2.2, Iterative Design and Development Execution: Section 4.2.4, Implementation of Planned Activities Execution: Section 4.2.5, Schedule Execution: Section 4.2.6, Configuration Management in Execution of Project

Activities Control: Section 4.3.1, Baseline Control Control: Section 4.3.2, Requirements Traceability

The recommendations are:

a) Identify and document the methodology, documentation and/or approach to data management that Booz Allen Hamilton is employing throughout the WBS.

b) Describe specifically how the additional methodology elements are being

employed during the development of the data models and interrelated components that are set out in Figure 1.

c) Describe how the SEVIS II application architecture, engineering, and

implementation activities are monitored by Booz Allen Hamilton data management staff and set out how the results of these activities are being incorporated into the iterative development of SEVIS II products.

5

d) Describe and illustrate through the WBS and schedule how the architecture, engineering, and implementation activities are informed and how they react to required changes that occur in data management work products.

e) Describe and illustrate through the WBS and schedule how SEVIS II application

architecture, engineering, and implementation activities are monitored by Booz Allen Hamilton data management staff.

f) Describe and illustrate through the WBS and schedule how the application

architecture, engineering, and implementation activities are informed and how they react to required changes that occur in data management work products.

g) Describe and illustrate through the WBS and schedule the process through which

the overall SEVIS II functionality, already divided into 12 products are further divided into packages.

h) Describe and illustrate through the WBS and schedule the process whereby

package contents will be refactored within a SEVIS II product and possibly across products.

i) Describe and illustrate through the WBS and schedule through prototypical

deliverable formats how data management work products are created, updated, and evolved in an integrated, non-redundant, and not-conflicting manner across all the functional areas of SEVIS II especially in an interative approach that is further divided into packages.

6

Figure 1. Data Management Environment within SEVIS II


A18 Requirements Process Sessions, Data Models, and Data ManagementQA


68

Requirements Sessions, Data Models, and Data Management QA From both the old and the new schedules, logical data modeling is to occur at the concurrently with use cases, activity diagrams, and wireframes. That’s very appropriate. The physical data model occurs at design time. That too is appropriate. During these requirements sessions, what is generally concurrently addressed are:

Use cases Activity diagrams Wire frames

During and then after each requirements session, the minutes indicate what effects resulted from the meeting for any of the three items. Users are kept apprised of the evolving status of these critical materials through the publication of new editions. That’s how it should be. Taken together however, they only represent a partial story because there are no impact reports or statuses on the data models. The use cases present the overall business process logic and include: use case steps, use case business rules, and use case [business] data elements. The activity diagrams present a process flow diagram for the use cases. The wire frames present a very early “design” rendition of how one or more use cases work together and “call” different contained processes. All these items are related to either a specific use case, or in the case of the wire frames, often represent the combined process logic of multiple use cases. Analogous to knowing the combined processes through the wireframes from across the use cases, the logical data models represent the persistent data effects from one or more use cases. As use cases are developed within a given package, the data modeler is easily able to know if a business data element is new or is represented by an already existing database table and column. That information can and could be easily recorded into adjacent columns of the Appendix A Data Elements of the use case. The data modeler would have his copy of the data models “open,” and he would be able to cut and paste the table name and column name into his copy of the use case’s Appendix A. After the requirements meeting, the data modeler’s Appendix A could be reviewed by the other requirements team members and copied over into the “for the record” copy of the use case. A use case’s effects on the logical data model are knowable when the use case is first drafted. If this were done, there could be immediate feedback on the ability of the data model to handle the use case. As you heard in the CRB/CCB on August 11, there was confusion as to just what the data model “said.” I had the data models in front of me, and it became very clear from the discussion that nobody knew, in any definitive way, whether certain columns existed (Calendar Number (SCR #1143), and Program Unique Identifier (SCR #1146) ). Had the data model information been recorded in the use case, as is clearly best practice, I believe there would have been less confusion. That prompted me to do an analysis last August 12 and convey to Nelofur just what the data model “said,” and what

the alternatives were for accomplishing Ann’s very clear and emphatic direction. If Jim Gawn had been on the call rather than on vacation, I am sure that he would have immediately responded with that information just as he has done in the past. In addition to helping complete both the process and data sides of requirements, as we heard over a month ago, there is also a benefit to the testing team as they construct test cases from having the database tables and columns adjacent to the business data elements in the use cases. If both process and data were agenda items in every requirements meeting, this would enable the requirements team (SEVP, Department of State, and BAH) to: 1) QA the process artifacts (use case, activity diagram, business rules and wireframes), and 2) QA the data artifacts (business data elements, database tables and columns, application of business rules, reference data values, and appropriateness of definitions). Right now, it seems that they are just “QAing” the process artifacts. There’s no formal “QAing” of the data artifacts. If this were done, the collection of “Appendix As” from all these use cases could be employed immediately as a way to produce, at a minimum, the following analysis reports:

If the same business data element has different definitions across the use cases. If the same business data element has different data types across the use cases. If the same business data element has different business rules across the use cases. If the same business data element has different reference data values across the

use cases. If the business data elements always map to the same database table and column. A complete set of business rules for a given business data element by database

table and column. A general sequence of execution of business rules by wire-frame process, then by

use case cross referenced to database table and column. A specific sequence of execution of business rules by wire-frame process, then by

use case step cross referenced to employed data element that is related to database table and column. (Note, this requires the exact business data element’s name to be used within the use case step.

An enumeration of all the use case processes including business rules by database tables and columns.

There are a number of ways to accomplish these analyses. Here are three: 1). First, engineer a set of Excel spread sheets for database table, column, business rule, wireframe, wire-frame contained process, use case, use case step, [business] data element, UseCaseStep with BusinessDataElement association, and [database table] column and data element association. Process each use case, starting from use case one in product one and copy and paste these data into the various Excel spreadsheets,

interrelating them as appropriate. This process is obviously very tedious and likely very error prone. 2) Accomplish the above but instead of spread sheets, make database tables through MS/Access. Build scripts to import Appendix A data into the various MS/Access tables. Build and use “relationship processes” to create appropriate associations. Use MS/Access reporting to generate the analysis reports. Properly engineered, this MS/Access database could generate the use case Appendix A attachments for the use cases. 3) See if Booz Allen Hamilton has amended RecPro to include business data element and database table and column as they indicated they would about a month ago. If they did, and if the RecPro has been loaded with these data, and if Jim Gawn has done (or is doing) the cross reference, I presume that RecPro’s reporting function could generate many of the analysis reports above. QA could then be done. I do not know if this would be as flexible as the MS/Access option, or whether there can be exports from the MS/Access database to load and cross reference the RecPro tool and database. Under any of these scenarios, if we received the analysis reports and developed findings and recommendations, we would not, I surmise, be doing IV&V. Rather, we would be doing data management QA. While I would rather just do IV&V, I fear that nobody is doing data management QA. From the last time the data models were reviewed (end of April 2009), the whole session was just several hours, and everybody was left to their own devices to figure out how or if there were appropriate business data element to database column and table mappings. I have little doubt that nobody traced use case data elements to database tables and columns. That is what would have been required to accomplish the data model QA. In the past when I have held data model review sessions I have taken each use case through the data model to ensue that reviewers understood just where the data was coming from and where it was stored in the database. That’s just best practice. For sure QA is being done by SEVP and Department of State on the process materials. That is, QA on the Use Cases, Activity Diagrams, and Wire Frames all during the Requirements meetings. Nobody is doing QA on the data management materials. Who is to do this? What are their tools? When are the sessions? Where are any of the results? If the answer is simply the Data Management Plan document, it is wholly inadequate. There are no trace backs from the tables and columns to the use case business data elements. There’s no comprehensive ability to deal with reference data, or parameter values. Finally there is no comprehensive treatment of business rules to determine conflicts, redundancy, and execution sequence. I am left to conclude that since “data” QA is not being done by the requirements teams during their meetings, it’s not being done at all. Data management QA is an essential requirements function. That’s just best practice. In regards to the data modeling tool, Erwin and its stored data models, each Erwin database table column can be derived from a “domain.” A domain can be employed to

function as a business data element. Right now, however, the Erwin data models identify “domains” as Integers, Strings, Decimal Numbers, etc. Instead, if the business data elements were all loaded into the Erwin “domain” component, the database tables and columns could be referenced back to their domain-based data elements. While this would help somewhat, it’s important to remember that the business data elements are defined within the context of use cases, not SEVIS II as a whole. This would force a generalization of use case business data elements into a set of SEVIS II wide data elements. This would be good as it would likely surface semantic conflicts between SEVIS II data elements and use case based data elements. Erwin’s tables, columns, definitions, and the like can all be exported from Erwin and loaded into MS/Access tables if that approach is taken to support data management QA. Thus, there would no need to abandon Erwin as a data modeling tool. I do not know if this type of import capability exists within RecPro. It therefore may be that the MS/Access approach is more efficient and more effective for accomplishing data management QA. The business rules from the use case business data elements could also be extracted and stored in the MS/Access database. Like data elements, a generalized SEVIS II set should be created and mapped to the use case based set of business rules. Redundancies and conflicts could then be quickly discovered. The Erwin tool can also store data constraints on a per database table column basis. For example, in the Erwin logical view of the Person table, the column, Gender, has the following definition: Gender of the person (Male or Female). But in the Physical view of the same table and column, there’s a “comment” with the value, “A one-character code indicating the Gender of the person (Male or Female). M/F.” These two, definition and comment, should not only be one and the same, but the valid values (M/F) should be stripped off. Instead, these gender value constraints, M/F, should be put into the constraint field. If that were done, Erwin could generate a column based SQL DDL constraint clause that would only allow the values, M or F. Right now, the SEVIS II application layer has to enforce the value, M/F. Alternatively, if Gender had been a reference data element (Gender_Id), the SEVIS II reference table would have enforced the values of M/F. It must be noted that even if this were done it would not adequately address the six/seven reference data cases. All that having been said, there is a way ahead that is a first-step that is both practical and would likely address some of data management QA needs.

1. Validate all that’s been said above. 2. Have daily meetings with Jim Gawn to develop the use-case and database table

and column cross walks within the Appendix As until all the use cases are caught up from Product 1 through Product 6. I would be happy to work with Jim to accomplish this. Otherwise it may well be too much work to get accomplished by a single individual and keep up with all the requirements meetings and the many other tasks to which Jim is likely assigned.

3. Attend the requirements meetings in person, and have as a requirements meeting agenda item, a database table and column impact action item and section in every use case “minutes.” I could work with Jim Gawn to accomplish after each requirements meeting. We would come to consensus on the Appendix A additions, changes, or deletions, record them, and provide the requirements team the modified Appendix A for their use.

If we take these three steps, then even if we don’t have any of the three “accomplish” alternatives above, we would at least be in a position to state with some level of confidence that the data models do or do not support the use cases. This will not solve the business rules problem, but at least it will accomplish a QA of the use case to data models problem.


A19 Wayne Smith Proposal_2010_10_07


69



October 7, 2010

Mr. Wayne SmithICE/OCIOFPS/SEVP IT Systems BranchSystems Development DivisionSEVIS Program 800 K Street, NW Suite 1000 Washington, D.C. 20536

Dear Wayne:

Thank you for taking my call this morning. In my email that I sent you shortly thereafter I indicated that Iwould send you a document this afternoon that outlines the steps necessary to engineer an implementablespecification that can be bid by vendors.

This effort will involve:

1. All the existing documentation submitted by Booz Allen Hamilton2. The existing EDS documentation of SEVIS I3. The Revised Requirements materials that you guys have been creating.

The objective and end result of the way forward is an implementable specification of SEVIS II that, uponimplementation will be correct. It's as simple as that.

As I indicated to you in our conversation, I have several contracting vehicles that can be used toaccomplish the work. Additionally, I already have a teaming relationship with a contractor that isproviding enterprise architecture services to DHS. The staff that I would employ on this effort are all highperformers that are already known to Paul.

Please find attached the document that I said I would provide. I am more than willing to actuallydemonstrate the process that I would use to accomplish this work.

Regards,Michael M. Gorman,President


1

Whitemarsh Letter to Wayne Smith, DHS/ICE OCIO in regards to SEVIS II-2 follow-on work.

Introduction

Whitemarsh understands well that the SEVIS II program office has endured a large quantity offrustrations over the past three years in regards the creation of a SEVIS replacement system. Hereinafter,the SEVIS system created by EDS is referred to as SEVIS I. The effort performed by the just concludedSEVIS II effort is referred to as SEVIS II-1. The work focused on the creation of an overarching set ofrequirements for a new SEVIS II contract is called SEVIS II-2.

Whitemarsh has written extensively about the frustrations and the program office is in possession of thesematerials. The objective of this paper is to outline a series of steps, a conceptual project plan, if you will,that can be employed to create the necessary and sufficient materials so that the program office can issuean RFP that can be reliably bid by a series of vendors, who, upon award will be able to move out smartlyand implement a SEVIS I replacement system "just once" that will represent the needs of the SEVPcommunity.

1 Support for Development of SEVIS II RFP

Whitemarsh will assist the Program Office with the development of materials that are in support of thecreation of an RFP for the SEVIS I replacement system. The technical steps that produced these materialsare fundamentally these five:

! Perform a sufficient and necessary analysis of the existing systems and efforts to then haveadequate material for SEVIS II proposal vendors to understand the existing systems and pastefforts to develop requirements and earlier SEVIS II implementation artifacts.

! Create a set of candidate architecture requirements for the proposed SEVIS II system so thatproposal vendors will understand the scope, objective, and operating environment of thereplacement SEVIS II System

! Create collections of materials based on the above and from other necessary SEVIS and SEVIS IIactivities that can be used in Sections C, D, F, J, L, and M of an SEVIS II RFP

! Create material that will compare and contrast fundamental SEVIS II development alternatives.

! Create Program Office special materials that compare and contrast likely proposed SEVIS IIarchitectures, SEVIS II development methodologies, SEVIS II developer artifact deliverablesformats, performance metrics, predetermined competitive ranges for bids, and key strategies to beemployed to ensure that the SEVIS II replacement effort can be fully supported by anIndependent Verification and Validation contractor


2


2 Analysis and Report of Existing Systems and Efforts

The existing SEVIS I system, the full set of artifacts from the SEVIS II-1 effort, and materials developedin the pursuit of a validated set of requirements from SEVIS II-2 will be identified and analyzed todetermine the necessary and sufficient knowledge that needs to be incorporated into the appropriatesections of the RFP so that developers can construct bids that are all within a predetermined competitiverange. The required artifacts, in order to develop the SEVIS II procurement documents are:

! Missions, Scope and User Community! Data Models! Function Models! Developed Information Systems! Business Event and Transaction Models! Interface Systems! System Control Components

These seven collections of artifacts need to be discovered, appropriately materialized and formatted andthen incorporated within the appropriate section of the SEVIS II system RFP. This will then enableadequate appreciation by a bidder in order to make accurate and price-competitive proposals. If an awardis made without this information, schedule delays will be inevitable because there will a significantquantity of engineering change proposals due to unknown but existing requirements, unknown butexisting business processes, unknown but existing data integrity rules, unknown but existing datastandardization and migration systems, and the like. The inevitable engineering change proposals that willoccur when these missing components become known will cause schedule slippages, milestones to bemissed, costs to escalate.

The objective of this existing systems analysis is a significant quantity of material that adequatelyexpresses the As-Is of the existing SEVIS system, the SEVIS II effort, efforts conducted subsequent to thepausing of the SERVIS II development effort. This As-Is document becomes a key component in theappropriate section of the SEVIS II RFP.

Data models are of critical importance because they are ultimately the center of these kinds of systems.Hence the archeological efforts on behalf of data models is a significant component of this effort.Essentially, stored and persistent data represents the materialization of the policy of the SEVP within thedomain of each SEVIS database. Any changes in a data model often has a pervasive change effect onmany information systems. Hence, understanding the data models in SEVIS I, SEVIS II-1, and in SEVISII-2 define the pathway, scope, complexity and size of the replacement SEVIS II system.

2.1 Mission, Scope, and User Community

The missions and scope materials for the existing system and efforts are to fully describe the ultimateobjective of a needed business information system. Necessary also will be a listing and description of allthe different user communities that are expected to be served. That is, those that create and update data,


3


that report data and that perform special analyses on the business information systems containing data.This material is important in the RFP so that bidders can fully understand the nature, scope, and usercommunities that are already served and that will be served by the replacement system.

2.2 Data Models

The data model materials for the existing systems are of six (6) distinct types. These are:

! Data element model! Conceptual data model! Logical data model! Physical data model! View data model! XML data model

The data element model will be set within the context of the 2002 version of the ISO 11179 data elementmetadata model. As such it will contain data element support information for concepts, conceptualdomains, [conceptual] value domains and value domain data types, value domains, data element concepts,data elements, and necessary support sets of value domain values that are to be supported across themyriad of database tables for each database schema involved in the business information system database.

The data elements, if they are the enterprise level, facilitate the creation of integration andinteroperability at the "fact" level across an entire suite of databases. Properly engineered, enterprise-leveldata elements also support automatic name and definition generation across collections of databases. Ifthe data elements are mapped to database table columns, the SEVIS II bidders will have the ability tobetter understand both the existing databases and the proper creation of the set of SEVIS II replacementdatabases. The understanding will be facilitated because while the database table columns may be nameddifferently they will be mapped to the same enterprise-level data element.

The conceptual data models are the data models of all the different concepts including for example,person, address, business transaction, organization, location, and different classes' reference data. Theseconcept data models then form templates to the different constructs within the existing databases. Likeenterprise data elements, these concept data models will be mapped to the data structure concepts in anew SEVIS II database. This mapping will both facilitate understanding; it will also increase the ability tohave integration, interoperability, and non-redundancy. A final benefit is that these concept data modelswill provide an assist during the proposed SEVIS II development vendor's ability to accomplish existingdata standardization and migration between the existing and future environments.

The logical data models are database models that are independent of database management systems(DBMSs). It may be the case that there are multiple databases within each of the existing businessinformation systems. Each of these databases will have a logical data model in addition to its physicaldata model. The logical data models are designed in third-normal form and have database table columnnames and data types that are independent of any implementing DBMS such as Oracle. Logical data


4


models conform to specific data architecture classes (see below). The value of logical data models to theproposed SEVIS II development vendors is that they will provide a clear understanding of the datastructures that are, through physical data models, employed by information systems for data collection,update, and reporting. The logical data models will have backwards mapping to the conceptual datamodels and to the data element models. This will enable the SEVIS II development vendors to betterunderstand all the interrelationships among database tables within and across all the databases from theexisting SEVIS I and SEVIS II and the mapping between the existing SEVIS I system and a proposedreplacement SEVIS II system. This mapping will enable the development of accurate estimates for datastandardization and migration between the existing and future environments.

The physical data models are the database models employed by the specific DBMSs that are employed bythe information systems in the creation, updating, reporting, and analyses of the business informationsystems data. These data models are mapped to the logical data models, and are the source of mappings tothe View data models and the XML data models. There may be multiple physical data models for eachlogical data model. These different physical data models may serve different classes of end-users such asoriginal data capture users, reporting users, or analysis users. Consequently the mapping is necessarybetween the logical and physical data models so that the SEVIS II development vendors can understandall the different database interface programs that will exist in the existing business information systemsand that have to exist in the proposed replacement SEVIS II system. Additionally, this mapping will beneeded to support the proper specification and bidding of data standardization and migration between theexisting and future environments.

The actual databases that correspond to the physical databases will have to be examined to determine thefaithfulness of adhering to the set of data type and value domain value rules established for database tablecolumn mapped data elements. This information is essential for the proper configuration of value domainvalue mappings between and among the existing business information systems, between existing businessinformation system databases, and between the set of existing business information systems and theproposed replacement SEVIS II system. Vendors will only be able to make accurate bids in terms of bothtime and money if this information is readily available within the appropriate RFP section.

The view data models are the specification of the interfaces between databases, their DBMS engines, andthe information systems that access database data. View data models can create new data through certainview clauses, can enforce certain business rules, and can include sophisticated multiple-table relationshipsand subset selections. View data models are inherently mapped to their host DBMS as view are a form ofDBMS schema object.

It is important to have views defined within the appropriate section of the RFP so that SEVIS IIdevelopment vendors can submit accurate bids. Without this information, there will not be sufficientinformation to quantify the count and complexity of data conversion programs that will have to be createdin support of data standardization and migration between the existing and future environments. Inaccurateestimates will make dates associated with proposed time-lines and milestones very problematic and willsubject the overall proposed effort subject to a large quantity of engineering-change proposals that willsignificantly delay SEVIS II development and increase its cost.


5


The XML data models are the specification of the interfaces among information systems. Data from onedatabase is extracted through an information system and conformed to one XML schema and is thenprovided to a different information system for input to a different database. XML models are essentialwithin modern architectures when information systems are not directly connected. Data might becollected from one source into a database and then extracted and conformed to an XML schema fortransmission to a different computing platform for use by a different information system and database. Itis important to have a high quality mapping between the XML data model schemas and the physical datamodels so that the level and extent of data integration and interoperability can be determined. For everydisconnect there must then be a bridge program constructed that standardizes the data that is to beexchanged. It is important for the SEVIS II development vendors to know about the existing XMLschemas and the mappings between the XML schemas and the physical data models so that they canproperly determine the quantity and complexity of the programs that perform extracts andtransformations. Not having XML schema information has the same down-side effects as view datamodels, that is, risking proposed time-lines and milestones, and causing a large quantity ofengineering-change proposals that will significantly delay SEVIS II development and increase its cost.

Each data model schema will be further classified by its data architecture class. That is, whether it is:

! Original data capture - a database engineered to receive data from end-users and/or interfacedinformation systems

! Transaction data staging area - a database that has semantically conformed data in terms ofprecision, granularity, temporal characteristics, and reference data value domain values

! Operational data store - a database that stores data across a broad subject area but is commonlyrestricted to just several years of data

! Wholesale data warehouse - a database that is like a ODS database except that it covers manyyears, and has been formatted to be in report-efficient formats

! Retail data warehouse or data mart - a database that is a subset of a wholesale data warehouse andis either designed to be in a "star-schema" format or in an "E-R" format.

! Reference data (also seen as Master Data and/or Authoritive Data Source - a set of individualdatabase tables and/or collections of database tables that represent stable values or collections ofvalues that are employed as "references" for other data or is "the" authoritative/definitive sourcefor this data


6


2.3 Function Models

Function models are the behavior models that govern the interaction between the existing businessinformation system users, the business information systems, and the databases. Function models arematerialized as documents in the following forms:

! End-user screen specifications and their step-by-step sequences and inter-screen invocations

! Batch processing systems including their steps, sequences and alternative processing routes andinter-batch process system invocations

! Business rules and their specifications that get executed on behalf of data quality checking,completeness, transformation, and computation

! Use case diagrams that specify the behavior to be performed. Included are step-by-stepsequences, invocation of business rules, and invocation of other use cases

! Data mapping between the required behavior model components and the databases, These arecommonly expressed in an SQL view form of syntax

! Information systems and contained subsystems down to processing modules mappings to thefunction models and contained processes within the function models

The behavior models of the existing business information systems need to be discovered and put into aform that they can be reviewed as to their correctness, complexity and completeness. Thereafter, a form ofthat research should be placed in the appropriate section of the SEVIS II RFP.

Only when a comprehensive functional analysis is accomplished will a SEVIS II development vendor beable to correctly assess the quantity, breadth, and complexity of the work that has to be migrated from theexisting information systems environments to the new environment. The down-side from notaccomplishing a comprehensive assessment and materialization of function models is that collections ofbusiness rules will not be uncovered, information systems necessary for the correct accomplishment ofthe new SEVIS II system's work will be missed, and there will be an under appreciation of the scope andeffort required in a valid bid from an SEVIS II development vendor.

2.4 Develop Information Systems

There are three classes of information systems that need to be identified, assessed and materialized intothe appropriate section of the SEVIS II RFP.

! Existing information systems within the current set of SEVIS I systems

! New candidate information systems for the proposed SEVIS II replacement system


7


! Data standardization and migration systems that must exist and execute between the existingSEVIS I systems and the new SEVIS II replacement system

Each existing information system needs to be identified and described as to its constructioncharacteristics. Included for example would be its programming language, engineering, intra-flow,inter-information system invocations, self-contained and defined data structures, encapsulated definitionof business rules, transformation rules, data integrity checks, and employment of self-contained referencedata. Every one of these information system constructs will affect the quantity and skill level of theresources that will have to be bid by a SEVIS II replacement system vendor. Again, without the completespecifications of these information system materials, all the usual cautions apply. That is, copiousengineering change proposals, missed milestone, and unacceptable information system products.

2.5 Business Event and Transaction Models

Business events are situations that occur in the SEVP environment that may require special before andafter processing, process sequence tracking and audit trails, and may include knowing and storing thevery context upon which the business event occurred. It may also require knowing which business eventoccurred before and then afterwards. Business events are independent of database data model which setsout the natural relationships among the data. Business events are also independent of the function modelthat sets out the human behavior functions that occur. Business events are however closely interrelatedwith both data and function models and must be supported by mappings.

Business event models are commonly based on rules and regulations that may exist as internal ProgramOffice policies or Federal wide policies or standard accounting policies.

Business events add a whole new layer of complexity onto an effort such as the migration of the SEVIS Ioperating environment into a SEVIS II operating environment. That is because the business event modelsin each environment might be very different and in some cases are irreconcilable. Regardless, the businessevent models need to be thoroughly discovered, set out as documents, and integrated with the otherdocument sets within this overall work step.

Again, without the complete specifications of these business events, not only will the usual cautionsapply, that is, engineering change proposals, missed milestone, and unacceptable information systemproducts, but also there might be significant errors in the audit ability and traceability of businesstransactions.

2.6 Interface Systems

It is almost always the case that information systems interface with many other types of informationsystems. Each such interface needs to be identified and thoroughly specified. The common components ofan interface system are the data models of the interface which may range from a direct interfacemechanism such as SQL views, to fixed format data file, to a comma delimited file, to an XML based data


8


exchange. In any of these interface alternatives, the key issues are data types, levels of precision, theproper use of reference data values, whether the exchanged data is atomic or derived, and the like.Each interface has to be specified such that there is little to no room for ambiguity. Specified too, has tobe the frequency and volume of data required for each interface execution. Also specified must be therequired consequences of interface failures.

Again, the usual cautions apply. If the interfaces material contained within the RFP is too little, interfacesmissed, or under specified, there will be engineering change proposals, missed milestone, andunacceptable information system products.

2.7 System Control Components

There are a number of components that deal with system control. Mainly they deal with:

! Audit Trails - the ability to roll-back a given update, and/or to follow a trail of previous updatesfor a particular business event

! Backup and Recovery - the ability to recover to the last successfully completed transaction or tospecified date and time of a collection of successfully completed transactions

! Message Processing - the posting of messages to end-users and/or recording to processing logsfor batch processing as the consequence of some event that occurred during the execution of atransaction or the instigation/termination of a transaction

! Security and Privacy - the ability to allow and/or prevent accessing (insert, delete, modify, read,or select) data and/or processes by classes of users and/or individual users

The existing set of system control facilities of these and others need to be identified and recorded fromwithin the existing SEVIS I system. As with the sections above, the usual set of cautions apply. That is, ifthere are missed audit trails, or databases and/processes not able to be backed or restored, or messagesthat are not complete or posted, or security and privacy facilities missed, it is likely that these misseditems will result in engineering change proposals that will in the end cause missed dates, milestones, andresult in increased costs.

3 Candidate Architectures for the Proposed SEVIS II System

Whitemarsh, armed with the materials created above will conduct in-depth interviews with the completeset of functional users to understand which components of the functionality represented by thespecifications contained within the materials developed from the SEVIS I, SEVIS II-1 and SEVIS II-2efforts.

Whitemarsh will conduct specific analyses to distinguish the functionality that is different because ofstyle from differences due to fundamentally different types of data, processing steps, critically different


9


business rules, and the like. This type of analysis will be conducted across the missions, data models,function models, developed information systems, business event and transaction models, interfacesystems, and system control components. Each such analysis will include a set of conclusions andalternatives.

The result of these analyses will be a differences report to the appropriate staff within the Program Officeso that they can make a judgment about the conclusions and a choice among the alternatives. Whitemarshbelieves that it is the proper purview of the Program Office make these judgments and alternative choicesbecause otherwise the SEVIS II development vendor will be charged with deciding the fundamental data,functions, processes, interfaces, etc.

Once the choices are made, Whitemarsh will create a candidate architecture document that embraces thesemissions through system control components. The candidate architectures will be an expression of theTo-Be of the SEVIS replaced system. This To-Be document becomes a key component in the appropriatesection of the SEVIS II RFP.

Together, these As-Is and To-Be sections represent expressions of the technical requirements of theProgram Office that the vendors can the employ to properly configure their proposal that represents thetransformation of the As-Is business information systems to the one To-Be business information system.

4 Prototyping and Metadata Management within SEVIS II

The seven sets of materials cited in section 1.2 that will have been collected from SEVIS I, SEVIS II-1,and SEVIS II-2 will all be stored in a metadata management system. These materials will all beelaborately cross referenced and reportable. These materials will support the production of traceabilityfrom requirements through to prototyped functional operations.

These materials will also support the creation of functional prototypes across the whole of refined set ofSEVIS II requirements. These prototypes can be created in a matter of days to at most a staff week andwill be presented as part of the functional models development and validation.

As each functional prototype is created it will be demonstrated to the functional subject matter experts forreview and comment. The results of the reviews will be folded back into changes to the data models, thefunctional models, and the business event and transaction models. At each such cycle, all the sevenclasses of artifacts that are stored in the metadata management system will be updated. Updatedtraceability is automatic. Immediately thereafter another functional prototype will be created and itsreview recommenced.

This process of functional prototyping will occur across entire breadth of SEVIS II until the functionalexperts are satisfied that close to 100% of all the functional requirements have been teased out of theirhidden corners and have been made manifest within both functional prototypes and also the metadatacontained within the metadata management system. The result of this effort will be a completely updatedand thoroughly cross-referenced set of the seven sets of metadata artifacts.


10


It needs to be clearly stated that the collection of functional prototypes are not a ready-for-prime-timeproduction class system. Rather, they are what their name implies: Functional Prototypes of the SEVIS Ireplacement system. Bidders, will be able to actually see and use the final set of functional prototypes asthey will be contained within the laboratory described in Section 1.5.

5 Materials in Support of SEVIS II RFP Sections C, D, F, J, L, and M

In addition to the extensive set of materials that would be developed during the activities described above,Whitemarsh will carefully review a recommended set of RFPs that have been issued by the ProgramOffice to extract policies, procedures, knowledge about the FAR, and the like that are most appropriate,and then determine a detailed outline of the materials that should be in the various RFP sections such asC, D, F, J, L, and M. This outline will be used to guide the selection of the most appropriate contents forthe various proposal section contents, once reviewed, revised and approved by the Program Office willthen become the working objective of Whitemarsh. There will certainly be the As-Is and To-Be sets ofmaterials that were created within sections above.

Additionally, it is recommended that the Program Office allow Whitemarsh to create an existing systemslaboratory that proposed bidders can visit to exercise the existing systems. This way, the proposedvendors can see what the As-Is specifications really look like in terms of operating business informationsystem transactions.

Whitemarsh, as part of establishing this laboratory will accomplish the required steps to make acomprehensive set of sample data that does not violate any of the Program Office privacy and securityguidelines. Whitemarsh will create business transaction based scenarios along with typical data so thatvisiting vendors can actually experience the operation of business functions, business events, informationsystems, interfaces, and the like. At the end of a set of demonstrations for a particular proposed vendor,the sample databases and transaction file will be restored.

It is further recommended that the laboratory contain a complete set of the working prototypes that willhave been created in Section 1.4 above. Finally recommended is that a read-only copy of the metadatamanagement system along with all the metadata-based seven artifacts be provided to the SEVIS IIbidders.

Collectively, these RFP based materials will enable the bidders to thoroughly understand the existingSEVIS I system, the seven collections of artifacts from Section 1.2, and be able to both see andexperience SEVIS I system and also the final set of SEVIS II prototypes. There should therefore benothing left for the bidders to guess when they create a proposal for the creation of a production classversion of SEVIS II.


11


6 Special Study Reports about Alternative Architectures, Development Methodologies,

Development Artifacts, Performance Metrics, and IV&V Work Breakdown StructuresWhitemarsh will accomplish special studies that, for example, compare and contrast likely proposedSEVIS II architectures, SEVIS II development methodologies, SEVIS II developer artifact deliverablesformats, performance metrics, predetermined competitive ranges for bids, and key strategies to beemployed to ensure that the SEVIS II replacement effort can be fully supported by an independentverification and validation (IV&V) contractor. Each of these special studies will be first set out as anoutline that is presented to the Program Office as a technical presentation. Upon review, revision, andapproval, the special study will be conducted quickly in support of a prototyped set of findings,conclusions and recommendations. This prototype study will then be submitted to the Program Office forreview and possible revision as to the approach, work steps, and deliverables. Upon approval, the specialstudy will be conducted thoroughly and the findings, conclusions, and recommendations submitted to theProgram Office for is consideration.

Whitemarsh believes that one special study, IV&V, is especially important. That is because IV&V,properly executed enables the Program Office to know that a project as extensive and as critical as SEVISII is properly managed, is making the right hardware and infrastructure decisions, is fully conformant tothe database architecture requirements, and has the information systems properly configured to ensureintegrity, reliability and repeatability. Whitemarsh will update its already created very detailed outline anda set of data management specific work steps that it recommends that can be used with the already createdSEVIS II-1 IV&V approach that only assessed the program management aspect of IV&V. Whatadditionally needs to be developed in the IV&V work plan are the tasks associated with businessinformation systems development, hardware and infrastructure development, and earned valueassessments. These areas were not accomplished in any meaningful way during the SEVIS II-1 effort.This revised IV&V document, when finished will include work steps, deliverable specifications, analysisstrategies, and approaches to thoroughly assess the SEVIS II replacement effort. Of note, the metadatamanagement system's contained artifacts will form the technical basis of comparison between the requiredSEVIS II-2 system and the actual accomplished work. It is the firm belief of Whitemarsh that theaccomplishment of traceability in every respect is the responsibility of the IV&V contractor.

7 PMO Related Support for SEVIS II Project Office

Whitemarsh's approach to providing PMO support to the SEVIS II Project Office will be one where wepartner and form a close working relationship with the SEVIS II Government staff. The partneringprovides open avenues of communication, and helps answer and solve concerns before they becomeissues or problems.

Our Whitemarsh program manager (PM) will work with the project stakeholders to define the project andplan the activities necessary to complete the defined work. Project planning is complete when the plans tomanage the project have been defined, reviewed, commitment obtained from the stakeholders, and thegovernment approves the plan. Project planning is an iterative process. We will provide program andproject management services to create and maintain project plans, schedule resources, manage budgets,


12


and oversee the execution and closure of the SEVIS II project as directed. Typically, our project planswill include: the project charter defining roles and responsibilities, scope (requirements, change requests),WBS, schedule, budget, communication plan, quality assurance, risk register and issue log. We willprovide program support in accordance with each project implementation plan to maintain consistencywith the mission support area. Our Team will adjust our approach and staffing as needed to meet specificrequirements.


13


A20 Paul Martindale Letter_2010_12_06


70



December 6, 2010

Mr. Paul MartindaleOffice of the CIO, Systems Development DivisionImmigration and Customs EnforcementU.S. Department of Homeland Security801 I Street, NW Washington, D.C. 20536

Dear Paul:

Thank you for allowing me to meet with your staff on December 1, 2010. It was good to interactwith you and to meet old friends such as Carol and Bob. It is certain that we all share a commongoal: the successful replacement of SEVIS with SEVIS II.

From our previous exchanges, you know that I was the data management IV&V on the firstattempt to replace SEVIS with SEVIS II. During my six months (late March 2009 through earlyOctober 2009) I created a number of findings documents. These findings documents wereobtained by your office in the middle of October 2009.

A letter describing all these data management IV&V findings documents was provided by me toAmerican Systems, my prime contractor, on October 13, 2009, and I provided that letter to youlast week. Since I do not possess the IV&V findings documents, my recollection of them isdrawn from the descriptions contained in the October 13, 2009 IV&V findings letter. The datamanagement IV&V documents addressed a number of issues including:

! Data Management IV&V Process (#2) ! Business Event History (#13) ! Reference Data Management (#14, 18) ! Requirements Management and Prototyping (#15)! Data Modeling Problems (#1, 19)! Data Management Issues (#3, 4, 5, 6, 7, 8, 9, 10, 11, 16, 17)

From your description of the process you are now executing to achieve success in this secondattempt of SEVIS II, you have changed the approach in contracting from one integration


1

Whitemarsh Letter to Paul Martindale, DHS/ICE OCIO in regards to SEVIS II follow-on work.

contractor with end-to-end responsibility to a series of smaller contractors with discreteresponsibilities. It seems, however, that you are continuing to pursue a strategy that is similar tothe one depicted on page 7 of the Whitemarsh presentation, Strategy for Success. Instead ofhaving a single integration contractor responsible for all these activities, you have chosen todivide these efforts into smaller contracts, possibly with different contractors. As I understoodthe discussion that occurred during our meeting, the first major phase, Requirements Analysisand Design, is divided into two contracting efforts, Requirements, and Design.

Conceptually, the approaches are equivalent because the integration contractor had also dividedits work into discrete efforts such as requirements, system and program design, databaseengineering, programming, unit and integration testing, data conversion, documentation, trainingand the like.

The integration contractor’s “PMO” was responsible for an end-to-end WBS, resource allocationand management, deliverables configuration and turn-over to the Government, and otheradministrative matters. The approaches are also equivalent because the Government’s PMO nowhas these responsibilities across all the individual contracting efforts.

Despite the one-contractor integrated effort, the problems described in the October 13, 2009Data Management IV&V letter occurred. These occurred or were enabled to occur for thefollowing four reasons:

1.0 End to End Metadata Management System and Database

There was no end-to-end metadata management system that ensured that all work products werestored as database records in the metadata management system’s database, and thereafter, alldeliverables would have essentially been “reports” from a database rather than individual stove-pipe documents.

It was clear from observing the creation and presentation of work products, the integrationcontractor created the majority of the work products cited in the Wayne Smith Letter’s Sections2.1 through 2.4. But even though these work products were created, the SEVIS II specificationsrepresented by these documents were not stored, retrievable, updatable, integrated, or non-redundant in a metadata management system database because these work products were createdusing different tool sets that were inherently unintegrated. In short, even though the integrationcontractor did most if not all the work, the SEVIS II specifications represented by their work wasnot stored into a metadata management system database that would have enabled work productintegration, non-redundancy, cross referencing, interchange and reuse. Simply put, despite all thework being done, none of the critical benefits were realized.


2


Because work product integration was missing, work product change impact analysis, cross-referencing among work products, and meaningful traceability across work products was socostly and error prone to create, check for errors, update and report, it was not accomplished.What could have been populated with virtually no extra work from their work product effortswere the metadata models on the following pages from the referenced document, MetabaseOverview: 19, 20, 21, 23, 24, 25, 26, 28, 30, 31, 32, and 34. Theses models, if populated wouldhave supported the quick and easy impact analyses, cross-referencing, and traceability.

The lack of an end-to-end metadata management system was discovered at my very first allowedcontact with the Integration contractor that occurred in mid April 2009. This critical missingelement became an ever increasing reason for overall SEVIS II failure.

2.0 Project Management Data Integrated with Work Products

Project management data was not integrated with work-product data and stored via the metadatamanagement system’s database. This would have enabled earned-value reporting, which isvaluable both to the integration contractor and the Government.

The project management data would have populated the Metadata Model, Project Managementthat is presented on page 27 of the document, Metabase Overview. Had this integration beenpresent, it would have supported the discovery of critical weak links in the accomplishment of theoverall effort. Research was done in this area and it showed critical failings. It is not certain ifthese failures were included in the data management IV&V findings documents, however.

2.0 Comprehensive Work Breakdown Structure

The project’s work breakdown structure that governed the effort was not sufficiently detailed asto data management or other critical areas such as hardware and software infrastructureinstallation, unit and integration testing, and the like. This caused overly optimistic estimates ofwork to be accomplished because whole collections of tasks were missing. It also ultimately ledto integration contractor findings that they themselves did not accept because it would haveresulted in database redesign, and system and program re-engineering. These changes would haveled to increased costs and even more delays. Critical and necessary changes were held hostage bywork products already developed.

4.0 Approach to Prototyping

The approach to prototyping requirements was not cost-effective and was very inefficient.Essentially, changes in requirements caused changes in either the database’s design or computerprograms, or both. This inefficient approach to prototyping caused long cycles betweenrequirements determination and software demonstration.


3


Additionally, because of the missing metadata management system and database, there was noway to accurately identify the impact of needed changes on already accomplished work products.

As stated earlier, the two approaches, one integration contractor, or a collection of individualcontractors, are generally equivalent because in either case there has to be a very strong PMOthat has the responsibility for and authority over the entire effort. Additionally, the PMO must beable to understand and deal with critical technical issues. Under the first approach the integrationcontractor must possess the strong PMO. Under the multiple-contractor approach, theGovernment must be the strong PMO. Thus, the four problems from above become theresponsibility of the Government’s PMO in order to achieve SEVIS II success.

Under this multiple-contractors Government-PMO approach, the Government must ensure thatwork products from one contractor are high quality, complete, and are conveyable to the follow-on contractor. That is because individual contractors have no responsibility and/or authority onewith and/or over the other. For example, if the work of one contractor is unknowingly deficient,the follow-on contractor has no authority to cause it to be corrected. This will likely lead tosuboptimal work across the contractors. To alleviate this, there has to be end-to-endaccountability, and a remedial mechanism. This can only be the Government’s PMO because ifthe first contractor’s effort is finished and the contract concluded, there is only the Government’sPMO to shoulder the responsibility of identifying, assessing, and repairing the deficiency prior tothe start of the next contractor’s work effort.

Simply put, the Government’s PMO must have and/or be able to employ all the technicalknowledge and skills of an integration contractor’s PMO.

With all this in mind, the following recommendations appear appropriate:

! Engineer an end-to-end, comprehensive and detailed work-product work breakdownstructure. Create this WBS from the several WBS documents already produced, andsupplement it with other WBS documents that are significantly more detailed in areassuch as data management, hardware and system’s software infrastructure, unit andintegration testing. For example, the Whitemarsh Database Project WBS is 125 pages.Test-execute the WBS with zero-length work tasks and revise it until there is a highdegree of confidence that it is correct. This becomes the overarching governance acrossall the contractors.

! Engineer an end-to-end QA/QC and IV&V type WBS that is, at the very least, a mergerof the one that governed this effort and the Data Management IV&V WBS (#2 from theOctober 13, 2009). Expand the sections within that combined document to address theQA/QC and IV&V efforts for the technical aspects of the SEVIS II effort. This becomes


4


the overarching QA/QC and IV&V governance across all the contractors and ensures thatwork products are developed with quality and are exchangeable across the contractors.

! Engineer, acquire, install, operate, and evolve and maintain a metadata managementsystem that is to be used by all the contractors so that all the work products areseamlessly exchangeable across the entire SEVIS II life cycle. This would necessarilyinvolve creating a metadata management system database that would record, integrate,update, and report all the metadata models from the document, Metabase Overview, pages 16 through 34.

Under the multi-contractor approach, the Government becomes responsible for thequality of every work product deliverable, for its storage into the metadata managementsystem database, and for the ability to extract and hand-off the work products to follow-on contractors.

The metadata management system must be able to store work product specifications insuch a way that the resulting database of work products is non-redundant, integrated, andfully able to support deliverable-based reports production, impact analysis, cross-referencing, continuous updating, and comprehensive reporting.

Accomplished, this metadata management system and database will not only be “living,”it will also support SEVIS II evolution and maintenance, help desk (#9), system and end-user documentation.

! Accomplish prototyping similar to that depicted on pages 10, 11, 12, 13, 14, and 15 of thepresentation, Strategy for Success. As prototypes are generated, demonstrated, andrevised through several cycles, perform continuous update of the specifications of SEVISII as depicted on page 11 of the Strategy for Success presentation, and as also describedin detail on pages 3 through 9 of the letter, Wayne Smith Proposal. This will ensure thatthere is a thoroughly vetted set of requirements, and a comprehensive functional designthat can be provided to contractors subsequent to the phases, Requirements and Design.

! Ensure via contract clauses with all contractors that all deliverables are conveyed throughupdates through the metadata management system into its database, and that thesedeliverables are able to be produced on demand through report writers prior to theGovernment’s recognition that a work product was delivered.

! Ensure via contact clauses that all delivered work-product modifications are conveyedthrough updates through the metadata management system into its database, and that


5


these modified deliverables are able to be produced on demand through report writersprior to the Government’s recognition that a modified work product was delivered.

! Review the previously created data management IV&V findings (e.g., #s 1, 3, 6, 7, 10,13, 14, and 17) contained in the documents described in the October 13, 2009 letter, andresolve them as may be appropriate. Most of the issues had little to do with the “way”work was being done. Rather they had to do with the architecture, engineering, andcontent of work products.

! Investigate and attempt to accomplish the generation of all production software from abasis of specification-engineered metadata. From the presentation, Strategy for Success,page 13 illustrates this process and page 18 sets out its real benefits. The specificationsshould be exported from the metadata management system’s database. Accomplished, the"nobody will touch anybody else's code" will be replaced with machine generated code.When this is accomplished, upwards to 90% of all program code will be machinegenerated. This causes standardization, dramatic increases in productivity and quality,and dramatically lower costs and risks.

If you would like to communicate further on the data management problems identified above,and those cited in the October 13 letter, I would need the documents referenced by the letter. Iam also willing to provide more information regarding the recommendations above. I haveincluded a series of links to documents that support these recommendations in the table thatfollows.

Regards,


Reference Links to Supporting Documents

Document Link

Book: Enterprise Architectures http://www.wiscorp.com/enterprise_architecture_book.html

Book: Data Interoperability Communityof Interest Handbook

http://www.wiscorp.com/data_interoperability_book.html

Book: Strategy for SuccessfulDevelopment of Business Information

http://www.wiscorp.com/strategy_for_successful_develo.html


6



Document Link

Systems

Paper 6: October 2006 - Modeling Dataand Designing Databases

Paper 8: April 2007 - EnterpriseArchitectures

Paper 11: February 2008 - Engineeringand Managing Information Systems Plans

Paper 12: April 2008 - ManufacturingProject Plans

Paper 14: September 2008 - ProjectMetrics

Paper 15: March 2009 - Earned ValueMeasurement

Paper 16: January 2010 - Business EventManagement

Paper 17: October 2010 - Reference DataManagement

Paper 18: November 2010 - RFPDevelopment

http://www.wiscorp.com/short_paper_series.html

Project Management Architecture andConcept of Operations

http://www.wiscorp.com/DatabaseProjects_-_WhitemarshProjectManagementOverview_-_paper_-_sam.pdf

Short version of the WhitemarshDatabase Project Work BreakdownStructures

http://www.wiscorp.com/DatabaseProjects_-_WorkBreakdownStructures_-_book_-_sam.pdf

Data Interoperability Need and SolutionCharacteristics

http://wiscorp.com/DataInteroperabilityNeedAndMetabaseSolutionMatrix.pdf

Critical Questions Addressed byMetabase System

http://www.wiscorp.com/critical_questions_answered.html

Book: Data Modeler Architecture andConcept of Operations

http://www.wiscorp.com/metabase_demo.html(link is near the bottom of that page)


7



Document Link

Book: Reverse and Forward EngineeringUsers Guide

http://www.wiscorp.com/metabase_demo.html(link is near the bottom of that page)

Paper: Metabase Overview http://www.wiscorp.com/metabase_demo.html(link is near the bottom of that page)


8


A21 Data Management IV&V_2011_11_29 Architecture and Concept ofOperations


71

Data Management Independent Verification and ValidationArchitecture and Concept of Operations




Data Management IV&V: Architecture and Concept of Operations

Table of Contents

1.0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.0 Data Management Contextual Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

3.0 Business Information Systems Work Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.0 Business Information System Work Products Interrelationships . . . . . . . . . . . . . . . . . . 12

5.0 Data Management IVV Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.0 Data Management IVV WBS and Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.1 Data Model Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.1.1 Data Model: Data Element Model Assessment . . . . . . . . . . . . . . . . . . . . 166.1.2 Data Model: Concepts Data Model Assessment . . . . . . . . . . . . . . . . . . . 186.1.3 Data Model: Logical Data Model Assessment . . . . . . . . . . . . . . . . . . . . 196.1.4 Data Model: Physical Data Model Assessment . . . . . . . . . . . . . . . . . . . . 226.1.5 Data Model: SQL View Data Model Assessment . . . . . . . . . . . . . . . . . . 256.1.6 Data Model: XML Interface Model Assessment . . . . . . . . . . . . . . . . . . . 28

6.2 Business Information System Work Product to Data Model Assessments . . . . . 306.2.1 Business Information Systems Assessment . . . . . . . . . . . . . . . . . . . . . . . 306.2.2 Business Requirements Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2.3 Business Rules Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2.4 Database Domains Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.5 Database Objects Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2.6 External data interface Requirements Assessment . . . . . . . . . . . . . . . . . 366.2.7 External Quality Standards Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.8 Information Needs Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2.9 Mission Organization Function Assessment . . . . . . . . . . . . . . . . . . . . . . 396.2.10 Resource Life Cycles Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2.11 Use Cases Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2.12 User Acceptance Tests Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2.13 Value Domains and Management Assessment . . . . . . . . . . . . . . . . . . . . 436.2.14 Contract Work Breakdown Structure (WBS) Assessment . . . . . . . . . . . 44

6.3 Business Information System Work Product to Business Information SystemWork Product Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.3.1 Business Information Systems Assessment . . . . . . . . . . . . . . . . . . . . . . . 476.3.2 Business Requirements Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.3.3 Business Rules Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3.4 Database Domains Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Copyright 2011, Whitemarsh Information Systems CorporationProprietary Data, All Rights Reserved

ii


6.3.5 Database Objects Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.3.6 External Data Interface Requirements Assessment . . . . . . . . . . . . . . . . . 596.3.7 External Quality Standards Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 626.3.8 Information Needs Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.3.9 Mission Organization Function Assessment . . . . . . . . . . . . . . . . . . . . . . 666.3.10 Resource Life Cycle Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.3.11 Use Cases Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.3.12 User Acceptance Tests Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.3.13 Value Domains and Management Assessment . . . . . . . . . . . . . . . . . . . . . 766.3.14 Contract Work Breakdown Structure (WBS) Assessment . . . . . . . . . . . 78

7.0 Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87


iii


1.0 Overview

In a large scale data-centric environment, there are a number of factors in the determination of anoverall success. Among these are:

! Project Management which includes the overall project's architecture, engineering anddeployment with special focus on requirements, schedule, and costs.

! Data Management which includes data architecture, modeling, engineering, anddeployment along with evolution and maintenance.

! Hardware Management which includes computing and network hardware architecture,engineering and deployment along with evolution and maintenance.

! Software Management which includes software application, engineering and deploymentalong with evolution and maintenance.

The focus of this paper is Data Management. To that end, the objective of this paper is to set out an overall contextual data management environment as it relates to a large scaledata-centric business information system project. This contextual environment includes:

! An enumeration and brief definition of the data architecture reference model data modelsthat comprise this data management environment.

! An enumeration and brief description of the various key business information systemwork products.

! A cross reference table between the data architecture reference model data models andvarious key business information system work products.

! A cross reference table among the various key business information system workproducts.

! An illustration of how these data management component interconnects through the useof a scenario.

! A detailed set of procedures through which the data architecture reference model datamodels and the business information system work products can be assessed.

! A section on the creation of a risk matrix including the development of risk indicators,that is, red, yellow, and green.

2.0 Data Management Contextual Environment

There are two major classes of components in the data management contextual environment:

! Data Models! Business Information System Work Products


1


The data models component consists of six classes of data models, which are all interrelated oneto the other. These are depicted in Figure 1. The objective of these six models is to significantlyincrease semantic interoperability, increase re-use, eliminate redundancy, and reduce the overallcost of project specification, implementation, and maintenance. The effect of having these sixmodels is a way to decrease overall project risk while at the same time increasing quality. Theconsequence of not having thesemodels is the converse of theseobjectives and effects.

Table 1 enumerates and brieflydescribes each of these six data modelclasses. These six data model classeshave real, practical, and existenceimplications for enterprises. To wit:The Y2K data debacles were a directconsequence of enterprise failure tohave these six data models within anon-redundant, unambiguous andintegrated data model managementenvironment. Most recently, the NASA1999 Mars Climate Orbiter crash wasdirectly tied to fact that oneorganization was computing with"metric" unit measurements andanother was computing with "English"unit measurements. The existence of aData Element Model semanticscapstone would have controlled dataspecifications, implementations, andoperations would have surfaced thissemantic disconnect.

This document does notaddress how to create each of thesedata models because the creationprocess is more than adequatelyaddressed within other Whitemarsh books, courses, seminars, and methodology documents.Rather, the focus of this document presumes is to assess the necessary and sufficient interactionbetween these data models and the other key business information system work products.

Data Element Model

Concepts Data Model

Logical Data Model

Physical Data Model

SQL View Data Model

XML Interface Model


Figure 1. Data Architecture Reference Model.


2


Data Model Class Description

Data Element Data elements are the enterprise facts that are employed as the semantic foundations forattributes of entities within data models of concepts (Specified Data Models), columns oftables within database models (Implemented Data Models) that support the requirements ofbusiness and are implemented through database management systems (Operational DataModels), that, in turn, are employed by business information systems (View Data Models)that materialize the database objects necessary for within the resources of the enterprisethat support the fulfillment of enterprise missions. Key components are Concepts,Conceptual Value Domain, Data Element Concepts, Data Elements and Value Domains.Semantic and data use modifiers can be assigned to every data element concept and dataelement.

Specified orConcepts DataModel

Specified Data Models are the data models of concepts. These models consist of subjects,entities, attributes, and inter-entity relationships. Relationships can interrelate entitieswithin multiple subjects. Each data model should address only one concept such as aperson’s name, or an address, etc. These concept data models can be templates for use indeveloping database models (Implemented or Operational). Every entity attribute shouldmap to its parent Data Element. Semantic and data use modifiers can be assigned to everyentity attribute. Key components are subjects, entities, attributes, and relationships.

A concepts data model is a data model of a specific concept, represented as a containersuch as student, school, organization, or address. These containers (e.g., student or school)must be specified before they can be implemented in one or more different databasecollections of tables that ultimately become operational through a DBMS such as Oracle.

Implemented orLogical DataModel

Implemented Data Models, are the data models of databases that are independent ofDBMSs. These models consist of the data structure components: schema, tables, columns,and inter-table relationships. Relationships are restricted to tables within a single schema.While each implemented database data model can address multiple concept data modelsfrom the collection of concept data models, each implemented data model should addressonly one broad subject. Every table column should map to a parent Attribute. Semantic anddata use modifiers can be assigned to every column. There is a many-to-many relationshipbetween the Specified Data Model and the Implemented Data Model. Key components areschemas, tables, columns, and relationships

Operational orPhysical DataModels

Operational, or Physical Data Models, are the data models of databases that have beenbound to a specific DBMSs. These models consist of the data structure components:DBMS schema, DBMS tables, DBMS columns, and inter-table DBMS relationships.DBMS Relationships are restricted to DBMS tables within a single DBMS schema. Eachoperational database data model can address multiple implemented data models. EveryDBMS Column should map to a parent Column. There is a many-to-many relationshipbetween the Implemented Data Model and the Operational Data Model. Key componentsare DBMS schemas, DBMS tables, DBMS columns, and DBMS Relationships.

In this state, that is, dependent upon a particular DBMS and upon the performancerequirements of a particular software application, this data model is termed “physical.”These data models are the operational data models that are bound to application businessinformation systems through view data models. These data models are often not in third


3


Data Model Class Description

normal form as a way to meet needed performance requirements. DBMS Columns from theDBMS tables from within these operational data models are deployments of a singlecolumn of a table from a logical data model.

View Data Model The View data models represent the interfaces between operational data models andbusiness information systems. View and their view columns can be characterized as Inputand/or Output. Additionally, these views can be mapped one to the other on a view columnbasis and processes can be specified to define any appropriate data value transformation.Key components are Views, View columns, and view-column interrelationships.

View data models are bound to the particular DBMS through which they are defined. Viewdata models enable application systems to select, employ, and update databases accordingto their physical data models without having to include physical data model details withinthe application systems.

XML InterfaceData Models

A XML interface model represents a specialized construction of importable or exportabledata with respect to the business information system. Each XML data stream is definedthrough a XML Schema. Both XML schemas and XML data streams are independent ofthe software applications that create and/or use them. XML Schemas and XML datastreams are DBMS represented in plain ASCII text. Key Components are XSDs, XMLelements, and XML attributes.

The structure of XML data is expressed through an XML schema that is employed to thenunderstand the contents of XML data records. XML schemas are created through specialsoftware applications. XML data streams are created by source application businessinformation systems and are subsequently read and processed by target applicationbusiness information systems.

Table 1. Data Model Layers within the Data Architecture Reference Model.

Figure 1 shows that the core of the data management environment is the data modelenvironment. Within this environment there are six distinct data models. For example, the DataElement model captures the once-only identification, specification, and definition of dataelements that may be represented as database table columns in many different database tables.

Similarly, there may be concept data models, for example, for students, schools,organizations, or addresses. These concept data models can be deployed in one or more logicaldatabase models, which, in turn are operationally deployed in one or more DBMS specificphysical data models.

Each of these six data model classes serve a special purpose and is interrelated with theother data models in some integrity-enhancing and work-saving manner. Again, Table 2 providesdefinitions and interrelationships.

Figure 1 shows a left-side set of one-to-many relationships going "down." Thisrelationship supports two meanings. The first is the mapping of an individual component of amodel, and the second is the mapping of a whole collection from within a data model. In theData Element model there can be individual data elements such as Person First Name, and there


4


can be collections of data elements within a specific data element concept collection, forexample, Person Related Information such as Person Identifier, Person Birth Date, Person FirstName, Person Middle Name, and Person Last Name.

In the first type of left-side one-to-many relationship, the individual data element,Persons First Name would be semantically mapped to zero, one, or more attributes withindifferent entities. For example, to Employee First Name, to Customer Contact First Name, or toCausality Insurance Contract First Name.

In the second type of "left-side" relationship, a whole collection of data elements can bemapped to a whole collection of attributes across one or more entities. For example, all the DataElements within a Data Element Concept collection called Biographic Data Elements might bemapped to the entity, Person Information, or to the entity, Customer Contact Information. In thiscase, the mapping of the data elements, Person Identifier, Person First Name, etc., is mapped to acorresponding set of attributes within one or more entities.

On the right-side of Figure 1, there is also a set of one-to-many relationships. This set,like the left-side one-to-many relationships has two meanings: individual component, and wholecollections. The meanings of the right-side one-to-many relationship are different from theleft-side one-to-many. The first type of right-side relationship, the mapping of an individualcomponent is not one-to-many, but one-to-one. Thus, an individual DBMS Column, for example,EmpFrstNam can be inherited from only one higher level component, for example, the singlecolumn, EmployeeFirstName.

The second type of right-side relationship, the mapping of collections can beone-to-many. That is, one collection can map to one set of columns within one table of a singleLogical Data Model while another collection from the same Physical Data Model can be mappedto a different collection within a different Logical Data Model. Hence, the collections can beseen as "from" one Physical Data Model to zero, one, or more Logical Data Models.

3.0 Business Information Systems Work Products

We are all familiar with the collection of work products that are identified, engineered, created,evolved and maintained during the life cycle of business information systems. While there can bean endless array of names for some of these work products, they generally fall into the workproduct categories that are listed in column one of Table 2. A depiction of the interrelationshipsof the data models and of the work products is presented in Figure 2. Table 2 also shows thecross reference between the Data Architecture reference model data models and the typical workproducts of a business information system effort.

Business Information System Work Products, for example, Business Requirements,shown in Figure 2 can have a one-to-many relationship between one or more different businessinformation system work products and zero, one or more of the data models. When two or morebusiness information system work products are interrelated with one or more of the data models,there may exist relationship between those two business information system work products


5


through artifacts contained in the data models. For example, there is a business requirement tocapture student addresses. Additionally, there is a use case through which a student's address iscaptured. Apart from the obviousness of the interrelationship, the fact that there is a commondata structure, Student Address, there is an interrelationship between the two businessinformation system work products, business requirements and use cases. When both workproducts and the data models are stored in a comprehensive metadata management systems, theexposition of the business information system work product traceability of one work product tothe other is a simple report request.

Data Element Model

Concepts Data Model

Logical Data Model

Physical Data Model

SQL View Data Model

XML Interface

Model




Database Objects


Business Rules

External Data Interface

Requirements



Systems

Value Domains and

Management

User Acceptance

TestsUse Cases

Missions, Organizations and Functions

Information Needs

Database Domains

Figure 2. Cross Reference between Data Architecture Models and Business Information SystemWork Products.


6


Table 2 identifies each of the business information system work products in the datamanagement environment are listed in alphabetical order in Table 2. These are cross referencedwith the data models with which they are involved in Table 2. The data models from Figure 2that are identified in Table 2 are not accomplished in isolation. They result from an initial andthen on-going analysis of the business information system work product. That is, BusinessRequirements, Business Rules, and the like. As each of these business information system workproducts are developed, reviewed, and evolved, the effect of those activities must be reflected inone or more of the data models depicted in Figure 1 and identified in Table 2.

Work Products

Data Architecture Reference Model Component

DataElement

ConceptsData

Model

LogicalData

Model

PhysicalData

Model

ViewData

Model

XMLData

Model

Business Information Systems U U U

Business Requirements U U U U

Business Rules U U U U U

Database Domains U

Database Objects U

External Data InterfaceRequirements

U U U

Eternal Quality Standards U U U U U U

Information Needs U U

Mission Organization Functions U

Resource Life Cycles U

Use Cases U U U U

User Acceptance Tests U U U

Value Domains and Management U U U U U U

Work Breakdown Structure(WBS)

U U U U U U

Table 2. Cross reference between work products and data architecture reference modelcomponent.


7


Each of the business information system work products are identified and described in Table 3.The last column of Table 3 enumerates the key data model artifacts that are involved with thework product. The data models that contain these artifacts are identified in Table 1.

This document does not address how to create each of these business information systemwork products because the creation process is more than adequately addressed within otherWhitemarsh books, courses, seminars, and methodology documents. Rather, the focus of thisdocument presumes is to assess the necessary and sufficient interaction among all the businessinformation system work products.

Business Information System Life Cycle Work Products

Component Description Data ModelComponents

BusinessRequirements

Business Requirements are the identification, specification, anddefinition of the components that must exist in the ultimate solutiondelivered by the contractor.

Business Requirements form the foundation upon which all componentsof are engineered, implemented, and maintained. Business requirementswill evolve over time. Thus, it is important to be able to track the initialand evolved requirements. It is unrealistic to initially have allrequirements because new and/or revised requirements are discoveredall during the project’s architecture, engineering, and implementation.

Subjects,EntitiesAttributesData ElementsDatabase DomainsDatabase Objects

BusinessRules

Business Rules are assertions of truth-states in the database. Eachbusiness rule includes the identification, name, description, and exactspecification of data-based rules that must either be true or that, after theexecution of an information system process, results in a state of truth.

There are two classes of Business Rules: data and process. Almostinvariably, business rules depend on existing data, reference or controldata, or data that is determined as a consequence of a process’sexecution. Almost all business rules are mappable to data, whetherpersistent or temporary.

Business rules are almost always discovered during design sessions, anduse-case walkthroughs. As business rules are discovered, the variousdata models need to be concurrently examined to determine whether thedatabase can support the rules. Since every business rule has a processcomponent, a key component of each rule is the specification of theprocess and a determination of where that rule is bound. That is, boundinto the data model component (e.g., Data Element, or DBMS column),a low-level application component, a mid-level application process, orin the user presentation layer.

Because of this multiplicity of possible bindings, business rules need tobe centrally defined and managed, but bound only into the data model

SchemaTablesColumnsDBMS SchemaDBMS TablesDBMS ColumnsValue Domains


8




or business information system work product within which it isaccomplished.

WorkBreakdownStructure(WBS)

Work Breakdown Structures are hierarchical representations of twoclasses of effort: What, and How. The “what” type of WBS contains anaction phrase and a noun phrase that together describe what is to bedone, and the name of the work product creation or evolution.

The second class of WBS, the “how WBSs” are tuned to deliverablesbut to the actual techniques employed to accomplish the data model orbusiness information system work product.

Both the “What” WBS and the “How” WBSs need to be interlinked.Well developed metadata management systems include completeproject management so that work plans and progress against work planscan be directly tied to and integrated with accomplishments.

Subjects,EntitiesAttributesData ElementsDatabase DomainsDatabase ObjectsSchemaTablesColumnsDBMS SchemaDBMS TablesDBMS Columns

External datainterface DataRequirements

External data interface Requirements are the specifications of aninterface between an internal database data structure and some externaldata source. Each interface essentially consists of a fully defined datamodel that defines every field in the interface to the extent that asoftware module can be created to read the records represented by theinterface and take appropriate action against the database. Such actionscan be to insert, delete, or modify database records.

DBMS SchemasDBMS TablesDBMS ColumnsDBMSRelationshipsValue DomainsViewsView ColumnsRelationshipsXML SchemasXML ElementsXML Attributes

ExternalQualityStandards

External Quality Standards are de jure and de facto standards throughwhich data management products and/or processes can be judged.

The ISO Standard 11179 enables assessment of the adequacy andcompleteness of the metadata associated with data elements. Included inthis class of assessment are Concepts, Conceptual Value Domains, DataElement Concepts, Value Domains including mapping amongequivalent values, Data Element Classifications, and AdministrativeInformation (for Stewardship).

The ISO/ANSI SQL standard enables the assessment of SQL datastructures and languages employed in database designs and applicationprogram access.

SchemasTablesColumnsRelationshipsViewsView ColumnsRelationshipsXML SchemasXML ElementsXML Attributes


9




WC3 XML standards enable an analysis of the names and engineeringof XML schemas and XML data streams so as to ensure maximuminteroperability conformity to existing sets of XML schema models.

BusinessInformationBusinessInformationSystems

Business Information Systems are the broad characterizations of theapplication systems that capture, update, and report data.

Business Information Systems are additionally detailed into theirspecific components, and those that deal with database data are mappedto the appropriate data model component.

ViewsView ColumnsRelationshipsXML SchemasXML ElementsXML Attributes

Use Cases Use Cases are highly engineered pseudo-process models that clearlydefine the behavior of the users and business information systems, andalso the responses provided from the databases as they take in, modify,or provide data to users. Use-cases are detailed to the level such that aprogrammer can interpret the process intent and write an applicationsystem module without semantic and/or process misunderstanding.

Use Cases present behavior-based scenarios of the use of the databaseto accomplish the requirements. Because use-cases directly identifydatabase data, mappings can be created between one use-case andanother to identify redundancy and possible conflict. Mappings can alsobe made between the detailed data and process aspects of use-cases andbusiness requirements, deployments of use-cases in software andhardware, value domains, business rules, and WBS.

SchemasTablesColumnsRelationshipsValue DomainsDBMS SchemasDBMS TablesDBMS ColumnsDBMSRelationshipsViewsView ColumnsRelationshipsXML SchemasXML ElementsXML Attributes

UserAcceptanceTests

User Acceptance Tests are stylized user-application system interactionscripts that can be exercised to the extent that fully informed users candetermine that all the requirements have been met and all use-cases aresatisfactorily performed.

User Acceptance Tests (UAT) are the ultimate mechanisms throughwhich organizations determine that it has received the businessinformation system that was specified. Because of all the different datamodels, and work products, the User Acceptance tests can be verycomprehensive and very telling.

DBMS SchemasDBMS TablesDBMS ColumnsDBMSRelationshipsValue DomainsViewsView ColumnsRelationshipsXML SchemasXML ElementsXML Attributes

ValueDomains

Value domains relate to the allowed, disallowed, or other definedcollections of values and interconnection of values that representdiscrete choices (Gender = Male, Female, unknown), or sequenced

DBMS SchemasDBMS TablesDBMS Columns


10




states such as Applied, Reviewed, Accepted, Rejected, or Appealed.Included as well are the mappings across time of evolved and/orchanged value domains. Value domains commonly stand alone and areallocated to data elements, or to attributes, columns, or DBMS columns.In all cases of value domain allocation, the allocations must be such thatsemantics conflicts are prohibited.

DBMSRelationshipsValue DomainsViewsView ColumnsRelationshipsXML SchemasXML ElementsXML Attributes

Resource LifeCycleAnalyses

Resource Life Cycle of Analysis identifies, defines, and sets out theresources of the enterprises, the life cycles that represent theiraccomplishments, and the interrelationships among the differententerprise resource life cycles. Resource life cycle nodes represent theend-state data resulting from the execution of business informationsystems. The end-state data is represented through database objectclasses.

SchemasTablesColumnsRelationships

MissionsOrganizationsand Functions

Missions, organizations, functions, and position assignments representthe identification, definition, and interrelationships among the personswho, through their positions, perform functions within theirorganizations that accomplish enterprise missions. Missions define thevery existence of the enterprise, and that are the ultimate goals andobjectives that measure enterprise accomplishment from within differentbusiness functions and organizations. Functions represent theprocedures performed by enterprise organization groups as they achievethe various missions of the enterprise from within different enterpriseorganizations. Organizations represent the bureaucratic units created toperform through their functions the mission of the enterprise.


InformationNeeds

Information needs represent the identification, definition, andinterrelationship of the information needed by various organizations intheir functional accomplishment of missions and what databases andinformation systems provide this information?


DatabaseDomains

Database domains are the data-intensive bridge between missiondescriptions and database object classes. While database object classesare non redundant, they may be referenced by several database domains.


DatabaseObject Classes

Database object classes represent the identification of 1) the critical datastructures, 2) the processes ensure high quality and integrity data withinthese data structures, 3) the value-based states represented by these datastructures, and 4) the database object centric information systems that



11




value and transform database objects from one state to the next.Database Objects are transformed from one valid state to another insupport of fulfilling the information needs of business informationsystems as they operation within the business functions oforganizations.

Table 3. Data Management Components and affected Data Models.

4.0 Business Information System Work Products Interrelationships

Table 4 provides a cross reference between business information system work products and otherbusiness information system work products . The intention of Table 4 is that, for example, aBusiness Rule "knows about" or must take into account zero, one or more BusinessRequirements.

The assessment strategy of the involvement of both Table 3 and Table 4 is set out in theData Management WBSs that are provided in Section 6.

The implication of the interrelationships is that when a given business informationsystem work products (e.g., Business Rules) is presented for review, the interrelated data models(e.g., Data Elements) need to be assessed to determine whether there has been a completespecification.

As a presentation of an business information system work products is underway, theeffect on the interrelated data model must be determined. For example, it is not uncommon thatduring the walk through of a use-case that a large quantity of data evaluation and value settingdiscussions surface. If the data model steward is present at these sessions, the implication of thedata impact issues can be quickly identified, researched, and the impact discussed. Once ause-case walk-thru is concluded the write-up of the walk-thru would naturally have a set of dataand process impact statements.


12


Business InformationSystem Work Products

Interrelationships Among Business Information System Components

1 2 3 4 5 6 7 8 9 10 11 12 13 14

1. Business InformationSystems

na U U U U U U U U U U U

2. Business Requirements U na U U U U U U U U U U U U

3. Business Rules U U na U U U U U U

4. Database Domains na U U U

5. Database Objects U U U na U U U U

6. External Data InterfaceRequirements

U U U U na U U U U U U U

7. External Qualitystandards

U U U na U U U

8. Information Needs na U U U U U

9. Mission OrganizationFunctions

U U U U U na U U U

10. Resource Life Cycles U U U U U na U U U

11. Use Cases U U U U U U U U na U U

12. User Acceptance Tests U U U U U U na U U

13. Value Domains andManagement

U U U U U U U na U

14. Work BreakdownStructure

U U U U U U U U U U U U U na

Table 4. Interrelationships Among Business Information System Work Products.

5.0 Data Management IVV Example Scenario

The following is an example scenario of how a data management IVV activity would occur forthe evaluation of a work product. The product in question is Customer Management. The datamodels in hand were dated July 15, 2007. Thus, while these data models are likely not current,they are the only data models in possession by the IVV team. These data models do addressCustomer, Organization, Person, and Credit Form.

During the presentation of the Customer Use Case, a number of issues were presented.The following is a subset of those issues that seem to have an impact on the data models:


13


! The ability to record the change in status of a Credit Form and to maintain the history ofthose status changes.

! The ability to record the change in status of an organization, and to maintain the historyof those status changes.

! The enumeration of various statuses including what each exactly means, how it wascreated, and how it is supported by corporate credit policy.

! The recording of statuses, that is, how or what determines a status, when it wasdetermined, how it is recorded, when it can change, and the like.

! The specification of relationships between core data instances. That is, betweencustomers, organizations, persons, credit forms, and the like.

! The formal specification of business rules that clearly specify, for example, the statusissues, under what conditions the business rules are executed, the consequence of successand failure, and the like.

! How business rules are discovered, recorded, specified, prototyped, formally presented,accepted or rejected, and upon acceptance, the impacts on data models, system/processmodels, and data values is determined.

! Where business rules are bound. That is, in the presentation layer, application layer, orDBMS layer. Under what conditions is this determined and then finally resolved. Whenbusiness rules are determined to be bound into multiple places, how it is determined thatthe business rules are implemented in the same way, are tested, and finally aredocumented.

! The ability for an applicant to see history. Is the history that is seen complete or a subset?Under what rules is this determined and implemented?

At the end of the use case presentation it is presumed that the following would occur:

! A use-case presentation finding document that identifies all the issues raised and howeach issue was resolved is created.

! The findings document is sent to all involved for acceptance and/or revision.! The stewards of the affected data models and involved components (e.g., business rules,

requirements, and user acceptance tests) are tasked to formally determine the impactsfrom the use-case findings.

! Impact statements are circulated to all involved parties for review.! Accepted impact findings that result in changes are drafted into change requirements.

6.0 Data Management IVV WBS and Deliverables

The actual involvement of the six data models depicted in Figure 2 to the business informationsystem work products is set out in Section 6.1 of the Data Management WBS provided in thissection, and cross-referenced in Table 4. Section 6.2 of this section provides an business


14


information system work product interaction with one or more data models. Section 6.3 of thissection sets out the WBS for business information system work product interactions with anotherbusiness information system work products. These inter-Involved Component interactions arecross-referenced in Table 4. Each of the WBSs within sections 6.2 and 6.3:

! Identifies the materials needed for the assessment.! Sets out the high-level assessment steps.! Determines the findings and create draft assessment report! Present the findings and revise draft assessment report! Create final report and deliver to The Agency

The Data Management IVV WBSs are the complete list of both the data models (six), and thebusiness information system work products (fourteen).

Section 6.1 focuses on the work steps for assessing the completeness and quality of theindividual data models (e.g., Data Elements, Concepts, or Logical Data Model) in context withbusiness information system work products (e.g., Business Requirements, Business Rules, orUser Acceptance Tests).

Section 6.2 focuses on the work steps involved with the assessment of businessinformation system work products (e.g., Business Requirements, Business Rules, External datainterfaces, or User Acceptance Tests) with respect to the involved data models (e.g., DataElements, Concepts, or Logical Data Model). Section 6.2 does not address the completeness orquality of each business information work product. Rather it focuses on the interaction betweenbusiness information system work products and the data architecture reference model datamodels.

Section 6.3 focuses on the work steps involved with the assessment of a businessinformation system work products (e.g., Business Requirements, Business Rules, or UserAcceptance Tests) with respect to other business information system work products that likelyhave been determined earlier in the business information system development process. Hence allthe references are "backwards" references. For example, that a given business rule identifies thebusiness requirement that it fulfills, or that a task within the work breakdown structure identifiesthat business requirements, or business rules, etc., have to be properly addressed.

It is proper to include all three sets rather than just the data models set because when aninvolved area is presented or examined, it has an effect on a data model that consequently needsto be assessed and/or examined. Similarly, when a data model is developed and subsequentlyassessed, the contents of the data model must reflect on the content of one or more businessinformation system work products. Finally, when a business information system work productsis addressed it must take into account one or more predecessor business information system workproducts.

The WBS listings in Sections 6.1, 6.2, and 6.3 presume the existence of capable dataarchitects, modelers, and engineers as well as the appropriate staff for each of the involvedcomponents. Hence there are few to no details about "how" each of the tasks and/or assessments


15


is accomplished. Without such a presumption, the quantity of tasks within each of the sectionswould take many pages. Needless to say, the efficient and effective accomplishment of the WBSelements in these sections depends on the deployment of a metadata management system that notonly takes in all these data architecture reference model data models and business informationsystem work products but also completely supports their integration, interoperability, and non-redundancy. Without such a metadata management system, for example, the WhitemarshMetabase System, accomplishing this work is very problematic. It must additionally be said thatwithout such a metadata management system and without these assessments businessinformation system development success is almost accidental.

The ultimate objective is that assessments can be performed and valid conclusions drawnabout content, completeness and quality about the data models, the business information systemwork products, the interactions between the data models and the business information systemwork products, and the interaction among business information system work products.

6.1 Data Model Assessments

6.1.1 Data Model: Data Element Model Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of data element models1.1.1. Review requirements documents1.1.2. Review scope and business problem related documentation1.1.3. Identify the data elements that are to be defined and captured1.1.4. Identify the meta-artifacts appropriate to the evaluation of data element models1.2. For each data element:1.2.1. Identify components, that is, concept, conceptual value domain, value domain, data

element concept, data element classification, and data element.1.2.2. Identify the definitions for each data element model component.2. Perform the assessment2.1. Assess each data element model against business information system work product2.1.1. Assess the adequacy of each data element with respect to the business rules.2.1.1.1. Assess whether all implied business rules implied data elements are reflected in

an appropriate data element model2.1.1.2. Assess whether all data element models are reflected in business rules.2.1.2. Assess the adequacy of each data element with respect to the External Quality Standards.2.1.2.1. Assess whether every data element is properly comports to Part 3 of the ISO

11179 for data element metadata.2.1.2.2. Assess whether every data element is properly comports to Part 5 of the ISO

11179 for data element metadata.


16


2.1.2.3. Assess the Data Management Maturity Model level appropriate for the conceptdata model as it relates to process and organization.

2.1.2.4. Assess the Data Interoperability Maturity Model level appropriate for the conceptdata model as it relates to process and organization.

2.1.3. Assess the adequacy of each data element with respect to the Information Needs.2.1.3.1. Assess whether every data element is able to be inferred from an information need

that is developed during analysis and design.2.1.3.2. Assess whether every data element, inferred through information needs analysis is

in the best form for use subsequently by appropriate data models.2.1.4. Assess the adequacy of each data element with respect to the Value Domain

Management.2.1.4.1. Assess whether the set of value domains for every data element are defined

unambiguously, clearly, distinctly, and not-overlapping.2.1.4.2. Assess whether every data element that is to have a restricted value domain is

identified and is correctly addressed by the appropriate set of properly configuredvalue domain management metadata.

2.1.5 Assess the adequacy of each data element with respect to the work breakdown structure.2.1.5.1. Assess whether there is sufficient work being allocated in the WBS to discover

and to record data elements.2.1.5.2. Assess whether data elements are properly recorded when they are discovered

during data modeling efforts for Concepts, Logical, and Physical data models.2.2. Assess data element meta-artifacts2.2.1. Assess the completeness of each meta-artifact2.2.1.1. Assess that all concepts are identified and are properly constructed2.2.1.2. Assess that all conceptual value domains are identified and are properly

constructed.2.2.1.3. Assess that all value domains of conceptual value domains are identified and are

properly constructed.2.2.1.4. Assess that all data element concepts, which are the proper joining of contextual

conceptual value domains and contextually employed concepts are identified andare properly constructed.

2.2.1.5. Assess that all data elements, which are the proper joining of contextual dataelement concepts and contextually employed value domains are identified and areproperly constructed.


3. Determine the findings and create draft assessment report4. Present the findings and revise draft assessment report5. Create final report and deliver to the Agency

6.1.2 Data Model: Concepts Data Model Assessment


17


1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of concept data models1.1.1. Review requirements documents1.1.2. Review scope and business problem related documentation1.1.3. Identify the data-based concepts that are to be defined and captured1.1.4. Identify the meta-artifacts appropriate to the evaluation of concept data models1.2. For each concept: 1.2.1. Identify components, that is, subjects, entities, attributes and relationships1.2.2. Identify the definitions for each concept data model component2. Perform the assessment2.1. Assess each concept data model against business information system work product2.1.1. Assess the adequacy of each concept data model with respect to the Business

Requirements.2.1.1.1. Assess whether all implied business requirement concepts are reflected in an

appropriate concept data model2.1.1.2. Assess whether all concept data models are reflected in business requirements

2.1.2. Assess the adequacy of each concept data model with respect to the External QualityStandards.

2.1.2.1. Assess whether every data concept data model is properly reflected in a datamodel that may exist.

2.1.2.2. Assess whether every data model that may be appropriate within the collection ofconcept data models is properly defined.



2.1.4. Assess the adequacy of each concept model with respect to the Value DomainManagement.

2.1.41. Assess whether the set of value domains for every attribute is defined unambiguously,clearly, distinctly, and not-overlapping.

2.1.42. Assess whether every attribute that is to have a restricted value domain is identified andis correctly addressed by the appropriate set of properly configured value domainmanagement metadata.

2.1.4.3. Assess that every attribute value domain does not semantically conflict with adata element value domain.

2.1.4. Assess the adequacy of each concept model with respect to the work breakdownstructure.

2.1.4.1. Assess whether there are sufficient steps and processes to accomplish a completeconcepts data model for each model that is discovered.

2.1.4.2. Assess the WBS to determine whether there is sufficient automation support togenerate a prototype based on the concepts data model that can be demonstrated


18


in expectation that insufficiently identified entities, attributes, relationships andassigned data semantics are allocated, assigned, and modified as needed.

2.1.4.3. Assess the WBS to determine if there is sufficient time to ensure that everyattribute is mapped to a corresponding data element.

2.2. Assess concept data model meta-artifacts2.2.1. Assess the completeness of each meta-artifact2.2.1.1. Assess that all subjects are identified and are properly constructed2.2.1.2. Assess that all entities within subjects are identified and are properly constructed.2.2.1.3. Assess that all entity super and subtypes are identified and are properly

constructed.2.2.1.4. Assess that all entity attributes are identified and are properly constructed.2.2.1.5. Assess that all attributes are mapped to data elements2.2.1.6. Assess that appropriate attributes are properly constrained by value domain

assignments.2.2.1.7. Assess that all intra-subject entity relationships are identified and are properly

constructed. 2.2.1.8. Assess that all inter-subject entity relationships are identified and are properly

constructed.2.2.1.9. Assess that the entity's primary key exclusively consists of business-fact-data and

enables the selection of one and only one row given that the entity was animplemented DBMS table.

2.2.1.10. Assess that the collections of entity attributes are sufficient to reflect the impliedpolicy of the entity.

2.2.1.11. Assess that the collection of entity attributes are sufficient for the entity's instanceinfrastructure.

2.2.1.12. Assess that the collection of entity attributes are sufficient for history and forauditability.


3. Determine the findings and create draft assessment report4. Present the findings and revise draft assessment report5. Create final report and deliver to The Agency

6.1.3 Data Model: Logical Data Model Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of logical data models1.1.1. Review requirements documents1.1.2. Review scope and business problem related documentation1.1.3. Identify the logical data models that are to be defined and captured1.1.4. Identify the meta-artifacts appropriate to the evaluation of logical data models


19


1.2. For each logical data model: 1.2.1. Identify components, that is, schemas, tables, columns, and relationships1.2.2. Identify the definitions for each logical data model component2. Perform the assessment2.1. Assess each logical data model against business information system work product2.1.1. Assess the adequacy of each logical data model with respect to the Business

Requirements.2.1.1.1. Assess whether all implied business requirement logical data models are reflected

in an appropriate logical data model2.1.1.2. Assess whether all logical data models are reflected in business requirements2.1.2. Assess the adequacy of each logical data model with respect to the Business Rules.2.1.2.1. Assess whether all implied business rules implied logical data model components

are reflected in an appropriate logical data model2.1.2.2. Assess whether all logical data model components are reflected in business rules.2.1.3. Assess the adequacy of each logical data model with respect to Database Domains 2.1.3.1. Assess whether each logical data model table can be explicitly mapped to a noun-

phrase that is contained in the database domain.2.1.4. Assess the adequacy of each logical data model with respect to Database Objects 2.1.4.1. Assess whether each logical data model table can be explicitly mapped to a table

that is contained in the database object.2.1.5. Assess the adequacy of each logical data model with respect to the External Quality

Standards.2.1.5.1. Assess whether the facilities defined within every logical data model is properly

drawn from at most ISO ANSI Standard for entry level SQL:1992.2.1.5.2. Assess whether every logical data model that may be appropriate within the

collection of logical data models is properly defined through the use of logicaldata modeling standards.



2.1.6. Assess the adequacy of each logical data model with respect to Information Needs2.1.6.1. Assess each logical data model component can be mapped to at least one

information need item.2.1.7. Assess the adequacy of each logical data model with respect to Mission Organization

Functions2.1.7.1. Assess that each logical data model component is addressed by one or more

aspects of a mission.2.1.7.2. Assess that each logical data model component is addressed by one or more

mission-organization components.2.1.7.3. Assess that each logical data model component is addressed by one or more

mission-organization-function components.


20


2.1.8. Assess the adequacy of each logical data model with respect to Resource Life Cycles2.1.8.1. Assess that each logical data model component within the context of a database

object table is addressed by one or more resource life cycle nodes.2.1.9. Assess the adequacy of each logical data model with respect to the Use Cases.2.1.9.1. Assess whether there is a sufficient set of use cases to account for all the logical

data models.2.1.9.2. Assess whether every logical data model is addressed by at least one use case.2.1.9.3. Assess whether the use case is sufficiently detailed to fully address all the tables,

columns, and relationships of the relevant logical data model.2.1.10. Assess the adequacy of each logical data model with respect to the Value Domain

Management.2.1.10.1. Assess whether the set of value domains for every column is defined

unambiguously, clearly, distinctly, and not-overlapping.2.1.10.2. Assess whether every column that is to have a restricted value domain is

identified and is correctly addressed by the appropriate set of properly configuredvalue domain management metadata.

2.1.10.3. Assess that every column value domain does not semantically conflict with anattribute value domain.

2.1.11. Assess the adequacy of each logical data model with respect to WBS.2.1.11.1. Assess whether all implied WBS logical data models are reflected in an

appropriate logical data model2.1.11.2. Assess whether all logical data model components are reflected in one or more of

the WBS elements2.2. Assess logical data model meta-artifacts2.2.1. Assess the completeness of each meta-artifact2.2.1.1. Assess that all schemas are identified and are properly constructed2.2.1.2. Assess that all tables within the schemas are identified and are properly

constructed.2.2.1.3. Assess that all table super and subtypes are identified and are properly

constructed.2.2.1.4. Assess that all columns are identified and are properly constructed.2.2.1.5. Assess that all columns are mapped to attributes2.2.1.6. Assess that appropriate columns are properly constrained by value domain

assignments.2.2.1.7. Assess that all columns contain the appropriate integrity constraints that are

supported by assertions and triggers2.2.1.8. Assess that all stored procedures are properly identified, designed, coded and

tested to meet integrity requirements.2.2.1.9. Assess that all table relationships are identified and are properly constructed. 2.2.1.10. Assess that the table's primary key exclusively consists of business-fact-data and

enables the selection of one and only one row given that the table was animplemented DBMS table.


21


2.2.1.11. Assess that the collections of table columns are sufficient to reflect the impliedpolicy of the table.

2.2.1.12. Assess that the collection of table columns are sufficient for the table's instanceinfrastructure.

2.2.1.13. Assess that the collection of table columns are sufficient for history and forauditability.

2.2.1.14. Assess keys and relationships.2.2.1.14.1. Assess whether primary key is a surrogate key or natural key.2.2.1.14.2. Assess that one and only one row is selected if a natural key2.2.1.14.3. Assess that one and only one row of business data is selected if a surrogate key.2.2.1.14.4. Assess whether there a unique constraint comprised of natural data if row

uniqueness is enforced through a surrogate key.2.2.1.14.5. Ensure that the specification of referential integrity and referential actions

correctly matches the business requirements for data retention and deletion. 2.2.2. Assign the risk level associated with each meta-artifact not properly constructed.3. Determine the findings and create draft assessment report4. Present the findings and revise draft assessment report5. Create final report and deliver to The Agency

6.1.4 Data Model: Physical Data Model Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of physical data models1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the physical data models that are to be defined and captured.1.1.4. Identify the meta-artifacts appropriate to the evaluation of physical data models.1.2. For each physical data model:1.2.1. Identify components, that is, DBMS schemas, DBMS tables, DBMS columns, and

DBMS relationships.1.2.2. Identify the definitions for each physical data model component2. Perform the assessment2.1. Assess each physical data model against business information system work product2.1.1. Assess the adequacy of each physical data model with respect to the Business

Information Systems.2.1.1.1. Assess whether the business information systems environment on which the

physical database is to be located has the most efficient and effective architectureand deployment strategy for the performance needs of the physical model.

2.1.2. Assess the adequacy of each physical data model with respect to the BusinessRequirements.


22


2.1.2.1. Assess whether all implied business requirement physical data models arereflected in an appropriate physical data model.

2.1.2.2. Assess whether all physical data models are reflected in business requirements.2.13. Assess the adequacy of each physical data model with respect to the Business Rules.2.1.3.1. Assess whether all implied business rules implied physical data model

components are reflected in an appropriate physical data model2.1.3.2. Assess whether all physical data model components are reflected in business

rules.2.1.4. Assess the adequacy of each physical data model that is to be populated by with respect

to the External data interface Requirements.2.1.4.1. Assess whether every physical data model that is to be populated by external data

is addressed by at least one external data interface requirement.2.1.4.2. Assess whether every physical data model that is to be populated by external data

is designed appropriately so that it can respond to the external data interfacerequirement.

2.15. Assess the adequacy of each physical data model with respect to the External QualityStandards.

2.1.5.1. Assess whether the facilities defined within every physical data model is properlydrawn from an Oracle DBMS facility that is at most ISO ANSI Standard for entrylevel SQL:1992.

2.1.5.2. Assess whether every physical data model that may be appropriate within thecollection of physical data models is properly defined through the use of physicaldata modeling standards.



2.1.6 Assess the adequacy of each physical data model with respect to the Use Cases.2.1.61. Assess whether there is a sufficient set of use cases to account for all the logical data

models.2.1.62. Assess whether every physical data model is addressed by at least one use case.2.1.63. Assess whether the use case is sufficiently detailed to fully address all the tables,

columns, and relationships of the relevant logical data model.2.1.64. Assess whether the use cases properly specify the functions by organization and that the

allowed access to the column in terms of read, write, select, and update are completelyspecified.

2.1.7 Assess the adequacy of each physical data model with respect to the User AcceptanceTests.

2.1.7.1. Assess whether the tests adequately test Inserts, Deletes, and Modifies for everyphysical data model DBMS table.

2.1.7.2. Assess whether referential integrity has been sufficiently defined to correctlymodel Restrict, Set Null, and Cascade.


23


2.1.7.3. Assess whether every Referential Action is properly engineered and tested.2.1.7.4. Assess whether every value domain management action correctly executes and

provide end-user violation messages that are clear, unambiguous, and helpful tothe end user.

2.1.7.5. Assess whether every inappropriate and/or out-of-bounds value for every physicaldata model database column is appropriately trapped.

2.1.8 Assess the adequacy of each physical data model with respect to the Value DomainManagement.

2.1.8.1. Assess whether the set of value domains for every DBMS column is definedunambiguously, clearly, distinctly, and not-overlapping.

2.1.8.2. Assess whether every DBMS column that is to have a restricted value domain isidentified and is correctly addressed by the appropriate set of properly configuredvalue domain management metadata.

2.1.8.3. Assess that every DBMS column value domain does not semantically conflictwith a column value domain.

2.1.9. Assess the adequacy of each physical data model with respect to WBS.2.1.9.1. Assess whether all implied WBS physical data models are reflected in an

appropriate physical data model2.1.9.2. Assess whether all physical data model components are reflected in one or more

of the WBS elements2.2. Assess physical data model meta-artifacts2.2.1. Assess the completeness of each meta-artifact2.2.1.1. Assess that all DBMS schemas are identified and are properly constructed2.2.1.2. Assess that all DBMS tables within the schemas are identified and are properly

constructed.2.2.1.3. Assess that all DBMS table super and subtypes are identified and are properly

constructed.2.2.1.4. Assess that all DBMS columns are identified and are properly constructed.2.2.1.5. Assess that all DBMS columns contain the appropriate integrity constraints that

are supported by assertions and triggers2.2.1.6. Assess that all stored procedures are properly identified, designed, coded and

tested to meet integrity requirements.2.2.1.7. Assess that all DBMS columns are mapped to columns2.2.1.8. Assess that appropriate DBMS columns are properly constrained by value domain

assignments.2.2.1.9. Assess that all DBMS table relationships are identified and are properly

constructed. 2.2.1.10. Assess that the DBMS table's primary key exclusively consists of

business-fact-data and enables the selection of one and only one.2.2.1.11. Assess that the collections of DBMS table columns are sufficient to reflect the

implied policy of the DBMS table.


24


2.2.1.12. Assess that the collection of DBMS table columns are sufficient for the DBMStable's instance infrastructure.

2.2.1.13. Assess that the collection of DBMS table columns are sufficient for history andfor auditability.

2.2.1.14. Assess keys and relationships.2.2.1.14.1. Assess whether primary key is a surrogate key or natural key.2.2.1.14.2. Assess that one and only one row is selected if a natural key2.2.1.14.3. Assess that one and only one row of business data is selected if a surrogate key.2.2.1.14.4. Assess whether there a unique constraint comprised of natural data if row

uniqueness is enforced through a surrogate key.2.2.1.14.5. Ensure that the specification of referential integrity and referential actions

correctly matches the business requirements for data retention and deletion.2.2.1.15. Assess the SQL DDL Scripts2.2.1.15.1. Ensure that the SQL scripts for reference data match the value domain

requirements2.2.1.15.2. Ensure that the SQL scripts for security roles match the security requirements as

it relates to the use cases, named user roles, organizations, and extent ofpermission to read, write, update, and select data.

2.2.1.15.3. Ensure that the SQL scripts for primary key sequence value specifications matchthe primary key requirements

2.2.1.15.4. Ensure that the SQL scripts for tables, columns and appropriate key specificationsmatch the DBMS table requirements

2.2.1.15.5. Ensure that the SQL scripts for triggers and other stored procedures match thedata integrity constraints



6.1.5 Data Model: SQL View Data Model Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of view data models1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the view data models that are to be defined and captured.1.1.4. Identify the meta-artifacts appropriate to the evaluation of view data models.1.2. For each view data model:1.2.1. Identify components, such as, views, view columns, select and join clauses.1.2.2. Identify the definitions for each view data model component.


25


2. Perform the assessment2.1. Assess each view data model against business information system work product2.1.1. Assess the adequacy of each view data model with respect to the Business Information

Systems.2.1.1.1. Assess whether every view data model is properly interfaced with one or more

business information systems.2.1.1.2. Ensure that every information system has database access only through a view

data model.2.1.2. Assess the adequacy of each view data model with respect to the Business Rules.2.1.2.1. Assess whether all implied business rules implied view data model components

are reflected in an appropriate view data model2.1.2.2. Assess whether all view data model components are reflected in business rules.

2.1.3. Assess the adequacy of each view data model that is to be populated by with respect tothe External data interface Requirements.

2.1.3.1. Assess whether every view data model that is to be populated by external data isaddressed by at least one external data interface requirement.

2.1.3.2. Assess whether every view data model that is to be populated by external data isdesigned appropriately so that it can respond to the external data interfacerequirement.

2.1.4. Assess the adequacy of each view data model with respect to the External QualityStandards.

2.1.4.1. Assess whether the facilities defined within every physical data model is properlydrawn from an Oracle DBMS facility that is at most ISO ANSI Standard for entrylevel SQL:1992.

2.1.4.2. Assess whether every physical data model that may be appropriate within thecollection of physical data models is properly defined through the use of theAgency physical data modeling standards.



2.1.5. Assess the adequacy of each view data model with respect to the Use Cases.2.1.5.1. Assess whether the use cases adequately specify the complete set of Inserts,

Deletes, and Modifies.2.1.5.2. Assess whether every value domain management action correctly executes and

provide end-user violation messages that are clear, unambiguous, and helpful asspecified in one or more use cases.

2.1.5.3. Assess whether every inappropriate and/or out-of-bounds value for every physicaldata model database column is appropriately trapped as specified in a use case.

2.1.6 Assess the adequacy of each view data model with respect to the User Acceptance Tests.


26


2.1.6.1. Assess whether the tests adequately test Inserts, Deletes, and Modifies for everyview data model DBMS table.

2.1.6.2. Assess whether referential integrity has been sufficiently defined to accomplishthe behavior defined within the view data model.

2.1.6.3. Assess whether every value domain management action correctly executes andprovide end-user violation messages that are clear, unambiguous, and helpful tothe end user.

2.1.6.4. Assess whether every inappropriate and/or out-of-bounds value for every physicaldata model database column is appropriately trapped.

2.1.6.5. Asses whether the view-based derived and compound columns, selects, nestedselects, and the defined classes of joins are properly defined and product thepre-defined expected results.

2.1.7. Assess the adequacy of each view data model with respect to the Value DomainManagement.

2.1.7.1. Assess whether the set of value domains for every view column defined withinthe physical data model is employed appropriately within the view.

2.1.7.2. Assess whether every view column that has a corresponding DBMS columnrestricted value domain is identified and is correctly addressed by the appropriateset of properly configured value domain management metadata.

2.1.7. Assess the adequacy of each view data model with respect to the WBS2.1.7.1. Assess whether there are sufficient resources and processes contained within the

WBS to properly accomplish the specification of a view data model.2.1.7.2. Assess whether there are sufficient resources and processes contained within the

WBS to properly accomplish the creation of SQL view DDL including its testing.2.2. Assess view data model meta-artifacts2.2.1. Assess the completeness of each meta-artifact2.2.1.1. Assess that all views are identified and are properly constructed2.2.1.2. Assess that all view columns are identified and are properly constructed.2.2.1.3. Assess that all view columns are mapped to DBMS columns2.2.1.4. Assess that all view columns contain the appropriate integrity constraint clauses2.2.1.5. Assess that all selects, nested selects, joins, renames, derived and compound data

view columns are properly constructed.2.2.2. Assign the risk level associated with each meta-artifact not properly constructed.


6.1.6 Data Model: XML Interface Model Assessment

1. Identify artifacts that bear on the assessment


27


1.1. Identify the appropriate set of XML interface models1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the XML interface models that are to be defined and captured.1.1.4. Identify the meta-artifacts appropriate to the evaluation of XML interface models.1.2. For each XML interface model:1.2.1. Identify components, such as, XML schema, XML element, and XML attributes.1.2.2. Identify the definitions for each XML interface model component.2. Perform the assessment2.1.1. Assess the adequacy of each XML data model with respect to the Business Information

Systems.2.1.1.1. Assess whether every XML data model is properly interfaced with one or more

business information systems as may be appropriate.2.1.1.2. Ensure that every appropriate information system has database access only

through a XML data model.2.1.2. Assess the adequacy of each XML data model with respect to Business Requirements.2.1.2.1. Assess that all the business requirements that state or imply the use of XML are

properly reflected in the XML data model.2.1.3. Assess the adequacy of each XML data model with respect to Business Rules.2.1.3.1. Assess that all the business rules that state or imply the use of XML are properly

reflected in the XML data model2.1.4. Assess the adequacy of each XML data model that is to be populated by with respect to

the External data interface Requirements.2.1.4.1. Assess whether every XML data model that is to be populated by external data is

addressed by at least one external data interface requirement.2.1.4.2. Assess whether every XML data model that is to be populated by external data is

designed appropriately so that it can respond to the external data interfacerequirement.

2.1.5. Assess the adequacy of each XML data model with respect to the External QualityStandards.

2.1.5.1. Assess whether the facilities defined within every XML data model is properlydrawn from an established set of conventions from within the W3C.

2.1.5.2. Assess whether every XML data model that may be appropriate within thecollection of XML data models is properly defined through the use of theAgencyXML data modeling standards.

2.1.5.3. Assess whether every XML data model that may be appropriate within thecollection of XML data models is properly defined through the use of CIOCouncil for XML data modeling standards.

2.1.5.4. Assess whether every XML data model that may be appropriate within thecollection of XML data models is properly defined through the use of the AgencyXLM data modeling standards.


28




2.1.6. Assess the adequacy of each XML data model with respect to the Use Cases.2.1.6.1. Assess whether the use cases adequately specify the required XML Schema and

that the XML Schema appropriately maps to the DBMS Data Model.2.1.7. Assess the adequacy of each XML data model with respect to the User Acceptance Tests.2.1.7.1. Assess whether the tests adequately test Inserts, Deletes, and Modifies for every

XML data model DBMS table.2.1.7.2. Assess whether every value domain management action correctly executes and

provide end-user violation messages that are clear, unambiguous, and helpful tothe end user.

2.1.7.3. Assess whether every inappropriate and/or out-of-bounds value for every XMLdata model database column is appropriately trapped.

2.1.8. Assess the adequacy of each XML data model with respect to the Value DomainManagement.

2.1.8.1. Assess whether the set of value domains for every XML element is definedunambiguously, clearly, distinctly, and not-overlapping.

2.1.8.2. Assess whether every XML element that is to have a restricted value domain isidentified and is correctly addressed by the appropriate set of properly configuredvalue domain management metadata.

2.1.8.3. Assess that every XML element value domain does not semantically conflict witha DBMS column value domain.

2.1.9. Assess the adequacy of each XML data model with respect to WBS.2.1.9.1. Assess whether all implied WBS XML data models are reflected in an appropriate

XML data model2.1.9.2. Assess whether all XML data model components are reflected in one or more of

the WBS elements 2.2. Assess XML data model meta-artifacts2.2.1. Assess the completeness of each meta-artifact2.2.1.1. Assess that all XML schemas are identified and are properly constructed2.2.1.2. Assess that all XML elements within the schemas are identified and are properly

constructed.2.2.1.3. Assess that all XML elements are mapped to DBMS columns2.2.1.4. Assess that appropriate XML elements are properly constrained by value domain

assignments.2.2.1.5. Assess that the collections of XML elements are sufficient to reflect the implied

policy of the mapped to one or more DBMS tables.2.2.1.6. Assess that the collection of XML elements are sufficient to present the

information necessary for updating a DBMS table's instance infrastructure.


29


2.2.1.7. Assess that the collection of XML elements are sufficient to present theinformation necessary for updating a DBMS table's history and for auditability.



6.2 Business Information System Work Product to Data Model Assessments

6.2.1 Business Information Systems Assessment1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of business information systems documents1.1.1. Review business information systems documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the business information system that is defined and captured.1.1.4. Identify the business information systems related data architecture reference model data

model components.1.2. For each business information system work product:1.2.1. Identify the relevant data architecture reference model, that is, Physical Data Model,

View Data Model, and XML Data Model1.2.2. Identify the description for each interrelated Business Information Systems data model

component.2. Perform the assessment2.1. Assess the adequacy of each physical data model with respect to the Business

Information Systems2.1.1. Assess whether every DBMS column from every table is addressed through an insert,

update, or possibly delete by at least one module of a software system.2.1.2. Assess whether every identified business rule is properly accomplished by one or more

appropriate modules of a software system.2.1.3. Assess whether every value domain value for every restricted value domain DBMS

column is properly addressed by one or more appropriate modules of a software system.2.1.4. Assess whether all user acceptance tests are properly addressed by one or more

appropriate modules of a software system.2.1.5. Assess whether all use cases are completely and properly addressed by one or more

appropriate modules of a software system.2.1.6. Assess whether all data updates are properly recorded on a re-processable audit train.2.1.7. Assess whether all data updates are able to be properly backed out as may be allowed by

a use case.2.2. Assess the adequacy of each view data model with respect to the Business Information

Systems.


30


2.2.1. Assess whether every view column from every view is addressed through an insert,update, or possibly delete by at least one module of a software system..

2.2.2. Assess whether every identified business rule is properly accomplished by one or moreappropriate modules of a software system.

2.2.3. Assess whether every value domain value for every restricted value domain DBMScolumn is properly addressed by one or more appropriate modules of a software system.

2.2.4. Assess whether all user acceptance tests are properly addressed by one or moreappropriate modules of a software system.

2.2.5. Assess whether all use cases are completely and properly addressed by one or moreappropriate modules of a software system.

2.2.6. Assess whether all data updates are properly recorded on a re-processable audit train.2.2.7. Assess whether all data updates are able to be properly backed out as may be allowed by

a use case.2.3. Assess the adequacy of each XML data model with respect to the Business Information

Systems.2.3.1. Assess whether an XML data package is properly constructed by the appropriate software

system according to the XML Schema.2.3.2. Assess whether an XML data package is properly read and the appropriate updates are

made to the database by the appropriate software system according to the rules set out inthe XML Schema.

2.4. Assign the risk level associated with each meta-artifact not properly constructed.3. Determine the findings and create draft assessment report4. Present the findings and revise draft assessment report5. Create final report and deliver to The Agency


1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of business requirements documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the business requirement that is defined and captured.1.1.4. Identify the business requirements related data architecture reference model data model

components.1.2. For each business requirement work product:1.2.1. Identify the relevant data architecture reference model, that is, Concepts Data Model,

Logical Data Model, Physical Data Model, and XML Data Model1.2.2. Identify the description for each interrelated business requirement data model

component.2. Perform the assessment.


31


2.1. Assess the adequacy of each concept data model with respect to the businessrequirement.

2.1.1. Assess whether all the implied concept data model components, that is, Subject, Entity,Attribute, Assigned Value Domain, and Relationship from the business requirement havebeen addressed in one or more aspects of the concept data model.

2.1.2. Assess concept data model components, that is, Subject, Entity, Attribute, AssignedValue Domain, and Relationship with respect to the specific business requirement aresufficiently specified.

2.1.3. Assess whether every Subject, Entity, Attribute, Assigned Value Domain, andRelationship is called for by one or more business requirement.

2.2. Assess the adequacy of each logical data model with respect to the business requirement.2.2.1. Assess whether all the implied logical data model components, that is, Schema, Table,

Column, Assigned Value Domain, and Relationship from the business requirement havebeen addressed in one or more aspects of the logical data model.

2.2.2. Assess logical data model components, that is, Schema, Table, Column, Assigned ValueDomain, and Relationship with respect to the specific business requirement aresufficiently specified.

2.2.3. Assess whether every Schema, Table, Column, Assigned Value Domain, andRelationship is called for by one or more business requirement.

2.3. Assess the adequacy of each physical data model with respect to the businessrequirement.

2.3.1. Assess whether all the implied physical data model components, that is, DBMS schema,DBMS tables, and DBMS columns from the business requirement have been addressed inone or more aspects of the physical data model.

2.3.2. Assess physical data model components, that is, DBMS Schema, DBMS Table, DBMSColumn, Assigned Value Domain, and Relationship with respect to the specific businessrequirement are sufficiently specified.

2.3.3. Assess whether every DBMS Schema, DBMS Table, DBMS Column, Assigned ValueDomain, and Relationship is called for by one or more business requirement.

2.4. Assess the adequacy of each XML data model with respect to the business requirement.2.4.1. Assess whether all the implied XML data model components, that is, XML schema,

XML elements and supporting XML structures from the business requirement have beenaddressed in one or more aspects of the XML data model.

2.4.2. Assess XML data model components, that is, XML schema, XML elements andsupporting XML structures with respect to the specific business requirement aresufficiently specified.

2.4.3. Assess whether every XML schema, XML elements and supporting XML structures iscalled for by one or more business requirement.


3. Determine the findings and create draft assessment report4. Present the findings and revise draft assessment report


32


5. Create final report and deliver to The Agency

6.2.3 Business Rules Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of business rule documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the business rule that is defined and captured.1.1.4. Identify the business rule related data architecture reference model data model

components.1.2. For each business rule work product:1.2.1. Identify the relevant data architecture reference model, that is, Data Element Model,

Logical Data Model, Physical Data Model, View Data Model, and XML Data Model 1.2.2. Identify the description for each interrelated Business Rules data model component.2. Perform the assessment2.1. Assess the adequacy of each data element model with respect to the business rule. 2.1.1. Assess whether all the implied data element model components, that is, Value Domains,

and Data Elements from the business rule have been addressed in one or more aspects ofthe data element model.

2.1.2. Assess data element model components, that is, Value Domains, and Data Elements withrespect to the specific business rule are sufficiently specified.

2.1.3. Assess whether every Value Domain and Data Element is called for by one or morebusiness requirement.

2.2. Assess the adequacy of each logical data model with respect to the business rule.2.2.1. Assess whether all the implied logical data model components, that is, Column, and

Assigned Value Domain from the business rule have been addressed in one or moreaspects of the logical data model.

2.2.2. Assess logical data model components, that is, Column, and Assigned Value Domainwith respect to the specific business rule is sufficiently specified.

2.2.3. Assess whether every Column and Assigned Value Domain is called for by one or morebusiness requirement.

2.3. Assess the adequacy of each physical data model with respect to the businessrequirement.

2.3.1. Assess whether all the implied physical data model components, that is, DBMS columnsand Assigned Value Domains from the business rule have been addressed in one or moreaspects of the physical data model.

2.3.2. Assess physical data model components, that is, DBMS Column, and Assigned ValueDomain with respect to the specific business rules are sufficiently specified.

2.3.3. Assess whether the business rule use of DBMS columns are appropriate with respect todata type, allowed operation, and if appropriate SQL functions.


33


2.3.4. Assess whether business rule stored procedure implementations are correctly engineeredand result in unambiguous messages provided the end user or up through the applicationsystem calling sequence.

2.3.5. Assess whether every DBMS Column and Assigned Value Domain is called for by oneor more business requirement.

2.4. Assess the adequacy of each View data model with respect to the business requirement.2.4.1. Assess whether all the implied View data model components, that is, view and view

columns from the business rule have been addressed in one or more aspects of the XMLdata model.

2.4.2. Assess View data model components, that is, view and view columns with respect to thespecific business rule are sufficiently specified.

2.4.3. Assess whether the business rule use of view columns are appropriate with respect toallowed functionality of views.

2.4.4. Assess whether business rule stored procedure implementations are correctly engineeredand result in unambiguous messages provided the end user or up through the applicationsystem calling sequence.

2.4.5. Assess whether every view and view column is called for by one or more businessrequirement.

2.5. Assess the adequacy of each XML data model with respect to the business requirement.2.5.1. Assess whether all the implied XML data model components, that is, XML schema,

XML elements and supporting XML structures from the business rule have beenaddressed in one or more aspects of the XML data model.

2.5.2. Assess XML data model components, that is, XML schema, XML elements andsupporting XML structures with respect to the specific business rule are sufficientlyspecified.

2.5.3. Assess whether every XML schema, XML elements and supporting XML structures iscalled for by one or more business requirement.



6.2.4 Database Domains Assessment1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of database domain documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the database domain that is defined and captured.1.1.4. Identify the database domain related data architecture reference model data model

components.


34


1.2. For each database domain work product:1.2.1. Identify the relevant data architecture reference model, that is, Data Element Model, and

Logical Data Model1.2.2. Identify the description for each interrelated database domain component.2. Perform the assessment2.1. Assess the adequacy of each database domain with respect to the data element model. 2.1.1. Assess whether the appropriate noun phrases contained in a database domain are properly

allocated to data elements.2.2. Assess the adequacy of each database domain with respect to the logical data model. 2.2.1. Assess whether the appropriate noun phrases contained in a database domain are properly

allocated to database object tables, or to property classes (likely to then become tables).2.3. Assess the adequacy of each database domain. 2.3.1. Assess whether all the noun phrases contained in a database domain have been properly

allocated to data elements or database object tables, or to property classes (likely to thenbecome tables).


6.2.5 Database Objects Assessment1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of database object documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the database object that is defined and captured.1.1.4. Identify the database object related data architecture reference model data model

components.1.2. For each database object work product:1.2.1. Identify the relevant data architecture reference model, that is, Logical Data Model1.2.2. Identify the description for each interrelated database object component.2. Perform the assessment2.1. Assess whether the appropriate tables contained in a database object are properly

allocated.2.2. Assess whether all the logical data model tables have been properly allocated to database

object tables.2.3. Assess whether all the logical data model table processes properly add, delete, or modify

all table columns allocated to the database object table.2.4. Assess whether database object table processes, upon failure return the database object

table row to its original state.2.5. Assess whether all the logical data model tables have been properly allocated to database

object states.


35


2.6. Assess whether all the logical data model table states proceed from the null state to aseries of valued-states in a proper sequence and finally return to a null state.

2.7. Assess whether all the database object information systems are properly engineered totransform database object tables from one valid state to the next.


6.2.6 External data interface Requirements Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of External data interface Requirements documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the external data interface requirement that is defined and captured.1.1.4. Identify the external data interface requirement related data architecture reference model

data model components.1.2. For each external data interface requirement system work product:1.2.1. Identify the relevant data architecture reference model, that is, Physical Data Model,

View Data Model, and XML Data Model 1.2.2. Identify the description for each interrelated External data interface Requirements data

model component.2. Perform the assessment2.1. Assess the adequacy of each physical data model with respect to the External data

interface Requirements2.1.1. Assess whether the external data interface is sufficiently identified and specified to the

level that an Extract, Transform, and Load process can be expertly constructed.2.1.2. Assess whether there is sufficient detail to the external data interface to unambiguously

address issues related to granularity of both sides of the interface, precision of the variousvalues for the data fields, and an exact matching of the values for any data fields that is tobe imported.

2.1.3. Assess whether there is sufficient information to be able to fill out audit trail informationand to be able to back out data once it has been imported.

2.2. Assess the adequacy of each view data model with respect to the External data interfaceRequirements.

2.2.1. Assess whether the external data interface is sufficiently identified and specified to thelevel that a set of views can be constructed to directly import the data from a connectedsource.

2.2.2. Assess whether there is sufficient detail to the external data interface to unambiguouslyconstruct views that that address the granularity of both sides of the interface, precision


36


of the various values for the data fields, and an exact matching of the values for any datafields that is to be imported.

2.2.3. Assess whether there is sufficient information to be able to fill out audit trail informationbuilt into views.

2.3. Assess the adequacy of each XML data model with respect to the External data interfaceRequirements.

2.3.1. Assess whether the external data interface is sufficiently identified and specified to thelevel that a set of XML Schemas can be constructed to process data that is exported fromexternal sources.

2.3.2. Assess whether there is sufficient detail to the external data interface to unambiguouslyconstruct XML schemas that that address the granularity of both sides of the interface,precision of the various values for the data fields, and an exact matching of the values forany data fields that is to be imported.

2.3.3. Assess whether there is sufficient information to be able to fill out audit trail informationbuilt into the XML schemas.


6.2.7 External Quality Standards Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of External Quality Standards documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the external quality standard that is defined and captured.1.1.4. Identify the external quality standard data architecture reference model data model

components.1.2. For each external quality standard work product:1.2.1. Identify the relevant data architecture reference model, that is, Data Element Model,

Concepts Data Model, Logical Data Model, Physical View Data Model, View DataModel and XML Data Model

1.2.2. Identify the description for each interrelated External Quality Standards data modelcomponent.

2. Perform the assessment2.1. Assess the components of the Data Element Model against required metadata

components from ISO 11179 standard (Part 3) for data element metadata.2.2. Assess the components of the Concepts Data Model against the required metadata for the

U.S. Federal The Agency CIO Council's Data Performance Plan


37


2.3. Assess the components of the Logical Data Model against ISO ANSI SQL 1992 EntryLevel.

2.4. Assess the components of the Physical Data Model against Oracle 10g but not to containany SQL facility and/or syntax that exceeds ISO ANSI SQL 1992 Entry Level without aspecific waver.

2.5. Assess the components of the View Data Model against ISO ANSI SQL 1992 EntryLevel.

2.6. Assess the components of the XML Data Model against W3C guidelines, the U.S.Department of Justice's NEAM model, and the XML Guidelines published by the U.S.Department of the Navy.


6.2.8 Information Needs Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of Information Needs documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the information need that is defined and captured.1.1.4. Identify the information need related data architecture reference model data model

components.1.2. For each information need system work product:1.2.1. Identify the relevant data architecture reference model, that is, Data Elements and

Logical Data Model1.2.2. Identify the description for each interrelated Information Needs component.2. Perform the assessment2.1. Assess the adequacy of each data element with respect to Information Needs 2.1.1. Assess each information need component that is inferred to be a data element is

represented appropriately as a data element.2.1.2. Assess each information need component that is inferred to be a data element and ensure

that it is both atomic and non-derived. 2.1.3. Assess each information need component that is inferred to be a data element and ensure

that it contains the proper data type, scale, and precision. 2.1.4. Assess each information need component that is inferred to be a data element and ensure

that it contains the proper value domain mappings.. 2.2. Assess the adequacy of each logical data model with respect to Information Needs 2.2.1. Assess each information need component that is inferred to be a table is represented

within a table within a logical data model.


38


2.2.2. Assess each information need component that is inferred to be a table is representedappropriately by one or more table columns in terms of the information need’s name,description and purpose.

2.2.3. Assess each information need component that is inferred to be a table is representedappropriately by one or more table columns within a logical data model in terms of datatype, scale, precision, granularity and temporalness.


6.2.9 Mission Organization Function Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of Mission Organization Function documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the mission organization functions that are defined and captured.1.1.4. Identify the mission organization funcion related data architecture reference model data

model components.1.2. For each mission organization funcion work product:1.2.1. Identify the relevant data architecture reference model, that is, Logical Data Model2. Perform the assessment2.1. Assess whether each mission is addressed by one or more logical data model tables to

ensure complete coverage.2.2. Assess whether each organization is addressed by one or more logical data model tables

with respect to adding, modifying, or deletion.2.3. Assess whether each function is addressed by one or more logical data model tables with

respect to having the appropriate processes to accomplish adding, modifying, ordeletion..

2.4. Assess whether each mission-organization is addressed by one or more logical datamodel tables to appropriateness of coverage within the organization and to ensureeconomy of work.

2.5. Assess whether each mission-organization-function is addressed by one or more logicaldata model tables to appropriateness of coverage within functions performed by variousmission-organizations to ensure economy of work.

3. Determine the findings and create draft assessment report.4. Present the findings and revise draft assessment report.5. Create final report and deliver to The Agency.

6.2.10 Resource Life Cycles Assessment


39


1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of Resource Life Cycle documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the resource life cycle that is defined and captured.1.1.4. Identify the resource life cycle related data architecture reference model data model

components.1.2. For each resource life cycle work product:1.2.1. Identify the relevant data architecture reference model, that is, Logical Data Model1.2.2. Identify the description for each interrelated Resource Life Cycle data model component.2. Perform the assessment2.1. Assess the adequacy of the resource life cycle node database object assignment.2.2. Assess the adequacy of the resource life cycle node database object assignment to a

database table.2.3. Assess the adequacy of the resource life cycle node database object assignment to one or

more database table columns in terms of name, description and purpose.2.4. Assess the adequacy of the resource life cycle node database object assignment to one or

more database table columns in terms of data type, scale, precision, granularity andtemporalness.

3. Determine the findings and create draft assessment report.4. Present the findings and revise draft assessment report.5. Create final report and deliver to The Agency.

6.2.11 Use Cases Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of Use Case documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the use case that is defined and captured.1.1.4. Identify the use case related data architecture reference model data model components.1.2. For each use case work product:1.2.1. Identify the relevant data architecture reference model, that is, Logical Data Model,

Physical Data Model, View Data Model, and XML Data Model1.2.2. Identify the description for each interrelated Use Cases data model component.2. Perform the assessment2.1. Assess the adequacy of each logical data model with respect to the Use Cases2.1.1. Assess whether every user case implied logical data model components are properly

constructed in the concept data model, that is, Schemas, Tables, Columns, and AssignedValue Domains.

2.1.2. Assess whether every user case implied logical data model table column


40


2.1.3. Assess whether every user case implied one or more logical data model table columns isproperly defined in terms of name, description and purpose.

2.1.4. Assess whether every user case implied one or more logical data model table columns isproperly defined in terms of data type, scale, precision, granularity and temporalness.

2.1.5. Assess whether every value domain value for every restricted value domain databasetable column is properly addressed by one or more appropriate modules of a use case.

2.2. Assess the adequacy of each physical data model with respect to the Use Cases2.2.1. Assess whether every DBMS column from every table is addressed through an insert,

update, or possibly delete by at least one component and/or section of a use case.2.2.2. Assess whether every identified business rule is properly accomplished by one or more

appropriate modules of a use case.2.2.3. Assess whether every value domain value for every restricted value domain DBMS

column is properly addressed by one or more appropriate modules of a use case.2.2.4. Assess whether all data updates are able to be properly backed out as may be allowed by

a use case.2.3. Assess the adequacy of each view data model with respect to the Use Cases.2.3.1. Assess the adequacy of each view data model with respect to the Use Cases2.3.2. Assess whether every view column from every table is addressed through an insert,

update, or possibly delete by at least one component and/or section of a use case.2.3.3. Assess whether every identified business rule is properly accomplished by one or more

appropriate modules of a use case.2.3.4. Assess whether every value domain value for every restricted value domain DBMS

column is properly addressed by one or more appropriate modules of a use case.2.3.5. Assess whether all data updates are able to be properly backed out as may be allowed by

a use case.2.4. Assess the adequacy of each XML data model with respect to the Use Cases.2.4.1. Assess whether an XML data package is specified in sufficient detail as to be

unambiguous.2.4.2. Assess whether an XML data package is specified in sufficient detail to ensure that it can

be unambiguous properly read and the appropriate updates are made to the database.2.5. Assign the risk level associated with each meta-artifact not properly constructed.3. Determine the findings and create draft assessment report.4. Present the findings and revise draft assessment report.5. Create final report and deliver to The Agency.

6.2.12 User Acceptance Tests Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of user acceptance test assessment documents1.1.1. Review user acceptance test assessment documents.1.1.2. Review scope and business problem related documentation.


41


1.1.3. Identify the use acceptance test that is defined and captured.1.1.4. Identify the use acceptance test related data architecture reference model data model

components.1.2. For each user acceptance test work product1.2.1. Identify the relevant data architecture reference model, that is, Logical Data Model,

Physical Data Model, View Data Model, and XML Data Model1.2.2. Identify the description for each interrelated User Acceptance Test data model

component.2. Perform the assessment2.1. Assess the adequacy of each physical data model with respect to User Acceptance Tests2.1.1. Assess whether every DBMS column from every table is addressed through an insert,

update, or possibly delete by at least one component and/or section of a User AcceptanceTest.

2.1.2. Assess whether every identified business rule is properly accomplished by one or moreappropriate modules of a User Acceptance Test.

2.1.3. Assess whether every value domain value for every restricted value domain DBMScolumn is properly addressed by one or more appropriate modules of a User AcceptanceTest.

2.1.4. Assess whether all data updates are able to be properly backed out as may be allowed bya User Acceptance Test.

2.2. Assess the adequacy of each view data model with respect to User Acceptance Tests.2.2.1. Assess the adequacy of each view data model with respect to User Acceptance Tests2.2.2. Assess whether every view column from every table is addressed through an insert,

update, or possibly delete by at least one component and/or section of a User AcceptanceTest.

2.2.3. Assess whether every identified business rule is properly accomplished by one or moreappropriate modules of a User Acceptance Test.

2.2.4. Assess whether every value domain value for every restricted value domain DBMScolumn is properly addressed by one or more appropriate modules of a User AcceptanceTest.

2.2.5. Assess whether all data updates are able to be properly backed out as may be allowed bya User Acceptance Test.

2.3. Assess the adequacy of each XML data model with respect to User Acceptance Tests.2.3.1. Assess whether an XML data package is specified in sufficient detail as to be

unambiguous.2.3.2. Assess whether an XML data package is specified in sufficient detail to ensure that it can

be unambiguous properly read and the appropriate updates are made to the database.2.4. Assign the risk level associated with each meta-artifact not properly constructed.3. Determine the findings and create draft assessment report4. Present the findings and revise draft assessment report5. Create final report and deliver to The Agency


42


6.2.13 Value Domains and Management Assessment

1.1. Identify the appropriate set of value domain management assessment documents1.1.1. Review value domain management documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the value domains that is defined and captured.1.1.4. Identify the value domain related data architecture reference model data model

components.1.2. For each value domain management work product:1.2.1. Identify the relevant data architecture reference model, that is, Data Element Model,

Concept Data Model, Logical Data Model, Physical Data Model, View Data Model, andXML Data Model

1.2.2. Identify the description for each interrelated Value Domain Management data modelcomponent.

2. Perform the assessment2.1. Assess the adequacy of each data element model with respect to Value Domain

Management.2.1.1. Assess whether each value domain is properly specified and that all value domain values

allowed are well defined, non-overlapping, and have been formally approved for use inthe databases and enforced through the business information systems.

2.1.2. Assess whether restricted value data elements are properly assigned a specific valuedomain.

2.2. Assess the adequacy of each concept data model with respect to Value DomainManagement.

2.2.1. Assess whether a value domain that is assigned to an attribute is a subset of a valuedomain that is assigned to a data element.

2.3. Assess the adequacy of each logical data model with respect to Value DomainManagement .

2.3.1. Assess whether a value domain that is assigned to an column is a subset of a valuedomain that is assigned to an attribute.

2.4. Assess the adequacy of each physical data model with respect to the Value DomainManagement.

2.4.1. Assess whether a value domain that is assigned to a DBMS column is a subset of a valuedomain that is assigned to a column.

2.5. Assess the adequacy of each view data model with respect to the Value DomainManagement.

2.5.1. Assess whether each view column is properly established to enforce a DBMS column'sassigned value domain.

2.5.2. Assess whether each software system module that employs a view column that representsa restricted value domain is established such that it will only allow legal values.

2.6. Assess the adequacy of each XML data model with respect to the Value DomainManagement.


43


2.6.1. Assess whether each view column is properly established to enforce a DBMS column'sassigned value domain.

2.6.2. Assess whether each software system module that employs an XML element thatrepresents a restricted value domain is established such that it will only allow legalvalues.


6.2.14 Contract Work Breakdown Structure (WBS) Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of WBS documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the WBSs that are defined and captured.1.1.4. Identify the WBS related data components.1.2. For each WBS development, review, or evolution effort:1.2.1. Identify the relevant components, that is, Data Element Model, Concepts Data Model,

Logical Data Model, Physical Data Model, and XML Data Model 1.2.2. Identify the description for each interrelated WBS data model component.2. Perform the assessment2.1. Assess the adequacy of each data element data model with respect to the WBS.2.1.1. Assess whether all the implied data element data model components have been delivered

in terms of components, instances, and stored metadata work products.2.1.2. Assess whether all the implied data element data model components have been properly

detailed as to methodology, evaluation, presentation, and delivery work steps.2.1.3. Assess whether all the implied data element data model components have been properly

allocated sufficient unit effort estimates.2.1.4. Assess whether all the implied data element data model components have been properly

allocated sufficient quantity of units that have to be developed.2.1.5. Assess whether all the implied data element data model components have been properly

allocated work environment factors to determine an accurate estimate of requiredresources.

2.1.6. Assess whether all the implied data element data model components have been properlyallocated work accomplishment and recording functions necessary to support earnedvalue reporting.

2.1.7. Assess whether all the implied data element data model components have been properlyallocated metadata recording effort to ensure that all interrelationships are properlyrecorded into the metadata management system database.


44


2.2. Assess the adequacy of each concepts data model with respect to the WBS.2.2.1. Assess whether all the implied concepts data model components have been delivered in

terms of components, instances, and stored metadata work products.2.2.2. Assess whether all the implied concepts data model components have been properly

detailed as to methodology, evaluation, presentation, and delivery work steps.2.2.1. Assess whether all the implied concepts data model components have been delivered in

terms of components, instances, and stored metadata work products.2.2.2. Assess whether all the implied concepts data model components have been properly

detailed as to methodology, evaluation, presentation, and delivery work steps.2.2.2. Assess whether all the implied concepts data model components have been properly

allocated sufficient unit effort estimates.2.2.3. Assess whether all the implied concepts data model components have been properly

allocated sufficient quantity of units that have to be developed.2.2.4. Assess whether all the implied concepts data model components have been properly


2.2.5. Assess whether all the implied concepts data model components have been properlyallocated work accomplishment and recording functions necessary to support earnedvalue reporting.

2.2.6. Assess whether all the implied concepts data model components have been properlyallocated metadata recording effort to ensure that all interrelationships are properlyrecorded into the metadata management system database.

2.3. Assess the adequacy of each logical data model with respect to the WBS.2.3.1. Assess whether all the implied logical data model components have been delivered in

terms of components, instances, and stored metadata work products.2.3.2. Assess whether all the implied logical data model components have been properly

detailed as to methodology, evaluation, presentation, and delivery work steps.2.3.3. Assess whether all the implied logical data model components have been properly

allocated sufficient unit effort estimates.2.3.4. Assess whether all the implied logical data model components have been properly

allocated sufficient quantity of units that have to be developed.2.3.5. Assess whether all the implied logical data model components have been properly


2.3.6. Assess whether all the implied logical data model components have been properlyallocated work accomplishment and recording functions necessary to support earnedvalue reporting.

2.3.7. Assess whether all the implied logical data model components have been properlyallocated metadata recording effort to ensure that all interrelationships are properlyrecorded into the metadata management system database.

2.4. Assess the adequacy of each physical data model with respect to the WBS.


45


2.4.1. Assess whether all the implied physical data model components have been delivered interms of components, instances, and stored metadata work products.

2.4.2. Assess whether all the implied physical data model components have been properlydetailed as to methodology, evaluation, presentation, and delivery work steps.

2.4.2. Assess whether all the implied physical data model components have been properlyallocated sufficient unit effort estimates.

2.4.3. Assess whether all the implied physical data model components have been properlyallocated sufficient quantity of units that have to be developed.

2.4.4. Assess whether all the implied physical data model components have been properlyallocated work environment factors to determine an accurate estimate of requiredresources.

2.4.5. Assess whether all the implied physical data model components have been properlyallocated work accomplishment and recording functions necessary to support earnedvalue reporting.

2.4.6. Assess whether all the implied physical data model components have been properlyallocated metadata recording effort to ensure that all interrelationships are properlyrecorded into the metadata management system database.

2.5. Assess the adequacy of each XML data model with respect to the WBS2.5.1. Assess whether all the implied XML data model components have been delivered in

terms of components, instances, and stored metadata work products.2.5.2. Assess whether all the implied XML data model components have been properly detailed

as to methodology, evaluation, presentation, and delivery work steps.2.5.3. Assess whether all the implied XML data model components have been properly

allocated sufficient unit effort estimates.2.5.4. Assess whether all the implied XML data model components have been properly

allocated sufficient quantity of units that have to be developed.2.5.5. Assess whether all the implied XML data model components have been properly


2.5.6. Assess whether all the implied XML data model components have been properlyallocated work accomplishment and recording functions necessary to support earnedvalue reporting.

2.5.7. Assess whether all the implied XML data model components have been properlyallocated metadata recording effort to ensure that all interrelationships are properlyrecorded into the metadata management system database.



46


6.3 Business Information System Work Product to Business Information System WorkProduct Assessments

Figure Table 4 provides the cross reference of wok products to work products. As an instance ofa work product is delivered, the following are key items that should be assessed with respect toall the other work products that can be affected.

6.3.1 Business Information Systems Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of Business Information Systems documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the Business Information Systems that are defined and captured.1.1.4. Identify the Business Information Systems related work products.1.2. For each Business Information Systems related work product assessment:1.2.1. Identify the relevant components, that is, Business Requirements, Business Rules,

Database Objects, External data interface Requirements, External Quality Standards,Mission Organization Function, Resource Life Cycles, Use Cases, User AcceptanceTests, Value Domains Management, and WBS.

1.2.2. Identify the description for each interrelated business information systems component.2. Perform the assessment2.1. Assess whether the business information system individual components properly identify

the specific business requirements that are accomplished.2.1.1. Assess how the allocated business information system requirements are to be met, how it

is to be tested and through what means the testing is reported.2.1.2. Assess how allocated business information system requirements that are in conflict one

with another are to be resolved. 2.2. Assess whether the business information system individual components properly identify

and accomplish the business rules.2.2.1. Assess how the allocated business rules are to be met, how it is to be tested and through

what means the testing is reported.2.2.2. Assess how allocated business rules that are in conflict one with another are to be

resolved. 2.3. Assess whether the business information system individual components properly identify

and are appropriately engineered to address the database objects for this effort.2.3.1. Assess the allocated database object table processes to ensure that they result in processes

that either maintain or restore a state of integrity of a given database object table.2.3.2. Assess that the allocated database object table process column are properly acted upon by

the business information system with respect to selection, valuation, modification, or


47


value deletion to either maintain or restore a state of integrity of a given database objecttable.

2.3.3. Assess that the allocated database object table states are accomplished in an appropriatesequence according to the database object states identified in the complete specificationof database object classes.

2.4. Assess whether the business information system individual components properly identifyand are appropriately engineered to address the external data interface requirements forthis effort.

2.4.1. Assess the data specification of the external data interface requirement to ensure that allthe logical data model table columns is properly defined in terms of name, descriptionand purpose.

2.4.2. Assess the data specification of the external data interface requirement to ensure that allthe logical data model table columns is properly defined in terms of data type, scale,precision, granularity and temporalness.

2.4.3. Assess the data specification of the external data interface requirement to ensure that allthe value domain values for every restricted value domain database table column areproperly addressed.

2.5. Assess whether the business information system individual components properly identifyand are appropriately engineered to address the external quality standards for this effort.

2.5.1. Assess whether every data element implied for use as a database table column properlycomports to Part 3 of the ISO 11179 for data element metadata.

2.5.2. Assess whether every data element implied for use as a database table column properlycomports to Part 5 of the ISO 11179 for data element metadata.

2.5.3. Assess that every database column employed in the external data interface requirementconforms to an allowed data type from ISO ANSI SQL 1992 Entry Level.

2.5.4. Assess that every DBMS table column employed in the external data interfacerequirement conforms to an allowed data type from ISO ANSI SQL 1992 Entry Level.

2.5.5. Assess that every view column employed in the external data interface requirementconforms to an allowed data type from ISO ANSI SQL 1992 Entry Level.

2.6. Assess whether the business information system individual components properly identifyand are appropriately engineered to address the mission organization function for thiseffort.

2.6.1. Assess whether each mission is addressed by one or more logical data model tables toensure complete coverage.

2.6.2. Assess whether each organization is addressed by one or more business informationsystem components with respect to adding, modifying, or deletion.

2.6.3. Assess whether each function is addressed by one or more business information systemcomponents with respect to having the appropriate processes to accomplish adding,modifying, or deletion..

2.6.4. Assess whether each mission-organization is addressed by one or more businessinformation system components to appropriateness of coverage within the organizationand to ensure economy of work.


48


2.6.5. Assess whether each mission-organization-function is addressed by one or businessinformation system components to appropriateness of coverage within functionsperformed by various mission-organizations to ensure economy of work.

2.7. Assess whether the business information system individual components properly identifyand are appropriately engineered to address the resource life cycle analysis for this effort.

2.7.1 Assess whether the business information system individual components fulfill theimplied requirements of the accomplishment of the end state of a resource life cyclenode.

2.8. Assess whether the business information system individual components properlyidentified and are appropriately engineered and accomplish the appropriate sections ofthe use cases from which they are derived.

2.8.1. Assess whether the business transactions accomplished by the business informationsystems are properly identified through their use cases.

2.8.2. Assess whether the business transactions accomplished by the business informationsystems properly identify column in terms of read, write, select, and update arecompletely specified.

2.8.3. Assess whether there sufficient metadata captured for each business transaction.2.8.4. Assess whether the logical database tables identified for the proper capture of a business

transaction.2.8.5. Assess whether the relevant tables associated with a business transaction history are

properly identified.2.8.6. Assess whether there sufficient metadata captured for each business transaction history.2.8.7. Assess whether the logical database tables identified for the proper retrieval of a business

transaction history.2.8.8. Assess whether the history destination tables are properly identified for the capture of

business transaction history.2.9. Assess whether the business information system individual components properly identify

and are appropriately engineered to address the user acceptance tests for this effort.2.9.1. Assess whether every business information system component user acceptance test is

properly engineered to reflect success or failure and that appropriate messages aregenerated and actions taken.

2.10. Assess whether the business information system individual components properly identifyand are appropriately engineered to address the value domains for this effort.

2.10.1. Assess whether there is sufficient business information system individual components toensure that only an appropriate set of restricted value domain data element values arepresented.

2.10.2. Assess whether sufficient business information system individual components in supportof a restricted value domain choice.

2.11. Assess whether the business information system individual components properly identifyand are appropriately engineered to address the WBS for this effort.

2.11.1. Assess whether all the business information system individual components have beendelivered in terms of components, instances, and stored metadata work products.


49


2.11.2. Assess whether all the business information system individual components have beenproperly detailed as to methodology, evaluation, presentation, and delivery work steps.

2.11.3. Assess whether all the business information system individual components have beenproperly allocated sufficient unit effort estimates.

2.11.4. Assess whether all the business information system individual components have beenproperly allocated sufficient quantity of units that have to be developed.

2.11.5. Assess whether all the business information system individual components have beenproperly allocated work environment factors to determine an accurate estimate ofrequired resources.

2.11.6. Assess whether all the business information system individual components have beenproperly allocated work accomplishment and recording functions necessary to supportearned value reporting.

2.11.7. Assess whether all the business information system individual components have beenproperly allocated metadata recording effort to ensure that all interrelationships areproperly recorded into the metadata management system database.



1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of business requirements documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the business requirements that are defined and captured.1.1.4. Identify the business requirements related work products.1.2. For each business requirement related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Business Rules,

Database Domains, Database Objects, External data interface Requirements, ExternalQuality Standards, Information Needs, Mission Organization Function, Resource LifeCycles, Use Cases, User Acceptance Tests, Value Domains Management, and WBS.

1.2.2. Identify the description for each interrelated business requirement component.2. Perform the assessment2.1. Assess whether each business requirement is addressed by one or more business

information systems and contained components as may be appropriate.2.1.1. Assess whether each allocated business requirement is satisfied by the portion of the

business information system to which it is allocated.2.1.2. Assess whether the collection of allocated business requirements do not result in an

conflicts that need to be resolved.


50


2.2. Assess whether each business requirement is addressed by one or more business rules asmay be appropriate.

2.2.1 Assess whether each allocated business requirement is satisfied by the business rule in amanner that clearly results in a pass/fail.

2.2.2. Assess whether the collection of allocated business requirements do not result in anconflicts that need to be resolved.

2.3. Assess whether each business requirement is addressed by one or more database domainsas may be appropriate.

2.3.1 Assess whether each allocated business requirement is satisfied by the database domainin a manner that clearly results in a pass/fail.


2.4 Assess whether each business requirement is addressed by one or more database object isaddressed by one or more business information systems as may be appropriate.

2.4.1 Assess whether each allocated business requirement is satisfied by the database object ina manner that clearly results in a pass/fail.


2.5 Assess whether each business requirement is addressed by one or more external datainterface requirement as may be appropriate.

2.5.1 Assess whether each allocated business requirement is satisfied by the external datainterface requirement in a manner that clearly results in a pass/fail.


2.6. Assess whether each business requirement is addressed by one or more external qualitystandard as may be appropriate.

2.6.1 Assess whether each allocated business requirement is satisfied by the external qualitystandard in a manner that clearly results in a pass/fail.


2.7. Assess whether each business requirement is addressed by one or more information needas may be appropriate.

2.7.1 Assess whether each allocated business requirement is satisfied by the information needsin a manner that clearly results in a pass/fail.


2.8. Assess whether each business requirement is addressed by one or more missionorganization functions as may be appropriate.

2.8.1 Assess whether each allocated business requirement is satisfied by the missionorganization function in a manner that clearly results in a pass/fail.



51


2.9. Assess whether each business requirement is addressed by one or more resource lifecycles as may be appropriate.

2.9.1 Assess whether each allocated business requirement is satisfied by the resource life cyclein a manner that clearly results in a pass/fail.


2.10. Assess whether each business requirement is addressed by one or more use case isaddressed by one or more value domains and management as may be appropriate.



2.11. Assess whether each business requirement is addressed by one or more user acceptancetests as may be appropriate.



2.12. Assess whether each business requirement is addressed by one or more value domainmanagement as may be appropriate.

2.12.1 Assess whether each allocated business requirement is satisfied by the value domains in amanner that clearly results in a pass/fail.


2.13. Assess whether each business requirement is addressed by one or more WBS as may beappropriate.

2.13.1. Assess whether all the business requirements have been delivered in terms ofcomponents, instances, and stored metadata work products.

2.13.2. Assess whether all the business requirements have been properly detailed as tomethodology, evaluation, presentation, and delivery work steps.

2.13.3. Assess whether all the business requirements have been properly allocated sufficient uniteffort estimates.

2.13.4. Assess whether all the business requirements have been properly allocated sufficientquantity of units that have to be developed.

2.13.5. Assess whether all the business requirements have been properly allocated workenvironment factors to determine an accurate estimate of required resources.

2.13.6. Assess whether all the business requirements have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.

2.13.7. Assess whether all the business requirements have been properly allocated metadatarecording effort to ensure that all interrelationships are properly recorded into themetadata management system database.



52



6.3.3 Business Rules Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of business rule documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the business rules that are defined and captured.1.1.4. Identify the business rules related work products.1.2. For each business rule related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Business

Requirements, External data interface Requirements, Use Cases, User Acceptance Tests,Value Domains Management, and WBS.

1.2.2. Identify the description for each interrelated business rule component.2. Perform the assessment2.1. Assess, as applicable, whether each business rule is addressed by one or more business

information systems as may be appropriate.2.1.1. Assess whether there is sufficient logic within the business information system to

adequately execute the business rule in a pass/fail manner.2.1.2. Assess whether the allocated business information system business rules do no

adequately result in conflicts that need to be resolved.2.2. Assess, as applicable, whether each business rule is addressed by one or more business

requirements as may be appropriate.2.2.1 Assess whether each business rule maps to at least one business requirement.2.2.2 Determine whether business rules that are not matched by requirements are to be deleted,

or whether the requirements document requires revision.2.3 Assess, as applicable, whether each business rule is addressed by one or more database

object is addressed by one or more business information systems as may be appropriate.2.3.1. Assess whether each business rule is properly addressed by one or more database object

database table data structures.2.3.2. Assess whether each business rule is properly addressed by one or more database object

database table processes.2.3.3. Assess whether each business rule is properly addressed by one or more database object

states.2.3.4. Assess whether each business rule is properly addressed by one or more database object

business information systems.2.3.5. Assess whether the allocated database object business rules do not result in conflicts that

need to be resolved.


53


2.4. Assess, as applicable, whether each business rule is addressed by one or more externaldata interface requirements as may be appropriate.

2.4.1 Assess whether the business rule can be adequately supported by the specifications of theexternal data interface data columns.

2.4.2 Assess whether the business rule can be adequately supported by the specifications of theexternal data interface data column data types.

2.4.3 Assess whether the business rule can be adequately supported by the specifications of theexternal data interface data column value domains.

2.4.4 Assess whether the business rule can be adequately supported by the specifications of theexternal data interface data column precision, scale, and granularity.

2.5. Assess whether each business rule is addressed by one or more use case is addressed byone or more value domains and management as may be appropriate.

2.5.1. Assess whether the business rules is sufficiently detailed to reflect the actions,conditions, and logic of use cases as specified.

2.6. Assess whether each business rule is addressed by one or more user acceptance tests asmay be appropriate.

2.6.1. Assess whether the user acceptance test allocated business rules are of sufficient detail toenable a pass/fail result.

2.6.2. Assess whether each business rule is addressed by one or more user acceptance test isaddressed by one or more value domains and management as may be appropriate.

2.6.3. Assess whether the allocated user acceptance test business rules do not result in conflictsthat need to be resolved.

2.7. Assess whether each business rule is addressed by one or more value domainmanagement as may be appropriate.

2.7.1. Assess whether the business rules is sufficiently detailed to address the value domains asspecified.

2.7.2. Assess whether the allocated value domain business rules do not result in conflicts thatneed to be resolved.

2.8. Assess whether each business rule is addressed by one or more WBS as may beappropriate.

2.8.1. Assess whether all the business rules have been delivered in terms of components,instances, and stored metadata work products.

2.8.2. Assess whether all the business rules have been properly detailed as to methodology,evaluation, presentation, and delivery work steps.

2.8.3. Assess whether all the business rules have been properly allocated sufficient unit effortestimates.

2.8.4. Assess whether all the business rules have been properly allocated sufficient quantity ofunits that have to be developed.

2.8.5. Assess whether all the business rules have been properly allocated work environmentfactors to determine an accurate estimate of required resources.


54


2.8.6. Assess whether all the business rules have been properly allocated work accomplishmentand recording functions necessary to support earned value reporting.

2.8.7. Assess whether all the business rules have been properly allocated metadata recordingeffort to ensure that all interrelationships are properly recorded into the metadatamanagement system database.


6.3.4 Database Domains Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of database domain documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the database domains that are defined and captured.1.1.4. Identify the database domains related work products.1.2. For each database domain related work product assessment:1.2.1. Identify the relevant components, that is, Database Objects, Mission Organization

Function, and WBS.1.2.2. Identify the description for each interrelated database domain component.2. Perform the assessment2.1 Assess whether each database domain is addressed by one or more database objects as

may be appropriate.2.3. Assess whether each database domain is addressed by one or more mission organization

functions as may be appropriate.2.3. Assess whether each database domain is addressed by one or more WBS as may be

appropriate.2.3.1. Assess whether all the database domain have been delivered in terms of components,

instances, and stored metadata work products.2.3.2. Assess whether all the database domain have been properly detailed as to methodology,

evaluation, presentation, and delivery work steps.2.3.3. Assess whether all the database domain have been properly allocated sufficient unit effort

estimates.2.3.4. Assess whether all the database domain have been properly allocated sufficient quantity

of units that have to be developed.2.3.5. Assess whether all the database domain have been properly allocated work environment

factors to determine an accurate estimate of required resources.2.3.6. Assess whether all the database domain have been properly allocated work

accomplishment and recording functions necessary to support earned value reporting.


55


2.3.7. Assess whether all the database domain have been properly allocated metadata recordingeffort to ensure that all interrelationships are properly recorded into the metadatamanagement system database.


6.3.5 Database Objects Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of database object documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the database object that are defined and captured.1.1.4. Identify the database object related work products.1.2. For each database object related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Business

Requirements, Business Rules, External data interface Requirements, MissionOrganization Function, Resource Life Cycles, and WBS.

1.2.2. Identify the description for each interrelated database objects component.2. Perform the assessment2.1. Assess whether each database object is addressed by one or more business information

systems as may be appropriate.2.1.1. Assess whether database object table structures are properly reflected in the use of views

that are employed by the business information systems.2.1.2. Assess whether database object table processes are properly reflected in programmed

processes of business information systems.2.1.3. Assess whether database object states are properly engineered to be achieved in business

information systems that are retained if the business information system is successful orare returned to a previous state if the business information system fails.

2.1.4. Assess whether database object information systems are properly accomplished withinthe business information systems to which they are allocated.

2.2. Assess whether each database object is addressed by one or more business requirementsas may be appropriate.

2.2.1. Assess whether a database object business requirement is sufficiently detailed to beallocated to an appropriate database object contained component.

2.2.2. For inadequately specified business requirements, enhance/detail their specification sothat they can be allocated to an appropriate database object contained component.

2.3. Assess whether each database object is addressed by one or more business rules as maybe appropriate.


56


2.3.1. Assess whether database object table data structure business rules are properlyconfigured to be achieved through SQL DDL data integrity clauses.

2.3.2. Assess whether database object table process business rules are properly configured to beachieved through SQL stored procedures or business information system containedprocedures.

2.3.3. Assess whether database object states business rules are properly configured to beproperly sequenced and able to be achieved through database object information systems.

2.3.4. Assess whether database object information systems business rules are properlyconfigured to be achieved through business information system contained processes.

2.4. Assess whether each database object is addressed by one or more external data interfacerequirements as may be appropriate.

2.4.1. Assess whether the database object table structure is completely addressed by an externaldata interface.

2.4.2. On partially addressed database object table structures, assess whether there is asufficient data structure within the database to complete the importing of a completedatabase object in one or more states.

2.4.2. Assess whether there are sufficient database object processes to adequately process dataprovided through a external data interface.

2.4.3. Assess whether there is supporting database object states that already exist to import orexport a database object in the required external data interface database object state.

2.4.4. Assess whether there is sufficient database object information system specification andimplementation to import or export a database object in the desired state.

2.5. Assess whether each database object is addressed by one or more mission organizationfunctions as may be appropriate.

2.5.1. Assess whether each database object is able to be identified through a database domaindescription with one or more mission organization functions.

2.5.2. For database objects that are not discoverable from database domains within missionorganization functions enhance the database domain statements and if necessary themission organization function statements.

2.6. Assess whether each database object is addressed by one or more resource life cycles asmay be appropriate.

2.6.1. Assess whether every database object can be properly identified from one or moreresource life cycle node statements.

2.6.2. For database objects that are not discoverable from resource life cycle node statements,enhance these statements and if necessary the resource life cycles and possibly even theresource hierarchies.

2.7. Assess whether each database object is addressed by one or more WBS as may beappropriate.

2.7.1. Assess whether all the database objects have been delivered in terms of components,instances, and stored metadata work products.

2.7.2. Assess whether all the database objects have been properly detailed as to methodology,evaluation, presentation, and delivery work steps.


57


2.7.3. Assess whether all the database objects have been properly allocated sufficient unit effortestimates.

2.7.4. Assess whether all the database objects have been properly allocated sufficient quantityof units that have to be developed.

2.7.5. Assess whether all the database objects have been properly allocated work environmentfactors to determine an accurate estimate of required resources.

2.7.6. Assess whether all the database objects have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.

2.7.7. Assess whether all the database objects have been properly allocated metadata recordingeffort to ensure that all interrelationships are properly recorded into the metadatamanagement system database.

2.8. Assign the risk level associated with each meta-artifact not properly constructed. 3.Determine the findings and create draft assessment report

4. Present the findings and revise draft assessment report5. Create final report and deliver to The Agency

6.3.6 External Data Interface Requirements Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of external data interface requirements documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the external data interface requirements that are defined and captured.1.1.4. Identify the external data interface requirements related work products.1.2. For each external data interface requirements related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Business

Requirements, Business Rules, Database Objects, External Quality Standards, MissionOrganization Function, Resource Life Cycles, Use Cases, User Acceptance Tests, ValueDomains Management, and WBS.

1.2.2. Identify the description for each interrelated external data interface requirementscomponent.

2. Perform the assessment2.1. Assess whether each external data interface requirements is addressed by one or more

business information systems as may be appropriate.2.1.1. Assess whether the external data interface requirements business information system

component is sufficiently detailed to assure coverage of the requirement.2.1.2. Assess whether the performance requirements from the external data interface is

acceptable for the resources currently allowed for the operation of the businessinformation systems.


58


2.1.3. If external data interfaces are not able to be inferred from business information systems,determine whether external data interfaces and/or business information systems need tobe enhanced.

2.2. Assess whether each external data interface requirements is addressed by one or morebusiness requirements as may be appropriate.

2.2.1 Assess whether the external data interface requirements business requirement isspecified to such an extent that it can be executed and will result in a pass/fail result inaddition to any data value calculation or transformation.

2.2.2. If external data interfaces are not able to be inferred from business requirements,determine whether external data interfaces and/or business requirements need to beenhanced.

2.3. Assess whether each external data interface requirements is addressed by one or morebusiness rules as may be appropriate.

2.3.1 Assess whether the external data interface requirements business rule is specified to suchan extent that it can be executed and will result in a pass/fail result in addition to any datavalue calculation or transformation.

2.3.2. If external data interfaces are not able to be inferred from business rules, determinewhether external data interfaces and/or business rules need to be enhanced.

2.4 Assess whether each external data interface requirements is addressed by one or moredatabase objects as may be appropriate.

2.4.1. Assess whether each external data interface database object table data structure is clearlyidentified and satisfies the needs of the external data interface requirement.

2.4.2. Assess whether an under specified external data interface database object data structureneeds to be enhanced to meet the needs of the external data interface requirement.

2.4.3. Assess whether each external data interface database object table process is sufficientlyspecified to carry out the required data acquisition, transformation and storage of the datarepresented by the external data interface.

2.4.4. Assess whether each external data interface requirement database object table state issufficiently set out and exists within a sequence such that it can be achieved when thedatabase object is properly created, or if the creation fails that the database object returnsto a prior state.

2.4.5. Assess whether each external data interface requirement database object businessinformation system is sufficiently specified that when executed the specified ending stateis achieved through the proper execution of the database object table processes.

2.4.6. If external data interfaces are not able to be inferred from database objects, determinewhether external data interfaces and/or database objects need to be enhanced.

2.5 Assess whether each external data interface requirements is addressed by one or moreexternal quality standards as may be appropriate.

2.5.1. Assess whether the data interface requirement is expressed within an external qualitystandard such as ANSI SQL and/or WC3 so that it can be ported from one technology tothe next without major recreation.


59


2.5.2. If external data interfaces are not able to be inferred from external quality standards,determine whether external data interfaces and/or external quality standards inventoryneeds to be enhanced.

2.6 Assess whether each external data interface requirements is addressed by one or moremission organization functions as may be appropriate.

2.6.1. Assess whether the external data interface requirement is discoverable from withinmission organization functions.

2.6.2. If external data interfaces are not able to be inferred from mission organization functions,determine whether external data interfaces and/or mission organization functions need tobe enhanced.

2.7 Assess whether each external data interface requirements is addressed by one or moreresource life cycles as may be appropriate.

2.7.1. Assess whether each external data interface requirement resource life cycle is clearlyidentified and that through its execution fulfills a needed action that contributes to theachievement of the resource life cycle node.

2.7.2. If external data interfaces are not able to be inferred from resource life cycles, determinewhether external data interfaces and/or resource life cycles need to be enhanced.

2.8 Assess whether each external data interface requirements is addressed by one or more usecase is addressed by one or more value domains and management as may be appropriate.

2.8.1. Assess external data interface requirement value domain to ensure that it is sufficientlyspecified to meet the needs of both the external data interface requirement and the needsof the database in terms of data transformation between an externally defined value andan internally defined value.

2.8.2 If external data interfaces are not able to be inferred from use cases, determine whetherexternal data interfaces and/or use cases need to be enhanced.

2.9 Assess whether each external data interface requirements is addressed by one or moreuser acceptance tests as may be appropriate.

2.9.1. Assess each external data interface requirement user acceptance test to ensure that it isvalid, reliable, repeatable, and discriminating.

2.9.2. Assess each external data interface requirement user acceptance test to ensure that itsresults are pass or fail.

2.9.3. If external data interfaces are not able to be inferred from user acceptance tests,determine whether external data interfaces and/or user acceptance tests need to beenhanced.

2.10 Assess whether each external data interface requirements is addressed by one or morevalue domains as may be appropriate.


60


2.10.1. Assess each external data interface requirement user acceptance test to ensure that it iscompletely represented through an appropriate set of value domains.

2.10.2. If external data interfaces are not able to be inferred from value domains, determinewhether external data interfaces and/or value domains need to be enhanced.

2.11. Assess whether each external data interface requirements is addressed by one or moreWBS as may be appropriate.

2.11.1. Assess whether all the external data interface requirements have been delivered in termsof components, instances, and stored metadata work products.

2.11.2. Assess whether all the external data interface requirements have been properly detailed asto methodology, evaluation, presentation, and delivery work steps.

2.11.3. Assess whether all the external data interface requirements have been properly allocatedsufficient unit effort estimates.

2.11.4. Assess whether all the external data interface requirements have been properly allocatedsufficient quantity of units that have to be developed.

2.11.5. Assess whether all the external data interface requirements have been properly allocatedwork environment factors to determine an accurate estimate of required resources.

2.11.6. Assess whether all the external data interface requirements have been properly allocatedwork accomplishment and recording functions necessary to support earned valuereporting.

2.11.7. Assess whether all the external data interface requirements have been properly allocatedmetadata recording effort to ensure that all interrelationships are properly recorded intothe metadata management system database.


6.3.7 External Quality Standards Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of external quality standards documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the external quality standards that are defined and captured.1.1.4. Identify the external quality standards related work products.1.2.2. For each external quality standards related work product assessment:2.1. Assess whether each external quality standard is addressed by one or more business

information systems as may be appropriate.



61


1.1. Identify the appropriate set of external quality standards documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the external quality standards that are defined and captured.1.1.4. Identify the external quality standards related work products.1.2. For each external quality standards requirements related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Database

Objects, External Data Interfaces Requirements, User Acceptance Tests, Value DomainsManagement, and WBS.

1.2.2. Identify the description for each interrelated external data interface requirementscomponent.

2. Perform the assessment2.1 Assess whether each external quality standard is addressed by one or more business

information systems as may be appropriate. 2.1.1 Assess whether there exists an external quality standard that governs the engineering,

development, and maintenance of a business information system.2.1.2. Assess whether the external quality standard can be applied to the business information

system in an efficient and effective manner.2.2 Assess whether each external quality standard is addressed by one or more database

object is addressed by one or more business information systems as may be appropriate.2.2.1 Assess whether there exists an external quality standard that governs the engineering,

development, and maintenance of a collection of database object classes.2.2.2. Assess whether the external quality standard can be applied to the database object class

in an efficient and effective manner.2.3 Assess whether each external quality standard is addressed by one or more external data

interface requirement as may be appropriate.2.3.1 Assess whether there exists an external quality standard that governs the engineering,

development, and maintenance of a external data interface requirement .2.3.2. Assess whether the external quality standard can be applied to the external data interface

requirement in an efficient and effective manner.2.4. Assess whether each external quality standard is addressed by one or more user

acceptance tests as may be appropriate.2.4.1 Assess whether there exists an external quality standard that governs the engineering,

development, and maintenance of a collection of user acceptance tests .2.4.2. Assess whether the external quality standard can be applied to the user acceptance tests

in an efficient and effective manner.2.5. Assess whether each external quality standard is addressed by one or more value domain

management as may be appropriate.2.5.1 Assess whether there exists an external quality standard that governs the engineering,

development, and maintenance of value domains.


62


2.5.2. Assess whether the external quality standard can be applied to the value domains anefficient and effective manner.

2.6. Assess whether each external quality standard is addressed by one or more WBS as maybe appropriate.

2.6.1. Assess whether all the external quality standards have been delivered in terms ofcomponents, instances, and stored metadata work products.

2.6.2. Assess whether all the external quality standard have been properly detailed as tomethodology, evaluation, presentation, and delivery work steps.

2.6.3. Assess whether all the external quality standard have been properly allocated sufficientunit effort estimates.

2.6.4. Assess whether all the external quality standard have been properly allocated sufficientquantity of units that have to be developed.

2.6.5. Assess whether all the external quality standard have been properly allocated workenvironment factors to determine an accurate estimate of required resources.

2.6.6. Assess whether all the external quality standard have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.

2.6.7. Assess whether all the external quality standard have been properly allocated metadatarecording effort to ensure that all interrelationships are properly recorded into themetadata management system database.


6.3.8 Information Needs Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of information needs documents1.1.1. Review information needs documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the information needs that are defined and captured.1.1.4. Identify the information needs related work products.1.2. For each information needs related work product assessment:1.2.1. Identify the relevant components, that is, Mission Organization Function, Resource Life

Cycles, Use Cases, User Acceptance Tests, and WBS.1.2.2. Identify the description for each interrelated information needs component.2. Perform the assessment2.1. Assess whether each information need is addressed by one or more mission organization

functions as may be appropriate.


63


2.1.1 Assess whether each information need can be properly inferred by a mission organizationfunction such that it can be sufficiently understood and detailed and thus accounted forwithin database domains, data elements, database objects, and external data interfaces.

2.1.2. If information needs are not able to be inferred from mission organization functions,determine whether mission organization functions and/or information needs need to beenhanced.

2.2. Assess whether each information need is addressed by one or more resource life cycles asmay be appropriate.

2.2.1. Assess whether each information need can be properly identified as having beenaddressed within one or more resource life cycle nodes.

2.2.2. If information needs are not able to be inferred from resource life cycle nodes, determinewhether resource life cycle nodes and/or information needs need to be enhanced.

2.3. Assess whether each information need is addressed by one or more use case is addressedby one or more value domains and management as may be appropriate.

2.3.1. Assess whether information needs are sufficiently detailed and represented within usecases to assure that the information need is properly addressed.

2.3.2. If information needs are properly addressed by one or more use cases, determine whetheruse cases and/or information needs need to be enhanced.

2.4. Assess whether each information need is addressed by one or more user acceptance testsas may be appropriate.

2.4.1. Assess whether information needs are sufficiently detailed and represented within useracceptance tests to assure that the information need is properly captured, modified, and/ordeleted.

2.4.2. If information needs are properly addressed by one or more user acceptance tests,determine whether user acceptance tests and/or information needs need to be enhanced.

2.5. Assess whether each information need is addressed by one or more WBS as may beappropriate.

2.5.1. Assess whether all the information needs have been delivered in terms of components,instances, and stored metadata work products.

2.5.2. Assess whether all the information needs have been properly detailed as to methodology,evaluation, presentation, and delivery work steps.

2.5.3. Assess whether all the information needs have been properly allocated sufficient uniteffort estimates.

2.5.4. Assess whether all the information needs have been properly allocated sufficient quantityof units that have to be developed.

2.5.5. Assess whether all the information needs have been properly allocated work environmentfactors to determine an accurate estimate of required resources.

2.5.6. Assess whether all the information needs have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.


64


2.5.7. Assess whether all the information needs have been properly allocated metadatarecording effort to ensure that all interrelationships are properly recorded into themetadata management system database.


6.3.9 Mission Organization Function Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of mission organization function documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the mission organization function that are defined and captured.1.1.4. Identify the mission organization function related work products.1.2. For each mission organization function related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Business

Requirements, Database Domains, External Data Interface Requirements, InformationNeeds, Use Cases, User Acceptance Tests, Value Domains Management, and WBS..

1.2.2. Identify the description for each interrelated mission organization function component.2. Perform the assessment2.1. Assess whether each mission organization function is addressed by one or more business

information systems as may be appropriate.2.1.1. Assess whether each mission organization function that is to be addressed by automation

is properly identified through a business event that is tied to a business informationsystem.

2.1.2. Assess whether each mission organization function business information system isproperly set within the context of a business event network.

2.1.3. Assess whether each mission organization function business information system isproperly set within the context of a business calendar network.

2.2. Assess whether each mission organization function is addressed by one or more businessrequirements as may be appropriate.

2.2.1. Assess whether each mission can be allocated to one or more business requirements.2.2.2. Assess whether each organization can be allocated to one or more business requirements.2.2.3. Assess whether each mission organization can be allocated to one or more business

requirements.2.2.4. Assess whether each function can be allocated to one or more business requirements.2.2.5. Assess whether each mission organization function can be allocated to one or more

business requirements.


65


2.2.6. If business requirements are not able to be inferred from missions, or organizations orfunctions, determine whether business requirements and/or missions, organizations, orfunctions need to be enhanced.

2.2.7. If business requirements are not able to be inferred from mission organizations,determine whether business requirements and/or mission organization functions need tobe enhanced.

2.2.8. If business requirements are not able to be inferred from mission organization functions,determine whether business requirements and/or mission organization functions need tobe enhanced.

2.3. Assess whether each mission organization function is addressed by one or more databasedomains as may be appropriate.

2.3.1. Assess whether each mission is properly set out in terms of database domains.2.3.2. If database domains are not able to be inferred from missions, determine whether

database domains and/or mission need to be enhanced. 2.4 Assess whether each mission organization function is addressed by one or more external

data interface requirement as may be appropriate.2.4.1. Assess whether mission organization function that infers an external data interface

requirement is sufficient detailed to understand database object and business informationsystem requirements.

2.4.2. If external data interface requirements are not able to be inferred from missionorganizations, determine whether data interface requirements and/or mission organizationfunctions need to be enhanced.

2.5. Assess whether each mission organization function is addressed by one or moreinformation needs as may be appropriate.

2.5.1. Assess whether the information needs inferred by the mission organization function aresufficiently detailed so that they can be properly identified from within resource lifecycle nodes.

2.5.2. If information needs are not able to be inferred from mission organizations, determinewhether information needs and/or mission organization functions need to be enhanced.

2.6. Assess whether each mission organization function is addressed by one or more use caseis addressed by one or more value domains and management as may be appropriate.

2.6.1. Assess whether the use cases inferred by the mission organization function aresufficiently detailed so that they can thereafter be properly represented in subsequentwork products.

2.6.2. If use cases are not able to be inferred from mission organizations, determine whether usecases and/or mission organization functions need to be enhanced.

2.7. Assess whether each mission organization function is addressed by one or more useracceptance tests as may be appropriate.

2.7.1. Assess whether the user acceptance tests inferred by the mission organization functionsare sufficiently detailed so that their execution can serve to attest to the successfulaccomplishment of the mission organization function.


66


2.7.2. If user acceptance tests are not sufficiently detailed to support mission organizationfunction successful accomplishment, determine whether user acceptance tests and/ormission organization functions need to be enhanced.

2.8. Assess whether each mission organization function is addressed by one or more WBS asmay be appropriate.

2.8.1. Assess whether all the mission organization functions have been delivered in terms ofcomponents, instances, and stored metadata work products.

2.8.2. Assess whether all the mission organization functions have been properly detailed as tomethodology, evaluation, presentation, and delivery work steps.

2.8.3. Assess whether all the mission organization functions have been properly allocatedsufficient unit effort estimates.

2.8.4. Assess whether all the mission organization functions have been properly allocatedsufficient quantity of units that have to be developed.

2.8.5. Assess whether all the mission organization functions have been properly allocated workenvironment factors to determine an accurate estimate of required resources.

2.8.6. Assess whether all the mission organization functions have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.

2.8.7. Assess whether all the mission organization functions have been properly allocatedmetadata recording effort to ensure that all interrelationships are properly recorded intothe metadata management system database.


6.3.10 Resource Life Cycle Assessment

Business Information Systems, Business Requirements, Database Objects, External datainterface Requirements, Information Needs, Use Cases, User Acceptance Tests, and WBS.

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of resource life cycle documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the resource life cycle that are defined and captured.1.1.4. Identify the resource life cycle related work products.1.2. For each resource life cycle related work product assessment:2.1. Assess whether each resource life cycle is addressed by one or more business information

systems as may be appropriate.


67


2.1.1. Assess whether each resource life cycle business information systems are sufficientlydetailed to assure that the intent of the resource life cycles on a node by node basis areaccomplished.

2.2.2. If business information systems are determined not to be sufficient to support thesuccessful completion of the resource life cycle nodes, determine whether the businessinformation systems and/or resource life cycle nodes need to be enhanced.

2.2. Assess whether each resource life cycle is addressed by one or more businessrequirements as may be appropriate.

2.2.1 Assess whether there are sufficient business requirements to identify the complete set ofresource life cycle components including resources, resource life cycle nodes, allocatedbusiness information systems and database objects.

2.2.2. If business requirements are determined not to be sufficient to support the successfulcompletion of the resource life cycle nodes, determine whether the business requirementsand/or resource life cycle nodes need to be enhanced.

2.3 Assess whether each resource life cycle is addressed by one or more database object isaddressed by one or more business information systems as may be appropriate.

2.3.1. Assess whether each allocated resource life cycle node database object is sufficientlydetailed as to database object data structure, database object table process, databaseobject states, and database object information systems to support the successfulaccomplishment of the resource life cycle node end state.

2.3.2. If database objects are determined not to be sufficient to support the successfulcompletion of the resource life cycle nodes, determine whether the database objectsand/or resource life cycle nodes need to be enhanced.

2.4 Assess whether each resource life cycle is addressed by one or more external datainterface requirement as may be appropriate.

2.4.1. Assess whether resource life cycle external data interface requirements are sufficientlydetailed to ensure that the data that is captured from the external interface supports thesuccessful completion of the resource life cycle node.

2.4.2. If external data interfaces are determined not to be sufficient to support the successfulcompletion of the resource life cycle nodes, determine whether the external datainterfaces and/or resource life cycle nodes need to be enhanced.

2.5 Assess whether each resource life cycle is addressed by one or more information need asmay be appropriate.

2.5.1. Assess whether the data needs as defined by database object table structures allocated toresource life cycle nodes are sufficient to satisfy the data needs inferred from eachinformation need.

2.5.2. If database object table structures are determined not to be sufficient to support theinformation needs that are associated with the resource life cycle nodes, determinewhether the database object table structures and/or information needs should beenhanced.


68


2.6. Assess whether each resource life cycle is addressed by one or more use case is as maybe appropriate.

2.6.1. Assess whether accomplishment of each resource life cycle node associated with aresource life cycle is fully specified within an allocated collection of use cases.

2.6.2. If the allocated collection of use cases are determined not to be sufficient to support thecomplete set of resource life cycle nodes, determine whether the use cases and/orresource life cycle nodes should be enhanced.

2.7. Assess whether each resource life cycle is addressed by one or more user acceptance testsas may be appropriate.

2.7.1. Assess whether the collection of allocated user acceptance tests are sufficiently detailedto produce either a pass or fail for the accomplishment of each resource life cycle nodecontained in a resource life cycle.

2.7.2. If the allocated collection of user acceptance tests are determined not to be sufficient tosupport the complete set of resource life cycle nodes, determine whether the useracceptance tests and/or resource life cycle nodes should be enhanced.

2.8. Assess whether each resource life cycle is addressed by one or more WBS as may beappropriate.

2.8.1. Assess whether all the resource life cycles have been delivered in terms of components,instances, and stored metadata work products.

2.8.2. Assess whether all the resource life cycles have been properly detailed as tomethodology, evaluation, presentation, and delivery work steps.

2.8.3. Assess whether all the resource life cycles have been properly allocated sufficient uniteffort estimates.

2.8.4. Assess whether all the resource life cycles have been properly allocated sufficientquantity of units that have to be developed.

2.8.5. Assess whether all the resource life cycles have been properly allocated workenvironment factors to determine an accurate estimate of required resources.

2.8.6. Assess whether all the resource life cycles have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.

2.8.7. Assess whether all the resource life cycles have been properly allocated metadatarecording effort to ensure that all interrelationships are properly recorded into themetadata management system database.


6.3.11 Use Cases Assessment



69


1.1. Identify the appropriate set of use case documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the use cases that are defined and captured.1.1.4. Identify the use case related work products.1.2. For each use case related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Business

Requirements, Business Rules, Database Objects, External data interface Requirements,External Quality Standards, Mission Organization Function, Resource Life Cycles, UserAcceptance Tests, and WBS.

1.2.2. Identify the description for each interrelated use case component.2. Perform the assessment2.1. Assess whether each use case is addressed by one or more business information systems

as may be appropriate.2.1.1. Assess whether each business information system and each component within each

business information system that result from the collection of use cases that areprecursors to the specification and development of business information systems andcontained components are sufficiently detailed to infer the organization, construction, andprocess sequences represented by the business information system.

2.1.2. Identify each business information system component allocated use case that fails to havea sufficient quantity of detailed use cases and determine whether the business informationsystem component and/or use case should be enhanced.

2.2. Assess whether each use case is addressed by one or more business requirements as maybe appropriate.

2.2.1. Assess whether each business requirement involved use case is sufficiently detailed toassure that the business rule is tested such that it produces a result of pass or fail.

2.2.2. If each business rule involved business requirement is not sufficiently detailed, determinewhether the use case and/or the business rule should be enhanced.

2.3. Assess whether each use case is addressed by one or more business rules as may beappropriate.

2.3.1. Assess whether each business rule involved use case is sufficiently detailed to assure thatthe business rule is tested such that it produces a result of pass or fail.

2.3.2. If each business rule involved use case is not sufficiently detailed, determine whether theuse case and/or the business rule should be enhanced.

2.4 Assess whether each use case is addressed by one or more database objects is addressedby one or more business information systems as may be appropriate.

2.4.1. Assess whether each database object involved use cases is sufficiently detailed to assurethat the database object is able to be tested such that it produces a result of pass or fail.

2.4.2. Assess whether each use case involved database object table data structure is sufficientlydetailed to assure that the database object table data structure is able to be tested such thatit produces a result of pass or fail.


70


2.4.3. Assess whether each use case involved database object table process is sufficientlydetailed to assure that the database object table process is able to be tested such that itproduces a result of pass or fail.

2.4.4. Assess whether each use case involved database object state is sufficiently detailed toassure that the database object state is able to be tested such that it produces a result ofpass or fail.

2.4.5. If each use case involved database object data structure, process, state or informationsystem is not sufficiently detailed, determine whether the use case and/or the databaseobject data structure, process, state or information system should be enhanced.

2.5 Assess whether each use case is addressed by one or more external data interfacerequirement as may be appropriate.

2.5.1. Assess whether each external data interface involved use case is sufficiently detailed toassure that the use case is tested such that it produces a result of pass or fail.

2.5.2. If each external data interface involved use case is not sufficiently detailed, determinewhether the use case and/or the external data interface should be enhanced.

2.6. Assess whether each use case is addressed by one or more external quality standard asmay be appropriate.

2.6.1. Assess whether each external quality standard involved use case is sufficiently detailed toassure that the use case’s adherence to the standard is determined such that it produces aresult of pass or fail.

2.6.2. If each external quality standard involved use case is not sufficiently detailed, determinewhether the use case and/or the external quality standard should be enhanced.

2.7. Assess whether each use case is addressed by one or more mission organization functionsas may be appropriate.

2.7.1. Assess whether each mission organization function involved use case is sufficientlydetailed to assure that the use case is such that it affirms that the mission organizationfunction is accommodated by the use case.

2.7.2. If each mission organization function involved use case not sufficiently detailed,determine whether the use case and/or the mission organization function should beenhanced.

2.8. Assess whether each use case is addressed by one or more resource life cycles as may beappropriate.

2.8.1. Assess whether each resource life cycles involved use case is sufficiently detailed toassure that the use case is tested such that it produces a result of pass or fail.

2.8.2. Assess whether each resource within a resource life cycle is adequately specified toindicate whether the use cases are sufficient for comprehensive resource life cycle usecase assessment.

2.8.3. Assess whether each resource life cycle set of nodes within a resource life cycle isadequately specified to indicate whether the use cases are sufficient for determiningcomplete resource life cycle assessment.


71


2.8.4. Assess whether each resource life cycle node allocated set of database objects areadequately specified to indicate whether the use cases are sufficient for determiningcomprehensive database object allocation assessment.

02.8.4. Assess whether each resource life cycle node allocated set of business informationsystems are adequately specified to indicate whether the use cases are sufficient fordetermining comprehensive business information system allocation assessment.

2.8.5. If each resource life cycles involved component of resources, resource life cycle nodes,and allocated sets of database objects and business information systems are notsufficiently detailed, determine whether the use case and/or the resource life cycles andcontained resource life cycle components need to be enhanced.

2.9. Assess whether each use case is addressed by one or more user acceptance tests as maybe appropriate.

2.9.1. Assess whether each user acceptance test involved use case is sufficiently detailed toassure that the use case is tested such that it produces a result of pass or fail.

2.9.2. If each user acceptance test use case not sufficiently detailed, determine whether the usecase and/or the use case should be enhanced.

2.10. Assess whether each use case is addressed by one or more WBS as may be appropriate.2.10.1. Assess whether all the use cases have been delivered in terms of components, instances,

and stored metadata work products.2.10.2. Assess whether all the use cases have been properly detailed as to methodology,

evaluation, presentation, and delivery work steps.2.10.3. Assess whether all the use cases have been properly allocated sufficient unit effort

estimates.2.10.4. Assess whether all the use cases have been properly allocated sufficient quantity of units

that have to be developed.2.10.5. Assess whether all the use cases have been properly allocated work environment factors

to determine an accurate estimate of required resources.2.10.6. Assess whether all the use cases have been properly allocated work accomplishment and

recording functions necessary to support earned value reporting.2.10.7. Assess whether all the use cases have been properly allocated metadata recording effort

to ensure that all interrelationships are properly recorded into the metadata managementsystem database.

2.11. Assign the risk level associated with each meta-artifact not properly constructed.3. Determine the findings and create draft assessment report.4. Present the findings and revise draft assessment report.5. Create final report and deliver to The Agency.

6.3.12 User Acceptance Tests Assessment



72


1.1. Identify the appropriate set of user acceptance test documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the user acceptance test that are defined and captured.1.1.4. Identify the user acceptance test related work products.1.2. For each user acceptance test related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Business

Requirements, Business Rules, External data interface Requirements, Use Cases, ValueDomains Management, and WBS.

1.2.2. Identify the description for each interrelated user acceptance test component.2. Perform the assessment2.1. Assess whether each user acceptance test is addressed by one or more business

information systems as may be appropriate.2.1.1. Assess whether each user acceptance test allocated to a business information system

contained component is sufficiently detailed to result in a pass/fail.2.2.2. If each business information system user acceptance test use case not sufficiently

detailed, determine whether the user acceptance test and/or the various businessinformation system components should be enhanced.

2.2. Assess whether each user acceptance test is addressed by one or more businessrequirements as may be appropriate.

2.2.1. Assess whether each user acceptance test business requirement is sufficiently detailedthat the business requirement can be determined as having been met or not.

2.2.2. If each user acceptance test business requirement is not sufficiently detailed, determinewhether the user acceptance test or the business requirement should be enhanced.

2.3. Assess whether each user acceptance test business requirement is addressed by one ormore business rules as may be appropriate.

2.3.1. Assess whether each user acceptance test business rule is sufficiently specified todetermine whether the user acceptance test fully tests the business rule.

2.3.2. If each user acceptance test business rule is not sufficiently detailed, determine whetherthe user acceptance test or the business rule should be enhanced.

2.4 Assess whether each user acceptance test is addressed by one or more database objects asmay be appropriate.

2.4.1. Assess whether each user acceptance test database object is sufficiently specified todetermine whether the user acceptance test produces a pass/fail result.

2.4.2. Assess whether each user acceptance test involved database object table data structure issufficiently detailed to assure that the database object table data structure is tested suchthat it produces a result of pass or fail.

2.4.3. Assess whether each user acceptance test involved database object table process issufficiently detailed to assure that the database object table process is tested such that itproduces a result of pass or fail.


73


2.4.4. Assess whether each user acceptance test involved database object state is sufficientlydetailed to assure that the database object state is tested such that it produces a result ofpass or fail.

2.4.5. If each user acceptance test involved database object data structure, process, state orinformation system is not sufficiently detailed, determine whether the user acceptancetest and/or the database object data structure, process, state or information system shouldbe enhanced.

2.5 Assess whether each user acceptance test is addressed by one or more external datainterface requirement as may be appropriate.

2.5.1. Assess whether each user acceptance test external data interface is sufficiently specifiedto determine whether the user acceptance test fully tests the business rule.

2.5.2. If each user acceptance test external data interface is not sufficiently detailed, determinewhether the user acceptance test or the external data interface should be enhanced.

2.6. Assess whether each user acceptance test is addressed by one or more use cases as maybe appropriate.

2.6.1. Assess whether each user acceptance test use case is sufficiently detailed to result in theassurance that every aspect of the use case will be fully tested.

2.6.2. If each user acceptance test use case is not sufficiently detailed, determine whether theuser acceptance test or the use case should be enhanced.

2.7. Assess whether each user acceptance test is addressed by one or more value domainmanagement as may be appropriate.

2.7.1. Assess whether each user acceptance test value domain is sufficiently detailed as to theemployment mechanism that employs the value domain for validation, selection, update,and integrity control to ensure proper use.

2.7.2. If each user acceptance test value domain is not sufficiently detailed, determine whetherthe user acceptance test, the value domain, or the value domain employment mechanismsshould be enhanced.

2.8. Assess whether each user acceptance test is addressed by one or more WBS as may beappropriate.

2.8.1. Assess whether all the user acceptance test have been delivered in terms of components,instances, and stored metadata work products.

2.8.2. Assess whether all the user acceptance test have been properly detailed as tomethodology, evaluation, presentation, and delivery work steps.

2.8.3. Assess whether all the user acceptance test have been properly allocated sufficient uniteffort estimates.

2.8.4. Assess whether all the user acceptance test have been properly allocated sufficientquantity of units that have to be developed.

2.8.5. Assess whether all the user acceptance test have been properly allocated workenvironment factors to determine an accurate estimate of required resources.

2.8.6. Assess whether all the user acceptance test have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.


74


2.8.7. Assess whether all the user acceptance test have been properly allocated metadatarecording effort to ensure that all interrelationships are properly recorded into themetadata management system database.


6.3.13 Value Domains and Management Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of value domain management documents1.1.1. Review requirements documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the value domain management that are defined and captured.1.1.4. Identify the value domain management related work products.1.2. For each value domain management related work product assessment:1.2.1. Identify the relevant components, that is, Business Requirements, Business Rules,

External data interface Requirements, External Quality Standards, Use Cases, UserAcceptance Tests, and WBS.

1.2.2. Identify the description for each interrelated value domain management component.2. Perform the assessment2.1. Assess whether each value domain management is addressed by one or more business

requirements as may be appropriate.2.1.1. Assess whether each value domain management business requirement is sufficiently

detailed to know whether the business requirement has been properly met.2.1.2. If each value domain management business requirement is not sufficiently detailed,

determine whether any of the value domains, business requirements, or the value domainemployment mechanisms should be enhanced.

2.2. Assess whether each value domain management is addressed by one or more businessrule as may be appropriate.

2.2.1. Assess whether each value domain management business rule is sufficiently detailed toknow whether the business rule has been properly met.

2.2.2. If each value domain management business rule is not sufficiently detailed, determinewhether any of the value domains, business rules, or the value domain employmentmechanisms should be enhanced.

2.3 Assess whether each value domain is addressed by one or more database objects as maybe appropriate.

2.3.1. Assess whether each value domain database object is sufficiently specified to determinewhether the user acceptance test produces a pass/fail result.

2.3.2. Assess whether each value domain involved database object table data structure issufficiently detailed to assure that the database object table data structure is tested suchthat it produces a result of pass or fail.


75


2.3.3. Assess whether each value domain involved database object table process is sufficientlydetailed to assure that the database object table process is tested such that it produces aresult of pass or fail.

2.3.4. Assess whether each value domain involved database object state is sufficiently detailedto assure that the database object state is tested such that it produces a result of pass orfail.

2.3.5. If each value domain database object data structure, process, state or information systemis not sufficiently detailed, determine whether the user acceptance test and/or thedatabase object data structure, process, state or information system should be enhanced.

2.4 Assess whether each value domain management is addressed by one or more externaldata interface requirement as may be appropriate.

2.4.1. Assess whether each value domain management external data interface requirement issufficiently detailed to know whether the value domain has been properly employed.

2.4.2. If each value domain management external data interface requirement is not sufficientlydetailed, determine whether any of the value domains, external data interfaces, or thevalue domain employment mechanisms should be enhanced.

2.5. Assess whether each value domain management is addressed by one or more externalquality standard as may be appropriate.

2.5.1. Assess whether each value domain management external quality standard is sufficientlydetailed to know whether the external quality standard has been properly met.

2.5.2 If each value domain management external quality standard is not sufficiently detailed,determine whether any of the value domains, external quality standard , or the valuedomain employment mechanisms should be enhanced.

2.6. Assess whether each value domain management is addressed by one or more use case isaddressed by one or more value domains and management as may be appropriate.

2.6.1. Assess whether each value domain management use case is sufficiently detailed to knowwhether the use case has been properly employed the value domain to carry out itspecified processes.

2.6.2. If each value domain management use case is not sufficiently detailed, determine whetherany of the value domains, use cases, or the value domain employment mechanismsshould be enhanced.

2.7. Assess whether each business requirement is addressed by one or more user acceptancetests as may be appropriate.

2.7.1. Assess whether each value domain management user acceptance test is sufficientlydetailed to know whether the user acceptance test sufficiently exercises the allocatedvalue domains.

2.7.2. If each value domain management user acceptance test is not sufficiently detailed,determine whether any of the value domains, user acceptance tests, or the value domainemployment mechanisms should be enhanced.

2.8. Assess whether each value domains is addressed by one or more WBS as may beappropriate.


76


2.8.1. Assess whether all the value domains have been delivered in terms of components,instances, and stored metadata work products.

2.8.2. Assess whether all the value domains have been properly detailed as to methodology,evaluation, presentation, and delivery work steps.

2.8.3. Assess whether all the value domains have been properly allocated sufficient unit effortestimates.

2.8.4. Assess whether all the value domains have been properly allocated sufficient quantity ofunits that have to be developed.

2.8.5. Assess whether all the value domains have been properly allocated work environmentfactors to determine an accurate estimate of required resources.

2.8.6. Assess whether all the value domains have been properly allocated work accomplishmentand recording functions necessary to support earned value reporting.

2.8.7. Assess whether all the value domains have been properly allocated metadata recordingeffort to ensure that all interrelationships are properly recorded into the metadatamanagement system database.

2.9. Assign the risk level associated with each meta-artifact not properly constructed. 3. Determine the findings and create draft assessment report4. Present the findings and revise draft assessment report5. Create final report and deliver to The Agency

6.3.14 Contract Work Breakdown Structure (WBS) Assessment

1. Identify artifacts that bear on the assessment1.1. Identify the appropriate set of work breakdown structure documents1.1.1. Review work breakdown structure documents.1.1.2. Review scope and business problem related documentation.1.1.3. Identify the work breakdown structures that are defined and captured.1.1.4. Identify the work breakdown structure related work products.1.2. For each work breakdown structure related work product assessment:1.2.1. Identify the relevant components, that is, Business Information Systems, Business

Requirements, Business Rules, Database Domains, Database Objects, External datainterface Requirements, External Quality Standards, Information Needs, MissionOrganization Function, Resource Life Cycles, Use Cases, User Acceptance Tests, andValue Domains Management.

1.2.2. Identify the description for each interrelated work breakdown structure component.2. Perform the assessment2.1. Assess whether the work breakdown structure document is accomplished through the

appropriate set of business information systems as may be appropriate.2.1.1. Assess whether all the business information systems have been delivered in terms of

components, instances, and stored metadata work products.


77


2.1.2. Assess whether all the business information systems have been properly detailed as tomethodology, evaluation, presentation, and delivery work steps.

2.1.3. Assess whether all the business information systems have been properly allocatedsufficient unit effort estimates.

2.1.4. Assess whether all the business information systems have been properly allocatedsufficient quantity of units that have to be developed.

2.1.5. Assess whether all the business information systems have been properly allocated workenvironment factors to determine an accurate estimate of required resources.

2.1.6. Assess whether all the business information systems have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.

2.1.7. Assess whether all the business information systems have been properly allocatedmetadata recording effort to ensure that all interrelationships are properly recorded intothe metadata management system database.

2.1.8. Assess whether all the business information systems are accomplished such that theymake maximum use of previously created work products.

2.1.9. Assess whether all business information systems work products are stored as metadata tothe maximum extent possible and that all stored metadata is integrated, interrelated, andnon redundant with previously stored metadata from other work products.

2.1.10. Assess whether earned value reporting can occur as an automatic byproduct of thearchitecture, engineering, development, deployment and evolution of businessinformation systems.

2.2. Assess whether the work breakdown structure document is accomplished throughbusiness rules as may be appropriate.

2.2.1. Assess whether all the business rules have been delivered in terms of components,instances, and stored metadata work products.

2.2.2. Assess whether all the business rules have been properly detailed as to methodology,evaluation, presentation, and delivery work steps.

2.2.3. Assess whether all the business rules have been properly allocated sufficient unit effortestimates.

2.2.4. Assess whether all the business rules have been properly allocated sufficient quantity ofunits that have to be developed.

2.2.5. Assess whether all the business rules have been properly allocated work environmentfactors to determine an accurate estimate of required resources.

2.2.6. Assess whether all the business rules have been properly allocated work accomplishmentand recording functions necessary to support earned value reporting.

2.2.7. Assess whether all the business rules have been properly allocated metadata recordingeffort to ensure that all interrelationships are properly recorded into the metadatamanagement system database.

2.2.8. Assess whether all the business rules are accomplished such that they make maximumuse of previously created work products.


78


2.2.9. Assess whether all business rule work products are stored as metadata to the maximumextent possible and that all stored metadata is integrated, interrelated, and non redundantwith previously stored metadata from other work products.

2.2.10. Assess whether earned value reporting can occur as an automatic byproduct of thearchitecture, engineering, development, deployment and evolution of business rules.

2.3. Assess whether the work breakdown structure document is accomplished through theappropriate set of external data interface requirements as may be appropriate.

2.3.1. Assess whether all the external data interfaces have been delivered in terms ofcomponents, instances, and stored metadata work products.

2.3.2. Assess whether all the external data interfaces have been properly detailed as tomethodology, evaluation, presentation, and delivery work steps.

2.3.3. Assess whether all the external data interfaces have been properly allocated sufficientunit effort estimates.

2.3.4. Assess whether all the external data interfaces have been properly allocated sufficientquantity of units that have to be developed.

2.3.5. Assess whether all the external data interfaces have been properly allocated workenvironment factors to determine an accurate estimate of required resources.

2.3.6. Assess whether all the external data interfaces have been properly allocated workaccomplishment and recording functions necessary to support earned value reporting.

2.3.7. Assess whether all the external data interfaces have been properly allocated metadatarecording effort to ensure that all interrelationships are properly recorded into themetadata management system database.


2.3.9. Assess whether all work products are stored as metadata to the maximum extent possibleand that all stored metadata is integrated, interrelated, and non redundant with previouslystored metadata from other work products.


2.4. Assess whether the work breakdown structure document is accomplished through theappropriate set of database domains as may be appropriate.






79








2.5 Assess whether the work breakdown structure document is accomplished through theappropriate set of database object is addressed by one or more business informationsystems as may be appropriate.












80


2.6 Assess whether the work breakdown structure document is accomplished through theappropriate set of external data interface requirement as may be appropriate.









2.6.9. Assess whether all work products are stored as metadata to the maximum extent possibleand that all stored metadata is integrated, interrelated, and non redundant with previouslystored metadata.


2.7. Assess whether the work breakdown structure document is accomplished through theappropriate set of external quality standard as may be appropriate.








81






2.8. Assess whether the work breakdown structure document is accomplished through theappropriate set of more information need as may be appropriate.











2.9. Assess whether the work breakdown structure document is accomplished through theappropriate set of mission organization functions as may be appropriate.



82











2.10. Assess whether the work breakdown structure document is accomplished through theappropriate set of user acceptance tests as may be appropriate.










83




2.11. Assess whether the work breakdown structure document is accomplished through theappropriate set of resource life cycles as may be appropriate.











2.12. Assess whether the work breakdown structure document is accomplished through theappropriate set of use cases as may be appropriate.






84








2.13. Assess whether the work breakdown structure document is accomplished through theappropriate set of user acceptance tests as may be appropriate.













85



7.0 Risk Assessment

To the maximum extent practical, every data management assessment includes a list of the itemsassessed and a rating for each item. The proposed risk assessments are: no risk (0), low (1),moderate (2), or high (3).

Additionally, weighting factor multipliers of the risk assessments are: Concepts DataModel (1), Data Element Model (2), Logical Data Model (2), Physical Data Model (3), ViewData Model (3), and XML Model (3).

Every data component, whether it is a Data Model such as Data Element, Concepts,Logical, Physical, View, or XML, and every Interrelated Component such as BusinessRequirements, Use Cases, or User Acceptance Tests should be evaluated for its data orinterrelated data characteristics. The evaluation strategy will conclude that the componentrepresents one of the following five categories of product and process maturity and quality:

! Effective implementation! Implementation evident-not effective! Implementation underway-not yet in place! Respondent aware of requirement-not yet implemented! Component not evident

In addition, an overall risk will be assigned to the component. The strategy for assessing risks iscommon to most risk management plan. The risk process is represented by a matrix and consistsof two dimensions: likelihood, and consequence. The Likelihood dimension consists of fivelevels:

! Remote! Unlikely! Likely! Highly Likely! Near Certainty

The consequence dimension also consists of five levels:

! Minimal or no Impact! Acceptable with Some Reduction in Margin! Acceptable with Significant reduction in margin


86


! Acceptable No Remaining margin! Unacceptable

The combination of these two five levels produces an overall risk as set out in the followingtable:

LikelihoodLevels

Consequence Levels

1 2 3 4 5

5 Y Y R R R

4 G Y Y R R

3 G G G Y R

2 G G G G R

1 G G G G Y


87


A22 Metabase System Data Models


72

Metabase Overview, Meta Model Entity Relationship Diagrams, and the Knowledge Worker Framework

Business Information Systems


System

DBMS Environment

Application Type


PredominantUserClass

Resource Life Cycle

Node

Resource Life Cycle Node Business

Information System Assignment

Resource

Copyright 2005, Whitemarsh Information Systems Corporation,All Rights Reserved

08/18/2005

Business Information System Database Object Information

System Assignment

Database Object Information

System

View

Business EventMission,

Organization, & Function

View Column

View Column Structure

View Column Structure Type


Systems & View

Business Event Cycle

Business Cycle Structure Type

Business Event Cycle Structure

Calendar Cycle

Calendar Cycle Structure Type

Calendar Cycle Structure

View Column Structure Process

Level (Control, Management, Operational )

Construction Method (Custom,

Code Generator, COTS)

Status (Development, Maintenance, Production)

Programming Language

Data Architecture

Class

EnviornmentType


20


Database Objects

Database Object

database object state and database object information

system

database object information system and

database object process

database object information

system

database object state

database object process column

database object table

processdata element

column

table

membership rationale


Database Domain

Database Domain & Database

Object

Database Objects Copyright 2005, Whitemarsh Information Systems Corporation,All Rights Reserved

04/12/2005

Business Information System Database

Object Information System Assignment

Business Information System

Schema


21


Data Elements

Compound Data Element & Derived

Data Element

Data Element & Meta Category

Value

Compound Data Element & Data

Element

Compound Data Element

Data Element Concept & Meta Category Value

Derived Data Element

Meta Category Value

Derived Data Element & Data

Element

Data Element

Business Domain


01/25/2003

Meta Category Value Type

Data Elements


Classification

Compound Data Element Structure


Structure TypeValue Domain

Conceptual Value

Domain

Data Element Classification

Structure


Structure Type

Conceptual Value Domain

Structure

Conceptual Value Domain Structure Type

Data Element Concept Structure

Data Element Concept

Structure Type


Data Element & Data Element Classification

Data Element ConceptValue Domain

Structure

Value Domain Structure Type

Value Domain Data Type

Value Domain Values

Value Domain Values Structure

Value Domain Values

Structure Type

ConceptConceptStructure

Concept Structure

Type


22


Data Integrity Rule: Specification

Table

Column Input

ActionValidateSelectInput

Data Integrity

Rule

Column

Schema

Column Action

Column Validate

Column Select

Data Integrity Rule Structure

Data Integrity Rule Structure Type

Data Integrity Rule Specification



23


Data Integrity Rules: Binding

Data Integrity RuleData Integrity Rule Structure

Type

Data Integrity Rule

Structure

Data Integrity Rule Type

Database Object Table

Process



View ColumnDBMS Column

Column

Attribute

Data Element

Entity

Table

DBMS Table

View


& Derived Data Element


Database Object

Database Object Object Table Process

Column

Data Integrity RuleMeta Entity Mapping

Metabase Meta-Entity

Type

Data Integrity Rule Binding



24


Document and Form

Document and FormCopyright 2004, Whitemarsh Information Systems Corporation,

All Rights Reserved12/15/2004

View

Business Event

View Column




Organization

Function

Mission

Mission Organizations

Mission Organization & Function

Document Section

DocumentCell

Mission Organization

Function&

Document Section

Document Cell&

View Column

DocumentDocument Structure

Document Structure Type

FormSection

Form CellForm Cell

&View Column

FormForm

StructureForm

Structure Type


Function&

Form Section


25


Implemented Data Model

Data Element & Meta

Category Value


Data Element Concept &

Meta Category Value

Meta Category Value

Table Primary Key

Column

Table

Table Primary Key & Column

Table Foreign Key

Table Foreign Key & Column

Attribute

Entity

Subject

Data Element

Business Domain

Column & Meta Category

Value

Schema

Value DomainStructure


SQL Data Type

Implemented Data ModelCopyright 2006, Whitemarsh Information Systems

Corporation,All Rights Reserved

01/26/06

Meta Category Value TypeClassification

TableCandidate

Key

TableCandidate Key &

Column



Structure Type

Value Domain


26


Information Needs Analysis

Characterisitic

Characteristic Type

Ranking

Information Need Type

Information Need

Mission, Organizational

Functional Ranked Information Need

Information Need Characterisitic Assignment

Organization

Function

Mission




27


Mission Organization, Function, and Position


Function Position

Mission, Organization, Function, Position

Organization

Function

Mission



Database Domain

Database Domain & Database Object

Database Object


8/23/2005

Business Event


System

Management Level

Person

Position


Function PositionPerson


28


Operational Data Model


Value

Meta Category Value

Column

Table

Database

Data Element

Business Domain

Column & Meta Category Value

Schema

DBMS DBMS Schema

DBMS Column

DBMS Table



06/01/2005

DBMS Data Type

DBMS Table

Primary Key

DBMS Table Primary Key & DBMS Column

DBMS Table Foreign Key &

Column

DBMS Table Foreign Key

Meta Category

Value Type

SQL Data Type



Classification

Database Architecture Class

DBMS Table CandidateKey & DBMS Column

DBMS Table Candidate

Key

DBMS Table Secondary

Key

DBMS Table Secondary Key & DBMS Column

Database NatureDatabase

Production Status

DBMS Data Type Picture


29


Project Management

Staff

Phone

Phone Type

Status Type

State

Work

Assigned Task

Task

Project

Task Template

Project Template

Deliverable Template Type

Deliverable

Deliverable Template

Job Title

Organization

Project Template Type

Resource

Role Type

Skill Level

Skill

Staff Skill Level

Work Environment Factor Type

Work Environment

Factor

Task Skill Level Requirement

Contract

Contract Resource

Contract & Organization

Contract Role

Skill Level Type

Task & Work Environment Factor

Work Environment Multiplier Type

Project Template &Deliverable Template

Project Template &Task Template

Base Line

Base LineWEF

Base LineStaff

RLC Node


30


Requirements Management


Requirement Category

Requirement

Mission Organization &

Function


3/08/2011

RequirementStructure

Type


Resource Life Cycle Node and Requirement

Structure

Use Case and Requirement Structure

Business Event


System

DBMS Column

User Acceptance Test StepStructure

Data Integrity Rule Structure and

Requirement Structure

Business Event and Requirement

Structure

Business Information System and Requirement

Structure

DBMS Column and Requirement

Structure

User Acceptance Test Step

Structure and Requirement

Structure

Mission Organization & Function and Requirement

Structure

Resource Life Cycle Node

Data Integrity Rule

Structure

Use Case

Database ObjectDatabase Object and Requirement


31


Resource Life Cycle Analysis


Information Need

Resource Life Cycle

Node

Resource Life Cycle

Node Structure

Resource Life Cycle Node Information Need

Assignment

Resource Life Cycle Node Information

System Assignment

Database


Database Object Assignment


System

DBMS

Resource


Structure Type

Resource Type

Mission Resources


Mission

DBMS Schema


02/18/2000

Data-base

Object


32


Specified Data Model

Data Element & Meta

Category Value

Data Element ConceptStructure


Meta Category Value

Meta Category

Value

AttributeEntity

SubjectData Element

Business Domain

Entity Primary Key

Entity Primary Key & Attribute

Entity Foreign Key

Entity Foreign Key & Attribute

Attribute & Meta Category Value



Specified Data ModelCopyright 2000, Whitemarsh Information Systems Corporation,



Entity Candidate Key


& Attribute



33


Use Cases

Use Cases


Function


01/19/2011

Business Event


SystemUse Case

Use CaseEvent

Use CaseSpecial

Conditions

Use Case Event Actors

Use CasePost

Conditions

Use CasePreconditions

Use Case Events & Mission Organization

Function

Use CaseEvent & Business

Information System

Use Case Facts & Use Case

Preconditions

Use Case Facts & Use Case Events

Use Case Facts & Use Case Post

Conditions

Use Case Facts

SchemaTablesColumns

Use Case Actors

Use Case Actor Role

Use Case Structure

Use Case Structure

Type

Use Case Facts and Columns

Use Case and Use Case Facts

Mission, Organization,

Function, Position, Person


System


34




Use Case Event

User Acceptance

Test


5/04/2010



Type


User Acceptance Test Column

View Column


35


View Data Model

Compound Data Element &



Value


Meta Category Value

Column

Table

Database

Data Element

Business Domain


View

View Column

View Column & Compound Data

Element

View Column & Derived Data

Element

View Column & DBMS ColumnSchema

DBMS

DBMS Schema

DBMS Column

DBMS Table


12/10/2001


SQL Data Type

View Data Model


Classification



Structure


Structure Type




System



System & View


36


Wire Frames

View Column & DBMS Column

Use CaseEvent

ScreenSection

Screen Section Cell

Screen Section Cell

Column

Screen

ViewBusiness Rule

View Column

Screen &Business

Information System

Screen &Business

Information System

Use Case Event & Screen Section

Screen Control

Screen ControlType

DBMS Column

DBMS Table


37


A23 Whitemarsh DHS/ICE Presentation on RFP Development


73


REQUEST FOR PROPOSAL (RFP) DEVELOPMENT

STRATEGY FOR SUCCESS

1

1/20/2011


DATA MANAGEMENT PRACTICES

1/20/2011

2

Communities of Interest

Independent Verification &

Validation

Iterative RequirementsDevelopment

Data ManagementPrograms

1

2

34

5


TOPICS

1. Traditional Methodology2. Methodology Problems3. Replacement Methodology4. Problem Resolutions5. Replacement Methodology Milestones6. Candidate Staffing7. Required Hardware and Software8. Where Used / Past Performance9. Approach Comparison Summary10. Summary and Benefits

3

1/20/2011


ULTIMATE OBJECTIVE Create an RFP that results in development bids from credible

vendors that are valid, reliable, repeatable, and are within a narrow competitive range.

Create an RFP that incorporates a prototype-proven V5 set of “requirements,” prototypes, and other Architecture and Design materials that are non-redundant, integrated, and cross-referenced.

Create vendor contract that is focused only on implementation Produce a vendor developed system that is predictable as to

time, scope, cost, and content.

1/20/2011

4


REAL PROBLEM NEEDING REAL SOLUTION

1/20/2011

5

Error Statistics Summaries from Standish Chaos Studies (1999 through 2009)

Result Classification

Percent

Utility (Gas & Electric) 365 Respondents on the Success of Client/Server Development Efforts

Succeed 24 16

Challenged 43 53

Failed 33 31

Legend Category DescriptionSucceed On-time, within budget, features as promised

Challenged Late, greater than budgeted, less features than promised

Failed Cancelled outright


TOP REASONS FOR SUCCESS & FAILURE

Success User Involvement Executive Management Support Clear Statement of Requirements

Failure Incomplete Requirements Lack of User Involvement Lack of Resources

1/20/2011

6


KNOWLEDGE WORKER FRAMEWORK

Deliver-ables Mission

Machine Interface “Man”

Database Object

Bus. Info Systems

Business Event

Business Function

Organ-ization

Scope 5 2 3 1 3 4

Business 5 3 2 1 6 6

System 3 2 2 1 12 8

Technology 1 0 0 0 8 6

Deployment 0 0 0 0 5 5

Operations 0 0 0 0 3 3

Pct Total 14 7 7 3 37 32

1/20/2011

7


DISTRIBUTION OF GAO ERROR PERCENTS ACROSS BUSINESS INFORMATION SYSTEM DEVELOPMENT

Building and Employing Enterprise Architecture Models: Scope and Business Rows, all columns. About 41% of all GAO IT errors.

Creating and Evolving Information Systems Plans: System Row, all columns. About 8% of GAO IT errors.

Architecture and Engineering of Data Models: Technology Row, database object column. Less than 2% of Errors

Performing Reverse Engineering of Legacy Systems and Databases: Operations, Deployment, Technology and System Rows. Database Objects Column. Less than 2% of Errors

Forward Engineering Manufacture of New Systems and Databases:Operations, Deployment, Technology and System Rows. Database Objects Column. Less than 2% of Errors

Employment Errors:Systems through Operations Rows. Operations and Functions Columns. About 49% of Errors.

1/20/2011

8


1.0 TRADITIONAL METHODOLOGY

1/20/2011

9


2.0 METHODOLOGY PROBLEMS

Intrinsically Nothing. Operationally, Everything. Long (6-9 month) cycles across interviews, document development,

software development, and Functional SME demonstration & review. Very significant monies spent each cycle (approx $3 million per month). Push-back by SMEs, et al causes:

Significant Software re-do that costs large $$$ and real delay Significant DB re-do that costs even more $$$ and even more delay

Money and time runs out well before ultimate requirements are discovered and turned into operational database and software.

All deliverables are stove-pipe documents with little to no configuration management, integration, interoperability, and traceability.

1/20/2011

10


TRADITIONAL DEVELOPMENT PHASES AND TIME-LINE

11

1/20/2011


3.0 REPLACEMENT METHODOLOGY Integrate functional SMEs into small requirements development teams Iterate requirements through prototypes until “uncle.” Incorporate “Architecture & Design” metadata into a database that is:

Non-redundant Integrated Interoperable Fully-traceable

Finalize “Requirements” into RFP before release. RFP contains: Architecture & Design database and supporting metadata management system. Complete set of executable prototypes that demonstrate requirements Everything in non-redundant, integrated, interoperable and traceable form. Other RFP materials.

1/20/2011

12


4.0 PROBLEM RESOLUTIONS

1/20/2011

13

Existing Problems Resolution

Problem Solution (assumes 6 major functional areas)

Long 6-9 month cycles Days to 3-week cycles from interviews to prototype demonstration

Very significant monies ($50 – 70 million) before first real demonstration

2 experts plus 2 SMEs per team ($30K per cycle) * 5 cycles & 6 functional areas = $900K for all functional areas.

Functional User Pushback Functional SMEs are part of teams. With 5 cycles, all requirements are teased-out through prototype generation.

Stove Pipe Architecture & Design Documents

All deliverables and prototypes are contained within a single, integrated, non-redundant and traceable database with supporting metadata management system.


REPLACEMENT PROCESS FLOW

1/20/2011

14


SCOPE OF METADATA DATABASE

1/20/2011

15


BUSINESS INFORMATION CENTRIC METADATA MANAGEMENT ENVIRONMENT

1/20/2011

16


PROTOTYPE GENERATION

17

1/20/2011


5.0 REPLACEMENT METHODOLOGY MILESTONES

1/20/2011

18

Milestone Wk ActivitiesStart & Team Formation 2 Contract, Get team members, build schedule

Load SEVIS 2 into Database 6 Mine SEVIS II documents & Load DB

Cycle 1 10 Generate 1st prototype round, modify MD DB, and present to SMEs.

Cycle 2 13 Revise MD DB, generate 2nd prototype round, and present to SMEs.

Cycle 3 16 Revise MD DB, generate 3nd prototype round, and present to SMEs.

Cycle 4 19 Revise MD DB, generate 4th prototype round, and present to SMEs.

Cycle 5 22 Revise MD DB, generate 5th prototype round, and present to SMEs.

Consolidate MD DB 26 Final Revision of all Metadata to ensure highest quality

Build RFP Sections (C, J, L, M) 30 Produce documents from Metadata DB into critical RFP Sections

Support Vendor Q&A 40 Be available to provide answers and demonstrations to all vendors.

Create Proposal Evaluation Guide

44 Generate Proposal evaluation guide for Government reviewers.


ITERATIVE REQUIREMENTS DEVELOPMENT

19

1/20/2011


6.0 CANDIDATE STAFFING

1/20/2011

20

Team Candidate Role

0 Richard Gibbs Project Manager

1 Mike Gorman Database and Business Information System Expert

Robert Artigas Prototype Generation Expert (Clarion)

2 Hank Lavender Database and Business Information System Expert

Russ Eggen Prototype Generation Expert (Clarion)

3 Marcos Ferrer Database and Business Information System Expert

Lew Struck Prototype Generation Expert (Clarion)


7.0 HARDWARE AND SOFTWARE

Moderate Windows 2008 Server Metabase System 10 Concurrent User License Mimer DBMS License Six laptops with Windows XP or W7 Three Clarion et al Licenses (one for each

team)

1/20/2011

21


8.0 WHERE USED / PAST PERFORMANCE

U.S. Army TACOM. From $400K to $40K per system State of California. Prototypes for Major Revision Hershey Chocolate. Enterprise Architecture then incremental

functional implementation State of Ohio. State-wide Courts System prototype then

production implementation Mars Foods. World Wide Inventory Management INCITS. $300K for a $2.4 million Membership Management

System Army CIO-G6 AR 25-1 and DA PAM 25-1-1

1/20/2011

22


BUSINESS INFORMATION SYSTEM COST MODEL

1/20/2011

23


APPROACH COMPARISON SUMMARY

1/20/2011

24

Contract let at Month 1. Requirements & Design mainly by contractor Heavy front end cost weighting No real requirements-proven prototypes SME push-backs often too late and very costly SMEs mainly involved as reviewers

Requirements & Design is done “in house”. “V1” contract let only after Requirements &

Design (“D’s) is proven via prototypes SME push-backs virtually eliminated Implementation Contract starts with proven

Requirements and Design SMEs integral partners of Requirements and

design and QA/QC for Implementation.

Versus


10.0 SUMMARY AND BENEFITS Strategy to create high-quality, prototype-proven requirements. Quick Cycles of at most 3-weeks to arrive at design version 5 before RFP is

issued. (Demonstrations reduced from 9 – 12 months to five iterations of 3 week cycles)

Complete integration of all Architecture & Design documents into a metadata management database and system.

Delivery of V5 proven requirements to proposal vendors. Little to no room for misinterpretation. Supported by Metadata DB, Copious cross-references, and Prototypes.

Virtually eliminates implementation time and money on requirements, design, and revisions. Total focus on first-time correct implementation.

Easy to QA & QC because implementation starts with V5 of proven requirements.

1/20/2011

25


RFP SECTIONS “C,” “J,” “L,” & “M”

Generate content for RFP sections from metadata management database.

Create very high quality RFP content that is valid, reliable, and repeatable.

Create section “M” evaluation recommendations. E.g., Highly value continued use of Metadata Management

environment for all implementation deliverables. Highly value use of code generators that standardize,

maximize re-use, and minimize custom coding.

1/20/2011

26


IN CLOSING, THIS APPROACH… Increases Productivity. A data-driven foundation for all

integrated and non-redundant specifications basis for implementation. Maximizes re-use of existing SEVIS II materials developed over three year period. Thereafter 5 prototype cycles.

Increases Quality. Maximizes requirements accuracy across entire SEVIS domain--proven through prototypes.

Decreases Risk. Maximizes traceability, integration and non-redundancy.

Decreases Cost. Prototype-proven requirements support identify once, define/specify once, and implement once strategy.

1/20/2011

27


A24 Whitemarsh Methodology WBS


74



ii

Whitemarsh on Database


October 2011


Designations used by companies to distinguish their products are often claimed as trademarks. Inall instances where Whitemarsh Press is aware of a claim, the product names appear in initialcapital or all capital letters. Readers, however, should contact the appropriate companies formore complete information regarding trademarks and registration.

©2011 by Whitemarsh Information Systems CorporationAll rights reserved

This publication is designed to provide accurate and authoritative information in regard to thesubject matter covered. It is sold with the understanding that the publisher is not engaged inrendering legal, accounting, or other professional services. If legal advise or other expertassistance is required, the services of competent professional person should be sought. FROM ADECLARATION OF PRINCIPLES JOINTLY ADOPTED BY A COMMITTEE OF THEAMERICAN BAR ASSOCIATION AND A COMMITTEE OF PUBLISHERS.

Reproduction or translation of any part of this work beyond that permitted by section 107 or 108of the 1976 United States Copyright Act without the permission of the copyright holder isunlawful. Requests for permission or further information should be addressed to WhitemarshPress.

ISBN n-nnn-nnnnn-n

Printed in the United States of America

10 9 8 7 6 5 4 3 2 1


iv


Table of Contents

1 Preliminary Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01 Form project team, plan phase, & estimate project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01.01 Select manager for project phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01.02 Identify administrative, clerical, and computer supports . . . . . . . . . . . . . . . . . . . . 11.01.03 Select project staff for phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01.04 Secure commitments for staff availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01.05 Create estimate for project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01.06 Create phase and task plans and schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01.07 Organize phase review committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01.08 Conduct methods training as required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.01.09 Set up phase documentation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.01.10 Create project plan and schedule estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.01.11 Establish metabase system database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.01.12 Interrogate and maintain metabase system database during phase . . . . . . . . . . . . 21.01.13 Establish effective computing environment, libraries, etc., for resource usage

tracking, for storage of data, programs, and run streams for development and unittest, for system test and integration, and for production . . . . . . . . . . . . . . . . . . . . 2

1.01.14 Develop and/or use database standards for phase . . . . . . . . . . . . . . . . . . . . . . . . . 21.01.15 Identify and allocate management and clerical overhead to phase . . . . . . . . . . . . 21.02 Create initial database project requirements description . . . . . . . . . . . . . . . . . . . . . . . . . . 21.02.01 Request and review documentation of prior related database efforts . . . . . . . . . . 21.02.03 Obtain initial scoping information for project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.02.02.01 Conduct broad interviews with user management to determine business database

objectives for database project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.02.02.02 Identify, name and briefly describe the involved missions . . . . . . . . . . . . . . . . . . 31.02.02.04 Identify, name and briefly describe the business resources that are the foundation

of the database objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.02.02.07 Identify, name and briefly describe the existing business information systems . . 31.02.02.09 Identify, name and briefly describe the critical business events that currently

involve automation assists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.02.02.11 Identify, name and briefly describe the business functions that must be performed

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.02.02.12 Identify, name and briefly describe the organizations involved in the enterprise

database effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.02.03.01 Identify major suppliers & uses of database data . . . . . . . . . . . . . . . . . . . . . . . . . 31.02.03.02 Identify, create, & analyze prototypical data and reports . . . . . . . . . . . . . . . . . . . 31.02.03.03 Conduct preliminary data transfer and data conversion interview . . . . . . . . . . . . 31.02.04 Formulate list of business database objectives that are to be achieved . . . . . . . . . 41.02.05 Formulate reasonable list of mechanisms to evaluate project success . . . . . . . . . 4


v


1.02.06 Reach consensus on database objectives and evaluation mechanisms . . . . . . . . . 41.03 Create mission description model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.04 Create business information systems plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.04.01 Create Ross resource life cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.04.02 Create relationships between resource life cycle nodes and metabase component

instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.04.03 Propose business information systems projects . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.04.04 Examine the state of automation for each associated business information system

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.04.04.01 Determine improvements required for logical database . . . . . . . . . . . . . . . . . . . . 91.04.04.02 Determine improvements required for physical database . . . . . . . . . . . . . . . . . . . 91.04.04.03 Determine improvements required for interrogation . . . . . . . . . . . . . . . . . . . . . . 101.04.04.04 Determine improvements required for system control . . . . . . . . . . . . . . . . . . . . 101.04.04.05 Create system upgrade assessment report for information system . . . . . . . . . . . 101.04.04.06 Estimate the resources required to upgrade the business information system . . . 121.04.04.07 Prepare consolidated business information system upgrade report for each

business information systems associated with resource life cycle node . . . . . . . 121.04.04.08 Create consolidated high-level estimate for all business information systems

associated with each resource life cycle node . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.04.04.09 Create overall business information system upgrade presentation . . . . . . . . . . . 131.04.04.10 Conduct phase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.04.05 Create and load resource life cycle node pert chart . . . . . . . . . . . . . . . . . . . . . . . 131.04.06 Enter the resource life cycle node chart into a project management package as a

PERT chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.04.07 Enter the PERT chart of the upgrade business information systems as a subproject

for appropriate resource life cycle nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.04.08 Resource load the resource life cycle subproject nodes . . . . . . . . . . . . . . . . . . . 131.04.09 Project management scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.04.10 Publish and review the Information systems plan . . . . . . . . . . . . . . . . . . . . . . . . 141.05 Create preliminary analysis phase report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.05.01 Select project from information systems plan to accomplish . . . . . . . . . . . . . . . 141.05.02 Prepare database system scope narrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.05.03 Create plan & format for presenting mission descriptions, database domains, and

all graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.05.04 Create proposal for conceptual specification phase . . . . . . . . . . . . . . . . . . . . . . . 141.05.05 Prepare final report for preliminary analysis phase . . . . . . . . . . . . . . . . . . . . . . . 151.06 Create preliminary analysis presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.07 Conduct phase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Conceptual Specification Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16


vi


2.01 Form project team, plan phase, and revise project plan . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.01 Select manager for project phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.02 Identify administrative, clerical, and computer supports . . . . . . . . . . . . . . . . . . . 162.01.03 Select project staff for phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.04 Secure commitments for staff availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.05 Create phase and task plans and schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.06 Organize phase review committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.07 Conduct methods training as required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.08 Set up phase documentation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.09 Revise project plan and schedule estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.01.10 Interrogate and maintain metabase system database . . . . . . . . . . . . . . . . . . . . . . 162.01.11 Develop and/or use database standards for phase . . . . . . . . . . . . . . . . . . . . . . . . 162.01.12 Review & revise preliminary analysis phase as necessary . . . . . . . . . . . . . . . . . 162.02 Create logical database of business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.02.01 Perform detailed data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.02.02 Perform detailed data analysis for data transfer and conversion . . . . . . . . . . . . . 172.02.03 Update project mission descriptions, mission description diagram, database

domains & construct database domain diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 172.02.04 Define data integrity model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.02.04.01 Finalize database domain diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.02.04.02 Finalize database objects and database object diagram . . . . . . . . . . . . . . . . . . . . 182.02.04.03 Create generalized/abstracted/leveled database domain diagrams . . . . . . . . . . . 182.02.04.04 Narrow database diagram to project scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.02.04.05 Update business and technical glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.02.04.06 Specify data elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.02.04.07 Create database object table component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.02.04.08 Specify database object table process component . . . . . . . . . . . . . . . . . . . . . . . . 222.02.04.09 Create database object information system component . . . . . . . . . . . . . . . . . . . . 262.02.04.10 Specify database object state component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.02.05 Create or modify specified data model as appropriate . . . . . . . . . . . . . . . . . . . . 272.02.06.01 Perform data requirements analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.02.06.02 Define retail data warehouse data integrity model . . . . . . . . . . . . . . . . . . . . . . . 272.02.06.03 Identify data integrity requirements for data transfer and data conversion . . . . . 282.02.06.04 Perform analysis to support data transfer and conversion from source databases to

retail data warehouse databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.02.06.05 Verify retail data warehouse data integrity model . . . . . . . . . . . . . . . . . . . . . . . . 282.02.06.06 Create retail data warehouse logical database specification report . . . . . . . . . . . 292.02.06.07 Create retail data warehouse logical database presentation . . . . . . . . . . . . . . . . . 292.02.06.08 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.02.06 Create logical database specification report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.02.08 Create logical database presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


vii


2.02.09 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.03 Specify physical database of business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.03.01 Specify business information systems model . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.03.01.01 Identify business information systems appropriate for subordinate mission description

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.03.01.02 Create online data update system specification . . . . . . . . . . . . . . . . . . . . . . . . . . 312.03.01.03 Create batch data update system specification . . . . . . . . . . . . . . . . . . . . . . . . . . 332.03.01.04 Create data loading subsystem specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.03.01.05 Create specification for each data transfer and data conversion subsystem . . . . 362.03.01.06 Create enterprise-wide data collection system specification . . . . . . . . . . . . . . . . 372.03.02 Create business event model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.03.03 Create use case model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.03.04 Create Organization Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.03.05 Estimate database size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.03.06 Evaluate requirements for backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.03.07 Specify database integrity subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.03.08 Consolidate logical database changes to accommodate physical database . . . . . 412.03.09 Prepare physical database requirements specification . . . . . . . . . . . . . . . . . . . . . 412.03.10 Create physical database presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.03.11 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.04 Analyze interrogation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.04.01 Identify, name and then create information system process diagram for each

specialized report subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.04.02 Analyze standard report requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.04.03 Analyze ad-hoc report requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.04.04 Prepare interrogation requirements report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.04.05 Analyze data transfer and data conversion reporting requirements . . . . . . . . . . . 432.04.06 Create interrogation presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.04.07 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.05 Specify system control requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.05.01 Specify audit trail needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.05.02 Specify backup & recovery needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.05.03 Specify concurrent operations requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.05.04 Specify security & privacy requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.05.05 Specify reorganization requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.05.06 Specify multiple database requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.05.07 Prepare system control requirement report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.05.08 Create system control presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.05.09 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.06 Validate cross product of data integrity and data transformation models . . . . . . . . . . . . 462.07 Create cross-product validation presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46


viii


2.08 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.09 Validate through prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.09.01 Select appropriate DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.09.02 Create logical database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.09.03 Create test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.09.04 Create physical database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.09.05 Create interrogation scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.09.06 Present design iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.09.07 Create design iteration changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.09.08 Update database specification design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.09.09 Walkthrough all components of the data transfer and data conversion . . . . . . . . 492.10 Consolidate logical database changes required to accommodate physical database

interrogation, and system control additional requirements, and revise as necessary . . . 492.11 Create conceptual specification phase report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.11.01 Create introduction & scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.11.02 Create logical database requirements section . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.11.03 Create physical database requirements section . . . . . . . . . . . . . . . . . . . . . . . . . . 502.11.04 Conduct final review of functional completeness & acceptable interaction of data

integrity model and data transformation model. . . . . . . . . . . . . . . . . . . . . . . . . . 502.11.05 Create interrogation requirements section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.11.06 Prepare system control requirements section . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.11.07 Prepare conceptual specification phase report . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.12 Create conceptual specification phase presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.13 Conduct phase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 Binding Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01 Form project team, plan phase, and revise project plan . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.01 Select manager for project phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.02 Identify administrative, clerical, and computer supports . . . . . . . . . . . . . . . . . . . 533.01.03 Select project staff for phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.04 Secure commitments for staff availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.05 Create phase plans and schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.06 Organize phase review committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.07 Conduct methods training as required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.08 Set up phase documentation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.09 Revise project plan and schedule estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.01.10 Develop and/or use database standards for phase . . . . . . . . . . . . . . . . . . . . . . . . 533.01.11 Interrogate and maintain metabase system database during phase . . . . . . . . . . . 533.02 Review conceptual specification phase for completeness and revise as necessary . . . . . 533.03 Remedy any data availability and quality problems determined during conceptual

specification phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.04 Determine Impact on Corporate Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53


ix


3.04.01 Evaluate tables that are boundary to outside systems and revise as necessary tomaximize compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.04.02 Determine impact on logical database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.04.03 Determine impact on physical database specification . . . . . . . . . . . . . . . . . . . . . 543.04.04 Determine impact on interrogation subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . 553.04.05 Determine impact on system control facilities . . . . . . . . . . . . . . . . . . . . . . . . . . 553.04.06 Determine impact on ancillary supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.04.07 Determine impact on database system quality tests . . . . . . . . . . . . . . . . . . . . . . . 553.04.08 Formulate corporate business model impact report . . . . . . . . . . . . . . . . . . . . . . . 563.05 Evaluate, select and/or procure DBMS packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.05.01 Determine whether database application requires static relationship data structures

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.05.02 Create requirements document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.05.03 Create DBMS requirements document presentation . . . . . . . . . . . . . . . . . . . . . . 563.05.04 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.05.05 Issue RFP and select DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.05.06 Formulate DBMS selection report and presentation . . . . . . . . . . . . . . . . . . . . . . 573.05.07 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.05.08 Install package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.05.09 Conduct DBMS training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.05.10 Determine DBMS performance characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 573.05.10.01 Develop prototypical implemented data model design . . . . . . . . . . . . . . . . . . . . 583.05.10.02 Develop prototypical implemented data model DDL and submit to DBMS . . . . 583.05.10.03 Develop prototypical data loading programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.05.10.04 Develop prototypical data update programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.05.10.05 Develop prototypical interrogation modules in HLI and NL . . . . . . . . . . . . . . . 583.05.10.06 Develop statistically valid distributions of sample data . . . . . . . . . . . . . . . . . . . 583.05.10.07 Assess DBMS system control capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.05.10.08 Run various tests at different loads, velocities,etc. . . . . . . . . . . . . . . . . . . . . . . . 603.05.10.09 Develop graphs and tables to assist in database design and language selection

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.05.10.10 Create DBMS performance report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.05.10.11 Create DBMS performance presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.05.10.12 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.05.11 Develop hints and tidbits section for documentation . . . . . . . . . . . . . . . . . . . . . . 613.05.12 Create a mapping from DBMS taxonomy to DBMS documentation . . . . . . . . . 613.05.13 Develop generic examples for all database application functions . . . . . . . . . . . . 613.05.14 Adjust programming effort estimates for programming assists provided by natural

languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.06 Evaluate, select and/or procure metabase system database packages . . . . . . . . . . . . . . . 613.06.01 Create metabase system database requirements document . . . . . . . . . . . . . . . . . 61


x


3.06.02 Create metabase system database requirements document presentation . . . . . . . 623.06.03 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.06.04 Issue RFP and select metabase system database . . . . . . . . . . . . . . . . . . . . . . . . . 623.06.05 Formulate metabase system database selection report and presentation . . . . . . . 623.06.06 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.06.07 Install metabase system database package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.06.08 Conduct metabase system database training . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.06.09 Accomplish metabase system database prototype implementation . . . . . . . . . . . 633.06.10 Conduct metabase system database prototype demonstion . . . . . . . . . . . . . . . . . 633.06.11 Create metabase system database prototype demonstration presentation . . . . . . 633.06.12 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.07 Determine Implementation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.07.01 Bind logical database to selected DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.07.02 Bind physical database to selected DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.07.03 Determine interrogation implementation strategy . . . . . . . . . . . . . . . . . . . . . . . . 663.07.04 Configure system control implementation strategy . . . . . . . . . . . . . . . . . . . . . . . 663.07.05 Assess hardware availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.07.06 Determine implementation strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.07.07 Prepare system proposal for implementation phase . . . . . . . . . . . . . . . . . . . . . . 683.07.08 Create implementation approach presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.07.09 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.08 Prepare binding phase report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.09 Create binding phase presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.10 Conduct phase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694 Implementation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01 Form project team, plan phase, and revise project plan . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.01 Select manager for project phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.02 Identify administrative, clerical, and computer supports . . . . . . . . . . . . . . . . . . . 714.01.03 Select project staff for phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.04 Secure commitments for staff availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.05 Create phase plans and schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.06 Organize phase review committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.07 Conduct methods training as required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.08 Set up phase documentation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.09 Revise project plan and schedule estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.01.10 Develop and/or use database standards for phase . . . . . . . . . . . . . . . . . . . . . . . . 714.01.11 Interrogate and maintain metabase system database during phase . . . . . . . . . . . 714.02 Create or revise logical database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.03 Create or revise physical database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.03.01 Create or revise operational data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.03.02 Create or revise views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72


xi


4.03.03 Create or revise each data update subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.03.04 Create or revise each data loading subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.03.05 Create or revise each data conversion subsystem . . . . . . . . . . . . . . . . . . . . . . . . 754.03.06 Create or revise test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.03.07 Create or revise database backup procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.03.08 Perform system development test on physical database . . . . . . . . . . . . . . . . . . . 764.03.09 Revise human support subsystems affected by new on-line data update subsystems

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.03.10 Create or revise physical database implementation report . . . . . . . . . . . . . . . . . 764.03.11 Create or revise physical database implementation presentation . . . . . . . . . . . . 774.03.12 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.04 Create or revise critical interrogation subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.04.01 Analyze implementation requirements & create schedule for specific interrogation

subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.04.02 Analyze implementation requirements for specific interrogation subsystem . . . 774.04.03 Create or revise specific interrogation unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.04.04 Create interrogation implementation report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.04.05 Create or revise interrogation implementation presentation . . . . . . . . . . . . . . . . 804.04.06 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.05 System control implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.05.01 Implement or revise fully supported DBMS facilities . . . . . . . . . . . . . . . . . . . . . 804.05.02 Implement or revise partially supported DBMS facilities . . . . . . . . . . . . . . . . . . 804.05.03 Acquire/implement and/or revise facilities not supported by DBMS . . . . . . . . . 804.05.04 Create utilization scenarios & fully test all facilities . . . . . . . . . . . . . . . . . . . . . . 814.05.05 Create or revise operations documentation & guides . . . . . . . . . . . . . . . . . . . . . 814.05.06 Determine, implement and maintain security and privacy for implementation

phase activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.05.07 Create or revise system control implementation report . . . . . . . . . . . . . . . . . . . . 814.05.08 Create or revise system control implementation presentation . . . . . . . . . . . . . . . 824.05.09 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.06 Develop or revise ancillary supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.06.01 Develop or revise database system training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.06.02 Develop or revise database hotline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.06.03 Develop or revise database standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.06.04 Develop or revise final test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.06.05 Develop or revise database system documentation . . . . . . . . . . . . . . . . . . . . . . . 834.06.05.01 Develop internal database documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.06.05.02 Prepare user manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.06.05.03 Prepare operations documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.06.05.04 Review & finalize all documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.06.06 Prepare ancillary supports implementation report . . . . . . . . . . . . . . . . . . . . . . . . 85


xii


4.06.07 Create or revise ancillary supports presentation . . . . . . . . . . . . . . . . . . . . . . . . . 854.06.09 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.07 Plan and conduct system quality tests (system quality test) . . . . . . . . . . . . . . . . . . . . . . 854.07.01 Create or revise system operation scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.07.02 Create or revise tests to validate scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.07.03 Schedule database system quality test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.07.04 Conduct system quality tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.07.05 Prepare system test report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.07.06 Create system test presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.07.07 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.08 Create implementation phase report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.09 Create implementation phase presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.10 Conduct phase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875 Conversion & Deployment Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01 Form project team, plan phase, and revise project plan . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.01 Select manager for project phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.02 Identify administrative, clerical, and computer supports . . . . . . . . . . . . . . . . . . . 885.01.03 Select project staff for phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.04 Secure commitments for staff availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.05 Create phase plans and schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.06 Organize phase review committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.07 Conduct methods training as required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.08 Set up phase documentation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.09 Revise project plan and schedule estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.01.10 Develop and/or use database standards for phase . . . . . . . . . . . . . . . . . . . . . . . . 885.01.11 Interrogate and maintain metabase system database during phase . . . . . . . . . . . 885.02 Review prior phase for completeness and revise as necessary . . . . . . . . . . . . . . . . . . . . 885.03 Secure, install and test all equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.04 Conduct all training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.04.01 Conduct user training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.04.02 Conduct system maintenance training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.05 Convert all data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.06 Create conversion and deployment report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.07 Create conversion and deployment review presentation . . . . . . . . . . . . . . . . . . . . . . . . . 895.08 Conduct phase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.09 Prepare estimate for production and administration phase . . . . . . . . . . . . . . . . . . . . . . . 895.10 Prepare project production & administration phase funding . . . . . . . . . . . . . . . . . . . . . . 895.11 Present for funding review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896 Production and Administration Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.01 Form project team, plan phase, and revise project plan . . . . . . . . . . . . . . . . . . . . . . . . . . 916.01.01 Select manager for project phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91


xiii


6.01.02 Identify administrative, clerical, and computer supports . . . . . . . . . . . . . . . . . . . 916.01.03 Select project staff for preliminary analysis phase . . . . . . . . . . . . . . . . . . . . . . . 916.01.04 Secure commitments for staff availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.01.05 Create phase plans and schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.01.06 Organize phase review committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.01.07 Conduct methods training as required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.01.08 Set up phase documentation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.01.09 Revise project plan and schedule estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.01.10 Develop and/or use database standards for phase . . . . . . . . . . . . . . . . . . . . . . . . 916.01.11 Interrogate and maintain metabase system database during phase . . . . . . . . . . . 916.02 Database system production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.02.01 Commence database system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.02.02 Conduct ongoing database system production . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.02.03 Develop and maintain views as necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.03 Develop interrogation subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.03.02 Create views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.03.03 Prototype through a natural language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.03.04 Select cost efficient language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.03.05 Implement interrogation subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.03.06 Perform system development test on interrogation subsystem . . . . . . . . . . . . . . 936.03.07 Assess production impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.03.08 Develop interrogation implementation report . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.03.09 Create interrogation implementation presentation . . . . . . . . . . . . . . . . . . . . . . . . 946.03.10 Conduct interrogation review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.04 Application Optimization Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.04.01 Assess physical database performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.04.02 Assess interrogation performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.04.03 Assess system control performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.04.03.01 Assess audit trail performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.04.03.02 Assess performance of backup & recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.04.03.03 Assess performance of message processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.04.03.04 Assess completeness and performance of security & privacy . . . . . . . . . . . . . . . 956.04.03.05 Assess performance of concurrent operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.04.03.06 Assess sophistication of reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.04.03.07 Assess sophistication of multiple database object processing . . . . . . . . . . . . . . . 966.04.03.08 Create system control assessment report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.04.04 Create logical database change requirements to accommodate performance . . . 976.04.05 Create consolidated application performance change requirements report . . . . . 976.04.06 Create assessment to change ancillary support for application performance change

requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97


xiv


6.04.07 Create consolidated application performance change requirements presentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.04.08 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.05 Determine database system maintenance policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.05.01 Select maintenance approach, methods, and tools . . . . . . . . . . . . . . . . . . . . . . . . 986.05.01.01 Determine maintenance approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.05.01.02 Establish maintenance methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.05.01.03 Identify and select maintenance tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.05.01.04 Document selections and formalize findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.05.02 Determine procedures for standard and emergency maintenance . . . . . . . . . . . . 986.05.03 Publish maintenance policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.06 Perform standard system maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.06.01 Identify and assign maintenance problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.06.01.01 Identify maintenance need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.06.01.02 Document maintenance need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.06.01.03 Analyze the maintenance need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.06.01.04 Identify proper person/organization to solve problem . . . . . . . . . . . . . . . . . . . . . 996.06.02 Analyze problem and estimate maintenance effort . . . . . . . . . . . . . . . . . . . . . . . 996.06.02.01 Analyze problem, determine solution and work around . . . . . . . . . . . . . . . . . . 1006.06.02.02 Determine pervasiveness and issue alert as appropriate . . . . . . . . . . . . . . . . . . 1006.06.02.03 Determine alternative of choice and obtain approval . . . . . . . . . . . . . . . . . . . . 1006.06.02.04 Set priority of implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.06.02.05 Notify proponent of schedule of change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.06.03 Accomplish the maintenance change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.06.03.01 Create conceptual specification of change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.06.03.02 Create implementation specification of change . . . . . . . . . . . . . . . . . . . . . . . . . 1016.06.03.03 Implement the change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.06.03.04 Perform system development test on change . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036.06.03.05 Deliver the change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036.06.04 Plan and conduct system quality tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036.06.05 Conduct required training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.06.06 Install change into production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.06.07 Monitor database application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.07 Perform emergency maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.07.01 Document the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.07.02 Verify the problem through independent methods . . . . . . . . . . . . . . . . . . . . . . 1056.07.03 Determine solution to problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.07.04 Acquire approval for change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.07.05 Change run-time modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.07.06 Modify source code and create database object for production library . . . . . . . 1056.07.07 Install change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105


xv


6.07.08 Create standard maintenance change request . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.08 Accomplish database system revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.08.01 Propose database system revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.08.02 Prepare implementation strategy of revision . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.08.03 Implement revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.08.03.01 Implement revised logical database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.08.03.02 Implement revised physical database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.08.03.03 Implement interrogation subsystem revisions . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.08.03.04 Accomplish system control changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.08.03.04.01 Revise fully supported DBMS facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.08.03.04.02 Revise partially supported DBMS facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.08.03.04.03 Revise facilities not supported by DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.08.03.04.04 Revise utilization scenarios & fully test all facilities . . . . . . . . . . . . . . . . . . . . 1086.08.03.04.05 Revise operations documentation & guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.08.03.04.06 Create revised system control implementation report . . . . . . . . . . . . . . . . . . . . 1086.08.03.04.07 Create revised system control implementation presentation . . . . . . . . . . . . . . . 1086.08.03.04.08 Conduct subphase review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.08.04 Revise ancillary supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.08.05 Plan and conduct system quality tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096.08.06 Prepare software release notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096.08.07 Merge revision into production system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106.08.08 Perform enterprise model audit on evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 1106.08.09 Conduct revision review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106.09 Perform enterprise database audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106.09.01 Audit metabase system database components and note discrepancies by

identifying the items's unique identifier and suspected problem . . . . . . . . . . . . 1106.09.02 Audit non-metabase system database data and computer programs . . . . . . . . . 1166.09.03 Audit ancillary support items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.09.04 Formulate audit report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.09.05 Monitor database system operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.09.06 Certify enterprise model audit pass/fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121


xvi



xvii



18

1Preliminary Analysis Phase

1 Preliminary Analysis

1.01 Form project team, plan phase, & estimate project1.01.01 Select manager for project phase1.01.02 Identify administrative, clerical, and computer supports

1.01.03 Select project staff for phase1.01.03.01 Review all job descriptions of staff to match requirements of DB project

methodology1.01.03.02 Interview and select database specialist1.01.03.03 Interview and select functional users

1.01.04 Secure commitments for staff availability1.01.04.01 Estimate time requirement for project manager1.01.04.02 Estimate time requirement for administrative, clerical, and computer supports

1.01.05 Create estimate for project1.01.05.01 Identify possible manager for project1.01.05.02 Identify ideal project staff types and quantities for project1.01.05.03 Identify appropriate WBS for project type1.01.05.04 Review selected WBS to ensure that it has the least number of steps consonant

with maximum quality1.01.05.05 Configure steps into PERT chart1.01.05.06 Identify appropriate metrics, work unit quantities, and work environment factors

for each selected WBS step1.01.05.07 Resource load each step by resource type1.01.05.08 Ensure that project management package has appropriate calendar for project time

period1.01.05.09 Generate CPM and Gantt charts1.01.05.10 Prepare project description for project and generally identify the missions,

business functions, and database objects that are to be addressed1.01.05.11 Review with key users and revise all project estimate components until complete

and acceptable1.01.05.12 Fix project base line for earned value reporting

1.01.06 Create phase and task plans and schedules1.01.06.01 Create phase specific PERT charts1.01.06.02 Create phase specific Gantt charts1.01.06.03 Create phase CPM charts1.01.06.04 Create phase manpower estimate charts

1.01.07 Organize phase review committee1.01.08 Conduct methods training as required


1.01.09 Set up phase documentation files

1.01.10 Create project plan and schedule estimates1.01.10.01 Create PERT charts1.01.10.02 Create Gantt charts1.01.10.03 Create CPM charts1.01.10.04 Create manpower estimate charts

1.01.11 Establish metabase system database1

1.01.11.01 Define tables and relationships1.01.11.02 Create schema and views1.01.11.03 Create update programs and reports1.01.11.04 Establish forms and procedures1.01.11.05 Accomplish initial metadata database loading

1.01.12 Interrogate and maintain metabase system database during phase

1.01.13 Establish effective computing environment, libraries, etc., for resource usagetracking, for storage of data, programs, and run streams for development and unittest, for system test and integration, and for production

1.01.14 Develop and/or use database standards for phase

1.01.15 Identify and allocate management and clerical overhead to phase1.01.15.01 Assess and allocate appropriate management overhead for reviews, supervision to

the phase.1.01.15.02 Assess and allocate appropriate clerical support for various phase activities

1.02 Create initial database project requirements description1.02.01 Request and review documentation of prior related database efforts1.02.02 Record key documents and contents of these documents into the metabase system

database

1.02.03 Obtain initial scoping information for project1.02.02.01 Conduct broad interviews with user management to determine business database

objectives for database project1.02.02.02 Record key documents and contents of these business database objectives into the

metabase system database as documents

1 The metabase system database is a repository product of Whitemarsh Information Systems.Metabase is available either as a standalone PC or PC/server software product or as a designspecification for client development on their own computing environment.


2

Phase 1, Preliminary Analysis

1.02.02.02 Identify, name and briefly describe the involved missions1.02.02.03 Record mission descriptions and hierarchies into the metabase system database1.02.02.04 Identify, name and briefly describe the business resources that are the foundation

of the database objects1.02.02.05 Record business resources and hierarchies into the metabase system database1.02.02.06 Record mission descriptions and hierarchies into the metabase system database1.02.02.07 Identify, name and briefly describe the existing business information systems1.02.02.08 Record business information systems descriptions and hierarchies into the

metabase system database1.02.02.09 Identify, name and briefly describe the critical business events that currently

involve automation assists1.02.02.10 Record business events and hierarchies into the metabase system database1.02.02.11 Identify, name and briefly describe the business functions that must be performed1.02.02.10 Record business functions and hierarchies into the metabase system database1.02.02.12 Identify, name and briefly describe the organizations involved in the enterprise

database effort1.02.02.13 Record business objectives and hierarchies into the metabase system database1.02.02.14 Interrelate missions with organizations and functions.1.02.02.15 Interrelate missions organizations functions with resources.1.02.02.16 Interrelate missions organizations functions with recorded requirements

documents components1.02.02.17 Interrelate missions organizations functions with recorded database objectives

documents components1.02.02.18 Interrelate missions organizations functions with recorded business information

systems1.02.02.19 Interrelate mission-organization-functions, business information systems,

business events with requirements as appropriate

1.02.03 Perform preliminary data analysis1.02.03.01 Identify major suppliers & uses of database data

1.02.03.02 Identify, create, & analyze prototypical data and reports1.02.03.02.01 Identify prototypical data and reports1.02.03.02.02 Create matrix versions of data and reports1.02.03.02.03 Describe significant characteristics of data and reports1.02.03.02.04 Summarize data and reports fundamental orientation towards operational, control,

or MIS1.02.03.02.05 Update metabase system database with information needs analysis information

1.02.03.03 Conduct preliminary data transfer and data conversion interview1.02.03.03.01 Determine the number of systems to be converted


3


1.02.03.03.02 Determine the type of automation for each system1.02.03.03.03 Determine the number of files and file access methods for each system1.02.03.03.04 Determine the file layouts for each file1.02.03.03.05 Update metabase system database with data transfer and data conversion

information within business information system specifications, views, and viewcolumns

1.02.03.03.06 Obtain user concurrence on interview findings

1.02.04 Formulate list of business database objectives that are to be achieved1.02.04.01 Formulate database objectives dealing with the business problem that is to be

solved1.02.04.02 Formulate database objectives dealing with the system to be converted1.02.04.03 Formulate database objectives dealing with the design and development period1.02.04.04 Formulate database objectives dealing with the benefits to be achieved.1.02.04.05 Formulate list of business database objectives that are to be achieved during data

conversion1.02.04.05 Document database objectives as documents, document components and relate

these to mission-organization-functions and record these into the metabase systemdatabase

1.02.05 Formulate reasonable list of mechanisms to evaluate project success1.02.06 Reach consensus on database objectives and evaluation mechanisms1.02.07 Document database objectives and evaluation mechanisms as documents,

document components and relate these to mission-organization-functions andrecord these into the metabase system database

1.03 Create mission description model1.03.01 Create business mission submodel1.03.01.01 Succinctly create business mission in business policy terms1.03.01.01.01 Name mission1.03.01.01.02 Describe mission in business policy terms1.03.01.01.03 Use prototypical source data and reports to assist in definition1.03.01.01.04 Remove any organizational references from missions1.03.01.01.05 Remove any techniques or details that indicate how the mission is accomplished1.03.01.01.06 Review missions to ensure that only the end-result what is described, and that

both who and how has been removed1.03.01.01.07 Review mission description with key users and revise until complete and

acceptable 1.03.01.01.08 Enter mission description into metabase system database

1.03.01.02 Partition business mission into sufficient stand alone subordinate missions


4


1.03.01.02.01 Identify stand alone subordinate missions1.03.01.02.02 Describe subordinate missions in business terms1.03.01.02.03 Use prototypical data and reports to assist in definition1.03.01.02.04 Review subordinate mission with key users and revise until complete and

acceptable 1.03.01.02.05 Repartition subordinate mission descriptions into lower level subordinate mission

descriptions and repeat description until no longer necessary1.03.01.02.06 Enter subordinate missions into metabase system database

1.03.01.03 Create mission description diagram

1.03.02 Create database domain submodel

1.03.02.01 Create database domains1.03.02.01.01 Succinctly describe database domain from subordinate mission descriptions in

business policy terms1.03.02.01.01 Name database domain1.03.02.01.02 Describe database domain in business policy terms1.03.02.01.03 Use prototypical source data and reports to assist in definition1.03.02.01.04 Validate database domain sufficiency by balancing the implied major database

outputs against the major database contents1.03.02.01.05 Review database domain with key users and revise until both non-redundant,

complete, and acceptable 1.03.02.01.06 Relate database domains to missions and enter into metabase system database1.03.02.01.07 Interrelate database domains with requirements as appropriate

1.03.02.02 Partition domains into sufficient stand alone subordinate database domains1.03.02.02.01 Identify stand alone subordinate database subdomains1.03.02.02.02 Describe subordinate database domains in business terms1.03.02.02.03 Use prototypical data and reports to assist in definition1.03.02.02.04 Review database subordinate database subdomains with key users and revise until

complete and acceptable 1.03.02.02.05 Repartition subordinate database subdomains into lower level subordinate

database subdomains and repeat description until no longer necessary1.03.02.02.06 Enter subordinate database domains into metabase system database

1.03.02.03 Create initial database domain diagram for each database subdomain1.03.02.03.01 Identify and define entities in non-redundant fashion1.03.02.03.02 Identify and define obvious relationships among entities1.03.02.03.03 Construct database domain diagrams


5


1.03.02.03.04 Review diagrams, entities, and relationships with users to assess relevance &revise as necessary

1.03.02.04 Merge subordinate database domain diagrams1.03.02.04.01 Select most complex subordinate database domain diagram1.03.02.04.02 Attempt merger of other database domain diagrams1.03.02.04.03 Adjust subordinate database domain entities & relationships until merger is

possible1.03.02.04.04 Review combined database domain diagram for common understanding &

agreement with key users1.03.02.04.05 Finalize database domain diagram

1.03.03 Create database object submodel1.03.03.01 Select entity from database domain diagram as a potential database object1.03.03.02 Create name for potential database object1.03.03.03 Create definition for potential database object1.03.03.04 Determine if multiple database object tables exist for potential database object1.03.03.05 Record as database objects those potential database objects that have multiple

database object tables1.03.03.06 Record as database object tables those potential database objects that do not

contain multiple database object tables1.03.03.07 Record as data elements those potential database objects that are not even

database object tables; rather they describe single business fact1.03.03.08 Review discovered database objects, database object tables and data elements

with users to ensure proper business names and business definitions1.03.03.09 Provide an example for each database object, property class, and data element1.03.03.10 Enter database objects, database object tables and data elements into metabase

system database1.03.03.11 Present defined database objects and review as appropriate1.03.03.12 Create database object diagram1.03.03.13 Create relationships between database objects and database domains and then

enter into metabase system database1.03.03.14 Interrelate database objects with requirements as appropriate

1.03.04 Create high-level business organization submodel1.03.04.01 Succinctly create business organizations in business policy terms1.03.04.01.01 Name business organization1.03.04.01.02 Describe business organization in business policy terms1.03.04.01.03 Use prototypical source data and reports to assist in definition1.03.04.01.04 Remove any mission and functional style indications from business functions1.03.04.01.05 Relate organizations to missions as appropriate into the metabase system database


6


1.03.05 Create high-level business function submodel1.03.05.01 Succinctly create business function in business policy terms1.03.05.01.01 Name business function1.03.05.01.02 Describe business function in business policy terms indicating appropriate

business activities1.03.05.01.03 Use prototypical source data and reports to assist in definition1.03.05.01.04 Remove any organizational style indications from business functions1.03.05.01.05 Identify organizations that perform same high-level description of business

function1.03.05.01.06 Remove any detailed techniques that indicate how the business function is

accomplished1.03.05.01.07 Enter discovered business functions into metabase system database1.03.05.01.08 Enter any newly discovered organizations into metabase system database1.03.05.01.09 Interrelate functions with mission-organizations and enter interrelationships into

metabase system database1.03.05.01.10 Review business functions to ensure that how the business function is kept at a

high-level1.03.05.01.11 Review business function description with key users and revise until complete

and acceptable

1.03.05.02 Partition business function into sufficient stand alone subordinate businessfunctions

1.03.05.02.01 Identify stand alone subordinate business functions1.03.05.02.02 Describe subordinate business functions in business terms1.03.05.02.03 Use prototypical data and reports to assist in definition1.03.05.02.04 Review subordinate business function with key users and revise until complete

and acceptable 1.03.05.02.05 Repartition subordinate business function descriptions into lower level

subordinate business function descriptions and repeat description until no longerhigh-level

1.03.05.03 Enter subordinate business functions into metabase system database

1.03.05.04 Create high-level business function diagram1.03.05.04.01 Identify high-level business functions & define its purpose, scope, etc., in terms

of business activities1.03.05.04.02 Identify the business environment & activities in which business function occurs1.03.05.04.03 Identify organizational responsibility for business function1.03.05.04.04 Identify frequency of business function1.03.05.04.05 Provide an example of each business function flow diagram1.03.05.04.06 If business function contains business functions then repeat only a few levels


7


1.03.05.04.07 Record business function data into metabase system database

1.03.06 Create business and technical terms glossary, and organize in learning order

1.03.07 Create mission model report1.03.07.01 Prepare mission scope and narrative1.03.07.02 Create plan & format for presenting mission descriptions, database domains,

database objects, high level functions and all graphics1.03.07.03 Prepare report for mission description model

1.03.08 Create preliminary analysis presentation1.03.08.01 Review & revise preliminary analysis phase1.03.08.02 Construct features, advantages and benefits (FAB) of database system1.03.08.03 Use FABs to create use scenarios1.03.08.04 Graphically identify entities/processes that participate in scenario1.03.08.05 Create narrative for use scenario1.03.08.06 Identify key individual for use scenario1.03.08.07 Review use scenario & narrative with key individual and modify as appropriate1.03.08.08 Create A/V materials for use scenario presentation1.03.08.09 Review and finalize A/V materials prior to review

1.03.09 Conduct phase review1.03.09.01 Present mission description model1.03.09.02 Receive and respond to comments1.03.09.03 Modify model components as necessary1.03.09.04 Seek concurrence with phase

1.04 Create business information systems plan1.04.01 Create Ross2 resource life cycles1.04.01.01 Identify critical corporate resources1.04.01.02 Create life-cycle for each resource1.04.01.03 Interconnect lifecycles via enablement-precedence vectors1.04.01.04 Review with key users and revise until complete and acceptable

1.04.02 Create relationships between resource life cycle nodes and metabase componentinstances

1.04.02.01 Create relationships between resource life cycle nodes and database objects, andenter into metabase system database

2 Resource Life Cycles were created by Ron Ross. They are described in the book Resource LifeCycle Analysis


8


1.04.02.02 Create relationships between resource life cycle nodes and subordinate missiondescriptions, and enter into metabase system database

1.04.02.03 Create relationships between resource life cycle nodes and subordinate businessfunction descriptions, and enter into metabase system database

1.04.02.04 Create relationships between resource life cycle nodes and existing systems, andenter into metabase system database

1.04.02.05 Create relationships between resource life cycle nodes and existing files anddatabases, and enter into metabase system database

1.04.02.06 Generate appropriate metabase system database reports to clearly display as-isand to-be versus resource life cycle nodes.

1.04.02.07 Review with key users and revise until complete and acceptable1.04.02.08 Interrelate resource life cycle nodes with requirements as appropriate

1.04.03 Propose business information systems projects1.04.03.01 Hypothesize as an operational subject database project all the database objects

associated with a single resource life cycle1.04.03.02 Hypothesize as an operational information systems project all the resource life

cycle nodes associated with a single subordinate mission description1.04.03.03 Reestablish the precedence-enablement vectors at the subordinate mission levels1.04.03.04 Interrelate business information systems with requirements as appropriate

1.04.04 Examine the state of automation for each associated business information system

1.04.04.01 Determine improvements required for logical database1.04.04.01.01 Determine changes to database objects1.04.04.01.02 Determine changes to data elements1.04.04.01.03 Determine changes to tables and columns1.04.04.01.04 Determine changes to data integrity rules1.04.04.01.05 Prepare logical database impact report1.04.04.01.06 Quantify the logical database components required to be added, deleted or

modified1.04.04.01.07 Create logical database impact presentation1.04.04.01.08 Conduct subphase review

1.04.04.02 Determine improvements required for physical database1.04.04.02.01 Determine changes in data distribution model1.04.04.02.02 Determine changes in process distribution model1.04.04.02.03 Determine changes in DBMS1.04.04.02.04 Determine changes in end-user GUI1.04.04.02.05 Quantify the physical database components required to be added, deleted or

modified


9


1.04.04.02.06 Prepare physical database impact report1.04.04.02.07 Create physical database impact presentation1.04.04.02.08 Conduct subphase review

1.04.04.03 Determine improvements required for interrogation1.04.04.03.01 Determine improvements for ad hoc reports1.04.04.03.02 Determine improvements for standard reports1.04.04.03.03 Quantify the interrogation components required to be added, deleted or modified1.04.04.03.04 Prepare interrogation impact report1.04.04.03.05 Create interrogation impact presentation1.04.04.03.06 Conduct subphase review

1.04.04.04 Determine improvements required for system control1.04.04.04.01 Determine changes required for audit trails1.04.04.04.02 Determine impact on backup & recovery needs1.04.04.04.03 Determine impact on concurrent operations1.04.04.04.04 Determine impact on security & privacy1.04.04.04.05 Determine impact on reorganization1.04.04.04.06 Determine impact on multiple databases1.04.04.04.07 Quantify the system control components required to be added, deleted or

modified1.04.04.04.08 Prepare system control impact report1.04.04.04.09 Create system control impact presentation1.04.04.04.10 Conduct subphase review

1.04.04.05 Create system upgrade assessment report for information system

1.04.04.05.01 Create introduction & scope1.04.04.05.01.01 Include mission descriptions1.04.04.05.01.02 Include mission description diagrams1.04.04.05.01.03 Demarcate the intended users1.04.04.05.01.04 Identify the systems being upgraded1.04.04.05.01.05 Review list of business goals, database objectives, & criteria for success

measurement for database system, and revise as necessary1.04.04.05.01.06 Provide a summary of pertinent statistics about database

1.04.04.05.02 Create logical database requirements section1.04.04.05.02.01 Include database domains and database domain diagrams1.04.04.05.02.02 Include final data integrity model (database objects, tables, columns, and

data integrity rules)1.04.04.05.02.03 Create final report of logical database


10


1.04.04.05.03 Create physical database requirements section1.04.04.05.03.01 Include data loading subsystem specifications1.04.04.05.03.02 Include data update subsystem specifications1.04.04.05.03.03 Include database size estimate changes1.04.04.05.03.04 Include data source quality reports1.04.04.05.03.05 Include backup requirements reports1.04.04.05.03.06 Include data integrity subsystem specifications1.04.04.05.03.07 Create final physical database report

1.04.04.04.04 Create business systems environment section1.04.04.05.04.01 Include business event specifications1.04.04.05.04.02 Include business function specifications

1.04.04.05.05 Conduct final review of functional completeness & acceptable interaction oflogical, physical, and business system environment models

1.04.04.05.06 Create interrogation requirements section1.04.04.05.06.01 Include standard report requirements1.04.04.05.06.02 Include ad-hoc report requirements1.04.04.05.06.03 Prepare final consolidated interrogation requirements report

1.04.04.05.07 Prepare system control requirements section1.04.04.05.07.01 Include system control functional requirements1.04.04.05.07.02 Include system control resource requirements1.04.04.05.07.03 Prepare final consolidated system control specification

1.04.04.05.08 Prepare summary of business information system requirements report1.04.04.05.08.01 Prepare summary of logical database including statement of limitations,

audience, etc.1.04.04.05.08.02 Prepare summary of physical database including statement of limitations,

audience, etc.1.04.04.05.08.03 Prepare summary of interrogation including statement of limitations,

audience, etc.1.04.04.05.08.04 Prepare summary of system control including statement of limitations,

audience, etc.1.04.04.05.08.05 Prepare a summary that specifies overall limitations, problem areas, etc.

1.04.04.06 Estimate the resources required to upgrade the business information system1.04.04.06.01 Identify possible manager for business information system upgrade project1.04.04.06.02 Identify ideal project staff types and quantities for business information system

upgrade project


11


1.04.04.06.03 Review selected WBS to ensure that it has the least number of steps consonantwith maximum quality

1.04.04.06.04 Configure steps into a PERT chart that is local to the business information system1.04.04.06.05 Identify appropriate metrics, work unit quantities, and work environment factors

for each selected WBS step1.04.04.06.06 Resource load each step by resource type1.04.04.06.07 Ensure that business information system upgrade project management package

has appropriate calendar for time period1.04.04.06.08 Generate CPM and Gantt charts1.04.04.06.09 Prepare business information system upgrade project description and identify the

missions, business functions, and database objects that are to be addressed1.04.04.06.10 Review with key users and revise all business information system upgrade project

estimate components until complete and acceptable1.04.04.06.11 Fix business information system upgrade project base line for earned value

reporting

1.04.04.07 Prepare consolidated business information system upgrade report for eachbusiness information systems associated with resource life cycle node

1.04.04.07.01 Prepare consolidated summary of logical database including statement oflimitations, audience, etc.

1.04.04.07.02 Prepare consolidated summary of physical database including statement oflimitations, audience, etc.

1.04.04.07.03 Prepare consolidated summary of interrogation including statement of limitations,audience, etc.

1.04.04.07.04 Prepare consolidated summary of system control including statement oflimitations, audience, etc.

1.04.04.07.05 Prepare a consolidated summary that specifies overall limitations, problem areas,etc.

1.04.04.08 Create consolidated high-level estimate for all business information systemsassociated with each resource life cycle node

1.04.04.08.01 Identify possible manager for consolidated project1.04.04.08.02 Adjust, if necessary, project staff types and quantities for consolidated project1.04.04.08.03 Identify overall WBS for consolidated set of projects1.04.04.08.04 Adjust, if necessary, metrics, quantities, and work environment factors for each

selected WBS step1.04.04.08.05 Create overall project PERT, Gantt, and CPM task plans and schedules

1.04.04.09 Create overall business information system upgrade presentation1.04.04.09.01 Modify features, advantages and benefits (FAB) of database system1.04.04.09.02 Include FABs to create database use scenarios


12


1.04.04.09.03 Graphically identify tables or processes that participate in scenario1.04.04.09.04 Create narrative for database use scenario1.04.04.09.05 Identify key individual for database use scenario1.04.04.09.06 Review database use scenario & narrative with key individual and modify as

appropriate1.04.04.09.07 Create A/V materials for database use scenario presentation1.04.04.09.08 Review and finalize A/V materials prior to review

1.04.04.10 Conduct phase review1.04.04.10.01 Present system upgrade specification1.04.04.10.02 Receive and respond to comments1.04.04.10.03 Modify as necessary1.04.04.10.04 Seek concurrence with system phase

1.04.05 Create and load resource life cycle node pert chart1.04.06 Enter the resource life cycle node chart into a project management package as a

PERT chart1.04.07 Enter the PERT chart of the upgrade business information systems as a subproject

for appropriate resource life cycle nodes

1.04.08 Resource load the resource life cycle subproject nodes1.04.08.01 Resource load each node by resource type1.04.08.02 Ensure that resource life cycle upgrade project management package has

appropriate calendar for resource life cycle upgrade project time period1.04.08.03 Generate CPM and Gantt charts for individual subprojects within resource

lifecycle node1.04.08.04 Review with key users and revise business information system plan estimate

components until complete and acceptable

1.04.09 Project management scheduling1.04.09.01 Revise as necessary PERT charts of the overall set of resource life cycles1.04.09.02 Execute the project management algorithms for scheduling1.04.09.03 Create Gantt charts1.04.09.04 Create CPM charts1.04.09.05 Create manpower estimate charts

1.04.10 Publish and review the Information systems plan1.04.10.01 Establish the Information systems plan review committee1.04.10.02 Identify proponents for each resource life cycle node and for each information

system within each resource life cycle node


13


1.04.11 Create business information systems plan presentation1.04.11.01 Modify features, advantages and benefits (FAB) of business information systems

plan1.04.11.02 Include FABs to create business information systems plan use scenarios1.04.11.03 Graphically major tables and/or business information systems that participate in

scenario1.04.11.04 Create narrative for business information systems plan use scenario1.04.11.05 Identify key individual for business information systems plan use scenario1.04.11.06 Review business information systems plan use scenario & narrative with key

individual and modify as appropriate1.04.11.07 Create A/V materials for business information systems plan use scenario

presentation1.04.11.08 Review and finalize A/V materials prior to review

1.04.12 Conduct phase review1.04.12.01 Present resource life cycle node upgrade specification1.04.12.02 Receive and respond to comments1.04.12.03 Modify as necessary1.04.12.04 Seek concurrence for resource life cycle node upgrade plan

1.05 Create preliminary analysis phase report1.05.01 Select project from information systems plan to accomplish1.05.02 Prepare database system scope narrative1.05.03 Create plan & format for presenting mission descriptions, database domains, and

all graphics

1.05.04 Create proposal for conceptual specification phase1.05.04.01 Determine professional staffing requirements1.05.04.02 Determine support staffing requirements1.05.04.03 Determine facilities support requirements1.05.04.04 Determine automation support requirements1.05.04.05 Create Gantt chart for conceptual specification phase1.05.04.06 Create necessary proposal narrative

1.05.05 Prepare final report for preliminary analysis phase

1.06 Create preliminary analysis presentation1.06.01 Review & revise preliminary analysis phase1.06.02 Construct features, advantages and benefits (FAB) of database system1.06.03 Include FABs to create use scenarios1.06.04 Graphically identify entities/processes that participate in scenario


14


1.06.05 Create narrative for use scenario1.06.06 Identify key individual for use scenario1.06.07 Review use scenario & narrative with key individual and modify as appropriate1.06.08 Create A/V materials for use scenario presentation1.06.09 Review and finalize A/V materials prior to review

1.07 Conduct phase review1.07.01 Present preliminary analysis1.07.02 Receive and respond to comments1.07.03 Modify system as necessary1.07.04 Seek concurrence with system phase


15

2

Conceptual Specification Phase

2 Conceptual specification2.01 Form project team, plan phase, and revise project plan2.01.01 Select manager for project phase2.01.02 Identify administrative, clerical, and computer supports

2.01.03 Select project staff for phase2.01.03.01 Interview and select database specialist2.01.03.02 Interview and select functional users


2.01.05 Create phase and task plans and schedules2.01.05.01 Create phase specific PERT charts2.01.05.02 Create phase specific Gantt charts2.01.05.03 Create phase CPM charts2.01.05.04 Create phase manpower estimate charts

2.01.06 Organize phase review committee2.01.07 Conduct methods training as required2.01.08 Set up phase documentation files

2.01.09 Revise project plan and schedule estimates2.01.09.01 Revise PERT charts2.01.09.02 Revise Gantt charts2.01.09.03 Revise CPM charts2.01.09.04 Revise manpower estimate charts

2.01.10 Interrogate and maintain metabase system database2.01.11 Develop and/or use database standards for phase2.01.12 Review & revise preliminary analysis phase as necessary

2.02 Create logical database of business requirements

2.02.01 Perform detailed data analysis2.02.01.01 Identify all sources of data and all types of reports2.02.01.02 Collect descriptions of data from various forms, prior reports, and user interviews

2.02.01.03 Analyze each data source and report2.02.01.03.01 Define general characteristics, i.e., structural, descriptive, or historical

Phase 2, Conceptual Specification

2.02.01.03.02 Determine data criticality to project mission description2.02.01.03.03 Specify the general orientation of the data, i.e., operational, tactical, or strategic2.02.01.03.04 Identify the typical report request mechanism2.02.01.03.05 Determine the expected frequency of usage2.02.01.03.06 Determine the granularity, i.e., operational, summary, projected2.02.01.03.07 Determine data currency requirement, i.e., daily, monthly, quarterly, annual, etc.2.02.01.03.08 Determine data availability, i.e., automated, manual, unknown2.02.01.03.09 Determine data reliability2.02.01.03.10 Enter characteristics into metabase’s report, file or document meta entity types

2.02.01.04 Record report descriptions and characteristics onto report form and enter intometabase system database

2.02.01.05 Construct a data analysis report, and review & revise with users as necessary

2.02.02 Perform detailed data analysis for data transfer and conversion2.02.02.01 Identify affected users, systems and files involved in the data transfer and/or data

conversion process2.02.02.02 Gather data transfer and data conversion file information2.02.02.03 Identify all sources of data and all types of reports2.02.02.04 Obtain a sample of the data and the format for each file2.02.02.05 Collect descriptions of data from prior reports and interviews2.02.02.06 Identify all file element data editing and validations2.02.02.07 Load metabase system database with system file, file element, external view

columns, database view columns, and views to reflect the inventory of files to betransferred or converted.

2.02.02.08 Construct data transfer and data conversion report, and review and revise withusers as necessary

2.02.02.09 Determine the type of conversion best suited for the operating environment2.02.02.10 Prepare a data analysis/data source report2.02.02.11 Prepare detailed conversion plan2.02.02.12 Present data analysis report and detail conversion plan to users

2.02.03 Update project mission descriptions, mission description diagram, databasedomains & construct database domain diagrams

2.02.03.01 Refine mission descriptions2.02.03.02 Refine mission diagrams2.02.03.03 Refine database domain descriptions2.02.03.04 Refine database domain diagrams2.02.03.05 Refine database objects and database object diagrams2.02.03.06 Review and revise metabase system database data as appropriate


17


2.02.04 Define data integrity model

2.02.04.01 Finalize database domain diagram2.02.04.01.01 Select most complex database domain diagram2.02.04.01.02 Attempt merger of other database domain diagrams2.02.04.01.03 Correct rejected diagrams2.02.04.01.04 Review database domain diagram with users for common understanding, &

agreement, and revise as necessary to achieve sufficient simplicity2.02.04.01.05 Review database domain descriptions and diagrams against data analysis report to

insure complete coverage2.02.04.01.06 Iteratively review database domain diagram with users, and revise as necessary

until satisfactory2.02.04.01.07 Finalize database domain diagram section of conceptual specification2.02.04.01.08 Finalize relationships between resource life cycle nodes with requirements

2.02.04.02 Finalize database objects and database object diagram2.02.04.02.01 Select entity from database domain diagram as a potential database object2.02.04.02.02 Create name for potential database object2.02.04.02.03 Create definition for potential database object2.02.04.02.04 Determine if multiple database object tables exist for potential database object2.02.04.02.05 Record as database objects those potential database objects that have multiple

database object tables2.02.04.02.06 Record as database object tables those potential database objects that do not

contain multiple database object tables2.02.04.02.07 Record as data elements those potential database objects that are not even

database object tables; rather they describe single business fact data element2.02.04.02.08 Review discovered database objects, database object tables and data elements

with users to ensure proper business names and business definitions2.02.04.02.09 Provide an example for each database object, database object table, and data

element2.02.04.02.10 Enter database objects, database object tables and data elements into metabase

system database2.02.04.02.11 Present defined database objects and review as appropriate2.02.04.02.12 Create database object diagram2.02.04.02.13 Create relationships between database objects and database domains and then

enter into metabase system database2.02.04.02.14 Finalize relationships between database objects with requirements

2.02.04.03 Create generalized/abstracted/leveled database domain diagrams


18


2.02.04.03.01 Create higher level database domain diagram if combined database domaindiagram is too complex

2.02.04.03.01.01 Identify and name higher level entity groups2.02.04.03.01.02 Identify higher level relationships between entity groups2.02.04.03.01.03 Construct higher level database domain diagram

2.02.04.03.02 Assess level of simplicity achieved2.02.04.03.03 Repeat higher level abstraction process to achieve yet higher levels as necessary

2.02.04.04 Narrow database diagram to project scope2.02.04.04.01 Compare database domain diagram to project goals and identify entities clearly

within project scope to project goals2.02.04.04.02 Identify entities that are components of other automated systems and label as

automated input data sources2.02.04.04.03 Identify remaining entities as undetermined and seek resolution from users and

management2.02.04.04.04 Factor into project scope those entities that are determined by users and

management to be included2.02.04.04.05 Record excluded entities in "outside scope" section of project definition2.02.04.04.06 Create revised database domain diagram that includes only those entities within

project scope2.02.04.04.07 Review and revise database domain diagrams to ensure consistency2.02.04.04.08 Conduct subphase review

2.02.04.05 Update business and technical glossary

2.02.04.06 Specify data elements2.02.04.06.01 Decompose each data source into data elements2.02.04.06.02 Create decomposition algebra for subsequent recreation2.02.04.06.03 Transform derived data into primitive elements2.02.04.06.04 Transform data into best format and maintain transformed algebra2.02.04.06.05 Use installation naming conventions to label data elements2.02.04.06.06 Create appropriate data element value domains2.02.04.06.07 Create definition, content, structure, algebra, etc.2.02.04.06.08 Create data integrity statements for valid values, invalid values, etc.2.02.04.06.09 Provide an example of the kind of data element that would be typified by the data

element name2.02.04.06.10 Define as data elements those entities that did not become database objects, if

appropriate2.02.04.06.11 Assess data element relevance to database domain diagram2.02.04.06.12 Add relevant data elements to metabase system database


19


2.02.04.06.13 Add upper level data element metadata to metabase system database2.02.04.06.13.01 Add data element concepts as necessary2.02.04.06.13.02 Add value domains as appropriate2.02.04.06.13.03 Add conceptual value domains as appropriate2.02.04.06.13.04 Add concepts as appropriate

2.02.04.06.13 Present defined data elements and review as appropriate

2.02.04.07 Create database object table component

2.02.04.07.01 Allocate data elements as columns to database objects2.02.04.07.01.01 Select database object for data element allocation2.02.04.07.01.02 Review database object's database object tables for suggestions of data

elements2.02.04.07.01.03 Select data elements from metabase system database and assign to

database objects as columns for database object tables2.02.04.07.01.04 Identify columns as single valued or multi valued2.02.04.07.01.05 Evaluate database object tables from database objects to determine

suggested data element complete usage2.02.04.07.01.06 Search for additional data elements if database object tables are not

exhausted2.02.04.07.01.07 Modify metabase system database with additionally discovered data

elements2.02.04.07.01.08 Evaluate metabase system database to determine complete usage of all

contained data elements2.02.04.07.01.09 Incorporate additional data elements into metabase system database if they

are justified2.02.04.07.01.10 Adjust database object tables section of database object definition for

addition of newly discovered data elements2.02.04.07.01.11 Assign newly discovered data elements to an database object2.02.04.07.01.12 Create localized column names where appropriate

2.02.04.07.02 Create normalized database object table for each database object2.02.04.07.02.01 Examine columns for similar purpose2.02.04.07.02.02 Assign columns to database object tables of obvious name within database

object2.02.04.07.02.03 Examine database object tables and split them into owner and member

database object tables as required by single or multi-set status ofsubcollections of columns

2.02.04.07.02.04 Identify the set of columns that make up a primary key for each databaseobject table


20


2.02.04.07.02.05 Examine database object tables for commonly employed columns2.02.04.07.02.06 Create a supertype database object table of the commonly employed

columns2.02.04.07.02.07 Examine candidate database object tables for candidate columns that are

used for only subsets of database object table rows2.02.04.07.02.08 Create one or more subtype database object tables for the columns that are

used for only subsets of database object table rows2.02.04.07.02.09 Finalize database object table descriptions2.02.04.07.02.10 Provide an example of the kind of database object table that would be

typified by the database object table name2.02.04.07.02.11 Create instances diagrams for each database object as a vehicle to

illustrate data

2.02.04.07.03 Verify that database object tables are in third normal form2.02.04.07.03.01 Identify database object table primary key2.02.04.07.03.02 Check for multi-set columns, put into new or lower database object tables2.02.04.07.03.03 Check for partial primary-key dependencies, put into new database object

tables2.02.04.07.03.04 Check for nonprimary key column dependencies into new database object

tables2.02.04.07.03.05 Remove columns dependent on columns from other database object tables,

and note the required relationship for later inclusion2.02.04.07.03.06 Reevaluate & correct stated name, function, etc. of database object as it

relates to database object tables, if necessary2.02.04.07.03.07 Collect columns that were discarded for allocation to other database object

tables of database object or to other database object's database objecttables

2.02.04.07.03.08 Revise database object table description2.02.04.07.03.09 Reassemble database object tables2.02.04.07.03.10 Create database object table graphic for each database object

2.02.04.07.04 Create global database object table graphic

2.02.04.07.05 Modify database object tables to allow for historical data2.02.04.07.05.01 Determine periodicity of data change2.02.04.07.05.02 Determine whether history is required2.02.04.07.05.03 Set forth policy if history is kept as data changes, or at specific intervals2.02.04.07.05.04 Specifically enumerate the intervals2.02.04.07.05.05 Specify rules for historical data retention if they change, i.e., daily for a

month, then monthly for a year, then quarterly, etc.


21


2.02.04.07.05.06 Specify algorithms for computing historical summaries, i.e., average, high,low, etc.

2.02.04.07.05.07 Adjust segment descriptions and structures to account for historical data2.02.04.07.05.08 Revise database object table graphics

2.02.04.07.06 Update database object definition2.02.04.07.06.01 Check database object for proper name & purpose2.02.04.07.06.02 Finalize relationships between database objects with requirements2.02.04.07.06.03 Revise example of the database object as necessary2.02.04.07.06.04 Review and revise metabase system database as appropriate2.02.04.07.06.05 Review and revise database object diagram as appropriate

2.02.04.07.07 Verify completeness of database object graphic2.02.04.07.07.01 Review complete database object table graphic against database objects to

verify correctness2.02.04.07.07.02 Create global graphic of all database object tables within database objects2.02.04.07.07.03 Review global database object table graphic against database domain

diagram to verify correctness

2.02.04.08 Specify database object table process component

2.02.04.08.01 Identify data integrity requirements2.02.04.08.01.01 Specify as data integrity rules those inferred though relationship

descriptions contained within and between database objects2.02.04.08.01.02 Specify as data integrity rules intra-database object table column

dependencies2.02.04.08.01.03 Specify as data integrity rules the self contained row conditions that

determine row acceptance into the database2.02.04.08.01.04 Specify as data integrity rules the inter database object table row

conditions that determine whether a dependent database object table isaccepted into the database

2.02.04.08.01.05 Specify as data integrity rules inter-database object table element valueconditional dependencies

2.02.04.08.01.06 Specify as data integrity rules inter-database object table derived datadependencies

2.02.04.08.01.07 Finalize relationships between data integrity rules with requirements

2.02.04.08.02 Identify data integrity requirements for data transfer and data conversion2.02.04.08.02.01 Specify as data integrity rules changes in valid and invalid values for edit

database object tables


22


2.02.04.08.02.02 Specify as data integrity rules changes in range values for edit databaseobject tables

2.02.04.08.02.03 Specify as data integrity rules changes in database object table look-upsfor edit database object tables

2.02.04.08.02.04 Specify as data integrity rules all changes from derived external viewcolumns to atomic database view columns

2.02.04.08.02.05 Specify as data integrity rules all changes from atomic external viewcolumns to derived database view columns

2.02.04.08.02.06 Provide example of the data integrity rule

2.02.04.08.03 Specify all identified data integrity rules with a name & definition, function/role,owner & member database object table, and relational algebra

2.02.04.08.04 Provide an example of the data integrity rule2.02.04.08.05 Record data integrity rule in metabase system database

2.02.04.08.06. Specify all database object table processes2.02.04.08.06.01 Create an add, delete, and modify database object table process for each

database object table2.02.04.08.06.02 Create selection logic to obtain each database object table row2.02.04.08.06.03 Create appropriate messages for different types of database object table

process actions2.02.04.08.06.04 Provide an example of database object table process2.02.04.08.06.05 Record database object table process data into metabase system database

2.02.04.08.07. Specify intra database object referential action database object table processes2.02.04.08.07.01 Identify database object table within a database object2.02.04.08.07.02 Create appropriate referential action add, delete, and modify database

object table process for all database object tables within the databaseobject

2.02.04.08.07.03 Create selection logic to obtain each database object table row2.02.04.08.07.04 Create appropriate messages for different types of database object table

process actions2.02.04.08.07.05 Provide an example of referential action database object table process2.02.04.08.07.06 Record referential action database object table process data into metabase

system database

2.02.04.08.08 Specify inter-database object referential action database object table processes2.02.04.08.08.01 Create database object tables that intersect database objects2.02.04.08.08.02 Identify the preeminent database object owner for the intersectiing data

structure segments


23


2.02.04.08.08.02 Create appropriate referential action add, delete, and modify databaseobject table process for all database object intersection database objecttables

2.02.04.08.08.03 Create selection logic to obtain each database object intersection databaseobject table row

2.02.04.08.08.04 Create appropriate messages for different types of database object tableprocess actions

2.02.04.08.08.05 Provide an example of referential action database object table process2.02.04.08.08.06 Record referential action database object table process data into metabase

system database

2.02.04.08.09 Specify all data integrity rule-based database object table processes2.02.04.08.09.01 Identify appropriate database object table for data integrity rule-based

database object table processes2.02.04.08.09.02 Create appropriate add, delete, and modify database object table processes

to accomplish data integrity rule2.02.04.08.09.03 Create selection logic to obtain each database object table row2.02.04.08.09.04 Create appropriate messages for different types of database object table

process actions2.02.04.08.09.05 Provide an example of data integrity rule-based database object table

process2.02.04.08.09.06 Record data integrity rule-based database object table process data into

metabase system database

2.02.04.08.10 Create specified views for database object table processes2.02.04.08.10.01 Name and describe the specified view2.02.04.08.10.02 Identify appropriate specified view columns from database object table2.02.04.08.10.03 Identify appropriate specified view navigation logic to navigate database

objects2.02.04.08.10.04 Identify appropriate specified view select clauses to obtain database object

table rows2.02.04.08.10.05 Create appropriate messages for different types of view actions2.02.04.08.10.06 Record specified view definition into metabase system database

2.02.04.08.11 Create additional required database object table process model data integrity rules2.02.04.08.11.01 Specify any additional data integrity rules that are inferred though

relationship descriptions contained in database object tables2.02.04.08.11.02 Specify any additional data integrity rules that are intra-database object

table column dependencies


24


2.02.04.08.11.03 Specify any additional data integrity rules that are self contained recordconditions that determine database object table row acceptance into thedatabase

2.02.04.08.11.04 Specify any additional data integrity rules that are inter database objecttable row conditions that determine whether a dependent database objecttable row is accepted into the database

2.02.04.08.11.05 Specify any additional data integrity rules that are inter-database objecttable element value conditional dependencies

2.02.04.08.11.06 Specify any additional data integrity rules that are inter-database objecttable derived data dependencies

2.02.04.08.11.07 Specify all identified data integrity rules with a name & definition,function/role, owner & member database object table , and relationalalgebra

2.02.04.08.11.08 Provide an example of the data integrity rule2.02.04.08.11.09 Record data integrity rule in metabase system database2.02.04.08.11.10 Identify appropriate database object table for data integrity rule-based

primitive database object table processes2.02.04.08.11.11 Create appropriate add, delete, and modify primitive database object table

processes to accomplish data integrity rule2.02.04.08.11.12 Create selection logic to obtain each database object table row2.02.04.08.11.13 Create appropriate messages for different types of database object table

process actions2.02.04.08.11.14 Provide an example of data integrity rule-based primitive database object

table process2.02.04.08.11.15 Record data integrity rule-based primitive database object table process

data into metabase system database

2.02.04.08.12 Validate database object table process model2.02.04.08.12.01 Evaluate each database object table process for clear, unambiguous

meaning2.02.04.08.12.02 Evaluate specified views for appropriate construction2.02.04.08.12.03 Evaluate database object table processes for conflicting updates2.02.04.08.12.04 Evaluate all data integrity rules by information system process to ensure

that no rules are in conflict.

2.02.04.08.13 Create database object table process model deliverable2.02.04.08.13.01 Create database object table process model narrative2.02.04.08.13.02 Finalize all database object table process model information system

process flow diagrams

2.02.04.08.14 Conduct subphase review


25


2.02.04.09 Create database object information system component

2.02.04.09.01 Create detailed database object information system and diagrams2.02.04.09.01.01 Identify each database object information system& define its purpose,

scope, etc., in terms of database object transformation2.02.04.09.01.02 Record each database object information system descriptively and place

appropriately into a database object information system diagram2.02.04.09.01.03 Identify specific subordinate database object information systems that are

included in database object information system2.02.04.09.01.04 Specify rules that governs database object information system success

within database object information system process flow diagram2.02.04.09.01.05 Specify required reactions as a consequence of database object

information systemfailure2.02.04.09.01.06 Provide an example of each database object information system flow

diagram2.02.04.09.01.07 If database object information system contains subordinate database object

information systems then repeat until unnecessary

2.02.04.09.02 Estimate implementation phase efforts for each database object informationsystem

2.02.04.09.03 Create documentation for each database object information system2.02.04.09.03.01 Create database object information system narrative2.02.04.09.03.02 Create summary of design requirements


2.02.04.10 Specify database object state component2.02.04.10.01 Identify appropriate database lifecycle resources2.02.04.10.01.01 For each database life cycle resource2.02.04.10.01.02 Identify the life cycle nodes2.02.04.10.01.03 For each life cycle node2.02.04.10.01.03.01 Identify the database objects that are modified by the life cycle node2.02.04.10.01.03.02 For each identified database object 2.02.04.10.01.03.02.01 Identify the database object tables that must be added/deleted/or

modified to accomplish the business policy of the node2.02.04.10.01.03.02.02 Name the end result of the database object instance transformation

as the database object state2.02.04.10.01.03.02.03 Identify the database object information systems that must be

executed to accomplish the database object transformation


26


2.02.04.10.01.03.02.03 Store the database object state and the algebra for accomplishingthe database object state transformation through database objectinformation systems into the metabase

2.02.04.10.02 Identify the database life resources

2.02.05 Create or modify specified data model as appropriate2.02.05.01 Examine every database object and set of database object tables for generalization2.02.05.02 As necessary, create generalized subject or subordinate subject within specified

data model2.02.05.03 Name, describe, and enter subject within specified data model2.02.05.04 Determine if database object tables already exist as specified data model entities.2.02.05.05 If existing, create relationships between database object table columns and

specified data model entity attributes2.02.05.06 If not existing, create generalized entities from database object tables2.02.05.07 Create attributes within newly created entities2.02.05.08 Create relationship between newly created attributes and database object table

columns2.02.05.09 Create relationship between newly created attributes and data elements2.02.05.010 Create meta category value assignments as appropriate2.02.05.011 Create value domain assignments as appropriate

2.02.06 Create retail data warehouse database design

2.02.06.01 Perform data requirements analysis2.02.06.01.01 Identify types of reports that are to be produced by retail data warehouse2.02.06.01.02 Collect descriptions of data from various forms, prior reports, and user interviews2.02.06.01.03 Analyze each data source and report to uncover the source of data and its required

derivations2.02.06.01.04 Record report descriptions and characteristics onto report form and enter into

metabase system database2.02.06.01.05 Construct a data analysis report, and review & revise with users as necessary

2.02.06.02 Define retail data warehouse data integrity model2.02.06.02.01 Identify database objects from database object diagram that are appropriate for

participation in the retail data warehouse database2.02.06.02.02 Identify/create normalized table structure from each database object appropriate

for retail data warehouse2.02.06.02.03 Finalize retail data warehouse table descriptions2.02.06.02.04 Provide an example of the kind of retail data warehouse table that would be

typified by the table name2.02.06.02.05 Verify that retail data warehouse tables support sufficient history to satisfy reports


27


2.02.06.02.06 Verify that retail data warehouse tables contain sufficient derived data to supportsummary level reports

2.02.06.03 Identify data integrity requirements for data transfer and data conversion2.02.06.03.01 Specify as data integrity rules changes in valid and invalid values for edit tables2.02.06.03.02 Specify as data integrity rules changes in range values for edit tables2.02.06.03.03 Specify as data integrity rules changes in table look-ups for edit tables2.02.06.03.04 Specify as data integrity rules all changes from derived external view columns to

atomic database view columns2.02.06.03.05 Specify as data integrity rules all changes from atomic external view columns to

derived database view columns2.02.06.03.06 Provide example of the data integrity rule2.02.06.03.07 Specify all identified data integrity rules with a name & definition, function/role,

owner & member table, and relational algebra2.02.06.03.08 Provide an example of the data integrity rule2.02.06.03.09 Record data integrity rule in metabase system database

2.02.06.04 Perform analysis to support data transfer and conversion from source databases toretail data warehouse databases

2.02.06.04.01 Gather data transfer and data conversion information such as necessary data valuetransformations and derivations

2.02.06.04.02 Construct data transfer and data conversion report, and review and revise withusers as necessary

2.02.06.04.03 Determine the type of conversion best suited for the operating environment2.02.06.04.04 Prepare a data analysis/data source report2.02.06.04.05 Prepare detailed conversion plan2.02.06.04.06 Present data analysis report and detail conversion plan to users

2.02.06.05 Verify retail data warehouse data integrity model

2.02.06.05.01 Review retail data warehouse tables for well defined quality2.02.06.05.01.01 Examine retail data warehouse table for well defined function2.02.06.05.01.02 Examine row for unique occurrences2.02.06.05.01.03 Evaluate appropriateness of assigned columns2.02.06.05.01.04 Evaluate retail data warehouse table uniqueness2.02.06.05.01.05 Evaluate reliability of element values over all retail data warehouse table

instances2.02.06.05.01.06 Evaluate adequacy of historical and derived data requirements2.02.06.05.01.07 Evaluate overall retail data warehouse table quality

2.02.06.05.02 Review data transfer and conversion components for well defined quality


28


2.02.06.05.02.01 Review system, file, file element, external view column, database viewcolumn, and view for clear, unambiguous definition and name

2.02.06.05.02.02 Review external view column and database view column for correct dataediting and validation clause

2.02.06.05.03 Review data integrity rules for well defined quality2.02.06.05.03.01 Evaluate data integrity rules for clear, unambiguous meaning & function2.02.06.05.03.02 Evaluate data integrity rule relational algebra for unique owner & distinct

member selection2.02.06.05.03.03 Evaluate intersection tables for sufficiency & adequacy

2.02.06.05.04 Review data integrity model for well defined quality2.02.06.05.04.01 Review & revise database domain diagram and relationship annotations2.02.06.05.04.02 Review & revise tables versus elements for clarity and consistency2.02.06.05.04.03 Review & revise tables versus data integrity rules for clarity &

consistency2.02.06.05.04.04 Review & revise elements versus data integrity rules for clarity &

consistency2.02.06.05.04.05 Review and revise table graphic for clarity & consistency

2.02.06.05.05 Review data integrity model against business database objectives andmeasurements of project success to determine if revisions are necessary

2.02.06.06 Create retail data warehouse logical database specification report2.02.06.06.01 Compile database object section2.02.06.06.02 Compile table section2.02.06.06.03 Compile data integrity rule section2.02.06.06.04 Review & revise retail data warehouse logical database section of specifications

2.02.06.07 Create retail data warehouse logical database presentation2.02.06.07.01 Modify features, advantages and benefits (FAB) of database system2.02.06.07.02 Include FABs to create logical database use scenarios2.02.06.07.03 Graphically identify database objects/processes that participate in scenario2.02.06.07.04 Create narrative for logical database use scenario2.02.06.07.05 Identify key individual for logical database use scenario2.02.06.07.06 Review logical database use scenario & narrative with key individual and modify

as appropriate2.02.06.07.07 Create A/V materials for logical database use scenario presentation2.02.06.07.08 Review and finalize A/V materials prior to review

2.02.06.08 Conduct subphase review


29


2.02.06.08.01 Present logical database2.02.06.08.02 Receive and respond to comments2.02.06.08.03 Modify system as necessary2.02.06.08.04 Seek concurrence with system subphase

2.02.06 Create logical database specification report2.02.07.01 Compile mission description section2.02.07.02 Compile database mission description diagram section2.02.07.03 Compile database domain section2.02.07.04 Compile database domain diagram section

2.02.07.04 Compile data integrity model2.02.07.04.01 Compile database object section2.02.07.04.02 Compile data element section2.02.07.04.03 Compile data integrity rule section

2.02.07.05 Review & revise logical database section of conceptual specifications

2.02.08 Create logical database presentation2.02.08.01 Modify features, advantages and benefits (FAB)of database system2.02.08.02 Include FABs to create logical database use scenarios2.02.08.03 Graphically identify database objects/processes that participate in scenario2.02.08.04 Create narrative for logical database use scenario2.02.08.05 Identify key individual for logical database use scenario2.02.08.06 Review logical database use scenario & narrative with key individual and modify

as appropriate2.02.08.07 Create A/V materials for logical database use scenario presentation2.02.08.08 Review and finalize A/V materials prior to review

2.02.09 Conduct subphase review2.02.09.01 Present logical database2.02.09.02 Receive and respond to comments2.02.09.03 Modify system as necessary2.02.09.04 Seek concurrence with system subphase

2.03 Specify physical database of business requirements2.03.01 Specify business information systems model2.03.01.01 Identify business information systems appropriate for subordinate mission

description

2.03.01.02 Create online data update system specification


30


2.03.01.02.01 Create detailed information system processes and diagrams for online data updatesystem

2.03.01.02.01.01 Identify each user-required information system process & define itspurpose, scope, etc., in terms of business activities

2.03.01.02.01.02 Record each information system process descriptively and placeappropriately into a information system process diagram

2.03.01.02.01.03 Review the business environment & activities in which informationsystem process occurs to ensure the information system process'ssufficiency

2.03.01.02.01.04 Identify and record organizational responsibility for information systemprocess

2.03.01.02.01.05 Identify frequency of information system process2.03.01.02.01.06 Identify specific subordinate information system processes that are

included in information system process2.03.01.02.01.07 Specify rules that governs information system process success within

information system process flow diagram2.03.01.02.01.08 Specify required reactions as a consequence of information system process

failure2.03.01.02.01.09 Provide an example of each information system process flow diagram2.03.01.02.01.10 If information system process contains subordinate information system

processes then repeat until unnecessary

2.03.01.02.02 Create screen specification2.03.01.02.02.01 Name, describe, and sketch the screen, and identify the information

system process that invokes the screen2.03.01.02.02.02 Review the screen for simplicity and single-purpose. If complex, then

divide the screen into subordinate single-purpose screens.2.03.01.02.02.03 Identify appropriate screen elements2.03.01.02.02.04 Use where ever possible the list of columns, but if necessary add new

columns element and its new definition to the list of columns2.03.01.02.02.05 Specify the help message that is to be present for each screen element2.03.01.02.02.06 Specify the valid and invalid value data integrity rules for each screen

element2.03.01.02.02.07 Specify the legal and illegal range value data integrity rules for each

screen element2.03.01.02.02.08 Specify the database object table look up data integrity rules for each

screen element2.03.01.02.02.09 Specify which screen elements must be valued for legal entry2.03.01.02.02.10 Identify which screen elements should be protected from update2.03.01.02.02.11 Identify any internal processes that must be accomplished for each screen,

and/or screen element


31


2.03.01.02.02.12 Specify the required function keys and the actions that are to be taken foreach

2.03.01.02.02.13 Identify appropriate specified navigation logic among screens if differentthan that implied by the information system process diagram

2.03.01.02.02.14 Connect all input screens to appropriate external views with informationsystem control logic units

2.03.01.02.02.15 Connect all input screen specified views to appropriate information systemcontrol logic units

2.03.01.02.03 Design file operations2.03.01.02.03.01 Identify file that must be read or written2.03.01.02.03.01 Identify appropriate external view with information system control logic

unit2.03.01.02.03.03 Identify any internal processes that must be accomplished for each file cell

or file record

2.03.01.02.04 Create internal processes2.03.01.02.04.01 Identify and name internal process2.03.01.02.04.02 Describe internal process2.03.01.02.04.03 Create external view with information system control logic unit, or with

screen, or with screen element, or with file operation, or with file cell2.03.01.02.04.04 Create data transformation algorithm2.03.01.02.04.05 Record internal process into metabase system database along with

relationship metadata

2.03.01.02.05 Estimate implementation phase efforts for each online data update subsystem

2.03.01.02.06 Review and and determine effect ion human support subsystems affected by newon-line data update subsystems

2.03.01.02.06.01 Identify each human support subsystem2.03.01.02.06.02 Create process diagram to determine all manual processes2.03.01.02.06.03 Optimize manual processes to take advantage of new tools2.03.01.02.06.04 Identify new training requirements2.03.01.02.06.05 Identify any necessary job description revisions2.03.01.02.06.06 Formulate plan to implement changes to human support subsystems

2.03.01.02.07 Create documentation for each online data update subsystem2.03.01.02.07.01 Create online data update subsystem narrative2.03.01.02.07.02 Create summary of design requirements2.03.01.02.07.03 Finalize relationships between data update subsystem with requirements


32



2.03.01.03 Create batch data update system specification

2.03.01.03.01 Create detailed information system processes and diagrams for batch data updatesystem









processes then repeat until unnecessary2.03.01.03.01.11 Connect all information system processes to appropriate specified views2.03.01.03.01.12 Connect all information system processes specified views to appropriate

database object table processes



or file record


screen, or with screen element, or with file operation, or with file cell


33


2.03.01.03.03.04 Create data transformation algorithm2.03.01.03.03.05 Record internal process into metabase system database along with


2.03.01.03.04 Estimate implementation phase efforts for each batch data update subsystem

2.03.01.03.05 Review and revise human support subsystems affected by new batch data updatesubsystems

2.03.01.03.05.01 Identify each human support subsystem2.03.01.03.05.02 Create process diagram to determine all manual processes2.03.01.03.05.03 Optimize manual processes to take advantage of new tools2.03.01.03.05.04 Identify new training requirements2.03.01.03.05.05 Identify any necessary job description revisions2.03.01.03.05.06 Formulate plan to implement changes to human support subsystems

2.03.01.03.06 Create documentation for each batch data update subsystem2.03.01.03.06.01 Create batch data update subsystem narrative2.03.01.03.06.02 Create summary of batch data update subsystem design requirements2.03.01.03.06.03 Finalize relationships between data update subsystem with requirements


2.03.01.04 Create data loading subsystem specification2.03.01.04.01 Identify, name, and then create information system process diagram for each data

load subsystem that illustrates any load sequence requirements

2.03.01.04.02 Evaluate initial data source quality for each data load subsystem2.03.01.04.02.01 Identify data source for each element2.03.01.04.02.02 Identify source data format2.03.01.04.02.03 Identify difference between database & source data formats, editing, etc.2.03.01.04.02.04 Sample source data to evaluate quality2.03.01.04.02.05 Evaluate differences among multiple sources of same data2.03.01.04.02.06 Devise strategy to resolve data source differences2.03.01.04.02.07 Estimate resources required to bring source data into conformance with

database requirements2.03.01.04.02.08 Prepare source data evaluation report

2.03.01.04.03 Review and revise human support subsystems affected by new data loadsubsystems

2.03.01.04.03.01 Identify each human support subsystem2.03.01.04.03.02 Create information system process diagram to determine all data processes


34


2.03.01.04.03.03 Optimize processes to take advantage of new tools2.03.01.04.03.05 Identify new training requirements2.03.01.04.03.05 Identify any necessary job description revisions2.03.01.04.03.06 Formulate plan to implement changes to human support subsystems

2.03.01.04.04 Create specifications for each load subsystem2.03.01.04.04.01 Identify size & number of records for each database object table 2.03.01.04.04.02 Create a logical record-type loading sequence chart2.03.01.04.04.03 Specify editing & validation for each database object table 2.03.01.04.04.04 Specify inter-record editing & validation2.03.01.04.04.05 Determine error alternatives for all editing and validation2.03.01.04.04.06 Connect all data loading file definitions to appropriate specified views2.03.01.04.04.07 Connect all data loading file specified views to appropriate database

object table processes2.03.01.04.04.08 Estimate implementation phase efforts for each data loading subsystem2.03.01.04.04.09 Determine required backup during database loading2.03.01.04.04.10 Finalize relationships between data load subsystem with requirements

2.03.01.04.05 Create screens2.03.01.04.05.01 Name, describe, and sketch the screen, and identify the information



columns and its new definition to the list of columns2.03.01.04.05.05 Specify the help message that is to be present for each screen element2.03.01.04.05.06 Specify the valid and invalid value Data integrity rules for each screen

element2.03.01.04.05.07 Specify the legal and illegal range value Data integrity rules for each

screen element2.03.01.04.05.08 Specify the database object table look up Data integrity rules for each

screen element2.03.01.04.05.09 Specify which screen elements must be valued for legal entry2.03.01.04.05.10 Identify which screen elements should be protected from update2.03.01.04.05.11 Identify any internal processes that must be accomplished for each screen,

and/or screen element2.03.01.04.05.12 Specify the required function keys and the actions that are to be taken for

each2.03.01.04.05.13 Identify appropriate specified navigation logic among screens if different

than that implied by the information system process diagram


35


2.03.01.04.05.14 Connect all input screens to appropriate external views with informationsystem control logic units

2.03.01.04.05.15 Connect all input screen specified views to appropriate information systemcontrol logic units



or file record




2.03.01.04.08 Estimate implementation phase efforts for overall load subsystem2.03.01.04.09 Prepare documentation for each load subsystem2.03.01.04.10 Conduct subphase review

2.03.01.05 Create specification for each data transfer and data conversion subsystem2.03.01.05.01 Review and revise information system process diagram for each data conversion

subsystem that illustrates any data conversion sequence requirements 2.03.01.05.02 Optimize processes to take advantage of new tools2.03.01.05.03 Identify size and number of records for each database object table 2.03.01.05.04 Create a logical record-type data conversion sequence chart2.03.01.05.05 Specify editing & validation for each database object table 2.03.01.05.06 Specify data integrity rules2.03.01.05.07 Determine error alternatives for all editing and validation2.03.01.05.08 Estimate implementation phase efforts for overall data conversion subsystem2.03.01.05.09 Determine required back-up during database data conversion2.03.01.05.10 Prepare documentation for each data conversion subsystem2.03.01.05.11 Conduct subphase review2.03.01.05.12 Finalize relationships between data transfer and data conversion subsystem with

requirements


36


2.03.01.06 Create enterprise-wide data collection system specification

2.03.01.06.01 Identify corporate forms for which data collection systems are to be created

2.03.01.06.02 Analyze each corporate form and design specific information system to collectdata









processes then repeat until unnecessary

2.03.01.06.03 Create data collection screen specification2.03.01.06.03.01 Name, describe, and sketch the screen, and identify the information



columns and its new definition to the list of columns2.03.01.06.03.05 Specify the help message that is to be present for each screen element2.03.01.06.03.06 Specify the valid and invalid value Data integrity rules for each screen

element2.03.01.06.03.07 Specify the legal and illegal range value Data integrity rules for each

screen element2.03.01.06.03.08 Specify the database object table look up Data integrity rules for each

screen element


37


2.03.01.06.03.09 Specify which screen elements must be valued for legal entry2.03.01.06.03.10 Identify which screen elements should be protected from update2.03.01.06.03.11 Identify any internal processes that must be accomplished for each screen,

and/or screen element2.03.01.06.03.12 Specify the required function keys and the actions that are to be taken for

each2.03.01.06.03.13 Identify appropriate specified navigation logic among screens if different

than that implied by the information system process diagram2.03.01.06.03.14 Connect all input screens to appropriate external views with information

system control logic units2.03.01.06.03.15 Connect all input screen specified views to appropriate information system

control logic units




2.03.01.06.05 Create normalized database object table for each data collection form2.03.01.06.05.01 Examine candidate columns for similar purpose2.03.01.06.05.02 Assign candidate columns to candidate database object tables of obvious

name within data collection form2.03.01.06.05.03 Examine candidate database object tables and split into owner and

member database object tables as required by single or multi-set status ofsubcollections of candidate columns

2.03.01.06.05.04 Identify the set of columns that make up a primary key for each databaseobject table

2.03.01.06.05.05 Examine candidate database object tables for commonly employedcandidate columns

2.03.01.06.05.06 Create a supertype database object table of the commonly employedcandidate columns

2.03.01.06.05.07 Examine candidate database object tables for candidate columns that areused for only subsets of database object table rows

2.03.01.06.05.08 Create one or more subtype database object tables for the candidatecolumns that are used for only subsets of database object table rows

2.03.01.06.05.09 Finalize database object table descriptions


38


2.03.01.06.05.10 Provide an example of the kind of database object table that would betypified by the database object table name

2.03.01.06.06 Estimate implementation phase efforts for each data collection system

2.03.01.06.07 Review and revise human support subsystems affected by new data collectionsystems

2.03.01.06.07.01 Identify each human support subsystem2.03.01.06.07.02 Create process diagram to determine all manual processes2.03.01.06.07.03 Optimize manual processes to take advantage of new data collection

system2.03.01.06.07.04 Identify new training requirements2.03.01.06.07.05 Identify any necessary job description revisions2.03.01.06.07.06 Formulate plan to implement changes to human support subsystems

2.03.01.06.08 Create documentation for each data collection subsystem2.03.01.06.08.01 Create online data collection subsystem narrative2.03.01.06.08.02 Create summary of design requirements

2.03.01.06.09 Conduct subphase review2.03.01.06.10 Finalize relationships between data transfer and data conversion subsystem with

requirements

2.03.02 Create business event model2.03.02.01 Identify and describe business events that are business information system

triggers2.03.02.02 Identify the business information system that are to be performed to adequately

respond to the business event2.03.02.03 Provide an example of each business event2.03.02.04 Record business event and interconnect with business information systems into

metabase system database

2.03.03 Create use case model2.03.03.01 Select high-level business function for detailing into use cases2.03.03.02 Describe use cases in business policy terms2.03.03.03 Identify network relationships among use cases as appropriate2.03.03.04 Identify and describe use case components for pre-conditions2.03.03.05 Identify relationships between use case facts and post-conditions2.03.03.06 Identify and describe use case components for special-conditions2.03.03.07 Identify and describe use case components for use case events2.03.03.08 Identify involved use cases facts


39


2.03.03.09 Identify database column mappings to use case facts2.03.03.10 Identify relationships between use case facts and pre-conditions2.03.03.11 Identify relationships between use case facts and post-conditions2.03.03.12 Identify relationships between use case facts and special-conditions2.03.03.13 Identify relationships between use case facts and use case events2.03.03.14 Identify use case mission-organization-function positions involved in

accomplishment of use case events2.03.03.15 Identify use case business information systems involved in accomplishment of

use case events2.03.03.16 Provide an example of each use case2.03.03.17 Record use cases artifacts into the metabase system database2.03.03.18 Finalize relationships between use cases with requirements

2.03.04 Create Organization Model2.03.04.01 Identify organizations involved in various missions2.03.04.02 Identify subordinate organizations as necessary and enter all organization units

into metabase system database2.03.04.03 Identify the business functions that are performed by the organization2.03.04.04 Identify the role the organization plays with respect to the business function2.03.04.05 Record business function role relationship between organizational units and

business functions2.03.04.06 Identify the quantity of staff hours and quantity of staff required to perform the

identified function2.03.04.07 Finalize relationships between mission-organization-functions with requirements

2.03.05 Estimate database size2.03.05.01 Estimate number of rows per table2.03.05.02 Estimate overhead per table2.03.05.03 Estimate overall database size2.03.05.04 Record database size in conceptual specifications

2.03.06 Evaluate requirements for backup2.03.06.01 Determine media for backup2.03.06.02 Determine method for backup2.03.06.03 Estimate resources to perform backup2.03.06.04 Scope procedures for accomplishing backup2.03.06.05 Estimate elapsed time for backup2.03.06.06 Prepare backup conceptual specification documentation

2.03.07 Specify database integrity subsystem


40


2.03.07.01 Create a information system process diagram that measures database structuralintegrity

2.03.07.02 Name and define each information system process2.03.07.03 Determine the actions that are to be taken when an integrity test is passed2.03.07.04 Determine the actions that are to be taken when an integrity test is failed2.03.07.05 Determine how to compute a measure of database integrity2.03.07.06 Determine what and how to report database integrity failures2.03.07.07 Identify changes required in the logical database to accommodate integrity

subsystem2.03.07.08 Identify changes required in the physical database to accommodate integrity

subsystem2.03.07.09 Create data integrity subsystem views as appropriate2.03.07.10 Connect data integrity subsystem views to appropriate information system

processes, database object table processes, and Data integrity rules2.03.07.11 Create a minispecification for each information system process2.03.07.12 Estimate implementation phase efforts2.03.07.13 Create data integrity subsystem narrative2.03.07.14 Create summary of implementation phase requirements2.03.07.15 Create data integrity conceptual specification documentation2.03.07.16 Conduct subphase review2.03.07.17 Finalize relationships between data integrity subsystem with requirements

2.03.08 Consolidate logical database changes to accommodate physical database

2.03.09 Prepare physical database requirements specification2.03.09.01 Review & revise database data transformation model2.03.09.02 Review & revise each database update subsystem specification2.03.09.03 Review & revise each database loading subsystem specification2.03.09.04 Review & revise database size estimate2.03.09.05 Review & revise source data quality report2.03.09.06 Review & revise backup requirements2.03.09.07 Review & revise data integrity subsystem specification2.03.09.08 Review physical database requirements section against business database

objectives and measurements of project success to determine if revisions arenecessary

2.03.09.09 Compile physical database conceptual specification report

2.03.10 Create physical database presentation2.03.10.01 Modify features, advantages and benefits (FAB) of database system2.03.10.02 Include FABs to create physical database subsystem scenarios2.03.10.03 Graphically identify tables or processes that participate in scenario


41


2.03.10.04 Create narrative for scenario2.03.10.05 Identify key individual for scenario2.03.10.06 Review scenario & narrative with key individual and modify as appropriate2.03.10.07 Create A/V materials for scenario presentation2.03.10.08 Review and finalize A/V materials prior to review

2.03.11 Conduct subphase review2.03.11.01 Present physical database2.03.11.02 Receive and respond to comments2.03.11.03 Modify system as necessary2.03.11.04 Seek concurrence with system subphase

2.04 Analyze interrogation requirements2.04.01 Identify, name and then create information system process diagram for each

specialized report subsystem

2.04.02 Analyze standard report requirements2.04.02.01 Identify generic report formats2.04.02.02 Identify tables, elements & relationships2.04.02.03 Identify table selection & sorting2.04.02.04 Identify database design changes that are necessary to accommodate report2.04.02.05 Determine computations & transformation requirements2.04.02.06 Use useful decomposition algebra previously specified2.04.02.07 Estimate total number of reports2.04.02.08 Estimate total implementation phase efforts2.04.02.09 Estimate total processing2.04.02.10 Allocate processing over monthly cycles2.04.02.11 Validate against data availability matrix2.04.02.12 Create standard report requirements section

2.04.03 Analyze ad-hoc report requirements2.04.03.01 Identify generic report formats2.04.03.02 Identify database tables, elements, & relationships2.04.03.03 Identify selection & sorting2.04.03.04 Identify database design changes that are necessary to accommodate report2.04.03.05 Determine computations & transformation requirements2.04.03.06 Use useful decomposition algebra previously specified2.04.03.07 Estimate life span of ad-hoc reports2.04.03.08 estimate quantity of ad-hoc reports2.04.03.09 Estimate frequency of report execution2.04.03.10 Estimate total processing


42


2.04.03.11 Allocate processing over monthly cycles2.04.03.12 Validate against data availability matrix2.04.03.13 Create ad-hoc report requirements section

2.04.04 Prepare interrogation requirements report2.04.04.01 Review & revise standard reports requirements2.04.04.02 Review & revise ad-hoc report requirements2.04.04.03 Consolidate database design change requirements to accommodate interrogation2.04.04.04 Prepare consolidated interrogation requirements report2.04.04.05 Finalize relationships between data interrogation systems with requirements

2.04.05 Analyze data transfer and data conversion reporting requirements2.04.05.01 Identify generic report formats2.04.05.02 Identify tables, elements and relationships2.04.05.03 Determine computations and transformation requirements2.04.05.04 Estimate total number of reports2.04.05.05 Estimate total implementation phase efforts2.04.05.06 Estimate total processing2.04.05.07 Finalize relationships between data transfer and data conversion reporting

systems with requirements

2.04.06 Create interrogation presentation2.04.06.01 Modify features, advantages and benefits (FAB) of database system2.04.06.02 Include FABs to create interrogation use scenarios2.04.06.03 Graphically identify tables or processes that participate in scenario2.04.06.04 Create narrative for interrogation use scenario2.04.06.05 Identify key individual for interrogation use scenario2.04.06.06 Review interrogation use scenario & narrative with key individual and modify as

appropriate2.04.06.07 Create A/V materials for interrogation use scenario presentation2.04.06.08 Review and finalize A/V materials prior to review

2.04.07 Conduct subphase review2.04.07.01 Present interrogation2.04.07.02 Receive and respond to comments2.04.07.03 Modify system as necessary2.04.07.04 Seek concurrence with system subphase

2.05 Specify system control requirements

2.05.01 Specify audit trail needs


43


2.05.01.01 Identify audit trail needs for change control2.05.01.02 Identify audit trail needs for security tracking2.05.01.03 Identify audit trail needs to satisfy legal requirements2.05.01.04 Identify audit trail content2.05.01.05 Estimate number of audit trail transactions per cycle2.05.01.06 Estimate processing costs per audit transaction2.05.01.07 Identify volume of audit trail transactions2.05.01.08 Determine required audit trail life span2.05.01.09 Identify logical database changes required to support audit trails2.05.01.10 Finalize relationships between system control audit trails with requirements

2.05.02 Specify backup & recovery needs2.05.02.01 Classify report & update operation required currency2.05.02.02 Identify impact of database crash2.05.02.03 Determine resources for recovery2.05.02.04 Prepare backup & recovery requirements2.05.02.05 Determine extra resources for transaction processing2.05.02.06 Determine resources required for recovery2.05.02.07 Prepare backup & recovery requirements report2.05.02.08 Finalize relationships between backup and recovery with requirements

2.05.03 Specify concurrent operations requirements2.05.03.01 Categorize update transactions by cycle2.05.03.02 Determine resource availability diminished by lockout processing2.05.03.03 Categorize report transactions by cycle2.05.03.04 Determine resource availability diminished by report processing2.05.03.05 Reevaluate method of update transaction processing to reduce lockout

requirements2.05.03.06 Prepare concurrent operations report2.05.13.07 Finalize relationships between concurrent operations with requirements

2.05.04 Specify security & privacy requirements2.05.04.01 Identify legal security requirements2.05.04.02 Identify "company" confidential requirements2.05.04.03 Identify personnel data security requirements2.05.04.04 Identify columns and tables required to be held secure2.05.04.05 Create strategy for user access profiles2.05.04.06 Identify requirements for capturing violations2.05.04.07 Instigate policy study for security violations2.05.04.08 Prepare security & privacy requirements report2.05.04.09 Finalize relationships between security and privacy with requirements


44


2.05.05 Specify reorganization requirements2.05.05.01 Determine expected row volume volatility per table2.05.05.02 Identify expected frequency & quantity of element type changes2.05.05.03 Identify expected frequency & quantity of table changes2.05.05.04 Identify expected frequency & quantity of relationship type changes2.05.05.05 Develop scenarios to accomplish database reorganization2.05.05.06 Estimate processing resources & frequency of database reorganization over

annual period2.05.05.07 Prepare reorganization requirements report2.05.05.07 Finalize relationships between reorganization with requirements2.05.06 Specify multiple database requirements2.05.06.01 Identify interrelated databases2.05.06.02 Identify data interconnection2.05.06.03 Identify method of interconnection2.05.06.04 Identify requirement for coordinated update2.05.06.05 Determine method to validate coordinated update2.05.06.06 Identify requirement for multiple database system control facilities2.05.06.07 Prepare multiple database requirement report2.05.06.08 Finalize relationships between multiple database requirements with requirements

2.05.07 Specify data transfer and data conversion backup and recovery needs2.05.07.01 Identify impact of database crash2.05.07.02 Determine resources for recovery

2.05.07 Prepare system control requirement report

2.05.07.01 Consolidate system control functional requirements2.05.07.01.01 Review & revise audit trail requirements2.05.07.01.02 Review & revise backup & recovery needs2.05.07.01.03 Review & revise concurrent operations requirements2.05.07.01.04 Review & revise security & privacy requirements2.05.07.01.05 Review & revise reorganization requirements2.05.07.01.06 Review & revise multiple database report2.05.07.01.07 Prepare consolidated system control requirements report

2.05.07.02 Review system control specification against business database objectives andmeasurements of project success to determine if revisions are necessary

2.05.07.03 Consolidate database changes requirements to accommodate system control

2.05.07.04 Prepare system control report2.05.07.04.01 Review & revise system control requirements report


45


2.05.07.04.02 Review & revise system control resource requirements report2.05.07.04.03 Prepare consolidate system control report for conceptual specification

2.05.08 Create system control presentation2.05.08.01 Modify features, advantages and benefits (FAB) of database system2.05.08.02 Include FABs to create system control use scenarios2.05.08.03 Graphically identify tables or processes that participate in scenario2.05.08.04 Create narrative for system control use scenario2.05.08.05 Identify key individual for system control use scenario2.05.08.06 Review system control use scenario & narrative with key individual and modify

as appropriate2.05.08.07 Create A/V materials for system control use scenario presentation2.05.08.08 Review and finalize A/V materials prior to review

2.05.09 Conduct subphase review2.05.09.01 Present database system components2.05.09.02 Receive and respond to comments2.05.09.03 Modify system as necessary2.05.09.04 Seek concurrence with system subphase

2.06 Validate cross product of data integrity and data transformation models2.06.01 Use data integrity model to functionally validate the completeness of the data

transformation model2.06.02 Use the data transformation model to functionally validate the completeness of

the data integrity model2.06.03 Resolve any functional imbalance between the data integrity model and the data

transformation model

2.07 Create cross-product validation presentation2.07.01 Modify features, advantages and benefits (FAB) of database system2.07.02 Include FABs to create use scenarios2.07.03 Graphically identify tables or processes that participate in scenario2.07.04 Create narrative for use scenario2.07.05 Identify key individual for use scenario2.07.06 Review use scenario & narrative with key individual and modify as appropriate2.07.07 Create A/V materials for use scenario presentation2.07.08 Review and finalize A/V materials prior to review

2.08 Conduct subphase review2.08.01 Present cross-product validation2.08.02 Receive and respond to comments


46


2.08.03 Modify system as necessary2.08.04 Seek concurrence with system subphase

2.09 Validate through prototyping

2.09.01 Select appropriate DBMS2.09.01.01 Determine most functional & flexible schema-DDL creation & submission

language2.09.01.02 Determine most functional & flexible of sub-schema DDL submission language2.09.01.03 Determine most functional & flexible table data loading utility2.09.01.04 Determine most flexible relationship specification & interrogation language2.09.01.05 Determine most functional & flexible data update transaction utility2.09.01.06 Determine most functional & flexible backup, recovery & logical database

reorganization language2.09.01.07 Select the DBMS which maximizes required features

2.09.02 Create logical database

2.09.02.01 Divide database into appropriate partitions2.09.02.01.01 Review database for 6-10 table partitions2.09.02.01.02 Create database graphic for each partition2.09.02.01.03 Identify value-based relationships for tables within each partition2.09.02.01.04 Select most significant elements for each table2.09.02.01.05 Select table primary key & appropriate secondary keys2.09.02.01.06 Determine necessary columns, data types & editing clauses2.09.02.01.07 Create prototype partitions report

2.09.02.02 Create implemented data model DDL for each prototype2.09.02.02.01 Create implemented data model schema level DDL2.09.02.02.02 Create implemented data model table DDL2.09.02.02.03 Create implemented data model table column DDL2.09.02.02.04 Create implemented data model relationship DDL2.09.02.02.05 Create implemented data model editing & validation clauses2.09.02.02.06 Create implemented data model view DDL for data editing2.09.02.02.07 Create implemented data model view for update transactions2.09.02.02.08 Create implemented data model view for report transactions

2.09.02.03 Submit implemented data model DDL to DBMS to create logical database2.09.02.03.01 Code implemented data model schema DDL into file2.09.02.03.02 Code implemented data model view DDL into file2.09.02.03.03 Submit to DBMS


47


2.09.02.03.04 Correct as necessary

2.09.03 Create test data2.09.03.01 Create table data coding form2.09.03.02 Identify strategy to create realistic test data2.09.03.03 Create statistically significant test data for each table2.09.03.04 Create test data collections appropriate for each prototype2.09.03.05 Enter test data onto files2.09.03.06 Prepare test data report

2.09.04 Create physical database2.09.04.01 Create data loading program2.09.04.02 Allocate computer space for data2.09.04.03 Execute load program to load test data2.09.04.04 Validate volume & correctness of loaded data

2.09.05 Create interrogation scenarios2.09.05.01 Identify prototype demonstration audiences2.09.05.02 For each audience determine prototype demonstration needs2.09.05.03 Create typical reports in end user language2.09.05.04 Create update transactions in end-user language2.09.05.05 Test user demonstrations to build complete scripts2.09.05.06 Create user documentation & demonstration handouts

2.09.06 Present design iteration2.09.06.01 Establish schedule for prototype demonstrations2.09.06.02 Issue preparatory material to participants2.09.06.03 Initiate demonstration through presentation of goals & database objectives of

database system2.09.06.04 Conduct formal component of demonstration2.09.06.05 Conduct ad hoc component of demonstration

2.09.06.06 Solicit applicability to user needs2.09.06.06.01 Document required tables2.09.06.06.02 Document required columns2.09.06.06.03 Document required relationships

2.09.06.07 Prepare demonstration report

2.09.07 Create design iteration changes2.09.07.01 Evaluate change requirements


48


2.09.07.02 Determine effect on fundamental logical database model2.09.07.03 Determine whether extent of changes are unique or common2.09.07.04 Determine effect on other users if changes are made2.09.07.05 Reevaluate whether participant database domains have enough commonality for

single database2.09.07.06 Formulate design changes2.09.07.07 Formulate report to justify database redesign2.09.07.08 Prepare a report indicating incorrect database domain identification

2.09.08 Update database specification design2.09.08.01 Review & revise logical database specification2.09.08.02 Review & revise physical database specification2.09.08.03 Review & revise interrogation specification2.09.08.04 Prepare database design change report

2.09.09 Walkthrough all components of the data transfer and data conversion2.09.09.01 Create test data2.09.09.02 Create physical database2.09.09.03 Create interrogation scenarios2.09.09.04 Present design iteration2.09.09.05 Prepare demonstration report

2.10 Consolidate logical database changes required to accommodate physical databaseinterrogation, and system control additional requirements, and revise as necessary

2.11 Create conceptual specification phase report

2.11.01 Create introduction & scope2.11.01.01 Include mission descriptions2.11.01.02 Include mission description diagrams2.11.01.03 Demarcate the intended users2.11.01.04 Identify the systems being replaced2.11.01.05 Review list of business goals, database objectives, & criteria for success

measurement for database system, and revise as necessary2.11.01.06 Provide a summary of pertinent statistics about database

2.11.02 Create logical database requirements section2.11.02.01 Include database domains and database domain diagrams2.11.02.02 Include final data integrity model2.11.02.03 Create final report of logical database


49


2.11.03 Create physical database requirements section2.11.03.01 Include data transformation model2.11.03.02 Include data loading subsystem specifications2.11.03.03 Include data update subsystem specifications2.11.03.04 Include business event specifications2.11.03.05 Include business function specifications2.11.03.06 Include database size estimate2.11.03.07 Include data source quality reports2.11.03.08 Include backup requirements reports2.11.03.09 Include data integrity subsystem specifications2.11.03.10 Create final physical database report

2.11.04 Conduct final review of functional completeness & acceptable interaction of dataintegrity model and data transformation model.

2.11.05 Create interrogation requirements section2.11.05.01 Include standard report requirements2.11.05.02 Include ad-hoc report requirements2.11.05.03 Prepare final consolidated interrogation requirements report

2.11.06 Prepare system control requirements section2.11.06.01 Include system control functional requirements2.11.06.02 Include system control resource requirements2.11.06.03 Prepare final consolidated system control specification

2.11.07 Prepare conceptual specification phase report2.11.07.01 Prepare summary of logical database including statement of limitations, audience,

etc.2.11.07.02 Prepare summary of physical database including statement of limitations,

audience, etc.2.11.07.03 Prepare summary of interrogation including statement of limitations, audience,

etc.2.11.07.04 Prepare summary of system control including statement of limitations, audience,

etc.2.11.07.05 Prepare a summary that specifies overall limitations, problem areas, etc.

2.12 Create conceptual specification phase presentation2.12.01 Modify features, advantages and benefits (FAB) of database system2.12.02 Include FABs to create database use scenarios2.12.03 Graphically identify tables or processes that participate in scenario2.12.04 Create narrative for database use scenario


50


2.12.05 Identify key individual for database use scenario2.12.06 Review database use scenario & narrative with key individual and modify as

appropriate2.12.07 Create A/V materials for database use scenario presentation2.12.08 Review and finalize A/V materials prior to review

2.13 Conduct phase review2.13.01 Present conceptual specification2.13.02 Receive and respond to comments2.13.03 Modify system as necessary2.13.04 Seek concurrence with system phase


51



52

3

Binding Phase

3 Binding

3.01 Form project team, plan phase, and revise project plan3.01.01 Select manager for project phase3.01.02 Identify administrative, clerical, and computer supports



3.01.05 Create phase plans and schedules3.01.05.01 Create phase specific PERT charts3.01.05.02 Create phase specific Gantt charts3.01.05.03 Create phase CPM charts3.01.05.04 Create phase manpower estimate charts



3.01.10 Develop and/or use database standards for phase3.01.11 Interrogate and maintain metabase system database during phase

3.02 Review conceptual specification phase for completeness and revise as necessary3.03 Remedy any data availability and quality problems determined during conceptual

specification phase

3.04 Determine Impact on Corporate Business Model3.04.01 Evaluate tables that are boundary to outside systems and revise as necessary to

maximize compatibility

3.04.02 Determine impact on logical database3.04.02.01 Determine impact on mission descriptions


3.04.02.02 Determine impact on mission description diagrams3.04.02.03 Determine impact on database domains3.04.02.04 Determine impact on database domain diagram3.04.02.05 Determine impact on business and technical glossary

3.04.02.06 Determine impact on data integrity model3.04.02.06.01 Determine impact on database objects3.04.02.06.02 Determine impact on data elements3.04.02.06.03 Determine impact on data integrity rules

3.04.02.07 Create logical database impact report3.04.02.08 Create logical database presentation3.04.02.09 Conduct subphase review

3.04.03 Determine impact on physical database specification

3.04.03.01 Determine impact on data transformation model3.04.03.01.01 Determine impact on primitive data transformations3.04.03.01.02 Determine impact on information system process diagram3.04.03.01.03 Create data transformation model impact report3.04.03.01.04 Conduct subphase review

3.04.03.02 Determine impact on existing data update subsystems3.04.03.02.01 Analyze impacted data update subsystems3.04.03.02.02 Analyze impacted data input formats3.04.03.02.03 Determine impact on human support subsystems3.04.03.02.04 Determine impact on documentation3.04.03.02.05 Create data update subsystem impact report3.04.03.02.06 Conduct subphase review

3.04.03.03 Determine impact on existing data loading subsystems3.04.03.03.01 Analyze impacted data load subsystems3.04.03.03.02 Analyze impacted data input formats3.04.03.03.03 Determine impact on human support subsystems3.04.03.03.04 Determine impact on documentation3.04.03.03.05 Create data update subsystem impact report3.04.03.03.06 Conduct subphase review

3.04.03.04 Determine impact on database size3.04.03.05 Determine impact on requirements for backup3.04.03.06 Determine impact on database integrity subsystem


54

Phase 3, Binding Phase

3.04.03.07 Prepare physical database requirement report3.04.03.08 Create physical database impact presentation3.04.03.09 Conduct subphase review

3.04.04 Determine impact on interrogation subsystems3.04.04.01 Analyze impact on standard report requirements3.04.04.02 Analyze impact on ad-hoc report requirements3.04.04.03 Prepare interrogation impact report3.04.04.04 Create interrogation impact presentation3.04.04.05 Conduct subphase review

3.04.05 Determine impact on system control facilities3.04.05.01 Determine impact on audit trails3.04.05.02 Determine impact on backup & recovery needs3.04.05.03 Determine impact on concurrent operations3.04.05.04 Determine impact on security & privacy3.04.05.05 Determine impact on reorganization3.04.05.06 Determine impact on multiple databases3.04.05.07 Prepare system control impact report3.04.05.08 Create system control impact presentation3.04.05.09 Conduct subphase review

3.04.06 Determine impact on ancillary supports3.04.06.01 Determine impact on database training3.04.06.02 Determine impact on database hotline3.04.06.03 Determine impact on database standards3.04.06.04 Determine impact on test data3.04.06.05 Determine impact on documentation3.04.06.06 Prepare ancillary supports impact report3.04.06.07 Create ancillary supports impact presentation3.04.06.08 Conduct subphase review

3.04.07 Determine impact on database system quality tests3.04.07.01 Analyze appropriate system quality tests3.04.07.02 Determine impact on testing scenarios3.04.07.03 Determine impact on backup and recovery procedures3.04.07.04 Determine impact on system performance and test success criteria3.04.07.05 Determine impact on required operations, procedures, and guides that are to be

evaluated3.04.07.06 Determine impact on existing system quality test plan3.04.07.07 Prepare system quality test impact report


55


3.04.07.08 Create system quality test impact presentation3.04.07.09 Conduct subphase review

3.04.08 Formulate corporate business model impact report3.04.08.01 Create logical database impact section3.04.08.02 Create physical database impact section3.04.08.03 Create interrogation impact section3.04.08.04 Create system control section3.04.08.05 Create ancillary supports impact section3.04.08.06 Create system quality test impact section

3.05 Evaluate, select and/or procure DBMS packages

3.05.01 Determine whether database application requires static relationship datastructures

3.05.01.01 Estimate expected frequency of prototype revisions throughout life of database3.05.01.02 Determine whether relationship changes are isolated to few parts of the database

or are wide spread3.05.01.03 If wide spread, categorize database as requiring only dynamic relationship data

structures3.05.01.04 If well defined and few, categorize database as best suited to multiple static

relationship data structures3.05.01.05 If few or not at all, categorize database as best suited to only static relationship

data structures3.05.01.06 Choose DBMS that minimizes discrepancies between conceptual specification

requirements & DBMS functions available

3.05.02 Create requirements document3.05.02.01 Define logical database requirements as specified in conceptual specification3.05.02.02 Define physical database requirements as specified in conceptual specification3.05.02.03 Define interrogation requirements as specified in conceptual specification3.05.02.04 Define system control requirements as specified in conceptual specification

3.05.03 Create DBMS requirements document presentation3.05.03.01 Modify features, advantages and benefits (FAB) of database system3.05.03.02 Include FABs to illustrate DBMS requirements3.05.03.03 Graphically identify database objects/processes that participate in illustrated

requirement3.05.03.04 Create narrative for DBMS requirements3.05.03.05 Identify key individual for review of DBMS requirements


56


3.05.03.06 Review DBMS requirements & narrative with key individual and modify asappropriate

3.05.03.07 Create A/V materials for DBMS requirements presentation3.05.03.08 Review and finalize A/V materials prior to review

3.05.04 Conduct subphase review3.05.04.01 Present DBMS requirements3.05.04.02 Receive and respond to comments3.05.04.03 Modify system as necessary3.05.04.04 Seek concurrence with system subphase

3.05.05 Issue RFP and select DBMS3.05.05.01 Create a complete example for vendor illustrated responses3.05.05.02 Issue requirements specification and receive responses3.05.05.03 Conduct oral presentations as necessary3.05.05.04 Secure written commitments for all undocumented and upcoming features3.05.05.05 Evaluate candidates against standard3.05.05.06 Evaluate candidates against each other3.05.05.07 Evaluate cost differential between systems in terms of cost avoidance in

application development3.05.05.08 Benchmark selected system

3.05.06 Formulate DBMS selection report and presentation3.05.06.01 Modify features, advantages and benefits (FAB) of database system3.05.06.02 Include FABs to support DBMS selection3.05.06.03 Create narrative for DBMS selection3.05.06.04 Identify key individual for review of DBMS selection3.05.06.05 Review DBMS selection narrative with key individual and modify as appropriate3.05.06.06 Create A/V materials for DBMS selection presentation3.05.06.07 Review and finalize A/V materials prior to review

3.05.07 Conduct subphase review3.05.07.01 Present DBMS selection decision3.05.07.02 Receive and respond to comments3.05.07.03 Modify selection as necessary3.05.07.04 Seek concurrence with DBMS selection subphase

3.05.08 Install package3.05.09 Conduct DBMS training

3.05.10 Determine DBMS performance characteristics


57


3.05.10.01 Develop prototypical implemented data model design3.05.10.02 Develop prototypical implemented data model DDL and submit to DBMS3.05.10.03 Develop prototypical data loading programs3.05.10.04 Develop prototypical data update programs3.05.10.05 Develop prototypical interrogation modules in HLI and NL3.05.10.06 Develop statistically valid distributions of sample data

3.05.10.07 Assess DBMS system control capabilities

3.05.10.07.01 Assess audit trail capabilities3.05.10.07.01.01 Assess acceptability at audit trail record content3.05.10.07.01.02 Assess acceptability of capture capability from all update sources &

modes3.05.10.07.01.03 Assess acceptability of audit trail reports3.05.10.07.01.04 Assess acceptability of audit trail logical transactions within a multiple

user environment3.05.10.07.01.05 Assess acceptability of audit trail transactions within a multiple database

environment3.05.10.07.01.06 Assess audit trail backup & recovery3.05.10.07.01.07 Assess audit trail capability to reorganize its record content3.05.10.07.01.08 Assess impact on data loading transactions3.05.10.07.01.09 Assess impact on data update transactions3.05.10.07.01.10 Assess impact on interrogation transactions3.05.10.07.01.11 Prepare audit trail acceptability report

3.05.10.07.02 Assess backup & recovery capability3.05.10.07.02.01 Assess the acceptability of basic design3.05.10.07.02.02 Assess the adequacy of backup & recovery for batch type jobs3.05.10.07.02.03 Assess the adequacy of backup & recovery for on-line update3.05.10.07.02.04 Assess the adequacy of backup & recovery for logical transactions on

multiple databases3.05.10.07.02.05 Assess the adequacy of backup & recovery for high volume multi-user

update in batch & on-line3.05.10.07.02.06 Assess the adequacy of backup & recovery for the backup & recovery

capabilities3.05.10.07.02.07 Assess the impact on data loading transactions3.05.10.07.02.08 Assess the impact on data update transactions3.05.10.07.02.09 Prepare backup & recovery acceptability report

3.05.10.07.03 Assess message processing capabilities3.05.10.07.03.01 Examine messages to determine their understandability


58


3.05.10.07.03.02 Determine whether message types can automatically trigger DBA createdmessages

3.05.10.07.03.03 Determine whether source & user identity of certain messages can belogged

3.05.10.07.03.04 Determine whether message content can be changed or augmented3.05.10.07.03.05 Determine whether error processing can be enabled & disabled for certain

run units3.05.10.07.03.06 Determine impact on data update transactions3.05.10.07.03.07 Determine impact on data loading transactions3.05.10.07.03.08 Determine impact on interrogation transactions3.05.10.07.03.09 Prepare messages acceptability report

3.05.10.07.04 Assess security & privacy capabilities3.05.10.07.04.01 Examine DBMS mechanism to establish & maintain security & privacy to

determine ease-of-use3.05.10.07.04.02 Determine the DBMS ability to protect security & privacy from O/S

utility tampering3.05.10.07.04.03 Determine security & privacy ability to protect row, column &

relationship3.05.10.07.04.04 Determine security & privacy ability to protection the basis of values,

conditions, etc.3.05.10.07.04.05 Determine security & privacy ability to meet specific needs stated in the

conceptual specifications3.05.10.07.04.06 Determine impact on data update transactions3.05.10.07.04.07 Determine impact on data loading transactions3.05.10.07.04.08 Determine impact on interrogation transactions3.05.10.07.04.09 Prepare security & privacy acceptability report

3.05.10.07.05 Assess concurrent operations capabilities3.05.10.07.05.01 Assess DBMS capabilities to perform multiple update commands within

all languages3.05.10.07.05.02 Assess DBMS capabilities to perform multiple updates to the same

database3.05.10.07.05.03 Assess DBMS capability to perform multiple updates to the same row3.05.10.07.05.04 Assess DBMS resources that are consumed to effect various concurrent

access controls3.05.10.07.05.05 Determine impact on production operations3.05.10.07.05.06 Prepare concurrent operations acceptability report

3.05.10.07.06 Assess reorganization capabilities


59


3.05.10.07.06.01 Assess DBMS capabilities to logically restructure a table to delete, modifyor add elements

3.05.10.07.06.02 Assess DBMS capabilities to physically resequence rows within a table3.05.10.07.06.03 Assess DBMS capability to resize storage structure components without

database reloading3.05.10.07.06.04 Assess DBMS capability to add, change, or modify inter-table

relationships3.05.10.07.06.05 Assess DBMS reorganization impact on production applications3.05.10.07.06.06 Prepare reorganization capability report

3.05.10.07.07 Assess multiple database object processing capabilities3.05.10.07.07.01 Assess capability to operate multiple databases within one DBMS copy3.05.10.07.07.02 Assess capability to operate multiple databases from various DBMS

languages3.05.10.07.07.03 Assess capability to operate database editions from DBMS languages3.05.10.07.07.04 Assess capability for multiple database update transaction audit trail logs3.05.10.07.07.05 Assess capability for multiple database backup &recovery & other system

control facilities3.05.10.07.07.06 Assess impact on production operations3.05.10.07.07.07 Prepare reorganization capabilities report

3.05.10.07.08 Create DBMS system control capability assessment presentation3.05.10.07.08.01 Modify features, advantages and benefits (FAB)of database system3.05.10.07.08.02 Include FABs to create system control capability impact scenarios3.05.10.07.08.03 Create narrative for system control capability impact scenario3.05.10.07.08.04 Identify key individual for review of system control capability impact

scenario3.05.10.07.08.05 Review system control capability impact scenario & narrative with key

individual and modify as appropriate 3.05.10.07.08.06 Create A/V materials for system control capability impact scenario

presentation3.05.10.07.08.07 Review and finalize A/V materials prior to review

3.05.10.07.09 Conduct subphase review3.05.10.07.09.01 Present system control capability assessment3.05.10.07.09.02 Receive and respond to comments3.05.10.07.09.03 Modify system as necessary3.05.10.07.09.04 Seek concurrence with system subphase

3.05.10.08 Run various tests at different loads, velocities,etc.3.05.10.09 Develop graphs and tables to assist in database design and language selection


60


3.05.10.10 Create DBMS performance report3.05 10.10.01 Construct prototypical database designs section3.05.10.10.02 Construct prototypical implemented data model DDL section3.05.10.10.03 Construct prototypical data loading program section3.05.10.10.04 Construct prototypical data update program section3.05.10.10.05 Construct prototypical interrogation section3.05.10.10.06 Construct system control assessment section3.05.10.10.07 Construct performance statistics section

3.05.10.11 Create DBMS performance presentation3.05.10.11.01 Modify features, advantages and benefits (FAB) of database system3.05.10.11.02 Include FABs to create DBMS use scenarios3.05.10.11.03 Graphically identify tables or processes that participate in scenario3.05.10.11.04 Create narrative for use scenario3.05.10.11.05 Identify key individual for use scenario3.05.10.11.06 Review use scenario & narrative with key individual and modify as appropriate3.05.10.11.07 Create A/V materials for use scenario presentation3.05.10.11.08 Review and finalize A/V materials prior to review

3.05.10.12 Conduct subphase review3.05.10.12.01 Present DBMS performance assessment results3.05.10.12.02 Receive and respond to comments3.05.10.12.03 Modify as necessary3.05.10.12.04 Seek concurrence with subphase

3.05.11 Develop hints and tidbits section for documentation3.05.12 Create a mapping from DBMS taxonomy to DBMS documentation3.05.13 Develop generic examples for all database application functions3.05.14 Adjust programming effort estimates for programming assists provided by natural

languages

3.06 Evaluate, select and/or procure metabase system database packages

3.06.01 Create metabase system database requirements document3.06.01.01 Define logical database requirements for graphics and analytics3.06.01.02 Define physical database requirements to support data loading, update, and

maintenance3.06.01.03 Define interrogation requirements to support needed methodology product

presentations


61


3.06.01.04 Define system control requirements to support the needs of any sophisticateddatabase application

3.06.02 Create metabase system database requirements document presentation3.06.02.01 Modify features, advantages and benefits (FAB) of database system3.06.02.02 Include FABs to illustrate metabase system database requirements3.06.02.03 Graphically identify database objects/processes that participate in illustrated

requirement3.06.02.04 Create narrative for metabase system database requirements3.06.02.05 Identify key individual for review of metabase system database requirements3.06.02.06 Review metabase system database requirements & narrative with key individual

and modify as appropriate3.06.02.07 Create A/V materials for metabase system database requirements presentation3.06.02.08 Review and finalize A/V materials prior to review

3.06.03 Conduct subphase review3.06.03.01 Present metabase system database requirements3.06.03.02 Receive and respond to comments3.06.03.03 Modify system as necessary3.06.03.04 Seek concurrence with system subphase

3.06.04 Issue RFP and select metabase system database3.06.04.01 Create a complete example for vendor illustrated responses3.06.04.02 Issue requirements specification and receive responses3.06.04.03 Conduct oral presentations as necessary3.06.04.04 Secure written commitments for all undocumented and upcoming features3.06.04.05 Evaluate candidates against requirements3.06.04.06 Evaluate candidates against each other3.06.04.07 Evaluate cost differential between metabase system database systems in terms of

cost avoidance in application development

3.06.05 Formulate metabase system database selection report and presentation3.06.05.01 Modify features, advantages and benefits (FAB) of database system3.06.05.02 Include FABs to support metabase system database selection3.06.05.03 Create narrative for metabase system database selection3.06.05.04 Identify key individual for review of metabase system database selection3.06.05.05 Review metabase system database selection narrative with key individual and

modify as appropriate3.06.05.06 Create A/V materials for metabase system database selection presentation3.06.05.07 Review and finalize A/V materials prior to review


62


3.06.06 Conduct subphase review3.06.06.01 Present metabase system database selection decision3.06.06.02 Receive and respond to comments3.06.06.03 Modify selection as necessary3.06.06.04 Seek concurrence with metabase system database selection subphase

3.06.07 Install metabase system database package3.06.08 Conduct metabase system database training

3.06.09 Accomplish metabase system database prototype implementation3.06.09.01 Accomplish logical database development or modifications to accomodate

metabase system database requirements3.06.09.02 Accomplish physical database development or modifications to accomodate

metabase system database requirements3.06.09.03 Accomplish interrogation development or modifications to accomodate metabase

system database requirements3.06.09.04 Accomplish system control development or modifications to accomodate

metabase system database requirements

3.06.10 Conduct metabase system database prototype demonstion3.06.10.01 Conduct and assess demonstration of metabase system database capabilities

versus logical database requirements3.06.10.02 Conduct and assess demonstration of metabase system database capabilities

versus physical database requirements3.06.10.03 Conduct and assess demonstration of metabase system database capabilities

versus interrogation requirements3.06.10.04 Conduct and assess demonstration of metabase system database capabilities

versus system control requirements

3.06.11 Create metabase system database prototype demonstration presentation3.06.11.01 Modify features, advantages and benefits (FAB)of database system3.06.11.02 Include FABs to create capability scenarios3.06.11.03 Create narrative for capability scenario3.06.11.04 Identify key individual for review of capability scenario3.06.11.05 Review capability scenario & narrative with key individual and modify as

appropriate 3.06.11.06 Create A/V materials for capability scenario presentation3.06.11.07 Review and finalize A/V materials prior to review

3.06.12 Conduct subphase review3.06.12.01 Present metabase system database selection conclusion


63


3.06.12.02 Receive and respond to comments3.06.12.03 Modify system as necessary3.06.12.04 Seek concurrence with metabase system database selection subphase

3.07 Determine Implementation Strategy

3.07.01 Bind logical database to selected DBMS

3.07.01.01 Transform and or revise dynamic database3.07.01.01.01 Create physical Database diagram from table graphic3.07.01.01.02 Determine whether relational or ILF3.07.01.01.03 For ILF, create or revise tables with owner & single-level members3.07.01.01.04 For relational, create or revise single level tables3.07.01.01.05 Define value-based relationships between tables and update various conceptual

specification components3.07.01.01.06 Identify fields for intra-table relationships as secondary keys

3.07.01.02 Transform and/or revise static database3.07.01.02.01 Create physical database diagram from table graphic3.07.01.02.02 Determine whether network or hierarchical

3.07.01.02.03 Create or revise network structures3.07.01.02.03.01 Identify as tables those with no inter-table related repeating groups3.07.01.02.03.02 Define relationships that structurally connect these tables3.07.01.02.03.03 Identify other inter-table relationships

3.07.01.02.04 Create or revise hierarchical structures3.07.01.02.04.01 Identify hierarchies of most stable relationships3.07.01.02.04.02 Identify value-based relationships between hierarchies3.07.01.02.04.03 Identify fields for intra-table relationships as secondary keys

3.07.01.03 Record transformation or revision details in specification3.07.01.03.01 Identify additional dependency definitions, conditions, constraints, etc.3.07.01.03.02 Create additional tables as needed3.07.01.03.03 Create additional elements as needed3.07.01.03.04 Create additional data integrity rules as needed

3.07.01.04 Create logical database transformation or revision report3.07.01.04.01 Review & adjust logical database narratives from conceptual specification3.07.01.04.02 Review & revise all transformation tables3.07.01.04.03 Review & revise all transformation elements


64


3.07.01.04.04 Review & revise all transformation data integrity rules

3.07.01.05 Create logical database transformation or revision presentation3.07.01.05.01 Modify features, advantages and benefits (FAB) of database system3.07.01.05.02 Include FABs to create use scenarios3.07.01.05.03 Graphically identify tables processes that participate in scenario3.07.01.05.04 Create narrative for use scenario3.07.01.05.05 Identify key individual for use scenario3.07.01.05.06 Review use scenario & narrative with key individual and modify as appropriate3.07.01.05.07 Create A/V materials for use scenario presentation3.07.01.05.08 Review and finalize A/V materials prior to review

3.07.01.06 Conduct subphase review3.07.01.06.01 Present logical database transformation or revision3.07.01.06.02 Receive and respond to comments3.07.01.06.03 Modify system as necessary3.07.01.06.04 Seek concurrence with system subphase

3.07.02 Bind physical database to selected DBMS

3.07.02.01 Create or revise storage structure (static only)3.07.02.01.01 Determine most frequent table entry point within static structure3.07.02.01.02 Identify tables most frequently accessed subsequent to entry point3.07.02.01.03 Create database diagrams of access structures3.07.02.01.04 Identify mechanism of relationship between structures3.07.02.01.05 Update transformation specification as appropriate

3.07.02.02 Select access strategy

3.07.02.02.01 Select or revise access strategy for entry table3.07.02.02.01.01 Determine predominate access relationship between siblings for access

structure entry table3.07.02.02.01.02 Identify field for hash/calc access3.07.02.02.01.03 Identify whether sibling relationship is entry-order or by specific field

order3.07.02.02.01.04 Identify fields by each table is to be ordered3.07.02.02.01.05 Indicate that access is relative record access (data integrity ruleect)

3.07.02.02.02 Select or revise access strategy for subordinate tables3.07.02.02.02.01 Identify subordinate table to be connected by relationship3.07.02.02.02.02 Identify conditions or constraints to bind owners & members


65


3.07.02.02.02.03 Determine whether sibling relationship is entry-order or by specific fieldorder

3.07.02.02.02.04 Indicate that access is relative record access (data integrity ruleect)3.07.02.02.02.05 Identify field by which table is to be ordered3.07.02.02.02.06 Determine whether occurrences are to be "placed-near"

3.07.02.02.03 Validate selected or revised access strategy3.07.02.02.03.01 Combine all table access into single access strategy graphic3.07.02.02.03.02 Identify most significant update scenarios & report sequences3.07.02.02.03.03 Conduct "walk-throughs" to determine processing sequences3.07.02.02.03.04 Evaluate overall processing efficiency

3.07.03 Determine interrogation implementation strategy3.07.03.01 Review processing requirements and determine if reports are efficient database

users3.07.03.02 Identify database structure additions to efficiently support significant

interrogations3.07.03.03 Assess cost benefit of database change in terms of additional data loading and

data update

3.07.03.04 Modify database design3.07.03.04.01 Modify or add elements3.07.03.04.02 Modify or add tables3.07.03.04.03 Modify or add data integrity rules3.07.03.04.04 Modify data integrity subsystem design and estimates3.07.03.04.05 Modify data update subsystem design and estimates3.07.03.04.06 Modify data loading subsystem design and estimates3.07.03.04.07 Modify database size3.07.03.04.08 Modify all supporting documentation

3.07.04 Configure system control implementation strategy

3.07.04.01 Determine method of system control implementation3.07.04.01.01 Identify those requirements that are fully supported by DBMS facilities3.07.04.01.02 Identify those requirements that are partially DBMS supported3.07.04.01.03 Identify those requirements that are without DBMS support3.07.04.01.04 Determine those facilities which require additional system control facilities to

operate3.07.04.01.05 Determine extent of lockout required by each facility3.07.04.01.06 Create a DBMS support availability matrix


66


3.07.04.02 Create system control implementation estimate & report3.07.04.02.01 Estimate the cost & time to implement fully supported DBMS facilities3.07.04.02.02 Estimate the cost & time to implement the partially DBMS supported facilities3.07.04.02.03 Estimate the cost & time to design, implement & test DBMS facilities not at all

supported3.07.04.02.04 Assign priorities to each item & rank order by importance to application3.07.04.02.05 Create a system control report detailing availability, cost & importance

3.07.04.03 Include impact on production applications3.07.04.03.01 Factor in impact due to audit trails3.07.04.03.02 Factor in impact due to backup and recovery3.07.04.03.03 Factor in impact due to security and privacy3.07.04.03.04 Factor in impact due to concurrent operations3.07.04.03.05 Factor in impact due to multiple database object processing

3.07.04.04 Create system control implementation estimate presentation3.07.04.04.01 Modify features, advantages and benefits (FAB) of database system3.07.04.04.02 Include FABs to illustrate reasons for system control implementation estimate3.07.04.04.03 Create narrative for system control implementation estimate3.07.04.04.04 Identify key individual for system control implementation estimate3.07.04.04.05 Review system control implementation estimate & narrative with key individual

and modify as appropriate3.07.04.04.06 Create A/V materials for system control implementation estimate scenario

presentation3.07.04.04.07 Review and finalize A/V materials prior to review

3.07.04.05 Conduct subphase review3.07.04.05.01 Present system control implementation estimate3.07.04.05.02 Receive and respond to comments3.07.04.05.03 Modify system as necessary3.07.04.05.04 Seek concurrence with system subphase

3.07.05 Assess hardware availability3.07.05.01 Determine effect of proposed database system on CPU available capacity3.07.05.02 Determine effect of proposed database system on available mass storage3.07.05.03 Determine effect of proposed database system on telecommunications facilities3.07.05.04 Formulate hardware requirements estimates3.07.05.05 Create hardware enhancement proposals that include cost, procurement

alternatives, and delivery schedules

3.07.06 Determine implementation strategy


67


3.07.06.01 Identify implementation alternatives3.07.06.01.01 Define each alternative in sufficient detail to evaluate advantages and drawbacks3.07.06.01.02 Determine the logical database effect on the existing conceptual specification

design resulting from alternative3.07.06.01.03 Determine the physical database effect on the existing conceptual specification

design resulting from alternative3.07.06.01.04 Determine the interrogation effect on the existing conceptual specification design

resulting from alternative3.07.06.01.05 Determine the system control effect on the existing conceptual specification

design resulting from alternative3.07.06.01.06 Define interface boundaries requirement to outside systems3.07.06.01.07 Determine approximate implementation cost for each alternative3.07.06.01.08 Determine cost versus benefit ratio for each alternative

3.07.06.02 Determine Gantt/PERT/CPM charts for each alternative3.07.06.03 Present alternative for review and selection3.07.06.04 Consolidate Gantt, PERT, and CPM charts for selected alternative

3.07.07 Prepare system proposal for implementation phase3.07.07.01 Adjust subsystems or specifications per special study results3.07.07.02 Create estimate for implementation phase3.07.07.03 Obtain approval for implementation

3.07.08 Create implementation approach presentation3.07.08.01 Modify features, advantages and benefits (FAB) of database system3.07.08.02 Include FABs to create system implementation strategy3.07.08.03 Create narrative for system control implementation estimate scenario3.07.08.04 Identify key individual for system implementation strategy3.07.08.05 Review system implementation strategy & narrative with key individual and

modify as appropriate3.07.08.06 Create A/V materials for system implementation strategy presentation3.07.08.07 Review and finalize A/V materials prior to review

3.07.09 Conduct subphase review3.07.09.01 Present database system implementation strategy3.07.09.02 Receive and respond to comments3.07.09.03 Modify strategy as necessary3.07.09.04 Seek concurrence with implementation strategy

3.08 Prepare binding phase report3.08.01 Prepare section on data availability


68


3.08.02 Prepare section on corporate business model impact3.08.03 Prepare section on DBMS selection and evaluation3.08.04 Prepare section on implementation strategy

3.09 Create binding phase presentation3.09.01 Modify features, advantages and benefits (FAB) of database system3.09.02 Include FABs to create system implementation strategy3.09.03 Create narrative for system control implementation estimate scenario3.09.04 Identify key individual for system implementation strategy3.09.05 Review system implementation strategy & narrative with key individual and

modify as appropriate3.09.06 Create A/V materials for system implementation strategy presentation3.09.07 Review and finalize A/V materials prior to review

3.10 Conduct phase review3.10.01 Present binding report3.10.02 Receive and respond to comments3.10.03 Modify report as necessary3.10.04 Seek concurrence with implementation phase strategy


69



70

4

Implementation Phase

4 Implementation







4.01.10 Develop and/or use database standards for phase

4.01.11 Interrogate and maintain metabase system database during phase

4.02 Create or revise logical database4.02.01 Define implemented data model schema clauses4.02.02 Define implemented data model table clauses4.02.03 Define implemented data model table condition clauses4.02.04 Define implemented data model inter-table relationship clauses4.02.05 Define implemented data model intra & inter-table data integrity clauses4.02.06 Define implemented data model relationship clauses4.02.07 Submit implemented data model DDL & make corrections


4.03 Create or revise physical database

4.03.01 Create or revise operational data model4.03.01.01 Create operational data model for main database file allocation4.03.01.02 Create operational data model for database support files allocation4.03.01.03 Create operational data model for database configured for data loading4.03.01.04 Create operational data model for database configured for data update4.03.01.05 Create operational data model for backup files4.03.01.06 Create documentation to support use of each operational data model

4.03.02 Create or revise views4.03.02.01 Identify view requirements for each update subsystem as appropriate4.03.02.02 Identify view requirements for each load program4.03.02.03 Identify view requirements for each interrogation program4.03.02.04 Identify data interfaces needed for system control functions, if needed4.03.02.05 Create appropriate views4.03.02.06 Create documentation for each view

4.03.03 Create or revise each data update subsystem4.03.03.01 Divide batch & on-line transactions

4.03.03.02 Create or revise, then implement & test each batch update subsystem

4.03.03.02.01 Create or revise batch subsystems4.03.03.02.01.01 Create general design for a transaction driven program4.03.03.02.01.02 Identify & engineer standard approach to implement batch programs so as

to avoid repetitive analysis, specification, coding testing & documentationof common or functionally similar logic

4.03.03.02.01.03 Create design of update transaction4.03.03.02.01.04 Create design of update transaction error processing4.03.03.02.01.05 Review & adjust transactions to conform to design of transformed

database4.03.03.02.01.06 Create programming specifications for each update transaction4.03.03.02.01.07 Create programming specification for transaction rollback4.03.03.02.01.08 Identify appropriate views for subsystem4.03.03.02.01.09 Review each transaction for completeness & consistency with respect to

the system as a whole

4.03.03.02.02 Implement batch update subsystems4.03.03.02.02.01 Program each transaction4.03.03.02.02.02 Program each error message transaction


72

Phase 4, Implementation

4.03.03.02.02.03 Program transaction validation4.03.03.02.02.04 Walk through program code of each transaction4.03.03.02.02.05 Conduct walk through of DBMS DML logic for efficiency and integrity4.03.03.02.02.06 Evaluate placement of commits with respect to efficiency and integrity4.03.03.02.02.07 Validate appropriate interaction with database through views4.03.03.02.02.08 Conduct walk through of prototype stream of batch updates to validate

overall interaction

4.03.03.02.03 Perform system development test on each batch update subsystem4.03.03.02.03.01 Generate an appropriate set of test data to validate transaction operation4.03.03.02.03.02 Create scenarios for subsystem test4.03.03.02.03.03 Test each transaction individually & then in collections4.03.03.02.03.04 Conduct operation validation against test database4.03.03.02.03.05 Validate all error messages & transaction validation operations4.03.03.02.03.06 Validate all other system control features4.03.03.02.03.07 Construct resource consumption data & validate against requirements

4.03.03.03 Create or revise, then implement & test each on-line update subsystem

4.03.03.03.01 Create or revise on-line data update subsystems4.03.03.03.01.01 Create general design for a transaction driven program4.03.03.03.01.02 Identify & engineer standard approach to implement on-line programs so

as to avoid repetitive analysis, specification, coding testing &documentation of common or functionally similar logic

4.03.03.03.01.03 Create design for update transaction4.03.03.03.01.04 Create design of update transaction error processing4.03.03.03.01.05 Review & adjust transactions to conform to design of transformed

database4.03.03.03.01.06 Create programming specifications for each transaction4.03.03.03.01.07 Create programming specification for transaction rollback4.03.03.03.01.08 Identify appropriate view for each transaction

4.03.03.03.02 Implement on-line data update subsystems4.03.03.03.02.01 Program each transaction4.03.03.03.02.02 Program each message & validation subordinate transactions4.03.03.03.02.03 Program if necessary transaction rollback4.03.03.03.02.04 Program whatever links are required to chain transactions4.03.03.03.02.05 Program if necessary multiple transaction rollback4.03.03.03.02.06 Conduct walk through of program code for transactions4.03.03.03.02.07 Conduct walk through of DBMS DML logic for efficiency and integrity4.03.03.03.02.08 Evaluate placement of commits with respect to efficiency and integrity


73


4.03.03.03.02.09 Validate appropriate interaction with database through views

4.03.03.03.03 Perform system development test on each on-line data update subsystems4.03.03.03.03.01 Generate an appropriate set of test data to validate transaction operation4.03.03.03.03.02 Create scenario to test single & concurrent update transactions4.03.03.03.03.03 Test each transaction individually & then concurrently4.03.03.03.03.04 Validate correct transaction operation4.03.03.03.03.05 Validate all error messages & transaction validation operations4.03.03.03.03.06 Validate acceptable database reaction to conflicting concurrent operations4.03.03.03.03.07 Validate all other system control features4.03.03.03.03.08 Construct resource consumption data & validate against requirements

4.03.04 Create or revise each data loading subsystem

4.03.04.01 Update data loading subsystem conceptual specification report4.03.04.01.01 Revise logical table loading sequence chart to conform to transformed database4.03.04.01.02 Revise editing & validation for each table4.03.04.01.03 Revise inter-table editing & validation4.03.04.01.04 Revise error processing procedures4.03.04.01.05 Create a data loading subsystem implementation phase specification

4.03.04.02 Design or revise static data loading subsystems4.03.04.02.01 Identify entry point tables4.03.04.02.02 Create program minispecification to read data & store row4.03.04.02.03 Create program minispecification to read member table, store it in the database &

update relationships for which row is a member4.03.04.02.04 Create program minispecification to effect editing & validation4.03.04.02.05 Determine appropriate action for entry table and/or member table load failure4.03.04.02.06 Create program minispecification for error processing

4.03.04.03 Design or revise dynamic data loading subsystems4.03.04.03.01 Identify major "owner" tables4.03.04.03.02 Create program minispecification to read data & store row4.03.04.03.03 Create program minispecification to load "member" row & to value for

owner-member relationship4.03.04.03.04 Create program minispecification to effect editing & validation4.03.04.03.05 Determine whether "member" is to be loaded if "owner" fails editing and/or

validation test4.03.04.03.06 Create program minispecification for error processing

4.03.04.04 Implement data loading subsystems (static)


74


4.03.04.04.01 Program each minispecification4.03.04.04.02 Program editing & validation4.03.04.04.03 Walk through program code of load subsystem4.03.04.04.04 Conduct walk through of DBMS DML logic for efficiency and integrity4.03.04.04.05 Evaluate placement of commits with respect to efficiency and integrity4.03.04.04.06 Validate appropriate interaction with database through views4.03.04.04.07 Conduct walk through prototype stream of data load subsystem

4.03.04.05 Perform system development test on data loading subsystems4.03.04.05.01 Generate an appropriate set of test data to validate load subsystem4.03.04.05.02 Create strategy to validate correctness of data loading4.03.04.05.03 Perform simple data load to validate correct operation4.03.04.05.04 Validate all error messages & error processing4.03.04.05.05 Validate acceptable database reaction to database load errors4.03.04.05.06 Construct resource consumption data on test database loads

4.03.05 Create or revise each data conversion subsystem4.03.05.01 Update data conversion subsystem conceptual specification report4.03.05.01.01 Revise logical table data conversion sequence chart to conform to transformed

database4.03.05.01.02 Revise editing & validation for each table4.03.05.01.03 Revise inter-table editing & validation4.03.05.01.04 Revise error processing procedures4.03.05.01.05 Create a data conversion subsystems implementation phase specification

4.03.05.02 Design or revise static data conversion subsystems4.03.05.02.01 Identify entry report point tables4.03.05.02.02 Create program mini-specification to read data & store data4.03.05.02.03 Create program mini-specification to effect editing & validation4.03.05.02.04 Determine appropriate action for entry table failure4.03.05.02.05 Create program mini-specification for error processing

4.03.05.03 Design or revise dynamic data conversion subsystems4.03.05.03.01 Identify tables4.03.05.03.02 Create program mini-specification to read, convert, and store row4.03.05.03.03 Create program mini-specification to effect editing & validation4.03.05.03.04 Create program mini-specification for error processing

4.03.05.04 Implement data conversion subsystems (static)4.03.05.04.01 Program the mini-specification4.03.05.04.02 Program the editing & validation


75


4.03.05.04.03 Walk through program code of data conversion subsystem4.03.05.04.04 Conduct walk through of DBMS DML logic for efficiency and integrity4.03.05.04.05 Evaluate placement of commits with respect to efficiency and integrity4.03.05.04.06 Validate appropriate interaction with database through subschema4.03.05.04.07 Conduct walk through prototype stream of data conversion subsystem

4.03.06 Create or revise test data4.03.06.01 Review test data from conceptual specification prototype for applicability4.03.06.02 Modify test data to conform to transformed database4.03.06.03 Create test data for each data loading & data update subsystem4.03.06.04 Validate correctness of test data4.03.06.05 Organize test data in permanent form for many database operations

4.03.07 Create or revise database backup procedures4.03.07.01 Identify DBMS mechanism for database backup4.03.07.02 Establish procedure to involve database backup4.03.07.03 Test backup procedure on loaded test database4.03.07.04 Validate correct operation4.03.07.05 Construct resource consumption data on test database backups

4.03.08 Perform system development test on physical database4.03.08.01 Create testing scenarios for data loading, data update, data conversion & backup

subsystems4.03.08.02 Determine method to validate tests against predetermined results4.03.08.03 Conduct sufficient tests to certify valid, reliable & consistent operation4.03.08.04 Review & validate all physical database implementation documentation

4.03.09 Revise human support subsystems affected by new on-line data updatesubsystems

4.03.09.01 Revise each human support subsystem4.03.09.02 Revise process diagrams for all manual processes4.03.09.03 Optimize manual processes to take advantage of new tools4.03.09.04 Create new training materials4.03.09.05 Revise any necessary job description revisions4.03.09.06 Execute plan to implement changes to human support subsystems

4.03.10 Create or revise physical database implementation report4.03.10.01 Review & adjust physical database narratives from conceptual specification4.03.10.02 Create complete documentation for storage structure4.03.10.03 Create complete documentation for access strategy4.03.10.04 Create complete documentation for data loading subsystem


76


4.03.10.05 Create complete documentation for data update subsystem4.03.10.06 Create complete documentation for test data4.03.10.07 Create complete documentation for database backup procedure

4.03.11 Create or revise physical database implementation presentation4.03.11.01 Modify features, advantages and benefits (FAB) of database system4.03.11.02 Include FABs to illustrate physical database implementation4.03.11.03 Create narrative for physical database implementation4.03.11.04 Identify key individual for physical database implementation4.03.11.05 Review physical database implementation & narrative with key individual and

modify as appropriate4.03.11.06 Create A/V materials for physical database implementation presentation4.03.11.07 Review and finalize A/V materials prior to review

4.03.12 Conduct subphase review4.03.12.01 Present physical database system implementation4.03.12.02 Receive and respond to comments4.03.12.03 Modify system as necessary4.03.12.04 Seek concurrence with system subphase

4.04 Create or revise critical interrogation subsystems4.04.01 Analyze implementation requirements & create schedule for specific interrogation

subsystems

4.04.02 Analyze implementation requirements for specific interrogation subsystem

4.04.02.01 Identify specific implementation4.04.02.01.01 Adjust generic interrogation requirements to transformed database4.04.02.01.02 Adjust generic tables & elements to requirements of transformed database4.04.02.01.03 Adjust generic data integrity rules to transformed database4.04.02.01.04 Identify specific reports required for implementation4.04.02.01.05 Create preliminary reports requirements statement for each identified report

4.04.02.02 Analyze interrogation subsystem complexity4.04.02.02.01 Identify reports by number of required databases4.04.02.02.02 Identify reports by outside data file requirements4.04.02.02.03 Identify reports by database update in addition to reporting4.04.02.02.04 Identify reports by sophistication of data calculation & processing4.04.02.02.05 Identify reports by output format complexity4.04.02.02.06 Create a report complexity matrix


77


4.04.02.03 Estimate resources required to create or revise subsystem reports4.04.02.03.01 Identify & engineer standard approach to implement on-line programs so as to

avoid repetitive analysis, specification, coding testing & documentation ofcommon or functionally similar logic

4.04.02.03.02 Estimate resources required to create most simple reports4.04.02.03.03 Estimate resources required to generate moderate reports4.04.02.03.04 Estimate resources required to generate complex reports4.04.02.03.05 Identify priority or importance for report4.04.02.03.06 Create a priority & resource requirements matrix

4.04.02.04 Determine implementation order for generating specific subsystems4.04.02.04.01 Present report priority & estimated resource requirements4.04.02.04.02 Determine implementation order4.04.02.04.03 Establish implementation schedule

4.04.03 Create or revise specific interrogation unit

4.04.03.01 Create or revise unit minispecification4.04.03.01.01 Create an introductory section4.04.03.01.02 Include the required tables4.04.03.01.03 Include the required elements4.04.03.01.04 Include the data integrity rules that are required for inter-table navigation4.04.03.01.05 Create pseudocode or acceptable alternative that reflects transformations and

processing steps4.04.03.01.06 Indicate inputs & formats4.04.03.01.07 Indicate outputs & formats4.04.03.01.08 Identify appropriate views

4.04.03.02 Prototype unit components through a natural language4.04.03.02.01 Identify DBMS language that least inhibits report generation4.04.03.02.02 Translate minispecification into DBMS language4.04.03.02.03 Submit to DBMS & debug4.04.03.02.04 Demonstrate to users to validate design4.04.03.02.05 Project current resource expenditure to production volume4.04.03.02.06 Determine frequency of use & number of users for report4.04.03.02.07 Create validated design report

4.04.03.03 Select final interrogation language for each unit component4.04.03.03.01 If interrogation module's life span exceeds that of DBMS choose ANSI standard

language for module implementation


78


4.04.03.03.02 If interrogation module's life span is within life span of DBMS, choose the mostcost-effective DBMS natural language

4.04.03.03.03 Create estimate for generations report

4.04.03.04 Implement interrogation unit4.04.03.04.01 Program each minispecification4.04.03.04.02 Program data input file editing, processing, etc.4.04.03.04.03 Program any system control facilities needed for any database updates4.04.03.04.04 Walk through program code4.04.03.04.05 Validate appropriate interaction with database through views4.04.03.04.06 Conduct walk through of DBMS DML logic for efficiency and integrity4.04.03.04.07 Create appropriate program documentation

4.04.03.05 Perform system development test on each interrogation unit4.04.03.05.01 Generate an appropriate set of test data to validate report4.04.03.05.02 Perform basic testing to validate report operation4.04.03.05.03 Validate all error processing & messages4.04.03.05.04 Construct resource consumption data on test database4.04.03.05.05 Extrapolate consumption to production database4.04.03.05.06 Determine whether estimates are within acceptable limits

4.04.03.06 Assess production impact4.04.03.06.01 Summarize interrogation resource consumption4.04.03.06.02 Identify schedule for execution4.04.03.06.03 Compute cyclical requirements estimates4.04.03.06.04 Factor in data update subsystem resource requirements4.04.03.06.05 Determine whether combined resources estimates are acceptable4.04.03.06.06 Determine which interrogation module consumes excessive resources and revise

as appropriate

4.04.03.07 Develop interrogation unit implementation report4.04.03.07.01 Create standard documentation for each interrogation module/unit4.04.03.07.02 Create appropriate run/JCL instructions4.04.03.07.03 Summarize resource consumption requirements4.04.03.07.04 Summarize cyclical report requirements4.04.03.07.05 Coordinate interrogation module production requirements with update transaction

data availability

4.04.04 Create interrogation implementation report

4.04.05 Create or revise interrogation implementation presentation


79


4.04.05.01 Modify features, advantages and benefits (FAB) of database system4.04.05.02 Include FABs to illustrate interrogation implementation4.04.05.03 Graphically identify tables or processes that participate in each interrogation

implementation4.04.05.04 Create narrative for each interrogation implementation4.04.05.05 Identify key individual for review of interrogation implementation4.04.05.06 Review interrogation implementation & narrative with key individual and modify

as appropriate4.04.05.07 Create A/V materials for use interrogation implementation presentation4.04.05.08 Review and finalize A/V materials prior to review

4.04.06 Conduct subphase review4.04.06.01 Present interrogation implementation4.04.06.02 Receive and respond to comments4.04.06.03 Modify system as necessary

4.05 System control implementation

4.05.01 Implement or revise fully supported DBMS facilities4.05.01.01 Determine mechanism to invoke facility4.05.01.02 Thoroughly validate facility with test database4.05.01.03 Estimate impact on production operations

4.05.02 Implement or revise partially supported DBMS facilities4.05.02.01 Create design & specification for each program/module that must be implemented4.05.02.02 Determine impact on logical, physical & interrogation database software modules4.05.02.03 Estimate resources required for implementation4.05.02.04 Review design & resource estimate & schedule implementation4.05.02.05 Implement & test facilities against test database4.05.02.06 Estimate impact on production operations

4.05.03 Acquire/implement and/or revise facilities not supported by DBMS4.05.03.01 Determine whether facility is available from other sources

4.05.03.02 Create or revise, then implement & test facilities4.05.03.02.01 Create or revise design & specification for each program/module that must be

implemented4.05.03.02.02 Determine impact on logical, physical & interrogation database software modules4.05.03.02.03 Estimate resources required for implementation4.05.03.02.04 Review design & resource estimate & schedule implementation4.05.03.02.05 Implement & test facilities against test database part of DBMS


80


4.05.03.03 Check with DBMS vendor user group for facility availability4.05.03.04 Determine whether facility can be available on a timely basis4.05.03.05 Acquire & rigorously test facility4.05.03.06 Determine impact on production operations

4.05.04 Create utilization scenarios & fully test all facilities4.05.04.01 Determine conditions that necessitate facility utilization4.05.04.02 Determine method or procedures for facility invocation4.05.04.03 For recurring facility usage establish schedule of utilization4.05.04.04 Create tests of facilities against various sizes & configurations of the test database4.05.04.05 Review production impact & adjust as necessary

4.05.05 Create or revise operations documentation & guides4.05.05.01 Create complete operational documentation for each facility4.05.05.02 Create complete schedules for periodic facilities4.05.05.03 Adjust system production costs by resource requirements for recurring facilities4.05.05.04 Predict the number of occurrences of system control facilities that occur only

reactively4.05.05.05 Create an overall production impact estimate, facility use procedures & schedule

for use

4.05.06 Determine, implement and maintain security and privacy for implementationphase activities

4.05.06.01 Determine security and privacy profiles for implementation phase users4.05.06.01.01 Identify various securable facilities, such as databases, run-units, views, etc.4.05.06.01.02 Create user profile for each users as needed4.05.06.01.03 Review security profile with security officer

4.05.06.02 Implement user profiles to DBMS/security facility4.05.06.03 Maintain user profiles as needed.

4.05.07 Create or revise system control implementation report4.05.07.01 Review & adjust system control narratives from conceptual specification4.05.07.02 Create complete documentation for each system control component4.05.07.03 Finalize user documentation for facility invocation4.05.07.04 Update all resource consumption estimates for production operations4.05.07.05 Finalize format & documentation of the test database for system control testing

4.05.08 Create or revise system control implementation presentation4.05.08.01 Modify features, advantages and benefits (FAB) of database system


81


4.05.08.02 Include FABs to illustrate system control implementation4.05.08.03 Create narrative for system control implementation4.05.08.04 Identify key individual for system control implementation review4.05.08.05 Review system control implementation & narrative with key individual and

modify as appropriate4.05.08.06 Create A/V materials for system control implementation presentation4.05.08.07 Review and finalize A/V materials prior to review

4.05.09 Conduct subphase review4.05.09.01 Present system control implementation components4.05.09.02 Receive and respond to comments4.05.09.03 Modify system as necessary4.05.09.04 Seek concurrence with system subphase

4.06 Develop or revise ancillary supports

4.06.01 Develop or revise database system training4.06.01.01 Identify source of database technology training4.06.01.02 Identify source of DBMS training

4.06.01.03 Identify training required for various subsystem users4.06.01.03.01 Determine training needs for data loading subsystem users4.06.01.03.02 Determine training needs for data update subsystem users4.06.01.03.03 Determine training needs for data conversion subsystem users4.06.01.03.04 Determine training needs for system control facilities users4.06.01.03.05 Determine training needs for systems maintenance personnel4.06.01.03.06 Determine training needs for interrogation subsystem users4.06.01.03.06.01 Determine training needs for standard report users4.06.01.03.06.02 Determine training needs for ad hoc report users4.06.01.03.06.03 Determine training needs for DBMS natural language users

4.06.01.04 Identify training required for general aspects of database project4.06.01.05 Create detailed training outline for each training module4.06.01.06 Develop training materials4.06.01.07 Test & revise training4.06.01.08 Create training schedule4.06.01.09 Write new user job descriptions4.06.01.10 Assist in planning hiring/transferring of user personnel4.06.01.11 Estimate user implementation manpower costs

4.06.02 Develop or revise database hotline


82


4.06.02.01 Identify the various groups that require technical assistance4.06.02.02 Identify the specific knowledge needed by each group4.06.02.03 Determine the availability of training to initially assist user group4.06.02.04 Determine the materials necessary to support the hotline groups4.06.02.05 Develop the training material needed for the hotline group4.06.02.06 Develop hotline group procedures4.06.02.07 Test & revise hotline personnel & procedures4.06.02.08 Create hotline operational plan

4.06.03 Develop or revise database standards4.06.03.01 Define rationale & benefits for standards4.06.03.02 Propose standards for each database component4.06.03.03 Review & revise standards as necessary to achieve complete integrated set4.06.03.04 Review & revise standards to conform to organizational requirements4.06.03.05 Devise method to constantly review standards for usability & applicability4.06.03.06 Determine effect of standards on production operations4.06.03.07 Create a final standards manual for database project

4.06.04 Develop or revise final test data4.06.04.01 Review & finalize test data for data update subsystem4.06.04.02 Review & finalize test data for data loading subsystems4.06.04.03 Review & finalize test data for backup4.06.04.04 Review & revise test data for major interrogation subsystems4.06.04.05 Review & revise test data for each system control component4.06.04.06 Review & revise test data for system prototype demonstration4.06.04.07 Review & revise test data for system prototype demonstration4.06.04.08 Create test data report & use procedures

4.06.05 Develop or revise database system documentation

4.06.05.01 Develop internal database documentation

4.06.05.01.01 Review & revise all conceptual documentation as affected by implementation4.06.05.01.01.01 metabase system database updates: mission descriptions, database

domains, database objects, reports, business terms, policies, table,columns, data integrity rules, business information systems

4.06.05.01.02 Review & revise all implementation documentation for clarity, correctness anduniformity

4.06.05.01.02.01 metabase system database tables: schema, views, DBMS record, DBMSelement, subsystem, program, module, etc.


83


4.06.05.01.02.02 Inter-module logic control charts4.06.05.01.02.03 Module logic narrative and diagrams4.06.05.01.02.04 Program logic narrative & diagrams4.06.05.01.02.05 Subsystem logic narrative and diagrams4.06.05.01.02.06 Annotated computer software listings4.06.05.01.02.07 Messages and meanings4.06.05.01.02.08 Test data and testing procedures

4.06.05.01.03 Review & revise all documentation relating to ancillary supports, especiallyhotline

4.06.05.01.04 Develop strategy for documentation change control4.06.05.01.05 Determine mechanism for documentation, duplication and change dissemination4.06.05.01.06 Create documentation report

4.06.05.02 Prepare user manuals4.06.05.02.01 Prepare logical database user manuals4.06.05.02.02 Prepare data update operations manuals4.06.05.02.03 Prepare interrogation subsystem user manuals4.06.05.02.04 Prepare system control user manuals

4.06.05.03 Prepare operations documentation4.06.05.03.01 Create final procedures or JCL4.06.05.03.02 Create job or run narratives for data update, data loading, and interrogation

subsystems4.06.05.03.03 Create job or run narratives for system control functions such as backup and

recovery, security and privacy, reorganization, and the like4.06.05.03.04 Create job schedule requirements4.06.05.03.05 Create run setup instructions4.06.05.03.06 Create job cataloguing instructions4.06.05.03.07 Create off-line storage library instructions4.06.05.03.08 Assemble operations documentation package4.06.05.03.09 Review operations documents with operations manager and change

documentation as required

4.06.05.04 Review & finalize all documentation4.06.05.04.01 Review all ancillary support products, that is, documentation, procedures, etc for

correctness and the like4.06.05.04.02 Revise as necessary4.06.05.04.03 Prepare final products4.06.05.04.04 Prepare procedure for duplication & distribution4.06.05.04.05 Review procedure for change, control & products revision distribution


84


4.06.06 Prepare ancillary supports implementation report4.06.06.01 Create final statement on production operations impact4.06.06.02 Create overall schedule for ancillary supports for maintenance & administrative

phase

4.06.07 Create or revise ancillary supports presentation4.06.07.01 Modify features, advantages and benefits (FAB) of database system4.06.07.02 Include FABs to illustrates ancillary supports utilization4.06.07.03 Develop appropriate documentation to illustrate use of ancillary supports4.06.07.04 Identify key individual for review of ancillary supports4.06.07.05 Review ancillary supports & narrative with key individual and modify as

appropriate4.06.07.06 Create A/V materials for use scenario presentation4.06.07.07 Review and finalize A/V materials prior to review

4.06.09 Conduct subphase review4.06.09.01 Present ancillary support components4.06.09.02 Receive and respond to comments4.06.09.03 Modify system as necessary4.06.09.04 Seek concurrence with system subphase

4.07 Plan and conduct system quality tests (system quality test)

4.07.01 Create or revise system operation scenarios4.07.01.01 Create scenario & schedule for initial data acquisition & database loading4.07.01.02 Create scenario & schedule for a complete set of data updates4.07.01.03 Create scenario & schedule for database interrogation subsystems4.07.01.04 Create scenario & schedule for various database system control facilities4.07.01.05 Create scenario & schedule for utilization of ancillary supports4.07.01.06 Combine all scenarios & schedules into one overall proposed operations plan

4.07.02 Create or revise tests to validate scenarios4.07.02.01 Identify artificial and production tests appropriate to validate correct production

environment.4.07.02.02 Identify method to acquire production environment or to use a subset without

change4.07.02.03 Create testing scenarios that simulate production environment4.07.02.04 Identify backup and recovery procedures for system operation4.07.02.05 Identify all ancillary supports and establish criteria for acceptance4.07.02.06 Establish system performance and test success criteria4.07.02.07 Identify all required operations, procedures, and guides that are to be evaluated


85


4.07.02.08 Formulate complete system quality test plan

4.07.03 Schedule database system quality test4.07.03.01 Review all schedules, scenarios & tests, and build in delays due to process

failures4.07.03.02 Review proposed schedule to determine acceptability4.07.03.03 Optimize schedule as necessary4.07.03.04 Determine beginning date & time for system test

4.07.04 Conduct system quality tests4.07.04.01 Acquire system quality test environment

4.07.04.02 Accomplish database schema changes4.07.04.02.01 Create modified database4.07.04.02.02 Reorganize database as needed

4.07.04.03 Install software into test environment4.07.04.04 Execute artificial tests4.07.04.05 Execute production tests4.07.04.06 If either tests fail, construct system quality test failure report4.07.04.07 If both tests pass, construct system quality test passes report4.07.04.08 If system quality test fails, restore pretest environment4.07.04.09 If system quality test passes, proceed with production environment modification

4.07.05 Prepare system test report4.07.05.01 Review all documentation & adjust as necessary4.07.05.02 Review all proposed operations, schedules & revise as necessary4.07.05.03 Review all proposal resource consumption estimates & revise as necessary4.07.05.04 Combine all documentation into one and revise as necessary

4.07.06 Create system test presentation4.07.06.01 Modify features, advantages and benefits (FAB) of database system4.07.06.02 Include FABs to illustrate system test4.07.06.03 Create narrative for system test4.07.06.04 Identify key individual for review of system test4.07.06.05 Review system test narrative with key individual and modify as appropriate4.07.06.06 Create A/V materials for system test presentation4.07.06.07 Review and finalize A/V materials prior to review

4.07.07 Conduct subphase review4.07.07.01 Present system test components


86


4.07.07.02 Receive and respond to comments4.07.07.03 Modify system as necessary4.07.07.04 Seek concurrence with system subphase

4.08 Create implementation phase report4.08.01 Include the physical database implementation report4.08.02 Include the interrogation implementation report4.08.03 Include the system control implementation report4.08.04 Include the ancillary supports implementation report4.08.05 Include the system test report

4.09 Create implementation phase presentation4.09.01 Modify features, advantages and benefits (FAB) of database system4.09.02 Include FABs to illustrate database system implementation4.09.03 Create narrative for database system implementation4.09.04 Identify key individual for review of database system implementation4.09.05 Review database implementation & narrative with key individual and modify as

appropriate4.09.06 Create A/V materials for database system implementation presentation4.09.07 Review and finalize A/V materials prior to review

4.10 Conduct phase review4.10.01 Present implementation phase components4.10.02 Receive and respond to comments4.10.03 Modify system as necessary4.10.04 Seek concurrence with system subphase


87

5

Conversion & Deployment Phase

5 Conversion & Deployment








5.02 Review prior phase for completeness and revise as necessary5.03 Secure, install and test all equipment

5.04 Conduct all training5.04.01 Conduct user training5.04.02 Conduct system maintenance training5.04.03 Conduct data transfer and data conversion user training

5.05 Convert all data


5.06 Create conversion and deployment report

5.07 Create conversion and deployment review presentation5.07.01 Modify features, advantages and benefits (FAB) of database system5.07.02 Include FABs to illustrate database system implementation5.07.03 Create narrative for database system implementation review5.07.04 Identify key individual for review of conversion and deployment review5.07.05 Review database conversion and deployment review & narrative with key

individual and modify as appropriate5.07.06 Create A/V materials for conversion and deployment presentation5.07.07 Review and finalize A/V materials prior to review

5.08 Conduct phase review5.08.01 Present conversion and deployment review5.08.02 Receive and respond to comments5.08.03 Modify system as necessary5.08.04 Seek concurrence with system phase

5.09 Prepare estimate for production and administration phase5.10 Prepare project production & administration phase funding5.11 Present for funding review


89



90

6

Production and Administration Phase

6 Production & Administration


6.01.03 Select project staff for preliminary analysis phase6.01.03.01 Interview and select database specialist6.01.03.02 Interview and select functional users






6.02 Database system production

6.02.01 Commence database system6.02.01.01 Begin operation of all ancillary supports6.02.01.02 Create database structure6.02.01.03 Perform initial database load6.02.01.04 Begin operation of data update subsystems6.02.01.05 Begin operation of interrogation subsystems6.02.01.06 Begin operation of various system control supports


6.02.02 Conduct ongoing database system production6.02.02.01 Perform cyclical updates6.02.02.02 Perform ad hoc updates6.02.02.03 Perform cyclical reports6.02.02.04 Perform ad hoc reports6.02.02.05 Conduct ongoing training6.02.02.06 Provide hotline services6.02.02.07 Perform system control supports6.02.02.08 Operate database system

6.02.03 Develop and maintain views as necessary6.02.04 Develop and maintain security and privacy facilities as needed6.02.05 Conduct parallel operations as appropriate6.02.06 Create production commencement report6.02.07 Create production commencement presentation6.02.08 Perform production commencement review

6.03 Develop interrogation subsystems6.03.01 Create requirements specifications6.03.01.01 Create an introductory section detailing problem addressed, scope, etc.6.03.01.02 Include the required tables6.03.01.03 Include the required elements6.03.01.04 Include the data integrity rules that are required for inter-table navigation6.03.01.05 Include a statement of transformation & processing steps6.03.01.06 Indicate inputs & formats6.03.01.07 Indicate outputs & formats

6.03.02 Create views6.03.02.01 Identify view requirements for each interrogation requirement and program as

appropriate6.03.02.02 Create documentation for each view6.03.02.03 Create relationships among views, database object information systems, database

object table processes and data integrity rules as appropriate

6.03.03 Prototype through a natural language6.03.03.01 Identify DBMS language that least inhibits report generation6.03.03.02 Translate mini-specification into DBMS language6.03.03.03 Submit to DBMS & debug6.03.03.04 Demonstrate to users to validate design6.03.03.05 Project current resource expenditure to production volume6.03.03.06 Determine frequency of use & number of users for report


92

Phase 6, Production and Administration Phrase

6.03.03.07 Create validated design report

6.03.04 Select cost efficient language6.03.04.01 If interrogation module's life span exceeds that of DBMS choose ANSI standard

language for module implementation6.03.04.02 If interrogation module's life span is within life span of DBMS, choose the most

cost-effective DBMS natural language6.03.04.03 Create estimate for generations report

6.03.05 Implement interrogation subsystem6.03.05.01 Program each mini-specification6.03.05.02 Program data input file editing, processing, etc.6.03.05.03 Program any system control facilities needed for any database updates6.03.05.04 Walk through program code6.03.05.05 Validate appropriate interaction with database through views6.03.05.06 Conduct walk through of DBMS DML logic for efficiency and integrity6.03.05.07 Create appropriate program documentation

6.03.06 Perform system development test on interrogation subsystem6.03.06.01 Generate an appropriate set of test data to validate report6.03.06.02 Perform basic testing to validate report operation6.03.06.03 Validate all error processing & messages6.03.06.04 Construct resource consumption data on test database6.03.06.05 Extrapolate consumption to production database6.03.06.06 Determine whether estimates are within acceptable limits

6.03.07 Assess production impact6.03.07.01 Summarize interrogation resource consumption6.03.07.02 Identify schedule for execution6.03.07.03 Compute cyclical requirements estimates6.03.07.04 Factor in data update subsystem resource requirements6.03.07.05 Determine whether combined resources estimates are acceptable6.03.07.06 Determine which interrogation module consumes excessive resources

6.03.08 Develop interrogation implementation report6.03.08.01 Create standard documentation for interrogation module/subsystem6.03.08.02 Create appropriate run/JCL instructions6.03.08.03 Summarize resource consumption requirements6.03.08.04 Summarize cyclical report requirements6.03.08.05 Coordinate interrogation module production requirements with update transaction

data availability


93


6.03.09 Create interrogation implementation presentation6.03.09.01 Modify features, advantages and benefits (FAB) of database system6.03.09.02 Include FABs to illustrate interrogation implementation6.03.09.03 Graphically identify tables or processes that participate in each interrogation

implementation6.03.09.04 Create narrative for each interrogation implementation6.03.09.05 Identify key individual for review of interrogation implementation6.03.09.06 Review interrogation implementation & narrative with key individual and modify

as appropriate6.03.09.07 Create A/V materials for use interrogation implementation presentation6.03.09.08 Review and finalize A/V materials prior to review

6.03.10 Conduct interrogation review6.03.10.01 Present interrogation implementation6.03.10.02 Receive and respond to comments6.03.10.03 Modify system as necessary

6.04 Application Optimization Assessment

6.04.01 Assess physical database performance6.04.01.01 Assess data online and batch update for ease of use and acceptable performance6.04.01.02 Assess data batch data loading for ease of use and acceptable performance6.04.01.03 Formulate strategy for improving performance6.04.01.04 Determine acceptability of eliminating indexes6.04.03.05 Create physical database performance assessment report

6.04.02 Assess interrogation performance6.04.02.01 Assess the ease of use of interrogation6.04.02.02 Assess the performance of interrogation6.04.02.03 Determine requirement to add indexes6.04.02.04 Formulate strategy for improving ease of use and performance6.04.03.05 Create interrogation performance assessment report

6.04.03 Assess system control performance

6.04.03.01 Assess audit trail performance6.04.03.01.01 Assess acceptability at audit trail record content6.04.03.01.02 Assess acceptability of capture capability from all update sources & modes6.04.03.01.03 Assess acceptability of audit trail reports6.04.03.01.04 Assess acceptability of audit trail logical transactions within a multiple user

environment


94


6.04.03.01.05 Assess acceptability of audit trail transactions within a multiple databaseenvironment

6.04.03.01.06 Assess audit trail backup & recovery6.04.03.01.07 Assess audit trail capability to reorganize its record content6.04.03.01.08 Assess impact on data loading transactions6.04.03.01.09 Assess impact on data update transactions6.04.03.01.10 Assess impact on interrogation transactions6.04.03.01.11 Prepare audit trail acceptability report

6.04.03.02 Assess performance of backup & recovery6.04.03.02.01 Assess the acceptability of basic design6.04.03.02.02 Assess the adequacy of backup & recovery for batch type jobs6.04.03.02.03 Assess the adequacy of backup & recovery for on-line update6.04.03.02.04 Assess the adequacy of backup & recovery for logical transactions on multiple

databases6.04.03.02.05 Assess the adequacy of backup & recovery for high volume multi-user update in

batch & on-line6.04.03.02.06 Assess the adequacy of backup & recovery for the backup & recovery capabilities6.04.03.02.07 Assess the impact on data loading transactions6.04.03.02.08 Assess the impact on data update transactions6.04.03.02.09 Prepare backup & recovery acceptability report

6.04.03.03 Assess performance of message processing6.04.03.03.01 Examine messages to determine their understandability6.04.03.03.02 Determine whether message types can automatically trigger DBA created

messages6.04.03.03.03 Determine whether source & user identity of certain messages can be logged6.04.03.03.04 Determine whether message content can be changed or augmented6.04.03.03.05 Determine whether error processing can be enabled & disabled for certain run

units6.04.03.03.06 Determine impact on data update transactions6.04.03.03.07 Determine impact on data loading transactions6.04.03.03.08 Determine impact on interrogation transactions6.04.03.03.09 Prepare messages acceptability report

6.04.03.04 Assess completeness and performance of security & privacy6.04.03.04.01 Assess acceptability of DBMS mechanism to establish & maintain security &

privacy to determine ease of use6.04.03.04.02 Reevaluate the DBMS ability to protect security & privacy from O/S utility

tampering6.04.03.04.03 Reevaluate the security & privacy ability to protect row, column & relationship


95


6.04.03.04.04 Reevaluate the security & privacy ability to protection the basis of values,conditions, etc.

6.04.03.04.05 Reevaluate the security & privacy ability to meet specific needs stated in theconceptual specifications

6.04.03.04.06 Assess impact on data update transactions6.04.03.04.07 Assess impact on data loading transactions6.04.03.04.08 Assess impact on interrogation transactions6.04.03.04.09 Prepare security & privacy acceptability report

6.04.03.05 Assess performance of concurrent operations6.04.03.05.01 Assess DBMS capabilities to perform multiple update commands within all

languages6.04.03.05.02 Assess DBMS capabilities to perform multiple updates to the same database6.04.03.05.03 Assess DBMS capability to perform multiple updates to the same row6.04.03.05.04 Assess DBMS resources that are consumed to effect various concurrent access

controls6.04.03.05.05 Determine impact on production operations6.04.03.05.06 Prepare concurrent operations acceptability report

6.04.03.06 Assess sophistication of reorganization6.04.03.06.01 Assess DBMS capabilities to logically restructure a table to delete, modify or add

elements6.04.03.06.02 Assess DBMS capabilities to physically resequence rows within a table6.04.03.06.03 Assess DBMS capability to resize storage structure components without database

reloading6.04.03.06.04 Assess DBMS capability to add, change, or modify inter-table relationships6.04.03.06.05 Assess DBMS reorganization impact on production applications6.04.03.06.06 Prepare reorganization capability report

6.04.03.07 Assess sophistication of multiple database object processing6.04.03.07.01 Assess capability to operate multiple databases within one DBMS copy6.04.03.07.02 Assess capability to operate multiple databases from various DBMS languages6.04.03.07.03 Assess capability to operate database editions from DBMS languages6.04.03.07.04 Assess capability for multiple database update transaction audit trail logs6.04.03.07.05 Assess capability for multiple database backup &recovery & other system control

facilities6.04.03.07.06 Assess impact on production operations6.04.03.07.07 Prepare multiple database object processing capabilities report

6.04.03.08 Create system control assessment report6.04.03.08.01 Incorporate audit trail section


96


6.04.03.08.02 Incorporate message processing section6.04.03.08.03 Incorporate security & privacy section6.04.03.08.04 Incorporate database recovery section6.04.03.08.05 Incorporate concurrent operations section6.04.03.08.06 Incorporate multiple database section6.04.03.08.07 Incorporate reorganization section

6.04.04 Create logical database change requirements to accommodate performance6.04.04.01 Identify requirement to denormalize database structures6.04.04.01 Identify requirements for additional derived data6.04.04.01 Identify requirements for additional data integrity rules

6.04.05 Create consolidated application performance change requirements report6.04.05.01 Create logical database change requirements section6.04.05.02 Create physical database change requirements section6.04.05.03 Create interrogation change requirements section6.04.05.04 Create system control change requirements section

6.04.06 Create assessment to change ancillary support for application performance changerequirements

6.04.06.01 Assess requirements to revise database training6.04.06.02 Assess requirements to revise hotline6.04.06.03 Assess requirements to revise database standards6.04.06.04 Assess requirements to revise test data

6.04.07 Create consolidated application performance change requirements presentation6.04.07.01 Modify features, advantages and benefits (FAB) of database system6.04.07.02 Include FABs to create application performance change requirements impact

scenarios6.04.07.03 Create narrative for application performance change requirements scenario6.04.07.04 Identify key individual for review of application performance change

requirements scenario6.04.07.05 Review application performance change requirements scenario & narrative with

key individual and modify as appropriate 6.04.07.06 Create A/V materials for application performance change requirements scenario

presentation6.04.07.07 Review and finalize A/V materials prior to review

6.04.08 Conduct subphase review6.04.08.01 Present application performance change requirements assessment6.04.08.02 Receive and respond to comments


97


6.04.08.03 Modify application performance change requirements as necessary6.04.08.04 Seek concurrence with application performance change requirements

6.05 Determine database system maintenance policy

6.05.01 Select maintenance approach, methods, and tools

6.05.01.01 Determine maintenance approach6.05.01.01.01 Assign maintenance to development team6.05.01.01.02 Assign maintenance to special system maintenance team6.05.01.01.03 Assign maintenance to maintenance pool

6.05.01.02 Establish maintenance methods6.05.01.02.01 Make ad hoc changes6.05.01.02.02 Make batches of changes6.05.01.02.03 Make homogeneous change batches6.05.01.02.04 Make changes on determined time cycles

6.05.01.03 Identify and select maintenance tools6.05.01.03.01 Use formal application change procedures6.05.01.03.02 Use super zap type tools

6.05.01.04 Document selections and formalize findings

6.05.02 Determine procedures for standard and emergency maintenance6.05.02.01 Review and revise existing procedures or develop new ones6.05.02.02 Develop cases or scenarios to validate procedures

6.05.02.03 Establish control and feedback mechanisms6.05.02.03.01 Identify metabase system database reports for component changes6.05.02.03.02 Identify appropriate forms and reports for maintenance control and reporting6.05.02.03.03 Review and revise call lists for emergency and standard maintenance6.05.02.03.04 Establish maintenance review committees6.05.02.03.05 Review, revise, and publish control and reporting mechanisms

6.05.02.04 Publish standard and emergency maintenance procedures

6.05.03 Publish maintenance policy

6.06 Perform standard system maintenance


98


6.06.01 Identify and assign maintenance problem

6.06.01.01 Identify maintenance need6.06.01.01.01 Review error reports6.06.01.01.02 Solicit new requirements6.06.01.01.03 Propose enhancements6.06.01.01.04 Respond to government regulations

6.06.01.02 Document maintenance need6.06.01.02.01 Document conditions surrounding need6.06.01.02.02 Specify precisely need database objectives6.06.01.02.03 Indicate affected or related projects6.06.01.02.04 Identify metabase system database components affected6.06.01.02.05 Create maintenance need document

6.06.01.03 Analyze the maintenance need6.06.01.03.01 Obtain need evidence6.06.01.03.02 Organize evidence into cases or scenarios6.06.01.03.03 Classify as familiar or unfamiliar6.06.01.03.04 Investigate unfamiliar to uncover possible causes6.06.01.03.05 Compare known against other known problem areas6.06.01.03.06 Develop cause or solution hypothesis6.06.01.03.07 Test hypothesis6.06.01.03.08 Document the cause

6.06.01.04 Identify proper person/organization to solve problem6.06.01.04.01 Assign to general management if policy problem6.06.01.04.02 Assign to user of data entry or quality problem6.06.01.04.03 Assign to applications maintenance if application problem6.06.01.04.04 Assign to systems software if operating system type problem6.06.01.04.05 Assign to vendor if problem is package related

6.06.02 Analyze problem and estimate maintenance effort

6.06.02.01 Analyze problem, determine solution and work around6.06.02.01.01 Use metabase system database to identify components to change6.06.02.01.02 Review operations guides to identify needed changes6.06.02.01.03 Review training manuals or guides to identify needed changes6.06.02.01.04 Review computer support manuals to identify needed changes6.06.02.01.05 Review standards, policy, or procedures to identify needed changes6.06.02.01.06 Develop complete change material and review/revise as appropriate


99


6.06.02.01.07 Develop problem work around

6.06.02.02 Determine pervasiveness and issue alert as appropriate6.06.02.02.01 Determine problem impact on other systems6.06.02.02.02 Develop system impact statement6.06.02.02.03 Perform risk analysis to assess special fix or general solution6.06.02.02.04 For general solutions, develop plan6.06.02.02.05 For special fix, develop plan6.06.02.02.06 Develop notice for affected users

6.06.02.03 Determine alternative of choice and obtain approval

6.06.02.03.01 Identify alternative

6.06.02.03.02 Evaluate cost-benefit of alternative6.06.02.03.02.01 Determine cost to implement6.06.02.03.02.02 Determine cost to operate

6.06.02.03.02.03 Determine cost to convert6.06.02.03.02.03.01 Determine data conversion costs6.06.02.03.02.03.02 Determine program conversion costs6.06.02.03.02.03.03 Determine ancillary supports conversion costs

6.06.02.03.02.04 Determine annual benefits6.06.02.03.02.05 Determine rate of return or cash flow rate of return

6.06.02.03.03 Accept or reject alternative

6.06.02.04 Set priority of implementation6.06.02.05 Notify proponent of schedule of change

6.06.03 Accomplish the maintenance change

6.06.03.01 Create conceptual specification of change6.06.03.01.01 Estimate effort for conceptual specification of change

6.06.03.01.02 Identify entity instances that need to be changed6.06.03.01.02.01 Select and review mission description for change6.06.03.01.02.02 Select and review database domain for change6.06.03.01.02.03 Select and review business term for change6.06.03.01.02.04 Select and review database objects for change


100


6.06.03.01.02.05 Select and review columns for change6.06.03.01.02.06 Select and review tables for change6.06.03.01.02.07 Select and review tables for change6.06.03.01.02.08 Select and review data integrity rules for change6.06.03.01.02.09 Select and review information system processes for change6.06.03.01.02.10 Select and review primitive data transformations for change

6.06.03.01.03 Develop specific change transaction6.06.03.01.04 Evaluate entity instance change with respect to other applications use of instance6.06.03.01.05 Specify additional entity instances to accomplish change6.06.03.01.06 Formulate change transaction

6.06.03.01.07 Identify ancillary support changes6.06.03.01.07.01 Specify changes to training6.06.03.01.07.02 Specify changes to test data6.06.03.01.07.03 Specify changes to operational procedures6.06.03.01.07.04 Specify changes to external documentation6.06.03.01.07.05 Specify changes to hotline6.06.03.01.07.06 Create consolidated supports changes specification

6.06.03.01.08 Develop consolidated change document

6.06.03.02 Create implementation specification of change6.06.03.02.01 Estimate effort for implementation specification

6.06.03.02.02 Identify metadata that need to be changed6.06.03.02.02.01 Select and review schema DDL for change6.06.03.02.02.02 Select and review schema tables for change6.06.03.02.02.03 Select and review schema columns for change6.06.03.02.02.04 Select and review subsystems for change6.06.03.02.02.05 Select and review programs for change6.06.03.02.02.06 Select and review modules for change

6.06.03.02.03 Identify corresponding implemented system component to change6.06.03.02.03.01 Identify and review schemas for change6.06.03.02.03.02 Identify and review views for change6.06.03.02.03.03 Identify and review programs for change6.06.03.02.03.04 Identify and review modules for change6.06.03.02.03.05 Identify and review job control languages for change6.06.03.02.03.06 Identify and review non database files for change6.06.03.02.03.07 Identify and review test data for change


101


6.06.03.02.03.08 Identify and review internal documentation for change6.06.03.02.03.09 Identify and review system development tests for change

6.06.03.02.04 Develop specific change proposals6.06.03.02.05 Evaluate change with respect to other application users6.06.03.02.06 If compatible change, formulate changes6.06.03.02.07 If not compatible change, formulate additional components to accomplish change

6.06.03.02.08 Specify changes to ancillary supports6.06.03.02.08.01 Specify changes to training materials and procedures6.06.03.02.08.02 Specify changes to test data6.06.03.02.08.03 Specify changes to operational procedures6.06.03.02.08.04 Specify changes to external documentation6.06.03.02.08.05 Specify changes to hotline methods and practices6.06.03.02.08.06 Compile ancillary support change specifications

6.06.03.02.09 Develop consolidated change document

6.06.03.03 Implement the change6.06.03.03.01 Plan the change process6.06.03.03.02 Operate current system until change occurs6.06.03.03.03 Obtain needed access to software and data for change6.06.03.03.04 Acquire software change environment

6.06.03.03.05 Develop system development test requirements

6.06.03.03.05.01 Specify requirements for functional testing6.06.03.03.05.01.01 Develop checklist for conformance of metabase system database changes6.06.03.03.05.01.02 Develop checklist for conformance of system component changes6.06.03.03.05.01.03 Develop checklist for conformance of ancillary support changes6.06.03.03.05.01.04 Consolidate functional check lists

6.06.03.03.05.02 Develop success criteria for all tests6.06.03.03.05.03 Specify plan for regression testing6.06.03.03.05.04 Specify plan to investigate economy, efficiency, and effectiveness6.06.03.03.05.05 Specify plan for stress testing6.06.03.03.05.06 Create a consolidate SDT plan and document

6.06.03.03.06 Accomplish the change6.06.03.03.06.01 Accomplish metabase system database changes6.06.03.03.06.02 Accomplish system component changes


102


6.06.03.03.06.03 Accomplish ancillary support changes6.06.03.03.06.04 Create system development test testing package

6.06.03.04 Perform system development test on change6.06.03.04.01 Validate conformance to functional requirements

6.06.03.04.02 Perform unit, integration, & system testing6.06.03.04.02.01 Create environment for computer testing6.06.03.04.02.02 Create test data sets for tests6.06.03.04.02.03 Validate that unit performs function as specified6.06.03.04.02.04 Accomplish integration testing6.06.03.04.02.05 Accomplish system tests

6.06.03.04.03 Perform regression testing6.06.03.04.04 Perform stress testing6.06.03.04.05 Perform economy, efficiency, and effectiveness testing6.06.03.04.06 Prepare system development test report

6.06.03.05 Deliver the change6.06.03.05.01 Create consolidated change document6.06.03.05.02 Prepare and or package all deliverables prior to system development test6.06.03.05.03 Create notification of change completion

6.06.04 Plan and conduct system quality tests

6.06.04.01 Plan the system quality tests6.06.04.01.01 Identify artificial and production tests appropriate to validate correct production

environment.6.06.04.01.02 Identify method to acquire production environment or to use a subset without

change6.06.04.01.03 Create testing scenarios that simulate production environment6.06.04.01.04 Identify backup and recovery procedures for system operation6.06.04.01.05 Identify all ancillary supports and establish criteria for acceptance6.06.04.01.06 Establish system performance and test success criteria6.06.04.01.07 Identify all required operations, procedures, and guides that are to be evaluated6.06.04.01.08 Formulate complete system quality test plan

6.06.04.02 Conduct system quality tests6.06.04.02.01 Acquire system quality test environment

6.06.04.02.02 Accomplish database schema changes


103


6.06.04.02.02.01 Create modified database6.06.04.02.02.02 Reorganize database as needed

6.06.04.02.03 Install software into test environment6.06.04.02.04 Execute artificial tests6.06.04.02.05 Execute production tests6.06.04.02.06 If either tests fail, construct system quality test failure report6.06.04.02.07 If both tests pass, construct system quality test passes report

6.06.04.03 If system quality test fails, restore pretest environment6.06.04.04 If system quality test passes, proceed with production environment modification

6.06.05 Conduct required training6.06.05.01 Establish schedule for classes6.06.05.02 Determine needed facilities and equipment6.06.05.03 Accomplish training6.06.05.04 Obtain reviews of training

6.06.06 Install change into production6.06.06.01 Determine materials to change6.06.06.02 Create change package6.06.06.03 Distribute release materials6.06.06.04 Install change into production library6.06.06.05 Delete unnecessary facilities

6.06.06.06 Finalize changed system documentation6.06.06.06.01 Finalize metabase system database changes6.06.06.06.02 Finalize training materials changes6.06.06.06.03 Finalize external documentation changes6.06.06.06.04 Finalize internal documentation changes

6.06.07 Monitor database application6.06.07.01 Set or revise monitoring goals and database objectives

6.06.07.02 Set or revise standards of performance6.06.07.02.01 Set or revise standards for hotline6.06.07.02.02 Set or revise standards for training6.06.07.02.03 Set or revise standards for documentation6.06.07.02.04 Set or revise standards for system operation

6.06.07.03 Establish mechanisms of measurement and feedback


104


6.06.07.04 Monitor system operation6.06.07.05 Analyze reported problems

6.07 Perform emergency maintenance6.07.01 Document the problem6.07.02 Verify the problem through independent methods6.07.03 Determine solution to problems6.07.04 Acquire approval for change6.07.05 Change run-time modules6.07.06 Modify source code and create database object for production library6.07.07 Install change6.07.08 Create standard maintenance change request

6.08 Accomplish database system revision

6.08.01 Propose database system revision6.08.01.01 Define new/modified functions by subsystem6.08.01.02 Define scope of existing subsystem modifications6.08.01.03 Generally define the extent of logical database changes6.08.01.04 Generally define the extent of physical database changes6.08.01.05 Generally define the extent of system control changes6.08.01.06 Generally define the extent of documentation and training changes

6.08.01.07 Estimate the revision release schedule6.08.01.07.01 Logical database changes6.08.01.07.02 Physical database changes6.08.01.07.03 System control releases6.08.01.07.04 Ancillary supports

6.08.01.08 Create database system revision proposal presentation6.08.01.08.01 Identify features, advantages and benefits (FAB) of database revision6.08.01.08.02 Include FABs to justify database system revision6.08.01.08.03 Create narrative for database system revision review6.08.01.08.04 Identify key individual for review6.08.01.08.05 Review database revision with key individual and modify as appropriate6.08.01.08.06 Create A/V materials for database system revision presentation6.08.01.08.07 Review and finalize A/V materials

6.08.01.09 Conduct revision proposal review6.08.01.09.01 Present database system revision6.08.01.09.02 Receive and respond to comments


105


6.08.01.09.03 Modify revision as necessary6.08.01.09.04 Seek concurrence for revision work

6.08.01.10 Prepare estimate for revision6.08.01.11 Prepare revision project funding document6.08.01.12 Present for funding review

6.08.02 Prepare implementation strategy of revision6.08.02.01 Identify implementation alternatives6.08.02.02 Determine Gantt/PERT/CPM charts for each alternative6.08.02.03 Present alternatives for review and selection6.08.02.04 Consolidate Gantt, PERT, and CPM charts for selected alternatives6.08.02.05 Prepare system proposal for implementation phase6.08.02.06 Create implementation approach presentation6.08.02.07 Conduct subphase review

6.08.03 Implement revision6.08.03.01 Implement revised logical database6.08.03.01.01 Transform revised database6.08.03.01.02 Record details in transformation specification6.08.03.01.03 Create logical database implementation report6.08.03.01.04 Create logical database implementation presentation6.08.03.01.05 Conduct subphase review

6.08.03.02 Implement revised physical database6.08.03.02.01 Determine appropriate storage structure6.08.03.02.02 Determine access strategy6.08.03.02.03 Revise DDL, storage structure DDL & views6.08.03.02.04 Revise or design, then implement & test data update subsystem6.08.03.02.05 Revise or design, then implement & test data loading subsystem6.08.03.02.06 Revise data integrity subsystem6.08.03.02.07 Revise test data6.08.03.02.08 Revise database backup procedures6.08.03.02.09 Perform system development test on physical database6.08.03.02.10 Create physical database implementation report6.08.03.02.11 Create physical database implementation presentation6.08.03.02.12 Conduct subphase review

6.08.03.03 Implement interrogation subsystem revisions6.08.03.03.01 Create views6.08.03.03.02 Prototype through a natural language


106


6.08.03.03.03 Select cost efficient language6.08.03.03.04 Implement interrogation subsystem6.08.03.03.05 Perform system development test on interrogation subsystem6.08.03.03.06 Assess production impact6.08.03.03.07 Develop interrogation implementation report6.08.03.03.08 Create interrogation implementation presentation6.08.03.03.09 Conduct interrogation review

6.08.03.04 Accomplish system control changes

6.08.03.04.01 Revise fully supported DBMS facilities6.08.03.04.01.01 Determine mechanism to invoke facility6.08.03.04.01.02 Thoroughly validate facility with test database6.08.03.04.01.03 Estimate impact on production operations

6.08.03.04.02 Revise partially supported DBMS facilities6.08.03.04.02.01 Create design & specification for each program/module that must be

implemented6.08.03.04.02.02 Determine impact on logical, physical & interrogation database software

modules6.08.03.04.02.03 Estimate resources required for implementation6.08.03.04.02.04 Review design & resource estimate & schedule implementation6.08.03.04.02.05 Implement & test facilities against test database6.08.03.04.02.06 Estimate impact on production operations

6.08.03.04.03 Revise facilities not supported by DBMS6.08.03.04.03.01 Determine whether facility is available from other sources

6.08.03.04.03.02 Revise, then implement & test facilities6.08.03.04.03.02.01 Create or revise design & specification for each program/module that must

be implemented6.08.03.04.03.02.02 Determine impact on logical, physical & interrogation database software

modules6.08.03.04.03.02.03 Estimate resources required for implementation6.08.03.04.03.02.04 Review design & resource estimate & schedule implementation6.08.03.04.03.02.05 Implement & test facilities against test database part of DBMS

6.08.03.04.04 Revise utilization scenarios & fully test all facilities6.08.03.04.04.01 Determine conditions that necessitate facility utilization6.08.03.04.04.02 Determine method or procedures for facility invocation6.08.03.04.04.03 For recurring facility usage establish schedule of utilization


107


6.08.03.04.04.04 Create tests of facilities against various sizes & configurations of the testdatabase

6.08.03.04.04.05 Review production impact & adjust as necessary

6.08.03.04.05 Revise operations documentation & guides6.08.03.04.05.01 Revise operational documentation for each facility6.08.03.04.05.02 Revise schedules for periodic facilities6.08.03.04.05.03 Adjust system production costs by resource requirements for recurring

facilities6.08.03.04.05.04 Predict the number of occurrences of system control facilities that occur

only reactively6.08.03.04.05.05 Revise an overall production impact estimate, facility use procedures &

schedule for use

6.08.03.04.06 Create revised system control implementation report6.08.03.04.07 Create revised system control implementation presentation6.08.03.04.08 Conduct subphase review

6.08.04 Revise ancillary supports6.08.04.01 Revise database training6.08.04.02 Revise database hotline6.08.04.03 Revise database standards6.08.04.04 Revise test data

6.08.04.05 Develop database system documentation6.08.04.05.01 Develop internal database documentation6.08.04.05.02 Prepare user manuals

6.08.04.06 Prepare operations documentation6.08.04.07 Review & finalize all materials6.08.04.08 Prepare ancillary supports implementation reports6.08.04.09 Create ancillary supports presentation6.08.04.10 Conduct subphase review

6.08.05 Plan and conduct system quality tests

6.08.05.01 Plan the system quality tests6.08.05.01.01 Develop artificial and production tests appropriate to validate correct operation

within production environment6.08.05.01.02 Identify method to acquire production environment or to use a subset without

change


108


6.08.05.01.03 Create testing scenarios that simulate production environment6.08.05.01.04 Identify backup and recovery procedures for system operation6.08.05.01.05 Identify all ancillary supports and establish criteria for acceptance6.08.05.01.06 Establish system performance and test success criteria6.08.05.01.07 Identify all required operations, procedures, and guides that are to be evaluated6.08.05.01.08 Formulate complete system quality test plan

6.08.05.02 Conduct system quality tests6.08.05.02.01 Acquire system quality test environment

6.08.05.02.02 Accomplish database schema changes6.08.05.02.02.01 Create modified database6.08.05.02.02.02 Reorganize database as needed

6.08.05.02.03 Install software into production environment6.08.05.02.04 Execute artificial tests6.08.05.02.05 Execute production tests6.08.05.02.06 If either tests fail, construct system quality test failure report6.08.05.02.07 If both tests pass, construct system quality test passes report

6.08.05.03 If system quality test fails, restore pretest environment6.08.05.04 If system quality test passes, proceed with production environment modification

6.08.06 Prepare software release notice6.08.06.01 Create release numeric identifier6.08.06.02 Create release name if appropriate6.08.06.03 Determine exact release date6.08.06.04 Create summary of release6.08.06.05 Describe each new function or revision6.08.06.06 Describe each modification6.08.06.07 Describe the DDL changes6.08.06.08 Set down the release schedule for DDL, software, and data availability6.08.06.09 Enumerate the modifications or re-releases of documentation for user guides,

external and internal documents

6.08.07 Merge revision into production system6.08.07.01 Merge software into production environment6.08.07.02 Perform database DDL modifications as necessary6.08.07.03 Perform database reloads as necessary6.08.07.04 Perform data conversions as necessary


109


6.08.08 Perform enterprise model audit on evolution6.08.09 Conduct revision review

6.09 Perform enterprise database audit 6.09.01 Audit metabase system database components and note discrepancies by

identifying the items's unique identifier and suspected problem

6.09.01.01 Audit tasks6.09.01.01.01 Review each task to determine conformance to the Whitemarsh methodology6.09.01.01.02 Review task descriptions, deliverable names and descriptions for correctness

6.09.01.02 Audit task assignments6.09.01.02.01 Review assignments for completion dates, deliverable produced, and realistic

estimates6.09.01.02.02 Review task assignment estimates against actual charges to determine

unacceptable deviations

6.09.01.03 Audit charges6.09.01.03.01 Review charges in conjunction with task assignments, and tasks to determine

whether charge descriptions match tasks and assignments6.09.01.03.02 Make sure that persons submitting charges have submitted backup time sheets,

and are valid employees6.09.01.03.03 If the charges are for deliverables, require the identification of the deliverables to

validate the appropriateness of the charges

6.09.01.04 Audit persons6.09.01.04.01 Review all person records for correct data, spelling, non duplicates, and validity

for project work

6.09.01.05 Audit information system process6.09.01.05.01 Review each information system process for correct definition, naming, etc. for

relevance to actual business activities that occur6.09.01.05.02 Review all subordinate events, and the tree structure of nested information system

processes to ensure that each information system process is complete, and welldefined

6.09.01.05.03 Follow all information system processes to their terminal information systemprocess and verify correct utilization of database object processes and views.

6.09.01.06 Audit business terms6.09.01.06.01 Review each term for correct spelling, definition, abbreviation, and the like


110


6.09.01.06.02 Spot check the documentation, DBMS DDL, software source code for correctutilization, especially for abbreviations

6.09.01.07 Audit data integrity rules6.09.01.07.01 Review data integrity rules for correct definition, naming, and description6.09.01.07.02 Review columns and tables referenced by the Data integrity rule for correct

reference6.09.01.07.03 Review computer modules--indata integrity ruleectly referenced for correct

language specification6.09.01.07.04 Create data that violates a Data integrity rule and run an appropriate program to

test the effect. if the transaction is rejected, then the Data integrity rule is working

6.09.01.08 Audit mission descriptions and mission description diagrams6.09.01.08.01 Review the mission descriptions for correct name and definition6.09.01.08.02 Review the mission description diagrams for correct names, symbols, and symbol

interactions

6.09.01.09 Audit database domains6.09.01.09.01 Review the database domains for correct name and definition

6.09.01.10 Audit data elements6.09.01.10.01 Review for correct naming, definition, and example especially as it relates to the

mission description6.09.01.10.02 Identify all data elements not related to database table columns and justify

inclusion6.09.01.10.03 Verify that all element integrity rules are properly reflected in schema DDL or

data update modules6.09.01.10.04 Make sure that all data elements are allocated to at least one database domain6.09.01.10.05 Verify that appropriate need category is identified6.09.01.10.07 Verify that if there is a related data element value domain that it is correctly

defined and its values are correct

6.09.01.11 Audit database objects6.09.01.11.01 Review for correct definition, naming, etc. review for correct utilization within

the scope of a database domain6.09.01.11.02 Make sure all database objects are allocated to at least one business database

domain

6.09.01.11.03 Audit database object tables6.09.01.11.03.01 Identify all database object tables relate to the database object for correct

allocation


111


6.09.01.11.03.02 Verify that example is appropriate6.09.01.11.03.03 Verify that properties are correctly and appropriately defined6.09.01.11.03.04 Verify that appropriate need category is identified

6.09.01.11.04 Audit database object table processes6.09.01.11.04.01 Ensure that all database processes for database structure segment

existence tests are acceptable6.09.01.11.04.01 Ensure that all database processes for individual database structure

column tests are acceptable6.09.01.11.04.01 Ensure that all database processes for database structure segment

referential integrity tests are acceptable

6.09.01.11.05 Audit database object databases information systems6.09.01.11.05.01 Ensure that database object information systems retain database integrity

or rollback6.09.01.11.05.02 Ensure that all database object table processes are properly included in

database object business informations systems

6.09.01.11.06 Audit database object states6.09.01.11.06.01 Ensure that all business resource life cycle states are identified6.09.01.11.06.02 Ensure that all database object information systems are properly allocated

6.09.01.12 Audit tables6.09.01.12.01 Review tables for correct naming, definition, and the like6.09.01.12.02 Verify that each table corresponds to an appropriate database object and database

domain6.09.01.12.03 Verify that the elements allocated to the table cause it to be in third normal form.

if not,then justify nested structures. review load,update, and delete modules toverify that noun acceptable modifications occur

6.09.01.12.04 Verify that all tables related to DBMS tables6.09.01.12.05 Verify that table example is appropriate

6.09.01.13 Audit columns6.09.01.13.01 Review columns for correct naming, definition, etc. verify that correct elements,

tables, and tables are referenced6.09.01.13.02 Verify that one or more elements are correctly identified as a primary key or is

part of a primary key6.09.01.13.03 Make sure that each element's definition is a subordinate definition of a table, and

is included in a related database object's properties6.09.01.13.04 Review related Data integrity rule's for correct inclusion6.09.01.13.05 Review the element's function group for appropriate allocation


112


6.09.01.14 Audit database domain diagrams6.09.01.14.01 Review identified entities and relationships proper naming, and the like6.09.01.14.02 Ensure that each database domain diagrams maps to an appropriate database

domain and in turn to an appropriate mission descriptions

6.09.01.15 Audit inward and/or outward file specifications6.09.01.15.01 Review each file's file elements to ensure that the file elements accurately reflect

the file generation and/or reading programs used for generation/access6.09.01.15.02 Review each file element to ensure that the file element is correctly identified and

named6.09.01.15.03 Check that the file elements are correctly mapped to the appropriate external view

columns, database view columns, views, column, and table.6.09.01.15.04 Check that the file elements are utilizing the proper edit and validation checks6.09.01.15.05 Check that the inward or outward data conversions for file elements are correctly

specified and are programmed correctly

6.09.01.16 Audit edit and validation tables6.09.01.16.01 Review and validate each table for correct values and meanings6.09.01.16.02 Identify the element that uses the table and make sure that the values are

appropriate6.09.01.16.03 Review all the tables to find duplicates and recommend deletions where

appropriate

6.09.01.17 Audit user identifiers6.09.01.17.01 Review user identifiers for appropriate description6.09.01.17.02 Review library of files for each user identifier and clear out unnecessary ones if

possible6.09.01.17.03 Drop user identifiers that are no longer being used

6.09.01.18 Audit reports6.09.01.18.01 Review each report's report elements to ensure that the report elements accurately

reflect the report generation6.09.01.18.02 Review each report element to ensure that the report element is correctly

identified and named6.09.01.18.03 Check that the report elements are correctly mapped to the appropriate external

view columns, database view columns, views, column, and table.6.09.01.18.04 Check that the report elements are utilizing the proper edit and validation checks6.09.01.18.05 Check that the outward data conversions for report elements are correctly

specified and are programmed correctly


113


6.09.01.18.01 Review the report's name, description, headers, footers, control breaks and allcalculated report elements that defines the report to ensure that the data producedaccurately reflects the headings

6.09.01.19 Audit policies6.09.01.19.01 Review the policy name, description, and proper citation6.09.01.19.02 Review the database objects, mission descriptions, database domains, and

elements to ensure appropriate references

6.09.01.19 Audit screens6.09.01.20.01 Review each screen's screen elements to ensure that they accurately reflect the

screen programs used for data entry6.09.01.20.02 Review each screen element to ensure that the screen element is correctly

identified and named, and if applicable the appropriate help is displayed wheninvoked

6.09.01.20.03 Check that the screen elements are correctly mapped to the appropriate externalview columns, database view columns, views, column, and table.

6.09.01.20.04 Check that the screen elements are utilizing the proper edit and validation checks6.09.01.20.05 Check that the inward or outward data conversions for screen elements are

correctly specified and are programmed correctly

6.09.01.21 Audit schemas6.09.01.21.01 Review the name, description, DBMS name, and mission description referenced

by the schema for accuracy and clarity6.09.01.21.02 Examine all identified DBMS tables for correct relationships

6.09.01.22 Audit DBMS tables6.09.01.22.01 Review the name, DBMS name, and schema references6.09.01.22.02 Examine the identified tables of correct relationships to specification records6.09.01.22.03 Verify that the columns allocated to the table cause it to be in third normal form.

if not,then justify nested structures. review load,update, and delete modules toverify that unacceptable modifications occur

6.09.01.23 Audit DBMS columns6.09.01.23.01 Review all DBMS columns inclusions to verify correct naming, data type, picture,

and the like6.09.01.23.02 Verify that the picture is compatible with the DBMS column picture6.09.01.23.03 Access the related DBMS table, and specification DBMS columns to verify

appropriate references

6.09.01.24 Audit subsystems


114


6.09.01.24.01 Review the name and description of the subsystem to assess correctness6.09.01.24.02 Access related programs to determine if their overall purpose matches that of the

subsystem6.09.01.24.03 Access related mission description to determine appropriateness

6.09.01.25 Audit modules6.09.01.25.01 Review the name and description of the module to assess correctness6.09.01.25.02 Access the related programs to determine whether the module is actually present

in the source code6.09.01.25.03 Access the DBMS tables to determine if the module deals with the referenced

tables6.09.01.25.04 Access the primitive data transformations to determine whether the module's

purpose corresponds to that of the database object process's6.09.01.25.05 Access the actual module source code to review the database object process

requirements to the module's source language6.09.01.25.06 If the module contains a Data integrity rule, access the Data integrity rule through

column to determine the module is correctly identified as containing the Dataintegrity rule

6.09.01.26 Audit programs6.09.01.26.01 Review the name, description, and language of the program to assess correctness6.09.01.26.02 Access related modules to determine whether the description of the program is

supported by the module descriptions6.09.01.26.03 Access the subsystem description to assess whether the program's purpose

corresponds to that of the subsystem6.09.01.26.04 Access the program's code to determine whether all the modules are actually

present

6.09.02 Audit non-metabase system database data and computer programs

6.09.02.01 Audit program listings6.09.02.01.01 Determine that each program is identified by the metabase system database6.09.02.01.02 Review each program for adequate flow documentation and normalized top-down

structure6.09.02.01.03 Evaluate program for adequate cohesion, coupling, and the like6.09.02.01.04 Make sure each program-local variable is defined within the program6.09.02.01.05 Review the program's organization for ANSI standard language, and overall clear

and concise documentation6.09.02.01.06 If job control files are required to operate the program, make sure that these JCL

files are properly referenced from within the program, and the general descriptionof the purpose of the JCL is included


115


6.09.02.01.07 Whenever a program uses a non-database table and/or file, its name, purpose,structure, and general content should be clearly stated

6.09.02.01.08 Whenever a program uses a test data set its name, purpose, structure, and generalcontent should be clearly stated

6.09.02.02 Audit JCL listings6.09.02.02.01 Review each listing for clarity, comments, and clear statement of purpose, use,

and logic6.09.02.02.02 Ensure that each JCL listing contains references to the programs and/or data files

that are to be used6.09.02.02.03 Whenever a JCL procedure uses a test data set its name, purpose, structure, and

general content should be clearly stated

6.09.02.03 Audit database DDL6.09.02.03.01 Cross check each database DDL against that which is contained in the metabase

system database6.09.02.03.02 Cross check any schema-based integrity clauses for column and row integrity

with element and data integrity rules

6.09.02.04 Audit views6.09.02.04.01 Cross check each view that is contained in the metabase system database

6.09.02.05 Audit non database tables and files6.09.02.05.01 Review each identified (from programs and JCL) for correct name, purpose,

content, and structure that is implied by the program or JCL file6.09.02.05.02 Identify all other tables and files and determine why it has not been properly

identified as belonging to a program or a JCL file6.09.02.05.03 Access the metabase system database to determine that all tables and files are

properly defined within the metabase system database

6.09.02.06 Audit test data sets6.09.02.06.01 Review each identified (from programs and JCL) for correct name, purpose,

content, and structure that is implied by the program or JCL file6.09.02.06.02 Identify all other test data sets and determine why it has not been properly

identified as belonging to a program or a JCL file6.09.02.06.03 Access the metabase system database to determine that all test data sets are

properly defined within the metabase system database

6.09.02.07 Audit source library and version generation system6.09.02.07.01 The structure, content, and linguistic organization of the source library should be

thoroughly evaluated for clarity, and orthogonality


116


6.09.02.07.02 Create tests of software source with already known results to determine adequacyof the procedures for testing the addition, deletion, and modification of dataintegrity rules, modules, programs, nondatabase data files, etc

6.09.03 Audit ancillary support items

6.09.03.01 Audit database documentation6.09.03.01.01 Database documentation titles, descriptions, dates and versions as they exist in the

metabase system database should be reviewed to verify conformance to the actualpublications

6.09.03.01.02 The complete collection of database documentation should be evaluated todetermine its adequacy

6.09.03.01.03 The procedure by which database documentation is gathered should be examinedto determine whether the most current documents are collected and whether thecollection process is comprehensive and complete

6.09.03.01.04 Once the collection is produced, it should be evaluated for overall consistency,format, and clarity

6.09.03.02 Audit user manuals6.09.03.02.01 User documentation titles, descriptions, dates and versions as they exist in the

metabase system database should be reviewed to verify conformance to the actualpublications

6.09.03.02.02 The procedure by which user documentation is generated should be examined todetermine whether the most current information is included and whether thematerial is comprehensive and complete

6.09.03.03 Audit user help documentation6.09.03.03.01 The procedure by which user help documentation is generated should be

examined to determine whether the most current information is included andwhether the material is comprehensive and complete


6.09.03.04 Audit operations documentation6.09.03.04.01 Operations documentation titles, descriptions, dates and versions as they exist in

the metabase system database should be reviewed to verify conformance to actualpublications

6.09.03.04.02 The complete collection of operations documentation should be evaluated todetermine its adequacy


117


6.09.03.04.03 The procedure by which operations documentation is gathered should beexamined to determine whether the most current documents are collected andwhether the collection process is comprehensive and complete


6.09.03.04.05 For all procedures that accomplish normal system operation, that is, data entry,update, and reporting should be followed--exactly--to determine accuracy andoperations efficiency

6.09.03.04.06 For all procedures that accomplish abnormal system operations: securitymaintenance, backup and recovery, reorganization, database crash recovery, etc.should be followed--exactly--to determine accuracy and operations efficiency

6.09.03.05 Audit internal system and subsystem design documentation6.09.03.05.01 Internal system and subsystem documentation titles, descriptions, dates and

versions as they exist in the metabase system database should be reviewed toverify conformance to the actual publications

6.09.03.05.02 The complete collection of system and subsystem documentation should beevaluated to determine its adequacy

6.09.03.05.03 The documentation should indicate flow, interconnections, database andnondatabase data requirements, physical device requirements, printer outputs, andthe like

6.09.03.06 Audit hotline documentation, policies and procedures6.09.03.06.01 Hotline documentation policies and procedures titles, descriptions, dates and

versions as they exist in the metabase system database should be reviewed toverify conformance to the actual publications

6.09.03.06.02 The complete collection of hotline documentation should be evaluated todetermine its adequacy

6.09.03.06.03 The procedure by which hotline documentation is gathered should be examined todetermine whether the most current documents are collected and whether thecollection process is comprehensive and complete


6.09.03.06.05 All hotline procedures responding to normal operation questions: data entry,update, and reporting should be reviewed through typical scenarios to ensureadequate hotline personnel training, access to appropriate materials, etc

6.09.03.06.06 The procedures that log, classify, and account for hotline calls should be reviewedto determine whether the hotline reporting forms provide information regardingdatabase system adequacy, training sufficiency, performance, etc

6.09.03.07 Audit training materials for database, DBMS, and system use:


118


6.09.03.07.01 Training materials, titles, descriptions, dates and versions as they exist in themetabase system database should be reviewed to verify conformance to the actualpublications

6.09.03.07.02 Student evaluations should be reviewed to identify training problem areas, forexample, lab assignments, and lectures

6.09.03.07.03 Hotline call sheets should be reviewed to discover problem areas that might beaddressed by training

6.09.03.08 Audit system specification procedures6.09.03.08.01 The system specification, implementation, and operation procedures should be

reviewed to determine adequacy, completeness, clarity, and efficiency6.09.03.08.02 Evaluated should be the process of analyzing requirements, data entry, operations,

report production, user training, and the like

6.09.03.09 Audit system development tests6.09.03.09.01 Each system development test for each type of software, procedure, test data,

training materials documentation, etc., should be reviewed to ensure that thetesting procedures are valid, discriminating, and reliable

6.09.03.09.02 system quality test results should be reviewed to determine whether pass/failperformance reflects on the adequacy of the SDTs.

6.09.03.10 Audit system quality tests6.09.03.10.01 Each system quality test for each type of software, procedure, test data, training

materials documentation, etc., should be reviewed to ensure that the testingprocedures are valid,discriminating, and reliable

6.09.03.10.02 The process of notification of the testers should be reviewed to determinesufficiency of notice and a full awareness of the items being tested.

6.09.03.10.03 Enterprise model audit results should be reviewed to determine whether pass/failperformance reflects on the adequacy of the sdts.

6.09.03.11 Audit system audits6.09.03.11.01 The review the system audit procedure, and based on the results,modifications to

the system specification,implementation, and operation procedures accomplishedto lessen the quantity of enterprise model audit failures

6.09.04 Formulate audit report6.09.04.01 For specifications or documentation, indicate the type of revision required6.09.04.02 For data, test files, and tables, formulate change requirement6.09.04.03 For procedures, formulate scope of necessary change to procedure and test plan6.09.04.04 For computer program changes, formulate types of changes required, including

specification of test data, and test plan


119


6.09.04.05 Create combined change document for submittal as standard system maintenancetasks

6.09.05 Monitor database system operation6.09.05.01 Set or revise monitoring goals and database objectives

6.09.05.02 Set or revise standards of performance6.09.05.02.01 Set or revise standards for hotline6.09.05.02.02 Set or revise standards for training6.09.05.02.03 Set or revise standards for documentation6.09.05.02.04 Set or revise standards for system operation

6.09.05.03 Establish mechanisms of measurement and feedback6.09.05.04 Monitor system operation6.09.05.05 Generate system use statistics6.09.05.06 Analyze reported problems

6.09.06 Certify enterprise model audit pass/fail6.09.06.01 Review discrepancy reports from audit6.09.06.02 Review reported problems from system operation6.09.06.03 If no problems, then test passes6.09.06.04 If problems, then determine action plan for remediation and submit problems to

standard system maintenance procedure


120

INDEXAccess Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65, 66, 77, 106ANSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 93, 116Application Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12, 51, 99, 119Atomic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 28Audit Trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 44, 55, 67Backup . 10, 11, 35, 40, 41, 44, 45, 47, 50, 54, 55, 58, 60, 67, 72, 76, 77, 83, 84, 86, 95, 96, 103,

107, 109, 110, 118Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 45, 55, 67, 84, 86, 103, 109, 118Base Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 12Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53, 68, 69Binding Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53, 68, 69Business Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 39, 50Business Event Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Business Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9, 11, 39, 40, 50Business Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 3, 6-8, 12, 40Business Information System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 9, 11-13, 39Business Information System Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Business Information Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 8, 9, 12-14, 30, 31, 39, 40, 84Business Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 5Business Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Business Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7, 26, 40Business Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 30Business Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101CALC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65, 77, 114Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 40Characteristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 17, 27, 57Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-22, 24, 29, 40, 48, 59, 96, 112-116Computer Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Conceptual Specification Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 16, 49-51, 53Conceptual Value Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Concurrent Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 44, 45, 55, 59, 67, 74, 96, 97Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 29, 72, 117-119Conversion and Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Corporate Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53, 56, 68Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 16-18, 27, 28Data Conversion . . . . . . . . . . . . . . . . . 3, 4, 17, 22, 28, 36, 37, 39, 43, 45, 49, 75, 76, 82, 88, 100Data Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 18-20, 30, 112Data Element Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Data Element Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


121

Work Breakdown Structure Index

Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 9, 18-20, 27, 54, 111Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Data Integrity . . 9, 11, 18, 19, 22-25, 27-32, 35, 36, 38, 41, 46, 50, 54, 64-66, 71, 77, 78, 84, 92,

97, 101, 106, 111, 113, 115-117Data Integrity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 18, 27-30, 46, 50, 54Data Integrity Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-25, 28-30, 111, 115Data Integrity Rules . . 9, 11, 22-25, 28, 29, 31, 32, 35, 36, 38, 41, 54, 64, 66, 77, 78, 84, 92, 97,

101, 111, 116, 117Data Loading . . . . . . . . . 11, 34, 35, 47, 48, 50, 54, 58, 59, 61, 66, 72, 74-77, 82-84, 94-96, 106Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27, 47, 48, 58, 61, 71, 72Data Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Data Update Subsystem . . . . . . . . . . . . . . . . 11, 32-34, 50, 54, 66, 72, 76, 77, 79, 82, 83, 93, 106Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-29Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii, 1-30, 32-51, 53-69, 71-77, 79-89, 91-120Database Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27, 42, 43, 49, 60, 66Database Domain . . . . . . . . . . . . . . . . . . . . . 5, 6, 11, 17-19, 22, 29, 30, 49, 50, 54, 101, 111-113Database Domain Submodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Database Object . . . . 6, 17, 18, 20-27, 29, 30, 32, 33, 35, 36, 38, 39, 41, 60, 67, 92, 96, 97, 105,

111, 112, 115Database Object Information System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Database Object Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Database Object State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 27Database Object Table . . . . . . . . . . . . . . . . . . . . 18, 20-25, 27, 32, 33, 35, 36, 38, 39, 41, 92, 112Database Object Table Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-25Database Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 9, 82, 83Database Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Database Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41, 60, 77, 96Database View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 23, 28, 29, 113, 114Database View Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29DBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59, 95DBMS . . . . 10, 47, 48, 56-61, 64-68, 73-76, 78-82, 84, 92, 93, 96, 107, 108, 111, 113-115, 119DBMS Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115DBMS Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84DBMS Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115DDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47, 48, 58, 61, 72, 101, 106, 110, 111, 116Deliverable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 110Derived Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 22, 23, 25, 28, 97DML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73-76, 79, 93


122

Index

Document . . . 2, 4, 16, 17, 26, 33, 34, 36, 37, 39, 41, 48, 49, 53-56, 61, 62, 66, 71-73, 76-79, 81-86, 88, 91-93, 98, 99, 101-106, 108, 110, 111, 116-120

Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 6, 11, 17-19, 22, 27, 29, 30, 49, 50, 54, 101, 111-113Dynamic Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Element . . . . . . . . . . . . . . . . . . . . . . . . . 6, 17-20, 22, 25, 28-32, 34-36, 38, 45, 84, 111-114, 116End-user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 37, 110, 120Enterprise Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 110Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 17-19, 27, 101Extent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49, 66, 105External Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101, 102, 104External View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 23, 28, 29, 32-34, 36, 38, 113, 114Fact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6, 18Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 17, 29, 32-36, 38, 48, 72, 77, 79, 93, 113, 116, 117File Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32-34, 36, 38Form . . . 1, 8, 14, 16, 17, 19, 21, 27, 34, 37, 38, 42, 43, 48, 49, 53, 54, 71, 76, 78, 82, 88, 91, 92,

98, 112, 115, 117-119Function . 1, 6-9, 11, 16, 21, 23, 25, 28, 29, 32, 36, 38-40, 45-47, 50, 53, 71-73, 78, 88, 91, 102,

103, 110, 113Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8, 19, 54Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81, 83, 113Hotline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 83, 84, 92, 97, 101, 102, 105, 108, 118-120Implementation Phase . . . . . . . . . . . . . . 26, 32, 34-36, 39, 41-43, 68, 69, 71, 74, 75, 81, 87, 106Implementation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64, 66-69, 106Implemented Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47, 48, 58, 61, 71, 72Implemented Data Model Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48, 71Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Information . . . . . . . . . . . . i, iv, 2-4, 8-14, 17, 25-28, 30-42, 54, 84, 92, 101, 111, 112, 117-119Information Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Information System . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 9-14, 25, 26, 31-39, 41, 42, 54, 101, 111Information System Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32-34, 36, 38Information Systems Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8, 14Input Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 101Integrity 9, 11, 18, 19, 22-25, 27-32, 35, 36, 38, 41, 46, 50, 54, 55, 64-66, 71, 73-79, 84, 92, 93,

97, 101, 106, 111-113, 115-117Internal Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32, 34, 36, 38Interrogation . . . 10-12, 42-44, 47-51, 55, 56, 58, 59, 61, 63, 66, 68, 72, 77-80, 82-85, 87, 91-97,

107, 108Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 32, 34, 35, 39, 58, 76, 83, 84, 95, 102, 116Justify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49, 106, 111, 112, 115


123


Key . 1, 2, 4-9, 12-15, 21, 29, 30, 38, 42, 43, 46, 47, 51, 56, 57, 60-63, 65, 67-69, 77, 80, 82, 85,87, 89, 94, 97, 106, 113

Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47, 48, 60, 78, 79, 82, 92, 93, 107, 111, 115, 116Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8, 9, 12-14, 18, 26, 112Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 12, 32, 58, 72-74, 76, 78, 84, 95List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 4, 10, 16, 31, 35, 37, 50, 53, 71, 88, 91Logical Database . . . . 9-12, 16, 29, 30, 41, 44, 47-50, 53, 54, 56, 61, 63-65, 68, 71, 84, 97, 105,

106Logical Database Reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20, 23, 25, 28, 29, 38, 74Message Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58, 95, 97Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-25, 58, 59, 73-75, 79, 84, 93, 95Metabase . . . 2-9, 16-18, 20, 22-25, 27, 28, 32, 34, 36, 38-40, 53, 61-63, 71, 84, 88, 91, 98-100,

102-104, 110, 116-119Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 20, 32, 34, 36, 38, 101Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 12, 13Mission . . . . . . . . . . . . . . . . . . . . . . . . 3-10, 14, 17, 30, 31, 40, 47, 50, 54, 84, 101, 111, 113-115Mission Description . . . . . . . . . . . . . . . . . . . . . . 4, 5, 8-10, 17, 30, 31, 50, 54, 101, 111, 114, 115Mission Description Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4, 8Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 80, 82, 84, 93, 94, 107, 108, 115Natural Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78, 79, 82, 92, 93, 107Navigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40, 64Normalized Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20, 38Object . . . . 6, 17, 18, 20-27, 29, 30, 32, 33, 35, 36, 38, 39, 41, 60, 67, 92, 96, 97, 105, 111, 112,

115Operational Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8, 65, 67, 78Ordered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 4, 6, 7, 31, 33, 37, 40, 83, 99, 116, 117Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20, 23-25, 28, 29, 38, 64, 74Owner-member Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv, 99, 110Physical Database . . . 9-12, 30, 41, 42, 48-51, 54-56, 61, 63-65, 68, 72, 76, 77, 87, 94, 97, 105-

107Preliminary Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 8, 14-16, 91Primary Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 38, 47, 113Primitive Data Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54, 101, 115Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 44-46, 55, 59, 67, 81, 84, 92, 95-97Program . . . . . . . . . . . . . . . . 48, 61, 72-76, 79, 80, 84, 92, 93, 100, 107, 108, 111, 115-117, 120Project . . . . . 1, 2, 4, 9, 12-14, 16, 17, 19, 29, 42, 46, 53, 71, 78, 82, 83, 88, 89, 91, 92, 106, 110


124

Index

Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 12, 13Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 12, 13, 99Property Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47, 48, 56, 63, 73, 75, 76, 78, 83, 92, 107Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Record . . . . . . . . . . . . . . . . . . . . . . . . . 2-4, 6, 8, 17-19, 23-28, 31-40, 58, 64, 65, 84, 94, 95, 106Recovery . . . . . . . . . . . . . . . . . . . . . . 10, 44, 45, 47, 55, 58, 60, 67, 84, 86, 95-97, 103, 109, 118Referential Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 25, 28, 29, 64Relational Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 25, 28, 29Relationships . . . 2, 5, 6, 9, 18, 19, 22, 27, 33-35, 37, 39-45, 47, 49, 60, 64, 74, 92, 96, 113, 114Reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 45-47, 55, 59, 60, 84, 96, 97, 118Report . . . 8-12, 14-18, 27-30, 34, 41-50, 54-60, 62, 64, 66-69, 74-87, 89, 92-97, 103, 104, 106-

109, 114, 119, 120Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Resource . . . . . . . . . 1, 2, 8, 9, 11-14, 18, 26, 44, 46, 50, 73-76, 78-82, 86, 92, 93, 107, 108, 112Resource Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8, 9, 12-14, 18, 112Resource Life Cycle Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Resource Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 12, 13Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86, 104, 109Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 25, 28, 40Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72, 73, 112Row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-25, 28, 45, 59, 74, 75, 96, 116Schema . . . . . . . . . . . . . . . . . . . . . . . . 2, 47, 48, 71, 76, 84, 86, 101, 102, 104, 109, 111, 114, 116Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31, 32, 34-38, 114Screen Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31, 32, 34-36, 38, 114Security and Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45, 67, 81, 84, 92Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22, 112Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-25, 29, 42, 43, 57, 60, 62, 63, 68, 106Set . . 2, 12, 13, 16, 20, 21, 27, 38, 53, 71, 73-75, 79, 83, 85, 86, 88, 91, 93, 100, 103, 105, 109,

110, 116, 120Specified Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 12, 16, 40, 53, 71, 88, 91State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 26, 27Static Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Storage Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60, 65, 76, 96, 106Subject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv, 9, 27Subordinate Business Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7, 9Subordinate Database Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Subordinate Mission Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 31Subschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76


125


System . . . . . . . . . . . . . . . . . . . . . 2-18, 20, 22-51, 53-58, 60-69, 71-89, 91-94, 96-111, 115-120System Control . 10-12, 32-34, 36, 38, 44-46, 49-51, 55, 56, 58, 60, 61, 63, 66-69, 72-74, 79-85,

87, 91-94, 96, 97, 105, 107, 108System Quality Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 85, 86, 103, 104, 109, 119Table . . v, 18, 20-25, 27-29, 32, 33, 35, 36, 38-42, 45, 47, 48, 59, 60, 64-66, 71, 74, 75, 78, 84,

92, 96, 111-116Table Look up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32, 35, 38Table Primary Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 47Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 13, 16, 110Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Technical Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Test Data . . . . . . . . . . . . 48, 49, 55, 73-77, 79-84, 93, 97, 101-103, 106-108, 116, 117, 119, 120Third Normal Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 112, 115Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 47, 60, 72-74, 79, 94, 96, 101, 111Tree Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59, 95Update Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22, 49, 74, 75User . . 2, 4, 10, 16, 27, 31, 33, 37, 45, 48, 49, 58, 59, 81, 83, 84, 88, 95, 99, 108, 110, 113, 114,

117-119User Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88, 119Value Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27, 112Value Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 20Value-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47, 64Value-based Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47, 64View . . . . . . . . . . . . . . . . . . . . . 4, 17, 23, 24, 28, 29, 32-34, 36, 38, 48, 72, 73, 92, 113, 114, 116View Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Volatility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Warehouse Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i, iii, iv, 1, 12, 13, 100, 106, 110


126


A25 Data Management Documents Created by Whitemarsh vs documentsobtained by DHS/ICE from IV&V Contractor


75



SEVIS II Data Management Documents created by Michael M. Gorman with indication that the documents were obtained by DHS/ICE during 2nd

half of October, 2009

Id

Obtainedby ICEfrom

IV&VApproximate

Date

Title (BestRecollection)

and DeliverableType Size/Pages Description

1 No Early April Data ModelAnalysesType: Anomaly

57 items across4 data models,20 pages

The January 2009 functional data models were examined for qualityand comprehensiveness. A total of over 55 areas of concern wereidentified and described. This analysis was started on day 2 of the DataManagement IV&V assignment.

2 Yes Mid April Data ManagementIV&V Architectureand Concept ofOperationsType: SOW

60+ pages The data management I&V Process identified the specific items thatare created during the SEVIS II process that need to undergo analysisfor data management issues. Each item is cross referenced to fivelayers of data models that are accomplished in quality databaseprojects. Each item is supported by a detailed work breakdownstructure of activities that ultimately lead to a determination of riskeach item.

--- Yes Late April Four ObservedPotential Risks

6 pages This document, not remembered for inclusion in the original list of the19 documents lists four OPRs. These include: Contractor WorkBreakdown Structure, Data Management Products Schedule, DataManagement Components of Use Cases, Data Management Maturity


1

Enumeration and Description of Documents Produced and Documents Obtained by DHS/ICE from the IV& Contractor



Id

Obtainedby ICEfrom

IV&VApproximate

Date



Assessment

--- Yes Late April Data ManagementMaturityAssessment

1 page This document contained the data management maturity material fromthe four OPRs document..

--- Yes Late April Data ManagementComponents of UseCases

3 pages This document contained the use case material from the four OPRsdocument. It also contained a copy of the Data Management MaturityAssessment material from the previous document.

--- Yes Late April Work BreakdownStructure OPR

6 pages This document contains a detailing of the Work Breakdown StructureOPR that was identified in the Four Observed Potential Risksdocument.

3 Yes Mid May Data ManagementIssuesType: Anomaly

18 distinctitems

In preparation for the May IVV report, a white paper was created thatidentified 18 data management issues that were not being satisfactorilyaddressed in SEVIS II. Each item was identified, described and theconsequences set out if the items were not addressed.

4 No Late May Data ManagementSection for the May30 IV&V Bi-Monthly ReportType: IV&V Report

18 subsectionsto a DataManagementSection

A separate data management section for the May 30 IV&V report wascreated. It addressed the 18 items above and each was identified,described and a recommendation was engineered.


2




Id

Obtainedby ICEfrom

IV&VApproximate

Date



5 No Late May Data ManagementPlan ReviewType: Review

30 distinctcomments

An analysis of the data management plan was created against theDevelopment Contractor’s May 2009 data management plan. Thisanalysis had over 30 items, of which 13 items were red and almost allthe others were orange. The overall plan was “red.”

6 No Late May Data ConversionPlan ReviewType: Review

About 30specific items

A analysis of the data conversion plan was created against the May2009 data conversion plan put forward by the DevelopmentContractor. This analysis contained about 35 “medium” (orange)issues.

7 No Early June Product 6 Use CaseAnalyses re DataManagementType: Anomaly

16 Analyzeduse cases withabout 5 sectionsof analysis foreach analyzedcase

The use cases for Product 6 (EV Management) were examined indetail dealing with data management, data conversion, SystemRequirements Document, System Design Document. Each such usecase was examined for comprehensiveness and for attention tointegrity and quality.

8 No Mid June IV&V DataManagementConcernsType: Anomaly

11 Items thatare ofsignificance toSEVIS II

An overall list of data management concerns related to SEVIS II wascreated that needed priority attention within the project. Issues dealtwith Batch, SQL Views, DBMS Backup and Recovery, PerformanceTuning, Logical and Physical Reorganization, Data Security,Reference Data Management, Data Warehousing and BusinessIntelligence (a.k.a., reporting), Data Quality and Integritymanagement, and User Acceptance Testing


3




Id

Obtainedby ICEfrom

IV&VApproximate

Date



9 No Mid June Help Desk PlanReviewType: Review

Multi-page This short document presents an analysis of the help desk plan andidentifies areas where the plan could be improved so that it couldemploy data management artifacts and SEVIS II data directly into theoverall help desk effort. This document was developed during the HelpDesk Plan review but was never incorporated into the IV&V reviewdocument.

10 No Late June Analysis of DataManagementconcerns employingthe I-17 as theexample.Type: Anomaly

Multi-page This 13 page document presents the findings of the research into theneed for a comprehensive and detailed approach to the capture ofbusiness event history within SEVIS II. The key areas that wereaddressed were: Mappings among the SEVIS II work products, AuditTrails, History and Business Transactions (that became Business EventHistory), Reference Data Management, Business Rule Management,and End User Reporting.

11 Yes Late June SEVIS II DataManagementConcerns withConsequences andConclusionsType: Anomaly

Multi-page This 4 page document presents five of the 18 data management issuesthat were presented to the Development Contractor to determine theirapproach to resolving these items. It had been hoped that all 18 itemswould be discussed but only five were allowed to be presented by theIV&V Contractor’s CEO. Additionally, only two hours was allowedfor the presentation, questions, and answers.

--- Yes Late June Data ManagementIV&V Concerns

Single Page This document lists and briefly describes and then finally lists aquestion regarding 5 concerns to data management IV&V. These


4




Id

Obtainedby ICEfrom

IV&VApproximate

Date



concerns were to then be asked of the Implementation Contractor.They were.

12 No Late June CommunicationsPlan ReviewType: Review

Multi-page This short document presented a number of issues that existed in theCommunications Plan that was under review. Items addressed relatedto a more effective manner of developing findings, minutes, andrecommendations resulting from the many SEVIS II meetings. Material for this document was developed from my 30+ yearsexperience as the Secretary of the ANSI H2 Technical Committee onDatabase Languages that standardized the SQL Language. Thisdocument was developed during the Communications Plan review butwas never incorporated into the IV&V review document.

13 Yes, andYes

Late June through Mid August

Business EventHistoryType: OPRType: Anomaly

OPR and 20+page white paper includingillustrativesolution

A two-page OPR (observed potential risk) and a very extensive 20+page white paper was created to address one of the most critical SEVISII data management issues: Business Event Transactions. The whitepaper presented a comprehensive set of requirements from the FRD, anallocation of the 55 FRD identified and listed requirements on thissingle topic to Products 6 Use Cases, and an illustrated approach thatcan successfully handle SEVIS II Business Event History transactionmanagement.

14 Yes, andYes

Late June through Mid August

Reference DataType: OPR

OPR and 15 +page white

A two-page OPR (observed potential risk) and two white papers werecreated. The first white paper is 7 pages and is high level. The second


5




Id

Obtainedby ICEfrom

IV&VApproximate

Date



Type: Anomaly paper includingillustrativesolution

white paper is extensive 15+ page white paper was created to addressone of the most critical SEVIS II data management issues: ReferenceData. Six reference data cases were cited and illustrated how they existin SEVIS II. The effects from not addressing this type of reference datais also included in the white papers. The detailed white paper containsan illustrated solution for the Reference Data problem. A seventh casehas been created for Parameter-data such as critical dates, durationsbetween events, and the like that are to be set by and possibly changedover the life time of SEVIS II.

15 Yes Mid August RequirementsProcessOptimizationStrategyType: Anomaly

Multi-pagewhite paper

This document analyzes the current requirements analysis process. Ithas been clearly stated by the SEVP business owner that therequirements process is not working in an efficient and effectivemanner. This paper analyzes the overall process and sets out mitigationstrategies that help the overall process and especially the needs of datamanagement.

16 No Mid August Interfaces QualityAssurance CheckListType: Anomaly

Multi-pagelisting ofevaluationitems.

A multipage check list of items that need to be assessed for thecomplete life cycle of every interface between outside sources and theSEVIS II systems. Built in concert with the ICE interfaces agreementdocument and also similar documents from the U.S. Department ofJustice and the DoD Architecture Framework documents. Thisdocument will enable a reliable and repeatable process for assessing


6




Id

Obtainedby ICEfrom

IV&VApproximate

Date



SEVIS II interfaces, which exceeds 10.

17 No Late August Data Model QualityAssurance ChecklistType: Anomaly

Multi-page This document brings forward all the data management problems thathave been observed since March 23, 2009. This document was createdin anticipation of the existence of a complete new set of data models sothat the data model assessment done by early April could be broughtup to date. The document contains 8 sections: March/April DataManagement Problems, May 2009 Data Management Plan problems,May 2009 Data Management IV&V problems, Business Event Historyissues, Reference Data document issues, Parameters Issues, DAMA’sDM-BOK key assessment areas, and the Data Management IV&VArchitecture and Concept of Operations document sections. Each ofthese sections identifies the data management problems that wereidentified and cataloged when the referenced documents were created.

--- Yes Late September RequirementsSessions, DataModels, and DataManagement QA

5 pages This document presents the general process model for use cases,activity diagrams, and wire frames. The document identifies why it isan on-going mistake to have not had data modeling deeply involved inthese sessions. A specific example of how important this issue was tothe overall development of the SEVIS II specification that was thenbeing implemented.


7




Id

Obtainedby ICEfrom

IV&VApproximate

Date



18 No Late September Analysis of UseCase Data Elementsacross all the SEVISII Products (1, 2, 3,4, 6, & 7)Type: Anomaly

100 pages Identification of all use case data elements in terms of Reference Data,Master Data, and Parameter Data. Each use case data element ischaracterized by the Reference Data case to which it belongs so thatthe data models can be properly assessed in regards to whether theyproperly address the data requirements of the use case data element.

19 Yes Early October Analysis ofSeptember 29Delivery of SEVISII data ModelsType: Anomaly

55 pages This 55 page document contains the analysis of the delivered set ofdata models from the Development Contractor to the IV&V. Thesedata models were evaluated against 144 previously identified adversefindings and data management best practices and guidelines.

The 144 item checklist that was used to accomplish the data modelevaluation was developed from two sources. The first source was theApril through August adverse findings documents that I previouslycreated. The second source was the Data Management Association'sBook of Knowledge (DAMA DM-BOK). There were 113 items in thefirst set of documents and 31 items from the DAMA DM-BOK.

The final outcome of the Booz Allen Hamilton data model evaluationwas a 55 page document. Of the 144 evaluation items, 83 were unique;sixty-one were duplicate because they were reported multiple times inthe April through August adverse findings documents, or were also in


8




Id

Obtainedby ICEfrom

IV&VApproximate

Date



the DAMA DM-BOK. Of the 83 unique items, 55% continue to be"red," another 29% continue to be "orange," and only 12% are green.

20 No Current through10/9/09

Daily Activity LogType: Weekly

35 pages A daily log of activities since starting the data management IV&Vassignment at Burke Consortium.

21 No Current through10/9/09

Weekly StatusReportsType: Weekly

32 weeklystatus reports.

Weekly status reports to BCI staff. By direction, these only list titles ofactivities. Recently, these have included “Notes” at the end pointingout data management issues that highlighted from the various otherdocuments.


9


A26 Text of Email that identified the quantity of Whitemarsh work productsaccomplished on SEVIS II for DHS/ICE.


76

Email

From Michael M. Gorman, Whitemarsh

To Paul Martindale, Carol Wanzer, Wayne Smith

Date 10/12/2009

Subject Thank you for the Opportunity

I want to thank you, Carol and Paul for opportunity to bring over 40 years of experience onsystems like SEVIS II to bear over the past 6+ months. My participation on the project wasenabled by Shawn O'Rourke of American Systems. He indicated that I was chosen for thisassignment not only because of my significant data management experience but also because ofmy many years as a business information systems architect, engineer and developer.

During my data management analysis activities I developed a deep understanding of the effortand created a myriad of findings, analyses, and mitigation strategies dealing with the critical datamanagement issues enveloping SEVIS II. Created in all were 19 different documents whichincluded:

! 20 pages of adverse findings I uncovered from the January 2009 data models from BoozAllen Hamilton. These findings were completed within a week of my assignment. Thatis, by the first week of April 2009.

! A detailed review the Booz Allen Hamilton's May 2009 Data Management Plan. Thisreview contained over 30 adverse findings (13 were "red").

! A July 2009 Functional Requirements Document (FRD) based white paper and approachto capture, record, integrate, and report SEVIS II business event history and activities.

! An assessment of Booz Allen Hamilton's September 2009 data models against 144previously identified adverse findings and deviations from data management bestpractices and guidelines. This data model evaluation showed that 55% of the issuescontinue to be "red" and 33% remain "orange." Only 12% are "green."

While I was never given an opportunity to present and/or discuss my work products with youpersonally, I assume BCI shared my 19 different documents that contained reports, concerns andrecommendations.

I hope my contributions over these months have been beneficial to the respective parties. I havea vested interest in the SEVIS II program and the objective of protecting our nation. I know thatSEVIS II requires the massive collaboration and validation of enormous quantities data acrossmultiple agencies and data sources.

My analyses highlight the challenges of manipulating these data sources and presentingcomprehensive and creditable information to key organizations. Regrettably, my assessment ofthe current set of data models is that they do not exhibit the necessary levels of quality andintegrity that will enable SEVP to definitively defend SEVIS II outputs. While the data

management challenges seem complex, a coordinated integrated effort from all parties canovercome these challenges and establish data stability and creditability within the usercommunities.

Please do not hesitate to contact me should there be any questions about the documents that wereproduced supporting the SEVIS II program.


A27 Revised Business Event Management


77

Business Event Management





Table of Contents

1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Topics Covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

3. Rationale for Business Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

4. Business Event Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5. Solution Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.1 All Possible Business Event Context Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2 Actual Business Event Context Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5. Whitemarsh Methodology Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6. Metabase System Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17


ii


1. Objective

Data exists in two forms: Content-data, and Meta-data. This short paper is all about content-data,not about metadata. Within content data there are two broad classifications: "context", and"real." Real data includes, for example, a person's social security number, birth date, propername, and the like. This paper is not about real data.

Context relates to the business events that occur that cause real data to come intoexistence. Business Events exist in two forms: Possible and Actual.

Identifying and capturing both classes (Possible and Actual) of business events and theirsequences can be critical for database applications that must maintain detailed transactionhistories rendering and event auditing. Examples include include "chain of custody," finance,workflow, ordering, manufacturing, and human-activity tracking. Context data is critical to theproper recording of both kinds of business events, that is, Possible and Actual, and following onfrom that, the interrelationships between and among business events.

Both types of context data must address the six interrogatives: who, what, when, where,why, and how of the real data's capture, storage, interrelationships and maintenance.

This paper identifies, classifies, and defines these types of data and illustrates theirdefinition through a prototypical database design that necessarily must exist.

2. Topics Covered

The topics is this paper include:

! Rationale for business event management! Business event data structures! Solution approach! Whitemarsh methodology support! Whitemarsh metabase system support

3. Rationale for Business Event Management

Often, we see database schemas as large collections of database tables without recognizing thediscrete database table patterns for employees, companies, orders, invoices, and customers.Figure 1 illustrates just such a database. This entity-relationship style data warehouse data modelappears quite traditional and addresses customers, sales organizations, [product] componentitems, customer locations, orders and shipments, and sales statistics. The majority of data for thisdatabase comes from original data architecture-based databases and business informationsystems. The data for the database depicted in Figure 1 is extracted from the operational systemdatabases, likely recast, and stored in this data warehouse.


1


Each well-designed database table represents an encapsulated data-based policy instancesuch as an address, an employee’s biographic information, an invoice header or detail, or acustomer’s key contact information. Each such table is characterized by a name, a set ofcolumns, and if well designed, a primary key that is based on column-based business facts that,when valued, selects one and only one row.

A database table is, however, often part of a larger and more comprehensive set ofbusiness-based data known as a database object class. A database object class almost always is comprised of multiple functionally related database tables for something like Employees,Companies, Orders, Invoices, and Customers. Within Customer, for example, there would be acustomer's basic information, customer contacts, customer addresses, customer locations, and thelike. Each of these represents a table within the context of the Customer. Database objects,

Invoice Header

Order/Shipment Detail

Position Assignment

Position Type

Person)

Position

Subordinate Third Party

Third Party

Sales Organ-ization

Customer Location Role


Structure

Sales Organization

Structure

Sales Organization

Structure Type


Sales Statistics


Item Sales Statistics

Subordinate Customer Group

Customer GroupCustomer Group

Assignment

Customer Classification

Structure


Customer Classification Assignment

Sales Organization Position Assignment

Sales Organization Third Party Assignment

Component Item & Item Variant

Item Classification Assignment

Item Classification

Item Classification

Structure Type

Item Composition(Component Item

Structure)

Component ItemItem Variant

Group (Product)

Item Variant Type

Customer Location Role Structure Type


Type

Alternate Customer

Location Role Name

Alternate Customer

Location Role Name Type

Customer Location Call-

upon Information

Product Placement Information

Item Classification

Structure

Unit of Measure

Customer Location Telecom

InformationCustomer

Location Address Information

Customer

Customer Structure Type

CustomerStructure

Customer Location Role Debit/Credit Transaction

Customer Location Role Debit/Credit

Transaction Line

Warehouse

Warehouse Customer

Location Role Assignment

Warehouse Component Item

Inventory

Mars Calendarattaches to where

ever there is a date

Order/Shipment Header


Structure Type Customer Classification

Type

Customer Location

Sales Organization Position/Third Party

Customer Location RoleAssignment

Figure 1. Sales Data Warehouse.


2


regardless of persistence and regardless of whether single or multi-tables contain the samefour-part composition:

! Data Structure: Database object class data structures are the set of data structures thatmap onto the different value sets from multiple database tables for real world database.

! Database Object Process: Database object class processes are the set of computersoftware based processes that enforce the integrity of values from simple or complexcolumns, references between database objects and actions among contained data structuresegments, and the proper computer-based rules governing data structure segmentinsertion, modification, and deletion.

! Database Object Information System: Database object class information systems are the collections of specifications that control, sequence, and iterate the execution of variousdatabase object processes that, in turn, cause changes in database object states to achievespecific value-based states in conformance to the requirements of business policies. Forexample, the reception and database posting of data from business information systemactivities (screens, data edits, storage, interim reports, etc.).

! Database Object State: A database object class state represents the database objectafter-state of the successful accomplishment of one or more recognizable business events.Database object state changes are initiated through named business events that arecontained in business functions.

A set of data from a database object class that represents a policy-based well-defined instance iscalled a database object. Examples of database objects for Employee might be EmployeeRequisition, Employee Candidate, Employee Interviewed, Employee Hired, Employee Assigned,Employee Reviewed, Employee Promoted, and Employee Separated. Each named databaseobject consists of a subset of rows of valued columns across the database object’s tables thatmatch an engineered set of business rules.

Database object classes almost always have a root database table for a database objectclass and a set of subordinate database tables related to the root table through primary andforeign keys. Database object classes can have multiple levels to their hierarchies. From Figure1, Persons is a database object class. Position Type and Position is also a database object class.So too are Sales Organization, Customers, Invoices, and [product] Component Items.

From Figure 1, some database object class data structures are networks. Included in thesenetwork structures are customers, sales organizations, customer groupings, customerclassifications, component items, and item classifications.

Database object classes are often derived through use-case analyses. Use-cases are seenas collections of related business functions that employ discrete, recognized business processesthat are focused on employees, companies, orders, invoices, and customers. Use cases often end


3


up as software module collections that collect, store, update one or more database objects andreport business information from these database objects.

Database objects are not completely isolated one from another or from other enterpriseartifacts. Rather they are collected into subject related groups and are allocated to the essentialresources of the enterprise. From Figure 1, these enterprise resources include Persons,Customers, Component Items, and Sales Organizations. Other examples of enterprise resourcesmight be assets, facilities, finance, and reputation. Each of these resources proceed through well-defined resource life cycle states. Each resource life cycle state is evidenced through a collectionof database objects from one or more database object classes. Each resource life cycle state isachieved through the execution of one or more business information systems.

Clearly, a parallel structure between database objects and identifiable businessinformation systems functions exists. As business functions, via their business informationsystems, are executed, database objects are created, stored and updated. As the database objectsare created, stored, and modified, the states of the enterprise resources (persons, facilities,customers, etc.) change.

In spite of the existence of the database object classes, database objects, resources, and their resource life cycle states, the questions that cannot be answered are:

! When did the represented underlying database objects occur?! In what sequence did the underlying database objects occur?! What were the total set of all possible database objects?! What, from all possible database object classes, were the specific database objects that

did occur?! Who accomplished the various database objects and in what sequence?

For longitudinal, auditing, or historical research, it is necessary to address these questions. Missing from this two-part (business functions (via business information systems) and

database object classes) paradigm are business events. Here, a business event is the formalidentification of the execution of the business information system software that captures orupdates database objects. Business functions are fundamentally human-based processes.Business events are the instigators of database object class actions that effect discrete,identifiable, recognizable, trackable, inter-relatable, time-sequenced, and reportable databaserecords. For example, the creation of Employee Requisitions are the business functions. Thecreation of a specific Employee Requisition within the database is not only the instantiation ofone or more database objects through the business function supported business informationsystems, it must also be the instantiation of the “who, what, when, where, why, and how”information related to the employee requisition business event itself.

Each business event execution represents a business event transaction. Once developedinto executing software, business event transaction content data is captured through the businessinformation system software layer and is stored in the database as database objects.


4


The business event transaction’s data is the "who, what, when, where, why, and how"about each time-sequenced, business event-driven execution. This business event transactiondata is created with each business event execution.

Database designs, however, seldom support the capture of data about 1) the businessevent transactions themselves, 2) the history of business event transactions, or 3) theinterrelationships among business event transactions. Rather, the database objects are oftenmerely stored in the database without all the “who, what, when, where, why and how” contextdata.

Business events exit in two forms: possible and actual. The possible business events arethose that are anticipated to occur. These are identified through the business information systemmethodology tasks of requirements, analysis, and design. In contrast, actual business events arethose that actually occur. These exist as a consequence of end-user behavior.

Seldom defined and stored as “real” database data are the business events that are“possible” to occur versus which business events “actually” occur. Even more rarely stored arethe interrelationships between possible and actual business events.

If the context data is stored only at the database table level, lost will be the context datafor whole database objects. If context data is stored only at the actual business event level, lostwill be the ability to compare and contrast actual verus possible business events that wouldsupport the development of patterns that might be critical to the very missions served by thesebusiness information systems.

If the business events are not explicitly defined and manifest within the businessinformation software and database objects, the context of the business event transactions will belost during the capture of the database content data. Even more importantly, lost also will be thecontext and interrelationships of the business’ operations themselves.

4. Business Event Data Structures

Business event context data is needed for three types of commonlyseen database structures: single tables, hierarchies, and networks.Single tables such as Person should contain all the necessary data toreflect its purpose and intent. The captured business event contextdata only needs to relate to one row from the content table.

Hierarchical data structures commonly exist across multipletables such as Invoice Header and Detail, Order Header and Detail,and the like. Hierarchical business events often mirror the databaseobject data structures of database object classes. Figure 2 illustratesa multi-table business event for Position Type and Position. In thistype of hierarchy, the identifier (most likely) of the Position Type isa proper column in the Position table.

Position Type

Position

Figure 2. Multi-tableHierarchy


5


Another form of hierarchical data structure are self-referencing tables such as Organization contains Organization. Inthis case the value of the parent organization is contained as a valueof a column such as Parent Organization Id within the Organizationtable. This is illustrated in Figure 3. In hierarchical data structures,only one parent is allowed for each table.

Network-based business events are quite different fromhierarchical business events. Whenever a business event can beinvoked by multiple parent events, the business event conforms to a

network. For example, the business event, Order Entry, might invoke the child business event,Make a Payment. A different business event, Invoice Processing, accomplished by an on-linecustomer might also invoke the same contained business event, Make a Payment. What makesthis a network is that the “child,” Make a Payment, has two parents, Order Entry and InvoiceProcessing.

Other network examples include Organization Management. One organization mightmorph into multiple organizations and thereafter be absorbed into a consolidated organization.An organization that purchases three other organizations is a hierarchy. In contrast, anorganization that is the result of the merger of two other organizations is a network. Anothercommon network example is reference data. A value set that takes one value and divides it intotwo others is hierarchy, while the merger of three values into one value is a network.

Because business event transactions such as Make a Payment can have multiple parentsas well as multiple children, the business event transaction's data structure has to be a network.Without a network structure, that is, with only a hierarchical data structure, data redundancy andsubsequently, conflicts occur. That ultimately leads to update errors as multiple records requireupdate when there should have only been one update.

There are two types of network structures that need to be addressed with respect tobusiness events. The first, shown in Figure 4, is a traditional many-to-many network. It has two“parent” tables and one “interrelationship” table.

Organization

Figure 3. Self-referencing hierarchy.


6


In this form of a network there are three tables. The Person table is essentially anemployee. The Position table represents the functional jobs of the enterprise. The PositionAssignment table represents an association between a person and the position that the personoccupies. Commonly, the Position Assignment table has a Position Assignment Start Date and aPosition Assignment End Date. Often, these dates are not allowed to overlap.

The minimal quantity of business event context data that must be represented here mustaddress the Position Assignment table. While the other two tables, Person and Position, existindependently from the Position Assignment data, the Position Assignment business event mightrequire knowledge of the Person and Position for there to be a complete set of business eventcontext data.

The second type of network structure is the bill-of-materials data structure. This datastructure contains three tables. It is illustrated in Figure 5. While this bill-of-materials network

data structure is commonly employed with product-based manufacturing applications, it hasapplicability to personnel, financial tracking, and workflow applications. This data structure isorganized to represent the relationships among instances of a single object. All three tablescomprise the database object class.

The Component Item table, in product composition applications holds all the product’sparts. The Component Item Structure table holds the interrelationships among all the parts and

Position Assignment

Person Position

Figure 4. Interrelationship-type Network Structure

Component ItemComponent Item

StructureComponent Item Structure Type

Figure 5. Bill of Materials Data Structure.


7


supporting part usage information such as quantities among the parts that comprise specificassemblies. The Component Item Structure Type table enables the classification of thecollections of Component Item Structures.

As an example, suppose the component item is a bicycle. For a bicycle, there is acollection of discrete contained components. Some of these contained components can beemployed multiple times throughout the bicycle. An example is a spoke for either a front or rearwheel, or a bolt and nut. The strategy of a bill of materials data structure is that a givencomponent item is represented once-only in the database no matter how many different times itis employed. The once-only representation is contained in the Component Item table.

There are two relationships between Component Item and Component Item Structure.The top relationship can be termed as an “Active” relationship such as “Contains.” An exampleis that the bicycle contains a frame, a front wheel, and a back wheel. In this example, therewould be four component items: Bicycle, Frame, Front Wheel, Back Wheel. There would be acontains relationship from Bicycle to Frame, to Front Wheel, and to Back Wheel. TheComponent ID value of the bicycle is stored in the Passive Id column of the Component ItemStructure table. The Active Id of the three relationship instances of the Component ItemStructure table that contains the Id of the Frame, the Front Wheel, and the Back Wheel.

Similarly, there is a second relationship that is passive in form. In this example, therelationship is “Is contained in.” There is thus a relationship from each of the containedcomponent items, that is, Frame, Front Wheel, and Back Wheel to the containing Bicyclecomponent item. The Component Id of the Frame, or Front Wheel, or Back Wheel is stored inthe Active Id column. The Component Id of the bicycle is stored in the Passive Id.

The purpose of the Component Item Structure Type table is to support classifications of collections of the Component Item Structure records. For example, “Contains” and “Is ContainedIn.” There could be different collections of Component Items such as metal, plastic, imported, ordomestic.

Similar to the multi-table network, the minimal required data necessary to represent thebusiness event is the Component Item Structure table. Most likely, however, the rows from theComponent Item and the Component Item Structure Type tables are also encapsulated within thebusiness event’s context data. The creation and maintenance of the Component Item data and theComponent Item Structure Type data is independent from the Component Item Structurerelationships that exist between and among Component Items.

Because of the myriad of different database table structures, that is, single tables, andcollections of interrelated hierarchical and network tables that map to enterprise business database objects and because of the inherent complexity of enterprise business functions and theircorresponding business events, the need for a robust solution to business event context data isreal and must be comprehensive.

5. Solution Approach


8


A comprehensive solution for business event management must address:

! Both possible and actual business events.! Simple, hierarchical and network based business events.

The overall strategy is to capture the context data for all business events that are possible tooccur, and to capture the context data for all business events that actually do occur. The contextdata for each business event exists independently from the content data. The business event datatakes on an “about-data” or metadata viewpoint. The context data must be related to the variousinstances of the content data.

Figure 6 illustrates an approach for 1) all possible business event transactions, 2) thehistory of actual business event transactions, and 3) the interrelationships between all possiblebusiness events, all actual business events, and between possible and actual business eventtransactions, and finally 4) the interrelationship between context data and content data. All threeblocks have internal relationships among their rows instances and also relationships betweenrows across the top, middle, and bottom blocks.


9


Business Event Class

#2 Contains, Is Contained in

#1, Requires,Is Required By

#1003, #104, #101, #2Organization contains

Charter

#1002, #102, #101, #2Organization contains

Business Unit

#1001, #103, #102, #1Business Unit requires

Key Contact

#1000, #103, #101, #1Organization requires

Key Contact

#104 Create Charter

Document

#103 Create Key Contact

#102 Create Business Unit

#101 Create Organization

Business Event Class Structure

Type

Business Event Class Structure

“Type Tables”

“Rows”


#2 Contains, Is Contained in

#1, Requires,Is Required By

#1003, #425, #5, #2Marketing Div contains Marketing Div Charter.

#1002, #179, #83, #1Chicago requires Mark

Johnson

#1001, #648, #5, #1Marketing requires

Harold Jackson

#1000, #83, #5, #2Marketing contains

Chicago Marketing Office

#425, #1003, Charter for

Marketing Div.

#179, #1000, Mark Johnson

#83, #1002, Chicago

Marketing Office

#5 , #1003, Marketing Division


Structure Type

Business Event Transaction Structure

“Type Tables”

“Rows”

#648, #1000, Harold Jackson.

#8943, #1003, “content” data for the charter of the

Marketing Division

Each Business Event Transaction, Business Event Transaction Structure, and Business Event Structure Type contains the “who, what, when, where, why, and

how” context data.

Figure 6. Double network structures to capture both business events and theircontexts.


10


Figure 6 shows three major blocks of tables. The top block represents all possible business eventtransactions. The middle block represents all actual business event transactions including thebusiness event’s contact data. That is, the “who, what, when, where, why and how” of each. Thebottom block represents that actual “content” data for a given business transaction.

5.1 All Possible Business Event Context Data

The top block from Figure 6 contains two classes of tables: "Type Tables" and "Instance" rows.In the top part of the top block there are three tables: Business Event Class, Business Event ClassStructure, and Business Event Class Structure Type. These tables, when instantiated, representall possible business events.

The Business Event Class table rows hold the name and descriptive data for eachdifferent business event that can possibly occur. These different business events are identifiedduring the business information system’s requirements and use case creation activities.Essentially, the Business Event Class table represents a data-based version of the businessinformation system’s processes.

The middle table, Business Event Class Structure, enables the capture of theinterrelationships among business event transaction classes. This represents the contextualizedhistory of all possible business events. Essentially, the Business Event Class Structure tablerepresents a data-based version of the interrelationships between and among all the businessinformation systems’s processes.

The middle table consists, at a minimum, its own identifier, the ActiveId (of thecontained part), the PassiveId (of the containing part), and a foreign key value to the BusinessEvent Class Structure Type table. The stylized name string in this table represents a <part><relationship> <part> sentence, as in Organization Contains Key Contact.

In both the top block (i.e., Business Event Class) and in the middle block (Business EventTransaction), the two middle tables show the Contains (or Requires) relationship as the “top”relationship line. The column that stores the Business Event Class row Id-value is the Passive Id.For example, the row ID value “101" from the Business Event Class row, #101 CreateOrganization, is shown in the middle table rows, #1000 and #1002. The value “101" iscontained in the third column of each of those two rows. Stylistically, the relationship line is the“top” line.

Two stylized set of names, Requires and Contains, were created to support the semanticsbetween the two related business events. That is, the meaning of the relationship between theActiveId referenced business event and the PassiveId referenced business event. The table,Business Event Class Structure Type, provides a descriptive name for the inter-relationship butalso the applicability to textually describe the meaning of the inter-relationship. In the firstinstance, it is "Requires" or "Is Required By." From the top block of Figure 6, the BusinessEvents Classes are:


11


! Create Organization! Create Business Unit! Create Key Contact! Create Charter Document

As a consequence of the development of the various uses cases of the business informationsystem, the Business Event Class Structures, which represents the interrelationships among thebusiness events are:

! Organization requires Key Contact! Business Unit requires Key Contact! Organization Contains Business Unit! Charter contains Organization

The Business Event Class Structure, has two child-to-parent relationships with Business EventClass. This enables a network. The top relationship line is an "active" relationship. For example,the record, “#1003, 104, 101, 2" essentially means “Organization contains and CharterDocument.” The “passive” relationship “bottom line” means “Charter Document is contained inOrganization.”

As another example and read in the “passive way, the relationship row, #1001 is KeyContract is required by Organization. Note also that #103 Create Key Contact is also required by#102 Create Business Unit. Because the key contact is a "child" of both Organization andBusiness Unit, the data structure is called a network. That's because a network uniquely enablesa child to be "owned" by multiple parents.

5.2 Actual Business Event Context Data

The middle block from Figure 6 also contains "type" and "instance" tables. In this second block,however, the "type" tables are at the bottom of the middle block so as to minimize “crossedlines.” The tables are Business Event Transaction, Business Event Transaction Structure, andBusiness Event Transaction Structure Type.

Note, the key naming differences between the top and middle block. The top blockcontains the word, Class, for all three of its tables. The middle black contains the word,Transaction, for its tables. “Class” is proper for the top block because it signifies business eventtypes. “Transaction” is proper for the middle block because it signifies business event instances.In short, the top block is a “Type” layer and the middle block is an “Instance” layer.

From the middle block, Business Event Transactions that actually occurred are:

! Create Marketing Division! Create Chicago Marketing Office


12


! Create Key Contact for <Mark Johnson>! Create Charter for Marketing Division! Create Key Contact for <Harold Jackson>

In these examples, the Business Event Transaction table not only contains its own Id value andthe descriptive information about the business event transaction, it also contains a column thatidentifies the Id value of the Business Event Class Structure row. This enables the mapping froman actually occurring Business Event Transaction back to its type Business Event ClassificationStructure row.

As a consequence of the execution of the business information system based use cases,the Business Event Transaction Structures, which represents the interrelationships among thebusiness event transactions that actually occurred are:

! Marketing contains Chicago Marketing Office! Marketing requires Harold Jackson! Chicago requires Mark Johnson! Marketing Division contains Marketing Division Charter

The instance example here is for the Marketing Division. The method of reading the rows is thesame as in the top block.

The value from having these “possible” and “actual” business event network data structures issignificant. For example, fFrom top to bottom, here’s what one set of data structures “says.”

! Organization contains Charter Document (1003, 104, 101, 2)! Marketing Division contains Marketing Division Charger Document (1003, 425, 5, 2, 2)! Content data for the charter for the marketing division (8943, 1003)

What can then be determined are all the business event transactions that occurred at the sametime that are related to each other, or are related to their corresponding “possible” business eventclasses.

Here, once the capture of a Marketing Division Charter is started, a prior step has to bethe capturing of the Charter's organization, which in this case is the Marketing Division. Eachorganization (e.g., the Marketing Division) is represented in the Business Event Transactiontable.

The “real” data for the Marketing Divisions data is not contained in any of these BusinessEvent Transaction, Business Event Transaction Structure, and Business Event Structure Typetables. Rather, what is contained is the business event context data for the Marketing Division.That is, the "when, how, where, why, who, and what" of each business event transaction. This isshown in the “box” that is below and to the right of the Charter contains Marketing Divisionbusiness event transaction structure row.


13


The content data for the Marketing Division is represented by the #8943 row at thebottom of Figure 6. This row has the foreign key value, #1003, back to the Marketing Divisionbusiness event transaction structure row that, in turn, has a foreign key value #5 back to theBusiness Event Transaction row, Marketing Division. That row, in turn, has a foreign key #1003back to the Business Event Class Structure row, Charter contains Organization, which, in turn,maps to the business events, Create Charter Document and Create Organization.

Figure 1, that is subseted in Figures 2 through 5, is the representation of the collection ofcontent tables. The inter-relationships among these content tables naturally exist in thedatabase’s design and are traversed through normal business information system processes. Ineach of these tables, there is a column that contains the foreign key value of the business event’stransaction table from the middle block. The role the middle block serves is to be able to accessall the other business event transactions that came before or that occurred after the creation ofupdate of the Marketing Division’s content data. The role of the top block is to set the actualbusiness event transactions within the context of all possible transactions.

All in all, these three collections of business event tables, that is, possible, actual, andcontent provide non-redundant, discrete, identifiable, recognizable, trackable, inter-relatable,time-sequenced, and reportable business event information across all business functions thatinvoke business events.

While this approach may appear indirect and somewhat complex, it represents industrystandard best practice for capturing business events, the contextual relationships among businessevents, and the various collections of business events.

The top and middle blocks of network structures are required because the first representsall possible business events and interrelationships, and the second represents all actual businessevents and relationships. Married together, business reports can be produced that not onlyindicate what is possible and even required, but also what has actually occurred. That providesthe ability to create critical reports of what actually exists and what remains missing.

Through this approach what can be captured are 1) the business event transactionsthemselves, 2) the history of business event transactions, and 3) the interrelationships amongbusiness event transactions.

5. Whitemarsh Methodology Support

This short paper set out a clear interdependence between a business’ process model that aremanifest through business events and specific database data representations of those businessprocess based business events. Figure 6 clearly shows that a form of the business event processesare records of data in both the top and middle blocks. These processes are identified throughexamining the artifacts produced from the Whitemarsh Methodology that contains about 125pages of work tasks. These tasks exist in all comprehensive database project methodologies.That table that follows contains the start of the methodology tasks that relate to the


14


identification, specification, and ultimate implementation of the business information systemprocesses and supporting database structures for capturing business event data.

MethodologyPhase

Task Number and Name Description of Effort

PreliminaryAnalysis

1.02.02.04 Identify, name, andbriefly describe the businessinformation systems

This task identifies and describes all the appropriatebusiness information system that need to be involvedin any existing maintenance and/or interfacing effort.When the business information systems are not yetdeveloped then they are merely identified here but arefurther detailed as to the business functions, databaseobjects, and business events that are involved.

1.02.02.06 Identify, name, andbriefly describe the businessfunctions ...

This task is the first real task to identify the humanfunctions that are to be performed. Ultimately thesefunctions are manifest as use cases that, whenimplemented cause the execution of business eventsthat in turn have to be properly captured and tracked.

1.04.01 Create Resource LifeCycles

This task enables the creation of all the resources andresource life cycle node. It also support the allocationof database object classes and business informationsystems to the identified and defined resource lifecycle nodes.


2.03.02 Create business eventmodel

This task accomplishes the identification andspecification of all th business events that are to beaccomplished that result in updates to the variousdatabases. These business event definitions occur inconjunction with the definition of the detailedbusiness function model.

2.03.03 Create detailed businessfunction model

This task is a follow on task to the PreliminaryAnalysis Phase task that accomplished a high levelidentification and definition of all the businessfunctions. Once the detailed business functions aredetermined the business events that are to beaccomplished are allocated. The business events, inturn, are associated with business information systemsand these detailed mission-organization-functions. Asthe use cases are detailed, the events within each usecase are mapped to the mission-organization-functions as well.

2.09 Validate through Prototyping This task is very important. That is because within theprototype a large majority and possibly even all thebusiness events will have been identified.Consequently, the business events can be cast as dataand stored in the database tables that correspond to


15


MethodologyPhase

Task Number and Name Description of Effort

the top and middle blocks of Figure 6.

Implementation 4.03.03.02.01.01 Create generaldesign for a transaction drivenprogram

This task provided additional detail and a firmeridentification of the business events that need to betracked within the business information systems.

4.03.03.02.01.03 Create design ofupdate transaction

This task provided additional detail and a firmeridentification of the business events that need to betracked within the business information systemsupdated transactions.

4.03.03.02.01.06 Createprogramming specifications foreach update transaction

This task provided additional detail and a firmeridentification of the business events that need to betracked within the programming specifications of thebusiness information systems updated transactions.This is needed to know which business event trackingdatabase tables need to be accessed including theappropriate columns, the setting of certain values fordates, person who has performed the updates, and thelike.

4.03.03.02.01.07 Createprogramming specification fortransaction rollback

This task is very important because in the event adatabase transaction is rolled back there may be aneed to create a business transaction cancellingtransaction that is stored in the business eventdatabase tables. It may be that the business event wasattempted but only that there was a computer failure.In this case, the attempt would likely still need to berecorded.

6. Metabase System Support

As the methodology tasks from Section 5 are accomplished, specification and implementationartifacts are created, interrelated, and are stored into the metabase. The metabase system modulesthat are directly involved in the accomplishment of business event management are:

Module Name Role in Business Event Management

Mission, Organization,Function Position Assignment

This module enables the capture of all the business functions that are involvedin the identification of the business events that need to be captured.

Business Information System This module enables the capture of the hierarchies and networks of businessinformation systems and their modules that ultimately are to be executed toaccomplish enterprise missions. This data becomes many of the Figure 6 top


16


Module Name Role in Business Event Management

and middle block records.

Data Element Model This module enables the specification of the business data elements that becomethe foundation semantics of attribute of entities and columns of table that in turnwill form the data structures necessary to capture the business event data.

Specified Data Model This module enables the creation of the data models based on the concepts thatmust be captured within the business event data models. Included in each datamodel are entities, attributes, and relationships. Attributes are mapped back todata elements from the data element model.

Implemented Data Model This module enables the creation of the data models based on the real databasesthat are to exist in support of the data structures for business event classes andtransactions. Included in each database models are tables, column, and inter-table relationships. Columns are mapped back to data elements from the dataelement model.

Operational Data Model This module enables the creation of the DBMS bound data models that willcontain the actual business event class and transaction that support businessevent capture, tracking and management. Included in each database models areDBMS tables, DBMS columns, and DBMS interrelationships.

View Data Model This module enables the creation of the specifications of specific interchangesbetween application systems that are tracking business events and the databasesthat are storing the tracked business events.

Resource Life Cycle Analysis This module enables the identification, capture, and interrelationships of theenterprise resources and their resource life cycle nodes that reflect the result ofthe execution of a collection of business events to achieve the resource lifecycle states necessary by the organizations as they execute their functions toaccomplish enterprise missions.

Database Object Model This model enables the complete specification of all the database tables andprocesses that are involved in the capture of the business events from across allthe business information systems. The database object classes are then allocatedto the Resource Life Cycle nodes.

Use Case Model (Spring2010)

This model is created during requirements analysis and design. It essentiallybecomes the detailed function model and is interrelated with the Mission-Organization-Function model, Database Object Classes, and the BusinessInformation Systems models. Each use case ultimately becomes theemployment of a business event.

Document and Form Model(January 2010)

This model is created during the requirements phase and identifies, describesand details the various forms and/or documents and contents of the forms anddocuments that must be addressed during the development of a completeinventory of business events. This model, like the use case model is interrelatedwith the Mission-Organization-Function model, and the Business InformationSystems models.


17


7. Conclusions

The practical application of the points made in this paper include:

! There is a clear rationale for the capture of critical business event data. That is, the “who,what, when, where, why, and how” of each business event transaction.

! There is a clear distinction between all possible business event transactions and all actualbusiness event transactions.

! The difference between the all-possible and the actual transactions need to be tracked andinterrelated so that critical behavior reports can be generated.

! The specifications necessary to capture business event transactions are independent fromthose that capture the content data associated with a database transaction.

! The database tables for a business event transaction are independent from the databasetransaction. Additionally, there are relationships among all the business eventtransactions, relationships to business event classes, and among the business eventtransactions and the database content transactions.

8. References

The following references to Whitemarsh materials provide a more detailed exposition practicalapplication of the significant content of this paper.

Paper URL

Comprehensive Metadata Management http://www.wiscorp.com/ComprehensiveMetadataManagement.pdf

Metabase Overview http://www.wiscorp.com/Metabase.zip

Whitemarsh Data Modeler, Architecture and Concept ofOperations

http://www.wiscorp.com/MetabaseDataModelerArchitectueandConceptofOperations.zip

Metabase User Guides http://www.wiscorp.com/MetabaseUserGuides.zip


18


Paper URL

Iterations of Database Design http://www.wiscorp.com/iterations_of_database_design.pdf

Data Management Conferences http://www.wiscorp.com/dama2002.ziphttp://www.wiscorp.com/dama2003.ziphttp://www.wiscorp.com/wrad2000.zip

The following documents are available for Whitemarsh Website Members. The URLs thatfollow provide descriptions of the pages. Members should log in and proceed to the appropriatepage, e.g., Enterprise Database, find the book, paper, or course and perform the download.

Paper URL

Data Management Program - Metadata ArchitectureFor Data Sharing

Data Management Program - Database InterfaceArchitectures

Data Management Program - Projects And Data-AssetProduct Specifications

Data Management Program - Work BreakdownStructures

Knowledge Worker Framework Database Objects

Managing Database - Four Critical Factors

http://www.wiscorp.com/wwmembr/mbr_products_edb.html

Work Breakdown Structures http://www.wiscorp.com/wwmembr/mbr_products_dp.html

Data Architecture Classes

Guidelines for Data Architecture Class - DataWarehouse

Iterations of Database Design

http://www.wiscorp.com/wwmembr/mbr_products_dd.html


19


Paper URL

Work Breakdown StructuresDatabase Project Work plan TemplatesInformation Systems DevelopmentMethodology Phases 1 and 2Whitemarsh Project EstimatingWork plan Development

http://www.wiscorp.com/wwmembr/mbr_products_dp.html









20


A28 Revised Reference Data Management


78


Table of Contents

1.0 Objective ............................................................................................................................ 1

2.0 Topics Covered .................................................................................................................. 1

3.0 Introduction ........................................................................................................................ 1

4.0 Reference Data Cases ........................................................................................................ 24.1 Single Content Columns ........................................................................................ 64.2 Multiple Content Columns ..................................................................................... 74.3 Sequenced Values .................................................................................................. 84.4 Mapped Values ...................................................................................................... 94.5 Discrete Values .................................................................................................... 124.6 Range of Values ................................................................................................... 13

5.0 Reference Data Updating and Maintenance .................................................................... 155.1 Single Content Column ........................................................................................ 155.2 Multiple Content Columns ................................................................................... 155.3 Sequenced ............................................................................................................ 155.4 Mapped Values .................................................................................................... 165.5 Discrete Values .................................................................................................... 165.6 Range Of Values .................................................................................................. 16

6.0 Recasting Data ................................................................................................................. 16

7.0 Conclusions ...................................................................................................................... 17

8.0 References ........................................................................................................................ 18


ii


1.0 Objective

The objective of this paper is to present the Whitemarsh approach to managing a very critical setof enterprise data: Reference Data. This short paper describes the rationale for reference data andits management, sets out the six most common reference data cases, a generalized data model formanaging reference data, descriptions of each of the six reference data cases, a strategy forreference data updating and maintenance, and finally, the recasting of existing reference data.

2.0 Topics Covered


! Rationale for Reference Data! Description of the Six Reference Data Cases! Generalized Data Model! Specifications of Six Reference Data Cases! Strategy for Reference Data Updating and Maintenance! Recasting Reference Data

3.0 Introduction

Reference data represents data-based object collection classification schemes. Each referencedata value should be orthogonal in terms of its semantics. Reference data values are employed touniquely distinguish one object collection from another.

Collections of objects can be characterized in multiple ways. Thus, there can be multiplereference-data based characterizations. Simple reference data consists of discrete valuesrepresenting single, easily distinguished meaning. Complex reference data contains multipleinter-related facts that are intrinsically related to each other, and in many situations have theirvalues changed in lock step.

An instance of reference data is almost always a row in a database table. As with all otherrows, there are four kinds of columns for each table: uniqueness columns, metadata columns,content columns, and relationship columns. Uniqueness columns represent a set of values thatcauses the selection of just one row. Metadata columns represent the reference data'sadjudication information. That is, the information that affirms the authoritativeness of the values.This normally contains who, what, when, where, why, and how context data. Content columnsrepresent the "real" data, and for a single reference data content column that would be just thereference data value and the reference data value meaning. The final column set, relationship,represents the columns that, when valued, provide the uniqueness value for a different row in thesame table (recursive relationship) or different table (child table for a parent-child relationship).


1


In this later situation, the uniqueness column set is often called the reference data table's primarykey.

Any database column that has a severely restricted value domain can be seen as referencedata. Additionally, whole collections of data, that is, multiple columns within a reference datatable, can also be seen as reference data. Reference data is often employed as sort fields,selection fields, and as "control breaks" for the purpose of statistical calculations. Sometimesreference data exists as single database columns, and other times reference data containsmultiple columns that act as collections, in concert. On occasion, the reference data columnvalues must "progress" from one value to the next in a strict sequence.

4.0 Reference Data Cases

The six common cases for managing reference data are presented in Table 1. Specific examplesfor each of these cases are provided in the tables (Tables 4 through 9) and are described in thesix subsections of this section. Table 2 of this section names and describes the database tables forthe data model for reference data. Included in these subsections are descriptions of the data thatneeds to exist in the various data model tables from the generalized data model for referencedata. Table 3 of this section describes the data that needs to be stored in the reference data tablesto accomplish proper value domain governance.

ReferenceData Case

Reference DataType

Description

1 Single Content Column A single column of reference data such as a person Gender (e.g.,female and male), Gender. See current practice above.

2 Multiple ContentColumn

Multiple columns that should be treated together.

3 Sequenced Single or multiple columns of reference data that proceed in astrict sequence. For example, Proposed, Draft, Final, andRevised.

4 Mapped Values Single or multiple columns of reference data that have changedvalues and/or meanings across time, or that represent a"transformed in" value from a set of inward interface processesor "transformed out" value for a set out outward interfaceprocesses. Mapped values may also represent a reduction in thequantity of "mapped to" values from a set of "mapped from"values. The converse is also possible.

5 Discrete Values Specific enumerated values that can be additionally allowed ordisallowed. There can be multiple sets of discrete values, someallowed and other disallowed.


2


ReferenceData Case

Reference DataType

Description

6 Range Of Values Specific ranges of values that can be additionally allowed ordisallowed. There can be multiple sets of value ranges, someallowed and other disallowed.

Table 1. Reference Data Cases

These six reference data cases can be incorporated within the data model design set out in Figure1. The database tables within the data model are set out in the Table 2.

Data Model for Reference Data

Code Fact TableCode Assignment

A Code Fact Table Code Assignment stores the assignment of a specific code type (e.g.Gender) value for one or more columns in various database content table columns. Thistable also contains both effective start and end dates.

Code Type A Code Type identifies the specific code type, such as Gender. Multiple content columnsare addressed in the Code Type Structure and Code Type Structure Type tables. Code Typevalues are addressed in the Code Value, Code Value Structure and Code Value StructureType tables.

Code TypeStructure

The Code Type Structure table supports the interrelationship of different Code Types thatare required for multiple content columns that contain values that must be modified inlock-step.

Code TypeStructure Type

The Code Type Structure Type table’s data contains the specification necessary to fullyunderstand the Code Type Structure records that a Code Type Structure Type recordgoverns. This sets out collections of Code Type columns that need to be addressed incombinations.

Code Value The Code Value table contains the specific values associated with a given Code Type.Each Code Value record contains the code, values, meaning, description, and effective startand end dates. The relationships that exist between and among code values are managed bythe Code Value Structure and Code Value Structure Type tables.

Code ValueStructure

The Code Value Structure table contains the specific interrelationships among code values.This table enables two classes of interrelationships. Sequencing, and value mappings.Sequencing is needed for value sets that progress from one value to the next. Valuemappings are needed support the changes in values for a given meaning across time. Valuemappings support equivalent values, merged values from previous multiple values anddiverged values from a common previous value.

Code ValueStructure Type

The Code Value Structure Type table’s data contains the specification necessary to fullyunderstand the Code Value Structure records that a Code Type Structure Type recordgoverns. This would set out collections of Code Values that need to be addressed inspecific collections.


3


Data Model for Reference Data

External Standard An External Standard is the specification that governs identified collections of Code Typesand their corresponding values. As the external standard changes over time, the values mayhave to migrate from one value set to the next. Value migration is managed by theappropriate Code Value tables.

External StandardOrganization

An External Standard Organization is the value domain standards creation organization.This might be an organization managed by ISO, ANSI, an industry association, or a formalworking group within an enterprise.

Fact Table A fact table is a surrogate name for a content database table that contains one or morecolumns that have restricted value domains that require reference-based value domainmanagement.

Policy Basis The Policy Basis table contains the necessary information to understand the policy basisfor a collection of Code Values from one or more Code Types. Essentially the Policy Basisdata represents the study organization that performs the analysis and formulation of theinitial, subsequent, and evolution of the various Code Type value sets.

Policy BasisMember

The Policy Basis Member table contains the names of the persons who participated in thedevelopment of the policy basis for the value sets appropriate for the various Code Types.

Policy Basis StudyMembership

Policy Basis Study Membership represents the interrelationship between Policy Basismembers and the Policy Basis studies that determine the Code Type value domains andsubsequent evolutions of these value domains.

Table 2. Database Tables for the Reference Data Model


4


Figure 1. Generalized Data Model for Reference Data.


5


For all of the six cases the following tables need to be populated with an appropriate set of datathat supports specific Code Types and Code Values. For the sequenced and mapped code values,this includes the policy basis for interrelationship among code values. For Code Types, thisincludes the relevant information within Code Type structures needed to support related CodeTypes. These tables are set out in Table 3.

Reference Data Table Involvement

External Standard The standard from the enterprise or an external organization that is to govern theexistence of the code types and the code values associated with the code types.

External StandardOrganization

The name and description of the organization charged with the creation of the referencedata standard. This could also be the working group within the organization that hascreated the code types and associated code values.

Policy Basis The description of the policy basis that governs the identification of the complete set ofcode values and by inference the code types that are to be managed.

Policy Basis Member The names of the members that belong to the value domain policy group charged withidentification and specification of the code types and code values.

Policy Basis StudyMembership

The association of the given policy basis members with the specific policy basis thatgoverns the Code Values and by inference Code Types.

Table 3. Database Tables for the Reference Data Model

4.1 Single Content Columns

An example of Case 1, Single Content Column reference data, is Gender. The involvedReference Data tables are identified and described in Table 4.

Reference Data Tables for Single Content Columns


The row of data from within the reference data table that contains the primary key valuethat, in turn becomes the foreign key value of the reference data column from within theappropriate fact table.

Code Type The row of data that contains the name of the code table column about which referencedata values are created. This row contains the effective start and end date for the CodeType. This is to ensure that the code value that exists is from a current Code Typecolumn.

Code Type Structure This is not necessary for this reference case.

Code Type StructureType

This is not necessary for this reference case.


6


Reference Data Tables for Single Content Columns

Code Value The row of data that contains the specific value, code, meaning and description that isrepresented by the appropriate column in the fact table. The effective start and end datesmust be appropriately set so that the represented fact table value represents a currentvalue.

Code Value Structure This is not necessary for this reference case.

Code Value StructureType


Fact Table The column from within the appropriate fact table that contains the reference datacolumn. The value from this column acts as a foreign key value reference to the CodeFact Table Code Assignment row that, in turn, represents the reference data Code Value.

Table 4. Database Tables for Single Content Columns

4.2 Multiple Content Columns

An example of Case 2, Multiple Content Column reference data, is postal addresses. In eachaddress there are valid triples: City, State, and Postal Code. It is often incorrect to only updateone of these columns without also updating its adjacent column’s value. The involved ReferenceData tables are identified and described in Table 5.

Reference Data Tables for Multiple Content Columns


The row of data from within the reference data table that contains the primary key valuethat, in turn, becomes the foreign key value of the reference data column from within theappropriate fact table.


Code Type Structure This table contains multiple rows of data, one each for the different Code Types thatmust be associated with each other as a multiple content columns. The relationship thatexists between the multiple columns essentially is: “Also involves” as the activerelationship and “Is involved with” as the passive relationship.


This table contains the multiple content column subset collection data that supports theidentification of collections of multiple content columns. In this example, the individualactive and passive descriptive names are identified and defined. Defined also is theoverall meaning of this Code Type Structure relationship type.

Code Value The row of data that contains the specific value, code, meaning and description that isrepresented by the appropriate column in the fact table. The effective start and end dates


7


Reference Data Tables for Multiple Content Columns

must be appropriately set so that the represented fact table value represents a currentvalue.

Code Value Structure This is not necessary for this reference case.




Table 5. Database Tables for Multiple Content Columns

4.3 Sequenced Values

An example of Case 3, Sequenced Values reference data are the various values for a document’sprogression state. For example, Proposed, Draft, Final, and Revised. The involved ReferenceData tables are identified and described in Table 6.

Reference Data Tables for Sequenced Values








Code Value Structure Rows of data from this table, ordered according to a specific sequence of values one tothe other.


This table contains the sequenced values subset collection data that supports theidentification of collections of sequences of values. In this example, the individual active


8


Reference Data Tables for Sequenced Values

and passive descriptive names are identified and defined. Defined also is the overallmeaning of this Code Value Structure relationship type.


Table 6. Database Tables for Sequenced Values

A variation on either the single content column or the multiple content column reference datatype is sequenced reference data. In the case, the reference data values must either proceed in aforward or backward strict sequence, or can skip values forward or backward. Regardless, thegeneral approach that is most commonly applicable is that any given value must be preceded bya previous value. For example, the values, Proposed, Draft, Final, and Revised. are essentiallyindicators of state-based on well-defined assessments of a document’s progression.

In the example, the rules may be that the Draft state cannot exist except as a successor toa Proposed state. Or, that the Revised state cannot be set without the Final state having beenachieved. Some states may exist in parallel and are only dependent on the prior state.

Representation of reference data sequence rules requires the employment of the CodeValue Structure and Code Value Structure Type reference data tables. When these tables areproperly valued, an application program can query an existing state and know what value is theallowed successor state. If an inappropriate value change is attempted, the data from thesereference data tables can be used to support a rejection. When these states are represented as datawithin the Code Value Structure data, they can be changed without 1) finding all the differentapplication programs in which they have been encoded, 2) propose and accomplish softwarechanges, 3) perform testing, and 4) modify user-guide documentation and the like.

With this strategy, single or multiple column reference data that is to be sequenced canbe represented. The value of managing this sequence as part of the reference data is that itprevents any required encoding of a sequence in the application programs. Additionally, rulescan be established and placed in the database that provides triggering information to theapplication program whenever any sequence "transgression" occurs.

4.4 Mapped Values

The ability to map reference data values one to another is needed for a number of differentreasons. The five most common cases are:

! Single or multiple content column value changes! Single value equivalences! Reduced quantity of reference data values


9


! Expanded quantity of reference data values! External interfaces to other application systems and databases

An example of single value equivalences is again, “Gender.” For example, 0 = Female = F =Mujer. The involved Reference Data tables are identified and described in Table 7.

Reference Data Tables for Mapped Values







Code Value The row of data that contains the specific value, code, meaning and description that isrepresented by the appropriate column in the fact table. The effective start and end datesmust be appropriately set so that the each of the acceptably represented fact table valuerepresents a current value.

Code Value Structure Rows of data from this table represent the interrelationships across all the code valuesthat are valid. The different cases that have to be mapped include: equivalent values, andformer and new values. In this last case, there are two subcases, a reduction in thequantity of former values that is replaced by a single new value, and an expansion in thequantity of a single former value that is replaced by a set of multiple new values. The“from” value is identified through a Code Value retrieval based on the ActiveId value.The “to” value is identified through a Code Value retrieval based on the PassiveId value.


This table contains the mapped values subset collection data that supports theidentification of collections of mapped of values. In this example, the individual activeand passive descriptive names are identified and defined. Defined also is the overallmeaning of this Code Value Structure relationship type.

For this specific example, there would be different sets of Code Value Structure Typedata for each of the five different cases. When a row of data from the Code ValueStructure data is retrieved, the Code Value Structure Type value enables the retrieval ofthe “type” information and also for the retrieval of the other Code Value Structure rowsthat represent the “from” or “to” value for that particular case.



10


Reference Data Tables for Mapped Values

Table 7. Database Tables for Mapped Values

In the first case, single or multiple content column value changes, whenever a single or multiplecontent column value changes, both the previous and current values may need to be interrelatedwithin the Code Value Structure table in order to represent history. Additionally, if the valuesare "changed in place" within the fact tables themselves, databases that contain millions ofrecords and significant quantities of reference data columns would require large quantities ofcomputer resources to effect the data value change. Not only would this be a waste of computerresources, all the backups of the database would have to be brought back on-line and have theirreference data values changed as well.

Through the strategy of a mapped Code Value Structure table, an existing value wouldbe retrieved, the effective end date would be discovered to be no longer valid, and the nowcurrent value would be retrieved.

For an actual example, if the value (e.g. Gender = "F”) is stored in the database and thevalue needs to be changed to "Female," then, when the change is needed, all the records with "F"have to be retrieved and the gender column value changed to "Female." This has two problems.First, the previous value of "F" is now lost if there hasn't been an audit trail record created foreach of the changed records, and second, there can be a significant quantity of computingresources expended for this change. If there were a million records and half were "F" then therewould have to be 500,000 records changed and also 500,000 audit trail records created.

The only practical alternative to this approach is to create the Code Value Structurerecords that interrelate the old value, “F,” to the now current value, "Female," that has as itsstarting date and time the very same ending date and time for the "F" reference data record. TheCode Value Structure record is the method that interrelates the "F" reference data record withthe "Female" Code Value record. With this approach, none of the half-million records have to bechanged. When the actual gender is needed for a person, the reference data value is retrieved.Because there is an "end date" value, the PassiveId value is employed to retrieve the currentvalue for that reference data field. This technique works when there is the same quantity of validvalues after a change as there was before.

In the second case, reduced quantity of reference data values, several values may bereplaced by a single value. Suppose there were the values: Proposed, Draft, Final, and Revised.Suppose the new set was to combine the values Proposed and Draft into just one value, Initial. Inthis case the two discrete values would have to point to the same new value. This approach isstraight forward if the mapping is always "forward." But if it's backwards, it would not beknown what the prior value for “Initial” had been. That is, either "Proposed" or "Draft."This toocan be addressed by “walking back” from the Code Value row to the Code Fact Table CodeAssignment row.

In the third case, expanded quantity of reference data values, suppose the current valuesare: Proposed, Draft, Final, and Revised. Suppose the new values are to be: Proposed, Draft,Preliminary Acceptance, Accepted, Final, and Revised. In this case, business rules need to be


11


created or changed that enable a re-casting of the reference data values. In this situation, notonly must these values be added to the Code Value table, the interrelationships among thesevalues and also the proper sequence must be added to the Code Value Sequence table. Therealso must be the identification of the business rules that would provide the unambiguousknowledge to know the conditions supporting the proper discernment of these new values. Thesebusiness rules must be properly added and/or modified within existing business informationsystems. If the business information systems had been properly designed these changes shouldbe minor.

In this third case, where there are interfaces to external systems either for data importingor exporting, there has to be Code Value mappings from the various reference data basedexternal system data fields to the current set of reference data. These fields have to bediscovered and their reference data values and meanings uncovered and stored in the referencedata tables. This effort is directly supported by the reference data tables in Figure 1.

In the fourth case, external interfaces to other application systems and databases, onimporting, an external data record is read, its fields and values are known, and known as well arethe transformed-to values. If all these values are stored in the Code Value tables, the dataimporting programs do not have to contain all these value transformation rules.

On exporting, this same general strategy applies for exporting data except in reverse. Ineither scenario, it is best to have the reference data tables contain all the value mappings and anynecessary supporting rules for value mappings so that they are explicitly visible, are data notprogram based, and can be more easily changed than from within programs.

4.5 Discrete Values

An example of Case 5, Discrete Values, Zip Code, again serves as a good example. That’sbecause the Code Values are able to be well defined and are discrete. The involved ReferenceData tables are identified and described in Table 8.

Discrete values reference data simply means that the values are enumerated. Forexample, the values 20716, 20717, 20718, 20720, and 20721. A common capability forrepresenting discrete values is the ability to indicate that certain discrete values are not allowed.So, if all between 20716 and 20718 but not 20719, then the list would either containmechanisms to express both.

Discrete value management can exist on either single content or multiple columns, andalso on sequenced value and mapped value columns.

Reference Data Tables for Discrete Values



Code Type The row of data that contains the name of the code table column about which reference


12


Reference Data Tables for Discrete Values

data values are created. This row contains the effective start and end date for the CodeType. This is to ensure that the code value that exists is from a current Code Typecolumn.

Code Type Structure If there is multiple code table columns involved, this table contains multiple rows ofdata, one each for the different Code Types that must be associated with each other as amultiple content columns. The relationship that exists between the multiple columnsessentially is: “Also involves” as the active relationship and “Is involved with” as thepassive relationship.


If there are multiple code table columns involved, this table contains the multiplecontent column subset collection data that supports the identification of collections ofmultiple content columns. In this example, the individual active and passive descriptivenames are identified and defined. Defined also is the overall meaning of this Code TypeStructure relationship type.


Note: the data model design shown in Figure 1 does not properly reflect the ability toexpress NOT values for discrete values. It also does not express the ability to have amixture of discrete and NOT sets of discrete values. Changes in the data model arenecessary to accomplish this capability.

Code ValueStructure





Table 8. Database Tables for Discrete Values

4.6 Range of Values

The immediately preceding example demonstrates the need to express ranges of values, such as20716 through 20718, or 20718 through 20721. Negative ranges are commonly expressible aswell. So, 20716 through 20718, but not 20719 would be expressible. Again, as in the last casethis could involve both single and multiple column cases. The involved Reference Data tablesare identified and described in Table 9.


13


Reference Data Tables for Range of Values




Code Type Structure If there is multiple code table columns involved, this table contains multiple rows ofdata, one each for the different Code Types that must be associated with each other as amultiple content columns. The relationship that exists between the multiple columnsessentially is: “Also involves” as the active relationship and “Is involved with” as thepassive relationship.


If there are multiple code table columns involved, this table contains the multiplecontent column subset collection data that supports the identification of collections ofmultiple content columns. In this example, the individual active and passive descriptivenames are identified and defined. Defined also is the overall meaning of this Code TypeStructure relationship type.

Code Value The row of data that contains the specific range of values, code, meaning and descriptionthat is represented by the appropriate column in the fact table. The effective start andend dates must be appropriately set so that the represented fact table value represents acurrent value.

Note: the data model design shown in Figure 1 does not properly reflect the ability toexpress ranges of values. Nor does it properly express NOT values for value ranges. Itdoes not contain the ability of mixtures of ranges of values and NOT sets of ranges ofvalues Finally, it does not express the ability to have a mixture of discrete and ranges ofvalues. Changes in the data model are necessary to accomplish this capability.

Code ValueStructure





Table 9. Database Tables for Range of Values


14


5.0 Reference Data Updating and Maintenance

Issues related to changes to reference data values parallels the Section 4 six reference data cases.Some of the update anomalies have already been addressed above and are cited. Of overallconcern is what happens to a reference data value that was once valid, and through a change, hasnow become invalid? In this situation, there will have to be a thorough examination of how theformerly valid reference data values were stored in the database. How are they discovered? Canit be automatic? Or should it ever be automatic? Regardless, how will the already stored invalidvalues be changed? Will prior generated reports have to be re-executed and the difference incounts and other statistical and/or financial summaries have to represented along withexplanation?

5.1 Single Content Column

The key issue with single content column value changes is whether history is to be retained ornot. If not, there is no need to retain the previous value. In this case, there would be an automaticand complete recasting of one value and meaning to a different value and meaning. However, ifhistory needs to be retained, this case immediately turns into a mapped value case where the oldvalues are mapped to the new values.

Of especial concern is whether a reference data value's meaning has changed. If it has,and if the new meaning is to have the prior meanings retained, then again, this case immediatelytransforms to a mapped values case.

5.2 Multiple Content Columns

The updating concerns in this case are the same as for single content columns except that thevalue changes are possibly tracked as collection.

5.3 Sequenced

Sequenced values are inherently more complex. That's because, for example, two additionalstates might have been introduced prior to a given state. All the business rules that enable anexact determination of all the states need to be very carefully examined to be assured that whenthe rules are executed the new set of sequenced states are able to materialized.


15


5.4 Mapped Values

Mapped values are also inherently more complex. That is because there will be prior mappingsand new mappings. Each changed mapping set has to have the same end-date and start-dates soas to avoid unmapped intervals. If the mappings change, the various statistics, especially as theyrelate to importing and exporting from external systems may change and need to be explained.This will be especially so in situations where the quantity of source and target mapped valueshave changed.

5.5 Discrete Values

Discrete values are similar to single content column values except if an existing value becomesno longer valid. For example, if there were the discrete values, 20716, 20717, 20718, 20720, and20721 and under a new scheme 20718 is now seen as invalid, the 20718 Value Case transformsto a mapped value case because the value 20718 might be mapped to either 20717 or 20720.Otherwise the reference data value becomes invalid and cannot remain in the database as such.If a new value is allowed, it may be necessary to revisit prior business event executions todetermine if previously excluded data should now be included. Similarly, if a value is no longerallowed, prior data inclusions would have to be discovered and examined to determine what todo about what now becomes invalid data.

5.6 Range Of Values

Ranges of values are similar to discrete values except if an existing begin or end value becomesno longer valid. For example, if there was the existing range, 20716 through 20717, and the newscheme was 20716 through 20721, an examination would have to be conducted to discover ifpreviously invalided records with the value 20718 and now need to be included. Similarly, if thenew range was 20716, through 20720, an examination of some existing records (e.g., 20721)that formerly passed a range test would have to be examined to determine appropriate actions.

6.0 Recasting Data

The most critical issue surrounding reference data is what to do when acceptable values change.Within the reference data community this is sometimes called "recasting." Simply, recastingmeans that when a reference data value and/or meaning are changed, the understanding resultingfrom effectively the same queries and/or reports may also change. The three common cases are:

! Single value change (with and without history).


16


! Organizational relationship change (with and without history)! Meaning Change (with and without history)

For the first case, single value change (with and without history), some changes are simple andothers are significantly more complex. Simple cases change, for example, the value of "F" to"Female." In this situation, there is no recasting of the meaning of reference data value, only thevalue itself. Reports that include historical data will have to be able to not only obtain referencedata values via their surrogate reference data values, but also have to discover and access anychanged values that are, by reference data design represented by different reference datasurrogate Id values.

For the second case, organizational relationship changes (with and without history), zipcodes provide a ready but simple example. Zip codes change from time to time. Some entirelynew ones are added, and some existing ones are split. For example, the "city", Hershey, PA doesnot really exist. It's just a U.S. Postal Service designation. If the USPS changes "Hershey, PA"to "Derry Township, PA" what happens to all the existing addresses for "Hershey, PA?" Thiswould cause certain existing addresses that were formerly valid to now be invalid. Additionally,it might appear that Deny Township doubled in size if the report was based on its zip code.More importantly is the possibility of invalid addresses that were once valid and are now storedin a database. How are they discovered? How are they corrected?

A more critical example of organizational relationship changes would be the history ofcertain organizations within a database. Organizations can change through either acquisitions orlosses. How is that history of changes reported over time? From one year to the next a givenorganization can take on a completely different set of statistics. If longitudinal graphs areshown, there could be some real surprises.

For the third case, meaning change (with and without history), reference data recastingcan be very problematic. For example, suppose there are five values before, such as Proposed,Draft, Final, Terminated and Revised. Suppose the meaning of Terminated is changed from itsmeaning, Administrative Reasons, to also be understood as Administrative and Fraud Reasons.Grant Applications that were formerly denied for simply administrative reasons may now beseen as being denied for a very different set of reasons. While such a change can beaccomplished through the reference data case, mapping, the real issue is reporting.

All these cases require very careful analysis and assessment to understand the completeimplications of making reference data changes. All three reference data recasting cases apply toall six of the reference data types.

7.0 Conclusions


! There is a critical need to reference data management as reference data are often the keycharacteristics employed for selection, counting, sorting, and grouping.


17


! There exists a generalized data model that can be employed for reference datamanagement.

! The six common cases that must be addressed to effect reference data management are:single content column, multiple content columns, sequenced values, mapped values,discrete values, and range of values.

! Strategies have to be created and set into motion to accomplish reference datamanagement that is both efficient and effective, and that maintains to the maximumextent possible, the histories of values and meanings as the values were originallyimplemented.

8.0 References


Paper URL

Data Modeler Architecture and Concept Of Operations

Reverse and Forward Engineering GuideMetabase Module User Guides

http://www.wiscorp.com/metabase_demo.html

Comprehensive Metadata Management (short paper). http://www.wiscorp.com/featured_papers.html

DAMA 2002 - Metadata Architecture for Enterprise WideData Sharing - Problem Specification DAMA 2003 - Metadata Architecture for Enterprise WideData Sharing - Problem Solution

http://www.wiscorp.com/DatabaseDesignInformation.html



18


Paper URL

Data Management Program - Data StandardsArchitectures And Implementation

Data Management Program - Engineering


Data Management Program - Tag And Post Vs DataStandardization

http://www.wiscorp.com/EnterpriseDatabase.htm

Iterations of Database Design http://www.wiscorp.com/DatabaseDesign.htm

Data Is Executed Policy http://www.wiscorp.com/DatabaseProjects.htm

A Column By Any Other Name is Not a Data ElementPresentation (several paper and courses)

Achieving Data Standardization (several papers, abook and courses)

Achieving Enterprise Wide Data SemanticsStandardization

An Old Saw That Just Wont Cut

An Old Saw That Just Wont Cut - SoftwareImplementation Report

Analysis of the DISA 8320 Data StandardizationApproach

Data Standardization Work Plan

The Data Standardization Problem

http://www.wiscorp.com/DataQuality.htm


19


A29 Manufacturing Project Plans


79

Manufacturing Project Plans





Table of Contents

1.0 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.0 Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

3.0 Understanding Work Breakdown Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.1 Understanding WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Homogeneous Wn&vBS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Heterogeneous Wn&vBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4 Work Plan Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.0 Highly Engineered Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.0 Standardized Project and Deliverables Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6.0 Assessing and Assigning Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.0 Project Plan Constriction and Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8.0 Recording Work and Generating Earned Value Reporting . . . . . . . . . . . . . . . . . . . . . . . 27

9.0 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

10.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


ii


1.0 Objective

The objective of this paper is to present the Whitemarsh approach to engineering project plansthrough the use of collections of standardized work breakdown structures, earned-value provenmetrics, and the management of these plans within a comprehensive metadata managementsystem, Metabase, that additionally supports earned value based reporting.

This paper asserts that there is no real difference between real-product metadata andproject-management data. Project management data is metadata because it represents anabstraction of real-projects. Both forms of these metadata overlap in content and purpose. Eachhowever has a different use-perspective. Real-product metadata serves to identify, catalog, andmanage metadata-based representations of deliverables (i.e., data and process models). Incontrast, project-management data identifies, catalogues, and manages the projects thatultimately result in the creation of real-product metadata.

Consequently, this paper asserts that because of the overlap of purpose and content, bothreal-product metadata and project-management data belong in the same database and should bemanaged by a common metadata management system. For Whitemarsh, that means the MetabaseSystem. As of the writing of this Short Paper, both the Metabase System and the Whitemarshproject management system exist but have not yet been integrated. The points of integration areobvious and were designed to be so. Additionally, the development environment employed byWhitemarsh enables the integration of these data and systems in just a few staff months.

2.0 Topics


! Understanding Work Breakdown Structures! Highly Engineered Project Management! Standardized Project and Deliverables Templates! Assessing and Assigning Staff! Project Plan Construction and Estimation! Recording Work and Generating Earned Value Reporting

More software projects have gone awry for lack of calendar time than for all other causescombined. Why is this cause of disaster so common? Five reasons come to mind.

! First, our techniques of estimating are poorly developed. More seriously, they reflect anunvoiced assumption which is quite untrue, i.e., that all will go well.

! Second, our estimating techniques fallaciously confuse hours expended with deliverablesaccomplished, hiding the assumption that men and months are interchangeable.


1


! Third, because we are uncertain of our estimates, software managers often lack thecourteous stubbornness of Antoine's chef. 1

! Fourth, schedule progress is poorly monitored. Techniques, which have been proven androutine in other engineering disciplines are considered radical innovations in InformationTechnology (IT).

! Fifth, when schedule slippage is recognized, the natural (and traditional) response is toadd manpower. Like dousing a fire with gasoline, this just makes matters worse, muchworse. 2

3.0 Understanding Work Breakdown Structures

A work breakdown structure (WBS) is the breakdown of work. That’s easy, but what’s thedefinition of “work?” First of all, is it a noun or a verb? If it is a noun, a WBS is a breakdown ofa product. If the work is a database schema, it’s the schema, the tables, the columns within thetables, the data types of the columns, and the like. But, if work is a verb, then a WBS is abreakdown of processes such as Perform Assessment, Design Database, Engineer Hardware,Accomplish Testing, Commence Production, and Perform Maintenance.

In all actuality, the answer to the question above is, Yes. Work is both a noun and a verb.Consequently, both breakdown structures exist. Not only that, but more breakdown structuresexist and they all have to be considered and employed appropriately to have successful projects.The set of breakdown structures include:

! Product WBS! Organization WBS! Finance WBS! Methodology WBS! Requirements WBS! Computing Infrastructure WBS

1 Written on the menu at Antoine's in New Orleans: "Good cooking takes time. If you are made to wait, it is to serve youbetter, and to please you." From Frederick P. Brooks, Jr., The Mythical Man-Month. Reading, MA: Addison-Wesley, 1975, page13.

2 Ibid, page 14.


2


These six breakdowns structures, all generally referred to as WBSs are involved in the creationof project work products. Figure 1 shows a general relationship. This figure illustrates that agiven project work product fits within the six breakdown structures provided in Table 1.

All IT projects are developed through project plans that commonly employ workbreakdown structures (WBS) of the classes listed above. This short paper concentrates on justtwo of the WBSs, that is, Methodology, which is hereinafter referred to as WvBS and theProduct, which is hereinafter referred to as WnBS. An overall project plan involves not onlythese two WBSs, but also the following additional four items:

! PERT chart, a network that shows task interrelationships! Unit effort estimates! Factors affecting unit effort estimates! Recording of real-work accomplishment

These four items are addressed in later sections of this paper.

ProjectWork

Product

OrganizationWork Breakdown

Structure

MethodologyWork Breakdown

Structure

RequirementsWork Breakdown

Structure

Computing InfrastructureWork Breakdown Structure

FinanceWork Breakdown

Structure

ProductWork Breakdown Structure

Figure 1. Project work product setting within critical breakdown structures.


3


Breakdown Structure Class Example Context Description

Product WBS A product from the Product WBS, such as Columns of a Table within aSchema.

Methodology WBS Accomplished by Task 2.2.2, Develop Data Model of Develop LogicalDatabase of Conceptual Specification Phase.

Requirements WBS A component of the Data Model of the Data Architecture within theTarget Architecture

Computing Infrastructure WBS Accomplished by the Data Modeling tool, xyz on the workstationswithin the servers of the 123 network node.

Finance WBS Paid for by the Enterprise Data Infrastructure Development Project.

Organization WBS Accomplished by the Data Modeling staff of the Enterprise DataGroup of Corporate Infrastructures.

Table 1. Work Breakdown Structure Classes and descriptions

3.1 Understanding WBS

The term work breakdown structure is commonly employed in projects. Its first word, work, ifnot understood by all, can lead to significant confusion. Within the U. S. Department of Defensecommunity, the word work is often seen as a noun. Thus, the term work breakdown structureimplies a hierarchical decomposition of the actual product being delivered.

In Information Technology (IT), the term work breakdown structure is also commonlyemployed in projects, but it is used as a verb! Thus, in IT, the term work breakdown structureimplies a hierarchical breakdown of the activities.

The misunderstanding is not so bad, however, because in the Continuous Flow Modelillustrated in Figure 2, both types (verbs and nouns) are employed. Through this Continuous-Flow process, several unique features are present:

! All four processes are concurrently executing.

! Changes to enterprise resources occur in unison, periodically, and in a very controlledmanner.

! A metadata management system, Metabase, always contains all the enterprise resourcespecifications: current or planned. Simply put, if an enterprise resource semantic is notwithin the metabase, it is not enterprise policy.

! All changes are planned, scheduled, measured, and subject to auditing, accounting, andtraceability.


4


! All documentation of all types is generated from the metabase.

The phrases from Figure 2 that comprise the process bubbles are verbs, the set of WvBS. In theMetabase System, the storage location of the products of an Management Information Systemsproject, the breakdown is really a WnBS. While the two are not the same, they are definitelyrelated, for example, Plan the Project and Project Plan.

There is, therefore, a strong correlation between activity lists (WvBS) and product lists(WnBS). Not surprisingly, if one project's product list is different from another project's productlist, the two activity lists are also likely to be different. This leads to the conclusion that sincethere are different and valid product lists (WnBS), there must also be different and validmethodologies (WvBS). The appropriate pairing of a WnBS with an appropriate WvBS is giventhis notation: Wv&nBS.

Figure 2. Continuous Flow Model.


5


For any particular project, then, if its product list is fundamentally different fromthat of another project, the methodologies must also be different.

In addition to pairing appropriate sets of Wv&nBS for specific projects, multiple customers mayrequire, for example, MISs in different subject areas. For example, one client had an MIS projectfor Government Grant and Loan Accounting. Another client had an MIS project for Program,Planning, and Budgeting (PBS). While both projects are MISs, and both could have beendeveloped through the same database project methodology, each client wanted to see their ownpersonalized work plan. A Wn&vBS needed to be developed for each customer, that is, one forthe Grants MIS and another for the PBS customer. While the customers may be satisfied, acontractor performing the work will appear to have undertaken very different projects when, infact, the structure and format of the real work products and the methodology employed areessentially the same. Lost from the contractor will be any internal attempt to measure workaccomplishment or performance across MIS projects, and any benefits from common training,use of a multiple-project repository, and the like.

These losses can be avoided if the contractor first has its own Wn&vBS for MISs. Fromthis internal MIS Wn&vBS, the contractor can build relationships between its own Wn&vBS andthat of the customer. Figure 3 presents a diagram that portrays such a set of relationships. Suchan arrangement permits contractor methodologies to be evaluated, improved, and audited overmany years and against many projects.

3.2 Homogeneous Wn&vBS.

In Figure 3, a project's methodology is represented by the methodology meta-entity and recursiverelationship on the top-right. The product list of the methodology is represented by the work-products schema meta-entity and recursive relationship on the bottom-right. As steps of themethodology produce product, intersection meta-entities (called the Methodology-Task BuildSequence) are created.

The Methodology-Task Build Sequence intersection table is more than just an intersectiontable because it must have a sequencing all its own so that the methodology and products can beaccomplished in a specific project-logical order. Figure 4 illustrates a set of Wn&vBS. TheWnBS is on the left side and shows the breakdown of the Conceptual Design. Conceptual designmay be the name of the overall product of the conceptual design phase. In a previous phase,Preliminary Analysis, there are other products such as mission model, high-level E-R diagrams,evaluation criteria, and so forth. In this hierarchy, three of the products, that is, logical model,physical model, and interrogation, are shown. Contained within the logical model are the E-Rdiagram, objects, and data elements.

On the right side of the figure is a WvBS. It shows the verb sequence of BuildConceptual Design down through three of the steps within Build Logical Database. Theintersection of the WnBS and the WvBS is shown at the bottom. Among the attributes contained


6


in the Build Sequence table would be sequence, start date and time, and expected stop date andtime. Other tables that could be attached to the build sequence table could be various time cardsfrom staff members performing work. And, related to the various rows from the WnBS tablecould be the actual work products themselves. For example, attached might be an entity-relationship diagram entity called Accounts Payable.

Analogous to the way the methodology and work products are organized and interrelatedon the right side of Figure 3, the client's project tasking and deliverables list are represented onthe left side of Figure 3. When requests for proposals (RFPs) are issued, the buyer often issueswhat is on the left. If the contractor is a quality contractor, the right side also already exists.How to intersect the two? The intersection records, all labeled cross-relationships, provide theexplanation.

Once the two Wn&vBS are created, a sophisticated contractor can quickly tell whetherthe RFP is one of quality. Assuming that the Wn&vBS of the contractor is valid, there will be agood match between the buyer's Wn&vBS and the seller's. If the match is not exact, fourpossibilities exist:

! The buyer is attempting to buy less than what is needed.! The buyer is attempting to buy more than what is needed.! The seller would build less than what is needed.! The seller would build more that what is needed.

Regardless of which alternative exists, the discrepancies have to be examined and resolvedbefore a quality proposal is generated and before a quality contract is consummated.

Figure 3. Interrelationships between standard and client workbreakdown structures.


7


Contract performance disputes are almost always based on unknown mismatchesbetween the client's and the contractor's Wn&vBS.

Every project has a product list that is more or less unique. For projects with homogeneousproduct sets, for example, a human resources system and an operating system, the specificproduct list for the HR system is different from the product list for an operating system. Includedin the differences would be the types of products, the types of tests, the interface products, and soforth. In this case, some of the products are likely to be the same in form but very different incontent.

Additionally, there may be a difference in the significance of one product over another.For example, extremely detailed logic design is required before an operating system is coded, butonly logic sketches are required for the HR system that is 4GL-based. Similarly, the databasedesign section for the HR system requires significant effort, while the effort may be nonexistentfor an operating system.

Figure 4. Illustrated instance interrelationships between WnBS and WvBS.


8


3.3 Heterogeneous Wn&vBS

For heterogeneous projects, for example, a command and control system for the military, theproduct list includes software, hardware, training, documentation, quality measures, standardsadherence, and so forth. Each of these products has a unique product list, that is, a unique WnBS.Furthermore, a command and control system for the U. S. Air Force would be somewhatdifferent than one for the Navy or the Army. A critical issue, then, is how to provide a unifiedWn&vBS to the client for diverse product sets (WnBS) and, by implication, diverse process sets(WvBS).

Figure 5 shows a data structure to handle heterogeneous Wn&vBSs. The center of thefigure is the same except that there are multiple hierarchies, one for each methodology.Similarly, there would be multiple subsets of the repository schema for each different producttype. The additional entities allow inter-WnBS and inter-WvBS relationships. Such relationshipsallow projects to identify, for example, the relationship between an HR data update subsystem,which is a product within an HR WnBS, and a particular computing hardware subsystem from anappropriate hardware WnBS. If the client's RFP is of quality, it too will have similar structures asdepicted on the left side of Figure 5.

Figure 6 illustrates a heterogeneous set of Wn&vBS. The project on the right side of thefigure is a particular enterprise database project. From Figure 3, there could be a multiple of suchprojects underway. There would then be multiple sets of the right side of the diagram. Severalmight be for the concurrent development of detailed data models for particular aspects of aninitial high-level E-R diagram effort.

Figure 5. Interrelationships between multiple standard and client work breakdownsstructures.


9


For example, there might have been the development of an overall E-R diagram thatincluded the finance area, and then three to six smaller projects to develop detailed data modelsfor accounts payable, procurement, receivables, general ledger, and cash flow management. Eachof these projects would have their own WvBS and would commonly contribute to different andto shared instances of the same WnBS.

There might also be, as depicted on the left side of the figure, a project underway toconfigure the overall set of hardware to accommodate an entirely new finance system. This, ofcourse, cannot be done until the data and processing requirements of the various enterprisedatabase projects are completed.

Figure 6 thus shows how the Wn&vBS for each project type would be created, and then,as illustrated on the bottom of Figure 6, the timing sequence of when all these project typesshould be finished.

Once all the various Wn&vBSs are developed, an overall schedule, satisfactory to boththe client and the contractor, must be created. Figure 7 shows the meeting of the minds betweenthe two parties. The two middle meta-entities at the ends show the client schedule and thecontractor schedule. And, the meta-entity at the bottom shows the matching between the twoschedules, or the detailed project schedule.

Figure 6. Interrelationships between Heterogeneous WnBS and WvBS/


10


3.4 Work Plan Summary

The approach to enterprise-wide database must be focused on only one objective: the successfulcompletions of database projects within and across the missions, organizations and functions ofthe enterprise.

A quality database project life cycle provides a clear cut path, and a common-senseapproach, to database projects. Using quality life cycles enables a project's costs and schedulesto be accurately projected and managed. The controls imposed by a quality life cycle enables theknowledge worker to identify what products are due, when they are due, and under what qualitymeasures the products are judged. Because each product is well defined, project members canfocus their work efforts. In short, knowledge work is accomplished more quickly and moreaccurately.

A quality life cycle reduces project anxiety as each next step is already set down and is alogical consequence of the prior step. Again, sharply focused targets translate into quality work.

Figure 7. Interrelationships between Wn&VBS, contractor, client schedules, andoverall schedule.


11


The methodology life cycle, along with all the estimates, knowledge worker productspecifications, actual products, and worker time cards indicating progress, must be stored in theMetabase System database. This ties project planning to product deliveries—in short, realproject management and control. Because the Metabase System is database-centric, cross-reference reports are easy to generate.

A quality database environment represents a complete solution to database needs. Itrepresents the time-tested, rigorously defined products necessary for organizations to accomplishdatabase projects successfully, the first time, and within budget.

The amount of work in creating a project plan and schedule, and controlling and trackinga project through its entire life cycle, should not be underestimated. Prudent project managersspend about 20-45 percent of the total project's cost on this task alone, depending on the overallsize of the project. This means that on a ten staff-year project of real work, at least another twostaff-years should be spent on its planning, scheduling, and ongoing control. Too little timecauses:

! Bad initial estimates due to poor work assessments! Inaccurate progress reporting during project execution! Under delivery of product, given required quality! Under delivery of quality, given required product

The next sections of this paper provide a highly engineered strategy that has been implementedto satisfy the following requirements:

1. Enterprise visibility of all projects.

2. Standardized project, task, and deliverables templates to ensure work product sharing andcomparative analysis.

3. Standardized work environment factors so that true accomplishment can be measured andproductivity improvements can be realistically accomplished.

4. Standardized staff assessments, assignments, productivity measures to ensure fair andaccurate assessments of staff quality and progress.

5. Deliverables based work reporting so that earned-value assessments of progress can bemade.


12


4.0 Highly Engineered Project Management

Highly engineered project management requires a database-centric system to capture andmanage the data critical to effective project management. Organizations taking an enterprise-approach must have a centralized database application for project management to avoid theproliferation of stove-pipe based projects.

As stated at the outset, there are significant overlaps in the metadata managed bymetadata management systems such as the Metabase System and the data managed by projectmanagement systems. In addition to the overlap and shared objectives and processes, there is acritical need to have an enterprise perspective on both versus a stove-pipe perspective.

For example, there are not only overlaps in organizational and staff data, the very objectsmanaged by a project management system, the deliverables, which are in fact, IT’s deliverables,that is, enterprise architecture components, data models, process models, business informationsystem models, and the like. Because of these overlaps, and because of shared goals andprocesses, an underway extension of the Metabase system is to have Project Management as aMetabase System module.

The project management module’s database’s design is depicted in Figure 8. It consistsof a number of entities. All these entities are traditional and are interconnected through one-to-many relationships except for those entities that show a one-to-many relationship from the entityto itself. Organization (upper right) contains such a relationship. This relationship means that theentity contains subordinate organizations. For example, an Information Technology organizationcontains the Information Resource Management organization, which in turn may contain theData Administration organization, and Database Administration organization.

The eight entities that are recursively are:

! Contract! Deliverable! Deliverable Template! Organization! Project Template Type! Resource! Task! Task Template

The entities from Figure 8 are also divided into six distinct clusters, which are:

! Contracts, organizations and contract [staff] resources! Resource and Resource Life Cycle Node! Project, Deliverable, and Task Templates! Project Staff


13


! Project Building and Estimation! Project Work

In general, the Contracts, Organizations, and Contract [staff] Resource cluster of entitiesrepresent the environment within which projects take place.

The Resource and Resource Life Cycle Node3 entity represents the target of the project,that is, the area of the business benefitted by the project. For example, for manufacturing,finance, human resources, or land use planning.

The Projects, Deliverable, and Task Templates entity cluster enables the definition of thetemplates employed in the actual building of projects. Defined across the enterprise, thesetemplates enable standard project execution and accomplishment measurement.

Staff

Phone

Phone Type

Status Type

State

Work

Assigned Task

Task

Project

Task Template

Project Template


Deliverable


Job Title

Organization


Resource

Role Type

Skill Level

Skill

Staff Skill Level


Work Environment

Factor


Contract

Contract Staff


Contract Role

Skill Level Type





Base Line

Base LineWEF

Base LineStaff

RLC Node

Figure 8. Data model for a highly engineered project management database.

3 Resource and resource life cycle node has the exact same definition as it does within theWhitemarsh metabase and also the process of Resource Life Cycle Analysis of Ron Ross.


14


The Project Staff entity cluster enables the inclusion of the staff as resources for acontract, and also permit the specification of the specific types and performance ratings of skillsthat a person may bring to a specific project.

The Project Building and Estimation entity cluster represents the entities that supportbuilding projects. Projects and associated tasks are initially created through the use of the ProjectDeliverables, and Tasks Templates. Once projects and associated tasks are created, they aremodified by attaching work environment factors and specific skill-level based staff assignments.Only then can task and project resources be computed.

Finally, as task work is accomplished, the Project Work entity is valued. As actual workis accomplished, it can be reported through any of its related entities.

5.0 Standardized Project and Deliverables Templates

The standardized Project and Deliverables templates involve the following entities from Figure8:

! Deliverable Template! Deliverable Template Type! Project Template! Project Template and Deliverable Template! Project Template and Task Template! Project Template Type! Task Template

The purpose of these entities is to pre-define classes of projects that are accomplished one ormore times. Even when a project is expected to be accomplished only once, it must first bedefined as a project template. The reason is simple: No matter how many times you may protestto the contrary, a project is never done only once. Further, the effort to create a project from thetemplate requires the push of only one button. Hence there is no real cost, only a real benefit.

A Project Template can be seen as being within a hierarchical class of projects. Thisgives rise to the notion of project template types. While clearly the strategy for identifyinghierarchical classes of project template types is subjective, the following project template typesare illustrative:

1 Training1.01 Needs Assessment1.02 Development1.03 Execution1.04 Evaluation2 Information Technology


15


2.01 Needs Assessment2.02 Tool Development2.03 Component2.03.01 Requirements2.03.02 Specification2.03.03 Implementation2.03.04 Evolution3 Metabase3.01 Requirements3.02 Component3.02.01 Development

These classes of project templates may mirror the various sections of a mission statement andmay take on several generic prefix “forms” such as: plan..., execute...., and evaluate....

Once project template classes are identified, the individual project templates within eachclass can be identified. For example, the following project templates would be suitable for theproject template type, Metabase Component Development.

! Enterprise data architectures! Data elements! Specified data models! Implemented data models! Operational data models! Business events! Database domains! Missions! Organizations

The names for these project template examples were all taken from the Knowledge WorkerFramework and other Whitemarsh materials. The goal here is to classify the possible types andkinds of projects that are likely to be accomplished within the organization. This classificationdoes not, however, relate to an enterprise’s resource, that is, Finance, Human ResourceDevelopment, Distribution, Manufacturing, etc. Rather, these project templates serve as themechanism to classify projects that address, for example the development of an enterprise dataarchitecture model within the enterprise resource, Human Resources, or the development of anOperational Data Model for a data warehouse data architecture class database, Retail SalesManagement.

Associated with each project template there are Deliverable Templates and Tasktemplates. These are independent of Project Templates so that standard Deliverable Templatesand Task Templates can be developed and employed within Project Templates. For example,every Project Template that creates a Knowledge Worker product is likely to contain a delivered


16


product presentation. For any given presentation, the deliverable is likely to be the same: that is,the presentation’s materials. Additionally, the work plan to create the presentation is also likelyto be the same.

To create the Project Template, Presentation, the Deliverable Template and TaskTemplate merely have to be associated to the Project Template by creating two intersectionentity instances, Project Template & Deliverable Template, and Project Template & TaskTemplate. This same multi-use strategy is likely to apply to Project Reviews, Testing Scenarios,User Guide Development, Project Plans, Phase Plans, and the like.

The deliverable template entity is recursive, and thus can contain subordinate deliverabletemplates. For example, a deliverable template may be the Enterprise Data Architecture.Contained within it would be the Database Domains, Database Objects, Data Elements, andSpecified Data Models. Within Specified Data Models would be the Entities, Attributes, PrimaryKeys, and Foreign Keys. In this regard, the set of meta-entities from the Whitemarsh metabaseare clearly first-rate candidates for deliverable templates.

In addition to deliverable templates, there are also deliverable template types thatrepresent the classification of deliverable templates. For example, there might be a deliverabletemplate type such as:

! Process models! Data architectures! Business information system architectures! Plans! Analyses

Each of the deliverable template types is a way to broadly classify the different types ofdeliverable templates to which each belongs.

Task templates are recursive and represent the natural hierarchical decomposition oftasks. For example, there might be a task template to Define Database domains. The subtaskswithin that task template might include Identifying, Describing, Reviewing, and Finalizing theDatabase Domains. The complete set of tasks and subtasks for the Whitemarsh database projectmethodology is provided in a Whitemarsh book, Work Breakdown Structure.4

Collectively, the project, deliverable, and task template entities enable the standarddefinition of the types of projects that are performed within the enterprise. By standardizing theproject types, management and status reports can be created.

Deliverable templates contain an attribute for unit effort hours. This value represents thequantity of staff hours required to complete the deliverable under normal conditions. A

4 Great care must be exercised as to the level of detail for tasks. If they are too shallow, ambiguityresults. If they are too deep, resentment and strangulation occurs. In the Whitemarsh databaseproject methodology, for example, the table of contents of the work breakdown structurerepresents the right level of detail by which a Whitemarsh database project should be specified andmanaged. The Table of Contents is 14 pages. The full work breakdown structure is 125 pages.


17


deliverable, for example might be a defined data element, and the deliverable unit effort for thismight be 2 staff hours.

The deliverable template entity also contains another attribute that indicates whether thework associated with producing the deliverable is divisible. For example, it is not likely that thework to create a defined data element is divisible. Therefore, no more than one person should beassigned the task of creating a single defined data element. Similarly, task templates contain anattribute that indicates whether the task is divisible. The task (but not the task template) containsan attribute to indicates the quantity of deliverables to be produced. If the task template indicatesthat the task is divisible, and if the quantity of delivered units is more than one, then the work isdivided as evenly as possible among all assigned staff. The rules for work division are these:

Deliverable[Template] Divisible

Task [Template]Divisible

Task deliverablequantity

Assigned workdivided?

No No N/A No

No Yes more than one Yes

Yes Yes one No

Yes Yes more than one Yes

Yes No N/A No

Whenever work is not divisible, the work’s elapsed time is computed to be that of the slowestworking person. Other assigned persons are presumed to be “watching” the expert teach or leadthe others in the production of the deliverable. Hence, the work proceeds at the rate of theslowest person, not the fastest.

6.0 Assessing and Assigning Staff

Figure 8 has the following entities related to assessing and assigning staff:

! Job Title! Phone! Phone Type! Skill! Skill Level! Skill Level Type! Staff! Staff Skill Levels! State


18


The staff entity contains the necessary information to identify persons associated with projects.Staff can be associated with more than one project. The staff member’s name, address and phonenumbers are entered. In addition to this basic information, hourly costs are stored. These exist asdirect hourly costs and indirect hourly costs. Direct hourly costs are typically those associatedwith salary and benefits. Indirect hourly costs are those associated with assigned overhead suchas office space, tools, management and supervision, and the like. When staff costs are computedfor a project, both types of hourly costs are employed to produce subtotals and then overall staffcost.

The staff member’s skill levels are identified from a list of skills and the skill level types.The skills should relate to the type of activities performed. Skills might include for example:

! Data Administration! Data Quality Control! Database Administration! Documentation! Logical Database Design! Management! Physical Database Design! Programming! Quality assurance and quality control! Requirements analysis! Systems Analysis! Teaching! Testing! Training program development

With respect to each skill, there can be distinct types that characterize the skill level achieved forthe skill. The following skill level types are suggested:

! Expert! Journeyman! Novice! Unskilled

A skill level is a skill of a certain performance type. For example, unskilled data modeler, novicedata modeler, journeyman data modeler, or expert data modeler. For each combination of skilland skill level type, a multiplier is affixed. This multiplier field represents an assessment of therelative speed that work can be performed. For example, if the norm is journeyman, the SkillLevel Multiplier might be classified as 1.0. If a novice performs the task 30% slower, the SkillLevel Multiplier might be 1.3. For an expert who performs the work 20% faster, the Skill Level


19


Multiplier might be 0.8. Finally, an unskilled worker might take twice as long and would have aSkill Level Multiplier of 2.0.

Once a complete set of skills, skill level types, and skill levels with their multipliers arecreated, they can be associated with staff. A staff member may have more than one skill, and bean expert at one and a novice at another. Once a person through their staff skill level is assignedto work on a project task, the staff skill level multiplier either speeds up the work, has no effect,or slows it down. This assignment capability provides project managers the ability to explainexactly why two projects that are the same in all respects except for the skill levels of theassigned staff will take two different quantities of staff hours.

7.0 Project Plan Constriction and Estimation

Figure 8 has the following entities related to Project Plan Construction and Estimation:

! Assigned Task! Base Line! Deliverable! Project! Role Type! Status Type! Task! Task & Work Environment Factor! Task Skill Level Requirement! Work Environment Factor! Work Environment Factor Type! Work Environment Multiplier Type

To create a project, the following steps must be accomplished:

1. Create the project record2. Choose the project template3. Choose the project’s status4. Choose the project’s resource5. Select the project’s contract6. Enter the project’s description7. Choose the project’s leader8. Create basic information for each task9. Choose the appropriate work environment factor for each task10. Assign the tasks to project staff members11. Choose the role that each project staff member performs on a task


20


12. Press the Compute Project Resources button on the project record13. Record the project’s base line

In Step 1, the project record is created on the screen that contains the list of existing projects.Upon insert, a new [but null] project is created and is presented for further update.

Step 2 requires the selection of the project’s project template. A set is presented and oneis chosen. Step 3 includes supplying the project’s title, and a status that is chosen from the statustype entity list. Statuses should proceed through a life cycle. The following sequence of statusesare suggested:

1. Proposed2. Deleted3. Approved4. Scheduled5. On-going6. Terminated7. Completed8. Reviewed9. Finalized

Step 4 sets the project within the context of a particular Resource Life Cycle Node. Thus,it is related to a specific collection of databases and business information systems, and existswithin the overall life cycle of the Resource.

In Step 5, the appropriate contract under which the task is performed is selected.In Step 6, a 250 character description of the project can be included. While this seems

short, it must be remembered that there are many other name and description attributes that incombination serve to fully describe both the project and its context. Included for example are allthe deliverables and their templates, tasks and their templates, contract, and resource.

In Step 7, the project’s leader is chosen from a staff list. At this point, the only additionalpiece of information that can be added at the project level is the project’s start date. Once this isentered, all remaining work must be done at the individual task level. This is done in steps 8, 9and 10.

Once the project’s basic information is captured, the project’s basic information isessentially complete, and the auto-build of the project can start. Auto-build is the manufacturingstep. Project classes are identified, defined, and include deliverables, and unit effort. Oncerefined, these projects are made into templates. Thereafter, these Project Template are availableto manufacture projects.

Auto-build is accomplished by highlighting the newly created project and instigating theproject build process. Immediately, all the deliverable template records and task template recordsassociated with the identified project template record are copied into the project’s deliverableand task entities. At that point, the lists of deliverables and tasks can be displayed


21


Once the project’s auto-build step is complete, the project‘s tasks can be updated. Thisprocess, that is, Step 8, is started by highlighting the project from within the project list andinstigating a change. The project’s update window is then presented. Each project task ischanged by first highlighting a specific task in the project’s task list window and invoking thechange function.

Under the strategy set out in this approach, that is, auto generating project details throughthe use of predefined project, task, and deliverable templates no task may be deleted from, norcan any additional tasks be added to any generated project. If there is additional work in thenature of additional tasks, the project’s template must be changed. That is, new tasks added to orexisting tasks deleted from that task template from within the project’s template.

The ability to add or delete tasks from a project has specifically been removed fromWhitemarsh project management because to allow additions or deletions would in effect bedefeating the project management strategy: standardization of project specification,accomplishment, and measurement. If task lists derived from a template are allowed to bemodified then eventually all templates will be irrelevant as all projects will ultimately beuniquely accomplished.

Great care must therefore be taken to ensure that the task lists at the project templatelevel are sufficiently comprehensive but not too detailed. The exact details of how a task isaccomplished should be left to the ingenuity of the person performing the work. That is whatdistinguishes the skill types, inexperienced, novice, journeyman, and expert. Having tasks atsuch a level of detail that every five-minutes of effort is both specified and controlled issuffocating, insulting to individual creativity, and absurd. Whitemarsh project management is forknowledge workers, not for process or manufacturing-line workers. That is a profounddifference.

As an example, if the project is an IT project that creates a database application, and ifthe Whitemarsh methodology, which has a 125 page 3300 task work breakdown structure, isemployed, these 3300 tasks must not be stored in the project management database. But, if bymistake they were, then it would take forever to estimate such a project and it would also beimpossible to manage because the task detail is too low. Instead, only the high level tasks shouldbe stored. This represents about 450 tasks. That’s a 8:1 reduction.

Better still is to divide the database project into at least six smaller projects, one for eachphase. In that case, the six projects would represent only about 70 tasks each. That’s much easierto estimate and to manage. Even within a given phase there can be further subdivisions thatmakes evolution and maintenance easier. Suppose there were four different approaches to thedefinition of a database table. Each could be a separate task template with its own set ofdeliverables. That would allow for the appropriate picking and choosing.

The only tasks that can be changed are those that are “leafs.” A request to change a non-leaf task results is an error. In this Step 8, the basic task information can be adjusted. At theoutset, the task shows the related task template, deliverable template, and the deliverabletemplate’s unit effort hours. This data is automatically brought from the task template.Automatically loaded as well is the task sequence number, whether the task’s work is divisible,


22


and the task’s title. The user is able to change the task’s title and description to something morestylistic, detailed, or appropriate. Notwithstanding, the task should still be seen as animplementation of a task from the task template.

Entered on the task window is the current status (1=Proposed through 9=Finalized), andthe quantity of deliverable units that the task expects to produce. For example, 125 defined dataelements. Once the quantity is entered, the task level unit effort hours to be automaticallycomputed. If a quantity of zero is recorded, the task will effectively not participate in thedetermination of the project’s resources. The task’s start date should also be entered and as it isused to determine the task’s completion date after work environment factors and staff areassigned. Note however, that the task’s start date is “overruled” when the schedule for the entireproject is computed.

In Step 9, the appropriate work environment factors that govern the tasks are picked.Once picked, the task screen shows chosen work environment factors. When a new workenvironment factor is needed, an exiting set is presented. Choices should be made that relate tothe work environment for that specific task. Each chosen work environment factor has an itseffect on the unit effort hours computed for the task.

The staff hours in the task templates assumes normal work environments for each task.While the definition of the work environment factor types and the specific factors is clearlyunder the control of the project management administrator, the following suggestions areoffered:

Work Environment Factors.

Factor Name FactorValue

Factor Description

Experience of Team 1.00 No Effect

1.00 Competent Team That Has Performed this Type of WorkBefore

1.10 Experienced Dp Staff but Novices at this Type of Work

1.20 Novice Dp Staff

Reviews Conducted by theClient

1.00 No Effect

1.00 Reviews, That Is, Walk Throughs Are Conducted by theClient as Scheduled


23




Factor Description

1.10 Reviews Are Conducted but by Inexperienced Reviewers

1.20 Reviews Are Generally Not Conducted

Analyst/programmer ToolsEnvironment

1.00 No Effect

0.75 Work station with CASE and Metadata Management System.

0.60 Work station with CASE and Metadata Management System,and Shared Metadata System.

0.40 Work station with CASE and Metadata Management System,and Shared Metadata System and Code Generator.

1.00 Workstation or PC with PC DBMS, Telecommunications toShared Environment

1.05 PC with only Word Processing and Stand-alone CASE ToolEnvironment.

1.10 PC with only Word Processing and Stand-alone “Visio” ToolEnvironment.

1.25 PC with Only Word Processing and No CASE/repositoryEnvironment

1.30 For Server only Terminals That Only Provide Access to aMainframe Word Processor

1.40 For No Equipment Available to the Staff, Except Through anAdministrative Person

Environment Availability 1.00 No Effect

1.00 If the Equipment and All Required Software Is Available forat Least 6 Business Hours Each Day


24




Factor Description

1.16 For Each Hour below the Average of Six That the EquipmentIs Unavailable

Extent of User Contact 1.00 No Effect

1.00 If the Users Are Available Within Half Day Request toReview Interim Products (Work in Progress, but Not aDeliverable).

1.10 If Users Are Available but Only Within 2 Business Days ofRequest



1.40 If Users Are Generally Not Available

In Step 10, staff members are assigned to the task. The list of currently assigned task membersappears on the task screen. Changes in these assignments can be accomplished through inserts,changes or deletes.

On an insert, a list of staff members and their associated skills is presented. When aspecific staff member is chosen, so also chosen is the staff’s skill and skill level multiplier.

Once a staff member has been assigned to a task, Step 11 consists of picking theirappropriate role. Suggested roles might be:

! Developer or contributor! Manager or leader! Reviewer

Once all the work environment factors and staff have been assigned to a task, the resourcesassociated with that task can be computed. This is done through three processes:

! Compute Factored Hours! Compute Elapsed Hours


25


! Compute Completion Date

When the Compute Factored Hours process is executed, the standard hours from the task’s tasktemplate is multiplied by the multiplicative summation of all the work environment factorsproducing Factored Hours.

When the Compute Elapsed Hours process is executed, the staff work hours for eachassigned staff member is computed as the Factored Hours multiplied by the staff’s Skill LevelMultiplier. The elapsed hours for a task is determined as the longest effort for any oneparticipant in a task. The field, staff assigned hours, is the commutative quantity of all staff workhours.

When the Compute Completion Date process is executed, the start date of the task isemployed to then compute the completion date according to these rules:

! Duration Days are computed by dividing elapsed hours by hours-per-workday. TheWhitemarsh project management software’s basic reference data can be changed. Itincludes, for example, hours-per-workday. If a task has a duration of 24 staff hours and ifthe hours-per-workday are 6, then the staff-days is equal to 4.

! The total staff-hours for a project is the sum of all the staff hours.

! The completion date depends on whether a task which contains other tasks is marked asserial or parallel.

If the containing task is marked as serial, then the completion date for itscontained tasks is computed to be start date for the first contained task plus theduration days for every other contained task. Weekends and holidays areexcluded.

If the containing task is marked as parallel, then the completion date for its containedtasks is computed to be the start date for the first contained task plus the duration days forthe longest contained task. Weekends and holidays.

If a graphical representation of activities is required, the Whitemarsh task and resource data canbe exported via the Microsoft Project export format and be imported into a project managementsystem like Microsoft Project, or other third-party PERT an Gantt chart creation tools.

Great care must be taken not to try to make project plans perfect. Too much timewill have been spent to accomplish a result that will, in just a few days to a weekbecome outdated. Too many internal and external factors cause project plans tobecome “broken” including such trivial causes such as sick-leave, layoffs, slippedphysical product delivery schedules, to say nothing of significant causes such as


26


enterprise mission redirection, change in database management systems,replacement of computing hardware.

An analysis of 13 multi-hundred million dollar U.S. Government GeneralAccountability Office IT projects showed that 95% of all late IT projects werecaused by errors/changes the occurred outside the control of IT. Thus, getting theoverall project plan within 10% is certainly close enough. Additionally, forcingconformance to a perfect-plan that has been autocratically declared not subjectto change is simply bad management and bad execution.

In step 12, the overall project resources and end-dates are computed. Once all the work to eachtask has been completed, the Compute Project Resources process is executed. At that point, theproject’s factored hours, staff hours, and elapsed hours are all computed. The start-date and end-dates for each task are recomputed beginning with the project’s start date.

Unless otherwise indicated, tasks within a project are processed in a hierarchically serialmanner. If a project contains multiple tasks, or if a task contains other tasks, and the schedule-parallel indicator is parallel, then the contained tasks within the project or within specific tasksare scheduled in parallel. That is, the elapsed time for a containing project or task is the elapsedtime of the longest contained tasks. That set of tasks becomes the critical path. Once all thescheduling is accomplished, the project’s end date is computed.

Once a project is scheduled, the Check Overload processe can be executed. This processtriggers an analysis that determines if any staff member is overloaded for a task. It determinesthis by summing the staff members assigned hours across task schedules. If the sum is greaterthan the allowed work hours for the period, then the overload indicator is set. A staffingallocation report is generated and it shows the project and task level of staff loading by staffperson across time. The granularity of time used to assess overloading is one week.

Step 13 enables the project manager to record a baseline for the project. A baseline is thedated permanent recording of key project, task, resource and schedule information. When thebaseline is recorded, a new set of the information is created for every task in the project.Collected as well is the key information from the work environment factors and the staffassignments on the date of the baseline.

Once project planning is finished, the project’s baseline is created by invoking theBaseline process on the project update window. The data values for all of the above attributes arecollected on a task by task basis and stored into the baseline entity. Baselines support progressreporting. Since a key attribute of the baseline entity is the baseline date, multiple baselines canbe created and the baseline information can be described and tracked during the life of theproject.

8.0 Recording Work and Generating Earned Value Reporting


27


Figure 8 has only one entity, Work that is directly related to the recording of work andsupporting earned value reporting. This entity records the hours expended by an assigned staffperson including a description of the work performed. Work is recorded in terms of the assignedtask. A window that contains four interlinked lists is presented. The first list contains theprojects. The second, linked with projects is the contained tasks. The third is the task’s containedassignments, and finally the fourth contains the work records. If a new work record is to beadded, the Insert button is pressed. The recorded work includes the start and end dates, hoursworked, quantity of deliverable units completed, and the description of the effort.

As a task is completed, its status should be changed. As a project is completed, theproject’s status should also be changed. Reports perform project accomplishment analysis byschedule, status, hours, and earned value. Earned value analysis computes the percent of a taskbeing complete based on the deliverable units accomplished. If 100 units are proposed and 50 arecomplete, then percent complete is judged to be 50%. Earned value date adjustments mean thatthe quantity of hours expended by summing work hours to complete a task results in projectionsof the hours needed to complete the task. When earned value rescheduling is performed the task’s end-date is recomputed. On the project level, earned value analysis and reschedulingaccomplishes the rescheduling of the entire project. This results in new task and project dates.

9.0 Conclusions

The enterprise-level project management approach in this paper clearly enables:

! Concurrently managing disjoint projects

! Managing generally uncontrolled resources

! Enabling maximum re-use of past efforts

! Incorporating learned experiences

! Not requiring a full-time project planner

! Supporting what-if resource allocation scenarios

! Enabling management to know about and view all projects and resources across theenterprise

! Supporting the presentation of projects individually, or from the perspective of abusiness-defined set of priorities


28


! Enabling multiple, concurrent, but differently scheduled projects against the sameenterprise resource5

! Supporting single projects that affect multiple enterprise resources

! Permitting projects that develop completely new capabilities, or changes to existingcapabilities within enterprise resources

Because Whitemarsh project management system is implemented as a database application, itsupports the following types of reports:

! Projects and project statistics of a certain project template! Projects and project statistics within certain [business area] resources! Projects and project statistics by deliverable types! Projects and project statistics by organizational units! Projects and project statistics by specific project staff members! Projects and project statistics by certain types of skills! Projects and project statistics according to certain status types! Projects and project statistics according to certain work environment factors

10.0 References


The following references to Whitemarsh materials provide a more detailed expositionpractical application of the significant content of this paper.

The following documents are available free from the Whitemarsh website:

Paper URL


Metabase Overview http://www.wiscorp.com/Metabase.zip

5 An enterprise resource represents an essential component of the business. Resources provide thebusiness context for projects. For example, staff, money, contracts, equipment, and facilities. Moreon resources, resource life cycles and resource life cycle networks is found in the WhitemarshKnowledge Worker and Information Systems planning books, papers, and courses.


29


Whitemarsh Data Modeler, Architecture and Concept ofOperations

http://www.wiscorp.com/MetabaseDataModelerArchitectueandConceptofOperations.zip

Information Systems Planning: Book, Course, andPresentation (short and long) – samples

Knowledge Worker Framework: Book, Course, andPresentation (short and long) – samples

http://www.wiscorp.com/EnterpriseDatabase.htm

Database Architecture Classes: sample http://www.wiscorp.com/DatabaseDesign.htm

Resource Life Cycle Analysis: Paper http://www.wiscorp.com/MetabaseProducts.htm

Database Project Work Breakdown Structure – sample http://www.wiscorp.com/DatabaseProjects.htm

Resource Life Cycle Analysis Metabase Module UserGuide

http://www.wiscorp.com/metabase_demo.html

Metabase System (Free Version) Request form http://www.wiscorp.com/freemb.html

The following documents are available for Whitemarsh Website Members. The URLs that follow providedescriptions of the pages. Members should log in and proceed to the appropriate page, e.g., Enterprise Database, findthe book, paper, or course and perform the download.

Paper URL








Data Architecture Classes

Guidelines for Data Architecture Class - DataWarehouse

http://www.wiscorp.com/wwmembr/mbr_products_dd.html


30


Paper URL

Iterations of Database Design










Information Systems Planning: Book, Course, andPresentation (short and long)

Knowledge Worker Framework: Book, Course, andPresentation (short and long)



31


A30 Whitemarsh Project Methodology Overview


80

Whitemarsh Project ManagementOverview




Whitemarsh Project Management Overview

Why Project Management is Important

Project Management is important because almost all enterprises suffer from one or more of thefollowing problems:

! Inaccurate estimates! Conflicting priorities among projects! Inability to deal with varying levels of work conditions, staff skills, and the like! No intra- and inter-project reporting

Simply put, a common lament is that while there are projects everywhere, the ability toeffectively manage these projects on an individual or enterprise-wide basis is nowhere.

For example, studies by have shown that many, if not most, knowledge worker projectsexhibit these characteristics: over budget, under specified, delivered late, and fail to meetorganizational expectations. While not all reasons for failure can be laid at the foot of projectmanagement, too many can. Among the underlying reasons are invalid work plans, insufficienttime for requirements changes, and inexperienced or mis-allocated staff resources.

The United States Government’ General Accounting Office (GAO) has been studying ITprojects for a number of years, and a review of 10 GAO studies clearly shows that the mainreasons why IT systems fail has nothing to do with IT. Again, while not all reasons arespecifically related to project management, some of the reasons have to do with criticalcomponents of project management. And again, these are invalid work plans, insufficient timefor requirements changes, and inexperienced or mis-allocated staff resources.

As a consequence of market pressures and corporate mergers, two classes of projectmanagement systems remain today:

! PC based or low-end packages! Server based or high-end packages

PC based project management systems are typified by Microsoft’s Project (www.microsoft.com)or Time Line Solution’s product, Time Line (www.tlsolutions.com). Server based projectmanagement systems are typified by Primavera (www.primavera.com) and Welcom Software(www.welcom.com).

While the high-end packages are designed for very large, complex project’s of thousandsof nodes, and while the low-end packages are well suited for scheduling a single project ofrelatively simple complexity, both the high end and low end solutions do not really address theproblems associated with:

! Disjoint projects! Management of generally uncontrolled resources! Repeatability of projects


1


! Incorporation of learned experience into the project estimation cycle

Many knowledge worker projects involve persons from within different organizations overwhose time the project manager may not have direct control. Thus, the best the project managercan do is to request participation and to create approximate schedules that show deliverablesfrom these non-controlled participants.

If the knowledge worker project manager creates elaborate project schedules based onmany layers of intricately crafted activity networks, then while they look magnificent the instantthey are first created, these project plans cannot withstand assaults from all the scheduleconflicts. Once these assaults are underway, the project manager has to continuously adjust thelayers of project activity networks, resource estimates, parallel and serial paths, etc. Soon theproject manager’s life is consumed by project management rather than project accomplishment.

The dilemma then becomes:

! Accomplish the project, or! Plan the project’s accomplishment.

All too often, project planning is discarded because the project management system, initiallythought to be the savior from chaos actually had become another source of chaos. The castle ofproject management becomes the project manager’s dungeon wherein time is the dungeonmaster, the PERT chart is the shackles, and the schedule is the rack.

To be successful at Knowledge Worker project management, an approach must:

! Concurrently manage disjoint projects! Manage generally uncontrolled resources! Enable maximum re-use of past efforts! Incorporate learned experiences! Not require a full-time project planner! Support what-if resource allocation scenarios! Enable management to know about and view all projects and resources across the

enterprise! Support the presentation of projects individually, or from the perspective of a

business-defined set of priorities

Whitemarsh Project Management Environment

Whitemarsh project management is based first and foremost on its database design. The general“life cycle” of Whitemarsh project management is:

! Employ project, deliverable, and task templates to plan projects


2


! Plan and estimate projects in a gross way and accommodate different workenvironment factors

! Staff projects and generate schedules

! Record progress towards deliverable accomplishment

! Re-plan projects as needed

! “Learn” from actual durations from accomplished deliverables

Whitemarsh project management does not, however, support the creation of:

! Very precise parallel and serial networking of projects or tasks! Very detailed and precise scheduling! Gantt, PERT or CPM diagram production

These three activities are the proper activities of both low-end and high-end project managementsystems. In support of these systems, the Whitemarsh project management system generatesoutput data files that can be input into these systems. These systems can then be used to createvery precise schedules, activity diagrams and the like. Whitemarsh holds however, theproposition that if accomplishing these three activities were THE basis for successful projectmanagement then there would be no need for Whitemarsh project management. While veryprecise schedules, activity diagrams and the like are important, it seems clear that these featureshave little or nothing to do with project management success.

In contrast, Whitemarsh believes that project management success is predicated ondifferent activities, which are:

! Continuous optimization of repeatable projects,

! Accommodation of various work environments and factors within theseenvironments,

! Adjustment of project schedules based on differing staff and skill levels, and

! Capturing actual work accomplishment metrics that support earned value analysisand reporting.

The project management database design employed by Whitemarsh has been implementedseveral times as the basis for project management over the past 10 years. Whitemarsh believes


3


therefore that the “design bugs” are worked out. Whitemarsh project management serves theneed of the independent project manager who has to accomplish the definition, management andreporting of diverse and possibly disjoint projects with staff of varying skill levels within mixedwork environments that are generally not within direct control. Whitemarsh believes that thistype of knowledge worker environment is the rule, not the exception.

Whitemarsh Project Management, A Difference in Kind

A key difference between the Whitemarsh project management approach and others is that theWhitemarsh approach concentrates on the management of “nouns” while other projectmanagement approaches focus on the management of “verbs.” Clearly, since there is no onesacred, perfect way to produce a deliverable (i.e., the nouns), if the focus of project managementis to identify and control the “methods” (i.e., the verbs) by which deliverables are produced, thento have enterprise-wide project management and/or to have enterprise-wide metrics, theenterprise must first carve-into-stone the processes by which work is done. Not only is thisimpossible, it is highly undesirable. It is impossible because it is inconceivable that there is onlyone way to accomplish any product. It is undesirable because it is insulting to project staffs topresume to control their every technique, process and step. Not only can’t it be done, no one willallow it to be done.

In contrast to managing “verbs,” Whitemarsh project management manages “nouns.” Itdoes this by collecting the quantities of resources expended to produce deliverables. Whitemarshproject estimates are therefore based on the staff hours required to produce deliverables ratherthan to accomplish tasks.

This technique enables different styles of project management to be employed or be setone against the other by comparing the resources expended to produce deliverables. There mightbe one project template for mainframe development, another for micros, and finally amethodology for web-based systems even though all the deliverables might be essentially thesame. Alternatively, there might be multiple project templates that produce the same set ofdeliverables to serve the needs of different styles or techniques as might be the case for the data-driven and process driven approaches.

Additionally, the Whitemarsh project management approach enables enterprise-wideproject reporting in terms of the cost and effort to produce deliverables versus theaccomplishment of activities. As work techniques improve, either through the increased skill ofstaff, or through the adoption of different techniques, the efforts remain comparable because it isthe quantity of resources expended to produce the deliverables that are compared rather than theactivities, which are no longer able to be compared because they are now different, that producethe deliverables.

To illustrate, when you go into a grocery store and buy an apple, the cost is expressed interms of the product you are buying, the apple. While you may wonder how much the variousactivities cost that ultimately produced the apple, fundamentally, you probably do not care.


4


When you go to five different stores and compare the cost of apples (given a standard forequating quality), again you are only comparing the cost of the deliverable, the apple. If onestore spends 10% for transportation and another spends 8%, you probably don’t care. It’s thefinal cost of the apple that matters, nothing else. So also should it be with project management.The only thing that should matter is the final cost of the deliverable. Nothing more, and nothingless.

If however you are a wholesale apple buyer that deals with a co-operative and bycontract, you have to pay every apple grower the maximum cost incurred by any one member ofthe cooperative, then you have a real incentive to look “behind” the costs of the deliverables (theapples) to find the different underlying processes that make the costs different. Even then, thegoal then is to find the lowest-cost set of activities, and to then highly recommend that set ofactivities to all members of the cooperative so that your costs for the deliverable–as a buyer–willgo down. So, while there may be an interest in activity-sets, they are not the driving force. So toowith Whitemarsh project management wherein the cost of deliverables rather than the cost ofmethods is the driving force.

Whitemarsh project management enables the melding project templates with selected:

! Task templates–that is, the enterprise’s techniques, methods or work breakdownstructures that have been proven of the years to accomplish in work the most costeffective manner.

! Deliverable templates–that is, the enterprise’s specifications of and unit effortmetrics required to accomplish the components of its Knowledge Workerproducts.

The resulting Project Templates are then specially tuned into “real” projects by determining thequantity deliverables, and then affecting the resulting “norm” estimates through:

! Work environment factors–that is, the effects from varied work environments onthe creation of deliverables according to certain task templates.

! Staff–that is, the effects from persons and their varying types and degrees of skillson the rate of production of deliverables according to the task templates.

Collectively, these four project management components are an exemplary use of the databasefundamental, define once, use many times. Whitemarsh believes it has achieved the ability tohave maximum reuse with minimum original, one-off effort.


5


5.4 Architecture and Concept of Operations

Whitemarsh Project Management is squarely founded on a database application that captures andmanages the data critical to effective project management. The database’s design is depicted inFigure 1, and consists of a number of entities. All these entities are traditional and areinterconnected through one-to-many relationships except for those entities that show a one-to-many relationship from the entity to itself. Organization (upper right) contains such arelationship. This relationship means that the entity contains subordinate organizations. Forexample, an Information Technology organization contains the Information ResourceManagement organization, which in turn may contain the Data Administration organization, andDatabase Administration organization. The eight entities that are recursively related are:

! Contract! Deliverable! Deliverable Template! Organization! Project Template Type! Resource! Task! Task Template

The entities from Figure 1 are also divided into six distinct clusters, which are:

! Contracts, organizations and contract [staff] resources! Resource and Resource Life Cycle Node! Project, Deliverable, and Task Templates! Project Staff! Project Building and Estimation! Project Work

In general, the Contracts, Organizations, and Contract [staff] Resource cluster of entitiesrepresent the environment within which projects take place.

The Resource and Resource Life Cycle Node1 entity represents the target of the project,that is, the area of the business benefitted by the project. For example, for manufacturing,finance, human resources, or land use planning.

1 Resource and resource life cycle node has the exact same definition as it does within theWhitemarsh metabase and also the process of Resource Life Cycle Analysis of Ron Ross.


6


The Projects, Deliverable, and Task Templates entity cluster enables the definition of thetemplates employed in the actual building of projects. Defined across the enterprise, thesetemplates enable standard project execution and accomplishment measurement.

The Project Staff entity cluster enables the inclusion of the staff as resources for acontract, and also permit the specification of the specific types and performance ratings of skillsthat a person may bring to a specific project.

The Project Building and Estimation entity cluster represents the entities that supportbuilding projects. Projects and associated tasks are initially created through the use of the ProjectDeliverables, and Tasks Templates. Once projects and associated tasks are created, they aremodified by attaching work environment factors and specific skill-level based staff assignments.Only then can task and project resources be computed.

Staff

Phone

Phone Type

Status Type

State

Work

Assigned Task

Task

Project

Task Template

Project Template


Deliverable


Job Title

Organization


Resource

Role Type

Skill Level

Skill

Staff Skill Level


Work Environment

Factor


Contract

Contract Resource


Contract Role

Skill Level Type





Base Line

Base LineWEF

Base LineStaff

RLC Node

Base Line & Task

Base LineType

Figure 1. Database design in support of project management.


7


Finally, as task work is accomplished, the Project Work entity is valued. As actual workis accomplished, it can be reported through any of its related entities.

Because Whitemarsh project management system is implemented as a databaseapplication, it supports the following types of reports:

! Projects and project statistics of a certain project template! Projects and project statistics within certain [business area] resources! Projects and project statistics by deliverable types! Projects and project statistics by organizational units! Projects and project statistics by specific project staff members! Projects and project statistics by certain types of skills! Projects and project statistics according to certain status types! Projects and project statistics according to certain work environment factors


8


A31 Modeling Data and Designing Databases


81

Modeling Data and Designing Databases






ii

Table of Contents

1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. Topics Covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. How to Discover the Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.1 Missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.2 Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.4 Prior Data and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.5 Scope Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.6 Database Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.7 Database Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.8 Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.9 Data Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.10 Validation through Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4. Where to Put Your Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5. How to Build a Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13



1

1. Objective

The objective of this Whitemarsh Short Paper is to present an approach to the comprehensive,efficient and effective process of creating data models through mission, database domain, andlocalized entity-relationship modeling. The paper then concludes with an overall process andcheck list for designing databases that is supported by a reference to a different Whitemarshpaper. Whitemarsh Short Papers are available from the Whitemarsh website at:

http://www.wiscorp.com/short_paper_series.html

At first, it might seem strange to separate the process of modeling data from the process ofdesigning databases. Not only are these topics really different, but if the first is not done beforethe second, then not only will you have a bad database design, but you will also have a highprobability that the databases are not-integrated, are redundant, and that definitely possessesconflicting semantics. These are the inverses of desired characteristics.

Simply stated a schema and its contained tables represent a completely encapsulated setof data specifications within the “hard boundaries” of its schematic (hence, it’s within a schema).In contrast, a model of data is simply a collection of entities, attributes and relationships amongthe entities across one or more subject areas. Data models have no real hard-boundaries, onlyabstract boundaries. Data models are supposed to represent the semantics of natural collectionsof data specifications. Schemas are specifications of semantics of data specifications containedwithin a database that, in turn, lead to actual instances of stored data. A data model is a type-collection specification. A database is a data-instance-collection specification.

Case Study

A school system needs to build a database application (an application where the database is thecore component). The problem domain is to track individuals who are being trained to be HealthRoom Medical Assistants (HMA). The school system has about 140,000 students, exists withinan urban setting, reports to an urban government that exists within a U.S. State.

There are about 210 health rooms across the system, and whenever the RN is absent froma school, then an HMA has to handle the dispensing of medicine, medical record keeping, andfirst aid. The HMA can only be authorized to perform health-related activities through a“delegating” RN. The HMA “works under” the delegating RN’s license.

Schools principals are responsible for selecting HMA candidates. They must pass areading, writing, and arithmetic test. If the test is failed, the HMA candidate cannot come back tothe class for 90 days. The HMA nominee must “sit” for a 40-hour class. There are three testsduring the class, and a practical demonstration-based exam at the end. If any test is failed, theHMA candidate is “expelled” and they have to retake the entire course starting with the entrancetest.



2

There are also a follow-up review and direct observation of every HMA every 45 schooldays. After the first 45-day period, the HMA candidate can then apply to the State to thenbecome a certified HMA. If thereafter, the HMA fails the follow-up review and/or any directobservation, the supervising RN must report that failure to the State Board of Nursing. TheBoard of Nursing may then decertify the HMA. If decertified, the process begins again from theentrance test for a new applicant. Giving the wrong drugs or dosage to a student, or failing toproperly document medical treatments is a serious matter, and the Board of Nursing takes itseriously.

The task is to build the database application against these requirements. A nursesupervisor of the school system’s student health organization chose MS/Access to build theapplication based on the school system’s IT department. Since the nurse supervisor was told thatMS/Access is really simple, and since she is a subject matter expert, she just fired up Access onher computer and started to type in the database’s design: One table, of course. As shediscovered something she forgot, she just modified the database’s one table design, one columnat a time.

After about nine months, the one-table database in MS/Access was complete. She thenstarted to type in data for about 300 records of HMAs in various stages of the certificationprocess. Of course “she” herself is required to be present to understand and explain each andevery row of data. There are multiple status codes, some of which are related to others. There isno history.

During a review of the database’s design, and in light of the requirements stated above,questions were asked about the underlying process, test re-takes, test failures, observations,recertifications, how HMA moves from one school to the next are recorded, how changes in RNdelegation are handled, and the automatic refreshing of names, addresses, and schools from theschool system’s databases. None of these questions were accommodated within the database’sdesign.

A question was then asked, “Where’s your model of the data?” She stated, “Oh, righthere.” She showed the MS/Access database table. She was not aware that a model of the data isdifferent from a database’s design. After this review, the next two hours were then spent figuring out the model of the data. At the end of this first data model design session about 15-20 entitieswere identified and related. At this point she knew that these requirements were beyond what sheknew how to do with Access. What was starting to emerge was the need for: 1) a data model thatwould mirror the real requirements, and 2) an application system to manage the user interface,underlying processes, data entry, errors, relationships, editing, workflow, and reporting.

What should she have done? That’s the subject of this short paper. This paper is writtenas if she had all the necessary tools to accomplish all the steps. Will she have these tools? Willthe school system expend the resources to make “simple, little applications” like these practicallypossible? A good, sophisticated tool set like Clarion for Windows (www.SoftVelocity.com)make both client/server and Internet-based applications such as these very practical and costeffective to accomplish.



3

2. Topics Covered

The topics in this paper include:

! How to discover the data model! Where to put your data model! How to build a database design

3. How to Discover the Data Model

The overall process of modeling data is provided in Figure 1. Instantly you may be asking, “Whyare functions and organizations involved in modeling data?” Won’t that lead to a stove-pipefunctional specification? If you don’t know, in a general way, what your going to do with thedata, nor who’s going to be using it, then how can you know if you’ve got the right model?However, if you treat the functions and organizations as “hard” outside boundaries then yes, astove-pipe database design might result. If, however, organizations and functions merely serve ascontextual sources then no, while the data model design is focused, a stove-pipe database willnot necessarily result.

Some suggest, in contrast, to using functional and organizations contexts that you justcover a whole wall in a 50x 30 room with butcher block paper, put a rectangle in the upper leftcorner, write “Customer,” and then wait for divine intercession. Some have grown old andretired waiting for the revelations. In addition, such a strategy often results in fully expendedbudgets and employment termination. Clearly, this is not a desired outcome.

A careful review of the process model in Figure 1 shows that neither “schema” nor“database” (other than database domains) is specified. That’s because it’s a process to modeldata. Thereafter, the data model can be employed to help create database schemas that are, ofcourse, an essential requirement for database-centric applications. Provided here are summarydescriptions of these data modeling processes, and reasons why they are performed. Detaileddescriptions including specifications of the data model products that are built and theirinterrelationships are all provided in Section 7, References.

3.1 Missions

Missions are the idealized descriptions of what the enterprise is all about, not just what is doneon a day to day basis with respect to a specific narrow function. Identification and specificationof the relevant missions are critical. In the case study, the focus was on the database’s design toaccomplish known processes. There was no overall understanding of how these collections ofprocesses fit into the overall mission of the school system.



4

3.1Identify,


missions

3.5Create first level scope model of overall effort.

3.6Analyze and

specify database domains

3.4Identify analyze,

and specify relevant existing

data sources, formats, and

reports

3.7Discover and

specify database objects

3.8Discover and specify data

elements

3.9Discover and

specify subjects, entities,

attributes, and relationships

3.2Identify

analyze, and specify relevant organizations

3.3Identify


functions

3.10Publish, review,

and revise model of data via prototype

generation.

Figure 1. Data modeling process flow.



5

Because the nurse supervisor was focused only on the database’s design, she missed theopportunity to identify all the different objects (in the broadest sense of the word) that shouldhave been involved. Her focus was on the HMA only. Mission isn’t the sole answer, however.Rather, missions are the context within which the data model answer is derived.

3.2 Organizations

Organizations accomplish aspects of missions with databases, information systems andfunctions. In the case study, the enumeration of the various organizations serves to identify thegroups that have to be involved in getting, maintaining, and using the information. For example,HMAs may be transferred from one school to the next. Knowing that, and knowing that probablythe last thing on the mind of the transferred HMA is to notify someone in the school system’sstudent health organization of the transfer, how to know the current HMA’s school is a realproblem. The school system’s HR organization should have the most current assignment for aperson. Consequently, a feature of the resulting HMA system would be to access, on a weeklybasis, the HR system’s database, and validate, HMA by HMA whether the current HMAassigned location is the correct one. If it is, then OK. Otherwise, that school would have to beflagged as no longer having an available HMA.

Again, organization, like mission, is not the answer to knowing the full set ofrequirements. Rather, it too is a contextual element and provides the identification of groups thathave to be involved in the full set of requirements for a complete solution.

3.3 Functions

Functions are the procedures that are performed by groups as they accomplish the variousmissions of the enterprise from within different enterprise organizations. This is where the actualactivities are specified that need to be performed. Setting out and defining functions cause theidentification of areas of data, data elements, states, exceptions and the like involved in theeffort. Functions are all identified within the scope of the mission-organizations that result fromthe previous step. These functions directly lead to the set of processes, automated and manual,that are needed in some way for a complete HMA solution. Common functions would include forexample:

! HMA candidate registration! HMA class formation! HMA entrance test administration! HMA instructor assignment! HMA class room acquisition! HMA attendance recording



6

! HMA class test administration! HMA medical records management! HMA practical test administration! Certification application! HMA infraction reporting

3.4 Prior Data and Reports

Prior data and reports generally refer to the set of all data that must be involved in theapplication, and by inference also in the data model’s design. In the case study, there is Board ofNursing requirements for HMA applications, transactions, and reporting. There are also datarequirements to support the individual HMA person such as biographic data, assignments, tests,scores, and HMA progress states. All these data need to be identified and analyzed within thecontext of the missions, organizations, and functions as they directly lead to subjects, entities,attributes, and of course, relationships.

3.5 Scope Model

The above four: missions, organizations, functions and prior data are all brought together toconvey one overall understanding of just what the mission is, which organizations are involved,what activities are performed, and just what data is involved in accomplishing the effort.

Once the scope model is complete, then from a non-IT point of view, the specification isnot only complete, it should also be able to be reviewed for missing items and functionality. Ifany are found, then they should be corrected before proceeding. Correcting these errors here isvery inexpensive as no databases are yet designed nor has any software been built. Once thescope model is as complete as it can be, then, the next step, database domains, can proceedquickly.

3.6 Database Domains

Database domains are text or list based noun-intensive statements. Database domain paragraphsare the precursor step to entity-relationship models. Well done, each sentence in a DatabaseDomain’s text becomes a multi-entity and relationship statement. Here, there’s no intendedgranularity to an entity. Some may end up being complex (i.e., database objects), other simpler,and some even just data elements.

Once database domains are complete, the various entity relationship diagrams arecreated, subject by subject. If there’s enough information, then a full set of attributes is createdfor each entity. It’s best that the entities are in third normal form so that there is a crispness to the



7

specificity of the set of entities within each subject. Relationships can be made between entitiesin different subjects to provide a more uniform model of the data.

From the point of view of the case study, here are examples of database domainstatements:

! School system has health rooms.! HMAs have delegating RNs! Schools have certified HMAs! School system delivers HMA classes! HMA classes have certified teachers! School system employees are enrolled in HMA classes! School system HMA enrollees have passed (or failed) HMA tests! Candidate HMAs apply for State Certifications! State Certified HMAs must re-certify every two years from date of original certification

From these examples, entities, attributes, and relationships are very obvious. Entity-relationshipmodels are easily drawn and validated by reviewing the subject-verb-object relationship andcardinality with subject matter experts. If any statement is missing, now is the time to add it.

3.7 Database Objects

Database objects are collections of entities (actually collections of tables within a database’sschema). Full database object specification includes its data structure (i.e., a table collection);table-based add, delete, and update processes; database object value-states; and database objectvalue-state transform specifications. But for the purposes of this effort, the database objectmodels are employed to provide a coherent understanding of the processes that are required tooperate against multiple entities so as to ensure an overall integrity. Database objects areextensively described within documents via references in Section 7.

In the case study, “school system” is clearly a database object as it has multiply containedentities. The “HMA class” is probably a simple database object, and the “Certification Date” iscertainly a data element. Because the entity-relationship diagrams exist that were created fromthe database domains, identifying the database objects, simple entities and data elements is fast,and most often correct on their first recognition.

3.8 Data Elements

During the process of creating attributes within entities, each attribute should be mapped toenterprise-wide data elements as a way to maximize semantic uniformity across differentlynamed attributes that represent the same data element, and also to ensure a uniformity of value



8

domains. Once data elements are created and mapped to attributes, “where-used” reports candocument maximum semantic integrity.

In the case study, Certification Date is the data element, and the columns, CertificationDate, and Renewal Certification Date are specializations of the data element that are mapped toit.

3.9 Data Models

If the steps above are accomplished, then the data model for the HMAs will largely be complete.If the effort is part of an overall larger modeling effort, then many of the subjects, entities,attributes, and relationships will already have been created. Having these available from ametadata repository will greatly speed these steps. The remaining step is to actually create adatabase schema of just the relevant data specifications and then proceed through prototyping tothen validate the data model.

In the case study, a very quick set of entities was discovered, and included for example:

! HMA Instructor! School System Employee! HMA Class! HMA Test! HMA Test Score! In-school Observation! Health Room! HMA Assignment! State Certification Record! Supervising Registered Nurse

3.10 Validation through Prototyping

This step, validation through prototyping, is critical because up to this point the solution hasbeen almost entirely paper-based. Even if data models are in a metadata repository, they are stilluntested designs. Data model design testing requires a process model through which the datamodel can be exercised to know that it represents the necessary data in an easy-to-use way.

The first step is to make a database schema. This is accomplished by importingcollections, or subsets of collections of entities into a database’s schema. Once represented as adatabase schema, a code generator that ingests the schema can materialize an actual database-centric application.

Once the application is generated, it can be electronically “shaped” to match a desiredbehavior model, and then demonstrated to users. User feedback is essential because that’s when



9

you hear, “Where’s the XYZ data?” Reviewing something on paper is just not sufficient. Once areview is done, and the comments are all logged, just throw the generated application away. Ifthere are changes to the data models, then make the changes and regenerate the prototypeapplication. Once a series of cycles is performed, eventually the application and the data modelwill become stable. If there are six such cycles, all within a two-month period, then that’s likeimplementing at version six versus implementing at version one, and then expending two orthree years achieving the same design. For sure, this strategy is faster, cheaper, and far moreeffective.

In the case study, the database’s schema was able to be quickly created because all theentities, attributes and relationships existed in the metadata repository. A schema with all thetables was created in one afternoon. It was reviewed. The application was generated about twohours later. Another day was spent pruning the application prior to demonstration. Then, therewere six sessions with relevant subject matter experts set up; one every two weeks. That wasmore than enough time to cycle back in the changes to the data model, the database’s design, andthe generated application.

4. Where to Put Your Data Model

The data models should be placed into a metadata repository that is integrated and nonredundant.The model of such a metadata repository is similar to the one in Figure 2. Each box represents acategory of metadata and is sometimes called a meta-entity. This is a very high level subsetrepresentation of the metadata repository data model. The diagram shows that the obvious placeswhere the results from steps 3.1 through 3.8 are stored. Step 3.9 produces the metadata for thesubject, entity, and attribute meta-entities. Relationships among entities are not shown. Step 3.10causes the creation of the metadata for the business information system, module, database table,and column meta-entities. Relationships among tables are not shown.

It is sometimes stated that metadata repositories are too expensive and take too long toimplement. Thus, they are an impractical solution. This is not true because if you are an IT datamanagement professional, then a metadata repository capable of storing all the metadataidentified in this paper and performing all the functions this paper describes can be purchased forless than one-day’s consulting fee. A fully sophisticated code generator can be purchased for lessthan three-days of consulting fees. The products exist. The way and the strategy exist.

If these tools are used on this project, then they are also available for other projects. Ifproperly used, these tools enable data integration and reuse such that subsequent projects are ofhigher quality, lower risk, lower cost and the involved staff are much more productive. Thereis no downside to increasing the sophistication of the workers and their work tools. Thesophistication of solutions increases, the ability of non-IT staff to accomplish work of this natureincreases, and the overall data integration and reuse greatly expand. Again, there is no downsideto employing more sophisticated tool sets.



10

Mission

MissionOrganizations

MissionOrganization

Function

Organization

Functions

Database Objects


Systems

Database Domains

Database Tables

DatabaseSchema

Columns

Attribute Entity Subject

Module

Figure 2. High level representation of metadata repository subset.



11

5. How to Build a Database Design

The database’s design starts after Step 3.10 is complete. Existing at that point, is a functionallyacceptable database design that conforms to business policy requirements. It is most likely notcomplete from an Information Technology point of view, however.

The complete iterations of database design include:

! Ensuring that the database schema meets business policy requirements aresatisfied. (Steps 3.1 through 3.10)

! Incorporating database structures to properly reflect historical data.

! Adding database columns to support comprehensive audits.

! Installing security devices to protect against data and process misuse and theft.

! Inclusion of database administrator special columns and processes.

! Creating generalized versus specialized data structures to support multiple usedata.

Once a database schema has been created and the database application completed, there maybeother iterations such as:

! Tuning database structures to ensure adequate performance.

! Accommodating different flavors of SQL syntax for different databasemanagement systems (DBMS).

! Installing special key structures instead of business-fact-based keys.

! Accommodating the special physical database requirements of different DBMS.

! Modifying database structures to support special or intensive analyses andreporting.

Finally special iterations of a database’s design may be needed for:

! Ensuring that the database is “non-stop” and always optimized.



12

! Accommodating the needs of client/server, the Internet, or Service OrientedArchitectures, or combinations of all three.

These iterations are all addressed in a Whitemarsh paper, Iterations of Database Design that isidentified in Section 7, References.

In terms of the case study, software systems like Clarion for Windows can interact withMS/Access databases through ODBC and JDBC. So, if the original objective is to have a simple,efficient, and an effective database-centered application to manage the HMA area, this objectiveis achievable. If the right tool-set for the HMA application is employed, the entire applicationcould be accomplished within two calendar months.

6. Conclusions


! A data model is not the same as a database design.

! The activities for modeling data are an integral part of traditional requirement’s analysisand design.

! Metadata resulting from the activities in all the steps of Section 3 should be stored in ametadata repository.

! Database design begins in earnest after the database has been functionally validatedthrough prototyping.

! From an architecture and engineering point of view it is both invalid and counterproductive in terms of semantic integration, nonredundancy, and enterpriseinteroperability to begin real business system design and implementation until after a datamodel has been throughly validated.

If sophisticated processes, methodologies, and tool sets s are used on projects such as this, thenthere will be greater data integration on this project and on subsequent projects. The overallresults will be of higher quality. There will be fewer under specified processes, bad orconflicting edits, schools without certified HMAs, and the like. Finally, because the developingstaff is all professionals, many with advanced degrees, these sophisticated processes,methodologies and tool sets are well within their capabilities. There is no downside to increasingthe sophistication of the workers and their work tools.



13

7. References


The following documents are available free from the Whitemarsh website:

Paper URL

Iterations of Database Design http://www.wiscorp.com/iterations_of_database_design.pdf

Data Management Conferences http://www.wiscorp.com/dama2002.ziphttp://www.wiscorp.com/dama2003.ziphttp://www.wiscorp.com/wrad2000.zip


Metabase Overview http://www.wiscorp.com/metabase.zip


Paper URL




A32 Metabase Rationale and Knowledge Worker Framework With MetaModels


82

Metabase Overview, Meta Model Entity Relationship Diagrams,

and the Knowledge Worker FrameworkMarch 2011





Table of Contents

Rationale for Metabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Metabase Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Metabase Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Relationship to the Knowledge Worker Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Knowledge Worker Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Relationship Among Knowledge Worker Framework Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Metabase: The Metadata Repository for the Knowledge Worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Employing the Metabase within the Knowledge Worker Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Metabase Meta Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Database Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Data Integrity Rule: Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Data Integrity Rules: Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Document and Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Implemented Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Information Needs Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Mission Organization, Function, and Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Operational Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Requirements Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Resource Life Cycle Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Specified Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31User Acceptance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32View Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Wire Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34



Rationale for Metabase1

No one would ever question why a businessneeds it's finance books. Well, the metadatarepository is the business's informationsystems’ books. If you cannot run a goodbusiness without the former, you cannot rungood information systems environmentwithout the latter.

A significant portion of the time and costs associated withresolving the Year 2000 problem can be directly attributedto a lack of a quality metadata environment withininformation systems organizations. The fact that oneinformation system organization within an enterprise hadvirtually no Year 2000 problem while anotherorganization within that same enterprise was running theirinformation systems shop “24x7" was no accident. Theformer had a long history of metadata management andthe later thought metadata was a wasted overhead expense.

Vital to database success is control over semantics.The controls are mainly in the area of the definitions thatform the basis of the interfaces to standard processes (e.g.,computing net profit) and the standard data definitions(e.g., what does profit mean?).

It is not necessary, however, to control theinterfaces to the end user. Just how a data entry screen orreport looks to different people is immaterial so long as

the enforced semantics (rules of meaning and usage) arethe same.

In the development of large data processingprojects dealing with enterprise-wide, indispensablebusiness functions, documentation of the designrequirements and resulting information systemspecifications is seldom accomplished such that it istimely, accurate, or complete. That is disastrous for thefollowing three reasons:

! Only the momentous facts that areremembered are recorded.

! As systems are specified, the lower-leveldesign details are redundantly developed,often in conflicting manners.

! As system components are maintained, theefforts are crippled because of theundocumented business knowledge that isessential to understanding the component.

Amelioration of these three important problems starts withorganizations adopting formal methods for performinganalysis and design. Formal methods are only measurablyproductive and repeatable if they are very detailed andproceduralized. Such detail, however, dehumanizesknowledge workers, who, in turn, are certain to generate


1


protests about being production workers on an assemblyline, which, by the way, is worthwhile only when all of itsproducts are the same. In contrast, to the production line,business information system designs are uniqueassemblies of large sets of components, many of which aresimilar in design.

Designing business information systems is not anactivity for the production worker; rather, it is an activityfor a knowledge worker. While there is clearly procedureto both activities, designing an information systemrequires individualized applications of creativity, humanfactors techniques, and rule making. Accordingly,requiring the robot-like use of a fully detailedmethodology cannot result in responsive informationsystem designs. Work plans must be drawn from proventechniques against which metrics have been captured andhoned over the years.

Building a business information system, once it isdesigned in sufficient detail, is largely a rote application ofcomputer language coding. There are a number of qualityand robust code generators that can use the metadata for abusiness information system design to produce computercode that is competitive in performance to a human codedapplication. There is, of course, no comparison betweenhuman coding costs and code generator costs.

To fully respond to the three problems cited above,knowledge workers should have the freedom to createtheir own analysis and design work products for data and

processes within strictures dealing with format, time,quality, and resources. These work products must beplaced into a metabase. The metabase, containing theseproducts in fixed formats and sequences, can be accessedby code generators (both human and computerized) tobuild the business information system. If the generator isquick enough, a fully functional version of the businessinformation system design can be live-tested a short timelater. As design flaws are found, the metabase's metadatacan be changed and the business information systemregenerated. In short, an interactive design process, inwhich the metabase is the empowering component.

Traditionally, it is not uncommon to expend 20percent of a total systems development lifecycle onrequirements and design. The remaining 80 percent isexpended on building, testing, and documentation. Onceimplemented, 500 percent more is spent over a system'slifecycle for changes, fixes, and evolutions, also in a 20/80ratio. The overall total is 600 percent. If, with codegenerators, the 80 percent is reduced to effectively zero,then there must also be a profound reduction in the 500percent systems lifecycle maintenance.

Metabase Components

The metabase concept implemented as a databaseapplication includes:


2


! Business Information Systems! Business Events! Data Elements! Database Objects! Documents and Forms! Implemented Data Models! Missions, Organizations, and Functions! Operational Data Models! Requirements Management! Resource Life Cycle Analysis! Specified Data Models! Use Cases! View Models

Whitemarsh has implemented these into discrete databaseapplications with Clarion for Windows by theSoftVelocity Corporation (www.softvelocity.com). Thesemetabase systems operate on Windows 98, NT, 2000, XPand 2003 computing environments. Clarion for Windowswas chosen because it meets the Whitemarsh requirementsof sophisticated code generators coupled withsophisticated metadata management within itsenvironment. Metabase environments are distributed toWhitemarsh website members in the form of SQLloadable metadata. The data management engine of themetabase is SQL via ODBC. Access to metabases can bethrough ODBC clients such as Crystal Reports.

Metabase Benefits

The complete set of metadata components map onto thecomplete life cycle of database application, that is, its:

! Specification! Implementation! Operation (and maintenance)

The following is a partial list of benefits attained throughthe use of a metabase. A metabase will:

! Assist top management in identifying theresources required to build an informationsystem.

! Provide discipline and control for the designprocess.

! Provide a structured approach to conceptualdesign.

! Enhance the application developmentprocess through the utilization of prior work.

! Provide a management facility formonitoring database projects.


3


! Allow for the nonredundant storage of datadefinitions and business policies thatproduce greater consistency throughout theenterprise.

Relationship to the Knowledge Worker Framework

The metabase does not exist in isolation. It is the metadatarepository for the Whitemarsh Knowledge WorkerFramework, which correlates very closely with themajority of the Federal Enterprise ArchitectureFramework.

The table on the next page depicts the knowledgeworker framework. As John Zachman so often says,“Someday, you are going to wish you had all thosemodels, enterprise wide, horizontally and verticallyintegrated at an excruciating level of detail.” That is easyto say, and may even be easy to believe, but is there anyproof? The figure that follows the knowledge workerframework diagram presents the percentages of projectsthat fail when the metadata inferred by the cell has notbeen created, employed and maintained. Simply put, yesthere is proof to Zachman’s admonition..

Related Materials

The Knowledge Worker Framework is described in detailin the Knowledge Worker Framework book that isavailable on the Whitemarsh website, www.wiscorp.com.Also available on the website is the Metabase system anduser guides and also the Data Modeler Architecture andConcept of Operations.

Supporting the Whitemarsh metabase and theknowledge worker framework is a large collection ofcourses, books, methodologies, project management tools,and seminars. These are all geared to achieve fourobjectives:

! Increase productivity! Increase quality! Decrease cost! Decrease risk

On every serious project the savings derived fromWhitemarsh product use has exceeded their cost.


4



Deliverables Mission

Man-Machine Interface

Machine Interface Man

Database ObjectBusiness InfoSystem Business Event Business Function Organization

Scope List of businessmissions

List of majorbusiness resources

List of businessinformation Systems

List of interfaceevents

List of majorbusiness scenarios

List of organizations

Business Missionhierarchies

Resource LifeCycles

Informationsequencing andhierarchies

Event sequencingand hierarchies

Business scenariosequencing andhierarchies and usecases

Organization charts,jobs and descriptions

System Policy hierarchies Data Elements,Specified datamodels andIdentified Database objects

Information systemdesigns

Invocationprotocols, input andoutput data, andmessages

Best practices,quality measures andaccomplishmentassessments

Job roles, responsibilities, andactivity schedules

Technology Policy executionenforcement

Implemented datamodels and DetailedDatabase Objects

Information systemsapplication designs

Presentation layerinformation systeminstigators

Activity sequencesto accomplishbusiness scenarios

Procedure manuals,task lists, qualitymeasures andassessments

Deployment Installed businesspolicy andprocedures

Operational datamodels

Implementedinformation systems

Client & serverwindows and/orbatch executionmechanisms

Office policies andprocedures toaccomplish activities

Daily schedules,shift and personnelassignments

Operations Operating business

ApplicationInterface data model

Operatinginformation systems

Start, stop, andmessages

Detailed procedure based instructions

Daily activityexecutions, andassessments


5



Row Totalsof GAO AllocatedErrors inPercentDeliverables Mission

Man-Machine Interface

Machine Inter-face Man

DatabaseObject

BusinessInformation

SystemBusiness

EventBusinessFunction

Organ-ization

Scope 5 2 3 1 3 4 18

Business 5 3 2 1 6 6 23

System 3 2 2 1 12 8 28

Technology 1 0 0 0 8 6 15

Deployment 0 0 0 0 5 5 10

Operations 0 0 0 0 3 3 6

Col. Totals 14 7 7 3 37 32 100

Note: All numbers expressed as Percent allocations of errors to cells ...12 Gray cells are Information Technology Cells. IfIT were Zero Percent Failure, 95% of all IT Systems would still fail.


6


Relationship Among Knowledge Worker Framework Columns

Each Knowledge Worker Framework column generally defines a key metabase model


7


Metabase: The Metadata Repository for the Knowledge Worker


8


Employing the Metabase within the Knowledge Worker Framework

Metabase Software Module


Mis

sion

Dat

abas

eO

bje

cts

Bu

sin

ess

Info

rmat

ion

S

yste

m

Bu

sin

ess

Eve

nt

Bu

sin

ess

Fu

nct

ion

Bu

sin

ess

Org

aniz

atio

n

Mission, Organization, Function PositionAssignment

U U U U

Resource Life Cycles U U

Document & Form, Information Needs,Characteristics, Requirements Analysis, andUse Cases

U U

Data Modeler! Data Elements! Specified Data Model! Implemented Data Model! Operational Data Model! View Data Model

U U

Business Information Systems U

Information Systems Planning U U U U U U


9


Business questions addressed by the metabase modules within the Knowledge Worker Framework


Knowledge Worker FrameworkColumns

Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion

Mission Analysis

What are the essential missions that define the very existence of theenterprise, and that are the ultimate goals and objectives that measureenterprise accomplishment from within different business functions andorganizations?

U U U

Functional Analysis

What procedures are performed by groups in their achievement the variousmissions of the enterprise from within different enterprise organizations?

U


10





Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion

Organizational Analysis

Which organizations are accomplishing what aspects of missions with whatdatabases, information systems and through which functions?

U U U U


What are the key Resources (facilities, materiel, staff, etc.)?How are theysequenced, interrelated, and how are they supported through databases andinformation systems?

U U


11





Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion

Information Needs

What information (a.k.a. query results or reports) is needed by variousorganizations in their functional accomplishment of missions and whatdatabases and information systems provide this information?

U


12





Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion

Documents and Forms

What documents and forms provide critical information about the enterprise?How are those documents and forms interrelated one with the other? How arethese materials subdivided and then properly related to specific functionsperformed by organizations in the accomplishment of missions? How arethese able to be related to certain View columns?

U U U U U U


13





Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion


What are the requirements that in total support the development of keyenterprise database components? How these requirements are interrelated,subdivided, and then related to the various metadata components that are“required” as a consequence? How can the complete set of effects can beknown and interrelated?

U U U U U U


14





Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion

Use Cases

What are the detailed business process scenarios required to accomplish thenecessary work of the enterprise? What are the interrelationships among usecases? How are the use cases subdivided into certain events? What are thepre-, post-, and special-conditions of these use cases? What are the businessfacts that are read, selected, updated, and reported within use cases? Whatare the relationships between use case facts and database view columns?

U U U U U U


15





Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion

Database

What data is needed by functional proponents, how is it defined within dataarchitectures and databases and how and where are those databasesdeployed and then used by business information systems in support of missionaccomplishment.

U


16





Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion

Data Mode Management

What are the context independent semantic templates of data elements andhow are these configured into models of data (the consequence of policyexecution) determined as needed by functional experts in support ofenterprise missions, and how are these specified data model requirementsconfigured into implemented databases that ultimately operate within variousorganizations as they perform the functions needed by enterprise missions.

U U


17





Mis

sion

Dat

abas

e O

bjec

ts

Bus

ines

s In

form

atio

n S

yste

ms

Bus

ines

s E

vent

Bus

ines

s F

unct

ion

Bus

ines

s O

rgan

izat

ion


Exactly what are the business information systems, where are they, how arethey related to mission, organization, function, and databases. What is theimpact on these business information systems when policy (a.k.a., data) isrequired or changed.

U


18


Metabase Meta Models

! Business Information Systems! Database Objects! Data Elements! Data Integrity Rule: Specification! Data Integrity Rules: Binding! Document and Form! Implemented Data Model! Information Needs Analysis! Mission Organization, Function, and Position! Operational Data Model! Project Management! Requirements Management! Resource Life Cycle Analysis! Specified Data Model! Use Cases! User Acceptance Tests! View Data Model! Wire Frames


19




System

DBMS Environment

Application Type


PredominantUserClass

Resource Life Cycle

Node

Resource Life Cycle Node Business

Information System Assignment

Resource


08/18/2005

Business Information System Database Object Information

System Assignment

Database Object Information

System

View

Business EventMission,

Organization, & Function

View Column




Systems & View

Business Event Cycle

Business Cycle Structure Type

Business Event Cycle Structure

Calendar Cycle

Calendar Cycle Structure Type

Calendar Cycle Structure


Level (Control, Management, Operational )

Construction Method (Custom,

Code Generator, COTS)

Status (Development, Maintenance, Production)

Programming Language

Data Architecture

Class

EnviornmentType


20


Database Objects

Database Object

database object state and database object information

system

database object information system and

database object process

database object information

system

database object state

database object process column


processdata element

column

table

membership rationale


Database Domain

Database Domain & Database

Object

Database Objects Copyright 2005, Whitemarsh Information Systems Corporation,All Rights Reserved

04/12/2005

Business Information System Database

Object Information System Assignment

Business Information System

Schema


21


Data Elements

Compound Data Element & Derived

Data Element


Value

Compound Data Element & Data

Element


Data Element Concept & Meta Category Value


Meta Category Value

Derived Data Element & Data

Element

Data Element

Business Domain


01/25/2003


Data Elements


Classification

Compound Data Element Structure


Structure TypeValue Domain

Conceptual Value

Domain


Structure


Structure Type

Conceptual Value Domain

Structure

Conceptual Value Domain Structure Type



Structure Type


Data Element & Data Element Classification

Data Element ConceptValue Domain

Structure

Value Domain Structure Type

Value Domain Data Type

Value Domain Values

Value Domain Values Structure

Value Domain Values

Structure Type

ConceptConceptStructure

Concept Structure

Type


22


Data Integrity Rule: Specification

Table

Column Input

ActionValidateSelectInput

Data Integrity

Rule

Column

Schema

Column Action

Column Validate

Column Select

Data Integrity Rule Structure

Data Integrity Rule Structure Type

Data Integrity Rule Specification



23


Data Integrity Rules: Binding

Data Integrity RuleData Integrity Rule Structure

Type

Data Integrity Rule

Structure

Data Integrity Rule Type


Process



View ColumnDBMS Column

Column

Attribute

Data Element

Entity

Table

DBMS Table

View


& Derived Data Element


Database Object

Database Object Object Table Process

Column

Data Integrity RuleMeta Entity Mapping

Metabase Meta-Entity

Type

Data Integrity Rule Binding



24


Document and Form

Document and FormCopyright 2004, Whitemarsh Information Systems Corporation,


View

Business Event

View Column




Organization

Function

Mission



Document Section

DocumentCell


Function&

Document Section

Document Cell&

View Column

DocumentDocument Structure

Document Structure Type

FormSection

Form CellForm Cell

&View Column

FormForm

StructureForm

Structure Type


Function&

Form Section


25


Implemented Data Model

Data Element & Meta

Category Value



Meta Category Value

Meta Category Value

Table Primary Key

Column

Table

Table Primary Key & Column

Table Foreign Key

Table Foreign Key & Column

Attribute

Entity

Subject

Data Element

Business Domain

Column & Meta Category

Value

Schema



SQL Data Type

Implemented Data ModelCopyright 2006, Whitemarsh Information Systems

Corporation,All Rights Reserved

01/26/06


TableCandidate

Key

TableCandidate Key &

Column



Structure Type

Value Domain


26


Information Needs Analysis

Characterisitic

Characteristic Type

Ranking


Information Need

Mission, Organizational

Functional Ranked Information Need

Information Need Characterisitic Assignment

Organization

Function

Mission




27


Mission Organization, Function, and Position


Function Position

Mission, Organization, Function, Position

Organization

Function

Mission



Database Domain

Database Domain & Database Object

Database Object


8/23/2005

Business Event


System

Management Level

Person

Position


Function PositionPerson


28




Value

Meta Category Value

Column

Table

Database

Data Element

Business Domain


Schema

DBMS DBMS Schema

DBMS Column

DBMS Table



06/01/2005

DBMS Data Type

DBMS Table

Primary Key

DBMS Table Primary Key & DBMS Column

DBMS Table Foreign Key &

Column

DBMS Table Foreign Key

Meta Category

Value Type

SQL Data Type



Classification

Database Architecture Class

DBMS Table CandidateKey & DBMS Column

DBMS Table Candidate

Key

DBMS Table Secondary

Key

DBMS Table Secondary Key & DBMS Column

Database NatureDatabase

Production Status

DBMS Data Type Picture


29


Project Management

Staff

Phone

Phone Type

Status Type

State

Work

Assigned Task

Task

Project

Task Template

Project Template


Deliverable


Job Title

Organization


Resource

Role Type

Skill Level

Skill

Staff Skill Level


Work Environment

Factor


Contract

Contract Resource


Contract Role

Skill Level Type





Base Line

Base LineWEF

Base LineStaff

RLC Node


30




Requirement Category

Requirement

Mission Organization &

Function


3/08/2011


Type


Resource Life Cycle Node and Requirement

Structure

Use Case and Requirement Structure

Business Event


System

DBMS Column


Data Integrity Rule Structure and

Requirement Structure

Business Event and Requirement

Structure

Business Information System and Requirement

Structure

DBMS Column and Requirement

Structure


Structure and Requirement

Structure

Mission Organization & Function and Requirement

Structure


Data Integrity Rule

Structure

Use Case

Database ObjectDatabase Object and Requirement


31




Information Need

Resource Life Cycle

Node

Resource Life Cycle

Node Structure

Resource Life Cycle Node Information Need

Assignment

Resource Life Cycle Node Information

System Assignment

Database


Database Object Assignment


System

DBMS

Resource


Structure Type

Resource Type

Mission Resources


Mission

DBMS Schema


02/18/2000

Data-base

Object


32


Specified Data Model

Data Element & Meta

Category Value

Data Element ConceptStructure


Meta Category Value

Meta Category

Value

AttributeEntity

SubjectData Element

Business Domain

Entity Primary Key

Entity Primary Key & Attribute

Entity Foreign Key

Entity Foreign Key & Attribute

Attribute & Meta Category Value



Specified Data ModelCopyright 2000, Whitemarsh Information Systems Corporation,





& Attribute



33


Use Cases

Use Cases


Function


01/19/2011

Business Event


SystemUse Case

Use CaseEvent

Use CaseSpecial

Conditions

Use Case Event Actors

Use CasePost

Conditions

Use CasePreconditions

Use Case Events & Mission Organization

Function

Use CaseEvent & Business

Information System

Use Case Facts & Use Case

Preconditions

Use Case Facts & Use Case Events

Use Case Facts & Use Case Post

Conditions

Use Case Facts

SchemaTablesColumns

Use Case Actors

Use Case Actor Role

Use Case Structure

Use Case Structure

Type

Use Case Facts and Columns

Use Case and Use Case Facts

Mission, Organization,

Function, Position, Person


System


34




Use Case Event

User Acceptance

Test


5/04/2010



Type


User Acceptance Test Column

View Column


35


View Data Model

Compound Data Element &



Value


Meta Category Value

Column

Table

Database

Data Element

Business Domain


View

View Column

View Column & Compound Data

Element

View Column & Derived Data

Element

View Column & DBMS ColumnSchema

DBMS

DBMS Schema

DBMS Column

DBMS Table


12/10/2001


SQL Data Type

View Data Model


Classification



Structure


Structure Type




System



System & View


36


Wire Frames

View Column & DBMS Column

Use CaseEvent

ScreenSection

Screen Section Cell

Screen Section Cell

Column

Screen

ViewBusiness Rule

View Column

Screen &Business

Information System

Screen &Business

Information System

Use Case Event & Screen Section

Screen Control

Screen ControlType

DBMS Column

DBMS Table


37


1. Metabase is a term crafted from “metadata database.” The term, metabase, has been used by Whitemarsh since 1981 in reference to the many differentmetadata database systems that Whitemarsh has built for its clients. These metabases have been built in Information Builder’s Focus, CA’s IDMS,.Cincom’s Total, and SoftVelocity Corporation’s Clarion for Windows.


38


A33 Gorman_At Burke_Documents List_Computer Directory Listing


83

Untitled

H:\SEVIS\SEVIS II Architecture\Data Management\Data Conversion Plan and Review\ivv Cotnments_Data_Conversion_plan_20090603_Gorman.doc

H:\SEVIS\SEVIS II Architecture\oata Management\iw Comments_Data_Conversion_plan_20090603_lVV Submitted.doc

H:\SEVIS\SEVIS II Architecture\Data Management\Data Management issues and Analyses\Data Management issues_2009_05.doc

H:\SEVIS\SEVIS II Architecture\Data Management\Data Management issues and Analyses\oata Management Review of Work Products Approach.doc

H:\SEVIS\SEVIS II Architecture\Data Management\Data Management Issues and Analyses\Requirements Process sessions, Data Models, and Data Management QA.doc

H:\SEVIS\SEVIS II Architecture\oata Management\Data Management Issues and Analyses\Requirements Process Three Sentences01.doc

H:\SEVIS\SEVIS n Architecture\Data Management\Data Management ivv Arch and conops\oata Management ivv Architecture and Concept of Operations.doc

H:\SEVIS\SEVIS II Architecture\Data Management\Data Management ivv Arch and conops\oata ivv Domai n_LDM-PDM.vsd

H:\SEVIS\SEVIS 11 Architecture\oata Management\Data Management ivv Arch and conops\oata Management ivv Architecture and Concept of operations_LDM PDM_03.doc

H:\SEVIS\SEVIS n Architecture\oata Management\Data Management ivv concerns\SEVis n Data Management iv&v Concern Conclusions from BAH Meeting.doc

H:\SEVIS\SEVIS n Architecture\pata Management\Data Management ivv concerns\SEVis n Data Management iv&v Concerns Analysis of i-17.doc

H:\SEVIS\SEVIS II Architecture\Data Management\Data Management IVV Concerns\SEVlS II Data Management iv&v Concerns Matrix with sullets.doc

H:\SEVIS\SEVIS II Architecture\oata Management\Data Management iw Concerns\SEViS II Data Management iv&v Concerns_with Consequences.doc

H:\SEVIS\SEVIS II Architecture\oata Management\Data Management ivv Concerns\SEVis II Data Management iv&v Concerns_with Questions Consequences And Conclusions.doc

H:\SEVIS\SEVIS II Architecture\oata Management\Data Management IW Concerns\SEVlS II Data Management iv&v Concerns_with Questions.doc

H:\SEVIS\SEVIS II Architecture\Data Management\Data Management Periodic ivv Report\oata Management ivv Report Outline.doc

I:\SEVIS\SEVIS II Architecture\Data Management\Data Management Periodic ivv Report\Gorman Drafted >ata Management Concerns IVV Report May 2009_Enumerated.doc

I:\SEVIS\SEVIS II Architecture\Data Management\Data Managment Plan and Review\Review of BAH :hanges to DMP (June 2009) from ivv Submitted comments.doc

I:\SEVIS\SEVIS II Architecture\oata Management\Data Managment Plan and Review\iVV_comments_Data lanagement Plan_20090603_ivv Submitted.pdf

I:\SEVIS\SEVIS II Architecture\oata Management\Data Managment Plan and Review\lvv_comments_Data lanagement Plan_20090603_Gorman Submitted.doc

I:\SEVIS\SEVIS II Architecture\Data Management\Data Managment Plan and Review\lVV_Comments_Data lanagement plan_20090527.doc

I:\SEVIS\SEVIS II Architecture\Data Management\Data Models and Eval uations\Data Model ;valuation\Data Model Analysis Document.xls

I:\SEVIS\SEVIS ii Architecture\Data Management\Data Models and Evaluations\Data Model :valuation\oata Model Evaluation Check List.doc

I:\SEVIS\SEVIS ii Architecture\oata Management\Data Models and Eyaluations\Data Model :valuation\Data Model Evaluation September 29 2009 Data Models Via Data Model Evaluation Check .i st.doc

):\SEVIS\SEVIS II Architecture\Data Management\Data Models and Evaluations\Data Model :valuation\Reference Data Master Data And Parameterized Data use Case Analysis_By use Case.doc

H:\SEVIS\SEVIS II Architecture\oata Management\Use case Analysis\(Prod 1, UC 12)_complete Appeal.doc

S:\SEVIS\SEVIS II Architecture\oata Management\Use Case Analysis\(Prod 4, UC 43)_Address i/erif ication.doc

-I:\SEVIS\SEVIS II Architecture\Data Management\SEVlS Products and Packages Development Life :ycle\01 SEVIS Product Package Development Life Cycle.vsd

H:\SEVIS\SEVIS II Architecture\oata Management\SEVis Products and Packages Development Life Cycle\02 SEVIS Package within Product Development Life Cycle.vsd

H:\SEVIS\SEVIS II Architecture\Data Management\SEVlS Products and Packages Development Life :ycle\03 SEVIS individual product Development Life cycle.vsd

H:\SEVIS\SEVIS n Architecture\Data Management\SEVis Products and Packages Development Life :ycle\04 SEVIS Inter-Product Development Life Cycle.vsd

H:\SEVIS\SEVIS II Architecture\Data Management\SEViS Products and Packages Development Life :ycle\05 SEVIS Product Development Life Cycle.vsd

l:\SEVIS\SEVIS II Architecture\Data Management\SEViS Products and Packages Development Life ;ycle\Business Event Management Model.vsd

H:\Burke Consortium\Weekly Activity Log and Status Reports\Weekly Activity Log.txt

H:\Burke Consortium\Weekly Activity Log and Status Reports\Gorman Weekly Report #38 (3-18-09 thru 3-24-09).doc

-i:\Burke Consorti um\Weekly Activity Log and Status Reports\Gorman Weekly Report #66 (9-30-09 thru L0-06-09).doc