prelaunchX Invitation

prelaunchX Invitation: You're invited to join prelaunchX

programing language approaches

Prototype-based programming is a style of object-oriented programming in which classes are not present, and behavior reuse (known as inheritance in class-based languages) is performed via a process of cloning existing objects that serve as prototypes. This model can also be known as class-less, prototype-oriented or instance-based programming. Delegation is the language feature that supports prototype-based programming.

The original (and most canonical) example of a prototype-based language is the programming languageSelf developed by David Ungar and Randall Smith. However, the classless programming style has recently grown increasingly popular, and has been adopted for the programming languages JavaScript,Cecil, NewtonScript, Io, MOO, REBOL, Lisaac and several others.

Comparison with class-based models

With class-based languages, the structure of objects is specified in programmer-defined types calledclasses. While classes define the type of data and functionality that objects will have, instances are "usable" objects based on the patterns of a particular class. In this model, classes act as collections of behavior (methods) and structure that are the same for all instances, whereas instances carry the objects' data. The role distinction is thus primarily based on a distinction between structure and behavior on the one hand, and state on the other.

Advocates of prototype-based programming often argue that class-based languages encourage a model of development that focuses first on the taxonomy and relationships between classes. In contrast, prototype-based programming is seen as encouraging the programmer to focus on the behavior of some set of examples and only later worry about classifying these objects into archetypal objects that are later used in a fashion similar to classes. As such, many prototype-based systems encourage the alteration of prototypes during runtime, whereas only very few class-based object-oriented systems (such as the dynamic object-oriented system, Smalltalk, or Perl) allow classes to be altered during the execution of a program.

While the vast majority of prototype-based systems are based on interpreted and dynamically typedprogramming languages, it is important to point out that statically typed systems based on prototypes are technically feasible. The Omega programming language discussed in Prototype-Based Programming ^[1] is an example of such a system, though according to Omega's website even Omega is not exclusively static but rather its "compiler may choose to use static binding where this is possible and may improve the efficiency of a program."

Object construction

In class-based languages a new instance is constructed through the class's constructor and an optional set of constructor arguments. The resulting instance is modeled on the layout and behavior dictated by the chosen class.

In prototype-based systems there are two methods of constructing new objects, through cloning of an existing object, and through ex nihilo ("from nothing") object creation. While most systems support a variety of cloning, ex nihilo object creation is not as prominent.^[2]

Systems that support ex nihilo object creation allow new objects to be created from scratch without cloning from an existing prototype. Such systems provide a special syntax for specifying the properties and behaviors of new objects without referencing existing objects. In many prototype languages, there is often a basic Object prototype that carries commonly needed methods and is used as a master prototype for all other objects. One useful aspect of ex nihilo object creation is to ensure that a new object's slot names do not have namespace collisions with the top-level Object object. (In the MozillaJavaScript implementation, one can accomplish this by setting a newly constructed object's __proto__property to null.)

Cloning refers to a process whereby a new object is constructed by copying the behavior of an existing object (its prototype). The new object then carries all the qualities of the original. From this point on, the new object can be modified. In some systems the resulting child object maintains an explicit link (via delegation or resemblance) to its prototype, and changes in the prototype cause corresponding changes to be apparent in its clone. Other systems, such as the Forth-like programming language Kevo, do not propagate change from the prototype in this fashion, and instead follow a more concatenative model where changes in cloned objects do not automatically propagate across descendants.^[3]

// Example of true prototypal inheritance style 
// in JavaScript.
 
// "ex nihilo" object creation employing the literal 
// object notation {}.
var foo = {one: 1, two: 2};
 
// Another "ex nihilo" object.
var bar = {three: 3};
 
// Gecko and Webkit JavaScript engines can directly 
// manipulate the internal prototype link.
// For the sake of simplicity, let's just pretend 
// that the following line works regardless of the 
// engine used:
bar.__proto__ = foo; // foo is now the parent of bar.
 
