Metodologia General de Desarrollo

10
Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 1 de 10 METODOLOGIA GENERAL DE DESARROLLO Actualización: 3.1 Autor: Centro de Calidad de Aplicaciones

description

Metodologia

Transcript of Metodologia General de Desarrollo

Page 1: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 1 de 10

METODOLOGIA GENERAL DE DESARROLLO Actualización: 3.1 Autor: Centro de Calidad de Aplicaciones

Page 2: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 2 de 10

Contenido

1. OBJETIVOS Y ALCANCE ....................................................................................................... 3

2. PROCESO Y PLATAFORMA .................................................................................................. 3

3. DETALLE DE FASES E HITOS DE FINALIZACION ............................................................... 6

FASE DE PLANIFICACIÓN Y PREANALISIS ............................................................................................... 6

FASE DE ANÁLISIS FUNCIONAL ................................................................................................................. 7

FASE DE DISEÑO TÉCNICO ........................................................................................................................ 7

FASE DE CONSTRUCCIÓN Y PRUEBAS .................................................................................................... 8

FASE DE IMPLANTACIÓN ............................................................................................................................ 9

TRAZABILIDAD ENTRE FASES ................................................................................................................... 9

4. RESUMEN DE FASES E HITOS .............................................................................................. 9

5. ENTREGABLES POR CADA FASE DEL PROYECTO ......................................................... 10

6. CICLOS CORTOS .................................................................................................................. 10

Control de Versiones

Versión Responsable Fecha Descripción del cambio 1.0 CCA Primera versión del documento 2.0 Claudio Carlés Duran Julio 2006 3.0 Claudio Carlés Duran Julio 2007 3.1 Claudio Carles Duran Octubre 2008

Page 3: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 3 de 10

1. OBJETIVOS Y ALCANCE El presente documento tiene por objetivo presentar una metodología general para ser aplicada a los proyectos de desarrollo que se llevan a cabo en el ámbito de la Dirección de Sistemas de Información. Se establece como referencia para los equipos de Desarrollo, independientemente del tipo de proyecto o tecnología utilizada para el mismo. 2. PROCESO Y PLATAFORMA En general, una Metodología se define como un “conjunto de métodos, reglas y postulados empleados por una disciplina determinada”. También se puede definir como un “procedimiento particular, o conjunto de procedimientos empleados en una actividad específica”. En Ingeniería del Software, el término “Metodología” se asocia frecuentemente a un grupo de prácticas recomendadas para un tipo determinado de desarrollo, acompañado por un lenguaje de notación, y por un conjunto de herramientas y técnicas que se deben aplicar en los proyectos. La Metodología General de Desarrollo de Repsol-YPF se enmarca dentro de esta última definición. La Metodología General de Desarrollo está dividida en 2 grandes niveles:

• Proceso de Desarrollo

: define las fases, hitos, actividades y entregables del ciclo de desarrollo, e incorpora guías con las pautas a seguir, y las plantillas para generar la documentación.

• Plataforma de Desarrollo

: es el conjunto de elementos reutilizables, herramientas, estándares y buenas prácticas que están a disposición de los equipos de desarrollo para su utilización en los proyectos.

Es fundamental entender bien la diferencia entre Proceso y Plataforma. En el Proceso se determina qué debe hacerse durante el desarrollo, mientras que en la Plataforma se determina cómo deben hacerse las cosas. Por ejemplo: en el Proceso de Desarrollo para entornos Web, se determina que en la Fase de Construcción y Pruebas se debe construir el sistema en base a las definiciones de la Fase de del Diseño Técnico; mientras que en la Plataforma se define que para hacer esa construcción en .NET deben considerarse el uso de ciertos componentes específicos del framework, respetar unos estándares de programación, aplicar un conjunto determinado de buenas prácticas y usar las herramientas indicadas para las pruebas unitarias. La Metodología define un Proceso de Desarrollo que es independiente del entorno tecnológico, es decir, el ciclo de vida de todos los desarrollos será siempre el mismo, sea cual fuere el entorno sobre el que se trabaja. No obstante, está claro que la Plataforma varía entre los distintos entornos tecnológicos. Las Guías de Entorno, particulares para cada Tecnología, describen cada fase del Ciclo de Desarrollo, identificando “que” se hace (Proceso) y “como” se hace (Plataforma).

Page 4: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 4 de 10

La relación entre los elementos del Proceso y de la Plataforma se describe esquemáticamente en el siguiente gráfico:

