BÚSQUEDA Y DESCRIPCIÓN DE REQUISITOS FUNCIONALES.
ESPECIFICACIÓN DE SOLUCIONES TÉCNICAS. ANÁLISIS DE VIABILIDAD TÉCNICA Y ECONÓMICA.
ÍNDICE
1. INTRODUCCIÓN
2. IDENTIFICACIÓN DE LAS NECESIDADES
3. ESTUDIO DE VIABILIDAD
4. ANÁLISIS ECONÓMICO
5. ANÁLISIS TÉCNICO
6. ASIGNACIÓN Y COMPROMISOS
7. MODELIZACIÓN DE LA ARQUITECTURA DEL SISTEMA
7.1. Diagramas de arquitectura
7.2. Especificación de la arquitectura del sistema
8. BIBLIOGRAFÍA
1. INTRODUCCIÓN
El análisis del sistema es una actividad que engloba la mayoría de las tareas que hemos llamado colectivamente ingeniería de sistemas basados en ordenador. Algunas veces se incurre en confusión porque el término se usa a menudo en un contexto que alude sólo a las actividades de análisis de los requisitos del software. Para el propósito de este estudio, el análisis del sistema se centra en todos los elementos del sistema, no sólo en el software.
El análisis del sistema se realiza teniendo presentes los siguientes objetivos: (1) identificar las necesidades del cliente; (2) evaluar la viabilidad del sistema; (3) realizar un análisis técnico y económico; (4) asignar funciones al software, al hardware, a la gente, a la base de datos y a otros elementos del sistema; (5) establecer restricciones de coste y tiempo; (6) crear una definición del sistema que sea la base para todo el trabajo posterior de ingeniería. Para alcanzar con éxito esos objetivos, se requiere experiencia, tanto en hardware como en software (así como en ingeniería humana y en bases de datos). Aunque la mayoría de los profesionales de la industria reconocen que el tiempo y el esfuerzo gastado en el análisis de sistemas producen dividendos importantes más adelante en el proceso de desarrollo del sistema, todavía surgen tres preguntas:
¿Cuánto esfuerzo se debe emplear en el análisis y en la definición de sistemas y de software? Es difícil establecer unas directrices definitivas para determinar el esfuerzo de análisis. El tamaño del sistema y su complejidad, el área de aplicación, el uso final y las obligaciones del contrato son sólo unas pocas de las muchas variables que afectan al esfuerzo total dedicado al análisis. Una regla de “andar por casa” usada a menudo es que se debe dedicar entre el 10 y el 20 por
100 de todo el esfuerzo de desarrollo al análisis del sistema y aplicar otro 10 o 20 por 100 del esfuerzo de la ingeniería del software del análisis de los requisitos del software.
¿Quién lo hace? Todas las tareas han de ser dirigidas por un analista bien formado y con experiencia. El analista trabaja en contacto con el personal técnico y administrativo, tanto del cliente como del que desarrolla el sistema. Para muchos proyectos grandes, debe crearse un equipo para cada tarea de análisis.
¿Por qué es tan difícil? Se trata de una transformación de un concepto dudoso en un conjunto concreto de elementos tangibles. Debido a que durante el análisis la comunicación es excepcionalmente densa, abundan las oportunidades de mal entendimiento, omisiones, inconsistencias y errores. Finalmente, la percepción del sistema puede cambiar a medida que avanza la actividad, invalidando, de esta manera, el trabajo anterior.
2. IDENTIFICACIÓN DE LAS NECESIDADES
El primer paso del proceso de análisis del sistema implica la identificación de las necesidades. El analista (ingeniero de sistemas) se entrevista con el cliente o su representante. El cliente puede ser un representante de una compañía externa, del departamento de marketing de la compañía del analista (cuando se está definiendo un producto) o de otro departamento técnico (cuando se va a desarrollar un sistema interno).
La identificación de las necesidades es el punto de partida en la evolución de un sistema basado en ordenador. La Figura 51.1 muestra las entradas que se le suministran al analista como parte de este paso. Para empezar, el analista da asistencia al cliente definiendo los objetivos del sistema (producto): la información que se va a obtener, la información que se va a suministrar, las funciones y el rendimiento requerido. El analista se asegura de distinguir entre lo que “necesita” el cliente (elementos críticos para la realización) y lo que el cliente “quiere” (elementos deseables pero no esenciales).
Una vez que se han identificado todos los objetivos, el analista pasa a una evaluación de la
información suplementaria: ¿existe la tecnología necesaria para construir el sistema? ¿qué recursos de fabricación y de desarrollo especiales se requerirán? ¿qué límites se han impuesto a los costes y a la agenda? Si el nuevo sistema es un producto que va a ser desarrollado para venderlo a muchos clientes, también se hacen las siguientes preguntas: ¿cuál es el mercado potencial para el producto? ¿cómo se compara este producto con los de la competencia? ¿qué lugar ocupa este producto dentro de la línea global de la compañía?
La información recogida durante la etapa de identificación de las necesidades se especifica en un documento de conceptos del sistema. A veces, es el cliente el que prepara un documento de conceptos inicial antes de reunirse con el analista. Invariablemente, los resultados de la comunicación analista- cliente producen modificaciones en el documento.
3. ESTUDIO DE VIABILIDAD
Todos los proyectos son realizables (¡con recursos ilimitados y un tiempo infinito!). Desdichadamente, el desarrollo de un sistema basado en ordenador se caracteriza por la escasez de recursos y la dificultad (si no imposibilidad) de cumplir los plazos de entrega. Es necesario y prudente evaluar la viabilidad de un proyecto lo antes posible. Se pueden evitar meses o años de esfuerzo, miles de millones de pesetas y una inversión profesional incalculable, si un sistema mal concebido es reconocido como tal al principio de la etapa de definición.
El análisis de viabilidad y el análisis del riesgo están relacionados de varias maneras. Si el riesgo del proyecto es grande, se reduce la posibilidad de producir software de calidad. Sin embargo, durante la ingeniería del sistema centramos nuestra atención en cuatro áreas de interés básico:
Viabilidad económica. Una evaluación del coste de desarrollo frente al beneficio final producido por el sistema desarrollado.
Viabilidad técnica. Un estudio de la funcionalidad, el rendimiento y las restricciones que pueden afectar a la posibilidad de realización de un sistema aceptable.
Viabilidad legal. Una determinación de cualquier infracción, violación o ilegalidad que pudiera resultar del desarrollo del sistema.
Alternativas. Una evaluación de los enfoques alternativos para el desarrollo del sistema.
No será necesario llevar a cabo un estudio de viabilidad para sistemas en los que la justificación económica es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe una alternativa razonable. Sin embargo, cuando no se da alguna de las anteriores condiciones, debe realizarse el estudio.
La justificación económica es normalmente la principal consideración para la mayoría de los sistemas (excepciones notables son los sistemas de defensa nacional, los sistemas impuestos por la ley y las aplicaciones de alta tecnología, como el programa espacial). La justificación económica comprende un amplio rango de aspectos, entre los que se encuentran el análisis de coste-beneficio, las estrategias de
ingresos a largo plazo, el impacto en otros productos o en centros de explotación, el coste de los recursos que se necesitan para el desarrollo y el crecimiento potencial del mercado.
La viabilidad técnica es frecuentemente el área más difícil de evaluar en esta etapa del proceso de desarrollo del sistema. Debido a que los objetivos, las funciones y el rendimiento son de alguna manera confusos, cualquier cosa puede parecer posible si se hacen las consideraciones adecuadas. Es esencial que el proceso de análisis y de definición se realice en paralelo con el análisis de viabilidad técnica. De esta forma, se pueden juzgar las especificaciones concretas según se van determinando.
Las consideraciones que van asociadas normalmente a la viabilidad técnica son:
Riesgo del desarrollo. ¿Puede el elemento del sistema ser diseñado de tal forma que las funciones y el rendimiento necesarios se consigan dentro de las restricciones determinadas en el análisis?
Disponibilidad de recursos. ¿Hay personal cualificado para desarrollar el elemento del sistema en cuestión? ¿Están disponibles para el sistema otros recursos necesarios (de hardware y de software)?
Tecnología. ¿Ha progresado la tecnología relevante lo suficiente como para poder soportar el sistema?
Los desarrolladores de los sistemas basados en ordenador son optimistas por naturaleza. (¿Quién más tiene el suficiente coraje para intentar hacer aquello a lo que nosotros frecuentemente nos comprometemos sin pensarlo mucho?). Sin embargo, durante una evaluación de viabilidad técnica debería prevalecer una actitud cínica, si no pesimista. Las equivocaciones en esta etapa pueden ser desastrosas.
La viabilidad legal comprende un amplio rango de aspectos que incluyen los contratos, la responsabilidad, las infracciones y un millar de otros detalles frecuentemente desconocidos para el personal técnico. Un estudio de los aspectos legales del software va más allá del alcance de este tema.
El grado en el que se consideran las alternativas muchas veces está limitado por restricciones de tiempo y de dinero; sin embargo, no se debería descartar cualquier alternativa legítima, aunque no tenga quien “la financie”.
El estudio de viabilidad puede documentarse en un informe separado de los otros documentos importantes de gestión e incluirse como apéndice en la especificación del sistema. Aunque el formato del informe de viabilidad puede variar, el esquema de la tabla 51.1 cubre la mayoría de los aspectos importantes. La revisión del estudio de viabilidad ha de llevarla a cabo primero el gestor del proyecto (para asegurar la fiabilidad de su contenido) y luego el director administrativo (para determinar el estado del proyecto). El estudio debe provocar una decisión de “seguir/no seguir.
4. ANÁLISIS ECONÓMICO
Entre la información más relevante que contiene el estudio de viabilidad se encuentra el análisis de coste-beneficio, una evaluación de la justificación económica para un proyecto de sistema basado en ordenador. El análisis de coste-beneficio señala los costes del desarrollo del proyecto y los contrasta con los beneficios tangibles (esto es, medibles directamente en pesetas) e intangibles del sistema.
El análisis de coste-beneficio es complicado porque los criterios varían según las características del sistema a desarrollar, el tamaño relativo del proyecto y la recuperación esperada de la inversión como parte del plan estratégico de la compañía. Además, muchos beneficios obtenidos de los sistemas basados en ordenador son intangibles (p. ej.: una mejor calidad del diseño mediante una optimización iterativa, una mayor satisfacción del cliente debida a un control programable y unas mejores decisiones comerciales a partir de datos de ventas con formato previamente analizados). Puede ser difícil lograr comparaciones directas cuantitativas.
Como hemos visto anteriormente, el análisis de los beneficios diferirá dependiendo de las características del sistema. La mayoría de los sistemas de proceso de datos se desarrollan teniendo como principal objetivo una mejor cantidad, calidad, rapidez y organización de la información. Así, los beneficios se centran en el acceso a la información y su impacto en el entorno del usuario. Los beneficios que se pueden asociar a programas de análisis científico y de ingeniería o a un producto basado en microprocesador pueden diferir substancialmente.
Los beneficios de un sistema nuevo siempre se determinan de acuerdo con el modo de trabajo ya existente. Por ejemplo, consideremos un sistema de diseño asistido por ordenador (CAD) que vaya a reemplazar a elementos del proceso manual de diseño en ingeniería. El analista de sistemas debe definir características ponderables del sistema existente (diseño manual) y del sistema propuesto (CAD). Seleccionando el tiempo de producción de un dibujo completo y detallado (t-dibujo) entre las muchas cantidades medibles, el analista llega a la conclusión de que el sistema CAD supondrá una reducción de 4 a 1 en ese t-dibujo. Para cuantificar con más detalle este beneficio, determina los siguientes datos:
t-dibujo, tiempo medio de dibujo = 4 horas d, coste por hora de dibujo = 2.000 ptas
n, número de dibujos por año = 8.000
p, porcentaje de dibujo que se va a realizar en el sistema CAD = 60 por 100
Conocidos los datos anteriores, puede establecer una estimación del ahorro anual o beneficio:
Ahorro en el coste del tiempo de dibujo = reducción * t-dibujo * n * c * p = 9.600.000 ptas. por año
Otros beneficios tangibles del sistema CAD serían tratados de una manera similar. A los beneficios intangibles (p. ej.: mejor calidad de diseño y mayor estímulo para los empleados) se les puede asignar valores en pesetas o usarlos como apoyo de una recomendación de “seguir”, si fuese oportuna.
Otro aspecto del análisis de coste-beneficio es la consideración de los costes incrementales asociados con los beneficios añadidos (mayor o mejor funcionalidad y rendimiento). En algunos casos los costes se incrementan proporcionalmente a los beneficios hasta un determinado punto. Después de ese punto, cada beneficio adicional es demasiado caro. Por ejemplo, consideremos una función de sondeo en tiempo real que tiene 500 milisegundos de tiempo muerto. Se pueden añadir nuevas tareas a un coste relativamente bajo; sin embargo, si la ejecución total de la tarea se aproxima a los 500 milisegundos, el coste de implementación aumenta drásticamente, ya que se debe mejorar el rendimiento global. En otros casos, los costes aumentan proporcionalmente y después se nivelan a favor de los beneficios añadidos, antes de aumentar drásticamente para los posteriores beneficios. Como ejemplo, consideremos un sistema operativo monousuario que se va mejorando hasta soportar finalmente varios usuarios. Una vez que se dispone del soporte multiusuario, la tasa de aumento del coste al añadir funciones multiusuario puede bajar un poco. Sin embargo, una vez que se alcance la capacidad máxima del procesador, las nuevas funciones requerirán un procesador más potente, con el consiguiente gran incremento en el coste.
Sólo gastando el tiempo necesario para evaluar la viabilidad, reducimos las oportunidades de situaciones extremadamente embarazosas (o más que embarazosas) en etapas posteriores de un proyecto
de un sistema. El esfuerzo gastado en el análisis de viabilidad que resulta en la cancelación de un proyecto propuesto no es un esfuerzo desaprovechado.
5. ANÁLISIS TÉCNICO
Durante el análisis técnico, el analista evalúa los méritos técnicos del concepto de sistema, mientras que al mismo tiempo recoge información adicional sobre el rendimiento, fiabilidad, facilidad de mantenimiento y posibilidad de producción. En algunos casos la etapa de análisis del sistema también incluye una cantidad limitada de investigación y de diseño.
El análisis técnico empieza con una definición de la viabilidad técnica del sistema propuesto. ¿Qué tecnologías se requieren para conseguir la funcionalidad y el rendimiento del sistema? ¿Qué nuevos materiales, métodos, algoritmos o procesos se requieren y cuál es el riesgo de su desarrollo? ¿Cómo afectarán al coste estos elementos de tecnología?
Las herramientas de que se puede disponer para el análisis técnico se encuentran en las técnicas matemáticas de modelización y optimización, en la probabilidad y la estadística, en la teoría de colas y en la teoría de control -por nombrar unas cuantas. Sin embargo, es importante tener en cuenta que la evaluación analítica no es siempre posible. La modelización (bien matemática o física) es un mecanismo efectivo para el análisis técnico de sistemas basados en ordenador. El modelo se crea a partir de la observación del mundo real o de una aproximación basada en los objetivos del sistema. El analista comprueba el comportamiento del modelo y lo compara con el del mundo real o con el del sistema esperado, obteniendo información de viabilidad técnica para el sistema propuesto.
Blanchard y Fabrycky definen un conjunto de criterios para el uso de modelos durante el análisis técnico de sistemas:
1. El modelo debe representar la dinámica de la configuración del sistema que está siendo evaluado, de una forma que sea suficientemente simple de comprender y manipular, y también que esté lo suficientemente cerca de la realidad operativo como para obtener resultados satisfactorios.
2. El modelo debe realzar aquellos factores que sean más relevantes para el problema en cuestión y suprimir (con discreción) aquéllos que no sean importantes.
3. El modelo debe ser amplio, incluyendo todos los factores relevantes, y fiable en cuanto a repetición de resultados.
4. El diseño del modelo debe ser lo suficientemente simple como para permitir una rápida implementación de la resolución del problema. A no ser que la herramienta pueda ser utilizada de una manera rápida y eficiente por el analista o por el gestor, será de poca utilidad. Si el modelo es grande y muy complejo, puede ser apropiado desarrollar una serie de modelos en los que la salida de uno pueda ser conectada a la entrada de otro. También puede ser deseable evaluar un elemento específico de un sistema independientemente del resto de los elementos.
5. El diseño del modelo debe incorporar previsiones para poder modificarlo y/o expandirlo fácilmente y permitir la evaluación de factores adicionales si se requieren. En un desarrollo satisfactorio del modelo, a menudo se hace una serie de intentos antes de alcanzar el objetivo final. Los intentos iniciales pueden hacer evidentes ciertas lagunas en la información que no se hayan detectado a primera vista y, consecuentemente, sugerir cambios beneficiosos.
Los resultados del análisis técnico son la base de otra decisión del tipo “seguir/no seguir” con el sistema. Si el riesgo técnico es alto, si los modelos indican que la funcionalidad o el rendimiento deseados no pueden ser alcanzados, o si las piezas no encajan bien, ¡hay que volver a la mesa de trabajo!
6. ASIGNACIÓN Y COMPROMISOS
Una vez que se ha respondido a las cuestiones relativas a la tarea de análisis, hay que considerar soluciones alternativas. Cada función del sistema, con su rendimiento requerido y sus características de interfaz, es asignada a uno o más elementos del sistema.
Por ejemplo, el análisis de un nuevo sistema de gráficos de computadora indica que una función importante es la transformación espacial de las imágenes gráficas tridimensionales. Una investigación de soluciones alternativas para la función de transformación revela las siguientes opciones:
1. Todas las transformaciones tridimensionales realizadas por el software.
2. Las transformaciones “simples” (p.ej.: cambio de escala, traslación y rotación) realizadas por el hardware y las transformaciones “complejas” (p.ej.: perspectiva y sombreado) realizadas por el software.
3. Todas las transformaciones realizadas por un procesador gráfico implementado con hardware.
Se evalúa cada alternativa de configuración para el sistema de acuerdo con un conjunto de “parámetros de evaluación” (criterios de compromiso) que han sido ordenados de acuerdo con su importancia. En general, los parámetros de evaluación están relacionados con los factores económicos (p.ej.: el coste del ciclo de vida). Cuando dos o más parámetros de evaluación del sistema de bajo orden (p.ej.: e tiempo de respuesta o la resolución de la pantalla) pueden variar (en diferentes asignaciones), permitiendo que se siga alcanzando un parámetro deseable de alto orden (p. ej.: el coste o la fiabilidad), se aísla un área de compromiso.
7. MODELIZACIÓN DE LA ARQUITECTURA DEL SISTEMA
Una vez asignadas las funciones del sistema basado en ordenador, el ingeniero de sistemas puede crear un modelo que represente las interrelaciones entre los distintos elementos del sistema y establezca una base para los posteriores pasos de análisis de requisitos y de diseño. Ya hemos visto que cada sistema basado en ordenador se puede modelar como una transformación de información mediante una arquitectura de entrada-proceso-salida. Hatley y Pirbhai han ampliado este enfoque, incluyendo dos características adicionales del sistema: el procesamiento de la interfaz de usuario y el procesamiento de mantenimiento y de autocomprobación. Aunque estas características adicionales no están presentes para todos los sistemas basados en ordenador, son muy comunes y su especificación hace que cada modelo de sistema sea más robusto.
7.1. Diagramas de Arquitectura
Para desarrollar el modelo del sistema se utiliza una plantilla de arquitectura. El ingeniero de sistemas asigna elementos del sistema a cada una de las cinco regiones de procesamiento dentro de la plantilla: (1) interfaz de usuario, (2) entrada, (3) función y control del sistema, (4) salida y (5) mantenimiento y autocomprobación. El formato de la plantilla de arquitectura aparece en la Figura.
Como casi todas las técnicas de modelización utilizadas en la ingeniería del software y de sistemas,
la plantilla de arquitectura permite al analista crear una jerarquía de detalles. En el nivel superior de la jerarquía está el diagrama de contexto de la arquitectura (DCA).
El diagrama de contexto establece los límites de información entre los que se está implementando el sistema y el entorno en el que va a funcionar el sistema. Es decir, el DCA define todos los productores de información externos utilizados por el sistema, todos los consumidores de información externos creados por el sistema y todas las entidades que se comunican a través de la interfaz o realizan mantenimiento o autocomprobación.
Para ilustrar el uso del DCA, consideremos un sistema de clasificación de cinta transportadora. Esta utiliza un ordenador personal (PC) como estación de clasificación. El PC ejecuta todo el software del SCCT; está conectado al lector de códigos de barras para leer los números de serie de cada caja; está conectado al equipo de supervisión de la cinta transportadora para obtener la velocidad; guarda todos los números de serie clasificados; interactúa con un operador de la estación de clasificación produciendo una serie de informes y diagnósticos; manda señales de control al hardware encargado de la maniobra para clasificar las cajas y se comunica con el ordenador central de la fábrica de automatización, En la Figura
51.3 se muestra el DCA.
Cada cuadro de la Figura representa una entidad externa, es decir, un productor o un consumidor de
información del sistema. Por ejemplo, el lector de códigos de barras produce información que entra en el sistema SCCT. El símbolo que representa el sistema completo (o, a niveles más bajos, los subsistemas principales) es un rectángulo en negrita. Aquí, el SCCT está representado en la región de proceso y control, en el centro del DCA. Las flechas del DCA representan la información (de datos y de control) que fluye entre el entorno externo y el sistema SCCT. La entidad externa lector de códigos de barras produce información de entrada que debe ser etiquetada como código de barras. En esencia, el DCA ubica el sistema en el contexto de su entorno externo.
El ingeniero de sistemas refina el diagrama de contexto de la arquitectura considerando con más detalle el rectángulo en negrita la Figura 51.3 identifica los subsistemas principales que permiten el funcionamiento del sistema de clasificación de cinta transportadora en el contexto definido por el DCA. De acuerdo con la Figura 51.4, se definen los subsistemas principales en un diagrama de flujo de la arquitectura (DFA), que se obtiene a partir del DCA. Como guía para el desarrollo del DFA -un “esquema” más detallado del SCCT-, el ingeniero de software utiliza la información que fluye a través de las regiones del DCA. El diagrama de flujo de la arquitectura muestra los subsistemas principales y las líneas importantes de flujo de información (control y datos). Además, la plantilla de la arquitectura clasifica el procesamiento de los subsistemas en una de las cinco regiones de procesamiento vistas anteriormente. En esta etapa, cada uno de los subsistemas pueden contener uno o más elementos del sistema (p. ej.: hardware, software, gente) según hayan sido asignados por el ingeniero de sistemas.
El diagrama inicial de flujo de la arquitectura se constituye en el nodo raíz de la jerarquía de DFAs.
Se puede ampliar cada rectángulo redondeado del DFA inicial en otra plantilla de arquitectura dedicada exclusivamente a él. Cada uno de los DFAs del sistema se puede utilizar como punto de partida para los posteriores pasos de ingeniería del subsistema que describe.
7.2. Especificación de la Arquitectura del Sistema
Se pueden especificar (limitar) los subsistemas y la información que fluye entre ellos para que esté disponible en los posteriores trabajos de ingeniería. La especificación del diagrama de arquitectura (EDA) presenta la información sobre cada subsistema y el flujo de información entre los subsistemas. La EDA contiene una descripción -denominada narrativa de módulo del sistema– de cada subsistema. La narrativa de módulo del sistema describe qué hace el subsistema, qué información procesa y cómo está relacionado con otros subsistemas. Además de las narrativas, la EDA puede contener un diccionario de arquitectura: una lista con los elementos de información que aparecen en el DFA y sus descripciones.
El último elemento de la especificación del diagrama de arquitectura es el diagrama de interconexión de la arquitectura (DIA) y la correspondiente descripción de la interconexión. Las flechas del DFA indican el flujo del control y de los datos, sin describir cómo se efectúa ese flujo de información. El DIA y la especificación correspondiente, describirán cómo se transfiere la información: electrónicamente (p. ej.: por un bus), ópticamente (p. ej.: por un enlace óptico de alto ancho de banda) o mecánicamente (p. ej.: mediante un actuador o una articulación mecánica). Para desarrollar el DIA, el ingeniero de sistemas tiene que tomar decisiones de implementación que es mejor dejarlas para la etapa de diseño.
8. BIBLIOGRAFÍA
Pressman, Roger S. Ingeniería del Software Mc Graw-Hill, 1993
López, Antonio Metodologías de Desarrollo Ra-ma, 1990