RESUMEN INFORMATICA IV

PUDS FASES:
 Inicio  Modelado de Negocio
Flujos de trabajo
 Elaboración  Requerimientos
 Construcción  Análisis
AyDS
 Transición

 Diseño
 Implementación Info IV
 Prueba

Cada Flujo se trabajo se describe enunciando:

 Actividades
 Artefactos
 Trabajadores

UNIDAD N° 1
MODELO DE DISEÑO

Modelo de Análisis:
 Terminado el modelo se tiene una descripción detallada de todos los requisitos del
sistema.
Modelo de Diseño:
 Constituye una formalización y refinamiento adicional al modelo de análisis.
 Modelo de objetos representando la realización física de los casos de uso.
 Permite conocer especificaciones muy detalladas de todos los objetos,
incluyendo operaciones y atributos.
 Se definirán explícitamente las interfaces de los objetos y la semántica de las
operaciones.
 Se compondrá de bloques que constituirán los objetos de diseño, que luego serán
implementados como código fuente, abstrayendo la implementación real.
 Inicialmente cada objeto de análisis se transformará en un bloque, teniendo
rastreabilidad en los modelos.
 Es una abstracción de cómo el sistema se construye realmente y nos permite
reducir la complejidad del mismo.
 Es la última parte de la iteración de elaboración y comienza la de construcción.
 Se deben tener definidas las herramientas que se utilizarán en el desarrollo de la
aplicación, ya que muchas cosas se pueden dejar listas y autogenerarlas para el modelo
de implementación.
Para desarrollar el modelo de diseño debemos:
Identificar el ambiente de implementación: Identificar e investigar las consecuencias que el
ambiente de implementación tendrá sobre el diseño.
Incorporar estas conclusiones y desarrollar un primer enfoque del modelo de diseño:
Usamos el modelo de análisis como base y traducimos los objetos de análisis a objetos de diseño,
de acuerdo al ambiente actual de implementación.

1
Describir cómo interactúan los objetos en cada caso de uso específico: El modelo de diseño
se focaliza en describir todos los estímulos enviados entre objetos y qué operación hará cada uno.
Este proceso nos dará las interfases de cada objeto.
Rastreabilidad:
 Se puede rastrear una clase desde el código fuente al análisis y viceversa.
 Es importante porque a medida que el sistema tiene cambios a lo largo de su
ciclo de vida se necesita saber siempre dónde se deben hacer los cambios en el
código fuente.
Artefactos
1.-Clases de diseño:
 Son abstracciones de clases de implementación.
 Muchas características de las clases tienen relación directa con el lenguaje
de programación, por eso es necesario tenerlo elegido en esta instancia.
 Se deben definir para cada clase sus métodos, atributos, parámetros, tipos,
visibilidad de los atributos (públicos, protegidos, privados, amigos).
2.-Realización de casos de uso de diseño:
 Se vinculan directamente con las realizaciones de casos de uso de
análisis, los cuales se relacionan con casos de uso de modelos de casos de
uso (así se traza rastreabilidad a través de los distintos modelos).
 Se tienen en cuenta los distintos requerimientos no funcionales que se
fueron recolectando.
 Las realizaciones poseen:
 descripción textual del flujo de eventos,
 diagramas de clases,
 diagramas de interacción.
Diagramas de clases:

 Las clases y subsistemas pueden intervenir en más de un caso de una

realización de casos de uso.
 A través 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

Usuario
Entidad de control de personal
Nombre
Apellido
Obtener datos de usuarios()
Dirección
Actualizar datos de usuarios()
Telefono
Imprimir resultados()
Id Empleado
Generar consulta de usuarios()
Ingresar()
Borrar()
Administrador de Modificar()
sistema Interfaz Salida
Botones de Comando
Etiquetas

visualización()
Confirmación()

Diagramas de interacción:
2
 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 diseño desde el punto de vista de los casos de uso
observando qué mensajes se envían a los objetos, componentes o casos de
uso y viendo grosso modo cuánto tiempo consume el método invocado.
o Ayudan a comprender los cuellos de botella potenciales para poder
eliminarlos.
o Conceptos relacionados:
Línea de vida de un objeto (lifeline):
 Representa la vida del objeto durante la interacción.
 Un objeto se representa como una línea vertical punteada con
un rectángulo de encabezado y con rectángulos a través de la línea
principal que denotan la ejecución de métodos (activación). El
rectángulo de encabezado contiene el nombre del objeto y el de su
clase en un formato nombreObjeto:nombreClase.
Activación:
 Muestra el período de tiempo en el cual el objeto se
encuentra desarrollando alguna operación.
 Se denota como un rectángulo delgado sobre la línea de vida
del objeto.
Mensaje:
 Se denota mediante una línea sólida dirigida desde el objeto
que emite el mensaje hacia el objeto que lo ejecuta.
Tiempos de transición:
 En un entorno de objetos concurrentes o de demoras en la
recepción de mensajes es útil agregar nombres a los tiempos de
salida y de llegada de mensajes.

: Administrador de Interfaz entrada Gestor Personal Usuarios Interfaz Salida

sistema
Ingresa opcion

Solicita Ingres o Datos

Ingresa Datos

Datos a chequear

Solicita busqueda de Datos

Devuelve Datos

Chequea consistencia

Solicita visualización de la transacción

Visualiza Transacción

3
3.-Subsistema de diseño:

 Permite organizar y agrupar las clases de diseño de acuerdo a su

funcionalidad (hará mas manejable el modelo).
 Debe existir independencia entre los subsistemas para lograr su
reutilización y a la hora de las modificaciones, ya que los cambios en unos no
afectarán a los otros.
 Subsistema de servicio: prepara al sistema para cambios de servicios
individuales.

4.-Interfaz:

 A través 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 métodos conformarán la interfaz.
 Si se cambia el código de un método pero no se cambia ni su nombre, tipo y
parámetros, sólo se habrá cambiado funcionalidad y no su interfaz, por lo cual las clases
relacionadas a ésta no deberían sufrir ninguna modificación.
 Si se agregan parámetros o se cambian tipos, sí se debe cambiar la forma en que
estas clases se relacionaban.
5.-Descripción de la arquitectura:

 Debe estar constituida por:

definición de subsistemas que conforman el modelo de diseño,
con sus interfaces,
clases de diseño relacionadas directamente con clases de
análisis que conformaban la vista del la arquitectura del modelo de
análisis,

4
 realizaciones de casos de uso relevantes, los cuales tienen una
relación con las realizaciones del modelo de análisis y con los casos de
uso del modelo de casos de uso.

6.-Modelo de despliegue:

 Permite representar cómo será la distribución física del sistema, o sea dónde
residirá físicamente cada uno de los componentes (clases de interfaz, de control,
de entidad).
 Las ubicaciones físicas se denominan nodos.
 Existen relacionen entre ellos representadas por medios de comunicación: 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 aplicación).
 Otros nodos contienen las clases de control, que residen en los servidores de
aplicación.
 Hay nodos donde estarán las clases de entidad que luego constituirán los repositorios
de datos (BASES DE DATOS).

Servidor de Base de
Datos Terminal de
ventas

Terminal de
administración

Trabajadores
Arquitecto:
 Responsable de asegurar que el modelo de diseño y de despliegue se
correspondan con el modelo de casos de uso y de análisis.
 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 análisis.
 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 estén totalmente claras.
Ingeniero de componentes:
 Es el encargado de definir todo lo referido a las clases del diseño y también de
los subsistemas de diseño.
 Para las clases define sus métodos, 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
5
Diseño de la arquitectura:

 Comenzamos en esta etapa a definir los modelos de diseño y de despliegue,

utilizamos para ello los siguientes elementos:
a. Nodos y sus configuraciones de comunicación.
b. Subsistemas y sus interfaces.
c. Clases de diseño relevantes para la arquitectura.
d. Mecanismos genéricos de diseño.
a) Nodos y sus configuraciones de comunicación:
 Toda aplicación está compuesta por tres capas, una encargada de la interfaz
con el usuario, otra de almacenamiento de la información y una capa intermedia
encargada de procesar las reglas y lógica del negocio.
 Estas capas pueden tener tanto una división lógica como física:
división lógica: en la aplicación se encuentran muy bien
divididas las tres funcionalidades de estas capas,
división física: estas capas pueden residir en nodos
diferentes.
 Las primeras aplicaciones, manejaban estas tres capas todas juntas, tanto física
como lógicamente. El procesamiento se realizaba en las mainframes y los usuarios
accedían a él a través de terminales bobas.
 Luego aparecieron aplicaciones partidas lógicamente 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 sólo la función de capa de interfaz, tomando la
información que los usuarios ingresan al sistema, enviando esto hacia el
servidor y mostrando lo que dicho servidor envía hacia el puesto.
Cliente inteligente: en este caso el cliente no cumple únicamente la
función de interfaz con el usuario sino también las funciones de la capa intermedia,
realizando todos los chequeos y controles necesarios antes de hacer llamadas a la
capa de datos.
 Por último, están aquellas aplicaciones partidas lógicamente en tres capas (podrían
estar o no divididas también físicamente.):
 En estas aplicaciones están aisladas las tres funcionalidades de una
aplicación: interfaz, control y datos.

6
  Entre las distintas ventajas está la posibilidad de aumentar el rendimiento de
la aplicación a medida que existan más 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 sucedería con los servidores de base de batos, donde hay dos
variantes de este modelo:
Aplicaciones que se ejecutan en cada estación de trabajo,
generalmente realizadas en lenguajes de programación, como Visual
Basic.
Aplicaciones que se ejecutan en un servidor web y son
accedidas desde las estaciones de trabajo por algún 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 están instaladas en servidores web, éstos pueden ir creciendo y
agregando nuevos servidores a medida que la aplicación aumente
sus requerimientos de rendimiento.
 En este punto del flujo se analizan los distintos nodos que se utilizarán, con sus
características técnicas, como las conexiones que existirán entre éstos.
b) Subsistemas y sus interfaces:
 Objetivo de subsistema: organizar el modelo de diseño en piezas manejables.
 A partir de los paquetes de análisis y de servicios definidos se deben identificar
los subsistemas que existen.
 Si la clase de un subsistema interactúa con una clase de otro sistema, se definirá
una relación 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 métodos que
esta expone hacia fuera para que sean invocados por otras clases).
c) Clases de diseño relevantes para la arquitectura:
 Es importante detallar las clases que hay que tener en cuenta para la
arquitectura.
 No debemos analizar un gran número de clases ni bajar en un nivel de detalle
extremo en ese momento, sólo analizar las relevantes para la arquitectura.
 El análisis más fino se hará en el diseño de clases y en el de casos de uso.
d) Mecanismos genéricos de diseño:
 Se trata de todos aquellos requisitos especiales que fuimos detectando en
modelos anteriores y pospusimos hasta tener mejor definidas las características
más técnicas del proyecto (plataforma de cada capa, lenguajes, bases de datos).
 Suelen relacionarse con:
Persistencia.
Distribución transparente de objetos locales y remotos.
Seguridad.
Mono o multiusuario.
Manejo de errores.
Transacciones.
Arquitectura de la aplicación (una, dos o más capas lógicas).
Tipos de interfaz de usuario (Windows o Web).

Diseño de un caso de uso:

Éste tiene como objetivos:

7
 a) Identificación de clases de diseño.
b) Interacciones entre objetos.
c) Identificación de subsistemas de diseño.
d) Interacciones entre subsistemas.
a) Identificación de clases de diseño.
 Para cada realización de caso de uso se recogen todas las clases del diseño que
intervienen a través de un diagrama de clases de diseño.
 Tomaremos el caso de uso - análisis con sus clases de análisis correspondientes y
en base a esto y al resto de la información recabada hasta el momento para dicho caso
detectaremos todas las clases con sus respectivas relaciones.
 Para cada clase de diseño asignaremos un ingeniero de componentes como
responsable de la misma.
b) Interacciones entre objetos.
 Se definen cómo interactúan las clases que intervienen en cada realización de
caso de uso.
 Se utiliza un diagrama de secuencia que contiene instancias de actores, los objetos
de diseño y las transmisiones de mensajes entre estos.
 Se transforma el diagrama de colaboración de la realización de caso de uso-
análisis 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 erróneos de información por parte de actores,
errores generados por la misma aplicación o por hardware.
c) Identificación de subsistemas de diseño.
 Se tomarán los paquetes de análisis detectados en el modelo de análisis y
además aquellos requisitos que dejamos para esta etapa de diseño y con esto se
delinearán los distintos subsistemas de diseño que intervendrán en el sistema.
 Se utilizará un diagrama de clases.
d) Interacciones entre subsistemas.
 Para detectar las interacciones que existen entre los distintos subsistemas se
utilizarán los diagramas de secuencia.
 Se reflejan las relaciones entre los actores y subsistemas a través del envío de
mensajes entre los mismos
Diseño de una clase:
 Ya se tiene claro cuál será el rol exacto de cada clase dentro de las distintas
realizaciones de casos de uso. Ya se trazó la relación con las clases detectadas en el
modelo de análisis.
 Pasemos a analizar para cada una de ellas:
o operaciones,
o atributos,
o relaciones,
o métodos,
o estados.
 En el caso de las clases de entidad el análisis 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 aplicación.
 En las clases de interfaz el diseño de las mismas está muy ligado al lenguaje de
programación que se utilizará.
a) Operaciones
 Las responsabilidades detectadas en las clases de análisis implican una o
varias operaciones para las clases de diseño.

8
  Deben cubrir todas las operaciones que sean necesarias en todas las
realizaciones de casos de uso - diseño en los que las mismas participen.
 Es necesario describir, utilizando la sintaxis del lenguaje de programación,
la visibilidad de cada operación (publica, privada, protegida).
b) Atributos
 Debemos identificar en detalle los distintos atributos o propiedades de cada clase
en la sintaxis del lenguaje de programación.
 Se deben identificar los tipos de cada atributo, que dependerán del lenguaje
elegido.
c) Relaciones
 Se deben dejar muy bien reflejados los distintos tipos de relaciones que existan
entre las clases de diseño.
 Una entrada para esto son los diagramas de interacción (colaboración y secuencia)
ya que en éstos se manifiestan las relaciones y los envíos 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 características en aquellos objetos comunes.
d) Métodos
 Éstos especifican cómo se realizan las distintas operaciones, es recomendable
utilizar lenguaje en pseudo código y siempre teniendo en cuenta el lenguaje de
programación que utilicemos.
e) Estados
 Con el objeto de agregar mayor detalle para la implementación 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 través 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
aplicación junto con los cambios que permiten pasar de un estado a otro.
Estado:
 Identifica un periodo de tiempo del objeto -no instantáneo- en el cual él está
esperando alguna operación, tiene cierto estado característico o puede recibir
determinado tipo de estímulos.
 Se representa mediante un rectángulo con los bordes redondeados que puede tener
tres compartimientos: uno para el nombre, otro para el valor característico 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 transición 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.
Envío de mensajes
 Puede representarse el momento en el cual se envían mensajes a otros objetos.
 Esto se realiza mediante una línea punteada dirigida al diagrama de estados del
objeto receptor del mensaje.

Diseño de un subsistema:
 Los puntos clave a tener en cuenta son:

9
  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 Práctico

1.- Diagrama de casos de uso

Los casos de uso especifican una interacción 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 vehículo
 Antes de disponer del vehículo 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 basándose en una serie de criterios, como por
ejemplo la disponibilidad de los vehículos 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 depósito completa el proceso de reserva.
El cliente acude por el vehículo
 Cuando el cliente llega a la agencia de vehículos ésta le asigna el modelo de
vehículo solicitado según los niveles de stock disponibles.
 Una vez abonado el importe total el cliente recibe el automóvil.
El cliente devuelve el vehículo
 El cliente devuelve el vehículo a la agencia el día especificado en el acuerdo de
alquiler.

2.-Diagrama de clases de estructura estática

 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 estática o de
clases que muestran la estructura general del sistema, así como las propiedades
relacionales y de comportamiento.

10
3.- Diagrama de secuencia
 Proporcionan una vista detallada de un caso de uso.
 Muestran una interacción organizada en una secuencia de tiempo y ayuda a
documentar el flujo de lógica dentro de la aplicación.
 Los participantes se muestran en el contexto de los mensajes que se transfieren
entre ellos.

4.-Diagrama de colaboración
 Los diagramas de colaboración constituyen otro tipo de diagrama de interacción.
 Muestran cómo operan los objetos de un grupo entre sí en un caso de uso.
 A cada mensaje se le asigna un número para documentar el orden en el que tiene
lugar.

11
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 estímulos externos.
 El diagrama de estados asigna estos estados, así como los eventos de activación
que hacen que un objeto se encuentre en un estado determinado.

6.-Diagrama de actividades
 Los diagramas de actividades muestran la lógica que tiene lugar como respuesta a
las acciones generadas internamente.
 Está relacionado con una clase o caso de uso específico y muestra los pasos que se
deben realizar para llevar a cabo una operación determinada.

12
7.-Diagrama de despliegue
 Muestran cómo están configurados el hardware y el software del sistema.

8.-Diagrama de componentes
 Corresponden al modelo de implementación.
 Muestran cómo 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 vehículo, registros de servicios y detalles del cliente
y del empleado.
 Resulta esencial que estos datos se centralicen en una base de datos porque los
niveles de stock varían con las horas y todas las partes deben disponer de información
de última hora.
 El mantenimiento de los datos actualizados requiere actualizaciones de la
información en tiempo real de todas las partes.

13
 UNIDAD N°2
MODELO DE IMPLEMENTACION

Modelo de Implementación:
 Busca implementar cada objeto específico en términos de componentes (scripts, archivos
de código binario – ejecutables-,etc.).
 Son herramientas fundamentales los lenguajes de programación y las librerías.
 Se toman los resultados del diseño para convertirlos en un software ejecutable; un
sistema que integra componentes expresados en archivos fuentes, ejecutables, código binario y
similares dándole comportamiento concreto al modelo.
 La implementación es el proceso protagonista durante las iteraciones de la fase de
construcción. Observe que también se desarrolla trabajo de implementación durante las fases de
elaboración y transición. Generalmente en estos casos, las actividades de implementación dan
soporte a los flujos de análisis y diseño mediante prototipos; y la corrección de errores empotrados
en el código, respectivamente.
 Los propósitos de este flujo de trabajo son los siguientes:
 Planificar en pasos pequeños y manejables (enfoque incremental) las integraciones
de sistema necesarias en cada iteración.
 Definir la organización que tendrá el código en términos de subsistemas y capas de
proceso, mostrando la asignación de componentes ejecutables a nodos del diagrama de
despliegue.
 Implementar clases y objetos en términos de componentes (archivos de código
fuente, archivos binarios, archivos ejecutables, etc.), mostrando la asignación y
distribución de los mismos en un diagrama de componentes.
 Probar los componentes individuales implementados, compilando e integrándolos
en uno o más ejecutables libres de errores.
 Integrar los resultados producidos por desarrolladores individuales o equipos en un
sistema ejecutable.
Relación con otros flujos de trabajo
Algunas vinculaciones entre el flujo de trabajo implementación y los demás 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 análisis y diseño 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 serán incluidos durante
cada una de las integraciones de subsistemas y sistemas que acontecen durante este flujo de trabajo.
2.1. Implementar el diseño
 Cada clase del diseño es implementada codificando en un lenguaje de programación, o
utilizando un componente preexistente. Por eso la manera en que una clase del diseño será
concretamente implementada depende del lenguaje utilizado.
 El modelo de diseño puede ser más o menos ajustado al modelo de implementación
dependiendo de cómo haga corresponder las clases o construcciones similares en el lenguaje de
implementación elegido.
 Es necesario disponer antes de que el diseño comience, la forma en que las clases en el
modelo de diseño se relacionan con las clases de implementación asentando esta decisión en la Guía
de Diseño.
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 métodos tradicionales se consideran los siguientes tipos de pruebas:
 Pruebas de unidad: prueba de cada componente individual
 Pruebas de integración: prueba de funcionamiento de subsistemas
 Pruebas de Sistema: prueba de funcionamiento del sistema como un todo.

14
  Esta categorización es correcta, sin embargo el problema surge cuando se decide integrar
los subsistemas y el sistema total cuando casi se ha concluido la codificación de los componentes y
se definen equipos de pruebas que actuarán por etapas. Puede ser muy tarde, los errores podrían
propagarse sin ser detectados por los diferentes equipos de prueba.
 Las fallas descubiertas podrían develar graves problemas de diseño 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 sería peor aún, no deje las pruebas de componentes para el final de la fase de construcción. En
cada iteración, de la fase construcción, en cada construcción, aún en la fase de elaboración, haga
pruebas de integración y pruebas de sistema.

2.3. Entornos de desarrollo e integración

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.
 No es necesario que en este espacio el desarrollador disponga de los demás
subsistemas sobre los cuales no tiene responsabilidad.
 Es recomendable por otra parte que cada programador tenga acceso
mediante un repositorio común desde donde acceder a otros subsistemas y librerías
de uso compartido.
o Un entorno de integración de subsistemas para el grupo de desarrollo:
 A veces equipos de implementadores desarrollan simultáneamente 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 integración al sistema total. Un miembro del equipo de desarrollo
actúa como integrador, siendo su responsabilidad también su
mantenimiento y rendimiento.
o Un entorno de integración del sistema total:
 Quién o quiénes cumplan con el rol de integrador deberán contar con un
entorno de integración del sistema total en el que puedan agregar los
componentes individuales y/o subsistemas que resultaran al cabo de cada
iteración en una Construcción.

Flujo de trabajo de implementación

 Estructurar el Modelo de Implementación es la primera actividad desarrollada en el marco
de la Implementación.
 Los flujos: requerimientos, análisis y diseño ocurren con preeminencia en la Fase de
Elaboración. En esa etapa comenzamos a dar forma al Modelo de Implementación.
 En cada iteración, y en la medida en que avanzamos hacia la fase de Construcción –donde
subsisten declinando su incidencia actividades de requerimientos, análisis y diseño- toman mayor

15
 protagonismo las de: Estructuración del Modelo de Implementación, Planeamiento de la Integración,
Implementación de Componentes, Integración de los Subsistemas y el Sistema como un todo.

Actividades

3.1. Estructurar el modelo de implementación

El propósito del flujo de trabajo Estructurar el Modelo de Implementación es:
 Identificar los componentes significativos arquitectónicamente (ejecutables).
 Asignar componentes a los nodos de red.
 El propósito de esta actividad desarrollada por el arquitecto de software es establecer la
arquitectura en la que se apoyará la implementación y la asignación de responsabilidades para
subsistemas de implementación y sus respectivos componentes.
 Un modelo de implementación bien organizado resulta en la ocurrencia de un número
menor de conflictos durante el desarrollo de componentes y el proceso de construcción; también
previene problemas de configuración 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 definición de Modelo de Implementación. La naturaleza del trabajo a
desarrollar sugiere que la o las personas que administran esta actividad posean experiencia en la
construcción, administración de la configuración y el lenguaje de programación que se utilizará para
implementar el sistema.
Lineamientos de Trabajo
 Estructurar el modelo de implementación es algo que debemos hacer en paralelo con la
evolución de otros aspectos de la arquitectura.

16
  La actividad Estructurar el Modelo de Implementación a su vez contempla los siguientes
pasos:
 Crear el modelo de implementación inicial
 Ajustar los subsistemas de implementación
 Definir los imports – referencias a otros componentes - necesarios para cada
subsistema.
 Decidir cómo tratar los ejecutables.
 Decidir cómo tratar los elementos de prueba.
 Actualizar la vista de implementación.
Crear el modelo de implementación inicial
 La primera versión del modelo de implementación se obtiene como una copia espejada de
la última versión del Modelo de Diseño.
 Los paquetes de diseño se expresan como subsistemas compuestos a su vez de
componentes y todos los archivos relacionados necesarios para implementarlos.
 Considere que cada clase del diseño será un componente implementado codificando en un
lenguaje de programación o empleando un componente preexistente. La manera en que una clase del
diseño será concretamente implementada dependerá del lenguaje utilizado.
Ajustar los subsistemas de implementación
 El propósito de este paso es adaptar la estructura del modelo de implementación a
cuestiones tácticas relacionadas con el entorno de trabajo. Estas adaptaciones facilitan la
organización del equipo de trabajo y debe expresar, si hubiera, las restricciones del lenguaje de
programación a utilizar.
Definir imports necesarios para cada subsistema
 El objeto aquí es definir las dependencias y visibilidad de componentes entre subsistemas
o módulos.
 Generalmente, las dependencias en el modelo de implementación son heredadas del
modelo de Diseño, excepto cuando la estructura del modelo de implementación ha sido ajustada.
 Se presenta la estructura de capas de los subsistemas en diagramas de componentes.
