INFORMATICA IV

Ingeniería de Sistemas

GUÍA DE ESTUDIO
Carta al alumno

Estimado alumno:

Finalmente y luego de varios meses de recopilación, lectura y redacción

es un gran orgullo para nosotros poder presentarle en esta guía el resultado de nuestro
trabajo. Nos sentimos orgullosos por partida doble: Orgullosos por saber que con este
material se contribuye a la actualización de contenidos referidos al campo de la
ingeniería de software de la carrera de ingeniería de sistemas del IUA, brindando a los
alumnos procesos, técnicas y herramientas acordes al uso y demanda formativa del
presente, por un lado. Por otra parte, nos sentimos orgullosos por ver realizada la
oportunidad de plasmar en un trabajo académico la investigación y la experiencia
profesional en una disciplina de tanta trascendencia para la industria nacional del
software.

Esta es una profesión en la que se ha oído hablar ya muchas veces de

“balas de plata” presuntamente capaces de hacer desaparecer los innumerables fracasos
que sufren los proyectos de software. Los mentores del paradigma de objetos, por
ejemplo, hablan de aumentos de productividad del orden 14 a 1. “Siempre se ha dado
por supuesto que, si yo enseño un método, éste es correcto sólo porque yo lo digo”,
denuncia Víctor R. Basili, un profesor en la Universidad de Maryland. “Se están
produciendo todo género de cosas y resulta verdaderamente escalofriante lo malas que
son algunas de ellas,” dice también.

Hecha la salvedad, y seguros de que el éxito no radica en tal o cual

metodología, sino en la adopción y seguimiento disciplinado de una de ellas capaz de
formalizar los procesos, evolucionar y adaptarse a la realidad de cada situación; esta
materia, al igual que su antecesora Análisis y Diseño, se fundamenta en el desarrollo de
conocimiento teórico práctico sobre normas y estándares para el desarrollo de software
dado por el denominado "Proceso Unificado de Desarrollo".

Recuerde que cuenta con nuestro apoyo constante para vencer cualquier
contrariedad e inquietud.

¡Mucha suerte!

Los autores

1
 Ingeniería de Sistemas – Plan 1997

Informática IV – Versión 2006

Objetivos generales

Esperamos que al finalizar la materia usted haya logrado los siguientes objetivos:
 Participar activamente en un proyecto de desarrollo de software para una
empresa real, utilizando el marco metodológico propuesto por el proceso
unificado de desarrollo.
 Consentimiento cabal de los usuarios sobre los requerimientos y aspectos que
convalidan el lanzamiento de un proyecto de sistemas para la Organización
destinataria del aplicativo que se desarrollará como actividad práctica obligatoria
en esta materia.
 Transformar los requerimientos del usuario en subproductos de arquitectura que
describan los componentes de un sistema informático y su comportamiento en la
organización.
 Conocer los artefactos, trabajadores y actividades involucradas en los flujos de
diseño, implementación y prueba.
 Implementar y probar prototipos y versiones evolutivas de un aplicativo de
software.
 Desarrollar la creatividad para aplicar los conceptos teóricos, e integrarlos con
los aprendidos en materias anteriores.
 Comprender de una forma crítica y reflexiva los principios básicos que
fundamentan la implementación de sistemas de información basados en las
tecnologías de información seleccionadas como apoyo a los procesos
organizacionales.

2
Programa

Unidad 1: Diseño

1 Introducción
2 Artefactos
2.1 Modelo de diseño
2.2 Clases de diseño
2.3 Realización de casos de uso - diseño
2.4 Subsistema de diseño
2.5 Interfaz
2.6 Descripción de la arquitectura
2.7 Modelo de despliegue
3 Trabajadores
3.1 Arquitecto
3.2 Ingeniero de casos de uso
3.3 Ingeniero de componentes
4 Flujo de trabajo
4.1 Diseño de la arquitectura
4.2 Diseño de un caso de uso
4.3 Diseño de una clase
4.4 Diseño de un subsistema
5 Caso práctico de cierre

Unidad 2: Implementación

1. Propósito de la implementación4
2. Conceptos preliminares
2.1. Implementar el diseño
2.2. Las pruebas de desarrollo
2.3. Entornos de desarrollo e integración
2.4. Entorno de desarrollo individual
2.5. Entorno de integración de subsistemas
2.6. Entorno de integración del sistema total
3. El flujo de trabajo implementación
3.1. Estructurar el modelo de implementación
3.2. Planear la integración
3.3. Implementar componentes
3.4. Integrar cada Subsistema
3.5. Integrar el sistema
4. Actividades
4.1. Estructurar el modelo de implementación
4.2. Planear la integración del sistema
4.3 Implementar componente
4.4 Ejecución de pruebas unitarias
4.5 Corregir defectos
5. Artefactos
5.1 Modelo de implementación
5.2 Construcción

3
 5.3 Componente
5.4 Stubs
5.5. Subsistema de implementación
5.6 Interfases
5.7. La vista del modelo implementación
6. Trabajadores
6.1 Arquitecto de Software
6.2 Implementador
6.3 Integrador de Sistemas

Unidad 3: Pruebas

1. Propósito de las pruebas

2. Conceptos preliminares
2.1. Psicología y economía de las pruebas
2.2. Conceptos básicos
2.3 Tipos de prueba
2.4. Etapas de Prueba
3. Flujo de trabajo de prueba
3.1. Planificar pruebas
3.2. Diseñar prueba
3.3. Implementar prueba
3.4. Realizar pruebas de integración
3.5. Realizar prueba de sistema
3.6. Evaluar prueba
4. Artefactos
4.1. Artefacto modelo de pruebas
4.2. Artefacto caso de prueba
4.3. Artefacto procedimiento de prueba
4.4. Artefacto componente de prueba
4.5. Artefacto plan de prueba
4.6. Artefacto defecto
4.7. Artefacto evaluación de prueba
5. Trabajadores
5.1. Diseñador de pruebas
5.2. Ingeniero de pruebas de integración
5.3. Ingeniero de pruebas de sistema

Unidad 4: Utilizando PUDS

1 Metodología PUDS
1.1 PUDS dirigido por casos de uso, centrado en la arquitectura, iterativo e
incremental.
1.2 El UP entrega las 6 mejores prácticas
1.3 Ventajas y errores al utilizar el proceso unificado
2 Fases e iteraciones
2.1 Planificación de las fases
2.2 Planificación de las iteraciones

4
 2.3 Evaluación
3 Flujos de trabajo
3.1 Flujos de trabajo fundamentales
3.2 Dominio del problema y de la solución
3.3 Flujos de trabajo y modelos

Unidad 5: Implementación del cambio

1. Creación de conocimiento e implementación del cambio organizacional con T.I.

1.1 La creación del conocimiento con T.I. y la ventaja competitiva
2. Adquisición de hardware, software y servicios6
2.1. Evaluación y selección
2.2. Elaboración de una Requisición de Propuesta (RFP – Request For Proposal)
2.3. Factores a evaluar
2.4. Métodos de evaluación técnica
2.5. Evaluación financiera
2.6. Alternativas de adquisición y financiamiento
2.7. Método de benchmark
2.8. El método del costo / rendimiento
2.9. Conceptos sobre benchmark
2.10. Tipos de benchmark
3. Lanzamiento de un sistema de información
3.1. Contrataciones
3.2. Documentación
3.3. Capacitación de usuarios
3.4. Implantación
3.5. Mantenimiento de S.I.

5
Bibliografía propuesta

 JACOBSON, Ivar. El Proceso Unificado de Desarrollo. Editorial Addison

Wesley. España. 2000.

Este libro presenta una metodología para el desarrollo de sistemas software orientado a
objetos, éste es el proceso unificado de desarrollo de software que utiliza como técnica
de representación UML.

 WEITZENFELD, Alfredo. Ingeniería de Software orientada a Objetos con

UML, Java e Internet.. Ed. Thomson. México, 2004.

Este libro trabaja los conceptos principales del desarrollo de software y la notación
UML, a la vez que propone aplicaciones y ejemplos en Java.

 PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico. Quinta

edición. Editorial Mc Graw Hill. España. 2002.

Este libro abarca los tópicos más importantes de esta disciplina, con ejemplos y
aplicaciones prácticas.

 LARDENT, Alberto. Sistemas de Información para la gestión empresaria.

Primera edición. Editorial Prentice Hall. Buenos Aires. 2001.

Este libro presenta los SI respondiendo a las políticas organizacionales y las TI

brindando soluciones a la gestión empresarial.

Bibliografía Complementaria

 BOOCH, Grady. Análisis y Diseño orientado a objetos con aplicaciones.

Segunda edición. Editorial Addison Wesley/Díaz de Santos. USA. 1996.

El texto de Booch introduce en sus primeros capítulos los conceptos fundamentales del
modelo de objetos.

 LARMAN, Craig. UML y Patrones. Primera edición. Editorial Prentice Hall,

Inc. México. 1999.

Es un texto práctico que ejemplifica cada etapa del proceso de desarrollo de software
usando notación UML.

 TURBAN, Efraim. Decision Support and Intelligent Systems. Sexta Edición.

Editorial Prentice Hall, Inc. 1995-2001.

Este libro aborda las características de los sistemas de soporte de decisión (DSS) y los
EIS.

6
Introducción general orientadora

Los tiempos en que el desarrollo artesanal de sistemas era la regla

pasaron. Hoy nos enfrentamos a una explosión de la demanda de sistemas de
información que debe ser atendida en términos de cantidad, complejidad, calidad,
oportunidad y presupuesto. Esta realidad desbordante no podrá ser satisfecha, ni los
niveles de disconformidad de los usuarios atemperada si no contamos con un proceso
definido de desarrollo.

“La presencia de un proceso de desarrollo formalizado de software,

bien definido y bien gestionado, es un factor de éxito de un proyecto. Un proceso es
estable si su rendimiento futuro puede predecirse estadísticamente.” 1

Convencidos de esto, continuaremos con los flujos de trabajo

fundamentales del proceso unificado de desarrollo. Recordemos que en Análisis y
Diseño se caracterizó y describió al PUD, profundizando sobre la actividad de
modelado de negocio y los flujos de trabajo requerimientos y análisis. Completaremos
ahora el estudio de los flujos de: diseño, implementación y prueba, completando de
este modo, no todas, pero sí las más importantes disciplinas propuestas por esta
metodología adoptada en la actualidad por la mayoría de las comunidades
universitarias y profesionales de desarrollo de sistemas de información.
Posteriormente retomaremos el funcionamiento de la metodología para comprobar los
conceptos aprendidos sobre la misma.
Luego dedicaremos una unidad a la implementación del cambio, a fin de
estudiar métodos y herramientas para la selección de una plataforma tecnológica
adecuada (TI) que de soporte a los SI.

Esta es una materia taller donde será importante su conocimiento sobre

los conceptos teóricos desarrollados, pero lo es mucho más aún, su aplicación práctica
en un proyecto de sistemas tomando como referencia a una organización real.

Pretendemos que esta materia sirva como antesala a lo que será su

trabajo final de analista, integrando sus conocimientos, y así retroalimentar el proceso
de enseñanza aprendizaje que nos involucra.

1
Deming W. E. 1982, Quality, Productivity, and Competitive Position. Massachusetts Institute of
Technology Center for Advanced Engineering Study, Cambridge, MA.

7
Esquema conceptual general

Sistemas de Información

Implementación del cambio

U1

U5
Ingeniería de Software

U2

UML

PUDS Info. IV
Análisis y Diseño U4
Inicio

U5
Elaboración
Fases
U3 U4 U1
Construcción
U2
Análisis
Modelado de Transición U3
Negocio

Flujos de Trabajo Diseño

Requerimientos

Implementación

Prueba

Actividades Artefactos Trabajadores

8
¿Qué estudiamos?

En el modelo de requerimientos hemos especificado qué debe pasar

dentro del sistema. El modelo de análisis, por su parte, apunta a crear una plataforma
para el diseño del sistema, y también forma la base para el diseño. El modelo de
requerimientos es estructurado así por el modelo de análisis.

Recuerde que el trabajo de desarrollar el modelo de análisis implica la

distribución del comportamiento especificado en las descripciones de los casos de uso
entre los objetos del modelo de análisis.

En la unidad 1 de la materia vemos el modelo de diseño; éste nos define

la forma del sistema, preservando la estructura definida en el modelo de análisis, para
que soporte todos los requisitos, incluyendo los no funcionales. Este modelo será un
punto de partida para las actividades de implementación. Nos permitirá dividir el
trabajo de implementación en partes bien manejables, de manera tal que la tarea pueda
ser fácilmente distribuida entre los desarrolladores de la aplicación.

En la unidad 2 le presentamos los elementos necesarios para concretar

la definición de un modelo de implementación basado en una arquitectura estable y
definitiva. Veremos como encarar la construcción de un aplicativo en una versión
utilizable, perfectamente ajustado a las necesidades de los usuarios y definidas
previamente en el flujo de trabajo de requerimientos. Se analizará el propósito,
conceptos, actividades, trabajadores y artefactos que son propios del flujo de trabajo
implementación del PUD.

En la unidad 3 se tratan los aspectos relacionados con la fiabilidad y

calidad de los desarrollos de software. Veremos en particular el flujo de trabajo de
pruebas, recorriendo al igual que en otros flujos el propósito, conceptos, actividades,
trabajadores y artefactos aplicados a esta disciplina.

En la unidad 4 se retoman los conceptos y fundamentos de la

metodología para afirmar y corroborar los mismos en función de la experiencia
adquirida hasta ahora a través de cada uno de los flujos de trabajo vistos.

En la unidad 5 identificaremos las actividades propias del proceso de

implementación del cambio organizacional y tecnológico, poniendo especial atención
en la descripción de los criterios y ponderación de los factores que se utilizan en la
selección de hardware, software y servicios de tecnología de información (TI).
Finalmente, se presentan las actividades propias de la puesta en producción de un
sistema. Trataremos aspectos relacionados a las contrataciones, documentación,
capacitación, estrategias de implantación y mantenimiento.

9
¿Cómo es la evaluación?

La materia tiene dos instancias de evaluación: la autoevaluación y la

evaluación del docente a través de actividades obligatorias.

 Autoevaluación

La tópicos de autoevaluación han sido seleccionados teniendo en

cuenta los objetivos del aprendizaje, e integran los contenidos de cada unidad. Por
cada unidad encontrará en la página web de la asignatura un cuestionario y las
respuestas para que las confronte con las suyas. Intencionalmente las respuestas se
cargan en archivos diferentes con el objeto de que las acceda sólo después de haber
intentado responderlas por sus propios medios.

Las Actividades de autoevaluación se encuentran en la sección

archivos de cada unidad.

En la página web de la asignatura encontrará también casos de estudio

y ejemplos adicionales a los de esta guía.

 Evaluación a cargo del docente: Actividades obligatorias

Con el objeto de que el tutor pueda seguir y evaluar su proceso de

aprendizaje, se han previsto dos actividades obligatorias. Una al finalizar la primera
unidad y la otra al finalizar la tercera. Encontrará las actividades en la sección
archivos correspondientes a la actividad obligatoria 1 y 2 respectivamente.

Ambas actividades obligatorias deberán estar aprobadas para obtener la

regularidad en la materia y acceder así al examen final.

Las dos actividades obligatorias se desarrollarán llevando a cabo el

proceso de desarrollo de sistemas software con la metodología que se aborda en el
cursado de la asignatura. El tema a desarrollar deberá seleccionarlo a partir de una
empresa del medio (es deseable que continúe con el tema seleccionado en Análisis y
Diseño y para el cual ya realizó los dos primeros flujos de trabajo del PUD).

Cada una de estas actividades deberá remitirla a su tutor a través de la página

Web del IUA.

 Examen final

Es la instancia de evaluación presencial que se lleva a cabo en la

institución. Para ello debe estar habilitado para rendir y haber realizado previamente
la inscripción para examen.

Los criterios de evaluación de la asignatura son los siguientes:

 Rigurosidad y precisión en la formulación conceptual.
 Aplicación pertinente de los conceptos, mecanismos, métodos, procesos y
herramientas estudiados.
 Precisión en la utilización de terminología específica.

10
 Coherencia en el avance del proyecto.

La evaluación es individual, teórico-práctica. Es necesario aprobar el

teórico y el práctico para luego promediar el puntaje y obtener la calificación.

11
¿Cuánto tiempo lleva estudiar la asignatura?

Indiscutiblemente el tiempo que le llevará completar esta materia

depende de la dedicación horaria que usted brinde al estudio. Podrá influir también
sus conocimientos previos sobre el tema. También será muy determinante la correcta
elección de sus compañeros de grupo para el desarrollo del trabajo práctico. Considere
la compatibilidad de horarios y situación particular de cada estudiante en relación a
prioridades de estudio de esta asignatura.

Recuerde que para organizar sus tiempos y lograr un mejor

rendimiento de las horas de dedicación, puede consultar permanentemente con su
tutor.

Le ofrecemos un cronograma de trabajo, éste le brinda un porcentaje

aproximado de los tiempos necesarios para realizar el aprendizaje de cada unidad y
resolver las actividades propuestas en cada una de ellas.

Las columnas en blanco son para que usted organice su propio tiempo
de estudio.

Porcentaje de
Unidades Horas Fechas
tiempo
Unidad 1 20%
Actividad Obligatoria N° 1 15 %
Unidad 2 15 %
Unidad 3 15 %
Actividad Obligatoria N° 2 15 %
Unidad 4 10 %
Unidad 5 10 %
Examen Final

12
 Versión 2006

Informática IV

Unidad 1

Diseño
Unidad 1: Diseño

Autor/es
Boggio, Alejandra
Casali, Diego
Salamon, Alicia

Orientación del Aprendizaje

El modelo de requerimientos define los límites y especifica el comportamiento

general del sistema, cuando el usuario lo aprueba podemos comenzar con el modelo
de análisis. Éste nos ayuda a estructurar el sistema independientemente del entorno de
implementación. Ésto busca obtener una estructura robusta adaptable a cambios.
Ahora, una vez que tenemos el modelo de análisis, pasamos al modelo de diseño, que
nos define la forma del sistema preservando la estructura definida en el modelo de
análisis para que soporte todos los requisitos, incluyendo los no funcionales. Este
modelo será un punto de partida para las actividades de implementación y nos
permitirá dividir los trabajos de implementación en partes manejables, de manera tal
que la tarea pueda ser fácilmente distribuida entre los desarrolladores de la aplicación.
En esta unidad estudiamos el siguiente flujo de trabajo del PUDS: el diseño.
Consideramos las entradas, los artefactos que se obtienen y el proceso de construcción
de los mismos.
A esta altura podemos constatar mediante nuestra experiencia las ventajas de esta
metodología de desarrollo, retomamos sus características principales (dirigido por
casos de uso, iterativo e incremental y centrado en la arquitectura) y podemos ver
cómo en este punto dichos pilares han contribuido al desarrollo.

