Ingenieria De Software

Definición Ing de Software

Aplicación de un enfoque sistemático, disciplinado y cuantificable, al desarrollo, operación y mantenimiento del software

Tipos de Procesos de Desarrollo

Proceso Tradicional (Modelo Secuencial)

Requerimientos-> Análisis -> Diseño -> Implementación -> Prueba

Contras del enfoque tradicional: Los errores los detecto al final

Proceso en cascada

R->A->D->I->P (1era iteracion)

R->A->D->I->P (2da iteracion)

R->A->D->I->P (... iteracion)

Proceso Iterativo e Incremental

Obtengo la naturaleza iterativa de la construcción de prototipos + los aspectos sistemáticos del modelo lineal secuencial.

En este esquema reviso siempre cada parte del proceso y a medida que va pasando el tiempo tengo que comprobar lo nuevo con lo anterior ya testeado

Producto Software

Def: Es una solución (Sistema informático) conformado por fuente, ejecutable, documentación y datos para que funcione.

Fuentes - Ejecutable

Documentación:

De la creación del software

Del usuario final

Datos necesarios para que funcione el software

El Software no se rompe en el sentido clásico, solo se tiene que ir renovando para seguir incrementando su usabilidad.

Unidad 1: El Proceso Unificado

Es un proceso de desarrollo de software.

Def: Un proceso de desarrollo de software son actividades necesarias para transformar los requisitos de un usuario en un sistema de software.

El proceso unificado esta:

1. Basado en componentes de software interconectados mediante interfaces

2. Utiliza el lenguage unificado de Modelado (UML)

El proceso unificado tiene 3 características principales:

1. Dirigido por casos de uso

2. Centrado en la Arquitectura

3. Iterativo e Incremental

1. Proceso dirigido por casos de uso

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado. Estos representan los requisitos funcionales ( me dice que debe hacer el sistema). Es un método para podar requerimientos (tomo lo que debe hacer el sistema realmente).

No tiene que haber un requisito funcional que no esté expresado en un caso de uso.

Todo el conjunto de casos de uso constituyen el Modelo de Casos de Uso.

Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hilo ( avanza a través de una serie de flujos de trabajos, siempre teniendo en cuenta a las funcionalidades requeridas plasmadas en los CUs).

2. Centrado en la Arquitectura

La Arquitectura es una vista parcial de los modelos (ej: modelo de casos de uso) que voy necesitando durante los flujos de trabajo, destacan las características más importantes, dejando de lado los detalles, es decir refleja el Esqueleto del sistema.

Las restricciones pueden formar nuevos requisitos, y los mismos requisitos, forman nueva arquitectura, dando una relación de ida y vuelta entre Arquitectura - Casos de uso. Es decir la arquitectura se ve alimentada por los Casos de uso más importantes y además la arquitectura debe permitir el desarrollo de los casos de uso. Ambos evolucionan en paralelo

Que esté centrado en la arquitectura significa que, siempre que trabajo en el proceso de desarrollo, tengo muy en cuenta la arquitectura, ya que las actividades se centran en ella.

3. Iterativo e Incremental

Es práctico dividir, el esfuerzo de desarrollo de un proyecto de SW, en mini proyectos para bajar su complejidad.

Cada miniproyecto es una iteración, que resulta en un incremento.

Las iteraciones hacen referencia a pasos por los flujos de trabajo (recorro todas las disciplinas, cumpliendo objetivos en cada una de ellas, dentro en una fase), y los incrementos a crecimientos en el producto.

Las iteraciones deben ser controladas, lo que significa que deben seleccionarse y ejecutarse de forma planificada.

Baso la selección de lo implementado en cada iteración en:

Conjunto de casos de uso que amplían la funcionalidad

Riesgos más importantes que deben mitigarse

En cada iteración:

1. Se identifican y especifican casos de uso relevantes

2. crean un diseño usando la arquitectura seleccionada como guía

3. implementan los casos de uso

Si la iteración cumple con sus objetivos, se continúa con la próxima, sino se revisan las decisiones previas y se busca un nuevo enfoque.

