Modelos y Metodologias para desarrollo de proyectos en informática

Para los lectores de este Blog, los invito a iniciar un pequeño debate sobre modelos y metodologías para la Ingeniería de Software, basados en los conocimientos adquiridor por mi en el ramo de lenguajes y métodos de programación y un poco de Wikipedia. Este primer post, lo realizare en base a los modelo y metodologías más usadas. No duden en mandar comentarios o si ven algo catastroficamente mal :-P

Modelos de Desarrollo de Software

Como definición de modelo, podemos decir que es un esquema o una estructura que nos indica cuales son los pasos a seguir dentro del ciclo de vida de una aplicación. Sin embargo no nos dice que limites tiene cada uno de los pasos, ni que se debe cumplir para pasar de uno a otro, o al siguiente.

Faces en el Desarrollo de Software

Es el también llamado ciclo de vida del software, y cuenta con las siguientes faces:

  • Análisis de requisitos : Esta es la fase inicial del desarrollo, y según muchos, la más importante, ya que en base a estos requerimientos se construirá el proyecto. Se genera un documento llamado SDR(Documento de Especificación de Requisitos), que contiene todos los requisitos del sistema, y que, en general, deben ser resultado de mutuo acuerdo entre el desarrollador y el cliente, y firmado por ambos. Existen dos tipos de requerimientos:
    • Requerimientos funcionales: son parte intima del programa y reflejan las reglas del negocio para el cual el sistema va a conocer y manejar. Van también a depender de que importancia le de el cliente a cada requerimiento. Ejemplo de este tipo de requerimiento es, en el caso de un mantenedor de alumnos, que si la nota final es menor o igual a un 3,95 el alumno reprueba, o en el caso de un programa para un supermercado, que se envíe mensualmente un informe a la sucursal central, con cierta información. Son las reglas del negocio en si.
    • Requerimientos no funcionales : son aquellos en los que no se depende del sistema para poder definirlos, y no pertenecen a la regla del negocio. Ejemplo clásico es si la aplicación va a correr sobre una plataforma software y/o hardware específica o, dependiendo del enfoque que exija el cliente, los colores institusionales, formatos de informes o documentos generados por el sistema.
  • Diseño del sistema : Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Esta parte no fue vista en clases, apreciando que es aplicable solo para un grupo de desarrolladores. Cuando son dos o tres personas, no es necesario hacer tal documento, pero si tratar de que todos entiendan el sistema como un todo y como interactúan sus partes.
  • Diseño del programa : Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación. Aquí se decide la manera vamos a reflejar cada uno de los requerimientos en piezas de software, con que lenguaje y/o plataforma y/o framework.
  • Codificación : Es la fase de programación propiamente dicha. Aquí se desarrolla el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido. Aquí implementamos el código planteado en la fase anterior, y según nuestro modelo, metodología o proceso de desarrollo, será cuanto avancemos, como haremos la documentación, y en base a que documentos basaremos nuestro trabajo.
  • Pruebas o Tests : En base a la primera fase, se elaboran, tanto los "casos de uso" como "casos de prueba", los cuales evaluaran si cada pieza de software realiza lo indicado por las reglas del negocio, y dependiendo, generara mas documentación para evaluar el avance.
  • Implementación : El software obtenido se pone en producción. Se implementan los niveles software y hardware que componen el proyecto. La implementación es la fase que dura más y con más cambios en el ciclo de elaboración de un proyecto. Este paso debe manejarse con mucho cuidado, y dependiendo del modelo, hacer diferentes implementaciones, para pasarlas finalmente a producción.
  • Mantenimiento : Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios. Esta fase tampoco fue mencionada en clases, y es de suma importancia, a parte de ser nuestro sueldo por lo que dure el software, o que nos cambien por otro equipo, es la parte de soporte que se entregara al cliente en el caso que quiera hacer un cambio al sistema, o se pardusca un cambio en las reglas del negocio.
Hay otras faces que, dependiendo del modelo, metodología o proceso de desarrollo van a cambiar, con lo que pueden haber unas mas u otras menos. De todas maneras, nada es estricto, y menos aun en la practica.

Nótese además que cada fase, opcionalmente, va acompañada con documentación, cosa que queda mas explicita en las Metodologías, siendo mas estrictas que los modelos en todos los aspectos.

El Modelo Lineal o en Cascada

Este modelo, como su nombre lo indica, y requiere terminar una fase completa para pasar a la siguiente, dejando nula posibilidad de volver atrás, por lo que hay que empezar de nuevo. Esto implica de que si empezamos a desarrollar un software con este modelo, una vez terminado, en el caso de tener algún problema en la ultima etapa, no podemos hacer cambios directamente en la ultima fase, y hay que volver al principio y hacer todo nuevamente, y dependiendo de la metodología, quizás esto sea muy engorroso, sobre todo cuando se pide mucha documentación. En lo personal, no creo que exista algún proyecto de software que sea tan riguroso como para no poder modificarlo directamente en las ultimas etapas del desarrollo, pero en la teoría así es la cosa.

El Modelo Iterativo, de Aproximación o Incremantal

Este es muy diferente al anterior, ya que iniciamos nuestro desarrollo, pasando por todas las etapas, pero no completamos ninguna, y solo avanzamos un cierto porcentaje. Una ves terminado, volvemos al principio pero debemos regresar al inició para seguir desarrollando. En la primera iteración no hay problemas en que el software no este listo, ni si quiera en la segunda, ya que cada ves que hacemos una iteración, implementamos nuevas funcionalidades del software final, corregimos y vemos como le parece al cliente, refinando más nuestro producto final, hasta la ultima iteración, en donde se realiza la entrega al cliente, para poder pasarlo a producción.

De estos dos modelos, decienden todos los submodelos, metodologias y submetodologias que conocemos.

Metodologías de Desarrollo

A diferencia de los modelos, las metodologías definen patrones, de cierta manera estrictos para cada una de las etapas de desarrollo.

Dentro de las metodologías más usadas está OMT++ : Metodología 100% orientada a objetos y descendiente del modelo lineal, es decir, se maneja muy bien con lenguajes orientados a objetos, como Java, C++ y la familia de lenguajes .NET y obliga a realizar cada una de las etapas de desarrollo de la mejor manera, ya que, en teoría, no es posible volver atrás para una nueva captura de requerimientos, por ejemplo. Esta metodología usa el patrón MVC (Modelo Vista Controlador) para las faces de análisis y diseño.

En otro post voy a hablar en profundidad sobre OMT++, asi como otros, como RUP, FDD, XP, los modelos que descienden del lineal e incemental.

Recomendaciones a la hora de usar Metodologías o Modelos de Desarrollo

Las metodologías es bueno ocuparlas en todo momento, ya que nos permiten seguir una estructura sólida y aseguran entregar tanto una buena documentación como un buen producto final. En cambio los modelos podemos hacer lo que queramos, permitiéndonos cierta flexibilidad al momento de implementarlo, pero no especifica algunas características de los productos finales, no así la metodología si los establece.

Apoyando el Software Libre, a un mundo libre! - Designed by Posicionamiento Web