Table of Contents | Chapter 12 | Appendix A

CHAPTER 13

ALTERNATIVE SDLC WORK PATTERNS

13.0       OBJECTIVE

13.1      STANDARD SDLC METHODOLOGY (FULL SEQUENTIAL WORK PATTERN)

13.2       ALTERNATIVE WORK PATTERNS
            13.2.1 Alternative Work Pattern Selection

13.3      WORK PATTERN DESCRIPTIONS AND EXHIBITS
            13.3.1 Reduced Effort (Small Application Development) Work Pattern
            13.3.2 Rapid Application Development Work Pattern
            13.3.3 Pilot Development Work Pattern
            13.3.4 Managed Evolutionary Development Work Pattern
            13.3.5 O&M Small-Scale Enhancement Work Pattern
            13.3.6 O&M Project Work Pattern
            13.3.7 Procurement of Commercial-Off-the-Shelf (COTS) Product

13.0    OBJECTIVE

An important objective of an SDLC methodology is to provide flexibility that allows tailoring of the methodology to suit the characteristics of a particular system development effort. One methodology does not fit all sizes and types of system development efforts. For instance, it is not reasonable to expect a very small system development project to produce 35 deliverables and a different approach might be needed for a high-risk system development project that has very uncertain functional and technical requirements at the beginning of development. Therefore, the DOJ SDLC methodology provides for a full sequential SDLC work pattern and for alternative SDLC work patterns. It also provides a work pattern to accommodate the acquisition and implementation of a commercial-off-the-shelf (COTS) product.

13.1     STANDARD SDLC METHODOLOGY (FULL SEQUENTIAL WORK PATTERN)

The standard SDLC methodology, as represented in Chapters 3, Initiation Phase, through Chapter 12, Disposition Phase, is termed a “full sequential work pattern.” This full sequential work pattern creates the maximum number of deliverables (see Figure 1-3, Planning Documents in Chapter 1, Introduction).

During the Planning Phase, the Project Manager, in conjunction with the System Proponent, evaluates the documentation of the system concept, as contained in supporting documentation, and determines if the standard DOJ SDLC methodology should be used or if an alternative work pattern should be selected instead. The selection of work patterns is based on the selection criteria and the judgement of the involved management. In general, the full sequential work pattern is used if the development type is new or a large modification; if the system development size is large; if the associated mission is critical; if the system development risks are normal or high; and if complexity of the system development effort is normal or high.

In the full sequential work pattern, a project is divided into phases; the phases are conducted sequentially, and the initiation of each phase depends on a decision to continue that is made during a formal review near the end of the immediately preceding phase. This work pattern reflects a desire to follow a very conservative approach to project management.

A complete set of system development activities, tasks, and deliverables to be considered for inclusion in this full sequential work pattern is presented in Chapters 3 through 12.

13.2     ALTERNATIVE WORK PATTERNS

Alternative work patterns provide flexibility for the DOJ SDLC methodology. An alternative work pattern permits a project planner to tailor a project management plan to meet the specific needs of the project and still conform to SDLC standards. Alternative work patterns provide the opportunity for methods specialists to predefine the permitted tailoring, to ensure that a project planner’s customization does not overlook necessary activities or include unneeded ones. The alternative work patterns provided are as follows:

• Reduced effort work pattern
  
• Rapid application development (RAD) work pattern
  
• Pilot development work pattern
  
• Managed evolutionary development (MED) work pattern
  
• O&M small-effort enhancement work pattern
  
• O&M project work pattern
  
• Commercial-off-the-shelf (COTS) acquisition

The following are operational definitions for terms associated with these types of projects:

• Proof of Concept - A project that defines what will be proven and determines both the criteria and methods for the proof of concept. Once the proof of concept is demonstrated, a prototype project may be initiated.
  
• Prototype - An ensemble that is suitable for the evaluation of design, performance, and production potential and is not required to exhibit all the properties of the final system. Prototypes are installed in a laboratory setting and are not installed in the field, nor are they available for operational use. They are maintained only long enough to establish technical feasibility.
  