Ventajas del enfoque iterativo

Reducir el coste de riesgo a un solo incremento

Reducir el riesgo de retrasos, atacando los CUs más importantes

Acelerar el desarrollo de software

Los requisitos se van refinando en las iteraciones (no se pueden definir completos al inicio)

Vida del Proceso unificado

El proceso unificado se repite a lo largo de una serie de ciclos que conforman la vida de un sistema. Cada ciclo completo concluye con una versión de producto.

Cada ciclo consta de 4 fases:

Inicio: Determino el alcance del proyecto. si es viable construirlo con las herramientas que tenemos.

Elaboración: Planificar el proyecto, elaborar una arquitectura base para mi sistema.

Construcción: Construir el sistema (fase que mayor recursos implica)

Transición: Es la parte cuando el software esta instalado y funcionando.

Cada fase tiene n iteraciones, donde se van cumpliendo distintos objetivos de la fase

En cada iteración, se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos ( Req,An,Dis,Imp,Pru).

Cada fase finaliza con un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos, es decir un conjunto de modelos o documentos que han sido desarrollados hasta alcanzar un estado predefinido.

Los hitos tienen muchos objetivos dentro asociados a los distintos flujos de trabajos. Estos también permiten controlar la dirección y el progreso del trabajo.

Fase de Inicio

Durante la fase de inicio se desarrolla una descripción del producto final y se presenta el análisis de negocio. Además se identifican y priorizan los riesgos más importantes

La fase de inicio finaliza con el hito de objetivos del ciclo de vida.

Fase de Elaboración

Se especifican en detalle la mayoría de los CUs y se diseña la arquitectura. El resultado de esta fase es la línea base de la arquitectura.

Finaliza con el hito de la arquitectura del ciclo de vida.

Fase de Construcción

En la construcción se crea el producto. La línea base de la arquitectura crece hasta convertirse en el sistema completo. El producto tiene todos los CUs implementados, puede que haya defectos.

Finaliza con el hito de capacidad operativa inicial

Fase de Transición

La fase de transición es el periodo en el cual el producto se convierte en versión beta. Las iteraciones siguen agregando características al SW.

Finaliza con el hito de lanzamiento de producto.

Disciplinas o Flujos de Trabajo

Cada disciplina es un conjunto de actividades relacionadas, vinculadas a un área especifica dentro del proyecto total.

Los más importantes son: Requerimientos, Análisis, Diseño, Implementación y Prueba

Este agrupamiento es una ayuda para comprender el proyecto desde la visión tradicional en cascada.

Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos.

Def. Artefactos: Es cualquier cosa que se genere o modifique durante el proceso de desarrollo. Ej: actor, diagrama, modelo, clase, etc.

Los artefactos más importantes son los modelos que cada disciplina realiza:

modelo de casos de uso

modelo de análisis

modelo de diseño

modelo de implementación

modelo de prueba

Producto

Incluye todos los artefactos ( codigo fuente, manuales, requisitos, casos de usos, casos de prueba, interfaces, UML, arquitectura, etc).

Modelo de Casos de uso: todos los casos de usos y su relación con los usuarios.

Modelo de Análisis: Refina los casos de uso con más detalle y establece la asignación inicial de funcionalidad de sistema.

Modelo de Diseño: define la estructura en forma de subsistemas, clases, interfaces, etc.

Modelo de implementación: Incluye los componentes que representan el código fuente.

Modelo de Prueba: casos de prueba que verifican los casos de uso.

Representación de Arquitectura.

Todos estos modelos están relacionados mediante trazas. Las trazas son dependencias hacia atrás y adelante entre partes en los distintos modelos.

Unidad 2: Persona - Proyecto - Producto - Proceso

Persona: Principal actor de un proyecto de software (Desarrollador, ing. en pruebas, usuarios, clientes, arquitectura, etc), son seres humanos.

Proyecto: Elemento organizativo a través del cual se gestiona el desarrollo de software. El resultado es una versión de un producto.

Producto: Artefacto que se crea durante la vida del proyecto (modelos, código fuente, documentación, etc).

...