UNIDAD V: MODELO DE IMPLEMENTACION

5.1DIAGRAMA DE COMPONENTES

Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software (IEEE 1993) , y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software.¹Integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería.²

Se citan las definiciones más reconocidas, formuladas por prestigiosos autores:

• Ingeniería de software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978).
• Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976).
• La ingeniería de software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
• La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarollo, operación, y mantenimiento del software (IEEE, 1993).

En 2004, la U. S. Bureau of Labor Statistics (Oficina de Estadísticas del Trabajo de Estados Unidos) contó 760 840 ingenieros de software de computadora.³ El término "ingeniero de software", sin embargo, se utiliza de manera genérica en el ambiente empresarial, y no todos los que se desempeñan en el puesto de ingeniero de software poseen realmente títulos de ingeniería de universidades reconocidas.

Algunos autores consideran que "desarrollo de software" es un término más apropiado que "ingeniería de software" para el proceso de crear software. Personas como Pete McBreen (autor de "Software Craftmanship") cree que el término IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos "ingeniería de software" o "ingeniería del software"; aunque menos común también se suele referenciar como "ingeniería en software".^4 56 En Hispanoamérica los términos más comúnmente usados son los dos primeros.

La creación del software es un proceso intrínsecamente creativo y la ingeniería del software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la consecución del objetivo, por medio de diversas técnicas que se han demostrado adecuadas en base a la experiencia previa.

La IS se puede considerar como la ingeniería aplicada al software, esto es, por medios sistematizados y con herramientas preestablecidas, la aplicación de ellos de la manera más eficiente para la obtención de resultados óptimos; objetivos que siempre busca la ingeniería. No es sólo de la resolución de problemas, sino más bien teniendo en cuenta las diferentes soluciones, elegir la más apropiada.

UNIDAD IV: MODELO DEL DISEÑO

 4.1 ESTRATEGIAS DEL DISEÑO

 A través de la historia de la ingeniería de software ha evolucionado un conjunto de conceptos fundamentales de diseño de software. Cada uno ofrece al ingeniero de software un fundamento sobre el cual pueden aplicarse métodos de diseño más elaborados. Los conceptos fundamentales del diseño de software ofrecen el marco de trabajo necesario para hacer las cosas del “modo correcto”.

                                                        

La meta del diseño es crear un modelo de software que implemente todos los requisitos del cliente de manera correcta y complazca a aquéllos que lo
usen. El proceso de diseño avanza de una visión general del software a una visión más estrecha que define el detalle requerido para implementar un sistema.
El proceso de diseño comienza con un enfoque en la arquitectura. Se definen los subsistemas, se establecen mecanismos de comunicación entre los subsistemas; se identifican los componentes y se realiza una descripción detallada de cada componente. Además, se diseñan las interfaces internas, externas y del usuario.

 ABSTRACCIÓN: Para un problema determinado se pueden considerar muchos grados de abstracción. En un alto grado de abstracción una solución se establece en términos generales con el lenguaje de entorno del problema. En los grados de menor abstracción se proporciona una solución más detallada de la solución. Una abstracción procedimental se refiere a una secuencia de instrucciones que tiene una función específica y limitada.
Una abstracción de datos es una colección nombrada de datos que describe un objeto de datos.  Por ejemplo, se puede decir que la abstracción procedimental abrir emplearía la información contenida en los atributos de la abstracción de datos puerta.

         ARQUITECTURA: La arquitectura del software alude a la estructura general del software y las formas en las que la estructura proporcionan una integridad conceptual para un sistema. La arquitectura es la estructura u organización de los componentes del programa (módulos), la manera en que estos componentes
interactúan, y la estructura de datos que utilizan los
componentes.                                                            

        PATRONES: Un patrón de diseño describe una estructura de diseño que resuelve un problema recurrente de diseño particular dentro de un contexto específico y en medio de fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el patrón.
                                                         

                                                                     

        MODULARIDAD: Los patrones de arquitectura y diseño de software
materializan la modularidad; es decir, el software se divide en componentes con nombres independientes y que es posible abordar en forma individual. Estos componentes llamados módulos se integran para satisfacer los requisitos del problema. La modularidad se basa en la estrategia divide y vencerás (es más fácil resolver un problema complejo cuando éste se divide en piezas más manejables).

                                          