// If we try to access foo's properties from bar 
// from now on, we'll succeed. 
bar.one // Resolves to 1.
 
// The child object's properties are also accessible.
bar.three // Resolves to 3.

Delegation
In prototype-based languages that use delegation, the language runtime is capable of dispatching the correct method or finding the right piece of data simply by following a series of delegation pointers (from object to its prototype) until a match is found. All that is required to establish this behavior-sharing between objects is the delegation pointer. Unlike the relationship between class and instance in class-based object-oriented languages, the relationship between the prototype and its offshoots does not require that the child object have a memory or structural similarity to the prototype beyond this link. As such, the child object can continue to be modified and amended over time without rearranging the structure of its associated prototype as in class-based systems. It is also important to note that not only data but also methods can be added or changed. For this reason, most prototype-based languages refer to both data and methods as "slots".

Concatenation
Under pure prototyping, which is also referred to as concatenative prototypes, and is exemplified in the Kevo language, there are no visible pointers or links to the original prototype from which an object is cloned. The prototype object is copied exactly, but given a different name (or reference). Behavior and attributes are simply duplicated as-is.
Advantages to this approach include the fact that object authors can alter the copy without worrying about side-effects across other children of the parent. A further advantage is that the computational cost of method lookup during dispatch is drastically reduced when compared to delegation, where an exhaustive search must be made of the entire delegation chain before failure to find a method or slot can be admitted.
Disadvantages to the concatenative approach include the organizational difficulty of propagating changes through the system; if a change occurs in a prototype, it is not immediately or automatically available on its clones. However, Kevo does provide additional primitives for publishing changes across sets of objects based on their similarity (so-called family resemblances) rather than through taxonomic origin, as is typical in the delegation model.
Another disadvantage is that, in the most naive implementations of this model, additional memory is wasted (versus the delegation model) on each clone for the parts that have stayed the same between prototype and clone. However, it is possible to provide concatenative behavior to the programming while sharing implementation and data behind-the-scenes; such an approach is indeed followed by Kevo.[4].
An alternative quasi-solution to the problem of clones interfering with the behavior of the parent is to provide a means whereby the potential parent is flagged as being clonable or not. In MOO, this is achieved with the "f" flag. Only objects with the "f" flag can be cloned. In practice, this leads to certain objects serving as surrogate classes; their properties are kept constant to serve as initial values for their children. These children then tend to have the "f" flag not set.

Criticism
Advocates of class-based object models who criticize prototype-based systems often have concerns that could be seen as similar to those concerns that proponents of static type systems for programming languages have of dynamic type systems (see Datatype). Usually, such concerns involve: correctness, safety, predictability, and efficiency.
On the first three points, classes are often seen as analogous to types (in most statically typed object-oriented languages they serve that role) and are proposed to provide contractual guarantees to their instances, and to users of their instances, that they will behave in some given fashion.
On the last point, efficiency, the declaration of classes simplifies many compiler optimizations that allow developing efficient method and instance variable lookup. For the Self language, much development time was spent on developing, compiling, and interpreting techniques to improve the performance of prototype-based systems versus class-based systems. For example, the Lisaac compiler produces code almost as fast as C. Tests have been run with an MPEG-2 codec written in Lisaac, copied from a C version. These tests show the Lisaac version is 1.9% slower than the C version with 37% fewer lines of code[5].
The most common criticism made against prototype-based languages is that the community of software developers is not familiar with them, despite the popularity and market permeation of JavaScript. This knowledge level of prototype based systems seems to be changing with the proliferation of JavaScript frameworks and increases in the complex use of JavaScript as "Web 2.0" matures.

programe developement phases

5.1         Introduction

_____________________________________________________________

5.1.1         Purpose

During the Development Phase the Project Manager and the System Development Manager work closely together to develop, assemble, integrate, and test the AIS, and to update and finalize the plans for the deploying the AIS.