Decidir cómo tratar ejecutables
 Los ejecutables y otros objetos derivados son el resultado de aplicar un proceso de
construcción sobre un subsistema de implementación, y pertenecen lógicamente a dicho subsistema.
 En el caso más simple, para cada subsistema de implementación habrá un ítem de
configuración (nodo de la red) para cada ejecutable, y un ítem de configuración 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 construcción puede ser representado como un artefacto: el artefacto Construcción
asociado a un subsistema de implementación dado.
Decidir cómo 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 recomendación es aislar estos
componentes en una estructura de directorio o paquete, garantizando su visibilidad; pero facilitando
su eliminación al momento de construir la versión operativa del software.
Actualizar la vista de implementación
 Este paso consiste básicamente en la actualización del documento de Arquitectura de
Software y los diagramas correspondientes al modelo de implementación.
3.2. Planear la integración
 En la planificación de la integración se consideran los subsistemas que serán
implementados así como otros subsistemas existentes que serán integrados en la iteración corriente.
 El propósito del flujo de trabajo Planear la Integración es por lo tanto:
 Planear la integración del sistema para la actual iteración.
Trabajadores
 La integración es hecha habitualmente por una persona o un pequeño equipo.
 Los integradores necesitan experiencia en la gestión de construcciones y
configuraciones de software; pero fundamentalmente se requiere que los mismos posean un
fluido manejo del lenguaje de programación sobre el cual se desarrollaran los componentes.

17
  Debido a que a menudo la integración se desarrolla con un alto grado de
automatización, se requiere también conocimientos en sistemas operativos, interpretes de
comandos y herramientas.
Lineamientos de Trabajo
 La planificación de la integración debe ser hecha tempranamente, al menos de modo
rudimentario cuando se define la arquitectura.
 Con el objeto de evitar que el plan de construcción quede obsoleto, este debe ser
actualizado cada vez que sucedan modificaciones en la arquitectura y el diseño.
 Al menos una vez por cada iteración en las fases de construcción y transición, 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 construcción
 Definir series de construcción.
Identificar Subsistemas
 El plan de la iteración identifica y especifica los subsistemas con sus respectivos casos de
usos y escenarios a ser implementados. En el plan se analizan también las realizaciones de
casos de uso, diagramas de secuencia y colaboración. Se identifican también otros subsistemas
necesarios para facilitar la compilación y crear una versión ejecutable del software.
Definir conjuntos de construcción
 Para facilitar las cosas y manejar la complejidad se reduce el número de cosas sobre las
que es necesario pensar. En esta situación es recomendable definir conjuntos significativos de
subsistemas que funcionan juntos y pueden considerarse como una unidad desde el punto de vista de
una integración.
Definir series de construcción
 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
implementación.
 Por cada construcción, 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
implementación -.
3.3. Implementar componentes
 Los implementadores escriben código fuente, adaptan código existente, compilan y
ejecutan pruebas de unidad de componentes, generando re trabajo para el diseñador en caso de
detectarse errores atribuibles al mismo.
 Los implementadores también corrigen defectos y vuelven a ejecutar pruebas de unidad
para verificar cambios. Finalmente el código es revisado para evaluar calidad y cumplimiento de las
reglas que podrían estar previstas en una guía de programación.
 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 programación normalmente es desarrollada por una persona, sin embargo
propuestas metodológicas actuales como XP –Xtreme Programming- están proponiendo que la
codificación de cada componente sea realizada de a pares de programadores.
 Recordar que las personas que cumplan este rol deben manejar fluidamente el lenguaje de
programación adoptado.
Lineamientos de trabajo
 La actividad de revisión es recomendable que la lleven a cabo pequeños equipos de dos o
tres personas que podrían incluir miembros del área usuaria y programadores experimentados.
 Este trabajo tiene mejores resultados si se realiza en varias etapas, cada una enfocada en
pequeñas secciones del código.
 Son más productivas las revisiones frecuentes con un alcance acotado. En estas sesiones se
identifican los problemas específicos que necesitan ser resueltos. Las correcciones se implementan
al terminar la revisión.

18
  El propósito principal de esta actividad es producir nuevo código fuente o modificar el
existente de acuerdo a las especificaciones del modelo de diseño.
 La actividad implementar componente a su vez contempla los siguientes pasos:
 Implementar operaciones
 Implementar Estados
 Delegar para reutilizar
 Implementar asociaciones
 Implementar atributos
 Hacer la revisión preliminar del código.
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 operación
 Elección de un algoritmo: muchas operaciones son lo suficientemente simples para ser
implementadas directamente desde la especificación de las mismas. En otros casos podría 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,
podríamos optar entre escribir nuestro propio algoritmo (burbuja, shell, dicotómicos, etc.)
o el provisto por el lenguaje de implementación.
 Elección de una estructura de datos apropiada para el algoritmo: la implementación de la
estructura de datos para implementar el algoritmo va a depender del lenguaje elegido y podría recaer en
alguna de las siguientes: arrays, lists, queues, stacks, bags o variaciones de estas. La mayoría de los
lenguajes orientados a objetos proveen librerías de componentes reusables con estos tipos.
 Definición de nuevas clases y operaciones: esto sucede cuando necesitamos nuevas clases
que mantengan resultados intermedios. Por ejemplo, al descomponer una operación compleja en dos
operaciones más simples. Estas operaciones serán privadas y visibles por lo tanto solo en el contexto de la
misma y no fuera de ella.
 Codificar la operación: escribimos el código para la operación empezando por las
sentencias que definen su interfase. Por ejemplo, la declaración de función miembro en C++,
especificación de subprogramas en Ada, métodos en Visual Basic o Java.
Implementar estados
 La manera más sencilla de implementar el estado de un objeto es por referencia a los
valores de sus atributos sin ninguna representación especial. La transición de estados para un objeto
estará implícita en los cambios de valor de los atributos y las variaciones de comportamiento que
serán programadas a través de sentencias condicionales. Esta solución no será satisfactoria para
comportamientos complejos debido a la dificultad implicada en una eventual modificación del
comportamiento la necesidad de nuevos estados. Si el comportamiento de los componentes es estado
dependiente, podrían ser necesarios diagramas de transición de estados que describan su
comportamiento, faciliten su interpretación y posterior codificación.
Delegar para reutilizar
 Si una clase o parte de una clase puede ser implementada reutilizando una clase existente,
se usa el mecanismo de delegación en lugar de la herencia.
 Delegación 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 operación es llamada, la
operación llama una operación del objeto referenciado -de la clase reutilizada-. Recuerde que en un
buen diseño de objetos, estos son bastante haraganes. Están buscando todo el tiempo delegar la
responsabilidad a un “especialista” para que haga lo que a él se le ha pedido.
Implementar asociaciones
 Una asociación 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 asociación bidireccional es materializada como atributos en ambas clases procediendo
del mismo modo que se indicó para asociaciones unidireccionales.
19
  En cada lenguaje de programación en particular podrá descubrir mecanismos de asociación
propios del entorno que se utiliza.
Implementar atributos
Existen tres maneras de implementar atributos:
 A través 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 más flexible, pero tenga en cuenta que introduce una
indirección innecesaria. Por ejemplo, el número de seguridad social de un empleado podría ser
implementado como un atributo de tipo String o como una nueva clase.
 Podría darse también 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 revisión preliminar del código

 Siempre se compila el código, y se fija al máximo nivel de detalle los avisos del
compilador.
 Se controla mentalmente las operaciones, recorriendo el código tratando de encontrar todos
los caminos e identificando todas las condiciones de excepción. Esto se lleva a cabo tan pronto como
se pueda después de implementar algo nuevo.
 Si fuera posible, se utiliza herramientas automáticas de revisión.
3.4. Integrar cada Subsistema
 Si más de un implementador trabaja en la construcción del mismo subsistema, es necesario
crear regularmente una nueva versión 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 integración de subsistemas referido en el punto 2.3.
 Una vez en este entorno de integración cada construcción es probada, luego de lo cual, y
habiendo superado los requerimientos de calidad preestablecidos, la nueva versión del subsistema
pasa al entorno de integración del sistema total.
 Entonces el propósito de este flujo de trabajo es:
 Integrar los cambios producidos por múltiples desarrolladores, creando una nueva
versión de un subsistema de implementación.
Trabajadores
 La integración de cada subsistema es hecha habitualmente por una persona o un pequeño
equipo.
 Los integradores necesitan experiencia en la gestión de construcciones y configuraciones
de software; pero fundamentalmente se requiere que los mismos posean un fluido manejo del
lenguaje de programación sobre el cual se desarrollaran los componentes. Debido a que a menudo la
integración se desarrolla con un alto grado de automatización, se requiere también conocimientos en
sistemas operativos, interpretes de comandos y herramientas.
Lineamientos de Trabajo
 El trabajo de integración tiene habitualmente un alto grado de automatización con esfuerzo
manual requerido solo cuando la construcción falla por alguna circunstancia. Una estrategia
frecuente es programar construcciones y pruebas de unidad mediante procesos automáticos que se
ejecuten durante la noche.
3.5. Integrar el sistema
 Siguiendo el plan de integración de construcciones se agrega e integra cada subsistema en
el entorno de trabajo del sistema. De este modo se obtiene una nueva versión del software que es
sometida al flujo de trabajo de pruebas.
 El propósito entonces de este flujo de trabajo es:
o Integrar subsistemas de implementación para crear una nueva versión consistente del
sistema total.
Trabajadores
 Rige lo mismo que en el item anterior.
Lineamientos de Trabajo
 Rige lo mismo que en el item anterior.
20
4.4 Ejecución de pruebas unitarias
 El propósito principal de esta actividad es verificar la especificación 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 ejecución de pruebas
 Verificar resultados de pruebas
 Recuperar a partir de pruebas suspendidas
Ejecutar pruebas unitarias
 Este paso consiste en la ejecución de procedimientos de prueba o scripts si las pruebas son
automatizadas.
 El procedimiento mencionado consiste básicamente en:
 Establecer el entorno de prueba para asegurar que todos los elementos necesarios
tales como hardware, software, herramientas, datos, librerías, etc. han sido
previstos.
 Inicializar el entorno de prueba para asegurar que todos los componentes están en
el estado inicial correcto para el inicio de la prueba.
 Ejecutar los procedimientos de pruebas.
 La ejecución de los procedimientos de prueba varían, lo cual depende tanto de si el mismo
es automático, manual como de la necesidad de componentes Stubs y drivers específicos.
 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 ejecución de pruebas
 Este paso tiene el propósito de determinar si las pruebas concluyeron con éxito, y tener una
visión clara de la acción correctiva requerida.
 La ejecución 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 condición normal, entonces se debe continuar
con la Verificación de Resultados de Pruebas.
 Anormal o prematuro: los procedimientos de pruebas o scripts no se ejecutaron
completamente como se había 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
Recuperación a partir de pruebas suspendidas.
Verificar resultados de pruebas
 El propósito 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 compilación (warnings), o resultados inesperados, no han sido
ocasionados por influencias externas tales como una inicialización o datos incorrectos. Si las fallas
reportadas se deben a errores identificados en artefactos de prueba o debido a problemas con el
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 continúa 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 caídas de red, caídas de hardware, etc. En todos estos casos los síntomas son
parecidos:
 acciones inesperadas, ventanas emergentes y eventos no previstos.
 El entorno de prueba parece no responder y hasta podría colgarse el sistema.
Para recuperar a partir de una situación como ésta debería:

21
  Determinar la causa real del problema.
 Corregir el problema.
 Inicializar el entorno de pruebas nuevamente.
 Ejecutar las pruebas nuevamente.
4.5 Corregir defectos
 El propósito principal de esta actividad es implementar las correcciones al código
documentadas en el documento de requerimientos de cambios durante las actividades de pruebas
unitarias de componentes y revisiones de código.
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 síntoma del programa, forzando su
ocurrencia en forma efectiva. Si no se puede lograr que el error suceda efectivamente, estamos ante
complicaciones y será mucho más difícil localizarlo.
 Luego se limita el caso de prueba identificando cuál 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 cuestión y ejecuta el caso de prueba; si el error aún 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 también
con alguna idea sobre que factores están relacionados con la ocurrencia del error.
Localizar la falla
 El próximo paso es ejecutar los casos de prueba que originan la falla e intentar identificar