4.2 DISEÑO DE OBJETOS

         Un sistema orientado a objetos está compuesto de objetos que interactúan, los cuales mantienen ellos mismos su estado local y proveen operaciones sobre su estado. La representación del estado es privada y no se puede acceder a ella directamente desde fuera del objeto. El proceso de diseño de objetos comprende el diseño de clases de objetos y las relaciones entre estas clases. El diseño
orientado a objetos comprende el desarrollo de un modelo orientado a objetos de un sistema de software para implementar los requerimientos identificados. Los objetos en un diseño orientado a objetos están relacionados con el problema a
resolver.

Un proceso general para el diseño orientado a objetos puede contener las siguientes etapas:

      Comprender y definir el contexto y los modos de utilización del sistema

      Diseñar la arquitectura del sistema

      Identificar los objetos principales del sistema

      Desarrollar los modelos de diseño

      Especificar las interfaces de los objetos

Todas estas actividades se pueden ver como actividades entrelazadas que influyen entre sí. Los objetos se identifican y las interfaces se especifican completa o parcialmente en el momento de definir la arquitectura del sistema.

4.3 DISEÑO DE SISTEMAS

Durante el diseño de objetos, se ha desarrollado un diseño detallado con base en la arquitectura especificada. En general, el diseño de sistemas incluye aspectos como los siguientes:

      Selección del lenguaje de programación a utilizarse

      Incorporación de bibliotecas (para interfaces gráficas, estructuras de datos, etc.)

      Incorporación de una base de datos

      Incorporación de archivos en sus diferentes formatos

      Consideraciones de procesamiento,  como concurrencia, paralelismo, distribución y tiempo real.

Estos aspectos pueden variar entre un sistema y otro. Además, pueden afectar de manera importante la arquitectura final del sistema.

Existen diferentes enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema:

v  Agregar clases abstractas o interfaces que luego se especializarán según el ambiente de implementación

v  Instanciar objetos especializados para la administración del ambiente de implementación

v  Configurar múltiples versiones del sistema

v  Correspondientes a diferentes plataformas.

LENGUAJES DE PROGRAMACIÓN

Es importante señalar que un diseño orientado a objetos no necesariamente se tiene que implementar mediante un lenguaje orientado a objetos. Sin embargo, es más natural hacerlo de esta manera. Esto es debido a que los lenguajes orientados a objetos tienen un apoyo directo a los conceptos del análisis orientado a objetos (encapsulamiento, generalización, polimorfismo).
Sin embargo, se puede traducir cualquier concepto o mecanismo orientado a objetos a otros existentes en los lenguajes no orientados a objetos. El problema con este tipo de lenguajes es su conveniencia, mantenimiento y protección contra errores. Un lenguaje orientado a objetos hace que la escritura, mantenimiento y extensión de los programas sea más fácil y segura.
Cabe mencionar que no todos los lenguajes de programación orientados a objetos implementan de la misma forma los conceptos de la metodología orientada a objetos.  Aspectos como manejo de encapsulamiento, referencias, herencia múltiple varían de manera importante entre los lenguajes de programación.

 INTERFACES GRÁFICAS: Las interfaces gráficas tienen como objetivo principal administrar la interacción entre el usuario mediante elementos gráficos, como son botones, menús y textos. Las aplicaciones interactivas donde el control del ratón y teclado desempeñan un papel importante se conocen como sistemas controlados o dirigidos por eventos. Estos eventos comprenden: mover el ratón, oprimir uno de sus botones, oprimir una tecla, etc.

BASES DE DATOS: Las bases de datos son fundamentales en los sistemas de información. Una decisión importante en tal contexto es si debe utilizar bases de datos relacionales u orientados a objetos.
En general se consideran tres modelos de bases de datos principales:

ARCHIVOS: Aunque es más efectivo trabajar con bases de datos, es posible utilizar archivos, sobre todo cuando la especificación del sistema así lo requiera. En el caso de usar una base de datos, regularmente una clase se comunica con el DBMS
para hacer solicitudes a cualquier tabla. Sin embargo, en el caso de los archivos, tal manejador no existe por lo que el proceso se hace manualmente.

4.4 REVISIÓN DEL DISEÑO

Una revisión es un proceso o reunión durante la cual un producto de trabajo, un conjunto de productos de trabajo o la evidencia de la ejecución de un proceso se presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras partes interesadas para su comentario o aprobación.

