Desarrollo de Software Empresarial Jonas Montilva v0 PDF

DESARROLLO DE SOFTWARE
EMPRESARIAL
Jons Montilva C.
Judith Barrios A.
Universidad de Los Andes
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.
2
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
DESARROLLO DE SOFTWARE EMPRESARIAL 3

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):

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.
6
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.

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)
8
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.

Aspectos generales del mtodo Captulo
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
10
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

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
12
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.

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)
Operacin
y
Mantenimiento
Modelado
del Dominio de
la Aplicacin
Entrega de la Ingeniera
Aplicacin de Requisitos
Procesos
Pruebas de la Diseo
Gerenciales y
Aplicacin Arquitectnico
de Soporte
Construccin Diseo
& Integracin Detallado
Figura 2.6. Estructura del

modelo de procesos
14
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 Productos
Procesos
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

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.
16
.

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.
18
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

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).
20
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-

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.
22
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).

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.
24
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.

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.
26
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
Clientes ArcView ArcEditor ArcInfo
Servidor GIS ArcSDE
Servidor de DBMS
datos ORACLE
BDC-SIA
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.

Cliente
Aplicacin GIS-Web
Internet Browser
Capa de ArcIMS Viewer
Presentacin
Servidor WEB
ArcIMS Application
Server Conectors
Capa de
Lgica del ArcIMS Application
Negocio Server
ArcIMS Spatial
Server
ArcSDE
Capa de
Datos DBMS-ORACLE
BDC-SIA
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 Capa de Datos

Negocio
Navegador Servidor Servidor de GIS Server

Aplicaciones
estndar Web
ArcSDE
Componentes Funcionales en
Componentes de Interfaz U/S
Componentes de Interfaz U/S
Componentes Funcionales
Lado del Servidor Web
DBMS
Java, C#, C++,
Lado del Cliente
(ArcObjects)
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
28
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)

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
30
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

G. Asuntos Pblicos
D.Redes Regionales
Presidencia y Junta
D. Operacin, Mant.
G. Auditora Interna
D. Expansin de
D. Planificacin
Administracin
Y Transmisin
D. Produccin
G. Contralora
D. Telemtica
D. Finanzas y
D. Proyectos
G. Licitacin
Transmisin
D. Servicios
Generacin
G. Gestin
Ambiental
D. OPSIS
Directiva
G. RRHH
Interna
Componente
Geosfrico (Geologa, IB
SICR IMejT TR
Geomorfologa, Suelos SOC IC IMejG
L MT D
y Sismicidad) CMOC
Bitico (Fauna IB SOC IMejT TR

IMejG
y vegetacin) IC MT D
Hdrico IB SOC
PSE IMejT IMejG TR
(Hidrologa y SICR IC
PC OT MT Planta D
Limnologa) CMOC
Atmosfrico
IB SOC IMejT IMejG TR
(Clima, Meteorologa, PSE AE L
IC OT MT Planta D
Descargas elctricas)
PSE IB SOC TR
Socioeconmico SICR MT IMejG
PC IC D
IB SOC
Documentos PSE SICR IMejT TR
IC IMejG
Ambientales PC L MT D
CMOC
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

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.
32
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.

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
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 Elaborar el Plan de Proyecto de desarrollo de la
Desarrollo de aplicacin SIE que le sea asignada
Aplicaciones 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 Modelar el dominio de la aplicacin SIE..
Negocios Servir de enlace entre los usuarios y el equipo de
desarrollo.
Asegurar que los productos del desarrollo de la
34
aplicacin SIE estn alineados al sistema de negocios
que acta como dominio de la aplicacin.
Analista de Descubrir, analizar, especificar y documentar los
Sistemas requisitos de la aplicacin SIE.
Validar, en conjunto con los usuarios, los requisitos
establecidos.
Gestionar los requisitos.
Diseador de Disear la arquitectura de la aplicacin SIE y
Sistemas 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 Verificar y validar el sistema y sus diferentes
Pruebas 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 Gestionar el desarrollo de todo el Proyecto SIE,
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 Elaborar los procedimientos necesarios para gestionar

configuracin de los tems producidos en cada una de las aplicaciones
software 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 Asegurar la calidad del software producido por los
calidad equipos de desarrollo
Velar que los equipos de desarrollo empleen
apropiadamente el proceso de desarrollo de

aplicaciones definido a partir del Mtodo WATCH
Administrador de Proveer la informacin tcnica necesaria para que los
Bases de Datos 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 Mantener un alto nivel de disponibilidad de la
Sistemas 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
36
Como puede observarse en la figura 4.3, la estructura organizacional del Proyecto SIE es del
1
tipo matricial. En el tope de la estructura del Proyecto SIE 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

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.
38
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

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.
Operacin
y
Mantenimiento
Modelado
del Dominio de
la Aplicacin
Entrega de la Ingeniera
Aplicacin de Requisitos
Procesos
Pruebas de la Diseo
Gerenciales y
Aplicacin Arquitectnico
de Soporte
Construccin Diseo
& Integracin Detallado
a) Metfora del reloj

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:
40
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

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

Procesos de Gestin Planificacin del Proyecto (PP) Caso de Negocios
Plan del Proyecto
Organizacin del Proyecto (OP) Informes de Gestin
Proceso de desarrollo
Direccin del Proyecto (DP) Notas y correspondencia
del proyecto
Administracin de Recursos del

Proyecto (AP)
Control del Proyecto (CP)

Procesos de Soporte Gestin de la Configuracin del Plan de Gestin de la
Software (SCM) Configuracin
Aseguramiento de la Calidad del Plan de Gestin de Calidad

Software (SQA)
Gestin de Riesgos (GR) Plan de Gestin de Riesgos
Verificacin y Validacin (V&V) Plan de V&V

Plan de Pruebas
Capacitacin (CAP) Plan de Capacitacin
Procesos tcnicos Modelado del Dominio de la Modelo del Dominio de la
Aplicacin (MDA) Aplicacin
Ingeniera de Requisitos (IR) Documento de Requisitos
Diseo Arquitectnico (DA) Documento de Diseo
42
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

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
44
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.

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.
46
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 Elaborar y validar Caso de Negocios Caso de Negocios
Proyecto
Planificar el alcance del proyecto Plan del Proyecto
Elaborar la Estructura de Desagregacin del Trabajo (WBS) Proceso de desarrollo de la
aplicacin SIE
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
Organizacin del Definir roles y responsabilidades de los miembros del grupo de Plan de Gestin de RRHH
Proyecto desarrollo del proyecto (personal que ejecutar el proyecto)
Disear la estructura organizativa del grupo de desarrollo
(organigrama)
Direccin del Ejercer el liderazgo del grupo de desarrollo Informes de gestin, notas y
Proyecto correspondencia sobre el
Supervisar el personal
proyecto
Delegar autoridad
Motivar el personal
Coordinar las actividades
Comunicar resultados, decisiones e informacin sobre el
proyecto
Resolver conflictos
Administracin de Administrar los recursos humanos (RRHH) del proyecto Informes de gestin
Recursos 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.)
Control del Proyecto Desarrollar estndares de rendimiento del proyecto Informes de gestin sobre el
estado del proyecto
Establecer los mecanismos de monitora y reporte del proyecto
Plan del Proyecto
Medir y analizar el estado del proyecto
Actualizado
Tomar acciones correctivas
Actualizar el Plan del Proyecto

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.
rechazado
Caso de Negocios
Elaborar Validar
Caso de Caso de
Negocios Negocios
Aprobacin
aprobado
Planificar el
Alcance del
Proyecto
Alcance y objetivos
del proyecto
AND
Definir el proceso WBS
Elaborar la
de desarrollo de Estructura de
la aplicacin Trabajo (WBS)
AND
Planificar
Proceso de Actividades del
desarrollo Proyecto
Cronograma del
proyecto
Estimar Recursos Estimar Costos