el lugar concreto del código donde se produce el fallo. Ejemplos de cómo localizar una falla son:
 Ponga atención a la región sospechosa del código. Pruebe una pequeña 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. Continúe 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 programación para localizar un error – para revisar el código línea por
línea y monitorear los valores de variables significativas del programa.
Corregir la falla
 Cuando la falla ha sido localizada es momento de corregir el código. Esta debiera ser la
parte más fácil del proceso.
 Las siguientes son algunas recomendaciones para hacer efectiva la corrección:
 Asegúrese de comprender el problema y el programa antes de efectuar la
corrección.
 Corrija el problema, no el síntoma.
 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 localización de nuevas fallas.
 Cuando la falla ha sido corregida agregue un caso de prueba especial que
verifique particularmente el error.
5. Artefactos
5.1 Modelo de implementación
 El modelo de implementación describe la forma en que los elementos del modelo de
diseño, como las clases, se implementan en términos de componentes, como archivos de código
fuente, ejecutables, etc.
 Describe también cómo se organizan los componentes de acuerdo con los mecanismos de
estructuración y arquitectura de módulos disponibles en el entorno de implementación y en el
leguaje lenguajes de programación utilizados, y cómo dependen los componentes unos de otros.
5.2 Construcción
 Una Construcción es una versión operativa de parte o de un sistema completo que
demuestra un subconjunto de capacidades o funcionalidades propias del producto final.
 Es una expresión concreta y resultante del ciclo de vida iterativo. Representa y demuestran
la funcionalidad desarrollada a la fecha.
22
  Cada Construcción es puesta bajo el mecanismo de control de configuración 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 revisión y ayudará a descubrir problemas de integración en la medida que
los mismos han sido introducidos.
5.3 Componente
 Un componente es el empaquetamiento físico de los elementos de un modelo, como son
las clases en el modelo de diseño. Algunos estereotipos estándar de componentes son los siguientes:
 <<Ejecutable>>: es un programa que puede ser ejecutado en un nodo.
 <<File>>: es un archivo que contiene código fuente o datos.
 <<Library>>: es una librería estática o dinámica. (dll’s)
 <<Tabla>>: es una tabla de base de datos.
 <<Documento>>: es un documento.
 Durante la creación de componentes en un entorno de implementación particular estos
estereotipos pueden ser modificados para reflejar el significado real de estos. Los componentes
tienen las siguientes características:
 Relación de traza con los elementos del modelo que implementan.
 Implementación de varios elementos.
 Por ejemplo, un componente podría implementar varias clases, sin embargo, la forma
exacta en que se crea esta traza depende de cómo van a ser estructurados y armados en módulos los
archivos de código fuente, dado el lenguaje de programación 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 también mensajes y utilizando sus resultados. Estos últimos
componentes pueden ocasionar problemas a la prueba:
 Por no haber sido aún implementados.
 Por tener errores de funcionamiento, ocasionando confusión sobre el origen de los
problemas.
 Porque uno o más componentes de hardware podrían 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 magnéticas o mecanismos de apertura de
puertas podrían no disponerse por los programadores.
 Debido a que la prueba podría tornarse muy lenta cuando por ejemplo necesita
inicializar una base de datos.
 Ya que es muy difícil provocar ciertos resultados. Piense por ejemplo que todos
los métodos de sus clases que escriben en disco validan previamente el espacio
disponible. Ocasionar la situación “Sin espacio en disco” podría ser una tarea
bastante engorrosa.
 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
envía al momento de la prueba. Con una perspectiva más amplia podríamos considerar en esta
categoría a emuladores que simulan el comportamiento real de otros componentes no disponibles.
5.5. Subsistema de implementación
 Los subsistemas de implementación proporcionan una forma de organizar los artefactos
del modelo de implementación en trozos más manejables. Un subsistema puede estar formado por
componentes, interfaces y otros subsistemas, inclusive en forma recursiva. Además, un subsistema
puede implementar -y así proporcionar- las interfases que representan la funcionalidad que exportan
en forma de operaciones.
 Los subsistemas de implementación están muy relacionados con los subsistemas de diseño
en el modelo de diseño visto anteriormente. De hecho, los subsistemas de implementación deberían
seguir la traza uno a uno de sus subsistemas de diseño correspondientes.

23
5.6 Interfases
 Las interfases, ya definidas como artefactos en el Flujo de Trabajo Diseño, pueden ser
utilizadas en el modelo de implementación para especificar las operaciones realizadas por
componentes y subsistemas.
 Además 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 podríamos entenderlas
como conectores o facilitadores de acceso a los elementos de un modelo. La definición 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 implementación
 La vista de implementación es una de las cinco vistas arquitectónicas de un sistema. Las
otras son la vista lógica, vista de casos de uso, vista de procesos y vista de despliegue.
 El propósito de la primera es capturar las decisiones de arquitectura hechas para la
implementación.
 Típicamente la vista de implementación contiene:
 Una enumeración de todos los subsistemas del modelo de implementación.
 Diagramas de componentes ilustrando cómo los subsistemas están organizados en
capas y sus jerarquías.
 Ilustraciones de las dependencias de importación entre subsistemas.
 La vista de implementación es utilizada para:
 Asignar trabajo de implementación a programadores individuales, equipos de
programadores subcontratistas.
 Evaluar la cantidad de código a ser desarrollado, modificado o eliminado.
 Analizar la reutilización a gran escala.
 Considerar estrategias del la versión en desarrollo.
 Tanto la vista de implementación 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 técnicas respecto de la arquitectura del software. Típicamente el arquitecto
identifica y documenta los aspectos significativos de la estructura del sistema, incluyendo las vistas
de requerimientos, diseño, implementación 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 también su obligación manejar adecuadamente los riesgos técnicos y asegurar que las
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 estándares adoptados en el proyecto para su
posterior integración 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 integración de elementos de
implementación 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 integración de subsistemas donde el integrador los combina para producir una
construcción de un módulo o paquete del sistema. El integrador es responsable también de planear la
integración que tiene lugar una vez finalizada la del nivel de subsistemas. Efectivamente, los
subsistemas o módulos obtenidos son agregados e integrados posteriormente en otro espacio de
trabajo correspondiente al sistema total.

24
 UNIDAD N°3
MODELO DE PRUEBAS
Propósito de las pruebas
 Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y
las pruebas de sistema.
 Las pruebas de integración son necesarias para cada construcción dentro de la iteración;
mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
 Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar,
los procedimientos de prueba que detallan cómo 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
sistemáticamente.
 Las construcciones en las que se detectan defectos son probadas de nuevo y posiblemente
devueltas a otro flujo de trabajo, como diseño o implementación, de forma que los defectos
importantes puedan ser arreglados.
Relación 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 identificación de
las pruebas a realizar.
 El flujo de trabajo análisis y diseño determina el diseño apropiado para el producto de
software; esta es otra entrada importante del proceso de identificación de las pruebas a realizar.
 El flujo de trabajo implementación produce construcciones del producto de software que
son validadas por el flujo de trabajo pruebas. Dentro de una iteración varias construcciones podrían
ser testeadas. habitualmente una por ciclo de pruebas.
2.1. Psicología y economía de las pruebas
 Cuando se prueba un programa se desea agregarle algún 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; más bien es conveniente comenzar con la suposición 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
obtención de metas, el establecimiento de una de ellas en forma apropiada tiene gran
importancia desde el punto de vista psicológico.
 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 tendrán 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 difícilmente pueda ser considerado como
no exitoso; mas bien, ha demostrado ser una valiosa inversión.
2.2. Conceptos básicos
Testing de software
 Realizar testing de software no es debuggear un código, 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 demostración de que en dicho software no hay errores.
 Testear o probar un software es someterlo a ciertas condiciones a fin de demostrar si es
válido o no a partir de los requerimientos que le dieron origen, es decir, si satisface los
requerimientos definidos (validación), ya que podría ocurrir que un software no tuviera defectos
pero que tampoco realizara la funcionalidad especificada y acordada con el usuario.
 Implica la verificación de que dichas funcionalidades se implementan correctamente.

25
  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 aún más, si se
analizan los resultados, también al proceso de desarrollo utilizado.
 Podría 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 difícil de utilizar (no es amigable),
permite cometer errores, es difícil entender el código fuente, sólo quien lo construyó puede
modificarlo, es más complejo de lo necesario, no se sabe bien cómo 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 código 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 (considérese 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:
 Catastróficas: 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 había
definido como importante, por ejemplo, un tiempo de respuesta mayor al definido
es una falla de propiedad de desempeño.
 Formato: la salida puede mostrar los resultados esperados, pero la forma de la
misma no es correcta.
 La tipificación de la falla siempre se hace en la mayor categoría 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 erróneos), la misma será catalogada como
funcional (ya que un conjunto de datos erróneos puede obtenerse a la velocidad que se desea y aún
así la falla no se habrá solucionado). A pesar de esto la falla debe describirse completamente.
Defecto (fault)
 Se presenta en el código 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 equivocación 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 continuación dos maneras de focalizar el análisis del software en busca de
defectos de construcción.
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 efectúa la prueba considera el programa como una caja negra, es decir, se
desentiende completamente del comportamiento y estructura internos.
 Su interés 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.
26
  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 condición de entrada como un caso de
prueba.

Pruebas tipo caja blanca

 Las pruebas de caja blanca o lógicas, permiten examinar la estructura interna de los
programas.
 Usándola el operador de la prueba obtiene datos de prueba a partir del examen de la lógica
del programa.
 Una prueba exhaustiva de secuencia no garantiza de ninguna manera que el programa
cumpla con su especificación. Por ejemplo, si se pide hacer una rutina para ordenar valores
numéricos 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 lógicas 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 números para detectar una
convergencia, es decir determinar si la diferencia entre los dos números es menor que un valor
predeterminado.
 Se podría escribir la sentencia en la forma siguiente:
 Por supuesto, esta sentencia contiene un error porque deberíamos comparar EPSILON con
el valor absoluto de A-B y no se lo detectará necesariamente ejecutando cada secuencia lógica
posible dentro del programa.
 En conclusión, 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 métodos para
llegar a una estrategia razonable, aunque no sea perfecta. Esto es lo que esperamos aportar con el
contenido metodológico 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.
 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 más apropiados para ser
encarados por los propios desarrolladores del proyecto. En contraste, las pruebas de sistema
mencionadas más 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 integración 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 límites de esta categorización son ignorados. En particular las pruebas de
desarrollo han sido tratadas en la unidad 3 en el flujo de trabajo implementación.
 La mejor estrategia es dividir el esfuerzo de trabajo de pruebas a los fines de tener cierta
superposición 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 visión de calidad.
Pruebas de unidad
 Las pruebas de unidad de una iteración se enfocan en la verificación de los más pequeños
elementos del software. Se aplica a componentes del modelo de implementación 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 ejecución de un caso de uso.
Recuerde que tanto los diagramas de secuencia como los de colaboración, construidos a partir de los
casos de uso permiten visualizar el desempeño (colaboración) de cada componente. Los detalles de
las pruebas de unidad son abordados en el flujo de trabajo Implementación.

27
Pruebas de integración
 Las pruebas de integración son hechas para asegurar que los componentes del Modelo de
Implementación funcionan armónicamente cuando son combinados para ejecutar un caso de uso. El
alcance de la prueba es típicamente un paquete o un grupo de paquetes del modelo de
implementación. Estos paquetes podrían originarse en distintos grupos de desarrollo. Las pruebas de
integración exponen las omisiones o errores de especificación 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 implementación del
código. 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 aceptación
 Las pruebas de aceptación 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 aceptación adoptan alguna de estas tres modalidades:
 · Aceptación formal.
 · Aceptación informal o test alfa.
 · Aceptación beta o test beta.
 La elección de la estrategia habitualmente obedece a los requerimientos contractuales, el
dominio de la aplicación y los estandares organizacionales.
Aceptación formal
 La prueba de aceptación formal es un proceso cuidadosamente administrado. Los tests son
planeados y diseñados 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 aceptación formal son los mismos que se emplearon en la prueba del sistema.
 Los beneficios de este tipo de pruebas de aceptación son:
 Las funciones y características a ser probadas son conocidas.
 Los detalles de las pruebas son conocidos y pueden ser medidos.
 Los tests pueden ser automatizados.
 El progreso de la prueba puede ser medido y monitoreado.
 El criterio de aceptación es conocido.
 Las desventajas:
 Requiere importante cantidad de recursos y planeamiento.
 La prueba se puede convertir en una re implementación de la prueba del sistema.
 Podría no descubrir defectos subjetivos del software, ya que solo se buscan