Las revisiones al diseño de los productos de software se realizan por demanda con el objetivo de detectar e identificar no conformidades en el diseño antes de pasar a la codificación, así como también identificar aspectos de mejoramiento. Entre otros, en esta actividad se verifica la arquitectura y utilización de patrones en el diseño.

Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:

      Señalar la necesidad de mejoras en el producto de una sola persona o de un equipo

      Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.

      Conseguir un trabajo de mayor calidad maximizando los criterios de Correctitud  y Completitud principalmente.

Las revisiones software pueden ser:

 Informales: No hay procedimientos definidos, por lo que la revisión se realiza de la forma más flexible posible.

Ventajas: menor coste y esfuerzo, preparación corta, etc.

Desventajas: Detectan menos defectos

 Semi-formales: Se definen unos procedimientos mínimos a seguir (walkthroughs)

 Formales (Inspecciones): Se define completamente el proceso Revisión en detalle, por una persona o grupo distintos del autor, para: Verificar si el producto se ajusta a sus especificaciones o atributos de calidad  y a los estándares utilizados en la empresa Señalar las desviaciones sobre los estándares y las especificaciones Recopilar datos que realimenten inspecciones posteriores defectos.

4.5 DIAGRAMAS DE SECUENCIAS DEL DISEÑO

En un diagrama de secuencia se indicarán los módulos o clases que forman parte del programa y las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada.

Se realizan diagramas de secuencia para definir acciones que se pueden realizar en la aplicación en cuestión.

En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable.

Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases o módulos que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métodos van a implementar, qué deben llamar de la clase o módulo del otro, etc.

Aquí ya se ha decidido que se van a desarrollar tres librerías/paquetes/módulos, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de juego del ordenador.

El Diagrama de Secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores al sistema. Su creación forma parte de la investigación para conocer el sistema; se incluye dentro de la etapa del análisis.

En UML el Diagrama de Secuencia muestran gráficamente los eventos que pasan de los actores al sistema.

4.6 HERRAMIENTAS CASE PARA EL DISEÑO

Son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.

El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

      Análisis de datos y procesos integrados mediante un repositorio.

      Generación de interfaces entre el análisis y el diseño.

      Generación del código a partir del diseño.

      Control de mantenimiento.

Requisitos de aplicación de Case:

1.     Conocimiento y manejo de metodologías.

2.    Capacidad de trabajo en equipo.

3.    Desarrollo conjunto con los usuarios (Prototipos).

4.    Equipamiento apropiado.

Permiten al desarrollador crear un modelo del sistema que se va a construir y también la evaluación de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representación del análisis y ayudan a eliminar errores con anticipación. Se tienen:

·                                         Herramientas de análisis y diseño (Modelamiento).

·                                         Herramientas de creación de prototipos y de simulación.

·                                         Herramientas para el diseño y desarrollo de interfaces.

·                                         Máquinas de análisis y diseño (Modelamiento).

UNIDAD III: MODELO DE ANALISIS

UNIDAD 3 MODELO DE ANÁLISIS

Unidad 3

Objetivo de la unidad

Identificar a través de un modelo de requisitos la arquitectura de clases que participaran en el diseño del producto.

El modelo de análisis debe cumplir tres objetivos primarios: 1. Describe lo que requiere el cliente 2. Establecer una base para la creación de un diseño de software 3. Definir un conjunto de requisitos que puedan validarse una vez construido el software.

Reglas prácticas para el Modelado de Análisis El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio. Se debe minimizar el acoplamiento de todo el sistema Se debe tener la seguridad de que el modelo de análisis proporciona valor a todos los interesados. El modelo debe mantenerse tan simple como sea posible.

3.1ARQUITECTURA DE CLASES

El objetivo del modelo de análisis es crear una arquitectura de objetos que sirva como base para el diseño del sistema.

Dependiendo del tipo de aplicación existen varias arquitecturas. Ellas se distinguen  según la organización de los objetos de acuerdo a su funcionalidad. Esto es llamado dimensión de arquitectura.

Dimensión de la arquitectura

Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la interacción externa.

     Bidimensional: un grupo de objetos para manejar la funcionalidad y otros para las interacciones externas.

     Tridimensional: La más usada en los sistemas de información que siendo el Modelo-Vista-Control.

 

3.2 Identificación de clases según estereotipos

Clases con Estereotipos

