Ingeniería de Sistemas basado en Ingeniería del Software.
Introducción
En este parte de ingeniería de software consideramos los conceptos técnicos, métodos y mediciones que son aplicables al análisis, diseño y pruebas del software.
La ingeniería del software aparece como consecuencia de un proceso denominado ingeniería de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información.
El proceso de ingeniería de sistemas es denominado ingeniería de procesos de negocio cuando el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un producto, el proceso se denomina ingeniería de producto. Tanto la ingeniería de proceso de negocio como la de producto intentan poner orden al desarrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de aplicación diferente, ambas intentan poner al software en su contexto.
¿Qué es ingeniería de Sistema?
Antes de que el software se pueda construir, el sistema en el que residirá se debe comprender. Para lograrlo, se deben definir los objetivos generales del sistema; se debe identificar el papel del hardware, software, personas, bases de datos, procedimientos y otros elementos del sistema; y los requerimientos operacionales deben ser identificados; analizados, especificados, modelizados, validados y gestionados. Estas actividades son la base de la ingeniería de sistemas.
¿Quién lo hace?
Un ingeniero de sistema que trabaja para comprender los requisitos del sistema en colaboración con el cliente, los futuros usuarios y otras partes interesadas.
¿Por qué es importante?
Son importante por que generan elementos tecnológicos que para realizar este sistema en el que ayuda enormemente a la generación del software.
Los objetivos y los requisitos operacionales de mayor detalle son identificados gracias a la información facilitada por el cliente. Los requisitos son analizados para valorar su claridad, completitud y consistencia. Una especificación incorporada a un modelo de sistema, se crea y valida posteriormente por los clientes y las partes interesadas. Finalmente, los requisitos del sistema son gestionados para asegurar que los cambios se controlan adecuadamente.
¿Cuál es producto obtenido?
Se debe obtener una correcta representación del sistema como consecuencia de la ingeniería de sistema. Se puede realizar a través de un prototipo, una especificación o incluso un modelo simbólico, debiendo comunicar la operativa, la funcionalidad y las características de comportamiento del sistema que se va construir e incorporarlo dentro de la arquitectura del sistema.
¿Cómo puedo estar seguro de que lo he hecho correctamente?
El producto obtenido, a través de la aplicación de la ingeniería de sistemas, debe ser revisado para determinar su claridad, completitud y consistencia. Es importante que los cambios en los requisitos de un sistema sean gestionados utilizando métodos sólidos
Sistema Basado en Computadora
La palabra sistema es posiblemente el término más usado y abusado del léxico técnico. Hablamos de sistemas políticos y de sistemas educativos, de sistemas de aviación y de sistemas de fabricación, de sistemas bancarios y de sistemas de locomoción. La palabra no nos dice gran cosa. Usamos el adjetivo para describir el sistema y para entender el contexto en que se emplea. El diccionario Webster define sistema como:
1. Un conjunto o disposición de cosas relacionadas de manera que forman una unidad o un todo orgánico.
2. Un conjunto de hechos, principios, reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lógico de unión de las partes; 3. un método o plan de clasificación o disposición; 4.una manera establecida de hacer algo; método; procedimiento ...
Un conjunto o disposición de elementos que están organizados para realizar un objetivo prevenido procesando información.
El objetivo puede ser soportar alguna función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema:
ž Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido.
ž Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, conmutadores de red, dispositivos de telecomunicación) y dispositivos electromecánicos (por ejemplo, sensores, motores, bombas) que proporcionan una función externa, del mundo real.
ž Personas. Usuarios y operadores del hardware y software.
ž Documentación. Manuales, formularios y otra información descriptiva que plasma el empleo y/o funcionamiento del sistema.
ž Procedimientos. Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema.
Los elementos se combinan de varias maneras para transformar la información. Por ejemplo, un departamento de marketing transforma la información bruta de ventas en un perfil del típico comprador del producto; un robot transforma un archivo de órdenes, que contiene instrucciones específicas, en un conjunto de señales de control que provocan alguna acción física específica.
Tanto la creación de un sistema de información para asesorar a un departamento de marketing, como el software de control para el robot, requieren de la ingeniería de sistemas.
Una característica complicada de los sistemas basados en computadora es que los elementos que componen un sistema pueden también representar un macro elemento de un sistema aún más grande. El macro elemento es un sistema basado en computadora que es parte de un sistema más grande basado en computadora.
Por ejemplo, consideremos un «sistema de automatización de una fábrica» que es esencialmente una jerarquía de sistemas. En el nivel inferior de la jerarquía tenemos una máquina de control numérico, robots y dispositivos de entrada de información. Cada uno es un sistema basado en computadora por derecho propio.
Los elementos de la máquina de control numérico incluyen hardware electrónico y electromecánico (por ejemplo, procesador y memoria, motores, sensores); software (para comunicaciones, control de la máquina e interpolación); personas (el operador de la máquina); una base de datos (el programa CN almacenado); documentación y procedimientos. Se podría aplicar una descomposición similar a los dispositivos de entrada de información y al robot. Todos son sistemas basados en computadora.
En el siguiente nivel de la jerarquía, se define una célula de fabricación. La célula de fabricación es un sistema basado en computadora que puede tener elementos propios (por ejemplo, computadoras, fijaciones mecánicas) y también integra los macro elementos que hemos denominado máquina de control numérico, robot y dispositivo de entrada de información. Para resumir, la célula de fabricación y sus macro elementos están compuestos de elementos del sistema con las etiquetas genéricas: software, hardware, personas, base de datos, procedimientos y documentación.
En algunos casos, los macro elementos pueden compartir un elemento genérico. Por ejemplo, el robot y la máquina CN podrían ser manejadas por el mismo operador (el elemento personas). En otros casos, los elementos genéricos son exclusivos de un sistema. El papel del ingeniero de sistemas es definir los elementos de un sistema específico basado en computadora en el contexto de la jerarquía global de sistemas (macro elementos).
Independientemente del dominio de enfoque, la ingeniería de sistemas comprende una colección de métodos para navegar de arriba abajo y de abajo arriba en la jerarquía. El proceso de la ingeniería de sistemas empieza normalmente con una «visión global». Es decir, se examina el dominio entero del negocio o del producto para asegurarse de que se puede establecer el contexto de negocio o tecnológico apropiado.
La visión global se refina para enfocarse totalmente en un dominio de interés específico. Dentro de un dominio específico, se analiza la necesidad de elementos del sistema (por ejemplo, información, software, hardware, personas). Finalmente, se inicia el análisis, diseño y construcción del elemento del sistema deseado. En la parte alta de la jerarquía se establece un contexto muy amplio y en la parte baja se llevan a cabo actividades técnicas detalladas, realizadas por la disciplina de ingeniería correspondiente (por ejemplo, ingeniería hardware o software).
Modelado del sistema
La ingeniería de sistemas de computadora es un proceso de modelado. Tanto si el punto de mira está en la visión global o en la visión detallada, el ingeniero crea modelos que:
Definan los procesos que satisfagan las necesidades de la visión en consideración.
Representen el comportamiento de los procesos y los supuestos en los que se basa el comportamiento.
Definan explícitamente las entradas exógenas3 y endógenas de información al modelo.
Representen todos las uniones (incluyendo las salidas) que permitan al ingeniero entender mejor la visión.
Para construir un modelo del sistema, el ingeniero debería considerar algunas restricciones:
1. Supuestos que reducen el número de permutaciones y variaciones posibles, permitiendo así al modelo reflejar el problema de manera razonable. Por ejemplo considere un producto de representación en tres dimensiones usado por la industria de entretenimiento para crear animaciones realistas. Un dominio del producto permite la representación de formas humanas en 3D. Las entradas a este dominio comprenden la habilidad de introducir movimiento de un «actor» humano vivo, desde vídeo o creando modelos gráficos. El ingeniero del sistema hace ciertos supuestos sobre el rango de movimientos humanos permitidos de manera que puede limitarse el proceso y el rango de entradas.
2. Simplificaciones que permiten crear el modelo a tiempo. Para ilustrarlo, considere una compañía de productos de oficina que vende y suministra una amplia variedad de fotocopiadoras, faxes y equipos similares. El ingeniero del sistema está modelando las necesidades de la organización suministradora y está trabajando para entender el flujo de información que engendra una orden de suministro. Aunque una orden de suministro puede generarse desde muchos orígenes, el ingeniero categoriza solamente dos fuentes: demanda interna o petición externa. Esto permite una partición simplificada de entradas necesaria para generar una orden de trabajo.
3. Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se está modelando un sistema de aviónica para un avión de próxima generación. Como el avión tendrá un diseño de dos motores, todos los dominios de supervisión de la propulsión se modelarán para albergar un máximo de dos motores y sus sistemas redundantes asociados.
4. Restricciones que guían la manera de crear el modelo y el enfoque que se toma al implementar el modelo. Por ejemplo, la infraestructura tecnológica para el sistema de representación en tres dimensiones descrita anteriormente es un solo procesador basado en un Power-PC. La complejidad de cálculo de los problemas debe restringirse para encajar en los límites de proceso impuestos por el procesador.
5. Preferencias que indican la arquitectura preferida para todos los datos, funciones y tecnología. La solución preferida entra a veces en conflicto con otros factores restrictivos. Aunque la satisfacción del cliente es a menudo tomada en cuenta hasta el punto de realizar su enfoque preferido.
El modelo de sistema resultante (desde cualquier visión) puede reclamar una solución completamente automática, semiautomática o un enfoque manual.
De hecho, es posible a menudo caracterizar modelos de cada tipo que sirven de soluciones alternativas para el problema que tenemos entre manos. En esencia, el ingeniero del sistema modifica simplemente la influencia relativa de los diferentes elementos del sistema (personas, hardware, software) para crear modelos de cada tipo.
Simulación del sistema
Muchos sistemas basados en computadora interaccionan con el mundo real de forma reactiva. Es decir, los acontecimientos del mundo real son vigilados por el hardware y el software que componen el sistema, y basándose en esos sucesos, el sistema aplica su control sobre las máquinas, procesos e incluso las personas que motivan los acontecimientos.
Los sistemas de tiempo real y sistemas empotrados pertenecen a menudo a la categoría de sistemas reactivos.
Desgraciadamente, los desarrolladores de sistemas reactivos luchan a veces para hacerlos funcionar correctamente. Hasta hace poco, ha sido difícil predecir el rendimiento, la eficacia y el comportamiento de estos sistemas antes de construirlos.
Realmente, la construcción de muchos sistemas de tiempo real era una aventura. Las sorpresas (la mayoría desagradables) no se descubrían hasta que el sistema era construido y «arrojado colina abajo». Si el sistema se estrellaba debido a un funcionamiento incorrecto, comportamiento inapropiado o escaso rendimiento, cogíamos las piezas y empezábamos de nuevo.
Muchos sistemas de la categoría de los reactivos controlan máquinas y/o procesos (por ejemplo, aerolíneas comerciales o refinerías de petróleo) que deben operar con extrema fiabilidad.
Si el sistema falla, podrían ocurrir pérdidas económicas o humanas significativas. Hoy en día se utilizan herramientas software para el modelado y simulación de sistemas para ayudar a eliminar sorpresas cuando se construyen sistemas reactivos basados en computadora.
Estas herramientas se aplican durante el proceso de ingeniería de sistemas, mientras se están especificando las necesidades del hardware, software, bases de datos y de personas.
Las herramientas de modelado y simulación capacitan al ingeniero de sistemas para probar una especificación del sistema. Se estudia brevemente los detalles técnicos y técnicas especiales de modelado que se emplean para llevar a cabo estas pruebas.
Ingeniería de Proceso de Negocio: Una visión General
El objetivo de la ingeniería de proceso de negocio (ZPN) es definir arquitecturas que permitan a las empresas emplear la información eficazmente.
Cuando hablamos de una visión general de las necesidades de tecnología de información de una compañía, existen pequeñas incertidumbres que son planteadas a la ingeniería de sistemas. La ingeniería de proceso de negocio es un acercamiento para crear un plan general para implementar la arquitectura de computación.
Se deben analizar y diseñar tres arquitecturas diferentes dentro del contexto de objetivos y metas de negocio:
1. La arquitectura de datos proporciona una estructura para las necesidades de información de un negocio o de una función de negocio. Los ladrillos de la arquitectura son los objetos de datos que emplea la empresa. Un objeto de datos contiene un conjunto de atributos que definen aspectos, cualidades, características de los datos que han sido descritos. Por ejemplo, un ingeniero de la información puede definir el objeto de datos: cliente.
Para describir más en detalle al cliente, se definen los siguientes atributos:
Objeto: Cliente
Atributos:
ž nombre
ž nombre de la compañía
ž Clasificación del trabajo y autoridad en compra
ž Dirección comercial e información de contacto
ž Producto(s) de interés
ž Compra(s) anteriores
ž Fecha de último contacto
ž Situación del contacto
Una vez definido el conjunto de datos, se identifican sus relaciones. Una relación indica como los objetos están conectados. Como ejemplo, considerar los objetos: cliente y producto A. Los dos objetos pueden conectarse por la relación compra; es decir, un cliente compra el producto A o el producto A es comprado por un cliente.
Los objetos de datos (pueden existir cientos o miles para una actividad de negocio importante) fluyen entre las funciones de negocio, están organizados dentro de una base de datos y se transforman para proveer información que sirva a las necesidades del negocio.
2. La arquitectura de aplicación comprende aquellos elementos de un sistema que transforman objetos dentro de la arquitectura de datos por algún propósito del negocio. Se considera normalmente que la arquitectura de aplicación es el sistema de programas (software) que realiza esta transformación.
Sin embargo, en un contexto más amplio, la arquitectura de aplicación podría incorporar el papel de las personas (por ejemplo, cliente/servidor) que ha sido diseñado para implementar estas tecnologías.
3. La infraestructura tecnológica proporciona el fundamento de las arquitecturas de datos y de aplicaciones.
La infraestructura comprende el hardware y el software empleados para dar soporte a las aplicaciones y datos. Esto incluye computadoras y redes de computadora, enlaces de telecomunicaciones, tecnologías de almacenamiento y la arquitectura (por ejemplo, cliente/servidor) diseñada para implementar estas tecnologías.
Jerarquía de la ingeniería de Procesos
Como muestra la Figura, la visión global se consigue a través de la planificación de la estrategia de información (PEI). La PEI ve todo el negocio como una entidad y aísla los dominios del negocio (por ejemplo, ingeniería, fabricación, marketing, finanzas, ventas) importantes para la totalidad de la empresa. La PEI define los objetos de datos visibles a nivel empresa, sus relaciones y cómo fluyen entre los dominios del negocio.
La vista del dominio se trata con una actividad denominada análisis del área de negocio (AAN).
A medida que el ingeniero de información comienza el AAN, el enfoque se estrecha hacia un dominio del negocio específico. El AAN ve el área del negocio como una entidad y aísla las funciones de negocio y procedimientos que permiten al área del negocio lograr sus objetivos y metas. El AAN, al igual que la planificación de la estrategia de información, define objetos de datos, sus relaciones y cómo fluye la información. Pero a este nivel, estas características están delimitadas por el área de negocio que se está analizando. El resultado de AAN es aislar las áreas de oportunidad en las que los sistemas de información pueden prestar soporte al área de negocio.
Una vez que se ha aislado un sistema de información para un desarrollo posterior, la IPN hace una transición a la ingeniería del software. Invocando la fase del diseño de sistema de negocio (DSN), se modelan los requisitos básicos de un sistema de información específico y estos requisitos se traducen en arquitectura de datos, arquitectura de aplicación e infraestructura tecnológica.
El paso final de la IPN (construcción e integración, C&Z) se centra en los detalles de la implementación. La arquitectura e infraestructura se implementan construyendo una base de datos apropiada y estructuras internas de datos, mediante la construcción de aplicaciones que están constituidas por programas, y seleccionando los elementos apropiados de una infraestructura tecnológica para dar soporte al diseño creado durante el diseño del sistema del negocio. Cada uno de estos componentes del sistema debe integrarse para formar una aplicación o sistema de información completo.
La actividad de integración también coloca al nuevo sistema de información en el contexto del área de negocio, realizando todo el entrenamiento de usuario y soporte logístico para conseguir una suave transición.
Ingeniería de Producto: una visión General
La meta de la ingeniería de producto es traducir el deseo de un cliente, de un conjunto de capacidades definidas, a un producto operativo. Para conseguir esta meta, la ingeniería de producto (como la ingeniería de proceso de negocio) debe crear una arquitectura y una infraestructura.
La arquitectura comprende cuatro componentes de sistema distintos:
ž Software
ž Hardware
ž datos (bases de datos)
ž personas.
Se establece una infraestructura de soporte e incluye la tecnología requerida para unir los componentes y la información (por ejemplo, documentos, CD-ROM, vídeo) que se emplea para dar soporte a los componentes
Jerarquía de la ingeniería del producto
Como se muestra en la Figura (jerarquía de la ingeniería del producto), la visión global se consigue a través de la ingeniería de requisitos.
Los requisitos generales del producto se obtienen del cliente. Estos requisitos comprenden necesidades de información y control, funcionalidad del producto y comportamiento, rendimiento general del producto, diseño, restricciones de la interfaz y otras necesidades especiales. Una vez que se conocen estos requisitos, la misión del análisis del sistema es asignar funcionalidad y comportamiento a cada uno de los cuatro componentes mencionados anteriormente.
Una vez que se ha hecho la asignación, comienza la ingeniería de componentes del sistema que consiste un conjunto de actividades concurrentes que se dirigen separadamente a cada uno de los componentes del sistema:
ž Ingeniería del software
ž Ingeniería hardware
ž Ingeniería humana
ž Ingeniería de bases de datos.
Cada una de estas disciplinas de ingeniería toma una vista de dominio específica, pero es importante resaltar que las disciplinas de ingeniería deben establecer y mantener una comunicación activa entre ellas.
Parte del papel del análisis de sistemas es establecer los mecanismos de interfaz que permitirán que esto suceda.
La visión de elemento para la ingeniería de producto es la disciplina de ingeniería aplicada a la asignación de componentes. Para la ingeniería del software, esto significa actividades de modelado del análisis y diseño (cubierto en detalle en posteriores capítulos) y actividades de construcción e integración que comprenden generación de código, pruebas y actividades de soporte. El modelado de la fase de análisis asigna requisitos a las representaciones de datos, funciones y comportamiento.
El diseño convierte el modelo de análisis en diseños de datos, arquitectónicos, de interfaz y a nivel de componentes del software.
La consecuencia del proceso de ingeniería de sistemas es la especificación de un sistema o producto basado en computadora que se describe genéricamente, en diferentes niveles. Pero el desafío de la ingeniería del sistema (y de los ingenieros del software) es importante: ¿Cómo podemos asegurar que hemos especificado un sistema que recoge las necesidades del cliente y satisface sus expectativas? No hay una respuesta segura a esta difícil pregunta, pero un sólido proceso de ingeniería de requisitos es la mejor solución de que disponemos actualmente.
La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos: Identificación de Requisitos, Análisis de Requisitos y Negociación, Especificación de Requisitos, Modelizado del Sistema, Validación de Requisitos y Gestión de Requisitos.
Identificación de requisitos
En principio, parece bastante simple -preguntar al cliente, a los usuarios y a los que están involucrados en los objetivos del sistema o producto y sean expertos, investigar cómo los sistemas o productos se ajustan a las necesidades del negocio, y finalmente, cómo el sistema o producto va a ser utilizado en el día a día.
Hay una serie de problemas que nos ayudan a comprender por qué la obtención de requisitos es costosa.
ž problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más que clarificar los objetivos del sistema.
ž problemas de comprensión. Los clientes/usuarios no están completamente seguros de lo que necesitan, tienen una pobre compresión de las capacidades y limitaciones de su entorno de computación, no existe un total entendimiento del dominio del problema, existen dificultades para comunicar las necesidades al ingeniero del sistema, la omisión de información por considerar que es «obvia», especificación de requisitos que están en conflicto con las necesidades de otros clientes/usuarios, o especificar requisitos ambiguos o poco estables.
ž Problemas de volatilidad. Los requisitos cambian con el tiempo.
¿Por qué es tan difícil obtener un planteamiento claro de lo que
necesita el cliente?
ž identificar las personas que ayudarán a especificar requisitos y contrastar su papel en la organización;
ž definir el entorno técnico (arquitectura de computación, sistema operativo, necesidades de telecomunicaciones) en el sistema o producto a desarrollar e integrar;
ž identificar «restricciones de dominio» (características específicas del entorno de negocio en el dominio de la aplicación) que limiten la funcionalidad y rendimientos del sistema o producto a construir;
ž definir uno o más métodos de obtención de requisitos (entrevistas, grupos de trabajo, equipos de discusión);
ž solicitar la participación de muchas personas para que los requisitos se definan desde diferentes puntos de vista, asegurarse de identificar lo fundamental de cada requisito registrado;
ž identificar requisitos ambiguos como candidatos para el prototipado.
ž crear escenarios de uso para ayudara los clientes/usuarios a identificar mejor los requisitos fundamentales.
El resultado alcanzado como consecuencia de la identificación de requisitos variará dependiendo del tamaño del sistema o producto a construir. Para grandes sistemas, el producto obtenido debe incluir:
ž una relación de necesidades y características;
ž un informe conciso del alcance del sistema o producto;
ž una lista de clientes, usuarios y otros intervinientes que deben participar en la actividad de obtención de requisitos;
ž una descripción del entorno técnico del sistema;
ž una relación de requisitos (perfectamente agrupados por funcionalidad) y las restricciones del dominio aplicables a cada uno;
ž un conjunto de escenarios que permiten profundizar en el uso del sistema o producto bajo diferentes condiciones operativas
ž cualquier prototipo desarrollado para definir mejor los requisitos. los métodos de obtención de requisitos
Cada uno de los productos obtenidos debe ser revisado por las personas que hayan participado en la obtención de sus requisitos.
Análisis y negociación de requisitos
¿Qué cuestiones deben ser preguntadas y contestadas durante el análisis de requisitos?
ž Al iniciarse la actividad del análisis de requisitos se plantean las siguientes cuestiones:
ž ¿Cada requisito es consistente con los objetivos generales del sistema/producto?
ž ¿Tienen todos los requisitos especificados el nivel adecuado de abstracción? Es decir, ¿algunos requisitos tienen un nivel de detalle técnico inapropiado en esta etapa?
ž ¿El requisito es necesario o representa una característica añadida que puede no ser esencial a la finalidad del sistema?
ž ¿Cada requisito está delimitado y sin ambigüedad?
ž Cada requisito tiene procedencia. Es decir, ¿existe un origen (general o específico) conocido para cada requisito?
ž ¿Existen requisitos incompatibles con otros requisitos?
ž ¿Es posible lograr cada requisito en el entorno técnico donde se integrará el sistema o producto?
ž ¿Se puede probar el requisito una vez implementado?
ž El ingeniero del sistema debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de intervinientes deberán clasificar sus requisitos y discutir los posibles conflictos según su prioridad. Los riesgos asociados con cada requisito serán identificados y analizados. Se efectúan «estimaciones» del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el coste del proyecto y en el plazo de entrega. Utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados.
Especificación de requisitos
En el contexto de un sistema basado en computadoras (y software), el término especificación significa distintas cosas para diferentes personas.
Una especificación puede ser un documento escrito, un modelo gráfico, un modelo matemático formal, una colección de escenarios de uso, un prototipo o una combinación de lo anteriormente citado. Algunos sugieren que debe desarrollarse una «plantilla estándar» y usarse en la especificación del sistema, argumentando que así se conseguirían requisitos que sean presentados de una forma más consistente y más comprensible.
No obstante, en muchas ocasiones es necesario buscar la flexibilidad cuando una especificación va a ser desarrollada. Para grandes sistemas, un documento escrito, combinado con descripciones en lenguajes natural y modelos gráficos puede ser la mejor alternativa. En cualquier caso, los escenarios a utilizar pueden ser tanto los requeridos para productos de tamaño pequeño o los de sistemas que residan en entornos técnicos bien conocidos.
La Especificación del Sistema es el producto final sobre los requisitos del sistema obtenido por el ingeniero. Sirve como fundamento para la ingeniería del hardware, ingeniería del software, la ingeniería de bases de datos y la ingeniería humana.
Modelado del sistema
Considérese por un momento que se le ha requerido especificar los requisitos para la construcción de una cocina. Se conocen las dimensiones del lugar, la localización de las puertas y ventanas y el espacio de pared disponible. Debes especificar todos los armarios y electrodomésticos e indicar dónde colocarlos. ¿Será una especificación válida?
La respuesta es obvia. Para especificar completamente lo que vamos a desarrollar, necesitamos un modelo de la cocina con toda su información, esto es, un anteproyecto o una representación en tres dimensiones que muestre las posiciones de los armarios y electrodomésticos, y sus relaciones. Con el modelo será relativamente fácil asegurar la eficiencia del trabajo (un requisito de todas las cocinas), la estética «visual» de la sala (es un requisito personal, aunque muy importante).
Se construyen modelos del sistema por la misma razón que desarrollamos para una cocina un anteproyecto o una representación en 3D. Es importante evaluar los componentes del sistema y sus relaciones entre sí; determinar cómo están reflejados los requisitos, y valorar como se ha concebido la «estética» en el sistema.
Validación de requisitos
El resultado del trabajo realizado es una consecuencia de la ingeniería de requisitos (especificación del sistema e información relacionada) y es evaluada su calidad en la fase de validación. La validación de requisitos examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el producto.
El primer mecanismo para la validación de los requisitos es la revisión técnica formal. El equipo de revisión incluye ingenieros del sistema, clientes, usuarios, y otros intervinientes que examinan la especificación del sistema5 buscando errores en el contenido o en la interpretación, áreas donde se necesitan aclaraciones, información incompleta, inconsistencias (es un problema importante), requisitos contradictorios, o requisitos imposibles o inalcanzables.
Aunque la validación de requisitos puede guiarse de manera que se descubran errores, es útil chequear cada requisito con un cuestionario. Las siguientes cuestiones representan un pequeño subconjunto de las preguntas que pueden plantearse:
ž ¿Está el requisito claramente definido? ¿Puede interpretarse mal?
ž ¿Está identificado el origen del requisito (por ejemplo: persona, norma, documento)? ¿El planteamiento final del requisito ha sido contrastado con la fuente original?
ž ¿El requisito está delimitado en términos cuantitativos?
ž ¿Qué otros requisitos hacen referencia al requisito estudiado? ¿Están claramente identificados por medio de una matriz de referencias cruzadas o por cualquier otro mecanismo?
ž ¿El requisito incumple alguna restricción definida?
ž ¿El requisito es verificable? Si es así, ¿podemos efectuar pruebas (algunas veces llamadas criterios de validación) para verificar el requisito?
ž ¿Se puede seguir el requisito en el modelo del sistema que hemos desarrollado?
ž ¿Se puede localizar el requisito en el conjunto de objetivos del sistema/producto?
ž ¿Está el requisito asociado con los rendimientos del sistema o con su comportamiento y han sido establecidas claramente sus características operacionales?
ž ¿El requisito está implícitamente definido?
Las preguntas planteadas en la lista de comprobación ayudan a asegurar que el equipo de validación dispone de lo necesario para realizar una revisión completa de cada requisito.
Gestión de requisitos
La gestión de requisitos es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento.
Como en la Gestión de Configuración del Software (GCS), la gestión de requisitos comienza con la actividad de identificación. A cada requisito se le asigna un Único identificador, que puede tomar la forma: <tipo de requisito><requisito n.0 >
El tipo de requisito toma alguno de los siguientes valores: F = requisito funcional, D = requisito de datos, C =requisito de comportamiento, Z = requisito de interfaz, y S = requisito de salida. De esta forma, un requisito identificado como F09 indica que se trata de un requisito funcional y que tiene asignado el número 9 dentro de los citados requisitos.
Una vez los requisitos han sido identificados, se desarrollarán un conjunto de matrices para su seguimiento. Cada matriz de seguimiento identifica los requisitos relacionados con uno o más aspectos del sistema o su entorno. Entre las posibles matrices de seguimiento citamos las siguientes:
ž Matriz de seguimiento de características. Muestra los requisitos identificados en relación a las características definidas por el cliente del sistema/producto.
ž Matriz de seguimiento de orígenes. Identifica el origen de cada requisito.
ž Matriz de seguimiento de dependencias. Indica cómo se relacionan los requisitos entre sí.
ž Matriz de Seguimiento de subsistemas. Vincula los requisitos a los subsistemas que los manejan.
ž Matriz de seguimiento de interfaces. Muestra como los requisitos están vinculados a las interfaces externas o internas del sistema.
En muchos casos, las matrices de seguimiento se incorporan como parte de un requisito de base de datos y se utiliza para buscar rápidamente los diferentes aspectos del sistema a construir afectados por el cambio de requisito.
Todos los sistemas basados en computadora pueden modelarse como una transformación de la información empleando una arquitectura del tipo entrada-proceso salida.
La visión para incluir dos características adicionales del sistema: tratamiento de la interfaz de usuario y tratamiento del mantenimiento y autocomprobación. Aunque estas características adicionales no están presentes en todos los sistemas basados en computadora, son muy comunes y su especificación hace más robusto cualquier modelo del sistema.
Mediante la representación de entrada, proceso, salida, tratamiento de la interfaz de usuario y de autocomprobación, un ingeniero de sistemas puede crear un modelo de componentes de sistema que establezca el fundamento para análisis de requisitos posteriores y etapas de diseño en cada una de las disciplinas de ingeniería.
Para desarrollar el modelo de sistema, se emplea un esquema del modelado del sistema. El ingeniero de sistemas asigna elementos a cada una de las cinco regiones de tratamiento del esquema: (1) interfaz de usuario, (2) entrada, (3) tratamiento y control del sistema, (4) salida y (5) mantenimiento y autocomprobación. En la Figura 10.5 se muestra el formato del esquema de arquitectura.
Como casi todas las técnicas de modelado usadas en la ingeniería del software y de sistemas, el esquema del modelado del sistema permite al analista crear una jerarquía en detalle. En la parte alta de la jerarquía reside el diagrama de contexto del sistema (DCS).
El diagrama de contexto «establece el límite de información entre el sistema que se está implementando y el entorno en que va a operar». Es decir, el DCS define todos los suministradores externos de información que emplea el sistema, todos los consumidores externos de información creados por el sistema y todas las entidades que se comunican a través de la interfaz o realizan mantenimiento y autocomprobación
Aqui les dejo un video hacerca de la perspectivas de ingenieria de sistemas .
Aqui les dejo un video hacerca de la perspectivas de ingenieria de sistemas .
Bibliografía:
Ingeniería de software 5 edición Roger Pressman
No hay comentarios:
Publicar un comentario