During the Development Phase the Project Manager and the System Development Manager work closely together to:

a.       Develop, integrate, and test the AIS,

b.      Update and finalize plans to deploy the AIS, and

c.       Complete business transition planning and initiate business transition activities.

5.1.2         Overview

The Development Phase is divided into two stages: Construction and Production Readiness. In the Construction Stage, the System Development Manager ensures that all AIS subsystems, modules, and components are fully documented, have been coded and tested, and that identified discrepancies have been corrected.  The Construction Stage is completed when the Technical Review Board provides approval at Test Readiness Review., Earlier test results are reviewed and operational support arrangements are finalized during the Production Readiness Stage. The Production Readiness Stage ends with successful completion of the Production Readiness Review.  This review affirms that Acceptance Testing has been successfully completed and that the AIS is suitable for production use.

5.1.3         Tasks

The tasks to be completed during the Development Phase are:

a.       Allocate resources to support the current project plan.

b.      Complete business transition planning, and begin business transition activities.

c.       Perform component provisioning of reusable components.

d.      Code software that is not commercial off-the-shelf (COTS) and is not generated by the CASE tools.

e.       Perform module construction and application assembly of reusable components, and complete integration.

f.       Complete acquiring equipment and approved COTS software for the AIS.

g.      Complete AIS support documentation, including training.

h.      Perform system testing activities to include unit and integration testing, performance, and stress testing.

i.        Update the Configuration Management Plan.

j.        Perform a Configuration Management Build.

k.      Update the Economic Analysis.

l.        Update the Project Management, AIS Development, and Quality Assurance Plans.

m.    Update support plans.

n.      Develop the Production Installation and Data Conversion Plans.

o.      Update the technical architecture with details of the physical implementation.

p.      Perform Formal Qualification Testing[1] (FQT) and Beta Testing[2].

q.      Obtain approval to install the AIS into work areas.

r.        Software  development environment planning activities should be defined and submitted to OSDM/SDI.

5.1.4         Activities and Documentation

Development Phase activities and documentation requirements as summarized in the following table must conform to the indicated Technical Standard and Guidelines or other standards as noted.  Work products included in the Product Baselines are identified under the “Baseline” heading in Table 5.1.4.  Published standards and guidelines may be augmented by tailoring and documented in the Quality Assurance Plan.

Work Product	TSG  / Standard	Who’s Responsible	Must Create	Should Update	Must Update	Base- line	Must Complete
Business Case		Program Sponsor, Project  Manager				X
Project Management Plan and supporting baseline project schedules	IT-212.2-01	Project Manager, System Development Manager			X
AIS Project Quality Assurance Plan	IT-212.2-04	Office of System Product Assurance		X
Data Management Plan	IT-212.2-05	Office of Data Management		X			X
Data Conversion Plan	IT-212.2-05	System Development Manager	X				X
AIS Configuration Management Plan	IT-212.2-06	Office of System Product Assurance		X			X
Concept of Operations	IT-212.2-11	Program Sponsor, Project Manager			X		X
Detailed Design	IT-212.2-12	System Development Manager			X		X
Economic Analysis	IT-212.2-13	Project Manager, System Development Manager			X		X
Business Transition Plan	IT-212.3-05	Program Sponsor, Project Manager		X			X
Requirements Specification	IT-212.3-10	System Development Manager		X		X	X
Test Plan and Materials	IT-212.3-01	Office of System Product Assurance			X	X	X
Test Specifications and Procedures	IT-212.3-01	Office of System Product Assurance	X				X
Training Plan and Materials	IT-212.3-02	System Development Manager			X	X
Requirements Traceability Matrix	IT-212.3-11	Office of System Product Assurance		X

Table 5.1.4 Development Phase Activities and Documentation Requirements

