Ingenieria Software Gobex

Direccin General de
Administracin Electrnica y Tecnologas de la

Informacin
GOBIERNO DE EXTREMADURA
Servicio de Desarrollo de Proyectos
Metodologa de
Ingeniera del Software
para el desarrollo y
mantenimiento de
sistemas de
informacin del
Gobierno de
Extremadura
Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Gobierno de Extremadura
Pgina 1 de 23
Direccin General de
Informacin
ndice del Documento
1.- Introduccin .............................................. Pgina 4

2.- Propuesta de metodologa ........................... Pgina 4
3.- Ingeniera del software ............................... Pgina 6
3.1. Fase de Estudio de Viabilidad ................... Pgina 6
3.2. Fase de Anlisis ...................................... Pgina 7
3.3. Fase de Diseo ....................................... Pgina 10
3.4. Fase de Construccin del Sistema .............. Pgina 13
3.5.
Fase de implantacin y aceptacin del Pgina 17

sistema .................................................
4. Arquitectura ............................................... Pgina 19

5.- Lenguajes de programacin ......................... Pgina 22
6. Integracin con el proyecto e-GobEx .............. Pgina 22

Pgina 2 de 23
Direccin General de
Informacin
Control de versiones
Versin
Responsable
Observaciones
Fecha
SDP
Revisin del documento Plataforma

Corporativa
de
Aplicaciones
Informtica PCDAI.
Junio
2014
Borrador
SDP
Versin borrador del documento
Junio
2014
1.0
SDP
Versin inicial del documento
Julio
2014

Pgina 3 de 23
Direccin General de
Informacin
1.-Introduccin
El presente documento tiene como objetivo establecer la metodologa a
aplicar en la ingeniera del software para el desarrollo y mantenimiento de
sistemas de informacin el Gobierno de Extremadura en las distintas
arquitecturas presentes en la actualidad.
Como caracterstica principal de esta metodologa cabe destacar su
concepcin como metodolgica basada en el paradigma de orientacin a
objetos. Este paradigma por lo tanto nos har abandonar las concepciones
metodolgicas y los lenguajes de programacin tradicionales del desarrollo
estructurado y orientado a datos o funciones.
2.- Propuesta de metodologa
La Metodologa en cuestin constar de cuatro aspectos diferenciados

sobre los que hay que definir los criterios propios a aplicar: Ingeniera del
Software, Arquitectura, Lenguajes de programacin y pautas para la
integracin con la Plataforma de Administracin Electrnica de la Junta de
Extremadura. Se introducen de manera genrica cada uno de estos aspectos
que requerirn un detalle en captulos posteriores de este documento:
Ingeniera del Software

La ingeniera que se propone estar basada en METRICA v.3 utilizando
para el proceso de modelado el lenguaje de modelado unificado UML (Unified
Modeling Language) propiciado por la OMG (Object Management Group) sobre
sus diagramas especficos de representacin del modelado. Se pretende que el
ciclo de vida de desarrollo se encuentre ntegramente concebido sobre el
paradigma de orientacin a objetos.

Pgina 4 de 23
Direccin General de
Informacin
Arquitectura
La Arquitectura definir la forma de abordar el diseo de los
componentes definidos por la Ingeniera, en este caso sern las clases
identificadas. Mientras que en la Ingeniera definimos los pasos que hay que
seguir, en la Arquitectura se definirn aspectos relacionados con la ordenacin
e interrelacin entre las clases. Estar basada en la arquitectura de mltiples
capas especializadas en tareas especficas.
Leguajes de programacin
Dado que todo el desarrollo de aplicaciones estar basado en el
paradigma de orientacin a objetos, se hace necesario la utilizacin de
lenguajes concebidos para la programacin orientada a objetos o que la
soporten debidamente.
Integracin con la plataforma e-GobEx
En los proyectos en los que as se determine en orden a los

requerimientos funcionales establecidos en los documentos tcnicos, sern de
uso obligatorio los servicios corporativos para la integracin con el proyecto de
administracin electrnica (e-GobEx)

Pgina 5 de 23
Direccin General de
Informacin
3.- Ingeniera del Software
La ingeniera describe el procedimiento de trabajo que se

cabo para el desarrollo y mantenimiento de sistemas de
hacindolo independiente a su tipologa. Describe los productos
las distintas fases estandarizando el proceso y con objeto de
calidad del producto final.
debe llevar a
informacin,
a generar en
garantizar la
La Ingeniera del software propuesta se divide en cinco fases

secuenciales que forman el ciclo de vida de los sistemas de informacin: Fase
de Estudio de Viabilidad, Fase de Anlisis, Fases de Diseo, Fase de
Implementacin y Fase de Despliegue.
3.1.- Fase de estudio de viabilidad
En esta fase se define el problema que se quiere resolver a travs de la

especificacin de requisitos que debe cumplir la aplicacin. Obteniendo como
salida el Modelo de Requisitos.
Para su implementacin utilizaremos los siguientes componentes:
Modelo de Requisitos
Este modelo no tiene una representacin especfica en UML, por lo cual
ha sido diseado especficamente y representado al final de esta gua. No
obstante, en este modelo se deben recoger todos los requisitos especificados
por el usuario que deba cumplir la aplicacin en el momento de abordarla,
plasmndolos en un documento de requerimientos que deber ser aceptado
con su firma por los gestores proponentes. Con el tiempo los requisitos
cambiarn y por tanto este modelo tambin lo har.
Modelo de casos de uso de alto nivel

Pgina 6 de 23
Direccin General de
Informacin
Se recogen en este modelo los distintos casos de uso de la aplicacin y

como se resuelven estos a travs de la interaccin de los distintos actores,
identificados en este paso, y el sistema, que se va perfilando ya. Se utilizar
para confeccionar este modelo el Diagrama de Casos de Uso establecido dentro
de la metodologa UML.
Prototipo de interfaces de usuario
Desde el primer momento se tendr un esbozo de la salida e interfaz de
la aplicacin especfica para cumplir con los requisitos aportados por los
usuarios y las necesidades de intercambio de informacin detectadas. Para
este paso no hay representacin recomendada en UML por lo que se deber
recurrir
a
los
procedimientos
tradicionales
de
representacin
de
entradas/salidas con formato de representacin de informacin.
3.2.- Fase de Anlisis

En esta fase se aborda el anlisis exhaustivo de las clases que llevarn a
cabo la realizacin de los casos de uso. Se partir desde el Modelo de
Requisitos.
Establecimiento de los requisitos del sistema.
En esta actividad se lleva a cabo la definicin, anlisis y validacin de los
requisitos a partir de la informacin facilitada por el usuario, completndose el
modelo de requisitos obtenido en la actividad anterior. El objetivo de esta
actividad es obtener un catlogo detallado de los requisitos, a partir del cual se
pueda comprobar que los productos generados en las actividades de
modelizacin se ajustan a los requisitos de usuario.
Se propone como tcnica de obtencin de requisitos, la especificacin de los
casos de uso de la orientacin a objetos. Dicha tcnica ofrece un diagrama
simple y una gua de especificacin en las sesiones de trabajo con el usuario.

Pgina 7 de 23
Direccin General de
Informacin
Ilustracin 1: Tareas recomendadas por Metrica V3.

Anlisis de casos de uso
En este paso y por cada caso de uso, se especificar como resuelven los
casos de uso las diferentes clases de anlisis identificadas hasta ese momento,
pudiendo surgir nuevas clases de anlisis que se incorporarn al catlogo
anteriormente descrito. En particular para cada caso de uso se deber
confeccionar un Diagrama de Secuencia de UML que represente la realizacin
del caso de uso. Tambin son recomendables los diagramas de clase y de
objetos. Todos los diagramas que se realicen en este paso se debern
especificar a tres capas, es decir, para realizar un caso de uso, interactuarn
con el actor las clases de presentacin que se apoyarn en los servicios de las
clases de negocio y stas a su vez obtendrn los datos necesarios para su
operativa desde las clases de datos.

Pgina 8 de 23
Direccin General de
Informacin
Anlisis de clases
En este modelo, que no es un diagrama de clases al uso, se detallan cada
una de las clases que van apareciendo en la realizacin del diagrama de los
casos de uso. Por tanto, este paso y el siguiente se realizarn en paralelo. No
hay una representacin estndar para este modelo. No obstante las clases
sern distinguidas y agrupadas en las tres capas de la arquitectura: Capa de
Presentacin, Capa de Negocio y Capa de Datos, teniendo por tanto como
salida de este paso la localizacin y posterior definicin de las clases de
presentacin, de las clases de negocio y de las clases de datos.

Especificacin del plan de pruebas
En esta actividad se inicia la definicin del plan de pruebas, el cual sirve
como gua para la realizacin de las pruebas, y permite verificar que el sistema
de informacin cumple las necesidades establecidas por el usuario, con las
debidas garantas 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 del
marco adecuado para elaborar una planificacin paso a paso de las actividades
de prueba. El plan se inicia en la fase de anlisis, definiendo el marco general,
y estableciendo los requisitos de prueba de aceptacin, relacionados
directamente con la especificacin de requisitos.
Dicho plan se va completando y detallando a medida que se avanza en
los restantes procesos del ciclo de vida del software
Se plantean los siguientes niveles de prueba:
Pruebas unitarias.
Pgina 9 de 23
Direccin General de
Informacin
Pruebas
Pruebas
Pruebas
Pruebas
de integracin.
del sistema.
de implantacin.
de aceptacin.
En esta actividad tambin se avanza en la definicin de las pruebas de

aceptacin del sistema. Con la informacin disponible, es posible establecer los
criterios de aceptacin de las pruebas incluidas en dicho nivel, al poseer la
informacin sobre los requisitos que debe cumplir el sistema, recogidos en el
modelo de requisitos.
3.3.- Fase de Diseo

Pasamos a definir en esta fase las clases que habrn de ser
implementadas. Mientras que en la fase anterior nos preocupbamos de cubrir
los requisitos mediante la realizacin de los casos de uso identificados en la
Fase de Estudio de viabilidad y a travs de las clases de anlisis, en esta fase
se detallarn las clases anteriores, debiendo surgir nuevas clases auxiliares de
apoyo para la programacin, as como interfaces internas para la interaccin
entre clases. En suma, se detallarn los mtodos y atributos en su totalidad de
Pgina 10 de 23
Direccin General de
Informacin
cada una de las clases para su posterior implementacin en cualquier lenguaje

POO.
Diseo de casos de uso reales
Se abordar nuevamente la realizacin de los casos de uso utilizando
para ello los Diagramas de Secuencia de UML por cada caso de uso. Las nuevas
clases que vayan surgiendo de apoyo o complementarias se incorporarn al
catlogo de las clases de diseo listas para ser programadas.

Diseo de las clases
Sin representacin especfica, se pretende detallar las clases de diseo a
travs de un diagrama de clases. Sin embargo, como consecuencia del modelo
a tres capas, se distinguirn y agruparn las clases de presentacin (que
formarn la interfaz de usuario definitiva), las clases de negocio y las clases de
Pgina 11 de 23
Direccin General de
Informacin
datos. Se tienen en cuenta las decisiones tomadas sobre el entorno tecnolgico

y el entorno de desarrollo elegido para la implementacin.
Otro de los objetivos del diseo de las clases es identificar para cada
clase, los atributos, las operaciones que cubren las responsabilidades que se
identificaron en el anlisis, y la especificacin de los mtodos que implementan
esas operaciones, analizando los escenarios del Diseo de Casos de Uso
Reales. Se determina la visibilidad de los atributos y operaciones de cada
clase, con respecto a las otras clases del modelo.
Para aquellos sistemas que utilicen para almacenar informacin un
SGDBR se obtendr el Modelo Conceptual de Datos: Diagrama
entidad/relacin.

Diseo fsico de datos
En esta actividad se define la estructura fsica de datos que utilizar el
sistema, a partir del modelo lgico de datos normalizado o modelo de clases,
de manera que teniendo presentes las caractersticas especficas del sistema
Pgina 12 de 23
Direccin General de
Informacin
de gestin de datos concreto a utilizar, los requisitos establecidos para el

sistema de informacin, y las particularidades del entorno tecnolgico, se
consiga una mayor eficiencia en el tratamiento de los datos.
Tambin se analizan los caminos de acceso a los datos utilizados por
cada mdulo/clase del sistema en consultas y actualizaciones, con el fin de
mejorar los tiempos de respuesta y optimizar los recursos de mquina.
Modelo de datos
Con los casos de uso ya resueltos a partir de las clases que se van a
implementar, necesitaremos por ltimo realizar el modelo de datos que define
los datos y su almacenamiento. Este paso suele ser inicial en otras
metodologas. Se obtendr como salida dos modelos:
Modelo Lgico de datos: Diagrama relacional.
Modelo Fsico de datos: Diagrama de tablas.
En los sistemas que utilicen para almacenar su informacin un SGBDR los
modelos anteriores se obtendrn como reduccin del modelo Entidad/Relacin.
En este caso se recomienda que la estructura fsica de los datos obtenidos
cumplan, al menos, la tercera forma normal (3FN) como garanta de
normalizacin de datos.
3.4.- Fase de Construccin del Sistema

En este proceso se genera el cdigo de los componentes del Sistema de
Informacin, se desarrollan todos los procedimientos de operacin y seguridad
y se elaboran todos los manuales de usuario final y de explotacin con el
objetivo de asegurar el correcto funcionamiento del Sistema para su posterior
implantacin.
Para conseguir dicho objetivo, en este proceso se realizan las pruebas
unitarias, las pruebas de integracin de los subsistemas y componentes y las
pruebas del sistema, de acuerdo al plan de pruebas establecido.
Asimismo, se define la formacin de usuario final y, si procede, se
construyen los procedimientos de migracin y carga inicial de datos.
Generacin del cdigo de los componentes
El objetivo de esta actividad es la codificacin de los componentes del
Pgina 13 de 23
Direccin General de
Informacin
sistema del informacin, a partir de las especificaciones de construccin

obtenidas en el proceso Diseo del Sistema de Informacin (DSI), as como la
construccin de los procedimientos de operacin y seguridad establecidos para
el mismo.
En paralelo a esta actividad, se desarrollan las actividades relacionadas
con las pruebas unitarias y de integracin del sistema de informacin. Esto
permite una construccin incremental, en el caso de que as se haya
especificado en el plan de pruebas y en el plan de integracin del sistema de
informacin.

Ejecucin de pruebas unitarias
En esta actividad se realizan las pruebas unitarias de cada uno de los
componentes del sistema de informacin, una vez codificados, con el objeto de
comprobar que su estructura es correcta y que se ajustan a la funcionalidad
establecida.
En el plan de pruebas se ha definido el entorno necesario para la
realizacin de cada nivel de prueba, as como las verificaciones asociadas a las
pruebas unitarias, la coordinacin y secuencia a seguir en la ejecucin de las
mismas y los criterios de registro y aceptacin de los resultados.

Pgina 14 de 23
Direccin General de
Informacin

Ejecucin de pruebas de integracin
El objetivo de las pruebas de integracin es verificar si los componentes o
subsistemas interactan correctamente a travs de sus interfaces, tanto
internas como externas, cubren la funcionalidad establecida, y se ajustan a los
requisitos especificados en las verificaciones correspondientes.
La estrategia a seguir en las pruebas de integracin se establece en el
plan de pruebas, dnde se habr tenido en cuenta el plan de integracin del
sistema de informacin.
Esta actividad se realiza en paralelo a las actividades Generacin del
Cdigo de los Componentes y Procedimientos y Ejecucin de las Pruebas
Unitarias. Sin embargo, es necesario que los componentes objeto de las
pruebas de integracin se hayan verificado de manera unitaria.

Pgina 15 de 23
Direccin General de
Informacin
Ejecucin de pruebas de sistemas

El objetivo de las pruebas del sistema es comprobar la integracin del
sistema de informacin globalmente, verificando el funcionamiento correcto de
las interfaces entre los distintos subsistemas que lo componen y con el resto
de sistemas de informacin con los que se comunica.
En la realizacin de estas pruebas es importante comprobar la cobertura
de los requisitos, dado que su incumplimiento puede comprometer la
aceptacin del sistema por el equipo de operacin responsable de realizar las
pruebas de implantacin del sistema, que se llevarn a cabo en el proceso
Implantacin y Aceptacin del Sistema.

Manual de usuario

Pgina 16 de 23
Direccin General de
Informacin
3.5.- Fase de implantacin y aceptacin del sistema
Esta fase final materializa sobre los sistemas responsables de soportar la

aplicacin desarrollada todos los componentes que permiten que aquella opere
en la forma en que ha sido diseada:
Pruebas de implantacin
La finalidad de las pruebas de implantacin es doble:
Comprobar el funcionamiento correcto del mismo en el entorno de
operacin.
Permitir que el usuario determine, desde el punto de vista de operacin,
la aceptacin del sistema instalado en su entorno real, segn el
cumplimiento de los requisitos especificados.
Para ello, el responsable de implantacin revisa el plan de pruebas de
implantacin y los criterios de aceptacin del sistema, previamente elaborados.
Las pruebas las realizan los tcnicos de sistemas y de operacin, que forman
parte del grupo de usuarios tcnicos que ha recibido la formacin necesaria
para llevarlas a cabo.
Una vez ejecutadas estas pruebas, el equipo de usuarios tcnicos
informa de las incidencias detectadas al responsable de implantacin, el cual
analiza la informacin y toma las medidas correctoras que considere necesarias
para que el sistema d respuesta a las especificaciones previstas, momento en
el que el equipo de operacin lo da por probado.

Pruebas de aceptacin
Pgina 17 de 23
Direccin General de
Informacin
Ser necesario disponer de un entorno de pre-produccin perfectamente

instalado en cuanto a hardware y software de base, as como los componentes
del nuevo sistema, para realizar estas pruebas.
Las pruebas de aceptacin tienen como fin validar que el sistema cumple
los requisitos bsicos de funcionamiento esperado y permitir que el usuario
determine la aceptacin del sistema.
Por este motivo, estas pruebas son realizadas por el usuario final que,
durante este periodo de tiempo, debe plantear todas las deficiencias o errores
que encuentre antes de dar por aprobado el sistema definitivamente.
Los Directores de los Usuarios revisan los criterios de aceptacin,
especificados previamente en el plan de pruebas del sistema, y dirigen las
pruebas de aceptacin final que llevan a cabo los usuarios expertos. A su vez,
stos ltimos deben elaborar un informe que los Directores de los Usuarios
analizan y evalan para determinar la aceptacin o rechazo del sistema.

Paso a produccin
Esta actividad tiene como objetivo establecer el punto de inicio en que el
sistema pasa a produccin, se traspasa la responsabilidad al equipo de
mantenimiento y se empiezan a dar los servicios establecidos en el acuerdo de
nivel de servicio, una vez que el Comit de Direccin ha aprobado el sistema.
Para ello es necesario que, despus de haber realizado las pruebas de
implantacin y de aceptacin del sistema, se disponga del entorno de
produccin perfectamente instalado en cuanto a hardware y software de base,
componentes del nuevo sistema y procedimientos manuales y automticos. En
funcin del entorno en el que se hayan llevado a cabo las pruebas de
implantacin y aceptacin del sistema, habr que instalar los componentes del
sistema total o parcialmente. Tambin se tendr en cuenta la necesidad de
migrar todos los datos o una parte de ellos. Una vez que el sistema ya est en
Pgina 18 de 23
Direccin General de
Informacin
produccin, se le notifica al responsable de mantenimiento, al responsable de

operacin y al Comit de Direccin.

Se utilizar como tcnica el diagrama de despliegue.
4.- Arquitectura
La arquitectura propuesta en esta metodologa est basada en la
arquitectura clsica de tres capas: Presentacin, Negocio o Control y Datos.
Capa de presentacin
La capa de presentacin ofrece la interfaz de la aplicacin con la que
interacta el usuario. En esta capa se programar todo el cdigo, todas las
clases en programacin orientada a objetos, cuya finalidad sea validar datos de
entrada, controlar la navegacin y acceso a los distintos servicios de las
aplicaciones. En programacin WEB constituira la parte del cdigo destinada a
generar el cdigo HTML que conformaran las pginas WEB. No debe haber
ningn cdigo de lgica de negocio o de consulta de datos en la capa de
presentacin. El acceso a cdigo de negocio desde las clases de la capa de
presentacin se har a travs de mensajes a las clases de la capa de negocio.
El objetivo principal de esta capa es hacer independiente la aplicacin del
medio de visualizacin, de tal forma que se pueda programar una capa de
presentacin para salida hacia un navegador, consola, PDA, etc. sin necesidad
de hacer ningn cambio en las capas de negocio o de datos.
En particular, la programacin WEB se har a travs de un sistema o
framework de plantillas: un refinamiento ms de la capa de presentacin que

Pgina 19 de 23
Direccin General de
Informacin
independiza al diseador grfico del programador dedicado a controlar el flujo

de navegacin.
Capa de negocio
En esta capa se ubicar el cdigo especfico de control de la aplicacin.
Esta capa sustenta la lgica de negocio. Sus clases tienen dos objetivos
fundamentales interrelacionados: por un lado realizar los clculos,
transformaciones y controles inherentes a la cobertura de los requisitos
exigidos a la aplicacin y por otro lado servir las necesidades bsicas de datos
de la capa de presentacin a travs de mensajes a las clases de la capa de
datos. No debe haber ningn cdigo de visualizacin de informacin o de
consulta de datos en la capa de negocio.
Capa de datos
La capa de datos es la que encuentra en el nivel ms bajo de la
arquitectura y su nico fin es proporcionar el acceso a los datos para servir las
peticiones de la capa de negocio. Su objetivo fundamental es hacer
independiente la aplicacin de los sistemas de almacenamiento de datos, bien
sean SGBD, ficheros planos, sistemas jerrquicos, etc.
Es absolutamente necesario contar aqu con un framework de acceso a
datos: un refinamiento de la capa de datos que independiza las consultas de
datos del sistema de almacenamiento. Por ejemplo, en la capa de datos
podramos tener consultas SQL que se ejecuten contra cualquier SGBDR sin
cambiar nada en el cdigo de las clases de la capa de datos.

Pgina 20 de 23
Direccin General de
Informacin
Plantillas Formulario
Valores de los campos
PRESENTACION
Plantillas WEB
Cdigo
XHTML
Clases de
presentacin
Ejecucin de Accin
Datos formateados
D
E
Clases de
negocio
NEGOCIO
S
E
G
U
R
I
D
A
D
Solicitud de Informacin
Tabla de datos
Clases de
datos
DATOS
Cdigo SQL
I
N
T
E
R
F
A
Z
Puntero a resultado
Acceso a datos
...
Almacenes de datos: PostgreSQL,

MySQL, ORACLE, XML,
Ficheros, Estr. Jerrquicas, etc.

Pgina 21 de 23
Direccin General de
Informacin
5.- Lenguajes de programacin

Dada la gran diversidad de sistemas de informacin que componen el
catlogo de activos del Gobierno de Extremadura, y la particularidad de las
necesidades demandadas por los servicios gestores, en cada proyecto el
Director Tcnico del mismo deber especificar los criterios a seguir en este
sentido. Se dispondr para ello de documentos tcnicos especficos que
determinen las especificaciones tcnicas a seguir en el uso de los distintos
lenguajes de programacin, gestores de contenidos, etc. que debern ser
utilizadas en cada proyecto.
Sin menos cabo de lo anterior cabe mencionar que se deber optar de
manera preferente por el uso de Java y su plataforma Java EE, por criterios
como el posicionamiento global de las plataformas sobre la que se integra, el
compromiso adquirido por la Junta de Extremadura con su apoyo al software
libre, la amplitud de la comunidad que aporta herramientas complementarias y
frameworks de agilizacin de tareas, el soporte para diversidad de fabricantes,
portabilidad, etc. que hacen que esta opcin sea la ms adecuada segn los
criterios tcnicos de la Junta de Extremadura.
6.- Integracin con e-GobEx

La plataforma de administracin electrnica e-GobEx proporciona al resto
de sistemas de informacin una serie de servicios corporativos que aportan
funcionalidades comunes. Con este objetivo tambin se pretende ordenar,
coordinar y reducir los esfuerzos necesarios en el desarrollo y mantenimiento
de proyectos, evitando que aplicativos diferentes implementen funcionalidades
similares que pueden considerarse como corporativas.
Este conjunto de servicios corporativos son de uso OBLIGATORIO por el
resto de aplicativos informticos de la Junta de Extremadura, y no se admitirn
aplicaciones que implementen funcionalidades similares a las descritas por los
mismos.
Entre los servicios que ofrece la plataforma e-GobEx podemos destacar los
siguientes:
Pgina 22 de 23
Direccin General de
Informacin
Autenticacin Corporativa: sistema de autenticacin que incluye

todos los usuarios que necesitan acceder a aplicaciones de la
Junta de Extremadura.
Sistema de Registro nico: este sistema implementa las
funcionalidades de registro de documentos tanto de entrada
como de salida. Incluye los servicios necesarios para registrar
un documento de entrada/salida, devolviendo el nmero de
registro asignado y la fecha y hora de realizacin del asiento
registral.
Nere@: en caso de que el aplicativo informtico a desarrollar
incluya la gestin de procedimientos administrativos de la Junta
de Extremadura.
Notific@: para cualquier comunicacin o notificacin que el
nuevo aplicativo deba enviar se utilizar este sistema de
notificaciones corporativo.
Pasarela de Pagos: este mdulo permite realizar cargos en
cuentas bancarias de administrados, asociadas a trmites o
gestiones administrativas.
Portafirmas: este sistema permite realizar la firma electrnica
de documentos por parte del personal de la Junta de
Extremadura con competencias para ello.
Validacin de certificados: la Plataforma tambin provee de una
serie de servicios de validacin de certificados electrnicos
utilizados dentro de la organizacin.
Para el uso e integracin de estos servicios, el Servicio de Desarrollo de

Proyectos proporcionar la informacin detallada sobre los servicios web a
utilizar en cada caso.
El Servicio de Desarrollo de Proyectos, a travs del Director Tcnico
nombrado en cada caso, revisar con las empresas adjudicatarias de servicios
cuantos trminos estn contenidos en el presente documento, as como los
contenidos en los documentos tcnicos especficos proporcionados en cada
caso, pudiendo acordar sobre los productos contenidos en ellos el uso de
versiones distintas a las contenidas en los documentos.

Pgina 23 de 23

Ingenieria Software Gobex

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ingenieria Software Gobex

Încărcat de

Drepturi de autor:

Formate disponibile

Direccin General de

Administracin Electrnica y Tecnologas de la

Servicio de Desarrollo de Proyectos

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

ndice del Documento

1.- Introduccin .............................................. Pgina 4

Fase de implantacin y aceptacin del Pgina 17

4. Arquitectura ............................................... Pgina 19

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

Revisin del documento Plataforma

Versin borrador del documento

Versin inicial del documento

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

2.- Propuesta de metodologa

La Metodologa en cuestin constar de cuatro aspectos diferenciados

Ingeniera del Software

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

Integracin con la plataforma e-GobEx

En los proyectos en los que as se determine en orden a los

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

3.- Ingeniera del Software

La ingeniera describe el procedimiento de trabajo que se

La Ingeniera del software propuesta se divide en cinco fases

3.1.- Fase de estudio de viabilidad

En esta fase se define el problema que se quiere resolver a travs de la

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

Se recogen en este modelo los distintos casos de uso de la aplicacin y

3.2.- Fase de Anlisis

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

Ilustracin 1: Tareas recomendadas por Metrica V3.

Ilustracin 2: Tareas recomendadas por Metrica V3.

Servicio de Desarrollo de Proyectos

Ilustracin 3: Tareas recomendadas por Metrica V3.

Servicio de Desarrollo de Proyectos

En esta actividad tambin se avanza en la definicin de las pruebas de

Ilustracin 4: Tareas recomendadas por Metrica V3.

3.3.- Fase de Diseo

Servicio de Desarrollo de Proyectos

cada una de las clases para su posterior implementacin en cualquier lenguaje

Ilustracin 5: Tareas recomendadas por Metrica V3.

Servicio de Desarrollo de Proyectos

datos. Se tienen en cuenta las decisiones tomadas sobre el entorno tecnolgico

Ilustracin 6: Tareas recomendadas por Metrica V3.

Servicio de Desarrollo de Proyectos

de gestin de datos concreto a utilizar, los requisitos establecidos para el

3.4.- Fase de Construccin del Sistema

Servicio de Desarrollo de Proyectos

sistema del informacin, a partir de las especificaciones de construccin

Ilustracin 7: Tareas recomendadas por Metrica V3.

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

Ilustracin 8: Tareas recomendadas por Metrica V3.

Ilustracin 9: Tareas recomendadas por Metrica V3.

Metodologa de Ingeniera del Software para el desarrollo de sistemas de informacin del

Servicio de Desarrollo de Proyectos

Ejecucin de pruebas de sistemas