RESUMEN INFORMATICA IV

PUDS

FASES:
Inicio
Elaboracin
Construccin
Transicin

Flujos de trabajo

Modelado de Negocio
Requerimientos
Anlisis
AyDS

Diseo
Implementacin
Prueba

Info IV

Cada Flujo se trabajo se describe enunciando:

Actividades
Artefactos
Trabajadores

UNIDAD N 1
MODELO DE DISEO
Modelo de Anlisis:
Terminado el modelo se tiene una descripcin detallada de todos los requisitos del
sistema.
Modelo de Diseo:
Constituye una formalizacin y refinamiento adicional al modelo de anlisis.
Modelo de objetos representando la realizacin fsica de los casos de uso.
Permite conocer especificaciones muy detalladas de todos los objetos,
incluyendo operaciones y atributos.
Se definirn explcitamente las interfaces de los objetos y la semntica de las
operaciones.
Se compondr de bloques que constituirn los objetos de diseo, que luego sern
implementados como cdigo fuente, abstrayendo la implementacin real.
Inicialmente cada objeto de anlisis se transformar en un bloque, teniendo
rastreabilidad en los modelos.
Es una abstraccin de cmo el sistema se construye realmente y nos permite
reducir la complejidad del mismo.
Es la ltima parte de la iteracin de elaboracin y comienza la de construccin.
Se deben tener definidas las herramientas que se utilizarn en el desarrollo de la
aplicacin, ya que muchas cosas se pueden dejar listas y autogenerarlas para el modelo
de implementacin.
Para desarrollar el modelo de diseo debemos:
Identificar el ambiente de implementacin: Identificar e investigar las consecuencias que el
ambiente de implementacin tendr sobre el diseo.
Incorporar estas conclusiones y desarrollar un primer enfoque del modelo de diseo:
Usamos el modelo de anlisis como base y traducimos los objetos de anlisis a objetos de diseo,
de acuerdo al ambiente actual de implementacin.
1

Describir cmo interactan los objetos en cada caso de uso especfico: El modelo de diseo
se focaliza en describir todos los estmulos enviados entre objetos y qu operacin har cada uno.
Este proceso nos dar las interfases de cada objeto.
Rastreabilidad:
Se puede rastrear una clase desde el cdigo fuente al anlisis y viceversa.
Es importante porque a medida que el sistema tiene cambios a lo largo de su
ciclo de vida se necesita saber siempre dnde se deben hacer los cambios en el
cdigo fuente.

Artefactos
1.-Clases de diseo:
Son abstracciones de clases de implementacin.
Muchas caractersticas de las clases tienen relacin directa con el lenguaje
de programacin, por eso es necesario tenerlo elegido en esta instancia.
Se deben definir para cada clase sus mtodos, atributos, parmetros, tipos,
visibilidad de los atributos (pblicos, protegidos, privados, amigos).
2.-Realizacin de casos de uso de diseo:
Se vinculan directamente con las realizaciones de casos de uso de
anlisis, los cuales se relacionan con casos de uso de modelos de casos de
uso (as se traza rastreabilidad a travs de los distintos modelos).
Se tienen en cuenta los distintos requerimientos no funcionales que se
fueron recolectando.
Las realizaciones poseen:

descripcin textual del flujo de eventos,

diagramas de clases,

diagramas de interaccin.
Diagramas de clases:
Las clases y subsistemas pueden intervenir en ms de un caso de una
realizacin de casos de uso.
A travs de ellos se pueden tener registrado qu clases intervienen en las
realizaciones de los distintos casos de uso.
Interfaz Entrada
Botones de Comando
Cuadros de Texto
Etiquetas
Opciones()

Gestor de personal
Entidad de control de personal
Obtener datos de usuarios()
Actualizar datos de usuarios()
Imprimir resultados()
Generar consulta de usuarios()

Administrador de
sistema

Usuario
Nombre
Apellido
Direccin
Telefono
Id Empleado
Ingresar()
Borrar()
Modificar()

Interfaz Salida
Botones de Comando
Etiquetas
visualizacin()
Confirmacin()

Diagramas de interaccin:
o Se utilizan Diagramas de secuencia.
o En ellos las interacciones entre objetos se representan mediante la
transferencia de mensajes entre dichos objetos.
o Muestra las interacciones entre objetos ordenadas en secuencia temporal.
o Se utilizan para validar casos de uso.
o Documentan el diseo desde el punto de vista de los casos de uso
observando qu mensajes se envan a los objetos, componentes o casos de
uso y viendo grosso modo cunto tiempo consume el mtodo invocado.
o Ayudan a comprender los cuellos de botella potenciales para poder
eliminarlos.
o Conceptos relacionados:
Lnea de vida de un objeto (lifeline):

Representa la vida del objeto durante la interaccin.

Un objeto se representa como una lnea vertical punteada con

un rectngulo de encabezado y con rectngulos a travs de la lnea
principal que denotan la ejecucin de mtodos (activacin). El
rectngulo de encabezado contiene el nombre del objeto y el de su
clase en un formato nombreObjeto:nombreClase.
Activacin:

Muestra el perodo de tiempo en el cual el objeto se

encuentra desarrollando alguna operacin.

Se denota como un rectngulo delgado sobre la lnea de vida

del objeto.
Mensaje:

Se denota mediante una lnea slida dirigida desde el objeto

que emite el mensaje hacia el objeto que lo ejecuta.
Tiempos de transicin:

En un entorno de objetos concurrentes o de demoras en la

recepcin de mensajes es til agregar nombres a los tiempos de
salida y de llegada de mensajes.

: Administrador de
Interfaz entrada
sistema
Ingresa opcion

Gestor Personal

Usuarios

Interfaz Salida

Solicita Ingres o Datos

Ingresa Datos
Datos a chequear
Solicita busqueda de Datos
Devuelve Datos
Chequea consistencia

Solicita visualizacin de la transaccin

Visualiza Transaccin

3.-Subsistema de diseo:

Permite organizar y agrupar las clases de diseo de acuerdo a su

funcionalidad (har mas manejable el modelo).

Debe existir independencia entre los subsistemas para lograr su

reutilizacin y a la hora de las modificaciones, ya que los cambios en unos no
afectarn a los otros.

Subsistema de servicio: prepara al sistema para cambios de servicios

individuales.

4.-Interfaz:

A travs de ellas se especifican las distintas operaciones que pueden ser

realizadas por una clase o los subsistemas.

Representan la cara visible de la funcionalidad de una clase.

Dentro de una clase, sus atributos y mtodos conformarn la interfaz.

Si se cambia el cdigo de un mtodo pero no se cambia ni su nombre, tipo y

parmetros, slo se habr cambiado funcionalidad y no su interfaz, por lo cual las clases
relacionadas a sta no deberan sufrir ninguna modificacin.

Si se agregan parmetros o se cambian tipos, s se debe cambiar la forma en que

estas clases se relacionaban.
5.-Descripcin de la arquitectura:

Debe estar constituida por:

definicin de subsistemas que conforman el modelo de diseo,
con sus interfaces,
clases de diseo relacionadas directamente con clases de
anlisis que conformaban la vista del la arquitectura del modelo de
anlisis,
realizaciones de casos de uso relevantes, los cuales tienen una
relacin con las realizaciones del modelo de anlisis y con los casos de
uso del modelo de casos de uso.

6.-Modelo de despliegue:
Permite representar cmo ser la distribucin fsica del sistema, o sea dnde
residir fsicamente cada uno de los componentes (clases de interfaz, de control,
de entidad).
Las ubicaciones fsicas se denominan nodos.
Existen relacionen entre ellos representadas por medios de comunicacin: Internet,
extranet, intranet.
Hay nodos que contienen los componentes asociados a interfaces entre el sistema y
los actores (por ejemplo donde residen las distintas pantallas de aplicacin).
Otros nodos contienen las clases de control, que residen en los servidores de
aplicacin.
Hay nodos donde estarn las clases de entidad que luego constituirn los repositorios
de datos (BASES DE DATOS).

Servidor de Base de
Datos

Terminal de
ventas

Terminal de
administracin

Trabajadores
Arquitecto:
Responsable de asegurar que el modelo de diseo y de despliegue se
correspondan con el modelo de casos de uso y de anlisis.
Cuida que sea consistente y que est todo lo significativo para la arquitectura del
modelo.
Ingeniero de Casos de Uso:
Es el encargado de asegurar las realizaciones de casos de uso del modelo de
casos de uso y del modelo de anlisis.
Cuida los detalles para que cada caso de uso sea comprendido perfectamente y que
las relaciones con los casos de uso de los modelos anteriores estn totalmente claras.
Ingeniero de componentes:
Es el encargado de definir todo lo referido a las clases del diseo y tambin de
los subsistemas de diseo.
Para las clases define sus mtodos, atributos (interfaz) y las relaciones que existen
con otras clases, que relaciones existen con otros subsistemas y de qu forma se
relacionan con los otros subsistemas (interfaces).
Flujo de Trabajo

Diseo de la arquitectura:
Comenzamos en esta etapa a definir los modelos de diseo y de despliegue,
utilizamos para ello los siguientes elementos:
a. Nodos y sus configuraciones de comunicacin.
b. Subsistemas y sus interfaces.
c. Clases de diseo relevantes para la arquitectura.
d. Mecanismos genricos de diseo.
a) Nodos y sus configuraciones de comunicacin:
Toda aplicacin est compuesta por tres capas, una encargada de la interfaz
con el usuario, otra de almacenamiento de la informacin y una capa intermedia
encargada de procesar las reglas y lgica del negocio.
Estas capas pueden tener tanto una divisin lgica como fsica:
divisin lgica: en la aplicacin se encuentran muy bien
divididas las tres funcionalidades de estas capas,

divisin fsica: estas capas pueden residir en nodos

diferentes.
Las primeras aplicaciones, manejaban estas tres capas todas juntas, tanto fsica
como lgicamente. El procesamiento se realizaba en las mainframes y los usuarios
accedan a l a travs de terminales bobas.
Luego aparecieron aplicaciones partidas lgicamente en dos capas: una reside en el
servidor y la otra se ejecuta en los clientes.(Modelo cliente- servidor).
Existen dos variantes de este modelo:
Servidor inteligente: tanto la capa de datos como la de reglas de negocio
residen en un servidor llamado DBMS (DataBase Management System).
Los clientes cumplen slo la funcin de capa de interfaz, tomando la
informacin que los usuarios ingresan al sistema, enviando esto hacia el
servidor y mostrando lo que dicho servidor enva hacia el puesto.
Cliente inteligente: en este caso el cliente no cumple nicamente la
funcin de interfaz con el usuario sino tambin las funciones de la capa intermedia,
realizando todos los chequeos y controles necesarios antes de hacer llamadas a la
capa de datos.
Por ltimo, estn aquellas aplicaciones partidas lgicamente en tres capas (podran
estar o no divididas tambin fsicamente.):
En estas aplicaciones estn aisladas las tres funcionalidades de una
aplicacin: interfaz, control y datos.
Entre las distintas ventajas est la posibilidad de aumentar el rendimiento de
la aplicacin a medida que existan ms requerimientos con la misma, ya que la
capa intermedia al estar independizada de las otras dos, puede ir residiendo en
tantos servidores como vaya siendo necesario y es posible agregar servidores a
medida que vaya haciendo falta.
Lo mismo sucedera con los servidores de base de batos, donde hay dos
variantes de este modelo:
Aplicaciones que se ejecutan en cada estacin de trabajo,
generalmente realizadas en lenguajes de programacin, como Visual
Basic.
Aplicaciones que se ejecutan en un servidor web y son
accedidas desde las estaciones de trabajo por algn explorador de
internet, como Internet Explorer.
En el caso de aplicaciones Windows, stas residen en cada
equipo y deben estar instaladas en cada equipo. Las aplicaciones
Web estn instaladas en servidores web, stos pueden ir creciendo y
agregando nuevos servidores a medida que la aplicacin aumente
sus requerimientos de rendimiento.
En este punto del flujo se analizan los distintos nodos que se utilizarn, con sus
caractersticas tcnicas, como las conexiones que existirn entre stos.
b) Subsistemas y sus interfaces:
Objetivo de subsistema: organizar el modelo de diseo en piezas manejables.
A partir de los paquetes de anlisis y de servicios definidos se deben identificar
los subsistemas que existen.
Si la clase de un subsistema interacta con una clase de otro sistema, se definir
una relacin entre estos. Debemos definir la manera en que estas clases se relacionan,
es decir las interfaces que permiten que una clase sea accedida.(Ej.: los mtodos que
esta expone hacia fuera para que sean invocados por otras clases).
c) Clases de diseo relevantes para la arquitectura:
7

 Es importante detallar las clases que hay que tener en cuenta para la
arquitectura.
No debemos analizar un gran nmero de clases ni bajar en un nivel de detalle
extremo en ese momento, slo analizar las relevantes para la arquitectura.
El anlisis ms fino se har en el diseo de clases y en el de casos de uso.
d) Mecanismos genricos de diseo:
Se trata de todos aquellos requisitos especiales que fuimos detectando en
modelos anteriores y pospusimos hasta tener mejor definidas las caractersticas
ms tcnicas del proyecto (plataforma de cada capa, lenguajes, bases de datos).
Suelen relacionarse con:
Persistencia.
Distribucin transparente de objetos locales y remotos.
Seguridad.
Mono o multiusuario.
Manejo de errores.
Transacciones.
Arquitectura de la aplicacin (una, dos o ms capas lgicas).
Tipos de interfaz de usuario (Windows o Web).

Diseo de un caso de uso:

ste tiene como objetivos:
a) Identificacin de clases de diseo.
b) Interacciones entre objetos.
c) Identificacin de subsistemas de diseo.
d) Interacciones entre subsistemas.
a) Identificacin de clases de diseo.
Para cada realizacin de caso de uso se recogen todas las clases del diseo que
intervienen a travs de un diagrama de clases de diseo.
Tomaremos el caso de uso - anlisis con sus clases de anlisis correspondientes y
en base a esto y al resto de la informacin recabada hasta el momento para dicho caso
detectaremos todas las clases con sus respectivas relaciones.
Para cada clase de diseo asignaremos un ingeniero de componentes como
responsable de la misma.
b) Interacciones entre objetos.
Se definen cmo interactan las clases que intervienen en cada realizacin de
caso de uso.
Se utiliza un diagrama de secuencia que contiene instancias de actores, los objetos
de diseo y las transmisiones de mensajes entre estos.
Se transforma el diagrama de colaboracin de la realizacin de caso de usoanlisis en un esbozo inicial del correspondiente diagrama de secuencia.
A medida que bajemos en detalle en cada caso podemos encontrar cursos
alternativos para los casos como:
nodos o conexiones que dejan de funcionar,
ingresos errneos de informacin por parte de actores,
errores generados por la misma aplicacin o por hardware.
c) Identificacin de subsistemas de diseo.

 Se tomarn los paquetes de anlisis detectados en el modelo de anlisis y

adems aquellos requisitos que dejamos para esta etapa de diseo y con esto se
delinearn los distintos subsistemas de diseo que intervendrn en el sistema.
Se utilizar un diagrama de clases.
d) Interacciones entre subsistemas.
Para detectar las interacciones que existen entre los distintos subsistemas se
utilizarn los diagramas de secuencia.
Se reflejan las relaciones entre los actores y subsistemas a travs del envo de
mensajes entre los mismos
Diseo de una clase:
Ya se tiene claro cul ser el rol exacto de cada clase dentro de las distintas
realizaciones de casos de uso. Ya se traz la relacin con las clases detectadas en el
modelo de anlisis.
Pasemos a analizar para cada una de ellas:
o
operaciones,
o
atributos,
o
relaciones,
o
mtodos,
o
estados.
En el caso de las clases de entidad el anlisis depende de la base de datos a
utilizar y en este punto se est en condiciones de normalizar la BD y generar la
estructura que se utilizar en la aplicacin.
En las clases de interfaz el diseo de las mismas est muy ligado al lenguaje de
programacin que se utilizar.
a) Operaciones
Las responsabilidades detectadas en las clases de anlisis implican una o
varias operaciones para las clases de diseo.
Deben cubrir todas las operaciones que sean necesarias en todas las
realizaciones de casos de uso - diseo en los que las mismas participen.
Es necesario describir, utilizando la sintaxis del lenguaje de programacin,
la visibilidad de cada operacin (publica, privada, protegida).
b) Atributos
Debemos identificar en detalle los distintos atributos o propiedades de cada clase
en la sintaxis del lenguaje de programacin.
Se deben identificar los tipos de cada atributo, que dependern del lenguaje
elegido.
c) Relaciones
Se deben dejar muy bien reflejados los distintos tipos de relaciones que existan
entre las clases de diseo.
Una entrada para esto son los diagramas de interaccin (colaboracin y secuencia)
ya que en stos se manifiestan las relaciones y los envos de mensajes entre las
distintas clases.
En cuanto a las generalizaciones (o herencia) depender si el lenguaje que estemos
utilizando la soporte o no, en este ltimo caso tendremos que reemplazar esto por la
duplicidad de funcionalidades y caractersticas en aquellos objetos comunes.
d) Mtodos
stos especifican cmo se realizan las distintas operaciones, es recomendable
utilizar lenguaje en pseudo cdigo y siempre teniendo en cuenta el lenguaje de
programacin que utilicemos.
e) Estados
9

 Con el objeto de agregar mayor detalle para la implementacin de la clase podemos

reflejar los estados por los que puede pasar una clase.
En muchos casos suele ser importante utilizar diagramas de estados a travs de los
cuales podemos reflejar su comportamiento cuando reciben un mensaje.
Diagrama de estados
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una
aplicacin junto con los cambios que permiten pasar de un estado a otro.
Estado:
Identifica un periodo de tiempo del objeto -no instantneo- en el cual l est
esperando alguna operacin, tiene cierto estado caracterstico o puede recibir
determinado tipo de estmulos.
Se representa mediante un rectngulo con los bordes redondeados que puede tener
tres compartimientos: uno para el nombre, otro para el valor caracterstico de los
atributos del objeto en ese estado y otro para las acciones que se realizan al entrar,
salir o estar en un estado (entry, exit o do respectivamente).

Eventos
Es una ocurrencia que puede causar la transicin de un objeto de un estado a otro.
El nombre de un evento tiene alcance dentro del paquete en el cual est definido,
no es local a la clase que lo nombre.
Envo de mensajes
Puede representarse el momento en el cual se envan mensajes a otros objetos.
Esto se realiza mediante una lnea punteada dirigida al diagrama de estados del
objeto receptor del mensaje.
Diseo de un subsistema:
Los puntos clave a tener en cuenta son:
independencia entre subsistemas,
mantener interfaces y sus operaciones,
asegurar que el subsistema cumple con su objetivo en las distintas
realizaciones en las que est involucrado.