El tipo de funcionalidad o “la razón de ser” de un objeto dentro de una arquitectura se le conoce como su estereotipo

 Para los sistemas de información la arquitectura del sistema según nuestro modelo de análisis se basa en tres estereotipos básicos de objetos:

 El estereotipo entidad  (“entity” en inglés) para objetos que guarden información sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado con esta información también se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento asociados.

 El estereotipo interface o borde (“boundary” en inglés) para objetos que implementen la presentación o vista correspondiente a las bordes del sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos. Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para insertar o modificar información sobre el registro de usuario.

El estereotipo control (“control” en inglés) para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos control modelan funcionalidad que no se liga naturalmente con ningún otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computación y luego devolver el resultado a un objeto borde. Un ejemplo típico de objeto control es analizar el uso del sistema por parte de algún usuario registrado y presentar tal información posteriormente. Este comportamiento no le pertenece a ningún objeto entidad u objeto borde específico. Nótese que no hay ninguna restricción a los diferentes estereotipos que puedan utilizarse, no solamente las tres anteriores.

3.3 clases

Una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utilizó para crear) esa instancia se puede considerar como del tipo de ese objeto. Por ejemplo, una instancia del objeto de la clase "Persona" sería del tipo "Persona".

Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, encapsula el estado y el comportamiento del concepto que representa. Encapsula el estado a través de marcadores de datos llamados atributos (o variable miembro o variables de instancia), y encapsula el comportamiento a través de secciones de código reutilizables llamados métodos.

3.4 diagrama de secuencias

Un diagrama de secuencia muestra:

•    Interacción de un conjunto de objetos en una aplicación a través del tiempo.
•    Un conjunto de mensajes, dispuestos en una secuencia temporal.
•    Cada rol en la secuencia como una línea de vida, es decir: una línea vertical.

Un diagrama de secuencia representa una interacción como un gráfico bidimensional.

•       La dimensión vertical: es el eje del tiempo

•       La dimensión horizontal muestra los roles de clasificador que representan objetos individuales en la colaboración

Un rol de clasificador:

•   Es la descripción de un objeto que desempeña un determinado papel dentro de una interacción, distinto de los otros objetos de la misma clase.

•   La primera utilización de los diagramas de secuencia corresponde a la documentación de los casos de uso, se concentra en la descripción de la interacción,

    La segunda utilización corresponde a un uso más informático y     permite la representación precisa de las interacciones entre objetos.

      Por lo tanto puede mostrar:

•       Escenario como la historia individual de la transacción que detalla los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, como también

•      El uso de los mensajes de las clases diseñadas en el contexto de una operación.

Cuando está implementado  el comportamiento,

Cada mensaje en un diagrama de secuencia

Corresponde a:

• Una operación en una clase,
• A un evento disparador, o
• A una transición en una máquina de estados.

3.5 diccionario de clases según módulos

Diccionario de datos

Los diccionarios de datos son el segundo componente del análisis del flujo de datos. En sí mismos los diagramas de flujo de datos no describen por completo el objeto de la investigación. El diccionario de datos proporciona información adicional sobre el sistema. Esta sección analiza que es un diccionario de datos, por qué se necesita en el análisis de flujo de datos y como desarrollarlo. Se utilizará el ejemplo del sistema de contabilidad para describir los diccionarios de datos.

Un diccionario de datos es una lista de todos los elementos incluido en el conjunto de los diagramas de flujo de datos que describen un sistema. Los elementos principales en un sistema, estudiados en las secciones anteriores, son el flujo de datos, el almacenamiento de datos y los procesos. El diccionario de datos almacena detalles y descripciones de estos elementos.

Si los analistas desean conocer cuántos caracteres hay en un dato, con qué otros nombres se le conocen en el sistema, o en donde se utilizan dentro del sistema deben ser capaces de encontrar la respuesta en un diccionario de datos desarrollado apropiadamente.

El diccionario de dato se desarrolla durante el análisis de flujo de datos y ayuda el analista involucrado en la determinación de los requerimientos de sistemas. Sin embargo, como se verá más adelante, también el contenido del diccionario de datos se utiliza durante el diseño del sistema.

En informática, base de datos acerca de la terminología que se utilizará en un sistema de información. Para comprender mejor el significado de un diccionario de datos, puede considerarse su contenido como "datos acerca de los datos"; es decir, descripciones de todos los demás objetos (archivos, programas, informes, sinónimos...) existentes en el sistema. Un diccionario de datos almacena la totalidad de los diversos esquemas y especificaciones de archivos, así como sus ubicaciones. Si es completo incluye también información acerca de qué programas utilizan qué datos, y qué usuarios están interesados en unos u otros informes. Por lo general, el diccionario de datos está integrado en el sistema de información que describe.