Requeridos del Proyecto
Presupuesto
Elaborar
Documento
Plan del
Proyecto
Plan del Proyecto
Validar
Plan del
Proyecto
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.
48
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.

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.
50
Tabla 6.2 Tcnicas y herramientas que pueden emplearse en los procesos de gestin
Tcnicas, estndares y
Proceso Herramientas
mejores prcticas
Estndar PMIBOK
Metodologa de Gerencia de
Planificacin del Proyectos de LA EMPRESA
Proyecto PERT/CPM
Mtodo COCOMO II (estimacin de
costos)
Diseo organizacional Herramienta para gestin de
Organizacin del Matriz de asignacin de proyectos (Ej. MS PROJECT)
Proyecto responsabilidades
Organigramas
Direccin del
Proyecto Tcnicas de motivacin y liderazgo
Administracin de
Recursos
Control del
Proyecto PERT/CPM

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.
52
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

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
54
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.

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 Planificacin de la SCM Plan de Gestin de
Configuracin del la Configuracin
Software (SCM) Identificacin de la configuracin
del Software (Plan
Control de la configuracin SCM)
Contabilidad del asestado de la configuracin
Auditora de la configuracin
Gestin de versiones y entrega
Aseguramiento de la Planificacin de la SQA Plan de
Calidad del Software Aseguramiento de
(SQA) Evaluacin objetiva de productos
la Calidad del
Evaluacin objetiva de procesos Software (Plan
SQA)
Comunicacin de los aspectos de calidad
Resolucin de aspectos no-cumplidos
Gestin de Riesgos Planificacin de la gestin de riesgos Plan de Gestin de
(GR) Riesgos
Identificacin de riesgos
Anlisis de riesgos
Planificacin de respuestas
Monitoreo y control de riesgos
Verificacin y Planificacin de la V&V Plan V&V
Validacin (V&V)
Revisin del proyecto Plan de Pruebas
Revisin tcnica de productos
Gestin de pruebas
Capacitacin (CAP) Planificacin de la Capacitacin Plan de
Capacitacin
Contratacin de servicios de capacitacin
Capacitacin del equipo de desarrollo
Capacitacin de usuarios
Evaluacin de la 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,
56
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.

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.
58
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

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
60
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.

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

Planificacin de la V&V Elaboracin del Plan V&V
V&V del Concepto de Revisin tcnica del Caso de Negocios
operacin
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 Anlisis de la Trazabilidad
Aplicacin
Revisin tcnica del Diseo
Componentes (unidades)
Integracin Plan V&V
V&V de la Anlisis de la Trazabilidad Plan de Pruebas
Implementacin
Revisin tcnica del Cdigo Fuente Informes de
gestin sobre
Verificacin de los Casos de Pruebas de V&V
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 Anlisis de la Trazabilidad
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 Auditoria de la instalacin y configuracin de la
de la Aplicacin aplicacin
Generacin del informe final de V&V
Planificacin de la 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.
62
Anlisis de la Trazabilidad
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.

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.
64
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
Tcnicas, estndares y
Proceso
mejores prcticas Herramientas
Gestin de la Existe una amplia variedad de herramientas

SCM, incluyendo Rational Clear Case y CVS
Configuracin del IEEE Std. 828-1998
Software (ver:
http://www.laatuk.com/tools/SCM_tools.html)
PMIBOK (PMI, 2000)
Aseguramiento de
la Calidad del IEEE Std. 730-2001
Software Modelos de Calidad: FURPS,
McCall
PMIBOK (PMI, 2000) Matriz de Riesgos
Gestin de Riesgos
Revisin tcnica Ver lista de herramientas de V&V en:

http://vva.dmso.mil/Ref_Docs/VVTools/vvtools
Estrategias de pruebas: Caja
Verificacin y -pr.PDF
Negra y Caja Blanca
validacin
IEEE Std. 1012-1998
IEEE Std. 1028-1997

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.
66
<<reglas>>
Mtodo MD-SIA
Proceso de Desarrollo de la aplicacin
Normas y Estndares de la organizacin (incluye
mtodos, tcnicas, formularios) <<actor>>
Plan de Proyecto <<objetivo>>
Lder del Proyecto
Directivas para definicin y especificacin de Establecer formalmente
requisitos el conjunto de requisitos
que la aplicacin SIA
<<regula>> <<controla>> debe satisfacer.
<<persigue>>
<<documento>>
Informacin de Dominio <<documento>>

Anlisis de la Modelo del Dominio
Necesidades de los
interesados Aplicacin
Caso de Negocios de la Aplicacin
<<apoya>>
<<participa>> <<apoya>>
<<actor>> <<herramientas>>
Grupo Anlisis <<actor>> Tcnicas y estndares de especificacin y validacin de

productos de SW
Usuarios Ambiente ArcGIS/ ArcIMS
Formularios y planillas
Otras aplicaciones SIA Herramientas de graficacin y de apoyo al desarrollo
ArcGIS / ArcIMS
Figura 8.1a. Diagrama general del proceso Anlisis de la Aplicacin
Anlisis de la
aplicacin
Modelado Ingeniera de
de Dominio
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

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.
68
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.
<<reglas>>
<<objetivo>>
mtodos, tcnicas, formularios) Representar el contexto organizacional
en el cual se operar la aplicacin, de
Criterios de especificacin de objetivos Plan de <<actor>>
manera que se puedan definir sus
proyecto Lder del elementos, sus interrelaciones y el grado
Mtodo MD-SIA proyecto de influencia que pudiera tener sobre los
Proceso de Desarrollo de la aplicacin requisitos de la aplicacin SIA
<<controla>>
<<regula>> <<persigue>>
<<documento>>

Modelado de
Necesidades de los Dominio Modelo
interesados de Dominio
Caso de Negocios
<<participa>>
<<apoya>>
<<actor>> <<herramientas>>
Grupo de anlisis Herramientas de graficacin/
Miembros de organizacin documentos/
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).

Modelo de Dominio de la
Aplicacin
Modelo de 1
Objetivos
Modelo de Eventos
1
1 1
Modelo de Procesos del Modelo de Objetos del Modelo de Tecnologas
Negocio Negocio
1
1
Modelo de Reglas del
Negocio Modelo Actor/Rol
+ Estructura organizacional
1 1
Modelo de Procesos Modelo de Procesos

Primarios de Apoyo
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.
70
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.
Modelo de Tecnologas
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.

Modelado de
Dominio
Modelado de
Documentacin del
Elementos
Modelado
Organizacionales
de Dominio
Validacin del Modelo 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
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 Modelo de Objetivos
negocios: dominio o contexto de la (Jerarqua de Objetivos)
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.
72
Modelado de procesos primarios Identificar los procesos fundamentales. Cadena de valor
Definir la cadena de valor. Modelo de Procesos
Descomponer cada proceso en primarios (Diagramas de
subprocesos. procesos y subprocesos)
Construir los diagramas de procesos para Diagramas de actividad
cada proceso y subproceso. por subproceso
Definir las actividades asociadas a cada
subproceso de bajo nivel.
Modelado de procesos de apoyo Identificar los procesos de apoyo. Modelo de Procesos de
Descomponer cada proceso en apoyo (Diagramas de
subprocesos. procesos y subprocesos)
Construir de diagramas de procesos para Diagramas de actividad
cada proceso y subproceso. por subproceso
Definir las actividades asociadas a cada
subproceso de bajo nivel.
Modelado de tecnologa de Identificar las tecnologas de medicin y Resumen tcnico de
medicin y muestreo (M&M) muestreo. estaciones de medicin y
Analizar las tecnologas. muestreo
Caracterizar las tecnologas.
Modelado de reglas del negocio Identificar las reglas del negocio asociadas Lista de reglas del
a la aplicacin. negocio
Seleccionar las reglas relevantes para la
aplicacin.
Modelado de eventos Identificar los eventos asociados a la Lista de eventos
aplicacin. Matriz eventos/procesos
Describir los eventos segn su tipo.
Construir la matriz eventos/procesos.
Modelado de objetos Identificar los tipos de objetos del negocio. Modelo de objetos del
Definir las relaciones entre tipos de objetos. negocio (Diagrama de
Elaborar el modelo de objetos. clases de objetos)
Elaborar la matriz procesos-objetos. Matriz procesos/objetos
Modelado de actores y unidades Analizar la estructura organizacional. Modelo actor/rol
organizacionales Identificar los actores. Organigrama
Definir los roles de actores. Matriz actores/procesos.
Elaborar la 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 Elaborar plan de validacin. Plan de validacin
modelo Definir las responsabilidades de validacin de
los miembros del equipo de trabajo.
Revisin formal del modelo de Validar modelo de objetivos Modelo de dominio
dominio Validar modelo de procesos validado.
Validar modelo de reglas del negocio
Validar el resumen tcnico de las tecnologas de

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 Definir estructura del documento. Estructura del
estructura del documento Planificar actividades de redaccin. documento de
Definir pautas, lineamientos y terminologa a modelado de dominio.
emplear en la redaccin del documento.
Redaccin del documento Escribir cada seccin el documento atendiendo a Documento redactado
los lineamientos, pautas y terminologa y validado.
especificada.
Validar redaccin y estructura del documento.
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.
74
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
<<reglas>>
Mtodo MD-SIA
Modelo de proceso de la aplicacin
Normas y Estndares de la organizacin <<objetivo>>
(incluye mtodos, tcnicas, formularios)
Descubrir y formalizar el
Plan de Proyecto
conjunto de requisitos
<<actor>>
Directivas para definicin y especificacin de tcnicos que la aplicacin
requisitos Lder del proyecto SIA debe satisfacer.
<<regula>>
<<persigue>>
<<controla>>
<<documento>>

Necesidades de los Ingeniera
Documento de
interesados de requisitos
Requisitos
Modelo del Dominio
<<apoya>>
<<actor>> Tcnicas y estndares de especificacin
y validacin de productos de SW
-Grupo de Anlisis: <<actor>>
especificacin de requisitos Formularios
Ambiente ArcGIS /
Herramientas de graficacin y de apoyo
-Usuarios ArcIMS
al desarrollo ArcGIS / ArcIMS
.
Figura 8.8. Diagrama del proceso Ingeniera de Requisitos

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.
Documento de
Requisitos de la
Aplicacin
1 1
Descripcin de Especificacin de Requisitos
requisitos de la Aplicacin
1 1
*
1
Planillas de Modelo de casos Modelo preliminar de la
Matriz de de uso
recoleccin de interaccin de arquitectura de la
requisitos (Volere) requisitos O.. 1 aplicacin
1 Prototipo de 1
Listado de O.. * interfaz
requisitos de la Escenarios Modelo de clases
aplicacin
Modelo Dinmico Modelo Esttico
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
76
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 Anlisis Especificacin Validacin

de de de de
Requisitos Requisitos Requisitos 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.

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 Modelo de dominio
la aplicacin (sistema de negocios) actualizado.
Determinar los objetivos de la Objetivos de la aplicacin
aplicacin. claramente definidos.
Identificacin de actores del Identificar los actores del dominio Lista de actores clasificados.
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.
Recoleccin de requisitos de la Identificar requisitos funcionales de la Planillas (Volere) de
aplicacin. aplicacin. recoleccin de requisitos.
Identificar requisitos de interfaz
usuario/aplicacin.
Identificar requisitos no funcionales
de la aplicacin.
Recoleccin de requisitos de Identificar requisitos tcnicos. Modelos de casos de uso con
interaccin con otros sistemas Identificar requisitos funcionales. sus respectivos escenarios.
Identificar requisitos no funcionales.
Consolidacin de requisitos Verificar consistencia entre los Listado de requisitos de la
requisitos recolectados. aplicacin.
Unificar requisitos recolectados.
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 Establecer criterios de clasificacin. Requisitos clasificados.
requisitos Ubicar los requisitos dentro de la clasificacin.
78
Negociacin de Definir prioridades de los requisitos dentro de su Prioridades de los requisitos.
requisitos clasificacin. Listado de requisitos de la
Determinar el conjunto de requisitos que la aplicacin.
aplicacin debe satisfacer.
Refinamiento de Refinar requisitos no funcionales y funcionales Modelos de casos de uso, de
requisitos (casos de uso). clases y de estados.
Definir una arquitectura inicial de la aplicacin Arquitectura inicial: diagramas
segn los patrones propuestos en el mtodo de nodos
WATCH.
Refinar requisitos de almacenamiento (modelos
de clases de objetos).
Validacin Revisar, junto a los interesados, los requisitos Especificacin tcnica de la
de la aplicacin. aplicacin.
Ajustar los modelos. 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 Definir estructura del documento de Estructura y contenido de
contenido del documento de especificacin. documento.
especificacin Definir contenido del documento de
especificacin.
Elaborar el documento Especificar requisitos desde el punto de Documento de especificacin de
vista del interesado (stakeholder). requisitos de la aplicacin.
Documentar tcnicamente los requisitos
de la aplicacin (punto de vista del grupo
de desarrollo).
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 Validar la estructura y el contenido del Documento validado.
especificacin de documento
requisitos Validar especificacin tcnica de los
requisitos
Validar la especificacin Elaborar prototipo de la aplicacin. Prototipo de la aplicacin.

de requisitos a travs de Validar funcionalidad e interfaz de la
un prototipo aplicacin.
Validar modelos Ajustar los modelos de especificacin Modelos actualizados y
tcnica atendiendo a los resultados de validados.
validacin del prototipo.
Verificar consistencia e integridad de la
especificacin tcnica.
Definir pruebas de Determinar parmetros de aceptacin de Conjunto de casos de
aceptacin de la la aplicacin. prueba de aceptacin de
aplicacin Definir casos de prueba de aceptacin. la aplicacin.
Verificar, con los interesados, los
parmetros de aceptacin y los 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 Definicin de los medios de almacenamiento de los Procedimientos de
cambios requisitos de la aplicacin. gestin de
Establecimiento de procedimientos y mecanismos de requisitos.
mantenimiento y control de requisitos.
Gestin de cambios Seguir los procedimientos y mecanismos establecidos Base de datos de
para la gestin de cambios en los requisitos. requisitos
Realizar el cambio en los requisitos. actualizada.
Asegurar consistencia e integridad de la base de
datos una vez realizados los cambios.
Rastreo de cambios Definir mbito de influencia del cambio sobre los Matriz de rastreo de
requisitos de la aplicacin. requisitos.
Asegurar actualizacin de documentos y modelos de
la aplicacin.
80
Tcnicas y herramientas recomendadas para MDA e IR
Proceso Subproceso Tcnicas, estndares y prcticas Herramientas

Modelado Modelado de Revisin de los manuales y documentos de la Visio Professional
de elementos organizacin
Dominio SmartDraw
organizacionales
Entrevistas con miembros de la organizacin
de la Rational ROSE
aplicacin Vistas de campo
ArgoUML (Open
Entrevista con expertos source)
Validacin de
modelo de Observacin de procesos de la organizacin
dominio Modelado orientado a Objetos. Diagramas de
UML Business:
Documentacin Objetivos, procesos, actividades, objetos,
de modelado de organigramas
dominio
Ingeniera Descubrimiento Mtodo del Marco Lgico Visio Professional
de de Requisitos
requisitos Entrevistas y reuniones de trabajo con los SmartDraw
interesados
Rational ROSE
Plantilla Volere (http://www.volere.co.uk/)
ArgoUML (Open
Revisin tcnica de documentos y manuales source)
Criterios de clasificacin
Anlisis de
Requisitos Matriz requisitos.vs.requisitos
Tcnicas de negociacin de requisitos
Modelado orientado a Objetos. Diagramas de
UML:
Especificacin
de Requisitos - Clases, actividades, secuencia, estados,
componentes, nodos, casos de uso y
escenarios
Estructura de documento de especificacin:
Validacin de Estructura de Bruegge y Dutoit (2000) y
Requisitos estndar IEEE 830-1998 para especificacin
Prototipos de software
Gestin de Modelado de bases de datos relacionales
Requisitos
Matriz de seguimiento de requisitos

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.
82
<<reglas>>
Modelo de proceso
Mtodo MD-SIA <<objetivo>>
Normas y Estndares de la organizacin (incluye Especificar el conjunto de
mtodos, tcnicas y formularios)
componentes que deben
<<actor>>
Plan de Proyecto conformar la aplicacin SIA, para
Directivas de diseo, especificacin y Lder de proyecto que sta satisfaga los requisitos
documentacin de SW establecidos.
<<regula>>
<<controla>> <<persigue>>
<<documento>>
<<documento>> Documento de Diseo
Documento de Requisitos Diseo de la aplicacin
de la Aplicacin de la aplicacin
<<apoya>>
<<apoya>>
<<actor>> <<herramienta>> <<documento>>

<<documento>>
Grupo de diseo Ambiente Tcnicas y estndares de diseo de SW
Modelo de ArcGIS/ ArcIMS Formularios de especificacin de diseo de
Usuarios dominio SW
Herramientas de diseo
Figura 9.1a. Diagrama general del proceso Diseo de la Aplicacin
Diseo de la
de la aplicacin
Diseo de la
Diseo detallado
arquitectura
de la aplicacin
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.

Documento de Diseo
de la Aplicacin
1 1
Descripcin de Diseo de Especificacin de Diseo
la Aplicacin de la Aplicacin
1
1
1
Descripcin de mtodos,
tcnicas y notaciones de Documento de Documento de diseo de
diseo diseo de la componentes de
BD software
1
1 1
Descripcin de las metas Documento de Documento de
u objetivos de diseo de la diseo de la diseo de la
aplicacin Arquitectura Interfaz
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
84
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
<<reglas>>
Modelo de proceso
Mtodo MD-SIA
mtodos, tcnicas y formularios)
<<objetivo>>
Plan de Proyecto
<<actor>> Establecer el conjunto de
Directivas de diseo, especificacin y
componentes que integran la
documentacin de SW Lder de proyecto aplicacin, sus interrelaciones,
restricciones de interaccin y
su distribucin fsica.
<<regula>>
<<persigue>>
<<controla>>
<<documento>>
Documento de Diseo de la <<documento>>
Requisitos de la arquitectura Documento de Diseo

Aplicacin de la aplicacin de la arquitectura
<<participa>>
<<apoya>>
<<apoya>>
<<actor>> <<herramienta>> <<apoya>><<documento>>
<<documento>>
Grupo de diseo Ambiente Tcnicas y estndares de diseo de SW
Modelo de ArcGIS/ ArcIMS Formularios de especificacin de diseo de
Usuarios dominio SW
Figura 9.3. Diagrama general del proceso Diseo Arquitectnico

Modelo de productos de DA
Documento de Diseo de la
Arquitectura de la Aplicacin
Descripcin de diseo 1
Vistas Arquitectnicas
1
1
Descripcin del
estilo estructural Descripcin 1
1
metas u objetivos 1
de diseo Diagrama de Modelo de Modelo de
1
Despliegue interaccin 1
Casos de Uso
Mtodo de evaluacin
de la arquitectura 1 Modelo de
Componentes
Modelos de
1 1
Clases
Diagramas de Diagramas
secuencia de Objetos
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.
86
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
Elaboracin de
Definicin de Determinacin de Evaluacin de
vistas
metas de diseo subsistemas arquitectura
arquitectnicas
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

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 Revisar las caractersticas de la plataforma Lista de requisitos
requisitos de la tecnolgica disponibles tcnicos y de
arquitectura Revisar los requisitos de funcionalidad y funcionalidad que debe
restricciones definidos en el documento de cumplir la arquitectura de
especificacin de requisitos la aplicacin
Definir las caractersticas tcnicas y
funcionales de la arquitectura
Definicin de las metas de Revisar especificaciones de calidad que debe Criterios y parmetros de
calidad satisfacer la aplicacin calidad
Establecer los parmetros de calidad que la
arquitectura debe satisfacer
Definir los objetivos y las metas que debe
satisfacer la arquitectura a proponer
Descripcin de las metas y Describir cada uno de los objetivos de diseo Descripcin de metas y
objetivos de diseo resaltando su importancia, ventajas que aporta objetivos de diseo
y posibles debilidades
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
88
Tabla 9.2. Descripcin del flujo de trabajo: Determinacin de subsistemas
Definicin del estilo Revisar los objetivos de diseo Estilo arquitectnico
arquitectnico 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
Determinacin de los Establecer los criterios que permiten manejar la Divisin en
subsistemas complejidad de la aplicacin SIE subsistemas
Verificar la adaptacin del patrn de arquitectura con Modelo de
los criterios de reduccin de complejidad componentes
Dividir la aplicacin en subsistemas Descripcin de
Describir cada subsistema, sus componentes e subsistemas
interacciones con otros 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
Definicin de vista comportamiento
Definiicin de vista de uso Definicin de vista componentes
Definicin de vista datos
Definicin de vista despliegue
Elaboracin de vistas arquitectnicas
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 Determinar los casos de uso asociados a cada subsistema Modelos de
vista de uso (a partir del modelo de casos de uso de la especificacin de casos de uso y
requisitos) escenarios
Extender, si necesario, los casos de uso
Definir conjunto de escenarios de utilizacin
Revisar consistencia y coherencia de la vista de uso
Definicin de la Definir elementos de accin y reaccin entre la aplicacin y Modelo de
vista de el usuario y entre la aplicacin y otras aplicaciones interaccin
comportamiento Establecer mecanismos de interaccin entre subsistemas Diagramas de
y/o posibles componentes de la aplicacin. transicin de
Construir diagramas de secuencia y/o de estados estados
Revisar consistencia y coherencia de la vista de
comportamiento
Definicin de la Revisar los diagramas de clases de objetos Modelo de
vista de datos Describir cada elemento de datos desde el punto de vista clases

esttico y dinmico. Diagramas de
Construir los diagramas de clases transicin de
Determinar asociacin entre clases de objetos y estados
subsistemas de la aplicacin
Revisar consistencia y coherencia de la vista de datos
Definicin de la Revisar el modelo de clases de objetos Modelo de
vista de Revisar el modelo de casos de uso componentes
componentes 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
Definicin de la Revisar el modelo de componentes Modelo de
vista de Revisar la divisin de sistemas en subsistemas despliegue
despliegue 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
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 Definir factores clave de la arquitectura Lista de factores
de evaluacin Seleccionar un mtodo de evaluacin que permita claves a evaluar
medir los factores claves de la arquitectura Mtodo de evaluacin
Adaptar mtodo (si necesario) a las particularidades de la arquitectura
de la arquitectura a evaluar
Aplicacin del mtodo Definir modo de aplicacin del mtodo Resultados de la
Establecer cronograma de evaluacin evaluacin
Realizar la evaluacin Lista de
Analizar resultados oportunidades y
Construir lista de oportunidades y fortalezas de la debilidades de la
arquitectura arquitectura
90
El proceso Diseo Detallado (DD)
<<reglas>>
Modelo de proceso
Mtodo MD-SIA
<<objetivo>>
mtodos, tcnicas y formularios) Especificar, de manera precisa,
cada componente de
Plan de Proyecto
<<actor>> procesamiento, de interfaz y de
Directivas de diseo, especificacin y datos previsto en la arquitectura.
documentacin de SW Lder de proyecto
<<regula>>
<<controla>>
<<persigue>>
<<documento>>
<<documento>>
Documento de diseo de la
Documento de base de datos
Requisitos de la Diseo detallado
Aplicacin Documento de Diseo de
de la aplicacin interfaz de la aplicacin
Documento de Diseo
de la arquitectura Documento de diseo de
componentes de software
<<apoya>> <<apoya>> <<apoya>>

<<participa>>
<<documento>>
<<actor>> <<documento>> <<herramienta>>
Tcnicas y estndares de diseo de SW
Grupo de diseo Modelo de Ambiente
Formularios de especificacin de diseo de
dominio ArcGIS/ ArcIMS
Usuarios SW
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 detallado
de la aplicacin
Diseo de Diseo de las Diseo de

interfaz Bases Componentes de
usuario/sistema de datos software
Figura 9.11. Subprocesos del proceso Diseo
Detallado de la Aplicacin

Modelo de producto: Subproceso Diseo de Interfaz usuario/sistema
Documento de Diseo de la
Interfaz de la Aplicacin
1
1
Descripcin de objetivos y Especificacin de diseo

lineamientos de diseo
para la interfaz
1
Diseo de interfaz
humano/aplicacin
1
Modelo de 1
1
interaccin Diagrama
Diseo de de
contenido / navegacin
servicios 1 1
1 1
Diseo de Diseo de
Diagramas de Modelo de Casos estilo /
estructura de
secuencia de Uso la interfaz esttica
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 Definir el perfil de los usuarios Especificacin detallada de
los servicios a proveer a travs Analizar vista de uso contenido y servicios a
de la interfaz Estudiar vista de comportamiento proveer mediante la interfaz
Estudiar vista de datos
Revisar especificaciones de
plataforma tecnolgica (HW y SW)
Determinar servicios a proveer
Determinar contenido de la interfaz
Definicin del estilo y la esttica Revisar la especificacin de requisitos Especificacin de estilo y
de las pantallas de interaccin y otras normas y reglas esttica de la interfaz (color,
requeridas organizacionales letras, fondos, siglas, etc)
Establecer parmetros de estilo y Lista de componentes de
esttica de la interfaz interfaz: cajas, botones,
Determinar medios y modos de enlaces, iconos, etc.
interaccin Diseo general de pantallas
Definir conjunto de elementos de estructura
interfaz a implementar Diagrama preliminar de
componentes de interfaz
92
Definicin de la estructura de la Revisar la vista de comportamiento Estructura de interaccin o
interfaz Definir componentes de interfaz navegacin a travs de la
Establecer relaciones de orden, aplicacin (flujo de
dependencia y composicin entre los pantallas)
componentes de interfaz Diagrama de componentes
Especificar la estructura de interfaz de de interfaz
la aplicacin
Identificar fuentes (desarrollo, reuso)
proveedoras de los componentes de
interfaz
Modelo de producto: Subproceso Diseo de Base de Datos
Documento de Diseo de
la Base de Datos
1..2
1
Descripcin de la BD BD temtica Especificacin de la BD:
modelos
BD espacial
1
1
Descripcin de las Procedimientos de 1 1 1
BDs: temtica y administracin de
espacial la BD Modelo conceptual Modelo Modelo fsico
de la BD implementable de la BD
de la BD
1 0..1
Modelo Modelo
esttico dinmico
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

Tabla 9.6. Descripcin del flujo de trabajo: Diseo de Base de datos
Elaboracin del Diagramas de clases o
modelo Revisar el modelo de clases obtenido en procesos esquemas conceptuales
conceptual previos parciales (uno por cada
Definir en detalle los atributos espaciales, temporales proceso del negocio
y temticos en cada clase de objetos de negocio asociado con la
aplicacin SIE)
Verificar las relaciones (asociaciones, generalizacin y
composicin) entre las clases de negocios Modelo de clases global
o Esquema conceptual
Completar los diagramas de clases correspondientes
integrado de la BD
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
Elaboracin del Esquema
modelo Convertir los esquemas conceptuales en esquemas implementable de la
implementable implementables (relacionales). BD
Validar esquemas implementables con los
requerimientos de datos establecidos
Elaboracin del Esquema fsico de la
modelo fsico Establecer los ndices para cada una de las tablas del BD
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
Definicin de Procedimientos de
procedimientos Definir los procedimientos de respaldo y recuperacin administracin de la BD
de de la BD
administracin Definir los procedimientos de seguridad de la BD
Definir los procedimientos de control de cambios del
esquema de la BD
Modelo de producto: Subproceso Diseo de componentes
Documento de Diseo de
Componentes de Software
1
1
1..*
Modelo de Diagramas de
Componentes Interaccin implementacin
1..* 1 1..*
1..* *
Diagramas de Diagramas de Algoritmos Diagramas de Diagramas de
componentes actividad (seudo cdigo) objetos secuencia
Figura 9.16. Modelo de producto del subproceso Diseo de componentes
94
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 Definir los servicios que debe proveer cada Diagramas de
interfaz de componente componentes
componentes Especificar tcnicamente la interfaz de cada Contratos de uso
componente de software
Especificacin de Definir mecanismos de interaccin Diagramas de
interaccin de Especificar secuencias de interaccin componentes
componentes Modelos de interaccin
Especificacin de Determinar modo de implementacin de la Diagramas de clases

implementacin de parte activa de los componentes Diagramas de actividad
componentes Especificar las clases que integran cada Algoritmos (seudo-
componente, y sus relaciones cdigo)
Disear los mtodos de cada clase Diagramas de
implementacin

Proceso Subproceso Tcnicas, estndares y prcticas Herramientas

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

arquitecturas de software
Diseo Diseo de interfaz Modelado orientado a Objetos. Diagramas de UML: Visio Professional
detallado usuario/sistema - Clases, actividades, secuencia, estados, SmartDraw
Diseo de base de componentes, casos de uso y escenarios
Power point
datos Manejo de metforas, uso de colores, etc.
Rational Rose
Diseo de Prototipos
programas y ArcGIS
procedimientos Modelado de bases de datos relacionales
ArgoUML
Conversin de modelos conceptuales a modelos (opensource)
implementables
Descomposicin modular
96
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.
98
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.
<<reglas de negocio>>
Mtodo MD-SIA
Proceso de desarrollo de la aplicacin
Normas, estndares y procedimientos <<objetivo>>
<<actor>>
de codificacin, pruebas e instalacin Elaborar la Aplicacin SIA
Lder de de acuerdo al diseo
Plan del Proyecto
Desarrollo de la <<persigue>> establecido
Planes V&V, SCM, SQA y Capacitacin Aplicacin
<<documento>>
<<regula>> <<controla>>
Documento de
Implementacin
<<proceso>>
<<documento>> Documento de
Pruebas
Documento de
Diseo
Procesos de Informe final
Plan de Pruebas Implementacin
<<sistema>>
Aplicacin SIA
Operativa
<<actor>> <<datos>> <<documento>>

Grupos de BDC-SIA Modelo del Dominio
Implementacin,
Otras Documento de Requisitos
Pruebas e Instalacin
aplicaciones SIA
Documentacin de la
Interesados y usuarios
plataforma H/S: ArcGIS,
Grupos SQA y SCM ORACLE, etc.
Figura 10.1a Diagrama general del grupo de procesos de Implementacin de la Aplicacin
<<proceso>>
Procesos de
Implementacin
<<proceso>> <<proceso>> <<proceso>>
Construccin & Pruebas de la Entrega de la

Integracin Aplicacin Aplicacin
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.

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.
100
Mtodo MD-SIA
Proceso de desarrollo de la aplicacin <<objetivo>>
Normas, estndares y procedimientos <<actor>> Producir e integrar
de codificacin y pruebas Lder de los componentes
Desarrollo de la arquitectnicos
Plan del Proyecto <<persigue>>
Aplicacin de la Aplicacin
Planes V&V, SCM y SQA
<<regula>> <<controla>> <<documento>>
Documento de
<<proceso>> Implementacin
<<documento>>
Manuales de Uso
Documentos de y Mantenimiento
Diseo Construccin &
Plan de Pruebas Integracin <<sistema>>
Aplicacin SIA
Ensamblada

Gruposde Implementacin BDC-SIA Modelo del Dominio
y Pruebas
Otras Documento de Requisitos
Grupo SQA aplicaciones SIA
Documentacin de la
Grupo SCM plataforma H/S: ArcGIS,
ORACLE, etc.
Figura 10.2. Diagrama general del proceso Construccin & Integracin
Modelo de productos de C&I
Productos de
Construccin & Integracin
1 1 1
Documento de Manual de Manual de

Implementacin Uso Mantenimiento
Repositorio de Repositorios de
programas fuentes datos: Archivos y/o
de la aplicacin SIA BDs locales
Figura 10.3. Modelo de producto del proceso Construccin & Integracin
DESARROLLO DE SOFTWARE EMPRESARIAL

101
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
102
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>>
Construccin &
Integracin
<<proceso>>
<<proceso>> <<proceso>>
Creacin de la(s)
Construccin de Elaboracin de
Base(s) de Datos
Programas Manuales
Local(es)
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

103
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 Lenguaje de Programacin y Interfaz de Estructura Interna del

Componente Plataforma de Ejecucin Programacin (API) Componente
Procedimiento C, C++ Definicin del Conjunto de instrucciones
o funcin procedimiento o funcin
Script PHP, JSP, Javascript - Conjunto de comandos
empotrados en cdigo
HTML
Clase C++, C#, Java, PHP Interfaz de clase Conjunto de mtodos u
(mtodos pblicos) operaciones
Componente Java J2EE Interfaz de componente Conjunto de clases
propiamente C# - .NET (especificacin de interrelacionadas
dicho operaciones pblicas)
Flujo de trabajo de la Construccin de Programas
Construccin & Integracion

Adaptacin de
Componentes
Bsqueda de Pruebas Creacin del Pruebas de Elaboracin del

Componentes de Unitarias de Repositorio de Integracin de Documento de
Software Componentes Programas Componentes Integracin
Codificacin de
Componentes
;
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 Identificar repositorios de componentes Componentes de software
software reutilizables internos o externos a la empresa, gratuitos o que pueden ser
comerciales. reutilizados
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)
Adaptacin de Componentes Para aquellos componentes que puedan ser Componentes de software
Reutilizables modificados (componentes caja blanca): adaptados
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
Codificacin de nuevos Para aquellos componentes que deben ser Nuevos componentes de
Componentes codificados desde cero: software
o Revisar y refinar el diseo detallado
de cada componente
104
o Usando este diseo, codificar cada
componente en el lenguaje de
programacin usado para desarrollar
la aplicacin SIE
Pruebas unitarias de Elaborar el cronograma de pruebas unitarias

componentes de acuerdo al Plan de Pruebas Especificaciones de
diseo de pruebas de
Disear las pruebas unitarias para cada
cada componente
componente de software adaptado o
desarrollado Especificaciones de casos
Preparar los datos , mecanismos y de prueba
herramientas para pruebas unitarias
Ejecutar las pruebas unitarias de cada Especificaciones de
componente procedimientos de prueba
Depurar los errores encontrados en cada Reporte de fallas
componente encontradas
Componente probado
Creacin y actualizacin del Crear el repositorio de programas (base de Repositorio de Programas

repositorio de programas del componentes de software) del proyecto
proyecto Actualizar el repositorio con cada uno de los
componentes probados
Ensamblaje de la Aplicacin Ensamblar los componentes de cada capa de
SIE la aplicacin Aplicacin SIE
ensamblada (no probada
Ensamblar las tres capas de la aplicacin
an)
Pruebas de integracin de Elaborar el cronograma de pruebas de
componentes integracin de acuerdo al Plan de Pruebas Especificaciones de
diseo de pruebas de
Disear las pruebas de integracin de
integracin
componentes para cada una de las tres capas
de la arquitectura de la aplicacin Especificaciones de casos
Disear las pruebas de integracin entre capas de prueba
de la arquitectura de la aplicacin
Preparar los datos , mecanismos y Especificaciones de
herramientas para pruebas de integracin procedimientos de prueba
Ejecutar las pruebas de integracin Reporte de fallas
Depurar los errores encontrados durante las encontradas
pruebas de integracin
Aplicacin SIE
ensamblada
Elaboracin del Documento de Definir la estructura u contenido de Documento Documento de
Implementacin de Implementacin Implementacin
Redactar el documento
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.
105
Tabla 10.3. Descripcin del flujo de trabajo: Creacin de la(s) Base(s) de Datos Local(es)
Elaboracin o generacin del Para cada base de datos local: Scripts de creacin
script de creacin de cada o Codificar o generar el script de de la(s) base(s) de
base de datos local creacin de la BD, usando el datos locales
diseo fsico correspondiente
Creacin de la(s) base(s) de Procesar cada script en el Sistema de Base(s) de Datos

datos locales Gestin de Bases de Datos (DBMS) Locales
empleado localmente
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 Definir la estructura, medio y contenido del Manual de Uso
Uso Manual de Uso de la Aplicacin
Redactar el documento SIE
Elaboracin del Manual de Definir la estructura, medio y contenido del Manual de
Mantenimiento Manual de Mantenimiento Mantenimiento
Redactar el documento 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.
106
Mtodo MD-SIA
Normas, estndares y procedimientos <<objetivo>>
<<actor>>
de pruebas Asegurar que la
Lder de Aplicacin SIA cumple
Plan del Proyecto
Desarrollo de la con los requisitos
Planes V&V, SCM y SQA Aplicacin
<<persigue>>
<<regula>> <<controla>>
<<sistema>>
<<documento>>
Aplicacin SIA <<proceso>>
Ensamblada
Pruebas de la
<<documento>> Aplicacin <<sistema>>
Documento de
Aplicacin SIA
Implementacin
Probada
Plan de Pruebas

Grupos de Pruebas e BDC-SIA Modelo del Dominio
Implementacin
Otras Documentos de
Interesados aplicaciones SIA Requisitos y Diseo
Grupos SQA y SCM Documentacin de la
plataforma H/S: ArcGIS,
ORACLE, etc.
Figura 10.6. Diagrama general del proceso Pruebas de la Aplicacin
Modelo de productos de PA
3 * * * 3
Cronogramas de Especificaciones de Especificaciones Especificaciones de Resumen de

Pruebas: Diseo de Pruebas: de Casos de Procedimientos de Ejecucin de
Funcionales, No- Funcionales, No- Pruebas: Pruebas:Funcionale Pruebas:
funcionales y de funcionales y de Funcionales, No- s, No-funcionales y Funcionales, No-
Aceptacin Aceptacin funcionales y de de Aceptacin funcionales y de
Aceptacin Aceptacin
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

107
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 la
Aplicacin
<<proceso>> <<proceso>> <<proceso>>
Pruebas Pruebas No- Pruebas de

Funcionales Funcionales Aceptacin
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.
108
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 Elaboracin del Cronograma de Pruebas Cronograma de pruebas
(funcionales, no-funcionales (segn Plan de Pruebas)
de aceptacin)
Diseo de las pruebas

(funcionales, no-funcionales Definir los objetivos de las pruebas Especificaciones de
de aceptacin) diseo de pruebas
Identificar los tems de prueba
Especificaciones de casos
Identificar los aspectos que se van a probar de prueba
Seleccionar las estrategias y tcnicas de Especificaciones de
prueba procedimientos de prueba
Elaborar las especificaciones de diseo de

pruebas
Elaborar las especificaciones de casos de
prueba
Elaborar las especificaciones de
procedimientos de prueba
Actualizar Plan de Pruebas
Preparacin de las pruebas Mecanismos de prueba
(funcionales, no-funcionales Preparar mecanismos de pruebas (scripts,
Datos de prueba
de aceptacin) conductores, esqueletos, etc.)
Preparar los datos de prueba
Preparar el ambiente de pruebas
(herramientas, formatos, planillas, etc.)
Ejecucin de las pruebas Ejecutar cada una de las pruebas de acuerdo Reporte de fallas
(funcionales, no-funcionales al Plan de Pruebas y siguiendo las
de aceptacin) especificaciones de prueba
Reportar los errores encontrados
Correccin de errores (faltas y Aplicacin SIE probada

fallas) encontrados Corregir los errores detectados en cada una
de las pruebas funcionales, no funcionales o
de aceptacin
Realizar pruebas de regresin para asegurar

109
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
Mtodo MD-SIA
Normas, estndares y procedimientos
de pruebas e instalacin <<objetivo>>
<<actor>>
Plan del Proyecto Elaborar la Aplicacin SIA
Lder de de acuerdo al diseo
Planes V&V, SCM y SQA Desarrollo de la establecido
Plan de Capacitacin Aplicacin
<<regula>> <<controla>> <<persigue>>
<<sistema>>
<<documento>>
Aplicacin SIA <<proceso>> Informe final del
Probada Proyecto
Entrega de la
<<datos>> Aplicacin <<sistema>>
Datos para Aplicacin SIA

actualizacin de la Operativa
BD local

Grupos de BDC-SIA Modelo del Dominio
Implementacin y
Otras Documentos de
Pruebas
aplicaciones SIA Requisitos, Diseo,
Usuarios Implementacin y
Pruebas
Grupos SQA y SCM
Documentacin de la
plataforma H/S de
operacin
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.
110
Productos de la
Entrega de la Aplicacin
1 1
Informe Final Aplicacin SIA

del Proyecto Operativa
* * *
Programas Base(s) de Manuales de

Instalados en la Datos Local(es) Uso y
Plataforma de Actualizada(s) Mantenimiento
Operacin
Figura 10.10. Modelo de producto del proceso Entrega de la Aplicacin
Subprocesos del proceso EA
<<proceso>>
Entrega de la
Aplicacin
<<proceso>> <<proceso>> <<proceso>> <<proceso>> <<proceso>>
Capacitacin de Instalacin de la Actualizacin de Pruebas de la Entrega Formal

Usuarios Aplicacin la BD local Instalacin de la Aplicacin
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.

111
Capacitacin Entrega de la Aplicacin SIA
de Usuarios
Instalacin de la Pruebas de la Entrega Formal de

Aplicacin SIA Instalacin la Aplicacin SIA
Actualizacin de la(s)
BD(s) Local(es)
;
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 Definir los objetivos, necesidades y estrategias Plan de Capacitacin
Capacitacin de capacitacin
Establecer las actividades de capacitacin
Estimar los recursos requeridos
Elaborar el cronograma de actividades

Preparacin del material de Definir el formato, medio, estructura y Material de Capacitacin
capacitacin contenido del material de capacitacin
Elaborar el material de capacitacin
Organizacin y conduccin de Definir los objetivos, organizacin y estrategias
los talleres de capacitacin 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
112
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 Preparacin (seleccin, adquisicin Plataforma de Operacin de la Aplicacin
Plataforma de Operacin y/o instalacin) de los equipos SIE
(hardware) donde operar la
aplicacin
Instalacin del software operativo
sobre el cual se instalar la aplicacin
(sistema operativo, software GIS,
DBMS, etc.)
Instalacin de la Instalacin de la aplicacin SIE en la Aplicacin SIE instalada
aplicacin plataforma H/S de operacin
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 Determinar que datos iniciales debe(n) tener la(s) BD(s)
de inicio de 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 Datos iniciales
obtener los datos iniciales
Capturar, transcribir, editar, convertir y validar los 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.

113
Tabla 10.10. Descripcin del flujo de trabajo: Pruebas de la Aplicacin
Pruebas de ejecucin en la Disear las pruebas de ejecucin de la aplicacin en Especificaciones de
plataforma de operacin la plataforma de operacin pruebas
Ejecutar las pruebas de ejecucin Reporte de fallas
Depurar los errores encontrados durante las pruebas
de ejecucin
Pruebas del estado de Disear las pruebas del estado de la aplicacin en la Especificaciones de
la(s) BD(S) plataforma de operacin pruebas
Ejecutar las pruebas de ejecucin Reporte de fallas
del estado inicial de la(s) BD(s)
Pruebas de Integracin de Disear las pruebas de integracin de la aplicacin Especificaciones de
la Aplicacin SIE con la SIE con la BDC-SIE pruebas
BDC-SIE Ejecutar las pruebas de integracin Reporte de fallas
de integracin con la BDC-SIE
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 Transferir la responsabilidad de la operacin de la
a sus usuarios 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 Iniciar la operaciones de uso de la aplicacin SIE Aplicacin SIE
uso y mantenimiento de la Iniciar las operaciones de mantenimiento de la operativa
aplicacin SIE aplicacin SIE
Cierre del proyecto Evaluar el proyecto de desarrollo de la aplicacin Informe Final del
Elaborar el informe final del proyecto Proyecto
Presentar el informe al Comit Directivo de un SIE
Cerrar oficialmente el proyecto de desarrollo
114
Tcnicas y herramientas de implementacin
Proceso Tcnicas, estndares y prcticas Herramientas

Construccin Estndar de documentacin de pruebas IEEE- Software GIS (Suite ArcGIS)
& Integracin 829-1983 Gestor de bases de datos
Estrategias de pruebas de unidad: caja blanca y (ORACLE, MySQL, etc.)
caja negra) Ambientes integrados de
Estrategias de pruebas de integracin: pruebas desarrollo de software (IDE)
ascendentes, descendentes y combinadas Herramientas automatizadas
Plantillas para las especificaciones de pruebas para pruebas de software
Tcnicas de depuracin (debugging) Herramientas CASE (Visio
Tcnicas, formatos y plantillas de elaboracin de Profesional, Poseidon,
documentos tcnicos
Pruebas de Estndar de documentacin de pruebas IEEE- Ambientes integrados de

la Aplicacin 829-1983 desarrollo de software (IDE)
Estrategias de pruebas funcionales (caja negra), Herramientas automatizadas
pruebas no-funcionales (pruebas de interfaz, para pruebas de software
rendimiento, seguridad, etc.) Software GIS (Suite ArcGIS)
Plantillas para las especificaciones de pruebas Gestor de bases de datos
Tcnicas de depuracin (debugging) (ORACLE, MySQL, etc.)
Entrega de la Tcnicas de migracin de datos Software GIS (Suite ArcGIS)
Aplicacin Tcnicas de capacitacin: estrategias Gestor de bases de datos
instruccionales, dinmica de grupos (ORACLE, MySQL, etc.)
Tcnicas , formatos y plantillasde elaboracin de
informes tcnicos

115
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.
116
(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

117
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 Un conjunto organizado de datos, programas de computacin y

informtica (, documentacin que provee servicios de informacin a sus usuarios. Por
simplemente, servicios de informacin se entiende un conjunto de funciones
aplicacin) 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 Sistema empresarial para el cual una aplicacin informtica presta sus
Aplicacin servicios de informacin. Es el sistema ampliado, ambiente o contexto en el
cual una aplicacin opera.
Estructura Manera de organizar los equipos de trabajo de un SIE representada

organizativa mediante organigramas
Equipo de Conjunto de actores que participan directamente en el desarrollo de
desarrollo de aplicaciones de un SIE y que se organizan de acuerdo a una estructura
aplicaciones organizativa
Herramienta de Aplicacin sistema de software empleado para desarrollar software. Por
desarrollo de ejemplo, una herramienta CASE (Computer Aided Software Engineering)
software una herramienta grfica usada en la elaboracin de modelos de software.
Instanciacin del Proceso mediante el cual un equipo de desarrollo de aplicaciones aplica el

mtodo mtodo WATCH y lo adecua a las caractersticas propias de un proyecto y
aplicacin particular.
Interesado Actor, grupo de actores, unidad organizacional de la empresa usuario

(Stakeholder) 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
118
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 Conjunto de modelos que describen, en general, que deben hacer los
desarrollo de equipos de desarrollo para un elaborar una aplicacin informtica.
aplicaciones
Metodologa de Cuerpo de mtodos empleados por la Ingeniera de Software para producir,

desarrollo de mantener y operar software.
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 Componente del mtodo WATCH que describe los procesos gerenciales,
Procesos tcnicos y de soporte que deben seguir los equipos de desarrollo para
elaborar una aplicacin de un SIE.
Modelo de Componente del mtodo WATCH que describe, en trminos generales, los
Productos 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 Proceso que se realiza en una empresa (o sistema empresarial) con la

Negocio 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 Proceso tcnico, gerencial o de soporte que se ejecuta durante el desarrollo

desarrollo de

119
Concepto Definicin
software de una aplicacin informtica
Producto de Producto intermedio o final elaborado durante el desarrollo de una aplicacin

Software 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 Una empresa o un subsistema de ella. Es un sistema integrado por un

Empresarial conjunto de procesos de negocio que son ejecutados por los actores de la
empresa con la finalidad de alcanzar objetivos preestablecidos.
Sistema de Es un sistema que administra los datos alfanumricos y/o multimedia de una
Informacin empresa (o de una parte de ella), mediante el uso de tecnologas de
Empresarial 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 Es un tipo de sistemas de informacin empresarial que satisface las

Informacin necesidades de informacin de toda una empresa relacionadas con uno o
Corporativo ms procesos de negocio.
Sistema de Es un tipo de sistema de informacin empresarial que cubre las necesidades

Informacin de una ms unidades organizacionales de una empresa relacionadas,
Funcional generalmente, con un proceso de negocios particular.
Sistema de Es un tipo particular de sistema de informacin que procesa datos geo-

Informacin espaciales. Estos datos representan objetos geogrficos; es decir, aquellas
Geogrfica 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 ).
120
121

Desarrollo de Software Empresarial Jonas Montilva v0 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Desarrollo de Software Empresarial Jonas Montilva v0 PDF

Uploaded by

Copyright:

Available Formats

DESARROLLO DE SOFTWARE

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

DESARROLLO DE SOFTWARE EMPRESARIAL 3

Este documento describe el Mtodo de Desarrollo de Software Empresarial WATCH que

Sistemas de Informacin Empresarial (SIE)

Los Sistemas de Informacin Empresarial (SIE) son sistemas de informacin de alcance

Un SIE es definido como un sistema de informacin empresarial de tipo estratgico y de

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

DESARROLLO DE SOFTWARE EMPRESARIAL 5

2) Una plataforma infraestructura de operacin compuesta, generalmente, por un

3) Un conjunto de aplicaciones informticas orientadas a apoyar los procesos de negocio

Sistemas de informacin funcional.- Son sistemas de informacin de menor

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 de Mantenimiento de un SIE.- Son programas dedicados a facilitar la

4) El Personal Tcnico encargado de instalar, desarrollar y/o mantener los diferentes

Usuarios internos.- Son todos aquellos actores (personal de la empresa) que

Figura 1.1. Arquitectura general de un SIE

El Sistema de Informacin Empresarial(SIE) es visto o concebido como un sistema de

El propsito de un SIE es apoyar, a travs de la automatizacin y suministro de informacin, la

Estrategias de desarrollo de un SIE

1) Gestionar el desarrollo de un SIE como un proyecto corporativo.

DESARROLLO DE SOFTWARE EMPRESARIAL 7

3) Definir y aplicar un mtodo para el desarrollo de las aplicaciones que componen la

Para producir el conjunto de aplicaciones informticas que integran Un SIE es necesario

Caractersticas del mtodo WATCH

El mtodo WATCH est fundamentado en las mejores prcticas de la Ingeniera de Software y

En el diseo de este mtodo se emplearon, como marcos de referencia para la elaboracin

El cuerpo de conocimientos de la Ingeniera de Software (SWEBOK) de la

RUP: Rational Unified Process de IBM (Krutchen, 2000)

PMBOK: Project Management Body of Knowledge del Project Management

El mtodo WATCH est compuesto por tres modelos fundamentales:

2) Un modelo de actores que identifica a los actores interesados (stakeholders) en el

3) Un modelo de procesos que describe detalladamente los procesos tcnicos, gerenciales

Objetivos y estructura del documento

DESARROLLO DE SOFTWARE EMPRESARIAL 9

En este captulo, se describen las generalidades del mtodo de desarrollo de aplicaciones de

Objetivos del mtodo WATCH

WATCH es un mtodo de desarrollo de software que ha sido elaborado expresamente para

Garantizar la uniformidad, consistencia, facilidad de integracin y calidad de las distintas

Gestionar el desarrollo de las aplicaciones de un SIE como proyectos de ingeniera,

Asegurar que en el desarrollo de cada aplicacin de un SIE se empleen las mejores

Caractersticas del mtodo WATCH

2) Es estructurado y modular.- Posee una clara estructura que facilita su comprensin y

3) Es de propsito especfico.- El mtodo est dirigido al desarrollo de aplicaciones

4) Es flexible y adaptable.- Si bien el mtodo est dirigido al desarrollo de aplicaciones

Desarrollo de software iterativo e incremental.- WATCH considera el proceso de

Reutilizacin de activos de software.- El mtodo promueve la reutilizacin de

DESARROLLO DE SOFTWARE EMPRESARIAL 11

Modelado visual de la aplicacin.- Para desarrollar una aplicacin informtica es

Verificacin continua de la calidad de los productos.- WATCH asegura la calidad

Apropiada gestin de cambios.- Los cambios en los requisitos es una constante

6) Emplea las mejores prcticas y procesos de gestin de proyectos.- El mtodo

Estructura del mtodo WATCH

Figura 2.1. Componentes del

Figura 2.2. Principales tipos de productos del mtodo WATCH

Figura 2.3. Clasificacin de los actores

DESARROLLO DE SOFTWARE EMPRESARIAL 13

Figura 2.4. Procesos del mtodo WATCH