La ingeniería del software es el estudio de las técnicas y de la teoría que subyacen al desarrollo de software de alta calidad.

Objetivos

• Resolver el problema correcto
  • Comprender los detalles del problema
  • Analizar el problema y desarrollar un conjunto completo y preciso de requisitos
• Entregar una solución a tiempo y dentro del presupuesto
• Entregar una solución de alta calidad que satisfaga a cliente y usuarios

Metodología Software

• Metodología: “conjunto de métodos, reglas y postulados utilizados por una disciplina”
• En Software hace referencia a la organización del propio proceso de desarrollo

Existen numerosas metodologías, y casi todas tienen en común:

• División en etapas: cada una compuesta de flujos de trabajos
• Flujos de trabajo: compuesto por actividades específicas
• Personal: persona que realiza una actividad
• Actividades: tareas en las que intervienen personal y artefactos
• Artefactos: información generada por una actividad (documentos, diagramas, e incluso un sistema)

Un modelo del ciclo de desarrollo define el proceso que hay que seguir durante el desarrollo

Todos los modelos del ciclo de desarrollo contemplan las cuestiones fundamentales del análisis, el diseño, la implementación y la evaluación

• El proceso de análisis implica la especificación del problema
• El proceso de diseño implica la especificación de una solución
• Implementación: implica transformar el diseño en un sistema funcional
• Evaluación: implica verificar que el sistema creado se ajusta a las especificaciones descritas durante el proceso de análisis.

Flujos de trabajo en el DSOO

• Captura de requisitos
• Análisis
• Arquitectura
• Diseño
• Implementación
• Prueba
• Implantación
• (Mantenimiento)

Análisis OO

• Investigación del problema
• Encontrar y describir los objetos (o conceptos) en el dominio del problema
• Ejemplo de una biblioteca: libro, socio,…

Diseño OO

• Solución del problema
• Definición de los objetos software y su colaboración
• Los diseños se implementan en un lenguaje
• Ejemplo: Objeto Libro, atributo título, método obtenerCapitulo.

Es el proceso de planificar cómo resolver un problema mediante el software. El diseño contiene información suficiente para que el equipo de desarrollo implemente la solución. Es el anteproyecto de la solución software

¿Qué se considera un buen diseño?

• Fácil de entender
• Fácil de cambiar → flexible
• Satisface los requisitos

En general, los modelos se construyen para averiguar si algo funcionará.

¿Por qué construir modelos de software?

¿Por qué se deben construir diseños comprensibles antes de codificar?

Los modelos permiten:

• Visualizar sistemas nuevos o ya existentes
• Comunicar decisiones a los intervinientes del proyecto
• Documentar las decisiones realizadas en los flujo de trabajo
• Especificar la estructura y el comportamiento de los elementos de un sistema
• Utilizar una plantilla para construir la solución software.

(UML)

• Notación gráfica para dibujar diagramas de conceptos del software.
• Fowler describe tres niveles: conceptual, especificación e implementación.
• Los diagramas de especificación e implementación tienen una conexión fuerte con el código fuente. Poca ambigüedad.
• Los diagramas en el nivel conceptual no están tan fuertemente relacionados con el código. Los diagramas son muy útiles para comunicarse con los demás y resolver los problemas de diseño.
• Recargar un diagrama con cantidades de adornos es posible pero contraproducente.
• Mantén tus diagramas sencillos y claros.
• Los diagramas no son código fuente y no deben ser considerados como el lugar para declarar cualquier método, variable o relación.

UML define una notación que se expresa como diagramas y sirven para representar modelos/subsistemas o partes de ellos

• El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML
• UML es una herramienta, no un fin en sí mismo. Ayuda a pensar un los diseños y a comunicarlos.
• Refinamiento de los diagramas de manera iterativa

Desarrollo Iterativo

Hacer todo en iteraciones cortas (ej. ciclos de 2 semanas), cada uno comienza con un plan y finaliza con una entrega

La exploración inicial:

• No acaba en código.
• Responsable de los requisitos y las prioridades.
• Alcance del sistema.
• Casos de uso.

Estimar las características:

• Estimamos cada CU o historia de usuario. Tener en cuenta la estimación de historias ya implementadas, en otro caso, usar los días de programación perfectos.

Sondeos:

• Calibrar nuestras estimaciones. Velocidad inicial del equipo.

Planificación

• Utilizar la velocidad actual para suponer qué historias se completarán en cada iteración,

Planificar entregas:

• Comenzamos con la 1ª entrega. 6 iteraciones por la velocidad (25) hacen 150 puntos de historias.
• El cliente elige las más importantes para su negocio.

Planificar iteraciones:

• El primer día de cada iteración se puede crear un plan.
• Trocear las historias en tareas (4-10 hh). El cliente nos ayuda a realizar esta división contándonos los detalles completos de la historia.
• Cada desarrollador se hace un presupuesto de tareas.

A medio camino:

• Evaluar lo que se lleva hecho y modificaremos la planificación con el cliente.

Realimentación de velocidad:

• Al final de cada ciclo recalculamos nuestra velocidad, de manera que se ajusten el número de puntos de historia para la siguiente iteración.