• Proof of Technical Feasibility - The result of a successful prototype.
  
• Pilot - A system installed in the field to demonstrate that the systems concept is feasible in an operational environment. The pilot system installed has a predetermined subset of functions and is used by a bounded subset of the user population. Its features may not all function smoothly. The goal of the pilot is to provide feedback that will be used to refine the final version of the product. The pilot will be fielded for a preset, limited period of time only to permit pilot systems to be evaluated for operational feasibility.
  
• Proof of Operational Feasibility - The result of a successful pilot.
  
• Production - A fully documented system, built according to the SDLC, fully tested, with full functionality, accompanied by training and training materials, and with no restrictions on its distribution or duration of use.

13.2.1  Alternative Work Pattern Selection

During the Planning Phase, the Project Manager, along with the System Proponent, evaluates the system concept definition documentation and uses the criteria for selecting either the full sequential work pattern or an alternative work pattern.

This section shows the criteria for selecting an alternative work pattern. (Note: Criteria for selection may not be mutually exclusive - for example, complexity and size because size may be a factor of complexity.)

• Determine the type of system development:

  - New development

  - Modification or enhancement of existing system

  - Prototype system

  - Procurement of a COTS system

  - O&M small scale enhancement

  - O&M project

• Determine the cost of the system development project using the guidelines below:

- Class 1 - Very large projects with estimated development or life cycle costs of more than $20 million

- Class 2 - Large projects with estimated development or life cycle costs of between $10 million and $20 million

- Class 3 - Mid-size projects with estimated development or life cycle costs of between $2.5 million and $10 million

- Class 4 - Small projects with estimated development or life cycle costs of between $500,000 and $2.5 million

- Class 5 - O&M enhancement with estimated life cycle costs of less than $500,000.

• Determine mission-criticality of system development:

  - Most critical (C1) to non-mission critical (C5)

• Determine the risk of inability to achieve the project objectives from highest (D1) to lowest (D4), based on one or more of the following:

- Risk due to high uncertainty associated with the system’s requirements, the technology that the system will employ, or the way that the system will affect the DOJs’ business process

- Risk due to high visibility due to public or political attention or requirements

- Risk due to highly compressed development time (low turnaround time) because of an emergency or legal, business or political requirements

• Determine the complexity of the system development effort from highest (E1) to lowest (E3), based on one or more of the following:

  - The project affects many organizations or functional areas within DOJ, thus adding a level of difficulty regarding the definition of requirements.

  - The project results from business process reengineering, dramatically altering the use of information technology.

  - The project requires new or rapidly advancing technology.

  - The project requires a long time for development.

Use Exhibit 13-1, Alternative Work Pattern Selection, to select the work pattern appropriate for your project.

Exhibit 13-1: Alternative Work Pattern Selection

13.3     Work Pattern Descriptions and Exhibits

The subsequent sections provide descriptions for each alternative work pattern, including tasks and activities, required deliverables, and reviews for each relevant phase.

Deliverables for alternative work patterns are often created, revised, and finalized across multiple life cycle phases, as with the full sequential work pattern.

13.3.1  Reduced Effort (Small Application Development) Work Pattern

A Reduced Effort work pattern combines some phases, eliminates some of the deliverables otherwise required, and combines some of the reviews to reduce project formality in those situations where a conservative approach is not necessary. This is illustrated in Exhibit 13-2, Reduced Effort Work Pattern. Exhibit 13-3, Reduced Effort Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and the types of reviews required. Chapters 3 through 12 provide identification of the tasks cited in the exhibit.

Exhibit 13-2: Reduced Effort Work Pattern

Exhibit 13-3: Reduced Effort Work Pattern Summary

13.3.2  Rapid Application Development Work Pattern