Work Product	TSG  / Standard	Who’s Responsible	Must Create	Should Update	Must Update	Base- line	Must Complete
Users Manual and/or Guide	IT-212.4-13	System Development Manager	X				X
Infrastructure Disaster Recovery Plan	IT-212.2-08	Office of System Network Management	X				X
Programmer Maintenance Manual	IT-212.4-15	System Development Manager	X				X
CM Build Instructions with Version Description Document	IT-212.2-06	System Development Manager	X				X
Production Installation Plan	IT-212.5-01 01	System Development Manager	X				X
Operational Support Plan	IT-212.5-01	System Development Manager					X

Table 5.1.4 Development Phase Activities and Documentation Requirements (Concluded)

5.2         System Development

_____________________________________________________________

5.2.1         Software Development and Construction

Reviews, inspections and walk-throughs will be scheduled, conducted, tracked, and the results reported in accordance with the project's Quality Assurance Plan.

Application code, databases, database conversion software, interfaces, and code to integrate COTS products into the AIS are constructed during the Development Phase.  The following points apply to software development.

a.       To improve software documentation and maintainability, whenever possible, changes to AIS application code will be implemented using USPTO standard CASE tool procedures.  For later enhancement or maintenance, source code that had been automatically generated will be regenerated and not manually modified.

b.      All code will be designed, documented, and developed using modern software development concepts, tools, and techniques.  The supporting documentation will be reviewed by the Office of System Product Assurance for accuracy, efficiency, completeness, and ease of use.

c.       Developers will thoroughly document and test all software that performs automated conversion of data from existing to new databases. The supporting documentation will be reviewed by the Office of System Product Assurance for accuracy, efficiency, completeness, and ease of use.

d.      Using the component specification, the component provisioning task delivers an executing and tested implementation of the component.  Each component implementation is designed, coded, and tested.  For each reusable CASE component:

·         The component is specified in the CASE encyclopedia.

·         The component implementation model is constructed to meet the component specification model.

·         The component executable is generated from the component implementation model.

e.       The component publishing task places the component specification in a USPTO Enterprise Repository component catalog that should be browsed for review in future projects.  Publishing produces an installation package to deploy the component into an AIS development environment.  The entire model specification, including the data and behavior of the component, should be published for browsing.

f.       TRM designated programming languages will be used in all USPTO multi-user applications.  Nonstandard, high-order programming languages, as are commonly associated with COTS products, may be used for single user applications or where it can be shown to be more cost-effective for multi-user applications.

g.      To help ensure code portability and scalability, developers will not use vendor-unique extensions unless it can be shown to be cost-effective over the life of the application.  Waiver requests to use vendor-unique extensions must be submitted to the Technical Review Board for approval.  Waivers are not required to use:

·         COTS software packages and advanced software technology that is not modified or maintained by the USPTO and can operate on the USPTO information technology infrastructure.

·         Programming languages that require installation of vendor-provided updates to COTS software.  Use of such languages shall be restricted to implementing the vendor updates.

5.2.2         Integration

Hardware, software (including COTS software), and documentation components which have been individually tested are assembled into functional subsystems and systems in accordance with the project's quality assurance and configuration management plans. Application components must be integrated.  Either part or all of an entire application may be built by assembling components.  The component verification activity includes installation of components into the environment where they will reside when assembled into an application to verify that installation procedures work. The System Development Manager will complete and update all system design and support documentation in accordance with the applicable Technical Standards and Guidelines.  Integration may be performed iteratively with increasingly larger and more complex combinations of components.  The steps in which integration will occur shall be documented in the project's AIS project management and test plans.  Integration is completed when the entire AIS has been assembled, integration level testing has been performed, and integration test results have been approved by the Technical Review Board at Test Readiness Review.

5.3         Testing and Reviews

_____________________________________________________________