Caso Prctico
1.- Diagrama de casos de uso
Los casos de uso especifican una interaccin entre un usuario y el sistema en el que ste
puede lograr un objetivo.
Casos de uso para agencia de alquiler de autos:
El cliente reserva el vehculo
Antes de disponer del vehculo el cliente debe hacer la reserva. Para ello se pone en
contacto con la agencia de alquiler y realiza una solicitud.
La agencia la acepta o la rechaza basndose en una serie de criterios, como por
ejemplo la disponibilidad de los vehculos o el historial de alquiler del solicitante.
Si se acepta la reserva el comercio llena un formulario con los detalles del cliente y
el pago del depsito completa el proceso de reserva.
El cliente acude por el vehculo
Cuando el cliente llega a la agencia de vehculos sta le asigna el modelo de
vehculo solicitado segn los niveles de stock disponibles.
Una vez abonado el importe total el cliente recibe el automvil.
10

El cliente

devuelve el vehculo
El cliente devuelve el vehculo a la agencia el da especificado en el acuerdo de
alquiler.

2.-Diagrama de clases de estructura esttica

La siguiente tarea consiste en clasificar los objetos y sus relaciones.
Examinar los casos de uso ayuda a identificar las clases.
Las clases de objetos se modelan utilizando diagramas de estructura esttica o de
clases que muestran la estructura general del sistema, as como las propiedades
relacionales y de comportamiento.

3.- Diagrama de secuencia

Proporcionan una vista detallada de un caso de uso.
Muestran una interaccin organizada en una secuencia de tiempo y ayuda a
documentar el flujo de lgica dentro de la aplicacin.
Los participantes se muestran en el contexto de los mensajes que se transfieren
entre ellos.

11

4.-Diagrama de colaboracin
Los diagramas de colaboracin constituyen otro tipo de diagrama de interaccin.
Muestran cmo operan los objetos de un grupo entre s en un caso de uso.
A cada mensaje se le asigna un nmero para documentar el orden en el que tiene
lugar.

5.-Diagrama de estados
El estado de un objeto se define como sus atributos en un momento determinado.
Los objetos van pasando por distintos estados a medida que se ven influenciados
por estmulos externos.
El diagrama de estados asigna estos estados, as como los eventos de activacin
que hacen que un objeto se encuentre en un estado determinado.

6.-Diagrama de actividades
12

 Los diagramas de actividades muestran la lgica que tiene lugar como respuesta a
las acciones generadas internamente.
Est relacionado con una clase o caso de uso especfico y muestra los pasos que se
deben realizar para llevar a cabo una operacin determinada.

7.-Diagrama de despliegue
Muestran cmo estn configurados el hardware y el software del sistema.

8.-Diagrama de componentes
Corresponden al modelo de implementacin.
Muestran cmo distintos subsistemas de software conforman la estructura general
del sistema que se crea en una base de datos centralizada que contiene registros de
alquileres anteriores, detalles del vehculo, registros de servicios y detalles del cliente
y del empleado.

13

 Resulta esencial que estos datos se centralicen en una base de datos porque los
niveles de stock varan con las horas y todas las partes deben disponer de informacin
de ltima hora.
El mantenimiento de los datos actualizados requiere actualizaciones de la
informacin en tiempo real de todas las partes.

UNIDAD N2
MODELO DE IMPLEMENTACION
Modelo de Implementacin:
Busca implementar cada objeto especfico en trminos de componentes (scripts, archivos
de cdigo binario ejecutables-,etc.).
Son herramientas fundamentales los lenguajes de programacin y las libreras.
Se toman los resultados del diseo para convertirlos en un software ejecutable; un
sistema que integra componentes expresados en archivos fuentes, ejecutables, cdigo binario y
similares dndole comportamiento concreto al modelo.
La implementacin es el proceso protagonista durante las iteraciones de la fase de
construccin. Observe que tambin se desarrolla trabajo de implementacin durante las fases de
elaboracin y transicin. Generalmente en estos casos, las actividades de implementacin dan
soporte a los flujos de anlisis y diseo mediante prototipos; y la correccin de errores empotrados
en el cdigo, respectivamente.
Los propsitos de este flujo de trabajo son los siguientes:

Planificar en pasos pequeos y manejables (enfoque incremental) las integraciones

de sistema necesarias en cada iteracin.

14


Definir la organizacin que tendr el cdigo en trminos de subsistemas y capas de
proceso, mostrando la asignacin de componentes ejecutables a nodos del diagrama de
despliegue.

Implementar clases y objetos en trminos de componentes (archivos de cdigo

fuente, archivos binarios, archivos ejecutables, etc.), mostrando la asignacin y
distribucin de los mismos en un diagrama de componentes.

Probar los componentes individuales implementados, compilando e integrndolos

en uno o ms ejecutables libres de errores.

Integrar los resultados producidos por desarrolladores individuales o equipos en un

sistema ejecutable.
Relacin con otros flujos de trabajo
Algunas vinculaciones entre el flujo de trabajo implementacin y los dems flujos de trabajo:

Todo el proceso de desarrollo propuesto por el PUD est conducido por casos de uso. En
este flujo de trabajo se producen modelos que realizan y tienen una traza definida hacia el modelo de
casos de uso obtenido en el flujo requerimientos.

Los artefactos producidos durante los flujos de trabajo anlisis y diseo son una
entrada primaria para el proceso desarrollado durante este flujo de trabajo.

En el flujo de trabajo pruebas se definen los casos de prueba que sern incluidos durante
cada una de las integraciones de subsistemas y sistemas que acontecen durante este flujo de trabajo.
2.1. Implementar el diseo
Cada clase del diseo es implementada codificando en un lenguaje de programacin, o
utilizando un componente preexistente. Por eso la manera en que una clase del diseo ser
concretamente implementada depende del lenguaje utilizado.
El modelo de diseo puede ser ms o menos ajustado al modelo de implementacin
dependiendo de cmo haga corresponder las clases o construcciones similares en el lenguaje de
implementacin elegido.
Es necesario disponer antes de que el diseo comience, la forma en que las clases en el
modelo de diseo se relacionan con las clases de implementacin asentando esta decisin en la Gua
de Diseo.
2.2. Las pruebas de desarrollo
La frase Prueba de Desarrollo es utilizada para categorizar las actividades de prueba
ejecutadas por los arquitectos, ingenieros de componentes, programadores o desarrolladores de
software.
En muchos de los mtodos tradicionales se consideran los siguientes tipos de pruebas:
Pruebas de unidad: prueba de cada componente individual
Pruebas de integracin: prueba de funcionamiento de subsistemas
Pruebas de Sistema: prueba de funcionamiento del sistema como un todo.
Esta categorizacin es correcta, sin embargo el problema surge cuando se decide integrar
los subsistemas y el sistema total cuando casi se ha concluido la codificacin de los componentes y
se definen equipos de pruebas que actuarn por etapas. Puede ser muy tarde, los errores podran
propagarse sin ser detectados por los diferentes equipos de prueba.
Las fallas descubiertas podran develar graves problemas de diseo y generar un alto grado
de retrabajo no deseable para los costos y oportunidad de entrega del producto final.
No espere terminar todos los componentes para integrar subsistemas y el sistema final. Lo
que sera peor an, no deje las pruebas de componentes para el final de la fase de construccin. En
cada iteracin, de la fase construccin, en cada construccin, an en la fase de elaboracin, haga
pruebas de integracin y pruebas de sistema.
2.3. Entornos de desarrollo e integracin
Un sistema generalmente es implementado por equipos de desarrolladores o programadores
individuales que trabajan juntos y en paralelo. Para que esto sea posible son necesarios los siguientes
espacios o entornos de trabajo:

Un entorno de desarrollo individual para cada programador:

A los efectos de editar, compilar, ejecutar y probar todos los componentes

y el subsistema asignado, cada programador tendr un entorno de trabajo
individual.

15

No es necesario que en este espacio el desarrollador disponga de los dems

subsistemas sobre los cuales no tiene responsabilidad.

Es recomendable por otra parte que cada programador tenga acceso

mediante un repositorio comn desde donde acceder a otros subsistemas y libreras
de uso compartido.
Un entorno de integracin de subsistemas para el grupo de desarrollo:
A veces equipos de implementadores desarrollan simultneamente sobre
el mismo subsistema. En este caso los primeros necesitan integrar sus
componentes en un subsistema antes de que el mismo pueda ser liberado
para su integracin al sistema total. Un miembro del equipo de desarrollo
acta como integrador, siendo su responsabilidad tambin su
mantenimiento y rendimiento.
Un entorno de integracin del sistema total:
Quin o quines cumplan con el rol de integrador debern contar con un
entorno de integracin del sistema total en el que puedan agregar los
componentes individuales y/o subsistemas que resultaran al cabo de cada
iteracin en una Construccin.

Flujo de trabajo de implementacin

Estructurar el Modelo de Implementacin es la primera actividad desarrollada en el marco

de la Implementacin.

Los flujos: requerimientos, anlisis y diseo ocurren con preeminencia en la Fase de

Elaboracin. En esa etapa comenzamos a dar forma al Modelo de Implementacin.

En cada iteracin, y en la medida en que avanzamos hacia la fase de Construccin donde

subsisten declinando su incidencia actividades de requerimientos, anlisis y diseo- toman mayor
protagonismo las de: Estructuracin del Modelo de Implementacin, Planeamiento de la Integracin,
Implementacin de Componentes, Integracin de los Subsistemas y el Sistema como un todo.

16

Actividades

3.1. Estructurar el modelo de implementacin

El propsito del flujo de trabajo Estructurar el Modelo de Implementacin es:

Identificar los componentes significativos arquitectnicamente (ejecutables).

Asignar componentes a los nodos de red.

El propsito de esta actividad desarrollada por el arquitecto de software es establecer la

arquitectura en la que se apoyar la implementacin y la asignacin de responsabilidades para
subsistemas de implementacin y sus respectivos componentes.

Un modelo de implementacin bien organizado resulta en la ocurrencia de un nmero

menor de conflictos durante el desarrollo de componentes y el proceso de construccin; tambin
previene problemas de configuracin y facilita las sucesivas integraciones de componentes y
subsistemas.
Trabajadores

Quien cumpla con el rol de arquitecto de software es quien tiene la principal

responsabilidad en la definicin de Modelo de Implementacin. La naturaleza del trabajo a
desarrollar sugiere que la o las personas que administran esta actividad posean experiencia en la
construccin, administracin de la configuracin y el lenguaje de programacin que se utilizar para
implementar el sistema.
Lineamientos de Trabajo

Estructurar el modelo de implementacin es algo que debemos hacer en paralelo con la

evolucin de otros aspectos de la arquitectura.

17


pasos:

La actividad Estructurar el Modelo de Implementacin a su vez contempla los siguientes

Crear el modelo de implementacin inicial

Ajustar los subsistemas de implementacin
Definir los imports referencias a otros componentes - necesarios para cada
subsistema.
Decidir cmo tratar los ejecutables.
Decidir cmo tratar los elementos de prueba.
Actualizar la vista de implementacin.

Crear el modelo de implementacin inicial

La primera versin del modelo de implementacin se obtiene como una copia espejada de
la ltima versin del Modelo de Diseo.
Los paquetes de diseo se expresan como subsistemas compuestos a su vez de
componentes y todos los archivos relacionados necesarios para implementarlos.
Considere que cada clase del diseo ser un componente implementado codificando en un
lenguaje de programacin o empleando un componente preexistente. La manera en que una clase del
diseo ser concretamente implementada depender del lenguaje utilizado.
Ajustar los subsistemas de implementacin

El propsito de este paso es adaptar la estructura del modelo de implementacin a

cuestiones tcticas relacionadas con el entorno de trabajo. Estas adaptaciones facilitan la
organizacin del equipo de trabajo y debe expresar, si hubiera, las restricciones del lenguaje de
programacin a utilizar.
Definir imports necesarios para cada subsistema

El objeto aqu es definir las dependencias y visibilidad de componentes entre subsistemas

o mdulos.

Generalmente, las dependencias en el modelo de implementacin son heredadas del

modelo de Diseo, excepto cuando la estructura del modelo de implementacin ha sido ajustada.

Se presenta la estructura de capas de los subsistemas en diagramas de componentes.

Decidir cmo tratar ejecutables

Los ejecutables y otros objetos derivados son el resultado de aplicar un proceso de

construccin sobre un subsistema de implementacin, y pertenecen lgicamente a dicho subsistema.

En el caso ms simple, para cada subsistema de implementacin habr un tem de

configuracin (nodo de la red) para cada ejecutable, y un tem de configuracin para contener los
fuentes y otros elementos utilizados para producirlo.

Desde el punto de vista del modelado, un conjunto de ejecutables producidos en un

proceso de construccin puede ser representado como un artefacto: el artefacto Construccin
asociado a un subsistema de implementacin dado.
Decidir cmo tratar los elementos de prueba

En general los componentes y subsistemas de prueba no son tratados en forma muy

diferente al del resto del software desarrollado.

Sin embargo, los componentes y subsistemas de prueba no forman parte del sistema
implantado, y por lo general no se entregan al cliente. Por lo tanto la recomendacin es aislar estos
componentes en una estructura de directorio o paquete, garantizando su visibilidad; pero facilitando
su eliminacin al momento de construir la versin operativa del software.
Actualizar la vista de implementacin

Este paso consiste bsicamente en la actualizacin del documento de Arquitectura de

Software y los diagramas correspondientes al modelo de implementacin.
3.2. Planear la integracin

En la planificacin de la integracin se consideran los subsistemas que sern

implementados as como otros subsistemas existentes que sern integrados en la iteracin corriente.

El propsito del flujo de trabajo Planear la Integracin es por lo tanto:

Planear la integracin del sistema para la actual iteracin.
Trabajadores

La integracin es hecha habitualmente por una persona o un pequeo equipo.

18

 Los integradores necesitan experiencia en la gestin de construcciones y

configuraciones de software; pero fundamentalmente se requiere que los mismos posean un
fluido manejo del lenguaje de programacin sobre el cual se desarrollaran los componentes.
Debido a que a menudo la integracin se desarrolla con un alto grado de
automatizacin, se requiere tambin conocimientos en sistemas operativos, interpretes de
comandos y herramientas.
Lineamientos de Trabajo

La planificacin de la integracin debe ser hecha tempranamente, al menos de modo

rudimentario cuando se define la arquitectura.

Con el objeto de evitar que el plan de construccin quede obsoleto, este debe ser
actualizado cada vez que sucedan modificaciones en la arquitectura y el diseo.

Al menos una vez por cada iteracin en las fases de construccin y transicin, quien
cumple con el rol de integrador, desarrolla esta actividad que tiene como objetivo principal el de
planear el modo en que han integrarse cada componente y cada subsistema en el sistema que se
construye.

Los siguientes son los pasos que comprenden esta actividad:

Identificar subsistemas
Definir conjuntos de construccin
Definir series de construccin.
Identificar Subsistemas

El plan de la iteracin identifica y especifica los subsistemas con sus respectivos casos de
usos y escenarios a ser implementados. En el plan se analizan tambin las realizaciones de
casos de uso, diagramas de secuencia y colaboracin. Se identifican tambin otros subsistemas
necesarios para facilitar la compilacin y crear una versin ejecutable del software.
Definir conjuntos de construccin

Para facilitar las cosas y manejar la complejidad se reduce el nmero de cosas sobre las
que es necesario pensar. En esta situacin es recomendable definir conjuntos significativos de
subsistemas que funcionan juntos y pueden considerarse como una unidad desde el punto de vista de
una integracin.
Definir series de construccin

Se define una serie de construcciones para integrar el sistema incrementalmente. Esto es

hecho de abajo hacia arriba en la estructura de capas del sistema que compone el modelo de
implementacin.

Por cada construccin, se definen cuales subsistemas deben ir en el y que otros

subsistemas deben estar disponibles en calidad de stubs componentes de utilidad para facilitar su
implementacin -.
3.3. Implementar componentes

Los implementadores escriben cdigo fuente, adaptan cdigo existente, compilan y

ejecutan pruebas de unidad de componentes, generando re trabajo para el diseador en caso de
detectarse errores atribuibles al mismo.

Los implementadores tambin corrigen defectos y vuelven a ejecutar pruebas de unidad

para verificar cambios. Finalmente el cdigo es revisado para evaluar calidad y cumplimiento de las
reglas que podran estar previstas en una gua de programacin.

El objeto principal del flujo de trabajo Implementar Componentes consiste en

Producir componentes de software ajustado a los requerimientos y libre de

errores.
Trabajadores

La actividad de programacin normalmente es desarrollada por una persona, sin embargo

propuestas metodolgicas actuales como XP Xtreme Programming- estn proponiendo que la
codificacin de cada componente sea realizada de a pares de programadores.

Recordar que las personas que cumplan este rol deben manejar fluidamente el lenguaje de
programacin adoptado.
Lineamientos de trabajo

La actividad de revisin es recomendable que la lleven a cabo pequeos equipos de dos o

tres personas que podran incluir miembros del rea usuaria y programadores experimentados.

19


Este trabajo tiene mejores resultados si se realiza en varias etapas, cada una enfocada en
pequeas secciones del cdigo.

Son ms productivas las revisiones frecuentes con un alcance acotado. En estas sesiones se
identifican los problemas especficos que necesitan ser resueltos. Las correcciones se implementan
al terminar la revisin.

El propsito principal de esta actividad es producir nuevo cdigo fuente o modificar el

existente de acuerdo a las especificaciones del modelo de diseo.

La actividad implementar componente a su vez contempla los siguientes pasos:

Implementar operaciones
Implementar Estados
Delegar para reutilizar
Implementar asociaciones
Implementar atributos
Hacer la revisin preliminar del cdigo.
Implementar operaciones

Para implementar operaciones hacemos lo siguiente:

Elegimos un algoritmo

Elegimos una estructura de datos apropiada para el algoritmo

Definimos nuevas clases y operaciones de ser necesario

Codificamos la operacin

Eleccin de un algoritmo: muchas operaciones son lo suficientemente simples para ser