defectos esperados.
Aceptación informal
 En las pruebas de aceptación informal los procedimientos de test no son tan rigurosamente
definidos como en las pruebas de aceptación 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 también la aprobación
cuando se encuentra satisfecho.
 Los beneficios de esta forma de prueba de aceptación son:
 las funciones y características a ser probadas son conocidas.
 El progreso de la prueba puede ser medido y monitoreado.
 El criterio de aceptación es conocido.
 Podría descubrir defectos subjetivos del software, ya que la elección de los casos
de prueba es aleatorio y podrán aparecer defectos no esperados.
 Las desventajas
 se requieren recursos, planeamiento y administración.
 No se tiene control sobre los casos de prueba a ser utilizados.
 Los usuarios finales podrían dar su conformidad sin detectar defectos.

28
  Los usuarios finales tienden a focalizarse en la comparación del nuevo sistema con
uno anterior perdiendo prioridad la búsqueda de defectos.
Aceptación Beta
 De las tres modalidades de pruebas de aceptación 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 creación del entorno, selección de datos,
determinación de funciones y características a explorar. Además determina su propio criterio de
aceptación. Esta modalidad es enteramente implementada por los usuarios finales y como podrá
apreciar es la forma más subjetiva de aceptación.

 Los beneficios de esta forma de prueba de aceptación son:

 La prueba es enteramente implementada por los Usuarios Finales.
 Hay disponibilidad de potenciales probadores.
 Se incrementa la satisfacción de los usuarios que participan.
 Se descubren más defectos de aparición subjetiva que las dos modalidades
anteriores.
 Las desventajas:
 No todas las funciones y/o características pueden ser probadas.
 El progreso de la prueba es difícil 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 comparación del nuevo sistema con
uno anterior en lugar de buscar defectos.
 Los recursos necesarios para la prueba podrían escapar al control del proyecto.
 El criterio de aceptación 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 iteración, luego se
describen los casos y procedimientos necesarios para llevar a cabo las comprobaciones, hecho esto,
los desarrolladores implementan los componentes y stubs necesarios para dar la mayor
automatización posible al proceso.

29
  Todo esto se hace para cada construcción entregada como resultado del flujo de trabajo de
implementación.
 Finalmente, con estos casos, procedimientos y componentes de prueba como entrada, los
ingenieros de pruebas de integración y de sistema evalúan cada construcción y detectan
cualquier defecto que encuentren en ellos.
 Las fallas sirven como realimentación tanto para otros flujos de trabajo, como el de diseño
y el de implementación, como para los ingenieros de pruebas a fin de que lleven a cabo una
evaluación sistemática de los resultados de las pruebas.
3.1. Planificar pruebas
 Aquí se produce la planificación general del proceso de pruebas. Se especifican
estimaciones de los requerimientos de recursos humanos y sistema necesarios, así como la
determinación de una estrategia adecuada.

 El propósito principal de este flujo es:

 Identificar los objetivos y entregables del esfuerzo de pruebas.
 Identificar una buena estrategia de utilización de recursos.
 Definir los límites y alcances del proceso.
 Delinear el método que será usado.
 Definir el modo y criterio con el que el proceso será seguido y evaluado.

 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 diseñador de pruebas usará también otros artefactos de entrada, como por ejemplo el
modelo de diseño.
 Los diseñadores de pruebas desarrollan una estrategia de prueba para la iteración, 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 iteración en la
fase de elaboración.
 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á ningún defecto de prioridad medio-alta sin resolver.

30
  El desarrollo, realización y evaluación de cada caso procedimiento y componente de
prueba lleva algún tiempo y cuesta dinero. Sin embargo, ningún sistema puede ser probado
completamente, por tanto, deberíamos identificar los casos, procedimientos y componentes de
prueba con un mayor retorno a la inversión en términos de mejora de calidad. El principio general
consiste en desarrollar casos y procedimientos de prueba con un solapamiento mínimo para evaluar
los casos de uso más importantes y también los requisitos que están asociados a los riesgos más
altos.
3.2. Diseñar prueba
 Los propósitos de diseñar las pruebas son:
 Identificar y describir los casos de prueba para cada construcción.
 Identificar y estructurar los procedimientos de prueba especificado cómo realizar
los casos de prueba.
Diseño de los casos de prueba de integración
 Los casos de prueba de integración se utilizan para verificar que los componentes
interaccionan entre sí de la forma apropiada después de haber sido integrados en una construcción.
 La mayoría de los casos de prueba de integración pueden ser derivados de las
realizaciones de casos de uso-diseño, ya que las realizaciones de casos de uso describen cómo
interaccionan las clases y los objetos, y por tanto cómo se relacionan también los componentes entre
sí.
 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 mínimo. Para esto, los
diseñadores de prueba intentan encontrar un conjunto de caso de prueba con un solapamiento
mínimo, cada uno de los cuales procura un camino o escenario interesante a través de una
realización de caso de uso.
Diseño 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 números de actores y diferentes
tamaños de la base de datos.
 Cuando se desarrollan los casos de prueba de sistema los diseñadores de prueba deberían
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, quizás 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.
Diseño de los casos de prueba de regresión
 Algunos casos de prueba de construcciones anteriores se adoptan para pruebas de regresión
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 regresión puede suponer un esfuerzo de
desarrollo extra, lo que significa tener cuidado y convertirlos en caso de prueba de regresión
únicamente cuando el esfuerzo merezca la pena.
Identificación y estructuración de los procedimientos de prueba
 Los diseñadores pueden trabajar cada caso de prueba y sugerir procedimientos de
comprobación 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 cómo realizar un caso de prueba nuevo o cambiado.
 Además estos profesionales también 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 precisión para muchos casos de prueba.
31
  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á cómo probar el movimiento de dinero entre cuentas, por lo
cual toma como parámetros 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 después de
transferir. Los diseñadores 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 cómo se realizan parte de todos esos casos de
prueba.
3.3. Implementar prueba
 El propósito de la implementación 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:
 cuando usamos una herramienta de automatización 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 explícitamente usamos los
procedimientos de prueba como especificaciones iniciales. Observe que dicho
esfuerzo de programación podría requerir personal con buenas habilidades
programadoras.
 Los componentes de prueba emplean a menudo grandes cantidades de datos de entrada
para ser probados y producen también muchísimos 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 cálculo y bases de datos.
3.4. Realizar pruebas de integración
 En esta actividad se elaboran las pruebas de integración necesarias para cada una de las
construcciones creadas en una iteración y se recopilan los resultados de las pruebas.
 Las pruebas de integración se llevan a cabo en los siguientes pasos:
 realizar las pruebas de integración relevantes a la construcción 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 diseñadores de prueba, quienes usarán los defectos
para evaluar los resultados del esfuerzo de prueba.
3.5. Realizar prueba de sistema
 El propósito de la prueba de sistema es realizar las pruebas de sistema necesarias en cada
iteración y recopilar los resultados de las pruebas.
 La prueba de sistema puede empezar cuando las pruebas de integración indican que se han
alcanzado los objetivos de calidad de integración fijados en el plan de prueba de la iteración actual;
por ejemplo, el 95 por ciento de los casos de prueba de integración se ejecutan con el resultado
esperado.
 La prueba de sistema se elabora de forma análoga a la forma en que se realiza la prueba de
integración.

3.6. Evaluar prueba

 El propósito de la evaluación de la prueba es valorar los esfuerzos de prueba en una
iteración.
 Los diseñadores de pruebas evalúan los resultados de la prueba comprobando los
resultados obtenidos con los objetivos esbozados en el plan de prueba. Éstos preparan métricas que
les permiten determinar el nivel de calidad del software y qué cantidad de pruebas es necesario.
32
  En concreto, el ingeniero de prueba observa dos métricas:
 Compleción de la prueba, obtenida a partir de la cobertura de los casos de prueba
y de la cobertura de los componentes probados. Esta métrica indica el porcentaje
de casos de prueba que han sido ejecutados y el porcentaje de código que ha sido
probado.
 Fiabilidad, la cual se basa en el análisis no solo de las tendencias en los defectos
detectados y sino también en las pruebas que se ejecutan con el resultado
esperado.
 Para determinar la fiabilidad del sistema, los diseñadores de pruebas crean diagramas de
las tendencias de las fallas, donde representan la distribución de tipos específicos de defectos -como
defectos nuevos o fatales- a lo largo del tiempo. La prueba puede crear también 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.
 Las tendencias de los defectos siguen a menudo patrones que se repiten en varios
proyectos. Por ejemplo, normalmente el número de defectos nuevos generados cuando se prueba un
sistema se incrementa fallas rápidamente tan pronto como comienza la prueba, después 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.
 Basándose en el análisis de la tendencia de los defectos, los diseñadores de pruebas pueden
sugerir otras acciones, como por ejemplo:
 realizar pruebas adicionales para localizar más 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 iteración
actual se pusieron demasiado altos.
 Aislar las partes del sistema que parecen tener una calidad aceptable y entregarlas
como resultado de la iteración actual. Las partes que no cumplieron los criterios de
calidad han de ser revisados y probados de nuevo.
 Los diseñadores de prueba documenten la compleción de la prueba, su fiabilidad y
sugieren acciones en una descripción de la evaluación de la prueba.
4. Artefactos
4.1. Artefacto modelo de pruebas
 El modelo de pruebas describe principalmente cómo se evalúan los componentes
ejecutables -como las construcciones- en el modelo de implementación con pruebas de integración y
de sistema.
 El modelo de pruebas puede describir también la forma en que han de ser probados
aspectos específicos 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 colección 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 tamaño.

33
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 realización de caso de uso en el modelo de diseño.
 En la práctica, lo que se prueba puede venir dado por un requisito o colección de requisitos
del sistema cuya implementación 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 específico de un caso de uso. Un caso de prueba de este tipo incluye la
verificación del resultado de la interacción entre los actores y el sistema, que se
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 típicamente una prueba
del sistema como “caja negra”, es decir, una prueba del comportamiento
observable externamente del sistema.
 Un caso de prueba que especifica cómo ensayar una realización de caso de uso-
diseño o un escenario de la misma. Un caso de prueba de este tipo puede incluir la
verificación de la interacción entre los componentes que implementan dicho caso
de uso. Observe que los casos de prueba basados en una realización de caso de uso
típicamente especifican una prueba del sistema como “caja blanca”, es decir, una
evaluación de la interacción 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 montaña. Los ingenieros denominan a este caso de uso Pagar 300-Bicicleta de Montaña.
 Para ser completos, el caso de prueba ha de especificar la entrada, el resultado esperado y
otras condiciones para la verificación 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
visión general de casos de prueba similares sino también una entrada utilizable en la creación de
procedimientos de prueba y componentes de prueba.
 Cómo 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.

34
 Los siguientes son conjuntos de caminos independientes (los cuatro forman un conjunto
básico):
 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
 Fíjese 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 combinación de caminos ya definidos y no introduce ninguno nuevo.
 Cada uno de estos caminos muestra un escenario del caso del uso X.
 Ahora debemos diseñar casos de prueba para forzar la ejecución de estos caminos, de esta
