Desarrollo de Software Empresarial Jonas Montilva v0 PDF

DESARROLLO DE SOFTWARE
EMPRESARIAL

Jons Montilva C.
Judith Barrios A.
Universidad de Los Andes

2

Desarrollo de Software Empresarial

Derechos Reservados. Ninguna parte de este documento puede ser reproducida, almacenada, o
transmitida por medio alguno, sea ste electrnico, mecnico, por fotocopia o cualquier otro, sin la
previa autorizacin escrita de sus autores.

2007 Jons A. Montilva C. y Judith Barrios A.

DESARROLLO DE SOFTWARE EMPRESARIAL 3

TABLA DE CONTENIDOS

Captulo 1: Introduccin________________________________________________________ 5
Captulo 2: Aspectos generales del mtodo ________________________________________ 10
Captulo 3: Modelo de Productos ________________________________________________ 18
Captulo 4: El Modelo de Actores________________________________________________ 30
Captulo 5: El Modelo de Procesos_______________________________________________ 38
Captulo 6: Procesos de Gestin del Proyecto ______________________________________ 44
Captulo 7: Procesos de Soporte_________________________________________________ 52
Captulo 8: Procesos de Anlisis_________________________________________________ 66
Captulo 9: Procesos de Diseo _________________________________________________ 82
Captulo 10: Procesos de Implementacin_________________________________________ 98
Referencias Bibliogrficas
Glosario de Trminos

4


Captulo
Introduccin
1

Este documento describe el Mtodo de Desarrollo de Software Empresarial WATCH que
puede empleado en empresas para elaborar aplicaciones empresariales.
Este primer captulo persigue dos objetivos: (1) definir el mtodo WATCH y (2) describir el
entorno donde ser utilizado, esto es el Sistema de Informacin Empresarial SIE. Se
destaca, tambin, la importancia que tiene la aplicacin de un mtodo de desarrollo de
software y se indica como este documento est organizado.
Sistemas de Informacin Empresarial (SIE)
Los Sistemas de Informacin Empresarial (SIE) son sistemas de informacin de alcance
corporativo que administran los datos de una organizacin y proporcionan informacin
empresarial actualizada, oportuna y confiable a todas las unidades organizativas de la
empresa que as lo requieran.
Un SIE es definido como un sistema de informacin empresarial de tipo estratgico y de
alcance corporativo que presta apoyo a procesos de negocio de una empresa.
Objetivos de un SIE
Un SIE persigue dos objetivos generales:
administrar los datos de la empresa como activos o recursos corporativos y
proveer la informacin empresarial que requieran sus usuarios, es decir, todos
aquellos actores de la empresa que demanden informacin empresarial para
realizar sus procesos de negocio.
Su importancia, dentro del contexto empresarial, radica en la posibilidad de gestionar los datos
de LA EMPRESA como recursos estratgicos de alcance corporativo, a partir de los cuales se
podr generar la informacin empresarial que las diferentes unidades de la empresa necesiten
para operar eficaz y eficientemente.
Estructura de un SIE
La estructura de un SIE est fundamentada en una arquitectura distribuida en la que los datos
de uso corporativo se mantienen en un ambiente de servidor centralizado y son accesibles
desde cualquier computador-cliente conectado a la Intranet de la empresa. Los datos
centrales del sistema son accedidos a travs de un conjunto de aplicaciones informticas,
muchas de las cuales pueden, tambin, mantener sus propios datos locales.
Un SIE est, generalmente, formado por los siguientes componentes arquitectnicos (ver
figura 1.1):
6
1) Una base de datos corporativa (BDC-SIE) que organiza y gestiona los datos de uso
comn a toda la empresa.
2) Una plataforma infraestructura de operacin compuesta, generalmente, por un
servidor central y un conjunto de computadores clientes conectados a travs de la red de
datos de la empresa (no ilustrados en la Figura 1), un conjunto de paquetes de software
para el desarrollo, administracin y operacin de las bases de datos y una coleccin de
herramientas CASE para el desarrollo de aplicaciones.
3) Un conjunto de aplicaciones informticas orientadas a apoyar los procesos de negocio
de la empresa en diferentes unidades organizacionales. Estas aplicaciones se clasifican
en cuatro tipos:
Sistemas de informacin funcional.- Son sistemas de informacin de menor
alcance que un SIE y que estn dirigidos a satisfacer las necesidades especficas o
particulares de una o ms Gerencias o Direcciones. Estos sistemas, adems de
acceder a los datos de la BDC-SIE, pueden poseer sus propias bases de datos
locales. Estn divididos en tres tipos:
Sistemas de informacin fsico-natural
Sistemas de informacin socio-econmica
Sistemas de apoyo a procesos especficos de la empresa
Aplicaciones de propsito especfico.- Son todas aquellas aplicaciones menores
programas dedicados a satisfacer necesidades de informacin empresarial de
carcter departamental, grupal o individual. Estas aplicaciones emplean, para
manipular datos, los productos de software de escritorio que integran la suite del
software.
Programas de Mantenimiento de un SIE.- Son programas dedicados a facilitar la
administracin y mantenimiento de un SIE. Uno de estos programas es el que facilita
la actualizacin de los datos de la BDC-SIE, denominado Programa de
Mantenimiento de la BDC-SIE.
Aplicaciones web.- Son aplicaciones que facilitan el acceso a los datos centrales o
locales de un SIE mediante el uso de la tecnologa web. El objetivo principal de estas
aplicaciones es facilitarle a los usuarios de un SIE el acceso a los datos usando
interfaces grficas basadas en la tecnologa web. Una de estas aplicaciones es el
Portal de Informacin empresarial que proporcionar, via Intranet e Internet,
informacin empresarial de uso tanto interno como externo.
4) El Personal Tcnico encargado de instalar, desarrollar y/o mantener los diferentes
componentes de la arquitectura de un SIE. Este personal se encarga, tambin, de dar
apoyo tcnico a los usuarios de un SIE.
5) El conjunto de Usuarios que emplean los recursos o facilidades que proporciona Un SIE
para acceder, a travs de las aplicaciones informticas, a los datos centrales o locales del
sistema. Estn divididos en dos grupos:
Usuarios internos.- Son todos aquellos actores (personal de la empresa) que
requieren bien el acceso a la informacin que produce Un SIE o utilizar este
sistema para realizar sus actividades o procesos de negocio. Estn divididos en
los siguientes grupos: Personal Directivo, Personal Ejecutivo, Personal Tcnico,
Personal Administrativo y Especialistas Ambientales.
Usuarios externos.- Este grupo lo integran todas aquellas empresas,
instituciones o personas externas a LA EMPRESA que requieren los servicios de
un SIE.

Figura 1.1. Arquitectura general de un SIE
Alcance de un SIE
El Sistema de Informacin Empresarial(SIE) es visto o concebido como un sistema de
informacin corporativa, esto es, como un conjunto integrado de aplicaciones informticas que
gestionan datos y proporcionan informacin a uno o ms procesos de negocio, en diferentes
niveles de la jerarqua gerencial de la empresa.
El propsito de un SIE es apoyar, a travs de la automatizacin y suministro de informacin, la
ejecucin de todos aquellos procesos de negocio de la empresa que estn relacionados con
el rea ambiental de inters para la empresa.
Estrategias de desarrollo de un SIE
Tal como se pudo apreciar en la seccin anterior, Un SIE es un sistema complejo que abarca
todos los niveles gerenciales y operativos de la empresa. En su desarrollo, se emplean
tecnologas de punta muy especializadas y de un alto nivel de sofisticacin, tales como:
herramientas automatizadas, sistemas distribuidos, bases de datos espaciales y aplicaciones
web.
Para manejar esta complejidad, se hace indispensable definir un conjunto de estrategias que
garanticen el xito de su desarrollo y la consecucin de los objetivos de un SIE. Estas
estrategias son las siguientes:
1) Gestionar el desarrollo de un SIE como un proyecto corporativo.
8
2) Emplear las mejores prcticas de la Ingeniera de Software, la Gerencia de
Proyectos y los Sistemas de Informacin Empresarial. Estas prcticas permiten
asegurar que el sistema tenga una alta calidad. La calidad de sistema se mide en
trminos del grado de satisfaccin de los usuarios, el cumplimiento de los requisitos
establecidos y el nivel de calidad tecnolgica de los componentes del sistema.
3) Definir y aplicar un mtodo para el desarrollo de las aplicaciones que componen la
arquitectura de un SIE. Este mtodo debe estar fundamentado en el proceso y las
prcticas sealadas en las estrategias 1 y 2. El propsito de este mtodo es asegurar la
uniformidad, consistencia, integracin calidad y gestin de las aplicaciones informticas
que conforman la arquitectura de un SIE.
El mtodo WATCH
Para producir el conjunto de aplicaciones informticas que integran Un SIE es necesario
disponer de un mtodo de desarrollo del software que est bien definido y documentado. Este
mtodo debe establecer las actividades, prcticas, tcnicas y procedimientos que los grupos
responsables del desarrollo deben emplear para desarrollar las aplicaciones informticas de
un SIE e integrarlas a la BDC-SIE en la forma sealada en la figura 1.1.
El mtodo WATCH, descrito en este documento, es un marco metodolgico que describe los
procesos tcnicos, gerenciales y de soporte que deben emplear los equipos y grupos que
tendrn a su cargo el desarrollo de las aplicaciones informticas de un SIE.
Un marco metodolgico es un patrn que debe ser instanciado, es decir adaptado cada vez
que se use. Cada equipo de desarrollo de aplicaciones de un SIE deber usar el mtodo
como un patrn o plantilla metodolgica, a partir de la cual ellos deben elaborar el proceso
especfico de desarrollo de la aplicacin que dicho equipo deba producir.
Caractersticas del mtodo WATCH
El mtodo WATCH est fundamentado en las mejores prcticas de la Ingeniera de Software y
cubre todo el ciclo de vida de las aplicaciones; desde el modelado del dominio de la
aplicacin, pasando por la definicin de los requisitos de los usuarios, hasta la puesta en
operacin de la aplicacin.
Este mtodo incluye, tambin, una descripcin de los procesos de gerencia del proyecto que
se aplicarn para garantizar que el proyecto se ejecute en el tiempo previsto, dentro del
presupuesto acordado y segn los estndares de calidad establecidos.
En el diseo de este mtodo se emplearon, como marcos de referencia para la elaboracin
del proceso de desarrollo de las aplicaciones, los siguientes estndares y modelos:
CMMI: Capability Maturity Model del Software Engineering Institute (CMMI, 2005)
El cuerpo de conocimientos de la Ingeniera de Software (SWEBOK) de la
Sociedad de Computacin de la IEEE.
RUP: Rational Unified Process de IBM (Krutchen, 2000)
PMBOK: Project Management Body of Knowledge del Project Management
Institute (PMI, 2000)
Componentes del mtodo WATCH
El mtodo WATCH est compuesto por tres modelos fundamentales:
1) Un modelo de productos que describe los productos intermedios y finales que se
generan, mediante la aplicacin del mtodo, durante el desarrollo de una aplicacin
informtica de un SIE.
2) Un modelo de actores que identifica a los actores interesados (stakeholders) en el
desarrollo de las aplicaciones de un SIE y describe cmo deben estructurarse los equipos
de desarrollo y cules deben ser los roles y responsabilidades de sus integrantes
3) Un modelo de procesos que describe detalladamente los procesos tcnicos, gerenciales
y de soporte que los equipos de desarrollo debern emplear para elaborar las
aplicaciones informticas de un SIE.
Objetivos y estructura del documento
Este documento tiene por objetivos describir, en detalle, el mtodo WATCH que ser utilizado
por los equipos de desarrollo para producir las aplicaciones informticas que integran un SIE.
Los aspectos generales del mtodo, incluyendo sus objetivos, caractersticas y estructura, se
presentan en el Captulo 2. En el Captulo 3, se detalla el modelo de productos, el cual indica
que productos se generan mediante el uso del mtodo. Los actores interesados en la
ejecucin del Proyecto SIE y los aspectos organizativos de los equipos de desarrollo de
aplicaciones de un SIE se presentan en el Captulo 4. Una introduccin al modelo de procesos
est contenida en el Captulo 5. Este modelo se compone de tres tipos de procesos: procesos
gerenciales, tcnicos y de soporte. Los procesos gerenciales se describen en el Captulo 6; los
procesos de soporte en el Captulo 7; mientras que los procesos tcnicos se discuten en los
Captulos 8 10. La manera en que el mtodo debe ser utilizado por los equipos de desarrollo
se plantea en el Captulo 11 junto a las conclusiones y recomendaciones para actualizar el
mtodo.
10

Captulo Aspectos generales del mtodo
WATCH 2

En este captulo, se describen las generalidades del mtodo de desarrollo de aplicaciones de
un SIE (WATCH). Se presentan sus objetivos y se discuten sus caractersticas y estructura.
El objetivo de este captulo es dar una introduccin general del mtodo que facilite la
comprensin de sus bases conceptuales, su estructura y sus componentes metodolgicos.
Objetivos del mtodo WATCH
WATCH es un mtodo de desarrollo de software que ha sido elaborado expresamente para
ser utilizado durante el desarrollo de Sistemas de Informacin Empresarial SIE, con la finalidad
de:
Orientar a los equipos de desarrollo acerca de qu deben hacer y cmo deben desarrollar
una aplicacin informtica de un SIE.
Garantizar la uniformidad, consistencia, facilidad de integracin y calidad de las distintas
aplicaciones que integrarn Un SIE.
Gestionar el desarrollo de las aplicaciones de un SIE como proyectos de ingeniera,
siguiendo los estndares de gestin de proyectos establecidos en LA EMPRESA.
Asegurar que en el desarrollo de cada aplicacin de un SIE se empleen las mejores
prcticas, tcnicas, herramientas, estndares y lenguajes aceptados internacionalmente
para desarrollar software de alta calidad.
Caractersticas del mtodo WATCH
En el diseo del WATCH, se han usando las mejores prcticas, modelos y principios de varias
disciplinas, principalmente de, la Ingeniera de Mtodos, la Ingeniera de Software, la Gestin
de Proyectos y los Sistemas de Informacin.
La Ingeniera de Mtodos es una disciplina muy reciente que se encarga de: (1) estudiar los
problemas metodolgicos que caracterizan el desarrollo de productos tecnolgicos, y (2) de
proponer soluciones que apunten a mejorar los procesos de desarrollo y mantenimiento de
estos productos. Ha sido empleada con mucho xito en la elaboracin de mtodos para el
desarrollo y mantenimiento de software y sistemas de informacin. De esta disciplina se tom
la estructura del mtodo, tal como se explica, ms adelante, en la Seccin Estructura del
Mtodo WATCH.
De la Ingeniera de Software y la Gestin de Proyectos, se tomaron conceptos, principios,
modelos, tcnicas y mejores prcticas que fueron integradas en un modelo de procesos nico
que constituye el corazn del mtodo WATCH. Este modelo de procesos describe cmo
desarrollar aplicaciones de alta calidad, en el tiempo establecido y bajo el costo presupuestado
en el Plan del Proyecto de cada aplicacin.
Las caractersticas ms relevantes del mtodo WATCH son las siguientes:
1) Est slidamente fundamentado.- Posee una base conceptual y metodolgica muy
bien sustentada. El mtodo descansa en conceptos bien establecidos que se derivan de
la Ingeniera de Software, los Sistemas de Informacin Geogrfica (SIG) y los Sistemas
de Informacin Empresarial (SIE). En concreto, el mtodo emplea una arquitectura de
dominio de tres capas que define los elementos principales de los SIG/SIE modernos.
Metodolgicamente, el modelo ha sido elaborado tomando como referencia modelos de
procesos bien conocidos o bien fundamentados, tales como el modelo RUP-Rational
Unified Process (Krutchen, 2000) y el mtodo WATCH (Montilva y Barrios, 2004b).
2) Es estructurado y modular.- Posee una clara estructura que facilita su comprensin y
utilizacin. Esta estructura separa los tres elementos primordiales de un mtodo: el
producto que se quiere elaborar, los actores que lo elaboran y el proceso que siguen los
actores para elaborar el producto. Estos tres elementos definen los tres componentes del
mtodo WATCH: modelo de productos, modelo de actores y modelo de procesos. Cada
uno de ellos posee, a su vez, una estructura modular claramente visible y acorde al
elemento que representa. As, por ejemplo, el modelo de procesos tiene una estructura
jerrquica de cinco (5) niveles compuesta de: grupo de procesos, procesos, sub-procesos,
actividades y tareas.
3) Es de propsito especfico.- El mtodo est dirigido al desarrollo de aplicaciones
geogrficas en entornos empresariales; es decir, al desarrollo de sistemas de informacin
de carcter corporativo que estn orientados al manejo de datos e informacin geogrfica.
Esta orientacin concreta y especfica resuelve los problemas que tienen la mayora de
los mtodos comerciales y acadmicos existentes, cuya generalidad va en detrimento de
su aplicabilidad en sistemas muy especializados, tales como los SIG y SIE.
4) Es flexible y adaptable.- Si bien el mtodo est dirigido al desarrollo de aplicaciones
especializadas (aplicaciones geogrficas en entornos empresariales), sus tres
componentes pueden ser adaptados, con relativa facilidad, a otros tipos de productos de
software. Esta labor, sin embargo, debe ser hecha por expertos en Ingeniera de Mtodos,
para asegurar la correcta y efectiva adaptacin a otros tipos de aplicaciones.
5) Emplea las mejores prcticas del desarrollo de software.- Al igual que otros mtodos
bien establecidos, tales como RUP (Krutchen, 2000) y OOSE (Jacobson, 1994), el
mtodo WATCH emplea prcticas metodolgicas internacionalmente aceptadas y
utilizadas en la industria del software, las cuales, al ser aplicadas apropiadamente,
contribuyen a resolver muchos de los problemas que, comnmente, se le atribuyen a los
proyectos de software. Entre estas prcticas, se destacan las siguientes:
Desarrollo de software iterativo e incremental.- WATCH considera el proceso de
desarrollo de aplicaciones como un proceso iterativo. Cada iteracin produce un
componente o una nueva versin operativa de la aplicacin.
Manejo eficiente de los requisitos.- Una mala gestin de los requisitos de una
aplicacin es una de las principales causas de problemas en proyectos de
desarrollo de software. Para evitar estos problemas, WATCH emplea las mejores
prcticas, tcnicas y procesos de la Ingeniera de Requisitos, las cuales facilitan
las actividades de identificacin, anlisis, especificacin, validacin y gestin de
requisitos.
Reutilizacin de activos de software.- El mtodo promueve la reutilizacin de
activos de software. Ello reduce costos y aumenta la calidad de los productos de
12
software elaborados usando el mtodo. Entre estos activos estn los siguientes:
arquitecturas de dominio, patrones de diseo, componentes de software
reutilizables y plantillas de documentos (Ej., plantillas para planes de proyecto,
pruebas de software, manuales de uso, etc.).
Modelado visual de la aplicacin.- Para desarrollar una aplicacin informtica es
indispensable modelar distintos aspectos de ella, en cada una de las etapas o
fases de su desarrollo. WATCH emplea lenguajes de modelado grfico o visual
ampliamente conocidos, tales como UML (Booch, Rumbaugh and Jacobson,
1999) y BPMN (BPMI, 2005). Estos lenguajes facilitan la representacin de la
aplicacin desde diferentes perspectivas y reducen los problemas de
comunicacin que normalmente surgen entre los expertos en Informtica y los
usuarios.
Verificacin continua de la calidad de los productos.- WATCH asegura la calidad
de la aplicacin, a travs del uso de un proceso bien definido de Verificacin y
Validacin (V&V). Este proceso es aplicado a todos los productos intermedios y
finales que se elaboran a lo largo del desarrollo de cada aplicacin.
Apropiada gestin de cambios.- Los cambios en los requisitos es una constante
en el desarrollo de aplicaciones empresariales. Estos cambios pueden surgir en
cualquier fase del desarrollo de una aplicacin, por lo que es necesario
controlarlos apropiadamente, a fin de evitar que el proyecto se postergue
continua o indefinidamente. WATCH emplea un proceso bien definido de Gestin
de la Configuracin de Software (SCM) que se encarga de controlar estos
cambios.
6) Emplea las mejores prcticas y procesos de gestin de proyectos.- El mtodo
WATCH emplea procesos y prcticas establecidas en el cuerpo de conocimientos de
gestin de proyectos propuesto por el PMI (Project Management Institute). Este cuerpo de
conocimientos es, tambin, empleado en la metodologa desarrollada por LA EMPRESA
para gestionar sus proyectos de ingeniera. WATCH est alineado a esta metodologa.
7) Integra los procesos de gestin con los procesos tcnicos y de soporte.- WATCH
define tres grupos de procesos: tcnicos, gerenciales y de soporte. Los procesos tcnicos
se relacionan con las actividades de anlisis, diseo, implementacin y pruebas de las
aplicaciones. Los procesos gerenciales se encargan de gestionar el desarrollo de cada
aplicacin como un proyecto de ingeniera; involucran, por lo tanto, actividades de
planificacin, organizacin, administracin, direccin y control del proyecto. Por su parte,
los procesos de soporte complementan los procesos tcnicos y gerenciales con
actividades, tales como: el aseguramiento de la calidad, la gestin de la configuracin, la
capacitacin de los actores y la gestin de riesgos del proyecto.
Estructura del mtodo WATCH
El mtodo WATCH est compuesto por tres modelos que describen los tres elementos claves
de todo mtodo: el producto que se quiere elaborar, los actores que lo elaboran y el proceso
que los actores deben seguir para elaborar el producto (ver figura 2.1).
Figura 2.1. Componentes del
Mtodo WATCH
El Modelo de Productos
Este modelo identifica y describe los tipos de productos que se deben generar durante el
desarrollo de una aplicacin SIE. Estos tipos de productos se elaboran durante la ejecucin de
los procesos tcnicos, gerenciales o de soporte, que estn contenidos en el Modelo de
Procesos del mtodo. La figura 2.2 recoge los principales tipos de productos que se deben
producir a lo largo del desarrollo de una aplicacin SIE y los clasifica de acuerdo a los grupos
de procesos donde ellos se generan.

Figura 2.2. Principales tipos de productos del mtodo WATCH
El modelo de producto incluye, adems, una caracterizacin del tipo de aplicaciones que el
WATCH puede producir. El modelo describe tres patrones arquitectnicos que pueden ser
usados durante el diseo de las aplicaciones SIE. Cada patrn establece los componentes y
conexiones que son tpicos de una familia de aplicaciones SIE. Los equipos de desarrollo
pueden emplear estos patrones para disear la arquitectura de sus aplicaciones. Estos
patrones se basan en la tecnologa GIS y DBMS empleadas en el desarrollo de un SIE. El
modelo de productos se describe detalladamente en el Captulo 3.
El Modelo de Actores
El Modelo de Actores tiene como objetivos: (1) Identificar los actores o interesados
(stakeholders) que estn involucrados en el desarrollo de las aplicaciones SIE; (2) Describir
las modalidades de organizacin de los equipos de trabajo que desarrollarn las aplicaciones
de un SIE; y (3) Definir los roles y responsabilidades de aquellos actores que integrarn estos
equipos de trabajo. La figura 2.3 clasifica los actores que deben participar en el desarrollo de
aplicaciones SIE en cuatro grupos diferentes.

Figura 2.3. Clasificacin de los actores
Los equipos de trabajo que desarrollarn las aplicaciones SIE estarn, generalmente,
compuestos por usuarios internos, desarrolladores y personal de apoyo. La estructura
organizativa de estos equipos y sus relaciones con la estructura organizativa de la empresa se
describen detalladamente en el Captulo 4.
14
El Modelo de Procesos
El objetivo de este modelo es describir los procesos tcnicos, gerenciales y de soporte que los
equipos de trabajo deben emplear para desarrollar las aplicaciones de un SIE. Estos procesos
se indican en la figura 2.4.

Figura 2.4. Procesos del mtodo WATCH
Estos procesos se clasifican, segn su naturaleza con respecto al proceso de desarrollo de
software, en tres grupos: procesos tcnicos, procesos de gestin y procesos de soporte (ver
figura 2.5).

Figura 2.5. Procesos del Mtodo WATCH
El modelo est inspirado en la metfora del reloj; metfora en la cual el proceso de desarrollo
de software es visto como un reloj, cuyo motor son los procesos gerenciales y de soporte y
cuyos diales constituyen los procesos tcnicos. Esta metfora determina la estructura del
modelo de procesos (ver figura 2.6)
Modelado
del Dominio de
la Aplicacin
Ingeniera
de Requisitos
Diseo
Arquitectnico
Diseo
Detallado
Pruebas de la
Aplicacin
Entrega de la
Aplicacin
Procesos
Gerenciales y
de Soporte
Operacin
y
Mantenimiento
Construccin
& Integracin
Figura 2.6. Estructura del
modelo de procesos
De acuerdo a la estructura del modelo, el proceso de desarrollo de software se inicia con la
planificacin del proyecto, la cual es parte de los procesos gerenciales. Una vez planificado el
proyecto, se da inicio a sus procesos tcnicos mediante la ejecucin del Modelado del
Dominio de la Aplicacin. Se continua, luego, con los procesos de Ingeniera de Requisitos,
Diseo Arquitectnico, Diseo Detallado, Construccin, Integracin y Pruebas, en el orden
indicado por las agujas del reloj; finalizando con la entrega de la aplicacin completa ( de un
subsistema de ella). Uno de los procesos de soporte, denominando Verificacin y Validacin
(V&V), se encarga de evaluar cada producto de los procesos tcnicos, a fin de determinar si el
proceso contina hacia la siguiente proceso debe retornarse a una proceso anterior para
corregir defectos en los productos. El proceso V&V define, por consiguiente, el carcter
iterativo del mtodo.
Los procesos del mtodo WATCH y sus productos
La Tabla 2.1 resume los componentes metodolgicos que integran el modelo de procesos del
WATCH y los relaciona con el modelo de productos.
Tabla 2.1. Relaciones entre procesos y productos
Grupos de
Procesos
Productos
Procesos de gestin
Caso de Negocios
Plan del Proyecto
Proceso de Desarrollo
Informes de Gestin
Procesos tcnicos
Modelo del Dominio de la Aplicacin
Documento de Requisitos
Documento de Diseo
Documento de Implementacin
Documento de Pruebas
Aplicacin SIE

Procesos de soporte
Otros componentes del Plan del
Proyecto:
Plan SCM
Plan SQA
Plan de Gestin de Riegos
Plan V&V
Plan de Pruebas
Plan de Capacitacin

El modelo de procesos se describe en el Captulo 5. Los procesos gerenciales se detallan en
el Captulo 6; mientras que los de soporte se especifican en el Captulo 7. Los Captulos 8, 9 y
10 presentan los detalles de los procesos tcnicos del mtodo.
Instanciacin del mtodo WATCH
Un aspecto importante de todo mtodo es su utilizacin; es decir, cmo el mtodo debe ser
empleado para desarrollar una determinada aplicacin. Los mtodos son patrones que guan
a un equipo de desarrollo en la definicin de un proceso. No pueden ser utilizados como una
frmula qumica, algoritmo o receta; en la que sus procesos y actividades se siguen al pie de
16
la letra y paso a paso. En su lugar, se requiere de un proceso de adecuacin que ajuste el
mtodo a las caractersticas particulares de cada aplicacin y a las condiciones existentes, en
la empresa, para el momento en que se desarrolla la aplicacin.
Al igual que otros mtodos modernos (Ej., RUP, WATCH, OOSE y Fusion), WATCH requiere
la utilizacin de un proceso de instanciacin. Este proceso consiste en emplear los tres
modelos, que integran el mtodo (modelo de productos, modelo de procesos y modelo de
actores), como marcos metodolgicos o patrones que permiten determinar: los productos
especficos de la aplicacin, el proceso particular que debe seguirse para desarrollar cada
aplicacin de un SIE y la organizacin del Equipo de Desarrollo. La figura 2.7 ilustra este
proceso.

Figura 2.7. La instanciacin del mtodo WATCH
El uso del mtodo se ejemplifica de la siguiente manera: asuma que se desea desarrollar una
aplicacin SIE denominada ASIE. Al inicio del proyecto, el Lder del Proyecto SIE y el Lder de
Desarrollo de la aplicacin ASIE, asignado al proyecto, instancian el mtodo de la siguiente
manera:
A partir del modelo de productos, los dos lderes elaboran una lista de los productos
concretos que se producirn durante el desarrollo del proyecto y describen las
caractersticas particulares de la aplicacin ASIE, as como su arquitectura inicial.
Usando el modelo de actores, los dos lderes elaboran una lista de los actores que
participarn en el proyecto y definen una estructura para la organizacin del equipo
de desarrollo E que se ajusta al tamao y complejidad de la aplicacin ASIE.
Empleando el modelo de procesos como un patrn metodolgico, los dos lderes
establecen el proceso P que define las actividades especficas que debe seguir el
equipo E para desarrollar la aplicacin ASIE.
.
18

Captulo
Modelo de Productos
3

El modelo de productos es el primer componente del mtodo WATCH. Este modelo describe
las caractersticas generales que tienen las aplicaciones de un SIE e identifica los productos
intermedios y finales que se deben producir durante el desarrollo de una aplicacin SIE.
La importancia de este modelo radica en el hecho de que l establece que es lo que cada
equipo de desarrollo debe producir a lo largo del proceso de desarrollo de una aplicacin SIE.
En este captulo se define con mayor precisin el concepto de Aplicacin SIE, en el marco
del Proyecto SIE.
Objetivos del modelo
El modelo de productos tiene como objetivos los siguientes:
Orientar a los equipos de desarrollo acerca de los productos intermedios y finales que
deben elaborarse en cada proyecto de desarrollo de aplicaciones SIE.
Facilitar la elaboracin de la estructura de trabajo (WBS- Work Breakdown Structure) de
cada proyecto de desarrollo de aplicaciones SIE.
Facilitar el diseo de las aplicaciones SIE a travs de patrones arquitectnicos que
describen las caractersticas estructurales de los diferentes tipos de aplicaciones SIE.
Componentes del modelo
Tal como se muestra en la figura 3.1, el modelo de productos est compuesto por dos tipos de
resultados: productos intermedios y productos finales ( entregables).
Los productos intermedios son todos aquellos resultados que se originan durante el desarrollo
del proyecto y que son necesarios para gestionar el proyecto y/o desarrollar el sistema.
Los productos finales son las aplicaciones mismas que se entregan a los usuarios y
mantenedores del sistema SIE, una vez que el proyecto de desarrollo de la aplicacin finalice.