implementadas directamente desde la especificacin de las mismas. En otros casos podra requerir un
algoritmo no trivial por alguna de las siguientes razones:
o Intentamos implementar operaciones complejas
o Queremos optimizar operaciones simples pero resueltas de modo ineficiente. Por ejemplo,
un componente que debe ordenar los elementos de una lista; por razones de perfomance,
podramos optar entre escribir nuestro propio algoritmo (burbuja, shell, dicotmicos, etc.)
o el provisto por el lenguaje de implementacin.

Eleccin de una estructura de datos apropiada para el algoritmo: la implementacin de la

estructura de datos para implementar el algoritmo va a depender del lenguaje elegido y podra recaer en
alguna de las siguientes: arrays, lists, queues, stacks, bags o variaciones de estas. La mayora de los
lenguajes orientados a objetos proveen libreras de componentes reusables con estos tipos.

Definicin de nuevas clases y operaciones: esto sucede cuando necesitamos nuevas clases
que mantengan resultados intermedios. Por ejemplo, al descomponer una operacin compleja en dos
operaciones ms simples. Estas operaciones sern privadas y visibles por lo tanto solo en el contexto de la
misma y no fuera de ella.

Codificar la operacin: escribimos el cdigo para la operacin empezando por las

sentencias que definen su interfase. Por ejemplo, la declaracin de funcin miembro en C++,
especificacin de subprogramas en Ada, mtodos en Visual Basic o Java.
Implementar estados

La manera ms sencilla de implementar el estado de un objeto es por referencia a los

valores de sus atributos sin ninguna representacin especial. La transicin de estados para un objeto
estar implcita en los cambios de valor de los atributos y las variaciones de comportamiento que
sern programadas a travs de sentencias condicionales. Esta solucin no ser satisfactoria para
comportamientos complejos debido a la dificultad implicada en una eventual modificacin del
comportamiento la necesidad de nuevos estados. Si el comportamiento de los componentes es estado
dependiente, podran ser necesarios diagramas de transicin de estados que describan su
comportamiento, faciliten su interpretacin y posterior codificacin.
Delegar para reutilizar

Si una clase o parte de una clase puede ser implementada reutilizando una clase existente,
se usa el mecanismo de delegacin en lugar de la herencia.

Delegacin significa que la clase es implementada con la ayuda de otra clase. La clase
referencia un objeto de otra clase utilizando una variable. Cuando una operacin es llamada, la
operacin llama una operacin del objeto referenciado -de la clase reutilizada-. Recuerde que en un
buen diseo de objetos, estos son bastante haraganes. Estn buscando todo el tiempo delegar la
responsabilidad a un especialista para que haga lo que a l se le ha pedido.

20

Implementar asociaciones

Una asociacin unidireccional es implementada como un puntero -un atributo que contiene
una referencia a un objeto-. Si la cardinalidad destino fuera uno, entonces esta puede ser definida
como un puntero simple. En cambio si la cardinalidad destino es muchos, entonces debe ser tratada
como un conjunto de punteros.

Una asociacin bidireccional es materializada como atributos en ambas clases procediendo

del mismo modo que se indic para asociaciones unidireccionales.

En cada lenguaje de programacin en particular podr descubrir mecanismos de asociacin

propios del entorno que se utiliza.
Implementar atributos

Existen tres maneras de implementar atributos:

A travs de variables primitivas incluidas en el lenguaje

Reutilizando una clase o componente existente

Por medio de una nueva clase.

Definir una nueva clase es a menudo ms flexible, pero tenga en cuenta que introduce una
indireccin innecesaria. Por ejemplo, el nmero de seguridad social de un empleado podra ser
implementado como un atributo de tipo String o como una nueva clase.

Podra darse tambin el caso que grupos de atributos se combinen en dos nuevas clases tal
como se muestra en el ejemplo siguiente donde ambas implementaciones son correctas:

Hacer la revisin preliminar del cdigo

Siempre se compila el cdigo, y se fija al mximo nivel de detalle los avisos del
compilador.

Se controla mentalmente las operaciones, recorriendo el cdigo tratando de encontrar todos

los caminos e identificando todas las condiciones de excepcin. Esto se lleva a cabo tan pronto como
se pueda despus de implementar algo nuevo.

Si fuera posible, se utiliza herramientas automticas de revisin.

3.4. Integrar cada Subsistema

Si ms de un implementador trabaja en la construccin del mismo subsistema, es necesario

crear regularmente una nueva versin consistente del subsistema para que en la misma se integren
los cambios producidos por cada desarrollador individual. El resultado de estas integraciones es
alojado en el entorno de integracin de subsistemas referido en el punto 2.3.

Una vez en este entorno de integracin cada construccin es probada, luego de lo cual, y
habiendo superado los requerimientos de calidad preestablecidos, la nueva versin del subsistema
pasa al entorno de integracin del sistema total.

Entonces el propsito de este flujo de trabajo es:

Integrar los cambios producidos por mltiples desarrolladores, creando una nueva
versin de un subsistema de implementacin.
Trabajadores

La integracin de cada subsistema es hecha habitualmente por una persona o un pequeo

equipo.

Los integradores necesitan experiencia en la gestin de construcciones y configuraciones

de software; pero fundamentalmente se requiere que los mismos posean un fluido manejo del
lenguaje de programacin sobre el cual se desarrollaran los componentes. Debido a que a menudo la
integracin se desarrolla con un alto grado de automatizacin, se requiere tambin conocimientos en
sistemas operativos, interpretes de comandos y herramientas.
Lineamientos de Trabajo

El trabajo de integracin tiene habitualmente un alto grado de automatizacin con esfuerzo

manual requerido solo cuando la construccin falla por alguna circunstancia. Una estrategia
frecuente es programar construcciones y pruebas de unidad mediante procesos automticos que se
ejecuten durante la noche.
3.5. Integrar el sistema

21


Siguiendo el plan de integracin de construcciones se agrega e integra cada subsistema en
el entorno de trabajo del sistema. De este modo se obtiene una nueva versin del software que es
sometida al flujo de trabajo de pruebas.

El propsito entonces de este flujo de trabajo es:

o Integrar subsistemas de implementacin para crear una nueva versin consistente del
sistema total.
Trabajadores

Rige lo mismo que en el item anterior.

Lineamientos de Trabajo

Rige lo mismo que en el item anterior.

4.4 Ejecucin de pruebas unitarias

El propsito principal de esta actividad es verificar la especificacin y la estructura interna

de una clase o del componente que lo implementa.

Los pasos principales de esta actividad son los siguientes:

Ejecutar pruebas unitarias
Evaluar la ejecucin de pruebas
Verificar resultados de pruebas
Recuperar a partir de pruebas suspendidas
Ejecutar pruebas unitarias

Este paso consiste en la ejecucin de procedimientos de prueba o scripts si las pruebas son
automatizadas.

El procedimiento mencionado consiste bsicamente en:

Establecer el entorno de prueba para asegurar que todos los elementos necesarios
tales como hardware, software, herramientas, datos, libreras, etc. han sido
previstos.
Inicializar el entorno de prueba para asegurar que todos los componentes estn en
el estado inicial correcto para el inicio de la prueba.
Ejecutar los procedimientos de pruebas.

La ejecucin de los procedimientos de prueba varan, lo cual depende tanto de si el mismo

es automtico, manual como de la necesidad de componentes Stubs y drivers especficos.

Pruebas automatizadas: se ejecutan los scripts creados durante el paso Implementar

Pruebas del Subflujo Implementar Componentes.

Pruebas Manuales: se utilizan los procedimientos desarrollados durante la actividad

Estructurar Procedimientos de Pruebas que son usados para ejecutar manualmente la prueba.
Evaluar la ejecucin de pruebas

Este paso tiene el propsito de determinar si las pruebas concluyeron con xito, y tener una
visin clara de la accin correctiva requerida.

La ejecucin de las pruebas termina en alguna de las siguientes condiciones.

Normal: todos los procedimientos de pruebas (o scripts) se ejecutaron como se
proyect. Si la prueba termina en condicin normal, entonces se debe continuar
con la Verificacin de Resultados de Pruebas.
Anormal o prematuro: los procedimientos de pruebas o scripts no se ejecutaron
completamente como se haba previsto. Cuando la prueba termina de modo
anormal los resultados de la prueba pueden ser poco fiables. Hay que identificar la
causa del error, corregirlo y re ejecutar el test.
Si la prueba termina de modo anormal, se debe retomar en el paso
Recuperacin a partir de pruebas suspendidas.
Verificar resultados de pruebas

El propsito de este paso es determinar si el resultado de la prueba es confiable e

identificar las acciones correctivas si los resultados indican fallas.

Cuando la prueba termina, se revisan los resultados para asegurar que los mismos son
confiables, que las advertencias de compilacin (warnings), o resultados inesperados, no han sido
ocasionados por influencias externas tales como una inicializacin o datos incorrectos. Si las fallas
reportadas se deben a errores identificados en artefactos de prueba o debido a problemas con el

22

entorno de prueba, se toman las acciones correctivas apropiadas y se ejecuta la prueba nuevamente.
Si los resultados indican que las fallas son genuinamente atribuibles a los artefactos probados
entonces se contina con la actividad Corregir Errores.
Recuperar a partir de parada de pruebas

En este caso la meta ser determinar las acciones correctivas apropiadas para reiniciar una
prueba detenida, corregir el problema, recuperar y ejecutar la prueba nuevamente.

Esta parada puede deberse a fallas en los scripts utilizados para lanzar pruebas, en fallas
del sistema tales como cadas de red, cadas de hardware, etc. En todos estos casos los sntomas son
parecidos:

acciones inesperadas, ventanas emergentes y eventos no previstos.

El entorno de prueba parece no responder y hasta podra colgarse el sistema.

Para recuperar a partir de una situacin como sta debera:
Determinar la causa real del problema.
Corregir el problema.
Inicializar el entorno de pruebas nuevamente.
Ejecutar las pruebas nuevamente.
4.5 Corregir defectos

El propsito principal de esta actividad es implementar las correcciones al cdigo

documentadas en el documento de requerimientos de cambios durante las actividades de pruebas
unitarias de componentes y revisiones de cdigo.
Los pasos principales de esta actividad son:

Estabilizar el defecto.

Localizar la falla.

Corregir la falla.
Estabilizar el defecto

Este es el primer paso, exteriorizado como un sntoma del programa, forzando su

ocurrencia en forma efectiva. Si no se puede lograr que el error suceda efectivamente, estamos ante
complicaciones y ser mucho ms difcil localizarlo.

Luego se limita el caso de prueba identificando cul de los factores del caso de prueba
hacen que el error ocurra, y cuales factores son irrelevantes al mismo. Para determinar si un factor es
irrelevante, se cambia el factor en cuestin y ejecuta el caso de prueba; si el error an as ocurre, este
factor puede ser probablemente eliminado.

Si se logr, se finaliza con al menos un caso de prueba que reproduce el error y tambin
con alguna idea sobre que factores estn relacionados con la ocurrencia del error.
Localizar la falla

El prximo paso es ejecutar los casos de prueba que originan la falla e intentar identificar
el lugar concreto del cdigo donde se produce el fallo. Ejemplos de cmo localizar una falla son:
Ponga atencin a la regin sospechosa del cdigo. Pruebe una pequea parte de l,
comente para que no se ejecute la o las sentencias que supone producen el error
y corra nuevamente el caso de prueba. Contine comentando pedazos del
programa mientras el error persista. Como resultado se podr identificar el lugar
preciso donde se produce la falla.
Utilice un debugger herramienta provista por un entorno de desarrollo de un
lenguaje de programacin para localizar un error para revisar el cdigo lnea por
lnea y monitorear los valores de variables significativas del programa.
Corregir la falla

Cuando la falla ha sido localizada es momento de corregir el cdigo. Esta debiera ser la
parte ms fcil del proceso.

Las siguientes son algunas recomendaciones para hacer efectiva la correccin:

Asegrese de comprender el problema y el programa antes de efectuar la

correccin.

Corrija el problema, no el sntoma.

Haga un cambio a la vez. Corregir errores es en si misma una actividad

propensa a incluir nuevos errores. Introduzca los cambios incrementalmente para
facilitar la localizacin de nuevas fallas.

23


Cuando la falla ha sido corregida agregue un caso de prueba especial que
verifique particularmente el error.
5. Artefactos
5.1 Modelo de implementacin

El modelo de implementacin describe la forma en que los elementos del modelo de

diseo, como las clases, se implementan en trminos de componentes, como archivos de cdigo
fuente, ejecutables, etc.

Describe tambin cmo se organizan los componentes de acuerdo con los mecanismos de
estructuracin y arquitectura de mdulos disponibles en el entorno de implementacin y en el
leguaje lenguajes de programacin utilizados, y cmo dependen los componentes unos de otros.
5.2 Construccin

Una Construccin es una versin operativa de parte o de un sistema completo que

demuestra un subconjunto de capacidades o funcionalidades propias del producto final.

Es una expresin concreta y resultante del ciclo de vida iterativo. Representa y demuestran
la funcionalidad desarrollada a la fecha.

Cada Construccin es puesta bajo el mecanismo de control de configuracin con el objeto

de retornar eventualmente a versiones previas cuando el agregado de funcionalidad ocasiona
problemas de funcionamiento o compromete la integridad y estabilidad del sistema.

Durante el desarrollo iterativo del software podr haber numerosas construcciones. Cada
una proveer puntos de revisin y ayudar a descubrir problemas de integracin en la medida que
los mismos han sido introducidos.
5.3 Componente

Un componente es el empaquetamiento fsico de los elementos de un modelo, como son

las clases en el modelo de diseo. Algunos estereotipos estndar de componentes son los siguientes:
<<Ejecutable>>: es un programa que puede ser ejecutado en un nodo.
<<File>>: es un archivo que contiene cdigo fuente o datos.
<<Library>>: es una librera esttica o dinmica. (dlls)
<<Tabla>>: es una tabla de base de datos.
<<Documento>>: es un documento.

Durante la creacin de componentes en un entorno de implementacin particular estos

estereotipos pueden ser modificados para reflejar el significado real de estos. Los componentes
tienen las siguientes caractersticas:
Relacin de traza con los elementos del modelo que implementan.
Implementacin de varios elementos.

Por ejemplo, un componente podra implementar varias clases, sin embargo, la forma
exacta en que se crea esta traza depende de cmo van a ser estructurados y armados en mdulos los
archivos de cdigo fuente, dado el lenguaje de programacin que se est utilizando.
5.4 Stubs

Un componente es probado remitiendo mensajes a su interfase, esperando que este lo

procese y revisando el resultado. En el transcurso de este proceso, muy habitualmente, se utilizan
otros componentes enviando tambin mensajes y utilizando sus resultados. Estos ltimos
componentes pueden ocasionar problemas a la prueba:
Por no haber sido an implementados.
Por tener errores de funcionamiento, ocasionando confusin sobre el origen de los
problemas.
Porque uno o ms componentes de hardware podran no estar disponibles para el
programador. Piense por ejemplo en un sistema de control de accesos en el que los
dispositivos de lectura de las tarjetas magnticas o mecanismos de apertura de
puertas podran no disponerse por los programadores.
Debido a que la prueba podra tornarse muy lenta cuando por ejemplo necesita
inicializar una base de datos.
Ya que es muy difcil provocar ciertos resultados. Piense por ejemplo que todos
los mtodos de sus clases que escriben en disco validan previamente el espacio
disponible. Ocasionar la situacin Sin espacio en disco podra ser una tarea
bastante engorrosa.

24


Para evitar estos problemas utilizamos los componentes Stubs, los cuales se comportan
como si fueran los componentes reales, al menos para los valores o mensajes que su componente
enva al momento de la prueba. Con una perspectiva ms amplia podramos considerar en esta
categora a emuladores que simulan el comportamiento real de otros componentes no disponibles.
5.5. Subsistema de implementacin

Los subsistemas de implementacin proporcionan una forma de organizar los artefactos

del modelo de implementacin en trozos ms manejables. Un subsistema puede estar formado por
componentes, interfaces y otros subsistemas, inclusive en forma recursiva. Adems, un subsistema
puede implementar -y as proporcionar- las interfases que representan la funcionalidad que exportan
en forma de operaciones.

Los subsistemas de implementacin estn muy relacionados con los subsistemas de diseo
en el modelo de diseo visto anteriormente. De hecho, los subsistemas de implementacin deberan
seguir la traza uno a uno de sus subsistemas de diseo correspondientes.

5.6 Interfases

Las interfases, ya definidas como artefactos en el Flujo de Trabajo Diseo, pueden ser
utilizadas en el modelo de implementacin para especificar las operaciones realizadas por
componentes y subsistemas.

Adems como se mencion anteriormente los componentes y los subsistemas pueden tener
dependencias de uso sobre interfases.

En este caso las interfases no son necesariamente pantallas sino que podramos entenderlas
como conectores o facilitadores de acceso a los elementos de un modelo. La definicin de estos
conectores puntos de enlace se implementan de acuerdo al lenguaje utilizado. La firma (visibilidad,
nombre, argumentos de entrada / salida) de una clase en c++ o en java son la interfase de acceso a las
mismas.
5.7. La vista del modelo implementacin

La vista de implementacin es una de las cinco vistas arquitectnicas de un sistema. Las

otras son la vista lgica, vista de casos de uso, vista de procesos y vista de despliegue.

El propsito de la primera es capturar las decisiones de arquitectura hechas para la

implementacin.

Tpicamente la vista de implementacin contiene:

Una enumeracin de todos los subsistemas del modelo de implementacin.
Diagramas de componentes ilustrando cmo los subsistemas estn organizados en
capas y sus jerarquas.
Ilustraciones de las dependencias de importacin entre subsistemas.

La vista de implementacin es utilizada para:

Asignar trabajo de implementacin a programadores individuales, equipos de
programadores subcontratistas.
Evaluar la cantidad de cdigo a ser desarrollado, modificado o eliminado.
Analizar la reutilizacin a gran escala.
Considerar estrategias del la versin en desarrollo.

Tanto la vista de implementacin como las otras vistas de arquitectura son documentadas
en el Documento de Arquitectura del Software.
6. Trabajadores
6.1 Arquitecto de Software

El arquitecto de software tiene por sobre todo y principalmente la responsabilidad de

manejar las decisiones tcnicas respecto de la arquitectura del software. Tpicamente el arquitecto
identifica y documenta los aspectos significativos de la estructura del sistema, incluyendo las vistas
de requerimientos, diseo, implementacin y puesta en marcha del mismo.

El arquitecto es responsable de tomar decisiones razonables, atenuando los conflictos que