Desde esta perspectiva los contenidos que trabajamos en esta unidad son:

1 Introducción .........................................................................................................15
2 Artefactos .............................................................................................................16
2.1 Modelo de diseño .........................................................................................16
2.2 Clases de diseño ...........................................................................................16
2.3 Realización de casos de uso - diseño ...........................................................16
2.4 Subsistema de diseño ...................................................................................19
2.5 Interfaz .........................................................................................................20
2.6 Descripción de la arquitectura .....................................................................21
2.7 Modelo de despliegue ..................................................................................21
3 Trabajadores .........................................................................................................22
3.1 Arquitecto ....................................................................................................22
3.2 Ingeniero de casos de uso ............................................................................22
3.3 Ingeniero de componentes ...........................................................................22
4 Flujo de trabajo ....................................................................................................22
4.1 Diseño de la arquitectura .............................................................................23
4.2 Diseño de un caso de uso .............................................................................26
4.3 Diseño de una clase......................................................................................27
4.4 Diseño de un subsistema ..............................................................................31
5 Caso práctico de cierre .........................................................................................31

Al finalizar esta unidad usted habrá alcanzado los siguientes objetivos:

13
  Comprender la importancia del modelo de diseño.
 Diferenciar el modelo de diseño del modelo de análisis y del de
requerimientos.
 Diferenciar el modelo de diseño del modelo de implementación.
 Comprender los problemas que podemos tener en el diseño si no
contamos con un modelo de análisis robusto.
 Identificar los artefactos, trabajadores y flujos de trabajo que se
utilizan en el flujo de diseño.
 Comprender la función de los diagramas de secuencia.

¿Cómo estudiar esta unidad?

Para poder abordarla usted trabaja con la guía de estudio y profundiza los contenidos
de la misma en la bibliografía propuesta. Le sugiero que reflexione sobre cada punto a
tratar y realice las actividades que se presenten.

Bibliografía recomendada

 JACOBSON, Ivar. El Proceso Unificado de Desarrollo. Editorial Addison

Wesley. España. 2000.

 WEITZENFELD, Alfredo. Ingeniería de Software orientada a Objetos con

UML, Java e Internet.. Ed. Thomson. México, 2004.

 PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico. Quinta

edición. Editorial Mc Graw Hill. España. 2002.

 LARMAN, Craig. UML y Patrones. Primera edición. Editorial Prentice Hall,

Inc. México. 1999.

14
1 Introducción
Una vez terminado el modelo de análisis podemos decir que ahora sí ya tenemos una
descripción bien detallada de todos los requisitos del sistema. Entre otras cosas
podremos analizar todos aquellos requisitos no funcionales que fuimos registrando en
los flujos anteriores para estudiar en esta etapa de diseño. Es decir, el modelo de
diseño constituye una formalización y refinamiento adicional al modelo de análisis.

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

El modelo de implementación tiene como objetivo, valga la redundancia, implementar

cada objeto específico en términos de componentes, es decir, archivos de código
fuente -scripts-, archivos de código binario -ejecutables-. Desde el modelo de diseño
conseguimos especificaciones muy detalladas de todos los objetos, incluyendo sus
operaciones y atributos. El lenguaje de programación y las librerías de componentes
serán las herramientas fundamentales para la implementación.
En el modelo de diseño es muy importante que ya tengamos definidas las
herramientas que utilizaremos para desarrollar nuestra aplicación, ya que hay cosas
que se pueden dejar listas y así autogenerarlas para el modelo de implementación sin
tener que hacer prácticamente ningún cambio.

En este modelo, como en todos los demás, es muy importante el concepto de

rastreabilidad del que ya hemos hablado.

El modelo de diseño refina el modelo de análisis. Se definirán explícitamente las

interfases de los objetos y la semántica de las operaciones. Se compondrá de bloques
que constituirán los objetos de diseño. Estos bloques son la estructura real del modelo
y muestran cómo se ha diseñado el sistema.
Éstos serán luego implementados como código fuente, abstrayendo así la
implementación real. Son implantados por una clase o por varias clases diferentes.
Inicialmente cada objeto de análisis se transformará en un bloque, ésto significa que
tenemos una clara rastreabilidad en los modelos.
Cuando un objeto de análisis es rastreable a un bloque, los cambios introducidos en el
modelo de análisis serán locales al bloque correspondiente en el modelo de diseño y
en el código fuente.
La rastreabilidad es bidireccional, es decir que podemos rastrear una clase desde el
código fuente al análisis y ver qué le dio origen.

15
La rastreabilidad es muy importante en el desarrollo de sistemas porque a medida que
el mismo tiene cambios a lo largo de su ciclo de vida necesitamos saber siempre
dónde se deben hacer los cambios en el código fuente.

El modelo de diseño es una abstracción de cómo el sistema se construye realmente y

nos permite reducir la complejidad del mismo.
El diseño es la última parte de la iteración de elaboración y es quien comienza la de
construcción. Con ésto apuntamos a obtener una arquitectura estable y sólida,
sentando la base para el modelo de implementación.

A continuación detallamos los artefactos fundamentales que se utilizan en el modelo

de diseño, posteriormente vemos qué trabajadores se encargan de cada artefacto, y por
último relacionamos estos dos conceptos para comprender cuál es el orden de
utilización de cada artefacto a través del flujo de trabajo.

2 Artefactos
2.1 Modelo de diseño

Es un modelo de objetos representando la realización física de los casos de uso.

Recordemos que ahora tenemos en cuenta tanto los requisitos funcionales modelados
en el análisis como también los no funcionales. Servirá como alimentación para todo
lo referido a implementación.
Empezamos a ver ahora los distintos artefactos de este modelo.

2.2 Clases de diseño

Son abstracciones de clases de implementación. Hay muchas características de las

clases que tienen una relación directa con el lenguaje que elijamos para programación,
por lo cual es necesario que a esta altura ya tengamos definido qué lenguaje utilizar.
Ésto también nos ahorrará el trabajo de tener que redefinir muchas cosas en la
implementación.
En este momento tenemos que definir para cada clase sus métodos, atributos,
parámetros, tipos, visibilidad de los atributos (públicos, protegidos, privados, amigos).

2.3 Realización de casos de uso - diseño

Una realización de caso de uso - diseño tiene vinculación directa con realizaciones de
caso de uso - análisis, y recordemos que éstos tienen relación con casos de uso del
modelo de casos de uso. Con ésto trazamos relaciones de rastreabilidad de punta a
punta atravesando los distintos modelos.

En las realizaciones de diseño se tienen en cuenta también los distintos requerimientos

no funcionales que fuimos recolectando en las realizaciones anteriores.
Estas realizaciones poseen:
 descripción textual del flujo de eventos,

16
  diagramas de clases,
 diagramas de interacción.

Diagramas de clases

Las clases y los subsistemas que las contienen pueden intervenir en más de una
realización de casos de uso. A través de estos diagramas podremos analizar la relación
con los distintos casos de uso de diseño y de esta forma tener registrado qué clases
intervienen en las realizaciones de los distintos casos de uso.

Diagramas de interacción

En el caso del diseño utilizamos diagramas de secuencia. En ellos las interacciones

entre objetos se representan mediante la transferencia de mensajes entre dichos
objetos.
Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en
secuencia temporal, los objetos que se encuentran en el escenario y la secuencia de
mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita
por el escenario.

Los diagramas de secuencia, formalmente diagramas de traza de eventos o de

interacción de objetos, se utilizan con frecuencia para validar los casos de uso.
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 a grosso modo
cuánto tiempo consume el método invocado. Estos diagramas nos ayudan a
comprender los cuellos de botella potenciales para poder eliminarlos. A la hora de
documentarlos resulta importante mantener los enlaces de los mensajes a los métodos
apropiados del diagrama de clases.

En la siguiente figura tenemos un ejemplo de diagrama de secuencia:

17
Este diagrama da detalle al caso de uso denominado Pedir producto de una máquina
de café. Los conceptos más importantes relacionados con los diagramas de secuencia
son:

 línea de vida de un objeto (lifeline): la línea de vida de un objeto representa

la vida del objeto durante la interacción. En un diagrama de secuencia 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. Por ejemplo, el objeto m, instancia de la clase
MáquinaCafe envía dos mensajes seguidos para dar respuesta a la operación
PedirProducto: Servir al objeto p de la clase Producto y DarVueltas a sí
mismo (self-delegation).

 activación: muestra el período de tiempo en el cual el objeto se encuentra

desarrollando alguna operación, bien sea por sí mismo o por medio de
delegación a alguno de sus atributos. Se denota como un rectángulo delgado
sobre la línea de vida del objeto. En el ejemplo anterior el objeto
_Ingredientes se encuentra activo mientras ejecuta el método correspondiente
al mensaje Servir, el objeto p se encuentra activo mientras se ejecuta su
método Servir, que ejecuta _Ingredientes.Servir, y el objeto m se encuentra
activo mientras se ejecuta p.servir y DarVueltas.

 mensaje: el envío de mensajes entre objetos se denota mediante una línea

sólida dirigida desde el objeto que emite el mensaje hacia el objeto que lo
ejecuta. En el ejemplo anterior el objeto m envía el mensaje Servir al objeto
p, y un poco más adelante en el tiempo el objeto m se envía a sí mismo el
mensaje DarVueltas.

 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. Analizando la recepción de una llamada telefónica puede
tenerse un diagrama como el siguiente.

18
En este diagrama se tienen tres objetos concurrentes: el que hace la llamada, la central
telefónica y el que recibe la llamada. Se nombran los tiempos de los mensajes que
envía o recibe caller -a para descolgar, b para el tono de la llamada, c para la
marcación, d para el inicio del enrutamiento de la llamada, d' para la finalización del
enrutamiento-. Estos nombres o tiempos de transición permiten describir restricciones
de tiempo, por ejemplo, b-a < 1 sec o demoras entre el envío y la recepción entre d y
d'.

2.4 Subsistema de diseño

Nos permite organizar y agrupar las clases de diseño de acuerdo a su funcionalidad, lo

cual hará mucho más manejable el modelo.
Podemos trazar una relación entre los paquetes de análisis con estos subsistemas. Es
importante, como explicamos para los paquetes de análisis, que exista una
independencia entre los distintos subsistemas, ésto será fundamental para lograr la
reutilización de subsistemas y también a la hora de realizar modificaciones, ya que al
ser subsistemas independientes los cambios en uno no afectarán a los cambios en otro,
salvo que modifiquemos las formas en que los subsistemas -para ser más explícito, las
clases de éstos- modifiquen las interfaces de relación entre unas y otras.

Subsistema de servicio: tiene una relación uno a uno con los paquetes de servicio del
modelo de análisis y cumple la misma función que éstos, es decir, preparar el sistema

19
 para cambios de servicios individuales. Éstos pueden manejar muchos requisitos no
funcionales, cosa que no hacían los paquetes de servicio.

Teniendo como base el modelo de casos de uso que hemos analizado en unidades
anteriores consideramos el caso de uso “Comprar productos” y analizamos el
diagrama de clases de diseño y sus subsistemas.

Caso de uso “Comprar productos”: Diagrama de clases de diseño y subsistemas

Clases persistentes
Interfaces

Transacciones
Datos de
Pantalla terminal
Compra

Teclado
Interfaces

Manejador
Lectora cód Manejador Manejador clases
de barra cliente de compra persistentes
Transferencias
Cajero
Impresora
Productos

Compra
Movimientos

2.5 Interfaz

A través de las interfaces se especifican las distintas operaciones que pueden ser
realizadas por una determinada clase o por los diferentes subsistemas. Representan la
cara visible de la funcionalidad de una clase.
Es importante que cuanto antes se definan todas las interfaces de las diferentes clases
de cada subsistema. De esta forma podemos comenzar a establecer las relaciones
entre clases de manera estable y segura.
Por ejemplo, si luego de definir una interfaz necesitamos modificar funcionalidad
interna de esta clase sin afectar su interfaz, no será necesario realizar ningún cambio
sobre las clases que la utilizaban, en caso contrario, es decir si cambiamos la
funcionalidad y también la interfaz, ahora sí será necesario realizar algún retoque en
las clases relacionadas.
Dentro de una determinada clase, sus atributos y métodos conformarán la interfaz de
dicha clase. En el caso, por ejemplo, que cambiemos el código de un método pero no
cambiemos ni su nombre, tipo y parámetros, sólo habremos cambiado funcionalidad y

20
no su interfaz, por lo cual las clases relacionadas a ésta no deberán sufrir ninguna
modificación.
Ahora, si por ejemplo agregamos parámetros o cambiamos el tipo, en este caso sí
debemos cambiar la forma en que estas clases se relacionaban.

Para un subsistema su interfaz estará constituida por las interfaces de las clases que
conforman a éste.

Mencione un ejemplo de clases y métodos y defina cuáles son sus interfaces. Plantee
dos cambios a ésta, uno que afecte su interfaz y otro que no.

2.6 Descripción de la arquitectura

Ésta contiene una vista de la arquitectura del modelo de diseño. 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,
 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.

2.7 Modelo de despliegue

Este modelo nos permite representar cómo será la distribución física del sistema. Es
decir, dónde residirá físicamente cada uno de los componentes del sistema, clases de
interfaz, de control, de entidad. Las ubicaciones físicas se denominan nodos. Existen
relaciones entre ellos representadas por medios de comunicación, que pueden ser:
internet, extranet, intranet.

Tenemos nodos que contienen los componentes asociados con todo lo referido a
interfaces entre el sistema y sus actores, por ejemplo, donde residen las distintas
pantallas de la aplicación.
Existen también nodos que contienen todas las clases de control. Más adelante
veremos que todos éstos constituyen lo que se denomina reglas de negocio. Éstas
residen en los servidores de aplicación.
También veremos nodos donde estarán las clases de entidad que luego constituirán los
repositorios de datos de nuestra aplicación, éstos se denominan Bases de Datos, y
como usted ya ha visto en Informática III en la mayoría de los casos se utilizan
DBMS.

Para plasmar todo ésto utilizamos una vista de la arquitectura, pero ahora teniendo en
cuenta este modelo de despliegue.

21
3 Trabajadores

3.1 Arquitecto

Tal como expresamos para el modelo de análisis, este profesional es el responsable de

asegurar que el modelo de diseño y de despliegue se correspondan correctamente con
lo definido en el modelo de casos de uso y en el de análisis. Cuida que sea consistente
y que esté todo lo significativo para la arquitectura del modelo.

3.2 Ingeniero de casos de uso

Tal como definimos para el modelo de análisis, es el encargado de asegurar que las
realizaciones de casos de uso de diseño lleven un comportamiento acorde a las
realizaciones de casos de uso del modelo de casos de uso y del modelo de análisis.
Cuida todos 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.

3.3 Ingeniero de componentes

Se encarga 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. En el caso de los subsistemas define cómo
están compuestos (clases), qué relaciones existen con otros subsistemas y de qué
forma se relacionan con los otros subsistemas (interfaces)

4 Flujo de trabajo
El siguiente diagrama define en forma dinámica cómo es la relación entre los
trabajadores y los artefactos.

22
 Fuente: Jacobson, Ivar. Booch, Grady. Rumbaugh, James. El Proceso Unificado de Desarrollo del
Software. Ed. Addison Wesley. Madrid, 2000.

4.1 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

Como ya mencionamos, el diagrama de despliegue representa la distribución física de

los distintos componentes que intervienen en una aplicación.
Haciendo un poco de historia podemos mencionar cómo han ido evolucionando las
arquitecturas de las aplicaciones de software.
Antes de comentar este tema es importante que usted tenga bien en claro que toda
aplicación está compuesta por tres capas, una encargada de todo lo referido a interfaz
con el usuario, otra de almacenamiento de información y una capa intermedia
encargada de procesar las reglas y lógica del negocio en cuestión. Estas tres capas
pueden tener una división tanto lógica como física:
 división lógica se refiere a que en la aplicación se encuentran muy bien
divididas las tres funcionalidades de estas capas,
 división física quiere decir que estas capas pueden residir en nodos diferentes.

Las primeras aplicaciones que existieron, que trabajaban en grandes mainframes,

manejaban estas tres capas todas juntas, tanto física como lógicamente, todo el
procesamiento se realizaba en ese gran servidor y los usuarios accedían a estas
aplicaciones a través de "terminales bobas" cuya única función era la de emular
pantalla y teclado de estos grandes mainframes.

23
Luego comenzaron a aparecer aplicaciones partidas lógicamente en dos capas,
pudiendo estar o no también divididas físicamente. Una de las capas reside en un
servidor y la otra se ejecuta en los clientes. Este modelo recibe el nombre de 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).
Además de almacenar la información a través de procedimientos almacenados,
triggers y chequeos de integridad, realizaba también todas las tareas de reglas
de negocio. Los clientes cumplen sólo la función de capa de interfaz, tomando
la información que los usuarios ingresan al sistema, enviando ésto 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, tenemos aquellas aplicaciones partidas lógicamente en tres capas y como
dijimos en el caso anterior 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. Entre las distintas ventajas que tenemos con este modelo 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. Y antes de hacer referencia a
lo que ocurriría con la capa de interfaz vamos a mencionar 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.
Hechas en lenguajes como Visual Basic utilizando el modelo de objetos de
ASP -Active Server Pages- o con Java o con alguna de sus variantes.
Ahora, 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.

Ahora, luego de esta reseña, cabe mencionar que 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

¿Recuerda cuál era el objetivo de los subsistemas?

Organizar el modelo de diseño, en este caso, en piezas manejables.

A partir de los paquetes de análisis y los paquetes de servicios que ya definimos

debemos identificar los subsistemas que existen. Hay que tener en cuenta que pueden

24
existir subsistemas que encapsulen funcionalidad provista por productos de terceros y
que tal vez no hayan sido identificados aún en el modelo de análisis. Estos
subsistemas también deben ser incorporados en los distintos modelos ya que estarán
interactuando con los subsistemas desarrollados por nosotros.
Es importante que vayamos examinando los subsistemas de acuerdo a la distribución
que tendrán éstos en los distintos nodos de la aplicación. Debemos analizar también la
relación entre subsistemas y capas que tendrá nuestra aplicación. Recordemos el
concepto de división lógica en tres capas que ya mencionamos.
Es importante estudiar la relación que existirá entre los distintos subsistemas.

¿Cómo nos podemos ayudar para ésto?

Teniendo en cuenta las relaciones que ya definimos para los paquetes de análisis y de
servicios en el modelo de análisis.

Las relaciones entre subsistemas se verán luego reflejadas por las conexiones que
existan entre las clases de cada uno y las relaciones entre clases, que como usted ya
sabrá, se reflejan a través de las interfaces. Es decir, si la clase de un subsistema
interactúa con una clase de otro sistema, se definirá una relación entre éstos. Debemos
también definir la manera en que esas clases se relacionan, es decir, las interfaces que
permiten que una clase sea accedida. Por ejemplo los métodos que ésta expone hacia
afuera para que sean invocados por otras clases.

c) Clases de diseño relevantes para la arquitectura

Es importante en este punto que detallemos las clases que hay que tener en cuenta
para la arquitectura. Tendremos como entradas aquellas clases del análisis que
definimos importantes para la arquitectura, podrán aparecer algunas nuevas propias
del diseño y que en modelos anteriores fueron dejadas para analizar en esta etapa.
Pero tiene que quedar claro que no debemos analizar un gran número de clases ni
bajar en un nivel de detalle extremo en este momento, sólo analizar las relevantes para
la arquitectura. El análisis más fino de éstas y de todas las otras 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 su análisis hasta tener mejor definidas las características mas
técnicas asociadas con el proyecto, como por ejemplo la plataforma que utilizamos
para correr cada una de las capas de la aplicación, mecanismos de comunicación entre
objetos remotos, lenguajes de programación y Bases de Datos.
Estos requisitos especiales 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).

25
4.2 Diseño de un caso de uso
Éste tiene como objetivos:

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 recogemos todas las clases del diseño que
intervienen en el mismo 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 ésto y al resto de la información recabada hasta el momento para dicho caso de
uso 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

En este momento definimos exactamente cómo interactúan las distintas clases que
intervienen en cada realización de caso de uso. Utilizamos diagramas de secuencia,
que contienen instancias de actores, los objetos del diseño y las transmisiones de
mensajes entre éstos.
Transformamos el diagrama de colaboración de la realización de caso de uso - análisis
en un esbozo inicial del correspondiente diagrama de secuencia.
Se comienza el flujo del caso de uso con un mensaje de un actor hacia un objeto y de
ahí se continúa haciendo interactuar a los distintos objetos y actores del caso de uso
siguiendo el flujo real del caso de uso.
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

Sí, como usted está pensando, tomaremos 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 ésto delinearemos los distintos subsistemas de diseño que intervendrán
en nuestro sistema. Utilizamos un diagrama con el que ya estamos familiarizados para
reflejar los distintos subsistemas, las interfaces de éstos y las dependencias que
existan entre los mismos, éste es el diagrama de clases.

d) Interacciones entre subsistemas

Ahora, para detectar las interacciones que existen entre los distintos subsistemas
utilizamos diagramas de secuencia. Quedan así reflejadas las relaciones entre actores
y subsistemas a través del envío de mensajes entre los mismos. Recuerde que en el

26
modelo de análisis ya establecimos relaciones entre paquetes, lo cual nos ayudará
junto con los modelos de casos de uso para el armado de estos diagramas.

4.3 Diseño de una clase

A esta altura ya debemos tener en claro cuál será el rol exacto de cada clase dentro de
las distintas realizaciones de casos de uso. Trazamos relación con las clases
detectadas en el modelo de análisis.

Pasemos a analizar para cada una de ellas:

a) operaciones,
b) atributos,
c) relaciones,
d) métodos,
e) estados.

En el caso de clases de entidad el análisis de éstas suele variar un poco, ya que

dependerá de la base de datos que vaya a utilizar, por ejemplo, BD orientada a
objetos, BD relacional, BD documental. De acuerdo a lo que usted aprendió en
Informática III, a esta altura y una vez que ya tiene muy bien detectadas todas las
clases de entidad que existen, usted ya está en condiciones de normalizar su base de
datos y generar la estructura de almacenamiento que utilizará la aplicación.

En cuanto a las clases de interfaz el diseño de las mismas estará muy ligado al
lenguaje de programación que utilicemos para implementarlas. La funcionalidad es la
misma, pero de acuerdo al lenguaje y a la tecnología que definamos para la interfaz
(Windows, Web, monocapa, cliente-Servidor, n-capas) será la forma de diseñarla y
posteriormente implementarla. No es lo mismo diseñar una aplicación en Visual Basic
para Windows que una aplicación Java para Web, ya que los objetos y dónde residen
y se ejecuta cada uno de éstos es muy diferente.
Hoy por suerte hay tecnologías que independizan en gran parte de toda esta
problemática, así nos podemos ocupar realmente de la tarea del analista, diseñador y
programador sin tener que renegar tanto en lo que hace a problemas de los lenguajes y
de las plataformas donde nuestras aplicaciones se ejecutan. Un ejemplo es Visual
Studio .NET, que junto al Marco de Trabajo .NET (o .NET Framework) nos aíslan de
todas estas problemáticas permitiéndonos muy fácilmente, y utilizando prácticamente
tecnologías similares, desarrollar aplicaciones Windows, Web, pudiendo utilizar una
gran variedad de lenguajes de programación. La base de todo ésto gira alrededor de
que los distintos lenguajes utilizan todos los objetos comunes que nos brinda este
“Marco de Trabajo .NET” sin perder las sintaxis propia de cada lenguaje, pero de
alguna forma nuestra arquitectura de objetos se mantiene tanto para unos lenguajes
como para otros.

Pasemos ahora a ver las características propias de las clases, como ya dijimos,
fundamentalmente las de control.

a) Operaciones

27
Las responsabilidades detectadas en las clases de análisis implican una o varias
operaciones para las clases de diseño. Éstas 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

Ahora 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 ésto 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 ésto por la duplicidad de funcionalidades y características
en aquellos objetos comunes, como ya hemos visto.

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. No es necesario que bajemos en mucho nivel de detalle ya que la
definición de métodos es una tarea de la implementación. También debemos tener en
cuenta la utilización de herramientas generadoras de código, ya que a través de ellas
podemos, en la misma herramienta donde estemos haciendo el diseño, dejar reflejados
los métodos y a través de un botón generar automáticamente todos los métodos con
toda su cáscara (nombre, argumentos, tipo) y hasta en muchos casos con todo su
código en el lenguaje de programación que seleccionemos.

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

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

Se marcan también los estados iniciales y finales mediante los símbolos y ,

respectivamente.

Eventos
Es una ocurrencia que puede causar la transición de un objeto de un estado a otro.
Esta ocurrencia puede ser una de varias cosas:
 condición que toma el valor verdadero o falso,
 recepción de una señal de otro objeto en el modelo,
 recepción de un mensaje,
 paso de cierto periodo de tiempo después de entrar al estado o de cierta hora y
fecha particular.

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
Además de mostrar transición de estados por medio de eventos puede representarse el
momento en el cual se envían mensajes a otros objetos. Ésto se realiza mediante una
línea punteada dirigida al diagrama de estados del objeto receptor del mensaje. Si
tomamos como ejemplo un control remoto que envía órdenes de encender o apagar al
televisor o a la videograbadora es posible obtener un diagrama de estados como el
siguiente:

29
Los tres aparatos tienen diagramas de estados separados y algunas de las transiciones
del control remoto causan el envío de mensajes (togglePower) a los otros aparatos.

Transición simple
Una transición simple es una relación entre dos estados que indica que un objeto en el
primer estado puede entrar al segundo estado y ejecutar ciertas operaciones cuando un
evento ocurre y si ciertas condiciones son satisfechas. Se representa como una línea
sólida entre dos estados que puede venir acompañada de un texto.

Transición interna
Es una transición que permanece en el mismo estado en vez de involucrar dos estados
distintos. Representa un evento que no causa cambio de estado. Se denota como una
cadena adicional en el compartimiento de acciones del estado.

Transición compleja
Una transición compleja relaciona tres o más estados en una transición de múltiples
fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del
objeto o una sincronización. Se representa como una línea vertical de la cual salen o
entran varias líneas de transición de estado. En el ejemplo que sigue se muestra una
transición a dos threads concurrentes que luego se sincronizan.

30
4.4 Diseño de un subsistema

¿Recuerda la actividad de analizar un paquete del modelo de diseño?.

Bien, entonces tenga en mente la relación que hicimos entre paquetes y subsistemas
para ahora hacer el diseño de estos subsistemas. Los puntos clave a tener en cuenta
son:
 independencia entre subsistemas,
 mantener interfaces y sus operaciones,
 asegurar que el subsistema cumple con su objetivo en las distintas
realizaciones en las que esté involucrado.

5 Caso práctico de cierre

Ahora analizamos un ejemplo donde aplicamos cada uno de los diagramas que hemos
estudiado en ésta y en las unidades anteriores. Verá que hay notaciones graficas que
difieren en alguna forma a las vistas, ésto tiene como objeto que usted sepa que hay
herramientas de análisis y diseño que utilizan estas gráficas. En cada diagrama
encontrará un breve resumen de su objetivo.

El ejemplo en cuestión es un sistema de software para el alquiler de vehículos.

Este escenario trata cómo se deben utilizar los diagramas UML para modelar un
sistema de software de una agencia de alquiler de vehículos. Comenzando por tres
casos de uso sencillos los siguientes ejemplos muestran los procesos esenciales del
sistema.
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. Un sistema de software normal podría incluir cientos de
casos de uso sencillos. Algunos casos de uso que pueden aplicarse al sistema de la
agencia de alquiler son:

 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

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

En la siguiente imagen se muestra el diagrama de estos tres casos de uso.

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.

En un diagrama de clases los objetos que forman parte del sistema de alquiler de
vehículos se agrupan en clases y cada una de éstas contiene una sección de nombre y
otra de atributos. Algunas clases también incluyen una sección de operaciones que
especifica cómo se deben comportar los objetos de dicha clase.

En la clase Cliente los atributos incluyen no sólo el nombre, el número de teléfono, el

número del carnet de conducir y la dirección, sino también la fecha de nacimiento
necesaria para determinar que el cliente cumple con el requisito de mayoría de edad
indispensable para alquilar un vehículo. La clase Cliente también almacena
operaciones como las reservas.

32
Los diagramas de clases admiten la herencia. En la siguiente figura, por ejemplo, las
clases Mecánico y Agente de alquiler heredan atributos tales como el nombre y la
dirección de la clase Empleado.

Diagrama de secuencia

Recuerde que los diagramas 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. En un sistema de software
amplio el diagrama de secuencia puede incluir un mayor número de detalles y
contener miles de mensajes.

Imaginemos que un cliente desea realizar la reserva de un vehículo. El agente de

alquiler debe primero comprobar el registro del cliente para asegurarse de que éste
puede llevar a cabo esta operación. Si el cliente ha alquilado previamente un vehículo
de la compañía su historial estará registrado y el agente sólo tendrá que asegurarse
que las anteriores transacciones se realizaron sin problemas. Por ejemplo, el agente
puede confirmar que los vehículos alquilados anteriormente se devolvieron en el
plazo previsto. Luego, una vez aprobado el estado de alquiler del cliente el agente
puede aprobar la reserva del alquiler del vehículo. Este proceso se puede representar
en un diagrama de secuencia, tal como se muestra en la siguiente figura.

33
Diagrama de colaboración

Los diagramas de colaboración constituyen otro tipo de diagrama de interacción. Al

igual que los diagramas de secuencia 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.

Diagrama de estados

34
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. Por
ejemplo, en nuestro sistema de alquiler el objeto es un vehículo. A medida que el
vehículo va pasando por las diferentes fases del sistema de alquiler los distintos
estados crean un complejo pero esclarecedor diagrama. Por ejemplo, el auto se agrega
en primer lugar a la flota y permanece en el estado En stock hasta que se alquila.
Luego, una vez alquilado, el vehículo vuelve a la flota y al estado En stock.
En varios momentos del ciclo de vida comercial el vehículo precisará que se realicen
reparaciones (En reparación). Cuando el vehículo no puede ser usado se vende o se
desguaza para dejar cabida a uno nuevo.

Diagrama de actividades

Los diagramas de actividades muestran la lógica que tiene lugar como respuesta a las
acciones generadas internamente. Este tipo de diagrama 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.

35
Diagrama de despliegue

Los diagramas de despliegue muestran cómo están configurados el hardware y el

software del sistema. La agencia de alquiler necesita un sistema cliente/servidor con
una base de datos central de registros a la que pueda tener acceso el personal. Los
agentes de alquiler deben tener acceso a los datos sobre la disponibilidad del vehículo.
Mientras tanto, los mecánicos necesitan indicar que un determinado vehículo se
encuentra en el estado En reparación.

Diagrama de componentes

No hemos visto en detalle este tipo de diagrama, ya que corresponden al modelo de

implementación, pero lo mostramos para cerrar el ciclo de diagramas. Éstos 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

36
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. Los subsistemas
de software de este ejemplo incluyen Registros de vehículos, Registros de servicios,
Registros de ventas, Registro del cliente y Registro del empleado.

37
 Versión 2006

Informática IV

Unidad 2

Implementación
Unidad 2: Implementación

Autor/es
Jiménez, José Luis

Orientación del aprendizaje

Hasta el momento usted aprendió y desarrolló actividades de los flujos fundamentales de trabajo:
requisitos, análisis y diseño del proceso unificado de desarrollo (PUD). Lo que haremos ahora es
tomar los resultados del diseño y convertirlos en un software ejecutable; un sistema que integra
componentes expresados en archivos fuentes, ejecutables, código binario y similares dándole com-
portamiento concreto al modelo.

En esta unidad desarrollamos el Flujo de Trabajo Implementación (FTI). Al igual que en los flujos
anteriores le mostraremos el propósito, las actividades, los artefactos, conceptos principales y
roles que son propios de esta disciplina.

En el cuadro siguiente, ya conocido por usted, se muestra esquemáticamente el PUD completo,

podrá descubrir la información de contexto que necesita para saber exactamente dónde estamos
parados y hacia dónde vamos

Tal como puede ver en la figura anterior, la implementación es el proceso protagonista durante las
iteraciones de la fase de construcción. Observe que también se desarrolla trabajo de implementa-
ció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.

38
Desde esta perspectiva, los contenidos que trabajamos en esta unidad son:

1. Propósito de la implementación...................................................................................................41
2. Conceptos preliminares.................................................................................................................41
2.1. Implementar el diseño............................................................................................................41
2.2. Las pruebas de desarrollo.......................................................................................................42
2.3. Entornos de desarrollo e integración......................................................................................42
2.4. Entorno de desarrollo individual............................................................................................43
2.5. Entorno de integración de subsistemas ..................................................................................43
2.6. Entorno de integración del sistema total................................................................................43
3. El flujo de trabajo implementación..............................................................................................44
3.1. Estructurar el modelo de implementación ............................................................................45
3.2. Planear la integración.............................................................................................................47
3.3. Implementar componentes .....................................................................................................47
3.4. Integrar cada Subsistema .......................................................................................................48
3.5. Integrar el sistema ..................................................................................................................49
4. Actividades ...................................................................................................................................50
4.1. Estructurar el modelo de implementación ............................................................................51
4.2. Planear la integración del sistema.........................................................................................54
4.3 Implementar componente.......................................................................................................56
4.4 Ejecución de pruebas unitarias................................................................................................58
4.5 Corregir defectos.....................................................................................................................60
5. Artefactos......................................................................................................................................61
5.1 Modelo de implementación.....................................................................................................61
5.2 Construcción ...........................................................................................................................61
5.3 Componente ............................................................................................................................62
5.4 Stubs........................................................................................................................................62
5.5. Subsistema de implementación..............................................................................................63
5.6 Interfases .................................................................................................................................64
5.7. La vista del modelo implementación .....................................................................................64
6. Trabajadores..................................................................................................................................65
6.1 Arquitecto de Software ...........................................................................................................65
6.2 Implementador ........................................................................................................................66
6.3 Integrador de Sistemas............................................................................................................67

A partir del análisis y del recorrido propuesto esperamos que logre los siguientes objetivos:
 Planificar en pasos pequeños y manejables (enfoque incremental) las integraciones de sis-
tema 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, ar-
chivos 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.

¿Cómo estudiar esta unidad?

39
Esta unidad es autocontenida. Aquí encontrará toda la información básica para luego continuar con
el desarrollo de los siguientes temas. Le sugerimos que reflexione sobre cada punto a tratar y reali-
ce las actividades propuestas.
Asimismo, existe en el mercado una serie de textos valiosos que podrá consultar.

Bibliografía recomendada

 JACOBSON, Ivar. El Proceso Unificado de Desarrollo. Editorial Addison Wesley. Espa-

ña. 2000.

 WEITZENFELD, Alfredo. Ingeniería de Software orientada a Objetos con UML, Java e

Internet.. Ed. Thomson. México, 2004.

 PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico. Quinta edición. Edito-
rial Mc Graw Hill. España. 2002.

 LARMAN, Craig. UML y Patrones. Primera edición. Editorial Prentice Hall, Inc. México.
1999.

 BOOCH, Grady. Análisis y Diseño orientado a objetos con aplicaciones. Segunda edi-
ción. Editorial Addison Wesley/Díaz de Santos. USA. 1996.

40
1. Propósito de la implementación
La mayor parte de la arquitectura del sistema es delineada durante el diseño, siendo el propósito
principal del FTI el desarrollo de la arquitectura y el sistema como un todo. Más explícitamente los
propósitos de este flujo de trabajo son los siguientes:

 Planificar en pasos pequeños y manejables (enfoque incremental) las integraciones de sis-

tema 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, ar-

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

 Tal como se ha dicho varias veces, 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 prima-
ria 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. Conceptos preliminares

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. Por ejemplo, en los lenguajes orientados a objetos tal
como C++ y Java, una clase del diseño puede corresponder a una o varias clases. En Visual Basic,
en cambio una clase de diseño corresponde a un componente de un tipo específico. Por ejemplo,
módulo de clase, una pantalla, o un control de ésta. En Ada, una clase de diseño corresponde a uno
o varios tipos definidos en un paquete Ada.

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