forma podemos decir que cada instrucción de código se habrá ejecutado al menos una vez en las
pruebas, así como también se habrán ejecutado las instrucciones de las salidas verdadero y falso de
las decisiones.
 Se realiza luego un conjunto de casos de prueba para cada escenario (mínimamente 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.

35
  La especificación 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 especificación de
requerimientos que contiene el caso de uso.
 La configuración de software a probar:
 opciones de sistema,
 subsistemas, etc.
 Especificación de las entradas:
 el valor preciso de cada entrada,
 propiedades adicionales de dicha entrada si fuera necesario (por ejemplo
formatos, tiempos de espera, etc.)
 Especificación 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:
 configuración del hardware para la prueba,
 detalle del software necesario para la prueba (sistema software a probar, software
específico para realizar la prueba),
 recursos especiales, por ejemplo, la presencia de un usuario o una persona
específica.
 Especificación del procedimiento de prueba.
 Precondiciones (condiciones que deben cumplirse antes de ejecutar este caso de prueba,
por ejemplo, la ejecución 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 instalación verifican que el sistema puede ser instalado en la
plataforma del cliente y que el sistema funcionará correctamente cuando sea
instalado.
 Las pruebas de configuración 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 diseñado, por
ejemplo, empleando configuraciones de red incorrectas, capacidad de hardware
insuficiente o una carga de trabajo “imposible” de sobrellevar.
 · Las pruebas de tensión o de estrés 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 cómo realizar uno a varios casos de prueba o partes
de estos. Por ejemplo, una instrucción para un individuo sobre la forma ha de realizar un caso de
prueba manualmente, o una especificación de cómo interaccionar manualmente con una herramienta
de automatización de pruebas para crear componentes ejecutables de prueba.
 El cómo 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 métodos 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 Montaña 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 especificación ya que ya está detallado en el caso de uso:
 Caso de uso: Pagar 300-Bicicleta de Montaña.
 Seleccione el menú Hojear Facturas de la ventana principal. Se abre la ventana de
diálogo Consultar Facturas.
 En el campo Estado de la Factura, seleccione Pendiente y pulse el botón
Consultar. Aparece la ventana Resultados de la Consulta.
36
  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 botón 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á vacía;
 el Identificador de Confirmación 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 número de cuenta es el mismo que el especificado en
el caso de prueba [22-222-2222].
 Seleccione la opción Autorizar Pago para iniciar el abono de esta factura. Aparece
la ventana de diálogo para el Pago de Factura. Etc. Se especifica cómo se lleva a
cabo a través 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 también 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. También que el procedimiento de prueba es similar a la descripción de flujo
de eventos del caso de uso a Pagar Factura, aunque el método de prueba incluye información
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 instalación de software y hardware.
 Procedimientos de control.
 Procedimientos de finalización, reseteos de estados, limpieza de resultados.
 Procedimientos de supervisión de la ejecución de la prueba.
 Procedimientos de medición 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 programación, o siendo grabados con una herramienta de automatización de prueba.
 Los componentes de prueba se utilizan para probar los componentes en el modelo de
implementación, proporcionando entradas de prueba, controlando y monitorizando la ejecución de
los componentes a probar informando de los resultados de las pruebas. En inglés, 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 planificación de la prueba.
 La estrategia de prueba incluye la definición del tipo de pruebas a realizar para cada
iteración y sus objetivos, el nivel de cobertura de prueba y de código necesario y el porcentaje de
pruebas que deberían ejecutarse con un resultado específico.
4.6. Artefacto defecto
 Un defecto es una anomalía del sistema, como por ejemplo un síntoma de un fallo software
o un problema descubierto en una revisión.
 Se utiliza para localizar cualquier cosa que los desarrolladores necesitan registrar como
síntoma de un problema en el sistema que ellos deben controlar y resolver.
4.7. Artefacto evaluación de prueba
 Una evaluación de prueba es una valoración de los resultados de los esfuerzos de prueba,
tales como la cobertura del caso de prueba, la cobertura de código y el estado de los defectos.
5. Trabajadores
5.1. Diseñador de pruebas
 Un diseñador de pruebas es responsable de la integridad del modelo de pruebas,
asegurando que el mismo cumple con su propósito.
 Los diseñadores de pruebas también planean las pruebas, lo que significa que deciden los
objetivos apropiados y la planificación de las pruebas.

37
  Además, los diseñadores de pruebas seleccionan y describen los casos y los
procedimientos de prueba correspondiente que se necesitan, y son responsables de la evaluación de
las pruebas de integración y de sistema cuando éstas se ejecutan.
 Observe que los diseñadores de pruebas realmente no ejecutan las pruebas, sino que se
dedican a la preparación y evolución de las mismas. Otros dos tipos de trabajadores, los ingenieros
de pruebas de integración y los ingenieros de prueba de sistema, son los encargados de llevarlas a
cabo.

5.2. Ingeniero de pruebas de integración

 Los ingenieros de pruebas de integración son los responsables de hacen las pruebas de
integración que se necesitan para cada construcción producida en el flujo de trabajo de la
implementación.
 Se realizan para verificar que los componentes integrados en una construcción funcionan
correctamente juntos.
 Por esto, se derivan a menudo de los casos de prueba que especifican cómo probar
realizaciones de casos de uso-diseño.
 El ingeniero de pruebas de integración 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 construcción que muestra el resultado (ejecutable) de una iteración 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 cómo probar los casos de uso, aunque también 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 actúan como
ingenieros de pruebas de sistema necesitan saber mucho sobre el funcionamiento interno del
sistema. Por el contrario, éstos deberían 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.

38
 UNIDAD N°4
UTILIZANDO PUDS
 El PUDS es un proceso de desarrollo de software que transforma requerimientos de
usuarios en un producto software a través 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 técnica de casos de uso permite validar los requerimientos con el cliente y facilitar la
comunicación 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 análisis que utiliza el modelo de casos de uso
como entrada y que es diferente del modelo de diseño porque es un modelo conceptual en lugar de ser un
esquema de la implementación. Cada caso de uso en el modelo de casos de uso se traduce en una
realización de caso de uso en el modelo de análisis.
 Tomando los casos de uso uno a uno, los desarrolladores pueden identificar las clases que
participan en la realización de aquellos. Así obtenemos un conjunto de clases que juntas realizan los
casos de uso. Luego los desarrolladores diseñan las clases y las realizaciones de casos de uso para
aprovechar al máximo las tecnologías y productos a utilizarse.
 A continuación se implementan las clases diseñadas mediante un conjunto de archivos a
partir de los cuales se pueden generar (ejecutables, DLL’s, JavaBeans, componentes ActiveX, páginas
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 guían al proceso unificado, lo hemos visto sólo con una iteración. 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 relación de trazabilidad a través de todos
los modelos. Un caso de uso en el modelo de requisitos es trazable a su realización en el modelo de
análisis, y así sucesivamente a través de cada uno de los modelos del UP. Esta relación 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 elaboración se construye una arquitectura sólida
para que a partir de la misma podamos arrancar con la construcción de la totalidad del sistema sin tropiezos
posteriores.
A la hora de ir pasando por las distintas fases del proyecto los desarrolladores utilizarán la
arquitectura como guía general para situarse correctamente en el lugar en donde están parados y usarán los
distintos diagramas más detallados para realizar su trabajo, incluyendo aquellos casos de uso importantes
en este contexto.
La descripción de la arquitectura tiene cinco vistas, una para cada modelo:
1. Casos de uso
2. Análisis
3. Diseño
4. Despliegue
5. Implementación

39
  Una vista arquitectónica es una descripción simplificada (una abstracción) 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 descripción de la arquitectura no se pretende cubrir absolutamente todo, no debería
inundar con detalles minuciosos. Hay mucha información que no es necesaria tener en cuenta a la
hora de describir la arquitectura. Por ejemplo, sólo 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 definición 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 tecnológicamente complejos,
que combinan computación distribuida, productos y plataformas comerciales
diferentes y reutilizan componentes y marcos de trabajos, que se realizan en
lugares geográficamente 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 definición de la
arquitectura.
 Organizar el desarrollo: a medida que crece la organización del proyecto, crecen
proporcionalmente los esfuerzos para coordinar las actividades de los miembros
del equipo.
 Fomentar la reutilización: la reutilización es una de las ventajas principales de
esta metodología, para ello se debe conocer el dominio del problema y qué
componentes admite la arquitectura. Los componentes de software reutilizables
están diseñados 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 iteración se produce un incremento del
sistema que estamos construyendo. Es deseable que dicho sistema sea fácil de
modificar y permita la implementación 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 metodologías de desarrollo tradicionales en las
cuales el desarrollo también se realiza por etapas, pero las mismas se van realizando en serie, una
detrás de la otra sin posibilidad por ejemplo de recibir retroalimentación en alguna y volver para
atrás 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 iteración tiene asociado el de versión de sistema, es decir, en cada iteración
se obtiene una versión operativa del sistema software que estamos construyendo. Este sistema va
creciendo incrementalmente a través de las diferentes iteraciones, los modelos van evolucionando a
través de las mismas.
 Se divide el proyecto en un número de mini proyectos, siendo cada uno de ellos una
iteración. Cada iteración está compuesto por todas las fases de un proyecto de software, es decir que
cada una de ellas sería como un mini proyecto hecho con una metodología tradicional, como la de
cascada.
 Se debe manejar con mucho cuidado el hecho de poder avanzar y recibir retroalimentación
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.

40
  Cada iteración debe planificarse para controlar el proyecto. El Plan de la iteración es un
plan que incluye un conjunto secuencial de actividades, tareas, recursos asignados, objetivos,
criterios de evaluación (en función de los objetivos) de la iteración en cuestión. Será importante al
final de la iteración medir aspectos tales como el grado de terminación de la funcionalidad
planificada, los niveles de calidad alcanzados, adecuación a las normas y estándares vigentes en caso
de ser necesario.
 El concepto de iteración reduce, al principio del ciclo de vida, los riesgos que pueden
amenazar el progreso del desarrollo. Las versiones internas tras las iteraciones posibilitan la
retroalimentación de los usuarios y esto lleva a su vez a una corrección 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 tácticos.
 Conseguir una integración continua.
 Conseguir un aprendizaje temprano.
El UP entrega las 6 mejores prácticas
El proceso unificado describe cómo implementar efectivamente las seis mejores prácticas para el
desarrollo de software, las mismas son:

Ventajas y errores al utilizar el proceso unificado

Ventajas de utilizar esta metodología
 Prioriza la identificación y gestión de riesgos en etapas tempranas del desarrollo.
 Enfatiza la construcción 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 común.
 Es fácil de combinar con técnicas de otros métodos.
 Es fácil de personalizar, alienta versiones “light” mínimas.
 Permite trabajar con plantillas estándar.
 Puede escalar a proyectos grandes o pequeños.
 Ampliamente adoptado, por lo tanto, muchos recursos de consultoría y capacitación.
 Cada iteración finaliza con un entregable del producto.
Errores más comunes al utilizar esta metodología
 Superponer las ideas de cascada en las fases iterativas.
 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 planificación y el seguimiento de la
misma.
 Crear muchos artefactos innecesariamente, lo que aumenta la complejidad sin motivo.
 Dificultad en la planificación predictiva.

41
  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
 Elaboración
 Construcción
 Transición
 Cada una de las fases se divide en una o más 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 próxima iteración.
2.1 Planificación 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 iteración a través del Plan de iteración. Estos
planes se van completando con mayor detalle a medida que se avanza en el proyecto.
 En esta planificación debemos incluir mínimamente la forma evaluar cada iteración, 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 términos
específicos para un proyecto en particular. Se planifica:
 El tiempo que insumirá cada fase, incluyendo su fecha de finalización.
 Los hitos principales que indican la finalización de una fase para pasar a la
siguiente.
 Las iteraciones que se realizarán en cada fase.
2.2 Planificación de las iteraciones
 La cantidad de iteraciones que se realizarán en cada fase depende del sistema que
estamos construyendo, de su complejidad y tamaño.
 La duración de cada iteración podrá variar entre una semana y tres meses. Es
aconsejable que las actividades dentro de la iteración sean unidades asignables,
controlables y posibles de medir.
 Por cada iteración planificamos:
 El tiempo que llevará cada iteración, con su fecha de finalización.
 El contenido de la iteración, es decir, qué funcionalidades (expresadas en
casos de uso) se implementarán en la misma, qué riesgos estarán
presentes (o al menos potencialmente) y cuál será la estrategia de
mitigación, los subsistemas que se implementan (total o parcialmente).
 Los hitos secundarios que indicarán la finalización de la iteración.
 Esta planificación de la iteración se irá refinando a medida que nos acerquemos a
dicha iteración.
2.3 Evaluación
 Los criterios de evaluación seguramente se planificaron con anterioridad en función de los
objetivos. Se trata de parámetros o características que mínimamente se deben cumplir.
 Se establecen criterios para cada fase y para cada iteración dentro de cada fase. Se trata de
un momento en el que se verifica la satisfacción de dichos criterios o requisitos. Por lo anterior, se
deduce que los criterios deben poder ser observados de alguna manera por el responsable, es decir, el
jefe de proyecto.
 Esta evaluación permite:
 Evaluar la iteración 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 iteración.
 Los resultados de la evaluación se registran en un documento que crea el jefe de proyecto.

42
  Este documento se distribuye a los involucrados y se archiva, es decir, no sufre
modificaciones a lo largo del tiempo. La próxima evaluación generará un nuevo documento de
registro de resultados.

3 Flujos de trabajo
3.1 Flujos de trabajo fundamentales
 Cada iteración puede ser considerada como un pequeño proyecto en sí mismo, y constituye
una pasada por los cinco flujos de trabajo fundamentales del PUDS.
 Los flujos de trabajo fundamentales son:
 Requisitos
 Análisis
 Diseño
 Implementación
 Prueba

3.2 Dominio del problema y de la solución

 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
relación de traza con los objetos identificados en el dominio en la etapa anterior.
 En el flujo de trabajo de análisis se comenzó a trabajar con clases de fabricación pura, es
decir, creadas para la construcción de la solución, o sea, ya en el dominio de la solución. El resultado
de este flujo fue un modelo conceptual y lógico.
 En el flujo de diseño se continuó trabajando en el dominio de la solución 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 configuración 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 seleccionarán
los diagramas que se construirán.

43
 UNIDAD N°5
IMPLEMENTACION DEL CAMBIO

1.-Creación del conocimiento con t.i. y ventaja competitiva

 David Smith postula cuatro niveles de desarrollo organizacional en la creación del conocimiento:
o Compartir conocimiento,
o Nivelación,
o Creación 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 identificación, la adquisición, el mapeo, el
almacenaje, el acceso, la distribución, la nivelación y el uso del conocimiento.
 Facilitadores tecnológicos: Sistemas de información, recuperación de documentos,
herramientas de grupo, intranet corporativa, sistemas de base de conocimiento, etc.
 Alineación organizacional: Los líderes son parte crítica del alineamiento, junto con las
recompensas, roles, estructuras mentales, estructura y apertura.

La tecnología, no es nunca por sí misma la solución mágica a ninguna problemática. Sólo resulta
valiosa ante fines concretos. Debemos saber para qué queremos utilizar tal o cual tecnología, 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 tecnología de información:
 Crear conocimiento es el postulado fundamental en la implementación de
tecnologías de información.
 Involucrar a la mayor cantidad de personas posible en la reingeniería 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 motivación y del reconocimiento positivo a los miembros
involucrados en el proyecto.
 Trabajar dentro de la cultura de la empresa, no alrededor de ésta.

44
2. Adquisición de hardware, software y servicios
 Implementar determinada T.I. podría requerir de la incorporación de hardware, software
y/o servicios.
 El proceso de adquisición de recursos y equipo computacional es complejo.
 Las decisiones relacionadas con la adquisición de estos recursos deben considerar factores
tecnológicos y financieros.
 El proceso se inicia con la determinación de los requerimientos de cómputo, hasta la
administración de la conversión de programas y la transición y traslado de datos al nuevo sistema
computacional.
 Es importante conocer los síntomas 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.
Saturación y falta de capacidad del equipo computacional
Necesidad de incorporar nuevos sistemas de aplicación a la organización
Equivocada decisión durante el proceso de selección del equipo actual.
Existencia de requerimientos de competitividad que no pueden ser logrados con la
tecnología actual.
Existe la necesidad de cambiar la filosofía de operación de los sistemas actuales.
Las etapas para llevar a cabo el proceso de innovación tecnológica de recursos computacionales
son:
Determinación 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 organización.
El primer paso es tener un conocimiento profundo de la organización 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
operarán en el nuevo sistema.
El horizonte del proyecto se define como el lapso de tiempo futuro que se considera en un análisis.
Filosofía de operación o tipo de solución requerida
El plan deberá incluir aspectos tecnológicos requeridos para el desarrollo de nuevas aplicaciones,
tales como bases de datos, códigos de barras, sistemas por lotes o en línea, ya que estas especificaciones
pueden modificar de manera sensible los requerimientos y restricciones a considerar en el nuevo equipo.
La filosofía de operación que se desea con el nuevo equipo requiere un análisis del tipo de
solución que se implantará con él. Esta solución puede incluir equipos grandes, arquitecturas cliente-
servidor, estaciones de trabajo y PC’s entre otras.
Recursos que deben estimarse
 Capacidad de cómputo expresada. Por ejemplo: número de instrucciones por segundo.
 Capacidad de almacenamiento en RAM. Por ejemplo: tamaño en Gigabytes
 Capacidad de almacenamiento secundario, expresada en Megas, Gigas ó Terabytes.
 Capacidad total de impresión requerida, expresada como líneas de impresión por minuto.
 Cantidad de terminales requeridas para la captura o consulta de información.
 Hardware especializado para llevar a cabo funciones especiales: Terminales inteligentes,
concentradores, ruteadores, etc.
 Infraestructura de redes: Tarjetas de red, medios de transmisión, etc.

Requerimientos obligatorios
Conjunto de características que deben estar, de forma obligada y necesaria, presentes en el equipo
o solución presentada por el proveedor:
 Costo total del equipo o el presupuesto máximo autorizado.
 Tiempo máximo de entrega del equipo requerido.

45
  Compatibilidad con el lenguaje computacional actual, minimizando el esfuerzo de
conversión.
 Apoyo del proveedor durante la conversión de aplicaciones, si existe.
 Características mínimas requeridas de rendimiento de los equipos.

Requerimientos opcionales

Constituyen el conjunto de características 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 algún sistema de aplicación o paquete ya desarrollado para asegurar una
implantación rápida y exitosa.
 Alto grado de satisfacción 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.
 Rediseño o cambios importantes de las aplicaciones actuales.

2.1. Evaluación y selección

Evaluación técnica de las propuestas
Es el proceso mediante el cual el administrador del proyecto define y evalúa las características y
los factores técnicos de los equipos disponibles. El resultado de esta evaluación técnica, sumado al
resultado de la evaluación económica y financiera, constituye la plataforma de decisión del equipo y de la
solución a adquirir.
2.2. Elaboración de una Requisición 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 requisición de propuesta, documento que define los
requerimientos de la organización 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 evaluación y negociación entre los proveedores de
soluciones y la organización.
 Obliga al administrador del proyecto a formalizar el proceso de determinación de los
requerimientos de equipo.
 Constituye un documento que describe claramente las prioridades técnicas del sistema.
Se recomienda incluir en su estructura:
o Datos generales del responsable del proyecto.
o Fecha límite para recibir la propuesta del proveedor.
o Fecha límite para que el proveedor realice las presentaciones y/o demostraciones del
equipo propuesto.
o Bases y lineamientos generales que serán utilizados para comparar los diferentes
equipos.
o Breve descripción de la situación actual de la compañía y de la función de informática
dentro de la misma.
Requerimientos del sistema computacional
Se puede incluir la siguiente información:
o Requerimientos del equipo actual versus del equipo propuesto.
o Requerimientos obligatorios y opcionales.
o Información más detallada de las pruebas de benchmark o pruebas de rendimiento
o que serán efectuadas a las soluciones propuestas que estarán concursando.

46
 o En términos generales, deber incluirse toda la información relevante.
Formato de propuesta
Es importante definir estándares de las propuestas de los diferentes proveedores, para facilitar la
evaluación técnica y financiera de las mismas, y por ende, de la decisión final.
El formato de propuesta puede variar de una empresa a otra,pero incluye:
 Sistema o solución configurada. Con la descripción técnica detallada de
la solución propuesta y las capacidades de crecimiento del sistema. Debe contener
manuales técnicos de hardware y del software configurado, así como diagramas
esquemáticos de la configuración propuesta.
 Requerimientos de instalación. Se debe recordar que hay soluciones que
implican costosos requerimientos de instalación. Debe incluir:
o Espacio físico que ocupa el equipo.
o Instalaciones eléctricas 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
aplicación al nuevo equipo.
 Información de costos. Debe incluirse toda la información
económica 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 evaluación económica del proyecto de inversión.
 Condiciones del contrato: se especifican en formatos fijos que el
proveedor anexa a las propuestas, los cuales comúnmente son elaborados por el departamento
jurídico de la compañía.
 Nivel o grado de cumplimiento: Es importante insistir a los
proveedores que esta información 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 efectúe en una reunión 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 invitación a los proveedores fue exhaustiva, es de esperarse que
la cantidad de propuestas recibidas también sea elevada.
 El análisis y evaluación de todas puede resultar lento y costoso.
2.3. Factores a evaluar
La evaluación se realiza exclusivamente sobre las soluciones que satisfacen los requerimientos
obligatorios y que cumplen mejor las especificaciones opcionales.
Se clasifican en:
Factores de hardware.
 Son las características que ofrecen los componentes físicos de la solución. 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.
47
 Además se consideran paquetes especiales, tales como simuladores, análisis financieros,
programación lineal, control de proyectos, análisis estadísticos y paquetes que se enfocan a
resolver problemas funcionales a los usuarios, tales como contabilidad, cuentas por pagar, y
facturación, 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 más importantes para tomar una decisión de compra, así también
como el precio y el rendimiento.
Aspectos a analizar son:
1.- Generalidades del proveedor. Toda aquella información relacionada con la imagen
que éste tiene en el mercado local, regional y mundial, considerando aspectos técnicos, de mercado
y financieros, de tal manera que aseguren la permanencia y continuidad del proveedor. Ellos
incluyen:
 Representación mundial y regional del proveedor
 Tiempo de entrega del equipo y futuras ampliaciones
 Profesionalismo y preparación de los vendedores
 Situación económica y financiera
 Calidad de la documentación y manuales disponibles
2.- Apoyo a la capacitación:
Es el apoyo que brinda en la capacitación al personal técnico y usuarios con el uso de los
recursos de hardware y software propuestos. Incluye la capacitación:
 al personal de las áreas de investigación y soporte técnico
 en el área de análisis y programación
 a operadores
 capacitación a usuarios
3.-Mantenimiento de hardware y software.
Consiste básicamente 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 algún problema.
 Tiempo promedio que el sistema permanece caído durante cada falla.
 Existencia de una sucursal cercana con partes y repuestos para responder con
mayor oportunidad a fallas.
 Existencia de horario extendido, 7 días 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
operación 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 satisfacción de estos usuarios en relación con el proveedor.
5.- Apoyo durante la conversión de aplicaciones.
Se refiere a la asistencia que el proveedor pueda proporcionar al cliente
durante el proceso de conversión y traslado de las aplicaciones y programas al
nuevo equipo. Algunos aspectos a tomar en cuenta son:
 Los antecedentes que tiene el proveedor en el apoyo a otros clientes en
conversiones similares a las requeridas.
 Facilidad de iniciar la conversión de aplicaciones antes de la llegada del
equipo, a fin de reducir el tiempo y costo de la operación paralela de ambos
equipos.
2.4. Métodos de evaluación técnica
48
 Pueden aplicarse en forma individual o alternada, y complementariamente.
Método de mezcla de instrucciones: para comparar velocidades del procesador de diversos equipos se
puede escoger un conjunto de instrucciones representativas y más utilizadas por los programas de usuario y
sacar un promedio ponderado del tiempo de ejecución de ellas. Además, se debe asignar un peso a cada
instrucción de acuerdo con la frecuencia del uso de ésta en los programas.
Método de Kernel: un kernel es un problema simple y representativo de las aplicaciones típicas a
computarizar por el nuevo equipo; mide el tiempo que emplea en ejecutar esta aplicación cada uno de los
equipos que se comparan.
Método de simulación: consiste en hacer uno o varios programas utilizando técnicas y lenguajes de
simulación con el fin de imitar el funcionamiento de un sistema computacional. Se definen parámetros
como tiempo de ejecución, 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.
Método de benchmark: sirve para comparar el rendimiento de uno o varios programas de aplicación en
diferentes o igual plataforma de hardware. Existen revistas especializadas que periódicamente publican
evaluaciones de comparaciones técnicas de equipo computacional.
Método 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. Evaluación financiera

Es el proceso mediante el cual el administrador del proyecto define y evalúa las características y
los factores económicos de los equipos a considerar.

2.6. Alternativas de adquisición y financiamiento

Renta
Es el proceso por el cual el usuario renta el equipo del proveedor por un período definido como
obligatorio, al término 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 opción de compra del equipo.
El alquiler de computadoras tiene algunas ventajas con respecto a la adquisición del equipo:
 No implica un desembolso inicial de dinero.
 El proveedor es responsable por el mantenimiento del equipo.
 No es una opción obligatoria en el largo plazo.
 Evita la obsolescencia y es más fácil hacer un cambio por un equipo posterior.
 Existe una ventaja fiscal por ser un gasto deducible para pago de impuestos.
Algunas desventajas son:
 Es más costosa si es a largo plazo.
 Está sujeta a incremento por parte del proveedor.
Compra
Una segunda opción es la compra de un equipo computacional. Las ventajas son:
 Resulta más barato cuando se requiere por largos períodos.
 No existen incrementos de los pagos.
 Al final del período el equipo tiene un valor de recuperación.
Algunas posibles desventajas son:
 Obsolescencia.
 Error en la selección del equipo.
 Desembolso considerable de dinero.
 Incertidumbre sobre el valor de reventa o caída en desuso total.

2.8. El método del costo / rendimiento

Este método propone calificar y clasificar a los sistemas ofrecidos según la relación costo /
rendimiento. De la aplicación de este método resulta como mejor oferta aquella que, en conjunto, es
potencialmente más capaz como consecuencia de promediar y compensar el índice de potencialidad con el
costo de implementación. 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.
49
Fase 1: verificación de requisitos mínimos
Esta fase común a todos los procedimientos de evaluación de ofertas, tiene como finalidad la
verificación de que todas las propuestas cumplan las condiciones mínimas establecidas en el pliego de
especificaciones técnicas, donde se determinan los requerimientos mínimos que deberán ser atendidos.
Estos requerimientos mínimos deben ser desdoblados considerando:
 exigencias que constituyen el objeto principal de la contratación y que están definidas en
términos precisos, expresados en magnitudes cuantificadas y cuantificables. Pueden citarse para este
grupo:
o Parámetros de selección de hardware
o Parámetros de selección de software
o Soporte de la firma oferente
o Pruebas y demostraciones
 especificaciones que no constituyen el objeto principal de la contratación, pero que han
sido expresamente manifestados y que por sus características no son deducibles de la oferta. Por
ejemplo:
o Compatibilidad con otros equipos y dispositivos.
o Posibilidades de ampliación.
o Adaptación de procesos, etc.
Hecho este análisis se determinan, a partir de las ofertas aceptadas en el acto de apertura, las
propuestas que cumplen con los requerimientos mínimos exigidos. Los remanentes serán considerados en
detalle en la próxima fase.

Fase 2: ponderación y clasificación

Este método utiliza cuadros comparativos (grillas) de distintos niveles de consolidación, donde se
reflejan ponderaciones (P) y calificaciones (CAL) absolutas y relativas para los distintos parámetros de
selección.
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 información está dispuesta tabularmente, hallando en las líneas horizontales as
distintas características a evaluar (FACTOR), y en las columnas las propuestas, existiendo además
columnas para las calificaciones y ponderaciones.
Las ponderaciones representan el peso asignado a cada una de las características evaluada en los
distintos niveles, teniendo en cuenta los criterios de evaluación 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 característica 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 calificación 3 a la oferta que presente mayores prestaciones, y
proporcionalmente a esas prestaciones se asignarán valores a las ofertas restantes. A los atributos de tipo
cualitativo (monitores, memoria cache, etc.) dicha calificación asume el valor 0 o 3 en función de poseer o
no la característica 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 calificación máxima.
Se obtiene la relación costo/rendimiento para cada propuesta, a partir de la cual se establece un
ranking de las propuestas recibidas, considerándose como más adecuada aquella que estando dentro de las
posibilidades presupuestarias, haya obtenido el menor cociente.

50
51
52
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 función afín de demostración, se caracteriza
por 4 funciones o elementos esenciales:
 Medición del rendimiento de los sistemas;
 Programas del usuario, proporcionados por un cliente o presunto cliente como
especificación o como codificación real;
 Fase de ajuste, cuyo objeto es optimizar el rendimiento del sistema;
 Comparación del rendimiento optimizado de un sistema de un proveedor con el de un
sistema competitivo, o con otro sistema del mismo proveedor.

2.10. Tipos de benchmark

Teórico:
 Sirve para medir tiempos casi en forma exclusiva, es decir, mide velocidades.
 Consiste en programas que están escritos en un lenguaje de aplicación de alto nivel y que
realiza en forma simple y única un solo tipo de tarea. Las pruebas básicamente son para el
procesador, sus recursos (memoria, UAL), y los distintos periféricos: pantallas, discos, impresoras,
etc.
 Los programas usan los recursos del sistema de acuerdo a ciertos parámetros
especificados en tiempo de ejecución. No hace nada productivo con estos recursos, sino que los
ejercita a fin de efectuar mediciones genéricas. Por ejemplo, se le podría pedir que lea 1000
registros de un archivo en disco, ejecute 100000 adiciones de punto flotante e imprima 5000
líneas, y que luego indique el tiempo total requerido por este benchmark artificial.
 Ventajas:
 es rápido, simple, fácil y equitativo porque se usan los mismos programas en
distintos equipos.
 No sólo se prueba el equipo en sí, sino la eficiencia en la administración 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 adecuación, ni costo de conversión ni capacitación.
 Con estas pruebas no sólo se valoriza el hardware, sino también 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 aplicación del cliente, con
todos sus programas. Para ello es imprescindible que exista la facilidad de transmisión, ya sea vía
magnética y/o comunicaciones. A posteriori se deberán 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 ejecución.
 Es un conjunto de programas tomados de la carga de máquina del usuario y
transformados en un modelo adecuado de la carga de máquina total. A pesar de los problemas
existentes en cuanto a representatividad, existe un consenso general de que a los efectos de la
selección de un equipo de computación, el benchmark real es la herramienta preferida para la
medición de performance.
 Ventajas:
 Tiene la propiedad de evaluar en forma completa los recursos del equipo
y su sistema operativo.

53
  Evalúa 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 conversión.
 Inconvenientes:
 es lento, costoso y a veces suele ser demasiado complicado llevarlo a cabo,
sobre todo cuando no existe la posibilidad de traslación de datos entre un equipo
actual y aquel al cual se quiere hacer las pruebas.
 Sólo 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.
 Estos recursos no han sido contemplados o aprovechados por el sistema habida cuenta de
la inexistencia de los mismos en la instalación. Esta prueba es fundamental para poder comparar
las distintas formas de manejar los datos y editar la información.
 Además, 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 más tiempo, esfuerzo y costo que incluso el benchmark real.
 No todos los proveedores están 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 ponderación que se otorga a cada uno
de ellos al hacer el polinomio de calificación.

3. Lanzamiento de un sistema de información

3.1. Contrataciones
Lista de actividades que podrían desarrollarse:
 Definición de necesidades de adquisición o arrendamiento de hardware, software y / o
servicios de proveedores.
 Definición de factores de evaluación de hardware: desempeño, costo, confiabilidad,
disponibilidad, compatibilidad, modularidad, tecnología, ergonomía, conectividad, tamaño,
configuración, costo y soporte.
 Definición de factores de evaluación de software: eficiencia, flexibilidad, seguridad,
conectividad, lenguaje, documentación, plataforma de procesamiento, costo, soporte y otros
factores de interés.
 Definición de factores de evaluación de servicios: disponibilidad, trayectoria profesional
de los consultores, certificación y reputación del oferente a otras firmas, costos y otros factores de
interés.
 Redacción de los pliegos de especificaciones técnicas de la contratación.
 Lanzamiento de la contratación.
 Evaluación 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.

54
  Grillas comparativas de características costo y rendimiento (benchmark).
 Adjudicación de la contratación al proveedor.
3.2. Documentación
El desarrollo de una buena documentación para el usuario es una parte importante del proceso de
lanzamiento de una aplicación.
El manual del usuario de cada aplicación, debe incluir:
 Disposiciones generales.  Instructivos.
 Objetivos.  Flujogramas de navegación
 Políticas.  Reportes.
 Descripción de la aplicación.  Información sobre reportes.
 Flujo general de trabajo.  Muestra del reporte.
 Descripción de procedimientos.  Descripción del reporte.
 Pantallas  Glosario de términos.
 Formularios.
3.3. Capacitación de usuarios
La participación en los sistemas informáticos y su aceptación por el personal es la parte más
importante y difícil de la implementación.
Después de una capacitación práctica 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 diseño e implementación de sistemas con el objetivo de
lograr una comprensión de las metodologías y la tecnología de los sistemas de información.
Las acciones prácticas en lo referente al establecimiento de un programa para el desarrollo y la
capacitación de recursos humanos incluyen:
 Asegurar, cuanto antes, la identificación y la selección de los miembros del personal que
participan en todos los niveles de implementación y operación de los sistemas con el objetivo de
recibir capacitación pertinente, teórica y práctica, en los sistemas de información y en la
tecnología de sistemas.
 Considerar los temas asociados con el entorno de la organización en el cual se
implantarán y utilizarán los sistemas.
 Diseñar estrategias de capacitación para los sistemas de información, las cuales tengan
en cuenta los temas asociados con su desenvolvimiento, el entorno orgánico en el cual se prevé su
funcionamiento y las circunstancias particulares de la organización.
A continuación se recomiendan normas sobre las estrategias para capacitación de usuarios de
sistemas informáticos:
 Identificar los grupos destinatarios sobre la base de las funciones de los usuarios.
 Analizar los requisitos previstos de desempeño de los usuarios en relación con el sistema
nuevo mediante un modelo participativo que abarque todas las categorías y funciones.
Evaluar las necesidades de capacitación, incluido el nivel actual de comodidad y conocimiento de las
tecnologías que se van a emplear.
 Elaborar programas de capacitación para satisfacer las necesidades identificadas de los
grupos destinatarios.
 Establecer una red de puntos focales para la capacitación, los cuales toman en cuenta los
requisitos y las iniciativas de las unidades de la organización.
 Una estrategia de capacitación para las formas modernas de procesamiento y análisis de
información debe abarcar a todos los participantes y tener carácter interdisciplinario, sin dejar de
considerar las necesidades particulares de los diferentes grupos funcionales y profesionales.
Cada organización debe elaborar su propia estrategia para la capacitación inicial y continua en los
sistemas de información, la cual tiene en cuenta, por un lado, el desarrollo general de los sistemas de
información y, por otro, el entorno particular de cada sistema implementado.
Para ello se debe:
 Llevar a cabo la capacitación en un entorno multidisciplinario.
 Utilizar herramientas didácticas tecnológicas avanzadas siempre que sea posible.
 Proporcionarse capacitación en el trabajo a todos los niveles para satisfacer los requisitos
cotidianos.

55
 Vincular la educación y la capacitación con las experiencias prácticas para lograr la
motivación de los usuarios.
 Prestar mucha atención de acuerdo con el grupo destinatario para evitar el uso excesivo
de jerga tecnológica y complejidad de conceptos.
 Definir los niveles mínimos de capacidad.
 Proveer de recursos para respaldar la preparación de material de enseñanza y para
permitir la adaptación del material de capacitación a fin de satisfacer las necesidades de grupos
destinatarios de distintos niveles.
 En la capacitación debe incluir conocimientos de computación básica y práctica,
capacitación específica en las aplicaciones, desempeño y funciones individuales en la operación
del sistema.
 Probar los programas de capacitación antes del uso a gran escala.
 La metodología de presentación permitirá la interacción de los participantes.
 La capacitación se realizará lejos de las distracciones del ambiente de trabajo cotidiano y
lo más cerca que sea posible a la implementación real.
 Las actividades del grupo ayudarán a reducir la formulación tediosa de algunos temas
técnicos.
 Las situaciones simuladas, las presentaciones grupales o individuales determinarán 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 capacitación mediante la satisfacción y la
retroalimentación de los usuarios, la retroalimentación de los administradores, la situación previa
y posterior a la evaluación, y la frecuencia y el tipo de llamadas solicitando asistencia durante el
uso de los sistemas, resulta imprescindible como etapa final.
3.4. Implantación
A los fines de la puesta en marcha del sistema pueden seguirse cuatro métodos de conversión:
 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 conversión piloto.
 Por fases: se convierten sólo partes de una nueva aplicación o sólo unos cuantos
departamentos, sucursales o plantas a la vez. Esto permite que tenga lugar un proceso de
implementación gradual dentro de una organización.
 Piloto: un departamento u otro sitio de trabajo actúan 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 organización.
 Desmontes repentinos (sustitución)

3.5. Mantenimiento de S.I.

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

56
 Es la supervisión, evaluación y modificación de sistemas de información operacionales
para realizar los mejoramientos necesarios o deseados.
 Un nuevo sistema genera el fenómeno “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 señalan áreas
donde se lo podría mejorar.
 El mantenimiento es también necesario para otras fallas y problemas que surgen durante
la operación de un sistema.
 La actividad incluye también un proceso de revisión después de la implementación, 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 auditoría o revisión periódica 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 realización de modificaciones a un
sistema debido a cambios en la organización o el entorno empresarial. Por ejemplo, una nueva
legislación tributaria, las reorganizaciones de empresas y las nuevas incursiones empresariales
usualmente requieren que se realice una variedad de cambios en los sistemas de información.

57