pudieran plantearse a partir de los intereses particulares de cada apostador - stakeholder - del
sistema. Es tambin su obligacin manejar adecuadamente los riesgos tcnicos y asegurar que las

25

decisiones de ste tipo son convenientemente comunicadas, validadas y compartidas por los
miembros del equipo de trabajo.
6.2 Implementador

El rol del implementador o programador consiste fundamentalmente en el desarrollo y

prueba de componentes en concordancia con los estndares adoptados en el proyecto para su
posterior integracin en un subsistema mayor. Cuando son necesarios componentes de prueba tales
como drivers stubs es el mismo programador el responsable de su desarrollo y prueba para
incorporarlos en los subsistemas de apoyo.
6.3 Integrador de Sistemas

Los integradores son responsables de planificar y realizar la integracin de elementos de

implementacin para producir construcciones o versiones ejecutables del sistema.

Tal como se dijo en el punto 2.3 los implementadores liberan sus programas probados en
un espacio de integracin de subsistemas donde el integrador los combina para producir una
construccin de un mdulo o paquete del sistema. El integrador es responsable tambin de planear la
integracin que tiene lugar una vez finalizada la del nivel de subsistemas. Efectivamente, los
subsistemas o mdulos obtenidos son agregados e integrados posteriormente en otro espacio de
trabajo correspondiente al sistema total.

UNIDAD N3
MODELO DE PRUEBAS
Propsito de las pruebas

Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas de integracin y
las pruebas de sistema.

Las pruebas de integracin son necesarias para cada construccin dentro de la iteracin;
mientras que las pruebas de sistema son necesarias slo al final de la iteracin.

Disear e implementar las pruebas creando los casos de prueba que especifican qu probar,
los procedimientos de prueba que detallan cmo realizar las pruebas y si es posible, componentes de
prueba ejecutables para automatizar las pruebas.

Realizar las diferentes pruebas y manejar los resultados de cada una de ellas
sistemticamente.

Las construcciones en las que se detectan defectos son probadas de nuevo y posiblemente
devueltas a otro flujo de trabajo, como diseo o implementacin, de forma que los defectos
importantes puedan ser arreglados.
Relacin con otros flujos de trabajo

El flujo de trabajo requerimientos captura los requisitos para los productos de software.
Estos requerimientos son el punto de partida y entrada principal de la actividad de identificacin de
las pruebas a realizar.

El flujo de trabajo anlisis y diseo determina el diseo apropiado para el producto de

software; esta es otra entrada importante del proceso de identificacin de las pruebas a realizar.

El flujo de trabajo implementacin produce construcciones del producto de software que

son validadas por el flujo de trabajo pruebas. Dentro de una iteracin varias construcciones podran
ser testeadas. habitualmente una por ciclo de pruebas.

2.1. Psicologa y economa de las pruebas

Cuando se prueba un programa se desea agregarle algn valor -es decir, puesto que
la prueba es una actividad costosa, se desea un incremento del valor del programa.

Agregar valor significa aumentar su calidad o su confiabilidad, lo que, a su vez,

significa encontrar y eliminar errores. De aqu que no se deba probar un programa para
mostrar que funciona; ms bien es conveniente comenzar con la suposicin de que el
programa contiene errores y luego probar el programa para encontrar tantos como sea
posible.

Puesto que los seres humanos tendemos a estar fuertemente orientados hacia la
obtencin de metas, el establecimiento de una de ellas en forma apropiada tiene gran
importancia desde el punto de vista psicolgico.
26


Si la nuestra es demostrar que el programa no tiene errores, estaremos entonces
subconscientemente dirigidos hacia este fin, es decir, tenderemos a seleccionar datos de
prueba con baja probabilidad de hacer que el programa falle.

Si nos proponemos demostrar que el programa tiene errores, nuestros datos de

prueba tendrn una mayor probabilidad de lograrlo.

Esta ltima manera de enfocar el problema agrega al programa mayor valor que la
primera. Un caso de prueba que descubre un error difcilmente pueda ser considerado como
no exitoso; mas bien, ha demostrado ser una valiosa inversin.
2.2. Conceptos bsicos
Testing de software

Realizar testing de software no es debuggear un cdigo, ya que el objetivo es encontrar los

problemas, pero no el origen de los mismos, aunque puede ocurrir que en algunas ocasiones los
encuentre (luego de encontrar el problema se buscar el origen).

Tampoco es la demostracin de que en dicho software no hay errores.

Testear o probar un software es someterlo a ciertas condiciones a fin de demostrar si es

vlido o no a partir de los requerimientos que le dieron origen, es decir, si satisface los
requerimientos definidos (validacin), ya que podra ocurrir que un software no tuviera defectos
pero que tampoco realizara la funcionalidad especificada y acordada con el usuario.

Implica la verificacin de que dichas funcionalidades se implementan correctamente.

Testing es una actividad destructiva, y el mismo es exitoso en la medida que descubre

defectos en el software.

Esta actividad, definitivamente agrega valor (calidad) al producto, y an ms, si se

analizan los resultados, tambin al proceso de desarrollo utilizado.

Podra decirse que un software no tiene calidad por ejemplo cuando el sistema se cancela
inesperadamente, no cumple las funcionalidades requeridas por los usuarios, implementa dichas
funcionalidades en forma incorrecta, sus respuestas son lentas, es difcil de utilizar (no es amigable),
permite cometer errores, es difcil entender el cdigo fuente, slo quien lo construy puede
modificarlo, es ms complejo de lo necesario, no se sabe bien cmo probarlo, entre otros.

La calidad es un resultado del esfuerzo hecho durante todo el desarrollo, aumentar la

cantidad de las pruebas no aumenta necesariamente la calidad del sistema software.

Testing es una de las barreras para evitar que productos software de baja calidad lleguen a
clientes.

En un cdigo que estamos probando se pueden encontrar errores que causan defectos, los
cuales muestran fallas.
Falla (failure)

Es una diferencia entre los resultados (comportamientos) reales y los esperados.

Se da por ejemplo cuando un programa no se comporta como se esperaba que lo hiciera.
Puede ser interna o externa.
Una falla interna aparece antes de liberar el producto al cliente (considrese aqu
el concepto de cliente externo y cliente interno).
Una falla externa aparece luego de entregar el producto al cliente (externo o
interno).

Las fallas aparecen a partir de los casos de prueba.

Las fallas pueden ser:

Catastrficas: no se logra la salida esperada porque el software se cancela sin
producirla o sin haberla completado.
Funcional: los valores obtenidos como resultado difieren de los esperados.
Propiedad: hace referencia al incumplimiento de una propiedad que se haba
definido como importante, por ejemplo, un tiempo de respuesta mayor al definido
es una falla de propiedad de desempeo.
Formato: la salida puede mostrar los resultados esperados, pero la forma de la
misma no es correcta.

La tipificacin de la falla siempre se hace en la mayor categora que esta pueda alcanzar,
por ejemplo, si la falla es de propiedad y funcional (tal es el caso de un conjunto de datos que se
obtienen en un tiempo mayor al esperado y con datos errneos), la misma ser catalogada como

27

funcional (ya que un conjunto de datos errneos puede obtenerse a la velocidad que se desea y an
as la falla no se habr solucionado). A pesar de esto la falla debe describirse completamente.
Defecto (fault)

Se presenta en el cdigo y puede mostrar o causar una falla.

Si el sistema no falla no hay defectos.
Un defecto ocasiona de 0..n fallas.

Error (mistake)

Es cualquier equivocacin humana en un sistema software que genera defecto/s. El mismo

ser encontrado por el desarrollador

2.3. Tipos de prueba

Para encarar el proceso de pruebas de cada componente, subsistema o sistema es necesario

determinar la estrategia que ha de aplicarse.

Se presenta a continuacin dos maneras de focalizar el anlisis del software en busca de

defectos de construccin.

Pruebas tipo caja negra

Una forma de examinar el funcionamiento de un programa consiste en tomar solamente los

datos de entrada y salida obtenidos con los primeros.

La persona que efecta la prueba considera el programa como una caja negra, es decir, se
desentiende completamente del comportamiento y estructura internos.

Su inters se dirige nicamente a encontrar circunstancias en las cuales el programa no se

comporta de acuerdo con sus especificaciones, es decir sin aprovechar el conocimiento de la
estructura interna del programa.

Si el objetivo es hallar todos los errores en un programa, el criterio ser probar la entrada
de datos exhaustivamente. Esto implica emplear toda posible condicin de entrada como un caso de
prueba.

Pruebas tipo caja blanca

Las pruebas de caja blanca o lgicas, permiten examinar la estructura interna de los
programas.

Usndola el operador de la prueba obtiene datos de prueba a partir del examen de la lgica
del programa.

Una prueba exhaustiva de secuencia no garantiza de ninguna manera que el programa

cumpla con su especificacin. Por ejemplo, si se pide hacer una rutina para ordenar valores
numricos en orden creciente y en forma inadvertida se escribe la rutina para trabajar en forma
decreciente, entonces una prueba exhaustiva de secuencia podr ser de muy escasa ayuda para
descubrir el error.

Un programa puede ser incorrecto por causa de secuencias faltantes. Por supuesto, una
prueba exhaustiva de secuencias no detectar la falta de secuencias lgicas necesarias.

Una prueba de este tipo podr no detectar errores de sensitividad de los datos.

Existen muchos ejemplos de estos errores, pero bastar con presentar uno simple.

Suponga que en un programa se deben comparar dos nmeros para detectar una
convergencia, es decir determinar si la diferencia entre los dos nmeros es menor que un valor
predeterminado.

Se podra escribir la sentencia en la forma siguiente:

Por supuesto, esta sentencia contiene un error porque deberamos comparar EPSILON con
el valor absoluto de A-B y no se lo detectar necesariamente ejecutando cada secuencia lgica
posible dentro del programa.

En conclusin, aunque la prueba exhaustiva de entrada (caja negra) es superior a la prueba

exhaustiva de secuencia (caja blanca), ninguna de ellas resulta ser una estrategia til porque ambas
son impracticables. Existen, sin embargo, modos de combinar elementos de ambos mtodos para
llegar a una estrategia razonable, aunque no sea perfecta. Esto es lo que esperamos aportar con el
contenido metodolgico planteado en esta unidad.
2.4. Etapas de Prueba

Las pruebas se aplican con distintos niveles de esfuerzo y enfoques en el ciclo de vida de
desarrollo del software.

28


Es muy importante tener un enfoque adecuado en cada un de los momentos del proyecto.
Pruebas de desarrollo

Las pruebas de desarrollo se focaliza sobre los aspectos de test ms apropiados para ser
encarados por los propios desarrolladores del proyecto. En contraste, las pruebas de sistema
mencionadas ms adelante, pueden ser encaradas por un grupo independiente de pruebas.

Tradicionalmente, las pruebas de desarrollo han sido concebidas como pruebas de unidad
con foco ocasional en aspectos de integracin e infrecuentemente otros aspectos de prueba. Seguir
con este criterio tradicional presenta riesgos en la calidad del software. A menudo aspectos que
corresponden a los lmites de esta categorizacin son ignorados. En particular las pruebas de
desarrollo han sido tratadas en la unidad 3 en el flujo de trabajo implementacin.

La mejor estrategia es dividir el esfuerzo de trabajo de pruebas a los fines de tener cierta
superposicin natural cuya magnitud depende de cada proyecto en particular. Lo que resulta
insoslayable y recomendable siempre es que tanto los desarrolladores como el grupo independiente
de pruebas del sistema compartan una misma visin de calidad.
Pruebas de unidad

Las pruebas de unidad de una iteracin se enfocan en la verificacin de los ms pequeos

elementos del software. Se aplica a componentes del modelo de implementacin para comprobar
que el flujo de control y de datos esperados han sido contemplados y funcionan como se espera.
Estas expectativas se basan en como el componente participa en la ejecucin de un caso de uso.
Recuerde que tanto los diagramas de secuencia como los de colaboracin, construidos a partir de los
casos de uso permiten visualizar el desempeo (colaboracin) de cada componente. Los detalles de
las pruebas de unidad son abordados en el flujo de trabajo Implementacin.
Pruebas de integracin

Las pruebas de integracin son hechas para asegurar que los componentes del Modelo de
Implementacin funcionan armnicamente cuando son combinados para ejecutar un caso de uso. El
alcance de la prueba es tpicamente un paquete o un grupo de paquetes del modelo de
implementacin. Estos paquetes podran originarse en distintos grupos de desarrollo. Las pruebas de
integracin exponen las omisiones o errores de especificacin de sus respectivas interfaces.
Pruebas de sistema

Las pruebas de sistema indican los aspectos del esfuerzo de prueba a ser abordados
preferentemente por un grupo independiente de desarrollo que no particip en la implementacin del
cdigo. Normalmente estas pruebas son realizadas cuando el sistema ya funciona como un todo. El
ciclo de vida iterativo permite que estas pruebas se desarrollen tan pronto como sea posible con un
conjunto estabilizado de casos de usos.
Pruebas de aceptacin

Las pruebas de aceptacin son la prueba final que antecede a la entrega del software. El
objetivo aqu es verificar que el software est listo y puede ser utilizado por los usuarios finales en el
desarrollo de esas funciones y tareas para las que el fue construido.

Habitualmente las pruebas de aceptacin adoptan alguna de estas tres modalidades:

Aceptacin formal.

Aceptacin informal o test alfa.

Aceptacin beta o test beta.

La eleccin de la estrategia habitualmente obedece a los requerimientos contractuales, el

dominio de la aplicacin y los estandares organizacionales.
Aceptacin formal

La prueba de aceptacin formal es un proceso cuidadosamente administrado. Los tests son

planeados y diseados con el mismo nivel de detalle que las pruebas del sistema.

Los casos de prueba elegidos deben ser un subconjunto de los utilizados para la prueba del
sistema. Es importante no desviarse de ninguna manera de los casos de prueba elegidos, y la
presencia indispensable, en este caso, de los usuarios finales. Las actividades y artefactos producidos
en la prueba de aceptacin formal son los mismos que se emplearon en la prueba del sistema.

Los beneficios de este tipo de pruebas de aceptacin son:

Las funciones y caractersticas a ser probadas son conocidas.
Los detalles de las pruebas son conocidos y pueden ser medidos.

29

 Los tests pueden ser automatizados.

El progreso de la prueba puede ser medido y monitoreado.
El criterio de aceptacin es conocido.

Las desventajas:
Requiere importante cantidad de recursos y planeamiento.
La prueba se puede convertir en una re implementacin de la prueba del sistema.
Podra no descubrir defectos subjetivos del software, ya que solo se buscan
defectos esperados.
Aceptacin informal

En las pruebas de aceptacin informal los procedimientos de test no son tan rigurosamente
definidos como en las pruebas de aceptacin formal. Las funciones y aspectos de negocio a ser
evaluadas se identifican y documentan pero no tienen los casos de prueba particular a seguir como
en el caso anterior. Quien est probando determina no solo que hacer sino tambin la aprobacin
cuando se encuentra satisfecho.

Los beneficios de esta forma de prueba de aceptacin son:

las funciones y caractersticas a ser probadas son conocidas.
El progreso de la prueba puede ser medido y monitoreado.
El criterio de aceptacin es conocido.
Podra descubrir defectos subjetivos del software, ya que la eleccin de los casos
de prueba es aleatorio y podrn aparecer defectos no esperados.

Las desventajas
se requieren recursos, planeamiento y administracin.
No se tiene control sobre los casos de prueba a ser utilizados.
Los usuarios finales podran dar su conformidad sin detectar defectos.
Los usuarios finales tienden a focalizarse en la comparacin del nuevo sistema con
uno anterior perdiendo prioridad la bsqueda de defectos.
Aceptacin Beta

De las tres modalidades de pruebas de aceptacin la denominada Test Beta es la menos

controlada. El nivel de detalle, los datos y forma de encarar la prueba es determinada por cada
probador individual. Cada probador es responsable de la creacin del entorno, seleccin de datos,
determinacin de funciones y caractersticas a explorar. Adems determina su propio criterio de
aceptacin. Esta modalidad es enteramente implementada por los usuarios finales y como podr
apreciar es la forma ms subjetiva de aceptacin.
Los beneficios de esta forma de prueba de aceptacin son:
La prueba es enteramente implementada por los Usuarios Finales.
Hay disponibilidad de potenciales probadores.
Se incrementa la satisfaccin de los usuarios que participan.
Se descubren ms defectos de aparicin subjetiva que las dos modalidades
anteriores.

Las desventajas:
No todas las funciones y/o caractersticas pueden ser probadas.
El progreso de la prueba es difcil de ser medido.
Los usuarios finales pueden conformarse con el funcionamiento del sistema sin
ver ni reportar defectos.
Los usuarios finales tienden a focalizarse en la comparacin del nuevo sistema con
uno anterior en lugar de buscar defectos.
Los recursos necesarios para la prueba podran escapar al control del proyecto.
El criterio de aceptacin no es conocido.
3. Flujo de trabajo de prueba

El principal objetivo de ste flujo de trabajo es realizar y evaluar el resultado de las

pruebas.

Esta tarea consiste fundamentalmente en planificar el esfuerzo de cada iteracin, luego se

describen los casos y procedimientos necesarios para llevar a cabo las comprobaciones, hecho esto,

30

los desarrolladores implementan los componentes y stubs necesarios para dar la mayor
automatizacin posible al proceso.

Todo esto se hace para cada construccin entregada como resultado del flujo de trabajo de
implementacin.
Finalmente, con estos casos, procedimientos y componentes de prueba como entrada, los
ingenieros de pruebas de integracin y de sistema evalan cada construccin y detectan
cualquier defecto que encuentren en ellos.
Las fallas sirven como realimentacin tanto para otros flujos de trabajo, como el de diseo
y el de implementacin, como para los ingenieros de pruebas a fin de que lleven a cabo una
evaluacin sistemtica de los resultados de las pruebas.
3.1. Planificar pruebas

Aqu se produce la planificacin general del proceso de pruebas. Se especifican

estimaciones de los requerimientos de recursos humanos y sistema necesarios, as como la
determinacin de una estrategia adecuada.

El propsito principal de este flujo es:

Identificar los objetivos y entregables del esfuerzo de pruebas.
Identificar una buena estrategia de utilizacin de recursos.
Definir los lmites y alcances del proceso.
Delinear el mtodo que ser usado.
Definir el modo y criterio con el que el proceso ser seguido y evaluado.

31


