Request for Quotations (RFQ)
Call for Participation (CFP)
OGC Testbed 10
Annex C - Concept of Operations
RFQ Issuance Date: 15 July 2013
Proposal Due Date: 26 August 2013
Copyright © 2013 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/
This Annex describes the Concept of Operations for the OGC Testbed 10 Web Services Initiative which is organized in three threads. The schedule for this initiative is detailed in the Master Schedule (RFQ/CFP Main Body). The steps of the initiative are:
- Proposal Development - During this period, organizations are developing responses to the RFQ/CFP. OGC refines management and communication plans for the OGC Testbed 10 initiative operational phases and clarifies requirements.
- Proposal Evaluation, Selection and Negotiations: During this period, the OGC Testbed 10 IP Team will analyse responses for funded and unfunded work items for each of the activity threads within the WBS described in Annex-A of the OGC Testbed 10 RFQ. OGC will communicate with RFQ respondents concerning their proposals, negotiate on their participation for funded and in-kind contributions, and communicate the status of the OGC Testbed 10 to the OGC Technical and Planning Committees. During this timeframe, Participant Agreements for selected organisations and Statements of Work will be signed.
- Kickoff Workshop.: The Kickoff Workshop is a face-to-face meeting during which the selected organizations and participants will (a) develop generic interfaces and protocols to be used as a baseline for software components, (b) finalize the initial System Architecture, and (c) refine the Demonstration Concept.
- Interface Development, Test, and Refinement: During this period, selected organizations will develop interface components for insertion into testbed, and integrate selected components that support prototype testing and development for the OGC Testbed 10 Initiative.
- Preliminary Design and Deliverables: This is a necessary deadline for exchanging draft documents that are determined by the thread teams during the kick-off, such as design documents or preliminary service implementations needed for cross-thread purposes. This will not involve a face-to-face meeting but will be held using WebEx and Telecon.
- Demonstration Milestone: This is a preliminary deadline, also to be held by WebEx and Telecon, for submitting draft reports and screen captures of implemented services to date. These are typically organized and performed by each thread separately, rather than as a testbed-wide activity.
- Demonstration Event: At this event, outcomes and highlights of the OGC Testbed 10 initiatives will be demonstrated to OGC, sponsors, and the community of interest. This may consist of multiple demonstrations highlighting specific product capabilities.
- Final Delivery: This constitutes the close of funded activity, and all final reports and deliverables are due. Further development may take place to refine demonstrations for placement for public viewing on the OGC website, or for subsequent OGC meetings.
2 OWS–10 Lifecycle Phases
2.1 Proposal Development
2.1.1 Proposing Organization Activities
The following guidelines are provided to proposing organizations for proposal development:
- Proposing organizations must be members of OGC, or must submit an application for membership with their proposal, to have their proposals considered.
- The OGC Abstract Specification, as well as OGC Interface Specifications, may cover some of the technology areas under consideration in the RFQ. The relationship between the content of the proposal and the relevant OGC specifications should be noted by the Proposing organizations.
- Proposals with some basis in emerging related international Standards being developed by ISO, OASIS, IEEE, IETF, IAI or other standards development organizations should reference the relevant standard and sections thereof.
- Proposing organizations should plan on performing all development work at their own facilities, following the Kickoff. These facilities should include a server (where applicable) that is accessible to other testbed participants via the Internet. Technology Interoperability Experiments (TIEs) will be carried out among the participants based on these Internet-accessible servers.
- The immediate outcomes of the OGC Testbed 10 Initiative include Engineering Reports, which can become additional OGC specifications and Best Practices, as well as implementations that become part of the OGC Network infrastructure.
- Proposals need not address the full spectrum, or even a major portion, of the OGC Testbed 10 architecture and requirements as outlined in Annex B. Proposals can focus on specific portions of that architecture. One proposal can address parts or all of multiple threads. It is the task of the OGC Testbed 10 IP Team to ensure that all sponsor requirements are met, which may involve negotiating with individual bidding organizations to drop, add, or change some of their proposed developments. This negotiation will be completed in advance of the Kickoff.
- Proposing organizations should be prepared to build interoperable components and thus should be prepared to cooperate with all selected development teams, regardless of whether individual proposals covered the full OGC Testbed 10 architecture or portions of it.
- Software components developed in the OGC Testbed 10 initiative should either be based upon currently shipping products, or should be prototypes or pre-release versions of products that the responding organization intends to sell or otherwise distribute for ultimate deployment.
- Responding organizations must participate in the full course of interface and component development, test and integration experiments, and other essential activities throughout the initiative in order to have access to and participate in demonstration exercises.
- Proposal selection and funding may be on the basis of portions of the proposal deemed most likely to lead to a successful OGC Testbed 10 implementation.
- Proposal selection and funding for pure specification development will be much more limited than funding for the development of software components, and will be subject to a stringent review.
- Proposing organizations should feel free to provide alternatives to the initial OGC Testbed 10 architecture. However, it should be noted that proposals will be selected on the basis of how successfully the various components of all the selected responses interoperate. Radically different architectures that would require intensive rework on the part of a majority of the selected organizations participants would have to be supported by cost/benefit analysis. Advance coordination with affected participants to present a coherent, realistic, and reasonable approach will greatly improve chances of acceptance by the proposal review team.
- Proposing organisations shall use the supplied template and forms to complete their proposals.
Those organizations choosing to respond are expected to have representatives available to attend the following teleconferences:
- Questions Due and Q&A webinar
- Negotiations with selected organizations
Furthermore, selected organizations and participants offering in-kind Contributions shall plan to send at least one technical representative to the Kickoff Workshop.
Specific dates for the events listed above are provided in the OGC Testbed 10 Master Schedule.
2.1.2 Management Approach and Communications Plan
The OGC IP Team will apply its standard management approach, and initiate its communication plan during the period between the release of the RFQ and the submission of the responses. These activities will provide guidance to the OGC IP Team and participants for the conduct of OGC Testbed 10.
The management approach for OGC Testbed 10, as for other OGC IP initiatives, is outlined in the Interoperability Program Policies and Procedures documents available on the OGC Website. These documents provide details on the following roles and responsibilities of individuals providing management support to OGC initiatives:
- Sponsor Team—representatives from the organizations that have provided sponsorship for the OGC Testbed 10 initiative.
- OGC Initiative Manager—the OGC staff person responsible for the overall management of the OGC Testbed 10 initiative.
- Demonstration Manager —the individual responsible for planning and managing the Demonstration activity of the OGC Testbed 10 initiative – this role may be performed as part of other roles.
- Thread Architects—the individuals responsible for the overall initiative architecture during the course of the OWS initiative.
- Marketing—the individual responsible for the marketing aspects of the OGC Testbed 10 initiative.
- Interface Team—a team of individuals representing all of the participants that are engaged in component development and representing sponsor organizations. The primary task of this team is to develop component interface and protocol definitions, implement components, revise interface and protocol definitions, and evolve the Initiative Architecture.
- Demonstration Team—a team of individuals representing all of the participants and sponsoring organizations that are engaged in demonstration, testing, or data provision. The primary task of this team is to prepare scenarios for demonstrations, design tests that exercise the components, perform data development in support of these scenarios, build demonstrations and tests, and evolve the Demonstration Concept.
- OGC IP Team—a group composed of the OGC Initiative Manager, Thread Architects, Demonstration Manager, and Marketing.
The Communications Plan, included in this RFQ as Annex D, details resources and procedures for reporting and exchanging information with participants, relevant working groups (WGs), Technical Committee, Planning Committee, Strategic Member Advisory Committee, and sponsors. This plan includes the development of a Web page with appropriate documents and regular updates to OGC Testbed 10 information. The OGC IP Team will provide a list server for participants to exchange project-relevant e-mail. A teleconferencing plan will be developed to further support communications among participants.
2.2 Proposal Evaluation, Selection and Negotiations
The OGC IP Team and Sponsors will review the RFQ responses beginning immediately after the deadline for submission. During the analysis process the OGC IP Team may need to contact proposing organizations and participants for clarification and to understand the recommended Initiative Design and Demonstration Concept. The process leading up to the Kickoff Workshop is detailed in the following paragraphs.
2.2.1 Component and Requirement Analysis
The review team will accomplish the following tasks:
- Analyze the elements proposed in RFQ responses in the context of the sponsor priorities listed in Annex A.
- Compare the proposed efforts with the requirements of the initiative and determine viability.
- Assess the feasibility of the RFQ responses against the use cases.
- Analyze proposed specification refinement or development.
- Analyze proposed testing methodologies, including but not limited to performance testing methodologies.
2.2.2 Initiative (System) Architecture Recommendation
The proposal review team will then draft a straw system architecture, which will include the set of proposed components for development within the initiative, and relate them to the hardware and software available. Any candidate interface and protocol specifications received during the RFQ process will be included with the draft initiative architecture as annexes.
2.2.3 Demonstration Concept Recommendation
The proposal review team will incorporate the preliminary analysis of responses into a demonstration concept recommendation. This document will discuss the ability of proposed software components to work together in a demonstration context, and will identify gaps.
The demonstration concept document will include references to existing and emerging resources on OGC Network, including the resources under development in this testbed. The OGC Testbed 10 initiative will culminate in one or more sponsor demonstrations. The demonstration(s) could be a combination of virtual and physical events, depending on OGC Testbed 10 sponsor constraints and preferences.
2.2.4 Decision Technical Evaluation Meeting (TEM) I
At Decision Technical Evaluation Meeting I, OGC IP Team will present to the sponsors:
- The Initiative (System) Architecture Recommendation, and
- The Demonstration Concept Recommendation.
This presentation will be made in the context of first drafts of the plans described above:
- Communications Plan
- Sponsor requirements
The primary decisions to be made by the sponsors at this TEM are:
- Is the recommended Initiative Architecture workable? If not, how to make it workable.
- Which RFQ responses, or subset thereof, should be provided cost-sharing funds and at what level given all inputs?
- Is the Demonstration Concept workable? If not, how to make it workable.
- Are the management approach and the Communications Plan reasonable and complete?
Immediately following Decision TEM I, the OGC Testbed 10 IP Team will begin to contact proposing organizations based upon sponsor recommendations. The team will revise plans and concepts accordingly and make budgetary adjustments based on sponsor inputs.
2.2.5 Decision TEM II
At Decision Technical Evaluation Meeting II, the OGC IP Team will present to the sponsors:
- The Initiative (System) Architecture Revision, and
- The Demonstration Concept Revision.
- The Participants Recommendations.
The primary decisions to be made by the sponsors at this TEM are:
- Is the revised Initiative Architecture workable? If not, how to make it workable.
- Are the Participants Recommendations correct and affordable?
- Is the Demonstration Concept workable? If not, how to make it workable.
- Are the management approach and Communications Plans reasonable and complete?
Immediately following Decision TEM II, the OGC IP Team will 1) finalize the Initiative Architecture and Concept of Operation (now including the Demonstration Concept), 2) begin to insert specific information into the SOW template for each targeted participant organization, and 3) make the insertions of specifics for all participants into a Participant Agreement template. Each targeted respondent POC should be available or make arrangements for alternates during this period. The output of Decision TEM II will be a final Initiative Architecture and Demonstration Concept.
2.3 Kickoff Workshop
OGC Testbed 10 will be launched officially with a kickoff workshop (refer to the Master schedule Section 2 of the RFA/CFP Main Body for more information on dates and locations). In OGC Testbed 10, the Aviation Thread will be kicking off separately from the CCI and Open Mobility Threads. Selected organizations are only required to attend the kickoff workshop for the threads they were selected for.
Prior to the Kickoff Workshop, all the participants must commit to a preliminary Statement of Work, with the understanding this may change somewhat during the Kickoff, as the participants, architects and sponsors gain better understanding of the project scope, architecture needed, and implementation issues. Immediately after completion of the Kickoff, all participants must sign a Contract, as indicated above, that includes a description of the assigned work items in Annex A of the OGC Testbed 10 RFQ, subject to any mutually agreed changes decided during the Kickoff.
The Kickoff Workshop will address two inter-dependent and iterative development activities in the OWS process: (1) component interface and protocol definitions, and (2) demonstration scenario development. The scenarios used in OGC Testbed 10 will be derived from those presented in the RFQ and other candidates provided by OGC and the sponsors.
The Kickoff Workshop(s) consist of
- Technical breakouts to begin developing component interface definitions for the testbed. The responding organizations and companies are expected to have systems and/or software engineers in attendance to assist in the initial assessment and interaction of the interfaces. This may include UML modeling of the interfaces. Use cases will be made available to the demonstration development team, and the interface definition team should incorporate in their own analysis use cases provided by the demonstration development team.
- Technical breakouts to begin demonstration scenario design and creation. This activity will involve the development of use cases to explore the implications of the scenarios to OGC Testbed 10. These use cases should be made available to the interface development team, and demonstration developers should incorporate in their own analysis the use cases provided by the interface development team. The participants in this activity should understand that various data sources will be proposed as solutions to the RFQ. This group will apply the use cases to the development of storyboards based on the proposed data sources. The scenario design must account for the requirements and dependencies of the overall OGC Testbed 10 system, including any Client/tool designs, any Server designs, and service interfaces.
- Technical plenary sessions to enable the participants working on interface and protocol definitions to interact with those participants working on scenario vignettes and demonstration development.
An additional product of the Kickoff Workshop will be a development schedule that defines specific milestones in the Interface Development and Demonstration Development activities. Among the milestones will be Technology Integration Experiments.
2.4 OGC Testbed 10 Interface and Demonstration Development
This section defines an initial concept for the conduct of development activities in OGC Testbed 10 RFQ. Figure 2 lays out a notional schedule for the OGC Testbed 10 Initiative. The actual schedule and further information will be provided at the Kickoff Workshop.
Figure 2 – Notional Schedule for OGC Testbed 10
2.4.1 Specification and Interface Development
This Phase corresponds with WBS Tasks 10, 11 and 12 and their related sub-tasks. The schedule and further information will be provided at the Kickoff Workshop.
To the extent possible in an initiative of this duration, interface definition, software development, and test will follow the spiral development paradigm. In particular, issues exposed in each round of TIEs will drive requirements for the following round of specification (interface definition) refinement, coding, and test. The development cycle may also proceed incrementally, with primary attention on a limited set of operations at each turn of the cycle.
The Technical Architecture in Annex B describes an initial set of services and interface mechanisms. It also contains a notional System Architecture. Individual items in that notional System Architecture are to be refined during the Kickoff Workshop and will be further refined during this phase. Consistent with the spiral development paradigm, it is intended that there be periods of development followed by periods of synchronization between the various component developers. This will allow for issues to be resolved and documented before divergence begins to occur between individual component developers (i.e., two server developers) and between dependent component developers (i.e., server and client developers).
This phase builds upon the initiative characteristics developed during the Kickoff demonstration scenario design and creation discussions. To be successful, participants must execute four activities—designing a demonstration, building a demonstration, testing the demonstration, and packaging the demonstration for public sharing.
This phase capitalizes on the work performed at the Kickoff, and expands it to include finalizing demonstration storyboards, finalizing specification considerations, identifying data providers, and incorporating additional relevant data sources.
The goal is for participants to build and implement prototypes that clearly demonstrate the capabilities of the components by exercising the sponsors' scenarios. As a core requirement of the testbed effort, the sponsors have requested that all demonstrations be made available via the Internet, either for presentation purposes, or for use in their internal labs (See WBS task items 13, 14, and 15.2 and their related sub-tasks).
Participation in demonstration exercises is predicated upon full engagement with development, testing, and planning activities throughout the OGC Testbed 10 initiative. OGC Network Integration and Solution Transfer.
The OGC Network Integration will be complete when the interfaces and demonstrations developed during the Interface Development and Demonstration Development have been integrated into the OGC Network initiative infrastructure. This activity will result in configuration-controlled components that are considered stable enough to use in ongoing demonstrations, pilots, and further test bed activity.
Solution Transfer entails the installation of software components developed during the testbed at a Sponsor facility. This task will be complete when sufficient documentation or instruction has been provided, and adequate licensing procedures completed, to allow the Sponsor organizations to exercise and evaluate these products or product prototypes. Solution Transfer is not required for all components.
3 Progress Reporting
The OGC IP Team will provide monthly progress reports to the sponsors pertaining to the current status of the OGC Testbed 10 initiative. The OGC IP Team and the sponsors intend to provide regular status reports about the program to the OGC Technical Committee, Planning Committee, and the OGC Strategic Member Advisory Committee. Participant presentations to the TC will include presentations on Engineering Reports and Demonstration scenarios.
4 Integrated Initiatives
Other ongoing IP activities may present opportunities to support OGC Testbed 10 and be coordinated with the activities within OGC Testbed 10. Any such resources and related activities may be integrated with those of OGC Testbed 10 in order to take advantage of economies of scale, and possibly to explore the deployment of innovations coming from OGC Testbed 10.