Figura 3.1. Componentes del Modelo de Productos
Productos intermedios
Los productos intermedios resultan de la ejecucin de los procesos gerenciales y tcnicos
descritos en el Modelo de Procesos (ver Captulo 5). Son resultados que se producen y se
emplean durante la ejecucin de los proyectos de desarrollo de aplicaciones SIE. Son, por lo
general, utilizados por los Equipos de Desarrollo para gestionar los proyectos y desarrollar las
aplicaciones.
Tal como se muestra en la figura 3.1, este tipo de productos se dividen en dos grupos. Los
productos de gestin del proyecto son producidos por los Lderes de Desarrollo de
Aplicaciones y son empleados para gerenciar los proyectos; mientras que los productos
tcnicos son producidos por los diferentes grupos que integran los Equipos de Desarrollo (ver
Captulo 4, Fig. 4.1) durante la ejecucin de los procesos de desarrollo de las aplicaciones.
A continuacin, se describen brevemente cada uno de estos productos. Los detalles de estos
productos se dan en cada uno de los procesos gerenciales y tcnicos en los cuales ellos se
producen (ver Captulos 6 -10).
Caso de Negocios
El caso de negocio es el documento inicial de todo proyecto. Es un documento de carcter
gerencial que describe la importancia del proyecto, su justificacin, sus objetivos, la relacin de
estos objetivos con los objetivos de negocio, los resultados esperados y la estimacin
preliminar de costos. La Gerencia de Proyectos de CVG-LA EMPRESA define el caso de
negocios como un:
Documento que contiene el anlisis y resultados de la evaluacin del negocio que se propone, el cual
proporciona la justificacin para acometer el proyecto y define los resultados finales deseados, los criterios
20
de aceptacin y la informacin referente a los objetivos, entregas, tiempo, costo, calidad, seguridad y otros
requerimientos; as como los riesgos y oportunidades ms relevantes (CVG-LA EMPRESA, 2004)
Este documento es elaborado por actores o interesados de una o ms gerencias de la
empresa que tengan inters en el desarrollo de una nueva aplicacin SIE. El Comit Directivo
de un SIE discute el caso de negocios y toma una decisin en relacin a la nueva aplicacin
SIE que en dicho documento se propone.
Si el caso de negocios es aprobado, el Comit Directivo de un SIE debe designar el Lder de
Desarrollo de la aplicacin SIE (ver Captulo 4). Este lder tendr la responsabilidad de
gestionar el proyecto de desarrollo de la nueva aplicacin SIE. Su primera tarea consistir en
elaborar el Plan del Proyecto.
Plan del Proyecto
El Plan del Proyecto es un documento formal utilizado para gestionar la ejecucin del proyecto
y controlar su desarrollo. Es el documento de gestin ms importante; pues, es usado para
guiar los procesos de ejecucin y control del proyecto.
Es un documento que tiene una estructura compleja y un contenido que va mejorndose y
extendindose en la medida que el proyecto avanza. El plan del proyecto debe describir los
siguientes aspectos del proyecto de desarrollo de una nueva aplicacin SIE:
El alcance y los objetivos del proyecto.
La estructura de trabajo (WBS Work Breakdown Structure) que identifica y organiza
las actividades requeridas para desarrollar la nueva aplicacin SIE. Esta estructura
est fundamentada en los productos que el proyecto debe producir. Los detalles de
esta estructura se describen en el Estndar WBS (PMI, 2001).
La estimacin de tiempos de ejecucin de las actividades del proyecto y la
identificacin de los hitos del proyecto (milestones).
Los recursos humanos, tecnolgicos, fsicos y econmicos requeridos para ejecutar
estas actividades.
La estimacin de costos del proyecto.
Los riesgos que pueden afectar el proyecto.
La verificacin y validacin del producto.
Los aspectos de aseguramiento de la calidad de la aplicacin que se va a producir
Los aspectos de gestin de la configuracin del software de la aplicacin.
La figura 3.2 muestra la estructura general que el Mtodo WATCH propone para los planes de
proyectos de aplicaciones SIE. Esta estructura, compuesta por un conjunto variable de planes
subsidiarios, es una adecuacin de aquella propuesta en el Cuerpo de Conocimientos de
Gestin de Proyectos del PMI (PMI, 2000).

Figura 3.2. Estructura de un Plan de Proyecto
Tal como lo establece la figura 3.2, el Plan del Proyecto de una aplicacin SIE debe estar
compuesto por un conjunto de planes subsidiarios cuyo nmero, extensin, contenido y
formalidad dependern del tamao y complejidad de la aplicacin que se va a desarrollar.
Cada uno de los planes subsidiarios del Plan del Proyecto es elaborado y mantenido por el
Lder de Desarrollo de cada aplicacin. El plan es revisado por el Lder del Proyecto SIE y es
aprobado por el Comit Directivo de un SIE. El plan es utilizado durante todo el desarrollo del
proyecto para controlar su ejecucin.
Modelo del Dominio de la Aplicacin
El Modelo del Dominio de la Aplicacin es el primer documento tcnico que se produce
durante la ejecucin de los procesos tcnicos del desarrollo de una aplicacin SIE (ver
Captulo 5). Su objetivo es asegurar que el Equipo de Desarrollo tenga un conocimiento
adecuado del dominio de la aplicacin, de manera tal que se facilite, en los procesos
siguientes, definir apropiadamente los requisitos de la aplicacin.
El dominio de una aplicacin SIE es el sistema funcional de la empresa para el cual se
elabora dicha aplicacin. Este sistema consiste en uno o ms procesos de negocios que son
ejecutados por una o ms unidades organizacionales de la empresa, con la finalidad de
alcanzar objetivos predefinidos. El dominio de la aplicacin se le denomina, tambin, sistema
de negocios o sistema empresarial.
El Modelo de Dominio de la Aplicacin es un documento tcnico que describe:
Los objetivos del sistema de negocios donde estar ubicada la aplicacin SIE.
Los procesos de negocio que permiten alcanzar dichos objetivos.
Los actores de la empresa que ejecutan estos procesos de negocio y las unidades a
las cuales estos actores estn adscritos.
Los objetos de negocio que intervienen, en modo alguno, en la ejecucin de los
procesos de negocio.
La tecnologa que los procesos de negocio emplean para ejecutar sus actividades.
Los eventos que disparan o activan la ejecucin de los procesos de negocio.
Este documento es elaborado por el Grupo de Anlisis del Equipo de Desarrollo. En su
elaboracin se emplea la notacin UML Business (Eriksson and Penker, 2000) y el mtodo
BMM para modelado de negocios (Montilva and Barrios, 2004a). Este modelo debe ser
validado por el grupo de actores o interesados en el desarrollo de la aplicacin SIE.
Este documento tcnico es producido en el proceso de Ingeniera de Requisitos. Su objetivo
es identificar, describir, especificar y documentar cada uno de los requisitos funcionales y no-
22
funcionales que la aplicacin SIE debe satisfacer. El documento persigue dos objetivos
complementarios. Por un lado, busca identificar y describir las necesidades de informacin y
requisitos funcionales que los usuarios de la aplicacin SIE tienen; y, por otro lado, el
documento especifica tcnicamente los requisitos funcionales y no-funcionales que el Equipo
de Desarrollo emplear para disear la aplicacin.
Este documento es elaborado por el Grupo de Anlisis del Equipo de Desarrollo (ver Captulo
4) y debe ser validado por aquellos actores o interesados que estarn directamente
involucrados con el uso de la aplicacin.
Documento de Diseo
Es un documento tcnico producido durante los procesos de desarrollo de aplicaciones SIE,
Diseo Arquitectnico y Diseo Detallado (ver Captulo 5). Su objetivo es documentar los
detalles del diseo de la arquitectura del sistema y de cada uno de los componentes que
integran esta arquitectura.
El documento es elaborado por el Grupo de Diseo del Equipo de Desarrollo y debe ser
validado por todo el Equipo de Desarrollo. Es utilizado durante el proceso de Construccin e
Integracin con la finalidad de programar o producir cada uno de los componentes que
integran la arquitectura del sistema.
Es un documento tcnico producido durante el proceso de Construccin e Integracin. Su
objetivo es documentar los resultados de: (1) la construccin de cada componente de la
arquitectura del sistema; (2) las pruebas unitarias de cada componente y (3) las pruebas de
integracin de estos componentes.
Este documento contiene una descripcin de cada uno de los componentes arquitectnicos
producidos, as como los detalles de su integracin. Es utilizado posteriormente para realizar
las pruebas del sistema y para facilitar las labores de mantenimiento de la aplicacin una vez
que sta entre en produccin.
Este documento es elaborado por el Grupo de Implementacin e Instalacin (ver Captulo 4).
Es el ltimo documento tcnico que se produce durante el desarrollo de una aplicacin SIE.
Su objetivo es describir los resultados de las pruebas del sistema. Este tipo de pruebas verifica
que la aplicacin satisfaga los requisitos funcionales y no-funcionales que fueron establecidos
por los usuarios en el proceso de Ingeniera de Requisitos. A diferencia de las pruebas de
integracin, realizadas en el proceso de Construccin & Integracin, las pruebas del sistema
verifican que la aplicacin, como un todo, cumpla con los requisitos establecidos. Estas
pruebas validan, tambin, que la aplicacin sea el producto que los usuarios esperan.
El documento es elaborado por el Grupo de Pruebas una vez finalizada el proceso de Pruebas
de la Aplicacin. Este documento no debe confundirse con el Plan de Pruebas, el cual forma
parte del Plan del Proyecto. El Plan de Pruebas es, tambin, elaborado por el Grupo de
Pruebas antes de iniciar el proceso de Pruebas de la Aplicacin. Ambos documentos son
complementarios: El Plan de Pruebas describe el proceso de pruebas del sistema y el
Documento de Pruebas reporta la ejecucin de estas pruebas.
Productos finales
Los productos finales son aquellos productos que se entregan al cliente y a los usuarios una
vez que el proyecto de desarrollo de una aplicacin SIE ha concluido. En el caso particular de
un proyecto de desarrollo de una aplicacin SIE, este producto final es la aplicacin SIE
misma.
Aplicacin SIE
Una aplicacin SIE es una aplicacin informtica que accede a la base de datos corporativa
del sistema SIE (BDC-SIE), a fin de utilizar y/o actualizar los datos que esta base de datos
contiene. Cada aplicacin SIE es un sistema autnomo que ejecuta un conjunto de funciones
necesarias para mantener la BDC-SIE actualizada para apoyar las actividades que sus
usuarios realizan. Para ejecutar sus funciones, las aplicaciones SIE requieren acceder a datos
comunes contenidos en la BDC-SIE.
Desde el punto de vista estructural, una aplicacin SIE es un producto compuesto por una
coleccin de programas de software, una o ms bases de datos de uso local y un conjunto de
documentos tcnicos que facilitan las labores de mantenimiento y uso de la aplicacin SIE. La
figura 3.3 muestra la conformacin tpica de cada aplicacin SIE en trminos de sus
componentes de software.

Figura 3.3. Componentes tpicos de una aplicacin SIE
Programas
Cada aplicacin SIE consta de un conjunto de uno o ms programas de software que trabajan
coordinadamente para ejecutar las funciones establecidas para esa aplicacin. Las
caractersticas particulares de estos programas varan de una aplicacin a otra. Dependen del
diseo arquitectnico de la aplicacin y del tipo de tecnologa de software empleada para
implementarla.
As, por ejemplo, una aplicacin SIE distribuida estar formada por tres grupos de programas
relacionados y que estn asociados a las tres capas que componen una arquitectura
distribuida: Capa de Presentacin, Capa de Lgica de Negocios y Capa de Datos. El primer
grupo est asociado a la Capa de Presentacin y estar compuesto por uno o ms
componentes de software encargados de manejar los aspectos relativos a la interfaz
usuario/sistema de la aplicacin. El segundo grupo estar compuesto por varios componentes
de software encargados de implementar la Capa de Lgica del Negocio; es decir, el conjunto
de funciones que la aplicacin provee a sus usuarios. Finalmente, el tercer grupo implementa
la Capa de Datos y estar compuesto por las bases de datos locales y/o corporativa (BDC-
SIE) y el software requerido para administrar estas bases de datos (Ej. El sistema de
administracin de bases de datos ORACLE).
24
Repositorios de datos
Una condicin importante de una aplicacin SIE es que debe ser capaz de acceder a la base
de datos corporativa de un SIE (BDC-SIE); bien sea para utilizar los datos que esta BD
contiene para actualizarlos.
Adems de su habilidad natural para acceder a la BDC-SIE, los programas de una aplicacin
SIE pueden tener asociado uno o ms repositorios de datos locales. Estos repositorios
pueden ser de dos tipos: bases de datos y archivos. Las bases de datos, a su vez, pueden ser
de diferentes tipos: bases de datos relacionales, bases de datos geogrficos (Ej. BD
Georelacionales), bases de datos temporales (Ej. BD. Histricas), etc. El tipo de base de datos
local de una aplicacin SIE depende de la naturaleza y propsitos de la aplicacin.
Documentos tcnicos
El tercer componente fundamental de cada aplicacin SIE es el conjunto de documentos que
describen cmo utilizar la aplicacin y cmo mantenerla. Estos documentos pueden ser de
dos tipos: Manual de Uso y Manual de Mantenimiento.
El Manual de Uso est dirigido a los usuarios de la aplicacin. Este manual describe la
funcionalidad de la aplicacin y cmo los usuarios deben utilizar las funciones de la aplicacin.
El Manual de Mantenimiento est dirigido al personal que se encargar de mantener la
aplicacin SIE. Este manual describe todos los aspectos de diseo e implementacin de la
aplicacin que son necesarios para darle mantenimiento. El manual describe los siguientes
aspectos de la aplicacin:
La estructura de la aplicacin que incluyen su arquitectura, sus componentes
arquitectnicos y las relaciones entre estos componentes
La funcionalidad de la aplicacin expresada mediante casos de uso y el diseo de la
interfaz usuario/sistema.
La implementacin de la arquitectura incluyendo los programas, archivos y bases de
datos y la plataforma de operacin de la aplicacin.
El plan de mantenimiento de la aplicacin que describe las actividades, recursos,
mtodos, tcnicas y herramientas que se emplearn para darle mantenimiento
correctivo o perfectivo a la aplicacin.
La plataforma de software GIS de un SIE
Antes de describir los detalles de las aplicaciones SIE, es importante discutir la plataforma de
software que se emplear para su desarrollo y operacin. Esta plataforma contiene el software
(suite ArcGIS) que es necesario tener a disposicin para desarrollar los diferentes
componentes arquitectnicos de un SIE: la base de datos corporativos y las aplicaciones SIE.
La figura 3.4 muestra la plataforma de software GIS empleada por Un SIE.
Esta plataforma consta de tres niveles (ver figura 3.2). En el nivel superior se ubican las
aplicaciones GIS propiamente dichas (Mobile GIS, Desktop GIS, etc.). Conviene destacar que
las aplicaciones SIE son un tipo particular de aplicacin GIS. En el segundo nivel, se ubica el
conjunto de software servidor ArcGIS, que debe estar disponible para desarrollar y operar la
BDC-SIE y las aplicaciones SIE. En el nivel inferior, se ubican el sistema de gestin de bases
de datos (DBMS) y las bases de datos comunes que las aplicaciones SIE comparten entre s.
Los principales componentes de este nivel son la BDC-SIE, la cual es un tipo particular de
geodatabase, y el software ORACLE necesario para gestionar la BDC-SIE.

Figura. 3.4. Plataforma de software ArcGIS empleada por Un SIE (ESRI, 2005)
Las aplicaciones SIE como componentes de un SIE
Tal como se seal en el Captulo 1, las aplicaciones SIE son componentes arquitectnicos
del Sistema de Informacin EmpresarialSIE. Cada aplicacin SIE es un sistema autnomo,
pero integrado a la arquitectura de un SIE. La integracin se da a travs del acceso a la base
de datos corporativa BDC-SIE, utilizando la plataforma de software de un SIE (ver figura 3.5).

Figura. 3.5. Las aplicaciones SIE y su plataforma infraestructura de software
Cada aplicacin tiene un alto grado de autonoma con respecto a las dems aplicaciones que
integran Un SIE. Puede, por consiguiente, ser desarrollada separada e independientemente
del resto de las aplicaciones.
26
La plataforma infraestructura de desarrollo y operacin del sistema SIE es compartida por
todas las aplicaciones SIE. Es decir, todas las aplicaciones SIE utilizan la misma plataforma de
software GIS utilizada para crear y mantener la BDC-SIE y sus aplicaciones fundamentales
(ver figuras 3.4 y 3.5). En aquellos sistemas desarrollados antes que el sistema SIE y en
plataformas diferentes, se hace necesario establecer e implementar mecanismos de
integracin que faciliten la incorporacin de estas aplicaciones a la arquitectura de un SIE.
Tipos de aplicaciones SIE
Las aplicaciones SIE se clasifican en cuatro tipos:
Sistemas de informacin funcional.- Son sistemas de informacin de menor
alcance que Un SIE y que estn dirigidos a satisfacer las necesidades especficas o
particulares de una o ms Gerencias o Direcciones. Estos sistemas, adems de
acceder a los datos de la BDC-SIE, pueden poseer sus propias bases de datos
locales. Estn divididos en tres tipos:
Sistemas de informacin fsico-natural
Sistemas de informacin socio-econmica
Sistemas de apoyo a procesos especficos de la empresa
Aplicaciones de propsito especfico.- Son todas aquellas aplicaciones menores
programas dedicados a satisfacer necesidades de informacin empresarial de
carcter departamental, grupal o individual. Estas aplicaciones emplean, para
manipular datos, los productos de software de escritorio que integran la suite del
software ArcGIS: ArcExplorer, ArcEditor, ArcView, ArcInfo y el conjunto de
extensiones (Spatial Analyst, 3Danalyst, etc.).
Programas de Mantenimiento de un SIE.- Son programas dedicados a facilitar la
administracin y mantenimiento de un SIE. Uno de estos programas es el que facilita
la actualizacin de los datos de la BDC-SIE, denominado Programa de
Mantenimiento de la BDC-SIE.
Aplicaciones web.- Son aplicaciones que facilitan el acceso a los datos centrales o
locales de un SIE mediante el uso de la tecnologa web. El objetivo principal de estas
aplicaciones es facilitarle a los usuarios de un SIE el acceso a los datos usando
interfaces grficas basadas en la tecnologa web. Una de estas aplicaciones es el
Portal Corporativo de Informacin empresarial que proporcionar, va Intranet e
Internet, informacin empresarial de uso tanto interno como externo.
Arquitecturas tpicas de las aplicaciones SIE
Un aspecto fundamental de toda aplicacin SIE es su arquitectura de software. Una
arquitectura de software es la estructura que tiene una aplicacin. Esta estructura est
compuesta por un conjunto de componentes arquitectnicos interrelacionados mediante
conectores.
Las aplicaciones SIE tienen arquitecturas de software muy similares que podemos caracterizar
y agrupar en una o ms arquitecturas de dominio o patrones arquitectnicos. Estos patrones
son modelos que sirven de gua para el diseo arquitectnico de las aplicaciones SIE.
Patrn de aplicaciones de propsito especfico
La aplicacin SIE ms sencilla que se puede desarrollar es una aplicacin de escritorio
ArcGIS, la cual emplea la suite de programas ArcGIS de escritorio (ArcView, ArcEditor
ArcInfo) y el software ArcSDE para acceder a la BDC-SIE. Los datos de la BDC-SIE son
accedidos a travs del software ArcSDE, va red de datos, y usados localmente para realizar
el procesamiento requerido usando la funcionalidad provista por los programas ArcGIS de
escritorio. La arquitectura genrica de este tipo de aplicaciones se muestra en la figura 3.6.
Aplicaciones SIA
BDC-SIA
Clientes
ArcView
ArcSDE
ArcEditor ArcInfo
DBMS
ORACLE
Servidor GIS
Servidor de
datos
Aplicaciones SIA
BDC-SIA
Clientes
ArcView
ArcSDE
ArcEditor ArcInfo
DBMS
ORACLE
Servidor GIS
Servidor de
datos

Figura. 3.6 Patrn arquitectnico de las aplicaciones de propsito especfico
Este patrn arquitectnico es el ms simple de todos y aprovecha al mximo la funcionalidad
que provee el software ArcGIS de escritorio disponible en la plataforma de software de un SIE.
Este tipo de aplicacin no requiere esfuerzos de programacin; pues, las funciones que
provee el software ArcGIS de escritorio son suficientes para manipular, en el lado del cliente,
los datos extrados de la BDC-SIE. Las aplicaciones de este tipo son muy convenientes
cuando se requiere realizar operaciones de geoprocesamiento de propsito muy especfico
usando localmente un conjunto de datos de la BDC-SIE. Ntese que el estado de la BDC-SIE
no es alterado; pues, la aplicacin slo lee los datos que le interesa.
Patrn de aplicaciones GIS-Web
Otro tipo de aplicacin SIE que ser muy frecuente es aquel en el cual la interfaz
usuario/sistema de la aplicacin es construida usando la tecnologa Web. Para implementar
este tipo de aplicacin se emplea el software ArcIMS, el cual provee las capacidades
necesarias para desarrollar aplicaciones GIS basadas en tecnologa Web.
El patrn arquitectnico de este tipo de aplicacin se muestra en la figura 3.7. Es un patrn
tpico de aplicaciones de tres capas: capa de presentacin, capa de lgica de negocios y capa
de datos. En este patrn, la capa de presentacin de la aplicacin SIE consiste de una interfaz
web especializada compuesta por uno o ms visores ArcIMS (ArcIMS Viewer) capaces de
desplegar y manipular datos espaciales (mapas e imgenes). La funcionalidad que la
aplicacin puede ofrecer, en la capa de lgica del negocio, es implementada como servicios
ArcIMS que son procesados por el ArcIMS Application Server. Cada servicio solicitado
requiere para su ejecucin el acceso a los datos contenidos en la BDC-SIE. Este acceso lo
maneja transparentemente el ArcIMS Spatial Server usando el software ArcSDE, que acta
como compuerta a la base de datos BDC-SIE.
28
Capa de
Presentacin
Capa de
Lgica del
Negocio
Capa de
Datos
BDC-SIA
Cliente
Aplicacin GIS-Web
Internet Browser
Servidor WEB
ArcIMS Application
Server
ArcSDE
ArcIMS Viewer
ArcIMS Spatial
Server
ArcIMS Application
Server Conectors
DBMS-ORACLE
Capa de
Presentacin
Capa de
Lgica del
Negocio
Capa de
Datos
BDC-SIA
Cliente
Aplicacin GIS-Web
Internet Browser
Servidor WEB
ArcIMS Application
Server
ArcSDE
ArcIMS Viewer
ArcIMS Spatial
Server
ArcIMS Application
Server Conectors
DBMS-ORACLE

Figura.3.7. Patrn arquitectnico de las aplicaciones GIS-Web
Patrn de aplicaciones funcionales
Un tipo de aplicacin ms complejo es aquel en el cual la funcionalidad de la aplicacin va
ms all de una aplicacin GIS convencional. Los sistemas de informacin funcional son un
tipo de aplicacin que requieren combinar funciones de procesamiento de datos provenientes
de la BDC-SIE, con otros tipos de procesamiento de datos provenientes de bases de datos
no-geogrficas. Para este tipo de aplicaciones, se propone un patrn arquitectnico de tres
capas, en el cual cada capa es desarrollada usando componentes de software. La figura 3.8
muestra el patrn arquitectnico de este tipo de aplicacin SIE.
Capa de Presentacin Capa de Lgica del
Negocio
Capa de Datos
DBMS
Servidor
Web
Navegador
estndar
C
o
m
p
o
n
e
n
t
e
s

d
e

I
n
t
e
r
f
a
z

U
/
S

L
a
d
o

d
e
l

C
l
i
e
n
t
e
C
o
m
p
o
n
e
n
t
e
s

d
e

I
n
t
e
r
f
a
z

U
/
S

L
a
d
o

d
e
l

S
e
r
v
i
d
o
r

W
e
b
Servidor de
Aplicaciones
GIS Server
C
o
m
p
o
n
e
n
t
e
s

F
u
n
c
i
o
n
a
l
e
s

e
n

J
a
v
a
,

C
#
,

C
+
+
,

C
o
m
p
o
n
e
n
t
e
s

F
u
n
c
i
o
n
a
l
e
s
(
A
r
c
O
b
j
e
c
t
s
)
ArcSDE
BDC-SIA
Capa de Presentacin Capa de Lgica del
Negocio
Capa de Datos
DBMS
Servidor
Web
Navegador
estndar
C
o
m
p
o
n
e
n
t
e
s

d
e

I
n
t
e
r
f
a
z

U
/
S

L
a
d
o

d
e
l

C
l
i
e
n
t
e
C
o
m
p
o
n
e
n
t
e
s

d
e

I
n
t
e
r
f
a
z

U
/
S

L
a
d
o

d
e
l

S
e
r
v
i
d
o
r

W
e
b
Servidor de
Aplicaciones
GIS Server
C
o
m
p
o
n
e
n
t
e
s

F
u
n
c
i
o
n
a
l
e
s

e
n

J
a
v
a
,

C
#
,

C
+
+
,

C
o
m
p
o
n
e
n
t
e
s

F
u
n
c
i
o
n
a
l
e
s
(
A
r
c
O
b
j
e
c
t
s
)
ArcSDE
BDC-SIA

Figura 3.8. Patrn arquitectnico para sistemas de informacin funcional
Este patrn aprovecha las capacidades de desarrollo de aplicaciones empresariales que
ofrece ArcGIS, a travs de la coleccin de componentes de software GIS denominado
ArcObjects. Estos componentes ofrecen un conjunto de funciones especializadas para apoyar
el desarrollo de aplicaciones GIS complejas.
La librera de objetos ArcObjects puede ser utilizada para desarrollar aplicaciones de diferente
complejidad usando ArcGIS Desktop, ArccGIS Server y ArcGIS Engine. Estas aplicaciones se
pueden desarrollar bajo una de las siguientes plataformas de ejecucin: Java, C++, C#, .NET,
J2EE y COM y bajo una variedad de sistemas operativos Windows y UNIX.
La figura 3.9 muestra la relacin entre los dos servidores que se requieren para implementar la
Capa de Lgica de Negocios de una aplicacin SIE de tipo funcional. Ntese que los
componentes de la aplicacin (componentes .NET Java) interactan con los componentes
ArcObjects usando proxies. De esta manera, las funciones de geoprocesamiento (funciones
GIS) son invocadas por los componentes de la aplicacin haciendo uso de las interfaces de
programacin (APIs) que proveen los componentes ArcObjects. Los desarrolladores de
aplicaciones SIE pueden, de esta manera, desarrollar aplicaciones funcionales que invocan,
cuando sea necesario, las funciones GIS que provee el software ArcGIS Server.

Figura 3.9. Despliegue de los componentes de lgica de negocios en los servidores de la aplicacin
(ESRI, 2005)

30

Captulo
El Modelo de Actores
4

Este modelo es el segundo de los tres componentes que integran el Mtodo de Desarrollo de
un SIE (WATCH). Su funcin es discutir todos aquellos aspectos organizativos relacionados
con los actores, equipos de trabajo y dems interesados vinculados al desarrollo de las
aplicaciones de un SIE.
Un actor es un individuo o una unidad organizacional que esta activamente involucrada en el
proyecto o cuyos intereses pueden ser afectados positiva o negativamente como resultado de
la ejecucin del proyecto.
El Modelo de Actores describe las modalidades de organizacin de los equipos de trabajo que
desarrollarn las aplicaciones de un SIE.; as como, los roles y responsabilidades de aquellos
actores que integrarn estos equipos de trabajo. El modelo establece, tambin, las relaciones
entre los equipos de trabajo y otros interesados, tales como los usuarios del sistema.
El modelo ser utilizado por cada equipo de trabajo que tenga a su cargo el desarrollo de una
aplicacin SIE, con la finalidad de definir su estructura organizativa, los roles y
responsabilidades de cada uno de los miembros del equipo y dems aspectos requeridos
para la elaboracin del Plan de Gestin de Recursos Humanos de cada proyecto.
Objetivos del modelo
El Modelo de Actores tiene como objetivos los siguientes:
Identificar a los actores o interesados en el desarrollo de las aplicaciones SIE.
Describir como deben organizarse los equipos de trabajo que tendrn a su cargo el
desarrollo de las aplicaciones de un SIE.
Establecer los roles y responsabilidades generales que deben asumir los diferentes
actores que participan en el desarrollo de las aplicaciones de un SIE.
Componentes del modelo
Componente del WATCH cuya funcin es describir los aspectos organizativos de los equipos
de trabajo que desarrollarn las aplicaciones de un SIE. Est compuesto por:
Lista o Matriz de Interesados que identifica a los actores que pueden estar
relacionados con el desarrollo de las aplicaciones.
Estructura Organizacional de Referencia que sirve de modelo para la organizacin de
los equipos de desarrollo de aplicaciones y
Roles y Responsabilidades que describen las funciones y tareas que deben ejecutar
los actores de cada proyecto de desarrollo de aplicaciones.
Identificacin de Actores o Interesados (Stakeholders)
El desarrollo de las aplicaciones SIE requiere la participacin de un conjunto multidisciplinario
de actores con conocimientos, experiencia y competencias muy diversas. Estos actores son
individuos que pertenecen a diferentes grupos o unidades organizacionales de la empresa y
que tienen la necesidad o el inters en que el sistema SIE se desarrolle y entre en operacin.
Muchos de estos actores, pertenecen a diferentes Departamentos y Secciones de la Gerencia
de Informtica (GGA); otros pertenecen a otras Gerencias o Direcciones de la empresa; y
otras son personas, empresas instituciones externas que mantienen relaciones con CVG LA
EMPRESA o estn contratadas temporalmente para llevar a cabo actividades especficas en
proyectos relacionados con Un SIE.
Unidades interesadas en el desarrollo de un SIE
La Tabla 4.1 resume las principales unidades organizativas de LA EMPRESA que pueden
tener inters en el desarrollo de un SIE y que se beneficiarn con la informacin empresarial
que proveern las diferentes aplicaciones de este sistema. Esta tabla indica, a su vez, la
ubicacin de los actores en la estructura organizacional de la empresa.
Tabla 4.1. Unidades interesadas en el desarrollo de un SIE

Componente G
.

G
e
s
t
i
n

A
m
b
i
e
n
t
a
l
G
.

A
s
u
n
t
o
s

P
b
l
i
c
o
s
G
.

R
R
H
H
G
.

A
u
d
i
t
o
r
a

I
n
t
e
r
n
a
G
.

L
i
c
i
t
a
c
i
n
G
.

C
o
n
t
r
a
l
o
r
a

I
n
t
e
r
n
a
D
.

P
l
a
n
i
f
i
c
a
c
i
n
D
.

S
e
r
v
i
c
i
o
s
D
.

T
e
l
e
m
t
i
c
a
D
.

E
x
p
a
n
s
i
n

d
e

G
e
n
e
r
a
c
i
n
D
.

P
r
o
y
e
c
t
o
s

T
r
a
n
s
m
i
s
i
n
D
.

O
p
e
r
a
c
i
n
,

M
a
n
t
.

Y

T
r
a
n
s
m
i
s
i
n
D
.

P
r
o
d
u
c
c
i
n
D
.
R
e
d
e
s

R
e
g
i
o
n
a
l
e
s

