Modelos de Desarrollo de Software

Modelos Tradicionales e Iterativos

• Modelo Evolutivo

  
  

  Consiste en basarse en la descripción inicial para incrementar poco a poco (por versiones), empezando por versiones alpha (en construcción) iniciales, beta en desarrollo y finales en validación. Es interactivo y el cliente evalúa las novedades, pero puede generar problemas similares a la cascada.

• Modelo de Proceso Unificado (MPU)

  Creado por los autores del UML, se basa en diagramas que “construyen” la descripción del software, formando su arquitectura. Es iterativo e incremental. Consta de 4 fases:

  1. Inicio: Crea la descripción.
  2. Elaboración: Especifica la arquitectura y los casos de uso.
  3. Construcción: Genera el código.
  4. Transición: Se entrega al cliente y puede originar una nueva iteración.

  Sus ventajas son su flexibilidad al cambio, pero su desventaja es que está muy ligado a su arquitectura.

Modelos Ágiles

• Modelo Ágil

  Se basa en la impredecibilidad real de los requisitos y la planificación. Intercala diseño con desarrollo. Tiene una alta adaptabilidad, necesita retroalimentación del cliente y se basa en versiones (incrementos).

• Xtreme Programming (XP)

  Modelo iterativo de ciclos muy cortos, alta adaptabilidad, comunicación con el cliente, pruebas automatizadas, etc. El ciclo es: codificar, probar, evaluar, diseñar y repetir. Es útil para especificaciones cambiantes, pero poco útil en grandes proyectos o equipos.

• SCRUM

  Se basa en equipos de trabajo que se dedican a “hacer su parte”, una parte que ha sido acordada en una primera reunión diaria de 15 minutos en la que se coordinan los equipos, sus resultados y próximos objetivos.

Estructuras Organizacionales del Equipo

• Descentralizado Democrático (DD)

  No tiene un jefe permanente. Se nombra un jefe en función de cada tarea. Las decisiones, problemas y enfoques se llevan a consenso del grupo. La comunicación entre los miembros del equipo es horizontal.

• Descentralizado Controlado (DC)

  Tiene un jefe de equipo para las tareas y jefes secundarios para subtareas. La resolución de problemas se hace en grupo. El jefe de grupo distribuye la implementación de tareas entre los subgrupos. La comunicación entre subgrupos e individuos es horizontal. Hay comunicación vertical entre los jefes secundarios y el jefe de equipo.

• Centralizado Controlado (CC)

  Hay un único jefe de equipo. Este jefe resuelve los problemas a alto nivel y coordina el equipo. La comunicación es vertical entre el jefe y los miembros del equipo. Fue el primer organigrama que se empezó a aplicar.

Gestión de Riesgos en Proyectos de Software

Tipos de Riesgos

• Riesgos del Proyecto

  Amenazan el plan del proyecto. Si se materializan, aumentan el esfuerzo y/o coste. Identifican problemas potenciales en: Presupuesto, planificación, personal, recursos, participantes y requisitos.

• Riesgos Técnicos

  Amenazan la calidad del software. Aparecen cuando el sistema puede ser más difícil de lo esperado. Identifican problemas potenciales en: Requisitos, diseño, implementación, interfaz, verificación, mantenimiento, incertidumbre técnica y tecnologías desconocidas.

• Riesgos del Negocio

  Amenazan la viabilidad del proyecto. Identifican riesgos potenciales.

Estrategias de Gestión del Riesgo

• Gestión del Riesgo Reactiva

  Supervisa el proyecto en previsión de posibles riesgos. Se asignan recursos por si los riesgos se convierten en problemas. No se preocupa de los riesgos hasta que algo va mal. Cuando se falla, entra en acción la gestión de crisis. El proyecto se encuentra en riesgo real.

• Gestión del Riesgo Proactiva

  Comienza antes que los trabajos técnicos. Se identifican riesgos potenciales. Se evalúa su probabilidad y consecuencias. Se produce un plan de gestión del riesgo.

Estructura de Gestión de Riesgos (Probability/Impact)

Ejemplo de gestión de riesgo: Falta de experiencia desarrollando proyectos.

RISK, Probability/Impact: Lack of experience developing projects (
Identify
)

Plan de Contingencia (
Manage
):

1. Plan 1: EVITARLO. Hablar con algún experto para que nos enseñe.
2. Plan 2: REDUCIR EL IMPACTO. Revisar la planificación periódicamente para verificar si se está cumpliendo.

Planificación y Estimación de Proyectos

Planificación Temporal

Es una actividad que distribuye el esfuerzo estimado a lo largo de la duración prevista del proyecto, asignando el esfuerzo a las tareas de trabajo concretas. La planificación temporal no es estática, evoluciona con el tiempo.

El objetivo del gestor es:

• Definir las tareas de trabajo del proyecto.
• Identificar aquellas que son críticas.
• Hacer seguimiento de las tareas, con especial atención a las críticas.

El ciclo de gestión se resume en el acrónimo:

Planning (Planificación), Organizing (Organización), Monitoring (Monitorización), Adjusting (Ajuste).

Fórmulas de Estimación

Valor Esperado (VE):

$$VE = (V_o + 4V_m + V_p)/6$$

Cálculo de Esfuerzo y Coste:

$$EFFORT = \frac{424 \text{ (LOC)}}{65 \text{ (LOC/pm)}} = 65 \text{ (pm)}$$

$$COST = 65 \text{ (pm)} \times 780 \text{ (€/pm)} = 5070 \text{ (€)}$$

Donde LOC son Líneas de Código y pm son persona-mes.

Puntos de Función (Function Points – FP)

Los Function Points pueden usarse para estimar las LOC (Líneas de Código) dependiendo del número promedio de LOC por FP para un lenguaje dado.

$$LOC = AVC \times \text{número de function points}$$

Fundamentos de Ingeniería de Software y Requisitos

Definiciones Clave

• Ingeniería del Software

  Disciplina de ingeniería multicapa para la aplicación de métodos y herramientas que crean software fiable en máquinas reales (contando con sus restricciones), y que abarca todos los aspectos del mismo (especificación, mantenimiento, administración y gestión).

• Modelo de Proceso

  Un modelo de proceso, o paradigma de IS, es una plantilla, patrón o marco que define el proceso a través del cual se crea software.

• Actividades Estructurales

  Pueden ser: Comunicación con el cliente, Planificación, Análisis de riesgos, Ingeniería, Construcción y adaptación, y Evaluación por el cliente.

Requisitos del Sistema

Estructura típica de descripción de un caso de uso:

Description. Actors Involved. Actor’s Goal. Windows where takes places. Precondition. PostCondition. Basic Path. Alternative Path.

• Requisitos Funcionales

  Describen las funciones y respuestas del sistema ante distintos casos de uso.

• Requisitos No Funcionales

  Describen restricciones, a nivel de producto (tasa de fallos, memoria mínima), organizativo (lenguajes o procedimientos) o externos (legalidad o ética).

• Requisitos del Dominio

  Describen el entorno en que debe funcionar el sistema.

Pruebas de Software (Testing)

Las pruebas se hacen piramidalmente: primero se prueba cada elemento, luego cada módulo, cada subsistema, el sistema y finalmente se aceptaría el programa.

• Pruebas de Caja Negra: Se basan en la parte observable del sistema.
• Pruebas de Caja Blanca: Buscan comprobar (conociendo el diseño) todos los caminos y casos de prueba.