Unit, integration, and independent acceptance testing activities are performed during the Development Phase.  Unit and integration testing are performed under the direction of the Project Manager and System Development Manager.  Independent acceptance testing is performed independently from the developing organization and is coordinated by the Office of System Product Assurance.  The independent acceptance testing activities performed during the Development Phase are Formal Qualification Testing and Beta Testing.  Defects uncovered by acceptance testing may lead to changes in the work products created in the Concept, Detailed Analysis and Design, and Development Phases.  The technical standards and guidelines for those phases apply, as needed, during the Development Phase. As much as possible, acceptance testing will be performed in a test environment that duplicates the production environment.  The Technical Review Board reviews the results of each test. Additional information on testing is provided in the Testing TSG, IT-212.3-01.

5.3.1         Design Characteristics

Each program module will be separately tested and verified to ensure that all applicable business requirements and module interface specifications are addressed, and that all unit products conform to design specifications.

Each program module will be separately tested and verified to ensure that all applicable business requirements and module interface specifications are addressed, and that all unit products conform to design specifications.  Unit testing should verify that every logical path through the pseudo-code (or detailed module description) is implemented and functions as designed, and that no unit level code is accepted that is not designed and documented). All errors and discrepancies noted will be corrected.

5.3.2         Independent Security Testing

The Office of System Product Assurance and the Office of Information Systems Security will conduct independent system security testing during the Development Phase.  System security testing includes both the testing of the particular AIS components, including both purchased and “in-house developed” components, and the testing of the entire AIS.  Security management, physical facilities, personnel, procedures, the use of commercial or COTS products, the use of OCIO services (such as PTOnet services), and contingency plans are examples of security areas that affect the entire AIS.  Because Project Managers or System Development Managers usually specify or determine requirements relating to these security areas before or after the Development Phase, additional security testing is usually necessary throughout the life of the system. The Operational Support TSG, IT-212.5-01, and the Testing TSG, IT-212.3-01, provide additional information about testing AIS security requirements.

5.3.3         Peer Reviews

Peer reviews will be conducted on designated critical AIS projects to identify and remove defects from the products early and efficiently.  Peer reviews can be particularly effective when used to review the work products and documentation developed during the Detailed Analysis and Design and Development phases of the life cycle.  AIS or infrastructure project development documentation will be reviewed in accordance with the Quality Assurance TSG, IT-212.2-04.  For designated AIS projects, reviews, inspections and walk-throughs will be scheduled, conducted, tracked, and the results reported in accordance with the project's Quality Assurance Plan.

5.3.4         Test Readiness Review

This review is conducted at the end of the Development Phase to determine whether unit and integration testing has been conducted in accordance with the test procedures and that the tests are complete.  The Project Manager reviews and approves test procedures, specifications, test procedure modifications (i.e., redlines), and the results of all integration tests before requesting Technical Review Board review and approval of integration testing at Test Readiness Review.  A version of the Developmental Configuration is placed under formal configuration management after Test Readiness Review and is used for acceptance testing. 

5.3.5         COTS Acceptance Testing

Acceptance testing of COTS products will be performed and all problems and defects will be corrected in accordance with the terms of the contract or other purchase agreement.  Unit level testing of COTS products may not be required in circumstances where acceptance testing of the COTS product has been performed and documented.  COTS acceptance testing procedures and specifications, and all results of COTS acceptance testing will be reviewed, and if accepted by the Project Manager, will forwarded to the Technical Review Board for review and approval at Test Readiness Review.  The Office of System Product Assurance may perform independent testing of COTS products.

5.3.6         Integration Testing

Integration testing verifies the interoperability of AIS modules, components, and subsystems, up to the complete AIS, to ensure that all functional and technical objectives are achieved.  Typically, test data must be specifically designed and developed to ensure full coverage of all requirements, and to ensure that all procedural and control options in the AIS code are tested.  When possible, actual data should also be used in integration testing to ensure consistency between AIS specifications and the desired business process.  The results of all integration tests must be recorded.  Test Procedures are corrected by redlining the test procedures document to show changes.

5.3.7         Formal Qualification Testing (FQT)

