Marco metodológico - Extremadura · 2018-03-21 · basada en METRICA v3 utilizando para el proceso...

Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

MADES

Marco metodológico

19/03/2018

Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicaciónpública y/o transformación, total o parcial, por cualquier medio, de este documento sin el previo consentimientoexpreso y por escrito de la Consejería de Hacienda y Administración Pública de la Junta de Extremadura.



Avda. Valhondo S/NEdificio III MilenoMódulo 2 - 3ª planta06800 - Mérida

JUNTA DE EXTREMADURA

MADES

Marco metodológico

HOJA DE CONTROL

Proyecto MADES (Marco para el Desarrollo y Mantenimiento de los S.I.)

Documento Marco metodológico

Nombre del Fichero MADES - Marco metodológico.odt

Autor

Versión/Edición 1.0 Fecha Versión 19/03/2018

Aprobado por Fecha Aprobación

REGISTRO DE CAMBIOS

Versión Causa delCambio

Responsable delCambio Área

Fecha delCambio

CONTROL DE DISTRIBUCIÓN

Nombre y Apellidos Cargo ÁreaNº

Copias

Página 2 de 22





MADES

Marco metodológico

ÍNDICE

1 INTRODUCCIÓN ....................................................................... 4

1.1 Objeto .................................................................................................. 41.2 Alcance ................................................................................................ 51.3 Ámbito de Responsabilidades .............................................................. 51.4 Revisión de la Norma ........................................................................... 51.5 Publicación de la Norma ...................................................................... 6

2 METODOLOGÍA A SEGUIR ........................................................ 7

3 INGENIERÍA DEL SOFTWARE .................................................... 8

3.1 Fase de Estudio de Viabilidad .............................................................. 83.2 Fase de Análisis ................................................................................... 93.3 Fase de Diseño .................................................................................. 133.4 Fase de Construcción del Sistema ..................................................... 163.5 Fase de implantación y aceptación del sistema ................................ 20

Página 3 de 22





MADES

Marco metodológico

1 INTRODUCCIÓN

1.1 Objeto

La necesidad de minimizar las incidencias en producción y asegurarla mantenibilidad de los sistemas, hacen necesario disponer de unametodología que permita asegurar la calidad de los servicios yaplicaciones desarrolladas. Para ello se define un marco metodológico enel que se recoge el modelo de trabajo (normas, procedimientos, plantillas,etc.) que asegurará la calidad del software en sus distintas fases, así comola trazabilidad óptima en los proyectos.

El presente documento tiene como objetivo establecer el marcometodológico a aplicar en la ingeniería del software para el desarrollo ymantenimiento de los sistemas de la información en las distintasarquitecturas presentes en la actualidad.

El marco metodológico facilita las pautas que permitirán elcumplimiento de los siguientes objetivos:

● Conseguir que la ejecución de los distintos sistemas deinformación que se aborden sea conforme con los requisitos defuncionalidad y rendimiento expresados en:

• La correspondiente documentación contractual si es el casode un desarrollo externo.

• En el documento de inicio de proyecto que será realizado porel equipo de desarrollo (de la empresa adjudicataria o delpersonal propio de la DGTIC) al comienzo del mismo.

● Conseguir que los productos generados tanto documentales comoejecutables:

• Sean entregados en plazo

• Atiendan al formato y contenido establecidos

• Posean un nivel adecuado de calidad y profundidad

Página 4 de 22





MADES

Marco metodológico

● Conseguir que el mantenimiento de las aplicaciones resultesencillo y fácilmente abordable.

● El control sobre la ejecución de los proyectos (a través de losInformes de Seguimiento se ve cómo avanza el proyecto y segestionan los posibles riesgos).

El Marco Metodológico se concreta en estos elementos:

• Una metodología

• Unas plantillas de documentación.

1.2 Alcance

Todos los proyectos de desarrollo y mantenimiento de sistemas deinformación de la DGTIC.

1.3 Ámbito de Responsabilidades

De aplicación a los proveedores y responsables de proyectos desistemas de información de la DGTIC, así como por la unidad responsablede calidad que velará por su cumplimiento en cada sistema o aplicación.

1.4 Revisión de la Norma

