1.Metodología:
La metodología utilizada es UP (Proceso Unificado).
UP es un marco de desarrollo que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental.
Esta dividido en cuatro grandes fases, en donde al final de cada fase hay un hito.
Las fases de UP son: Inicio, Elaboración, Construcción y Transición. (Ver Ilustración 1)
A su vez cada una de estás fases está dividida en iteraciones de duración fija.
Al finalizar cada iteración vamos a obtener un incremento de nuestro producto.
Las iteraciones atraviesan distintas disciplinas (Flujos de Trabajo) que deben ser ejecutadas antes de la finalización de la misma.
Algunas disciplinas tendrán mayor carga de trabajo que otras, dependiendo en la necesidad que tenga dicha disciplina en ese momento.
Ilustración 1
2.Disciplinas (Flujos de Trabajo) y artefactos:
Las disciplinas se dividen en dos categorías, las de procesos y las de soporte.
A continuación se detalla de las disciplinas con el desglose de los artefactos que se construirán en cada diciplina.
Disciplinas de proceso:
•Modelado de negocio
oPresentación del proyecto
oProceso del Negocio
oDocumento de Cruce: Proceso-Actividad-CNU
oModelo de dominio de negocio
oGlosario Organizacional
•Requerimientos
oDocumento de relevamiento
oEspecificación de requerimientos (funcionales, no funcionales)
•Análisis
oCasos de uso trazo Grueso
oCasos de uso trazo fino
oPrototipo de pantalla
oDocumento de trazabilidad de Proceso-Actividad-CUN
oModelo de análisis (Diagrama de secuencia, Diagrama de Clases)
•Diseño
oModelo de datos (DER)
oModelado de diseño
oDefinición de Arquitectura
Disciplinas de soporte:
•Gestión del calidad
oPlan de calidad
oRevisión técnica formal o por pares (RTF)
oChecklist de verificación
•Gestión de cambio y configuraciones
oDocumento de configuración
oDocumento de trazabilidad
•Gestión de proyecto
oPlan del proyecto
oMinutas de reuniones con el cliente
oDocumento Post-mortem
3.Detalle de los artefactos
A continuación se detallaran los artefactos que se generaran dentro de las disciplinas correspondientes.
3.1Modelado de negocio
3.1.1Presentación del proyecto
Consiste en la presentación de la visión y objetivos del proyecto, la definición básica del cliente y el marco geográfico donde ser va a desarrollar.
3.1.2Proceso del negocio
Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. El objetivo de este documento es presentar los procesos de negocio más relevante que tiene este proyecto.
3.1.3Documento de Cruce: Proceso – Actividad –CNU
3.1.4Modelo de dominio de negocio
Modelo conceptual de un dominio de problema de interés que describe entidades, atributos, roles y relaciones, más las restricciones que gobiernan la integridad de los elementos del modelo involucrados en dicho domino de problema.
3.1.5Glosario Organizacional
Este documento consiste en realizar una referencia de términos particulares del proyecto con el fin de evitar confusiones y mal uso de conceptos.
3.2Requerimientos:
3.2.1Documento de relevamiento
El objetivo de este documento es volcar la información obtenida en las entrevistas con los potenciales usuarios del sistema y de las encuestas realizadas.
3.2.2Especificación de requerimientos (funcionales y no funcionales)
En dicho documento nombraremos los requisitos tanto funcionales como los no funcionales.
3.3Análisis:
3.3.1Casos de uso de trazo grueso
A partir de los requisitos funcionales del sistema, elaboraremos casos de uso de trazo grueso que consistirán en la identificación de actores y una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso.
3.3.2Casos de uso de trazo fino
En los casos de uso trazo fino se especifican una vez que se haya tomado la decisión de implementarlos. En este momento se deben contemplar todos los detalles que se dajaron pasar en los casos de uso de trazo grueso.
3.3.3Prototipos de pantallas:
Los prototipos de pantallas son interfaces graficas de cómo va a quedar el sistema.
Permiten evaluar la posición de la información sobre la pantalla y validarla con el usuarios.
De esta forma estaríamos recibiendo una retroalimentación por parte del usuario, ya que en los prototipos vera como el sistema expondrá o solicitara la información.
3.3.4Documento de trazabilidad de Proceso-Actividad-CUN:
3.3.5Modelo de análisis (Diagrama de secuancias – Diagrama de Clases):
El modelo de análisis nos ayuda a refinar los requisitos y nos permite razonar sobre los aspectos internos del sistema.
También nos ofrece un mayor poder expresivo y una mayor formalización, nos proporciona una estructura centrada en el mantenimiento, en aspectos tales como la flexibilidad ante los cambios y la reutilización.
3.4Diseño:
3.4.1Modelo de datos (DER)
Dicho diagrama de entidad de relación consistirá en modelado de entidades de datos relevantes para nuestro sistema así como sus interrelaciones y propiedades.
3.4.2Modelado de diseño
Consistirá en el diagrama de clases detallando sus módulos y su estructura de paquetización, especificando sus interacciones.
3.4.3Definición de arquitectura
La arquitectura que se defina a través de los requisitos funcionales y no funcionales debe estar explayada en esté documento.
Ya que esta arquitectura será el esqueleto de la fase de construcción en donde se desarrollara el software en base a está arquitectura.
3.5Gestión de calidad:
3.5.1Plan de calidad
Abarcara los procesos y procedimiento de aseguramiento y control de calidad específicos para el proyecto, enumerando las herramientas y artefactos utilizados para dicho fin.
3.5.2Revisión técnica formal o por pares (RTF)
En este documento se registraran los cambios que irán afectando el documento para llevar un control y poder informar al resto del equipo dichos cambios asegurando así su calidad de trabajo.
3.5.3Checklist de verificación
Se elaborarán listados de verificación para los diferentes tipos de artefactos con el objetivo de proveer un guía de buenas prácticas que garanticen la utilidad y efectividad de los mismos.
3.6Gestión de configuración de cambios:
3.6.1Documento de configuración
Se desarrolla un Plan de Gestión de Configuración que describe las actividades de Gestión de Configuración, los procedimientos y los responsables de dichas actividades.
3.6.2Matriz de trazabilidad
Consistirá en una tabla donde se registraran los diferentes casos de uso que tendrán a su vez una relación entre uno o muchos de ellos indicando su trazabilidad para una mejor organización a la hora de hacer un cambio.
3.7Gestión de proyecto
3.7.1Plan del proyecto
El plan de proyecto consiste en la planificación desde el comienzo del proyecto al fin del mismo, estimando las tareas a realizar, tiempos que llevara cada tarea, iteraciones, y recursos que realizaran el trabajo durante el proyecto.
3.7.2Minutas de reuniones con el cliente
El documento de minuta sirve para dejar asentado toda la información revisada en una reunión formal.
En las minutas tenemos detalles como: Participantes, lugar y fecha, temas abordados, accionables con sus correspondientes responsables, interesados en la reunion.
3.7.3Documento Post-mortem
El documento de Post Mortem es una guía para analizar la efectividad del proyecto en términos de Gestión de Proyectos, Calidad en el Desarrollo del proyecto en sí, una vez finalizado el mismo. Se avalúan todos los puntos del proyecto, tanto el producto, la gestión administrativa, los recursos humanos, etc.
4.Iteraciones:
Las iteraciones se establecen al principio del proyecto, de acuerdo a la complejidad del sistema en el que se va a trabajar.
La duración de cada iteración es fija (Nosotros las haremos de 1 semana) y no puede ser modificada durante el curso del proyecto. (Ver Ilustración 2)
Cada iteración debe atravesar todas las disciplinas de UP de acuerdo al gráfico, obteniendo de las mismas todos los artefactos necesarios, que serán luego mostrados al cliente para su revisión y aprobación. En caso de disconformidad o cambios necesarios, se podrán incorporar a la siguiente iteración.
5.Plan deAdministración de Riesgos
Existen riesgos asociados a cada proyecto que deben ser identificados, analizados, tratados y controlados. Se debe analizar la probabilidad de ocurrencia y el impacto que pueden llegar a tener. Deben priorizarse los riesgos en base a estas características, y generarse planes de respuesta.
Consistirá en un documento en el que se identificaran, listaran y analizaran los riesgos del proyecto que pueden afectar el costo y los tiempos de entrega del mismo. Entonces se realizara la gestión de los mismos, se ordenarán por criticidad para luego marcar las estrategias y forma de actuar del equipo de trabajo frente a los riesgos determinando como tratarlos, monitorearlos, gestionarlos y evitarlos en un futuro.
La metodología utilizada es UP (Proceso Unificado).
UP es un marco de desarrollo que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental.
Esta dividido en cuatro grandes fases, en donde al final de cada fase hay un hito.
Las fases de UP son: Inicio, Elaboración, Construcción y Transición. (Ver Ilustración 1)
A su vez cada una de estás fases está dividida en iteraciones de duración fija.
Al finalizar cada iteración vamos a obtener un incremento de nuestro producto.
Las iteraciones atraviesan distintas disciplinas (Flujos de Trabajo) que deben ser ejecutadas antes de la finalización de la misma.
Algunas disciplinas tendrán mayor carga de trabajo que otras, dependiendo en la necesidad que tenga dicha disciplina en ese momento.
Ilustración 1
2.Disciplinas (Flujos de Trabajo) y artefactos:
Las disciplinas se dividen en dos categorías, las de procesos y las de soporte.
A continuación se detalla de las disciplinas con el desglose de los artefactos que se construirán en cada diciplina.
Disciplinas de proceso:
•Modelado de negocio
oPresentación del proyecto
oProceso del Negocio
oDocumento de Cruce: Proceso-Actividad-CNU
oModelo de dominio de negocio
oGlosario Organizacional
•Requerimientos
oDocumento de relevamiento
oEspecificación de requerimientos (funcionales, no funcionales)
•Análisis
oCasos de uso trazo Grueso
oCasos de uso trazo fino
oPrototipo de pantalla
oDocumento de trazabilidad de Proceso-Actividad-CUN
oModelo de análisis (Diagrama de secuencia, Diagrama de Clases)
•Diseño
oModelo de datos (DER)
oModelado de diseño
oDefinición de Arquitectura
Disciplinas de soporte:
•Gestión del calidad
oPlan de calidad
oRevisión técnica formal o por pares (RTF)
oChecklist de verificación
•Gestión de cambio y configuraciones
oDocumento de configuración
oDocumento de trazabilidad
•Gestión de proyecto
oPlan del proyecto
oMinutas de reuniones con el cliente
oDocumento Post-mortem
3.Detalle de los artefactos
A continuación se detallaran los artefactos que se generaran dentro de las disciplinas correspondientes.
3.1Modelado de negocio
3.1.1Presentación del proyecto
Consiste en la presentación de la visión y objetivos del proyecto, la definición básica del cliente y el marco geográfico donde ser va a desarrollar.
3.1.2Proceso del negocio
Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. El objetivo de este documento es presentar los procesos de negocio más relevante que tiene este proyecto.
3.1.3Documento de Cruce: Proceso – Actividad –CNU
3.1.4Modelo de dominio de negocio
Modelo conceptual de un dominio de problema de interés que describe entidades, atributos, roles y relaciones, más las restricciones que gobiernan la integridad de los elementos del modelo involucrados en dicho domino de problema.
3.1.5Glosario Organizacional
Este documento consiste en realizar una referencia de términos particulares del proyecto con el fin de evitar confusiones y mal uso de conceptos.
3.2Requerimientos:
3.2.1Documento de relevamiento
El objetivo de este documento es volcar la información obtenida en las entrevistas con los potenciales usuarios del sistema y de las encuestas realizadas.
3.2.2Especificación de requerimientos (funcionales y no funcionales)
En dicho documento nombraremos los requisitos tanto funcionales como los no funcionales.
3.3Análisis:
3.3.1Casos de uso de trazo grueso
A partir de los requisitos funcionales del sistema, elaboraremos casos de uso de trazo grueso que consistirán en la identificación de actores y una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso.
3.3.2Casos de uso de trazo fino
En los casos de uso trazo fino se especifican una vez que se haya tomado la decisión de implementarlos. En este momento se deben contemplar todos los detalles que se dajaron pasar en los casos de uso de trazo grueso.
3.3.3Prototipos de pantallas:
Los prototipos de pantallas son interfaces graficas de cómo va a quedar el sistema.
Permiten evaluar la posición de la información sobre la pantalla y validarla con el usuarios.
De esta forma estaríamos recibiendo una retroalimentación por parte del usuario, ya que en los prototipos vera como el sistema expondrá o solicitara la información.
3.3.4Documento de trazabilidad de Proceso-Actividad-CUN:
3.3.5Modelo de análisis (Diagrama de secuancias – Diagrama de Clases):
El modelo de análisis nos ayuda a refinar los requisitos y nos permite razonar sobre los aspectos internos del sistema.
También nos ofrece un mayor poder expresivo y una mayor formalización, nos proporciona una estructura centrada en el mantenimiento, en aspectos tales como la flexibilidad ante los cambios y la reutilización.
3.4Diseño:
3.4.1Modelo de datos (DER)
Dicho diagrama de entidad de relación consistirá en modelado de entidades de datos relevantes para nuestro sistema así como sus interrelaciones y propiedades.
3.4.2Modelado de diseño
Consistirá en el diagrama de clases detallando sus módulos y su estructura de paquetización, especificando sus interacciones.
3.4.3Definición de arquitectura
La arquitectura que se defina a través de los requisitos funcionales y no funcionales debe estar explayada en esté documento.
Ya que esta arquitectura será el esqueleto de la fase de construcción en donde se desarrollara el software en base a está arquitectura.
3.5Gestión de calidad:
3.5.1Plan de calidad
Abarcara los procesos y procedimiento de aseguramiento y control de calidad específicos para el proyecto, enumerando las herramientas y artefactos utilizados para dicho fin.
3.5.2Revisión técnica formal o por pares (RTF)
En este documento se registraran los cambios que irán afectando el documento para llevar un control y poder informar al resto del equipo dichos cambios asegurando así su calidad de trabajo.
3.5.3Checklist de verificación
Se elaborarán listados de verificación para los diferentes tipos de artefactos con el objetivo de proveer un guía de buenas prácticas que garanticen la utilidad y efectividad de los mismos.
3.6Gestión de configuración de cambios:
3.6.1Documento de configuración
Se desarrolla un Plan de Gestión de Configuración que describe las actividades de Gestión de Configuración, los procedimientos y los responsables de dichas actividades.
3.6.2Matriz de trazabilidad
Consistirá en una tabla donde se registraran los diferentes casos de uso que tendrán a su vez una relación entre uno o muchos de ellos indicando su trazabilidad para una mejor organización a la hora de hacer un cambio.
3.7Gestión de proyecto
3.7.1Plan del proyecto
El plan de proyecto consiste en la planificación desde el comienzo del proyecto al fin del mismo, estimando las tareas a realizar, tiempos que llevara cada tarea, iteraciones, y recursos que realizaran el trabajo durante el proyecto.
3.7.2Minutas de reuniones con el cliente
El documento de minuta sirve para dejar asentado toda la información revisada en una reunión formal.
En las minutas tenemos detalles como: Participantes, lugar y fecha, temas abordados, accionables con sus correspondientes responsables, interesados en la reunion.
3.7.3Documento Post-mortem
El documento de Post Mortem es una guía para analizar la efectividad del proyecto en términos de Gestión de Proyectos, Calidad en el Desarrollo del proyecto en sí, una vez finalizado el mismo. Se avalúan todos los puntos del proyecto, tanto el producto, la gestión administrativa, los recursos humanos, etc.
4.Iteraciones:
Las iteraciones se establecen al principio del proyecto, de acuerdo a la complejidad del sistema en el que se va a trabajar.
La duración de cada iteración es fija (Nosotros las haremos de 1 semana) y no puede ser modificada durante el curso del proyecto. (Ver Ilustración 2)
Cada iteración debe atravesar todas las disciplinas de UP de acuerdo al gráfico, obteniendo de las mismas todos los artefactos necesarios, que serán luego mostrados al cliente para su revisión y aprobación. En caso de disconformidad o cambios necesarios, se podrán incorporar a la siguiente iteración.
5.Plan deAdministración de Riesgos
Existen riesgos asociados a cada proyecto que deben ser identificados, analizados, tratados y controlados. Se debe analizar la probabilidad de ocurrencia y el impacto que pueden llegar a tener. Deben priorizarse los riesgos en base a estas características, y generarse planes de respuesta.
Consistirá en un documento en el que se identificaran, listaran y analizaran los riesgos del proyecto que pueden afectar el costo y los tiempos de entrega del mismo. Entonces se realizara la gestión de los mismos, se ordenarán por criticidad para luego marcar las estrategias y forma de actuar del equipo de trabajo frente a los riesgos determinando como tratarlos, monitorearlos, gestionarlos y evitarlos en un futuro.