Cuando preparan el plan de prueba los ingenieros de prueba se mueven sobre un rango de
valores de entrada. El modelo de casos de uso y los requisitos adicionales ayudan a decidirse por un
tipo adecuado de pruebas y a estimar el esfuerzo necesario para llevarlas a cabo.

El diseador de pruebas usar tambin otros artefactos de entrada, como por ejemplo el
modelo de diseo.

Los diseadores de pruebas desarrollan una estrategia de prueba para la iteracin, es decir,
deciden que, y cuando ejecutar los tipos de prueba y determinar si el esfuerzo de prueba tiene xito.
En el siguiente ejemplo se define una estrategia de prueba de sistema para una ltima iteracin en la
fase de elaboracin.

Al menos el 75 por ciento de las pruebas deber estar automatizado. El resto podr ser
manual.

Cada caso de uso ser probado para su flujo normal y para tres flujos alternativos.

Criterio de xito: 90 por ciento de los casos de prueba pasados con xito.

No habr ningn defecto de prioridad medio-alta sin resolver.

El desarrollo, realizacin y evaluacin de cada caso procedimiento y componente de

prueba lleva algn tiempo y cuesta dinero. Sin embargo, ningn sistema puede ser probado
completamente, por tanto, deberamos identificar los casos, procedimientos y componentes de
prueba con un mayor retorno a la inversin en trminos de mejora de calidad. El principio general
consiste en desarrollar casos y procedimientos de prueba con un solapamiento mnimo para evaluar
los casos de uso ms importantes y tambin los requisitos que estn asociados a los riesgos ms
altos.
3.2. Disear prueba

Los propsitos de disear las pruebas son:

Identificar y describir los casos de prueba para cada construccin.
Identificar y estructurar los procedimientos de prueba especificado cmo realizar
los casos de prueba.
Diseo de los casos de prueba de integracin

Los casos de prueba de integracin se utilizan para verificar que los componentes
interaccionan entre s de la forma apropiada despus de haber sido integrados en una construccin.

La mayora de los casos de prueba de integracin pueden ser derivados de las

realizaciones de casos de uso-diseo, ya que las realizaciones de casos de uso describen cmo
interaccionan las clases y los objetos, y por tanto cmo se relacionan tambin los componentes entre
s.

32


Los ingenieros de pruebas deben crear un conjunto de caso de prueba que hiciera posible
alcanzar los objetivos establecidos en el plano de prueba con un esfuerzo mnimo. Para esto, los
diseadores de prueba intentan encontrar un conjunto de caso de prueba con un solapamiento
mnimo, cada uno de los cuales procura un camino o escenario interesante a travs de una
realizacin de caso de uso.
Diseo de los casos de prueba del sistema

Las pruebas de sistemas se usan para verificar que el sistema funciona correctamente como
un todo. Cada prueba de sistema prueba principalmente combinaciones de caso de uso instanciados
bajo condiciones diferentes. Estas condiciones incluyen diferentes:
configuraciones hardware (procesadores, memoria principal, disco duro, etc.),
diferentes niveles de carga del sistema, diferentes nmeros de actores y diferentes
tamaos de la base de datos.

Cuando se desarrollan los casos de prueba de sistema los diseadores de prueba deberan
dar prioridad a las combinaciones de los casos de uso que:
se necesitan que funcionar en paralelo.
Posiblemente funcionen en paralelo.
Probablemente se influencian mutuamente si se ejecutan en paralelo.
Involucran varios procesadores.
Usan frecuentemente recursos del sistema, como procesos, procesadores, bases de
datos y software de comunicaciones, quizs en formas complejas e impredecibles.

Pueden encontrarse, por lo tanto, muchos casos de prueba de sistema considerando los
casos de uso, especialmente considerando sus flujos de eventos y sus requisitos esenciales, como los
requisitos de rendimiento.
Diseo de los casos de prueba de regresin

Algunos casos de prueba de construcciones anteriores se adoptan para pruebas de regresin

en construcciones subsiguientes, aunque no todos son adecuados.

Para ser adecuados y contribuir a la calidad del sistema deben ser suficientemente flexibles
y ser resistentes a cambios en el software que est siendo probado.

La flexibilidad requerida en un caso de prueba de regresin puede suponer un esfuerzo de

desarrollo extra, lo que significa tener cuidado y convertirlos en caso de prueba de regresin
nicamente cuando el esfuerzo merezca la pena.
Identificacin y estructuracin de los procedimientos de prueba

Los diseadores pueden trabajar cada caso de prueba y sugerir procedimientos de

comprobacin para cada uno. Intentamos emplear procedimientos de prueba existentes tanto como
sea posible, lo que significa que podemos necesitar modificarlos de forma que se utilicen para
especificar cmo realizar un caso de prueba nuevo o cambiado.

Adems estos profesionales tambin intentan crear procedimientos de prueba que puedan
ser reutilizados en varios casos de prueba. Esto les permite usar un conjunto reducido de
procedimientos de prueba con rapidez y precisin para muchos casos de prueba.

En el siguiente se muestra un ejemplo de procedimiento de prueba.

El subsistema de servicios Cuentas proporciona funcionalidad para mover dinero entre

cuentas. Esta funcionalidad est involucrada en varias realizaciones de casos de uso, como las de
Pagar Facturas y Transferencias entre Cuentas. Un procedimiento de prueba llamado Verificar
Transferencia entre Cuentas especificar cmo probar el movimiento de dinero entre cuentas, por lo
cual toma como parmetros de entrada dos identidades de cuentas y una cantidad a transferir, y
valida la transferencia preguntando por el saldo de las dos cuentas involucradas antes y despus de
transferir. Los diseadores de prueba crean 8 casos de prueba para el caso de uso Pagar Factura y
14 casos de uso para el caso de uso Transferencia entre Cuentas. El procedimiento de prueba
Verificar Transferencia entre Cuentas especifica cmo se realizan parte de todos esos casos de
prueba.
3.3. Implementar prueba

El propsito de la implementacin de las pruebas es automatizar los procedimientos de

prueba creando componentes de prueba si eso es posible, pues no todos los procedimientos pueden
ser automatizados.

Los componentes de prueba se crean usando los procedimientos de prueba como entrada:

33

cuando usamos una herramienta de automatizacin de pruebas realizamos o

especificamos las acciones como se describen el los procedimientos de prueba.
Estas cciones son entonces grabadas dando como salida un componente de prueba;
por ejemplo, generando un script de prueba en Visual Basic.
Cuando programamos los componentes de prueba explcitamente usamos los
procedimientos de prueba como especificaciones iniciales. Observe que dicho
esfuerzo de programacin podra requerir personal con buenas habilidades
programadoras.

Los componentes de prueba emplean a menudo grandes cantidades de datos de entrada

para ser probados y producen tambin muchsimos datos de salida como resultado de las pruebas. Es
til visualizarlos de forma clara e intuitiva de manera que puedan especificarse correctamente y los
resultados de las pruebas sean interpretados.

Utilizamos para ellos hojas de clculo y bases de datos.

3.4. Realizar pruebas de integracin

En esta actividad se elaboran las pruebas de integracin necesarias para cada una de las
construcciones creadas en una iteracin y se recopilan los resultados de las pruebas.

Las pruebas de integracin se llevan a cabo en los siguientes pasos:

realizar las pruebas de integracin relevantes a la construccin llevan a cabo los
procedimientos de prueba manualmente para cada caso de prueba o ejecutando
cualquier componente de prueba que automatice los procedimientos de prueba.
Comprobar los resultados de las pruebas con los resultados esperados e investigar
los resultados de las pruebas que no coinciden con los esperados.
Comunicar de los defectos a los ingenieros de componentes responsable de los
componentes que se cree contiene lo fallos.
Informar de los defectos a los diseadores de prueba, quienes usarn los defectos
para evaluar los resultados del esfuerzo de prueba.
3.5. Realizar prueba de sistema

El propsito de la prueba de sistema es realizar las pruebas de sistema necesarias en cada

iteracin y recopilar los resultados de las pruebas.

La prueba de sistema puede empezar cuando las pruebas de integracin indican que se han
alcanzado los objetivos de calidad de integracin fijados en el plan de prueba de la iteracin actual;
por ejemplo, el 95 por ciento de los casos de prueba de integracin se ejecutan con el resultado
esperado.

La prueba de sistema se elabora de forma anloga a la forma en que se realiza la prueba de

integracin.

3.6. Evaluar prueba

El propsito de la evaluacin de la prueba es valorar los esfuerzos de prueba en una

iteracin.

Los diseadores de pruebas evalan los resultados de la prueba comprobando los

resultados obtenidos con los objetivos esbozados en el plan de prueba. stos preparan mtricas que
les permiten determinar el nivel de calidad del software y qu cantidad de pruebas es necesario.

En concreto, el ingeniero de prueba observa dos mtricas:

Complecin de la prueba, obtenida a partir de la cobertura de los casos de prueba
y de la cobertura de los componentes probados. Esta mtrica indica el porcentaje
de casos de prueba que han sido ejecutados y el porcentaje de cdigo que ha sido
probado.
Fiabilidad, la cual se basa en el anlisis no solo de las tendencias en los defectos
detectados y sino tambin en las pruebas que se ejecutan con el resultado
esperado.

Para determinar la fiabilidad del sistema, los diseadores de pruebas crean diagramas de
las tendencias de las fallas, donde representan la distribucin de tipos especficos de defectos -como
defectos nuevos o fatales- a lo largo del tiempo. La prueba puede crear tambin diagramas de
tendencias que representan el porcentaje de pruebas ejecutadas con xitos -es decir, ejecuciones de
pruebas que generan los resultados esperados- a lo largo del tiempo.

34


Las tendencias de los defectos siguen a menudo patrones que se repiten en varios
proyectos. Por ejemplo, normalmente el nmero de defectos nuevos generados cuando se prueba un
sistema se incrementa fallas rpidamente tan pronto como comienza la prueba, despus se mantiene
estable durante un tiempo y finalmente empieza a caer lentamente. Por tanto, comparando la
tendencia actual con tendencias similares en proyectos anteriores es posible predecir el esfuerzo
necesario para alcanzar un nivel de calidad aceptable.

Basndose en el anlisis de la tendencia de los defectos, los diseadores de pruebas pueden

sugerir otras acciones, como por ejemplo:
realizar pruebas adicionales para localizar ms defectos, si la fiabilidad medida
sugiere que el sistema no est suficientemente maduro.
Relajar el criterio para las pruebas si los objetivos de calidad para la iteracin
actual se pusieron demasiado altos.
Aislar las partes del sistema que parecen tener una calidad aceptable y entregarlas
como resultado de la iteracin actual. Las partes que no cumplieron los criterios de
calidad han de ser revisados y probados de nuevo.
Los diseadores de prueba documenten la complecin de la prueba, su fiabilidad y
sugieren acciones en una descripcin de la evaluacin de la prueba.
4. Artefactos
4.1. Artefacto modelo de pruebas

El modelo de pruebas describe principalmente cmo se evalan los componentes

ejecutables -como las construcciones- en el modelo de implementacin con pruebas de integracin y
de sistema.

El modelo de pruebas puede describir tambin la forma en que han de ser probados
aspectos especficos del sistema; por ejemplo, si la interfaz de usuario es utilizable y consistente o si
el manual de usuarios del sistema cumple con su cometido.

El modelo de pruebas es una coleccin de casos de prueba, procedimientos de prueba y

componentes de prueba.

Observe que si el modelo de prueba es grande, es decir, si contiene una gran cantidad de
casos de prueba, procedimientos de prueba y componentes de prueba, puede ser til introducir
paquetes en el modelo para manejar su tamao.

4.2. Artefacto caso de prueba

Un caso de prueba especifica una forma de probar el sistema, incluyendo la entrada o

resultado con la que se ha de probar y las condiciones bajo las que ha de probarse.

Un caso de prueba puede derivarse de, y por tanto puede seguir la traza de, un caso
de uso en el modelo de casos de uso o de una realizacin de caso de uso en el modelo de diseo.

En la prctica, lo que se prueba puede venir dado por un requisito o coleccin de requisitos
del sistema cuya implementacin justifica un ensayo que es posible realizar y que no es demasiado
caro. Los siguientes son casos de prueba comunes.
Un caso de prueba que especifica la forma de comprobar un caso de uso o un
escenario especfico de un caso de uso. Un caso de prueba de este tipo incluye la
verificacin del resultado de la interaccin entre los actores y el sistema, que se

35

satisfacen las precondiciones y post condiciones especificadas por el caso de uso,

y que se sigue la secuencia de acciones especificadas por el caso de uso. Advierta
que un caso de pruebas basado un caso de uso especifica tpicamente una prueba
del sistema como caja negra, es decir, una prueba del comportamiento
observable externamente del sistema.
Un caso de prueba que especifica cmo ensayar una realizacin de caso de usodiseo o un escenario de la misma. Un caso de prueba de este tipo puede incluir la
verificacin de la interaccin entre los componentes que implementan dicho caso
de uso. Observe que los casos de prueba basados en una realizacin de caso de uso
tpicamente especifican una prueba del sistema como caja blanca, es decir, una
evaluacin de la interaccin interna entre los componentes del sistema.
Ejemplo caso de prueba

Los ingenieros de pruebas sugieren un conjunto de casos de prueba para comprobar el caso
de uso Pagar Factura en el que cada caso de prueba verificar un escenario del caso de uso. Uno de
los casos de prueba propuesto es el pago de una factura de 300 pesos por un pedido de una bicicleta
de montaa. Los ingenieros denominan a este caso de uso Pagar 300-Bicicleta de Montaa.

Para ser completos, el caso de prueba ha de especificar la entrada, el resultado esperado y

otras condiciones para la verificacin del escenario del caso de uso.

Algunos casos de uso pueden ser parecidos y diferenciarse nicamente en un solo valor de
entradas o resultado. Esto se da a veces para casos de prueba que verifican diferentes escenarios del
mismo caso de uso, por lo que puede ser apropiado especificar los casos de uso en forma de tabla,
donde cada caso de prueba est representado por una fila y cada rango de valores de entrada y
resultado se representa por una columna. Una tabla de este tipo proporciona no solo una buena
visin general de casos de prueba similares sino tambin una entrada utilizable en la creacin de
procedimientos de prueba y componentes de prueba.

Cmo inferir casos de prueba

Considere el siguiente diagrama de actividades de un caso de uso X que forma parte de un

sistema (1, 2, 3... son actividades cualesquiera que forman parte del caso de uso X).

Este diagrama de actividades muestra el curso normal del caso y los alternativos al
especificar las salidas de las alternativas o rombos.

36


Los siguientes son conjuntos de caminos independientes (los cuatro forman un conjunto
bsico):

Camino A: 1, 2, 12

Camino B: 1, 2, 3, 4, 5, 6, 11, 2, 12

Camino C: 1, 2, 3, 4, 7, 9, 10, 11, 2, 12

Camino D: 1, 2, 3, 4, 7, 8, 10, 11, 2, 12

Fjese que el camino 1, 2, 3, 4, 5, 6, 11, 2, 3, 4, 7, 9, 10, 11, 2, 12 no se considera

independiente porque es una combinacin de caminos ya definidos y no introduce ninguno nuevo.

Cada uno de estos caminos muestra un escenario del caso del uso X.

Ahora debemos disear casos de prueba para forzar la ejecucin de estos caminos, de esta
forma podemos decir que cada instruccin de cdigo se habr ejecutado al menos una vez en las
pruebas, as como tambin se habrn ejecutado las instrucciones de las salidas verdadero y falso de
las decisiones.

Se realiza luego un conjunto de casos de prueba para cada escenario (mnimamente se

realiza al menos un caso de prueba para cada uno de esos escenarios).

Cada uno de estos casos de prueba se ejecuta, se documenta y se comparan los resultados
obtenidos con los resultados esperados.

37

La especificacin de un caso de prueba debe incluir:

Un identificador nico del caso de prueba.
Los responsables del mismo.
Referencias a documentos fuente, por ejemplo, una especificacin de
requerimientos que contiene el caso de uso.
La configuracin de software a probar:
opciones de sistema,
subsistemas, etc.

Especificacin de las entradas:

el valor preciso de cada entrada,
propiedades adicionales de dicha entrada si fuera necesario (por ejemplo
formatos, tiempos de espera, etc.)

Especificacin de las salidas:

el valor esperado de la salida,
atributos adicionales si fuera necesario (por ejemplo tiempos de respuesta, etc.)

Requerimientos sobre el ambiente de prueba:

configuracin del hardware para la prueba,
detalle del software necesario para la prueba (sistema software a probar, software
especfico para realizar la prueba),
recursos especiales, por ejemplo, la presencia de un usuario o una persona
especfica.

Especificacin del procedimiento de prueba.

Precondiciones (condiciones que deben cumplirse antes de ejecutar este caso de prueba,
por ejemplo, la ejecucin correcta de tal grupo de pruebas, la existencia de determinado objeto, etc.).
Otros casos de prueba

Se pueden especificar otros casos de prueba para probar el sistema como un todo. Por
ejemplo:
Las pruebas de instalacin verifican que el sistema puede ser instalado en la
plataforma del cliente y que el sistema funcionar correctamente cuando sea
instalado.
Las pruebas de configuracin verifican que el sistema funciona correctamente en
diferentes configuraciones; por ejemplo, en diferentes configuraciones de red.
Las pruebas negativas intentan provocar que el sistema falle para poder as
revelar sus debilidades. Los ingenieros de pruebas identifican los casos de prueba
que intentan utilizar el sistema en formas para los que no ha sido diseado, por
ejemplo, empleando configuraciones de red incorrectas, capacidad de hardware
insuficiente o una carga de trabajo imposible de sobrellevar.
Las pruebas de tensin o de estrs identifican problemas con el sistema cuando
hay recursos insuficientes o existe competencia por los recursos.
4.3. Artefacto procedimiento de prueba

Un procedimiento de prueba especifica cmo realizar uno a varios casos de prueba o partes
de estos. Por ejemplo, una instruccin para un individuo sobre la forma ha de realizar un caso de
prueba manualmente, o una especificacin de cmo interaccionar manualmente con una herramienta
de automatizacin de pruebas para crear componentes ejecutables de prueba.

El cmo llevar a cabo un caso de prueba puede ser especificado por un procedimiento de
prueba, pero es a menudo til reutilizar un procedimiento de prueba para varios casos de prueba y
reutilizar diferentes mtodos de prueba para un caso de prueba.
Ejemplo procedimiento de prueba