La norma que describe el Marco de Desarrollo de Sistemas deInformación de la DGTIC, desarrollada en este documento será revisada deforma anual, para adaptar, corregir y ampliar en su caso tanto su alcancecomo su contenido. La unidad competente de la DGTIC será quiendetermine los responsables de la revisión, adaptación y modificación de lanorma.

Página 5 de 22





MADES

Marco metodológico

1.5 Publicación de la Norma

El presente documento, así como las revisiones, serán de dominiopúblico y se pondrá a disposición de cualquier ciudadano interesadoutilizando los medios que la DGTIC estime oportunos, preferentemente através de Internet, desde los portales de información que la Junta deExtremadura tiene de acceso público.

Página 6 de 22





MADES

Marco metodológico

2 METODOLOGÍA A SEGUIR

La Metodología a seguir en cuanto a la ingeniería del software estarábasada en METRICA v3 utilizando para el proceso de modelado el lenguajede modelado unificado UML (Unified Modeling Language) propiciado por laOMG (Object Management Group) sobre sus diagramas específicos derepresentación del modelado. Se pretende que el ciclo de vida dedesarrollo se encuentre íntegramente concebido sobre el paradigma deorientación a objetos.

Página 7 de 22





MADES

Marco metodológico

3 INGENIERÍA DEL SOFTWARE

La ingeniería describe el procedimiento de trabajo que se debe llevara cabo para el desarrollo y mantenimiento de sistemas de información,haciéndolo independiente a su tipología. Describe los productos a generaren las distintas fases estandarizando el proceso y con objeto de garantizarla calidad del producto final.

La Ingeniería del software propuesta se divide en cinco fasessecuenciales que forman el ciclo de vida de los sistemas de información:Fase de Estudio de Viabilidad, Fase de Análisis, Fases de Diseño, Fase deImplementación y Fase de Despliegue.

3.1 Fase de Estudio de Viabilidad

En esta fase se define el problema que se quiere resolver a través dela especificación de requisitos que debe cumplir la aplicación, obteniendocomo salida el Modelo de Requisitos. Para su implementación utilizaremoslos siguientes componentes:

3.1.1Modelo de Requisitos

Este modelo no tiene una representación específica en UML, por locual ha sido diseñado específicamente y representado al final de estaguía. No obstante, en este modelo se deben recoger todos los requisitosespecificados por el usuario que deba cumplir la aplicación en el momentode abordarla, plasmándolos en un documento de requerimientos quedeberá ser aceptado con su firma por los gestores proponentes. Con eltiempo los requisitos cambiarán y por tanto este modelo también lo hará.

3.1.2Modelo de casos de uso de alto nivel

Se recogen en este modelo los distintos casos de uso de laaplicación y como se resuelven estos a través de la interacción de los

Página 8 de 22





MADES

Marco metodológico

distintos actores, identificados en este paso, y el sistema, que se vaperfilando ya. Se utilizará para confeccionar este modelo el Diagrama deCasos de Uso establecido dentro de la metodología UML.

3.1.3Prototipo de interfaces de usuario

Desde el primer momento se tendrá un esbozo de la salida e interfazde la aplicación específica para cumplir con los requisitos aportados porlos usuarios y las necesidades de intercambio de información detectadas.Para este paso no hay representación recomendada en UML por lo que sedeberá recurrir a los procedimientos tradicionales de representación deentradas/salidas con formato de representación de información.

3.2 Fase de Análisis

En esta fase se aborda el análisis exhaustivo de las clases quellevarán a cabo la realización de los casos de uso. Se partirá desde elModelo de Requisitos.

3.2.1Establecimiento de los requisitos del sistema.

En esta actividad se lleva a cabo la definición, análisis y validaciónde los requisitos a partir de la información facilitada por el usuario,completándose el modelo de requisitos obtenido en la actividad anterior.El objetivo de esta actividad es obtener un catálogo detallado de losrequisitos, a partir del cual se pueda comprobar que los productosgenerados en las actividades de modelización se ajustan a los requisitosde usuario.

Se propone como técnica de obtención de requisitos, laespecificación de los casos de uso de la orientación a objetos. Dichatécnica ofrece un diagrama simple y una guía de especificación en lassesiones de trabajo con el usuario.

Página 9 de 22





MADES

Marco metodológico

3.2.2Análisis de casos de uso

En este paso y por cada caso de uso, se especificará como resuelvenlos casos de uso las diferentes clases de análisis identificadas hasta esemomento, pudiendo surgir nuevas clases de análisis que se incorporaránal catálogo anteriormente descrito. En particular para cada caso de uso sedeberá confeccionar un Diagrama de Secuencia de UML que represente larealización del caso de uso. También son recomendables los diagramas declase y de objetos. Todos los diagramas que se realicen en este paso sedeberán especificar a tres capas, es decir, para realizar un caso de uso,interactuarán con el actor las clases de presentación que se apoyarán enlos servicios de las clases de negocio y éstas a su vez obtendrán los datosnecesarios para su operativa desde las clases de datos.

Página 10 de 22

Ilustración 1: Tareas recomendadas por Metrica V3.





MADES

Marco metodológico

3.2.3Análisis de clases

En este modelo, que no es un diagrama de clases al uso, se detallancada una de las clases que van apareciendo en la realización del diagramade los casos de uso. Por tanto, este paso y el siguiente se realizarán enparalelo. No hay una representación estándar para este modelo. Noobstante las clases serán distinguidas y agrupadas en las tres capas de laarquitectura: Capa de Presentación, Capa de Negocio y Capa de Datos,teniendo por tanto como salida de este paso la localización y posteriordefinición de las clases de presentación, de las clases de negocio y de lasclases de datos.

3.2.4Especificación del plan de pruebas

En esta actividad se inicia la definición del plan de pruebas, el cualsirve como guía para la realización de las pruebas, y permite verificar queel sistema de información cumple las necesidades establecidas por elusuario, con las debidas garantías de calidad.

Página 11 de 22







MADES

Marco metodológico

El plan de pruebas es un producto formal que define los objetivos de laprueba de un sistema, establece y coordina una estrategia de trabajo, yprovee del marco adecuado para elaborar una planificación paso a paso delas actividades de prueba. El plan se inicia en la fase de análisis,definiendo el marco general, y estableciendo los requisitos de prueba deaceptación, relacionados directamente con la especificación de requisitos.

Dicho plan se va completando y detallando a medida que se avanzaen los restantes procesos del ciclo de vida del software

Se plantean los siguientes niveles de prueba:

• Pruebas unitarias.

• Pruebas de integración.

• Pruebas del sistema.

• Pruebas de implantación.

• Pruebas de aceptación.

En esta actividad también se avanza en la definición de las pruebasde aceptación del sistema. Con la información disponible, es posibleestablecer los criterios de aceptación de las pruebas incluidas en dichonivel, al poseer la información sobre los requisitos que debe cumplir elsistema, recogidos en el modelo de requisitos.

Página 12 de 22






MADES

Marco metodológico

3.3 Fase de Diseño

Pasamos a definir en esta fase las clases que habrán de serimplementadas. Mientras que en la fase anterior nos preocupábamos decubrir los requisitos mediante la realización de los casos de usoidentificados en la Fase de Estudio de viabilidad y a través de las clases deanálisis, en esta fase se detallarán las clases anteriores, debiendo surgirnuevas clases auxiliares de apoyo para la programación, así comointerfaces internas para la interacción entre clases. En suma, se detallaránlos métodos y atributos en su totalidad de cada una de las clases para suposterior implementación en cualquier lenguaje POO.

3.3.1Diseño de casos de uso reales

Se abordará nuevamente la realización de los casos de usoutilizando para ello los Diagramas de Secuencia de UML por cada caso deuso. Las nuevas clases que vayan surgiendo de apoyo o complementariasse incorporarán al catálogo de las clases de diseño listas para serprogramadas.

Página 13 de 22





MADES

Marco metodológico

3.3.2Diseño de las clases

Sin representación específica, se pretende detallar las clases dediseño a través de un diagrama de clases. Sin embargo, comoconsecuencia del modelo a tres capas, se distinguirán y agruparán lasclases de presentación (que formarán la interfaz de usuario definitiva), lasclases de negocio y las clases de datos. Se tienen en cuenta las decisionestomadas sobre el entorno tecnológico y el entorno de desarrollo elegidopara la implementación.

Otro de los objetivos del diseño de las clases es identificar para cadaclase, los atributos, las operaciones que cubren las responsabilidades quese identificaron en el análisis, y la especificación de los métodos queimplementan esas operaciones, analizando los escenarios del Diseño deCasos de Uso Reales. Se determina la visibilidad de los atributos yoperaciones de cada clase, con respecto a las otras clases del modelo.

Página 14 de 22






MADES

Marco metodológico

Para aquellos sistemas que utilicen para almacenar información unSGDBR se obtendrá el Modelo Conceptual de Datos: Diagrama entidad/relación

3.3.3Diseño físico de datos

En esta actividad se define la estructura física de datos que utilizaráel sistema, a partir del modelo lógico de datos normalizado o modelo declases, de manera que teniendo presentes las características específicasdel sistema de gestión de datos concreto a utilizar, los requisitosestablecidos para el sistema de información, y las particularidades delentorno tecnológico, se consiga una mayor eficiencia en el tratamiento delos datos.

También se analizan los caminos de acceso a los datos utilizados porcada módulo/clase del sistema en consultas y actualizaciones, con el finde mejorar los tiempos de respuesta y optimizar los recursos de máquina.

Modelo de datos

Página 15 de 22






MADES

Marco metodológico

Con los casos de uso ya resueltos a partir de las clases que se van aimplementar, necesitaremos por último realizar el modelo de datos quedefine los datos y su almacenamiento. Este paso suele ser inicial en otrasmetodologías. Se obtendrá como salida dos modelos:

• Modelo Lógico de datos: Diagrama relacional.

• Modelo Físico de datos: Diagrama de tablas.

En los sistemas que utilicen para almacenar su información unSGBDR los modelos anteriores se obtendrán como reducción del modeloEntidad/Relación. En este caso se recomienda que la estructura física delos datos obtenidos cumplan, al menos, la tercera forma normal (3FN)como garantía de normalización de datos.

3.4 Fase de Construcción del Sistema

En este proceso se genera el código de los componentes del Sistemade Información, se desarrollan todos los procedimientos de operación yseguridad y se elaboran todos los manuales de usuario final y deexplotación con el objetivo de asegurar el correcto funcionamiento delSistema para su posterior implantación.

Para conseguir dicho objetivo, en este proceso se realizan laspruebas unitarias, las pruebas de integración de los subsistemas ycomponentes y las pruebas del sistema, de acuerdo al plan de pruebasestablecido.

Asimismo, se define la formación de usuario final y, si procede, seconstruyen los procedimientos de migración y carga inicial de datos.

3.4.1Generación del código de los componentes

El objetivo de esta actividad es la codificación de los componentesdel sistema del información, a partir de las especificaciones deconstrucción obtenidas en el proceso Diseño del Sistema de Información(DSI), así como la construcción de los procedimientos de operación yseguridad establecidos para el mismo.

Página 16 de 22





MADES

Marco metodológico

En paralelo a esta actividad, se desarrollan las actividadesrelacionadas con las pruebas unitarias y de integración del sistema deinformación. Esto permite una construcción incremental, en el caso de queasí se haya especificado en el plan de pruebas y en el plan de integracióndel sistema de información.

3.4.2Ejecución de pruebas unitarias

En esta actividad se realizan las pruebas unitarias de cada uno delos componentes del sistema de información, una vez codificados, con elobjeto de comprobar que su estructura es correcta y que se ajustan a lafuncionalidad establecida.

En el plan de pruebas se ha definido el entorno necesario para larealización de cada nivel de prueba, así como las verificaciones asociadasa las pruebas unitarias, la coordinación y secuencia a seguir en laejecución de las mismas y los criterios de registro y aceptación de losresultados.

Página 17 de 22






MADES

Marco metodológico

3.4.3Ejecución de pruebas de integración

El objetivo de las pruebas de integración es verificar si loscomponentes o subsistemas interactúan correctamente a través de susinterfaces, tanto internas como externas, cubren la funcionalidadestablecida, y se ajustan a los requisitos especificados en lasverificaciones correspondientes.

La estrategia a seguir en las pruebas de integración se establece enel plan de pruebas, dónde se habrá tenido en cuenta el plan deintegración del sistema de información.

Esta actividad se realiza en paralelo a las actividades Generación delCódigo de los Componentes y Procedimientos y Ejecución de las PruebasUnitarias. Sin embargo, es necesario que los componentes objeto de laspruebas de integración se hayan verificado de manera unitaria.

Página 18 de 22







MADES

Marco metodológico

3.4.4Ejecución de pruebas de sistemas

El objetivo de las pruebas del sistema es comprobar la integracióndel sistema de información globalmente, verificando el funcionamientocorrecto de las interfaces entre los distintos subsistemas que lo componeny con el resto de sistemas de información con los que se comunica.

En la realización de estas pruebas es importante comprobar lacobertura de los requisitos, dado que su incumplimiento puedecomprometer la aceptación del sistema por el equipo de operaciónresponsable de realizar las pruebas de implantación del sistema, que sellevarán a cabo en el proceso Implantación y Aceptación del Sistema.

3.4.5Manual de usuario

Página 19 de 22






MADES

Marco metodológico

3.5 Fase de implantación y aceptación del sistema

Esta fase final materializa sobre los sistemas responsables desoportar la aplicación desarrollada todos los componentes que permitenque aquella opere en la forma en que ha sido diseñada:

3.5.1Pruebas de implantación

La finalidad de las pruebas de implantación es doble:

• Comprobar el funcionamiento correcto del mismo en el entorno deoperación.

• Permitir que el usuario determine, desde el punto de vista deoperación, la aceptación del sistema instalado en su entorno real,según el cumplimiento de los requisitos especificados.

Para ello, el responsable de implantación revisa el plan de pruebasde implantación y los criterios de aceptación del sistema, previamenteelaborados. Las pruebas las realizan los técnicos de sistemas y deoperación, que forman parte del grupo de usuarios técnicos que harecibido la formación necesaria para llevarlas a cabo.

Una vez ejecutadas estas pruebas, el equipo de usuarios técnicosinforma de las incidencias detectadas al responsable de implantación, elcual analiza la información y toma las medidas correctoras que considere

Página 20 de 22






MADES

Marco metodológico

necesarias para que el sistema dé respuesta a las especificacionesprevistas, momento en el que el equipo de operación lo da por probado.

3.5.2Pruebas de aceptación

Será necesario disponer de un entorno de pre-producciónperfectamente instalado en cuanto a hardware y software de base, asícomo los componentes del nuevo sistema, para realizar estas pruebas.

Las pruebas de aceptación tienen como fin validar que el sistemacumple los requisitos básicos de funcionamiento esperado y permitir queel usuario determine la aceptación del sistema.

Por este motivo, estas pruebas son realizadas por el usuario finalque, durante este periodo de tiempo, debe plantear todas las deficienciaso errores que encuentre antes de dar por aprobado el sistemadefinitivamente.

Los Directores de los Usuarios revisan los criterios de aceptación,especificados previamente en el plan de pruebas del sistema, y dirigen laspruebas de aceptación final que llevan a cabo los usuarios expertos. A suvez, éstos últimos deben elaborar un informe que los Directores de losUsuarios analizan y evalúan para determinar la aceptación o rechazo delsistema.

Página 21 de 22






MADES

Marco metodológico

3.5.3Paso a producción

Esta actividad tiene como objetivo establecer el punto de inicio enque el sistema pasa a producción, se traspasa la responsabilidad al equipode mantenimiento y se empiezan a dar los servicios establecidos en elacuerdo de nivel de servicio, una vez que el Comité de Dirección haaprobado el sistema.

Para ello es necesario que, después de haber realizado las pruebasde implantación y de aceptación del sistema, se disponga del entorno deproducción perfectamente instalado en cuanto a hardware y software debase, componentes del nuevo sistema y procedimientos manuales yautomáticos. En función del entorno en el que se hayan llevado a cabo laspruebas de implantación y aceptación del sistema, habrá que instalar loscomponentes del sistema total o parcialmente. También se tendrá encuenta la necesidad de migrar todos los datos o una parte de ellos. Unavez que el sistema ya está en producción, se le notifica al responsable demantenimiento, al responsable de operación y al Comité de Dirección.

Se utilizará como técnica el diagrama de despliegue.

Página 22 de 22



Marco metodológico - Extremadura · 2018-03-21 · basada en METRICA v3 utilizando para el proceso...

Documents

Transcript of Marco metodológico - Extremadura · 2018-03-21 · basada en METRICA v3 utilizando para el proceso...