El Concepto de operaciones

El puente de los requerimientos operacionales a las especificaciones técnicas

Resúmen.

Este artículo describe el rol de un documento de operaciones en la especificación y

desarrollo de un sistema de software. También describe el proceso de desarrollo de una
operación, sus usos y beneficios, quien debería desarrollarlo y cuando debería ser
desarrollado.

Introducción.

El objetivo de la Ingeniería del Software es desarrollar y modificar sistemas de software

que satisfagan las necesidades del usuario, siguiendo un cronograma y dentro de un
presupuesto dado.
La correcta comunicación de los requerimientos operacionales, desde aquellos que
necesitan el sistema de software a aquellos que construyen el sistema, es el paso más
importante en el proceso de desarrollo del sistema. Tradicionalmente esta información ha
sido comunicada como sigue:
El desarrollador analiza las necesidades del usuario y los requerimientos del comprador, y
prepara una especificación de requerimientos que define la comprensión de los
desarrolladores de aquellas necesidades y requerimientos. Los usuarios y el comprador
revisan la especificación de requerimientos e intentan verificar que el desarrollador ha
comprendido correctamente sus necesidades y requerimientos.
Un manual de usuario es algunas veces escrito por el desarrollador para asistir a los
usuarios y al comprador para que pueda determinar si el sistema propuesto responde de
manera consistente a sus necesidades y expectativas. Un prototipo de la interface usuario
puede ser construído para demostrar que el desarrollador ha comprendido la interface
usuario deseada.
Esta manera tradicional de especificar requerimientos de software introduce varios
problemas: Primero, el comprador no puede comunicar adecuadamente las necesidades de
la comunidad usuaria al desarrollador, tal vez porque el comprador no comprende aquellas
necesidades. Segundo, el desarrollador puede no ser experto en el dominio de la aplicación,
lo cual inhibe la comunicación. Tercero, los usuarios y el comprador frecuentemente
encuentran difícil entender los requerimientos producidos por el desarrollador. Cuarto, la
especificación de requerimientos del desarrollador generalmente especifica atributos del
sistema tales como funciones, factores de rendimiento, restricciones de diseño, interfaces
del sistema, y atributos de calidad, pero típicamente contiene poco o nada acerca de
características del sistema especificado. Esto deja al usuario y al comprador inseguro de
que el sistema vaya a proveer la capacidad operacional necesaria.
Una versión preliminar del manual del usuario puede proveer alguna seguridad de que el
desarrollador comprendió las necesidades y expectativas usuario/comprador. Si fuese
escrito dicho manual, esto consume un tiempo y esfuerzo considerable. Es difícil demostrar
que la correspondencia entre especificaciones técnicas, manual de usuario, y los
requerimientos operacionales (no documentados) es completa y consistente.
Un prototipo de la interface usuario puede ser útil, pero existe el peligro de que esa
demostración de una interface usuario aceptable suponga que el desarrollador entiende
todas las necesidades operacionales del usuario. En resumen, la aproximación tradicional
no facilita la comunicación entre usuarios, comprador y desarrollador, ni enfatiza la
importancia de especificar los requerimientos operacionales del sistema.

-1-
 El Concepto de Operaciones. Fairley

El análisis conceptual ayuda a los usuarios a clasificar sus necesidades operacionales,

facilitando de este modo la comunicación entre usuarios, compradores y desarrolladores.
El desarrollo de un Documento Conceptual de Operaciónes (ConOps) para registrar los
resultados del análisis conceptual, provee un puente que va de las necesidades del usuario
al proceso de desarrollo del sistema.
Normalmente, el análisis y desarrollo del documento ConOps es el primer paso en el
proceso de desarrollo.

El proceso del Análisis Conceptual.

El análisis conceptual es el proceso de analizar el dominio de un problema y un entorno