D
.

F
i
n
a
n
z
a
s

y

A
d
m
i
n
i
s
t
r
a
c
i
n
D
.

O
P
S
I
S
P
r
e
s
i
d
e
n
c
i
a

y

J
u
n
t
a

D
i
r
e
c
t
i
v
a
Geosfrico (Geologa,
Geomorfologa, Suelos
y Sismicidad)

SICR
L

IB
SOC IC
CMOC

IMejT
MT
IMejG
TR
D
Bitico (Fauna
y vegetacin)

IB SOC
IC

IMejT
MT
IMejG
TR
D
Hdrico
(Hidrologa y
Limnologa)

PSE
PC
SICR
IB SOC
IC
CMOC

IMejT
OT MT
IMejG
Planta
TR
D

Atmosfrico
(Clima, Meteorologa,
Descargas elctricas)
PSE AE L
IB SOC
IC

IMejT
OT MT
IMejG
Planta
TR
D

Socioeconmico
PSE
PC
SICR
IB SOC
IC
MT IMejG
TR
D

Documentos
Ambientales

PSE
PC
SICR
L

IB SOC
IC
CMOC

IMejT
MT
IMejG
TR
D

Donde:
PSE: Divisin de Planificacin del Sector Elctrico
PC: Divisin de Planificacin Corporativa
AE: Divisin de Apoyo Areo
SICR: Divisin de Seguridad Interna y Control de Riesgo
L: Divisin de Logstica
IB: Divisin de Ingeniera Bsica
SOC: Divisin de Supervisin de Obras Civiles
IC: Divisin de Ingeniera de Construccin
32
CMOC: Divisin de Consolidacin y Mantenimiento de Obras Civiles
IMejT: Divisin de Ingeniera de Mejoras de Transmisin
MT: Divisin de Mejoras de Transmisin
IMejG: Divisin de Ingeniera de Mejoras de Generacin
Plantas: Divisin de Plantas
TR: Divisin de Transmisin Regional
D: Divisin de Distribucin

Organizacin de los equipos de desarrollo
Estructura organizativa
Para organizar los diferentes equipos de desarrollo de aplicaciones SIE se propone una
estructura clsica basada en las reas de procesos tcnicos que caracterizan a la Ingeniera
de Software: Anlisis, Diseo, Implementacin, Pruebas e Instalacin del Sistema.
La Figura 4.1 muestra el organigrama de referencia que ser empleado, por el Lder del
Proyecto SIE, para estructurar cada uno de los diferentes equipos que desarrollarn las
aplicaciones SIE.

Figura 4.1. Organizacin de los Equipos de Desarrollo de Aplicaciones SIE
Las ventajas de esta estructura son las siguientes:
Simplicidad y adaptabilidad: Es suficientemente simple, por lo que facilita su
adecuacin a las caractersticas de cada proyecto particular.
Alineacin al Modelo de Procesos: Se corresponde con las actividades tcnicas del
Modelo de Procesos.
Facilidad de reubicacin de los miembros: La asignacin de miembros del equipo de
desarrollo a los diferentes grupos que lo conforman es temporal y su duracin
depende de la duracin de los procesos correspondientes.
Clara definicin de las lneas de autoridad: La lneas de autoridad y la jerarqua
gerencial del proyecto se definen con bastante claridad.
Descripcin de actores que integran la estructura
1) Lder del Proyecto SIE.- Es el responsable del desarrollo y puesta en operacin de todo
el Proyecto SIE, incluyendo sus tres etapas: (I) Diseo de la BDC-SIE, (II) Implantacin de
la BDC-SIE y (III) Desarrollo de las Aplicaciones de un SIE. Reporta directamente al
Comit Directivo del Proyecto SIE (ver figura 4.3).
2) Lder de Desarrollo de Aplicaciones.- Es el responsable del desarrollo de una
aplicacin SIE. Reporta directamente al Lder del Proyecto SIE. Ejecuta todos los
procesos gerenciales indicados en el Modelo de Procesos (ver Captulo 5).
3) Grupo de Anlisis.- Est conformado por uno o ms especialistas en Anlisis de
Negocios y Anlisis de Sistemas. Reporta al Lder del Desarrollo de Aplicaciones. Es
responsable de los siguientes procesos descritos en el Modelo de Procesos:
i. Modelado del Dominio de Aplicacin
ii. Ingeniera de Requisitos
4) Grupo de Diseo.- Est compuesto por uno o ms especialistas en Diseo de Sistemas
de Informacin Geogrfica y Diseo de Software. Reporta al Lder del Desarrollo de
Aplicaciones. Es responsable de los siguientes procesos descritos en el Modelo de
Procesos:
i. Diseo Arquitectnico de la Aplicacin
ii. Diseo Detallado de la Aplicacin
5) Grupo de Implementacin.- Est integrado por uno o ms especialistas en
Programacin de Aplicaciones Web y/o Sistemas de Informacin Geogrfica. Reporta al
Lder del Desarrollo de Aplicaciones. Es responsable de los siguientes procesos descritos
en el Modelo de Procesos:
i. Construccin de la Aplicacin
ii. Instalacin de la Aplicacin
6) Grupo de Pruebas.- Est compuesto por uno o ms especialistas en Pruebas de
Software. Reporta al Lder de Desarrollo de Aplicaciones. Es responsable de los
siguientes procesos descritos en el Modelo de Procesos:
i. Pruebas de la Aplicacin, incluyendo pruebas de unidad, pruebas de integracin,
pruebas del sistema, pruebas de aceptacin, pruebas funcionales y pruebas no-
funcionales.
Roles y responsabilidades
Los actores o interesados identificados en la Tabla 1 participan en cada proyecto de diferentes
maneras. Dependiendo de su cargo, posicin, experiencia, conocimientos y responsabilidades
asignadas, estos actores tendrn una participacin en cada proyecto que debe ser definida
con claridad. La identificacin de roles tiene el propsito de definir lo que los diferentes actores
deben realizar en el proyecto.
34
Un rol se refiere a un conjunto definido de actividades y responsabilidades que una persona,
grupo de personas o unidad organizacional debe ejecutar en el marco de un proyecto. Es, por
consiguiente, una designacin temporal de responsabilidades. Es importante destacar,
tambin, que un conjunto de roles pueden ser asignados a un mismo interesado, sea este una
persona, grupo de personas o unidad organizacional.
Identificacin y clasificacin de roles
La figura 4.2 muestra los actores y los roles que se emplearn en el mtodo WATCH para
designar, de manera genrica, a los diferentes actores o interesados que participan o estn
vinculados con el desarrollo de los proyectos de aplicaciones SIE.
Actores
Roles
Actores
Roles

Figura 4.2. Actores y roles relacionados con el desarrollo de las aplicaciones SIE
Descripcin de roles y responsabilidades
Las principales responsabilidades que tienen cada uno de los roles que ejercern los
miembros de los equipos de desarrollo de aplicaciones SIE, se resumen en la Tabla 4.2.
Tabla 4.2. Roles y responsabilidades de los actores que participan en los equipos de Desarrollo de
Aplicaciones SIE
Rol Responsabilidades
Lder de
Desarrollo de
Aplicaciones
Elaborar el Plan de Proyecto de desarrollo de la
aplicacin SIE que le sea asignada
Coordinar con el Lder del Proyecto SIE la ejecucin
de las actividades de su equipo de desarrollo de
aplicaciones.
Prestar asistencia tcnica a los miembros del equipo
de desarrollo.
Controlar la ejecucin del Plan del Proyecto de
desarrollo de la aplicacin.
Reportar al Lder del Proyecto SIE el progreso del
proyecto de desarrollo de la aplicacin.
Analista de
Negocios
Modelar el dominio de la aplicacin SIE..
Servir de enlace entre los usuarios y el equipo de
desarrollo.
Asegurar que los productos del desarrollo de la
aplicacin SIE estn alineados al sistema de negocios
que acta como dominio de la aplicacin.
Analista de
Sistemas
Descubrir, analizar, especificar y documentar los
requisitos de la aplicacin SIE.
Validar, en conjunto con los usuarios, los requisitos
establecidos.
Gestionar los requisitos.
Diseador de
Sistemas
Disear la arquitectura de la aplicacin SIE y
especificar tcnicamente sus componentes.
Disear los detalles de cada componente: Interfaz U/S,
Bases de Datos, Programas y Documentacin.
Programador
Codificar, documentar y probar los componentes de
software de la aplicacin SIE.
Depurar los componentes que tengan faltas y fallas.
Integrar los componentes de la aplicacin y
desplegarlos en la plataforma de ejecucin del
proyecto.
Especialista en
Pruebas
Verificar y validar el sistema y sus diferentes
componentes.
Disear y ejecutar pruebas de unidad, de integracin,
del sistema y de aceptacin de la aplicacin.

Los equipos de desarrollo se apoyan en un conjunto de actores vinculados al Proyecto SIE y
cuya participacin es clave para facilitar las actividades tcnicas y gerenciales que los equipos
de desarrollo requieren. La Tabla 4.3 describe estos roles y responsabilidades que son propios
el personal de apoyo identificado en la figura 4.2.
Tabla 4.3. Roles y responsabilidades de los actores que apoyan a los Equipos de Desarrollo de
Aplicaciones SIE
Lder del Proyecto
SIE
Gestionar el desarrollo de todo el Proyecto SIE,
incluyendo la planificacin del proyecto SIE, su
organizacin, la administracin de los recursos
asignados, la coordinacin y el control del proyecto.
Organizar los equipos de desarrollo de las diferentes
aplicaciones que integran Un SIE.
Coordinar, con el Lder de Desarrollo de cada
aplicacin SIE, la ejecucin de las actividades del
equipo de desarrollo.
Prestar asistencia tcnica y gerencial a los Lderes de
Desarrollo de Aplicaciones.

Especialista en
configuracin de
software
Elaborar los procedimientos necesarios para gestionar
los tems producidos en cada una de las aplicaciones
SIE y controlar los cambios que puedan surgir en cada
una de ellas
Gestionar la configuracin de cada una de las
aplicaciones SIE
Especialista en
calidad
Asegurar la calidad del software producido por los
equipos de desarrollo
Velar que los equipos de desarrollo empleen
apropiadamente el proceso de desarrollo de
36
aplicaciones definido a partir del Mtodo WATCH
Administrador de
Bases de Datos
Proveer la informacin tcnica necesaria para que los
equipos de desarrollo puedan acceder a la BDC-SIE
Garantizar que los equipos de desarrollo hagan un uso
apropiado y permitido de la BDC-SIE
Facilitador
Capacitar a los equipos de desarrollo en el uso del
mtodo WATCH y las diferentes tcnicas,
herramientas, prcticas y estndares requeridos para
desarrollar aplicaciones SIE.
Capacitar a los equipos de desarrollo en el uso de la
plataforma de hardware y software requerida para
desarrollar las aplicaciones SIE
Consultor
Asesorar a los equipos de desarrollo de aplicaciones
SIE en el uso de los mtodos, tcnicas, estndares,
prcticas y herramientas requeridas en el Proyecto SIE
Administrador de
Sistemas
Mantener un alto nivel de disponibilidad de la
plataforma o infraestructura de hardware/software
usada para el desarrollo del Proyecto SIE
Dar soporte tcnico a los equipos de desarrollo en el
uso de la infraestructura de hardware/software.

Relaciones estructurales
La figura 4.3 muestra las relaciones de autoridad y jerarqua organizacional entre los equipos
de desarrollo de aplicaciones del proyecto y otras unidades organizacionales de la empresa.

Figura 4.3. Relaciones entre los Equipos de Desarrollo de Aplicaciones y otras Unidades
Como puede observarse en la figura 4.3, la estructura organizacional del Proyecto SIE es del
tipo matricial. En el tope de la estructura del Proyecto SIE
1
se encuentra el Comit Directivo, el
cual est integrado por personal ejecutivo de la empresa que promueve el desarrollo del
sistema SIE. Este comit toma las decisiones econmicas, tcnicas, presupuestarias ms
importantes relacionadas con el Proyecto SIE y el desarrollo de sus diferentes componentes
arquitectnicos.
El Lder del Proyecto SIE es el encargado de gestionar el proyecto completo de desarrollo del
sistema SIE, incluyendo la BDC-SIE, las aplicaciones SIE y dems componentes que integran
la arquitectura de un SIE descrita en el Captulo 1.
El desarrollo de cada aplicacin SIE es asignado a un equipo de desarrollo, el cual es dirigido
por un Lder de Desarrollo de Aplicaciones. Este equipo est integrado por personal adscrito a
diferentes unidades funcionales de la empresa; particularmente de los departamentos de las
Gerencias de Gestin Ambiental, Telemtica y otras gerencias usuarias de la aplicacin que
se desea desarrollar.

1
Ver documento No. SIE PP II 04: Plan de recursos humanos del proyecto SIE
38

Captulo
El Modelo de Procesos
5

El modelo de procesos es el tercer y ltimo componente del mtodo WATCH. Este modelo
establece los procesos necesarios para: (1) gestionar cada uno de los proyectos de desarrollo
de aplicaciones de un SIE y (2) llevar a cabo las actividades tcnicas y de soporte que
requieren estos proyectos.
En este captulo, se describe, de una manera general, el modelo de procesos del mtodo
WATCH. Se presentan los conceptos fundamentales para la comprensin del modelo. Se
discuten la metfora en la cual est fundamentado el modelo, su estructura y cada uno de sus
componentes.
Objetivos del modelo de procesos
Los objetivos de este modelo son los siguientes:
Identificar los procesos de gestin, tcnicos y de soporte que deben utilizarse en el
desarrollo de las aplicaciones SIE.
Describir cada uno de los procesos tcnicos, gerenciales y de soporte que los equipos de
desarrollo deben emplear para elaborar cada una de las aplicaciones SIE.
Facilitar la planificacin de los proyectos de desarrollo de aplicaciones SIE,
proporcionando una estructura de procesos que puede ser usada para elaborar la
Estructura de Desagregacin del Trabajo (WBS) de cada proyecto.
Estructura del modelo de procesos
El modelo de procesos del WATCH est formado por un total de trece (13) procesos, los
cuales, organizados en la forma una cadena de valor (ver figura 5.1), representa el proceso
completo de desarrollo de aplicaciones de un SIE. En esta cadena, los procesos de ingeniera
que se requieren para producir una aplicacin cualquiera de un SIE constituyen los procesos
fundamentales o claves de la cadena; mientras que sus procesos de apoyo estn compuestos
por todos aquellos procesos encargados de la gestin del proyecto y de otras actividades
relacionadas con la configuracin y calidad de la aplicacin, la gestin de riesgos y la
capacitacin del personal.

Figura 5.1. Los procesos del WATCH
Clasificacin de los procesos
Con el objeto de facilitar su descripcin, estos procesos se han organizado en tres grupos (ver
figura 5.2). El grupo de Procesos Tcnicos enmarcan todas las actividades de ingeniera que
estn relacionadas directamente con el ciclo de desarrollo de las aplicaciones. El grupo de
Procesos de Gestin cubre todas las actividades de gestin de proyectos de software. El
grupo de Procesos de Soporte concentra todas aquellas actividades que son necesarias para
apoyar la ejecucin de los procesos tcnicos y gerenciales.

Figura 5.2. Procesos del Mtodo WATCH
40
Relaciones entre los procesos
Los procesos sealados en la figura 5.2 se ejecutan en un orden preestablecido. Este orden
define el ciclo de desarrollo de una aplicacin SIE y ha sido elaborado siguiendo una metfora
basada en el reloj (Montilva and Barrios, 2004b). Un reloj est compuesto por un motor que
mueve agujas a lo largo de un dial. Este dial indica un orden progresivo, cuyo seguimiento
puede, en cualquier momento, ser alterado usando el motor, bien para avanzar hacia la hora
siguiente para retroceder a horas anteriores.
El orden de ejecucin de los procesos de nuestro modelo se asemeja a un reloj. Los procesos
de gestin y soporte estn ubicados en el centro del reloj; pues, se encargan de controlar la
ejecucin de los procesos tcnicos que se ubican en el dial del reloj, tal como lo muestra la
figura 5.3.
Una vez planificado el proyecto, el desarrollo de la aplicacin se inicia con el proceso tcnico
Modelado del Dominio de la Aplicacin y contina en el orden cclico indicado hasta llegar al
proceso tcnico Entrega de la Aplicacin. Cada ciclo del reloj WATCH representa el
desarrollo de una aplicacin SIE. Cuando la aplicacin es muy compleja y extensa, es
preferible dividirla en subsistemas que se desarrollan gradual o incrementalmente. En este
caso, cada ciclo representa el desarrollo de un subsistema.

a) Metfora del reloj
Modelado
del Dominio de
la Aplicacin
Ingeniera
de Requisitos
Diseo
Arquitectnico
Diseo
Detallado
Pruebas de la
Aplicacin
Entrega de la
Aplicacin
Procesos
Gerenciales y
de Soporte
Operacin
y
Mantenimiento
Construccin
& Integracin

b) Estructura y orden de los procesos del WATCH
Figura 5.3. Flujo de trabajo del modelo de procesos
Caractersticas del modelo de procesos
El modelo de procesos del WATCH posee un conjunto de caractersticas importantes que
deben conocerse para facilitar su instanciacin o uso. Estas caractersticas son las siguientes:
1) Es estructurado y modular.- Posee una estructura jerrquica claramente definida que facilita su
comprensin y utilizacin. La figura 5.4 muestra esta estructura jerrquica de cinco (5) niveles
representada mediante un diagrama de clases.
Grupo de Procesos
Proceso
Subproceso
Actividad
Tarea
*
*
*
*

Figura 5.4 Estructura de niveles del modelo de procesos
2) Es iterativo. Los procesos tcnicos se ejecutan en orden secuencial. Sin embargo, es posible
iterar (retornar a procesos anteriores) a fin de corregir defectos en los productos de los procesos
anteriores.
3) Es incremental. El modelo considera el proceso de desarrollo de aplicaciones como un proceso
incremental. Cada ciclo de ejecucin produce un subsistema de la aplicacin o una nueva versin
operativa de la aplicacin.
4) Promueve la reutilizacin de activos de software.- El modelo promueve la reutilizacin de
activos de software, lo cual reduce costos y aumenta la calidad de los productos de software que
se elaboren. Entre estos activos estn los siguientes: arquitecturas de dominio, patrones de
diseo, componentes de software reutilizables y plantillas de documentos (Ej., plantillas para
planes de proyecto, pruebas de software, manuales de uso, etc.).
5) Es representado visualmente.- En la descripcin del modelo se han empleado lenguajes de
modelado grfico o visual ampliamente conocidos, en particular, UML, UML Business y BPMN.
Estos lenguajes facilitan la representacin de los procesos y reducen los problemas de
comunicacin que, con respecto al mtodo, puedan surgir entre los miembros de los equipos de
desarrollo.
6) Verifica y valida continuamente la calidad de los productos.- El modelo asegura la calidad de
las aplicaciones, a travs del uso de un proceso bien definido de Verificacin y Validacin (V&V)
que se aplica a todos los productos intermedios y finales que se elaboran a lo largo del desarrollo
de cada aplicacin.
7) Emplea las mejores prcticas y procesos de gestin de proyectos.- El modelo emplea
procesos y prcticas establecidas en el cuerpo de conocimientos de gestin de proyectos
propuesto por el PMI (Project Management Institute). Este cuerpo de conocimientos es, tambin,
empleado en la metodologa desarrollada por LA EMPRESA para gestionar sus proyectos de
ingeniera. Los procesos de gestin del modelo estn alineados a esta metodologa.
8) Integra los procesos de gestin con los procesos tcnicos y de soporte.- El modelo define
tres grupos de procesos: tcnicos, gerenciales y de soporte. Los procesos tcnicos se relacionan
42
con las actividades de anlisis, diseo, implementacin y pruebas de las aplicaciones. Los
procesos de gestin se encargan de gestionar el desarrollo de cada aplicacin como un proyecto
de ingeniera; involucran, por lo tanto, actividades de planificacin, organizacin, administracin,
direccin y control del proyecto. Por su parte, los procesos de soporte complementan los procesos
tcnicos y gerenciales con actividades tales como: el aseguramiento de la calidad, la gestin de la
configuracin, la capacitacin de los actores y la gestin de riesgos del proyecto.
La estructura de procesos del mtodo WATCH
Tal como se indica en la figura 5.4, la estructura del modelo de procesos WATCH es
jerrquica. El nivel ms alto de esta estructura es el Nivel de Grupos de Procesos, el cual est
formado por los grupos de procesos de gestin, de soporte y tcnicos. Cada uno de estos
grupos de procesos se divide, a su vez, en procesos ms especficos. Cada proceso se divide
en sub-procesos y estos, a su vez, en actividades; las cuales, se dividen finalmente en tareas.
La profundidad de la jerarqua vara de un grupo de procesos a otro. As, por ejemplo, el grupo
de procesos tcnicos se estructura en cuatro niveles: procesos, sub-procesos, actividades y
tareas. Mientras que el grupo de procesos de gestin se estructura en slo dos niveles:
procesos y actividades.
La Tabla 5.1 describe la estructura jerrquica del modelo de procesos en sus dos niveles ms
altos: grupo de procesos y procesos. A esta tabla se ha agregado la columna Productos para
indicar los resultados que se producen en cada proceso. Esto permite, a su vez, asociar el
modelo de procesos con el modelo de productos del mtodo WATCH. La descomposicin de
los niveles inferiores cada uno de los procesos se da en los captulos respectivos.
Tabla 5.1. Descomposicin jerrquica de los procesos del Mtodo WATCH
Grupo de Procesos Procesos Productos
Planificacin del Proyecto (PP)

Organizacin del Proyecto (OP)

Direccin del Proyecto (DP)

Administracin de Recursos del
Proyecto (AP)

Procesos de Gestin
Control del Proyecto (CP)
Caso de Negocios
Plan del Proyecto
Informes de Gestin
Proceso de desarrollo
Notas y correspondencia
del proyecto

Gestin de la Configuracin del
Software (SCM)

Plan de Gestin de la
Configuracin
Aseguramiento de la Calidad del
Software (SQA)

Plan de Gestin de Calidad
Gestin de Riesgos (GR)

Plan de Gestin de Riesgos
Verificacin y Validacin (V&V)

Plan de V&V
Plan de Pruebas
Procesos de Soporte
Capacitacin (CAP) Plan de Capacitacin
Modelado del Dominio de la
Aplicacin (MDA)
Modelo del Dominio de la
Aplicacin
Ingeniera de Requisitos (IR) Documento de Requisitos
Procesos tcnicos
Diseo Arquitectnico (DA) Documento de Diseo
Grupo de Procesos Procesos Productos
Diseo Detallado (DD)
Construccin & Integracin (C&I) Documento de
Implementacin
Pruebas de la Aplicacin (PA) Documento de Pruebas
Entrega de la Aplicacin (EA) Aplicacin SIE
Programas
Base(s) de Datos
local(es)
Manuales de uso
Manuales de
mantenimiento

44

Captulo
Procesos de Gestin del Proyecto
6

La Gestin del Proyecto consta de un conjunto de procesos de tipo gerencial necesario para
asegurar que la ejecucin del proyecto sea exitosa; es decir, que la aplicacin SIE se
desarrolle a tiempo, dentro del presupuesto establecido y que posea una alta calidad.
La responsabilidad principal de este proceso recae en el Lder del Equipo de Desarrollo. A
travs de este proceso, el Lder planifica el proyecto, determina la organizacin ms apropiada
para el grupo equipo de actores que desarrollar la aplicacin SIE, dirige a este grupo,
administra los recursos que le han asignado al proyecto y controla el desarrollo de dicho
proyecto con respecto al plan establecido.
La Gestin del Proyecto es un grupo de procesos que se ejecuta a lo largo de toda la duracin
del proyecto. Se inicia desde el instante en que el Comit Directivo del Proyecto SIE aprueba
el desarrollo de una nueva aplicacin y culmina con la entrega de la aplicacin a sus usuarios
directos.
En este captulo, se discute cada uno de los procesos de gestin y se establecen sus
relaciones con los modelos de actores y de productos.
Objetivos del grupo de procesos
El grupo de procesos de gestin tiene como objetivos los siguientes:
Asegurar que el desarrollo de la aplicacin sea sistemtico, organizado, eficaz y eficiente,
mediante el empleo de los procesos gerenciales de planificacin, organizacin, direccin,
administracin de recursos y control.
Garantizar que la aplicacin se desarrolle a tiempo, bajo el presupuesto asignado y
siguiendo los estndares, planes y procedimientos establecidos para asegurar la calidad
de la aplicacin.
Descripcin general del grupo de procesos
El grupo de procesos de gestin consta de cinco procesos que cubren el ciclo gerencial de
proyectos de software. Estos procesos se indican en la figura 6.1.

Figura 6.1. Diagrama general del grupo de procesos de gestin del proyecto
Los procesos de gestin del proyecto se inician desde el momento en que un grupo de
interesados plantea, ante la(s) Gerencia(s) correspondiente(s), la necesidad de disponer de
una nueva aplicacin. Si esta(s) Gerencia(s) da(n) el visto bueno, se inicia el proceso de
elaboracin del Caso de Negocios, el cual es elaborado por este mismo grupo. Este
documento es discutido por el Comit Directivo del Proyecto SIE, quien decide si el proyecto
contina, se difiere o se niega.
Si el desarrollo de la aplicacin es aprobado por el Comit Directivo, este comit debe
designar al Lder de Desarrollo de la aplicacin quien deber realizar los procesos de
planificacin, organizacin, direccin, administracin de recursos y control del proyecto.
El Plan del Proyecto, elaborado durante la ejecucin del proceso de Planificacin del Proyecto,
debe describir las actividades, tiempos, recursos y costos requeridos para producir una
aplicacin de alta calidad. Este documento se mantiene actualizado peridicamente y a lo
largo del desarrollo de la aplicacin, a travs del proceso Control del Proyecto.
Los procesos de gestin se llevan a cabo en paralelo con los procesos de soporte y los
procesos tcnicos (ver Captulos 7 -10).
Los procesos de gestin finalizan cuando la aplicacin es liberada; es decir, entregada a sus
usuarios en un estado operativo satisfactorio.

Actores involucrados
En los procesos de gestin del desarrollo de una aplicacin SIE intervienen diferentes actores
interesados. Algunos de ellos participan de un modo activo, por ejemplo, tomando
decisiones ejecutando procesos; mientras que otros, simplemente, colaboran indirectamente
en la ejecucin de estos procesos. A continuacin, se identifican estos actores (ver Captulo 4)
y se describen brevemente sus principales responsabilidades durante la ejecucin de los
procesos de gestin.
1) Usuarios internos.- El personal ejecutivo de la empresa (directores, gerentes, jefes de
departamento y jefes de seccin) interviene, durante los procesos de gestin, promoviendo,
apoyando y validando el desarrollo de una nueva aplicacin SIE. De igual manera, los
especialistas y el personal tcnico de la empresa pueden promover el desarrollo de una nueva
aplicacin, bien impulsando la idea y/o elaborando el Caso de Negocios de la nueva
aplicacin.
2) Comit Directivo del Proyecto SIE.- Participa activamente en la toma de decisiones desde el
momento en que surge la necesidad de desarrollar una nueva aplicacin hasta que la
aplicacin es entregada a sus usuarios. Este comit decide el inicio de cada proyecto, evala
peridicamente su desarrollo y resuelve todos los aspectos financieros, polticos y econmicos
de cada uno de ellos.
3) Lder del Proyecto SIE.- Es el responsable de la gestin de todo el Proyecto SIE. Apoya al
Lder del Desarrollo de cada aplicacin SIE en diferentes aspectos gerenciales y tcnicos de la
ejecucin del proyecto de desarrollo. Reporta al Comit Directivo del Proyecto SIE.
4) Lder del Desarrollo de Aplicaciones.- Es el responsable de la ejecucin de todos los cinco
procesos de gestin. Reporta al Lder del Proyecto SIE. Dirige y coordina al Equipo de
Desarrollo de la aplicacin que le es encomendada.
46
Productos de los procesos de gestin
Caso de Negocios
Es el primer documento que se elabora antes de iniciar formalmente el proyecto. Su objetivo
es justificar econmica y tcnicamente la necesidad de desarrollar una nueva aplicacin SIE.
Es elaborado por el grupo de interesados en que la aplicacin se desarrolle. Su objetivo es
convencer al Comit Directivo del Proyecto SIE de la necesidad de desarrollar la aplicacin,
para dar respuesta a un conjunto de necesidades de informacin, que tiene una o ms
unidades organizacionales de la empresa.
El Caso de Negocios es utilizado por el Comit Directivo para decidir si la aplicacin debe
desarrollarse, diferirse o no procede. Esta decisin determina el inicio, diferimiento o
cancelacin del proyecto. Si se decide iniciar el proyecto, el Caso de Negocios establece un
compromiso del Comit Directivo para la asignacin de los fondos que el proyecto requiere.
Plan del Proyecto
Es el documento ms importante de la gestin del proyecto. El plan del proyecto determina,
rige y gua la ejecucin de todo el proyecto de desarrollo de una aplicacin. Este documento
describe: (1) los objetivos y alcance de la aplicacin SIE que se quiere desarrollar; (2) las
actividades que deben ejecutarse para que la aplicacin se desarrolle exitosamente; (3) los
recursos humanos, tecnolgicos, financieros, fsicos y materiales necesarios para desarrollar
la aplicacin; (4) el presupuesto que establece costo del proyecto; y (5) el proceso tcnico
necesario para desarrollar la aplicacin.
El Plan del Proyecto es un documento compuesto por un conjunto de planes diferentes, los
cuales se van desarrollando en diferentes etapas del desarrollo del proyecto. La figura 6.2
ilustra los componentes del Plan del Proyecto.

Figura 6.2. Componentes del Plan del Proyecto
Proceso de Desarrollo de la Aplicacin
Al igual que el Plan del Proyecto, este es uno de los documentos ms importantes que deben
producirse al inicio de cada proyecto de desarrollo de una aplicacin SIE. Este documento
describe detalladamente el proceso que el Equipo de Desarrollo debe seguir para producir la
aplicacin SIE. Este proceso se establece a travs de la instanciacin del Mtodo WATCH.
Los tres modelos que integran este mtodo modelos de productos, procesos y actores son
usados por el Lder de Desarrollo para establecer los detalles del proceso especfico que
guiar al Equipo de Desarrollo durante cada uno de los procesos tcnicos del proyecto.
La instanciacin del Mtodo WATCH es una actividad metodolgica en la cual el Lder de
Desarrollo de la aplicacin emplea este mtodo para determinar: (1) los productos especficos
que se producirn en este proyecto; (2) la estructura organizacional especfica del Equipo de
Desarrollo de la aplicacin que se va a elaborar; y (3) los procesos tcnicos, de gestin y de
soporte que se utilizarn para desarrollar la aplicacin.
Descripcin de procesos y actividades de gestin
Tabla 6.1. Estructura jerrquica de los procesos de gestin y sus productos
Procesos Actividades Productos
Planificacin del
Proyecto
Elaborar y validar Caso de Negocios
Planificar el alcance del proyecto
Elaborar la Estructura de Desagregacin del Trabajo (WBS)
Definir el proceso de desarrollo de la aplicacin mediante la
instanciacin del Mtodo WATCH
Planificar las actividades del proyecto
Estimar los recursos (humanos, tecnolgicos y de
infraestructura) que requiere el proyecto
Estimar el costo del proyecto
Elaborar el documento Plan del Proyecto
Validar el Plan del Proyecto
Caso de Negocios
Plan del Proyecto
Proceso de desarrollo de la
aplicacin SIE
Organizacin del
Proyecto
Definir roles y responsabilidades de los miembros del grupo de
desarrollo del proyecto (personal que ejecutar el proyecto)
Disear la estructura organizativa del grupo de desarrollo
(organigrama)
Plan de Gestin de RRHH
Direccin del
Proyecto
Ejercer el liderazgo del grupo de desarrollo
Supervisar el personal
Delegar autoridad
Motivar el personal
Coordinar las actividades
Comunicar resultados, decisiones e informacin sobre el
proyecto
Resolver conflictos

Informes de gestin, notas y
correspondencia sobre el
proyecto
Administracin de
Recursos del
Proyecto
Administrar los recursos humanos (RRHH) del proyecto
Administrar los recursos financieros del proyecto
Administrar los recursos tecnolgicos del proyecto (hardware,
software, redes, etc.)
Administrar la infraestructura de desarrollo del proyecto
(espacio fsico, mobiliario, materiales, insumos, etc.)
Informes de gestin
Control del Proyecto
Desarrollar estndares de rendimiento del proyecto
Establecer los mecanismos de monitora y reporte del proyecto
Medir y analizar el estado del proyecto
Tomar acciones correctivas
Actualizar el Plan del Proyecto
Informes de gestin sobre el
estado del proyecto
Plan del Proyecto
Actualizado

48
Planificacin del Proyecto
El desarrollo de una aplicacin SIE se inicia con el proceso del Planificacin del Proyecto (ver
figuras 6.1 y 6.3). Una vez que surge la necesidad de desarrollar una nueva aplicacin SIE,
sus interesados elaboran el Caso de Negocios. Este documento es validado por el Lder del
Proyecto SIE, antes de ser presentado al Comit Directivo del Proyecto SIE, quien decide si el
desarrollo de la nueva aplicacin procede o es rechazada.
Una vez aprobado el Caso de Negocios se designa el Lder de Desarrollo de la aplicacin,
quien se encarga de ejecutar el resto de las actividades de planificacin indicadas en el flujo
de trabajo de la figura 6.3.
Elaborar
Caso de
Negocios
Planificar el
Alcance del
Proyecto
Elaborar la
Estructura de
Trabajo (WBS)
Planificar
Actividades del
Proyecto
Estimar Recursos
Requeridos
Estimar Costos
del Proyecto
Elaborar
Documento
Plan del
Proyecto
Caso de Negocios
Plan del Proyecto
Validar
Caso de
Negocios
Aprobacin
aprobado
rechazado
Alcance y objetivos
del proyecto
WBS
Cronograma del
proyecto
Presupuesto
Validar
Plan del
Proyecto
Definir el proceso
de desarrollo de
la aplicacin
AND
AND
Proceso de
desarrollo

Figura 6.3 Flujo de trabajo del proceso Planificacin del Proyecto
Organizacin del Proyecto
El proceso de Organizacin del Proyecto (ver figura 6.4) consiste en definir: (1) el tamao del
Equipo de Desarrollo; (2) la estructura organizacional que se utilizar para conformar el Equipo
de Desarrollo de la aplicacin SIE; (3) los roles y responsabilidades de cada uno de los
miembros del equipo de desarrollo. Estos aspectos se integran para darle forma al documento
titulado Plan de Gestin de Recursos Humanos, el cual forma parte del Plan del Proyecto.

Figura 6.4 Flujo de trabajo del proceso Organizacin del Proyecto
Direccin del proyecto
Es responsabilidad del Lder de Desarrollo crear una atmsfera apropiada que facilite las
relaciones personales y profesionales entre los miembros del Equipo de Desarrollo. La
Direccin del Proyecto es un proceso en el cual el Lder ejerce su capacidad de liderazgo para
motivar a los miembros del Equipo de Desarrollo, coordinar sus actividades y mantener la
comunicacin necesaria con el personal del proyecto y los niveles gerenciales de la empresa
que soliciten informacin sobre el proyecto.
Administracin de Recursos
En este proceso, el Lder de Desarrollo se encarga de administrar todos los recursos
humanos, tecnolgicos y fsicos que le han sido asignados para ejecutar el proyecto (ver figura
6.5).
Las actividades de administracin de los recursos humanos involucran iniciar y concretar la
bsqueda, seleccin y contratacin de personal temporal para ejecutar actividades concretas
del proyecto, que no pueden ser ejecutadas por el personal de la empresa asignado al
proyecto. La administracin de recursos tecnolgicos consiste en definir, adquirir y/o instalar la
plataforma de hardware, software y redes que el proyecto requiere para su ejecucin. La
administracin de la infraestructura fsica consiste en asegurarle al Equipo de Desarrollo un
espacio fsico adecuado para llevar a cabo el desarrollo de la aplicacin.
50

Figura 6.5 Flujo de trabajo del proceso Administracin de Recursos del Proyecto

Control del Proyecto
Este proceso consiste en establecer, medir y evaluar el rendimiento de las actividades
ejecutadas con respecto a lo establecido en el plan del proyecto. Controlar el proyecto implica
comparar lo ejecutado con lo planificado, a fin de establecer los correctivos necesarios para
corregir las desviaciones.
La figura 6.6 ilustra el flujo de trabajo de este proceso. Las dos primeras actividades de control
que debe realizar el Lder de Desarrollo son: (1) establecer los mecanismos de monitora y
reporte de ejecucin del proyecto y (2) elaborar los estndares que sern usados para medir
el rendimiento del proyecto. Estos estndares y mecanismos son, luego, usados para
comparar los resultados alcanzados, hasta ese momento, con lo establecido en el Plan del
Proyecto. Si las diferencias entre lo ejecutado y lo planeado son significativas, se toman
decisiones que implican la actualizacin del Plan del Proyecto y/o la ejecucin de acciones
correctivas que lleven a reducir estas diferencias.

Figura 6.6 Flujo de trabajo del proceso Control del Proyecto

Tcnicas y herramientas
En la Tabla 6.2 se indican aquellas tcnicas, estndares, prcticas y herramientas
automatizadas ms relevantes y efectivas que pueden ser aplicadas en cada uno de los
procesos de gestin.

Tabla 6.2 Tcnicas y herramientas que pueden emplearse en los procesos de gestin
Proceso
Tcnicas, estndares y
mejores prcticas
Herramientas
Planificacin del
Proyecto
Estndar PMIBOK
Metodologa de Gerencia de
Proyectos de LA EMPRESA
PERT/CPM
Mtodo COCOMO II (estimacin de
costos)
Organizacin del
Proyecto
Diseo organizacional
Matriz de asignacin de
responsabilidades
Organigramas
Direccin del
Proyecto
Tcnicas de motivacin y liderazgo
Administracin de
Recursos

Control del
Proyecto
PERT/CPM
Herramienta para gestin de
proyectos (Ej. MS PROJECT)

52

Captulo
Procesos de Soporte
7

Adicionalmente a los procesos de gestin, existe un grupo de procesos que tienen un carcter
tcnico-gerencial y que contribuye a hacer ms efectivos los procesos de gestin. Este grupo
de procesos los denominamos procesos de soporte.
Su objetivo principal es complementar los procesos de gestin a travs de la gestin de los
productos, personas y procesos asociados al desarrollo de aplicaciones SIE.
En este captulo, se discuten cada uno de los procesos de soporte y se establecen sus
relaciones con los modelos de actores y de productos.
Objetivos del grupo de procesos
El grupo de procesos de soporte tiene como objetivo general complementar los procesos de
gestin mediante la gestin de productos, personas y procesos. De este objetivo general, se
definen los siguientes objetivos especficos:
Asegurar que los todos los productos producidos en cada proyecto de desarrollo de
aplicaciones SIE sean de alta calidad, cumplan con los requisitos establecidos y
satisfagan a sus usuarios.
Asegurar que el proceso de desarrollo definido para cada proyecto se cumpla. Este
proceso es definido mediante la instanciacin del Mtodo WATCH.
Controlar la configuracin de cada una de las aplicaciones SIE.
Manejar apropiadamente los riesgos que puedan surgir en cada uno de los proyectos de
desarrollo de aplicaciones SIE.
Garantizar el uso apropiado de las aplicaciones SIE mediante la capacitacin de sus
usuarios.
Garantizar que el personal de los equipos de desarrollo de aplicaciones SIE posean los
conocimientos, habilidades y destrezas necesarias para realizar eficaz y eficientemente
las actividades tcnicas, gerenciales y de soporte requeridas.
Descripcin general del grupo de procesos
El grupo de procesos de soporte consta de cinco procesos que se desarrollan en conjunto con
los procesos de gestin del proyecto. Estos procesos se indican en la figura 7.1.

Figura 7.1. Diagrama general del grupo de procesos de soporte
Actores involucrados
La responsabilidad principal de la ejecucin de este grupo de procesos recae tanto en el Lder
del Equipo de Desarrollo como en el Lder del Proyecto SIE, por cuanto la mayora de estos
procesos son ejecutados por el personal de apoyo del Proyecto SIE, en lugar del equipo de
desarrollo.
1) Lder del Proyecto SIE.-. Proporciona al Lder de Desarrollo de cada aplicacin SIE los
recursos tcnicos y humanos necesarios para gestionar la configuracin de la aplicacin,
asegurar su calidad, aminorar los riesgos, verificar y validar los productos del proyecto y
capacitar a los usuarios y a los miembros del equipo de desarrollo.
2) Lder del Desarrollo de Aplicaciones.-. Es responsable de gestionar los riesgos del
proyecto, verificar y validar los productos elaborados en el proyecto y capacitar a los miembros
del equipo de desarrollo y a los usuarios de la aplicacin SIE.
3) Especialista en Configuracin (SCM).- Es responsable de la gestin de la configuracin del
software producido en cada uno de los proyectos de desarrollo de aplicaciones SIE.
4) Especialista en Calidad (SQA).- Es responsable de la gestin y aseguramiento de la calidad
del software producido en cada uno de los proyectos de desarrollo de aplicaciones de un SIE.
5) Facilitadores.- Tienen la responsabilidad de preparar y ejecutar los programas de
capacitacin de usuarios de las aplicaciones SIE y del personal que participa en los equipos
de desarrollo de estas aplicaciones.
Productos de los procesos de soporte
Plan de Gestin de la Configuracin (Plan SCM)
Es un documento de tipo gerencial que describe las actividades, recursos, tiempos y costos
necesarios para controlar la configuracin de una aplicacin (el conjunto de productos que
surgen durante su desarrollo). Se elabora al inicio del proyecto, durante la ejecucin del
proceso Gestin de la Configuracin del Software (SCM).
El documento describe, entre otros, los siguientes elementos:
Objetivos y alcance de la SCM en el contexto de la aplicacin
Identificacin de los productos que estarn sujetos a control de configuracin
54
Lista de actividades de SCM y cronograma
Roles y responsabilidades del grupo encargado de la SCM
Prcticas, tcnicas y herramientas que se emplearn para la SCM
Plan de Aseguramiento de la Calidad (Plan SQA)
Es un documento gerencial que describe las actividades, procedimientos, responsabilidades y
recursos requeridos para asegurar que: (1) el proceso de desarrollo de una aplicacin se siga
y sea consistente con el Mtodo WATCH; y (2) la aplicacin satisfaga los atributos de calidad
establecidos para ella durante el proceso de Ingeniera de Requisitos.
Este documento debe identificar y describir los siguientes aspectos del Aseguramiento de la
Calidad del Software (SQA):
Objetivos y alcance de la SQA en el contexto de la aplicacin SIE que se va a
desarrollar.
Las actividades SQA y su cronograma
Las evaluaciones del proceso de desarrollo que deben realizarse
Las auditorias y revisiones de productos que deben realizarse
Los estndares y procedimientos que se emplearn para evaluar el proceso y revisar
los productos.
Roles y responsabilidades del grupo que se encargar de la SQA.
Los mecanismos y herramientas que se emplearn para asegurar la calidad de la
aplicacin.
Plan de Gestin de Riesgos
El objetivo de este documento es describir los procesos y productos de la Gestin de Riesgos
que ser empleada para identificar, analizar y controlar los eventos, factores condiciones
que puedan afectar la ejecucin del proyecto incidir negativamente en la calidad de sus
productos.
Este documento debe contener los siguientes elementos:
La Lista de Riesgos que identifica todos aquellos eventos, factores o condiciones que
pueden incidir negativamente en el desarrollo de la aplicacin y que tienen una
probabilidad de acontecer.
La Matriz de Riesgos que resulta del anlisis de los riesgos identificados en la Lista
de Riesgos. Esta matriz clasifica, evala y establece la prioridad de cada uno de los
riesgos identificados.
Las estrategias que se emplearn para gestionar los riesgos.
Las acciones de mitigacin y planes de contigencia que se aplicarn para reducir el
impacto de cada riesgo probable.
Los procedimientos de monitora y control de riesgos.
Plan de Verificacin y Validacin (Plan V&V)
Este documento describe las actividades, recursos, tiempos, tcnicas y procedimientos
necesarios para: (1) verificar que cada uno de los productos intermedios y finales, del
desarrollo de una aplicacin SIE, satisfacen los requisitos especificados en el Documento de
Requisitos; y (2) validar que la aplicacin, como producto final, satisface las necesidades de
informacin de sus usuarios; es decir, llena las expectativas de los usuarios.
La estructura y contenido de este documento, basado en el estndar IEEE-1012-1998, es el
siguiente:
Propsito del Plan V&V
Documentos referenciados
Definiciones
Descripcin general de la V&V
o Organizacin del grupo V&V
o Cronograma de actividades
o Esquema de niveles de integridad del software
o Recursos requeridos
o Responsabilidades
o Tcnicas, herramientas y mtodos que se emplearn en la V&V
Procesos de la V&V
o V&V del concepto de operacin de la aplicacin
o V&V de los requisitos
o V&V del diseo de la aplicacin
o V&V de la implementacin
o V& V de las pruebas
o V& V de la instalacin de la aplicacin
Mecanismos de reporte de las actividades V&V
Procedimientos de control
Tcnicas, herramientas y mtodos que se emplearn en la V/V
Plan de Pruebas
Es un documento que se deriva del Plan V&V. Tiene un carcter tcnico-gerencial y describe,
detalladamente, las actividades de Verificacin Dinmica (pruebas de software) que el Grupo
de Pruebas debe realizar, con la finalidad de detectar los errores (faltas y fallas) en cada uno
de los programas que haya sido elaborado por el Equipo de Desarrollo.
Este documento contiene los siguientes aspectos de las pruebas de cada aplicacin SIE:
Los objetivos de las pruebas.
Los niveles y tipos de pruebas que debern realizarse.
Los criterios de terminacin de cada tipo de prueba.
El modelo de proceso que se seguir para ejecutar las pruebas.
El cronograma de actividades de pruebas.
Las responsabilidades de los miembros del Grupo de Pruebas.
Las tcnicas y estrategias que se emplearn.
56
Los recursos requeridos para ejecutar las pruebas.
Los documentos que deben producirse durante las pruebas.
Los procedimientos de pruebas: casos de pruebas, reporte de pruebas, seguimiento
de la depuracin de errores.
Plan de Capacitacin
Este documento describe las actividades, recursos, costos y estrategias que se emplearn
para capacitar: (1) a los miembros del Equipo de Desarrollo, antes y durante la ejecucin del
proyecto; y (2) a los usuarios de la aplicacin SIE, una vez que esta haya sido puesta en
operacin.
Descripcin de procesos y actividades de gestin
Tabla 7.1. Estructura jerrquica de los procesos de soporte y sus productos
Procesos Subprocesos Productos
Gestin de la
Configuracin del
Software (SCM)
Planificacin de la SCM
Identificacin de la configuracin
Control de la configuracin
Contabilidad del asestado de la configuracin
Auditora de la configuracin
Gestin de versiones y entrega
Plan de Gestin de
la Configuracin
del Software (Plan
SCM)
Aseguramiento de la
Calidad del Software
(SQA)
Planificacin de la SQA
Evaluacin objetiva de productos
Evaluacin objetiva de procesos
Comunicacin de los aspectos de calidad
Resolucin de aspectos no-cumplidos
Plan de
Aseguramiento de
la Calidad del
Software (Plan
SQA)
Gestin de Riesgos
(GR)
Planificacin de la gestin de riesgos
Identificacin de riesgos
Anlisis de riesgos
Planificacin de respuestas
Monitoreo y control de riesgos
Plan de Gestin de
Riesgos
Verificacin y
Validacin (V&V)
Planificacin de la V&V
Revisin del proyecto
Revisin tcnica de productos
Gestin de pruebas
Plan V&V
Plan de Pruebas
Capacitacin (CAP)
Planificacin de la Capacitacin
Contratacin de servicios de capacitacin
Capacitacin del equipo de desarrollo
Capacitacin de usuarios
Evaluacin de la capacitacin
Plan de
Capacitacin

Gestin de la Configuracin del Software (SCM)
Todos los productos del desarrollo de una aplicacin (programas, documentos y datos) se
denominan colectivamente configuracin del software. En la medida que el proyecto de
desarrollo de una aplicacin avanza, esta configuracin crece rpidamente. De igual manera,
en la medida que se avanza en el proyecto, surgen tambin cambios de diferente tipo, que
obviamente afectan a los productos ya elaborados. Si no se manejan eficazmente estos
cambios, se corre el riesgo de perder el control de la configuracin de la aplicacin; lo cual
originara un conjunto de productos desactualizados, desorganizados e inmanejables. Para
resolver estos problemas que ocasionan los cambios, se hace necesario gestionar
eficazmente la configuracin del software.
La Gestin de la Configuracin del Software (SCM Software Configuration Management) es
un proceso de Ingeniera de Software que consiste en identificar la configuracin de una
aplicacin, con el propsito de: (1) controlar sistemticamente los cambios que puedan
producirse en esa configuracin; (2) mantener la integridad de la configuracin de la
aplicacin; y (3) mantener la trazabilidad (traceability) de la configuracin a lo largo de todo el
desarrollo de la aplicacin.
La Gestin de la Configuracin del Software se lleva a cabo mediante la ejecucin el conjunto
de subprocesos indicados en la figura 7.2

Figura 7.2 Subprocesos de SCM
Planificacin de la SCM
La gestin de la configuracin es un proceso que debe ser planificado para garantizar la
eficacia y la eficiencia de su ejecucin. El resultado del proceso de Planificacin de la SCM es
un documento denominado Plan de Gestin de la Configuracin (Plan SCM), el cual fue
descrito en la Seccin Productos de los procesos de soporte. Esta actividad es ejecutada
entre el Lder del Desarrollo de la aplicacin y el Especialista en Configuracin.
Identificacin de la Configuracin
Consiste en establecer la configuracin de la aplicacin e identificar los tems (productos o
componentes de productos) que sern controlados. Algunos de los tems que requieren
controlarse son los siguientes: planes, modelos de datos, diagramas de especificacin de
requisitos, diagramas de diseo, cdigo fuente y ejecutable, diseos de pruebas, documentos,
etc.
Para definir la configuracin de la aplicacin se debe utilizar el Modelo de Productos descrito
en el Captulo 3. Es importante observar que, cada producto es un objeto compuesto. Por
ejemplo, el documento de diseo est compuesto de un conjunto de modelos y diagramas
que describen la arquitectura y componentes del sistema. De este documento, se deben
seleccionar aquellos tems que deben ser sometidos a control. Las relaciones entre los tems
seleccionados deben, tambin, ser establecidas a fin de determinar el impacto que un cambio
en un tem ocasiona en el restos de los tems de configuracin.
Los tems de la configuracin se colocan bajo control en distintos momentos del desarrollo de
la aplicacin. Estos tems tienen asociado una lnea-base. Una lnea de base es una versin
particular inicial del tem (producto) que es usada como punto de partida para el control de
los cambios que puedan ocurrir en ese tem. Una vez que hay un acuerdo entre el equipo de
desarrollo sobre la lnea-base de un tem, los cambios a ese tem slo pueden llevarse a cabo,
siguiendo los procedimientos de control de cambios establecidos por el grupo SCM. Cada
cambio en el tem origina una nueva versin del tem.
58
Control de la Configuracin
Este proceso se encarga de manejar los cambios que ocurren a lo largo del proceso de
desarrollo de cada aplicacin SIE. Para ello se deben establecer los procedimientos y
mecanismos para reportar, evaluar y aprobar (o rechazar) los cambios.
Los cambios que surjan, en uno ms tems de la configuracin, se documentan en formatos
(planillas) diseadas para tal efecto por el Especialista en Configuracin. El Lder de
Desarrollo y el Especialista en Configuracin evalan el cambio propuesto y deciden si el
cambio puede realizarse no.
Los cambios aprobados son realizados por el equipo de desarrollo usando los procedimientos
definidos por el Especialista en Configuracin, quien una vez efectuado el cambio se
encargar de administrar la nueva versin del tem.
Contabilidad del Estado de la Configuracin
Consiste en registrar y reportar la informacin necesaria para gestionar efectivamente la
configuracin de la aplicacin. El Lder de Desarrollo se encarga de informar a otros actores
sobre el estado de la configuracin, las estadsticas de cambios y cualquier otro aspecto de la
gestin de la configuracin.
Auditoria de la Configuracin
Este proceso consiste en evaluar el cumplimiento de los productos y procesos con respecto a
los estndares, prcticas, planes, procedimientos y mtodos establecidos en la empresa para
el desarrollo de aplicaciones. El seguimiento del proceso definido a partir del Mtodo WATCH
es una de los aspectos crticos que deben auditarse peridicamente.
El propsito de las auditorias es: (1) asegurar que los productos sean consistentes con las
especificaciones elaboradas y que los cambios realizados en ellos no alteren esta
consistencia; y (2) asegurar que el proceso de desarrollo se lleva a cabo de acuerdo al Mtodo
WATCH y cumpla con los estndares, prcticas, planes, etc. que se han establecido en la
empresa.
Gestin de versiones y entrega
Los cambios en los tems controlados se manejan usando versiones. Cada vez que un tem
es modificado se crea una nueva versin del tem. El manejo de las diferentes versiones de
los tems es una actividad que debe llevar a cabo el Especialista en Configuracin, para
garantizar que la aplicacin evolucione consistentemente durante su desarrollo y que al
momento de la entrega de la aplicacin no surjan problemas con respecto a las versiones de
sus tems. La gestin de la entrega se encarga de identificar, empacar y entregar los tems y
componentes que forman la versin final de la aplicacin.
Aseguramiento de la Calidad del Software (SQA)
La calidad de una aplicacin SIE se define como la totalidad de caractersticas de la aplicacin
que tienen que ver con su habilidad para satisfacer las necesidades y requisitos establecidos
por sus usuarios. Estas caractersticas se establecen durante el proceso de Ingeniera de
Requisitos.
La calidad de la aplicacin depende, en muy buena medida, del proceso empleado para
desarrollarla. Si este proceso est bien definido y fundamentado, es de esperar que los
productos que se elaboren siguiendo dicho proceso sean de alta calidad.
El Aseguramiento de la Calidad del Software (SQA - Software Quality Assurance) es un
proceso de soporte que tiene por finalidad garantizar que los productos de software y los
procesos de desarrollo cumplan con estndares y atributos de calidad previamente
establecidos.
Es un proceso sistemtico y debidamente planificado para evaluar y garantizar: (1) la calidad
de los productos de software y (2) la adhesin de estos productos a estndares y
procedimientos establecidos
El proceso SQA est relacionado con dos elementos del desarrollo de una aplicacin. En
primer, est relacionado con el proceso utilizado para desarrollar la aplicacin (Cmo se
desarrolla?). El grupo SQA debe asegurar que este proceso est definido y se siga
correctamente. En segundo lugar, est relacionado con los productos de software (Qu se
desarrolla?). Es responsabilidad del grupo SQA garantizar que los productos producidos por
los equipos de desarrollo cumplen con los estndares y atributos de calidad que se han
establecido para esa aplicacin.
El proceso SQA se divide en los subprocesos indicados en la figura 7.3. Estos procesos son
responsabilidad del grupo SQA, el cual est integrado por el Lder de Desarrollo de
Aplicaciones y los Especialista en Calidad del Proyecto SIE.

Figura 7.3. Subprocesos de SQA
Planificacin de la SQA
El primer subproceso SQA consiste en elaborar el Plan SQA, descrito anteriormente en la
Seccin Productos de los procesos de soporte. Este plan define las actividades,
procedimientos y recursos necesarios para asegurar que: (1) el proceso de desarrollo de la
aplicacin se siga; y (2) la aplicacin satisfaga los atributos de calidad establecidos para ella.
Esta planificacin se realiza al inicio del proyecto, durante la ejecucin del proceso de gestin
denominado Planificacin del Proyecto.
Evaluacin Objetiva de Productos
Los diferentes productos intermedios y finales que se producen a lo largo del desarrollo de una
aplicacin SIE deben ser evaluados, a fin de determinar si ellos cumplen no con los
requisitos de calidad establecidos para la aplicacin. As, por ejemplo, el diseo arquitectnico
de la aplicacin es evaluado comparndolo con la especificacin de requisitos, para establecer
si ese diseo es consistente con los requisitos arquitectnicos establecidos.
Evaluacin Objetiva del Proceso
Es importante recordar que el proceso de desarrollo de cada aplicacin SIE es elaborado al
inicio del proyecto, a partir de la instanciacin del Mtodo WATCH.
La Evaluacin Objetiva del Proceso consiste en monitorear peridicamente el proceso de
desarrollo de cada aplicacin SIE, a fin de determinar si el equipo de desarrollo sigue dicho
60
proceso apropiadamente. De igual manera, se determina s otros estndares, prcticas y
mtodos, establecidos en el marco del Proyecto SIE a nivel organizacional, son seguidos
no.
Comunicacin de los Aspectos de Calidad
El incumplimiento de los atributos de calidad en los productos y de los elementos
metodolgicos en el proceso seguido deben ser debidamente identificados, documentados y
reportados al Lder del Proyecto SIE, a fin de tomar los correctivos necesarios.
Resolucin de Aspectos No-Cumplidos
Cada uno de los aspectos no-cumplidos del proceso y de los productos, que hayan sido
identificados durante la evaluacin, deben ser analizados por el grupo SQA y el Lder del
Proyecto SIE a fin de establecer las medidas correctivas necesarias.
Gestin de Riesgos
Los riesgos son eventos, factores o condiciones indeseadas cuya ocurrencia puede afectar
negativamente al proyecto. Los riesgos pueden afectar el proceso de desarrollo de una
aplicacin o a los productos de dicho desarrollo. Pueden incidir negativamente en los costos,
tiempos y recursos del proyecto. Un riesgo tiene una o ms causas asociadas que ocasionan
su ocurrencia y tiene una o ms consecuencias que se derivan de su ocurrencia.
La Gestin de Riesgos es un proceso de soporte de carcter gerencial empleado por el Lder
de Desarrollo para asegurar que la ocurrencia de eventos indeseados no afecten
negativamente el proyecto. Es un proceso sistemtico que consiste en identificar, analizar y
responder a los riesgos del proyecto (PMBOK, 2000). Consta del conjunto de subprocesos
indicados en la figura 7.4.

Figura 7.4. Subprocesos de Gestin de Riesgos
Planificacin de la Gestin de Riesgos
Este subproceso consiste en elaborar el Plan de Gestin de Riesgos descrito anteriormente
en la Seccin Productos de los procesos de soporte. Los detalles de la elaboracin de este
plan se describen en la Gua de Gestin de Proyecto PMIBOK (PMI, 2000).
Identificacin de Riesgos
Consiste en identificar todos aquellos riesgos que puedan afectar negativamente el proyecto.
Su producto es una Lista de Riesgos en la que cada riesgo posible es debidamente
identificado y descrito. El artculo de Wallace y Keil (2004) propone una lista completa de todos
los riesgos que normalmente estan presentes en el desarrollo de software.
Anlisis de Riesgos
Cada uno de los riesgos identificados y documentados en la Lista de Riesgos es debidamente
analizado en trminos de su impacto, su probabilidad de ocurrencia y su criticidad. Se
determinan los efectos o consecuencias que la ocurrencia de cada riesgo pueda tener sobre el
proyecto y, posteriormente, se establecen la prioridad del riesgo y su grado de criticidad con
respecto a los otros.
Planificacin de Respuestas
Para cada riesgo identificado se determinan las acciones necesarias para manejarlo. El Lder
de Desarrollo puede aplicar tres estrategias diferentes para manejar cada uno de los riesgos
identificados en el proyecto. Estas estrategias son las siguientes:
Anulacin del Riesgo.- Consiste en evitar la ocurrencia del riesgo. El proyecto es
reorganizado de tal manera que el riesgo no tenga posibilidad de ocurrir.
Transferencia del Riesgo.- El riesgo y sus consecuencias son transferidas a un actor
o agente externo al proyecto encargado de gestionarlo.
Asuncin del Riego.- El riesgo es aceptado por el proyecto y se establecen los
mecanismos necesarios para controlarlo o mitigarlo.
La atencin de los riesgos que son asumidos implica establecer las medidas de mitigacin del
riesgo o un plan de contingencia (plan B). La mitigacin del riesgo es el conjunto de acciones
que se toman para reducir a un mnimo el impacto del riesgo.
El Plan de Respuestas, contenido en el Plan de Gestin de Riesgos, debe establecer
claramente que hacer antes, durante y despus que el riesgo ha acontecido, as como los
responsables de la ejecucin de las acciones de respuesta al riesgo.
Monitoreo y Control de Riesgos
Cada vez que ocurra un riesgo, se emplea el Plan de Respuestas para tomar las acciones de
mitigacin all indicadas. Se hace, peridicamente, un seguimiento a la ejecucin de este plan.
El plan es actualizado frecuentemente para incorporar nuevos riesgos que puedan surgir a lo
largo del desarrollo del proyecto.

Verificacin y Validacin (V&V)
La Verificacin y Validacin (V&V) es un proceso de soporte estrechamente vinculado al
proceso SQA, de una manera tal que ambos se consideran complementarios. El proceso
V&V consiste en determinar si un producto intermedio o final, elaborado durante el desarrollo
de una aplicacin SIE, satisface: (1) el conjunto de requisitos establecidos en el Documento de
Requisitos de la aplicacin; y (2) las necesidades reales del cliente y/o sus usuarios.
La Verificacin asegura que el producto se construya correctamente. Es decir, que cumpla con
lo especificado. La verificacin est asociada al comportamiento y rendimiento del producto.
Mientras que, la Validacin asegura que el producto desarrollado sea el correcto. Es decir,
satisfaga las necesidades reales del cliente. La validacin est asociada al uso del producto y
al grado de satisfaccin del usuario con el producto.
La V&V es un proceso que se ejecuta a lo largo del desarrollo de la aplicacin. La figura 7.5
identifica los principales subprocesos de la V&V.

62

Figura 7.5. Subprocesos de la V&V
La descripcin de estos subprocesos y sus actividades se presentan en la Tabla 7.2. Esta
descomposicin jerrquica del proceso V&V est basada en el estndar IEEE-1012-1998 (ref).
Tabla 7.2. Actividades de los subprocesos V&V
Subprocesos Actividades Productos
Elaboracin del Plan V&V
V&V del Concepto de
operacin
Revisin tcnica del Caso de Negocios
V&V de Requisitos
Anlisis de la Trazabilidad
Revisin tcnica de los Requisitos
Elaboracin y Verificacin del Plan de Pruebas del
Sistema
Elaboracin y Verificacin del Plan de Pruebas de
Aceptacin
V&V del Diseo de la
Aplicacin
Revisin tcnica del Diseo
Componentes (unidades)
Integracin
V&V de la
Implementacin
Revisin tcnica del Cdigo Fuente
Verificacin de los Casos de Pruebas de
Componentes e Integracin
Verificacin de los Procedimientos de Pruebas de
Componentes e Integracin
Supervisin de las Pruebas de Componentes e
Integracin
V&V de las Pruebas
Verificacin de los Casos de Pruebas del Sistema
y de Aceptacin
Verificacin de los Procedimientos de Pruebas del
Sistema y de Aceptacin
Supervisin de las Pruebas del Sistema y de
Aceptacin
V&V de la Instalacin
de la Aplicacin
Auditoria de la instalacin y configuracin de la
aplicacin
Generacin del informe final de V&V
Plan V&V
Plan de Pruebas
Informes de
gestin sobre
V&V

Consiste en determinar las actividades, recursos, tiempos, estrategias, prcticas, tcnicas y
herramientas que se emplearn, a lo largo del proyecto, para verificar el cumplimiento de los
requisitos establecidos para la aplicacin y validar los productos finales producidos. Los
resultados de este subproceso son el Plan de Verificacin y Validacin (Plan V&V) y el Plan de
Pruebas, ambos descritos anteriormente en la Seccin Productos de los procesos de
soporte.
El anlisis de la trazabilidad es una de las actividades ms importante de verificacin. Consiste
en hacerle seguimiento a cada uno de los requisitos de la aplicacin para asegurar que el
requisito ha sido tomado en consideracin en los productos intermedios y finales. Para realizar
esta actividad, el Lder de Aplicacin emplea herramientas, tales como la Matriz de
Trazabilidad o Seguimiento de Requisitos (ver Captulo 8).
Revisin Tcnica de Productos
La Revisin Tcnica de Productos Revisin por Pares, como tambin se le denomina, es
una actividad grupal ampliamente utilizada para verificar y validar los productos del desarrollo
de software. Esta actividad es realizada por un grupo de 2-4 personas y consiste en someter
el producto a una revisin manual exhaustiva de su contenido, estructura y componentes. La
figura 7.5 muestra el flujo de trabajo requerido para aplicar esta tcnica. La revisin del
producto en grupo se realiza usando una de las dos estrategias siguientes: Inspeccin y
Recorrido Estructurado. La Inspeccin emplea una lista de chequeo que es preparada antes
de iniciar la revisin en grupo por el Lder de Desarrollo , en su ausencia, el Coordinador de
Revisin. A diferencia de la Inspeccin, el Recorrido Estructurado realiza un seguimiento
exhaustivo del producto, a travs de la lectura o recorrido de su documentacin.

Figura 7.5 Flujo de trabajo del subproceso de Revisin Tcnica de Productos
Pruebas de Software
Las pruebas de software constituyen un tipo de verificacin que se aplica slo a los programas
que integran cada aplicacin. Consisten en correr los programas de una aplicacin SIE, en la
plataforma H/S de desarrollo, con la finalidad de encontrar errores (faltas o fallas). El objetivo
de las pruebas es encontrar la mayor cantidad de errores antes de que la aplicacin sea
entregada a sus usuarios.
64
Los procesos de pruebas se ejecutan a lo largo del desarrollo de la aplicacin y dividen en dos
grupos de subprocesos complementarios: uno tcnico y el otro de gestin. El diseo y
ejecucin de las pruebas son procesos tcnicos que se ejecutan en los procesos de
Construccin & Integracin y Pruebas de la Aplicacin (ver Captulo 10). Mientras que la
gestin de pruebas es un subproceso de la V&V que involucra la realizacin de las siguientes
actividades gerenciales:
Planificacin de las Pruebas.- Consiste en determinar las actividades, recursos,
tiempos, estrategias, prcticas, tcnicas y herramientas que se emplearn durante los
procesos de Construccin & Integracin y Pruebas de la Aplicacin (ver Captulo 10)
para probar cada uno de los programas elaborados por el Equipo de Desarrollo. El
resultado de este subproceso es un Plan de Pruebas (ver Seccin Productos de los
procesos de soporte).
Organizacin del Grupo de Pruebas.- Consiste en definir: (1) la estructura del grupo
de pruebas (GP); (2) las funciones que este grupo debe realizar; (3) los roles que
cada miembro del GP debe jugar; (4) las responsabilidades de los miembros del
grupo; y (5) sus relaciones con otros grupos, tales como: Grupo de Anlisis, Grupo de
configuracin (SCM), Grupo de calidad (SQA), etc.
Control de la ejecucin de las pruebas.- Consiste en: (1) asegurar que las pruebas
se ejecuten de acuerdo a lo establecido en el Plan de Pruebas; (2) actualizar este
plan a fin de asegurar que los cambios que surjan en la configuracin del software
sean considerados; pues, cada cambio en el software que sea aprobado por el grupo
SCM impacta el plan de pruebas; (3) asegurar el cumplimiento de los estndares y
procedimientos de calidad establecidos por el grupo SQA; y (4) supervisar el uso
apropiado y la actualizacin de la documentacin de pruebas.
Capacitacin (CAP)
No menos importante es el proceso de Capacitacin de Personal, el cual consiste en capacitar
a dos tipos de actores de las aplicaciones SIE: Personal de los Equipos de Desarrollo y
Usuarios de cada aplicacin. Los subprocesos que integran el proceso de Capacitacin se
muestran en la figura 7.6.

Figura 7.6. Subprocesos de Capacitacin
La capacitacin del personal de desarrollo est orientada a formar y/o actualizar a los
miembros de los Equipos de Desarrollo en el uso de los principios, modelos, prcticas,
procesos, tcnicas y herramientas de aquellas disciplinas involucradas en el desarrollo de las
aplicaciones SIE, tales como: Ingeniera de Software, Gestin de Proyectos, Sistemas de
Informacin Geogrfica, Bases de Datos, Aplicaciones Web y Sistemas Distribuidos. La
capacitacin de todo el Equipo de Desarrollo en el uso del Mtodo WATCH es fundamental
para lograr que este mtodo produzca los resultados esperados.
La capacitacin de los usuarios est dirigida a preparar a los usuarios de cada aplicacin SIE
en uso correcto de la aplicacin. Es una actividad continua que se inicia en los procesos
finales de la ejecucin del proyecto; pero que contina durante la operacin del sistema, como
una actividad de soporte tcnico a los usuarios.
En la Tabla 7.2 se indican aquellas tcnicas, estndares, prcticas y herramientas
automatizadas ms relevantes y efectivas que pueden ser aplicadas en cada uno de los
procesos de soporte.
Tabla 7.2 Tcnicas y herramientas que pueden emplearse en los procesos de soporte
Proceso
Tcnicas, estndares y
mejores prcticas

Herramientas
Gestin de la
Configuracin del
Software
IEEE Std. 828-1998
Existe una amplia variedad de herramientas
SCM, incluyendo Rational Clear Case y CVS
(ver:
http://www.laatuk.com/tools/SCM_tools.html)
Aseguramiento de
la Calidad del
Software
PMIBOK (PMI, 2000)
IEEE Std. 730-2001
Modelos de Calidad: FURPS,
McCall

Gestin de Riesgos
PMIBOK (PMI, 2000)

Matriz de Riesgos

Verificacin y
validacin
Revisin tcnica
Estrategias de pruebas: Caja
Negra y Caja Blanca
IEEE Std. 1012-1998
IEEE Std. 1028-1997
Ver lista de herramientas de V&V en:
http://vva.dmso.mil/Ref_Docs/VVTools/vvtools
-pr.PDF

66

Captulo
Procesos de Anlisis
8

Los procesos tcnicos del mtodo WATCH se dividen en tres grupos: Procesos de Anlisis,
Procesos de Diseo y Procesos de Implementacin. Los procesos de anlisis cubren los
procesos de Modelado del Dominio de la Aplicacin e Ingeniera de Requisitos; los procesos
de diseo cubren los procesos de Diseo Arquitectnico y Diseo Detallado; mientras que, los
procesos de implementacin agrupan los procesos de Construccin & Integracin, Pruebas de
la Aplicacin y Entrega de la Aplicacin.
Este captulo describe, de manera detallada, los procesos tcnicos de anlisis. Estos procesos
son necesarios para: (1) establecer el dominio (ambiente organizacional) donde la aplicacin
SIE operar; y (2) especificar los requisitos que debe satisfacer dicha aplicacin. El anlisis de
la aplicacin consta, por lo tanto, de dos procesos tcnicos:
1. El Modelado del Dominio de la Aplicacin (MDA)
2. La Ingeniera de Requisitos (IR).
Este captulo est organizado de la siguiente manera: Primero, se presenta de manera
general, el grupo de procesos de anlisis. Luego se describe cada uno de los dos procesos
que lo componen. Cada uno de ellos est documentado en trminos de sus interrelaciones,
entradas y salidas y los productos parciales que se van produciendo durante su ejecucin.
A diferencia de los captulos anteriores, en este captulo y los siguientes, emplearemos la
tcnica UML Business (Ericksson and Penker, 2000) para describir los procesos. Esta tcnica
es adecuada para modelar procesos; por cuanto, facilita la descomposicin funcional de los
mismos y proporciona una mejor descripcin de sus entradas y salidas. El Anexo 1 resume las
notaciones de modelado usadas, en este documento, para explicar grficamente el Mtodo
WATCH.
Grupo de procesos de anlisis
Este grupo tiene como objetivos principales los siguientes: (1) entender y modelar el dominio
de la aplicacin SIE; esto es, el sistema de negocios de CVG-LA EMPRESA que la aplicacin
SIE apoyar; y (2) definir y especificar el conjunto de requisitos funcionales y no-funcionales
que la aplicacin SIE debe satisfacer. Para ello, se emplean tcnicas, mtodos y herramientas
apropiadas para el Modelado de Negocios y la Ingeniera de Requisitos. La figura 8.1a
describe, de manera muy general, el grupo de procesos de anlisis, visto como un todo; el
conjunto de procesos que conforman el grupo se muestra en la figura 8.1b.
<<documento>>
Informacin de Dominio
Necesidades de los
interesados
Caso de Negocios
<<documento>>
Modelo del Dominio
de la Aplicacin
<<actor>>
Grupo Anlisis
Usuarios
<<herramientas>>
Tcnicas y estndares de especificacin y validacin de
productos de SW
Formularios y planillas
Herramientas de graficacin y de apoyo al desarrollo
ArcGIS / ArcIMS
<<apoya>>
<<participa>>
<<controla>>
<<persigue>>
<<regula>>
<<objetivo>>
Establecer formalmente
el conjunto de requisitos
que la aplicacin SIA
debe satisfacer.
<<actor>>
Lder del Proyecto
<<reglas>>
Mtodo MD-SIA
Proceso de Desarrollo de la aplicacin
Normas y Estndares de la organizacin (incluye
mtodos, tcnicas, formularios)
Plan de Proyecto
Directivas para definicin y especificacin de
requisitos
<<apoya>>
<<actor>>
Ambiente ArcGIS/ ArcIMS
Otras aplicaciones SIA
Anlisis de la
Aplicacin

Figura 8.1a. Diagrama general del proceso Anlisis de la Aplicacin
Anlisis de la
aplicacin
Modelado
de Dominio
Ingeniera de
Requisitos
Anlisis de la
aplicacin
Modelado
de Dominio
Ingeniera de
Requisitos

Figura 8.1b. Diagrama general del proceso Anlisis de la Aplicacin
El proceso de Modelado del Dominio de la Aplicacin permite modelar el ambiente o
contexto organizacional (el sistema de negocios) para el cual se desarrollar la aplicacin, de
manera que se puedan definir sus elementos claves, sus interrelaciones y el grado de
influencia que stos pudieran tener sobre los requisitos tcnicos que la aplicacin SIE debe
satisfacer.
El proceso de Ingeniera de Requisitos permite descubrir, analizar, especificar y validar el
conjunto de requisitos funcionales y no-funcionales que la aplicacin SIE debe satisfacer. Este
proceso utiliza tcnicas, notaciones y herramientas orientadas por objetos para producir una
documentacin completa y precisa de los requisitos que se le impondrn a la aplicacin SIE.
El Proceso de Modelado del Dominio de la Aplicacin (MDA)
El dominio de una aplicacin SIE se define como el sistema de negocios para el cual se
desarrolla la aplicacin. Un sistema de negocios comprende un conjunto integrado de
procesos que son ejecutados por una o ms unidades organizacionales de LA EMPRESA.
Por ejemplo, los procesos de medicin de variables hidroclimatolgicas, que se ejecutan en el
Departamento de Manejo Ambiental, constituyen un sistema de negocios denominado El
68
Sistema de Medicin de Variables Hidroclimatolgicas. Este sistema tiene, actualmente, una
aplicacin SIE que lo soporta identificada como el Sistema de Informacin SHIDROCLIM.
El Modelado del Dominio de la Aplicacin (MDA) es el primer proceso tcnico del mtodo
MDA-SIE y se ejecuta inmediatamente despus que el Plan del Proyecto de desarrollo de una
nueva aplicacin SIE ha sido elaborado y aprobado por el Comit Directivo. Este proceso
tiene como objetivos fundamentales los siguientes:
Entender el dominio de la aplicacin SIE que se va a desarrollar.
Comprender los problemas que motivan el desarrollo de la aplicacin SIE.
Facilitar la identificacin de las necesidades de informacin que tienen los
usuarios futuros de esta aplicacin.
Para alcanzar estos objetivos se hace necesario modelar el dominio de la aplicacin SIE como
un sistema de negocios. Es importante destacar que, una aplicacin SIE es un sistema de
apoyo a otro mayor que lo contiene y al cual prestar sus servicios. Este sistema mayor lo
denominamos sistema de negocios. Un sistema de negocios est integrado por los
siguientes elementos organizacionales:
1. Objetivos.- Son aquellas finalidades que el sistema de negocios debe alcanzar y
que determinan su razn de ser. Entre estas finalidades est la misin del
sistema, sus objetivos estratgicos y sus metas.
2. Procesos de negocio.- Los procesos constan de actividades y tareas que en su
conjunto permiten alcanzar los objetivos pre-establecidos.
3. Objetos de negocio.- La ejecucin de los procesos involucra un conjunto de de
elementos denominados objetos del negocio; por ejemplo, materia prima,
productos, recursos humanos, clientes, etc.
4. Actores/Roles.- Los procesos son ejecutados por un grupo de actores de LA
EMPRESA que tienen la responsabilidad de ejecutar las actividades y tareas que
integran cada proceso. Cada actor ejecuta uno o ms roles. Un rol tiene asociado
un conjunto de responsabilidades. Por ejemplo, el actor Lder del Proyecto SIE
es un rol que ejecuta una persona determinada, quien es responsable de un
conjunto de actividades y tareas. Los usuarios son un tipo particular de actor que
interactuarn con la aplicacin directa o indirectamente.
5. Unidades organizativas.- Son las unidades de la empresa (Divisin, Gerencia,
Departamento Seccin) que participan en la ejecucin de los procesos de
negocios.
6. Reglas de negocio.- Los procesos de negocio deben cumplir con un conjunto de
regulaciones, normas, procedimientos y estndares denominados, en su
conjunto, como reglas de negocio.
7. Tecnologas.- Para ejecutar los procesos del sistema de negocio se requiere el
empleo de un conjunto de tecnologas. Por ejemplo, el sistema de Medicin de
Variables Hidroclimatolgicas emplea diferentes tecnologas de medicin que van
desde los dispositivos usados durante los aforos hasta los dispositivos que
transmiten las medidas al centro de datos.

8. Eventos.- Cada proceso del sistema de negocio tiene un punto de inicio y un
punto de finalizacin que indican cuando el proceso se activa y cuando debe
finalizar. A estos puntos los denominamos eventos.
La figura 8.2 muestra el diagrama del proceso MDA que describe los elementos que
intervienen en el modelado del dominio de una aplicacin SIE.
<<documento>>
Modelo
de Dominio
<<actor>>
Grupo de anlisis
Miembros de organizacin
<<herramientas>>
Herramientas de graficacin/
documentos/
<<reglas>>
mtodos, tcnicas, formularios)
Criterios de especificacin de objetivos Plan de
proyecto
Mtodo MD-SIA
Proceso de Desarrollo de la aplicacin
<<actor>>
Lder del
proyecto
Modelado de
Dominio
<<objetivo>>
Representar el contexto organizacional
en el cual se operar la aplicacin, de
manera que se puedan definir sus
elementos, sus interrelaciones y el grado
de influencia que pudiera tener sobre los
requisitos de la aplicacin SIA
<<apoya>>
<<participa>>
<<persigue>> <<regula>>
<<controla>>
<<documento>>
Necesidades de los
interesados
Caso de Negocios

Figura 8.2. Diagrama general del proceso Modelado de Dominio de la Aplicacin

El Modelo de Productos del Proceso MDA
El proceso MDA genera un producto final, denominado Modelo de Dominio de la Aplicacin o
Modelo Empresarial. Este modelo representa al sistema de negocios para el cual se
desarrollar la aplicacin SIE. Es un modelo compuesto por un conjunto de sub-modelos,
cada uno de los cuales representa un elemento organizacional del sistema de negocios. La
figura 8.3 captura la estructura del Modelo de Dominio de la Aplicacin mostrando los
componentes que se elaboran durante la ejecucin del proceso MDA.
Estos modelos son elaborados usando la notacin UML Business de Ericsson y Penker
(2000). El proceso de elaboracin de cada uno de ellos est fundamentado en el mtodo de
modelado de negocios BMM descrito por Montilva y Barrios (2004a).
70
Modelo de Dominio de la
Aplicacin
Modelo de
Objetivos
Modelo de Procesos del
Negocio
Modelo de Reglas del
Negocio
Modelo de Objetos del
Negocio
Modelo Actor/Rol
+ Estructura organizacional
Modelo de Tecnologas
Modelo de Eventos
Modelo de Procesos
de Apoyo
Modelo de Procesos
Primarios
1
1
1
1
1
1
1
1 1
Modelo de Dominio de la
Aplicacin
Modelo de
Objetivos
Modelo de Procesos del
Negocio
Modelo de Reglas del
Negocio
Modelo de Objetos del
Negocio
Modelo Actor/Rol
+ Estructura organizacional
Modelo de Eventos
Modelo de Procesos
de Apoyo
Modelo de Procesos
Primarios
1
1
1
1
1
1
1
1 1

Figura 8.3. Modelo de productos asociados al proceso Modelado de Dominio de la Aplicacin

Descripcin de los componentes del Modelo del Dominio de la Aplicacin
Cada uno de los elementos organizacionales del sistema de negocios es representado
mediante un sub-modelo que ser brevemente descrito en los prrafos siguientes. Cada uno
de ellos es un producto intermedio que es ensamblado al final del proceso de modelado del
dominio de la aplicacin para integrar y elaborar el documento que describe el Modelo de
Dominio de la Aplicacin.
Modelo de Objetivos
Este modelo contiene el conjunto de objetivos de la organizacin representados como una
jerarqua de objetivos. La raz de esta jerarqua representa la visin y la misin de la
organizacin, pasando luego a definir el objetivo general que se descompone en un conjunto
de sub-objetivos ms precisos; a su vez, stos se van descomponiendo hasta lograr definir los
objetivos de ms bajo nivel dentro de la organizacin, los cuales son asignados directamente
a los procesos del negocio.
Modelo de Procesos del Negocio
Este modelo representa el conjunto de procesos que se realizan en la organizacin y que
conllevan a la consecucin de los objetivos de alto nivel de la misma. Como punto de partida
se define la cadena de valor de la organizacin, la cual agrupa los procesos del negocio en
dos grandes categoras: los procesos primarios y los procesos de apoyo. Los primeros
representan la razn de ser de la organizacin, los segundos prestan el apoyo tcnico y
administrativo necesario para que los primeros se lleven a cabo.
Debido a la complejidad de una organizacin, cada proceso primario y de apoyo de la cadena
de valor, se va descomponiendo en un conjunto de subprocesos hasta alcanzar el nivel de las
actividades que son realizadas directamente por los actores de la organizacin.

Modelo de Reglas del Negocio
Este modelo representa el conjunto de reglas y normas de la organizacin que rigen y regulan
la ejecucin de actividades y procesos por parte de los actores.
Modelo de Eventos
Este modelo captura el conjunto de eventos tanto internos como externos a la organizacin
que causan, disparan y condicionan la ejecucin de las diferentes actividades y procesos.
Modelo de Actores y Roles
Este modelo representa el conjunto de actores de la organizacin que participan en la
ejecucin de las actividades y procesos organizacionales. Los actores pueden ser miembros o
no de la organizacin, mquinas, equipos o sistemas automatizados. Los actores son
responsables, bajo la definicin de un rol, de la consecucin de un objetivo operacional
especfico. Un actor mediante la ejecucin, coordinacin y/o supervisin de un conjunto de
acciones o actividades participa activamente en los procesos de negocios.
Los actores, miembros de la organizacin, forman parte de una unidad o dependencia, por lo
que se requiere modelar tambin la estructura organizativa de manera que se pueda definir
las relaciones de dependencia y autoridad entre los diferentes actores y los roles que ejecutan
en cada uno de los procesos organizacionales.
Modelo de Objetos del Negocio
Es una representacin, del conjunto de objetos de negocios, que se crean, modifican,
participan y/o fungen como recursos fundamentales en la ejecucin de las actividades
asociadas a cada proceso del negocio. Estos recursos son utilizados tanto a nivel de
operaciones bsicas como a nivel de los procesos de toma de decisiones en los diferentes
niveles gerenciales de la organizacin.
Permite establecer el conjunto de tecnologas que se emplean en los procesos de negocios
para ejecutar las actividades. Estas tecnologas son la base fundamental para la validacin de
algunos procesos del negocio, la definicin de los objetos o recursos del negocio que se
requieren capturar, su formato y uso, as como el conjunto de responsabilidades asignadas a
un grupo de actores de la organizacin o externos a ella.
Subprocesos del proceso MDA
EL proceso MDA se descompone en tres subprocesos complementarios: modelado de
elementos organizacionales, validacin y documentacin del modelo de dominio (ver figura
8.4).
La ejecucin del subproceso Modelado de elementos organizacionales define las
actividades que deben realizarse con el objetivo de producir los modelos de: objetivos,
procesos del negocio, reglas, eventos, objetos, tecnologa de medicin y muestreo.
Paralelamente, cada uno de estos submodelos es validado por un conjunto selecto de
usuarios o interesados de la aplicacin SIE que tengan un slido conocimiento del sistema de
negocios. Una vez validados todos los submodelos, se procede a elaborar el documento que
ensambla los submodelos, los relaciona y los presenta como un todo que describe el Modelo
del Dominio de la Aplicacin.
72
Validacin del Modelo de Dominio
Documentacin del
Modelado
de Dominio
Modelado de
Elementos
Organizacionales
Modelado de
Dominio
Validacin del Modelo de Dominio
Documentacin del
Modelado
de Dominio
Modelado de
Elementos
Organizacionales
Modelado de
Dominio

Figura 8.4. Subprocesos del proceso MDA
Descripcin de subprocesos
A continuacin, se presenta el flujo de trabajo asociado a cada uno de estos tres subprocesos
y su respectiva descripcin presentada en forma tabular. Cada tabla contiene las tareas que
detallan cada una de las actividades definidas en el flujo de trabajo respectivo.
Subproceso: Modelado de Elementos Organizacionales
Modelado de elementos organizacionales Modelado de elementos organizacionales

Figura 8.6. Flujo de trabajo del subproceso Modelado de Elementos Organizacionales

Tabla 8.1. Descripcin del flujo de trabajo: Modelado de Elementos Organizacionales
Actividad Tareas Productos
Modelado de objetivos Establecer los lmites del sistema de
negocios: dominio o contexto de la
aplicacin SIE
Definir la visin del sistema de negocios
Definir su misin.
Definir sus objetivos de alto nivel.
Descomponer objetivos de alto nivel en
sub-objetivos.
Modelo de Objetivos
(Jerarqua de Objetivos)

Modelado de procesos primarios Identificar los procesos fundamentales.
Definir la cadena de valor.
Descomponer cada proceso en
subprocesos.
Construir los diagramas de procesos para
cada proceso y subproceso.
Definir las actividades asociadas a cada
subproceso de bajo nivel.
Cadena de valor
Modelo de Procesos
primarios (Diagramas de
procesos y subprocesos)
Diagramas de actividad
por subproceso
Modelado de procesos de apoyo Identificar los procesos de apoyo.
Descomponer cada proceso en
subprocesos.
Construir de diagramas de procesos para
cada proceso y subproceso.
Definir las actividades asociadas a cada
subproceso de bajo nivel.
Modelo de Procesos de
apoyo (Diagramas de
procesos y subprocesos)
por subproceso
Modelado de tecnologa de
medicin y muestreo (M&M)
Identificar las tecnologas de medicin y
muestreo.
Analizar las tecnologas.
Caracterizar las tecnologas.
Resumen tcnico de
estaciones de medicin y
muestreo
Modelado de reglas del negocio Identificar las reglas del negocio asociadas
a la aplicacin.
Seleccionar las reglas relevantes para la
aplicacin.
Lista de reglas del
negocio
Modelado de eventos Identificar los eventos asociados a la
aplicacin.
Describir los eventos segn su tipo.
Construir la matriz eventos/procesos.
Lista de eventos
Matriz eventos/procesos
Modelado de objetos Identificar los tipos de objetos del negocio.
Definir las relaciones entre tipos de objetos.
Elaborar el modelo de objetos.
Elaborar la matriz procesos-objetos.
Modelo de objetos del
negocio (Diagrama de
clases de objetos)
Matriz procesos/objetos
Modelado de actores y unidades
organizacionales
Analizar la estructura organizacional.
Identificar los actores.
Definir los roles de actores.
Elaborar la matriz actores-procesos.
Modelo actor/rol
Organigrama
Matriz actores/procesos.

Subproceso: Validacin del Modelo de Dominio
Validacin de modelo de dominio
Figura 8.5. Flujo de trabajo del subproceso Validacin del Modelo de Dominio

Tabla 8.2. Descripcin del flujo de trabajo: Validacin de modelo de dominio
Planificacin de la validacin del
modelo
Elaborar plan de validacin.
Definir las responsabilidades de validacin de
los miembros del equipo de trabajo.
Plan de validacin
Revisin formal del modelo de
dominio
Validar modelo de objetivos
Validar modelo de procesos
Validar modelo de reglas del negocio
Validar el resumen tcnico de las tecnologas de
Modelo de dominio
validado.
74
medicin y muestreo.
Validar modelo de eventos
Validar modelo de objetos
Validar modelo de actores/roles
Validar correspondencia entre modelos
Subproceso: Documentacin del Modelo de Dominio
Documentacin del modelo de dominio
Figura 8.7. Flujo de trabajo Subproceso Documentacin del modelo de dominio
Tabla 8.3. Descripcin del flujo de trabajo Documentacin del modelo de dominio
Planificacin de la
estructura del documento
Definir estructura del documento.
Planificar actividades de redaccin.
Definir pautas, lineamientos y terminologa a
emplear en la redaccin del documento.
Estructura del
documento de
modelado de dominio.

Redaccin del documento Escribir cada seccin el documento atendiendo a
los lineamientos, pautas y terminologa
especificada.
Validar redaccin y estructura del documento.
Documento redactado
y validado.

El Proceso de Ingeniera de Requisitos (IR)
Una vez elaborado el Modelo de Dominio de la Aplicacin, el equipo de desarrollo tiene ya una
comprensin suficiente del problema y del sistema de negocios donde operar la aplicacin.
El proceso siguiente, denominado Ingeniera de Requisitos (IR), consiste en determinar y
documentar los requisitos funcionales y no-funcionales que los actores del sistema de
negocios tienen con respecto a la aplicacin SIE que se desea desarrollar.
Los requisitos expresan lo que la aplicacin SIE debe hacer para satisfacer las necesidades
de sus usuarios. Los requisitos expresan lo qu se supone debe hacer una aplicacin, no
intentan expresar cmo lograr estas funciones (Braude, 2003).
Los requisitos definen:
Lo que la aplicacin debe hacer: Las funciones que debe ejecutar, los datos que
debe capturar y almacenar y la informacin que debe producir.
La interaccin entre los usuarios y la aplicacin: La interfaz grfica usuario-
sistema (GUI).
Las restricciones bajo las cuales la aplicacin debe operar: La plataforma de
operacin de la aplicacin (Hardware/Software), la tecnologa de informacin que
debe usar y las interfaces con otros sistemas o aplicaciones.

Los atributos de calidad que la aplicacin debe satisfacer: seguridad, facilidad de
uso, documentacin, utilidad, etc.
Los requisitos se clasifican en dos tipos: funcionales y no funcionales. Los requisitos
funcionales establecen los servicios que debe proporcionar la aplicacin, determinan la
funcionalidad de la aplicacin. Describen lo que la aplicacin SIE deber hacer, esto es: (1) su
comportamiento; (2) su interaccin con los usuarios y su dominio de aplicacin (sistema de
negocios); y (3) sus respuestas a eventos externos, tales como la invocacin de sus
funciones.
Los requisitos no-funcionales definen las limitaciones que se le impondrn al diseo de la
aplicacin. Describen:
Las restricciones que se le imponen al desarrollo y operacin de la aplicacin,
tales como el ambiente de desarrollo, los recursos disponibles para desarrollo y el
ambiente de operacin de la aplicacin (la plataforma H/S bajo la cual la
aplicacin deber operar).
Las cualidades o atributos que el sistema debe satisfacer, tales como su
confiabilidad, utilidad, documentacin, rendimiento, interfaces con otros sistemas
o aplicaciones.
La Ingeniera de Requisitos es el proceso tcnico, usado por el mtodo MDA-SIE, para
descubrir, analizar, especificar, validar y gestionar los requisitos que las aplicaciones SIE
deben satisfacer. El diagrama de procesos de la Ingeniera de Requisitos se presenta en la
figura 8.8
.
<<actor>>
-Grupo de Anlisis:
especificacin de requisitos
-Usuarios
Tcnicas y estndares de especificacin
y validacin de productos de SW
Formularios
Herramientas de graficacin y de apoyo
al desarrollo ArcGIS / ArcIMS
<<apoya>> <<participa>>
<<controla>>
<<persigue>>
<<regula>>
<<objetivo>>
Descubrir y formalizar el
conjunto de requisitos
tcnicos que la aplicacin
SIA debe satisfacer.
<<actor>>
Lder del proyecto
<<reglas>>
Mtodo MD-SIA
Modelo de proceso de la aplicacin
Normas y Estndares de la organizacin
(incluye mtodos, tcnicas, formularios)
Plan de Proyecto
Directivas para definicin y especificacin de
requisitos
<<actor>>
Ambiente ArcGIS /
ArcIMS
<<apoya>>
Ingeniera
de
Requisitos
<<documento>>
Documento de
requisitos
<<documento>>
Necesidades de los
interesados
Modelo del Dominio

Figura 8.8. Diagrama del proceso Ingeniera de Requisitos
76
Modelo de productos IR
El conjunto de productos que se elaboran durante la ejecucin del proceso IR se presenta en
la figura 8.9. El producto principal del proceso IR es el Documento de Requisitos, el cual
describe cada uno de los requisitos que establecen los usuarios de la aplicacin. Tal como se
ilustra en la figura 8.9, este documento est compuesto de dos partes. La primera de ellas es
la Descripcin de Requisitos, la cual describe los requisitos desde la perspectiva de los
usuarios de la aplicacin SIE. Est dirigida a los usuarios y dems interesados en la
aplicacin. No tiene, por lo tanto, un carcter tcnico. La segunda es denominada
Especificacin de los Requisitos de la Aplicacin y consta de un conjunto de modelos
elaborados usando el lenguaje UML. Est dirigida a los miembros del Equipo de Desarrollo
que participarn en el diseo de la aplicacin. Tiene, por consiguiente, un carcter tcnico.

Figura 8.9. Modelo de producto del proceso Ingeniera de Requisitos
Descripcin de productos del proceso IR
Este proceso genera un conjunto de productos intermedios: modelo de casos de uso y sus
descripciones textuales, prototipo de la aplicacin, modelo preliminar de clases y modelo de la
arquitectura de la aplicacin. El ensamblaje y descripcin de estos modelos conforman el
Documento de Requisitos.
Este documento describe cada uno de los requisitos que se identifican, analizan y especifican
durante las actividades de descubrimiento, anlisis y especificacin de requisitos. Este
documento se estructura en dos partes. La primera parte esta dirigida a los usuarios y consiste
en describir la aplicacin y sus requisitos en la terminologa propia de los usuarios. La
segunda parte esta dirigida al Grupo de Diseo, que se encargar de traducir los modelos de
casos de uso y de clases en modelos de diseo de la aplicacin. El Documento de Requisitos
se puede organizar usando el estndar IEEE 830-1998 la estructura propuesta por Bruegge
y Dutoit (2000).
Modelo de casos de uso
Representa la funcionalidad de la aplicacin desde el punto de vista de sus actores y de sus
interacciones con otras aplicaciones SIE y/o sistemas de software. Es un producto clave para
la definicin y especificacin de requisitos funcionales, de interaccin entre el usuario y la
Documento de
Requisitos de la
Aplicacin
Matriz de
interaccin de
requisitos
Listado de
requisitos de la
aplicacin
Modelo de casos
de uso
Prototipo de
interfaz
Modelo preliminar de la
arquitectura de la
aplicacin
Escenarios
Modelo de clases
Modelo Dinmico Modelo Esttico
Planillas de
recoleccin de
requisitos (Volere)
1
1
1
1
1
*
1
O.. *
O.. 1
1
Especificacin de Requisitos
de la Aplicacin
Descripcin de
requisitos
Documento de
Requisitos de la
Aplicacin
Matriz de
interaccin de
requisitos
Listado de
requisitos de la
aplicacin
Modelo de casos
de uso
Prototipo de
interfaz
Modelo preliminar de la
arquitectura de la
aplicacin
Escenarios
Modelo de clases
Modelo Dinmico Modelo Esttico
Planillas de
recoleccin de
requisitos (Volere)
1
1
1
1
1
*
1
O.. *
O.. 1
1
Especificacin de Requisitos
de la Aplicacin
Descripcin de
requisitos

aplicacin y para definir, de manera preliminar, el conjunto de objetos del negocio que estn
involucrados en la aplicacin. Para elaborar este modelo se usan Diagramas de Casos de Uso
en UML. Adems de los diagramas de casos de uso, este modelo consta de un conjunto de
descripciones textuales de los casos de uso, denominadas escenarios. Un escenario describe
el flujo de eventos que ocurren en un caso de uso; es decir, la interaccin entre los actores y la
aplicacin.
Modelo preliminar de clases
Es una representacin, generalmente esttica, que contiene el conjunto de clases de objetos
de negocios, que participan en los diferentes casos de uso y/o fungen como recursos
fundamentales en la ejecucin de los procesos del negocio asociados all dominio de la
aplicacin SIE (el sistema de negocios). Dependiendo del tipo de aplicacin, se define adems
el modelo dinmico, representado por los estados y las transiciones entre ellos, a los que
estn sujetos los objetos del negocio.
Arquitectura preliminar de la aplicacin
Establece los componentes bsicos de la aplicacin y sus interrelaciones, atendiendo a la
funcionalidad de la aplicacin y a las restricciones y requisitos de hardware y software
definidos por la plataforma tecnolgica con que cuenta la organizacin.
Prototipo de la Aplicacin
Es un modelo de la interfaz usuario/sistema que tendr la aplicacin SIE. Se produce con la
finalidad de descubrir nuevos requisitos, facilitar la validacin de los requisitos funcionales de
la aplicacin e iniciar el diseo de la aplicacin.

Subprocesos del proceso IR

Descubrimiento
de
Requisitos
Anlisis
de
Requisitos
Especificacin
de
Requisitos
Validacin
de
Requisitos
Gestin de Requisitos

Figura 8.10. Subprocesos del proceso Ingeniera de Requisitos
A continuacin se presentan los flujos de trabajo de cada uno de los subprocesos que
componen el proceso Ingeniera de requisitos.

78
Subproceso: Descubrimiento de Requisitos
Descubrimiento de requisitos

Figura 8.11. Flujo de trabajo del subproceso Descubrimiento de Requisitos.
Taba 8.4. Descripcin del flujo de trabajo: Descubrimiento de Requisitos
Descripcin del problema Revisar los objetivos del dominio de
la aplicacin (sistema de negocios)
Determinar los objetivos de la
aplicacin.
Modelo de dominio
actualizado.
Objetivos de la aplicacin
claramente definidos.
Identificacin de actores del
dominio

Identificar los actores del dominio
que usarn la aplicacin.
Clasificar actores segn grado de
participacin en la aplicacin.
Seleccionar grupo de actores o
interesados que participarn en la
definicin de requisitos.
Lista de actores clasificados.
Recoleccin de requisitos de la
aplicacin.
Identificar requisitos funcionales de la
aplicacin.
Identificar requisitos de interfaz
usuario/aplicacin.
Identificar requisitos no funcionales
de la aplicacin.
Planillas (Volere) de
recoleccin de requisitos.
Recoleccin de requisitos de
interaccin con otros sistemas
Identificar requisitos tcnicos.
Identificar requisitos funcionales.
Identificar requisitos no funcionales.
Modelos de casos de uso con
sus respectivos escenarios.
Consolidacin de requisitos Verificar consistencia entre los
requisitos recolectados.
Unificar requisitos recolectados.
Listado de requisitos de la
aplicacin.

Subproceso: Anlisis de Requisitos
Anlisis de requisitos

Figura 8.12. Flujo de trabajo del subproceso Anlisis de Requisitos

Tabla 8.5. Descripcin del flujo de trabajo: Anlisis de Requisitos
Clasificacin de
requisitos
Establecer criterios de clasificacin.
Ubicar los requisitos dentro de la clasificacin.
Requisitos clasificados.

Negociacin de
requisitos

Definir prioridades de los requisitos dentro de su
clasificacin.
Determinar el conjunto de requisitos que la
aplicacin debe satisfacer.
Prioridades de los requisitos.
Listado de requisitos de la
aplicacin.
Refinamiento de
requisitos
Refinar requisitos no funcionales y funcionales
(casos de uso).
Definir una arquitectura inicial de la aplicacin
segn los patrones propuestos en el mtodo
WATCH.
Refinar requisitos de almacenamiento (modelos
de clases de objetos).
Modelos de casos de uso, de
clases y de estados.
Arquitectura inicial: diagramas
de nodos
Validacin Revisar, junto a los interesados, los requisitos
de la aplicacin.
Ajustar los modelos.
Especificacin tcnica de la
aplicacin.
Listado validado de los
requisitos de la aplicacin.

Subproceso: Especificacin de Requisitos
Especificacin de requisitos

Figura 8.13. Flujo de trabajo del subproceso Especificacin de Requisitos.
Tabla 8.6. Descripcin del flujo de trabajo: Especificacin de requisitos
Establecer estructura y
contenido del documento de
especificacin
Definir estructura del documento de
especificacin.
Definir contenido del documento de
especificacin.
Estructura y contenido de
documento.
Elaborar el documento

Especificar requisitos desde el punto de
vista del interesado (stakeholder).
Documentar tcnicamente los requisitos
de la aplicacin (punto de vista del grupo
de desarrollo).
Documento de especificacin de
Subproceso: Validacin de Requisitos
Validacin de requisitos

Figura 8.14. Flujo de trabajo del subproceso Validacin de requisitos
Tabla 8.7. Descripcin del flujo de trabajo: Validacin de requisitos
Revisar documento de
especificacin de
requisitos
Validar la estructura y el contenido del
documento
Validar especificacin tcnica de los
requisitos
Documento validado.
Validar la especificacin Elaborar prototipo de la aplicacin. Prototipo de la aplicacin.
80
de requisitos a travs de
un prototipo
Validar funcionalidad e interfaz de la
aplicacin.
Validar modelos Ajustar los modelos de especificacin
tcnica atendiendo a los resultados de
validacin del prototipo.
Verificar consistencia e integridad de la
especificacin tcnica.
Modelos actualizados y
validados.
Definir pruebas de
aceptacin de la
aplicacin
Determinar parmetros de aceptacin de
la aplicacin.
Definir casos de prueba de aceptacin.
Verificar, con los interesados, los
parmetros de aceptacin y los casos de
prueba de aceptacin de la aplicacin.
Conjunto de casos de
prueba de aceptacin de
la aplicacin.

Subproceso: Gestin de Requisitos
Gestin de requisitos

Figura 8.15. Flujo de trabajo del subproceso Gestin de requisitos
Tabla 8.8. Descripcin del flujo de trabajo: Gestin de requisitos
Planificacin de
cambios
Definicin de los medios de almacenamiento de los
Establecimiento de procedimientos y mecanismos de
mantenimiento y control de requisitos.
Procedimientos de
gestin de
requisitos.
Gestin de cambios

Seguir los procedimientos y mecanismos establecidos
para la gestin de cambios en los requisitos.
Realizar el cambio en los requisitos.
Asegurar consistencia e integridad de la base de
datos una vez realizados los cambios.
Base de datos de
requisitos
actualizada.
Rastreo de cambios Definir mbito de influencia del cambio sobre los
Asegurar actualizacin de documentos y modelos de
la aplicacin.
Matriz de rastreo de
requisitos.


Tcnicas y herramientas recomendadas para MDA e IR
Proceso Subproceso Tcnicas, estndares y prcticas Herramientas
Modelado
de
Dominio
de la
aplicacin
Modelado de
elementos
organizacionales

Validacin de
modelo de
dominio

Documentacin
de modelado de
dominio
Revisin de los manuales y documentos de la
organizacin
Entrevistas con miembros de la organizacin
Vistas de campo
Entrevista con expertos
Observacin de procesos de la organizacin
Modelado orientado a Objetos. Diagramas de
UML Business:
Objetivos, procesos, actividades, objetos,
organigramas
Visio Professional
SmartDraw
Rational ROSE
ArgoUML (Open
source)
Ingeniera
de
requisitos
Descubrimiento
de Requisitos

Anlisis de
Requisitos

Especificacin
de Requisitos

Validacin de
Requisitos

Gestin de
Requisitos
Mtodo del Marco Lgico
Entrevistas y reuniones de trabajo con los
interesados
Plantilla Volere (http://www.volere.co.uk/)
Revisin tcnica de documentos y manuales
Criterios de clasificacin
Matriz requisitos.vs.requisitos
Tcnicas de negociacin de requisitos
Modelado orientado a Objetos. Diagramas de
UML:
- Clases, actividades, secuencia, estados,
componentes, nodos, casos de uso y
escenarios
Estructura de documento de especificacin:
Estructura de Bruegge y Dutoit (2000) y
estndar IEEE 830-1998 para especificacin
Prototipos de software
Modelado de bases de datos relacionales
Matriz de seguimiento de requisitos
Visio Professional
SmartDraw
Rational ROSE
ArgoUML (Open
source)

82

Captulo
Procesos de Diseo
9

Este captulo describe los procesos tcnicos de diseo relacionados con el cmo debe ser
construida la aplicacin SIE para satisfacer los requisitos previamente recolectados. Este
grupo de procesos est compuesto por los procesos de Diseo Arquitectnico y Diseo
Detallado de la Aplicacin. El Diseo Arquitectnico produce la estructura de la aplicacin
representada como una arquitectura de software que muestra los componentes de la
aplicacin, sus conectores y las restricciones arquitectnicas. El Diseo Detallado describe
cada uno de estos componentes arquitectnicos.
La manera de presentar el grupo de procesos es la siguiente: primero se presenta el grupo, se
describe cada uno de los procesos que lo componen, sus interrelaciones, entradas y salidas y
productos parciales; luego cada proceso es descompuesto en dos o mas subprocesos los
cuales se describen de la misma forma y usando la misma notacin que el proceso principal.
Grupo de procesos de Diseo
Este grupo de procesos tcnicos tiene como objetivo general especificar la estructura y el
conjunto de componentes que deben conformar la aplicacin SIE para que sta satisfaga los
requisitos establecidos.
Para ello se emplean mtodos, tcnicas y herramientas apropiadas, para definir tanto el
diseo general de la aplicacin (su arquitectura) como para describir de manera detallada
cada uno de sus componentes; es decir, la interfaz usuario/ aplicacin, las bases de datos, los
programas, la documentacin y los procedimientos.
Diagrama de Procesos de Diseo
Tal como se seal anteriormente, el grupo de procesos de diseo comprende dos grandes
procesos: 1) El Diseo Arquitectnico (DA) y 2) El Diseo Detallado de los componentes de la
aplicacin (DD).
El proceso de Diseo Arquitectnico (DA) permite establecer el conjunto de componentes
que integran la aplicacin SIE, las relaciones y restricciones de interaccin entre ellos, las
relaciones con otras aplicaciones externas y la distribucin fsica de cada uno de estos
componentes.
El proceso de Diseo Detallado (DD) permite especificar de manera precisa cada uno de los
componentes de la arquitectura; incluyendo cada programa y su interfaz con el usuario, los
repositorios de datos y las conexiones previstas en la arquitectura. De igual manera, se
disean los procedimientos y documentos de uso y mantenimiento de la aplicacin.

<<documento>>
Tcnicas y estndares de diseo de SW
Formularios de especificacin de diseo de
SW
<<apoya>>
<<controla>> <<persigue>>
<<regula>>
<<objetivo>>
Especificar el conjunto de
componentes que deben
conformar la aplicacin SIA, para
que sta satisfaga los requisitos
establecidos.
<<actor>>
Lder de proyecto
<<herramienta>>
Ambiente
ArcGIS/ ArcIMS
Herramientas de diseo
<<apoya>>
<<reglas>>
Modelo de proceso
Mtodo MD-SIA
mtodos, tcnicas y formularios)
Plan de Proyecto
Directivas de diseo, especificacin y
documentacin de SW
<<actor>>
Grupo de diseo
Usuarios
<<participa>>
<<documento>>
Modelo de
dominio
<<apoya>>
<<documento>>
Documento de Diseo
de la aplicacin
Diseo
de la aplicacin
<<documento>>
de la Aplicacin

Figura 9.1a. Diagrama general del proceso Diseo de la Aplicacin
Diseo de la
de la aplicacin
Diseo de la
arquitectura
de la aplicacin
Diseo detallado
de la aplicacin

Figura 9.1b. Subprocesos del proceso de Diseo de la Aplicacin
Modelo de productos de diseo
De acuerdo al Modelo de Producto descrito en el Captulo 3, el conjunto de productos
asociados a los procesos de diseo de la aplicacin se muestra en la figura 9.2. El producto
mayor es el Documento de Diseo que agrupa a un conjunto de documentos tcnicos ms
detallados producidos durante la ejecucin de los procesos de Diseo Arquitectnico y Diseo
Detallado.
84
Documento de Diseo
de la Aplicacin
Descripcin de las metas
u objetivos de diseo de la
aplicacin
Documento de diseo de
componentes de
software
Documento de
diseo de la
Arquitectura
Documento de
diseo de la
BD
Descripcin de mtodos,
tcnicas y notaciones de
diseo
Documento de
diseo de la
Interfaz
1
1
1
1
1
1
Especificacin de Diseo
de la Aplicacin
Descripcin de Diseo de
la Aplicacin
1 1
Documento de Diseo
de la Aplicacin
Descripcin de las metas
u objetivos de diseo de la
aplicacin
componentes de
software
Documento de
diseo de la
Arquitectura
Documento de
diseo de la
BD
Descripcin de mtodos,
tcnicas y notaciones de
diseo
Documento de
diseo de la
Interfaz
1
1
1
1
1
1
Especificacin de Diseo
de la Aplicacin
Descripcin de Diseo de
la Aplicacin
1 1

Figura 9.2. Modelo de productos asociados al proceso Diseo Arquitectnico
Descripcin general de productos
Este proceso genera un producto final, el documento de diseo de la aplicacin, conformado
por un conjunto de productos intermedios: el documento de arquitectura de la aplicacin, las
especificaciones tcnicas de la(s) base(s) de datos, la especificacin completa de la interfaz
usuario/sistema y la especificacin de los programas y procedimientos requeridos para
implementar la aplicacin. A continuacin se describe brevemente cada uno de los productos
principales que integran el Documento de Diseo.
Documento de Diseo Arquitectnico
Es el producto final del proceso Diseo de la Arquitectura. Representa el conjunto de
componentes de la aplicacin, especificando sus caractersticas, funcionalidad, agrupamiento,
modos de interaccin y distribucin fsica en la plataforma tecnolgica de la organizacin, a la
cual pertenece la aplicacin SIE. El documento esta constituido por dos tipos de elementos:
los modelos en UML que representan la visin tcnica de la arquitectura y las descripciones
textuales que complementan y aclaran dicha especificacin tcnica.
Documento de Diseo de interfaz usuario/sistema
Producto parcial del proceso de Diseo Detallado de la aplicacin, especficamente con el
proceso de diseo de interfaz usuario/sistema. Este es un documento conformado por dos
partes complementarias: la tcnica y la textual o descriptiva. Esta ltima tiene como objetivo
explicar en trminos no demaSIEdos tcnicos el contenido del diseo detallado. La parte
tcnica contempla el conjunto de modelos que especifican de manera precisa, cmo debe ser
construida la interfaz de la aplicacin, indicando cmo sta debe responder o reaccionar ante
cada accin del usuario (modelo de interaccin). Adems, en este producto de diseo se
especifica, atendiendo al perfil del usuario, el contenido, estilo, modos de interaccin y
navegacin que proveer la interfaz de la aplicacin.
Documento de Diseo de la base de datos
Producto parcial del proceso Diseo Detallado de la aplicacin, especficamente relacionado
con el subproceso de especificacin de la(s) base(s) de datos de la aplicacin. Contiene al

igual que los otros documentos dos partes complementarias. En la parte tcnica se incluyen
los diseos de la base de datos a nivel conceptual (modelo de clases en UML datos
temticos y/o espaciales), a nivel de implementacin (relacional, espacial: vectorial o raster) y
a nivel de implantacin fsica en el sistema computacional disponible. La parte descriptiva del
documento especifica los criterios y elementos considerados para producir el diseo de la
base de datos y los procedimientos de administracin de dicha base de datos.
Documento de Diseo de componentes de software
Producto parcial del proceso Diseo Detallado de la aplicacin, especficamente relacionado
con el subproceso de especificacin de componentes de software de la aplicacin. Este
documento contiene la especificacin tcnica a nivel de algoritmos (seudo cdigo) o a nivel de
diagramas de actividades en UML, de cada uno de los componentes de software que se
deben construir para la implementar la aplicacin SIE. Esta especificacin va acompaada de
la descripcin de los servicios provistos por la interfaz de cada componente, de manera que se
pueda lograr la integracin (comunicacin, intercambio y cooperacin) entre los componentes
de la aplicacin tal y como se defini en la arquitectura.

El proceso Diseo de la Arquitectura (DA)
Diagrama del proceso
<<apoya>>
<<controla>>
<<persigue>>
<<regula>>
<<objetivo>>
Establecer el conjunto de
componentes que integran la
aplicacin, sus interrelaciones,
restricciones de interaccin y
su distribucin fsica.
<<apoya>>
<<participa>>
<<apoya>>
Diseo de la
arquitectura
de la aplicacin
<<documento>>
Documento de Diseo
de la arquitectura
<<documento>>
Documento de
Requisitos de la
Aplicacin
<<reglas>>
Modelo de proceso
Mtodo MD-SIA
Plan de Proyecto
documentacin de SW
<<actor>>
Lder de proyecto
<<documento>>
SW
<<herramienta>>
Ambiente
ArcGIS/ ArcIMS
<<actor>>
Grupo de diseo
Usuarios
<<documento>>
Modelo de
dominio

Figura 9.3. Diagrama general del proceso Diseo Arquitectnico
86
Modelo de productos de DA
Documento de Diseo de la
Arquitectura de la Aplicacin
Diagrama de
Despliegue
Modelo de
Componentes
Modelo de
Casos de Uso
Vistas Arquitectnicas
1
1
1
1
Mtodo de evaluacin
de la arquitectura
Descripcin
metas u objetivos
de diseo
Descripcin del
estilo estructural
1
1
1
Descripcin de diseo
1
Modelo de
interaccin
Diagramas de
secuencia
Diagramas
de Objetos
1 1
1
Modelos de
Clases
1
Arquitectura de la Aplicacin
Diagrama de
Despliegue
Modelo de
Componentes
Modelo de
Casos de Uso
Vistas Arquitectnicas
1
1
1
1
Mtodo de evaluacin
de la arquitectura
Descripcin
metas u objetivos
de diseo
Descripcin del
estilo estructural
1
1
1
Descripcin de diseo
1
Mtodo de evaluacin
de la arquitectura
Descripcin
metas u objetivos
de diseo
Descripcin del
estilo estructural
1
1
1
Descripcin de diseo
1
Modelo de
interaccin
Diagramas de
secuencia
Diagramas
de Objetos
1 1
1
Modelo de
interaccin
Diagramas de
secuencia
Diagramas
de Objetos
1 1
1
Modelos de
Clases
1

Figura 9.4. Modelo de producto del proceso Diseo Arquitectnico
Descripcin de productos DA
Este proceso genera dos tipos de productos: 1) la descripcin del diseo conformado por la
descripcin de las metas de diseo, del estilo estructural seleccionado como patrn y del
mtodo de evaluacin utilizado para determinar grado de acercamiento a los objetivos
planteados para el diseo. 2) la especificacin tcnica de la arquitectura constituida por las
diferentes vistas de diseo: uso, comportamiento, datos, componentes y despliegue. A
continuacin se describe brevemente cada uno de estos productos.
Modelo de Casos de Uso
Producto final del subproceso Elaboracin de vistas, especficamente las vistas de uso y
comportamiento de la aplicacin. En este caso representa el refinamiento del modelo de casos
de uso elaborado en el proceso de Ingeniera de Requisitos. Modelando de manera ms
precisa tanto las acciones de usuario como las reacciones del sistema. Sirve de entrada para
la definicin detallada de la construccin de los diagramas del modelo de interaccin y para la
especificacin de programas y procedimientos mediante los diagramas de actividad.
Modelo de Interaccin
Producto final del subproceso Elaboracin de vistas. Modelo constituido por los diagramas de
secuencia, actividad y/o transicin de estados de las clases dinmicas de la aplicacin. Segn
el tipo de aplicacin SIE, se determina si es necesario o no construir los diagramas de
transicin entre estados de las clases propias de la aplicacin.
Modelo de Clases
Producto final del subproceso Elaboracin de vistas, especficamente la vista de datos. Este
modelo es el refinamiento y extensin del modelo preliminar de clases construido durante el
proceso de Ingeniera de Requisitos.

Modelo de Componentes
Producto final del subproceso Elaboracin de vistas, especficamente la vista de
componentes. Representa el agrupamiento de los componentes definidos en la arquitectura
atendiendo a los requisitos de divisin en subsistemas, funcionalidad y/o servicios prestados
durante la ejecucin de la aplicacin. Notacin diagramas de componentes de UML.
Diagrama de Despliegue
Producto final del subproceso Elaboracin de vistas, especficamente la vista de despliegue.
Representa la distribucin de componentes de los componentes definidos en la arquitectura
atendiendo tanto a los requisitos tcnicos de plataforma de hardware y software como a los
requisitos de captura, acceso y manipulacin de datos y programas. Notacin diagramas de
despliegue o nodos de UML.
Subprocesos del proceso DA
Diseo de la
arquitectura
de la aplicacin
Definicin de
metas de diseo
Determinacin de
subsistemas
Elaboracin de
vistas
arquitectnicas
Evaluacin de
arquitectura

Figura 9.5. Subprocesos del proceso DA
EL proceso DA se descompone en cuatro subprocesos complementarios: Definicin del
diseo de metas de diseo, la determinacin de subsistemas, la elaboracin de vistas
arquitectnicas y la evaluacin de la arquitectura.
Descripcin de subprocesos DA
Cada subproceso es descrito en trminos de sus objetivos y del conjunto de actividades (flujo
de trabajo) y tareas (tabla de tareas y productos) cuya ejecucin permite producir cada uno de
los productos parciales definidos en el modelo de producto.
Subproceso: Definicin de metas de diseo
Este subproceso permite establecer las metas u objetivos de diseo que servirn de gua para
especificar y disear la aplicacin SIE y sus componentes.
Flujo de trabajo
88
Definicin de metas de diseo

Figura 9.6. Flujo de trabajo del subproceso Definicin de metas de diseo
Tabla 9.1. Descripcin del flujo de trabajo: Definicin de metas de trabajo
Determinacin de los
requisitos de la
arquitectura
Revisar las caractersticas de la plataforma
tecnolgica disponibles
Revisar los requisitos de funcionalidad y
restricciones definidos en el documento de
especificacin de requisitos
Definir las caractersticas tcnicas y
funcionales de la arquitectura
Lista de requisitos
tcnicos y de
funcionalidad que debe
cumplir la arquitectura de
la aplicacin
Definicin de las metas de
calidad
Revisar especificaciones de calidad que debe
satisfacer la aplicacin
Establecer los parmetros de calidad que la
arquitectura debe satisfacer
Definir los objetivos y las metas que debe
satisfacer la arquitectura a proponer
Criterios y parmetros de
calidad
Descripcin de las metas y
objetivos de diseo
Describir cada uno de los objetivos de diseo
resaltando su importancia, ventajas que aporta
y posibles debilidades
Descripcin de metas y
objetivos de diseo

Subproceso: Determinacin de subsistemas
Este subproceso gua la definicin de los diferentes subsistemas que componen la aplicacin,
sus objetivos, la manera de relacionarse entre ellos y con otras aplicaciones o sistemas.
Proceso que se basa en la definicin de criterios de descomposicin segn las caractersticas
de la aplicacin y de la plataforma tecnolgica de hardware y software.
Flujo de trabajo
Determinacin de subsistemas

Figura 9.7. Flujo de trabajo del subproceso Determinacin de subsistemas

Tabla 9.2. Descripcin del flujo de trabajo: Determinacin de subsistemas
Definicin del estilo
arquitectnico
Revisar los objetivos de diseo
Estudiar los diferentes estilos arquitectnicos que
pudieran satisfacer tales objetivos
Seleccionar un estilo o patrn arquitectnico
Adaptar el patrn seleccionado a los requisitos de
arquitectura predefinidos
Estilo arquitectnico
Determinacin de los
subsistemas
Establecer los criterios que permiten manejar la
complejidad de la aplicacin SIE
Verificar la adaptacin del patrn de arquitectura con
los criterios de reduccin de complejidad
Dividir la aplicacin en subsistemas
Describir cada subsistema, sus componentes e
interacciones con otros subsistemas
Divisin en
subsistemas
Modelo de
componentes
Descripcin de
subsistemas

Subproceso: Elaboracin de vistas arquitectnicas
Este subproceso gua la especificacin detallada de la arquitectura de la aplicacin a travs de
la elaboracin de las diferentes perspectivas o vistas que la componen: comportamiento, uso,
datos, componentes y despliegue.
Flujo de trabajo
Elaboracin de vistas arquitectnicas
Definiicin de vista de uso
Definicin de vista datos
Definicin de vista comportamiento
Definicin de vista despliegue
Definicin de vista componentes

Figura 9.8. Flujo de trabajo Subproceso Elaboracin de vistas arquitectnicas
Tabla 9.3. Descripcin del flujo de trabajo: Elaboracin de vistas arquitectnicas
Definicin de la
vista de uso
Determinar los casos de uso asociados a cada subsistema
(a partir del modelo de casos de uso de la especificacin de
requisitos)
Extender, si necesario, los casos de uso
Definir conjunto de escenarios de utilizacin
Revisar consistencia y coherencia de la vista de uso
Modelos de
casos de uso y
escenarios
Definicin de la
vista de
comportamiento
Definir elementos de accin y reaccin entre la aplicacin y
el usuario y entre la aplicacin y otras aplicaciones
Establecer mecanismos de interaccin entre subsistemas
y/o posibles componentes de la aplicacin.
Construir diagramas de secuencia y/o de estados
Revisar consistencia y coherencia de la vista de
comportamiento
Modelo de
interaccin
Diagramas de
transicin de
estados
Definicin de la
vista de datos
Revisar los diagramas de clases de objetos
Describir cada elemento de datos desde el punto de vista
Modelo de
clases
90
esttico y dinmico.
Construir los diagramas de clases
Determinar asociacin entre clases de objetos y
subsistemas de la aplicacin
Revisar consistencia y coherencia de la vista de datos
Diagramas de
transicin de
estados
Definicin de la
vista de
componentes
Revisar el modelo de clases de objetos
Revisar el modelo de casos de uso
Agrupar clases en componentes atendiendo a criterios
preestablecidos
Construir diagramas de componentes
Describir de manera general la interfaz de cada componente
Revisar consistencia y coherencia de la vista de
componentes
Modelo de
componentes

Definicin de la
vista de
despliegue
Revisar el modelo de componentes
Revisar la divisin de sistemas en subsistemas
Determinar asociacin entre componentes y subsistemas de
la aplicacin
Establecer distribucin de componentes segn estilo
arquitectnico y plataforma tecnolgica (Patrones
propuestos en WATCH)
Construir diagramas de despliegue
Revisar consistencia y coherencia de la vista de despliegue
Modelo de
despliegue

Subproceso: Evaluacin de la arquitectura
Este subproceso permite ajustar la arquitectura propuesta a los requisitos definidos para la
aplicacin. Para ello se selecciona un mtodo de evaluacin y se aplica.
Flujo de trabajo
Evaluacin de la arquitectura

Figura 9.9. Flujo de trabajo Subproceso Evaluacin de la arquitectura
Tabla 9.4. Descripcin del flujo de trabajo: Evaluacin de la arquitectura
Definicin del mtodo
de evaluacin
Definir factores clave de la arquitectura
Seleccionar un mtodo de evaluacin que permita
medir los factores claves de la arquitectura
Adaptar mtodo (si necesario) a las particularidades
de la arquitectura a evaluar
Lista de factores
claves a evaluar
Mtodo de evaluacin
de la arquitectura
Aplicacin del mtodo Definir modo de aplicacin del mtodo
Establecer cronograma de evaluacin
Realizar la evaluacin
Analizar resultados
Construir lista de oportunidades y fortalezas de la
arquitectura
Resultados de la
evaluacin
Lista de
oportunidades y
debilidades de la
arquitectura

El proceso Diseo Detallado (DD)
Diseo detallado
de la aplicacin
<<apoya>>
<<controla>>
<<persigue>>
<<regula>>
<<objetivo>>
Especificar, de manera precisa,
cada componente de
procesamiento, de interfaz y de
datos previsto en la arquitectura.
<<apoya>>
<<participa>> <<apoya>>
<<documento>>
Documento de
Requisitos de la
Aplicacin
Documento de Diseo
de la arquitectura
<<documento>>
Documento de diseo de la
base de datos
Documento de Diseo de
interfaz de la aplicacin
componentes de software
<<reglas>>
Modelo de proceso
Mtodo MD-SIA
Plan de Proyecto
documentacin de SW
<<actor>>
Lder de proyecto
<<documento>>
SW
<<herramienta>>
Ambiente
ArcGIS/ ArcIMS
<<actor>>
Grupo de diseo
Usuarios
<<documento>>
Modelo de
dominio

Figura 9.10. Diagrama del proceso Diseo Detallado de la aplicacin
Modelo de productos
Los productos producidos por el proceso Diseo Detallado ya han sido descritos de manera
general en la seccin correspondiente a la descripcin general de productos del grupo de
procesos Diseo de la aplicacin. Estos son el documento de diseo de interfaz
usuario/sistema, el documento de diseo de base de datos y el documento de diseo de
programas y procedimientos. Cada uno de estos productos se presenta en detalle, mas
adelante en este documento, cuando se describe cada uno de los subprocesos que los
producen.

Subprocesos del proceso DD

Diseo de
Componentes de
software
Diseo de las
Bases
de datos
Diseo detallado
de la aplicacin
Diseo de
interfaz
usuario/sistema
Figura 9.11. Subprocesos del proceso Diseo
Detallado de la Aplicacin
92
Modelo de producto: Subproceso Diseo de Interfaz usuario/sistema
Interfaz de la Aplicacin
Descripcin de objetivos y
lineamientos de diseo
para la interfaz
Diseo de interfaz
humano/aplicacin
Diseo de
contenido /
servicios
Diseo de
estilo /
esttica
Diagrama
de
navegacin
Diseo de
estructura de
la interfaz
1
1
1
1 1
1
Modelo de Casos
de Uso
Diagramas de
secuencia
1
1 1
Modelo de
interaccin
Especificacin de diseo
1
Interfaz de la Aplicacin
Descripcin de objetivos y
lineamientos de diseo
para la interfaz
Diseo de interfaz
humano/aplicacin
Diseo de
contenido /
servicios
Diseo de
estilo /
esttica
Diagrama
de
navegacin
Diseo de
estructura de
la interfaz
1
1
1
1 1
1
Modelo de Casos
de Uso
Diagramas de
secuencia
1
1 1
Modelo de
interaccin
Especificacin de diseo
1

Figura 9.12. Modelo de producto del subproceso Diseo de la Interfaz usuario/sistema.

Flujo de trabajo
Diseo de interfaz de usuario

Figura 9.13. Flujo de trabajo del subproceso Diseo de la Interfaz usuario/sistema

Tabla 9.5. Descripcin del flujo de trabajo: Diseo de la Interfaz usuario/sistema
Establecimiento del contenido y
los servicios a proveer a travs
de la interfaz
Definir el perfil de los usuarios
Analizar vista de uso
Estudiar vista de comportamiento
Estudiar vista de datos
Revisar especificaciones de
plataforma tecnolgica (HW y SW)
Determinar servicios a proveer
Determinar contenido de la interfaz
Especificacin detallada de
contenido y servicios a
proveer mediante la interfaz

Definicin del estilo y la esttica
de las pantallas de interaccin
requeridas
Revisar la especificacin de requisitos
y otras normas y reglas
organizacionales
Establecer parmetros de estilo y
esttica de la interfaz
Determinar medios y modos de
interaccin
Definir conjunto de elementos de
interfaz a implementar
Especificacin de estilo y
esttica de la interfaz (color,
letras, fondos, siglas, etc)
Lista de componentes de
interfaz: cajas, botones,
enlaces, iconos, etc.
Diseo general de pantallas
estructura
Diagrama preliminar de
componentes de interfaz

Definicin de la estructura de la
interfaz
Revisar la vista de comportamiento
Definir componentes de interfaz
Establecer relaciones de orden,
dependencia y composicin entre los
componentes de interfaz
Especificar la estructura de interfaz de
la aplicacin
Identificar fuentes (desarrollo, reuso)
proveedoras de los componentes de
interfaz
Estructura de interaccin o
navegacin a travs de la
aplicacin (flujo de
pantallas)
Diagrama de componentes
de interfaz
Modelo de producto: Subproceso Diseo de Base de Datos
la Base de Datos
Descripcin de las
BDs: temtica y
espacial
Procedimientos de
administracin de
la BD Modelo conceptual
de la BD
Modelo fsico
de la BD
Modelo
esttico
Modelo
dinmico
BD temtica
BD espacial
1
1
1
1..2
1 1
1 0..1
Descripcin de la BD
Especificacin de la BD:
modelos
1
Modelo
implementable
de la BD
la Base de Datos
Descripcin de las
BDs: temtica y
espacial
Procedimientos de
administracin de
la BD Modelo conceptual
de la BD
Modelo fsico
de la BD
Modelo
esttico
Modelo
dinmico
BD temtica
BD espacial
1
1
1
1..2
1 1
1 0..1
Descripcin de la BD
Especificacin de la BD:
modelos
1
Modelo
implementable
de la BD

Figura 9.14. Modelo de producto del subproceso Diseo de Base de Datos.

Flujo de trabajo
Diseo de la base de datos

Figura 9.15. Flujo de trabajo del subproceso Diseo de Base de datos
94
Tabla 9.6. Descripcin del flujo de trabajo: Diseo de Base de datos
Elaboracin del
modelo
conceptual
Revisar el modelo de clases obtenido en procesos
previos
Definir en detalle los atributos espaciales, temporales
y temticos en cada clase de objetos de negocio
Verificar las relaciones (asociaciones, generalizacin y
composicin) entre las clases de negocios
Completar los diagramas de clases correspondientes
a cada proceso del negocio (esquema conceptual
parcial) asociado a la aplicacin.
Verificar cada esquema parcial con los requerimientos
definidos para cada proceso
Validar con los usuarios respectivos cada esquema
parcial
Integrar los esquemas conceptuales parciales para
producir el esquema conceptual global
Establecer elementos de integracin y conversin de
datos y/o esquemas requeridos para la interaccin
con otras bases de datos de la organizacin
Diagramas de clases o
esquemas conceptuales
parciales (uno por cada
proceso del negocio
asociado con la
aplicacin SIE)

Modelo de clases global
o Esquema conceptual
integrado de la BD
Elaboracin del
modelo
implementable
Convertir los esquemas conceptuales en esquemas
implementables (relacionales).
Validar esquemas implementables con los
requerimientos de datos establecidos
Esquema
implementable de la
BD
Elaboracin del
modelo fsico
Establecer los ndices para cada una de las tablas del
esquema implementable
Definir los derechos de acceso para cada tipo de
usuario (usuario final, programador, ABD)
Definir las reglas de integridad de la BD
Elaborar el esquema de creacin de la BD fsica
Esquema fsico de la
BD
Definicin de
procedimientos
de
administracin
Definir los procedimientos de respaldo y recuperacin
de la BD
Definir los procedimientos de seguridad de la BD
Definir los procedimientos de control de cambios del
esquema de la BD
Procedimientos de
administracin de la BD

Modelo de producto: Subproceso Diseo de componentes
Componentes de Software
Modelo de
Interaccin
Componentes
Diagramas de
actividad
Diagramas de
secuencia
Diagramas de
objetos
Algoritmos
(seudo cdigo)
1..* *
1 1..*
1..*
1
Diagramas de
componentes
Diagramas de
implementacin
1..*
1

Figura 9.16. Modelo de producto del subproceso Diseo de componentes

Flujo de trabajo
Diseo de componentes de software

Figura 9.17. Flujo de trabajo del subproceso Diseo de componentes

Tabla 9.7. Descripcin del flujo de trabajo: Diseo de componentes
Especificacin de la
interfaz de
componentes

Definir los servicios que debe proveer cada
componente
Especificar tcnicamente la interfaz de cada
componente de software
Diagramas de
componentes
Contratos de uso
Especificacin de
interaccin de
componentes

Definir mecanismos de interaccin
Especificar secuencias de interaccin
Diagramas de
componentes
Modelos de interaccin
Especificacin de
implementacin de
componentes
Determinar modo de implementacin de la
parte activa de los componentes
Especificar las clases que integran cada
componente, y sus relaciones
Disear los mtodos de cada clase
Diagramas de clases
Algoritmos (seudo-
cdigo)
Diagramas de
implementacin

96

Proceso Subproceso Tcnicas, estndares y prcticas Herramientas
Diseo de
la
arquitectura
Definicin de metas
de diseo
Determinacin de
subsistemas
Elaboracin de
vistas
Evaluacin de la
arquitectura
Modelado orientado a Objetos. Diagramas de UML:
componentes, casos de uso y escenarios
Estilos arquitectnicos
Uso de la arquitectura genrica productos GIS,
ArcIMS, ArcView como referencia.
Manejo de complejidad mediante descomposicin en
subsistemas
Mtodos predefinidos para evaluacin de
arquitecturas de software
Visio Professional
SmartDraw
Power point
Rational Rose
ArcGIS
ArgoUML
(opensource)

Diseo
detallado
Diseo de interfaz
usuario/sistema
Diseo de base de
datos
Diseo de
programas y
procedimientos

Modelado orientado a Objetos. Diagramas de UML:
componentes, casos de uso y escenarios
Manejo de metforas, uso de colores, etc.
Prototipos
Modelado de bases de datos relacionales
Conversin de modelos conceptuales a modelos
implementables
Descomposicin modular
Visio Professional
SmartDraw
Power point
Rational Rose
ArcGIS
ArgoUML
(opensource)

98

Captulo
Procesos de Implementacin
10

Este captulo describe los procesos tcnicos de implementacin relacionados con la
construccin, pruebas y puesta en operacin de la aplicacin. Este grupo est compuesto por
los procesos de Construccin & Integracin, Pruebas de la Aplicacin y Entrega de la
Aplicacin. La Construccin & Integracin se encarga de producir, probar e integrar los
componentes arquitectnicos de la aplicacin. El proceso de Pruebas de la Aplicacin verifica
y valida la aplicacin para asegurarse que cumple con los requisitos especificados y satisface
las necesidades de los usuarios. La Entrega de la Aplicacin se encarga de poner en
operacin (produccin) a la aplicacin SIE desarrollada.
El captulo est organizado de la manera siguiente: primero se presenta el grupo de procesos
de implementacin, se describe despus cada uno de los procesos que lo componen, sus
interrelaciones, entradas y salidas y productos parciales; luego cada proceso es
descompuesto en dos o ms subprocesos, los cuales se explican de la misma forma, usando
la misma notacin UML Business.
El grupo de procesos de implementacin
El grupo de procesos de implementacin tiene como objetivos generales los siguientes: (1)
producir la aplicacin de acuerdo a las especificaciones de diseo arquitectnico y detallado
elaboradas en los procesos de diseo; (2) asegurarse de que la aplicacin cumple con todos
los requisitos acordados y satisface las necesidades del cliente; y (3) poner en produccin la
aplicacin en la infraestructura o plataforma de operacin instalada para tal efecto.
Adems de la codificacin de programas, otra actividad central de los procesos de
implementacin son las pruebas de estos programas. Es importante destacar, que las pruebas
de software se realizan a tres niveles: (1) Nivel de unidad, en el cual cada componente de
software es probado separadamente; (2) Nivel de integracin, en el cual se prueba la
integracin de los componentes y sus interacciones; y (3) Nivel de sistema, en el cual la
aplicacin se prueba como un todo. Las pruebas de unidad y de integracin tienen lugar
durante el proceso de Construccin & Integracin; mientras que las pruebas de sistema se
realizan en el proceso denominado Pruebas de la Aplicacin.
Tal como se seal anteriormente, este grupo comprende tres grandes procesos (ver figura
10.1a y 10.1b):
1) Construccin & Integracin
2) Pruebas de la Aplicacin
3) Entrega de la Aplicacin
El proceso de Construccin & Integracin (C&I) consiste en: (1) elaborar, codificar o adaptar
cada uno de los componentes que integran la aplicacin SIE; (2) probar cada componente
como una unidad; (3) integrar estos componentes de acuerdo a la arquitectura diseada; y (4)
probar la integracin de estos componentes.

El proceso de Pruebas de la Aplicacin (PA) consiste en verificar la aplicacin como un todo
y depurar los errores encontrados, a fin de asegurar que ella cumple con todos los requisitos
especificados en el Documento de Requisitos.
El proceso de Entrega de la Aplicacin (EA) es el proceso tcnico final del desarrollo de la
aplicacin SIE; en el cual, se realizan las actividades necesarias para ponerla en operacin
(produccin) y entregarla formalmente a sus usuarios.
<<documento>>
Documento de
Implementacin
Documento de
Pruebas
Informe final
<<actor>>
Grupos de
Implementacin,
Pruebas e Instalacin
Interesados y usuarios
Grupos SQA y SCM
<<documento>>
Modelo del Dominio
Documentacin de la
plataforma H/S: ArcGIS,
ORACLE, etc.
<<controla>> <<regula>>
<<reglas de negocio>>
Mtodo MD-SIA
Proceso de desarrollo de la aplicacin
Normas, estndares y procedimientos
de codificacin, pruebas e instalacin
Plan del Proyecto
Planes V&V, SCM, SQA y Capacitacin
<<actor>>
Lder de
Desarrollo de la
Aplicacin
<<proceso>>
Procesos de
Implementacin
<<objetivo>>
Elaborar la Aplicacin SIA
de acuerdo al diseo
establecido
<<documento>>
Documento de
Diseo
Plan de Pruebas
<<sistema>>
Aplicacin SIA
Operativa
<<persigue>>
<<datos>>
BDC-SIA
Otras
aplicaciones SIA

Figura 10.1a Diagrama general del grupo de procesos de Implementacin de la Aplicacin
<<proceso>>
Entrega de la
Aplicacin
<<proceso>>
Pruebas de la
Aplicacin
<<proceso>>
Construccin &
Integracin
<<proceso>>
Procesos de
Implementacin

Figura 10.1b. El grupo de procesos de Implementacin de la Aplicacin
El modelo de producto del grupo de procesos de Implementacin
Este proceso genera dos productos intermedios y uno final. Los dos productos intermedios
son: El Documento de Implementacin, conformado por los programas que implementan cada
uno de los componentes de software; y el Documento de Pruebas, que describe los resultados
del diseo y ejecucin de las pruebas tanto de los componentes como de su integracin e
instalacin. El producto final es, obviamente, la Aplicacin SIE completamente desarrollada y
lista para ser operada. A continuacin, se describe brevemente cada uno de estos productos.
100
Una descripcin detallada de cada uno de ellos, se da en la descripcin del proceso donde
ese producto se genera.
Documento de implementacin
Es un documento tcnico producido durante el proceso de Construccin e Integracin. Su
objetivo es documentar los resultados de: (1) la construccin de cada componente de la
arquitectura del sistema; (2) las pruebas unitarias de cada componente y (3) las pruebas de
Este documento contiene la descripcin y el cdigo fuente de cada uno de los componentes
arquitectnicos producidos, as como los detalles de su integracin. Es utilizado
posteriormente para realizar las pruebas del sistema, as como para facilitar las labores de
mantenimiento de la aplicacin una vez que sta entre en produccin.
Documento de pruebas
Este es el ltimo documento tcnico que se produce durante el desarrollo de una aplicacin
SIE. Su objetivo es documentar el diseo de las pruebas y los resultados de su ejecucin.
Informe Final
Es un documento de gestin que elabora el Lder de Desarrollo de la aplicacin con la
finalidad de dar por concluido el proyecto. Su objetivo es resumir el desarrollo del proyecto,
mediante la documentacin de las principales decisiones que se tomaron, los logros
alcanzados, las dificultades que se enfrentaron, los resultados de mtricas usadas, etc.
Aplicacin SIE
El producto final del desarrollo de una aplicacin es obviamente la misma aplicacin
compuesta por sus tres elementos que la integran: programas, repositorios de datos (archivos
y bases de datos) y documentos tcnicos (manuales de uso y mantenimiento).
El proceso de Construccin & Integracin (C&I)
Tal como se indic en el Captulo 3 (Modelo de Productos), una aplicacin SIE est integrada
por tres elementos: programas, repositorios de datos y manuales de uso y mantenimiento. Los
programas, a su vez, se organizan de acuerdo a la arquitectura de la aplicacin diseada en el
proceso de Diseo Arquitectnico. Esta arquitectura est, por lo general, compuesta de tres
capas interrelacionadas: una capa de presentacin encargada de la interfaz usuario/sistema;
una capa de lgica de negocios encargada de ejecutar las funciones de la aplicacin; y una
capa de datos encargada de la gestin de los datos. Cada capa, a su vez, consta de
componentes de software que se ensamblan o integran para conformar esa capa.
El proceso de Construccin & Integracin (ver figura 10.2) tiene como objetivo principal
elaborar cada uno de los tres elementos de que consta la aplicacin: programas, repositorios
datos y manuales. Los programas o componentes de software, que forman cada una de las
tres capas de la arquitectura de la aplicacin, deben ser elaborados y luego integrados para
darle forma a la capa. Los archivos y/o la(s) base(s) de datos que constituyen parte de la capa
de datos deben, tambin, ser creados y probados. Finalmente, los manuales de uso y
mantenimiento de la aplicacin son elaborados en este proceso.

DESARROLLO DE SOFTWARE EMPRESARIAL
101
<<sistema>>
Aplicacin SIA
Ensamblada
<<actor>>
Grupos de Implementacin
y Pruebas
Grupo SQA
Grupo SCM
<<controla>>
<<persigue>>
<<regula>>
<<actor>>
Lder de
Desarrollo de la
Aplicacin
<<proceso>>
Construccin &
Integracin
<<objetivo>>
Producir e integrar
los componentes
arquitectnicos
de la Aplicacin
Mtodo MD-SIA
de codificacin y pruebas
Plan del Proyecto
Planes V&V, SCM y SQA
<<documento>>
Documentos de
Diseo
Plan de Pruebas
<<documento>>
Modelo del Dominio
Documentacin de la
ORACLE, etc.
<<documento>>
Documento de
Implementacin
Manuales de Uso
y Mantenimiento
<<datos>>
BDC-SIA
Otras
aplicaciones SIA

Figura 10.2. Diagrama general del proceso Construccin & Integracin

Modelo de productos de C&I
Productos de
Construccin & Integracin
Manual de
Uso
Documento de
Implementacin
Manual de
Mantenimiento
1 1 1
Repositorio de
programas fuentes
de la aplicacin SIA
Repositorios de
datos: Archivos y/o
BDs locales

Figura 10.3. Modelo de producto del proceso Construccin & Integracin

102
Descripcin de productos C&I
Este proceso genera tres productos: 1) El Documento de Implementacin; 2) El Manual de
Uso; y (3) El Manual de Mantenimiento. Estos productos son elaborados por el Grupo de
Implementacin. A continuacin, se describe brevemente cada uno de estos productos.
Es un documento tcnico cuyo objetivo es documentar los resultados de: (1) la construccin
de cada componente de la arquitectura del sistema; (2) las pruebas unitarias de cada
componente y (3) las pruebas de integracin de estos componentes.
Este documento contiene una descripcin y el cdigo fuente de cada uno de los componentes
arquitectnicos producidos, as como los detalles de su integracin. Incluye, tambin, el diseo
de las pruebas unitarias (pruebas de cada componente de software) y de las pruebas de
Asociado a este documento, el Grupo de Implementacin debe mantener dos tipos de
repositorios:
Repositorio de programas.- Conjunto de archivos que contienen el cdigo fuente
producido por el Grupo de Implementacin.
Repositorios de datos.- Son los archivos o bases de datos locales que han sido
creadas por el Grupo de Implementacin
Una vez que el Grupo de Implementacin finalice las pruebas unitarias y de integracin de los
componentes de software y cree la(s) base(s) de datos locales, estos productos son
entregados al Grupo SQA/SCM. Este grupo se encargar de realizar la gestin de la
configuracin necesaria para garantizar el manejo de las versiones y control de los cambios
(ver Captulo 6).
El Documento de Implementacin es utilizado, posteriormente, para realizar las pruebas a
nivel del sistema, as como para facilitar las labores de mantenimiento de la aplicacin una vez
que sta entre en produccin.
Manual de uso
Es un producto final que forma parte de la aplicacin SIE. Su objetivo es describir como utilizar
la aplicacin SIE. Est dirigido a los usuarios de la aplicacin. La estructura de este
documento es guiada por la funcionalidad de la aplicacin, la cual est determinada por los
requisitos funcionales establecidos en el Documento de Requisitos. El documento debe
describir los siguientes aspectos del uso de la aplicacin:
Las caractersticas generales de la aplicacin.
Quienes son sus usuarios y las relaciones que la aplicacin tiene con los procesos de
negocio (procesos del dominio de la aplicacin) que los usuarios ejecutan.
La interfaz usuario/sistema de la aplicacin.
Cada una de las funciones de la aplicacin, indicando: cmo activarla; qu datos
debe proporcionar el usuario; qu datos o informacin produce el sistema; qu

103
procesos de negocio apoya; y qu mensajes de advertencia o error produce la
aplicacin.
Manual de mantenimiento
Es un producto final que forma parte de la aplicacin SIE. Su objetivo es describir cmo
realizar el mantenimiento de la aplicacin SIE. Est dirigido al grupo que se har cargo de
mantener la aplicacin una vez que esta haya sido puesta en operacin. La estructura y
contenido de este documento estn basados en los documentos de Requisitos, Diseo e
Implementacin. Debe describir tcnicamente la aplicacin y el proceso que este grupo debe
seguir para ejecutar las actividades de mantenimiento correctivo y perfectivo de la aplicacin.

Subprocesos del proceso C&I
<<proceso>>
Elaboracin de
Manuales
<<proceso>>
Creacin de la(s)
Base(s) de Datos
Local(es)
<<proceso>>
Construccin de
Programas
<<proceso>>
Construccin &
Integracin

Figura 10.4. Subprocesos del proceso C&I
EL proceso C&I se descompone en tres subprocesos complementarios: Construccin de
programas, creacin de las bases de datos locales y elaboracin de manuales de la
aplicacin.
Descripcin de subprocesos C&I
Cada uno de estos subproceso es descrito, a continuacin, en trminos de sus objetivos y del
conjunto de actividades (flujo de trabajo) y actividades (tabla de tareas y productos) cuya
ejecucin permite producir cada uno de los productos parciales definidos en el modelo de
producto.
Subproceso: Construccin de Programas
La construccin de programas consiste en buscar, adaptar, codificar o adquirir los
componentes de software que integran cada una de las tres capas de la arquitectura de una
aplicacin SIE. Una vez elaborados estos componentes, se prueban y ensamblan (integran)
para formar las correspondientes capas.
Un componente de software es una pieza de programa (cdigo) que ejecuta un conjunto de
funciones predeterminadas. Estas funciones son invocadas desde otro componente a travs
104
de una interfaz de programacin (API). La tabla 10.1 muestra algunos de los tipos de
componentes que pueden emplearse en el desarrollo de aplicaciones SIE.
Tabla 10.1. Tipos de componentes empleados en el desarrollo de aplicaciones SIE
Tipo de
Componente
Lenguaje de Programacin y
Plataforma de Ejecucin
Interfaz de
Programacin (API)
Estructura Interna del
Componente
Procedimiento
o funcin
C, C++ Definicin del
procedimiento o funcin
Conjunto de instrucciones
Script PHP, JSP, Javascript - Conjunto de comandos
empotrados en cdigo
HTML
Clase C++, C#, Java, PHP Interfaz de clase
(mtodos pblicos)
Conjunto de mtodos u
operaciones
Componente
propiamente
dicho
Java J2EE
C# - .NET
Interfaz de componente
(especificacin de
operaciones pblicas)
Conjunto de clases
interrelacionadas

Flujo de trabajo de la Construccin de Programas
Construccin & Integracion
;
Bsqueda de
Componentes de
Software
Adaptacin de
Componentes
Codificacin de
Componentes
Pruebas de
Integracin de
Componentes
Pruebas
Unitarias de
Componentes
Creacin del
Repositorio de
Programas
Elaboracin del
Documento de
Integracin

Figura 10.5. Flujo de trabajo del subproceso Construccin de Programas
Tabla 10.2. Descripcin del flujo de trabajo: Construccin de programas
Bsqueda de componentes de
software reutilizables
Identificar repositorios de componentes
internos o externos a la empresa, gratuitos o
comerciales.
Buscar componentes de software que puedan
ser reutilizados
Seleccionar aquellos componentes que
cumplan con las especificaciones de diseo
Adquirir los componentes seleccionados (si
son externos y/o comerciales)
Componentes de software
que pueden ser
reutilizados
Adaptacin de Componentes
Reutilizables
Para aquellos componentes que puedan ser
modificados (componentes caja blanca):
o Analizar el cdigo fuente a la luz de
las especificaciones de diseo
o Determinar los cambios que deben
hacerse al cdigo fuente
o Codificar los cambios
Componentes de software
adaptados
Codificacin de nuevos
Componentes
Para aquellos componentes que deben ser
codificados desde cero:
o Revisar y refinar el diseo detallado
de cada componente
Nuevos componentes de
software

105
o Usando este diseo, codificar cada
componente en el lenguaje de
programacin usado para desarrollar
la aplicacin SIE

Pruebas unitarias de
componentes
Elaborar el cronograma de pruebas unitarias
de acuerdo al Plan de Pruebas
Disear las pruebas unitarias para cada
componente de software adaptado o
desarrollado
Preparar los datos , mecanismos y
herramientas para pruebas unitarias
Ejecutar las pruebas unitarias de cada
componente
Depurar los errores encontrados en cada
componente
Especificaciones de
diseo de pruebas de
cada componente
Especificaciones de casos
de prueba
Especificaciones de
procedimientos de prueba
Reporte de fallas
encontradas
Componente probado

Creacin y actualizacin del
repositorio de programas del
proyecto
Crear el repositorio de programas (base de
componentes de software) del proyecto
Actualizar el repositorio con cada uno de los
componentes probados
Repositorio de Programas
Ensamblaje de la Aplicacin
SIE
Ensamblar los componentes de cada capa de
la aplicacin
Ensamblar las tres capas de la aplicacin

Aplicacin SIE
ensamblada (no probada
an)
Pruebas de integracin de
componentes
Elaborar el cronograma de pruebas de
integracin de acuerdo al Plan de Pruebas
Disear las pruebas de integracin de
componentes para cada una de las tres capas
de la arquitectura de la aplicacin
Disear las pruebas de integracin entre capas
de la arquitectura de la aplicacin
Preparar los datos , mecanismos y
herramientas para pruebas de integracin
Ejecutar las pruebas de integracin
Depurar los errores encontrados durante las
pruebas de integracin
Especificaciones de
diseo de pruebas de
integracin
de prueba
Especificaciones de
Reporte de fallas
encontradas
Aplicacin SIE
ensamblada
Elaboracin del Documento de
Implementacin
Definir la estructura u contenido de Documento
de Implementacin
Redactar el documento

Documento de
Implementacin

Subproceso: Creacin de la(s) Base(s) de Datos Local(es)
Este subproceso consiste en crear la o las bases de datos que la aplicacin SIE utilizar para
almacenar sus datos localmente. Es importante recordar que una aplicacin SIE, adems de
acceder a la BDC-SIE a travs de sus programas, tambin puede manejar sus propios datos
localmente.
Las dos actividades requeridas en este subproceso se ejecutan secuencialmente, por lo que
no se incluye el flujo de trabajo correspondiente. Estas actividades se describen brevemente
en la Tabla 10.3.
106

Tabla 10.3. Descripcin del flujo de trabajo: Creacin de la(s) Base(s) de Datos Local(es)
Elaboracin o generacin del
script de creacin de cada
base de datos local
Para cada base de datos local:
o Codificar o generar el script de
creacin de la BD, usando el
diseo fsico correspondiente

Scripts de creacin
de la(s) base(s) de
datos locales
Creacin de la(s) base(s) de
datos locales
Procesar cada script en el Sistema de
Gestin de Bases de Datos (DBMS)
empleado localmente

Base(s) de Datos
Locales

Subproceso: Elaboracin de Manuales
Este subproceso tiene por objetivo producir la documentacin tcnica que acompaa a la
aplicacin SIE, consistente en dos manuales tcnicos: manual de uso y manual de
mantenimiento. Estos manuales se pueden producir en medios impresos o electrnicos. Las
actividades de este subproceso se resumen en la Tabla 10.4.
Tabla 10.4. Descripcin del flujo de trabajo: Elaboracin de Manuales
Elaboracin del Manual de
Uso
Definir la estructura, medio y contenido del
Manual de Uso
Manual de Uso
de la Aplicacin
SIE
Elaboracin del Manual de
Mantenimiento
Definir la estructura, medio y contenido del
Manual de Mantenimiento
Manual de
Mantenimiento
de la Aplicacin
SIE

El proceso de Pruebas de la Aplicacin (PA)
Las pruebas de la aplicacin se realizan a nivel del sistema. Consisten, por lo tanto, en probar
la aplicacin como un todo, a fin de asegurar que ella satisface todos los requisitos funcionales
y no-funcionales que establece el Documento de Requisitos.
Este tipo de pruebas se divide en tres grupos:
Pruebas funcionales. Se encargan de probar la funcionalidad de la aplicacin de
acuerdo a lo especificado en los casos de uso descritos en el Documento de
Requisitos.
Pruebas no-funcionales. Consisten en probar o demostrar que cada uno de los
atributos de calidad, establecidos en el Documento de Requisitos, se cumplen.
Pruebas de aceptacin. Son pruebas de tipo funcional realizadas directamente por
los usuarios del sistema. Este tipo de prueba se centra en la interfaz U/S y en la
funcionalidad de la aplicacin.

107
<<documento>>
<<actor>>
Grupos de Pruebas e
Implementacin
Interesados
Grupos SQA y SCM
<<documento>>
Modelo del Dominio
Documentos de
Requisitos y Diseo
Documentacin de la
ORACLE, etc.
Mtodo MD-SIA
de pruebas
Plan del Proyecto
<<actor>>
Lder de
Desarrollo de la
Aplicacin
<<proceso>>
Pruebas de la
Aplicacin
<<objetivo>>
Asegurar que la
Aplicacin SIA cumple
con los requisitos
<<sistema>>
Aplicacin SIA
Probada
<<documento>>
Documento de
Implementacin
Plan de Pruebas
<<persigue>>
<<sistema>>
Aplicacin SIA
Ensamblada
<<datos>>
BDC-SIA
Otras
aplicaciones SIA

Figura 10.6. Diagrama general del proceso Pruebas de la Aplicacin
Modelo de productos de PA
Especificaciones de
Diseo de Pruebas:
Funcionales, No-
funcionales y de
Aceptacin
*
3
*
Especificaciones
de Casos de
Pruebas:
Funcionales, No-
funcionales y de
Aceptacin
Especificaciones de
Procedimientos de
Pruebas:Funcionale
s, No-funcionales y
de Aceptacin
Cronogramas de
Pruebas:
Funcionales, No-
funcionales y de
Aceptacin
*
Resumen de
Ejecucin de
Pruebas:
Funcionales, No-
funcionales y de
Aceptacin
3

Figura 10.9. Modelo de producto del proceso Pruebas de la Aplicacin
Descripcin de productos PA
Adems de aplicacin SIE probada, este proceso tcnico genera un producto intermedio
denominado Documento de Pruebas, el cual se describe a continuacin.
Es el ltimo documento tcnico que se produce durante el desarrollo de una aplicacin SIE.
Su objetivo es describir los resultados del diseo y ejecucin de las pruebas del sistema. Este
108
tipo de pruebas verifica que la aplicacin satisfaga los requisitos funcionales y no-funcionales
que fueron establecidos por los usuarios en el proceso de Ingeniera de Requisitos. A
diferencia de las pruebas de integracin, realizadas en el proceso de Construccin &
Integracin, las pruebas del sistema verifican que la aplicacin, como un todo, cumpla con los
requisitos establecidos. Estas pruebas validan, tambin, que la aplicacin sea el producto que
los usuarios esperan y necesitan.
El documento es elaborado por el Grupo de Pruebas una vez finalizado el proceso de Pruebas
de la Aplicacin. Este documento no debe confundirse con el Plan de Pruebas, el cual forma
parte del Plan del Proyecto. El Plan de Pruebas es, tambin, elaborado por el Grupo de
Pruebas antes de iniciar el proceso de Pruebas de la Aplicacin. Ambos documentos son
complementarios: El Plan de Pruebas describe el proceso de pruebas de la aplicacin y el
Documento de Pruebas reporta la ejecucin de estas pruebas. El Plan de Pruebas es un
documento de gestin, por lo que se describe en el Captulo 6.
Subprocesos del proceso PA
<<proceso>>
Pruebas de
Aceptacin
<<proceso>>
Pruebas No-
Funcionales
<<proceso>>
Pruebas
Funcionales
<<proceso>>
Pruebas de la
Aplicacin

Figura 10.7. Subprocesos del proceso PA
EL proceso PA se descompone en tres subprocesos complementarios: pruebas funcionales,
pruebas no-funcionales y pruebas de aceptacin.
Descripcin de subprocesos PA
Los tres subprocesos que conforman las Pruebas de la Aplicacin son bastante similares en
cuanto a su flujo de trabajo y actividades que deben ejecutarse. Ellos difieren en los objetivos
que persiguen, en la manera en que se ejecutan y en orden de ejecucin. Las pruebas
funcionales persiguen encontrar funciones incorrectas, faltantes o inconsistentes. Las pruebas
no-funcionales son pruebas que verifican que los atributos de calidad de la aplicacin,
establecidos en el Documento de Requisitos, se cumplan. Ambos tipos de pruebas son
diseadas y ejecutadas por el Grupo de Pruebas. Por su parte, las pruebas de aceptacin se
orientan a la validacin de la aplicacin; es decir, a demostrar que la aplicacin es el producto
que los usuarios esperan y requieren. Son diseadas por el Grupo de Pruebas; pero, son
ejecutadas directamente por los usuarios.
Dado que los flujos de trabajo y las actividades son similares para los tres tipos de pruebas,
presentamos, a continuacin, un nico flujo de trabajo (Figura 10.8) y una nica tabla de
actividades (Tabla 10.5). Tanto el flujo como la tabla son aplicables a cada uno de los tres
subprocesos de pruebas.

109

Flujo de trabajo de las Pruebas de la Aplicacin
Pruebas de la Aplicacin SIA
;

Figura 10.8. Flujo de trabajo para cada uno de los subprocesos de Pruebas de la Aplicacin
Tabla 10.5. Descripcin del flujo de trabajo de cada subproceso de Pruebas de la Aplicacin
Programacin de las pruebas
(funcionales, no-funcionales
de aceptacin)

Elaboracin del Cronograma de Pruebas
(segn Plan de Pruebas)
Cronograma de pruebas
Diseo de las pruebas
de aceptacin)

Definir los objetivos de las pruebas
Identificar los tems de prueba
Identificar los aspectos que se van a probar
Seleccionar las estrategias y tcnicas de
prueba
Elaborar las especificaciones de diseo de
pruebas
Elaborar las especificaciones de casos de
prueba
Elaborar las especificaciones de
Actualizar Plan de Pruebas
Especificaciones de
diseo de pruebas
de prueba
Especificaciones de
Preparacin de las pruebas
de aceptacin)

Preparar mecanismos de pruebas (scripts,
conductores, esqueletos, etc.)
Preparar los datos de prueba
Preparar el ambiente de pruebas
(herramientas, formatos, planillas, etc.)

Mecanismos de prueba
Datos de prueba
Ejecucin de las pruebas
de aceptacin)

Ejecutar cada una de las pruebas de acuerdo
al Plan de Pruebas y siguiendo las
especificaciones de prueba
Reportar los errores encontrados

Reporte de fallas

Correccin de errores (faltas y
fallas) encontrados
Corregir los errores detectados en cada una
de las pruebas funcionales, no funcionales o
de aceptacin
Realizar pruebas de regresin para asegurar
Aplicacin SIE probada
110
que las correcciones no introducen nuevos
errores

El proceso de Entrega de la Aplicacin (EA)
Este es el ltimo proceso tcnico que se realiza durante el desarrollo de una aplicacin SIE.
Consiste en: (1) Capacitar a los usuarios en el uso de la aplicacin; (2) Instalar la aplicacin
SIE en la infraestructura o ambiente de operacin definitivo; (3) Actualizar la(s) base(s) de
datos locales; (4) Realizar las pruebas de instalacin de la aplicacin e integracin a la BDC-
SIE, en su plataforma operativa; y (5) Entregar formalmente la aplicacin a sus usuarios y al
grupo de mantenimiento.
Diagrama del proceso EA
<<documento>>
Informe final del
Proyecto
<<actor>>
Grupos de
Implementacin y
Pruebas
Usuarios
Grupos SQA y SCM
<<documento>>
Modelo del Dominio
Documentos de
Requisitos, Diseo,
Implementacin y
Pruebas
Documentacin de la
plataforma H/S de
operacin
Mtodo MD-SIA
de pruebas e instalacin
Plan del Proyecto
Plan de Capacitacin
<<actor>>
Lder de
Desarrollo de la
Aplicacin
<<proceso>>
Entrega de la
Aplicacin
<<objetivo>>
Elaborar la Aplicacin SIA
de acuerdo al diseo
establecido
<<datos>>
Datos para
actualizacin de la
BD local
<<sistema>>
Aplicacin SIA
Operativa
<<persigue>>
<<sistema>>
Aplicacin SIA
Probada
<<datos>>
BDC-SIA
Otras
aplicaciones SIA

Figura 10.9. Diagrama general del proceso Entrega de la Aplicacin
Modelo de productos de EA
Este proceso genera dos tipos de productos: 1) La aplicacin SIE puesta en operacin (en
produccin) y 2) El Informe Final del Proyecto. Ambos productos fueron descritos al inicio de
este captulo (ver Seccin El modelo de producto del grupo de procesos de Implementacin).
El modelo de productos asociado al proceso EA se ilustra en la figura 10.10.

111

Productos de la
Entrega de la Aplicacin
Informe Final
del Proyecto
Programas
Instalados en la
Plataforma de
Operacin
*
1 1
Manuales de
Uso y
Mantenimiento
Base(s) de
Datos Local(es)
Actualizada(s)
Aplicacin SIA
Operativa
* *

Figura 10.10. Modelo de producto del proceso Entrega de la Aplicacin
Subprocesos del proceso EA
<<proceso>>
Entrega Formal
de la Aplicacin
<<proceso>>
Instalacin de la
Aplicacin
<<proceso>>
Capacitacin de
Usuarios
<<proceso>>
Entrega de la
Aplicacin
<<proceso>>
Pruebas de la
Instalacin
<<proceso>>
Actualizacin de
la BD local

Figura 10.11. Subprocesos del proceso EA
EL proceso EA se descompone en cinco subprocesos complementarios: Capacitacin de
usuarios, Instalacin de la aplicacin, Actualizacin de la base de datos local, Pruebas de la
instalacin, Entrega formal de la aplicacin.
Flujo de trabajo del proceso Entrega de la Aplicacin
Los cinco subprocesos que integran el proceso de Entrega de la Aplicacin se pueden
ejecutar en el orden indicado en la figura 10.12.
112
Entrega de la Aplicacin SIA
;
Capacitacin
de Usuarios
Instalacin de la
Aplicacin SIA
Actualizacin de la(s)
BD(s) Local(es)
Pruebas de la
Instalacin
Entrega Formal de
la Aplicacin SIA

Figura 10.12. Flujo de trabajo del proceso Entrega de la Aplicacin

Descripcin de subprocesos EA
Cada subproceso de Entrega de la Aplicacin es descrito, a continuacin, en trminos de sus
objetivos y del conjunto de actividades (tabla de descripcin de actividades) que el Equipo de
Desarrollo de la aplicacin debe realizar para producir los productos indicados.

Subproceso: Capacitacin de Usuarios
El objetivo de este subproceso es asegurar que los usuarios hagan un uso efectivo y
apropiado de la aplicacin SIE. Para ello es necesario elaborar y ejecutar un plan de
capacitacin que le permita a los usuarios adquirir el conocimiento, las destrezas y las
habilidades necesarias para utilizar apropiadamente la aplicacin SIE. Las actividades, tareas
y productos de este subproceso se muestran en la Tabla 10.7.
Tabla 10.7. Descripcin de las actividades del subproceso Capacitacin de Usuarios
Planificacin de la
Capacitacin
Definir los objetivos, necesidades y estrategias
de capacitacin
Establecer las actividades de capacitacin
Estimar los recursos requeridos
Elaborar el cronograma de actividades

Plan de Capacitacin
Preparacin del material de
capacitacin
Definir el formato, medio, estructura y
contenido del material de capacitacin
Elaborar el material de capacitacin
Material de Capacitacin
Organizacin y conduccin de
los talleres de capacitacin
Definir los objetivos, organizacin y estrategias
instruccionales de los talleres de capacitacin
Realizar los talleres de capacitacin

Subproceso: Instalacin de la Aplicacin
El objetivo de este proceso en trasladar la aplicacin SIE de su plataforma de desarrollo a la
plataforma en la que ella operar regularmente. Este subproceso es requerido siempre y

113
cuando ambas plataformas sean diferentes. Las actividades, tareas y productos de este
subproceso se muestran en la Tabla 10.8.
Tabla 10.8. Descripcin las actividades del subproceso: Instalacin de la Aplicacin
Preparacin de la
Plataforma de Operacin
Preparacin (seleccin, adquisicin
y/o instalacin) de los equipos
(hardware) donde operar la
aplicacin
Instalacin del software operativo
sobre el cual se instalar la aplicacin
(sistema operativo, software GIS,
DBMS, etc.)
Plataforma de Operacin de la Aplicacin
SIE
Instalacin de la
aplicacin
Instalacin de la aplicacin SIE en la
plataforma H/S de operacin
Aplicacin SIE instalada

Subproceso: Actualizacin de la(s) Base(s) de Datos Local(es)
El objetivo de este subproceso es llevar la(s) base(s) de datos locales al estado en que se
requiere para que la aplicacin pueda entrar en produccin. Este estado es el conjunto de
datos que esta(s) bases(s) de datos debe tener para el instante en que se da inicio a las
operaciones regulares de la aplicacin SIE.. Las actividades, tareas y productos de este
subproceso se muestran en la Tabla 10.9.
Tabla 10.9. Descripcin del flujo de trabajo: Actualizacin de la(s) Base(s) de Datos Local(es)
Definicin del estado
de inicio de la(s) BD(s)
Determinar que datos iniciales debe(n) tener la(s) BD(s)
local(es) para que la aplicacin SIE pueda entrar en
operacin

Preparar los datos Programar y organizar las actividades necesarias para
obtener los datos iniciales
Capturar, transcribir, editar, convertir y validar los datos
iniciales

Datos iniciales
Actualizar la(s) BD(s) Actualizar cada BD local con los datos iniciales BD(s)
actualizadas

Subproceso: Pruebas de Instalacin
Una vez que la aplicacin SIE ha sido instalada en su plataforma de operacin y su(s) BD(s)
ha(n) sido actualizada(s), se hace necesario realizar un conjunto de pruebas finales con los
objetivo de: (1) verificar que la aplicacin correr sin problemas en dicha plataforma; (2)
asegurar que los datos contenidos en la(s) BD(s) son correctos y representan el estado inicial
requerido para que la aplicacin SIE entre en produccin; y (3) verificar que la aplicacin SIE
se conecta sin dificultades a la BDC-SIE..
Las actividades, tareas y productos de este subproceso se muestran en la Tabla 10.10.

114
Tabla 10.10. Descripcin del flujo de trabajo: Pruebas de la Aplicacin
Pruebas de ejecucin en la
plataforma de operacin
Disear las pruebas de ejecucin de la aplicacin en
la plataforma de operacin
Ejecutar las pruebas de ejecucin
Depurar los errores encontrados durante las pruebas
de ejecucin
Especificaciones de
pruebas
Reporte de fallas
Pruebas del estado de
la(s) BD(S)
Disear las pruebas del estado de la aplicacin en la
plataforma de operacin
Ejecutar las pruebas de ejecucin
del estado inicial de la(s) BD(s)
Especificaciones de
pruebas
Reporte de fallas
Pruebas de Integracin de
la Aplicacin SIE con la
BDC-SIE
Disear las pruebas de integracin de la aplicacin
SIE con la BDC-SIE
Ejecutar las pruebas de integracin
de integracin con la BDC-SIE
Especificaciones de
pruebas
Reporte de fallas

Subproceso: Entrega Formal de la Aplicacin
Este ltimo subproceso tcnico tiene dos objetivos: (1) dar inicio formalmente a las
operaciones normales de la aplicacin SIE y (2) cerrar el proyecto de desarrollo de la
aplicacin. Las actividades, tareas y productos de este subproceso se muestran en la Tabla
10.11.
Tabla 10.11. Descripcin del flujo de trabajo: Entrega Formal de la Aplicacin
Entrega formal del sistema
a sus usuarios
Transferir la responsabilidad de la operacin de la
aplicacin a la unidad organizativa de la empresa que
tendr a su cargo la operacin de la aplicacin.
Transferir la responsabilidad del mantenimiento de la
aplicacin a la unidad organizativa de la empresa que
tendr a su cargo El mantenimiento de la aplicacin.

Inicio de las operaciones de
uso y mantenimiento de la
aplicacin SIE
Iniciar la operaciones de uso de la aplicacin SIE
Iniciar las operaciones de mantenimiento de la
aplicacin SIE

Aplicacin SIE
operativa
Cierre del proyecto Evaluar el proyecto de desarrollo de la aplicacin
Elaborar el informe final del proyecto
Presentar el informe al Comit Directivo de un SIE
Cerrar oficialmente el proyecto de desarrollo

Informe Final del
Proyecto

115

Tcnicas y herramientas de implementacin
Proceso Tcnicas, estndares y prcticas Herramientas
Construccin
& Integracin
Estndar de documentacin de pruebas IEEE-
829-1983
Estrategias de pruebas de unidad: caja blanca y
caja negra)
Estrategias de pruebas de integracin: pruebas
ascendentes, descendentes y combinadas
Plantillas para las especificaciones de pruebas
Tcnicas de depuracin (debugging)
Tcnicas, formatos y plantillas de elaboracin de
documentos tcnicos
Software GIS (Suite ArcGIS)
Gestor de bases de datos
(ORACLE, MySQL, etc.)
Ambientes integrados de
desarrollo de software (IDE)
Herramientas automatizadas
para pruebas de software
Herramientas CASE (Visio
Profesional, Poseidon,
Pruebas de
la Aplicacin
Estndar de documentacin de pruebas IEEE-
829-1983
Estrategias de pruebas funcionales (caja negra),
pruebas no-funcionales (pruebas de interfaz,
rendimiento, seguridad, etc.)
Plantillas para las especificaciones de pruebas
Tcnicas de depuracin (debugging)
Ambientes integrados de
desarrollo de software (IDE)
Herramientas automatizadas
para pruebas de software
Entrega de la
Aplicacin
Tcnicas de migracin de datos
Tcnicas de capacitacin: estrategias
instruccionales, dinmica de grupos
Tcnicas , formatos y plantillasde elaboracin de
informes tcnicos

116

Referencias bibliogrficas
(Booch, Rumbaugh and Jacobson, 1999) Booch, G. Rumbaugh, J. and Jacobson, I. The UML
User Guide. Addison Wesley, 1999
(BPMI, 2005) Business Process Modeling Initiative. Business Process Modeling Notation.
www.bpmi.org, 2005.
(Braude, 2003) Braude, E.J. Ingeniera de Software: Una perspectiva orientada a objetos. Cp.
3 y 4. Alfaomega, Mxico, 2003.
(Bruegge, Dutoit, 2000) Bruegge, B. and Dutoit, A. Object Oriented Software Engineering.
Prentice Hall, 2000.
(CMMI, 2005) Software Engineering Institute. Capability Maturity Model Integrated.
http://www.sei.cmu.edu/cmmi/
(CVG LA EMPRESA, 2004) CVG LA EMPRESA Gerencia de Proyectos. Divisin de Gestin
Corporativa de Proyectos. Julio, 2004.
(Checkland, 1981) Checkland, P. Systems Thinking, System Practice. John Wiley & Sons.
1981.
(Eriksson and Penker, 2000) Eriksson, H. and Penker, M. Business Modeling with UML. Wiley,
2000.
(Eriksson, Penker, Lyons and Fado, 2004) Eriksson, H-E, Penker, M. Lyons, B. and Fado, D.
UML 2 Toolkit. Wiley, 2004.
(Fuenmayor, 2001) Fuenmayor, R. Interpretando Organizaciones: Una teora Sistmico-
Interpretativa de Organizaciones. Consejo de Publicaciones de la ULA, Mrida, Venezuela,
2001.
(Hitchins, 2000) Hitchins, D. Basic Models for System Thinking. [En-lnea].
http://www.hitchins.co.uk/SysMods.html 2000.
(Jacobson, 1994) Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley. 1994.
(Kotonya and Sommerville, 2000) Kotonya, G. and Sommerville, I. Requirements Engineering:
Processes and Techniques. John Wiley and Sons, 2000.
(Kruchten, 2000) Kruchten, P. The Rational Unified Process: An Introduction. Addison-Wesley.
2000.
(Montilva and Barrios, 2004a) Montilva, J. and Barrios, J. A Business Modeling Method for
Information Systems Development. En Montilva, J. Besembel, I., Prez, M. y Losavio, F.
Sistemas de Informacin e Ingeniera de Software: Temas Selectos. Centro de Estudios en
Informtica. Mrida, Venezuela, 2004a. pp. 147-164.
(Montilva and Barrios, 2004b) Montilva, J. and Barrios, J. The Watch Model for Developing
Web Applications. En Montilva, J. Besembel, I., Prez, M. y Losavio, F. Sistemas de
Informacin e Ingeniera de Software: Temas Selectos. Centro de Estudios en Informtica.
Mrida, Venezuela, 2004b. pp. 327-344.

117
(OMG) OMG. Object Management Group. http://www.omg.org
(Pfleeger, 1998) Pfleeger, S.L. Software Engineering-Theory and Practice. Chap. 4. Prentice-
Hall, 1998.
(PMI, 2000) PMI. A Guide to the Project Management Body of Knowledge. PMBOK Guide.
Project Management Institute. Pennsylvania, USA. 2000.
(PMI, 2001) PMI. Practice Standard for Work Breakdown Structure. Project Management
Institute. Pennsylvania, USA. 2001.
(Sawyer and Kotonya, 2001) Sawyer, P. and Kotonya, G. Software Requirements. In Abran, A.
et al. (Eds.) Guide to the software engineering body of knowledge. Chapter 2. IEEE Computer
Society. Trial version 1.00, May 2001.
(Thayer and Dorfman, 2002) Thayer, R. and Dorfman, M. Software Engineering Vol.1: The
Development Process. 2nd. Edition. IEEE Computer Society. 2002.
(Wallace, 2004) Wallace, L. and Keil, M. Software Projects Risks and their Effect on
Outcomes. Communications of the ACM. Vol. 47, No. 4, April, 2004.
(ESRI, 2005) ESRI. http://www.esri.com
IEEE-1012-1998
IEEE 830-1998
118

Glosario de trminos
En esta seccin, se da un conjunto de definiciones claves que son esenciales para
familiarizarse y aplicar el mtodo WATCH.
Concepto Definicin
Actividad Conjunto estructurado de acciones o tareas realizadas por uno o ms
actores con la finalidad de alcanzar un objetivo predefinido. Una actividad
utiliza recursos (insumos) para generar productos o prestar servicios.
Actor Rol o funcin que ejerce una persona (o sistema) que interacta con una
aplicacin SIE participa, en modo alguno, en su desarrollo. Un actor est
vinculado de alguna manera al desarrollo del Sistema de Informacin
Empresarial(SIE); bien porque participa directamente en su desarrollo o
porque tiene la necesidad de utilizar este sistema.
En un sistema de negocios, un actor ejecuta actividades o tareas de uno o
ms procesos de negocio.
Aplicacin
informtica (,
simplemente,
aplicacin)
Un conjunto organizado de datos, programas de computacin y
documentacin que provee servicios de informacin a sus usuarios. Por
servicios de informacin se entiende un conjunto de funciones
automatizadas de entrada/adquisicin de datos, gestin de datos y
produccin de informacin para apoyar las actividades que realizan sus
usuarios.
BPMN (Business Process Modeling Notation) Notacin de modelado de procesos
propuesta por la organizacin BPMi (www.bpmi.org) como un medio para
modelar grficamente procesos en el contexto empresarial.
Dominio de la
Aplicacin
Sistema empresarial para el cual una aplicacin informtica presta sus
servicios de informacin. Es el sistema ampliado, ambiente o contexto en el
cual una aplicacin opera.
Estructura
organizativa
Manera de organizar los equipos de trabajo de un SIE representada
mediante organigramas
Equipo de
desarrollo de
aplicaciones
Conjunto de actores que participan directamente en el desarrollo de
aplicaciones de un SIE y que se organizan de acuerdo a una estructura
organizativa
Herramienta de
desarrollo de
software
Aplicacin sistema de software empleado para desarrollar software. Por
ejemplo, una herramienta CASE (Computer Aided Software Engineering)
una herramienta grfica usada en la elaboracin de modelos de software.
Instanciacin del
mtodo
Proceso mediante el cual un equipo de desarrollo de aplicaciones aplica el
mtodo WATCH y lo adecua a las caractersticas propias de un proyecto y
aplicacin particular.
Interesado
(Stakeholder)
Actor, grupo de actores, unidad organizacional de la empresa usuario
externo que participa directamente en el desarrollo de una aplicacin SIE o
que tiene la necesidad de utilizar esta aplicacin
Lenguaje de Lenguaje artificial, generalmente de carcter grfico textual, empleado en
el desarrollo de software y en el modelado de sistemas para representar

119
Concepto Definicin
Modelado diferentes aspectos de una aplicacin. Ejemplos, BPML, BPMN, UML.
WATCH Mtodo de desarrollo de aplicaciones informticas que ser empleado en
CVG-LA EMPRESA para elaborar las diferentes aplicaciones que integran la
arquitectura del Sistema de Informacin Empresarial- SIE
Mtodo de
desarrollo de
aplicaciones
Conjunto de modelos que describen, en general, que deben hacer los
equipos de desarrollo para un elaborar una aplicacin informtica.
Metodologa de
desarrollo de
software
Cuerpo de mtodos empleados por la Ingeniera de Software para producir,
mantener y operar software.
Modelo Representacin de un proceso, producto u otro elemento que interviene en
el desarrollo de un sistema o aplicacin.
Modelo de Actores Componente del mtodo WATCH cuya funcin es describir los aspectos
organizativos de los equipos de trabajo que desarrollarn las aplicaciones de
un SIE. Est compuesto por:
Lista o Matriz de Interesados que identifica a los actores que pueden
estar relacionados con el desarrollo de las aplicaciones.
Estructura Organizacional de Referencia que sirve de modelo para la
organizacin de los equipos de desarrollo de aplicaciones y
Roles y Responsabilidades que describen las funciones y tareas que
deben ejecutar los actores de cada proyecto de desarrollo de
aplicaciones.
Modelo de
Procesos
Componente del mtodo WATCH que describe los procesos gerenciales,
tcnicos y de soporte que deben seguir los equipos de desarrollo para
elaborar una aplicacin de un SIE.
Modelo de
Productos
Componente del mtodo WATCH que describe, en trminos generales, los
diferentes productos intermedios y finales que deben producirse durante el
desarrollo de una aplicacin de un SIE.
Objeto de Negocio Tipo de entidad vinculada de modo alguna a una empresa. Puede ser de
tipo concreto (Ej., insumos, productos, clientes y equipos, edificaciones, etc.)
o de tipo abstracto (Ej., servicios, datos, informacin, energa, ambiente,
software, etc.)
Proceso Conjunto estructurado de actividades que son ejecutadas por un conjunto de
actores con la finalidad de cumplir con objetivos pre-establecidos. Un
proceso transforma un conjunto de recursos (insumos: energa, informacin
y materia prima) en un conjunto de productos o servicios.
Proceso de
Negocio
Proceso que se realiza en una empresa (o sistema empresarial) con la
finalidad de alcanzar objetivos preestablecidos. Est compuesto por un
conjunto estructurado de actividades que son ejecutadas por actores. Se
divide en procesos claves (fundamentales) y procesos de apoyo ( soporte).
Proceso de
desarrollo de
Proceso tcnico, gerencial o de soporte que se ejecuta durante el desarrollo
120
Concepto Definicin
software de una aplicacin informtica
Producto de
Software
Producto intermedio o final elaborado durante el desarrollo de una aplicacin
informtica. Es cualquier resultado de una actividad o proceso de desarrollo
de software: aplicacin, modelo, plan, diseo, programa, especificacin,
base de datos, documento, informe, etc.
Rol Cargo o funcin que es ejercido por un actor en el marco del proyecto de
desarrollo de aplicaciones de un SIE

Responsabilidad Tarea que debe ser ejecutada por el actor que ejerce un rol determinado

Sistema
Empresarial
Una empresa o un subsistema de ella. Es un sistema integrado por un
conjunto de procesos de negocio que son ejecutados por los actores de la
empresa con la finalidad de alcanzar objetivos preestablecidos.
Sistema de
Informacin
Empresarial
Es un sistema que administra los datos alfanumricos y/o multimedia de una
empresa (o de una parte de ella), mediante el uso de tecnologas de
informacin y comunicacin, con el fin de:
Guardar un registro automatizado del estado de los objetos y procesos
de negocio de una empresa (o parte de ella) y
Producir informacin que facilite a los actores la ejecucin de los
procesos de negocio de la empresa, incluyendo los procesos claves
(produccin y servicios) y de soporte (gerenciales) de una empresa.
Sistema de
Informacin
Corporativo
Es un tipo de sistemas de informacin empresarial que satisface las
necesidades de informacin de toda una empresa relacionadas con uno o
ms procesos de negocio.
Sistema de
Informacin
Funcional
Es un tipo de sistema de informacin empresarial que cubre las necesidades
de una ms unidades organizacionales de una empresa relacionadas,
generalmente, con un proceso de negocios particular.
Sistema de
Informacin
Geogrfica
Es un tipo particular de sistema de informacin que procesa datos geo-
espaciales. Estos datos representan objetos geogrficos; es decir, aquellas
entidades de inters al sistema y que estn ubicadas sobre la superficie de
la tierra. Los datos geo-espaciales son datos geo-referenciados. Estn
constituidos por puntos, lneas o polgonos (o celdas) que estn referidos a
un sistema de coordenadas geogrficas preestablecida.
Tarea Actividad de corta duracin que es ejecutada por un actor en el marco de
otra actividad mayor.
Tcnica Procedimiento o algoritmo que describe los pasos que deben seguirse para
ejecutar un proceso o una actividad del desarrollo de una aplicacin. La
tcnica, generalmente, describe cmo se hace la actividad.
UML (Unified Modeling Language) Lenguaje de modelado de sistemas y software
que unifica un conjunto de notaciones diferentes que permiten modelar
distintos aspectos de un sistema, tales como su estructura, funcionalidad,
comportamiento e implementacin. Es un lenguaje estandarizado por el
consorcio OMG ( www.omg.org/uml ).

121

Desarrollo de Software Empresarial Jonas Montilva v0 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo de Software Empresarial Jonas Montilva v0 PDF

Cargado por

Copyright:

Formatos disponibles

DESARROLLO DE SOFTWARE

También podría gustarte