41
elegido. Por ejemplo, podría definir una relación 1:1 (uno a uno) para las clases de diseño y las de
implementación, lo cual resultará en un Modelo de Implementación con una gran trazabilidad hacia
el modelo de diseño, y viceversa. Esto es apropiado y beneficioso para el entorno del proceso de
desarrollo.

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. Verá también, más adelante, como la organización de los equipos de desarrolladores o progra-
madores puede condicionar la estructura de implementación.

Cada lenguaje de programación puede ofrecer sus propias características, lo cual invalida la posibi-
lidad de determinar un esquema de procesos (frame) generalizado. Es factible, sin embargo, acor-
dar uno lo suficientemente amplio para ser utilizado por cualquier lenguaje orientado a objetos.
Será su responsabilidad dentro de cada proyecto en particular ajustar este marco de trabajo al len-
guaje de programación específico que haya elegido y a la organización del equipo de trabajo.

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.

Esta categorización es correcta, sin embargo el problema surge cuando se decide integrar los sub-
sistemas 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 pro-
pagarse 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 cos-
tos y oportunidad de entrega del producto final.
No espere terminar todos los componentes para integrar subsistemas y el sistema final. Lo que se-
ría peor aún, no deje las pruebas de componentes para el final de la fase de construcción, recuer-
de... este es un método iterativo e incremental. 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.
Esto le permitirá mitigar riesgos asociados al presupuesto y cronograma y mejor aún mejorar la
calidad del producto final.

2.3. Entornos de desarrollo e integración

Un sistema generalmente es implementado por equipos de desarrolladores o programadores indivi-

duales 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,

 Un entorno de integración de subsistemas para el grupo de desarrollo,
 Un entorno de integración del sistema total.

42
2.4. Entorno de desarrollo individual

A los efectos de editar, compilar, link editar -sólo cuando el lenguaje utilizado no es interpretado
en tiempo de ejecución como Java-, ejecutar y probar todos los componentes y el subsistema asig-
nado, cada programador tendrá un entorno de trabajo individual. No es necesario que en este espa-
cio 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.

Ejemplo: el subsistema de atención a clientes a través de la web de un sistema bancario, necesita

de otros subsistemas desde los cuales importa directa o indirectamente elementos para ejecutar
componentes. En este caso, seis de los diez subsistemas serán necesarios para los implementadores
del subsistema de atención vía web.

Banca Banca Cajero Banca

Telefónica Web Automático Web

Prestamos Administ. Servicios Administ.

De Comercia- De
Cuentas les Cuentas

Admin. admin. Admin. admin.

Interface RDBMS Interface RDBMS

Sistema Comunic. Sistema Comunic.

Operativo Externas Operativo Externas

Modelo de implementación Espacio de desarrollo individual

2.5. Entorno de integración de subsistemas

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.

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

43
 Incremento N º1 Incremento N º2 Incremento N º3

Aplicaciones

Reglas de
negocio

Middleware

Software de
base del sistema

El ejemplo muestra un espacio de integración donde subsistemas de distintas capas son agregados
en cada incremento de integración.

3. El flujo de trabajo implementación

44
 Flujo de trabajo implementación

Como puede observar en este diagrama de actividad, estructurar el Modelo de Implementación es

la primer actividad desarrollada en el marco de la Implementación. Tal como mostramos en la figu-
ra 1 los flujos: requerimientos, análisis y diseño ocurren con preeminencia en la Fase de Elabora-
ción. No obstante note que también en esa etapa comenzamos a dar forma al Modelo de Implemen-
tació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
protagonismo las de: Estructuración del Modelo de Implementación, Planeamiento de la Integra-
ción, Implementación de Componentes, Integración de los Subsistemas y el Sistema como un to-
do.

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.

45
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. No considerar tempranamente esta actividad podría resultar en
una pobre organización de la implementación y ensamblado de componentes. Un hecho de ocu-
rrencia muy probable cuando este modelo está mal organizado o lo que es peor: no se ha definido,
impedirá el desarrollo en paralelo del software por parte de los miembros del equipo de trabajo.

En la figura siguiente se muestran esquemáticamente los actores, procesos y documentos utilizados

en esta actividad:

46
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 para el caso de siste-
mas grandes o complejos. 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 como podría ser el
‘make’ del sistema operativo unix.

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 obsole-
to, este debe ser actualizado cada vez que sucedan modificaciones en la arquitectura y el diseño.

En la figura siguiente se muestran esquemáticamente los actores, procesos y documentos utilizados

en esta actividad:

3.3. Implementar componentes

Los implementadores – programadores / desarrolladores - escriben código fuente, adaptan código

existente, compilan, link editan y ejecutan pruebas de unidad de componentes, generando re trabajo
para el diseñador en caso de detectarse errores atribuibles al mismo.

47
Los implementadores también corrigen defectos y vuelven a ejecutar pruebas de unidad para veri-
ficar 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 ajustados a los requerimientos y libres de errores.

Trabajadores

La actividad de programación normalmente es desarrollada por una persona, sin embargo propues-
tas metodológicas actuales como XP –Xtreme Programming- están proponiendo que la codifica-
ción de cada componente sea realizada de a pares de programadores. Es bueno 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 per-
sonas que podrían incluir miembros del área usuaria y programadores experimentados. Este traba-
jo 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 sesio-
nes se identifican los problemas específicos que necesitan ser resueltos. Las correcciones se im-
plementan al terminar la revisión.
En la figura siguiente se muestran esquemáticamente los actores, procesos y documentos utilizados
en esta actividad:

3.4. Integrar cada Subsistema

Si más de un implementador – programador / desarrollador – 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.
48
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 – un miembro del equi-
po de desarrollo - o un pequeño equipo para el caso de sistemas grandes o complejos. Los integra-
dores 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 programa-
ción sobre el cual se desarrollaran los componentes. Debido a que a menudo la integración se desa-
rrolla con un alto grado de automatización, se requiere también conocimientos en sistemas operati-
vos, interpretes de comandos y herramientas como podría ser el ‘make’ del sistema operativo unix.

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.

En la figura siguiente se muestran esquemáticamente los actores, procesos y documentos utilizados

en esta actividad:

3.5. Integrar el sistema

Siguiendo el plan de integración de construcciones se agrega e integra cada subsistema en el entor-

no de trabajo del sistema descrito en el punto 3.5. 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:

 Integrar subsistemas de implementación para crear una nueva versión consistente del siste-
ma total.

49
Trabajadores

La integración de cada subsistema es hecha habitualmente por una persona – un miembro del equi-
po de desarrollo - o un pequeño equipo para el caso de sistemas grandes o complejos. Los integra-
dores 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 programa-
ción sobre el cual se desarrollaran los componentes. Debido a que a menudo la integración se desa-
rrolla con un alto grado de automatización, se requiere también conocimientos en sistemas operati-
vos, interpretes de comandos y herramientas como podría ser el ‘make’ del sistema operativo unix.

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.

En la figura siguiente se muestran esquemáticamente los actores, procesos y documentos utilizados

en esta actividad:

4. Actividades
En este punto desarrollaremos con mayor nivel de detalle, describiendo paso a paso, las actividades
presentadas en el punto 3.

En la figura siguiente, y con el ánimo de dar una visión general sobre el desarrollo del punto 4,
aparecen algunas de las actividades que abordaremos. Tenga presente que en este punto lo que
hacemos es desarrollar con más detalle las actividades mencionadas en los flujos de trabajo vistos
en el punto 3. Notará también que de todas las actividades, por cuestiones de alcance y significa-
ción, se han escogido para desarrollar aquellas que a nuestro juicio son fundamentales para su do-
minio. Tanto para profundizar como para obtener más información sobre las actividades expuestas
le sugiero visitar el sitio www.rational.net/rupcenter.

50
4.1. Estructurar el modelo de implementación

El propósito de esta actividad desarrollada por el arquitecto de software es establecer la arquitectu-

ra en la que se apoyará la implementación y la asignación de responsabilidades para subsistemas de
implementación y sus respectivos componentes.

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. Por ejemplo, en los lenguajes
orientados a objetos tal como C++ y Java, una clase del diseño puede corresponder a una o varias
clases. En Visual Basic, una clase de diseño corresponde a un componente de un tipo específico.
Por ejemplo, módulo de clase, un “form” – pantalla o interfase - o un “control”. En Ada, una clase
de diseño corresponde a uno o varios tipos definidos en un paquete Ada.

Así, el Modelo de Diseño puede ser más o menos ajustado al Modelo de Implementación depen-
diendo de cómo haga corresponder las clases o construcciones similares en el lenguaje de imple-
mentación elegido. Por ejemplo, en una primera iteración, podría definir una relación 1:1 (uno a
uno) para las clases de diseño y las de implementación. Esto resultará en un Modelo de Implemen-
tación con una gran trazabilidad hacia el Modelo de Diseño y viceversa, lo cual es apropiado y
beneficioso para el entorno del proceso de desarrollo.

Le mostramos a continuación un ejemplo de diagrama de componentes que podría representar la

estructura de un Modelo de Implementación de un sistema de cajero automático.

51
Ajustar los subsistemas de implementación

El propósito de este paso es adaptar la estructura del modelo de implementación a cuestiones tácti-
cas 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.

¿Cree usted qué si decidiera modificar la organización de los subsistemas en algún mo-
mento deberá decidir también volver al Modelo de Diseño para reflejar estos cambios o
permitiría que ambos difieran? Justifique su respuesta.

A continuación, algunos ejemplos de los aspectos tácticos referidos:

 Organización del equipo de desarrollo. La estructura de subsistemas debe permitir a va-

rios programadores trabajar en paralelo. Es recomendable que cada subsistema sea respon-
sabilidad de solo y solo un equipo de programación. Esto podría determinar la necesidad de
dividir un subsistema muy grande en dos o más subsistemas y asignar cada uno de ellos a
dos grupos de trabajo, aun si cada equipo de trabajo lo constituye un único programador.
También los ciclos de construcción y liberación de versiones propios de cada miembro de-
ben ser considerados a la hora de subdividir el trabajo.
 Declaraciones de tipos. En la implementación a menudo se necesita importar componentes
de otro subsistema. Típicamente, esto ocurre cuando utiliza lenguajes tipados como C++,
Java y Ada. En esta situación, y en general, puede ser una buena idea extraer las declara-
ciones de tipos en un subsistema separado.

Ejemplo

Extraemos algunas declaraciones de tipo del subsistema D para utilizarla en un subsistema

A con el objeto de mantener este mismo independiente de cambios en los componentes pú-
blicos (visibles) del subsistema D.

52
  Código existente y componentes reusables. Podría necesitar incorporar código existente
o una librería de componentes re usables. Habitualmente estos elementos no han sido mo-
delados en el Diseño y debe incluirlos en el Modelo de Implementación.
 Ajuste de dependencias. Asumamos que un subsistema A y un subsistema B dependen
mutuamente a los fines de importación de componentes. Sería bueno hacer a B menos de-
pendiente de los cambios en el Subsistema A. Para ello extraemos los componentes de A
que B importa y ponerlos en un nuevo subsistema A1 en una capa mas baja.

Los componentes son extraídos del subsistema A y colocados en un Nuevo subsistema A1.

Definir imports necesarios para cada subsistema

El objeto aquí es definir las dependencias y visibilidad de componentes entre subsistemas o módu-
los.

Para cada subsistema se define de que otros necesita importar o acceder componentes. Esto puede
ser hecho para grupos completos de subsistemas, permitiendo que cada uno de ellos en una capa
determinada pueda importar o acceder a otros subsistemas de una capa distinta. Generalmente, las
dependencias en el modelo de implementación son heredadas del modelo de Diseño, excepto cuan-
do la estructura del modelo de implementación ha sido ajustada como se mostró previamente.

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.

Como decimos en la jerga “Póngase el sombrero de arquitecto de software”, y en colaboración

con el responsable de administrar la configuración decida la estructura a ser aplicada en el modelo
de implementación, seleccionando para cada nodo los ejecutables y archivos auxiliares referidos
(binarios, dll, componentes de prueba, etc).

53
 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 recomenda-
ción es aislar estos componentes en una estructura de directorio o paquete, garantizando su visibili-
dad; 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. Podrá obtener un modelo (template)
de este documento en la mediateca de la materia.

4.2. Planear la integración del sistema

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.

En la figura siguiente se muestran subsistemas identificados a partir de la realización de casos de

uso.

54
Definir conjuntos de construcción

En sistemas grandes donde podrían implicarse hasta cientos de subsistemas de implementación

podría ser muy complejo manejar el plan de integración.

Para facilitar las cosas y manejar la complejidad podríamos reducir el número de cosas sobre las
que es necesario pensar. En esta situación es recomendable definir conjuntos significativos de sub-
sistemas que funcionan juntos y pueden considerarse como una unidad desde el punto de vista de
una integración. Por ejemplo, todas las capas de servicio que pudieran ser necesarias para que un
subsistema dado pueda ser ejecutado podrían ser consideradas como un conjunto de construcció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 -.
En la figura siguiente se muestra una integración planeada para ser hecha en tres construcciones.

55
4.3 Implementar componente

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
 Implementare 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 implemen-
tadas directamente desde la especificación de las mismas. En otros casos podría requerir un algo-
ritmo no trivial por alguna de las siguientes razones:

 Intentamos implementar operaciones complejas

 Queremos optimizar operaciones simples pero resueltas de modo ineficiente. Por ejem-
plo, un componente que debe ordenar los elementos de una lista; por razones de perfo-
mance, 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 algu-
na 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
56
operaciones más simples. Estas operaciones serán privadas y visibles por lo tanto solo en el con-
texto 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 compor-
tamientos complejos debido a la dificultad implicada en una eventual modificación del comporta-
miento o la necesidad de nuevos estados. Si el comportamiento de los componentes es estado de-
pendiente, podrían ser necesarios diagramas de transición de estados que describan su comporta-
miento, 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 lla-
ma 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 co-
mo 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.

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 indirec-
ción innecesaria. Por ejemplo, el número de seguridad social de un empleado podría ser imple-
mentado como un atributo de tipo String o como una nueva clase.

57
 Alternativas de implementación de un atributo.

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:

Los Atributos en Línea están implementados como asociaciones a una clase Punto

Hacer la revisión preliminar del código

Esta no es la prueba unitaria de componentes, la cual veremos en detalle más adelante. Es tal como
se expresa en el título: una revisión de código hecha por el programador una vez implementada la
clase y consiste en lo siguiente:
 Siempre se compila el código, y se fija al máximo nivel de detalle los avisos del compila-
dor.
 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.

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 mejor dicho 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 automa-
tizadas. Productos como Rational Robot, Purify o cuantify son ejemplos de herramientas que per-
miten tal automatización.

El procedimiento mencionado consiste básicamente en:

1. Establecer el entorno de prueba para asegurar que todos los elementos necesarios tales co-
mo hardware, software, herramientas, datos, librerías, etc. han sido previstos.
2. Inicializar el entorno de prueba para asegurar que todos los componentes están en el estado
inicial correcto para el inicio de la prueba.
3. Ejecutar los procedimientos de pruebas.

58
La ejecución de los procedimientos de prueba varían, lo cual depende tanto de si el mismo es au-
tomático o manual como de la necesidad de componentes Stubs y drivers específicos.

 Pruebas automatizadas: se ejecutan los scripts creados durante el paso Implementar Prue-
bas del Subflujo Implementar Componentes.
 Pruebas Manuales: se utilizan los procedimientos desarrollados durante la actividad Estruc-
turar Procedimientos de Pruebas que son usados para ejecutar manualmente la prueba.

Evaluar la ejecución de pruebas

Este segundo 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 completa-

mente o 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 prue-
ba, se toman las acciones correctivas apropiadas y se ejecuta la prueba nuevamente. Si los resulta-
dos indican que las fallas son genuinamente atribuibles a los artefactos probados entonces se conti-
nú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 sis-
tema tales como caídas de red, caídas de hardware, etc. En todos estos casos los síntomas son pare-
cidos: 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:

59
 1. Determinar la causa real del problema.
2. Corregir el problema.
3. Inicializar el entorno de pruebas nuevamente.
4. 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 com-
ponentes 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 complica-
ciones 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 irrelevan-
te, 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 nueva-
mente 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. Tenga presente que es mucho más fácil corregir una sentencia de programación
que garantizar que dicha corrección permitirá al sistema seguir funcionando. 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.

60
  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 particu-
larmente 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, ejecuta-
bles, 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 le-
guaje o lenguajes de programación utilizados, y cómo dependen los componentes unos de otros.

Modelo de Sistema de Implementación Subsistema de Implementación

Implementación

Componente Interfaz

El modelo de implementación define una jerarquía de subsistemas

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 con-
creta y resultante del ciclo de vida iterativo. Representa y demuestran la funcionalidad desarrollada
a la fecha.

Cada Construcción es puesta bajo el mecanismo de control de configuración con el objeto de retor-
nar 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 pro-
veerá puntos de revisión y ayudará a descubrir problemas de integración en la medida que los
mismos han sido introducidos.

61
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 si-
guientes 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 proble-
mas.
 Porque uno o más componentes de hardware podrían no estar disponibles para el progra-
mador. 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 disponer-
se 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éto-
dos de sus clases que escriben en disco validan previamente el espacio disponible. Ocasio-
nar 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.

62
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 componen-
tes, 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.

Es importante entender que un subsistema de implementación se manifiesta a través de un “meca-

nismo de empaquetamiento” concreto en un entorno de implementación determinado tales como un
paquete en Java, un proyecto en Visual Basic, un directorio de archivos en un proyecto de C++ o
un paquete en una herramienta de modelado visual como Rational Rose.

Por tanto, la semántica de la noción de subsistema de implementación se refinará ligeramente

cuando se manifieste en un entorno de implementación determinado. Sin embargo, en esta unidad
discutimos la implementación a un nivel general, aplicable a la mayoría de los entornos de imple-
mentación.

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 se-
guir la traza uno a uno de sus subsistemas de diseño correspondientes.

Modelo de Modelo de
Diseño Implementa-
ción
<<trace>>

<<trace>>