In the RAD work pattern, the Initiation, System Concept Development and Planning Phases are conducted according to the full sequential work pattern. The Requirements Analysis and Design Phases are iteratively conducted, using prototyping tools to rough out and incrementally improve the understanding of requirements through a series of design prototypes. The functional requirements document and the system design document are started at the beginning of this activity but are not completed until the end of the Design Phase; these documents use, as much as is possible, the outputs of the prototyping tool to create this documentation. In the process, an initial set of requirements is used to create an initial version of the application, giving users visibility into the look, feel, and navigation capabilities of the application. User evaluation and feedback provide revisions to the statements of requirements, and the process is repeated – always involving the user. Typically, three cycle iterations will result in a completely understood set of requirements, but the iteration process can continue until successive differences in requirements are so small as to not be noticeable.

Following the completion of design prototyping, a full sequential work pattern is again engaged to accomplish the Development, Integration and Test, and Implementation Phases. The only deviation is the possibility of using some of the generated code from the design prototype to start the Development Process. This is illustrated in Exhibit 13-4, RAD Work Pattern. Exhibit 13-5, RAD Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and the types of reviews required.

Exhibit 13-4: RAD Work Pattern

Exhibit 13-5: RAD Work Pattern Summary

13.3.3  Pilot Development Work Pattern

In a pilot development work pattern, either a full sequential work pattern or a RAD work pattern is used to go from Initiation through the Development Phase. Decisions regarding full deployment of the application are held until after field trials and evaluations have proven the concept because of the risk involved in the complexity, visibility, and uncertainty of the project. The field trials and evaluations accomplish portions of user acceptance testing and implementation; after they are complete, possibly requiring 1 or more years, the remainder of implementation is completed. This means that migration to the Operations and Maintenance Phase is possibly deferred for more than a year. This is illustrated in Exhibit 13-6, Pilot Development Work Pattern. Exhibit 13-7, Pilot Development Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and the types of reviews required.

Exhibit 13-6: Pilot Development Work Pattern

Exhibit 13-7: Pilot Development Work Pattern Summary

13.3.4  Managed Evolutionary Development Work Pattern

The MED approach is particularly suited to situations where existing business processes will be altered considerably and where the full set of detailed functional requirements cannot be reliably defined early in the development life cycle. The MED discipline supports iterative definition, development, and deployment of subsystems by defining system-level functional and data requirements and a modular system architecture, which allows for subsequent refinement, development, and deployment of subsystems that can evolve to meet future business needs. Frequently, a particular release level containing partial, but not complete, functionality is referred to as a “build”. During the Planning and Requirements Analysis Phases, an entire series of successive builds is planned, each of which gets designed, developed, tested, and implemented.

This is illustrated in Exhibit 13-8, MED Work Pattern. Exhibit 13-9, MED Work Pattern Summary, shows, by phase, the tasks, the deliverables required, and the types of reviews required.

Exhibit 13-8: MED Work Pattern

• MED Incremental and Evolutionary Strategies. The MED-based development process combines an evolutionary development strategy with incremental delivery. System development using MED proceeds by defining a bounded vision of a future system and then iteratively refining the reengineered business processes, information system requirements, and technical architecture. The incremental delivery strategy within MED is used to encapsulate part of the overall system as a subsystem to be built and deployed. Subsystems are constructed when there is sufficient confidence that they will provide a cohesive, user-validated set of business functionality. As usage experience is obtained, lessons learned are fed back into each subsystem by improving each in subsequent versions of the system.
  
• MED Program Management. The Planning Phase is where the Project Manager, with approval of the System Proponent, determines that the functional requirements will best be fulfilled by assigning them to distinct, but functionally related subsystems. The Requirements Analysis Phase will be split into a Systems Requirements Analysis Phase to define overall system requirements and architecture and a Subsystem Requirements Analysis Phase for detailed definition of each subsystem. At the completion of the Requirements Analysis Phase, each subsystem begins its own branch of the life cycle to define a target subsystem architecture, business process, and requirements.
  