3.6 Herramientas CASE para el análisis

 

HERRAMIENTAS CASE

INTRODUCCIÓN

De acuerdo con Kendall el desarrollo de sistema es asistida por ordenadores es la aplicación de informática, es acelerar el proceso para que han sido desarrolladas. En cambio la herramienta CASE (Computer-Aided Software Engineering) sirve para apoyar una fase del ciclo de vida del sistema.

Cuando se planifica la base de datos permite escoger una herramienta CASE para llevar de forma eficaz y posible las tareas, también suelen incluir.

•          Un diccionario para los datos de la aplicación de base de datos.

•          Herramientas de diseño para dar apoyo al análisis de datos.

•          Herramientas para desarrollar el modelo de datos corporativo, los esquemas conceptual y lógico.

•          Herramientas para desarrollar los prototipos de las aplicaciones.

•          Con el uso de la herramienta CASE puede mejorar la productividad de aplicaciones de base de datos.

 

HISTORIA

En la década de los setenta el proyecto ISDOS desarrollo un lenguaje llamado "Problem Statement Language" (PSL) para la solución de un problema informático en un diccionario automatizado. Era un producto de que analizaba los problemas y necesidades.

La primera herramienta era para PC llamada "Excelerator" en 1984, la oferta de herramientas es muy amplia como es el EASYCASE o WINPROJECT.

TECNOLOGÍA

La tecnología CASE es la automatización del desarrollo software para mejorar la calidad del sistema de información.

•          Permitir aplicaciones prácticas de metodologías estructuradas, al ser realizadas con una herramienta consigue agilizar el trabajo.

•          Facilitar la realización de prototipos y desarrollo conjunto de aplicaciones.

•          Simplificar el mantenimiento de los programas.

•          Mejorar y estandarizar la documentación

•          Aumentar la portabilidad de las aplicaciones.

•          Facilitar la reutilización de componentes software.

•          Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.

 

UNIDAD 2: INGENIERÍA DE REQUISITOS

2.1. TAREAS DE LA INGENIERÍA DE REQUISITOS

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

Implicaciones

La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:

La educción (a veces llamada "elicitación", debido a una mala traducción de "elicitation") de los requisitos de usuario. El análisis y negociación de requisitos para derivar requisitos adicionales. La documentación de los requisitos como especificación. La validación de los requisitos  documentados contra las necesidades de usuario. Así como los procesos que apoyan estas actividades.

Fases de implementación

Desde un punto de vista conceptual, las actividades son de cinco clases. Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus expectativas. Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseño. Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados. Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicación. Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.

2.2. TÉCNICAS DE LA INGENIERÍA DE REQUISITOS

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

Entrevistas

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallos.

Las entrevistas pueden ser personales o grupales.

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

Prototipos

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Casos de uso

Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.

Ø  A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

Ø  Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

Ø  Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

Ø  Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