El documento describe el esquema de fases definido para el ciclo de vida y los hitos de finalización de cada Fase. La gestión de la Calidad está integrada de forma permanente en todo el ciclo de vida. La definición de los Entregables y las técnicas de modelado utilizadas en cada tecnología, son referidas en la GUIA DE ENTORNO correspondiente a cada tecnología.

Page 5: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 5 de 10

La Metodología define un ciclo de vida dividido en Fases, el esquema es el siguiente, que además muestra el paralelismo existente con la Metodología General de Gestión de Proyectos.

Metodología General de Gestión de Proyectos

Metodología General de Desarrollo (MGD)

Planificación y Preanalisis Analisis Funcional Diseño Técnico Construcción y

Pruebas Implantación

Planificación y Estudio Preliminar

Lanzamiento Control y seguimiento Cierre de Proyecto

Gestión de Calidad

Hito 1 Hito 5Hito 4Hito 3Hito 2

El ciclo de vida se descompone en 5 fases de desarrollo. La finalización de cada una de las fases del desarrollo marca un hito en el ciclo de vida del proyecto. A efectos de planificación, un proyecto con un alcance importante, puede descomponerse en ciclos de desarrollo parciales respecto de la funcionalidad total, donde cada uno de estos ciclos se rige por este mismo esquema de fases.

Page 6: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 6 de 10

3. DETALLE DE FASES E HITOS DE FINALIZACION A continuación se describen los objetivos y características de cada Fase del ciclo de vida de Desarrollo.

Fase de Planificación y Preanalisis

La Fase tiene como punto de partida la identificación del proceso (o procesos) de negocio que ha de ser implementado en un sistema de información. A su vez, dentro de este proceso se deben identificar aquellas actividades que estarán soportadas por el sistema, derivándose de este modo los requisitos de la aplicación. Los objetivos de la fase se resumen en:

• Definir, a partir del proceso de negocio afectado, un conjunto estable de requisitos del sistema, que describan sin ambigüedades las necesidades del usuario, enfocándolas a su futura utilización en un sistema de información, logrando su entendimiento y aprobación.

• Ser apto, para realizar una valoración del sistema a desarrollar.

Los requisitos se clasifican en 3 categorías: Funcionales, No Funcionales e Interfaz de Usuario. Se entiende por Requisito la circunstancia o condición necesaria para realizar o cumplir algo. Los Requisitos Funcionales (RF) son aquellos que describen el comportamiento esperado del sistema por parte de los usuarios para atender sus necesidades de negocio. Los requisitos funcionales reflejan el objetivo del sistema a desarrollar, o de forma más general, para qué se pide el sistema. Se debe excluir cualquier mención a cuestiones de implantación. Los Requisitos No Funcionales (RNF) describen aspectos del sistema visibles por el usuario que no se relacionan en forma directa con el comportamiento funcional del sistema. Además son restrictivos de la solución. Algunos ejemplos de RNF son:

• Seguridad • Disponibilidad • Eficiencia (Rendimiento) • Volumen • Usabilidad • Portabilidad • Legislativos/Normativos • Éticos

La Interfaz de Usuario es la capa encargada de dotar la funcionalidad necesaria para la interacción entre el usuario y la aplicación. Se debe de representar aquella Interfaz de Usuario que sea relevante (que sea importante, que tenga un significado para el negocio)

Page 7: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 7 de 10

Fase de Análisis Funcional

Recogiendo los requisitos definidos en la Fase anterior, los objetivos de la fase se resumen en:

• Ampliar, la definición de los RF, hasta un nivel suficiente para que el equipo de desarrollo pueda realizar el diseño técnico de la aplicación.

• Acordar, basándose en el proceso de negocio y los requisitos definidos, los criterios de aceptación

para la puesta en producción del sistema. Estos criterios quedan documentados en el Plan de Pruebas de Aceptación de Usuario.

En esta fase, la Especificación de los Requisitos Funcionales debe ser:

• Completa: Se deben describir todos los escenarios posibles, incluyendo el comportamiento excepcional.

• Consistente: No se debe contradecir a si misma. • No Ambigua: No debe ser posible interpretar aspectos de la especificación de 2 o más formas. • Verificable: Una vez construido el sistema, se puede diseñar una prueba repetible que demuestre

que se satisfacen los requisitos. Los errores producidos por una mala toma de requisitos, son siempre más relevantes y costosos, que errores producidos en fases posteriores del Ciclo de Vida de Desarrollo. El Plan de Pruebas de Aceptación es considerado dentro de esta Fase, ya que toda la información necesaria para generar dicho plan se obtiene al mismo tiempo que se realiza la especificación de los requisitos del sistema. Además, al igual que ocurre con los requisitos, el Plan de Pruebas de Aceptación también requiere la validación del área usuaria. El Plan esta enfocado a la ejecución de Escenarios de Negocio (Secuencia de eventos y/o actividades que simulan un conjunto de situaciones reales que el sistema debe atender) Para garantizar la mantenibilidad de los sistemas, es fundamental mantener la trazabilidad, tanto de los requisitos entre sí (para reflejar sus dependencias mutuas), como desde los requisitos hacia su correspondiente diseño e implementación final.

Fase de Diseño Técnico

El objetivo de la Fase es expresar formalmente la estructura del sistema, y definir la solución técnica más adecuada, asegurando el cumplimiento de los requisitos documentados en la fase anterior, respetando los estándares correspondientes a la plataforma tecnológica y aplicando en lo posible las buenas practicas recomendadas por esta. Se debe poner especial énfasis en la reutilización de los componentes que forman parte de la Plataforma de Desarrollo. Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el Software. Se deben identificar los distintos entornos (Desarrollo, Pruebas y Producción) en donde la aplicación se ejecutará. A continuación se mencionan las principales actividades que deben considerarse durante el desarrollo de la Fase:

Page 8: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 8 de 10

• Diseño del modelo estático: El objetivo es definir el conjunto de estructuras que servirán de soporte al estado interno del sistema en todo momento. En general, el componente más importante del modelo estático es el modelo de datos, pero según sea la tecnología aplicada, pueden utilizarse además otras estructuras para reflejar el estado interno del sistema (por ejemplo objetos).

• Diseño del Modelo de Comportamiento: El objetivo es diseñar el conjunto de operaciones que se llevan a cabo dentro del sistema, y que actúan modificando su estado interno (definido en el modelo estático). Según sea la tecnología utilizada, el modelo de comportamiento puede expresarse en forma de operaciones de clases, programas aislados, procedimientos almacenados, etc. Como resultado de esta actividad (y siempre respetando las definiciones de la fase de Análisis Funcional) deben quedar claramente diferenciadas aquellas operaciones que se realizan en forma batch de aquellas que se ejecutan on-line, con intervención directa de un usuario.

• Diseño de la Arquitectura Física de la Aplicación: Define los componentes físicos del sistema, su distribución y características particulares.

Hay que tener en cuenta los efectos que pueda producir la introducción del nuevo sistema sobre el entorno en el que debe funcionar, adecuando los criterios de diseño a las características del mismo. Como parte de esta fase también se considera el desarrollo de un prototipo. La utilización de prototipos puede ser de gran utilidad para el desarrollo, en la medida que se presenten como una aproximación del futuro sistema, ayudando a identificar posibles ajustes sobre los requisitos y reduciendo riesgo. Sin embargo, es importante gestionar de forma adecuada la expectativa del usuario, evitando que este considere que el prototipo es el sistema definitivo, y dejando claro en todo momento que se trata de una herramienta para validar la funcionalidad básica y el aspecto externo del sistema, y que aún requiere una importante actividad de desarrollo antes de llegar a ser el sistema real. En esta misma fase se comienza también con la definición del Plan de Pruebas Detallado, el cual sirve como guía para la realización de las pruebas y permitirá verificar que el sistema a desarrollar cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad. El Plan de Pruebas es un producto formal que define los objetivos de la prueba de un sistema, establece y coordina una estrategia de trabajo y provee un marco adecuado para elaborar una planificación paso a paso de las actividades de la prueba.

Fase de Construcción y Pruebas

El objetivo de esta Fase es construir el Sistema en base al Diseño Técnico definido en la Fase anterior realizando simultáneamente las pruebas necesarias para asegurar la Calidad. Podemos mencionar las siguientes actividades para esta fase:

• Construcción física del Sistema. Se construye el software en base a las definiciones del Diseño Técnico y según las pautas establecidas en la Plataforma. Esta actividad implica tanto la creación de los nuevos componentes como la incorporación o adecuación de los elementos reutilizables de la Plataforma, y abarca las tareas de programación, creación de la base de datos y montaje de los elementos definidos en la arquitectura.