operacional con el propósito de especificar las características de un sistema propuesto
desde la perspectiva del usuario.
El proceso tradicional de desarrollo de sistemas enfatiza en la funcionalidad y dice poco
acerca de cómo esa funcionalidad será usada. El análisis conceptual enfatiza en una visión
integrada de un sistema y sus características operacionales, mas que en el enfoque sobre
funciones y piezas individuales de un sistema.
El propósito más importante del análisis conceptual es evitar desarrollar un sistema en el
cual cada función individual encuentre su especificación, pero el sistema en su conjunto
falle por no satisfacer las necesidades del usuario.
El análisis conceptual debería ser el primer paso en el proceso de desarrollo del sistema
total. Este identifica las distintas clases de usuarios y modos de operación y provee a los
usuarios de mecanismos para definir sus necesidades y deseos. El Análisis Conceptual es
también útil para pulir necesidades y puntos de vista de diferentes usuarios, y permitir al
comprador especificar sus requerimientos del sistema.
Los usuarios tienen la oportunidad de expresar sus necesidades y deseos, pero se requiere
que ellos especifiquen qué necesidades son esenciales, cuales son deseables y cuales son
opcionales. Las necesidades de usuario priorizadas proveen las bases para establecer un
proceso de desarrollo incremental y hacer el balance entre necesidades operacionales,
cronogramas y presupuesto.
El análisis conceptual ayuda a clarificar y resolver necesidades, deseos y opiniones vagas y
conflictivas, reconciliando vistas divergentes. Puede ayudar a obtener consenso sobre los
puntos anteriores entre el grupo de usuarios/compradores.
En algunos casos, puede ocurrir que ningún sistema simple pueda satisfacer todas las
necesidades y deseos divergentes de múltiples usuarios y/o compradores. Es mejor llegar a
esta conclusión en etapas tempranas en el desarrollo del proyecto.
El Análisis conceptual es un proceso interactivo que debería involucrar a distintas
personas. El grupo de análisis debería incluir representantes de usuarios, compradores y
desarrolladores.
El resultado del Análisis Conceptual es registrado en el Documento ConOps, el cual sirve
como estructura para guiar el proceso de análisis y proveer el documento fuente para las
siguientes actividades de desarrollo del sistema (análisis, diseño, implementación y
validación).
El documento ConOps debería decir todo acerca del sistema que los usuarios/compradores
necesitan para comunicar a quienes desarrollarán el sistema.
El documento ConOps debería ser revisado repetidamente hasta que todas las partes
involucradas estén de acuerdo en el documento resultante.
Este proceso interactivo ayuda a traer a la superficie muchos puntos de vista, necesidades,
deseos y escenarios que de otro modo serían pasados por alto.

-2-
 El Concepto de Operaciones. Fairley

El Documento Conceptual de Operaciones (CopOps)

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, expectativas, entorno operativo, procesos y características del
sistema en consideración. Los elementos esenciales de un ConOps incluyen:
 Una descripción del sistema o situación actual.
 Una descripción de las necesidades que motivan el desarrollo de un nuevo sistema o la
modificación de uno ya existente.
 Modos de operación del sistema propuesto.
 Clases y características de usuario.
 Escenario operativo para cada modo operacional y clase de usuario.
 Limitaciones de la propuesta.
 Análisis del impacto del sistema propuesto.
Un documento ConOps debería en contraste a la especificación de requerimientos, ser
escrito en prosa narrativa, usando el lenguaje y terminología del dominio de aplicación del
usuario. Debería ser organizado para contar una historia, y debería hacer uso de formas
visuales (diagramas, ilustraciones, gráficos, etc.) cuando sea posible. Aunque es deseable,
no es necesario que las necesidades y deseos expresados en un ConOps estén
cuantificados; eso es, los usuarios pueden especificar su deseo como una “respuesta
rápida” u “operación formal”. Estos deseos son cuantificados durante el proceso de mapeo
del ConOps a la especificación de requerimientos y durante el pasaje de los requerimientos
a la arquitectura del sistema. Durante el desarrollo del sistema, el impacto del balanceo
entre los atributos del sistema cuantificado (tal como tiempo de respuesta) deben ser
explorados dentro de los límites de tiempo disponible, dinero, y el estado de la tecnología.
Un documento ConOps debería ser hecho a la medida del dominio de aplicación, entorno
operativo y audiencia. Esto significa que la terminología, nivel de abstracción, detalle,
contenido técnico y presentación formal deberían adjuntarse a los objetivos de ese
documento ConOps particular. Estos puntos son evaluados a continuación:
1. Un documento ConOps debe ser escrito en el lenguaje del usuario. Esto no
necesariamente implica que no se pueda usar un lenguaje técnico, pero más tarde
debería ser escrito en el lenguaje técnico del usuario si los usuarios son expertos en un
dominio técnico. Si el documento ConOps es escrito por el comprador o desarrollador,
los autores deben evitar usar la terminología asociada a su propia disciplina.
2. El nivel de detalle contenido en un ConOps debería ser apropiado para la situación. Por
ejemplo, puede haber casos en donde una descripción de alto nivel es suficiente. En
otros casos, una descripción detallada del sistema actual puede ser necesaria. El nivel de
detalle también depende de si el documento ConOps es para un sistema como un todo, o
si habrá documentos ConOps separados por cada segmento del sistema con un paraguas
ConOps que describe aspectos operacionales del sistema entero.
3. El formato de representación usado en un documento variará dependiendo de la
aplicación del documento. En algunas comunidades usuarias, los documentos de texto
son la tradición, mientras en otros son usados gráficos.
4. El esbozo de un documento ConOps, como se muestra en el apéndice A, puede no
aplicarse a cada sistema o situación. Para resumir el formato ConOps presentado en el
apéndice A debería ser hecho para producir un mecanismo de costo y eficiencia para
documentar las necesidades del usuario y para mantener el seguimiento a aquellas
necesidades a través del proceso de desarrollo.
-3-
 El Concepto de Operaciones. Fairley

