Metodología Proceso Unificado
En todo proyecto de desarrollo de software es necesario tener un orden lógico, para el desarrollo y la puesta en marcha del mismo. Esto hace necesario que se tenga una metodología de desarrollo, que se enfoque en ayudar a entender que es lo que quiere el cliente y que se brinde la solución más óptima que cumpla con los requerimientos establecidos.
La metodología que se utiliza para este caso es una metodología iterativa, donde cada iteración es un incremento o un avance del software, atacando así el problema en pequeños módulos, haciendo que sea más fácil en un futuro poderle hacer algún tipo de mantenimiento, o incluir un nuevo requerimiento. Dicho lo anterior, el mercado ofrece un sin número de metodologías que cumplen con este propósito, Para nuestro caso se utilizara UP (Proceso Unificado).
Proceso Unificado
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos.
Iterativo e Incremental: El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones. Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.
Dirigido por los casos de uso: En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: análisis, diseño, implementación, prueba.
Flujo de trabajo
Fases del flujo
En la gráfica anterior se muestra como se debe realizar la iteración para el desarrollo de software, a continuación se describe que se hace en cada fase, que documentos de entrada y salida generan cada una de ellas.
REQUISITOS
Como tal los requisitos no son una fase, este es el inicio del proyecto donde se quiere entender la problemática de las empresas y cuáles son los requisitos que a los cuales se le debe dar solución.
- Documentos Entrada: Como entrada se tiene los modelos mentales que tienen los stakeholders (personas interesadas), los relatos que se consiguen a través de las reuniones sostenidas para tratar de entender el problema al cual se le quiere dar una solución.
- Documentos de salida: Una vez se concluyen las reuniones pactadas, con la información allí recolectada se generan:
- Documento de planteamiento del problema:
- Documentos de requisitos.
- Modelos mentales de los stakeholders (Opcional).
- Esta etapa va unida con la fase de análisis del proyecto.
FASE DE ANALISIS
- En esta fase se realiza todo el análisis con la información recolectada en la etapa de REQUISITOS.
- Documentos de entrada:
- Descripción del problema
- Documento de requerimientos
- Modelos mentales stakeholders.
- Documentos de salida:
- Diagrama de casos de uso.
- Descripción de los casos de uso (Escenarios).
- Diagrama de Actividades.
- Modelo de dominio.
- Creación de Diagramas de Casos de Uso
Para crear los diagramas de los casos de uso se necesita como entrada la información recolectada en la etapa de requerimientos arrojando como salida el diagrama de los casos de uso.
Creación de la descripción de los casos de uso (Escenarios)
Los escenarios de los casos de uso son todas las actividades exitosas y no exitosas que pueden llegar a tener cada unos de los casos de uso en su flujo de trabajo.
Creación Diagramas de Actividad
Para esta etapa entran como documentos los diagramas de casos de uso y todos lo escenarios que se hallan identificado en la etapa anterior dando como resultado el diagrama de actividades.
Creación del modelo del Dominio
El modelo del dominio recibe los diagramas de casos de uso y la descripción de los mismos, el modelo del dominio es una representación visual del sistema, puede servir para generar un modelo entidad relación y es la base para el diagrama de clases. Se pueden describir algunos atributos, las asociaciones y la cardinalidad de las mismas.
Con este último diagrama concluye la fase de análisis, en este punto ya se debe tener claro que es lo que se quiere hacer, es decir se ha identificado el “QUE”. Dejando como resultado una serie de documentos que nos van a servir de entrada para algunos diagramas en la fase de análisis.
FASE DE DISEÑO
La fase de diseño es plasmar de una forma más concreta todo lo que se realizó en la fase de análisis es decir aquí vamos a ver el “COMO”, es decir cómo vamos hacer para que todo esto que se analizó pase a algo más tangible y real.
Documentos de Entrada:
- Diagrama de casos de uso.
- Descripción de los casos de uso (Escenarios).
- Diagrama de Actividades.
- Modelo de dominio.
- Documentos de Salida:
- Diagrama de Análisis Robusto.
- Diagrama de Secuencia.
- Diagrama de Clases.
- Creación de Análisis Robusto
Para este diagrama se utilizan los documentos generados en la fase de análisis, este diagrama sirve para identificar entradas de usuario (Bundary), controladores (Controller o Services), y repositorios de datos o persistencia (Entities). Esto va dando un descripción general de cómo se va a ir conformando las iteraciones dentro del sistema.
Creación Diagrama de Secuencia
Para la creación de un diagrama de secuencia se reciben como documentos de entrada los casos de uso con sus respectivos escenarios, el diagrama de actividades, esto en caso que no se haga un diagrama de análisis robusto, si se tiene el diagrama de robustez, podría tomarse este como base para realizar el diagrama de secuencia, con este diagrama se quiere mostrar como interactúa directamente e usuario con el software y cuáles son los mensajes que se envían entre los controladores o servicios del software.
Creación Diagrama de Clases
El diagrama de clases muestra gráficamente todas las clases que componen el sistema y las relaciones que se tienen entre ellas, en el diagrama de clases se describe todos los atributos y métodos que utiliza cada una de las clases, para realizar este diagrama se utiliza el diagrama de robustez y el diagrama de secuencia.
Con este último diagrama finaliza la fase de diseño a este punto ya debe se debe tener soluciona el “COMO”, ya se debe tener claro que se quiere hacer y cómo se quiere hacer.
FASE DE CONSTRUCCION
En esta fase se busca codificar todo lo creado en la fase de diseño y de analisis, para esta estapa se debe tener como entrada dependiendo el tipo de desarrollo(PLSql o Java), los diagramas de clases, documentos de requerimeintos, casos de usos y demas diagramas creados en la fases anteriores
Documentos de Entrada:
- Diagrama de Clases.
- Casos de uso (Escenarios).
- Diagrama de Robustez.
- Diagrama de secuencia.
- Docuementos de requerimientos de programación
Documentos de Salida:
- Se genera la primera iteración del aplicativo (Código fuente).
- Se realiza el versionamiento.
- Se hace la primera liberacion de la iteraccion o proyecto.
FASE DE PRUEBAS
La fase de pruebas es donde se pueden llegar a identificar los posibles errores que tiene el software, las pruebas deben ser escritas basadas en los casos de uso (Escenarios).
“Las pruebas que no arrojen ningún tipo de error están mal hechas”
La anterior es una premisa que conoce a nivel de pruebas, todas las pruebas deben ser cuidadosamente ejecutadas siguiendo el documento escrito para estas, esto no quiere decir que la persona encargada (Tester), no pueda hacer ciertas sugerencias para diferentes aspectos que encuentre en el sistema.
Documentos de entrada:
- Documentos de pruebas
Documentos de Salida:
- Documento de observaciones de las pruebas
Creación Documento de Pruebas
Una vez finalizada las pruebas se genera un documento de observaciones, en caso de ser necesario se hacen correcciones y se libera la primera versión del software. Si las pruebas no son satisfactorias, se revisa que fallo y en caso de ser necesario se retroalimentan todos lo modelos en la fase análisis y diseño.
Y con esto finaliza la primera iteración del software. Como se puede ver al finalizar cada iteración se va creando la documentación que al final será entregado a la empresa si esta lo solicita.
