Operational Concept Description (OCD)
A. Description of the OCD
Sections A1-A3 of this Operational Concept Description (OCD) section of the Instructional ICM-Sw Guidelines are intended to be read by CS577 students to help them understand what the OCD is and how to write their projects’ OCDs. They are not intended to be included in submitted OCDs.
1. Purpose of the OCD
The purpose of a development project’s OCD is to describe the success-critical stakeholders’ (also known as “key stakeholders”) shared vision of the project being undertaken. Key stakeholders typically include the system’s users, the clients, the customers (if different from the clients), and the developers. Depending on the nature of the project, others may also be considered as key stakeholders, including investors, administrators, operators, maintainers, component suppliers (e.g., suppliers of DBMSs, middleware, and other COTS products), and providers of other systems with which the current system communicates or interoperates. In the case of a safety-critical system such as air traffic control, members of the general public are also key stakeholders.
The OCD describes how the new, or modified/enhanced, software system that is the subject of the project, or simply referred to as “the system,” will operate within its environment. Where necessary, it includes prototypes to help flesh out details of the operational concept in such a way that it will meet the win conditions of all key stakeholders. (Note that for CS577 projects, screen prototypes are necessary.)
The OCD is written by developers with the collaboration of representatives of each category of key stakeholder. Unlike most of the other Instructional ICM-Sw documents, which include software-related technical detail that will not be understood by non-developer stakeholders, the OCD must be written in language understandable by all categories of stakeholder. If a particular project’s OCD has to contain terminology specific to any category of stakeholder, that terminology must be defined explicitly. This includes technical/business terminology from the client’s/customer’s field/domain, which may not be familiar to software developers. The definitions of these terminologies are to be included in the Support Information Document (SID).
Stakeholders use the OCD in various ways:
· Key executive stakeholders – to verify that the operational concept is of benefit to their organization
· Key operational stakeholders – to understand, at a high level, how their activities will be affected by the new system
· Development-side stakeholders – for the purpose of understanding, at a high level, what they are to develop and, in some cases, the constraints under which they must perform their development activities
2. OCD Life Cycle Process
As the project begins, you should start to develop the goals and visions shared among the key stakeholders as well as rough-usage scenarios of the system being developed. This will allow you to draft up Section 2 (Shared Vision) of the OCD and provide the context for the concurrent prototyping and WinWin negotiation activities. The results of these latter two activities will be used as a baseline to develop the project artifacts for the Foundations Commitment Package (FC Package) and the Development Commitment Package (DC Package). These artifacts include later versions of the OCD, the System and Software Requirements Definition (SSRD), the System and Software Architecture Description (SSAD), the Life Cycle Plan (LCP), the Feasibility Evidence Description (FED), and the Quality Management Plan (QMP). During this process, the prototypes should be continuously extended and refined; however, the WinWin negotiation results, in general, do not change. Both the FC Package and DC Package versions of the OCD are submitted to the CS577 Archive.
During CS577b, the OCD is updated as appropriate, but only change summaries are presented in section 1.2 for the Rebaselined Development Commitment Package (RDC Package) and Operation Commitment Package (OC Package). The final version of the OCD is delivered along with the client’s Initial Operational Capability (IOC) document and submitted to the CS577 Archive.
3. Completion Criteria
The following is the amount of information to be included at each phase and the levels of detail required for each phase.
3.1 Exploration Phase
Before starting your WinWin negotiations and developing your detailed prototypes, work with your client to develop goals, visions, and usage scenarios to draft up Section 2 of the FC Package OCD. If possible, get representatives from all categories of success-critical stakeholders — not just the client — to participate in the WinWin negotiations and prototype demonstrations. The participation of end users is often very important and critical to the success of the project. The importance of participation by other types of critical stakeholder, varies from project to project, from either very important to optional. Since you may not be able to identify all the categories of critical stakeholders by yourself, involve the client, as well as other already-identified stakeholders, in this process.
The OCD developed during the Exploration phase is part of the Valuation Commitment Package (VC Package) and acts as a baseline for other project artifacts in later phases.
3.2 Valuation Phase
During the Valuation phase, the following items must be described:
· Shared vision and contexts for success-critical stakeholders
· System transformation strategies: nominal, critical, and off-nominal scenarios as coordinated with the operational stakeholders
· Draft operational concept for IOC
· High level operational and organizational transformations
· A link to the WikiWinWin results
· Initial prototypes for functions that are high priority, high risk, and/or critical
At the end of the Valuation phase, the OCD should be ready for the Foundations Commitment Review (FCR).
3.3 Foundations Phase
During the Foundations phase, the following items must be described:
· Operational concept for IOC
· System transformation strategies as coordinated with operational stakeholders including nominal, critical, and off-nominal scenarios.
· All operational and organizational transformations
· Additional prototypes and further elaboration of existing prototypes
At the end of the Foundations phase, the OCD should be ready for the Development Commitment Review (DCR).
3.4 Development Phase
During the Development phase, the following item must be described:
· Change summary and changes from DC Package version
Additionally, the OCD must be consistent with the OC Package versions of other artifacts (OC SSRD, OC SSAD, OC LCP, OC FED, and OC SID).
B. Sections of the OCD Document
The sections listed below describe the base format for the OCD. For readability by faculty, TAs, graders, and CS577b students, every submitted OCD document (FC OCD, DC OCD, and IOC OCD) should contain each of the indicated sections with these titles and section numbers. (See the General Guidelines for exceptions.) The text under each heading and subheading describe what should be in each section. The texts are to be read by CS577 students to help them prepare the sections and are not intended to be included in submitted OCD.
1. OCD Overview
1.1 Purpose of the OCD
Introduce the project/system by identifying the following:
· The system by name or function
· The team developing the new system
· The client, the organization s/he represents, and the customer (if different from the client)
Each CS577 artifact should be written/edited by at least two team members, and have version control. Any document written/edited by more than one person should be under some type of version control, either formal or informal.
1.2 Status of the OCD
Provide information on the current status of the OCD. This information includes the following:
· The number of this version of the OCD
· The project milestone or anchor point (FCR, DCR, or IOC) for which this document is being prepared.
· List of significant changes from the previous milestone, including major updates and changes to the operational concepts
2. Shared Vision
This section provides the visions and goals that are shared among all the success-critical stakeholders. It should be descriptive in capturing the high-level view of the system being developed as well as the expected outcome and benefits. This includes goals that, when achieved, will make winners out of all the stakeholders.
2.1 Success-Critical Stakeholders
List each category of success-critical stakeholder for your project by authorized representative for project activities, organization, and their relationships to the Benefits Chain. The four classic categories are the software system’s users, customers/clients, developers, and maintainers. Be sure to identify additional stakeholders critical to your system’s success. These could include data and infrastructure providers, and proprietors of critical interfacing systems. Be sure to investigate the issues of where the system will be hosted, and by whom, when fleshing out this list. (See Section A.1 of these OCD Guidelines for a short discussion of success-critical stakeholders.)
Table 1: Example Stakeholders and Their Responsibilities
Stakeholders / Authorized Representative / Organization / Relations to Benefit ChainClients/Users / Alan Smith
Bob Jones / California Science Center / Beneficiary as the project advances
Maintainer / Catherine Kim / California Science Center / Responsible for updating and maintaining the system
Development Team / Don Lee
Ethan Howard
Frank Lin
Gerard Jackson / University of Southern California / Responsible for designing and developing the project application
IIV&V / Harry Abrash / University of Southern California / Part of the development team. Responsible for verifying and validating the documents and assuring the quality of the project.
2.2 System Capability Description
Provide an “elevator test” summary of the project’s expected benefits, i.e., a short executive summary that could convince a potential funder (venture capitalist) “during the course of a short elevator ride.” (See Geoffrey Moore’s Crossing the Chasm (Harper Collins, 1991, p.161)). Such an “elevator test” summary includes:
· The type of system to be built
· The target customer(s) for the system
· The need or opportunity that will be satisfied by the system
· A compelling reason for the customer to buy/use the system
· The closest competitor of the system
· The system’s primary differentiation from, or benefit over, the closest competitor or alternative approach, if there are competitors or alternatives ah the time
2.3 Expected Benefits
List in detail the benefits that the stakeholders can expect from the new system. These are the benefits that elevate the operational process at the organization. You should keep in mind that the benefits listed in this section should be kept to the level of detail that have values to all key stakeholders. These, generally, do not include detailed technical benefits.
The expected benefits developed in this section serve as a starting point for creating the benefits chain in the next section.
2.4 Benefits Chain
Specify any initiatives required to achieve the desired outcome(s), and the assumptions under which the successful pursuit of all the recognized initiatives will actually produce these beneficial outcomes in the form of a diagram known as the “Benefits Chain.” (The Benefits Chain is an extended version of the Results Chain in John Thorp’s The Information Paradox (McGraw Hill, 1998, p.98)).
The key stakeholders of a software development project engage in the project in order to achieve certain desired (beneficial) outcomes, with the expectation that successful completion of the development team’s “initiative” of designing and building the software will result in the achievement of these benefits. It is often not quite as obvious that:
· Achievement of the desired outcomes might depend upon the validity of certain unstated assumptions; frequently, such assumptions are unknown to one category of stakeholders, and so trivially obvious to another category of stakeholders that members of the second category do not even bother mentioning them. This can often lead to the detriment, or outright failure, of the project.
· Additional initiatives over and above the design and construction of the software may be required for the beneficial outcomes to be achieved. These initiatives do not necessarily involve the developers.
Therefore, it is critical to discuss this issue with representatives of all identified categories of key stakeholders and capture them in the benefits chain.
For example, a number of years ago a CS577 team worked on a system that would enable scholars all over the world to perform web-based searches for, and retrieval of, Chinese, Japanese, Korean, and Indian films from a USC archive of such films. The initiative of building a web-based (search and retrieval) system was certainly necessary to the achievement of this outcome, but, as it turned out, not sufficient; an additional initiative of; acquiring a donor to supply the significant funds required to digitize the large number of films in the archive was also necessary for the project to succeed.
The Benefits Chain is a notation for linking Initiatives (that consume resources) to Contributions (desired capabilities) and Outcomes (desired states) that may lead either to further contributions or to added value (benefits) as shown in Figure 1.
Figure 1: Notation for Benefits Chain Diagram
Initiative – The initiatives are high-level actions specifying what is needed to be done to accomplish the benefits and do not have to be detailed to the level of listing every single technical feature of the system. Each initiative should be singly listed in the diagram and should be in the level of detail that is valuable to all key stakeholders. Additionally, they should be written in verb form.
Contribution – The desired capability that lead to the desired outcome. An outcome can contribute for further benefits.
Assumptions – An important aspect of the Benefits Chain notation is Assumptions, which specifies the constraints and conditions for the realization of the Outcomes.
Stakeholders – Consists of both the development stage and operational stage stakeholders who are critical to the success of the initiatives and of the resulting outcome(s). It is critical that all the stakeholders are identified to determine the key actors of each initiative and key contributors to the resulting benefits.
Outcome – The resulting outcome.
Figure 2 and Figure 3 show the correct and incorrect examples of the Benefits Chain Diagram.