Roles para los documentos ConOps

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
-4-
 El Concepto de Operaciones. Fairley

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.

¿Cuándo debería ser desarrollado el ConOps?

El desarrollo de un documento ConOps debería ser el primer paso en el proceso de

desarrollo general, de modo que sirva como base para las actividades de desarrollo
siguientes. Podría ser desarrollado:
1. Antes de que sea tomada la decisión de desarrollar el sistema. Debería ser usado como
soporte durante el proceso de decisión.
2. Antes de enviar la Solicitud de la Propuesta (RFP). El ConOps debería estar incluido en
la Solicitud de Propuesta o Autorización del proyecto.
3. Como la primera tarea después de firmar el contrato, de modo que el desarrollador
pueda comprender mejor las necesidades y expectativas del usuario, antes de comenzar
las actividades de desarrollo.
En los casos (1) y (2), el desarrollo del ConOps será iniciado por el usuario o el comprador
(aunque el autor del documento podría ser un desarrollador). En el caso (3), el desarrollado
del ConOps puede ser iniciado por el usuario, comprador o desarrollador.
El análisis conceptual y la preparación de un documento ConOps puede también ser
bastante útil aún si es iniciado en etapas tardías del ciclo de vida del sistema. Sí, durante el
desarrollo del sistema, muchas opiniones, necesidades, visiones y puntos de vista
divergentes hacen que el proceso de desarrollo no pueda continuar exitosamente, un
documento ConOps puede proveer una visión “común” del sistema.
El desarrollador que construye un sistema podría querer desarrollar un documento ConOps,
aún cuando las especificaciones de requerimientos hayan sido generadas. El desarrollador
podría querer el ConOps como una vista de alto nivel e introducción al sistema, que sirva
como guía para un equipo de desarrollo.
Un documento ConOps podría ser desarrollado durante la fase operacional del ciclo de
vida del sistema, como soporte a usuarios, operadores y quienes mantienen el sistema.
Como conclusión, un documento ConOps puede ser desarrollado en cualquier momento
durante el ciclo de vida de un sistema; sin embargo, la mayoría de los beneficios que se
pueden esperar de él se pierden si es desarrollado después de las especificaciones de
requerimientos.

Escenarios para desarrollar el ConOps

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.
-5-
 El Concepto de Operaciones. Fairley

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.
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.

Un proceso de desarrollo para 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.

-6-
 El Concepto de Operaciones. Fairley

 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.
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.

Formato recomendado de un ConOps

1. Introducción al documento ConOps y al sistema descripto.

2. Lista de documentos referenciados en el documento ConOps.
3. Descripción del sistema actual, incluyendo alcance y objetivos del sistema actual,
políticas operativas y contrastes, modos de operación, clases de usuarios y el ambiente
de soporte. Si no hay sistema actual, describa las razones que motivan el desarrollo de
un nuevo sistema.
4. Naturaleza de los cambios y/o características propuestas, incluyendo la justificación
para aquellos cambios y/o características.
5. Conceptos operativos del sistema propuesto, incluyendo alcance y objetivos, políticas
operativas, modos de operación, clases de usuarios y ambiente de soporte para el
sistema propuesto.
6. Escenarios operacionales que describan como el sistema propuesto es ejecutado en su
ambiente, relacionando las capacidades y funciones del sistema a los modos de
operación, clases de usuarios e iteraciones con sistemas externos.
7. Impactos operativos y organizacionales sobre los usuarios, compradores,
desarrolladores y agentes de soporte/mantenimiento durante el desarrollo y después de
la instalación del sistema.
8. Alternativas consideradas pero no incluidas en el nuevo sistema, análisis de beneficios,
limitaciones, ventajas y desventajas del nuevo sistema.
9. Notas, abreviaturas, apéndices y glosario de términos.
Esta organización de un ConOps provee un flujo lógico de información, comenzando con
una descripción del sistema actual, transitando a través de la propuesta de cambios y
llegando a una descripción del nuevo sistema. Esto guiará al lector a través del sistema de
una manera simple intuitiva.

-7-
 El Concepto de Operaciones. Fairley

APENDICE

ESBOZO DE UN DOCUMENTO CONCEPTUAL DE OPERACIONES.

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-