i1 i2 i1 i2
En la figura anterior vemos como un subsistema de implementación del modelo de implementación
sigue la traza uno a un subsistema de diseño. Podría darse también que un subsistema de imple-
mentación tenga una traza uno a varios subsistemas de diseño. Independientemente de esta relación
de arquitectura entre paquetes de ambos modelos observe también que en este caso un componente
ejecutable del subsistema de implementación tiene traza hacia más de una clase del subsistema de
diseño. Así mismo puede verse como ambos subsistemas proporcionan la misma interfase i1 y de-
penden de la misma interfaz i2.

63
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 sub-
sistemas. 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 conecto-
res o 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.

En la figuras siguiente se muestra un subsistema de gestión de cuentas pertenecientes a un sistema

bancario con su interfase transferencias mediante el cual se accede al subsistema.

GestionDeCuentas

<<interfase>> <<Subsistema de Implem.>>

Transferencias

El código java correspondiente a la interfase transferencia

Package GestiónDeCuentas;
// Interfases proporcionadas:
public interface Transferencias {
public Cuenta Crear (Cliente propietario, Dinero saldo,
NumeroCuenta id_cuenta);
Public void Depositar (Dinero cantidad, Cantdad, Cadena razon);
}

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 implementa-
ció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 programado-

res o subcontratistas.
 Evaluar la cantidad de código a ser desarrollado, modificado o eliminado.

64
  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 reque-
rimientos, 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.

Habilidades

“El arquitecto ideal sería una persona con conocimientos en matemática, filosofía, letras, histo-
ria, música, medicina, leyes y algo de astronomía”.

Extractado la obra de Vitriivius Circa (un reconocido arquitecto romano) escrito en la primera
centuria A.C..

Seguramente será poco probable tener en nuestro equipo un miembro con tantas cualidades; pero
no se desanime, la aseveración de Vitruvius se hace sobre un marco ideal; y nos sirve para saber
cuales que las cualidades de quien cumpla con este rol. En definitiva para este rol buscamos al-
guien bien formado, maduro, visionario y con una vasta experiencia que faciliten su juicio crítico
en la ausencia de información completa.

Experiencia tanto en el dominio del problema como en el campo de la ingeniería de software, sin
dejar de considerar la comprensión de las necesidades de los usuarios. Si este rol lo ejecuta más de
una persona, estas habilidades podrían estar repartidas, pero al menos uno de los arquitectos de
software debe tener la visión global del proyecto.

Liderazgo a fin de manejar convenientemente el esfuerzo técnico de los miembros del equipo de
trabajo y tomar decisiones críticas, aún en condiciones de mucha presión. Para que el trabajo sea
efectivo el arquitecto de software y el jefe de proyecto deben trabajar mancomunadamente, uno
con autoridad en las cuestiones técnicas y el otro en los aspectos administrativos del proyecto res-
pectivamente.

Comunicación para guiar, dar confianza, persuadir y motivar. El arquitecto de software no puede
ser impuesto por decreto. Es necesario que el mismo cuente con el consentimiento y respeto de los
miembros del proyecto como del cliente, sus gerentes y usuarios en general.

65
Proactividad y orientación a objetivos con un implacable enfoque en los resultados. El arquitecto
de software es la fuerza técnica que respalda el proyecto. Los éxitos del arquitecto de software se
basan en decisiones razonables, cotidianas y sobre la marcha dadas en un marco de presión e in-
certidumbre casi permanente.

Asignación de roles

Si el proyecto es lo suficientemente grande para justificar un equipo de arquitectos, el objetivo es

tener una buena mezcla de talentos cubriendo un amplio espectro de experiencia y comprensión
común del proceso de ingeniería de software. El equipo de arquitectos no es necesariamente un
comité de representantes de varios subgrupos de trabajo. El trabajo de arquitecto es una función
full-time que requiere de una dedicación permanente.
En proyectos mas pequeños una sola persona puede actuar tanto como jefe de proyecto como ar-
quitecto de software. Sin embargo, si fuera posible, siempre es mejor que estos roles se asignen a
personas diferentes a fin de asegurar que los plazos y presión no deterioren la dedicación a una de
las dos funciones.

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 inte-
gración en un subsistema mayor. Cuando son necesarios componentes de prueba tales como drivers
o stubs es el mismo programador el responsable de su desarrollo y prueba para incorporarlos en los
subsistemas de apoyo.

Habilidades

Entre las habilidades y conocimientos apropiadas para este rol se puede mencionar:

Manejo del lenguaje de programación adoptado para el desarrollo.

Habilidades de lógica y programación
Conocimiento general del sistema a desarrollar.
Conocimiento sobre técnicas y herramientas de prueba.

Asignación de roles

Un programador puede ser asignado para implementar una parte estructural del sistema como una
clase o un subsistema de implementación; o una parte funcional del sistema tal como la realización
de un caso de uso.
Es común que una misma persona actúe como implementador y diseñador tomando las responsabi-
lidades de ambos roles.
Es posible que dos personas actúen implementando un mismo componente dividiendo responsabi-
lidades entre ambos o bien trabajando juntos en la modalidad de trabajo conocida como programa-
ción de a pares.

66
6.3 Integrador de Sistemas

Los integradores son responsables de planificar y realizar la integración de elementos de imple-

mentació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 espa-
cio 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 corres-
pondiente al sistema total.

Habilidades

Entre las habilidades y conocimientos apropiadas para este rol se puede mencionar:

Conocimiento del sistema o parte del sistema a ser integrado. En particular, el integrador necesita
conocer tanto las interdependencias entre elementos de implementación como las correspondientes
entre subsistemas.
Familiaridad con herramientas de integración.
Habilidades de coordinación y comunicación con los programadores para asegurar una integración
exitosa.

Asignación de roles

A veces podría ser apropiado para una persona actuar alternadamente como integrador y tester. Por
ejemplo, si el proyecto es pequeño o la integración corresponde al nivel de subsistema, podría
hacerse un uso eficiente de recursos asignando a un mismo miembro del equipo tanto la actividad
de pruebas como la de integración. Más aún, hablando de proyectos pequeños, una misma persona
podría actuar como implementador, tester e integrador.

67
 Versión 2006

Informática IV

Unidad 3

Pruebas
Unidad 3: Pruebas

Autor/es
Boggio, Alejandra
Jiménez, José Luis

Orientación del aprendizaje

Es un hecho bien conocido que en un proyecto típico de software, aproximadamente un

50% del tiempo y entre el 30% y el 50% del presupuesto se emplea en probar los
programas o sistemas en cuestión. Por lo tanto se podría esperar que la prueba del
software hubiese alcanzado, hoy en día, el refinamiento
de una “ciencia exacta”; sin embargo esto está lejos de ser así. En realidad parece que se
sabe menos sobre la prueba de software de lo que se conoce sobre cualquier otro
aspecto del desarrollo de los programas. Más aún, el tema ha estado “fuera de moda”, lo
que significa que hay poca literatura sobre el mismo.

En esta unidad desarrollamos el Flujo de Trabajo Pruebas. Al igual que en los flujos
anteriores le mostramos el propósito, las actividades, los artefactos, conceptos
principales y roles que son propios de esta disciplina.

En el cuadro siguiente, ya conocido por usted, se muestra esquemáticamente el PUD

completo, podrá descubrir la información de contexto que necesita para saber
exactamente dónde estamos parados y hacia donde vamos

Durante la fase de inicio puede hacerse parte de la planificación inicial de las pruebas.
Sin embargo, las pruebas se llevan a cabo sobre todo cuando una construcción -como un

68
resultado de implementación- es sometida a pruebas de integración y de sistema. Esto
quiere decir que la realización de pruebas se centra en las fases de elaboración -cuando
se prueba la línea base ejecutable de la arquitectura- y de construcción -cuando el
grueso del sistema está implementado-. Durante la fase de transición el centro se
desplaza hacia la corrección de defectos durante los primeros usos.

Desde esta perspectiva, los contenidos que trabajamos en esta unidad son:

1. Propósito de las pruebas ............................................................................................ 71

2. Conceptos preliminares .............................................................................................. 71
2.1. Psicología y economía de las pruebas ................................................................. 71
2.2. Conceptos básicos ............................................................................................... 72
2.3. Tipos de prueba ................................................................................................... 74
2.4. Etapas de Prueba.................................................................................................. 75
3. Flujo de trabajo de prueba .......................................................................................... 78
3.1. Planificar pruebas ................................................................................................ 79
3.2. Diseñar prueba..................................................................................................... 81
3.3. Implementar prueba............................................................................................. 83
3.4. Realizar pruebas de integración........................................................................... 84
3.5. Realizar prueba de sistema .................................................................................. 85
3.6. Evaluar prueba..................................................................................................... 86
4. Artefactos ................................................................................................................... 87
4.1. Artefacto modelo de pruebas............................................................................... 87
4.2. Artefacto caso de prueba ..................................................................................... 88
4.3. Artefacto procedimiento de prueba ..................................................................... 93
4.4. Artefacto componente de prueba......................................................................... 95
4.5. Artefacto plan de prueba ..................................................................................... 95
4.6. Artefacto defecto ................................................................................................. 95
4.7. Artefacto evaluación de prueba ........................................................................... 96
5. Trabajadores ............................................................................................................... 96
5.1. Diseñador de pruebas........................................................................................... 96
5.2. Ingeniero de pruebas de integración.................................................................... 96
5.3. Ingeniero de pruebas de sistema.......................................................................... 97

A partir del análisis y del recorrido propuesto esperamos que logre los siguientes
objetivos.
 Reconocer la importancia de este flujo en el desarrollo de sistemas.
 Satisfacer los requerimientos de calidad del software.
 Lograr una versión utilizable del aplicativo (Versiones alfa, beta y otras
versiones de prueba)

¿Cómo estudiar esta unidad?

Esta primera unidad es autocontenida. Aquí encontrará toda la información básica para
luego continuar con el desarrollo de los siguientes temas. Le sugerimos que reflexione
sobre cada punto a tratar y realice las actividades propuestas.
Asimismo, existe en el mercado una serie de textos valiosos que podrá consultar.

Bibliografía recomendada

69
 JACOBSON, Ivar. El Proceso Unificado de Desarrollo. Editorial Addison
Wesley. España. 2000.

 WEITZENFELD, Alfredo. Ingeniería de Software orientada a Objetos con

UML, Java e Internet.. Ed. Thomson. México, 2004.

 PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico. Quinta

edición. Editorial Mc Graw Hill. España. 2002.

 LARMAN, Craig. UML y Patrones. Primera edición. Editorial Prentice Hall,

Inc. México. 1999.

70
1. Propósito de las pruebas
 Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de
integración y las pruebas de sistema. La 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. La 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. Recuerde que en el PUD los Casos
de Uso (requerimientos) guían todo el proceso.

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. Conceptos preliminares
2.1. Psicología y economía de las pruebas
Es posible tratar el problema de la prueba se software desde diversos puntos de vista
técnicos; sin embargo, los criterios fundamentales que se pueden aplicar son,
aparentemente, de índole económico y psicológico. Dicho de otro modo, la posibilidad
de probar “completamente” un programa, la adecuada elección de quién debe hacerlo y
la adopción de un modo de pensar correcto acerca de este problema son cuestiones que
parecen contribuir en mayor grado al éxito de una prueba que otras de orden puramente
técnico. Es entonces conveniente comenzar con la presentación de tales temas antes de
pasar a otros de naturaleza más técnica.

Se trata entonces de acordar una definición correcta del término “probar” o “testear”,
términos que utilizaremos indistintamente con el mismo significado y alcance.

71
Con frecuencia se parte de una definición totalmente incorrecta de la palabra probar
aplicada al software, y ésta es una de las principales causas de que las pruebas resulten
deficientes. Por ejemplo: “probar es demostrar que no hay errores o defectos presentes
en un programa”, “el propósito de probar es mostrar que el programa realiza
correctamente las funciones esperadas”, y “probar es el proceso que lleva a confiar, en
que un programa hará lo que se supone que debe hacer”.

Estas definiciones son incorrectas porque describen casi lo opuesto de lo que debemos
considerar como prueba de un programa. Dejando por un momento de lado las
definiciones, pensemos en que cuando se prueba un programa se desea agregarle algún
valor -es decir, puesto que la prueba es una actividad costosa, se desea recuperar parte
de este costo por medio de 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 (esta suposición es válida para casi todos los programas) y luego probar el
programa para encontrar tantos como sea posible.

Proponga su propia definición de prueba de software.

La argumentación puede parecer meramente un sutil juego semántico, pero le aseguro

que influye decididamente en el éxito del proceso de prueba. 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. En
cambio 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 también, por supuesto, la verificación de que dichas funcionalidades se
implementan correctamente.

72
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 dela 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)
73
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. Usando la estrategia la persona
que efectúa la prueba considera el programa como una caja negra, es decir, se
desentiende completamente del comportamiento y estructura internos. En cambio, 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.

De acuerdo con este enfoque, 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. Para el programa del triángulo
visto en la introducción, habría que crear casos de prueba para todos los triángulos
válidos, hasta el máximo valor aceptado de número entero. Este será un número
astronómico de casos de prueba y, sin embargo, no será exhaustivo: no producirá
detección de error en aquellos casos en que el programa diga que –3,4,5 es un triángulo
escaleno y que 2, A, 2 es un triángulo isósceles. Para asegurar la detección de todos los
errores de este tipo, seria necesario usar, no solamente los datos de entrada válidos sino
también todos los datos de entrada posibles. Por ello, para probar el programa del
triángulo en forma realmente exhaustiva hay que utilizar un número de casos de prueba
virtualmente infinito.

Pruebas tipo caja blanca

Otra estrategia para probar software, 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.

Lo que se quiere hacer es establecer para esta estrategia un análogo a la prueba

exhaustiva del enfoque de caja negra. El neófito podría creer que la respuesta sería
hacer que cada sentencia del programa sea ejecutada por lo menos una vez, pero no es
difícil mostrar que este procedimiento es extremadamente inadecuado. Si se ejecutan
por la vía de casos de prueba todas las posibles secuencias del flujo de control del
programa, probablemente se podrá decir que está completamente probado.

Hay sin embargo dos fallas en este enunciado. La primera es que el número de
secuencias lógicas distintas en un programa es astronómicamente grande. La segunda es
que aunque se hayan probado cada una de las secuencias posibles en el flujo del control

74
del programa, éste podría estar todavía plagado de errores. Hay tres explicaciones para
esto.

La primera es que 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.

Segundo, 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.

Tercero, 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:

