Академический Документы
Профессиональный Документы
Культура Документы
Resumen.
Introducción.
-1-
El Concepto de Operaciones. Fairley
El documento ConOps describe los resultados del proceso de análisis conceptual. El documento
debería contener toda la información necesaria para describir las necesidades del usuario, objetivos,
-2-
El Concepto de Operaciones. Fairley
-3-
El Concepto de Operaciones. Fairley
El documento ConOps puede satisfacer uno de varios roles, o bien una combinación de los mismos:
1. Para comunicar los requerimientos/necesidades de usuarios y compradores a los desarrolladores
del sistema. El autor del ConOps podría ser un comprador, presentando las visiones del usuario a
un desarrollador; o un usuario presentando la visión del usuario a un comprador y/o un vendedor.
En este caso, el ConOps es usado por el desarrollador como la base de las futuras actividades de
desarrollo.
2. Para comunicar la comprensión del desarrollador a usuarios y/o compradores. El desarrollador
podría producir un documento ConOps como una ayuda en la comunicación de los
requerimientos técnicos a usuarios y compradores, o para explicar una estrategia de solución
posible a los mismos. En este caso, el ConOps es revisado por los usuarios y compradores para
determinar si la propuesta se corresponde con sus necesidades y expectativas.
3. Para comunicar la comprensión del comprador de las necesidades del usuario a un desarrollador.
En este caso el comprador debería desarrollar el ConOps, obtener el acuerdo del usuario, y usar
el ConOps para presentar las necesidades del usuario y requerimientos operativos al
desarrollador.
4. Para documentar las necesidades divergentes de diferentes grupos usuarios y/o compradores. En
este caso, cada grupo de usuario y/o comprador podría desarrollar un ConOps para documentar
sus necesidades y puntos de vista particulares. Esto debería ser hecho como un preludio para
obtener una visión consensuada, o determinar que ningún sistema simple pueda satisfacer todas
las distintas necesidades de usuarios y requerimientos de compradores.
5. Para documentar consenso sobre características del sistema entre múltiples usuarios, grupos de
usuarios, compradores múltiples. En este caso, el ConOps provee un mecanismo para
documentar la visión consensuada obtenida de necesidades, visiones y puntos de vista
divergentes entre diferentes usuarios o grupos de usuarios antes del proceso de desarrollo.
6. Para proveer un medio de comunicación entre ingenieros de sistemas y desarrolladores de
software. En este caso el ConOps debería describir las necesidades de usuario y requerimientos
operativos del sistema total (hardware, software y gente) y proveer un contexto para el rol del
software dentro del sistema total.
7. Para proveer la comprensión común entre múltiples organizaciones de desarrollo de sistemas y/o
software. En casos donde múltiples organizaciones de desarrollo de sistemas y/o software están
involucradas, el ConOps puede proveer una comprensión común de cómo el software encaja en
el todo sistema, y cómo cada parte de software encaja en la porción del sistema. En este caso,
puede haber múltiples documentos ConOps, relacionados de manera jerárquica que se
corresponde con las particiones del sistema.
Roles adicionales para el ConOps incluye:
8. Proveen un mecanismo para documentar las características de un sistema y las necesidades
operativas de los usuarios en una manera que pueda ser verificado por los usuarios sin requerir
tener cualquier conocimiento técnico más allá del requerido para realizar sus tareas.
9. Proveen un lugar para que los usuarios especifiquen sus deseos, visiones y expectativas sin
requerirles especificaciones cuantificadas y testeables. Por ejemplo, los usuarios podrían
expresar sus necesidades para un sistema “altamente formal” y sus razones por las que lo
necesitan, sin tener que producir un requerimiento formalmente testeable.
10. Proveen un mecanismo para que usuarios y compradores expresen sus pensamientos acerca
de estrategias posibles de solución. En algunos casos, puede haber diseños que contrastan. En
otros casos puede haber una variedad de estrategias de solución aceptables. El ConOps permite a
los usuarios y compradores registrar los contrastes de diseño, las razones para esos contrastes, e
indicar el rango de estrategias de solución aceptables.
-4-
El Concepto de Operaciones. Fairley
Idealmente, el análisis conceptual y el desarrollo del documento ConOps debería ser realizado por
el usuario. Sin embargo, dependiendo del propósito del desarrollo, el ConOps podría ser
desarrollado por los usuarios, el comprador o el desarrollador. En estos casos, el comprador o
desarrollador deben comprometer a los usuarios en el proceso para asegurar la correcta
comprensión del sistema actual, necesidades de los usuarios, visiones y expectativas para el nuevo
sistema.
Una manera de garantizar las interacciones necesarias es establecer un equipo interdisciplinario
constituído de representantes de todos los grupos usuarios, del comprador, y del desarrollador.
El usuario puede no saber como desarrollar un documento ConOps, o puede no conocer las
capacidades de la tecnología. Para reducir el impacto de estos problemas, personal calificado puede
asistir al usuario en el desarrollo del documento ConOps.
Un beneficio del desarrollo del ConOps por parte de los desarrolladores, es que ellos tienen en la
mayoría de los casos conocimiento de la tecnología disponible, y pueden ser capaces de proponer
formas alternativas de resolver los problemas del usuario. Otro beneficio del desarrollo del ConOps
por parte de los desarrolladores es que el proceso de análisis del ConOps proveerá al desarrollador
de un buen entendimiento de los problemas del usuario, necesidades y expectativas que facilitan las
siguientes etapas de desarrollo.
-5-
El Concepto de Operaciones. Fairley
Sin importar quién asume la responsabilidad primaria de producir el ConOps, es importante que
todas las partes (usuarios, compradores y desarrolladores) estén involucrados en el proceso de
análisis y que todos contribuyan con su punto de vista personal para desarrollar el ConOps.
La aproximación descripta antes intenta ser una guía. Si dicha aproximación entra en conflicto con
lo que parece ser lo más apropiado en una situación específica, la guía debería ser modificada para
encajar en esa situación.
Por ejemplo, puede no haber sistema actual, o el nuevo sistema puede ser una modificación del
sistema actual, o el nuevo puede ser un reemplazo total de un sistema absoleto (manual o
automatizado). Los temas enfatizados en el ConOps pueden ser diferentes en cada situación.
1. Determinar los objetivos, roles y miembros del equipo para el proceso ConOps.
2. Diseñar el formato del documento ConOps recomendado y obtener un esbozo del ConOps. Esto
es importante para que todos conozcan el formato acordado y las áreas contenidas en el
documento.
3. Describir los objetivos generales del sistema actual. También determinar y documentar los
objetivos generales para el nuevo o modificado sistema. Si no hay sistema actual, describa la
situación que motiva el desarrollo de un nuevo sistema.
4. Si hay un sistema existente, describa el alcance y los límites del sistema, e identifique el sistema
externo y la interface con él. También, establezca y describa en términos generales el alcance y
límites para el nuevo sistema, e identifique el sistema externo y la interfaz con él.
5. Describir las políticas operacionales que se aplican al sistema actual y cualquier cambio en
aquellas políticas y contrastes para el nuevo sistema.
6. Describa las características del sistema actual. Esto incluye las características operacionales del
sistema, procesos y ambiente operacional, modos de operación, clases de usuario, y el soporte
operacional y ambiente de mantenimiento.
7. Especificar las políticas operacionales que se aplicarán al nuevo sistema.
8. Determinar las características operacionales del sistema propuesto, eso es, describir las
características del sistema propuesto para satisfacer las necesidades y expectativas de los
usuarios.
9. Documentar los escenarios operativos para el nuevo sistema. Los escenarios son especificados
registrando, paso a paso, las secuencias de acciones e iteraciones entre un usuario y el sistema.
Los siguientes pasos pueden ser llevados a cabo para desarrollar un documento de escenarios de
operaciones :
Desarrollar un documento de escenarios que cubra todos los modos de operación, todas las clases
de usuarios, y todas las operaciones y procesos específicos del sistema propuesto.
Recorrer cada escenario con los usuarios apropiados y registrar información concerniente a
estados normales de operación como así también condiciones no usuales que son relevantes.
Durante las recorridas establecer nuevos escenarios para cubrir operaciones anormales tales
como manejos de excepciones, manejo de carga de estrés y manejo de datos incorrectos e
incompletos.
Desarrolle repetidamente escenarios hasta cubrir todas las operaciones y todas las variaciones
significativas de tales operaciones.
Por cada escenario operativo, desarrolle un escenario de prueba para ser usado en la validación
de aspectos operativos del sistema entregado en el ambiente del usuario. Asocie escenarios
operativos y escenarios de prueba.
-6-
El Concepto de Operaciones. Fairley
10. Después de que los escenarios han sido desarrollados, se debe validar la descripción del
sistema propuesto y los escenarios operacionales, recorriendo todos los escenarios con
representantes de todos los grupos usuarios.
11. Obtener consenso sobre las prioridades de los escenarios operacionales y las características
del sistema propuesto.
12. Analizar y describir los impactos operacionales y organizacionales que el sistema propuesto
tendrá sobre usuarios, compradores, desarrolladores y agentes de soporte/mantenimiento.
13. Describir los beneficios, limitaciones, ventajas y desventajas del sistema propuesto
comparado con el sistema actual.
-7-
El Concepto de Operaciones. Fairley
APENDICE
1. ALCANCE.
1.1. Identificación.
1.2. Vista global del sistema.
1.3. Vista global del documento.
2. DOCUMENTOS REFERENCIADOS
3. EL SISTEMA ACTUAL O SITUACION
3.1. Experiencia, objetivos y alcance del sistema o situación actual.
3.2. Políticas y contrastes operacionales del sistema o situación actual.
3.3. Descripción del sistema actual.
3.4. Modo de operación del sistema actual.
3.5. Clases de usuarios del sistema actual.
3.5.1. Estructura organizacional.
3.5.2. Perfiles de clases de usuarios.
3.5.3. Interacciones entre clases de usuarios.
3.6. Otro personal involucrado.
3.7. Entorno de soporte del sistema actual.
4. JUSTIFICACION POR CAMBIOS Y NUEVAS CARACTERISTICAS
4.1. Justificación por cambios y nuevas características.
4.2. Descripción de nuevas características y cambios necesarios.
4.3. Prioridades entre cambios y nuevas características.
4.4. Cambios y nuevas características consideradas pero no incluidas.
4.5. Suposiciones y contrastes.
5. CONCEPTOS DE OPERACIONES PARA EL SISTEMA PROPUESTO
5.1. Experiencias, objetivos y alcance del sistema nuevo o modificado.
5.2. Políticas y contrastes operacionales.
5.3. Descripción del sistema propuesto.
5.4. Modo de operación del sistema propuesto.
5.5. Clases de usuarios del sistema propuesto.
5.5.1. Estructura organizacional.
5.5.2. Perfiles de clases de usuarios.
5.5.3. Interacciones entre clases de usuarios.
5.6. Otro personal involucrado.
5.7. Entorno de soporte para el sistema propuesto.
6. ESCENARIOS OPERACIONALES PARA EL SISTEMA PROPUESTO
7. RESUMEN DE IMPACTOS
7.1. Impacto operacional.
7.2. Impacto organizacional.
7.3. Impacto durante el desarrollo.
8. ANALISIS DEL SISTEMA PROPUESTO
8.1. Resumen de mejoras.
8.2. Desventajas y limitaciones.
8.3. Alternativas y balances considerados.
-8-