Vous êtes sur la page 1sur 8

El Concepto de operaciones

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

Resumen.

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

-1-
El Concepto de Operaciones. Fairley

El desarrollo de un Documento Conceptual de Operaciones (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.

El Documento Conceptual de Operaciones (ConOps)

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

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

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

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

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-