Datos personales

Mi foto
http://es.linkedin.com/in/raulgarciacarretero

16 de noviembre de 2010

MIB (16/11/2010): FASES Y MODELOS DE UN PROYECTO DE DESARROLLO

Hilando con el punto en el que acabó la sesión de ayer y partiendo de la premisa de que la ingeniería del software es una disciplina que ofrece técnicas para desarrollar software de calidad, Marcelo Royán nos ha introducido hoy las fases de un proyecto de desarrollo en las que el equipo CLIENTE debe estar obligatoriamente presente (en todas y cada una de ellas):
  • Análisis de requisitos – se corresponde con el MRD, depende del equipo CLIENTE y las líneas maestras las establece el Project Owner.
  • Análisis funcional – describe con detalle el comportamiento del sitio Web una vez desarrollado ante cada una de las situaciones que se puedan presentar. Es la respuesta del equipo PROVEEDOR a lo que le entrega el CLIENTE. La responsabilidad recae principalmente en Expertos Funcionales y Consultores.
  • Documento de especificaciones técnicas – describe las características técnicas de la aplicación en todos sus aspectos.
  • Programación.
  • Pruebas – es fundamental realizar baterías de tests y en el entorno que vaya a ser el de producción.
  • Documentación – la hay de dos tipos: técnica (cómo funciona la Web) y funcional (cómo se ha programado). Es muy importante que en la funcional los programadores hagan comentarios al código para facilitar actualizaciones y evoluciones futuras.
  • Mantenimiento y evolución – mantener y mejorar el software para solventar errores y desarrollar nuevos requisitos.
Vistas y analizadas en profundidad cada una de las fases anteriores, nos hemos adentrado en los modelos de desarrollo de software, los cuales pueden definirse como un paradigma que se sigue en el proceso de desarrollo de software y cuyas dos modalidades más empleadas son el modelo en cascada y el modelo iterativo.
  1. En cascada: se basa en un enfoque metodológico que ordena rigurosamente las etapas del ciclo del software. El problema principal es que el paradigma es excesivamente lineal, por lo que cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo.
  2. Iterativo: se creó para cubrir las carencias del modelo en cascada a fin de flexibilizar la interacción entre pruebas y desarrollo. La idea que subyace bajo este modelo es desarrollar de forma incremental diferentes versiones entregables de la aplicación.
Con esto hemos cubierto una parte importante de la teoría y ahora estamos en disposición de "bajar a la tierra" y empezar a poner todos estos conceptos en práctica


Hasta mañana.

No hay comentarios: