Modelos de desarrollo de software y gestión de riesgos

Modelos de desarrollo de software

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: 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: inicio (crea la descripción), elaboración (especificar arquitectura y casos de uso), construcción (generar código) y 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.

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: modelo iterativo de ciclos muy cortos, alta adaptabilidad, comunicación con el cliente, pruebas automatizadas… Es codificar, probar, evaluar, diseñar y repetir. Ú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”, un parte que ha sido acordada en una primera reunión diaria de 15 mns en la que se coordinan los equipos, sus resultados y próximos objetivos.

Gestión de riesgos

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. Tiene 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 la coordinación del equipo. Comunicación vertical entre el jefe y los miembros del equipo. Fue el primer organigrama que se empezó a aplicar.

Gestión de riesgos del proyecto

Riesgos del proyecto: amenazan al plan del proyecto. Si se hacen reales aumenta 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.

Planificación temporal y gestión de riesgos

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.

POAM: Planning Organizing Monitoring Adjusting

Gestión de riesgos 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 de riesgos 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.

Otros conceptos

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

Ingeniería del Software: disciplina de ingeniería multicapa para aplicación de métodos y herramientas que creen 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).

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). Los requisitos del dominio describen el entorno en que debe funcionar el sistema.

Pruebas de software: se hacen piramidalmente, primero se prueba cada elemento, luego cada módulo, cada subsistema, sistema y finalmente se aceptaría el programa. Las pruebas de caja negra se basan en la parte observable del sistema, las de caja blanca busca comprobar (conociendo el diseño) todos los caminos y casos de prueba.