Taller 1: Metodología y Ciclo de Vida del Software
MODELO DE CICLO DE VIDA
El modelo de ciclo de vida elegido para la construcción del producto software LaundrySoft fue cascada modificado con reducción de riesgos debido a que permite reducir la incertidumbre en las primeras etapas del desarrollo pero que a su vez mantiene el enfoque simple, sistemático y secuencial del modelo de ciclo de vida en cascada puro.
El sistema se construye en un enfoque por módulos. Cada módulo se diseña por aparte, pero entendiéndolo como parte de un todo que se interrelaciona. Los módulos están divididos por roles de la siguiente manera:
· Admin: Módulo encargado de la gestión de operarios, clientes, pedidos y cotizaciones por parte del administrador.
· Cliente: Este módulo es el encargado de realizar las operaciones de generar solicitud de cotización, crear diseños propios, definir pedidos y ver el estado de los mismos por parte del cliente.
· Operario: Este módulo se encarga de la recepción de solicitudes de cotización por parte de los operarios, además es quien gestiona el proceso de tratamiento de pedido con cada uno de los elementos que intervienen en dicho proceso.
El ciclo de vida se ajusta bajo los tres factores resaltantes dentro de un proyecto de software, los cuales son: Alcance, Tiempo y Recursos. Bajo este enfoque se justificó el uso del modelo en cascada mejorado (cascada con reducción de riesgos).
Para definir el alcance del proyecto de software, se tuvo en cuenta los numerosos encuentros con el cliente, definiendo nuevas restricciones con relación a las funcionalidades que ejecutaría el sistema. El objetivo principal del modelo de cascada con reducción de riesgos, es sencillamente iterar sobre las etapas iniciales del proyecto, para tener robustez en cuanto a las funcionalidades del sistema y la forma en que se llevarán a cabo, así como el acertamiento en la determinación de los roles que se manejan en él .
Con relación al tiempo de desarrollo del proyecto, se llevó a cabo en un intervalo aproximadamente de 4 meses. Esta limitante implicó el desarrollo iterativo de las fases iniciales del proyecto, específicamente, las fases de análisis y diseño, garantizando la reducción en un gran porcentaje sobre las fallas que se visualizarían en las etapas de implementación del sistema.
Se entiende que realizar iteraciones durante ciertas etapas puede alargar el tiempo de desarrollo, pero viéndolo desde el punto de vista global del sistema de información, producirá reducciones en este factor, es más fácil regresar una etapa atrás a llevar el ritmo de un proyecto en estado de implementación a un estado inicial.
Por último cabe resaltar que el modelo facilitó el manejo de recursos debido a que los tiempos de desarrollo fueron optimizados gracias al principio que lleva implícito un modelo en cascada. Este modelo no permite iterar sobre cada una de las fases por lo que no estaríamos empleando recursos en exceso al mismo tiempo llevando a cabo las actividades de cada fase de manera rigurosa.
METODOLOGÍA APLICADA
Para el desarrollo del proyecto se escogió la metodología AUP porque en el desarrollo ágil las actividades de administración de cambios son típicamente parte del esfuerzo que se realiza en la administración de requerimientos, la cual es parte de la disciplina de Modelado.
Ahora se muestra la fusión de esta metodología con el ciclo de vida que se escogió el cual fue cascada mejorado con reducción de riesgos. La metodología ágil UP tiene cuatro fases las cuales acaban con todos los hitos alcanzados. La primera fase es la de iniciación en la cual el objetivo es identificar el alcance inicial del proyecto, una arquitectura potencial de su sistema y la aceptación del involucrado. Esta fase se puede combinar fácilmente con la fase de análisis y el inicio de la fase de diseño del ciclo de vida ya que ellas buscan definir el alcance del proyecto mediante una descripción tanto grafica como textual.
La segunda fase es la de elaboración en donde el objetivo es mejorar la arquitectura del sistema la cual se escogió en la fase de iniciación o escoger una entre las posibles candidatas. Esta fase se fusiona con el final de la fase de diseño del ciclo de vida en la cual se establece la arquitectura como tal, realizando las validaciones necesarias que determinen en un gran porcentaje de confiabilidad que es la apropiada para el sistema.
La tercera fase es la de construcción en la cual el objetivo es construir software funcional en una base regular, la cual cumpla con las necesidades de prioridad más alta de los involucrados de su proyecto. Esta fase se asimila a la fase de implementación en la cual se realiza el producto de acuerdo a lo realizado en la parte de análisis y diseño, esto permite que dicha implementación sea más fácil y ordenada de realizarse.
La cuarta y última fase es la fase de transición en la cual el objetivo es validar y desplegar el sistema en un ambiente de producción. Esta fase se fusiona con las dos últimas fases del modelo de ciclo vida que se escogió las cuales son la fase de pruebas y la fase de mantenimiento, ya que es la parte final del producto en donde se valida que el software funcione de manera correcta.
El paradigma bajo el cual se lleva a cabo la metodología del presente proyecto es la orientación a objetos. Este paradigma es fundamental en el desarrollo del proyecto por el hecho de permitir herencia, cohesión, polimorfismo, encapsulamiento y abstracción, lo cual permite un desarrollo más eficaz, que encaja perfectamente con el desarrollo por módulos.
Juan Daniel Vega Santos 1150958 — Angie Melissa Delgado León 1150990 — Edgar Yesid García Ortíz 1150967 — Fernando Antonio Peñaranda Torres 1150684