IF ((A-B < EPSILON) ....

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

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

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.
76
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.
 Los usuarios finales tienden a focalizarse en la comparación del nuevo sistema
con uno anterior perdiendo prioridad la búsqueda de defectos.
77
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 mas 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. En la siguiente figura se muestra mediante un diagrama de actividad el
comportamiento dinámico de este proceso. Inicialmente, 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. 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.

78
3.1. Planificar pruebas

Tal como lo sugiere el nombre de esta actividad, 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.

En la figura siguiente se muestran los participantes, artefactos de entrada y salida de

esta actividad.

79
 La entrada y el resultado de la planificación de pruebas

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.

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.

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

En la figura siguiente se muestran los participantes, artefactos de entrada y salida de

esta actividad.

La entrada y el resultado del diseño de pruebas

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 un realización de caso de uso.

Cuando los diseñadores de pruebas hacen los casos de prueba de integración consideran
como entrada primeramente los diagramas de interacción de la realización de casos de
81
uso. Los diseñadores de pruebas buscan combinaciones de entrada, salida y estado
inicial de sistema que den lugar a escenarios interesantes que empleen las clases -y por
lo tanto lo componentes- que participan en los diagramas.

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.
82
Ya que los casos de prueba están basados en los casos de uso o en realización de ellos,
la mayoría probarán varias clases de diferentes subsistemas de servicio, pero cada
procedimiento de evaluación debería, si fuera posible, especificar cómo probar clases de
un único sistema de servicios; sin embargo, algunas procedimientos de prueba pueden
especificar cómo probar un subsistema de servicio. Cada caso de prueba precisará
distintos procedimientos de prueba, quizás uno por cada subsistema de servicio probado
en el caso de pruebas.

Relacionando de esta forma los procedimientos de prueba con los subsistema de

servicios los primeros serían más fáciles de mantener. Cuando se cambia un subsistemas
de servicio los efectos del cambian que tienen que ver con los procedimientos de prueba
pueden entonces estar limitados a los usados para verificar el subsistema del servicio y
no se vería afectado ningún otro procedimiento de prueba. En el cuadro 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.

83
 La entrada y el resultado de la implementación de pruebas.

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
acciones son entonces grabadas dando como salida un componente de prueba; por
ejemplo, generando un escript 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.

84
 Entada y resultado de las pruebas de integración

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.

85
 Entrada y resultado de la prueba de sistema.

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

Entrada y resultado de la evaluación de prueba.

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
86
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. Como se ilustra en la figura 6.1., el modelo de pruebas es una colección de
casos de prueba, procedimientos de prueba y componentes de prueba.

Las siguientes secciones presentan los artefactos en el modelo de pruebas en detalle.

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.

Modelo de Pruebas Sistema de Pruebas

Casos de Prueba Procedimiento Componente

De Prueba De Prueba

87
 El modelo de pruebas.

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.

Modelo de Pruebas

Caso de Uso Caso de Prueba

(del modelo de Casos de Uso) (Prueba de Caja Negra)

Caso de Uso Caso de Prueba

(del modelo de Casos de Uso) (Prueba de Caja Blanca)

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.

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

Entrada

 Existe un pedido de una bicicleta de montaña y éste ha sido enviado a

un vendedor, Crazy Mountaineer, Inc. El precio es 300 pesos,
incluyendo gastos de envío.

 El comprador ha recibido una confirmación de pedido (ID 98765) de

una bicicleta de montaña. El valor confirmado es de 300 pesos,
incluyendo gastos de envío.

 El comprador ha recibido una factura (ID 12345), la cual se conforma

con la confirmación del pedido de la bicicleta de montaña. El total
facturado sería de 300 pesos, y la factura –la única presente en el
sistema- debería estar en el estado Pendiente y tendría que apuntar a
una cuenta 22-222-2222, que recibirá el dinero y que tiene un saldo de
963.456,00 pesos; su titular debería ser el vendedor.

 La cuenta 11-111-1111 del comprador tiene un saldo de 350 pesos.

Resultado

 El estado de la factura debería ser puesto a Cerrada, indicando así que

ha sido pagada.

 La cuenta 11-111-1111 del comprador debería tener un saldo de 50

pesos.

 El saldo de la cuenta 22-222-2222 del vendedor debería haber

aumentado hasta 963.756,00 pesos.

89
Condiciones

 No se permite que otras instancias de casos de uso accedan a las

cuentas durante el caso de prueba.

Observe que 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.

90
 1

9 5
8

6
10

11

12

Lo que hacemos ahora es construir el grafo de flujo para este caso de uso:

3,4

7 5,6

8 9

10
11
12

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

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

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

>Especifica cómo llevar a cabo

1..* 1..*
X X

Procedimiento de Prueba Caso de Prueba

Hay asociaciones muchos-a-muchos entre los procedimientos de prueba y los casos 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:

93
 Caso de uso: Pagar 300-Bicicleta de Montaña.

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

la ventana de diálogo Consultar Facturas.

2. En el campo Estado de la Factura, seleccione Pendiente y pulse el

botón Consultar. Aparece la ventana Resultados de la Consulta.
Verifique que la factura especificada en el caso de uso ID 12345
está en la lista en la ventana Resultados de la Consulta.

3. 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.

4. Seleccione la opción Autorizar Pago para iniciar el abono de esta

factura. Aparece la ventana de diálogo para el Pago de Factura.

5. 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
cierta 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:

94
  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
pruebas.
>automatiza
1..* 1..*
X

Componente de Prueba Procedimiento de Prueba

Asociaciones muchos-a-muchos entre componentes y procedimientos 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.

Fíjese que los componentes de prueba pueden ser implementados usando tecnología de
objetos. Si varios componentes de prueba tienen interacciones internas complejas o
interacciones complejas con los componentes ordinarios en el modelo de
implementación, puede adoptarse un “modelo de diseño de pruebas” -similar al modelo
de diseño- para modelar los componentes de prueba y representar vistas de alto nivel de
ellos.

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

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

Ingeniero de Pruebas
(responsable de)

Modelo de Casos de Procedimiento Evaluación Plan

Pruebas Prueba de Prueba Pruebas de
Pruebas

Las responsabilidades de un diseñador de pruebas en el flujo de trabajo de la prueba.

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

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

Advierta que este profesional prueba el resultado, es decir, una construcción, creado por
el integrador de sistemas en el flujo de trabajo de la implementación. Es por esto por lo
que en algunos proyectos se decide que estos trabajadores sean el mismo individuo o
grupo de pruebas para minimizar el solapamiento en el conocimiento necesario.

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

97
 Versión 2006

Informática IV

Unidad 4

Utilizando PUDS
Unidad 1: Utilizando PUDS

Autor/es
Boggio, Alejandra

Orientación del Aprendizaje

Todo desarrollo de software, para tener éxito, requiere de un proceso que permita
gestionar el proyecto, planificarlo, controlar los riesgos, organizar el equipo de
desarrollo, distribuir las funciones de cada uno, comunicar, gestionar avances y
retrasos, manejar recursos, etc.. En este sentido, el PUDS visto en Análisis y diseño y
en esta materia contribuye a lograr estos objetivos. Se han visto cada uno de los flujos
de trabajo principales de la metodología, los trabajadores que participan, las
actividades que realizan y los artefactos que generan.
En esta unidad pretendemos integrar los conceptos vistos hasta ahora, profundizando
un poco más en el funcionamiento del PUDS y destacando las ideas principales que
maneja, ahora ya con su conocimiento completo de la metodología sabrá identificar
las ventajas de utilizar la misma en un proceso de desarrollo de software.
A esta altura, Ud. podrá constatar mediante la experiencia que ha logrado en estas dos
materias las ventajas de esta metodología aplicada al desarrollo de software.

Desde esta perspectiva los contenidos que trabajamos en esta unidad son:

1 Metodología PUDS ............................................................................................100

1.1 PUDS dirigido por casos de uso, centrado en la arquitectura, iterativo e
incremental.............................................................................................................100
1.2 El UP entrega las 6 mejores prácticas ........................................................104
1.3 Ventajas y errores al utilizar el proceso unificado .....................................104
2 Fases e iteraciones..............................................................................................105
2.1 Planificación de las fases ...........................................................................105
2.2 Planificación de las iteraciones ..................................................................106
2.3 Evaluación..................................................................................................106
3 Flujos de trabajo.................................................................................................107
3.1 Flujos de trabajo fundamentales ................................................................107
3.2 Dominio del problema y de la solución .....................................................107
3.3 Flujos de trabajo y modelos .......................................................................108

Al finalizar esta unidad usted habrá alcanzado los siguientes objetivos:

 Reforzar la comprensión de la importancia de la metodología.
 Integrar los conceptos sobre la metodología que ha adquirido hasta
ahora.
 Retomando para recordar las características del PUDS con una visión
amplia y completa del mismo.
 Diferenciar al PU de otras metodologías.

98
¿Cómo estudiar esta unidad?

Para poder abordarla usted trabaja con la guía de estudio y profundiza los contenidos
de la misma en la bibliografía propuesta. Le sugiero que reflexione sobre cada punto a
tratar y realice las actividades que se presenten.

Bibliografía recomendada

 JACOBSON, Ivar. El Proceso Unificado de Desarrollo. Editorial Addison

Wesley. España. 2000.

 WEITZENFELD, Alfredo. Ingeniería de Software orientada a Objetos con

UML, Java e Internet.. Ed. Thomson. México, 2004.

 PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico. Quinta

edición. Editorial Mc Graw Hill. España. 2002.

99
1 Metodología PUDS
En los últimos años la tendencia y el desafío ha sido construir software cada vez más
grandes y más complejos en tiempos a su vez más cortos. Esta situación ha llevado a
la comunidad del software a plantearse la necesidad de contar con metodologías que
permitan lograr estos objetivos, herramientas que soporten tales procesos,
convenciones y acuerdos comunes, normas y modelos de calidad de productos y de
procesos, mediciones continuas, todo esto a fin de responder a esta realidad, ya que de
esto depende el éxito o no de los proyectos.

Como Ud. ya ha visto en Análisis y Diseño, 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 es un marco de trabajo configurable que puede adaptarse a diferentes
proyectos, con diferentes características en cuanto a tamaño, tipo de organización,
rubro del dominio, etc..

Recuerde también que afirmamos que el PUDS tiene tres aspectos o pilares
fundamentales que lo caracterizan. Repasemos estos pilares, ya que a esta altura, y
luego de haber recorrido y trabajado con los cinco flujos de trabajos fundamentales
del proceso en esta materia y su antecesora Análisis y Diseño, Ud. podrá identificar
claramente y comprobar aquello que en su momento parecía ser una descripción
teórica del proceso.

1.1 PUDS dirigido por casos de uso, centrado en la

arquitectura, iterativo e incremental.

El PUDS se apoya en tres pilares alrededor de los cuales gira la totalidad de la

metodología. Éstos son los casos de uso, la arquitectura y el concepto de iterativo e
incremental.

Dirigido por Casos de uso

Las necesidades del cliente no son fáciles de detectar, y más aún de representar. Para
esto utilizamos la técnica de casos de uso, la cual nos 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.
La técnica de casos de uso ha sido adoptada casi universalmente para la captura de
requisitos de sistemas de información, no sólo por ser simple (la técnica es bastante
intuitiva), sino también por ser efectiva. No es una aproximación a la orientación a
objetos, sino una representación eficaz de un proceso de negocio o la funcionalidad de
un sistema software, convirtiéndose en una buena forma de avanzar hacia el análisis
orientado a objetos.

100
Pero estos casos de uso son mucho más que una simple herramienta de captura de
requisitos, ya que los mismos 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.
Hemos descrito de una manera muy simplificada cómo los casos de uso guían al
proceso unificado, lo hemos visto sólo con una iteración. Vemos cómo 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 trazablidad 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.

Modelo de Modelo de Modelo de

casos de uso análisis diseño
<<trace>> <<trace>>

A A A

Realizaciones de un caso de uso y su relación de traza a través de los modelos del

PUDS.

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.

101
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

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, la experiencia
indica que 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.
Así también es importante que usted comprenda que no todos los casos de uso son
relevantes a la hora de definir la arquitectura, hay ciertos casos de uso
arquitectónicamente relevantes y son sólo éstos los que guían la arquitectura y por lo
tanto, los que se deben tener en cuenta a la hora de describirla.

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.

102
  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.

Los casos de uso especifican la funcionalidad del sistema.

La arquitectura define la forma.

La funcionalidad (casos de uso) y la forma (arquitectura) están relacionadas y

deben estar balanceadas.

Proceso Iterativo e incremental

El PUDS avanza poco a poco en el refinamiento de casos de uso, es decir, vamos

avanzando por etapas. Ésta es la clave del tercer pilar alrededor del cual gira el
proceso unificado de desarrollo de software: proceso iterativo e incremental.

El decir, basarnos en un proceso iterativo e incremental 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á compuesta por todas las fases de un proyecto de
software, es decir que cada una de ellas sería como un miniproyecto 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 ésto como moneda corriente
podemos caer en un terreno donde nos mantengamos siempre en un mismo lugar sin
percibir avance alguno.

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

103
posibilitan la retroalimentación de los usuarios y ésto 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.

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

Desarrolle Iterativamente

Administre Use
Arquitectura Modele Verique
Requeri- Visualmen
de Calidad
mientos te
Componentes

Controle Cambios

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

104
  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.
 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.
Como Ud. ya sabe, el 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. Este momento
permite al equipo de proyecto conocer el estado de avance del proyecto. Esta
información será de gran utilidad no sólo al mismo proyecto, sino que se utilizará
también para realizar estimaciones en otros proyectos para asignar recursos (humanos,
tiempo, económicos).

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. Además, 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.

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

106
Los resultados de la evaluación se registran en un documento que crea el jefe de
proyecto. Este documento se distribuye a los involucrados y se archiva, es decir, no
sufre modificaciones a lo largo del tiempo. La 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

Fuente: Jacobson, Ivar. Booch, Grady. Rumbaugh, James. El Proceso Unificado de Desarrollo del
Software. Ed. Addison Wesley. Madrid, 2000

3.2 Dominio del problema y de la solución

En la actividad de modelado de negocio que realizó en la materia Análisis y Diseño

Ud. trabajó con los objetos del negocio, es decir, con el dominio del problema.

107
Luego, en el flujo de requerimientos que realizó en la misma materia, 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 visto en la misma materia 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 trabajado en esta materia 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. Esto demuestra
que se trata de un proceso que puede ser configurado, y de esta manera lograr la
optimización del mismo.

Modelo de
Modelado de negocio
negocio

Modelo de
Requisitos casos de uso

Modelo de
Análisis
análisis

Modelo de Modelo de
Diseño
diseño despliegue

Implementaci Modelo de
ón implementación

Modelo de
Prueba
prueba

108
 Versión 2006

Informática IV

Unidad 5

Implementación del
cambio
Unidad 5: Implementación del cambio

Autor/es
Jiménez, José Luis

Orientación del aprendizaje

“Los gerentes de línea deben demostrar una comprensión clara de cómo sus productos
y programas de tecnología se comparan con los de sus competidores. La tecnología
debe incluirse en las visiones de su empresa. Ellos incorporan las iniciativas en tecno-
logía a sus planes anuales y quinquenales, y dichas iniciativas se vuelven parte de los
hitos gerenciales mediante los cuales ellos son juzgados. En otras palabras, las tecno-
logías de la información (T.I.) desempeñan un papel clave en su pensamiento estratégi-
co, su planeamiento, y lo que es más importante, en la manera que logran sus metas” 1

Existen ejemplos por doquier de costosos proyectos de tecnología que derivan en estre-
pitosos fracasos. Casi convertidos en mitómanos, algunos directivos y gerentes de em-
presas apuestan el éxito de su gestión empresaria al sólo hecho de aumentar constante-
mente sus inversiones en tecnología, como si la sola incorporación derivara en la conse-
cución automática de objetivos de calidad, costos y oportunidad para sus negocios. Es
cierto que la inclusión de tecnología aumenta las posibilidades de éxito, pero no reparar
en la importancia de acompañar estas inversiones con una planificación adecuada deri-
vará, casi inexorablemente, en proyectos costosos de efectividad cuestionable. También
es cierto que en estos tiempos que corren el mejor plan sin componentes tecnológicos
adecuados resta eficiencia a la gestión de las organizaciones.

Por eso, en esta unidad le daremos herramientas que le permitan actuar con equilibrio en
el planeamiento efectivo y éxito empresarial de las inversiones en T.I. en las que se verá
involucrado en su accionar profesional.

Desde esta perspectiva, los contenidos que trabajamos en esta unidad son:

1. Creación de conocimiento e implementación del cambio organizacional con T.I... 111

1.1 La creación del conocimiento con T.I. y la ventaja competitiva........................ 111
2. Adquisición de hardware, software y servicios ........................................................ 114
2.1. Evaluación y selección ...................................................................................... 116
2.2. Elaboración de una Requisición de Propuesta (RFP – Request For Proposal) . 117
2.3. Factores a evaluar .............................................................................................. 118
2.4. Métodos de evaluación técnica.......................................................................... 120
2.5. Evaluación financiera ........................................................................................ 121
2.6. Alternativas de adquisición y financiamiento ................................................... 121
2.7. Método de benchmark ....................................................................................... 121
2.8. El método del costo / rendimiento..................................................................... 122
2.9. Conceptos sobre benchmark.............................................................................. 125
2.10. Tipos de benchmark ........................................................................................ 126
3. Lanzamiento de un sistema de información ............................................................. 128
3.1. Contrataciones ................................................................................................... 128
3.2. Documentación.................................................................................................. 128
3.3. Capacitación de usuarios ................................................................................... 129

1
. Martin, Bob, “Planning for success, 2002”, Prentice Hall

109
 3.4. Implantación ...................................................................................................... 131
3.5. Mantenimiento de S.I. ....................................................................................... 132

A partir del análisis y del recorrido propuesto esperamos que logre los siguientes objeti-
vos:

 Identificar las actividades propias del proceso de implementación del cambio organi-
zacional y tecnológico.
 Describir los criterios y ponderación de factores que se utilizan en la selección de
hardware, software y servicios de tecnología de información (TI).
 Identificar los actores que se involucran en la implementación de nuevos proyectos
de SI.
 Identificar los documentos que permitan justificar las decisiones que habilitan la rea-
lización de un proyecto de sistemas.

¿Cómo estudiar esta unidad?

Esta unidad es autocontenida. Aquí encontrará toda la información básica para luego
continuar con el desarrollo de los siguientes temas. Le sugerimos que reflexione sobre
cada punto a tratar y realice las actividades propuestas.
Asimismo, existe en el mercado una serie de textos valiosos que podrá consultar.

Bibliografía recomendada

 PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico. Quinta edi-

ción. Editorial Mc Graw Hill. España. 2002.

 LARDENT, Alberto. Sistemas de Información para la gestión empresaria.

Primera edición. Editorial Prentice Hall. Buenos Aires. 2001.

110
1. Creación de conocimiento e implementación del
cambio organizacional con T.I.
Las organizaciones son organismos inteligentes, y como todo organismo que busca so-
brevivir, éstas deben ser generadoras, almacenadoras y transformadoras de los conoci-
mientos que le permitan enfrentar y modificar su entorno, ya sea para adaptarse a él o,
de ser posible, para adaptar el entorno a su beneficio.

Es común afirmar que en ambientes tan complejos como los que deben enfrentar hoy
las organizaciones, sólo aquellas que utilicen todos los medios a su alcance podrán lo-
grar el objetivo de ser exitosas.

Las tecnologías de información juegan un papel central en esta enloquecida carrera em-
prendida por las empresas contemporáneas. Actualmente, los sistemas de información
no son un lujo, sino un componente clave de las organizaciones, ya que este tipo de tec-
nologías se ven involucradas desde las líneas de producción hasta los más altos puestos
encargados de la toma de decisiones. De esta forma, los sistemas de procesamiento de
información inciden en la manera de trabajar, en la cultura y en la estrategia de muchas
de las compañías actuales.

El facilitar la comunicación, el procesamiento de datos y la manera de almacenar la in-

formación permiten establecer redes, y mediante los procedimientos adecuados, también
permiten descubrir el conocimiento diseminado a lo largo de la organización para con-
vertirlo en material de aprendizaje – conocimiento - útil a todos los miembros de la
misma.

1.1 La creación del conocimiento con T.I. y la ventaja competi-

tiva
Se reconoce que conocimiento es poder, y se sabe que en la era de la información, los
activos intangibles -entre ellos el conocimiento- juegan un papel fundamental para crear
ventajas competitivas para las organizaciones. Sin embargo, lo importante del conoci-
miento en las organizaciones depende de lo que se pueda hacer con él dentro de un ám-
bito de negocios. Es decir, el conocimiento por sí mismo no es relevante, en tanto no
pueda ser utilizado para dar origen a acciones de creación de valor.

Pero la creación del conocimiento no se obtiene por recetas de cocina, aplicación de una
determinada T.I:, ni surge por generación espontánea. Es un arduo proceso de las em-
presas; un proceso que implica un compromiso en todos los niveles, así como una parti-
cipación activa y responsable de los diversos actores de la empresa.

David Smith postula cuatro niveles de desarrollo organizacional en la creación del co-
nocimiento: Compartir conocimiento, nivelación, creación de conocimiento y 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 nue-
vas capacidades que le otorguen grandes ventajas sobre sus competidores. Dice también
que resolver los problemas y encontrar las oportunidades subyacentes en cada uno de
estos estados involucra tres elementos convergentes:

111
  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 documen-
tos, herramientas de grupo, intranet corporativa, sistemas de base de conoci-
miento, etc..
 Alineación organizacional: Los líderes son parte crítica del alineamiento, junto
con las recompensas, roles, estructuras mentales, estructura y apertura.

¿Qué papel juegan las Tecnologías de información en los procesos de creación de cono-
cimiento?

Como vimos en el punto anterior, las tecnologías de información son uno de los compo-
nentes claves para alcanzar cada una de las etapas involucradas en la creación del cono-
cimiento. Sin embargo, debemos tener claro que no todo lo que brilla es oro. De esta
manera, Mc Affe afirma que:

"varios estudios muestran que desde un 30% hasta en un 75% de los casos, los nuevos
sistemas no alcanzan las expectativas, no son capaces de registrar un impacto financie-
ro cuantificable, no mejoran los procesos laborales y no conllevan un verdadero cam-
bio organizacional. En algunos casos extremos, el resultado fue catastrófico. Por ejem-
plo, la compañía Nike gastó cientos de millones de dólares en un sistema que pronosti-
caba incorrectamente las ventas, y la Hershey Foods se quedó sin existencias de dulces
durante una temporada de Halloween debido a otro sistema erróneo. Asimismo, la dro-
guería FoxMeyer se declaró en bancarrota debido en gran parte a sus múltiples pro-
blemas con la implementación de su ERP (Enterprise Resource Planning – Sistema in-
tegral de gestión administrativa contable)".

El simple hecho de escoger la tecnología adecuada a las condiciones y necesidades del

negocio requiere un concienzudo análisis por parte de los encargados de estas tomas de
decisiones. A pesar de que esto resulta obvio para cualquier tipo de sistema, cuando se
aborda el tema de la creación del conocimiento en las organizaciones el asunto toma una
trascendencia mucho mayor.

La tecnología, —aún la más moderna, la más sofisticada o la más costosa— 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 asegurar-
nos de que cumple nuestras expectativas de uso y calidad antes de realizar cuantiosas
inversiones en ella.

En el caso de la creación del conocimiento, siendo este un tema tan atractivo, tan amplio
y de tantos alcances, los tipos de sistemas de información a utilizar pueden ser muy vas-
tos, así como la manera de abordar el tema desde la perspectiva creativa y/o personal.
La utilización de los nuevos sistemas abarca desde casos tan documentados y exitosos,
hasta esfuerzos mucho más modestos, como lo son el uso extensivo de correos electró-
nicos para compartir información.

Asimismo, no debemos perder de vista que las T.I. por sí mismas sólo se consideraban
como una herramienta para facilitar la comunicación y la coordinación a niveles bási-
cos, y, al utilizarse con propósitos de administración del conocimiento dentro de las
empresas, se tendía más a su abuso que a su efectiva explotación. No es probable que

112
los cuadros administrativos dentro de las organizaciones no fuesen capaces de reconocer
el potencial de los sistemas informáticos para la administración del conocimiento, pero
el hecho es que dicha tarea se enfocaba más en los mecanismos requeridos para facilitar
la creación del conocimiento que en el desarrollo de bases de datos extensivas o de
identificadores de conocimientos individuales. La creación del conocimiento recaía
principalmente en atraer y retener a todo aquel individuo capaz de comunicar y sinteti-
zar su propio conocimiento y experiencia. A este respecto, las prácticas de administra-
ción del personal que reconocían y perpetuaban altos niveles de autonomía resultaban
cruciales, ya que enfatizaban la naturaleza contextual de la administración del conoci-
miento en la práctica.

De esta manera, hoy en día se reconoce que lo verdaderamente importante es crear una
cultura organizacional que premie la colaboración, que brinde seguridad a los emplea-
dos y que facilite este tipo de procesos.

El tener una cultura que facilite el compartir conocimientos otorga beneficios a las em-
presas, les permite aumentar su productividad, dar mejor servicio a clientes y almacenar
conocimientos valiosos para el desempeño de sus funciones.

Los procesos de creación de conocimiento nunca deben iniciar ni terminar con la im-
plementación de algún sistema de tecnologías de información y de ningún modo debe
verse éste como el punto focal del proceso. Si se emprende un esfuerzo auténtico por
alcanzar una cultura del conocimiento en la organización se debe partir de un diagnósti-
co de las condiciones actuales de la empresa – dónde estamos-, saber para qué queremos
implementar los cambios – en qué se beneficiará el desempeño de la empresa ya sea en
el corto o en el largo plazo –, establecer un plan que incluya cada uno de los siguientes
elementos: procesos cognitivos, facilitadores tecnológicos y alineación organizacional,
y por último implementar este plan. Existen muchos libros que guían a las empresas que
emprenden esta aventura pero no se debe perder de vista que lo más importante es en-
tender las particularidades de cada una y que cada proceso es distinto.

Otro punto a tomar en cuenta es que los periodos de transición siempre resultan en si-
tuaciones delicadas que implican riesgos, los cuales deben ser cuidadosamente calcula-
dos de manera que no se ponga en riesgo la viabilidad de la empresa. Cuando se esté
evaluando la posibilidad de una inversión importante en Tecnologías de información
sobre todo dentro de un contexto de cambio profundo, como lo son los esfuerzos por
implementar culturas de creación de conocimiento en las empresas, nunca se debe per-
der de vista los límites y alcances indispensables en el sistema a implementar. Además,
si este va a incidir en procesos troncales de la operación, debemos asegurarnos de tener
planes de contingencia para cualquier eventualidad.

Las empresas creadoras de conocimiento parecen ser la alternativa para los tiempos de
cambio que corren. Los procesos de creación de conocimiento no sólo las hacen menos
vulnerables a las condiciones del mercado sino que explotar el conocimiento disemina-
do a lo largo de ellas facilita la creación de respuestas innovadoras, lo que les otorga un
margen de maniobra muy superior al que las empresas con enfoques más tradicionales
tienen.

Finalmente, y sin pretender darle una receta, considere los siguientes aspectos como
premisa indispensable cuando enfrente un proceso de cambio organizacional implemen-
tando tecnología de información:

113
  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.

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 comple-
jo La inversión en tiempo, dinero y esfuerzo que se realiza justifica plenamente el desa-
rrollo de una guía de acción que oriente al responsable de conducir y desarrollar el estu-
dio y el proceso.

El costo total del área de informática en las empresas está constituido por varios renglo-
nes. Una gran parte del costo se destina a la adquisición o desarrollo de programas de
aplicación que resuelvan problemas fundamentales de los usuarios. Otra parte importan-
te del costo se relaciona con la operación de los sistemas computacionales y con las
operaciones diarias, así también como los recursos de hardware o inversión en T.I.

Una distribución del presupuesto de acuerdo con estudios realizados a varias empresas
mostró los siguientes resultados:

Concepto Porcentaje
--------------------------------------------------------------------------------------------------
Sueldos y compensaciones 30
Compra o renta de hardware 18
Mantenimiento de hardware 7
Software (licencias, desarrollo y mantenimiento) 9
Comunicaciones (inversión y operación) 7
Papelería y accesorios 5
Viajes 5
Capacitación y entrenamiento 5
Planta física, equipo de oficina y servicios 5
Asesorías externas 4
Teléfono 4
Suscripciones y membresías 1
-------------------------------------------------------------------------------------------------
Total 100%

Como puede observarse, en promedio, cuando menos el 25% de los costos totales se
destina a recursos de hardware, de lo cual se deriva la necesidad de una guía o metodo-
logía que oriente al responsable de un proyecto de cambio de equipo durante el proceso.

114
Las decisiones relacionadas con la adquisición de estos recursos deben considerar facto-
res tecnológicos y financieros. No obstante, no existen procedimientos infalibles para
este proceso, el cual 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 consti-
tuyen 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 compu-
tacionales son:

 Determinación de los requerimientos.

Es necesario especificar las necesidades del nuevo equipo a fin de transmitirlas
de manera clara a los diferentes proveedores, para lo cual es obligatorio:
 Un conocimiento de la organización. El primer paso que deberá realizar el
responsable del proyecto de cambio de equipo, es tener un conocimiento pro-
fundo de la organización o la entidad de negocios que recibirá el servicio del
equipo que será adquirido. En caso de que la empresa decida contratar un
consultor, será necesario proporcionarle toda la información, o bien, que se
involucre con cada una de las unidades funcionales. El conocimiento de la
organización implica, por otra parte, saber cuál es el plan general o estratégi-
co del negocio y su índice o porcentaje de crecimiento del negocio estimado
durante el horizonte de planeación del proyecto.
 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 sis-
tema. 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 requeri-
mientos y restricciones a considerar en el nuevo equipo. La filosofía de ope-
ración que se desea con el nuevo equipo requiere un análisis del tipo de solu-
ció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.

115
  Capacidad de almacenamiento secundario, expresada en Megas, Gigas ó Te-
rabytes.
 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, pre-
sentes 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.
 Compatibilidad con el lenguaje computacional actual, minimizando el es-
fuerzo 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 pro-
puesta 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.

Tanto para el hardware como para el software es necesario estimar los volúmenes re-
queridos durante el horizonte de planeación previsto.

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 caracte-
rísticas y los factores técnicos de los equipos disponibles. El resultado de esta evalua-
ción técnica, sumado al resultado de la evaluación económica y financiera, constituyen
la plataforma de decisión del equipo y de la solución a adquirir.

116
2.2. Elaboración de una Requisición de Propuesta (RFP – Re-
quest For Proposal)
La evaluación técnica de los equipos se facilita si se elaboran correctamente las pro-
puestas por parte de los proveedores de soluciones. 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 requeri-
mientos 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 proveedo-
res 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:

 Datos generales del responsable del proyecto.
 Fecha límite para recibir la propuesta del proveedor.
 Fecha límite para que el proveedor realice las presentaciones y/o demostracio-
nes del equipo propuesto.
 Bases y lineamientos generales que serán utilizados para comparar los diferen-
tes equipos.
 Breve descripción de la situación actual de la compañía y de la función de in-
formática dentro de la misma.

Requerimientos del sistema computacional

Se puede incluir la siguiente información:

 Requerimientos del equipo actual versus del equipo propuesto.
 Requerimientos obligatorios y opcionales.
 Información más detallada de las pruebas de benchmark o pruebas de rendimien-
to que serán efectuadas a las soluciones propuestas que estarán concursando.
 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 fi-
nal.
El formato de propuesta puede variar de una empresa a otra, o de acuerdo con el pro-
blema específico que deba ser resuelto utilizando la T.I. No obstante incluye:
 Sistema o solución configurada. Con la descripción técnica detallada de la solu-
ción propuesta y las capacidades de crecimiento del sistema. Debe contener ma-
nuales técnicos de hardware y del software configurado, así como diagramas es-
quemáticos de la configuración propuesta.
 Requerimientos de instalación. Se debe recordar que hay soluciones que impli-
can costosos requerimientos de instalación. Debe incluir:

117
  Espacio físico que ocupa el equipo.
 Instalaciones eléctricas y equipos reguladores de voltaje.
 Temperatura ambiental y equipos de aire acondicionado.
 Requerimientos especiales tales como piso falso, equipo de control de hume-
dad, etc.
 Asistencia del proveedor. Aspecto tan importante como el producto, e incluye:
 Asistencia para el entrenamiento del personal en el nuevo equipo y calenda-
rio de cursos, incluyendo su costo.
 Personal de asistencia para hardware, software y en general, para el mante-
nimiento 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 apli-
cación al nuevo equipo.
 Información de costos. Debe incluirse toda la información económica y finan-
ciera de las propuestas. Ello comprende precios, plazos de pago y opciones de
compra disponibles por parte del proveedor, y en general, todos los datos reque-
ridos 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 departa-
mento jurídico de la compañía.
 Nivel o grado de cumplimiento: Es importante insistir a los proveedores que es-
ta información se incluya en la propuesta entregada en forma expresa y por se-
parado.

Apertura de concurso de proveedores

Una vez elaborado el RFP, es necesario abrir formalmente el concurso de los proveedo-
res. 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 re-
comienda 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 consi-
derar 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 reque-
rimientos obligatorios y que cumplen mejor las especificaciones opcionales. Se clasifi-
can en:
 Factores de hardware. Son las características que ofrecen los componentes físi-
cos de la solución. Por ejemplo: capacidades y velocidades de los diferentes
componentes.

118
 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. Además se consideran pa-
quetes especiales, tales como simuladores, análisis financieros, programación li-
neal, control de proyectos, análisis estadísticos y paquetes que se enfocan a re-
solver problemas funcionales a los usuarios, tales como contabilidad, cuentas
por pagar, y facturación, entre otros.
Es importante destacar que en la mayoría de los casos el tiempo de vida útil del
software de aplicación es superior al tiempo de vida útil de las plataformas de
hardware.
Esto conlleva la necesidad de llevar a cabo constantes conversiones y adapta-
ciones al mismo S.I. para que corra o funcione en plataformas diferentes y más
modernas de hardware, por lo que se debe dar gran peso a la posibilidad y facili-
dad 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.
Existe una tendencia de creer que mientras más tiempo permanezca un cliente
con un mismo proveedor, el servicio y soporte se deterioran, especialmente si
no existen compras importantes. En este sentido algunos aspectos a analizar
son:
- 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 ma-
nera que aseguren la permanencia y continuidad del proveedor. Ellos
incluyen:
o Representación mundial y regional del proveedor
o Tiempo de entrega del equipo y futuras ampliaciones
o Profesionalismo y preparación de los vendedores
o Situación económica y financiera
o Calidad de la documentación y manuales disponibles
- 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:
o al personal de las áreas de investigación y soporte técnico
o en el área de análisis y programación
o a operadores
o capacitación a usuarios
- 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:
o Calidad y cantidad de personal capacitado de tiempo comple-
to disponible en hardware y software.
o Tiempo promedio que tarda el proveedor en atender las fallas
reportadas.
o Tiempo o porcentaje de sistema funcionando, que es el tiempo
que trabaja el sistema sin que ocurra algún problema.
o Tiempo promedio que el sistema permanece caído durante ca-
da falla.
o Existencia de una sucursal cercana con partes y repuestos para
responder con mayor oportunidad a fallas.

119
 o Existencia de horario extendido, 7 días a la semana, 24 horas
diarias para atender fallas.
- 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:
o Cantidad de equipo de respaldo existente.
o Facilidad de trasladar procesos a los equipos de respaldo.
o Grado de satisfacción de estos usuarios en relación con el
proveedor.
- Apoyo durante la conversión de aplicaciones. Se refiere a la asisten-
cia 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:
o Los antecedentes que tiene el proveedor en el apoyo a otros
clientes en conversiones similares a las requeridas.
o 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.

Analice el ejemplo “Pliego de licitación” cargado en la sección archivos de la uni-

dad 4 en la página web de la materia.

2.4. Métodos de evaluación técnica

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 representati-
vas y más utilizadas por los programas de usuario y sacar un promedio ponde-
rado 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éc-
nicas y lenguajes de simulación con el fin de imitar el funcionamiento de un sis-
tema computacional. Se definen parámetros como tiempo de ejecución, capaci-
dad de memoria principal, acceso a dispositivos de entrada/salida, demanda de
usuarios en terminales, entre otros. Y se generan diferentes escenarios y corri-
das para cada uno de los equipos.
 Método de benchmark: sirve para comparar el rendimiento de uno o varios pro-
gramas de aplicación en diferentes o igual plataforma de hardware. Existen re-
vistas especializadas que periódicamente publican evaluaciones de comparacio-
nes 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 equi-
po propuesto de acuerdo con la medida en que cumple con el factor considera-
do. El equipo o la propuesta que obtiene el mayor puntaje se considera el gana-
dor.

120
2.5. Evaluación financiera
Es el proceso mediante el cual el administrador del proyecto define y evalúa las caracte-
rí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 sustan-
cial.
 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 poste-
rior.
 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.7. Método de benchmark

Ejercicio de evaluación técnica de propuestas.

Introducción

En primer término se podría aplicar un método simple donde prime el aspecto económi-
co en forma exclusiva, y por sobre cualquier otro aspecto. En el caso más optimista po-

121
dría ocurrir que todos los equipos ofrecidos cumplan con los requerimientos mínimos,
aún así, consideramos que esta forma de evaluación no contempla la verdadera poten-
cialidad de cada uno, por lo cual no es recomendable.

En segundo lugar podríamos proponer un método en el que no se plantean limitaciones

presupuestarias, pretendiéndose en términos generales la clasificación de las ofertas en
relación a la máxima potencialidad exclusivamente. Como las limitaciones presupuesta-
rias son por lo general una constante, y en la búsqueda de una decisión racional, consi-
deremos un tercer método.

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.

En función de los beneficios que brinda este tercer método, se expone en forma detalla-
da la implementación del mismo.

 Fase 1: verificación de requisitos mínimos

Esta fase común a todos los procedimientos de evaluación de ofertas, tiene como finali-
dad la verificación de que todas las propuestas cumplan las condiciones mínimas esta-
blecidas en el pliego de especificaciones técnicas, donde se determinan los requerimien-
tos 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:

 Parámetros de selección de hardware

 Parámetros de selección de software
 Soporte de la firma oferente
 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:

 Compatibilidad con otros equipos y dispositivos.

 Posibilidades de ampliación.
 Adaptación de procesos, etc.

122
Hecho este análisis se determinan, a partir de las ofertas aceptadas en el acto de apertu-
ra, las propuestas que cumplen con los requerimientos mínimos exigidos. Los remanen-
tes 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.

Debido a la gran diversidad de ítems a considerar, y con el objeto de mantener una vi-
sión integral de cada propuesta, 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 horizon-
tales las 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 - por el o los responsables del estudio
de las ofertas - a cada una de las características evaluada en los distintos niveles, tenien-
do en cuenta los criterios de evaluación fijados con anterioridad en el pliego, y que de-
bieran 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. Lo dicho es aplicable a atributos de tipo cuantitativo, en tanto que
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 califi-
caciones 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.

Una vez finalizada la clasificación de todos los ítems se obtiene, para cada oferta, un
puntaje que expresa su nivel técnico en relación al resto. Obviamente el más alto co-
rresponde a aquella oferta técnicamente mejor dotada. Se obtiene entonces 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. El siguiente es un
ejemplo muy resumido de lo dicho hasta aquí.

Matriz de selección

Oferentes A B C D
Factor P
Hardware 30 75,61 76,24 82,03 79,46
Software 40 90,33 93,17 92,33 62,33
Soporte de la firma 20 72,5 72,5 96,6 78,33
Pruebas 10 73,82 37,47 57,45 83,37

123
Rendimiento:

A) 2268.30 + 3613.20 + 1450 + 738.20 = 8069.70