• Realización de Pruebas. El tipo de pruebas a realizar podrá variar según se trate de desarrollos de aplicaciones transaccionales, gestión de contenidos o proyectos de carácter puramente técnico (migraciones, desarrollo de frameworks, etc). Se debe probar por módulo desarrollado, ya que así se facilita la detección y corrección de fallas y luego probar la integración de los mismos. Se realizarán las pruebas de aceptación siguiendo las pautas definidas en el Plan de Pruebas de Aceptación elaborado en la fase de Análisis Funcional. Las Pruebas de Aceptación constituyen un

Page 9: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 9 de 10

procedimiento formal ejecutado por los usuarios que permite verificar que el sistema producido es totalmente funcional y satisface los requisitos iniciales, como un paso previo a su implantación.

El objetivo fundamental es conseguir la aceptación del sistema por parte de los usuarios del mismo, para su posterior implantación. Se realizarán los procedimientos necesarios para la implantación y puesta en producción del sistema.

Fase de Implantación

En esta Fase se pone en marcha el Sistema en el entorno productivo, ejecutando la implementación de los elementos del modelo de diseño, asegurándose su fiabilidad y permitiendo su traspaso satisfactorio al área de Mantenimiento. Se debe evitar la modificación no autorizada de software que se ha probado, garantizando que se implanta lo mismo que se ha probado. Se realiza una verificación técnica de la aplicación y se emite un Informe Final de Calidad indicando el estado de la aplicación.

Trazabilidad entre Fases

Se considera a la Trazabilidad como la posibilidad de encontrar y seguir el rastro, a través de todas las fases del ciclo de vida de una aplicación. Es entonces, la capacidad para reconstruir la historia de una aplicación mediante información confeccionada y/o seleccionada para este fin. El siguiente grafico muestra la trazabilidad entre Fases, que permite que los elementos con un determinado nivel de abstracción puedan derivarse a partir de los elementos de otro modelo con un nivel de abstracción superior.

La MGD garantiza la trazabilidad entre fases a través de los productos generados en ella. 4. RESUMEN DE FASES E HITOS Se resume a continuación la asociación de cada una de las Fases con sus respectivos hitos de finalización. Fase Hito de Finalización Planificación y Preanalisis Propuesta de Proyecto o RFP en caso de Proyectos Cerrados.

Hito 1:

Análisis Funcional Aprobación formal por parte del usuario, de los requisitos funcionales, no funcionales e

interfaz de usuario (relevante, en caso de existir).

Hito 2:

Aprobación conjunta (Usuarios y Sistemas) del Plan de Pruebas de Aceptación. Diseño Hito 3:

Page 10: Metodologia General de Desarrollo

Dirección de Sistemas de Información Metodología General de Desarrollo v3.1 para RFP Pág. 10 de 10

Técnico Diseño detallado finalizado. Plan de pruebas completo.

Construcción y Pruebas

Aplicación construida, probada y aceptada por el usuario para su implantación. Hito 4:

Implantación Aplicación en régimen de mantenimiento. Hito 5:

Además de las Fases descritas, existen dos actividades que se desarrollan de forma paralela a la ejecución de estas Fases: Actividad Objetivo Gestión del Proyecto Esta actividad esta soportada por la Metodología General de Gestión de

Proyectos y tiene como objetivo el de monitorear de forma permanente el avance del proyecto, controlando la planificación, desvíos respecto del plan, gestión de riesgos, cumplimiento de entregas intermedias, hitos, etc.

Gestión de Calidad Realiza actividades de revisión y validación de los entregables a lo largo de todo el ciclo de desarrollo, con el fin de detectar incidencias de forma temprana y evitar que estas se trasladen al código. Efectúa revisiones de código y pruebas sobre el software construido. Como producto de estas actividades, elaborar informes de Calidad para los responsables de la gestión del Proyecto.

5. ENTREGABLES POR CADA FASE DEL PROYECTO Durante la ejecución de cada Fase se debe generar la documentación mínima que asegure el cumplimiento de los objetivos de la Fase, y que permita pasar a la siguiente Fase del desarrollo minimizando el riesgo de “vuelta atrás” por causa de incidencias derivadas de información insuficiente o incompleta. 6. CICLOS CORTOS Por tratarse de excepciones del ciclo de vida de un desarrollo, los mantenimientos Evolutivo y el Correctivo son tratados como procedimientos independientes, del ciclo de vida de un desarrollo normal. A continuación se detallan ambos. Mantenimiento Evolutivo Se define como el conjunto de actividades que se realizan para mejorar o añadir nuevas funcionalidades requeridas por el usuario. Mantenimiento Correctivo Se define como el conjunto de actividades dedicadas a corregir defectos en las aplicaciones, detectados por los usuarios durante la explotación del sistema.