• Risk Management within the Context of MED. The order in which a MED-based work pattern proceeds is heavily influenced by risk. MED is designed to focus explicitly on the development decisions around risk that is derived from uncertainty about the target system in the areas of business process, system requirements, technical architecture, cost, and schedule. This risk management strategy addresses two fundamental time-related risks of uncertainty and dependence. Uncertainty is reduced by acting on gathered information, such as from prototypes, simulations, studies, or models; dependence is eliminated by structuring parts of the system to be independently deployed as subsystems. To accomplish this, the Project Manager must define the target system. This consists of determining the system boundaries, specifying the target characteristics, assessing system risks and defining and executing risk mitigation activities; and developing subsystems, which is done as a project within the overall program. Projects are initiated once system-level risk is reduced to an acceptable level as documented in the risk management plan.
  
• Reviews and Approvals. When using the MED Work Pattern, there is an explicit milestone for the system-level requirements and a milestone for each subsystem requirement.

Exhibit 13-9: MED Work Pattern Summary

• Acknowledgment for the MED Methodology. The U.S. Patent and Trademark Office developed and documented the MED methodology. A full description of MED may be found in:

  Managed Evolutionary Development Guidebook, Second Edition, June 1993. This is a document produced by the U.S. Patent and Trademark Office. For further information contact: The Office of the Assistant Commissioner for Information Systems, U.S. Patent and Trademark Office, 2121 Crystal Drive, Arlington, VA 22202, (Fax) 703-305-9369.

13.3.5  O&M Small-Scale Enhancement Work Pattern

This work pattern is appropriate for small scale revisions to existing applications. Each O&M enhancement must be initiated by the Project Manager and must be tracked by an SCR. Typically, multiple O&M enhancements will be bundled into a planned software release identified by a version number.

The intent is to limit the use of this work pattern to simple, small-scale changes that will require no more than 160 labor hours for Initiation, Concept Development, Requirements Analysis, Design, Development, Integration & Testing, and Implementation, including any needed updates to product documentation and any required user training.

Exhibit 13-10, O&M Enhancement Work Pattern Summary shows, by phase, the tasks, deliverables, and types of reviews required.

Exhibit 13-10: O&M Enhancement Work Pattern Summary

13.3.6  O&M Project Work Pattern

This work pattern is appropriate for O&M Maintenance for existing applications. Each O&M project must be specifically organized and staffed for the purpose of conducting corrective, adaptive, or perfective maintenance on installed applications, including conversions needed to support upgrades and/or changes to the hardware and software operating environment. User help desk support and other small O&M enhancements may also be provided and delivered by the assigned project team. System revisions and conversions will be accomplished on an as-needed basis at a fixed level of support and within a corresponding fixed annual operating budget. The intent is to limit the use of this work pattern to ongoing support activities that typically do not fit within the definition of a systems development or enhancement project.

Exhibit 13-11, O&M Project Work Pattern Summary, shows, by activity, the task, deliverables, and types of reviews required.

Exhibit 13-11: O&M Project Work Pattern Summary

13.3.7  Procurement of Commercial-Off-the-Shelf (COTS) Product

This effort is designed for the purchase of COTS products to be used by DOJ within the framework of existing or planning systems, see Exhibit 13-12. These COTS products may be used at a single site or they may be installed to operate across the DOJ or a significant portion of the DOJ. The table in Exhibit 13-1: Alternative Work Pattern Selection, indicates when this pattern is to be used.

Exhibit 13-12: COTS Acquisition Work Pattern Summary

NOTE: May not be required, depending on the nature of the COTS product. This document will be more likely required for systems made up entirely of COTS products that require significant customization and integration. The decision to develop this document should be made during this life cycle phase.

Additional Work Patterns

Project teams should endeavor to follow the full sequential work pattern or one of the alternatives described above. However, from time to time, new project environments or system requirements into which these work patterns will not fit will evolve. In those cases, the Project Manager, working with the QA Manager, shall develop and document proposed new work patterns, submit them as updates to this guidance document, and use them as the basis of the project management plans.

Table of Contents | Chapter 12 | Appendix A