Se necesita un procedimiento de prueba para que un individuo lleve a cabo el caso de uso
Pagar 300-Bicicleta de Montaa discutido en el ejemplo anterior. La primera parte del
procedimiento de prueba se especifica como sigue el texto entre corchetes no tiene que incluirse en
la especificacin ya que ya est detallado en el caso de uso:

Caso de uso: Pagar 300-Bicicleta de Montaa.

38

Seleccione el men Hojear Facturas de la ventana principal. Se abre la ventana de

dilogo Consultar Facturas.
En el campo Estado de la Factura, seleccione Pendiente y pulse el botn
Consultar. Aparece la ventana Resultados de la Consulta.
Verifique que la factura especificada en el caso de uso [ID 12345] est en la lista
en la ventana Resultados de la Consulta.
Seleccione la factura a pagar especificada pulsando el botn dos veces. Aparece la
ventana Detalles de Factura para la factura seleccionada. Verifique los siguientes
detalles:
el Estado es Pendiente;
la Fecha de Pago est vaca;
el Identificador de Confirmacin de Pedido coincide con el identificador
en el caso de uso [ID 98765];
la Cantidad de la Factura coincide con la descripta en el caso de prueba
[300 pesos]; y el nmero de cuenta es el mismo que el especificado en el
caso de prueba [22-222-2222].
Seleccione la opcin Autorizar Pago para iniciar el abono de esta factura. Aparece
la ventana de dilogo para el Pago de Factura. Etc. Se especifica cmo se lleva a
cabo a travs de la interfaz de usuario el camino completo del caso de uso Pagar
Factura dando ciertas entradas al sistema, e indicando qu es necesario verificar en
las salidas del sistema.

Observe que este procedimiento de prueba se aplica tambin para otros casos de uso
similares en los que se utilizan distintos valores de entrada y resultado, es decir, los valores entre
corchetes son diferentes. Tambin que el procedimiento de prueba es similar a la descripcin de flujo
de eventos del caso de uso a Pagar Factura, aunque el mtodo de prueba incluye informacin
adicional, como los valores de entrada del caso de uso a emplear, la forma en la que estos valores
han de ser introducidos en el interfaz de usuario y lo que hay que verificar.

Los procedimientos pueden ser:

Procedimientos de instalacin de software y hardware.
Procedimientos de control.
Procedimientos de finalizacin, reseteos de estados, limpieza de resultados.
Procedimientos de supervisin de la ejecucin de la prueba.
Procedimientos de medicin de resultados de salida.
4.4. Artefacto componente de prueba

Un componente de prueba automatiza uno o varios procedimientos de prueba, o parte de

ellos.

Los componentes de prueba se desarrollan utilizando un lenguaje de guiones o un lenguaje

de programacin, o siendo grabados con una herramienta de automatizacin de prueba.

Los componentes de prueba se utilizan para probar los componentes en el modelo de

implementacin, proporcionando entradas de prueba, controlando y monitorizando la ejecucin de
los componentes a probar informando de los resultados de las pruebas. En ingls, los componentes
de prueba son a veces llamados test drivers, test arneses y test scripts.
4.5. Artefacto plan de prueba

El plan de prueba describe las estrategias, recursos y planificacin de la prueba.

La estrategia de prueba incluye la definicin del tipo de pruebas a realizar para cada
iteracin y sus objetivos, el nivel de cobertura de prueba y de cdigo necesario y el porcentaje de
pruebas que deberan ejecutarse con un resultado especfico.
4.6. Artefacto defecto

Un defecto es una anomala del sistema, como por ejemplo un sntoma de un fallo software
o un problema descubierto en una revisin.

Se utiliza para localizar cualquier cosa que los desarrolladores necesitan registrar como
sntoma de un problema en el sistema que ellos deben controlar y resolver.
4.7. Artefacto evaluacin de prueba

Una evaluacin de prueba es una valoracin de los resultados de los esfuerzos de prueba,
tales como la cobertura del caso de prueba, la cobertura de cdigo y el estado de los defectos.
5. Trabajadores

39

5.1. Diseador de pruebas

Un diseador de pruebas es responsable de la integridad del modelo de pruebas,

asegurando que el mismo cumple con su propsito.

Los diseadores de pruebas tambin planean las pruebas, lo que significa que deciden los
objetivos apropiados y la planificacin de las pruebas.

Adems, los diseadores de pruebas seleccionan y describen los casos y los

procedimientos de prueba correspondiente que se necesitan, y son responsables de la evaluacin de
las pruebas de integracin y de sistema cuando stas se ejecutan.

Observe que los diseadores de pruebas realmente no ejecutan las pruebas, sino que se
dedican a la preparacin y evolucin de las mismas. Otros dos tipos de trabajadores, los ingenieros
de pruebas de integracin y los ingenieros de prueba de sistema, son los encargados de llevarlas a
cabo.

5.2. Ingeniero de pruebas de integracin

Los ingenieros de pruebas de integracin son los responsables de hacen las pruebas de
integracin que se necesitan para cada construccin producida en el flujo de trabajo de la
implementacin.

Se realizan para verificar que los componentes integrados en una construccin funcionan
correctamente juntos.

Por esto, se derivan a menudo de los casos de prueba que especifican cmo probar
realizaciones de casos de uso-diseo.

El ingeniero de pruebas de integracin se encarga de documentar los defectos en los

resultados de dichas pruebas.
5.3. Ingeniero de pruebas de sistema

Un ingeniero de pruebas de sistema es responsable de realizar las pruebas de sistema

necesarias sobre una construccin que muestra el resultado (ejecutable) de una iteracin completa.

Las pruebas de sistema se llevan a cabo principalmente para verificar las interacciones
entre los actores y el sistema. Por esto, las pruebas de sistema se derivan a menudo de los casos de
prueba que especifican cmo probar los casos de uso, aunque tambin se aplican otros tipos de
pruebas al sistema como un todo.

El ingeniero de pruebas de sistema se encarga de documentar los defectos en los resultados

a las pruebas de sistema.

Debido a la naturaleza de las pruebas de sistema, los individuos que actan como
ingenieros de pruebas de sistema necesitan saber mucho sobre el funcionamiento interno del
sistema. Por el contrario, stos deberan tener familiaridad con el comportamiento observable
externo del sistema. Por tanto, algunas pruebas de sistema pueden ser realizadas por otros miembros
del proyecto, como los especificadores de casos de uso, o incluso por una persona externa al
proyecto, como usuario de versiones beta.

40

UNIDAD N4
UTILIZANDO PUDS

El PUDS es un proceso de desarrollo de software que transforma requerimientos de

usuarios en un producto software a travs de actividades que realizan trabajadores en un proyecto.

El PUDS se apoya en tres pilares: los casos de uso, la arquitectura y el concepto de

iterativo e incremental.
Dirigido por Casos de uso
La tcnica de casos de uso permite validar los requerimientos con el cliente y facilitar la
comunicacin de dichos requerimientos en el equipo que participa en el proyecto.
Existen entonces dos objetivos fundamentales:
encontrar los verdaderos requisitos y
representar los mismos de un modo adecuado para los usuarios, clientes y desarrolladores.

Los CU dirigen el proceso de desarrollo en su totalidad.

Los desarrolladores crean un modelo de anlisis que utiliza el modelo de casos de uso
como entrada y que es diferente del modelo de diseo porque es un modelo conceptual en lugar de ser un
esquema de la implementacin. Cada caso de uso en el modelo de casos de uso se traduce en una
realizacin de caso de uso en el modelo de anlisis.

Tomando los casos de uso uno a uno, los desarrolladores pueden identificar las clases que
participan en la realizacin de aquellos. As obtenemos un conjunto de clases que juntas realizan los
casos de uso. Luego los desarrolladores disean las clases y las realizaciones de casos de uso para
aprovechar al mximo las tecnologas y productos a utilizarse.

A continuacin se implementan las clases diseadas mediante un conjunto de archivos a

partir de los cuales se pueden generar (ejecutables, DLLs, JavaBeans, componentes ActiveX, pginas
web, etc.). Finalmente, durante el flujo de trabajo de prueba, los ingenieros corroboran que el sistema
implementa la funcionalidad descrita en los distintos casos de uso, y de esta forma se satisfacen los
requerimientos para los que fue construido.
As los casos de uso guan al proceso unificado, lo hemos visto slo con una iteracin. Este mismo
proceso se repite de manera iterativa e incremental a medida que avanzamos en el proceso de desarrollo.
Los casos de uso son un mecanismo para materializar la relacin de trazabilidad a travs de todos
los modelos. Un caso de uso en el modelo de requisitos es trazable a su realizacin en el modelo de
anlisis, y as sucesivamente a travs de cada uno de los modelos del UP. Esta relacin es fundamental para
mantener la integridad de los modelos en el tiempo cuando se presentan cambios que implican
actualizaciones en varios de ellos.

Centrado en la arquitectura
La arquitectura describe los cimientos del sistema que son necesarios como base para
comprenderlo, desarrollarlo y producirlo. En la fase de elaboracin se construye una arquitectura slida
para que a partir de la misma podamos arrancar con la construccin de la totalidad del sistema sin tropiezos
posteriores.
A la hora de ir pasando por las distintas fases del proyecto los desarrolladores utilizarn la
arquitectura como gua general para situarse correctamente en el lugar en donde estn parados y usarn los
distintos diagramas ms detallados para realizar su trabajo, incluyendo aquellos casos de uso importantes
en este contexto.
La descripcin de la arquitectura tiene cinco vistas, una para cada modelo:

41

1. Casos de uso
2. Anlisis
3. Diseo
4. Despliegue
5. Implementacin

Una vista arquitectnica es una descripcin simplificada (una abstraccin) de un sistema

software desde una perspectiva particular que incluye ciertas particularidades y omite u oculta otras
que no son relevantes para esta perspectiva.

En la descripcin de la arquitectura no se pretende cubrir absolutamente todo, no debera

inundar con detalles minuciosos. Hay mucha informacin que no es necesaria tener en cuenta a la
hora de describir la arquitectura. Por ejemplo, slo el 10 % de las clases de un sistema son relevantes
para la arquitectura, el 90 % restante no es significativo porque no es visible a todo el sistema.

Objetivos de la definicin de la arquitectura:

Permite comprender el sistema: El sistema debe ser comprendido por todos los
integrantes del equipo de proyecto.
Permite manejar la complejidad: usualmente se trata de sistemas con
funcionalidades complejas, que operan en entornos tecnolgicamente complejos,
que combinan computacin distribuida, productos y plataformas comerciales
diferentes y reutilizan componentes y marcos de trabajos, que se realizan en
lugares geogrficamente alejados entre s que deben ser coordinados y
ensamblados.
Permite a los integrantes del equipo de proyecto comprender y acordar qu se
est haciendo: el equipo debe conocer el progreso de la definicin de la
arquitectura.
Organizar el desarrollo: a medida que crece la organizacin del proyecto, crecen
proporcionalmente los esfuerzos para coordinar las actividades de los miembros
del equipo.
Fomentar la reutilizacin: la reutilizacin es una de las ventajas principales de
esta metodologa, para ello se debe conocer el dominio del problema y qu
componentes admite la arquitectura. Los componentes de software reutilizables
estn diseados y probados para ser utilizados o ensamblados, lo cual reduce los
tiempos y los costos, a la vez que aumenta la calidad disminuyendo la posibilidad
de defectos.
Hacer evolucionar el sistema: en cada iteracin se produce un incremento del
sistema que estamos construyendo. Es deseable que dicho sistema sea fcil de
modificar y permita la implementacin de nuevas funcionalidades, es decir, que
sea flexible a los cambios.

Proceso Iterativo e incremental

El PUDS avanza poco a poco en el refinamiento de casos de uso, se avanza por etapas.

Es lo que diferencia al PUDS de otras metodologas de desarrollo tradicionales en las

cuales el desarrollo tambin se realiza por etapas, pero las mismas se van realizando en serie, una
detrs de la otra sin posibilidad por ejemplo de recibir retroalimentacin en alguna y volver para
atrs para modificar funcionalidad. Se cumplen las etapas, se van cerrando y se avanza a la
siguiente. En nuestro caso la base es que el proceso sea realmente iterativo e incremental.

El concepto de iteracin tiene asociado el de versin de sistema, es decir, en cada iteracin

se obtiene una versin operativa del sistema software que estamos construyendo. Este sistema va
creciendo incrementalmente a travs de las diferentes iteraciones, los modelos van evolucionando a
travs de las mismas.

Se divide el proyecto en un nmero de mini proyectos, siendo cada uno de ellos una
iteracin. Cada iteracin est compuesto por todas las fases de un proyecto de software, es decir que

42

cada una de ellas sera como un mini proyecto hecho con una metodologa tradicional, como la de
cascada.

Se debe manejar con mucho cuidado el hecho de poder avanzar y recibir retroalimentacin
y retroceder, ya que si tomamos esto como moneda corriente podemos caer en un terreno donde nos
mantengamos siempre en un mismo lugar sin percibir avance alguno.

Cada iteracin debe planificarse para controlar el proyecto. El Plan de la iteracin es un

plan que incluye un conjunto secuencial de actividades, tareas, recursos asignados, objetivos,
criterios de evaluacin (en funcin de los objetivos) de la iteracin en cuestin. Ser importante al
final de la iteracin medir aspectos tales como el grado de terminacin de la funcionalidad
planificada, los niveles de calidad alcanzados, adecuacin a las normas y estndares vigentes en caso
de ser necesario.

El concepto de iteracin reduce, al principio del ciclo de vida, los riesgos que pueden
amenazar el progreso del desarrollo. Las versiones internas tras las iteraciones posibilitan la
retroalimentacin de los usuarios y esto lleva a su vez a una correccin temprana de la trayectoria
del proyecto.
Para resumir, los principales objetivos de un desarrollo iterativo e incremental son:
Atenuar los riesgos.
Obtener una arquitectura robusta.
Gestionar requisitos cambiantes.
Permitir cambios tcticos.
Conseguir una integracin continua.
Conseguir un aprendizaje temprano.
El UP entrega las 6 mejores prcticas
El proceso unificado describe cmo implementar efectivamente las seis mejores prcticas para el
desarrollo de software, las mismas son:

Ventajas y errores al utilizar el proceso unificado

Ventajas de utilizar esta metodologa

Prioriza la identificacin y gestin de riesgos en etapas tempranas del desarrollo.

Enfatiza la construccin temprana de una arquitectura cohesiva y robusta que ser probada
en las primeras iteraciones.

Permite identificar requerimientos en forma incremental.

Aplica el desarrollo evolutivo e incremental.

Genera artefactos bien definidos, con vocabulario comn.

Es fcil de combinar con tcnicas de otros mtodos.

Es fcil de personalizar, alienta versiones light mnimas.

Permite trabajar con plantillas estndar.

Puede escalar a proyectos grandes o pequeos.

Ampliamente adoptado, por lo tanto, muchos recursos de consultora y capacitacin.

Cada iteracin finaliza con un entregable del producto.

Errores ms comunes al utilizar esta metodologa

Superponer las ideas de cascada en las fases iterativas.

43


Realizar iteraciones demasiado largas.

Cometer errores al definir la visibilidad de los atributos y las operaciones.

Las iteraciones no son fijas, por lo que dependen de la planificacin y el seguimiento de la

misma.

Crear muchos artefactos innecesariamente, lo que aumenta la complejidad sin motivo.

Dificultad en la planificacin predictiva.

El equipo debe realizar muchas actividades y genera muchos artefactos, porque no se ha

definido correctamente el proceso.

Necesidad de utilizar herramientas CASE.

2.-Fases e iteraciones
Este concepto es el primer paso para dividir el trabajo en partes manejables.
PUDS contempla cuatro fases atendiendo al momento en que se realizan:
Inicio
Elaboracin
Construccin
Transicin

Cada una de las fases se divide en una o ms iteraciones.

Cada una de las cuatro fases de un proyecto finaliza con un hito.

Cada hito puede incluir muchos objetivos, incluso la toma de decisiones clave para avanzar
con la prxima iteracin.
2.1 Planificacin de las fases

Antes de comenzar a trabajar en un proyecto debemos planificar el proyecto y realizar un

Plan de proyecto. En cada fase planificaremos cada iteracin a travs del Plan de iteracin. Estos
planes se van completando con mayor detalle a medida que se avanza en el proyecto.

En esta planificacin debemos incluir mnimamente la forma evaluar cada iteracin, la

forma de gestionar los riesgos y la manera de asignar los recursos necesarios para llevar a cabo las
actividades.

El PUDS nos dice qu hacer en cada fase, los planes llevan estas indicaciones a trminos
especficos para un proyecto en particular. Se planifica:

El tiempo que insumir cada fase, incluyendo su fecha de finalizacin.

Los hitos principales que indican la finalizacin de una fase para pasar a la
siguiente.

Las iteraciones que se realizarn en cada fase.

2.2 Planificacin de las iteraciones

La cantidad de iteraciones que se realizarn en cada fase depende del sistema que
estamos construyendo, de su complejidad y tamao.

La duracin de cada iteracin podr variar entre una semana y tres meses. Es
aconsejable que las actividades dentro de la iteracin sean unidades asignables,
controlables y posibles de medir.

Por cada iteracin planificamos:

El tiempo que llevar cada iteracin, con su fecha de finalizacin.
El contenido de la iteracin, es decir, qu funcionalidades (expresadas en
casos de uso) se implementarn en la misma, qu riesgos estarn
presentes (o al menos potencialmente) y cul ser la estrategia de
mitigacin, los subsistemas que se implementan (total o parcialmente).
Los hitos secundarios que indicarn la finalizacin de la iteracin.

Esta planificacin de la iteracin se ir refinando a medida que nos acerquemos a

dicha iteracin.
2.3 Evaluacin

Los criterios de evaluacin seguramente se planificaron con anterioridad en funcin de los

objetivos. Se trata de parmetros o caractersticas que mnimamente se deben cumplir.

Se establecen criterios para cada fase y para cada iteracin dentro de cada fase. Se trata de
un momento en el que se verifica la satisfaccin de dichos criterios o requisitos. Por lo anterior, se

44

deduce que los criterios deben poder ser observados de alguna manera por el responsable, es decir, el
jefe de proyecto.

Esta evaluacin permite:

Evaluar la iteracin actual, por ejemplo, si el proyecto se mantiene dentro de los
costos y tiempos planificados, si se logran los objetivos de calidad definidos, etc.
Actualizar el plan de la siguiente iteracin.

Los resultados de la evaluacin se registran en un documento que crea el jefe de proyecto.

Este documento se distribuye a los involucrados y se archiva, es decir, no sufre

