INSTITUTO TECNOLÓGICO DE HUEJUTLA
CLAVE: 13DIT0001E
CARRERA:
INGENIERÍA EN SISTEMAS COMPUTACIONALES
NOMBRE DE LA MATERIA:
FUNDAMENTOS DE INGENIERÍA DE SOFTWARE
UNIDAD DE ESTUDIO:
UNIDAD 1 FUNDAMENTOS DE INGENIERÍA DE SOFTWARE
UNIDAD II INGENIERÍA DE REQUISITOS
UNIDAD III MODELOS DE ANÁLISIS
UNIDAD IV MODELO DE DISEÑO
UNIDAD V MODELOS DE IMPLEMENTACIÓN
NOMBRE DEL ALUMNO:
AMBROSIO ANTONIO MARTÍNEZ
SEMESTRE: V GRUPO: “A”
NOMBRE DEL DOCENTE:
MARÍA GUADALUPE RIVERA GARCÍA
FECHA DE ENTREGA:
MIÉRCOLES, 03 DE DICIEMBRE DEL 2014
UNIDAD 1 FUNDAMENTOS DE INGENIERÍA DE SOFTWARE
1.1 CONCEPTOS BÁSICOS
La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos (software).
Esta disciplina trasciende la actividad de programación, que es la actividad principal a la hora de crear un software. El ingeniero de software se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.
La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.
Cabe destacar que el proceso de desarrollo de software implica lo que se conoce como ciclo de vida del software, que está formado por cuatro etapas: concepción, elaboración, construcción y transición.
La concepción fija el alcance del proyecto y desarrolla el modelo de negocio; la elaboración define el plan del proyecto, detalla las características y fundamenta la arquitectura; la construcción es el desarrollo del producto; y la transición es la transferencia del producto terminado a los usuarios.
Una vez que se completa este ciclo, entra en juego el mantenimiento del software. Se trata de una fase de esta ingeniería donde se solucionan los errores descubiertos (muchas veces advertidos por los propios usuarios) y se incorporan actualizaciones para hacer frente a los nuevos requisitos. El proceso de mantenimiento incorpora además nuevos desarrollos, para permitir que el software pueda cumplir con una mayor cantidad de tareas.
Los Ingenieros de Software deben:
• Adoptar un enfoque sistemático para llevar a cabo su trabajo.
• Utilizar las herramientas y técnicas apropiadas para resolver el problema planteado, de acuerdo a las restricciones de desarrollo y a los recursos disponibles.
1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE
Hoy en día, el software tiene un papel dual. Es producto y canal de distribución de este. Como producto, ofrece la potencia de cómputo presentada como hardware de una computadora o, de manera más global por una red de computadoras accesible mediante hardware local y de acceso físico. Sin importar el lugar en que resida el software, ya sea en un celular o dentro de una computadora central, éste es un transformador de información; realiza la producción, el manejo, la adquisición, la modificación, el despliegue o la transmisión de la información que puede ser tan simple como un solo bit o tan compleja como una presentación multimedia. En su papel de vehículo para la entrega de un producto, el software actúa como la base para el control de la computadora (Sistemas Operativos), la comunicación de información (redes), y la relación y el control de otros programas (utilerías de software y ambientes).
PRIMERA ERA (1950 – 1965)
• Se trabajaba con la idea de “Codificar y Corregir”.
• No existía un planteamiento previo.
• No existía documentación de ningún tipo.
• Existencia de pocos métodos formales y pocos creyentes en ellos.
• Desarrollo a base de prueba y error.
SEGUNDA ERA (1965 – 1972)
• Se busca simplificar código.
• Aparición de Multiprogramación y Sistemas Multiusuarios.
• Sistemas de Tiempo Real apoyan la toma de decisiones.
• Aparición de Software como producto. (Casas de Software).
• Se buscan procedimientos para el desarrollo del Software.
TERCERA ERA (1972 – 1985)
• Nuevo Concepto: Sistemas Distribuidos.
• Complejidad en los Sistemas de Información.
• Aparecen: Redes de área local y global, y Comunicadores Digitales.
• Amplio Uso de Microprocesadores.
CUARTA ERA (1985 - 1995)
• Impacto Colectivo de Software.
• Aparecen: Redes de Información, Tecnologías Orientadas a Objetos.
• Aparecen: Redes Neuronales, Sistemas Expertos y SW de Inteligencia Artificial.
• La información como valor preponderante dentro de las Organizaciones.
QUINTA ERA (2000 hasta hoy en día)
Utiliza algunos requisitos de las eras anteriores solo que aumenta la omnipresencia de la web, la reutilización de información y componentes de software:
• Codificar: Transformar mediante las reglas de un código la formulación de un mensaje.
• Hardware: Componente físico de la computadora. Por ejemplo: el monitor, la impresora o el disco rígido. El hardware por sí mismo no hace que una máquina funcione.
• Multiprogramación: Se denomina multiprogramación a la técnica que permite que dos o más procesos ocupen la misma unidad de memoria principal y que sean ejecutados al "mismo tiempo“.
1.3 ETAPAS DEL DESARROLLO DEL SOFTWARE
Etapa de análisis: Es el proceso de investigar un problema que se quiere resolver. Definir claramente el Problema que se desea resolver o el sistema que se desea crear. Identificar los componentes principales que integrarán el producto.
Etapa de Diseño: Es el proceso de utilizar la información recolectada en la etapa de análisis al diseño del producto. La principal tarea de la etapa de diseño es desarrollar un modelo o las especificaciones para el producto o Componentes del Sistema.
Etapa de Desarrollo: Consiste en utilizar los modelos creados durante la etapa de diseño para crear los componentes del sistema.
Etapa de Pruebas o Verificación Prueba: Consiste en asegurar que los componentes individuales que integran al sistema o producto, cumplen con los requerimientos de la especificación creada durante la etapa de diseño.
Se recomienda aplicar las etapas:
• Análisis
• Diseño
• Desarrollo
• Prueba
A cada uno de los ejercicios de este curso.
Etapa de Implementación o Entrega Implantación: Consiste en poner a disposición del cliente el producto.
Etapa de Mantenimiento: Consiste en corregir problemas del producto y re- liberar el producto como una nueva versión o revisión (producto mejorado).
Etapa final EOL (End-of-Life) El fin del ciclo del producto consiste en realizar todas las tareas necesarias para asegurar que los clientes y los empleados están conscientes de que el producto ya no será vendido ni soportado.
1.4 CLASIFICACIÓN DE LA TECNOLOGÍA EN EL DESARROLLO DE SOFTWARE (TECNOLOGÍA ESTRUCTURADA Y ORIENTADA A OBJETOS)
Tecnologías de desarrollo estructurado
Las tecnologías de desarrollo estructurado son las más convencionales de las empleadas hoy día. Han surgido de la evolución de las ideas de programación estructurada (hace más de veinticinco años) hacia las fases iniciales del ciclo de vida. En su formulación actual, las notaciones empleadas en las prime-ras fases del ciclo de vida (especificación de requisitos de usuario y sistema)suelen estar constituidas por lenguajes gráficos que permiten: identificar el sistema y el entorno; representar el flujo de información entre los elementos; y, describir los datos y las actividades del sistema [12].La idea base de esta tecnología es que es posible estructurar el modelo de un sistema de software en base a funciones que procesan información que reciben de otras funciones (o del exterior) y dirigen la información procesada a otros módulos funcionales (o al exterior). El enfoque seguido, por tanto, es el de pensar en las funciones del sistema necesarias (extraídas de los requisitos del sistema) y luego en los datos que requieren.
Tecnologías orientadas a objetos
Las tecnologías de desarrollo estructurado han demostrado sus limitaciones a la hora de organizar y facilitar la evolución de sistemas de software complejos. La descomposición en funciones hace difícil al diseñador mantener la relación con los objetos del mundo real sobre los que se modifican generalmente los requisitos del usuario.
Los métodos de descomposición orientada a objetos constituyen la tendencia más influyente observada en la ingeniería de sistemas de software en los últimos años. Con ellos nos referimos a un conjunto de métodos (aún en fase de desarrollo o evolución) que permiten al analista diseñador concebir su sistema identificando clases de objetos, operaciones permitidas y relaciones entre ellos como base para la estructura del sistema a diseñar.
1.5 DEFINICIÓN E HISTORIA DE LAS HERRAMIENTAS CASE
¿Qué son las Herramientas CASE?
Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Como es sabido, los estados en el Ciclo de Vida de desarrollo de un Software son: Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.
CASE se define también como:
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.
La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas.
Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.
Historia de las Herramientas CASE
Las Herramientas CASE tienen su inicio con el simple procesador de palabras que fue usado para crear y manipular documentación. Los setentas vieron la introducción de técnicas gráficas y diagramas de flujo de estructuras de datos. Sobre este punto, el diseño y especificaciones en forma pictórica han sido extremadamente complejos y consumían mucho tiempo para realizar cambios.
La introducción de las herramientas CASE para ayudar en este proceso ha permitido que los diagramas puedan ser fácilmente creados y modificados, mejorando la calidad de los diseños de software. Los diccionarios de datos, un documento muy usado que mantiene los detalles de cada tipo de dato y los procesos dentro de un sistema, son el resultado directo de la llegada del diseño de flujo de datos y análisis estructural, hecho posible a través de las mejoras en las Herramientas CASE.
Pronto se reemplazaron los paquetes gráficos por paquetes especializados que habilitan la edición, actualización e impresión en múltiples versiones de diseño. Eventualmente, las herramientas gráficas integradas con diccionarios de base de datos para producir poderosos diseños y desarrollar herramientas, podrían sostener ciclos completos de diseño de documentos.
Como un paso final, la verificación de errores y generadores de casos de pruebas fueron incluidos para validar el diseño del software. Todos estos procesos pueden saberse integrados en una simple herramienta CASE que soporta todo el ciclo de desarrollo.
1.6 CLASIFICACIÓN DE LAS HERRAMIENTAS CASE
No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:
• Las plataformas que soportan.
• Las fases del ciclo de vida del desarrollo de sistemas que cubren.
• La arquitectura de las aplicaciones que producen.
• Su funcionalidad.
Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) ofront-end, orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) oback-end, dirigidas a las últimas fases del desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
UNIDAD II INGENIERÍA DE REQUISITOS
Definición: Requisito
Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.
Ingeniería de requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.
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.
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.
La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requisitos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante. Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto.
Tipos de Requerimientos
Los requerimientos de software pueden dividirse en 2 categorías: requerimientos funcionales y requerimientos no funcionales.
Requerimientos funcionales
Son los que definen las funciones que el sistema será capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.
Requerimientos no funcionales
Requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Características de un Requerimiento
Es importante no perder de vista que un requerimiento debe ser:
· Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
· Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe si se cumplió con él o no?
v Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
v Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
v Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
v No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.
2.1 TAREAS DE LA INGENIERÍA DE REQUISITOS
Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requisitos del sistema.
Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requisitos del sistema identificados hasta el momento.
Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.
Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir, verificar todos los requisitos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requisitos sean consistentes y que estén completos.
2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISITOS
Entrevistas y Cuestionarios
Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos.
Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.
Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él. El éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma.
Sistemas existentes
Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de información que se maneja y cómo es manejada, por otro lado también es útil analizar las distintas. Salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas.
Lluvia de ideas
Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea eso no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas.
Prototipos
Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no estén demasiado claros o que no se esté muy seguro de haber entendido correctamente los requerimientos.
Obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final.
Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.
El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo.
Casos de Uso
Los casos de uso son una técnica para especificar el comportamiento de un sistema.
“Un caso de uso es una secuencia de transacciones que son desarrolladas por un Sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas”
Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema.
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ía Objectory (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.
Se resume aquí:
ü 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.
ü 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.
ü 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.
ü Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación.
ü Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.
ü 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.
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 este post se hace referencia a 3 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:
IRQA
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.
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.
OSRMT (Open Source Requirements Management Tool)
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.
UNIDAD III MODELO DE ANÁLISIS
3.1 ARQUITECTURA DE CLASES
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Como se discutió en la introducción del libro, dependiendo del tipo de aplicación existen diversas arquitecturas que se pueden utilizar, siendo de nuestro interés aquellas arquitecturas especialmente diseñadas para el manejo de los sistemas de información, las cuales involucran ricas interfaces de usuario y accesos a base de datos como aspectos fundamentales de la arquitectura.
En término de las propias arquitecturas, éstas se distinguen según la organización de la funcionalidad que ofrecen los objetos dentro de ellas o la dimensión de los objetos. Esta dimensión corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de interfaces y base de datos, si existen tipos distintos de objetos para el manejo de cada una de estas por separado, entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que la arquitectura es de una sala dimensión.
Si aplicamos el concepto de dimensión a los métodos estructurados, podemos ver que estos consisten de dos dimensiones, correspondientes a funciones y datos. Las funciones representan un eje de comportamiento que no guarda información, mientras que los datos se ubican en un eje de información que no contiene comportamiento. En general, ejes de funcionalidad pueden corresponder a distintos tipos de funcionalidades, como se ve al contrastar funciones y datos versus manejo de interfaces y bases de datos. Sin embargo, la pregunta más importante que uno se hace respecto al número y tipo de dimensiones es: ¿Si se diseña un sistema con múltiples dimensiones, se obtendría un sistema más robusto y sensible a modificaciones? Ante todo esta pregunta se relaciona con el concepto de modularidad, siendo muy aceptado que cuanto mayor sea la modularidad de un sistema mayor es su robustez y extensibilidad.
En el caso de los sistemas de información, uno de las tipos de arquitecturas más importantes es la arquitectura MVC – Modelo, Vista, Control (Model, View, Control) popularizada por los ambientes de desarrollo de Smalltalk. Esta arquitectura se basa en tres dimensiones principales: Modeló (información), Vista (presentación) y Control (comportamiento) como se muestra en la Figura 7.2.
Figura 7.2 Diagrama de tres dimensiones correspondiente a la arquitectura MVC – Modelo, Vista, Control.
La vista o presentación de la información corresponde a las interfaces que se le presentan al usuario para el manejo de la información, donde por lo general pueden existir múltiples vistas sobre un mismo modelo. Típicamente la información representa el dominio del problema y es almacenada en una base de datos. Por otro lado el control corresponde a la manipulación de la información a través de sus diversas presentaciones. Y aunque existe cierta dependencia entre estas tres dimensiones se considera que la manera de presentar la información es independiente de la propia información y de cómo esta se controla. Sin embargo, cada una de ellas probablemente experimente cambios a lo largo de la vida del sistema, donde el control es el más propenso a ser modificado, seguido de la vista y finalmente el modelo. En el modelo de análisis descrito aquí utilizaremos como base la arquitectura MVC para capturar estos tres aspectos de la funcionalidad, como se muestra en la Figura 7.3.
Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo de requisitos. La razón de ser de las tres dimensiones del modelo de requisitos realmente se deriva para lograr una rastreabilidad con la arquitectura que se desarrollará en el modelo de análisis.
Figura 7.3 Diagrama de tres dimensiones correspondiente a la arquitectura del modelo de análisis basado en el modelo de casos de uso.
La arquitectura para el modelo de análisis será implementada mediante tres tipos o estereotipos de objetos como elementos básicos de desarrollo como veremos a continuación.
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 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 para objetos que implementen la presentación o vista correspondiente a las interfaces del sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos. Un ejemplo de un objeto interface es la funcionalidad de interface de usuario para insertar o modificar información sobre el registro de usuario.
El estereotipo control 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 interface. 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 interface específico.
Nótese que no hay ninguna restricción a los diferentes estereotipos que puedan utilizarse, no solamente las tres anteriores.
La notación de UML para un estereotipo se muestra en la Figura 7.4.
<< estereotipo >>
Nombre de la Clase
|
Figura 7.4 Diagrama de clase con estereotipo.
Los tres estereotipos correspondientes a las tres dimensiones para la arquitectura del modelo de análisis se muestran en la Figura 7.5.
Figura 7.5 Diagrama de clase para los tres estereotipo.
Considerando que habrá interacción entre los diferentes tipos de objetos, existirá cierto traslape en la funcionalidad que los objetos ofrecen. Como se mencionó anteriormente, este traslape deberá minimizarse para asegurar una buena extensibilidad, donde típicamente, cada tipo de objeto captura por lo menos dos de las tres dimensiones. Sin embargo, cada uno de ellos tiene cierta inclinación hacia una de estas dos dimensiones, como se muestra en la Figura 7.6.
Figura 7.6 Diagrama mostrando traslape en los estereotipos de los objetos. Clases para Casos de Uso
Cuando se trabaja en el desarrollo del modelo de análisis, normalmente se trabaja con un caso de uso a la vez. Para cada caso de uso se identifican los objetos necesarios para su implementación. Se identifican estos objetos según sus estereotipos para corresponder a la funcionalidad ofrecida en cada caso de uso. Se define explícitamente qué objeto es responsable de cual comportamiento dentro del caso de uso. Típicamente se toma un caso de uso y se comienza identificando los objetos interface necesarios, continuando con los objetos entidad y finalmente los objetos control. Este proceso se continúa a los demás casos de uso. Dado que los objetos son “ortogonales” a los casos de uso, en el sentido de que un objeto puede participar en varios casos de uso, este proceso es iterativo. Esto significa que cuando un conjunto de objetos ya existe, estos pueden modificarse para ajustarse al nuevo caso de uso. La meta es formar una arquitectura lo más estable posible, reutilizando el mayor número de objetos posible. De tal manera, la descripción original de los casos de uso se transforma a una descripción en base a los tres tipos de objetos, como se muestra en la Figura 7.7.
Figura 7.7 La funcionalidad de cada caso de uso es asignada a objetos distintos y de acuerdo a los estereotipos de dichos objetos.
Se parte el caso de uso de acuerdo a los siguientes principios:
La funcionalidad de los casos de uso que depende directamente de la interacción del sistema con el mundo externo se asigna a los objetos interface.
La funcionalidad relacionada con el almacenamiento y manejo de información del dominio del problema se asigna a los objetos entidad.
La funcionalidad específica a uno o varios casos de uso y que no se ponen naturalmente en ningún objeto interface o entidad se asigna a los objetos control. Típicamente se asigna a un sólo objeto control y si éste se vuelve muy complejo se asignan objetos control adicionales.
Por ejemplo, consideremos el caso de uso imprimir archivo, usado como ejemplo en el capítulo 6 y que se muestra nuevamente en la Figura 7.8.
Figura 7.8 Caso de uso imprimir archivo.
Para el caso de uso imprimir archivo se pueden utilizar los objetos (descritos según el diagrama de clases correspondiente) que se muestran en la Figura 7.9. Se utilizan dos clases interface: Interface Archivo e Interface Impresora, cinco clases entidad: Cola, Archivo con sus subclases Archivo Texto, Archivo Formateado y Archivo Gráfico y una clase control: Servidor Impresora.
Figura 7.9 Objetos identificados para el caso de uso imprimir archivo.
La arquitectura se completa generando asociaciones entre las distintas clases como se muestra en la Figura 7.10.
Figura 7.10 Objetos identificados para el caso de uso imprimir archivo mostrando asociaciones entre sí aunque omitiendo multiplicidad
El desafío para generar esta correspondencia entre objetos o clases y los casos de uso es precisamente decidir cuáles y cuantos objetos deben utilizarse en dicha correspondencia.
3.2 IDENTIFICACIÓN DE CLASES SEGÚN ESTEREOTIPOS
Para llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.
En general, los cambios más comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo a los objetos borde.
Los cambios a la funcionalidad son más difíciles de administrar, ya que ésta puede abarcar todos los tipos de objetos bordes.
Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a través de ellos se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentación comprensible para el actor.
Las clases borde en otras palabras, describen la comunicación bidireccional entre el sistema y los actores.
Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:
1. Se pueden identificar con base a los actores.
2. Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.
3. Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.
Estrategia correspondiente a los actores.
Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.
Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.
Clases entidad:
Validar Usuario: Este casi de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que se hace en la clase entidad Registro Usuario, utiliza también por el caso de uso Registro Usuario.
Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.
Registrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo que se hace en la clase entidad Registro Usuario.
Registrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad Registro Tarjeta.
Consultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones.
Hacer reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.
Pagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases entidad, sino más bien especificar cualquier clase adicional.
Control
En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.
3.3 CLASES
Los objetos se representan y agrupan en clases que son óptimas para reutilizarse y darles mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase.
Por ejemplo, los registros de los estudiantes en la sección de un curso almacenan información similar para cada estudiante. Se podría decir que los estudiantes constituyen una clase. Los valores podrían ser diferentes para cada estudiante, pero el tipo de información es el mismo.
Los programadores deben definir las diversas clases en el programa que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la clase establecida. El término instanciar se usa cuando un objeto se crea a partir de una clase.
Por ejemplo, un programa podría instanciar a un estudiante llamado Peter Wellington como un objeto de la clase denominada estudiante.
Lo que hace a la programación orientada a objetos, y por consiguiente al análisis y diseño orientado a objetos, diferente de la programación clásica, es la técnica de poner todos los atributos y métodos de un objeto en una estructura independiente, la propia clase. Ésta es una situación común en el mundo físico.
Por ejemplo, un paquete con harina para pastel empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para mezclar y hornear el pastel.
Un suéter de lana es similar a una clase porque incluye una etiqueta con instrucciones del cuidado que advierten que se debe lavarlo a mano y ponerlo a secar extendido. Cada clase debe tener un nombre que la distinga de todas las demás. Los nombres de clase normalmente son sustantivos o frases cortas y empiezan con una letra mayúscula.
En la figura 18.1 la clase se llama Renta Auto. En el UML, una clase se representa como un rectángulo. El rectángulo contiene otras dos características importantes: una lista de atributos y una serie de métodos. Estos elementos describen una clase, la unidad de análisis que es una parte principal de lo que llamamos análisis y diseño orientado a objetos.
Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la clase Renta Auto posee los atributos tamaño, color, marca y modelo. Todos los automóviles poseen estos atributos, pero los atributos de cada automóvil tendrán diferentes valores.
Por ejemplo, un automóvil puede ser azul, blanco o de algún otro color. Más adelante demostraremos que es posible ser rnás específico acerca del rango de valores para estas propiedades. Al especificar atributos, normalmente la primera letra es minúscula.
Un método es una acción que se puede solicitar a cualquier objeto de la clase. Los métodos son los procesos que una clase sabe cómo realizar. Los métodos también se llaman operaciones. La clase Renta Auto podría tener los siguientes métodos: inicio Renta ( ), entrega Auto f) y servicio ( ). Al especificar métodos, normalmente la primera letra es minúscula.
El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista 'business' del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos.
Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos.
Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria.
Figura 5: Diagrama de Secuencia para un escenario
Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la case instanciada por el objeto en la recepción final del mensaje.
Esta es la ultima etapa del modelo de análisis, en esta etapa se actualiza el diccionario de clases según módulos, originalmente descrito en el dominio del problema, aunque no es necesario ordenarlos por relevancia, a cada clase y caso de uso se le pueden asignar módulos adicionales, que estos a su vez pueden tener otros módulos o paquetes principales de importancia, estos ayudan a analizar de una mejor manera.
Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema.
Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema.
Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qué datos representan a la factura y al cheque.
Los dos son términos comunes en el mundo de los negocios y muchas personas conocen su significado.
Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripción de flujos de datos, almacenes de datos o procesos.
1. Borland Caliber Analyst
Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía Borland.
Por un lado está el Caliber DefineIT (la última de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema así como capturar los diferentes escenarios de negocio a través de diferentes herramientas visuales; es necesario señalar que este software es compatible con gran número de herramientas existentes en el mercado.
Por el otro está Caliber RM que nos permite gestionar dichos requisitos durante el ciclo de vida del producto, si bien no ayudaba al usuario a visualizar los requerimientos y por lo tanto no resultaba tan efectiva como ellos demandaban.
El paquete que incluye ambas aplicaciones nos permitirá realizar las siguientes tareas: representar y especificar los escenarios de manera visual, permitiendo el uso de un lenguaje común; generar diagramas de casos de pruebas y UML, mejorando tanto la velocidad como la exactitud de la definición de los requisitos; rastrear los requisitos software durante el ciclo de vida del proyecto, respondiendo de manera rápida a cualquier cambio que se produzca.
La compañía Seilevel Inc., una de las más fuertes en cuanto a los servicios relacionados con los requisitos del software, ha seleccionado esta herramienta como la mejor de este tipo. Según palabras de un directivo de la compañía ven características únicas en esta herramienta así como una experiencia de usuario excelente y una oportunidad para mejorar el trabajo de sus clientes en cuanto al análisis y gestión de requisitos se refiere.
2. CASE Spec
Esta herramienta está desarrollada por la empresa Goda Software, siendo esta una aplicación comercial de uso exclusivo para el sistema operativo Windows. Las principales características que avalan a esta herramienta son las siguientes:
Especificación: posibilidad de realizar las especificaciones tanto con las técnicas tradicionales como con los diagramas de casos de uso. Además, nos permite crear diagramas UML y de flujo de datos.
Seguimiento de los requisitos: a través del uso combinado de un procesador de textos y una hoja de cálculo, el usuario será capaz de realizar el seguimiento de los requisitos así como hacer un informe acerca de los mismos.
Capacidad de rastreo: mediante la existencia de una matriz se representan de manera sencilla las diferentes relaciones existentes entre los requisitos definidos y otra serie de elementos incidentes en el proyecto.
Capacidad de importar y exportar archivos.
Generación automática de la documentación del proyecto así como posibilidad de realizar amplios informes.
3. IRQA 4
Herramienta desarrollada por Visure y que tiene la meta de servir como aplicación para proporcionar un soporte integral en la ingeniería de requisitos de un proyecto de informática.
A parte de incluir las tareas más básicas de la ingeniería de requisitos (captura, análisis, modelado, organización y seguimiento), esta aplicación dispones de las siguientes características:
Reutilización de requisitos: permite que los requisitos definidos en un proyecto puedan ser utilizados en otros proyectos realizados por la organización, a través del uso de librerías. De esta manera se consigue ofertar una pequeña ventaja a la hora de realizar líneas de productos.
Vista documental: esta nueva opción ofrece un agrupamiento de los requisitos que permite al usuario observar una diferenciación clara entre los mismos así como facilitar toda labor relacionada con estos.
Ingeniería de requisitos: además de la gestión de los requisitos, esta aplicación proporciona funcionalidades relacionadas con la ingeniería de requisitos, lo que permite centralizar en una sola herramienta todas las actividades relacionadas con los requisitos (incluyendo las pruebas de validación y aceptación).
Al ser esta una herramienta integrada, se ofrece al usuario la libertad de seleccionar aquellas otras aplicaciones más adecuadas para la realización de otras tareas relacionadas con el ciclo de vida de un proyecto, lo que hace que no se dependa de un solo proveedor de aplicaciones.
4. Tiger Pro
Estamos ante una herramienta shareware desarrollada para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los defectos que aparecen a la hora de definir los requisitos de un programa. También ayuda al usuario a aclarar algunos de los requerimientos desde el punto de vista de las pruebas a realizar, señalando aquellos requerimientos cuya verificación pueda resultar complicada.
La herramienta, que se va actualizando con el paso del tiempo, permite exportar el trabajo realizado en archivos bajo el formato CSV.
Los usuarios que utilicen esta herramienta podrán trabajar en los requisitos tomando como referencia los siguientes conceptos: palabras claves relacionadas con el mismo (hasta 3 palabras para cada requisito), criterio de aceptación del requisito, seguimiento del mismo (tanto hacia la fuente como hacia otros lugares), prioridad del requerimiento, riesgo que trae consigo el requisito y coste del mismo. Además, a la hora de realizar los informes correspondientes, la herramienta nos proporcionará la opción de redactar los mismos en forma textual o bien nos presentará la información de forma gráfica.
5. GatherSpace
A la hora de realizar la definición de los requisitos para un proyecto de informática, el trabajo conjunto de todo el equipo de desarrollo es una parte fundamental para conseguir un buen resultado. Esta herramienta de definición y gestión de requisitos utiliza Internet como su lanzadera, ya que no es necesario instalar ningún programa para utilizarla: bastará con crear una cuenta en el sitio web de la misma y comenzar a definir el proyecto que se quiere desarrollar. De esta manera, la aplicación consigue que la colaboración de todos los miembros del grupo de desarrollo sea posible de una manera mucho más eficaz.
Las características más representativas de esta herramienta son las siguientes:
Creación de una jerarquía de requerimientos: permite crear paquetes funcionales para después relacionarlos con componentes de más alto nivel para después permitir asociar casos de uso más detallados y requisitos del software a dichos componentes.
Manipular varios proyectos al mismo tiempo, controlando el acceso de los usuarios para que estos puedan ver solo alguno de los proyectos.
Posibilidad de visualizar la documentación generada a partir de los requisitos en tres formatos diferentes: HTML, PDF y Microsoft Word.
Además de contar con todas estas opciones, la compañía ha dispuesto un buen sistema de seguridad que protegerá los datos introducidos en la herramienta.
Para asegurar la integridad del trabajo realizado se realizan copias de seguridad diaria de la información introducida en la herramienta y además existe la posibilidad de encriptar los datos introducidos en la misma. También es necesario señalar que el usuario podrá descargarse la información desde el servidor de la empresa tantas veces como le sea necesario.
6. IBM Rational RequisitePro
Esta herramienta, desarrollada por una de las compañías más importantes dentro del campo de la informática, se considera una de las herramientas más completas y potentes dentro del análisis y la gestión de los requisitos.
Una de las grandes ventajas que aporta este producto es la compatibilidad existente entre su software y algunos de los programas más utilizados. Por ejemplo, esta herramienta es capaz de comunicarse de manera muy eficiente con el Microsoft Word, de manera que la realización de los informes es más sencilla al tiempo que se ofrece al usuario una interfaz conocida para el desarrollo de su labor.
Además de esta compatibilidad, el programa también se comunica con gran eficiencia con algunos de los sistemas de bases de datos más utilizados en el mundo de la informática (DB2 de IBM, Microsoft SQL Server, Microsoft Access y Oracle) de manera tal que se controla el acceso a los datos existentes en el sistema al tiempo que se tiene un repositorio central de datos.
Por si esto no fuera suficiente, la comunicación entre la base de datos utilizada y el Microsoft Word permite al usuario gestionar los requisitos desde la base de datos seleccionada al tiempo que estos se mantienen dentro de su contexto en el procesador de textos.
Al igual que la herramienta estudiada anteriormente, Racional RequisitePro ofrece la posibilidad de trabajar mediante acceso Web.
De esta manera se logra tener tanto un acceso remoto como un acceso distribuido y además no se necesita que el software esté instalado en el cliente.
También es necesario mencionar que la herramienta dispone de una matriz de seguimiento de los requisitos (al igual que la herramienta CASE Spec); en este caso, dicha matriz puede representarse tanto de forma gráfica como de forma textual.
Además, en este caso se incorpora al seguimiento de los requisitos la existencia de un árbol de seguimiento global.
7. RaQuest
Se trata de la herramienta de gestión de requisitos desarrollada por la empresa Sparx Systems, desarrolladora también de la herramienta de análisis y modelado Enterprise Architect, utilizada en la Escuela.
Las características principales de esta herramienta son las siguientes:
Definición y gestión de los elementos relacionados con los requisitos, entre los que se encuentran el tipo, el estado, la dificultad del requisito, las relaciones existentes entre diferentes requisitos, etc.
Creación de paquetes para gestionar de manera más sencilla y completa los requisitos.
Generación de documentación del proyecto (tanto parcial como total) en los siguientes formatos: HTML, CSV, Word, Excel, RTF
Además de estas características, la herramienta nos ofrece una serie de vistas diferentes, dependiendo de la vista que queramos obtener del proyecto.
Estas vistas son: vista del tipo lista (permite ordenar los requisitos, mostrar diferentes listas, filtrar las listas en relación a diferentes palabras y buscar en el proyecto) y vista del tipo árbol (se pueden mostrar los árboles de proyecto y miembro así como mostrar los árboles por el tipo y por el estado).
Elección de la Herramienta a Utilizar
Debido a la gran compatibilidad existente con el Enterprise Architect, a la variedad de formatos para generar la documentación y a las numerosas opciones existentes en cuanto al tipo de vistas y la definición de los elementos relacionados con los requisitos, me he decantado por utilizar la herramienta RaQuest.
BIBLIOGRAFÍA
UNIDAD IV MODELO DE DISEÑO
4.1 Estrategias de diseño
El modelo de diseño es un refinamiento y formalización adicional del modelo del análisis, donde se toman en cuenta las consecuencias del ambiente de implementación. El resultado del modelo de diseño son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. El modelo de diseño se basa en el diseño por responsabilidades.
· Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficiente formal para alcanzar el código fuente. Por tal motivo se refinan los objetos, incluyendo las operaciones y atributos. Además se debe considerar aspectos como, los requisitos del rendimiento, tiempo real, concurrencia, lenguaje de programación, manejo de base de datos, etc.
· Otro objetivo del diseño es validar los resultados de los modelos de requisitos y análisis. Durante el diseño, se ve si los resultados anteriores son apropiados para la implementación. Si se descubren aspectos que no están claros en algunos de los modelos anteriores, estos se aclaran, posiblemente regresando a etapas anteriores.
· El modelo del diseño se considera como una formalización del espacio del análisis extendiéndolo para incluir una dimensión adicional que corresponde al ambiente de la implementación.
Esta nueva dimensión, corresponde al ambiente de implementación, se considera al mismo tiempo que se refina el modelo. La meta es refinarlo hasta que sea fácil escribir el código fuente. Como el modelo del análisis define la arquitectura general del sistema, se busca obtener una arquitectura detallada como resultado del modelo de diseño, de manera que haya una continuidad de refinamiento entre los dos modelos.
Un proyecto de diseño para tener un buen desarrollo debe tener una estructura en cuanto a la organización de cómo se va a llevar a cabo. Este desarrollo se va dividiendo en etapas lo que va a constituir la estructura. Entre esas etapas se encuentran:
Briefing, consiste en el primer contacto con el cliente para saber qué es lo que desea del proyecto, cuáles son sus expectativas, el ‘cómo’ porqué’ ‘cuanto’. Por lo tanto, se logra conocer al cliente y sus requerimientos y hacia dónde va dirigido o donde se quiere enfocar. Esto va a constituir un documento escrito donde se especifique qué es lo que quiere el cliente para saber qué es, específicamente, lo que hay que hacer. Es importante dejar claro todo para que después no haya ninguna confusión de lo que se hizo y lo que no se hizo o lo que se dijo o no se dijo.
Tabla Gantt o diagrama Gantt, es más bien una organización de cómo se va a trabajar en el proyecto. Por lo tanto, se van asignando tareas las cuales dependen del tiempo. Además, el tiempo debe ser pagado, así que se definen las horas hombre, lo que dice del costo de la utilidad.
Benchmark, teniendo en cuenta lo que el cliente quiere, visto en el brief, se van analizando los otros mercados, la competencia y se comparan. ¿Qué falta? Sin embargo, la idea no es copiarle a los otros, sino que dependiendo del cliente, estar a la altura de los demás o sobrepasarlos, pero para eso se debe tomar en cuenta qué recursos tienen que los hacen más populares.
Entrevista a los usuarios, principalmente, el usuario es a quien va dirigido el diseño por lo que es necesario saber lo que él piensa y sus expectativas, críticas, opiniones más que nada.
Modelos mentales y test, además de saber lo que piensa, es necesario saber cómo piensa, cómo estructura la información. Para eso hay varios test, donde se pone en juego distintas cosas como:
· La facilidad de encontrar las cosas, como links, información
· Que es lo primero que notan los usuarios al entrar en un sitio web
4.2 Diseño de objetos
Para los sistemas es posible definir un diseño en pirámide con las siguientes cuatro capas:
• Subsistema. Contiene una representación de cada uno de los subsistemas que le permiten al software conseguir los requisitos definidos por el cliente e implementar la infraestructura técnica que los soporta.
• Clases y Objetos. Contiene las jerarquías de clases que permiten crear el sistema utilizando generalizaciones y especializaciones mejor definidas incrementalmente. También contiene representaciones de diseño para cada objeto.
• Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con sus colaboradores. Establece las interfaces externas e internas para el sistema.
• Responsabilidades. Contiene las estructuras de datos y el diseño algorítmico para todos los atributos y operaciones de cada objeto.
Todo el programa está construido en base a diferentes componentes (Objetos), todo objeto del mundo real tiene 2 componentes: características y comportamiento.
Una clase es una plantilla genérica para un conjunto de objetos de similares características.
La herencia básicamente consiste en que una clase puede heredar sus variables y métodos a varias subclases.
Por ejemplo:
Los mensajes son invocaciones a los métodos de los objetos.
Esta es una técnica de diseño, la cual se caracteriza por la determinación y delegación de responsabilidades.
Análisis orientado a objetos
El modelo del análisis orientado a objetos ilustra información, funcionamiento y comportamiento.
El diseño orientado a objetos transforma el modelo del análisis en un modelo de diseño que sirve como anteproyecto para la construcción de software.
Modelos del diseño
• Estáticos. Estructura de subsistemas y/o clases y sus relaciones.
• Dinámicos. Se describen las estructuras que muestran la interacción entre objetos.
Ejemplos de UML: diagramas de secuencia, diagramas de estado.
Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.
Tipos: de creación, estructurales, de comportamiento.
4.3 Diseño de Sistemas
Diseño: El diseño es el proceso creativo de transformación del problema en una solución.
La solución será la que satisface todos los requerimientos planteados en la especificación de requerimientos, en muchos casos son ilimitadas.
Para transformar los requerimientos en un sistema que funcione, los diseñadores deben satisfacer tanto a los clientes como a los constructores de sistemas.
Los clientes deben comprender lo que el sistema debe hacer, y los constructores deben comprender cómo debe operar el sistema.
El diseño es un proceso iterativo que consta de dos partes: Diseño conceptual o del sistema, Diseño técnico.
Conceptual o del Sistema:
Se realiza primero, y le dice al cliente que es lo que hará realmente el sistema.
Una vez que se aprueba este diseño, se vuelca el trabajo a un trabajo de diseño más detallado.
El diseño conceptual describe el sistema en un lenguaje que el cliente pueda comprender, en lugar de usar términos técnicos o jergas de computación.
Un buen diseño conceptual debería tener las siguientes características:
• Se escribe en el lenguaje del cliente.
• No contiene expresiones de jerga técnica.
• Describe claramente las funciones del sistema.
• Es independiente de la implementación.
Está vinculado con los documentos del requerimiento.
Diseño Técnico:
Permite que los constructores comprendan el hardware y el software concretos que se necesitan para resolver el problema del cliente.
Es decir este diseño describe:
• La configuración de hardware.
• Las necesidades de software.
• Las interfaces de comunicación.
• Las entradas y salidas del sistema.
• La arquitectura de red.
• Y cualquier otro aspecto que incida en la transformación de los requerimientos en una solución.
• El diseño se describe en un único documento, pero muchas veces se vuelca en dos.
Ejemplo de Diseño Conceptual y Técnico:
4.4 Revisión del diseño
El proceso de revisión se realiza en tres etapas en correspondencia con los pasos del proceso de diseño:
1. Revisión del diseño preliminar.
2. Revisión crítica del diseño.
3. Revisión del diseño de programas.
Revisión del diseño preliminar:
Los clientes y usuarios se reúnen para validar el diseño conceptual.
Se asegura que todos los aspectos relativos a los requerimientos han sido apropiadamente contemplados en el diseño.
Se invita a participar a ciertas personas claves:
• Cliente (s), quien ayuda a definir los requerimientos del sistema.
• Analista (s), quien colabora para definir los requerimientos del sistema
• Usuario (s), potenciales del sistema.
• Diseñador (es) del sistema.
• Un moderador (solo coordina), un secretario (no se involucra).
• Otros desarrolladores (entregan perspectiva externa)
Durante la revisión se presenta a la audiencia el diseño conceptual. Al hacerlo, se demuestra que el sistema tiene la estructura requerida, las funciones y las características especificadas por los documentos de análisis.
Todos los participantes, en conjunto, verifican que el diseño propuesto incluya el hardware necesario, interfaces con otros sistemas, entradas y salidas.
Los clientes aprueban los diálogos y menús, los formatos de los informes y el tratamiento de defectos propuestos.
Revisión crítica del diseño:
Realiza una revisión crítica del diseño, donde se presenta una vista general del diseño técnico.
Integrantes:
• Analista (s), quien colabora para definir los requerimientos del sistema.
• Diseñador (es) del sistema.
• Un moderador (solo coordina), un secretario (no se involucra).
• Diseñador (es) de programas para este proyecto.
• Probador del sistema.
• Analista que escribirá la documentación del sistema.
• Otros desarrolladores (entregan perspectiva externa).
La revisión trata de aspectos técnicos.
El moderador conduce la reunión para que se traten dos puntos: si el diseño implementa todos los requerimientos y si es un diseño de calidad, usando diagramas, datos o ambas cosas, se explican las estrategias de diseño alternativa y como y porque se han tomado las principales decisiones de diseño, Si se identifican problemas mayores el diseño se rehace.
Revisión del diseño de programas:
Cuando el diseño técnico resulta satisfactorio, los diseñadores de programas estarán en posición de interpretarlo como el conjunto de descripciones de diseño para los componentes reales, que deben ser codificados y probados.
Después de completar los diseños de programas, pero antes de comenzar la codificación, presentan sus planes.
Integrantes:
• Analista (s), que produjeran los requerimientos del sistema.
• Diseñador (es) del sistema.
• Diseñador (es) del programa.
• Un moderador (solo coordina), un secretario (no se involucra).
• Diseñador (es) de programas para este proyecto.
• Probador del sistema.
• Analista que escribirá la documentación del sistema.
• Otros desarrolladores (entregan perspectiva externa).
Este proceso se centra en la detección de defectos más que en su corrección. Además se está evaluando el diseño no a los diseñadores.
El proceso beneficia a todos al encontrar defectos y problemas cuando aún son fáciles y poco costosos de corregir.
4.5 Diagramas de secuencia del diseño
Los casos de uso deben ser utilizados durante esta etapa, para describir el comportamiento dinámico del sistema, cualquiera de los diagramas de interacción del UML pueden ser utilizados. Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboración, utilizando diagramas de secuencia.
En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro programa y ponemos qué llamadas van haciendo unos a otros para realizar una tarea determinada.
Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que llamo subcaso de uso). En nuestro ejemplo de ajedrez, podemos hacer diagramas de secuencia para "jugar partida" o bien para partes de "jugar partida", como puede ser "mover pieza".
El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama y a quié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 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étdos van a implementar, que deben llamar de la clase del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de secuencia en el que sólo salga el actor "jugador" y una única clase "juego ajedrez" que representa nuestro programa completo, de forma que el cliente vea qué datos y en qué orden los tiene que meter en el programa y vea qué salidas y resultados le va a dar el programa.
El siguiente puede ser un diagrama de secuencia de nuestro ejemplo del ajedrez a un nivel de diseño muy preliminar
Aquí ya hemos decidido que vamos a hacer tres librerías/paquetes, 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. Hemos puesto una clase representando cada uno de los paquetes y hemos representado el caso de usa "mover pieza".
En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, etc) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difícil de leer. El diagrama puede acompañarse con un texto en el que se detallen todas estas situaciones erróneas y particularidades. Si se quiere dejar muy claro que un determinado error se contempla, por ejemplo, un movimiento no válido por el usuario, entonces sí se puede poner en el diagrama de secuencia, siempre que no "embarulle" demasiado.
En este diagrama sencillo ya vamos dejando algunas cosas claras, como por ejemplo, que la interface de usuario hace llamadas y, por tanto, ve a los otros dos, mientras que algoritmo sólo ve al tablero/reglas. El tablero/reglas aparentemente ve a la interface de usuario, pero no nos interesa si seguimos un patrón modelo-vista-controlador, así que ese "Refresca pantalla" lo implementaremos con un patrón observador, pero eso son detalles que quizás no vienen al caso ahora
4.6 Herramientas CASE para el diseño
Las herramientas de diseño, 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.
• 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).
El sistema experto podría incluir herramientas de diseño asistido por computadora (CAD) con el fin de materializar las expectativas de los clientes y las aptitudes de la empresa en el diseño final. Esto se lograría implementando una base de datos histórica (Data Warehouse) con referencias al desarrollo de otros filtros con el fin de comparar problemas, inconvenientes o ventajas que se tuvieron al desarrollar dichos productos. De igual forma, para la parte de los clientes se podría implementar una interfaz inteligente entre el sistema CAD y la base de datos del marketing que generara un diseño base del filtro que implicara las preferencias más significativas de los clientes. A partir de este diseño, los expertos de cada área podrían empezar a buscar un punto de balance entre lo que el cliente quiere y lo que más le conviene a la empresa para así obtener un diseño final de nuestro filtro.
• Producción.
• Ventas.
Ventajas de utilizar un Sistema Experto en la IC
Los sistemas expertos propician la efectividad de la empresa en todos sus departamentos, al automatizar algunas de las tareas de la empresa y al concentrar toda la información competente al proceso de desarrollo del producto. De esta forma podemos apreciar las siguientes ventajas al usar los sistemas expertos en la ingeniería concurrente lo que generalmente se conoce como ingeniería concurrente asistida por computadora (CACE):
• Información integrada. Este aspecto es el que persigue principalmente el sistema experto, pues se pretende juntar una gran cantidad de información que nos sirva de base para desarrollar nuestro producto. Esto promueve el hecho de que todos los participantes del equipo multidisciplinario tengan acceso a la información de los demás de manera previa, con el fin de que las juntas se lleven a cabo lo más rápido posible. La arquitectura del sistema experto podría diseñarse como una arquitectura cliente/servidor con el fin de que los participantes puedan acceder la información en cualquier momento e inclusive al mismo tiempo.
• Comunicación eficaz. La gran cantidad de información que se encuentra al alcance de los participantes del equipo, propicia que todos conozcan a cierto nivel el proceso de desarrollo visto desde el punto de vista cada departamento, con esto, se evitan discusiones sobre aspectos poco comprendidos en el proceso de diseño. Con el conocimiento general del proceso de desarrollo del producto, la comunicación se vuelve entonces más eficaz, pues cada participante conoce los inconvenientes y las ventajas que se tendrían para cada departamento en función de algún cambio en el diseño del producto.
• Rápida toma de decisiones. Con la información integrada en un solo núcleo y con la agilización de la comunicación entre los participantes del proyecto, se obtiene una aceleración en la toma de decisiones, producto de tener un equipo de expertos en cada área pero conocen y comprenden a las demás.
La Ingeniería Concurrente (IC) es una filosofía orientada a integrar sistemáticamente y en forma simultánea el diseño de productos y procesos, para que sean considerados desde un principio todos los elementos del ciclo de vida de un producto, desde la concepción inicial hasta su disposición final, pasando por la fabricación, la distribución y la venta. Debe otorgar además una organización flexible y bien estructurada, proponer redes de funciones apoyadas por tecnologías apropiadas y arquitecturas comunes de referencia (ejemplo: computadores en red y en bases de datos).
Retomando lo expuesto anteriormente la ingeniería concurrente es un esfuerzo sistemático para un diseño integrado, concurrente del producto y de su correspondiente proceso de fabricación y de servicio. Pretende que los desarrolladores, desde un principio, tengan en cuenta todos los elementos del ciclo de vida del producto, desde el diseño conceptual, hasta su disponibilidad incluyendo calidad, costo y necesidades de los clientes. Persigue un estudio sistemático, simultáneo, en el momento del desarrollo del producto, de las necesidades de mercado que va a cubrir, de los requisitos de calidad y costos, de los medios y métodos de fabricación, venta y servicio necesarios para garantizar la satisfacción del cliente.
Involucra el trabajo coordinado y simultáneo de los diversos departamentos de la empresa: Marketing, Ingeniería del Producto, Ingeniería del Proceso, Producción, Calidad, Ventas, Mantenimiento, Costos, etc.
La ingeniería concurrente sustituye el típico entorno de trabajo en el desarrollo y fabricación del producto basado en un diagrama secuencial de actuación de los distintos departamentos, por un trabajo concurrente, simultáneo, en equipo, de todos a partir del mismo momento en que se inicia el proceso.
BIBLIOGRAFÍA
http://ithuni4coronel.blogspot.mx/2013/05/41-estrategias-de-diseno.html
http://ithuni4coronel.blogspot.mx/2013/05/42-diseno-de-objetos.html
http://ithuni4coronel.blogspot.mx/2013/05/43-diseno-de-sistemas.html
http://ithuni4coronel.blogspot.mx/2013/05/44-revision-del-diseno.html
http://ithuni4coronel.blogspot.mx/2013/05/45-diagramas-de-secuencia-del-diseno.html
http://ithuni4coronel.blogspot.mx/2013/05/46-herramientas-case-para-el-diseño.html
UNIDAD V MODELO DE IMPLEMENTACIÓN
El Modelo de Implementación es comprendido por un conjunto de componentes y subsistemas que constituyen la composición física de la implementación del sistema. Entre los componentes podemos encontrar datos, archivos, ejecutables, código fuente y los directorios. Fundamentalmente, se describe la relación que existe desde los paquetes y clases del modelo de diseño a subsistemas y componentes físicos.
Un diagrama de implementación muestra:
Ø Las dependencias entre las partes de código del sistema (diagramas de componentes).
Ø La estructura del sistema en ejecución (diagrama de despliegue).
5.1 DIAGRAMAS DE COMPONENTES
Un componente es una parte física de un sistema (modulo, base de datos, programa ejecutable, etc.). Se puede decir que un componente es la materialización de una o más clases, porque una abstracción con atributos y métodos pueden ser implementados en los componentes.
Respecto a los componentes…
Ø Es implementado por una o más clases/objetos del sistema.
Ø Es una unidad autónoma que provee una o más interfaces.
Ø Las interfaces representan un contrato de servicios que el componente ofrece.
Los componentes pueden ser:
Ø Archivos
Ø Código fuente + Cabeceras
Ø Librerías compartidas (DLLs)
Ø Ejecutables
Ø Paquetes
Muestra como el sistema está dividido en componentes y las dependencias entre ellos.
· Proveen una vista arquitectónica de alto nivel del sistema.
· Ayuda a los desarrolladores a visualizar el camino de la implementación.
· Permite tomar decisiones respecto a las tareas de implementación y los Skills requeridos.
En un DC, un componente se representa con un rectángulo en el que se escribe su nombre y en él se muestran dos pequeños rectángulos al lado izquierdo. O también los siguientes:
Representación simple de un Componente
Elementos del Diagrama de Componentes
Normalmente los diagramas de Componentes contienen:
• Componentes
• Interfaces
• Relaciones de dependencia, generalización, asociación y realización
• Paquetes o subsistemas
Los componentes se pueden agrupar en paquetes así como los objetos en clases, además pueden haber entre ellos relaciones de dependencia como:
• Generalización
• Asociación
• Agregación
• Realización
Estereotipos de componentes
UML define cinco estereotipos estándar que se aplican en los componentes
Ø Executable, componente que se puede ejecutar
Ø Library, biblioteca de objetos estática o dinámica
Ø Table, Componentes que representa una tabla de base de datos
Ø File, componente que representa un documento que contiene código fuente o datos.
Ø Document, Comp. Que representa un documento.
¿Por qué utilizar un Diagrama de Componentes?
Ø Nos permite ver el modelado de un sistema o subsistema.
Ø Permite especificar un componente con interfaces bien definidas.
5.2 DIAGRAMAS DE DESPLIEGUE
El Diagrama de Despliegue es un diagrama que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.
Ø Permiten modelar la disposición física o topología de un sistema.
Ø Muestra el hardware usado y los componentes instalados en el hardware.
Ø Muestra las conexiones físicas entre el hardware y las relaciones entre componentes.
Usos que se les da a los diagramas de despliegue son para modelar:
· Sistemas cliente-servidor
· Sistemas completamente distribuidos
El elemento principal del diagrama son los NODOS.
Los nodos representan un recurso físico:
Ø Computadoras
Ø Sensores
Ø Impresoras
Ø Servidores
Ø Dispositivos externos
Los nodos pueden ser interconectados mediante líneas para describir una estructura de red.
Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento.
Estereotipo de nodo
Ø Estereotipo, son cosas u objetos q se repiten sin variación.
Ø El estereotipo de un nodo es la manera de poder verificar que tipo de nodo es el que se está observando.
Ejemplo Grafico
Se muestra número de estereotipos estándar, nombrados «cdrom»,«disk array», «pc client», «unix server». etc. Estos mostrarán un icono apropiado en la esquina derecha arriba del símbolo nodo.
Artefactos
Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso (modelos de Casos de Uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario etc.
Donde un artefacto es un conjunto de componentes.
Ejemplo Grafico
Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el estereotipo «artifact» y un icono de documento, como a continuación.
5.3 MODELOS DE PRUEBA
Objetivos de las pruebas
Ø Encontrar defectos en el software
Ø Una prueba tiene éxito si descubre un defecto
Ø Una prueba fracasa si hay defectos pero no los descubre
*Pruebas de Verificación
Ver si cumple las especificaciones de diseño
*Pruebas de Validación
Ver si cumple los requisitos del análisis.
El proceso de pruebas del software tiene dos objetivos:
1. Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.
2. Descubrir defectos en el software: que su comportamiento es incorrecto, no deseable o no cumple su especificación.
Pruebas de “caja blanca”
Pruebas en que se conoce el código a probar
Caja blanca (clear box: caja clara o transparente)
Se procura ejercitar cada elemento del código
Algunas clases de pruebas
Pruebas de cubrimiento
Pruebas de condiciones
Pruebas de bucles
Pruebas de “caja negra”
Pruebas en que se conoce sólo la interfaz
Caja negra (black box: caja opaca)
Se procura ejercitar cada elemento de la interfaz
Algunas clases de pruebas
Cubrimiento invocar todas las funciones (100%)
Clases de equivalencia de datos
Pruebas de valores límite
Estrategias de prueba del software
Ø Pruebas de unidades
Ø Pruebas de integración
Ø Pruebas de regresión
Ø Pruebas de validación
Pruebas de unidades:
Ø Se concentra en el esfuerzo de verificación de la unidad más pequeña del diseño del software: el componente o módulo del software.
Ø Las pruebas de unidad se concentran en la lógica del procesamiento interno.
Ø Este tipo de prueba se puede aplicar en paralelo a varios componentes.
Pruebas de integración:
Ø La prueba de integración es una técnica sistemática para construir la arquitectura del software, mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz.
Ø El objetivo es tomar componentes a los que se aplicó una prueba de unidad y construir una estructura de programa que determine el diseño.
Pruebas de regresión:
Ø La prueba de integración es una técnica sistemática para construir la arquitectura del software, mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz.
Ø El objetivo es tomar componentes a los que se aplicó una prueba de unidad y construir una estructura de programa que determine el diseño.
Pruebas de validación:
Ø Las pruebas de validación empiezan tras la culminación de la prueba de integración, cuando se han ejercitado los componentes individuales. Se ha terminado de ensamblar el software como paquete y se han descubierto y corregido los errores de interfaz.
Ø La prueba se concentra en las acciones visibles para el usuario y en la salida del sistema que éste puede reconocer.
BIBLIOGRAFÍA
entrada de Unknown @ 20:27
0 comentarios