2.3. MODELADO DE REQUISITOS

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodologíaObjectory(Jacobson et al. 1992), basada principalmente en el modelo de casos de uso. Actualmente esta metodología es parte del Proceso Unificado de Rational(RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, como se describió anteriormente en el Capítulo 3 y se resume aquí:

1.- Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en

cooperación con otros modelos como se verá más adelante.

2.-Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.

3.-Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de

diseño, adaptándose al ambiente de implementación real y refinándose aún más.

4.-Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de

implementación.

5.-Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.

6.-Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.

El propósito del modelo de requisitos es comprender completamente el problema y sus implicaciones. Todos los modelos no solamente se verifican contra el modelo de requisitos, sino que también se desarrollan directamente de él. El modelo de requisitos sirve también como base para el desarrollo de las instrucciones operacionales y los manuales ya que todo lo que el sistema deba hacer se describe aquí desde la perspectiva del usuario. El modelo de requisitos no es un proceso mecánico, el analista debe interactuar constantemente con el cliente para completar la información faltante, y así clarificar ambigüedades e inconsistencias. El analista debe separar entre los requisitos verdaderos y las decisiones relacionadas con el diseño e implementación. Se debe indicar cuales aspectos son obligatorios y cuales son opcionales para evitar restringir la flexibilidad de la implementación. Durante el diseño se debe extender el modelo de requisitos con especificaciones de rendimiento y protocolos de interacción con sistemas externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir aspectos de diseño, como el uso de lenguajes de programación particulares. En la metodología deObjectory, el modelo de requisitos consiste de tres modelos principales, visualmente representado por un diagrama de tres dimensiones.

7.-Modelo de Casos de Uso

El modelo de casos de uso describe un sistema en término de sus distintas formas de utilización, cada uno de estas formas es conocida como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Dado que los casos de uso describen el sistema a desarrollarse, cambios en los requisitos significarán cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un automóvil sería la secuencia de eventos desde que el conductor entra en el coche encendiendo el motor hasta llegar a su destino final. Por lo tanto, para comprender los casos de uso de un sistema primero es necesario saber quiénes son sus usuarios. Por ejemplo, conducir un automóvil es distinto a arreglarlo, donde los usuarios también son distintos, el dueño del automóvil y el mecánico, respectivamente.

8.- Actores

Los actores son entidades distintas a los usuarios, en el sentido que los usuarios son las personas reales que utilizan el sistema, mientras que los actores representan un cierto papel que una persona real puede jugar. Utilizando terminología orientada a objetos, se considera al actor como una clase de usuario, mientras que los usuarios se consideran como objetos o instancias de esa clase. Incluso, una misma persona puede aparecer como diferentes instancias de diferentes actores.

Los actores modelan cualquier entidad externa que necesite intercambiar información con el sistema. Los actores no están restringidos a ser personas físicas, pudiendo representar otros sistemas externos al actual. Lo esencial es que los actores representen entidades externas al sistema. Además, cada uno de estos actores podrá ejecutar una o más tareas del sistema.

2.4. HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS.

A medida que pasa el tiempo se logra entender que el empleo del software es una buena opción

para agilizar y sistematizar las tareas en el desarrollo de procesos. El desarrollo de software no es la

excepción; en este caso dichas herramientas se han denominado CASE (Ingeniería De Software Asistida

Por Computador). Estas incluyen un conjunto de programas que facilitan la optimización de un producto

ofreciendo apoyo permanente a los analistas, ingenieros de software y desarrolladores.

CASE es la aplicación de métodos y técnicas que dan utilidades a los programas, por medio de otros, procedimientos y su respectiva documentación. En esta investigación se hace referencia a las herramientas

que ayudan a la gestión de requisitos; es decir al proceso de identificación, asignación y seguimiento de los mismos, incluyendo interfaz, verificación, modificación y control de cada requisito, durante el ciclo de vida del proyecto. Los cambios/ actualizaciones de requisitos deben ser gestionados para asegurar que se mantenga la calidad del producto.

Hasta hace poco tiempo las herramientas para la gestión de requisitos de software se limitaban a editores

de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones, como las que se mencionan a continuación:

1.-IRQA 43

Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el

proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor

y los distintos miembros del equipo de desarrollo. Facilita la captura, organización y análisis de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable

a cada cliente.

2.-RETO

Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema; básicamente, mediante tres técnicas complementarias entre sí: la definición de la Misión del Sistema,

la construcción del Árbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso.

Además, se introduce un Proceso de Análisis que permite traducir el Modelo de Requisitos en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y propiciando una representación de la información

en el segundo prototipo.

3.-CONTROLA

Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a

la expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren

un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes tales como: Administración

de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.

4.-OSRMT (Open SourceRequirements Management Tool)4

Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en arquitectura

cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los requisitos tratados.

5.-JEREMIA5

Se trata exclusivamente de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo del sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida. Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas. Implementa un módulo orientado a la generación de la documentación posible de exportar en formato DocBook XML, la cual junto con los requisitos, se almacena en una base de datos en MySQL.

6.-RAMBUTAN6

Esta herramienta está basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final, ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el lugar donde está ubicado el cliente mientras que la aplicación de escritorio recibe la información, edita y perfecciona. Ambas aplicaciones permiten al usuario introducir, modificar y visualizar los datos que componen un documento de especificación de requisitos.

Comparada con otras herramientas de gestión de requisitos, Rambutan ofrece las siguientes ventajas competitivas: Aplicación cliente para palm (PDAclass), portabilidad entre plataformas, es independiente de cualquier metodología de especificación de requisitos, y permite distribución libre.