modificaciones a lo largo del tiempo. La prxima evaluacin generar un nuevo documento de
registro de resultados.

3 Flujos de trabajo
3.1 Flujos de trabajo fundamentales

Cada iteracin puede ser considerada como un pequeo proyecto en s mismo, y constituye
una pasada por los cinco flujos de trabajo fundamentales del PUDS.

Los flujos de trabajo fundamentales son:

Requisitos
Anlisis
Diseo
Implementacin
Prueba

3.2 Dominio del problema y de la solucin

En la actividad de modelado de negocio se trabaj con los objetos del negocio, es decir,
con el dominio del problema.

En el flujo de requerimientos se comenz a trabajar con clases de software. Estas con una
relacin de traza con los objetos identificados en el dominio en la etapa anterior.

En el flujo de trabajo de anlisis se comenz a trabajar con clases de fabricacin pura, es

decir, creadas para la construccin de la solucin, o sea, ya en el dominio de la solucin. El resultado
de este flujo fue un modelo conceptual y lgico.

En el flujo de diseo se continu trabajando en el dominio de la solucin para lograr el

sistema software.
3.3 Flujos de trabajo y modelos

Cada flujo de trabajo obtiene una salida, que es un modelo que lleva el mismo nombre que
el flujo.

La clave en la configuracin del proceso es qu incluir dentro del modelo, es decir, qu

diagramas utilizar en cada flujo de trabajo. Este es un aspecto configurable del proceso, ya que
dependiendo del proyecto, del conocimiento del dominio, de la complejidad, etc. se seleccionarn
los diagramas que se construirn.

45

UNIDAD N5
IMPLEMENTACION DEL CAMBIO
1.-Creacin del conocimiento con t.i. y ventaja competitiva

David Smith postula cuatro niveles de desarrollo organizacional en la creacin del conocimiento:
o Compartir conocimiento,
o Nivelacin,
o Creacin de conocimiento y
o Competir con conocimiento.

Cada uno de estos niveles otorga a la empresa facilidades y ventajas, y si dicha empresa es capaz
de avanzar a la etapa siguiente, ser capaz de alcanzar nuevas capacidades que le otorguen grandes
ventajas sobre sus competidores.

Resolver los problemas y encontrar las oportunidades subyacentes en cada uno de estos estados
involucra tres elementos convergentes:
Procesos cognitivos: Estos incluyen la identificacin, la adquisicin, el mapeo, el
almacenaje, el acceso, la distribucin, la nivelacin y el uso del conocimiento.
Facilitadores tecnolgicos: Sistemas de informacin, recuperacin de documentos,
herramientas de grupo, intranet corporativa, sistemas de base de conocimiento, etc.
Alineacin organizacional: Los lderes son parte crtica del alineamiento, junto con las
recompensas, roles, estructuras mentales, estructura y apertura.
La tecnologa, no es nunca por s misma la solucin mgica a ninguna problemtica. Slo resulta
valiosa ante fines concretos. Debemos saber para qu queremos utilizar tal o cual tecnologa, y
asegurarnos de que cumple nuestras expectativas de uso y calidad antes de realizar cuantiosas
inversiones en ella.
Considerar los siguientes aspectos como premisa indispensable al enfrentar un proceso de cambio
organizacional implementando tecnologa de informacin:

Crear conocimiento es el postulado fundamental en la implementacin de

tecnologas de informacin.

Involucrar a la mayor cantidad de personas posible en la reingeniera y otros

programas de cambio.

Hacer del cambio constante parte de la cultura.

Contarle a la mayor cantidad posible de personas sobre todos los aspectos, con la
mayor frecuencia posible y preferiblemente en persona.

Hacer uso amplio de la motivacin y del reconocimiento positivo a los miembros

involucrados en el proyecto.

46

Trabajar dentro de la cultura de la empresa, no alrededor de sta.

2. Adquisicin de hardware, software y servicios

Implementar determinada T.I. podra requerir de la incorporacin de hardware, software

y/o servicios.

El proceso de adquisicin de recursos y equipo computacional es complejo.

Las decisiones relacionadas con la adquisicin de estos recursos deben considerar factores
tecnolgicos y financieros.

El proceso se inicia con la determinacin de los requerimientos de cmputo, hasta la

administracin de la conversin de programas y la transicin y traslado de datos al nuevo sistema
computacional.

Es importante conocer los sntomas que se observan en las organizaciones, y que

constituyen un detonante del proceso de cambio de equipo, a fin de que el administrador de los
recursos de hardware se prepare para el manejo del proyecto:
Problemas de servicio con el proveedor actual.
El equipo computacional actual es obsoleto.
Saturacin y falta de capacidad del equipo computacional
Necesidad de incorporar nuevos sistemas de aplicacin a la organizacin
Equivocada decisin durante el proceso de seleccin del equipo actual.
Existencia de requerimientos de competitividad que no pueden ser logrados con la
tecnologa actual.
Existe la necesidad de cambiar la filosofa de operacin de los sistemas actuales.
Las etapas para llevar a cabo el proceso de innovacin tecnolgica de recursos computacionales
son:
Determinacin de los requerimientos.
Es necesario especificar las necesidades del nuevo equipo a fin de transmitirlas de manera clara a
los proveedores, para lo cual es obligatorio:
Un conocimiento de la organizacin.

El primer paso es tener un conocimiento profundo de la organizacin o la entidad de negocios que

recibir el servicio del equipo que ser adquirido.
Plan de desarrollo de aplicaciones.

Se debe contar con un plan de desarrollo de aplicaciones a corto, mediano y largo plazo que
operarn en el nuevo sistema.
El horizonte del proyecto se define como el lapso de tiempo futuro que se considera en un anlisis.
Filosofa de operacin o tipo de solucin requerida

El plan deber incluir aspectos tecnolgicos requeridos para el desarrollo de nuevas aplicaciones,
tales como bases de datos, cdigos de barras, sistemas por lotes o en lnea, ya que estas especificaciones
pueden modificar de manera sensible los requerimientos y restricciones a considerar en el nuevo equipo.
La filosofa de operacin que se desea con el nuevo equipo requiere un anlisis del tipo de
solucin que se implantar con l. Esta solucin puede incluir equipos grandes, arquitecturas clienteservidor, estaciones de trabajo y PCs entre otras.
Recursos que deben estimarse

Capacidad de cmputo expresada. Por ejemplo: nmero de instrucciones por segundo.

Capacidad de almacenamiento en RAM. Por ejemplo: tamao en Gigabytes

Capacidad de almacenamiento secundario, expresada en Megas, Gigas Terabytes.

Capacidad total de impresin requerida, expresada como lneas de impresin por minuto.

Cantidad de terminales requeridas para la captura o consulta de informacin.

Hardware especializado para llevar a cabo funciones especiales: Terminales inteligentes,

concentradores, ruteadores, etc.

Infraestructura de redes: Tarjetas de red, medios de transmisin, etc.

Requerimientos obligatorios
Conjunto de caractersticas que deben estar, de forma obligada y necesaria, presentes en el equipo
o solucin presentada por el proveedor:

47

 Costo total del equipo o el presupuesto mximo autorizado.

Tiempo mximo de entrega del equipo requerido.
Compatibilidad con el lenguaje computacional actual, minimizando el esfuerzo de
conversin.
Apoyo del proveedor durante la conversin de aplicaciones, si existe.
Caractersticas mnimas requeridas de rendimiento de los equipos.
Requerimientos opcionales
Constituyen el conjunto de caractersticas que son de gran ayuda y utilidad si se encuentran
presentes en el equipo, en caso contrario, no necesariamente la propuesta del proveedor debe ser
descartada.

Existencia de usuarios con configuraciones similares y que se encuentran en localidades

cercanas para tener un soporte mutuo.

Disponibilidad de algn sistema de aplicacin o paquete ya desarrollado para asegurar una

implantacin rpida y exitosa.

Alto grado de satisfaccin de los usuarios actuales.

Requerimientos futuros
Deben tenerse en cuenta situaciones como:

Crecimiento del negocio por arriba o por abajo del porcentaje estimado.

Fusiones o compra de nuevos negocios.

Rediseo o cambios importantes de las aplicaciones actuales.

2.1. Evaluacin y seleccin
Evaluacin tcnica de las propuestas
Es el proceso mediante el cual el administrador del proyecto define y evala las caractersticas y
los factores tcnicos de los equipos disponibles. El resultado de esta evaluacin tcnica, sumado al
resultado de la evaluacin econmica y financiera, constituye la plataforma de decisin del equipo y de la
solucin a adquirir.
2.2. Elaboracin de una Requisicin de Propuesta (RFP Request For Proposal)
Una vez que se han terminado las estimaciones de los requerimientos del equipo nuevo que se va a
adquirir, es necesario elaborar una solicitud o requisicin de propuesta, documento que define los
requerimientos de la organizacin sobre el equipo o la red requerida.
Tiene varias funciones:

Sirve como una propuesta del sistema que invita a los proveedores a participar en el
concurso.

Establece los primeros puntos de evaluacin y negociacin entre los proveedores de

soluciones y la organizacin.

Obliga al administrador del proyecto a formalizar el proceso de determinacin de los

requerimientos de equipo.

Constituye un documento que describe claramente las prioridades tcnicas del sistema.
Se recomienda incluir en su estructura:
o
Datos generales del responsable del proyecto.
o Fecha lmite para recibir la propuesta del proveedor.
o Fecha lmite para que el proveedor realice las presentaciones y/o demostraciones del
equipo propuesto.
o Bases y lineamientos generales que sern utilizados para comparar los diferentes
equipos.
o Breve descripcin de la situacin actual de la compaa y de la funcin de informtica
dentro de la misma.
Requerimientos del sistema computacional
Se puede incluir la siguiente informacin:
o Requerimientos del equipo actual versus del equipo propuesto.

48

o Requerimientos obligatorios y opcionales.

o Informacin ms detallada de las pruebas de benchmark o pruebas de rendimiento
o que sern efectuadas a las soluciones propuestas que estarn concursando.
o En trminos generales, deber incluirse toda la informacin relevante.
Formato de propuesta
Es importante definir estndares de las propuestas de los diferentes proveedores, para facilitar la
evaluacin tcnica y financiera de las mismas, y por ende, de la decisin final.
El formato de propuesta puede variar de una empresa a otra,pero incluye:

Sistema o solucin configurada. Con la descripcin tcnica detallada de

la solucin propuesta y las capacidades de crecimiento del sistema. Debe contener
manuales tcnicos de hardware y del software configurado, as como diagramas
esquemticos de la configuracin propuesta.

Requerimientos de instalacin. Se debe recordar que hay soluciones que

implican costosos requerimientos de instalacin. Debe incluir:
o
Espacio fsico que ocupa el equipo.
o
Instalaciones elctricas y equipos reguladores de voltaje.
o
Temperatura ambiental y equipos de aire acondicionado.
o
Requerimientos especiales tales como piso falso, equipo de control
de humedad, etc.

Asistencia del proveedor. Aspecto tan importante como el producto, e incluye:

Asistencia para el entrenamiento del personal en el nuevo equipo y
calendario de cursos, incluyendo su costo.
Personal de asistencia para hardware, software y en general, para el
mantenimiento del equipo.
Inventario de equipos de respaldo compatibles con el equipo configurado
en la propuesta.
Apoyo y experiencia para convertir las aplicaciones y los programas de
aplicacin al nuevo equipo.

Informacin de costos. Debe incluirse toda la informacin

econmica y financiera de las propuestas. Ello comprende precios, plazos de pago y opciones
de compra disponibles por parte del proveedor, y en general, todos los datos requeridos para
desarrollar la evaluacin econmica del proyecto de inversin.

Condiciones del contrato: se especifican en formatos fijos que el

proveedor anexa a las propuestas, los cuales comnmente son elaborados por el departamento
jurdico de la compaa.

Nivel o grado de cumplimiento: Es importante insistir a los

proveedores que esta informacin se incluya en la propuesta entregada en forma expresa y por
separado.
Apertura de concurso de proveedores

Una vez elaborado el RFP, es necesario abrir formalmente el concurso de los proveedores.

Durante esta fase del proceso es importante elaborar un documento que contenga todas las
especificaciones, ya descritas y darlo formalmente a cada uno de ellos.

Se recomienda que la entrega se efecte en una reunin por separado con cada proveedor,
recalcando la importancia de cumplir con el formato especificado.

Es importante considerar e invitar a todos los proveedores posibles.

Descarte de propuestas

Se descartan las propuestas que no cumplen con los requisitos obligatorios.

Hay que recordar que si la invitacin a los proveedores fue exhaustiva, es de esperarse que
la cantidad de propuestas recibidas tambin sea elevada.

El anlisis y evaluacin de todas puede resultar lento y costoso.

2.3. Factores a evaluar
La evaluacin se realiza exclusivamente sobre las soluciones que satisfacen los requerimientos
obligatorios y que cumplen mejor las especificaciones opcionales.
Se clasifican en:
Factores de hardware.

49


Son las caractersticas que ofrecen los componentes fsicos de la solucin. Por ejemplo:
capacidades y velocidades de los diferentes componentes.

Factores de software.

Se refiere al software interno o de sistemas, el cual se compone de programas de control,

los que incluye el sistema operativo, software de comunicaciones y administrador de base de datos.
Adems se consideran paquetes especiales, tales como simuladores, anlisis financieros,
programacin lineal, control de proyectos, anlisis estadsticos y paquetes que se enfocan a
resolver problemas funcionales a los usuarios, tales como contabilidad, cuentas por pagar, y
facturacin, entre otros.

Se debe dar gran peso a la posibilidad y facilidad de que todo el software que se desarrolle
sea abierto o transportable.
Factores de proveedor.
El soporte es uno de los criterios ms importantes para tomar una decisin de compra, as tambin
como el precio y el rendimiento.
Aspectos a analizar son:
1.- Generalidades del proveedor. Toda aquella informacin relacionada con la imagen
que ste tiene en el mercado local, regional y mundial, considerando aspectos tcnicos, de mercado
y financieros, de tal manera que aseguren la permanencia y continuidad del proveedor. Ellos
incluyen:
Representacin mundial y regional del proveedor
Tiempo de entrega del equipo y futuras ampliaciones
Profesionalismo y preparacin de los vendedores
Situacin econmica y financiera
Calidad de la documentacin y manuales disponibles

2.- Apoyo a la capacitacin:

Es el apoyo que brinda en la capacitacin al personal tcnico y usuarios con el uso de los
recursos de hardware y software propuestos. Incluye la capacitacin:

al personal de las reas de investigacin y soporte tcnico

en el rea de anlisis y programacin

a operadores

capacitacin a usuarios

3.-Mantenimiento de hardware y software.

Consiste bsicamente en la capacidad de un proveedor para proporcionar un soporte y servicio adecuado,
para asegurar el funcionamiento continuo o ininterrumpido del sistema. Deben considerarse aspectos
como:

Calidad y cantidad de personal capacitado de tiempo completo disponible en

hardware y software.

Tiempo promedio que tarda el proveedor en atender las fallas reportadas.

Tiempo o porcentaje de sistema funcionando, que es el tiempo que trabaja el

sistema sin que ocurra algn problema.

Tiempo promedio que el sistema permanece cado durante cada falla.

Existencia de una sucursal cercana con partes y repuestos para responder con
mayor oportunidad a fallas.

Existencia de horario extendido, 7 das a la semana, 24 horas diarias para atender

fallas.

4.- Equipos de respaldo.

Disponibles por parte del proveedor u otros usuarios. Estos equipos pueden garantizar la
operacin de la empresa del cliente durante fallas prolongadas. Pueden incluir:

Cantidad de equipo de respaldo existente.

Facilidad de trasladar procesos a los equipos de respaldo.

Grado de satisfaccin de estos usuarios en relacin con el proveedor.

5.- Apoyo durante la conversin de aplicaciones.

Se refiere a la asistencia que el proveedor pueda proporcionar al cliente
durante el proceso de conversin y traslado de las aplicaciones y programas al
nuevo equipo. Algunos aspectos a tomar en cuenta son:
50

Los antecedentes que tiene el proveedor en el apoyo a otros clientes en

conversiones similares a las requeridas.

Facilidad de iniciar la conversin de aplicaciones antes de la llegada del

equipo, a fin de reducir el tiempo y costo de la operacin paralela de ambos
equipos.
2.4. Mtodos de evaluacin tcnica
Pueden aplicarse en forma individual o alternada, y complementariamente.
Mtodo de mezcla de instrucciones: para comparar velocidades del procesador de diversos equipos se
puede escoger un conjunto de instrucciones representativas y ms utilizadas por los programas de usuario y
sacar un promedio ponderado del tiempo de ejecucin de ellas. Adems, se debe asignar un peso a cada
instruccin de acuerdo con la frecuencia del uso de sta en los programas.
Mtodo de Kernel: un kernel es un problema simple y representativo de las aplicaciones tpicas a
computarizar por el nuevo equipo; mide el tiempo que emplea en ejecutar esta aplicacin cada uno de los
equipos que se comparan.
Mtodo de simulacin: consiste en hacer uno o varios programas utilizando tcnicas y lenguajes de
simulacin con el fin de imitar el funcionamiento de un sistema computacional. Se definen parmetros
como tiempo de ejecucin, capacidad de memoria principal, acceso a dispositivos de entrada/salida,
demanda de usuarios en terminales, entre otros. Y se generan diferentes escenarios y corridas para cada
uno de los equipos.
Mtodo de benchmark: sirve para comparar el rendimiento de uno o varios programas de aplicacin en
diferentes o igual plataforma de hardware. Existen revistas especializadas que peridicamente publican
evaluaciones de comparaciones tcnicas de equipo computacional.
Mtodo de factores ponderados: consiste en asignar un peso a cada uno de los factores de hardware,
software y del proveedor descritos, y calificar cada equipo propuesto de acuerdo con la medida en que
cumple con el factor considerado.
El equipo o la propuesta que obtiene el mayor puntaje se considera el ganador.
2.5. Evaluacin financiera
Es el proceso mediante el cual el administrador del proyecto define y evala las caractersticas y
los factores econmicos de los equipos a considerar.
2.6. Alternativas de adquisicin y financiamiento
Renta
Es el proceso por el cual el usuario renta el equipo del proveedor por un perodo definido como
obligatorio, al trmino del cual suelen presentarse tres alternativas:

Cancelar el contrato y devolver el equipo al proveedor

Renovar el contrato de renta, negociando si es posible un descuento sustancial.

Ejercer la opcin de compra del equipo.