B) 2287.20 + 3726.80 + 1450 + 374.70 = 7838.70

C) 2460.90 + 3693.20 + 1932 + 574.50 = 8660.60

D) 2383.80 + 2493.20 + 1566 + 833.70 = 7267.70

Conclusión:

Oferta Costo Rendimiento Costo/Rendimiento Puesto

Oferente U$S
B 74.540 7.838 9.51 1
C 90.094 8.660 10.40 2
D 81.067 7.267 11.14 3
A 107.386 8.069 13.31 4

Hardware: grilla de calificación

C.P.U. / Periféricos Nivel 2 y 3

Oferentes A B C D
Factor P2 P3 N4 N3 N4 N3 N4 N3 N4 N3

C.P.U. 60 67.42 69.90 79.26 69.75

Proces. Cen- 20 50 80 70
tral
Memoria 30 41.41 76.16 40
Principal
Procesadores 50 90 80.83 87.5
de E/S
Periféricos 40 87.90 85.76 86.19 94.03
Unidad de 15 76.66 93.33 93.33
CDROM
Almacén Dis- 30 85.25 91.86 87.83
co Fijo
Unidad de 15 83.33 83.33 96.66
Cinta
Estaciones de 30 95.5 81 99.5
trabajo
Impresoras 10 96.66 78.33 93.33

