INGENIERIA DE SOFTWARE RESUMEN 2

Ciclo de Vida del Software

Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.

Definición de un Modelo de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software.

Define las fases primarias esperadas de ser ejecutadas durante esas fases.

Ayuda a administrar el progreso del desarrollo, y

Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Modelo Cascada

Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfacción de metas de esa fase o quizás a una sub secuencia de metas de la fase. El modelo de ciclo de vida cascada, captura algunos principios básicos:

Planear un proyecto antes de embarcarse en él.

Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.

Documentar los resultados de cada actividad.

Diseñar un sistema antes de codificarlo.

Testear un sistema después de construirlo.

Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.

Modelo De Desarrollo Incremental

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros

aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.

Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.

Si un error importante es realizado, sólo la última iteración necesita ser descartada.

Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.

Si un error importante es realizado, el incremento previo puede ser usado.

Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo De Desarrollo Evolutivo (prototipado)

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.

El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.

Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún

incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.

Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.

El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.

Modelo Espiral

El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:

Determinar qué quieres lograr.

Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.

Seguir la alternativa seleccionada en el paso 2.

Establecer qué tienes terminado.

El modelo espiral captura algunos principios básicos:

Decidir qué problema se quiere resolver antes de viajar a resolverlo.

Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.

Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.

No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y

Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible.

Ingeniería de Requisitos, es el proceso de desarrollar una especificación de Software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. Trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.

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 las partes interesadas, que pueden entrar en conflicto entre ellos.

Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones.

La ingeniería de requisitos es el conjunto de actividades y tareas del proceso de desarrollo de sistemas software que tiene como objetivos:

Definir, con la mejor calidad posible, las características de un sistema software que satisfaga las necesidades de negocio de clientes y usuarios y que se integre con éxito en el entorno en el que se explote. La definición de dicho sistema se realiza mediante lo que se conoce como una especificación de requisitos.

Gestionar las líneas base y las peticiones de cambios que se vayan produciendo en la especificación de requisitos, manteniendo la trazabilidad entre los requisitos y otros productos del desarrollo.

Los principales beneficios que se obtienen de la Ingeniería de Requisitos son:

Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la Ingeniería de Requisitos consiste de una serie de pasos organizados y bien definidos.

Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La Ingeniería de Requisitos proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la Especificación de Requisitos.

Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requisitos, Funcionalidades, Facilidad de Uso, Confiabilidad Desempeño.

Mejora la comunicación entre equipos: La especificación de requisitos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

Evita rechazos de usuarios finales: La Ingeniería de Requisitos obliga al cliente a considerar sus requisitos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Existen cuatro actividades básicas (extracción, análisis, especificación y validación) que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene, para el desarrollo de un proyecto de software, realizar una especificación y administración adecuada de los requisitos de los clientes o usuarios.

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. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requisitos; aquí se leen los requisitos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requisitos.

Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, pero se podría decir que la Especificación es el “pasar en limpio” el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML.

Validación: La validación es la etapa final de la IR. Su objetivo es 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.

La validación representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se está haciendo, y externo, porque se debe validar con el cliente.

Existen diversas técnicas y herramientas que se utilizan para llevar a cabo cada una de las actividades del proceso de Ingeniería de Requisitos, una de las razones por las cuales surgen los errores a la hora del levantamiento es la existencia de una gama de herramientas. No existe una especie de guía para el uso de los desarrolladores, estos utilizan incluso en la captura más de una técnica en cada una de las actividades que contiene el proceso.

Herramientas Extracción Análisis Especificación Validación

Entrevistas y Cuestionario X

Sistemas Existentes X X

Grabaciones de video y de audio. X X

Brainstorming (Tormenta de Ideas) X X

Sistemas Existentes X X

Arqueología de Documentos X X

Aprendiz X

Observación X

Run Use Case WorkShop X

Prototipo Bosquejado X X X

Prototipo Tangible/usable X X X

FODA X

Cadena de Valor X

Modelo de clase conceptual X X

Diagrama de actividad X X

ESRE X X X X

Casos de uso X X X X

Casa de calidad o QFD X

Checklist X X

Herramientas más 0055sadas

Entrevistas y cuestionarios: Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o grupos, información que se obtiene conversando con el encuestado. Las preguntas suelen distinguirse en dos categorías: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminología, mientras que las preguntas cerradas predeterminan todas las posibles respuestas y el interrogado elige entre las opciones presentadas.

Grabaciones de video y de audio: Básicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algún proceso en particular. En cuanto a su función de apoyo, es importante porque permite centrar la atención en la entrevista en sí, en vez de distraerse tomando notas de todo lo que se dice. Cuando se trata de analizar algún proceso en particular, su ayuda es inestimable (sobre todo las filmaciones de video) porque permite ver y analizar en detalle ese proceso la cantidad de veces que sea necesario.

Brainstorming (tormenta 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 requisitos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable.