:

:6 ; < =

La primera pregunta que se tiene al hablar de una reciente metodología,

como la que se va a trabajar, es “¿Qué es específicamente el RUP?” El RUP
es ante todo una completa metodología para el desarrollo de proyectos de
software
proceso de ingeniería de software creado para llevar a las organizaciones
desarrolladoras de software a alcanzar sus objetivos críticos, como el
cumplimiento de requisitos dentro de un marco de tiempo y de presupuestos
establecido. Según la compañía Rational - IBM, creadores de esta metodología
al
igual que del lenguaje UML y de Rational Rose, el RUP es como un tutor en
que proporciona guías de trabajo, y ejemplos de todos los aspectos y
plantillas
etapas en el desarrollo de software.

3 OOP: Object-Oriented Programming / Programación Orientada por Objetos

19
 : ; < =

Las nuevas tendencias en la cultura organizacional han demostrado

bajo
ensayo-y-error lo importante que es para sus proyectos el tener un proceso de
desarrollo de software bien definido y documentado. Es claro que a través del
tiempo estas empresas, en sus esfuerzos por aumentar su organización en los
proyectos, y por ende, su calidad, han generado y almacenado grandes
cantidades de conocimiento para su uso y el de todos sus colaboradores. Pero a
medida que pasa el tiempo este conocimiento pasa de pequeños documentos
informales, textos informativos, y notas de pocos proyectos, a una enorme pila de
hojas y medios informáticos, almacenados en alguna oscura parte recogiendo
polvo a medida que el reloj sigue su recorrido. Pragmáticamente hablando, hay
pocas organizaciones que se toman el tiempo y el esfuerzo de recoger toda esta
cantidad de documentación y corregir los errores, actualizar lo obsoleto o
simplemente hacer seguimiento de lo ya hecho.
Otro es el caso de las organizaciones que apenas empiezan a incursionar
en el mundo de la ingeniería de software y en principio no tienen proceso alguno,
y necesitan de manera intensa un punto de partida para poder empezar por el
camino del desarrollo de software de calidad. El RUP es un esfuerzo
multidisciplinario para proveer a este tipo de organizaciones con un proceso
organizado, flexible y robusto de ingeniería de software.

20
 :

Se enumerarán a continuación algunas de las características que hacen

único al proceso RUP en el mercado actualmente.

: 6 * $!0! ) !"#$%! &# /!4%5( #

El RUP está basado en software. El RUP no es simplemente un libro o

una
especificación en documentos que una vez realizada pasó al olvido. El RUP fue
creado como un proyecto de software, cumpliendo todo su ciclo de diseño,
desarrollo, implementación y mantenimiento.

: "

Es de vital importancia saber que el RUP, siendo un proyecto de

software,
fue diseñado y documentado por el conocido lenguaje UML4 y tiene una base en el
modelo de procesos USPM5, ambos haciendo que el backbone del RUP sea fuerte,

: /(>.*.&(& >(?! @#>

Todo el proceso del RUP se encuentra disponible permanentemente en la

Web, dado que desde el principio, uno de los objetivos del RUP era que éste
estuviera disponible de manera fácil a todo el grupo de trabajo cuando fuera
necesario. Este enfoque Web lo diferencia de otras alternativas metodológicas
que

4UML: Unified Modeling Language / Lenguaje Unificado de

Modelamiento
5 USPM: Unified Software Process Model / Modelo de Procesos de

Software
Unificado
21
 : 8 !/.>.*.&(& &# -%#' ($.A-

El RUP es un modelo flexible y dinámico que permite la fácil integración

con la variedad de herramientas de diseño de software existentes. Asimismo, por
las mismas características, es posible integrar el modelo de RUP a nuevos
diseños y programas.

: 9 !&,*( .&(& " *#B.>.*.&(&

Por la naturaleza modular y electrónica del RUP, este puede ser

configurado y acomodado para que cumpla con las necesidades y objetivos de la
mayoría de organizaciones. He aquí otra característica funcional que lo hace
diferente de las otras metodologías tradicionales.

: : * #- #C!*,$.A-

Rational sabe que el RUP siempre estará en continuo proceso de

revisión,
por tanto realiza iteraciones en el proceso de ingeniería de software y como
resultado se comprometen en sacar al menos dos actualizaciones del modelo por
año6, de este modo todos los que interactúen con el modelo siempre tendrán la
versión más madura del mismo.

6The Rational Edge, Enero 2001. What is the Rational Unified

Process?
22
 :8

El RUP tiene dos dimensiones, como se observa en el gráfico presentado a

continuación.

Figura 1: Arquitectura del RUP

En la gráfica de la arquitectura del RUP se observan dos ejes o

dimensiones.

• El eje horizontal representa el tiempo, y muestra los aspectos del

ciclo de vida del proceso, a medida que ocurren. Esta dimensión
representa el aspecto dinámico y siempre cambiante del proceso. Se
expresa en términos de fases, iteraciones y metas.
• El eje vertical, a su vez representa las disciplinas, que agrupa
lógicamente a las actividades por su naturaleza. Esta dimensión
representa el aspecto estático del proceso, y cómo se expresa en
términos de componentes, disciplinas, actividades, flujos de trabajo,
artefactos y roles.

23
 :9

Figura 2: Fases del RUP – Gráfica Recursos vs. Tiempo

El ciclo de vida de un software que siga el proceso RUP está dividido en

cuatro fases, cada una de las cuales termina en una meta. Es decir, cada fase es
el tiempo que transcurre entre dos metas. Al final de cada fase, se efectúan
procesos de control y evaluación para determinar si los objetivos de la fase fueron
alcanzados.
A saber, las cuatro fases son Concepción, Elaboración, Construcción y
Transición. Es importante planear el esfuerzo y el tiempo para cada fase, que
generalmente siempre son diferentes. Existen plantillas para este fin.
Gráficamente, un ejemplo de la planeación de un proyecto de software podría
ser:

Un recorrido completo a través de todas las fases equivale a un ciclo de

desarrollo. Cada ciclo de desarrollo debe tener como resultado la generación de
software. Un producto podrá continuar con su siguiente generación, recorriendo
de nuevo un ciclo de desarrollo completo, a no ser que el producto haya
alcanzado ya sus fines y se considere “muerto”. Los siguientes ciclos de desarrollo
son llamados ciclos de evolución. Cada vez que se cumple un ciclo de evolución,
se puede decir que el software va adquiriendo mayor calidad, madurez y
robustez.

24
 A continuación se explicará brevemente cada una de las fases del
RUP:

:96 (/# &# !-$#)$.A-

Esta fase es la de más importancia para proyectos nuevos que

para
evolución de proyectos anteriores. En esta fase lo fundamental es establecer los
objetivos del proyecto y hacer que todas las entidades relacionadas con el
mismo
• Establecer el alcance del proyecto y sus posibles marcos de acción.
Se debe especificar claramente lo que va a ser el producto y lo que
no.
• Identificar los casos de uso críticos para el sistema.
• Analizar y exhibir al menos una arquitectura candidata para el
desarrollo del sistema.
• Estimar el cronograma y costo del proyecto en su totalidad.
• Estimar los riesgos potenciales.
• Preparar el entorno para la realización del proyecto.
La meta de esta fase es llamada “Objetivos del ciclo de vida” y básicamente
evalúa cada uno de los objetivos frente a las personas o entidades relacionadas
con la coordinación y administración del proyecto de software.

:9 (/# &# *(>! ($.A-

El principal objetivo de esta fase es tener un fundamento de la

arquitectura
del sistema para proveer una base estable para la mayor parte del diseño e
implementación en la fase de construcción. La estabilidad de la arquitectura es
evaluada a través de uno o más prototipos de las arquitecturas. Los puntos clave
a cumplir y evaluar en esta fase son:
• Asegurar que la arquitectura, requerimientos y planeación son lo
suficientemente estables, y los riesgos son evaluados de tal manera
que se pueda determinar el costo y cronograma de todo el proyecto.

25
 • Tener en cuenta todos los riesgos significativos de la arquitectura.
• Producir un prototipo evolutivo de los componentes de
producción.
• Demostrar que la arquitectura escogida soportará los
requerimientos del sistema, dentro de un plazo de tiempo y un costo
razonable.
• Establecer un entorno de soporte.
La meta de esta fase es llamada “Arquitectura del ciclo de vida” y
básicamente mide la estabilidad de la visión, los requerimientos y la arquitectura.

:9 (/# &# !-/% ,$$.A-

Retomando la metáfora de la empresa manufacturera vs. empresa

de
software, tenemos que el énfasis de esta fase está en administrar los recursos de
la producción y controlar las operaciones de planta para optimizar la calidad, los
costos y el itinerario. El objetivo principal es clarificar los requerimientos
pendientes y completar el desarrollo del sistema basado en la arquitectura
elegida. Al final de esta fase, se deberían tener los siguientes resultados:
• Minimizar los costos de desarrollo gracias a la optimización de
recursos.
• Lograr la mejor calidad como sea pragmáticamente posible.
• Llegar al desarrollo de versiones útiles (alfa, beta, etc.)
• Completar el análisis, diseño, desarrollo y pruebas de toda
la funcionalidad requerida.
• Desarrollar de manera iterativa un proyecto que está listo
para hacer la migración a la comunidad de usuarios.
• Decidir si el software, los sitios y los usuarios están listos para que
la aplicación sea liberada.
Igualmente, esta fase tiene su meta, denominada “Capacidad inicial de
operación”, la cual determina si el producto está listo para ser lanzado en un
entorno de pruebas beta.

26
 :98 (/# &# (-/.$.A-

La etapa final del ciclo de desarrollo de software se enfoca en que el

software esté listo y disponible para sus usuarios, con todos sus objetivos
claramente logrados. Esta fase puede necesitar de varias iteraciones para su
cumplimiento completo, por ejemplo, el afinamiento del software mediante
sugerencias y comentarios de los usuarios finales.
Los objetivos específicos de esta fase varían de proyecto a proyecto, pero
algunos de los más importantes, son:
• Realizar las pruebas beta para validar el nuevo sistema con las
expectativas de los usuarios.
• Realizar pruebas beta en paralelo con el antiguo sistema que va a
reemplazar.
• Tener bases de datos en operación.
• Entrenamiento de los usuarios y mantenedores.
• Asignar labores de ingeniería de soporte.
• Realizar y activar tareas de soporte de errores.
• Acordar con los auditores y miembros directivos del proyecto que el
desarrollo fue realizado satisfactoriamente y que sus
elementos
La meta de esta fase es el “Lanzamiento del producto” y en él se evalúa el
nivel de satisfacción de los usuarios, así como los gastos reales vs. los
gastos propuestos.

27
 ::
@

Figura 3: Ciclo de Ing. De SW en el RUP

En el RUP, se tiene un ciclo de ingeniería de software cuyo objetivo es

desarrollar o mejorar un proceso. Este proceso está organizado en
una
agrupación de disciplinas las cuales a su vez están definidas por flujogramas
de trabajo.

Una disciplina es una colección de actividades relacionadas con áreas

de
importancia similar dentro de un proyecto. La manera de agrupar en disciplinas,
es para facilitar el trabajo a quienes tienen fuertes raíces en el proceso
de desarrollo en cascada. Tenemos entonces las siguientes disciplinas:

28
 ::6 !&#*(&! &#* #'!$.!

Esta disciplina se lleva a cabo con el fin de entender la estructura y

dinámica de la organización en el cual se va a realizar el sistema. Se deben
entender igualmente los problemas en la organización e identificar el potencial de
mejoras. En esta etapa también se debe asegurar que los clientes,
desarrolladores y usuarios, compartan un entendimiento sobre la visión y
objetivos de la

:: #D,./.%!/

En esta disciplina se debe acordar con aquellos involucrados en la

gestión
del proyecto lo que el sistema hará, es decir, delimitar el alcance del proyecto.
Igualmente se debe proveer a los desarrolladores con un mejor entendimiento de
los requerimientos del sistema. Todo esto ayuda a establecer una base en el
presupuesto tanto de costo como de tiempo.

:: -E*././ " ./#F!

El propósito de la disciplina de análisis y diseño, es transformar

los
requerimientos en un diseño del futuro sistema, y así evolucionar hacia una
arquitectura robusta del mismo. También en esta disciplina se harán
labores para adaptar el diseño y que iguale el entorno de la aplicación,
específicamente

::8 0)*#0#-%($.A-

La implementación es la disciplina que se encarga del proceso de

construcción y elaboración de código. En ella se debe definir la organización del
código, e implantar los diferentes subsistemas en capas. Igualmente, se deben
implementar clases y objetos como componentes del sistema (código fuente,
29
binarios, etc.). Estos componentes se deben probar en esta disciplina como
unidades, y finalmente, se deberán integrar los resultados producidos por
diferentes individuos o equipos en un sistema completamente ejecutable. Es
importante diferenciar que las pruebas en esta disciplina son hechas a
las

::9 ,#>(/

Como su nombre lo indica, la disciplina de pruebas se encarga de

realizar
búsquedas y validaciones a los defectos en la calidad del software, junto con su
documentación apropiada. En esta disciplina se debe igualmente validar
que todos los objetivos hechos en las especificaciones y requerimientos sean
tangibles y estén completamente implementados, hecho mediante
demostración concreta del proyecto de software. Es importante contar con la
auditoría de los clientes

::: #/)*.#',#

Esta disciplina garantiza que el software esté disponible para los

usuarios
finales. Este despliegue puede darse de cualquier manera que sea adecuada al
entorno de la organización, tales como una instalación personalizada, o un
paquete de instalación (MSI7, RPM8, etc.) o que las personas puedan acceder
libremente a través de Internet. Es claro que esta disciplina tiene su cima
generalmente en la fase de transición.

7 MSI: Microsoft Installer Package / Paquete de instalación de Microsoft

8RPM: Redhat Package Manager / Administrador de paquetes de
Redhat
30
 ::G &0.-./% ($.A- &# $(0>.!/ " $!-4.', ($.A-

Según el CMM9 del SEI10, ésta disciplina controla los cambios y mantiene la
integridad de los artefactos de un proyecto. Para la administración de cambios y
configuración se debe tomar en cuenta cuales elementos serán eventualmente
sujetos a configuración y cambios, posteriormente se deberá restringir los
cambios solo a esos elementos, auditar los cambios realizados y finalmente
definir y administrar las configuraciónes de esos elementos. Esta disciplina es
esencial para controlar los numerosos artefactos resultantes de un proyecto y su
equipo de trabajo. Este control es sumamente útil para evitar la confusión y
futuros conflictos.

::H &0.-./% ($.A- &#* ) !"#$%!

Un intento del RUP para facilitar la tarea de administración y coordinación

del proyecto es esta disciplina. En ella, se da un marco de trabajo para
administrar proyectos de software mediante el lineamiento de planeación,
reclutamiento, ejecución y auditoría. El RUP se enfoca más que todo en la
administración y en el control de riesgo que en la administración de presupuesto
y personal.

::I -%! -!

El objetivo de esta disciplina son las actividades necesarias para

configurar
el proceso de desarrollo de un proyecto. Describe las actividades
necesarias requeridas para el soporte del proyecto. Esta
disciplina se encarga de proporcionar un entorno
que soporte a todo el proyecto, por tanto está

9 CMM: Capability Maturity Model

10 SEI: Software Engineering Institute
31
 :G

El Rational Unified Process tiene ciertos elementos básicos o conceptos

clave que es importante señalar. En la gráfica a continuación se muestra un
diagrama de flujo de dichos elementos.

Figura 4: Flujograma de elementos del RUP

Se hablará un poco más sobre los distintos elementos a

continuación.

32
 :G6 ./$.)*.-(/

Como se mencionaba anteriormente, una disciplina es una colección de

actividades relacionadas con áreas de importancia similar dentro de un
proyecto. La manera de agrupar en disciplinas, facilita el trabajo a quienes
tienen fuertes

:G !-$#)%!/

Son las definiciones clave de un proceso (tales como iteración, riesgo,

fases, etc.). Generalmente van junto con las disciplinas para su mejor
entendimiento.

:G !*#/

Es uno de los conceptos más importantes, y tal vez el más céntrico de todo
el proceso. Un rol define el comportamiento y responsabilidades de un individuo
o equipo de trabajo en un proyecto. Es importante distinguir que un rol no es un
individuo, más bien, describe cómo los individuos o personas deberían
comportarse en la organización, y sus responsabilidades. Es decir, dentro de un
proyecto es común que una sola persona desempeñe diferentes roles. Dentro del
RUP existen muchos tipos de rol predeterminados. Las macro categorías que
los
• Analistas
• Desarrolladores
• Probadores (o testers)
• Administradores
• Roles varios (ej. Escritor técnico, diseñador gráfico, administrador
del sistema, especialista de productos, etc.)

33
 :G8 $%.C.&(&#/

Una actividad es una unidad de trabajo definida que cierto individuo

que
realice un rol podría tener que hacer. Una actividad tiene un propósito claro,
generalmente expresado en generar o actualizar un artefacto. Mientras
específica sea una actividad, más óptimo es el resultado. Al igual que en
otros
elementos del
RUP, cada actividad debe tener un período de ingeniería, otro
ejecución y finalmente uno de evaluación. Ejemplos de actividades
predeterminadas son asignar prioridad a los casos de uso, describir distribución,
o documentar clases.
Cada actividad puede tener relacionada una guía de trabajo que presenta
las técnicas y diferentes pasos sugeridos para llevar a la ejecución cierta unidad
de trabajo.

:G9 %#4($%!/

Una actividad puede tener artefactos de entrada o de salida. Un artefacto

es el resultado del trabajo de un proceso: los roles usan los artefactos como
insumos para realizar actividades o como productos de su proceso. Los
artefactos son responsabilidad de un solo rol y dan la idea que cada pedazo de
información en el proceso es responsabilidad de solo una persona. Un artefacto
puede tomar diferentes formas, como por ejemplo un modelo (modelo de casos de
uso, modelo de diseño, modelo de análisis e implementación), un elemento del
modelo (caso de uso, clase de diseño), un documento (visión, lista de riesgos,
glosario, caso de negocio o documento de arquitectura del software), código
fuente o ejecutables (como componentes). Al igual que las actividades, los
artefactos tienen guías de trabajo que definen un derrotero para indicar cómo
desarrollar y evaluar los artefactos. Estas guías de trabajo tienen a su vez ciertos
puntos de control que permiten un mayor control y acercamiento a los objetivos
de los mismos. Para cada artefacto el RUP presenta plantillas para usar en
diferentes formatos (Word,

34
provee modelos para los reportes, puesto que algunos artefactos pueden tener
como salida alguno de ellos.

:G: *,?! &# % (>(?!

Un flujo de trabajo es una secuencia práctica de actividades que tienen

como fin algún resultado que puede ser medido u observado. En un flujograma
de trabajo se pueden observar de manera clara y gráfica las interacciones
entre
el UML, un diagrama de secuencias, o un diagrama de colaboración, o un
diagrama de actividades. Para estandarizar, el RUP usa el diagrama de
actividades para cada disciplina.

35
 :H 7

Figura 5: Mejores prácticas

Para profundizar el conocimiento y el marco teórico sobre el RUP, se tocará

un tema de mucha importancia en el mundo actual de la ingeniería de software.
El RUP ha demostrado que cumple con algunas de las llamadas “mejores
prácticas” en la industria de software, prácticas que con el tiempo y uso han
demostrado ser efectivas en cuanto ahorro de tiempo y dinero. Estas son:

:H6 #/( !**! %# (%.C!

Todos los proyectos tienen cierto riesgo involucrado. El enfoque tradicional

de cascada en el cual cada paso se ejecuta por completo antes de entrar en el
otro
conlleva a descubrir los riesgos solamente hasta muy entrado el ciclo de
desarrollo de software, tiempo en el cual arreglar los errores de diseño es un
proceso tedioso y costoso. Con el RUP, donde por definición se llega con un
proceso iterativo de desarrollo y con marcas de control en cada paso, es más fácil
mitigar estos riesgos y arreglarlos oportunamente.
36
 :H &0.-./% ($.A- &# #D,./.%!/

Administrar un requisito, o cualquier condición que el sistema

deba
cumplir es importante para organizar, documentar y corroborar las
especificaciones del sistema. Es de suma importancia para mantener un
acuerdo
entre los clientes y los gestores del proyecto. Pudiera parecer que este proceso es
simple, pero en realidad es más complejo de lo que parece. El RUP permite
mantener un establecimiento de requisitos de manera clara y concisa, junto con
atributos compartidos con otros artefactos del modelo.

:H %.*.3($.A- &# ( D,.%#$%, (/ )!

$!0)!-#-%#/

El RUP tiene la capacidad de usar componentes en su modelado. Un

componente es un grupo coherente de código con interfaces y comportamientos
bien definidos que proporcionan fuerte encapsulación de sus contenidos. La
principal ventaja de usar arquitectura por componentes es que tienden a reducir
el tamaño y complejidad de la solución, y por tanto ésta será más robusta y
madura.

:H8 !&#*(0.#-%! C./,(*

El uso de un modelo visual, tal como el UML, permite usar notaciones

de
diseño ricas y claras para capturar el diseño de software. El UML proporciona un
más alto nivel de abstracción sobre el problema, manteniendo la sintaxis y la
semántica. De esta manera, mejora la comunicación dentro del equipo de
desarrollo y presenta una manera de interpretación sin ambigüedades. Otras de
sus ventajas son el tener la posibilidad de comparar diferentes alternativas a bajo
costo, el formar una base para la implementación y finalmente, capturar los
requerimientos de manera precisa.
37
 :H9 !-% !* &# $(*.&(& )# 0(-#-%#

Dentro del RUP se controla constantemente la calidad. Ya sea al final de

una fase, o al terminar las actividades de una disciplina, o al finalizar un
artefacto. No importa el estado de maduración del proyecto, el RUP ordena
verificar constantemente su calidad. Esto se diferencia de otros modelos y
aproximaciones a la ingeniería de software que tienen en cuenta el control de
calidad solo hasta muy entrado el ciclo de vida del proyecto de software.

:H: &0.-./% ($.A- &# *!/ $(0>.!/

Es muy importante en cualquier proyecto de desarrollo de software el estar

en capacidad de manejar los cambios. En proyectos de corto alcance puede no
parecer tan necesario, pero en otros de mayor alcance, donde hay varios equipos
de desarrolladores trabajando de manera asincrónica, la necesidad puede parecer
apremiante. Sin un control establecido, el proyecto de desarrollo
fácilmente
una correcta administración y manejo de los cambios, diferentes versiones,
equipos de trabajo, iteraciones y lanzamientos en el proyecto.

38
 G

Siguiendo como patrón el RUP, tenemos que la unidad organizacional

primaria en el desarrollo de todo proyecto, es la segmentarización por
fases. Como se explicaba anteriormente, en cada una de las fases se deben
seguir ciertos requerimientos y actividades, y al final de cada una de ellas,
establecer una evaluación con el fín de saber si los requerimientos de cada fase
fueron alcanzados. Así pues, iniciemos la exploración dentro de cada una de las
fases del

G6

Siendo este proyecto uno nuevo, es claro que se le debe hacer especial
énfasis a esta fase. Inicialmente, y con el fin de entender la estructura y la
dinámica de la organización en la que se va a trabajar en el futuro, se decidió
hacer el modelado del negocio como primer paso.

G66 !&#*(&! &#* #'!$.!

Con el fin de compartir una visión holística del negocio y de sus procesos
con los clientes, el primer paso en la fase inicial del ciclo de ingeniería de
software sugerido por el RUP fue este.

39
 Figura 6: Modelamiento del Negocio

Observamos que dentro del segmento del negocio que se va a trabajar,

existen dos procesos principales, Vender Productos en Línea y Gestionar
Pedidos, los cuales usan diferentes módulos. Dentro del primero, Vender
Productos en Línea, se observa que su objetivo es tomar los pedidos del cliente,
y como resultado, genera un pedido u órden. Usa los módulos de administración
y pedido, y como entrada, el inventario en bodega y el módulo de catálogo. Este
proceso es claramente el más importante dentro del proceso a mejorar, y
gracias

40
 G6 *$(-$#J $ !-!' (0( " 0( $! &# ($$.A-

Para el RUP (al igual que la mayoría de procesos organizados),

determinar
el alcance y el marco de acción de un proyecto es un paso vital y es
imprescindible tenerlo en cuenta con el fin de realizar un proceso maduro y
confiable con visión acertada a futuro. Por ello, se realizó el alcance del proyecto
dentro de unos márgenes temporales y materiales. Toda la información de esta
actividad, fue plasmada en los numerales 2, 3 y 4 del presente proyecto de grado.
Además, en un anexo está el llamado documento de Plan de Iteraciones, en el
cual se verá de manera detallada y granular la planeación de recursos del
proyecto.

G6 #D,./.%!/ " $(/!/ &# ,/! $ +%.$!/

Es importante en esta primera fase, identificar los requisitos y casos de

uso críticos para tener un entendimiento macro del sistema. Básicamente estos
serían los requisitos y casos de uso más básicos y globales que se pudieran tener
a un nivel alto.

Figura 7: Requisitos
Críticos
Tenemos como requisito funcional global «realizar una aplicación
web
interactiva que les permita a los clientes web de la compañía revisar el catálogo
completo a través de Internet, navegar por los productos, conocer los detalles y
especificaciones completas de los mismos, agregar estos productos a una orden, y
realizar el pedido cuando la orden esté completa. El sistema deberá enviar un
41
formato de XML para el departamento de pedidos, para que el pedido
realizado
sea actualizado correctamente en la base de datos de la empresa.»
Se logran identificar en principio tres grandes requisitos: Implementar
seguridad, hacer pedidos en línea y administrar el sistema. Para Implementar
Seguridad, tenemos que «el sistema deberá contar con un esquema de seguridad
que permita sesiones de usuarios recurrentes y la validación de cada usuario
mediante un esquema de nombre de usuario/contraseña».
En el requisito Hacer pedidos en línea, se tiene que «el usuario deberá
poder ver y navegar por el catálogo de productos de la empresa. Igualmente,
deberá ver y administrar su pedido (agregar productos, eliminar, etc.) y
finalmente podrá hacer su pedido a la compañía».
Por último, en Administrar el Sistema, se enuncia que «el sistema podrá ser
administrado por un usuario de tipo administrador, el cual podrá administrar
usuarios, productos, líneas, y pedidos».
Teniendo ya los requisitos críticos a nivel global, se puede crear una idea
más clara sobre el desarrollo de software en el proyecto que se pretende llevar a
cabo, y sirve como punto de partida hacia un modelo de casos de uso más
detallado junto con sus respectivos requisitos. También con estos requisitos, se
puede sacar al menos una arquitectura candidata para el desarrollo del
sistema,

G68 D,.%#$%, ( $(-&.&(%( .-.$.(* )( ( #*

&#/( !**! &#* /./%#0(

Para empezar con el desarrollo del sistema, se debe tener una idea sobre
la
arquitectura a utilizar. Una primera aproximación a la arquitectura sería
utilizando el modelo de dos capas, una para servidor de aplicaciones que maneje
la lógica del negocio y presentación, y otra para el servidor de bases de datos. Se
usaría GNU/Linux como sistema operativo para ambos servidores, mySQL como
manejador de bases de datos, Apache como servidor web y PHP como lenguaje de
programación. Se realizó un diagrama de distribución donde se
enumerará

42
 Figura 8: Arquitectura inicial con GNU/Linux

G69 -%! -! &#* ) !$#/! &# -'#-.# +( &#

!4%5( #

En la etapa inicial es muy importante saber igualmente cuál es el entorno

en el cual todo el proceso de ingeniería de software estará soportado. Como el
RUP está fuertemente basado en UML, existen varias alternativas en el mercado,
siendo las dos más reconocidas la Rational Rose Enterprise v200211, de IBM, y
Enterprise Architect Professional Edition 3.5112, de Sparx Systems.

11 Rational Rose Enterprise: http://www.rational.com/rose /

12Enterprise Architect Proffessional:
http://www.sparxsyste ms.com.au/
43
 ¿Por qué es importante escoger una herramienta CASE para modelar el
UML? «A medida que los sistemas se construyen hoy en día son más y más
complejos, las herramientas CASE para UML ofrecen muchos beneficios para
aquellos involucrados con un proyecto. Las herramientas CASE nos permiten
aplicar la metodología formal orientada a objetos y abstraerla del código a
un nivel donde el diseño y la arquitectura sean más fáciles de entender y
modificar. (…) El modelo actúa como un plano y guiará finalmente la
construcción del sistema»13. Es importante también hacer uso de una
arquitectura que proporcione un correcto entorno para el proyecto, para la
debida administración del proyecto y la elaboración del mismo con menor
complejidad.
Existen varios factores a evaluar en la elección de una herramienta CASE
rendimiento, facilidad de manejo, soporte a través del proyecto, de
capacidad
rendir informes y documentación, entre otros.
Estos factores varían de proyecto a proyecto, y acá evaluaremos su
rendimiento y acoplamiento con el proyecto en cuestión.
Característica Rose EA
Soporte de UML 1.4 Sí Sí
Soporte y posibilidades de expansión Excelente Normal
Diagramas de análisis y diseño Todos, con Todos
asistentes
Soporte para la creación automatizada de Muy completa (a Normal (C++,
código excepción de VB, Java y C#)
.NET)
Estimación No Sí
Riesgos No Sí
Reportes Limitado Muy completos
Concurrencia Sí Sí
Ingeniería de Requisitos Con software de Sí
terceros
Documentación para Pruebas Limitado Sí

13Dr. Jie Zhao, Comparison of UML Modelling Tools,

2002.
44
Facilidad de manejo Fácil Muy fácil
Precio U$5024.oo U$144.oo

Tabla 1: Comparación entre Rational Rose y Enterprise Architect

En la Tabla 1, se resaltan las características en las que cada paquete

se
ajusta más a las necesidades del proyecto. Como podemos ver, ambos paquetes
CASE tienen soporte para UML completo, de manera que cualquiera de los dos
sería una herramienta útil para el modelado. Con respecto a los diagramas, Rose
se lleva la delantera dado que además de presentar la posibilidad de
crear diagramas como el Enterprise Architect, proporciona asistentes
automáticos que hacen la tarea más fácil. Rose también se lleva la delantera al
Architect en la creación automatizada de código, puesto que genera código
mediante plantillas ya incluídas para muchos más lenguajes de programación
que su contendor, a excepción de .NET. Rose, junto con Architect, soportan
manejo de sesiones concurrentes, importante en el desarrollo del proyecto
para que el equipo completo pueda trabajar simultáneamente.
Rational Rose cuenta con el soporte de la corporación IBM, y está dentro
de una completa suite de productos especializados en ingeniería de software, por
tanto se puede integrar con otros programas adicionales para aumentar la
capacidad. Enterprise Architect, es producto de una compañía relativamente
nueva y poco conocida, especializada en su producto.
Enterprise Architect proporciona de por sí una amplia funcionalidad en
cuanto a manejo de requisitos se refiere. Rose, por su parte, no proporciona
soporte nativo para esta funcionalidad y requiere de otro paquete de la suite de
Rational para tenerlo.
En la parte de administración y gestión del proyecto, Enterprise Architect
toma la delantera puesto que contiene soporte nativo para el proceso de
estimación, mediante técnicas de UCP14. Rose no proporciona métodos de
estimación nativos. También el Architect se lleva el podio en cuanto a gestión de
riesgos, aunque no sea tan impresionante esta funcionalidad, está presente
de

14
UCP: Use Case Points, o Puntos de Casos de
Uso
45
 Enterprise Architect de nuevo se lleva el premio en el aspecto
de
documentación. Aunque ambos soportan la web, el Enterprise Architect
proporciona un módulo completo de documentación, flexible y con una impecable
salida en varios formatos de documentación y gráficas. El Rose por otra parte,
necesita de SoDa para tener documentación. Igualmente, el Architect proporciona
soporte nativo para el manejo de pruebas, mientras que el Rose necesita de
software adicional para lograrlo.
En cuanto a precio, el Enterprise Architect se lleva con creces el mejor
puesto. Sus U$149 representan apenas una pequeña fracción del cuantioso
precio del Rational Rose, que se vende a un precio de aproximadamente U$5,000.
Concluyendo, optamos por elegir al Enterprise Architect, de Sparx
Systems, puesto que es una completa herramienta para el modelado en UML y
que soporta al proyecto durante todo su ciclo. Además, soporta funcionalidades
muy importantes para el proyecto en curso, como son estimación, ingeniería de
requisitos y gestión de riesgos. Proporciona además muy buenas capacidades de
documentación, facilidad de manejo y aunque el Rose pueda expandirse y
complementarse con más software adicional, el Enterprise Architect es lo
apropiado para nuestro proyecto. Y, su relación precio – beneficio es mucho
mejor

G6: *(- &# %# ($.!-#/

Con el fin de planear, administrar y gestionar los procesos que llevarán al

desarrollo y terminación del proyecto, es importante contar con un Plan de
Iteraciones detallado. Dicho plan, es un conjunto de actividades y tareas con
recursos asignados, que son necesarias para realizar cada iteración. En el Anexo
G del presente documento, se encontrará el documento de Plan de Iteraciones.

46
 G6G #/%.A- &# .#/'!/

«Los riesgos son elementos que implican incertidumbre y pérdida, y están

presentes en todos los proyectos de Ingeniería de Software»15. Estos involucran
modificaciones tanto en las decisiones como en las acciones, y es importante
identificarlos a su gran mayoría y clasificar los más importantes con el fin de
tratar de minimizarlos y elaborar estrategias proactivas y planes de contingencia
reactivos para ellos.
Así pues, se creó una lista de comprobación de riesgos en la Tabla 2 con
aquellos que se juzgaron de mayor consideración, tomando como base la lista de
riesgos de software de la Universidad de Guadalajara, con sus
diferentes
el más crítico, se categorizaron los riesgos. Igualmente, se tomó en cuenta la
probabilidad que determinado riesgo ocurriera.

Riesgo Peso (W) P(r) %.

Riesgos por Tamaño
Inseguridad en la estimación del tamaño 3 70
Tamaño en número de programas, archivos y 3 40
transacciones calculado erróneamente.
Tamaño de la Base de Datos creada o usada por 2 30
el SW insuficiente.
Número de usuarios del SW superiores. 4 50
Cambios imprevistos a los requisitos 4 50
Poca reutilización del SW 2 70
Riesgos por Impacto en el Negocio
Incidencia sobre el ingreso de la compañía 3 40
Fecha de entrega insuficiente 4 70
Sistemas interoperables con el SW creado 1 10

15Curso de Ingeniería de Software (Universidad de Guadalajara): Módulos 10 y

11,
Gestión de Riesgos
47
 Usuario final incompetente para usar el SW 4 70
Cantidad y calidad de la documentación 4 60
insuficiente
Limitaciones gubernamentales en la creación 1 20
del SW
Retraso posible con sobrecostos para la 2 40
empresa
Defectos posibles con sobrecostos para la 3 50
empresa
Riesgos por el Cliente
No ha trabajado con el cliente anteriormente 2 70
El cliente no tiene la suficiente idea formal de 3 60
lo que quiere
El cliente no participa en reuniones formales 4 80
para definir el ámbito del SW
El cliente no establece una comunicación 4 70
fluida con el desarrollador
El cliente no participa en las revisiones 5 60
Es muy sofisticado técnicamente el área del 3 50
producto
El cliente no está dispuesto a “dejar hacer” el 4 30
trabajo al desarrollador
El cliente no entiende el proceso del SW 2 20
Riesgos por el Proceso
No hay claridad sobre el proceso de SW en la 2 30
organización desarrolladora
No tiene madurez sobre el desarrollo de SW 3 20
No está capacitada en procesos de SW 4 10
No se hacen RTFs documentadas 2 30
No hay métodos específicos para el análisis del 4 20
SW
No hay un método específico para el diseño de 3 40
datos y arquitectónico

48
 No se han definido y empleado reglas 3 30
específicas para la documentación del código
No se emplean métodos específicos para el 3 70
diseño de casos de prueba
No se emplean herramientas CASE en 4 20
diferentes etapas del proyecto
No se emplean métricas de calidad y 4 30
productividad en el proyecto
Riesgos por la Tecnología
Es muy nueva para su organización la 3 40
tecnología a construir
Los requisitos demandan nuevos métodos de 4 40
análisis, diseño o pruebas
Riesgos por el Entorno de Desarrollo
No se cuenta con una herramienta de gestión 3 20
de proyectos de SW
No existen herramientas de análisis y diseño 4 10
adecuadas para el SW a crear
No hay disponibles compiladores o 2 40
generadores de código apropiados para el SW
a crear.
No existen herramientas de pruebas 4 60
adecuadas para el SW a crear
No existen expertos disponibles para aclarar 4 20
dudas sobre las herramientas
No es adecuada la ayuda en línea de esas 4 10
herramientas
Riesgos por el Personal
No disponemos de la mejor gente 2 30
El personal no tiene todos los conocimientos 4 50
adecuados
No se ha asignado el personal para toda la 4 30
duración del proyecto

49
 Tabla 2: Lista de riesgos en el proyecto

Se tiene entonces un completo compendio sobre los riesgos en el actual

proyecto. Ahora determinamos cuáles son los riesgos más importantes que se
deben tener en consideración, puesto que es muy dispendioso en recursos tanto
de tiempo como de dinero hacer estudios y planes de RSGR (Reducción,
Supervisión y Gestión de Riesgos) a cada uno de ellos.
Para saber cuáles son los riesgos más importantes, definimos la
siguiente función:
Si W * P(r ) ≥ 2.8 ¡Es un riesgo importante!

En la tabla, se resaltaron los riesgos más importantes, que a saber,

son:

El cliente no participa en reuniones formales para definir el ámbito

del
software
El cliente no participa en las revisiones
Fecha de entrega insuficiente
Usuario final incompetente para usar el software
El cliente no establece una comunicación fluida con el desarrollador

Se observa que los riesgos más importantes tienen que ver con las
categorías de Riesgos por el Cliente y Riesgos por el Impacto en el Negocio. Con
estos riesgos ya identificados, el paso a seguir sería realizar un plan con el fín de
evitar que ocurran tales riesgos o de mitigar el impacto de los mismos en el
proyecto. Si se quisiera evaluar más profundamente el tema de los riesgos, se
pudiera plantear la ejecución de una matriz costo – beneficio, con el fin de saber
si se justifica hacer planes RSGR.
A grandes rasgos, en nuestro caso se identificó que los principales
problemas pueden surgir por la falta de comunicación con el cliente, el tiempo, y
la capacidad del usuario final. Como estrategias se podrían sugerir:
Mejorar la comunicación con el cliente

50
 Conscientizar al cliente de la importancia de su actuación activa dentro
del proceso de desarrollo de software y los inconvenientes que surgirían
por la falta de su apoyo.
Realizar un nuevo cronograma con mejores técnicas de estimación, o
contratar más personal capacitado.
Generar manuales más didácticos e informativos, y realizar talleres de
capacitación más extensos a los usuarios finales.
Crear ayuda interactiva en el software con el fín de hacerlo más
amigable al usuario.

Como vemos, la gestión de riesgos es una herramienta sumamente útil y

con resultados contundentes a la hora de realizar un proyecto de desarrollo de
software. Es claro que el tiempo invertido en la gestión de riesgos, genera como
resultados la identificación, mitigación y hasta posible erradicación de los riesgos
potenciales que como resultado, traerían una pérdida sumamente mayor de
dinero, tiempo y good will al desarrollador.

51
 G

El objetivo en esta fase es tener establecida una arquitectura del sistema

con los requisitos establecidos para proveer una fase estable y continuar con el
análisis, diseño y construcción del proyecto. En esta fase se debe terminar y
refinar el proceso de ingeniería de requisitos, y se empieza la labor de análisis y
diseño.

G 6 -'#-.# +( &# #D,./.%!/

En esta fase, los requisitos deben estar lo más depurados posible y

completos. Estos, deben ser unidos a los casos de uso y junto a estos últimos
formarán el punto de contacto y aceptación entre el equipo desarrollador y el
usuario final. Al terminarlos, se genera el “Documento de especificación de
requisitos”, el cual está en el Anexo F del presente documento.

Gracias a dicho documento, se logró tener una mejor visión y comprensión

de lo que es necesario para realizar el sistema, así como también se
pudo enmarcar y limitar de manera clara el sistema y proveer una base para
estimar el costo y factores técnicos de futuras iteraciones, que serán
incorporadas en el

52
 G !&#*! &# (/!/ &# /!

Según el RUP, el modelo de casos de uso debe estar al menos completo en

un 80% al terminar esta fase, con todos los casos de uso y actores identificados,
junto con la mayoría de descripciónes de los mismos casos de uso. En el Anexo D
del presente documento, se encontrará el modelo completo de los casos de uso, al
igual que en el archivo de Enterprise Architect, adjunto en los medios ópticos.

La Tabla 3 enuncia los casos de manera

abreviada:

Número Caso de Uso Categoría

1.1. Autorizarse en el sistema (login) Esencial
1.2. Cambiar clave Deseable
1.3. Recuperar clave Esencial
1.4. Registrarse en el sistema Esencial
2.1. Agregar Elementos al Pedido Esencial
2.2. Calcular Precio del Pedido Esencial
2.3. Cambiar Cantidades del Pedido Esencial
2.4. Efectuar Pedido Esencial
2.5. Eliminar Elementos del Pedido Esencial
2.6. Ingresar datos del Pedido Esencial
2.7. Mostrar Resumen del Pedido Deseable
2.8. Ver Detalles Producto Deseable
2.9. Ver Pedido Esencial
3.1. Agregar Categoría Esencial
3.2. Agregar Producto Esencial
3.3. Agregar Usuario Esencial
3.4. Eliminar Categoría Esencial
3.5. Eliminar Producto Esencial
3.6. Modificar Categoría Esencial

53
Número Caso de Uso Categoría
3.7. Modificar Producto Esencial
3.8. Modificar Usuario Esencial
3.9. Ver Pedidos Esencial

Tabla 3: Lista de Casos de uso

54
 G !&#*! &# (%!/

El modelo de datos se encarga de describir las representaciones físicas y

lógicas de los datos persistentes usados por la aplicación, es decir, las
relaciones, estructura, eventos y procedimientos de las bases de datos y sus
respectivos
representación. Para ver el modelo completo, favor remitirse al Anexo E del
presente documento.

Figura 9: Modelo Entidad - Relación

55
 G 8 .(' (0( &# *(/#/

El modelo de datos y el diagrama de clases van fuertemente relacionados el

uno con el otro. Dado que en la creación de uno, inherentemente sale el otro. Por
tanto, se observan las diferentes clases y las relaciones con sus respectivas
tablas.

Figura 10: Diagrama de Clases

*(/# (%#'! +(
Tipo: public Class
Estado Propuesto.Versión 1.0.Fase 1.0.
:
56
 Paquete: Diagrama de Clases
Detalles Creado el 14/08/2003. Modificado el
: 03/09/2003.
Clase para manejar las
categorías
Trazabilidad
Enlace de asociación desde la clase
Categoría
Enlace de asociación desde la clase Producto
Categoría -
Atributos
Atributo Tipo Notas
código private: int
nombre private: string
descripción private: string
categoríaPadre private: int

Tabla 4: Clase Categoría - Atributos

Método Tipo Notas

agregar () Public: void
eliminar (int) Public: void param: códigoProducto [ int - in ]

Editar (int) Public: void param: códigoProducto [ int - in ]

Listar () public: void

Tabla 5: Clase Categoría - Métodos

*(/# !-4.', ($.A-

Tipo: public Class
Estado: Propuesto.Versión 1.0.Fase 1.0.
Paquete: Diagrama de Clases
Detalles Creado el 14/08/2003. Modificado el
15/10/2003.
Maneja todas las variables y procesos de la
configuración
Trazabilidad
Enlace de asociación a la clase Pedido
Enlace de asociación a la clase
Usuario
57
Atributo Tipo Notas
hostBD private: string
usuarioBD private: string
passwordBD private: string
directorioPágina private: string
directorioPlantillas private: string
directorioImagenes private: string

Tabla 6: Clase Configuración - Atributos

*(/# &#-K !0) (

Tipo: public Class
Estado: Propuesto.Versión 1.0.Fase 1.0.
Paquete: Diagrama de Clases
Detalles Creado el 14/08/2003. Modificado el
03/09/2003.
Tiene incluida toda la funcionalidad de las ordenes de compra
realizadas.
Trazabilidad
Enlace de asociación desde la clase
Producto
Enlace de asociación desde la clase Usuario
Atributo Tipo Notas
código private: int
compradoPor private: string
fecha private: date
comentarios private: string
estado private: int
total private: int

Tabla 7: Clase Orden_Compra - Atributos

- Método Tipo Notas

detalles (int) public: void param: códigoOrden [ int - in ]

listar () public: void

Tabla 8: Clase Orden_Compra - Métodos

58
 *(/# #&.&!

Tipo: public Class

Estado: Propuesto.Versión 1.0.Fase 1.0.
Paquete: Diagrama de Clases
Detalles Creado el 14/08/2003. Modificado el
: 15/10/2003.
Toda la funcionalidad del pedido, es decir, de la canasta de
compras.
Trazabilidad
Enlace de asociación a la clase Producto
Enlace de asociación desde la clase
Configuración
Atributo Tipo Notas
elementos private: array
total private: int

Tabla 9: Clase Pedido - Atributos

Método Tipo Notas

agregar (int, int) public: void param: cantidad [ int - in ]
param: códigoProducto [ int - in ]

cantidad (int, int) public: void param: cantidad [ int - in ]

param: códigoProducto [ int - in ]

eliminar (int) public: void param: códigoProducto [ int - in ]

limpiar () public: void

contar () public: void
recalcular () public: void
ver () public: void
completarPedido () public: void
hacerPedido () public: void

Tabla 10: Clase Pedido - Métodos

59
 *(/# !&,$%!
Tipo: public Class
Estado: Propuesto.Versión 1.0.Fase 1.0.
Paquete: Diagrama de Clases
Detalles Creado el 14/08/2003. Modificado el
15/10/2003.
Clase para manejar los productos.
Trazabilidad
Enlace de asociación a la clase Categoría
Enlace de asociación a la clase
Orden_Compra
Enlace de asociación desde la clase Pedido
Atributo Tipo Notas
código private: int
nombre private: string
descripción private: string
precio private: int
especial private: int
palabrasClave private: string
foto private: string

Tabla 11: Clase Producto - Atributos

Método Tipo Notas

agregar () public: void
eliminar (int) public: void param: códigoProducto [ int - in ]

editar (int) public: void param: códigoProducto [ int - in ]

listar () public: void

ver () public: void

Tabla 12: Clase Producto - Métodos

*(/# /,( .!
Tipo: public Class
Estado: Propuesto.Versión 1.0.Fase 1.0.

60
 Paquete: Diagrama de Clases
Detalles Creado el 14/08/2003. Modificado el
: 15/10/2003.
Clase para manejar las
categorías
Trazabilidad
Enlace de asociación a la clase Orden_Compra
Enlace de asociación desde la clase
Configuración
Atributo Tipo Notas
username private: string
nombre private: string
apellido private: string
email private: string
teléfono private: string
dirección private: string
privilegios private: int

Tabla 13: Clase Usuario - Atributos

Método Tipo Notas

agregar () public: void
eliminar (string) public: void param: username [ string - in ]

Editar (string) public: void param: username [ string - in ]

listar () public: void

reinicializarClave public: void param: username [ string - in ]
(string)
registrar () public: void
cambiarClave () public: void param: username [ string - in ]
verificarPrivilegios () public: param: username [ string - in ]
boolean

Tabla 14: Clase Usuario - Métodos

61
 G 9 /%.0($.A- " 02% .$(/

Determinar o predecir con gran precisión el tamaño y duración de un

proyecto de ingeniería de software puede significar en una gran reducción de
incertidumbre en la etapa inicial de planeación, llevando así a mantener unas
cifras económicas y de tiempo precisas, permitiéndole a la gerencia del proyecto
no incurrir en sobrecostos y mantenerse dentro de un cronograma.
Hay varias alternativas en cuanto a la estimación, según Roger Pressman:
«Para realizar estimaciones seguras de costos y esfuerzos, se tienen
las siguientes alternativas:
• Dejar la estimación para más adelante, obviamente se puede
realizar
una estimación al cien por cien fiable después de haber terminado
el proyecto.
•
Basar las estimaciones en proyectos similares ya terminados.
•
Utilizar técnicas de descomposición relativamente sencillas
para generar las estimaciones de costos y esfuerzo del proyecto.
•
Desarrollar un modelo empírico para el cálculo de costos y
esfuerzos
En nuestro caso, las primeras dos alternativas quedan descartadas,
puesto
que uno de los objetivos del presente trabajo de investigación es la estimación
temprana y precisa, no se puede dejar para etapas más avanzadas la tarea de la
estimación. Tampoco ha habido proyectos similares ya terminados en los
cuales se pueda basar una estimación precisa. Por tanto, quedamos con las
alternativas de desarrollar un modelo empírico de estimación, o utilizar técnicas
de descomposición funcional sencillas.
Se decidió hacer uso de técnicas de estimación basadas en descomposición
funcional sencilla, quedando como candidatos más viables para la elección:
• COCOMO (Estimación por PF17 o SLOCs18)
• Estimación por UCP (Puntos de Casos de
Uso)

16PRESMAN, Roger L. Ingeniería del Software: Un enfoque

práctico
17 PF: Puntos de Función
18 SLOCs (Source Lines Of Code): Líneas de código fuente
 Se eligió la estimación por UCP puesto que en el presente proyecto los
casos de uso son uno de los pilares básicos y el medio de comunicación principal
entre el cliente y la gerencia del proyecto. Además, a diferencia de COCOMO, usar
el método de UCP permite realizar una estimación confiable en las primeras
etapas del proyecto, solamente haciendo uso de los casos de uso, sin entrar a
profundizar en la construcción y elaboración del proyecto, como lo necesita la
estimación por SLOCs o PF.
Estimar por UCP trae muchas ventajas. Además de la ya mencionada de la
capacidad para una estimación temprana, este método toma en cuenta los
factores de complejidad técnica y de complejidad del entorno del proyecto, para
computar de manera realista la duración del proyecto.
¿Cómo funciona? Resumiendo, a cada caso de uso y a cada actor se le
asigna determinada complejidad. Luego, se le asigna un peso o valor en una
escala a los diferentes componentes de la complejidad tanto técnica como del
entorno, para obtener los diferentes factores independientes en la ecuación.
Luego, mediante una prueba piloto en algún caso de uso o por la experiencia
previa, se obtiene el número total de horas por UCP único. Finalmente, en una
ecuación se calcula el número total de horas de desarrollo del proyecto.
De tal manera, que los datos de entrada para nuestra estimación, son:
• Horas por UCP único
• Modelo de Casos de Uso, con su complejidad determinada (tanto
para casos como para actores)
• Peso en la escala de factores de complejidad técnica
• Peso en la escala de factores de complejidad del entorno

Para la obtención del cálculo de Horas por UCP, se realizó una prueba
piloto en el desarrollo de un solo módulo del proyecto, en nuestro caso, el de
administración y se tomaron las métricas de tiempo, así como el resultado de los
UCP de dicho módulo. Partiendo de la ecuación básica de cálculo de las horas
totales de un proyecto, tenemos que:
HorasTotales
HorasTotales = UCP * HorasPorUCP = HorasPorUCP
UC
P

63
 Por tanto, en el módulo de administración que tardó cerca de 100 horas en
completar (HorasTotales), con un valor de UCP de 32, se tiene:
100
HorasPorUCP = ≈ 3.0
32
Entonces, es claro que el valor de HorasPorUCP en nuestro proyecto, es de
3.0, lo cual va a proporcionar una entrada muy precisa a la ecuación de cálculo
de la estimación por UCP, y servirá en proyectos futuros que tengan un modelado
de casos de uso a un nivel similar. En este caso, el modelado por casos de uso se
llevó a un nivel explícito y granular, casi al de funciones CRUD (Crear,
Recuperar, Actualizar y Eliminar).
Observemos la manera como se calculó la estimación para el proyecto
en
cuestión:

Ítem Valor
Fecha de Estimación 15-Ago-2003
Numero de Casos de Uso 22
Puntos de Casos de Uso Unicos (UUCP) 125.00
Complejidad Tecnica (TCF) 0.92
Complejidad del Entorno (ECF) 0.71
Puntos de Casos de Uso (UUCP * TCF * ECF) = UCP 81.00
Horas por UUCP (HRS) 3.00
Horas Totales (HRS * UCP) 243.00

Tabla 15: Estimación por puntos de casos de uso (UCP)

Se observa que la cantidad de horas para el desarrollo del proyecto, es de

243 horas en total. Es decir, el resultado de la estimación por puntos de casos de
uso, dio como resultado que se estima que para el desarrollo y construcción del
proyecto se tomarán 243 horas. Observemos cómo se obtuvieron los valores de
TCF y ECF.

($%! #/ &# !0)*#?.&(& 2$-.$(

Metrica Descripción Peso Valor TCF
TCF01 Sistema Distribuido 2,00 2,00 4,00

64
TCF02 Tiempo de respuesta 1,00 3,00 3,00
(rendimiento)
TCF03 Eficiencia del usuario final (en 1,00 2,00 2,00
linea)
TCF04 Procesamiento interno complejo 1,00 3,00 3,00
TCF05 El código debe ser reutilizable 1,00 2,00 2,00
TCF06 Fácil de instalar 1,00 1,00 1,00
TCF07 Fácil de usar 1,00 3,00 3,00
TCF08 Portable 2,00 4,00 8,00
TCF09 Fácil de cambiar 1,00 3,00 3,00
TCF010 Concurrente 1,00 1,00 1,00
TCF011 Incluir capacidades de 1,00 2,00 2,00
seguridad especiales
TCF012 Acceso directo a SW de terceros 1,00 0,00 0,00
TCF013 Necesidad de entrenamiento 1,00 0,00 0,00
especial
Total: 32.00

Tabla 16: Componentes del factor de complejidad técnica

Factor Valor
Valor TCF sin ajustar (UTV) 32.00
Peso del TCF (TWF) 0.01
Constante del TCF (TC) 0.60
Factor de Complejidad Técnica (TCF) = TC + (UTV * TWF) 0.92

Tabla 17: Cálculo del factor de complejidad técnica (TCF)

($%! #/ &# !0)*#?.&(& &#* -%! -!

Metrica Descripción Peso Valor ECF
ECF01 Conoce el RUP 1,50 4,00 6,00
ECF02 Experiencia con la aplicación 1,00 3,00 3,00
ECF03 Experiencia con el modelo POO 1,00 3,00 3,00
ECF04 Capacidades del analista líder 0,00 4,00 0,00
65
ECF05 Motivación 1,00 5,00 5,00
ECF06 Requisitos estables 2,00 4,00 8,00
ECF07 Trabajadores de medio tiempo -1,00 1,00 -1,00
ECF08 Dificultad en el lenguaje de -1,00 1,00 -1,00
programación
Total: 23.00

Tabla 18: Componentes del factor de complejidad del entorno

Factor Valor
Valor del ECF sin ajustar (UEV) 23.00
Peso del ECF (EWF) -0.03
Constante del ECF (EC) 1.40
Factor de Complejidad del Entorno (ECF) = EC + (UEV * EWF) 0.71

Tabla 19: Cálculo del factor de complejidad del entorno (ECF)

!0)*#?.&(& )! $(/! &# ,/! L-.$!

En la siguiente tabla se estimó la complejidad de cada caso de uso. La
complejidad sigue una escala así:
• Sencillo = 5.0
• Mediana = 10.0
• Difícil = 15.0
Esta complejidad se calcula mediante el número de escenarios o pasos por
cada caso de uso. También se podría calcular mediante el número de clases o
de tablas con las que se relaciona el caso de uso.

Módulo Nombre Tipo Complej.

Administración Ver Pedidos UseCase 5.0
Administración Modificar Usuario UseCase 5.0
Administración Agregar Usuario UseCase 10.0
Administración Eliminar Producto UseCase 5.0
Administración Modificar Producto UseCase 5.0
Administración Agregar Producto UseCase 5.0
66
Módulo Nombre Tipo Complej.
Administración Eliminar Categoría UseCase 5.0
Administración Modificar Categoría UseCase 5.0
Administración Agregar Categoría UseCase 5.0
Pedidos Efectuar Pedido UseCase 15.0
Pedidos Ingresar datos del Pedido UseCase 5.0
Pedidos Mostrar Resumen del Pedido UseCase 5.0
Pedidos Eliminar Elementos del Pedido UseCase 5.0
Pedidos Cambiar Cantidades del Pedido UseCase 5.0
Pedidos Calcular Precio del Pedido UseCase 5.0
Pedidos Agregar Elementos al Pedido UseCase 5.0
Pedidos Ver Pedido UseCase 5.0
Pedidos Ver Detalles Producto UseCase 5.0
Seguridad Registrarse en el sistema UseCase 5.0
Seguridad Recuperar clave UseCase 5.0
Seguridad Cambiar clave UseCase 5.0
Seguridad Autorizarse en el sistema (login) UseCase 5.0

Tabla 20: Complejidad por caso de uso

G : D,.%#$%, ( &# #/( !**!

Con el fin de tener la arquitectura de desarrollo ideal para el desarrollo del

trabajo, se han de evaluar las alternativas viables, más allá de la presentada
inicialmente, donde se evalúen su beneficios y desventajas técnicas,
administrativas y económicas.
Como se había mencionado anteriormente, se llevará a cabo la realización
bajo el modelo de n-capas o n-tier, lo que significa básicamente un modelo de n-
capas, consiste en construir diferentes capas dentro de la aplicación con el fin
que cada capa sea especializada en su tarea. Según N-Tier Inc., un modelo
por

67
 «Si un sistema va a ser descrito como N-Tier, deberá cumplir con las
siguientes reglas:
• Cada capa deberá poder existir en un sistema físicamente
independiente.
• Cada capa solo deberá intercambiar información con las
capas inmediatamente superior e inferior
• Cada capa podrá ser intercambiable»19

Por tanto, nuestra arquitectura tendrá un modelo por capas,

así:

()( &# -%# 4(3 &# #/#-%($.A-

Recibe los datos enviados por el servidor y los analiza de manera tal que
sean entendibles por el ser humano.
En este caso la interfaz la proporciona un navegador que analiza el
contenido de páginas HTML, XML, o DHTML, es decir, un navegador compatible
con los estándares de HTML v.4.0. En conclusión, el usuario final puede
hacer uso de cualquiera de los navegadores modernos, tales como Internet
Explorer 4.x

()( &# A'.$( &# #/#-%($.A- " &#* #'!$.!

Manipula y modifica los datos enviados por la capa inferior de acceso a los
datos y transforma de acuerdo a las reglas del negocio, generando el código
HTML o XML y la envía a la interfaz de presentación mediante HTTP. Como
alternativas
• Entorno Sun: JSP, con Enterprise Java
Beans
•
Entorno Microsoft: ASP.NET, con COM+
•
Entorno PHP: PHP, con XML
En la siguiente tabla comparativa se podrán apreciar las características
de
cada una de las alternativas, y la alternativa con características más deseable

19 N-TIER INC., Client/Server and the N-Tier Model of Distributed

Computing
68
será resaltada. Dicha tabla fue tomada de phpPatterns, en su artículo
“Presenting
with PHP: putting N-Tier Online”20.

Característica Microsoft Sun PHP

Multiplataforma Sí Sí Sí
IDE gráfico Excelente Bueno Regular
Madurez Sí Sí Sí
Fuertemente ligado a su familia de Si Algo No
productos
Funcionalidad para la web Sí Sí Sí
Facilidad de integración con diferentes Difícil Normal Fácil
tecnologías (ej. Competencia)
Facilidad de despliegue Relativamen Normal Fácil
te fácil
Facilidad de aprendizaje Normal Normal Muy fácil
Compatibilidad con productos anteriores Compatible No muy Compatible
compatible
Velocidad de desarrollo Normal Normal Rápido
Suporte y actualización Excelente Bueno Bueno
Cantidad de métodos y funciones aptos Normal Muchos Muchos
para utilizar
Orientado a objetos Sí Sí Sí
Hardware especial Sí Sí No
Benchmarks de desempeño Excelente Normal Excelente
Aceptación en el mercado Alta Alta Normal
Costo de acuerdo al presupuesto Alto Alto/Medio Libre

Tabla 21: Comparación entre tecnologías Microsoft, Sun y PHP

De la anterior tabla, se pueden extraer varias Para las

conclusiones.
necesidades de la empresa, las alternativas que más se acercaron fueron Sun y

20 phpPatterns(): Presenting with PHP: putting N-Tier Online.

http://www.phppatte rns.com/index.php/article/articleview/9/1/3
/
69
PHP. Como se va a seguir el modelo de n-capas, es importante para el desarrollo
del proyecto que se elija una opción que pueda ser multiplataforma y tenga
libertad para interactuar con otros sistemas que no siempre estén dentro de su
familia de productos. Por ello, y por su elevado costo, la alternativa de la
tecnología Microsoft fue descartada desde el inicio, aunque proporcione un
soporte y servicio al cliente excelente.
Por tanto, los dos contendores directos son las tecnologías Sun y PHP. Este
último proporciona algunas ventajas frente a su competidor que está siendo
ampliamente utilizado en el mercado. Algunos factores que entran a modificar la
decisión, son la facilidad de aprendizaje y la velocidad de desarrollo de pequeños
proyectos enfocados hacia la web utilizando PHP, dado que éste está
especializado en eso, Internet. Por ello también existen muchas funciones en PHP
especializadas y que pueden ser muy útiles al momento de desarrollar, evitando
trabajo no necesario. Aunque PHP no sea respaldado por una entidad
reconocida a nivel internacional, es un software en continua evolución por un
equipo de trabajo de muy buena calidad y poco a poco está siendo utilizado y
reconocido en el mundo.
Tal vez el factor más decisivo a la hora de elegir luego de conocer los
anteriores puntos, fue el precio. Como se explicó anteriormente, la tecnología
Microsoft es la más cara de todas, seguida por la Sun y finalmente, PHP que
prácticamente no tiene costo (salvo el del soporte y mantenimiento). Aunque se
puedan llevar a cabo soluciones de mediano y bajo costo con Sun (Tomcat,
Jboss, etc.), estas no aseguran por completo la correcta operatividad e
interconexión con los sistemas, y obviamente, se perdería el soporte.
Por tanto, se eligió la alternativa de utilizar PHP con XML en esta capa del
esquema.

()( &# $$#/! ( *!/ (%!/

Recibe las peticiones del nivel superior, ingresa a las diferentes fuentes de
datos y devuelve los valores en formato accesible. Se tiene:
• JDBC
• ODBC

70
 •Librerías de abstracción de acceso a datos, nativas de
PHP
Teniendo en cuenta que se optó por el entorno PHP en la anterior capa, no
tiene mucho sentido elegir JDBC como capa de acceso de datos. Por tanto, se
tienen ODBC y las librerías nativas de PHP como alternativas. Aunque PHP tiene
soporte completo para ODBC, igualmente tiene una cantidad importante de
librerías nativas de acceso a los datos, que proporcionan más velocidad. Por ello,
se eligió la alternativa de utilizar las librerías de abstracción de acceso a
datos

()( &# (%!/

Los datos físicos almacenados en repositorios. Varía desde archivos
planos,
bases de datos relacionales o repositorios de XML. Como alternativas:
• Microsoft SQL Server 2000
• IBM DB2/Informix
• Oracle9i Database
• mySQL
Bloor Research realizó una investigación para IBM con el fin de realizar
una comparación exhaustiva de las grandes compañías en el mercado de las
bases de datos. Ellos especifican que una base de datos debe ser evaluada según
su tecnología, así:
«Específicamente, se deben evaluar en la tecnología subyacente los factores
de disponibilidad, facilidad de uso, interoperatividad, escalabilidad y seguridad»21
En esta capa, los requisitos de la aplicación no son
exhaustivos,
simplemente requieren de un RDBMS que sea compatible con el estándar ANSI
SQL, que tenga buen rendimiento, y que tenga una excelente tasa costo-
beneficio. Por ello, se realizó una comparación básica entre los servidores
anteriormente enunciados. Se concluyó, que comparativamente las bases de
datos comerciales (SQL Server, Oracle9i y DB2) son excelentes y tienen una
trayectoria y soporte notable. De ellas, el estudio de Bloor Research enuncia que
globalmente, el mejor

21IBM: Bloor Research – Databases: An evaluation & comparison.

2001
71
Microsoft SQL Server. Siendo notables los anteriores productos, notable también
es el precio, siendo U$3,500.oo el más económico de todos. Estando el proyecto
enfocado a la pequeña y mediana empresa, los precios se salen del presupuesto y
se está en la necesidad de elegir una alternativa más económica, en este caso,
mySQL server comercial con valor de U$495,oo con soporte incluido por un año.
Es claro que por estar en una arquitectura de capas, donde cada una es
independiente de la otra, y estar basada en el estándar ANSI SQL, esta base de
datos podrá ser migrada sin problemas a una más robusta en caso de ser
necesario en un futuro.

Tenemos entonces una arquitectura basada mayormente en tecnologías de

código abierto, y gráficamente es:

Figura 11: Esquema n-tier sobre arquitectura GNU/Linux

72
 G G #C./.A- ( *( #/%.A- &# .#/'!/

En esta etapa inicial es importante realizar una revisión a la gestión de

riesgos con el fin de implantar nuevas medidas y estrategias, en caso de ser
necesarias y evaluar los nuevos riesgos que hayan surgido debido a la
arquitectura de desarrollo elegida.
De acuerdo con la política de gestión de riesgos establecida anteriormente,
se verificó que las estrategias estén siendo desarrolladas y que éstas se hicieran
en realidad efectivas. Adicionalmente, se realizó un análisis de riesgos
específicamente sobre la nueva tecnología a utilizar.
Riesgos específicos de la arquitectura Peso P(r)
No se obtenga soporte sobre la tecnología 4 30
empleada
No haya personal capacitado para 5 35
administrar/mantener la tecnología
La tecnología será obsoleta 4 10
La base de datos será insuficiente e 3 20
inadecuada
El hardware no soportará la arquitectura 5 5

Tabla 22: Riesgos específicos de la arquitectura

Aunque ningún factor sobrepase el valor crítico que se estableció como

punto límite, se debe poner especial énfasis en el riesgo que versa sobre que no
haya personal capacitado para administrar/mantener la tecnología. De esto
se
desprende, que la empresa debe buscar asesoría externa, o realizar
capacitaciones internas sobre la nueva tecnología a
implantar.

G H .(' (0( &# #$,#-$.(

73
 De los diagramas de interacción existentes (secuencia y colaboración), se
optó por seleccionar el diagrama de secuencia como preferido, puesto que
demuestra claramente a través del tiempo la interacción entre los diferentes
componentes del sistema. Veamos pues el diagrama de secuencia del módulo
más

74
Figura 12: Diagrama de Secuencia - Módulo de pedidos
75
 El diagrama también se puede apreciar en forma de tabla, como se
muestra a continuación:
Cod Mensaje Desde Hacia
1 verCatálogo Interfaz de catálogo
2 listar() Interfaz de catálogo
3 listarProductos
4 verDetallesProducto Interfaz de catálogo
5 ver() Interfaz de catálogo
6 mostrarDetallesProduc
to
7 agregarProductoAPedi Interfaz de catálogo
do
8 agregar(int, int) Interfaz de catálogo
9 recalcular()
10 confirmarAgregarProd Interfaz de catálogo
ucto
11 hacerPedido Interfaz de catálogo
12 verificarPrivilegios() Interfaz de catálogo
13 completarPedido() Interfaz de catálogo
14 recalcular()
15 confirmarPedido Interfaz de catálogo
16 hacerPedido() Interfaz de catálogo
17 ver() Interfaz de catálogo
18 mostrarDetallesPedido
19 cambiarPedido Interfaz de catálogo
20 cantidad(int, int) Interfaz de catálogo

Tabla 23: Diagrama de Secuencia – Módulo Pedidos

76
 G

En la etapa de construcción se pasa del desarrollo y construcción de la

propiedad intelectual producto de fases anteriores, hacia la elaboración y
construcción de productos utilizables en versiones alfa o beta. Es vital que al
terminar esta fase se haya completado el análisis, diseño, desarrollo y pruebas de
toda la funcionalidad requerida. Dentro de la ideología del RUP, se trató de hacer
un balance en minimizar el tiempo de desarrollo con una buena calidad en el
producto, buscando maneras de minimizar los costos de desarrollo, es decir,
evitar el trabajo innecesario mediante la reutilización de código (una de
las

Fue importante en esta fase rectificar y clarificar tanto los requisitos como
el diseño que fueron necesarios, desarrollar o implementar los subsistemas o
componentes, e integrarlos. Dicha integración se realizó en el llamado modelo
operacional, el cual representa una composición física de la implementación en
términos de subsistemas y elementos (directorios, archivos, código fuente
y

Durante la etapa de la construcción se hizo uso de un sistema de manejo

de versiones llamado CVS (Concurrent Versión Set) con motivos de seguridad,
organización y además para proporcionar documentación detallada de todos
los

77
 G 6 #C./.A- ( *( #/%.0($.A- " 02% .$(/

Se llevó un registro preciso de tiempo en la implementación de cada caso

de uso durante esta fase, con el fin de verificar qué tan diferente fue la realidad a
lo planeado durante el paso de estimación. En la siguiente tabla
observaremos
Módulo Horas Horas Horas % de
Estimadas Reales Diferencia Diferencia
Administración 96 96 0 0%
Pedidos 105 127 22 20.9523%
Seguridad 39 42 3 7.6923%
Total 240 269 29 12.0833%

Tabla 24: Comparación tiempo estimado vs. tiempo real

Se nota que hubo un 12.083% de diferencia con relación al

tiempo
estimado, es decir, hubo un retraso del 12.083% en el tiempo de implementación
del proyecto. Aunque en la actividad de estimación se hizo una prueba piloto con
un módulo con el fin de establecer un precedente, el resultado obtenido
demuestra que la diferencia de tiempos fue mayor en el módulo de mayor
proporción de integración, que fue el módulo de pedidos. Aunque la estimación
no fue perfecta, lejos de pensar que es inservible, los datos y resultados
obtenidos sirven para perfeccionar la misma estimación con el fin que sea
más certera y

G *(- &# ,#>(/

Una vez realizada la primera versión alfa, es necesario realizar un plan de

pruebas con el fin de evaluar contra el criterio de aceptación con suficiente
amplitud y profundidad, la implementación y ejecución de la aplicación
desarrollada, almacenando la información necesaria para diagnosticar y
resolver

78
identificar adicionalmente potenciales riesgos en los que el proyecto pueda caer,
desde las primeras fases del desarrollo del mismo.
El plan de pruebas que se realizó incluye diferentes tipos de riesgos dentro
de los cuales hay varios tipos de pruebas que fueron ejecutadas por el grupo de
desarrollo e integración, o por terceras partes ajenas al proceso de construcción.
Este plan de pruebas es basado en algunas pruebas sugeridas por el
mismo RUP.

.#/'!1 ,-$.!-(*.&(&
Este riesgo abarca los posibles problemas relacionados con la misma
funcionalidad del sistema. Para probar este riesgo y sus posibles problemas, se
ejecutaron tres tipos de pruebas:

Prueba de
Funcionalidad
Fue utilizada con el fin de validar que la unidad examinada funcione como
se espera, es decir, que trabaje conforme a los casos de uso, requisitos, servicios,
etc. Cada unidad examinada puede ser desde un método o función, hasta un
sistema completo.

Prueba de
Seguridad
Se verificó que la información solo puede ser accedida por aquellos
actores
que en realidad tienen los privilegios y credenciales para hacerlo.
Prueba de
Volúmen
Este examen probó la capacidad del sistema de recibir/devolver cantidades
de información muy grandes o vacías. Se usaron consultas que devolvieran
grandes cantidades de información, o información que fuera difícil para el motor
de búsqueda encontrar.

79
 .#/'!1 /(>.*.&(&

Implica que la unidad a ser examinada cumpla con las

características
propias de una correcta interfaz al usuario. Es decir, evalúa la estética, la
consistencia de la interfaz, la documentación, etc. Se efectuó la llamada prueba
de usabilidad.
Prueba de
Usabilidad
Se examinaron factores tales como la estética, la documentación, la ayuda
en línea, la facilidad de comunicación con el humano, la consistencia, y demás
factores que permitan que la aplicación sea amigable al usuario.

.#/'!1 !-4.(>.*.&(&

Como su nombre lo indica, las pruebas realizadas para

identificar
problemas de este tipo busca que la aplicación sea confiable en distintos niveles,
es decir, busca la robustez de la misma. Las pruebas más importantes en este
campo, son:
Prueba de
Integridad
Se enfoca a la robustez de la unidad a examinar. Busca que tal unidad
sea
resistente a fallos, y evalúa factores técnicos como uso de recursos y que la
aplicación esté de acuerdo con los estándares del lenguaje.
Prueba de
Estructura
En el caso de las aplicaciones enfocadas a la web, esta prueba
examinó
que todo el sistema sea completamente navegable, sin enlaces muertos, con
congruencia en el diseño de navegación, el contenido correcto sea mostrado, y
que no hayan páginas inaccesibles (llamadas islas o huérfanas). En este caso, se
realizaron pruebas usando el software spider de pruebas de estructura

80
LinkChecker, el cual fue de gran ayuda para encontrar problemas de tipo
estructurales en la aplicación web.

Prueba de
Adversión
Busca evaluar como se desempeñó el sistema en situaciones extremas y
adversas, tales como sobrecarga de procesador, servicios no disponibles, falta de
memoria, fallas en la comunicación, y falta de cualquier tipo de recurso que sea
necesario. Más que para corregir situaciones, este tipo de prueba se realiza con
el fin de identificar cómo funciona el sistema en condiciones anormales, para así
poder sacar los debidos planes de contingencia y de mitigación de riesgos, con su
debido presupuesto para el futuro. Para estas pruebas, se hizo uso del software
de pruebas automáticas OpenSTA, el cual sirvió para simular el comportamiento
de clientes y así sobrecargar la aplicación, para finalmente dar los
resultados

.#/'!1 #-&.0.#-%!

Las pruebas en este ámbito se realizan con el fin de evaluar las

características relacionadas con el rendimiento de un determinado sistema. Tales
características pueden ser de tiempo de respuesta, confiabilidad operacional, y
límites conocidos, entre otros.

Prueba de
Carga
Varía la cantidad de entradas de operación normal al sistema (número
de
consultas, usuarios, etc.) manteniendo constante la configuración. Se usó la
aplicación de pruebas automáticas OpenSTA para este tipo de pruebas.
Prueba de Perfiles de
Funcionamiento
Varía las configuraciónes del sistema, mientras las entradas de operación
normal del sistema permanecen constante. Se observa el comportamiento de la
aplicación bajo estos cambios.

81
 Pruebas de Comparación
(benchmarking)
Compara los valores mesurables de la unidad a probar, con los de una
unidad estándar ya conocida.

.#/'!1 (-%#-.0.#-%! " !)! %#

Finalmente estas últimas pruebas, se aseguran que la unidad a ser

examinada cumpla características propias de una correcta configuración e
instalación.

Pruebas de
Configuración
Se pretendió evaluar y asegurar que el sistema funcionara en diferentes
configuraciones tanto de software como de hardware.

Pruebas de
Instalación
Se buscó probar cómo era la instalación de la aplicación en diferentes
configuraciones tanto de software como de hardware. Se utiliza para identificar
posibles errores y realizar planes de contingencia y mitigación.

G (/!/ &# ,#>(

Por definición, un caso de prueba es la definición formal de un conjunto

específico de entradas, condiciones de ejecución y resultados esperados,
identificados con el fin de evaluar determinado aspecto de un elemento dentro de
un proyecto. Se efectuaron casos de prueba para la realización de los «tests»
propuestos en el plan de pruebas ya mencionado. Algunos de estos casos de
prueba se encuentran en el Anexo I del presente documento.

82
 G 8 #)! %# &# ! #/

Una vez efectuados los casos de prueba para llevar a cabo el plan de
pruebas, en caso tal que hayan casos de prueba cuya ejecución haya dejado
como resultado que no pasa el criterio de aceptación los resultados esperados, se
debe emitir un reporte de errores en el cual estarán plasmados de manera clara y
concisa los errores y los problemas que deberán ser solucionados con el fin que
los elementos evaluados logren pasar los criterios de aceptación definidos.
Algunos ejemplos de documentos de reporte de errores, están en el Anexo
II del presente documento.

G 9 .%# .!/ &# C(*,($.A-

Luego de las anteriores actividades, se llega a la meta de la fase de

construcción, en la que se plantearon los criterios de evaluación y en caso de ser
positivos, se continúa con la fase de transición.
A saber, los criterios de evaluación que se realizaron fueron:

• ¿Está el producto lo suficientemente maduro y listo para su

lanzamiento hacia los usuarios finales?
• ¿Están los usuarios finales listos para aceptar el proyecto?
• ¿Continúa siendo aceptable el presupuesto luego de terminar esta
fase?

En caso tal que alguna de estas preguntas o criterios de evaluación fuera

negativa, el paso a la fase de transición tendría que ser pospuesto y los artefactos
relacionados con el criterio de evaluación, identificados y corregidos.

83
 G8

En la fase de transición se asegura que la aplicación esté disponible para

los usuarios finales. También se hacen los cambios menores basándose más que
todo en la retroalimentación de los usuarios beta y/o usuarios finales. Se dice
cambios menores (configuración, instalación y usabilidad), porque los grandes
cambios estructurales debieron haber sido corregidos en la fase anterior. Para
esta fase, las bases de datos deben estar completamente en operación.

G86 ,#>(/ >#%( " $()($.%($.A-

Actualmente, en el desarrollo del proyecto se está en esta última fase

obligatoria para el RUP, donde los usuarios finales están llevando a cabo las
pruebas beta y comparando la nueva aplicación con la manera antigua de
realizar los procesos.
En paralelo, se está haciendo una inducción al área administrativa que
estará usando el software, de manera tal que se adapten al uso de la nueva
aplicación, e igualmente recibir la retroalimentación de estos usuarios para
corregir e implementar cambios menores.

G8 #C./.A- (* *(- &# %# ($.!-#/

Una vez en la fase de transición, es importante revisar el Plan de

Iteraciones con el fin de analizar los criterios de evaluación particulares a cada
iteración, así como para la ratificación del plan de la siguiente iteración. El
historial de estas revisiones puede ser visto en el Anexo G del presente
documento.

84
 G8 .%# .!/ &# C(*,($.A-

Para terminar la última fase del ciclo del RUP, y por ende la iteración, es
necesario responder a unas preguntas o criterios de evaluación con el fín de
saber si los objetivos fueron alcanzados y si es necesario o no realizar otro ciclo
del RUP.
Los criterios de evaluación en este caso son:

• ¿Está(n) satisfecho(s) el (los) usuario(s)?

• ¿El presupuesto real vs. el presupuesto planeado sigue
siendo aceptable?

Nuevamente, en caso que alguno de los criterios de evaluación sea

respondido de manera negativa, implicaría una revisión a los artefactos
involucrados en esta fase para identificar las causas de la falla, y finalmente
realizar los correctivos pertinentes.
Una vez terminado el ciclo del RUP, se tendría una aplicación o modelo de
implementación muy bien documentado, maduro, y de calidad, y si es necesario
realizar cambios adicionales al mismo, se realizaría otro nuevo ciclo o iteración,
donde se haría énfasis a la solución del problema, funcionalidad adicional o al
mejoramiento de la calidad.

85