Nivel 3

Oferta:

124
 A) 1000 + 1242.30 + 4500 = 6742.30 => 67.42

B) 1149.90 + 2557.5 + 1249.95 + 2865 + 966.60 = 8789.95 => 87.90

.....................................
.....................................

Nivel 2

Oferta:
A) 4045.20 + 3516.00 = 7561.00 => 75.61

B) 4194.00 + 3430.40 = 7624.40 => 76.24

C) 4756.60 + 3447.60 = 8203.20 => 82.03

D) 4185.00 + 3761.20 = 7946.20 => 79.46

Hardware: grilla de calificación Nivel 4

Procesador central

Oferente A B C D
Factor P
Designación, modelo XE-5006 5000/30-C NCR-4300 VS-SE
Fecha de anuncio merc. 30 2001 1 1999 3 2000 2 2000 2
Ciclo base 30 300 Mhz. 2 300 Mhz. 2 300 Mhz. 2 350 Mhz. 3
Longitud de palabra 20 64 3 64 3 64 3 64 3
Baterías Back-up 20 no 0 Si 3 Si 3 No 0

Calificación

Oferta:
A) 30 + 60 + 60 + 0 = 150 => 50 %

B) 90 + 60 + 60 + 60 = 270 = > 90 %

C) 60 + 60 + 60 + 60 = 240 = > 80 %

D) 60 + 90 + 60 +0 = 210 => 70 %

A partir del pliego de licitación de ejemplo que se encuentra cargado en la sección de

archivos, unidad 4 de la página web de la materia confeccione una planilla excel que
permita automatizar el proceso de selección de tres ofertas hipotéticas. Envíe por correo
electrónico a su tutor la planilla desarrollada.

2.9. Conceptos sobre benchmark

125
 1- Punto de referencia de cota conocida desde el cual pueden efectuarse medicio-
nes.

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:

o Medición del rendimiento de los sistemas;

o Programas del usuario, proporcionados por un cliente o presunto cliente
como especificación o como codificación real;
o Fase de ajuste, cuyo objeto es optimizar el rendimiento del sistema;
o Comparación del rendimiento optimizado de un sistema de un proveedor
con el de un sistema competitivo, o con otro sistema del mismo provee-
dor.

Benchmark . Problema

Problema tipo, problema patrón.

1- Problema que sirve para evaluar el rendimiento de las computadoras al compa-

rarlas entre sí.

2- Rutina que se emplea para determinar la velocidad de ejecución o de procesa-

miento de una computadora.

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

En un benchmark teórico los programas usan los recursos del sistema de acuerdo a cier-
tos parámetros especificados en tiempo de ejecución. No hace nada productivo con es-
tos 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 adicio-
nes de punto flotante e imprima 5000 líneas, y que luego indique el tiempo total reque-
rido por este benchmark artificial. Si se trata de seleccionar un sistema de computación,
se podría correr este benchmark en diversas configuraciones y luego comparar resulta-
dos.

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 administra-
ció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. Si entre los equipos
puede haber comunicación se trasladan los fuentes, sino, se digita cada uno de ellos.

126
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 recom-
pilar 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.

Un benchmark real 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 - y cómo se los
administra - del equipo y su sistema operativo. Además, 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 además 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 dife-
rentes que puede haber entre los distintos equipos, y/o sistemas operativos, y/o lengua-
jes.

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 len-
guajes. 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 además 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 resulta-
dos son contrapuestos; esto obliga a que se deban realizar los tres tipos de prueba, eva-
luar los resultados, y luego una ponderación que se otorga a cada uno de ellos al hacer el
polinomio de calificación.

127
3. Lanzamiento de un sistema de información
3.1. Contrataciones
El proceso de puesta en marcha de un nuevo sistema de información podría requerir la
contratación de hardware, software y / o servicios. A continuación se presenta una lista,
no taxativa 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, confiabili-
dad, disponibilidad, compatibilidad, modularidad, tecnología, ergonomía, conec-
tividad, tamaño, configuración, costo y soporte.
 Definición de factores de evaluación de software: eficiencia, flexibilidad, segu-
ridad, conectividad, lenguaje, documentación, plataforma de procesamiento, co-
sto, 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 operati-
vos y aplicativos.
 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.
 Objetivos.
 Políticas.
 Descripción de la aplicación.
 Flujo general de trabajo.
 Descripción de procedimientos.
 Pantallas
 Formularios.
 Instructivos.
 Flujogramas de navegación
 Reportes.
 Información sobre reportes.

128
  Muestra del reporte.
 Descripción del reporte.
 Glosario de términos.

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. En general, los afectados por el nuevo
sistema no comprenden realmente la función o el valor de la tecnología de información,
ni tampoco el esfuerzo, en función del tiempo, el compromiso y los recursos necesarios,
para la implantación de sistemas eficaces de información.

Sorprendentemente, incluso los administradores pueden estar mal preparados para dis-
cernir tales temas. Sin embargo, todos afirman ser conscientes de la importancia de la
información para la toma de decisiones y del hecho de que “no hay suficiente” informa-
ción.

Después de una capacitación práctica apropiada, los usuarios deben visualizar los bene-
ficios 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 metodo-
logías y la tecnología de los sistemas de información, sin la cual sería muy difícil usar
apropiadamente los datos y la capacidad de procesamiento implantadas. Los individuos
en la organización que generan, recopilan y usan datos e información, deben también
recibir instrucción y capacitación, de manera que puedan participar eficazmente en la
gestión de la información.

El personal de apoyo a la capacitación debe participar en las etapas del diseño y la im-
plementación de los sistemas. 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 per-

sonal 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 usua-

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

129
  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 in-
terdisciplinario, sin dejar de considerar las necesidades particulares de los dife-
rentes grupos funcionales y profesionales.

Hay que considerar los siguientes grupos destinatarios: los grupos que generan, recopi-
lan y suministran datos; las personas responsables de adoptar decisiones operativas -
profesionales y administradores-; los administradores, los planificadores y los encarga-
dos de formular las políticas; y los administradores de sistemas de información. 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 implemen-
tado.

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.
 Vincular la educación y la capacitación con las experiencias prácticas para lo-
grar 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 pa-
ra permitir la adaptación del material de capacitación a fin de satisfacer las nece-
sidades 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 determi-
nará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 llama-
das solicitando asistencia durante el uso de los sistemas, resulta imprescindible
como etapa final.

130
3.4. Implantación
A los fines de la puesta en marcha del sistema pueden seguirse cuatro métodos de
conversión:

 paralela,
 por fases,
 piloto,
 desmontes repentinos (sustitución)

La operación inicial de un nuevo sistema computacional puede ser una tarea difícil.
Por lo general, este tipo de operación es un proceso de conversión en el que el per-
sonal, los procedimientos, el equipo, los medios de entrada /salida y las bases de da-
tos de un sistema de información antiguos deben convertirse a los requerimientos de
un sistema nuevo.

Las conversiones pueden realizarse en paralelo, según el cual el sistema antiguo y el

nuevo operan hasta que el equipo de desarrollo de proyectos y la gerencia de usua-
rios 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 so-
lucionarse antes de que abandonen el sistema antiguo. La instalación podría realiza-
se también mediante un desmonte directo o una introducción repentina del sistema
recientemente desarrollado. También se pueden llevar a cabo por fases, donde 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 implemen-
tación gradual dentro de una organización. Beneficios similares se generan a partir
del uso de una conversión piloto, donde un departamento u otro sitio de trabajo ac-
tú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.

Sistema antiguo
En paralelo
Sistema nuevo

Sistema Sistema
Antiguo nuevo Piloto

¡Error!
Sistema Sistema
Antiguo nuevo Por fases

Sistema Sistema
antiguo nuevo Introducción
repentina
131
3.5. Mantenimiento de S.I.
Una vez que el sistema se encuentra implementado y que los usuarios finales lo están
operando, comienza el mantenimiento. Esta función constituye la supervisión, evalua-
ción y modificación de sistemas de información operacionales para realizar los mejora-
mientos necesarios o deseados. Por ejemplo, la implementación de un nuevo sistema
usualmente genera el fenómeno que se conoce como “curva de aprendizaje”. El perso-
nal 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 expe-
riencia con el nuevo sistema, estos señalan áreas donde se lo podría mejorar.

El mantenimiento es también necesario para otras fallas y problemas que surgen duran-
te la operación de un sistema. Los usuarios finales y el personal de sistemas de informa-
ción desempeñan entonces una función de solución de problemas, con el fin de determi-
nar las causas de estos y sus soluciones.

La actividad de mantenimiento incluye también un proceso de revisión después de la

implementación, para garantizar que los sistemas recientemente implementados satisfa-
gan 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 mantenimien-
to. Este incluye una auditoría o revisión periódica de un sistema, con el fin de asegurar-
se de que este operando en forma apropiada y de que este logrando sus objetivos. Ade-
más, esta auditoria es para supervisar continuamente el nuevo sistema en busca de pro-
blemas 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 empresa-
rial. 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 empresarial actuales.

132
Índice

Unidad 1: Diseño

1 Introducción.........................................................¡Error! Marcador no definido.

2 Artefactos ............................................................¡Error! Marcador no definido.
2.1 Modelo de diseño ........................................¡Error! Marcador no definido.
2.2 Clases de diseño ..........................................¡Error! Marcador no definido.
2.3 Realización de casos de uso - diseño...........¡Error! Marcador no definido.
2.4 Subsistema de diseño...................................¡Error! Marcador no definido.
2.5 Interfaz.........................................................¡Error! Marcador no definido.
2.6 Descripción de la arquitectura .....................¡Error! Marcador no definido.
2.7 Modelo de despliegue..................................¡Error! Marcador no definido.
3 Trabajadores ........................................................¡Error! Marcador no definido.
3.1 Arquitecto ....................................................¡Error! Marcador no definido.
3.2 Ingeniero de casos de uso ............................¡Error! Marcador no definido.
3.3 Ingeniero de componentes ...........................¡Error! Marcador no definido.
4 Flujo de trabajo....................................................¡Error! Marcador no definido.
4.1 Diseño de la arquitectura .............................¡Error! Marcador no definido.
4.2 Diseño de un caso de uso.............................¡Error! Marcador no definido.
4.3 Diseño de una clase .....................................¡Error! Marcador no definido.
4.4 Diseño de un subsistema .............................¡Error! Marcador no definido.
5 Caso práctico de cierre ........................................¡Error! Marcador no definido.

Unidad 2: Implementación

1. Propósito de la implementación ..................................................¡Error! Marcador no definido.

2. Conceptos preliminares ................................................................ ¡Error! Marcador no definido.
2.1. Implementar el diseño ........................................... ¡Error! Marcador no definido.
2.2. Las pruebas de desarrollo ...................................... ¡Error! Marcador no definido.
2.3. Entornos de desarrollo e integración ..................... ¡Error! Marcador no definido.
2.4. Entorno de desarrollo individual ........................... ¡Error! Marcador no definido.
2.5. Entorno de integración de subsistemas.................. ¡Error! Marcador no definido.
2.6. Entorno de integración del sistema total................ ¡Error! Marcador no definido.
3. El flujo de trabajo implementación .............................................¡Error! Marcador no definido.
3.1. Estructurar el modelo de implementación ............ ¡Error! Marcador no definido.
3.2. Planear la integración ............................................ ¡Error! Marcador no definido.
3.3. Implementar componentes..................................... ¡Error! Marcador no definido.
3.4. Integrar cada Subsistema ....................................... ¡Error! Marcador no definido.
3.5. Integrar el sistema.................................................. ¡Error! Marcador no definido.
4. Actividades ...................................................................................¡Error! Marcador no definido.
4.1. Estructurar el modelo de implementación ............ ¡Error! Marcador no definido.
4.2. Planear la integración del sistema ........................ ¡Error! Marcador no definido.
4.3 Implementar componente ...................................... ¡Error! Marcador no definido.
4.4 Ejecución de pruebas unitarias ............................... ¡Error! Marcador no definido.
4.5 Corregir defectos .................................................... ¡Error! Marcador no definido.
5. Artefactos .....................................................................................¡Error! Marcador no definido.
5.1 Modelo de implementación .................................... ¡Error! Marcador no definido.
5.2 Construcción........................................................... ¡Error! Marcador no definido.
 5.3 Componente............................................................ ¡Error! Marcador no definido.
5.4 Stubs ....................................................................... ¡Error! Marcador no definido.
5.5. Subsistema de implementación ............................. ¡Error! Marcador no definido.
5.6 Interfases................................................................. ¡Error! Marcador no definido.
5.7. La vista del modelo implementación..................... ¡Error! Marcador no definido.
6. Trabajadores .................................................................................¡Error! Marcador no definido.
6.1 Arquitecto de Software........................................... ¡Error! Marcador no definido.
6.2 Implementador........................................................ ¡Error! Marcador no definido.
6.3 Integrador de Sistemas ........................................... ¡Error! Marcador no definido.

Unidad 3: Pruebas

1. Propósito de las pruebas ............................................ ¡Error! Marcador no definido.

2. Conceptos preliminares .............................................. ¡Error! Marcador no definido.
2.1. Psicología y economía de las pruebas ................. ¡Error! Marcador no definido.
2.2. Conceptos básicos ............................................... ¡Error! Marcador no definido.
2.3. Tipos de prueba ................................................... ¡Error! Marcador no definido.
2.4. Etapas de Prueba.................................................. ¡Error! Marcador no definido.
3. Flujo de trabajo de prueba .......................................... ¡Error! Marcador no definido.
3.1. Planificar pruebas ................................................ ¡Error! Marcador no definido.
3.2. Diseñar prueba..................................................... ¡Error! Marcador no definido.
3.3. Implementar prueba............................................. ¡Error! Marcador no definido.
3.4. Realizar pruebas de integración........................... ¡Error! Marcador no definido.
3.5. Realizar prueba de sistema .................................. ¡Error! Marcador no definido.
3.6. Evaluar prueba..................................................... ¡Error! Marcador no definido.
4. Artefactos ................................................................... ¡Error! Marcador no definido.
4.1. Artefacto modelo de pruebas............................... ¡Error! Marcador no definido.
4.2. Artefacto caso de prueba ..................................... ¡Error! Marcador no definido.
4.3. Artefacto procedimiento de prueba ..................... ¡Error! Marcador no definido.
4.4. Artefacto componente de prueba......................... ¡Error! Marcador no definido.
4.5. Artefacto plan de prueba ..................................... ¡Error! Marcador no definido.
4.6. Artefacto defecto ................................................. ¡Error! Marcador no definido.
4.7. Artefacto evaluación de prueba ........................... ¡Error! Marcador no definido.
5. Trabajadores ............................................................... ¡Error! Marcador no definido.
5.1. Diseñador de pruebas........................................... ¡Error! Marcador no definido.
5.2. Ingeniero de pruebas de integración.................... ¡Error! Marcador no definido.
5.3. Ingeniero de pruebas de sistema.......................... ¡Error! Marcador no definido.

Unidad 4: Utilizando PUDS

1 Metodología PUDS ............................................. ¡Error! Marcador no definido.
1.1 PUDS dirigido por casos de uso, centrado en la arquitectura, iterativo e
incremental. ............................................................. ¡Error! Marcador no definido.
1.2 El UP entrega las 6 mejores prácticas .........¡Error! Marcador no definido.
1.3 Ventajas y errores al utilizar el proceso unificado ...... ¡Error! Marcador no
definido.
2 Fases e iteraciones ............................................... ¡Error! Marcador no definido.
2.1 Planificación de las fases.............................¡Error! Marcador no definido.
2.2 Planificación de las iteraciones....................¡Error! Marcador no definido.
 2.3 Evaluación ...................................................¡Error! Marcador no definido.
3 Flujos de trabajo ..................................................¡Error! Marcador no definido.
3.1 Flujos de trabajo fundamentales ..................¡Error! Marcador no definido.
3.2 Dominio del problema y de la solución.......¡Error! Marcador no definido.
3.3 Flujos de trabajo y modelos.........................¡Error! Marcador no definido.

Unidad 5: Implementación del cambio

1. Creación de conocimiento e implementación del cambio organizacional con T.I.

........................................................................................ ¡Error! Marcador no definido.
1.1 La creación del conocimiento con T.I. y la ventaja competitiva¡Error! Marcador
no definido.
2. Adquisición de hardware, software y servicios .......... ¡Error! Marcador no definido.
2.1. Evaluación y selección ........................................ ¡Error! Marcador no definido.
2.2. Elaboración de una Requisición de Propuesta (RFP – Request For Proposal)
¡Error! Marcador no definido.
2.3. Factores a evaluar ................................................ ¡Error! Marcador no definido.
2.4. Métodos de evaluación técnica............................ ¡Error! Marcador no definido.
2.5. Evaluación financiera .......................................... ¡Error! Marcador no definido.
2.6. Alternativas de adquisición y financiamiento ..... ¡Error! Marcador no definido.
2.7. Método de benchmark ......................................... ¡Error! Marcador no definido.
2.8. El método del costo / rendimiento....................... ¡Error! Marcador no definido.
2.9. Conceptos sobre benchmark................................ ¡Error! Marcador no definido.
2.10. Tipos de benchmark .......................................... ¡Error! Marcador no definido.
3. Lanzamiento de un sistema de información ............... ¡Error! Marcador no definido.
3.1. Contrataciones ..................................................... ¡Error! Marcador no definido.
3.2. Documentación.................................................... ¡Error! Marcador no definido.
3.3. Capacitación de usuarios ..................................... ¡Error! Marcador no definido.
3.4. Implantación ........................................................ ¡Error! Marcador no definido.
3.5. Mantenimiento de S.I. ......................................... ¡Error! Marcador no definido.