Formal Qualification Testing is an independent acceptance testing activity performed on an approved Configuration Management Build by the Office of System Product Assurance.  During this testing activity all AIS functional capabilities, including security measures, are independently exercised to verify that the AIS meets all functional and security requirements.  Formal Qualification Testing is performed against the requirements identified in the project's Requirements Traceability Matrix in accordance with the redlined test specifications and test procedures developed during integration testing.

5.3.8         Beta Readiness Review

When a Beta Readiness Review is conducted, it verifies that formal testing is complete and that the system is ready to be tested by selected users, including employee union representatives.  The Office of System Product Assurance will forward the results of Formal Qualification Testing to the Technical Review Board for review at the Beta Readiness Review.  This review will be conducted in accordance with the project's Quality Assurance Plan and test plans.  The AIS will not be installed in production work areas or operational facilities, or connected to production systems without the concurrence of the Project Manager.

5.3.9         Beta Testing

During Beta Testing selected users test routine features of the AIS to verify that the AIS performs as expected.  Beta testing exercises the entire system as it is commonly used, rather than testing it extensively against formal statements of requirements.  In preparation, the Beta testers will receive training on the AIS using the training material delivered with the AIS.  The Project Manager selects test participants and establishes the schedule for Beta Testing.

5.4         Project Risk Management

_____________________________________________________________

The Project Manager will continue to evaluate risks to AIS project requirements, cost, and schedule.  The most common risks encountered during the Development Phase relate to events that may prevent full development or implementation of AIS project requirements.  Security requirements and controls, if not previously addressed, will impose significant project risk during the Development Phase.  This is due to the potential cost and complexity necessary to retrofit these requirements and designs into the AIS late in the life cycle.  Significant risks will also result if review and approval of designs and supporting plans, development tools, development skills, appropriate unit and integration testing, or specification, installation and testing of security controls are inadequate.  AIS project managers must also evaluate the risks associated with recent changes and upgrades to the hardware configuration, operating system and system utilities, software development tools, and AIS COTS components.  The Project Manager will advise the Program Sponsor and the CIO on matters of significant risk.  The Project Manager will also coordinate risk management activities with key managers and analysts based upon their ability to control risk. The Project Management TSG, IT-212.2-01, provides additional guidance on managing risk.

5.4.1         Project Risk Assessment

The Project Manager and the System Development Manager will continue to analyze the existing project situation to identify, analyze, and mitigate significant AIS project risks.  These managers will focus on ensuring the full implementation of AIS project requirements.  AIS project management will also focus on providing appropriate review and approval of designs and supporting plans, and completing appropriate unit and integration testing that includes testing of security requirements. The Project Manager must also provide appropriate review and approval for changes in hardware, software, development tools, and COTS components.  The Project Manager and the System Development Manager will ensure the complete documentation of information and activities that  identify, estimate, and evaluate significant risks.

5.4.2         Project Risk Review and Mitigation

Risk assessment findings will be presented to the Program Sponsor, Technical Review Board, or the CIO, as necessary.  These presentations will reaffirm the significance of risks and will solicit management support for addressing significant risks.  Based upon the recommendations of the Project Manager, the Program Sponsor or the CIO may assign additional staff or allocate additional resources to control significant risks.

5.5         AIS and COTS Security

_____________________________________________________________

Security activities for an AIS may include:

a.       developing AIS security aspects,

b.      monitoring the development process itself for security problems,

c.       responding to requirements changes from a security perspective,

d.      monitoring security risks.

Security risks that may arise during the Development Phase include risks associated with code intentionally designed to defeat security measures and disguised as useful code, incorrect code, poorly functioning development tools, manipulation of code, and malicious insiders.

Security activities for COTS software may include monitoring to ensure that security is part of market surveys, contract solicitation documents, and evaluation of proposed systems.  Many systems use a combination of “in-house” development and COTS acquisition.  In this case all the security activities discussed above are applicable.

