In both cases, the CONOPS is intended to facilitate a common understanding of ideas, challenges, and issues on possible solution strategies without addressing the technical solution or implementation; it is often a first step for developing system requirements.
As systems continue to evolve in complexity, SEs and mission owners can utilize a CONOPS to develop and sustain a common vision of the system for all stakeholders over the system's life cycle. The original CONOPS written at the beginning of system acquisition should be updated after developmental and operational testing, to convey how the system being acquired will actually be used.
This update is needed since many final systems include some additional capabilities not originally envisioned at program start, and may not include some capabilities that were omitted during trade-off analysis. Post-fielding life cycle costs often dwarf those of the development effort. Therefore, it is critical that the CONOPS provide sufficient information to determine long-term life cycle needs such as training, sustainment and support throughout capability fielding and use.
A CONOPS should define any critical, top-level, performance requirements or objectives stated either qualitatively or quantitatively including system rationale for these objectives. Multiple CONOPS guidelines, models, and methodologies are available that can be tailored as needed for particular environments or situations. Johns Hopkins University's Whiting School of Engineering provides an approach to making this decision based on SE analysis of criteria:.
This guide does not specify the exact techniques to be used in developing the CONOPS document, but it does provide approaches that might be used. Each organization that uses this guide should develop a set of practices and procedures to provide detailed guidance for preparing and updating CONOPS documents.
These detailed practices and procedures should take into account the environmental, organizational, and political factors that influence application of the guide [1]. They should also consider any guidelines that have been put in place by the organization. The main objective of a CONOPS is to "communicate with the end user of the system during the early specification stages to assure the operational needs are clearly understood and incorporated into the design decisions for later inclusion in the system and segment specifications [1].
It may also be the case that the operational user does not understand or cannot envision how new capabilities will operate in their environment, particularly if it is a new type of system or operation. In these cases, experiments and prototypes can be of value in illuminating these issues.
For a software-intensive capability, the CONOPS might have a greater emphasis on the information system perspective of the users' needs and developers' products concentrating on software feasibility and software requirements. A CONOPS should define any critical, top-level, performance requirements or objectives stated either qualitatively or quantitatively including system rationale for these objectives.
It is critical that the CONOPS provide enough information to help with future activities such as sustainment, training, fielding, support, and even disposal. A concept should communicate the needs to the acquisition and development communities clearly. In general, it will include the following:. You must be logged in to post a comment. Leave a Reply Cancel reply You must be logged in to post a comment.
0コメント