El alquiler de computadoras tiene algunas ventajas con respecto a la adquisicin del equipo:

No implica un desembolso inicial de dinero.

El proveedor es responsable por el mantenimiento del equipo.

No es una opcin obligatoria en el largo plazo.

Evita la obsolescencia y es ms fcil hacer un cambio por un equipo posterior.

Existe una ventaja fiscal por ser un gasto deducible para pago de impuestos.
Algunas desventajas son:

Es ms costosa si es a largo plazo.

Est sujeta a incremento por parte del proveedor.

Compra
Una segunda opcin es la compra de un equipo computacional. Las ventajas son:

Resulta ms barato cuando se requiere por largos perodos.

No existen incrementos de los pagos.

Al final del perodo el equipo tiene un valor de recuperacin.

Algunas posibles desventajas son:

Obsolescencia.

Error en la seleccin del equipo.

Desembolso considerable de dinero.

51

Incertidumbre sobre el valor de reventa o cada en desuso total.

2.8. El mtodo del costo / rendimiento

Este mtodo propone calificar y clasificar a los sistemas ofrecidos segn la relacin costo /
rendimiento. De la aplicacin de este mtodo resulta como mejor oferta aquella que, en conjunto, es
potencialmente ms capaz como consecuencia de promediar y compensar el ndice de potencialidad con el
costo de implementacin. De esta manera resultar recomendada, siempre que se clasifique y pondere con
"criterio", la que mejor se ajuste a las necesidades y posibilidades de la empresa.

Fase 1: verificacin de requisitos mnimos

Esta fase comn a todos los procedimientos de evaluacin de ofertas, tiene como finalidad la
verificacin de que todas las propuestas cumplan las condiciones mnimas establecidas en el pliego de
especificaciones tcnicas, donde se determinan los requerimientos mnimos que debern ser atendidos.
Estos requerimientos mnimos deben ser desdoblados considerando:

exigencias que constituyen el objeto principal de la contratacin y que estn definidas en

trminos precisos, expresados en magnitudes cuantificadas y cuantificables. Pueden citarse para este
grupo:
o
Parmetros de seleccin de hardware
o
Parmetros de seleccin de software
o
Soporte de la firma oferente
o
Pruebas y demostraciones

especificaciones que no constituyen el objeto principal de la contratacin, pero que han

sido expresamente manifestados y que por sus caractersticas no son deducibles de la oferta. Por
ejemplo:
o
Compatibilidad con otros equipos y dispositivos.
o
Posibilidades de ampliacin.
o
Adaptacin de procesos, etc.
Hecho este anlisis se determinan, a partir de las ofertas aceptadas en el acto de apertura, las
propuestas que cumplen con los requerimientos mnimos exigidos. Los remanentes sern considerados en
detalle en la prxima fase.
Fase 2: ponderacin y clasificacin
Este mtodo utiliza cuadros comparativos (grillas) de distintos niveles de consolidacin, donde se
reflejan ponderaciones (P) y calificaciones (CAL) absolutas y relativas para los distintos parmetros de
seleccin.
Los cuadros reflejan conjuntos de tems de importancia relativa equivalente. De este modo se
considera cada conjunto como un todo, que a la vez consolida un conjunto de niveles inferiores e integra
un conjunto de nivel superior.
En el mismo la informacin est dispuesta tabularmente, hallando en las lneas horizontales as
distintas caractersticas a evaluar (FACTOR), y en las columnas las propuestas, existiendo adems
columnas para las calificaciones y ponderaciones.
Las ponderaciones representan el peso asignado a cada una de las caractersticas evaluada en los
distintos niveles, teniendo en cuenta los criterios de evaluacin fijados con anterioridad en el pliego, y que
debieran expresar acabadamente las necesidades de la empresa contratante.
Las calificaciones son elementales a nivel de cada caracterstica evaluada, y absolutas o relativas
para cada oferta en cada cuadro. Las calificaciones elementales asumen valores entre 0 y 3. Para un
determinado factor se dar la calificacin 3 a la oferta que presente mayores prestaciones, y
proporcionalmente a esas prestaciones se asignarn valores a las ofertas restantes. A los atributos de tipo
cualitativo (monitores, memoria cache, etc.) dicha calificacin asume el valor 0 o 3 en funcin de poseer o
no la caracterstica considerada. Las calificaciones absolutas se obtienen como resultado de la sumatoria de
las ponderaciones por las calificaciones elementales de cada oferta; en tanto que las relativas -tiles para
un cuadro de nivel superior - como un porcentaje de la calificacin mxima.

52

Se obtiene la relacin costo/rendimiento para cada propuesta, a partir de la cual se establece un

ranking de las propuestas recibidas, considerndose como ms adecuada aquella que estando dentro de las
posibilidades presupuestarias, haya obtenido el menor cociente.

2.9. Conceptos sobre benchmark

1- Punto de referencia de cota conocida desde el cual pueden efectuarse mediciones.
2. Punto que sirve de referencia para medir cotas, ensamblar rganos, etc.
El termino benchmark, que a menudo se confunde con la funcin afn de demostracin, se caracteriza
por 4 funciones o elementos esenciales:

Medicin del rendimiento de los sistemas;

Programas del usuario, proporcionados por un cliente o presunto cliente como

especificacin o como codificacin real;

Fase de ajuste, cuyo objeto es optimizar el rendimiento del sistema;

Comparacin del rendimiento optimizado de un sistema de un proveedor con el de un

sistema competitivo, o con otro sistema del mismo proveedor.

53

2.10. Tipos de benchmark

Terico:

Sirve para medir tiempos casi en forma exclusiva, es decir, mide velocidades.

Consiste en programas que estn escritos en un lenguaje de aplicacin de alto nivel y que
realiza en forma simple y nica un solo tipo de tarea. Las pruebas bsicamente son para el
procesador, sus recursos (memoria, UAL), y los distintos perifricos: pantallas, discos, impresoras,
etc.

Los programas usan los recursos del sistema de acuerdo a ciertos parmetros
especificados en tiempo de ejecucin. No hace nada productivo con estos recursos, sino que los
ejercita a fin de efectuar mediciones genricas. Por ejemplo, se le podra pedir que lea 1000
registros de un archivo en disco, ejecute 100000 adiciones de punto flotante e imprima 5000
lneas, y que luego indique el tiempo total requerido por este benchmark artificial.

Ventajas:
es rpido, simple, fcil y equitativo porque se usan los mismos programas en
distintos equipos.
No slo se prueba el equipo en s, sino la eficiencia en la administracin de los
recursos por parte del S.0. y la eficiencia del compilador.
Su costo es muy bajo, ya que incluso hay proveedores que tienen disponible este
software.
No requiere desarrollos ni adecuacin, ni costo de conversin ni capacitacin.
Con estas pruebas no slo se valoriza el hardware, sino tambin el software, ya
que esta es una muy buena oportunidad para evaluar el software, los
compiladores, editores, etc.

Inconvenientes:

no puede evaluar los componentes complejos del procesamiento, ni

tampoco las vinculaciones y/o interacciones entre programas, o entre programas
y el S.O.
Real:

Consiste en la prueba completa de la totalidad los sistemas de aplicacin del cliente, con
todos sus programas. Para ello es imprescindible que exista la facilidad de transmisin, ya sea va
magntica y/o comunicaciones. A posteriori se debern recompilar las fuentes y reorganizar las
bases de datos, sobre todo los ndices. Una vez hecho esto se toman los tiempos de cada uno de los
programas durante su ejecucin.

Es un conjunto de programas tomados de la carga de mquina del usuario y

transformados en un modelo adecuado de la carga de mquina total. A pesar de los problemas
existentes en cuanto a representatividad, existe un consenso general de que a los efectos de la
seleccin de un equipo de computacin, el benchmark real es la herramienta preferida para la
medicin de performance.

Ventajas:

Tiene la propiedad de evaluar en forma completa los recursos del equipo

y su sistema operativo.

Evala en forma equiparable, los programas que se usan en un equipo

actual. Sirve para verificar las diferencias entre los distintos compiladores para el
mismo lenguaje, y comparar aquellos.

Da una idea del costo que significa la conversin.

Inconvenientes:
es lento, costoso y a veces suele ser demasiado complicado llevarlo a cabo,
sobre todo cuando no existe la posibilidad de traslacin de datos entre un equipo
actual y aquel al cual se quiere hacer las pruebas.
Slo prueba los programas en la forma en la que se usan actualmente, sin
posibilidad de aprovechar los recursos nuevos o diferentes que puede haber
entre los distintos equipos, y/o sistemas operativos, y/o lenguajes.
Optimizado:

Consiste en una prueba de los sistemas que se posee pero haciendo uso de los nuevos
recursos que tiene el S.O. y/o equipo, o los compiladores, o los nuevos lenguajes.

54


Estos recursos no han sido contemplados o aprovechados por el sistema habida cuenta de
la inexistencia de los mismos en la instalacin. Esta prueba es fundamental para poder comparar
las distintas formas de manejar los datos y editar la informacin.

Adems, sirve para comparar el tiempo y el costo de desarrollar esas modificaciones en

los sistemas para adecuarlos a esas nuevas posibilidades.

Ventajas:
es imprescindible para poder comparar realmente las grandes diferencias en
cuanto a prestaciones y sus ventajas entre los distintos equipos o S.O.
Brinda la posibilidad de poder evaluar el costo de estos cambios y sus
beneficios, tanto para los usuarios de las aplicaciones como para quienes las
desarrollan.

Inconvenientes:
requiere ms tiempo, esfuerzo y costo que incluso el benchmark real.
No todos los proveedores estn dispuestos a realizar estas pruebas, y a veces los
resultados son contrapuestos; esto obliga a que se deban realizar los tres tipos de
prueba, evaluar los resultados, y luego una ponderacin que se otorga a cada uno
de ellos al hacer el polinomio de calificacin.
3. Lanzamiento de un sistema de informacin
3.1. Contrataciones
Lista de actividades que podran desarrollarse:

Definicin de necesidades de adquisicin o arrendamiento de hardware, software y / o

servicios de proveedores.

Definicin de factores de evaluacin de hardware: desempeo, costo, confiabilidad,

disponibilidad, compatibilidad, modularidad, tecnologa, ergonoma, conectividad, tamao,
configuracin, costo y soporte.

Definicin de factores de evaluacin de software: eficiencia, flexibilidad, seguridad,

conectividad, lenguaje, documentacin, plataforma de procesamiento, costo, soporte y otros
factores de inters.

Definicin de factores de evaluacin de servicios: disponibilidad, trayectoria profesional

de los consultores, certificacin y reputacin del oferente a otras firmas, costos y otros factores de
inters.

Redaccin de los pliegos de especificaciones tcnicas de la contratacin.

Lanzamiento de la contratacin.

Evaluacin de ofertas:

Pruebas y ensayos
Sobre los dispositivos de hardware y sistemas operativos.
Sobre los aplicativos de software
Sobre el funcionamiento concurrente de hardware, sistemas operativos
y aplicativos.

Grillas comparativas de caractersticas costo y rendimiento (benchmark).

Adjudicacin de la contratacin al proveedor.

3.2. Documentacin
El desarrollo de una buena documentacin para el usuario es una parte importante del proceso de
lanzamiento de una aplicacin.
El manual del usuario de cada aplicacin, debe incluir:

Disposiciones generales.

Instructivos.

Objetivos.

Flujogramas de navegacin

Polticas.

Reportes.

Descripcin de la aplicacin.

Informacin sobre reportes.

Flujo general de trabajo.

Muestra del reporte.

Descripcin de procedimientos.

Descripcin del reporte.

Pantallas

Glosario de trminos.

Formularios.
3.3. Capacitacin de usuarios

55

La participacin en los sistemas informticos y su aceptacin por el personal es la parte ms

importante y difcil de la implementacin.
Despus de una capacitacin prctica apropiada, los usuarios deben visualizar los beneficios del
sistema implementado. Es necesario definir un programa estructurado para el desarrollo de recursos
humanos a fin de aumentar la conciencia, evaluar las necesidades de adiestramiento e incluir a los
miembros del personal en todos los aspectos del diseo e implementacin de sistemas con el objetivo de
lograr una comprensin de las metodologas y la tecnologa de los sistemas de informacin.
Las acciones prcticas en lo referente al establecimiento de un programa para el desarrollo y la
capacitacin de recursos humanos incluyen:

Asegurar, cuanto antes, la identificacin y la seleccin de los miembros del personal que
participan en todos los niveles de implementacin y operacin de los sistemas con el objetivo de
recibir capacitacin pertinente, terica y prctica, en los sistemas de informacin y en la
tecnologa de sistemas.

Considerar los temas asociados con el entorno de la organizacin en el cual se

implantarn y utilizarn los sistemas.

Disear estrategias de capacitacin para los sistemas de informacin, las cuales tengan
en cuenta los temas asociados con su desenvolvimiento, el entorno orgnico en el cual se prev su
funcionamiento y las circunstancias particulares de la organizacin.
A continuacin se recomiendan normas sobre las estrategias para capacitacin de usuarios de
sistemas informticos:

Identificar los grupos destinatarios sobre la base de las funciones de los usuarios.

Analizar los requisitos previstos de desempeo de los usuarios en relacin con el sistema
nuevo mediante un modelo participativo que abarque todas las categoras y funciones.
Evaluar las necesidades de capacitacin, incluido el nivel actual de comodidad y conocimiento de las
tecnologas que se van a emplear.

Elaborar programas de capacitacin para satisfacer las necesidades identificadas de los

grupos destinatarios.

Establecer una red de puntos focales para la capacitacin, los cuales toman en cuenta los
requisitos y las iniciativas de las unidades de la organizacin.

Una estrategia de capacitacin para las formas modernas de procesamiento y anlisis de

informacin debe abarcar a todos los participantes y tener carcter interdisciplinario, sin dejar de
considerar las necesidades particulares de los diferentes grupos funcionales y profesionales.
Cada organizacin debe elaborar su propia estrategia para la capacitacin inicial y continua en los
sistemas de informacin, la cual tiene en cuenta, por un lado, el desarrollo general de los sistemas de
informacin y, por otro, el entorno particular de cada sistema implementado.
Para ello se debe:

Llevar a cabo la capacitacin en un entorno multidisciplinario.

Utilizar herramientas didcticas tecnolgicas avanzadas siempre que sea posible.

Proporcionarse capacitacin en el trabajo a todos los niveles para satisfacer los requisitos
cotidianos.

Vincular la educacin y la capacitacin con las experiencias prcticas para lograr la

motivacin de los usuarios.

Prestar mucha atencin de acuerdo con el grupo destinatario para evitar el uso excesivo
de jerga tecnolgica y complejidad de conceptos.

Definir los niveles mnimos de capacidad.

Proveer de recursos para respaldar la preparacin de material de enseanza y para

permitir la adaptacin del material de capacitacin a fin de satisfacer las necesidades de grupos
destinatarios de distintos niveles.

En la capacitacin debe incluir conocimientos de computacin bsica y prctica,

capacitacin especfica en las aplicaciones, desempeo y funciones individuales en la operacin
del sistema.

Probar los programas de capacitacin antes del uso a gran escala.

La metodologa de presentacin permitir la interaccin de los participantes.

La capacitacin se realizar lejos de las distracciones del ambiente de trabajo cotidiano y

lo ms cerca que sea posible a la implementacin real.

56


Las actividades del grupo ayudarn a reducir la formulacin tediosa de algunos temas
tcnicos.

Las situaciones simuladas, las presentaciones grupales o individuales determinarn en

qu medida los participantes lograron el nivel de conocimiento o el dominio de las aptitudes
indicadas por los objetivos.

Evaluar la eficacia de los programas de capacitacin mediante la satisfaccin y la

retroalimentacin de los usuarios, la retroalimentacin de los administradores, la situacin previa
y posterior a la evaluacin, y la frecuencia y el tipo de llamadas solicitando asistencia durante el
uso de los sistemas, resulta imprescindible como etapa final.
3.4. Implantacin
A los fines de la puesta en marcha del sistema pueden seguirse cuatro mtodos de conversin:

Paralela: el sistema antiguo y el nuevo operan hasta que el equipo de desarrollo

de proyectos y la gerencia de usuarios finales acuerden cambiarse por completo. Durante
este tiempo es cuando deben compararse y evaluarse las operaciones y los resultados de
ambos sistemas. Los errores pueden identificarse y corregirse, y los problemas
operacionales pueden solucionarse antes de que abandonen el sistema antiguo.
Beneficios similares se generan a partir del uso de una conversin piloto.

Por fases: se convierten slo partes de una nueva aplicacin o slo unos cuantos
departamentos, sucursales o plantas a la vez. Esto permite que tenga lugar un proceso de
implementacin gradual dentro de una organizacin.

Piloto: un departamento u otro sitio de trabajo actan como lugar de prueba. En

este sitio puede probarse un sistema nuevo hasta que las personas encargadas del
desarrollo consideren que puede implementarse en toda la organizacin.

Desmontes repentinos (sustitucin)

3.5. Mantenimiento de S.I.

Una vez que el sistema se encuentra implementado comienza el mantenimiento.

Es la supervisin, evaluacin y modificacin de sistemas de informacin operacionales

para realizar los mejoramientos necesarios o deseados.

Un nuevo sistema genera el fenmeno curva de aprendizaje. El personal que lo opera y

utiliza cometer errores simplemente porque no est familiarizado con l y aunque estos errores
generalmente disminuyen a medida que se adquiere experiencia con el sistema, estos sealan reas
donde se lo podra mejorar.

El mantenimiento es tambin necesario para otras fallas y problemas que surgen durante
la operacin de un sistema.

La actividad incluye tambin un proceso de revisin despus de la implementacin, para

garantizar que los sistemas recientemente implementados satisfagan los objetivos de desarrollo de
sistemas que se les han establecido.

Los errores en el desarrollo o el uso de un sistema deben corregirse mediante el proceso

de mantenimiento. Este incluye una auditora o revisin peridica de un sistema, con el fin de
asegurarse de que este operando en forma apropiada y de que este logrando sus objetivos.

La auditoria es para supervisar continuamente el nuevo sistema en busca de problemas

potenciales o cambios necesarios. El mantenimiento incluye la realizacin de modificaciones a un
sistema debido a cambios en la organizacin o el entorno empresarial. Por ejemplo, una nueva

57

legislacin tributaria, las reorganizaciones de empresas y las nuevas incursiones empresariales

usualmente requieren que se realice una variedad de cambios en los sistemas de informacin.

58