As the AIS is built, choices are made about the system, which can impact security including: selection of specific COTS products, AIS architecture, and, AIS site or hardware selection.  In addition, security activities such as contingency planning, security awareness training, and security documentation must be conducted.  The Operational Support TSG, IT-212.5-01 provides additional information regarding the operational aspects of AIS security.  Security, like all requirements, must be anticipated from the beginning of the Initiation Phase.

5.6         Business Transition Planning

_____________________________________________________________

Transition activities should be tested during the Development Phase to ensure that all personnel, business process, and organizational changes can be implemented with minimum disruption to ongoing production.

Business Transition Planning, which began during the Detailed Analysis and Design Phase, continues through the Development Phase following the guidance contained in the Business Transition Planning TSG, IT-212.3-05. All significant changes to the business process made during the Development Phase must be reviewed by the System Development Manager, and reviewed and approved by the Project Manager.  The Program Sponsor and Project Manager should coordinate significant business process changes with the employee union representatives.

5.6.1         Transition Activities

Transition activities should be reviewed and evaluated during the Development Phase to ensure that all personnel, business process, and organizational changes can be implemented with minimum disruption to ongoing production.  Where feasible, interviews and surveys should be conducted to identify issues and determine the level of acceptance to changes in policies, procedures, and job descriptions.  Additional changes in the Business Transition Plan may be necessary based upon feedback collected though this process.  Moreover, specific presentations and specialized training sessions may be needed to further emphasize the intended goals and benefits of the process improvement activity, including AIS support.  All transition and change management activities will be documented and tracked in the Project Management Plan according to IT-212.02-01.  The Project Manager may brief the Technical Review Board on the expected impact the deployed AIS will have on their organization at Test Readiness Review.

5.6.2         Preparing the Organization for Change

End user involvement in the specification, design, development, and testing of transition activities is absolutely essential to promote broad-based process ownership and acceptance.  During the Development Phase, end users and the employee union representatives should be heavily involved in transition activities which require pilot testing (e.g., workflow redesign, team-oriented examination) and should play a major role in reporting the results of pilot tests.  Moreover, end users should be involved in updating the desired business process and in planning AIS deployment throughout the organization.  Where feasible, end users should take the lead in validating revised policies and procedures, new forms and formats, job aids, and performance measures.

5.7         Production Readiness Review

_____________________________________________________________

At the Production Readiness Review, the TRB will confirm that the AIS is complete, correct, fully tested, and ready for the Deployment Phase to begin.

The products of the Development Phase, and updates to existing plans and specifications must be reviewed by the Technical Review Board.  The Production Readiness Review will confirm that the AIS is complete, correct, fully tested, and ready for the Deployment Phase to begin. This review establishes the product and operational baselines and confirms that appropriate operational and maintenance support is available.  The Product Baseline consists of the documentation describing all the necessary functional and physical characteristics of the elements that compose the system and the actual equipment and software.  The Technical Review Board will confirm that the installation of the AIS into the production environment will have no adverse impact on other AISs or the PTO information technology infrastructure.

Deficiencies identified in unit, integration, Formal Qualification, and Beta Testing must be resolved, and changes generated by the review must be incorporated into the appropriate work products as directed by the Technical Review Board.  Based upon a finding that the AIS is suitable for production use, the Technical Review Board will recommend to the Program Sponsor and CIO to the deploy the AIS in accordance with the Production Installation Plan.

---

[1]  Formal Qualification Testing (FQT) exercises the entire AIS to independently confirm and extend integration testing results in an environment that more closely duplicates the production environment.  OSPA will test all AIS requirements that can reasonably be tested.  These requirements are identified in the current AIS requirements traceability matrix.  See 5.4.6 below.

[2] Beta testing may be tailored in or out of the life cycle.  End users  perform Beta Testing in an ad hoc manner to confirm that the system will provide the expected  functionality before placing the system into full service.  This testing will simulate the production environment as closely as is reasonably possible.  See 5.4.7 and 5.4.8 below.