Formación de Analistas de Sistemas

Informáticos

ANALISIS Y DISEÑO DE
SISTEMAS

Paula Inés Di Rocco

Año 2019
PRESENTACION.

En esta sección presentaremos los lineamientos fundamentales de

este espacio curricular de análisis y diseño de sistemas,
perteneciente a educación terciaria por técnica superior.

Los alumnos y profesores gestionaremos el aprendizaje de este

módulo teniendo en cuenta que utiliza la modalidad de estudio a
distancia a través de IRSO virtual.

Este espacio curricular aborda los saberes propios del análisis y

diseño de sistemas en el marco de la formación específica
contextualizando los científicos, tecnológicos y socioculturales ya
desarrollados a lo largo de la carrera, desarrollando las funciones y
tareas específicas del analista de sistemas.

Estos lineamientos fundamentales con los que debemos trabajar

serán efectivos para poder obtener una comprensión efectiva y
rápida de los conceptos básicos del análisis y diseño de sistemas.

El objetivo de este espacio curricular es llevar los conceptos

estudiados en el mismo a la práctica real para trabajar en la
implementación de sistemas.

Trabajaremos utilizando la presente guía tratando de no alejarnos

del eje principal que la misma nos provee. Haciendo un seguimiento
de la misma, podremos ir estudiando los conceptos fundamentales
asociados al análisis y diseño.

1
En la guía se enuncian los diferentes conceptos teóricos y ejemplos
de aplicación de los mismos. Sobre este material de estudio, se
recomienda una lectura lenta y comprensiva, releyendo en forma
reiterada todo aquello que el alumno no comprenda.

A su vez, metodológicamente, cada semana tendrán acceso a una

clase teórica y otras actividades académicas, en las cuales los
alumnos deberán consolidar, integrar y ampliar los conocimientos
enfrentando situaciones propias del ejercicio de la profesión

Al comienzo de la clase teórica figurarán estratégicamente los

conceptos de la unidad que previamente deberán leer y además las
actividades académicas que deberán resolver para afianzar los
conceptos mencionados.

El material de estudio consta del presente apunte, al que podrán

asociarse diferentes libros y manuales de los que oportunamente
haremos llegar títulos y e ítems de lecturas recomendadas.

El aprendizaje de los saberes de este espacio curricular también se

complementará utilizando la herramienta del chat que permitirá al
alumno la posibilidad de interactuar con el profesor y compañeros
con la finalidad de consultar, mencionar o aclarar dudas sobre
diversos temas afines la materia.

2
Es importante para el alumno la utilización de la herramienta de
foro que también provee nuestro campus virtual. En el módulo o en
las clases se utilizará:

Foro.

El ícono Foro avisará al alumno la posibilidad de acceso al mismo.

Allí se tratarán temas, conceptos, cuestiones específicas del
contenido del curso. El foro se utilizará como espacio de reflexión
compartida y debate que ayudarán al alumno a abordar y afianzar
diferentes conceptos del análisis y diseño de sistemas.

A lo largo del módulo se podrán visualizar otros íconos que ayudarán

a los alumnos a afianzar diversos conceptos importantes. Se
utilizarán:

Atención o recuerde.

El icono de Atención o recuerde es para aquellas definiciones o

textos breves que deben recordar o son conceptos claves que se
usarán a lo largo del módulo.

Lea con atención.

El icono de Lea con atención será usado cuando el texto para leer
con atención es largo y tal vez de allí surge una actividad o un
ejemplo posterior.

Luego de la primera mitad del curso, el alumno deberá realizar un

trabajo práctico que permitirá de alguna manera conocer si está
manejando correctamente cada uno de los elementos que iremos
proponiendo a lo largo de la cursada.

3
Las respuestas al trabajo práctico serán recibidas de modo que
puedan ser evaluadas por la cátedra. El segundo trabajo práctico se
realizará sobre el final de la cursada, y por las características de
desarrollo de la materia, el carácter del mismo será de integración de
todos los temas tratados.

La asignatura es de un peso importante en cuanto al tiempo de

dedicación por parte del alumno, para poder ir desarrollando todo el
contenido de la misma, de modo que es recomendación de la
cátedra una dedicación horaria no inferior a cuatro horas reloj
semanales para poder ir distribuyendo de modo adecuado los
tiempos y contenidos de la misma.

El examen final se rendirá en la habitual forma presencial, en alguna

de las fechas que oportunamente haremos llegar con el calendario,
que contempla dos llamados para los exámenes de Marzo, dos para
los de Diciembre y uno para Julio. El temario del examen final es
abarcativo del programa de la asignatura en su totalidad.

Las consultas con el profesor titular de la asignatura pueden hacerse

al teléfono/fax 4342-2357, por e-mail al correo electrónico
virtual@irso.edu.ar o a través del chat, foro o envío y recepción de
clases en el campus virtual. Personalmente, en el Instituto Raúl
Scalabrini Ortiz, Bmé. Mitre 970 – 5ºPiso - Capital Federal de lunes a
viernes de 19 a 20 horas.

Objetivos del espacio curricular Análisis y Diseño de Sistemas.

Los alumnos lograrán adquirir las herramientas y conocimientos

necesarios para el análisis, la planificación e implementación de la

4
etapa del diseño de un sistema pudiendo determinar con precisión el
papel del analista en todas las etapas de un proyecto.

Además los alumnos aprenderán los elementos y conceptos

necesarios para incorporar una metodología de trabajo para la tarea
de análisis y diseño de sistemas, que permita al analista desarrollar
su producto interactuando de manera efectiva con todos los
trabajadores y usuarios del proyecto de sistema de información.

5
INDICE.

Presentación. 001

Índice. 006

Unidad 1: Conceptos Preliminares Sobre Sistemas. 011

1. Definición de sistemas. 010

2. Clasificación de sistemas. 011
3. Los actores en los sistemas de información. 015
4. Orígenes de solicitud de un sistema. 025
5. Solicitud de un proyecto. 030
6. Administración de la revisión y selección de un 032
proyecto.
7. Requerimientos de un sistema. 037
8. Selección y contrato del software. 041
9. Recolección de datos. 049
10. La importancia de una Metodología. 060

Unidad 2: Primeros Pasos en el Proceso Unificado. 062

1. Definición de análisis y diseño de sistemas. 062

2. Definición de objeto. 064
3. Definición de análisis y diseño orientado a objetos. 065
4. Definición de programación orientada a objetos. 065
5. El software y su complejidad. 066
6. Técnicas para dominar la complejidad del software. 072

6
7. Método y Metodología. 074
8. Abstracción y Jerarquía. 075
9. El Proceso Unificado. 076
10. Importancia de los 3 conceptos básicos del Proceso 084
Unificado.

Unidad 3: La vida de Proceso Unificado. 086

1. El Modelo o Producto del Proceso Unificado. 086

2. Los Modelos dentro del Proceso Unificado. 088
3. Relación entre los Modelos y su Vista Autocontenida. 089
4. El Proceso y las Personas. 090
5. La incidencia del Proceso en las Personas. 092
6. El Proceso y los Flujos de Trabajo. 093
7. El Proceso y las Fases en un Ciclo. 095

Unidad 4: Casos de Uso dirigen el Proceso. Flujos de Trabajo y

Modelos. 101

1. Flujos y Modelos. 101

2. Los Modelos. 102
3. Objetivos de los Casos de Uso. 105
4. Modelo de Casos de Uso. 108
5. Modelo de Análisis. 111
6. Modelos de Diseño. 114
7. Modelo de Implementación. 117
8. Modelo de Prueba. 117

7
Unidad 5: La arquitectura dirige el Proceso. 119

1. La arquitectura. 119
2. Descripción de la arquitectura. 120
3. Objetivos de la arquitectura. 122
4. Restricciones de la arquitectura. 122
5. Desarrollo de la arquitectura. 124
6. Patrones de la arquitectura. 125

Unidad 6: Las iteraciones dirigen el Proceso. 127

1. Iteraciones, fases, hitos y fases del Proceso. 127

2. Objetivos de las iteraciones. 128
3. La iteración. 130
4. El ciclo de vida y las iteraciones. 133

Unidad 7: Captura de Requisitos. 136

1. Objetivo del flujo de trabajo de los requisitos. 136

2. Pasos a seguir en el flujo de trabajo de requisitos. 140
3. Enumerar requisitos candidatos. 140
4. Comprender el contexto del sistema. 140
5. Capturar requisitos funcionales. 142
6. Capturar requisitos no funcionales. 143
7. Los requisitos en el Ciclo de Vida. 144
8. Lista de características. 146
9. Modelo de Dominio. 147
10. Modelo de Negocio. 150
11. Requisitos adicionales. 153

8
 Unidad 8: Casos de Uso. 155 1

1. Modelo de casos de uso 155

2. Actor en los casos de uso. 158
3. Casos de uso. 158
4. Descripción de la arquitectura, Glosario y 162
Prototipo de Interfaz de usuario.
5. Trabajadores en los casos de uso. 163
6. El flujo de trabajo de la captura de 165
requisitos.
7. Encontrar actores y casos de uso. 166
8. Descripción de cada caso de uso. 172
9. Descripción del modelo de caso de uso 172
10. Priorizar casos de uso. 173
11. Detallar casos de uso 174
12. Interfaces de usuario. 179
13. Estructuración del Modelo de Casos de Uso 182

Unidad 9: Análisis. 186

1. Objetivo del análisis. 186

2. Papel del análisis en el Ciclo de vida. 189
3. Modelo de Análisis. 191
4. Clases de análisis. 192
5. Clases de interfaz, de entidad, de control. 193
6. Realización de casos de uso – análisis. 195
7. Trabajadores en el análisis. 199

Glosario. 201
Bibliografía. 219
Modelo de Examen. 221

9
ANALISIS Y DISEÑO DE SISTEMAS.

Unidad I: Conceptos Preliminares sobre Sistemas.

1. Definición de sistemas.
2. Clasificación de sistemas.
3. Los actores en los sistemas de información.
4. Orígenes de solicitud de un sistema.
5. Solicitud de un proyecto.
6. Administración de la revisión y selección de un proyecto.
7. Requerimientos de un sistema.
8. Selección y contrato del software.
9. Recolección de datos.
10. La importancia de una Metodología.

1. Definición de Sistema.

Un sistema es un conjunto de elementos interrelacionados, con

un objetivo en común. A su vez, cada elemento puede estar
dividido en otras partes que interactúan entre sí y éstas pueden
constituir otro sistema más pequeño que se llama subsistema.

10
 Dentro de un sistema, sus elementos o subsistemas que lo
conforman, conviven y trabajan entre sí para alcanzar una meta u
objetivo común.

2. Clasificación de los sistemas.

Una de las clasificaciones más básicas de los sistemas es

dividirlos en abiertos y cerrados. Estos son aquellos que no se
relacionan con el medio ambiente. Son sistemas teóricos como
algunos conjuntos de elementos matemáticos. En la práctica no
existen. Los sistemas abiertos son los que sí se relacionan con su
medio ambiente, es decir, reciben un estímulo y responden en
función de él.

Dentro de los sistemas abiertos, que son los que tendremos en

cuenta, existe una gran diversidad de clasificaciones. Podemos
clasificar los sistemas abiertos en sistemas naturales y los
hechos por el hombre.

Dentro de los sistemas naturales podemos dividir en sistemas

físicos y sistemas vivientes. Los sistemas físicos pueden ser
entre otros: estelares (galaxias, sistemas solares, etc), sistemas
geológicos (ríos, cordilleras, etc) sistemas moleculares
(organizaciones complejas de átomos). Los sistemas vivientes
comprenden toda gama de plantas y animales que nos rodean y
la raza humana. Es interesante estudiar estos sistemas pues a
veces queremos modificarlos o cambiarlos.

Desarrollamos una gran cantidad de sistemas hechos por el

hombre que deben interactuar con los naturales en forma
armoniosa. Un marcapasos computarizado controla y ayuda al
corazón humano, interactúan entre ellos. Dentro de estos

11
sistemas podemos destacar sistemas sociales (organizaciones
de leyes, doctrinas, costumbres, etc), sistemas de transportes
(redes de carretera, canales, aerolíneas, buques cargueros),
sistemas de comunicación (teléfono, señales de humo, señales
de manos), sistema de manufactura (fábricas, líneas de
ensamblado, etc), sistemas financieros (contabilidad,
inventarios, bolsas de valores), etc.

La mayoría de estos sistemas hoy en día, incluyen computadoras

y no podrían subsistir sin ellas. Pero algunos se manejan con su
ausencia. Es por esto que los sistemas hechos por el hombre se
dividen en computadorizados y manuales. En la mayoría de los
casos uno supone que los sistemas de información deberían ser
computarizados y muchas veces los analistas de sistemas
estudian el comportamiento de un sistema para determinar que el
mismo no requiere de computadoras para su correcto
funcionamiento. Todo esto depende del costo, de la conveniencia,
de la seguridad, de la facilidad de mantenimiento, de diversas
políticas, etc.

Con frecuencia, no se advierte pero un negocio también es un

sistema. Sus componentes son mercadotecnia, producción,
ventas, compras, investigación, embarque, contabilidad,
personal, sistemas. Todos estos sectores trabajan en conjunto
para crear una utilidad que beneficie a los empleados y
accionistas de la empresa. Cada uno es un sistema en sí mismo y
se lo llama sistema de negocio.

Cada sistema de negocio depende de una o más entidades

abstractas llamadas sistemas de información. Los sistemas de
información sirven a los sistemas de negocio.

12
Los sistemas de información son como cualquier otro sistema
dentro de una empresa pues tienen propósitos e interactúan con
otros imponentes de la empresa. Su tarea consiste en procesar la
entrada, mantener archivos de datos en relación con la empresa
y producir información, informes y otras salidas.

En las empresas los analistas de sistemas desarrollan dos tipos

de sistema de información: sistemas de procesamiento de
transacciones y sistemas de decisiones administrativas.

Los sistemas de procesamiento de transacciones mejoran la

actividad diaria de los cuales dependen las empresas. Las
actividades son de rutina, ocurren con frecuencia y en la misma
forma. Existen manuales y computarizados, cuyo objetivo básico
es la eficiencia, velocidad y exactitud en el procesamiento de
grandes cantidades de datos.

Los sistemas de decisiones administrativas se utilizan para dar

apoyo directo a los gerentes responsables de la toma de
decisiones dentro de la empresa. No les dice cómo tomar la
decisión pero les ayuda dándoles información importante que les
servirá al proceso de decisión.

A su vez, estos sistemas se dividen en sistemas de información

gerencial y sistemas de apoyo a la toma de decisiones.

Los sistemas de información gerencial proporcionan

información en forma periódica para ayudar a los gerentes con las
decisiones que surjan y que puedan anticiparse. Entonces son
estructurados y tienen un formato predeterminado por el
desarrollador de sistemas.

13
Los sistemas de apoyo a la toma de decisiones, en contraste
apoyan a la toma de decisiones que está menos estructurada y no
rutinaria, es decir, aquellas decisiones donde parte del proceso de
decisión consiste en definir qué información es la necesaria y al
manera de utilizarla. El gerente define los formatos de los
informes durante el proceso real de decisión. No se desarrollan
antes de tiempo, los gerentes trabajan en forma interactiva con
una terminal. Los desarrolladores deben diseñar sistemas con la
flexibilidad necesaria para dar apoyo a los análisis especiales y a
las consultas no planeadas.

Existe otra clasificación dentro de los sistemas computarizados o

automatizados: sistemas on line, sistemas batch, sistemas web o
distribuídos y sistemas de tiempo real.

Los sistemas on line son aquellos sistemas donde el usuario

interactúa con él, es decir, el sistema funciona solamente si el
usuario ingresa un dato.

Los sistemas batch son aquellos donde el sistema funciona

autónomamente dependiendo de un recorrido secuencial de algún
grupo de datos. No dependen de la interacción del usuario.

Los sistemas web o distribuídos son aquellos cuyos

componentes de hardware y software están en ordenadores
conectados en red que se comunican y coordinan sus acciones
mediante el paso de mensajes, para el logro de un objetivo. Se
establece la comunicación mediante un protocolo prefijado por un
esquema cliente-servidor.

14
 Estos sistemas de distribución de información están basados en
hipertextos o hipermedios enlazados y accesibles a través de
Internet. Con un navegador web, un usuario visualiza sitios web
compuestos de páginas web que pueden contener texto,
imágenes, videos u otros contenidos multimedia, y navega a
través de ellas usando hiperenlaces.

Los sistemas de tiempo real son aquellos donde el

funcionamiento del mismo depende del paso del tiempo. Son
sistemas que funcionan como los on line, es decir, con la
interacción del usuario pero si éste está ausente y trascurre un
corto período de tiempo, el sistema funciona en forma autónoma.

Son muy interesantes los sistemas basados en el conocimiento

o sistemas expertos. Son aquellos que se construyen de tal
manera que sean capaces de explicar las líneas de razonamiento
que llevaron a las decisiones que tomaron. Explican incluso por
qué descartaron ciertos caminos de razonamiento y por qué
escogieron otros. Los sistemas expertos se utilizan por ejemplo en
el campo de la medicina donde se llevan a cabo diagnósticos y
procesos terapéuticos. Es un asistente inteligente pues es un
apoyo de alto nivel intelectual para el experto humano. Estos
sistemas contienen grandes cantidades de diversos
conocimientos que emplean en el desempeño de una tarea dada.
Estos sistemas se asocian en el campo de la inteligencia artificial.

Foro. Una Transacción y Tiempo Real.

3. Los actores en los sistemas de información.

Dentro de una empresa todos los sectores se relacionan entre sí

tendiendo hacia un objetivo común. Este objetivo es algo

15
concreto, es el producto final de la empresa. La información que
circula en una empresa es la que hace que todos los sectores
terminen de vincularse entre sí. La información es un elemento
abstracto y su manejo es complejo.

El analista de sistemas es un personaje clave dentro de la

empresa. Su tarea es clave en cualquier proyecto de desarrollo
de sistemas. Su rol es muy importante pues es la persona que
se ocupa de diversas tareas todas ellas tendientes al manejo de la
información dentro de una empresa.

Se ocupa de diversas tareas todas ellas tendientes al manejo de

la información. No lleva a cabo una sola tarea.

Debido a que el analista de sistemas trabaja en el medio de

usuarios, administradores, programadores, ejecutivos y auditores,
entre otros, debe obtener un consenso entre todos ellos haciendo
uso de su arte en la diplomacia y la negociación.

Como vemos en una empresa existen varias personas que

conviven entre sí, todos ellos cumplen con un rol realizando
tareas específicas que tienden al cumplimiento de un mismo
objetivo.

Entonces podemos definir a estas personas que conviven en la

empresa, utilizando el sistema de información como actores. Y
podemos clasificarlos en cinco grupos:

1. Dueños del Sistema.

2. Usuarios del Sistema.

3. Diseñadores de Sistemas.

16
4. Constructores de Sistemas.

5. Analistas de Sistemas.

Ahora explicaremos cada uno de estos grupos.

1. Dueños del Sistema

Para cualquier sistema de información grande o pequeño habrá

uno o más dueños del sistema, los dueños del sistema tienden a
estar interesados en: ¿cuánto costara el sistema?, ¿cuál será el
costo/beneficio?, ¿cuándo recuperaran la inversión y como la
recuperaran?, etc.… Este grupo es que paga por el sistema.

2. Usuario del Sistema

Los usuarios del sistema son lo que definen los requerimientos del
negocio y las expectativas del sistema.

Ellos ven a un sistema de información en términos de la

funcionalidad que provee a sus trabajos, en que sea fácil de
aprender y de utilizar.

Hay muchas clases de usuarios, pero para estudiarlos los

separaremos en dos grandes clases: Usuarios Internos y Usuarios
Externos dentro de los cuales se cuenta con más subdivisiones
las cuales se explican a continuación.

17
Usuarios Internos: Son aquellos empleados del negocio para el
cual se está construyendo el sistema y son el mayor porcentaje de
usuarios de un sistema. Dentro de este grupo tenemos:

Empleados administrativos y de servicios: realizan los procesos

del día a día, procesan órdenes, facturas, pagos etc. Ellos
capturan los datos en el sistema.

Staff técnico y profesional: son empleados que realizan tareas

especializadas ej. Abogados, ingenieros, científicos etc.

Supervisores, mandos medios y ejecutivos: son los empleados

que toman decisiones, ya sea decisiones del día a día
(supervisores), de corto plazo (mandos medios) o largo plazo
(ejecutivos).

Usuarios Externos: El uso de Internet ha permitido extender los

límites de las organizaciones, de forma que se ha generado un
aumento de usuarios externos, dentro de los cuales podemos
mencionar:

Clientes: son cualquier organización o persona(s) que compren

nuestros productos o servicios. Hoy día nuestros clientes se
pueden convertir en usuarios directos, ya que pueden ejecutar
ordenes y compras directamente al sistema, como por ejemplo
las compras online.

Surtidor o Proveedor: son cualquier organización en la cual

nuestra compañía compre insumos. Hoy día nuestros
proveedores pueden interactuar directamente con nuestros
sistemas y determinar nuestra necesidad de insumos y crear de
forma automática ordenes con dichas necesidades.

18
 Socios: son cualquier organización a la cual nuestra compañía
compre servicios o de la que sea socio. Ejemplo:
mantenimiento, manejo de la red, outsourcing, etc.

Empleados: son empleados que trabajan en el camino o en

casa. Ejemplo: representantes de venta, empleados que
puedan trabajar remotamente en el sistema.

La cantidad de usuarios externos ha ido en aumento en los

últimos tiempos, ellos se conectan a la información de la
compañía a través de laptops, handhelds y smartphones (ya sea
con conexión en bases o vía inalámbrica) por lo que debemos
tener presente el uso de estos dispositivos al momento de realizar
el diseño del sistema.

3. Diseñadores del Sistema.

Son técnicos especializados que traducen los requerimientos de

los usuarios del negocio en soluciones técnicas. Ellos diseñan:
bases de datos, entradas y salidas del sistema, pantallas, redes y
software que se puede adaptar a los requerimientos del usuario.

Un diseñador del sistema puede pertenecer a algunas de las

siguientes especialidades:

Administrador de la base de datos: son especialistas en bases

de datos, se encargan de realizar el diseño de la base de
datos, y la coordinación de cambios en bases de datos
corporativas.

19
 Arquitectos de redes: se especializan en redes y
telecomunicaciones.

Arquitectos Web: se encargan de diseñar sitios web para las

organizaciones, generalmente de un alto grado de complejidad.

Artistas Gráficos: son especialistas en la tecnología grafica y en

métodos de diseño de interfaces fáciles de utilizar. (en pc, web,
handheld, smartphones, etc)

Expertos en Seguridad: son en especialistas en tecnología y

metodologías utilizadas para asegurar la integridad y la
privacidad de los datos y la red.

Especialistas en tecnología: son expertos en la aplicación de

tecnologías especificas que podrían ser utilizadas en un
sistemas. Tanto en paquetes de software como en hardware
con características especificas.

4. Constructores del Sistema.

Su rol es la construcción del sistema de acuerdo a las

especificaciones dadas por el diseñador de sistemas.

Un constructor del sistema puede pertenecer a algunas de las

siguientes especialidades:

Programador de Aplicaciones: son especialistas que

convierten los requerimientos de la compañía en lenguajes de

20
 programación. Ellos desarrollan y prueban programas de
computación que capturan y almacenan datos.

Programadores de Sistemas: son especialistas que desarrollan,

prueban e implementan software a nivel de sistema operativo.

Programadores de Bases de Datos: son especialistas en

tecnologías y lenguajes de bases de datos, que construyen,
modifican y prueban las estructuras de las bases de datos así
como los programas que se utilizan para darles mantenimiento
a las mismas.

Administrador de Redes: son especialistas que diseñan,

instalan y optimizan las redes de computadoras.

Administradores de la Seguridad: son especialistas que

diseñan, implementan y manejan la seguridad y controles de
privacidad de una red.

Webmaster: son especialistas que codifican y dan

mantenimiento a los servidores Web.

Integradores de Software: son especialistas que integran

paquetes de software con hardware, redes y otros paquetes de
software.

5. Analista de Sistemas.

Es un especialista que estudia los problemas y necesidades de

una organización para determinar cómo las personas, datos,

21
procesos y la tecnología de la información pueden en conjunto
mejorar un negocio.

Roles del Analista de Sistemas.

El analista de sistemas evalúa de manera sistemática el

funcionamiento de un negocio mediante el examen de la entrada,
el procesamiento de datos y su consiguiente producción de
información, con el propósito de mejorar los procesos de una
organización. Muchas mejoras incluyen un mayor apoyo a las
funciones de negocio a través del uso de sistemas de información
computarizados.

Un analista debe tener la capacidad de trabajar con todo tipo de

gente y contar con suficiente experiencia en computadoras. El
analista desempeña diversos roles, en ocasiones varios de ellos
al mismo tiempo. Los tres principales roles del analista de
sistemas son el de consultor, exporto en soporte técnico y agente
de cambio.

El Rol de Consultor del Analista de Sistemas.

Con frecuencia, el analista de sistemas desempeña el rol de

consultor para un negocio y, por tanto podría ser contratado de
manera especifica para enfrentar los problemas de sistemas de
información de una empresa. Esta contratación se puede
traducir en una ventaja porque los consultores externos tienen
una perspectiva fresca de la cual carecen los demás miembros
de una organización. También se puede traducir en una
desventaja porque alguien externo nunca conocerá la
verdadera cultura organizacional. En su función de consultor
externo, usted dependerá en gran medida de los métodos
sistemáticos que se deberá aprender de los libros sobre el
análisis y diseño de sistemas de información. Además tendrá

22
que apoyarse en los usuarios de los sistemas de información
para entender la cultura organizacional desde el punto de vista
que ellos tienen.

El Rol de Experto en Soporte Técnico del Analista de Sistemas.

Otro rol que tendrá que desempeñar es el de experto en

soporte técnico dentro de la empresa en la cual labora de
manera regular. En este rol el analista recurre a su experiencia
profesional con el hardware y software de cómputo y al uso que
se le da en el negocio. Con frecuencia, este trabajo no implica
un proyecto completo de sistemas, sino más bien la realización
de pequeñas modificaciones o la toma de decisiones que se
circunscriben a un solo departamento.

Como experto en soporte técnico, usted no esta a cargo del

proyecto, tan solo actúa como recurso para aquellos que si lo
están. Si usted es un analista de sistemas contratado por una
empresa manufacturera o servicios, gran parte de sus
actividades podrían ajustarse a este rol.

El rol de Agente de Cambio del Analista de Sistemas

El rol más completo y de mayor responsabilidad que asume el

analista de sistemas es el de agente de cambio, ya sea interno
o externo para la empresa. Como analista, usted es un agente
de cambio si desempeña cualquiera de las actividades
relacionadas con el ciclo de vida del desarrollo de sistemas y
esta presente en la empresa durante un largo periodo (de dos
semanas a más de un año). Un agente de cambio se puede
definir como alguien que sirve de catalizador para el cambio,
desarrolla un plan para el cambio y coopera con los demás
para facilitar el cambio.

23
 Su presencia en el negocio inicia el cambio. Como analista de
datos, usted debe estar consciente de este hecho y utilizarlo
como punto de partida para su análisis. De ahí que tenga que
interactuar con los usuarios la administración desde el principio
del proyecto. Sin su colaboración usted no podría entender lo
que ocurre en una organización y el cambio real nunca se
daría.

Si el cambio (es decir, las mejoras al negocio que se pueden

concretar mediante los sistemas de información) parece factible
después de efectuar el análisis, el siguiente paso es desarrollar
un plan para el cambio de manera conjunta con quienes tienen
la facultad de autorizarlo. Una vez que se haya alcanzado el
consenso acerca de los cambios por realizar, usted tendrá que
interactuar constantemente con quienes vaya a cambiar.

En su calidad de analista de sistemas desempeñando la

función de agente de cambio debe promover un cambio que
involucre el uso de los sistemas de información. También es
parte de su tarea enseñar a los usuarios el proceso del cambio,
ya que las modificaciones a un sistema de información no solo
afecta a este sino que provocan cambios en el resto de la
organización.

Cualidades del Analista de Sistemas.

De las descripciones anteriores sobre los roles que desempeña el

analista de sistemas, se deduce fácilmente que el analista exitoso
debe contar con una amplia gama de cualidades. Hay una gran
diversidad de personas trabajando como analistas de sistemas,
por lo que cualquier descripción que intente ser general esta
destinada a quedarse corta en algún sentido. No obstante, la

24
 mayoría de los analistas de sistemas tienen algunas cualidades
comunes.

En primer lugar, el analista es un solucionador de problemas. Es

una persona que aborda como un reto el análisis de problemas y
que disfruta al diseñar soluciones factibles. Cuando es necesario,
el analista debe contar con la capacidad de afrontar
sistemáticamente cualquier situación mediante la correcta
aplicación de herramientas, técnicas y su experiencia.

El analista también debe ser un comunicador con capacidad para

relacionarse con los demás durante extensos periodos. Necesita
suficiente experiencia en computación para programar, entender
las capacidades de las computadoras, recabar los requisitos de
información de los usuarios y comunicarlos a los programadores.
Asimismo, debe tener una ética personal y profesional firme que
le ayude a moldear las relaciones con sus clientes.

El analista de sistemas debe ser una persona autodisciplinada y

automotivada, con la capacidad de administrar y coordinar los
innumerables recursos de un proyecto, incluyendo a otras
personas. La profesión de analista de sistemas es muy exigente;
pero es una profesión en constante evolución que siempre trae
nuevos retos.

Foro. Implementación. Una función del Analista.

4. Orígenes de solicitud de un sistema.

Las aplicaciones de sistemas de información se originan

virtualmente en todas las áreas de la compañía y se refieren a
una cantidad de diferentes problemas de negocios. Los orígenes
de solicitud de un proyecto son los lugares de la empresa donde

25
puede surgir un problema a resolver y en consecuencia se origina
la necesidad de solicitar una propuesta de aplicación.

Los usuarios solicitan proyectos de sistemas de información por

diferentes razones. A veces es para solucionar un problema,
como la reducción de costos, realizar ciertas tareas o mejorar el
control de trabajo que se lleva a cabo. Otras veces es para
mejorar la eficiencia del trabajo realizado en los departamentos.
Existen variados motivos para requerir ayuda de sistemas de
información.

Las computadoras procesan datos muy rápidamente y su

velocidad es una de las razones por las que la gente busca el
desarrollo de proyectos de sistemas. En estos casos se requiere
la capacidad de las computadoras para calcular, clasificar y
consultar datos e información a una mayor velocidad.

En ocasiones se solicitan los proyectos de sistemas de

información para mejorar la exactitud de los datos procesados o
para asegurar que siempre se siga un procesamiento que
prescribe cómo realizar una tarea específica.

Las empresas almacenan grandes cantidades de datos sobre sus

operaciones, empleados, clientes, proveedores, finanzas. Se
necesita saber dónde almacenar los datos y cómo consultarlos
cuando se necesitan. El almacenamiento de datos se vuelve más
complejo si los usuarios desean recuperar los datos en varias
formas en distintas circunstancias.

26
En muchos negocios, el trabajo hecho en determinada área es
coordinado con el que se lleva a cabo en otra. Los sistemas de
información se utilizan para integrar las actividades que se
expanden alrededor de diversas áreas de la empresa.

Algunos diseños de sistemas permiten que se realice la misma

cantidad de trabajo a menor costo. Es decir, si se acepta la
ventaja del cálculo automatizado y de las capacidades de
recuperación que se pueden incluir en los programas que
conforman las aplicaciones.

La mayoría de las tareas se pueden llevar a cabo en forma

automatizado aunque alguna de ella se continúa desarrollando en
forma manual. Ahorrar dinero es atractivo para los gerentes de la
empresa. Los procedimientos automatizados del negocio pueden
hacer cambiar la naturaleza del trabajo aunque la necesidad de
personal normalmente no decrece. Los empleados no son
reemplazados y, de hecho, su trabajo puede convertirse en algo
más interesante si las tareas tediosas se automatizan.

Los datos se almacenan proporcionando una seguridad que sería

difícil de alcanzar en un ambiente no automatizado. La facilidad
en la exactitud de los cálculos de grandes cantidades de datos, el
acceso a los datos en forma restringida y la encriptación de los
datos hacen que la información se almacene y se brinde en forma
segura.

27
 Mayor velocidad en el
proceso.
Mayor exactitud y mejor
consistencia
Consulta más rápida de la
información
Integración de las áreas
del negocio
Reducción de costos
Mayor seguridad.
Utilizar la capacidad de la
computadora para calcular,
clasificar y consultar datos e
información cuando se desea
una mayor velocidad que la del
personal que efectúa las mismas
tareas.
Llevar a cabo correctamente y en
la misma forma cada vez las
etapas de cálculo que incluyen
aritmética.
Localizar y consultar información
del almacenamiento. Efectuar
rastreos complejos.
Coordinar las actividades del
negocio que se realizan en forma
separada de la empresa a través
de la captación y distribución de
la información.
Utilizar la capacidad de cómputo
para procesar datos a un costo
menor que con otros métodos,
mientras se mantiene la exactitud
y los niveles de rendimiento.
Salvaguardar los datos
confidenciales e importantes, de
manera que sean accesibles
solamente para aquellas
personas que tengan
autorización.

Existen cuatro orígenes principales de solicitudes de proyecto:

Los gerentes de departamentos, los ejecutivos de alto nivel, los
analistas del sector de sistemas y los grupos externos a la
empresa.

Los gerentes de departamentos de la empresa suelen elevar

luna solicitud de un proyecto cuando necesitan solucionar algún
problema inherente a su sector, una actividad de operación diaria
necesita mejoras o se necesita mejorar la eficiencia de un trabajo,
Estas solicitudes se enfocan en un aspecto específico del

28
departamento o sector. El gerente de departamento que solicita
un proyecto no suele tener en cuenta la interacción con otros
departamentos Estos proyectos no suelen ser amplios y
abarcativos a toda la empresa, no benefician a otros
departamentos.

Los ejecutivos de alto nivel, como los presidentes o

vicepresidentes de la empresa tienen información que no están
disponibles para los gerentes de los departamentos. Esta
información junto con las amplias responsabilidades que ellos
asumen influye directamente en los requerimientos de los
proyectos que ellos solicitan. Estos proyectos son más amplios
que los proyectos departamentales. Estos proyectos suelen incluir
a varios departamentos. Los proyectos que incluyen a múltiples
sectores son más difíciles de administrar y controlar
comparándolos con los departamentales. Por otro lado tienen
menor probabilidad de éxito, pues son más amplios y más
costosos.

Los analistas del sector de sistemas de la empresa también

pueden originar solicitudes de proyectos. Ellos detectan áreas
donde los problemas se deben solucionar. Por eso, muchas veces
originan proyectos que son motivaciones a otros departamentos.
A su vez, los profesionales y desarrolladores del área de
sistemas son usuarios. Por lo tanto, pueden solicitar pedidos de
proyectos que están relacionados directamente con su sector.
Sistemas operativos, sistemas de administración de proyectos,
herramientas de lenguaje de programación, o cambios de equipos
son ejemplos de solicitudes de proyectos originados por los
analistas de sistemas. Estos proyectos tienen menor prioridad que
los propios de la empresa.

29
 Los diferentes acontecimientos fuera de la compañía también
originan solicitudes de proyectos. Los grupos externos a la
empresa, por ejemplo organismos gubernamentales requieren
que las empresas usen sistemas especiales para contabilidad,
economía, leyes. Surgen diversas leyes u ordenanzas que las
empresas deben cumplir. Por lo tanto los proyectos que surgen
por este motivo tienen máxima prioridad con respecto a los
propios de la empresa y además tienen el mismo nivel de
importancia.

5. Solicitud de un proyecto.

Ante un problema existente en un sector de la empresa, el usuario

pide una solución ante el comité de selección de un proyecto.
Este comité se encarga de revisar los pedidos solicitados y decide
cuál encarar para su desarrollo. Este pedido que realizan los
usuarios de un sector debe estar contenido en una propuesta
formal.

La propuesta del proyecto es un elemento crítico para iniciar el

estudio de sistemas. Aunque la forma de tal solicitud varía de
acuerdo a cada empresa, existe un acuerdo general sobre la
clase de información que debe proporcionarse.

En esta propuesta, quién realiza esta petición identifica la

situación dónde se necesita y proporciona detalles. Esto es
importantísimo para los miembros del comité de revisión, pues es
útil que ellos conozcan por qué quien hace la petición piensa que
el proyecto es importante. Por lo tanto, el informe debe contener
el significado del problema o situación.

30
El comité debe conocer si la solicitud del proyecto surgió por un
solo evento o su causa se debe a una situación recurrente. Si
existe un contínuo problema de control.

No siempre existe una situación clara y sencilla del problema. Es

útil que la persona que hace la petición del proyecto proporcione
también los nombres de otros individuos con los que se pueda
hacer contacto para obtener más información. Esto de debe a
que, probablemente se deberá iniciar una investigación preliminar
del proyecto.

Es muy importante que se detalle cuál es el problema, para que

los miembros del comité conozcan con claridad la situación
existente. Detallar la problemática del problema sirve para aclarar
la importancia y las causas del mismo.

Muchas veces el usuario presenta el problema a solucionar pero

no sabe cómo se puede solucionar. Pero otras veces sí, por lo
tanto es importante también que en la solicitud del proyecto se
proporcione cuál cree el usuario que es la solución.

El usuario podría estar motivado por el sector de sistemas. El

analista de sistemas podría colaborar con el usuario informándole
los sistemas de información existentes en la empresa que podrían
ayudar con el futuro proyecto.

La solicitud de un proyecto tiene un nivel de compromiso para el

usuario, pues el mismo debería justificar su pedido. Además esta
solicitud constituye un elemento de gran utilidad para los
miembros del comité pues a raíz de esto ellos conocen los
problemas existentes en la empresa.

31
6. Administración de la revisión y selección de un proyecto.

En una empresa se generan muchas más peticiones de

proyectos de las necesarias o de las que las mismas quieren o
son capaces de llevar a cabo. Antes de que se lleve a cabo
cualquier trabajo en relación a estas solicitudes, alguien debe
decidir cuáles se van a realizar y cuáles se van a rechazar o dejar
para más adelante. A este proceso se lo llama administración de
la revisión y selección de un proyecto.

Este tipo de decisión de aceptar o rechazar una petición, se

puede llevar a cabo de diversas maneras y por diversos miembros
de la empresa.

Uno de los métodos más comunes para llevar a cabo la

administración de la revisión y selección de proyectos, es
mediante un comité. Un comité es una reunión de personas que
debaten y deciden ciertos temas, en este caso la petición de un
proyecto.

Diversos miembros de la empresa pueden llegar a intervenir en

este proceso de revisión y selección. Los analistas de sistema
colaboran mucho en esta tarea, asesorando sobre los sistemas de
información. Aunque ellos no son los que toman la decisión final.

Los miembros de un comité trabajan en conjunto para conseguir

un objetivo. En este caso seleccionar los proyectos que se
llevarán a cabo. Por ese motivo conviene que la cantidad de
miembros del comité no sea fija y que los mismos se vayan
rotando. A su vez, también conviene que sus miembros trabajen
durante un tiempo no muy extenso. La renovación de sus
miembros se realiza a través de una votación.

32
En estos comités debe haber siempre un encargado de comité. El
encargado se especializa en llevar adelante la reunión. Su perfil
es muy característico, pues debe ser un muy buen líder.
Justamente es la persona que integra las opiniones de todos los
miembros, los ordena, y es que se encarga de resolver problemas
de comunicación entre todos cuando existen los desacuerdos. Su
rol es muy importante.

Existen varios tipos de comités y se clasifican de acuerdo a que

sector y que miembro de la empresa intervienen en este proceso.
Son: comité directivo, comité de sistemas de información y comité
de grupo de usuarios.

En la mayoría de las empresas, el comité directivo, es el que se

encarga de la supervisión de la revisión de las solicitudes de
proyectos. Este tipo de comité también se llama consejo
operativo, comité operativo o grupos de selección de proyectos.

Este comité está constituido por el presidente o vicepresidente,

gerentes claves de la empresa, gerentes técnicos y miembros del
grupo de sistemas de información. Sin embrago, el comité no está
dominado por la gente del sector de sistemas. En general domina
la reunión el presidente o vicepresidente, a pesar que pueda
recibir la colaboración del líder.

Este comité evalúa y decide proyectos de gran importancia para la

empresa, amplios, abarcativos para toda la empresa y de
principal interés para toda la empresa. Muchas veces en este tipo
de comité no se puede tomar una decisión con la simple
presentación de la solicitud de un proyecto. Por lo tanto, se puede
necesitar pedir un estudio preliminar para poder decidir sobre la

33
puesta en marcha de un proyecto. Este estudio preliminar ayuda a
los miembros del comité en el proceso de decisión.

El comité consta de varios gerentes de importancia para la

empresa quienes tienen la responsabilidad y la autoridad para
decidir cuáles proyectos son de importancia para la empresa. Los
gerentes tienen información y criterios sobre los proyectos a
evaluar, pues ellos están involucrados en el trabajo. Los
especialistas en sistemas del comité proporcionan la información
técnica y de desarrollo y sobre todo, su conocimiento valioso
sobre el manejo de la información.

Los proyectos de sistemas son inversiones de negocios. Los que

deciden son los gerentes y no los analistas de sistemas. Los
analistas aconsejan y no deciden.

En algunas empresas, las revisiones de los proyectos van

dirigidas al grupo de gerentes y analistas de sistemas. En
general, todas las solicitudes de desarrollo y de servicios se
reciben en el departamento de sistemas de información y allí este
comité de sistemas de información se encarga de aprobar y
desaprobar los proyectos y asignar prioridades.

Muchas veces existe este tipo de comité cuando se realizan

muchas solicitudes de proyectos que tienen que ver con servicios
de rutina o mantenimiento de sistemas existentes. El personal de
sistemas tiene buena visión de los requerimientos de estos
proyectos y trabajan en conjunto con otros gerentes que se
encargan de la planeación del negocio. Así deciden sobre la
puesta en marcha de estos proyectos.

34
Otras veces, se tienen que decidir cuestiones importantes sobre
equipos, herramientas de desarrollo para el área de sistemas,
capacitación para el personal de sistemas, cambios en los
sistemas operativos o lenguajes de programación, bases de
datos, etc. Si el área de sistemas tiene cierta autonomía y
presupuesto asignado para estas cuestiones, también se reúne
este comité. En este caso, los usuarios del área de sistemas
realizan sus propias solicitudes de proyectos hacia el encargado
de este comité.

En general este comité de sistemas de información, lo componen

el responsable o gerente del sector y los líderes de proyectos del
mismo sector. Ellos revisan y seleccionan estos proyectos que
están íntimamente relacionados con el sector de sistemas. En el
caso que los proyectos a desarrollar necesitan de un gran
presupuesto o constituyen compromisos a largo plazo, pueden no
tener los suficientes elementos para tomar una real decisión.

Si ellos no logran un consenso en este proceso de decisión,

pueden derivar el problema al comité directivo o a la presidencia
de la empresa. En este caso, los usuarios del sector de sistemas
que realizaron la solicitud, pierden la confianza suministrada a los
encargados del comité de sistemas de información. Al no lograr
un acuerdo entre ellos mismos y tener que recurrir a otro tipo de
comité, pierden su autoridad en el proceso de decisión, y los
usuarios suelen reaccionar negativamente. En el futuro
peticionarán ante el comité directivo. Por lo tanto, el comité del
sistema de información tiende a disolverse.

En algunas empresas, existen ciertos departamentos o sectores

que suelen tener o tomar la responsabilidad de las decisiones de
proyectos. Esta responsabilidad se distribuye entre los mismos

35
usuarios del sector. En este caso se conforma un comité de
grupo de usuarios.

La tarea que llevan a cabo en este tipo de comité es administrar la

revisión y selección de proyectos que suelen surgir en el mismo
departamento. En estos sectores, en forma individual, contratan a
sus propios analistas o desarrolladores para llevar a cabo el
desarrollo de estos proyectos tan particulares. Los departamentos
conforman sus propios comités de decisión, controlan lo que han
desarrollado y cuándo se podrán en marcha.

Estas decisiones y desarrollos de proyectos tienen una gran

ventaja. Sus proyectos no tienen que esperar largos períodos
tiempos para su desarrollo. No dependen del sector directivo para
su puesta en marcha. Los usuarios deciden rápidamente sus
futuros proyectos. A su vez, estos departamentos no trabajan en
conjunto con el resto de los departamentos hacia la misma meta.
No se aprovechan los recursos y no coordinan sus esfuerzos para
planear un sistema de información compartido e integrado que
pudiera beneficiar a la empresa en su conjunto. Los equipos de
computación de la empresa suelen saturarse, pues si se
desarrollan los proyectos, éstos no comparten recursos, ni
almacenamientos, ni horas de procesamiento.

Los sectores que conforman este tipo de comité, son sectores que
tienen una autonomía propia y un presupuesto asignado. Este tipo
de presupuesto suele ser incrementado por grupos o empresas
externas a la compañía que les brindan apoyo monetario o a
través de sus propios servicios.

Estos grupos de usuarios suelen encontrar algunas veces

desalentadoras decisiones del comité directivo. Luego toman

36
 decisiones por “mano propia” y generalmente sus proyectos no
coinciden con las metas propias de la empresa. Dichos sistemas
de información concebidos bajo este tipo de decisiones son
sistemas que duplican información y no consideran la interacción
con otros departamentos. Por lo tanto, el sector de sistemas de la
empresa debe implementar varias tareas que solucionen los
problemas ocasionados.

Los proyectos decididos bajo este tipo de comité de usuarios son

sistemas que tienen alta probabilidad de éxito. El éxito si se
consideran su desarrollo y puesta en marcha. Pero el éxito es un
fracaso si consideramos que no es un sistema integrado y
compartido por toda la empresa. La empresa no lo integra en su
presupuesto, es una ventaja para la compañía. Pero luego debe
invertir bastante dinero en las futuras aplicaciones que solucionen
estos problemas.

Foro. Comité de Selección. Reunión de Consorcio.

7. Requerimientos de un Sistema.

Los estudios de sistema son el resultado de una evaluación para

conocer cómo funcionan los métodos actuales y si son necesarios
y posibles algunos ajustes.

La determinación de los requerimientos es el estudio del sistema

actual de negocio a fin de encontrar cómo trabaja el sistema y
dónde debe mejorarse.

Un requerimiento es una característica que debe incluirse en un

nuevo sistema y puede consistir en una forma de captar o

37
procesar datos, producir información, controlar una nueva
actividad de negocio o dar apoyo a la gerencia.

Entonces la determinación de los requerimientos significa

estudiar el sistema actual y recopilar los datos suficientes para
encontrar cuáles son estos requerimientos.

Lo primero que debe realizar el analista de sistemas es entender

la situación. Existen ciertos requerimientos que son comunes a
cualquier situación y otros que están orientado al tipo de actividad:
transacciones o toma de decisiones. A su vez es interesante
saber si el sistema afecta a varios departamentos.

Durante el análisis de los requerimientos básicos se debe hacer

hincapié en conocer el proceso básico, las entradas y las salidas,
los tiempos requeridos y la cantidad de trabajo de las actividades
y los controles de rendimientos que necesita todo el sistema.

Se debe entender el proceso conociendo un antecedente de los

datos fundamentales y de las descripciones del sistema. Es
primordial conocer el objetivo de la actividad, las tareas que se
desempeñan, los lugares en dónde se desempeñan las personas,
el tiempo y la frecuencia con que se realizan estas actividades y
los gerentes o jefes que utilizan la información resultante.

Además el analista de sistemas debe identificar los datos

utilizados y la información producida durante el análisis de los
requerimientos básicos. Debe entender y conocer los datos que
se necesitan para llevar a cabo las tareas básicas que inician una
actividad de negocio y los datos resultantes de los producido por
dichas actividades. Es decir, qué realiza el empleado y qué le
sirve al gerente.

38
Durante el análisis de los requerimientos básicos también se debe
determinar el tiempo del proceso y la cantidad de trabajo. La
frecuencia de las actividades del negocio varía enormemente.
Algunas actividades se llevan a cabo en todo momento del día,
otra son diarias, semanales o mensuales. El efecto de estas
actividades es totalmente distinto. Por eso es importante conocer
la frecuencia de las actividades. Es interesante conocer la función
de iniciación de la actividad para poder determinar su tiempo y la
cantidad de trabajo pues a veces es difícil obtener esta
información. El tiempo por sí mismo no determina la importancia
de la actividad aunque afecta directamente al proceso. En general
cuando una actividad se ejecuta con poca frecuencia tiene
asociado una gran cantidad de trabajo. Y las actividades muy
frecuentes se asocian con poco trabajo. Las actividades de poca
frecuencia son importantes y de gran complejidad.

En las situaciones de negocios bien controladas el éxito de las

actividades es alto. Por lo tanto, en esta etapa de conocimiento y
entendimiento del proceso se deben identificar los controles que
se deben realizar a las mismas. No siempre es fácil averiguar
estos controles pues la falta de los mismos esconde un mal
resultado de las actividades. Encontrar controles débiles o
faltantes es un descubrimiento importante en cualquier
investigación de sistemas.

Existen otros requerimientos que no son comunes a cualquier

situación y que están orientados al tipo de actividad de
transacciones. Es por eso que se denominan requerimientos de
transacciones de usuarios. Los sistemas de nivel de
transacción están basados en actividades que son rutinarias,
comunes y asociadas a poca cantidad de trabajo. En los sistemas

39
de información una transacción es una actividad que necesita una
entrada de datos, realiza un cálculo o proceso y almacena otro
dato o conjunto de ellos. Es interesante averiguar en qué consiste
la operación de transacción, la persona que la realiza, su
operatoria el tiempo que necesita para llevarla a cabo y si existe
alguna condición diferente que afecte la forma en que las
transacciones sean procesadas. El analista de sistemas debe
averiguar los datos que se necesitan para procesar la transacción,
la información que genera y los datos que se almacenan.

Las decisiones, a diferencia de las actividades de transacción,

pueden no seguir un procedimiento específico. Al averiguar los
requerimientos de decisiones de los usuarios, se observa que
las rutinas no son muy claras y los controles pueden ser muy
vagos. La información se integra para tomar una decisión y
controlar una actividad. Los sistemas de toma de decisiones
pueden apoyar decisiones recurrentes mientras que otros son
únicos y no recurrentes. Los datos de las actividades de
transacciones se procesan con el objetivo de proporcionar nueva
información para la toma de decisiones. Se debe tener en cuenta
los datos del procesamiento de transacciones que se requieren
pero que no resultan del procesamiento mismo. Y además los
datos que se originan en las fuentes externas a la empresa.
También se debe tener en cuenta cómo se deben procesar los
datos para producir la información necesaria y cómo se deben
presentar la misma.

Un analista que investiga los sistemas de toma de decisiones

debe estar consciente de los sistemas de transacción que los
apoya. Los sistemas efectivos de toma de decisiones requieren
que en primer lugar se tengan procedimientos adecuados de
procesamiento de transacciones.

40
 En los negocios o empresas los departamentos dependen entre sí
para obtener un resultado exitoso. Surgen los requerimientos
para toda la empresa. Cuando los analistas estudian un proyecto
para un departamento, también deben tener en cuenta las
implicaciones que haya en otros departamentos que interactúan
con el sistema que se investiga. A veces los sistemas de
información ayudan a tareas que se llevan a cabo en varios
departamentos. En otros casos, los sistemas se operan en forma
separada dependen de datos que otros departamentos
proporcionan. Es responsabilidad de los analistas de sistemas
identificar las dependencias entre departamentos y determinar
cómo pueden afectar al proyecto de sistemas.

8. Selección y contrato del software.

En muchas oportunidades los directivos o administradores de la

empresa deciden no desarrollar un proyecto. Existen muchas
causas para tomar esta decisión, pero la necesidad del proyecto
se originó a raíz de un problema existente. Este problema se debe
solucionar de todas maneras. Una de las posibles soluciones es
adquirir software ya creado o solicitar desarrollo a medida.

Por lo tanto, el analista de sistemas, debe colaborar en esta tarea

de búsqueda. Cuando solicita software preplaneado, se debe
dedicar a lo que se denomina selección de software. Cuando
contrata software a medida, realiza un contrato de software.

41
La selección de software es determinar si el software comercial
se adecua a una tarea específica y el arreglo de los términos de
contrato son responsabilidad de la empresa usuaria.

La selección del software es una tarea complicada a pesar que

parezca tan fácil. Si esta actividad se la ve como una mera
compra de un producto, es una gran equivocación. El que lleva a
cabo la selección tiene una gran responsabilidad, pues si la nueva
aplicación termina no solucionando los problemas o complica más
aún la situación, sobre éste recae todo el peso del fracaso.
En consecuencia, para concretar una buena selección del
software, se debe primeramente tener un conocimiento concreto
de los requerimientos del sistema. Una tarea difícil es determinar
si un paquete específico de software se adecua a dichos
requerimientos. Finalmente, para aquellos paquetes que cumplen
esta condición, se debe determinar la mejor opción entre varias
alternativas.

En todos los casos que los analistas de sistemas evalúan un

software, ellos deben comparar las características del software a
contratar con los requerimientos de la aplicación previamente
desarrollados.

En este proceso de comparación se debe tener en cuenta los

siguientes items:

 las transacciones y los datos de cada transacción que es

necesario manejar,
 informes, documentos y otras salidas de datos que debe
producir el sistema ,
 archivos y bases de datos que maneja el sistema, archivos
de transacción que se necesitan para mantener los datos,

42
  volumen de datos que debe almacenarse,
 volumen de transacciones que se procesarán,
 características únicas respecto a la aplicación que
requieran consideración especial,
 requisitos de consulta,
 mejoras futuras y apoyo a las mismas,
 características de hardware y de comunicación que
requieren el software y
 los límites del sistema.

Teniendo en cuenta todos estos ítems, junto a las características

de costo y limitaciones que se hayan especificado, el analista de
sistemas podrá rápidamente eliminar los paquetes que no sirven y
no se adecuan a los requerimientos del sistema.

Finalmente, se examinan los candidatos restantes basándose en

la flexibilidad, la capacidad, la confiabilidad y los servicios del
proveedor.

La flexibilidad es la posibilidad de establecer parámetros. Incluye

la posibilidad de hacer frente a requerimientos cambiantes y a
necesidades dinámicas del usuario. Un software flexible siempre
es mejor que otro completamente rígido aunque la flexibilidad
excesiva no es buena. Esto se debe a que el analista debe definir
demasiados elementos en el sistema.

Las áreas donde la flexibilidad es deseable es en el

almacenamiento de datos, por ejemplo, en un programa
interactivo donde el usuario debe ingresar datos y los mismos
deben estar almacenados adecuadamente en función de
diferentes formas de recuperarlos. La flexibilidad también se debe
dar en la producción de informes y opciones, donde los mismos

43
podrían ofrecerse con diferentes formas de ordenarse y
presentarse. En la definición de parámetros, a su vez se observa
la flexibilidad. Una impresión de etiquetas que se pueda efectuar
en distintos tamaños se da sólo si el sistema es flexible y es
capaz de soportarlo. La entrada de datos es importante para
evaluar la flexibilidad. Es mejor ingresar el dato correspondiente a
un correo electrónico de una persona con la libertad de poder
escribirlo en dos o tres renglones que sólo tener disponibilidad
para uno.

La capacidad se refiere al número de archivos que se pueden

almacenar y la cantidad de datos que cada archivo puede
contener.

La capacidad depende también del hardware específico en el cual

se utilizará el software, el lenguaje en el cual se escribe el
software, el sistema de base de datos, el sistema de carpetas y
archivos, el sistema de generación de software automático, etc.

La capacidad se determina por el tamaño máximo de cada

registro medido en número de bytes, por el tamaño máximo del
archivo medio medido en número de bytes, por el tamaño
máximo del archivo medido en número de campos por registro,
por el número de archivos que pueden estar activos
simultáneamente y el número e archivos que se pueden registrar
en un directorio de archivos.

La capacidad es importante en la actualidad y a futuro y afecta

profundamente en la selección de software.

La confiabilidad y la previsión de auditoría son temas imposibles

de dejarlos de lado al evaluar un software. Los usuarios a menudo

44
tienden a confiar en exceso en los sistemas de información y esto
no es aconsejable.

Para realizar una buena selección de software, deben existir en el

sistema controles adecuados. Es decir los auditores deben tener
la habilidad para validar los informes y la salida de datos. A su
vez también deben verificar la autenticidad y precisión de los
datos e información.

Para ello se debe tener la habilidad para seguir el curso de una

transacción, imprimir selectivamente registros y transacciones en
el sistema que cumplan determinados criterios, informar si el
sistema está en balanceo y proporcionar suficientes controles en
la entrada de datos.

Confiabilidad en un sistema significa que los datos son confiables,

precisos y creíbles. También debe existir un elemento de
seguridad, que es determinar el método y su aplicabilidad de
proteger al sistema de usos no autorizados. Una clave de acceso
no es suficiente, se deben tener niveles múltiples de palabras
claves, pues no todos los usuarios requieren el mismo nivel de
acceso.

Se debe poder controlar la recuperación de informes, la

autorización a recibir informes, el acceso a datos de transacciones
para procesamiento, los cambios de saldos de cuentas, la
corrección de datos en archivos, y cambios de normas actuales
de seguridad y palabra clave.

Cuando el analista de sistemas compra un software, debe evaluar

los servicios del proveedor. El software requiere mantenimiento y

45
el analista debe determinar quién lo llevará a cabo y a qué costo,
antes de que el acuerdo de compra se haya firmado.

En este proceso se debe tener en cuenta los siguientes items:

 la frecuencia con que se llevará a cabo el mantenimiento, si

se proporcionarán versiones nuevas de manera regular y
los costos de estas actualizaciones,
 la existencia de un pago mensual por mantenimiento, los
servicios que incluye y que excluye,
 el suministro de la programación al cliente para adecuar los
aspectos específicos del software a las necesidades del
usuario, el precio, la prioridad y el tiempo después de que
se logre el acuerdo,
 los acuerdos existentes para el control de incrementos en
los pagos para el mantenimiento,
 los horarios disponibles para los servicios de apoyo al
software,
 las condiciones en las que se podrán recibir apoyo de
emergencia cuando se necesiten fuera del horario de
oficina,

Los vendedores de software tienen en cuenta estos ítems y los

comentan a los analistas pero una gran mayoría los esconden. El
analista de sistema se debe hacer responsable de obtener las
respuestas.

El apoyo del proveedor también incluye la capacitación cuando se

adquiere el sistema. Se debe averiguar de ante mano si esta
capacitación será por pago o por cortesía del proveedor, si se
hará en las instalaciones del usuario o en la compañía

46
proveedora. Se debe establecer también la cantidad de horas y de
personas que recibirán dicha capacitación.

Como corolario del proceso de evaluación del software se tiene

que tener en cuenta que el software bueno que no se mantiene
en condiciones adecuadas en un entorno dinámico, muy
pronto dejará de serlo.

Si no existe un contrato de software, que contenga todos los

acuerdos y aún las promesas verbales, puede llegar a ser difícil
probarlos luego que el sistema se instaló o luego de que se ha
cambiado al personal.

Las negociaciones del contrato constituyen un proceso legal. Los

analistas de sistemas y los gerentes de procesamiento de datos
no son hábiles con estas negociaciones. Por lo tanto se puede
solicitar asesoramiento al abogado de la compañía usuaria o a
uno externo a la misma. El abogado confeccionará un esbozo o
primera versión del contrato o modificará el sugerido con el
vendedor.

Existen dos tipos de contratos de software: el alquiler de paquete

de software y la asignación de programación al cliente.

Con frecuencia cuando las empresas adquieren software

solamente reciben el derecho a utilizarlo mediante un pago, sea
esto por única vez o durante un tiempo. Una licencia pagada
permite el uso del software de manera indefinida. La empresa no
posee al software, no lo puede vender o distribuir copias de él. A
esto se los denomina alquiler de paquete de software.

47
La asignación de programación al cliente se llama cuando la
empresa contrata los servicios de una agencia independencia
para producir software. Se puede estipular si la labor se llevará a
cabo por un pago fijo o por el costo del trabajo del encargado. Se
puede llegar a sumar un porcentaje específico del costo que se
añade al costo original, considerándolo ganancia para el
encargado. También se puede sumar una cantidad fija de acuerdo
a duración por calendario o por horas.

En un contrato se estipula la propiedad del software o si hay

contrato de alquiler o de servicios.

Cuando se establece un software a medida, los términos del

contrato deben proteger a la empresa usuaria. Debe especificar
cuándo y de qué manera se termina la prueba del software y
cuándo se pone en marcha la puesta total del software. A veces el
pago también se vincula a la puesta en marcha. Y otras veces se
realiza un pago con la entrega del software y luego un porcentaje
del pago con la puesta en marcha del mismo.

La empresa se deberá asegurar que el software continuará

disponible y que recibirá mantenimiento independientemente de lo
que le ocurra al proveedor. Este puede vender el software y ser
adquirido por otra compañía o desaparecer del mercado debido a
la venta o quiebra.

Los abogados juegan un papel importantísimo en la negociación

del contrato. Solicitan que el vendedor proporcione código fuente
o los listados de los programas o que depositen una copia del
programa ante una tercera parte independiente que la mantendrá
disponible. Debe cerciorarse que el software esté disponible para
el comprador si existe desacuerdo en el mantenimiento y las

48
 mejoras en los casos en que el comprador desee efectuar un
contrato para llevar a cabo su propio mantenimiento.

Este proceso legal es tan importante como otro paso relacionado

con el desarrollo de sistemas. Desafortunadamente estos
aspectos no atraen tanto la atención tanto como otros aspectos
de sistemas.

Foro. Selección de Software.

9. Recolección de datos.

Los analistas de sistemas utilizan varios métodos para llevar a

cabo la recopilación de datos. Esta tarea consiste básicamente en
preguntar, escuchar la respuesta y obtener las conclusiones.
Parece una tarea muy sencilla pero no lo es. Depende de la
persona que ofrece la información y del que la recibe. Es por ese
motivo que la tarea de recolección de datos no es simple. En
primer motivo, pues no podemos manejar la voluntad de la
persona que informa. Y finalmente porque el perfil del analista que
se dedica a esta tarea debe contener el don de la intuición, la
sutilidad, la cortesía, la amabilidad y sobre todo el don de saber
retirarse a tiempo.

Además el resultado de esta tarea es la base para el

conocimiento del problema existente, los requerimientos del
sistema a desarrollar y los detalles que se necesitan para
completar la investigación de sistemas.

Existen varios métodos para llevar a cabo la recolección de datos:

la entrevista, el cuestionario, la revisión de documentos y la
observación.

49
La utilización de los métodos mencionados no se lleva a cabo en
forma única. No es conveniente investigar con un solo método,
todos los métodos son complementarios para recopilar los datos.
Cada uno tiene ventajas y desventajas. Es importante usar varios
de estos métodos pues en la investigación es vital tener en cuenta
la verificación cruzada de datos.

9.1 Entrevistas.

La entrevista se utiliza para recabar información en forma verbal,

a través de preguntas que propone el analista. Los que responden
a estas preguntas son los directivos, gerentes o empleados que
conozcan y proporcionen datos sobre el problema a solucionar,
que operen el sistema actual o que serán afectados por el sistema
propuesto. En general, los entrevistados son personas que tienen
poder para la toma de decisiones o que conozcan en gran detalle
la problemática a solucionar.

El analista de sistemas entrevista en forma personal o grupal. En

general tienden a ser personales y se desarrollan en forma grupal
cuando el proyecto es amplio, importante y en cual interfieren
varios departamentos.

A pesar que los analistas prefieren esta técnica, no constituye la

mejor fuente de recopilación de datos. Todas las técnicas son
complementarias. Con las entrevistas se obtienen los primeros
datos, aquellos que tienen que ver con los requerimientos básicos
e importantes del proyecto, los lineamientos generales, sin
detalles.

50
Al evaluar las entrevistas, se debe tener en cuenta los datos que
se obtienen, el tipo de entrevista a desarrollar, las personas que
se entrevistan y la realización de la entrevista en sí.

Recabar datos mediante la entrevista.

La entrevista es una forma de conversación y no una

interrogación. Al analizar las características de los sistemas con
personal seleccionado cuidadosamente sobre sus conocimientos
sobre el sistema, se pueden obtener datos que no están
disponibles en ninguna otra forma. Es decir, si no existe una
charla estos datos no salen a la luz.

Existe información cualitativa y cuantitativa al llevar a cabo las

investigaciones de los sistemas. Se reúne información cualitativa
con las entrevistas. La información cualitativa está relacionada
con opiniones, políticas y descripciones narrativas de actividades
o problemas.

Es importante la entrevista si resulta esencial la inclusión de datos

sobre productos nuevos, cambios en la política en relación con
clientes, proyectos de construcción o crecimientos planeados.
Esta información no se la obtiene de ninguna manera si no es a
través del comentario del entrevistado.

Mucha gente es incapaz de expresarse en forma escrita y

prefiere discutir sus ideas y opiniones en forma verbal. Incluso,
cuando surgen los malos entendidos, las falsas expectativas o
incluso la resistencia potencial para las aplicaciones en desarrollo,
es mejor la técnica de la entrevista, la charla, la comunicación
oral.

51
Cuando se desea obtener datos de los gerentes de alto nivel, es
más fácil pedirles una entrevista a que llenen un cuestionario.

Determinación del tipo de entrevista.

Existen preguntas con una cierta estructura y otras sin estructura,

es decir, una sesión de preguntas y respuestas libres o no.
Cuando se desea adquirir información general se acopla mejor las
preguntas sin estructuras, con una sesión de preguntas y
respuestas libres. Cuando se desea conocer actitudes, ideas y
creencias sobre el que responde, también conviene una
atmósfera abierta y de fácil flujo. Sin embargo, cuando se desea
asegurar una alta confiabilidad en las respuestas, las entrevistas
estructuradas son mejores.

En una entrevista estructurada el formato de respuestas puede

ser abierto o cerrado. Las preguntas para respuestas abiertas
permiten a los entrevistados dar cualquier respuesta que parezca
apropiada. Pueden completar las respuestas con sus propias
palabras. Cuando se proporciona al usuario un conjunto de
respuestas que el mismo pueda seleccionar, se corre el riesgo de
inducir al entrevistado hacia la respuesta. Se trata de preguntas
para preguntas cerradas.

Los analistas deben dividir su tiempo entre desarrollar preguntas

para entrevistas y analizar sus respuestas. Las entrevistas no
estructuradas requieren de menor tiempo de preparación. Se
invierte menos tiempo en analizar las respuestas de las
entrevistas estructuradas. Por el contrario, se invierte más tiempo
en analizar las respuestas de las entrevistas no estructuradas

52
El tiempo que debe invertir el analista para la preparación de las
entrevistas estructuradas con respuestas cerradas es mayor al
invertido para su administración y posterior análisis.

Selección de entrevistados.

Los analistas deben tener especial cuidado en la selección del

personal entrevistado pues realizar entrevistas lleva tiempo y
además a veces, existen personas que son las únicas a las
cuales se les puede solicitar cierta información. Por otro lado
tampoco es amplio el número de personas que se entrevistan.

Durante las primeras etapas de estudio de sistemas, cuando se

estudia la factibilidad de un proyecto, se debe utilizar el método
de la entrevista y se deben aplicar en los niveles directivos.

Durante la investigación detallada, las entrevistas se aplican a

todos los niveles de empleados y de algunos niveles directivos.
Las entrevistas dependen de quien pueda proporcionar la mayor
parte de la información útil para el estudio.

Realización de la entrevista.

Es vital la habilidad del entrevistador para la realización de la

entrevista y para el éxito en la búsqueda de los datos. A su vez,
la preparación del objetivo de una entrevista específica y las
preguntas por realizar tienen importancia para el éxito de una
entrevista.

El tacto y la imparcialidad de los entrevistadores e incluso el uso

de una vestimenta apropiada ayudan a asegurar una vestimenta
apropiada. Quienes responden pueden crear situaciones difíciles.

53
 Y las dificultades que pueden presentarse en una entrevista son
variadas y el entrevistador debe acudir a su vasta experiencia.
Los analistas deben estar al tanto y atentos cuando se intenta
minimizar el esfuerzo de la investigación con preguntas evasivas
o incompletas. Un entrevistador sin experiencia puede llegar a ser
cuestionado fácilmente por los entrevistados y esto no es
adecuado para la obtención de datos.

Debido a todas estas cuestiones, es tan importante la verificación

a través de otros métodos de recopilación de datos. Incluso
algunos entrevistados pueden dar respuestas ya esperadas o
aprobadas. También es importante la habilidad del entrevistador
cuando los entrevistados no pueden expresar sus verdaderas
opiniones.

El analista debe tener en cuenta los siguientes ítems:

 ¿Qué es lo que me está diciendo la persona?

 ¿Por qué me lo está diciendo a mí?
 ¿Qué se está olvidando?
 ¿Qué espera esta persona que haga yo?

9.2 Cuestionario.

El cuestionario proporciona una alternativa muy útil para la

obtención de información y al igual que las entrevistas deben
diseñarse cuidadosamente para una máxima efectividad.

Se recurre a un cuestionario cuando es la única forma posible de

relacionarse con un gran número de personas y obtener la

54
información de varios aspectos del sistema. Se suele preparar los
cuestionarios y distribuirlos a todas las personas apropiadas.

En este caso, no se pueden tener en cuenta las observaciones o

reacciones de quienes responden los cuestionarios. Cuando se
deben tener en cuenta dichas actitudes, los analistas tienen que
recurrir a reunir al grupo solicitando permiso a su supervisor o
gerente. De esta manera, las personas, distendidas y con libertad
pueden responder las preguntas y el analista puede observar sus
reacciones al contestar.

En la mayor parte de los casos el analista no podrá ver a quienes

responden e incluso se encontrará con el anonimato. La ventaja
está dada por el hecho de poder sacar de la muestra las
respuestas inadecuadas. Si el cuestionario no es anónimo, de
ninguna manera se puede realizar esto.

A pesar que su aplicación puede realizarse con un mayor número

de individuos, es muy rara la respuesta total. Los usuarios tienden
a no darle prioridad a estos cuestionarios. Se pueden mejorar las
tasas de respuestas, si se puede reunir a un grupo grande para
llevar a cabo esta tarea. El desarrollo y distribución de los
cuestionarios es caro, por lo tanto el tiempo invertido en esto debe
utilizarse en forma inteligente.

Existen cuestionarios abiertos y se aplican cuando se quieren

conocer sentimientos, opiniones y experiencias generales. Son
muy útiles cuando se quiere conocer las razones de las ideas de
quienes responden.

55
Algunas personas encuentran más fácil escoger entre varias
posibilidades y este tipo de cuestionarios se denomina cerrados.
Este tipo de cuestionario limita las respuestas posibles del
interrogado. Se aplican los cuestionarios cerrados cuando se
quiere conocer información sobre los hechos. Este tipo de
cuestionario fuerza a los interrogados a tomar una posición con
respecto a aspectos importantes. Tienen preguntas con respuesta
del tipo si no.

La primera etapa que se debe tener en cuenta para desarrollar un

cuestionario es la definición de su objetivo. Es importante pues el
analista quiere obtener los hechos al considerar la estructura más
útil para el estudio y la más sencilla de entender por parte de los
interrogados.

La selección de aquellas personas que reciban el cuestionario se

definen en función de la información que van a brindar. Constituye
un tema importante pues un cuestionario lo puede contestar una
persona que no está calificada y la información resultante sería
inútil. Si además el cuestionario no es anónimo, no puede
retirarse la respuesta de la muestra. Se debe verificar los
antecedentes y experiencias que sirven de base para la respuesta
de los cuestionarios de aquellas personas que recibirán el
cuestionario. El analista se debe asegurar de que quienes reciban
el cuestionario tenga la información necesaria.

9.3 Revisión de documentos.

La revisión de documentos también se llama revisión de

registros. Este término, registro, no solamente se refiere a un

56
elemento de la base de datos sino a cualquier tipo de documento
que pueda quedar registrado o guardado en la empresa. Pude ser
una factura emitida, un cronograma, un manual de procedimiento,
una norma de trabajo, un organigrama o un simple papel escrito
por un empleado con recordatorios para llevar a cabo su tarea.

Los analistas llevan a cabo esta técnica cuando examinan

registros. Las empresas ya cuentan disponible para el analista
esa información, sólo tienen que solicitarla.

Esta forma de encontrar datos puede servir como presentación

del analista si se realiza al iniciar el estudio de investigación. Esta
técnica puede servir como un término de comparación de lo que
sucede en el departamento con lo que los registros presentan
como lo que debería suceder. La revisión de registros es una muy
buena tarea que lleva a descubrir múltiples errores o desaciertos
que se realizan en la empresa.

Se inspeccionan los manuales y los sistemas de información

existentes que entran dentro del área de investigación con el
objetivo de chequear si lo que hace en la realidad coincide con lo
planeado.

Los registros permiten a los analistas que se familiaricen con

algunas operaciones u oficinas de la compañía y las relaciones
formales a las que debe darse apoyo. La inspección de registros
muestra cómo se producen de hecho las actividades, dónde se
ubica el poder verdadero para las decisiones o cómo se realizan
las tareas en la actualidad.

En algunas empresas los manuales y estándares sobre

procedimientos de operación usualmente están obsoletos. No se

57
mantienen completamente actualizados para llegar a reflejar los
procedimientos existentes. Algunos diagramas de organización
muestran cómo las distintas unidades se relacionan con el resto.
Si se comparan formularios en blanco con manuales de
operación, el analista puede observar y darse cuenta como se
llenan. Es importante muestrear algunos formularios o
documentos con el objetivo de calcular porcentajes de error y
estadísticas que describan en forma completa una situación.

Es tan importante verificar ciertos formularios o documentos en

forma cruzada para determinar si las tareas se llevan a cabo
correctamente y si se controlan eficientemente.

Los analistas deben buscar aquellos formularios que utilizan los

individuos para su propio uso, los simples papeles que el resto
desconoce porque no son parte de los procedimientos
preestablecidos. Esto muestra que la tarea debe relevarse
nuevamente y estas anotaciones con cálculos u otras operaciones
deben ser tenidas en cuenta.

Los analistas no deben pasar por alto los informes de los

estudios previos, ni los resúmenes de los consultores ni los
informes de los gerentes. Estos pueden proporcionar una historia
que explique el mecanismo de los procedimientos que los
analistas observan durante el estudio y algún dato sobre puntos
detectados que aún no tienen solución.

58
9.4 Observación.

La observación es muy importante para la obtención de la

información, pues es el método que cierra el circuito de la
investigación. Si de otra forma no se pudo encontrar algún dato,
tal vez con el simple observar se averigua.

El método de la observación le proporciona al analista una

dimensión de las actividades del sistema. Los métodos de
entrevista y cuestionarios no son completos para obtener la
información.

Si se observan directamente las operaciones, las dudas sobre el

uso de formularios o la manera en que se realizan las actividades
se pueden evacuarse. Se puede averiguar rápidamente si los
pasos específicos se suceden o no como estaban establecidos.

El poder observar las operaciones que se realizan en una

empresa y poder compararlas con las tareas que lleva a cabo un
gerente de alto nivel en una toma de decisiones ayudan
perfectamente al analista en su etapa de investigación.

Es muy útil para el analista el método de la observación para

saber cómo se manejan los documentos, cómo se realizan los
procesos y si ocurren los pasos establecidos. El analista a través
de este tipo de método puede captar quién utiliza los documentos
y si encuentra dificultades. Puede llegar a detectar que algunos
documentos o formularios no se utilizan.

Se puede llegar a observar cualquier tipo de etapas poco

usuales, además de identificar las tareas problemáticas. También

59
 se pueden observar aquellas tareas que hacen retardar a otro
procedimiento. Son los llamados cuellos de botella. Diagnosticar
los cuellos de botella es fundamental en la etapa de investigación.

El método de la observación presenta ciertos peligros en aquellos

sectores de la empresa donde se realiza alguna transacción
dificultosa o también en situaciones de toma de decisiones.

En el momento de la observación, las tareas no se llevan a cabo

en forma natural y la forma de trabajo se puede modificar. El
sentirse observado hace que un empleado no trabaje
naturalmente y se puede distorsionar totalmente el análisis de la
información.

En esos casos, se puede realizar la observación participativa,

que proporciona tranquilidad a los usuarios y a su vez no se
sienten cuestionados ni invadidos. El observador, por otra parte,
participa en la tarea y culmina su tarea de investigación sobre la
tarea en cuestión.

La información recabada a través de este tipo de método será

informativa si el analista se convierte en parte de la situación y
hace el trabajo por sí solo. La información será informativa en la
medida que el analista pueda posteriormente retroceder y ser
objetivos en cuanto a lo que han experimentado.

10. La importancia de una Metodología.

Para llevar a cabo el desarrollo global de un sistema nuevo el

analista de sistemas requiere de un método o una metodología

60
que le permite trabajar e interactuar con sus pares de una manera
clara, concisa y sin malos entendidos. La metodología provee
orden de trabajo y permite que muchas personas que llevan a
cabo diferentes actividades hablen el mismo lenguaje y se puedan
comunican a través del resultado de sus tareas.

Todos los integrantes saben lo que tienen que hacer y en qué

forma. Se evitan los malos entendidos y la duplicación del trabajo.
Es importante definir las actividades a llevarse a cabo en un
proyecto de desarrollo de sistemas. A su vez, se debe lograr
congruencia entre la multitud de proyectos de un desarrollo global
de un sistema en una empresa u organización.

Otro objetivo fundamental es proporcionar puntos de control y

revisión de las decisiones sobre continuar o no con un proyecto,
que apunta a la necesidad de administrar el control de un
proyecto. El objetivo fundamental del desarrollo global de un
sistema nuevo de sistemas es permitir organizar las actividades,
aumentando la probabilidad de que se aborden los problemas
pertinentes en el momento adecuado.

61
ANALISIS Y DISEÑO DE SISTEMAS.

Unidad 2: Primeros Pasos en el Proceso Unificado.

1. Definición de análisis y diseño de sistemas.

2. Definición de objeto.
3. Definición de análisis y diseño orientado a objetos.
4. Definición de programación orientada a objetos.
5. El software y su complejidad.
6. Técnicas para dominar la complejidad del software.
7. Método y Metodología.
8. Abstracción y Jerarquía.
9. El Proceso Unificado.
10. Importancia de los 3 conceptos básicos del Proceso Unificado.

1. Definición de análisis y diseño de sistemas.

El análisis y diseño de sistemas es el proceso de examinar una

situación de la empresa con la intención de mejorarla mediante
nuevos procedimientos y métodos.

El análisis de sistemas es el proceso que sirve para recopilar e

interpretar los hechos, diagnosticar problemas y utilizar estos
hechos a fin de mejorar el sistema. Es el conocimiento del
problema y no su solución.

62
El diseño de sistemas es el proceso de planeación de un nuevo
sistema dentro de la empresa para reemplazar o completar al
existente.

El análisis pone énfasis en una investigación del problema y los

requisitos, en vez de ponerlos en una solución. Por ejemplo, si se
desea un nuevo sistema de información informatizado para un
negocio, ¿cómo se utilizará?

Análisis es un término amplio, es mejor referirnos como análisis

de requisitos o estudio de requisitos o análisis de objetos o
estudios de los objetos del dominio.

El Diseño pone énfasis en una solución conceptual que satisface

los requisitos, en lugar de colocarlo en la implementación. Por
ejemplo, la descripción de la base de datos y objetos de software.
Finalmente los objetos pueden ser implementados.

De la misma manera que lo propusimos con el término anterior, es

mejor calificarlo como diseño de objetos o diseño de base de
datos.

Resumiendo, el análisis tiene que ver con hacer lo correcto y el

diseño tiene que ver con hacerlo correcto. Es decir, el qué y el
cómo.

63
2. Definición de objeto.

Un objeto es una entidad tangible que muestra algún

comportamiento tangible. Un objeto puede cambiar de estado,
actuar, ser manipulado o permanecer en relación a otros objetos
de maneras apropiadas para ese objeto.

Por ejemplo, un ascensor se caracteriza por tener propiedades

invariantes que hacen que el mismo se pueda desplazar para
arriba y para abajo por su hueco.

Más sencillamente, un objeto es una cosa que generalmente se

extrae del vocabulario del espacio del problema o del espacio de
la solución. Una clase es una descripción de un conjunto de
objetos que son lo suficientemente similares para compartir una
especificación.

Además, todo objeto tiene identidad (puede nombrarse y

distinguirse de otra manera de otros objetos), estado (hay
algunos datos asociados a él) y comportamiento (se le pueden
hacer cosas al objeto, y él a su vez puede hacer cosas a otros
objetos).

Otro ejemplo, en un sistema de contabilidad, en la interfaz de

usuario, aparecerán objetos como botones, menús y cuadros de
diálogos. En la base de datos, existirán objetos como tablas que
representarán entidades del dominio como clientes, productos,
etc. En el conjunto de servicio de negocios, aparecerán objetos
tales como transacciones y reglas de negocios.

64
3. Definición de análisis y diseño orientados a objetos.

En el análisis y diseño orientado a objetos, centramos nuestra

atención en encontrar y describir los objetos en el dominio del
problema. En un caso de un sistema de información de una
farmacia, algunos de los conceptos son Medicamento, Cliente, y
Laboratorio.

En el diseño orientado a objetos, pensamos en la definición de los

objetos software y en cómo colaboran para satisfacer los
requisitos. En el caso de la farmacia, un objeto software
Medicamento podría tener un atributo nombre y un método
obtenerComponentes.

Finalmente, en la implementación o programación orientada a

objetos, los objetos de diseño se implementan, como la clase
Java Medicamento.

4. Definición de programación orientada a objetos.

La programación orientada a objetos es un método de

implementación en el que los programas se organizan como
colecciones cooperativas de objetos, cada uno de los cuales
representa una instancia de alguna clase, y cuyas clases son,
todas ellas, miembros de una jerarquía de clases unidas mediante
relaciones de herencia.

La programación orientada a objetos utiliza objetos y no

algoritmos. Cada objeto es una instancia de alguna clase y las

65
 clases están relacionadas con otras clases por medio de
relaciones de herencia. La herencia es una relación entre clases
en la que una clase comparte la estructura y/o el comportamiento
definidos en otra clase.

5. El software y su complejidad.

El software es complejo y muy complicado. Es su propia y

esencial característica.

Es complejo porque hereda la complejidad del dominio del

problema, la dificultad de gestionar el proceso de desarrollo y la
flexibilidad que se puede alcanzar a través del software.

La complejidad del dominio del problema.

El problema a resolver presenta muchos requisitos que compiten

entre sí o se contradicen (cuando se compite entre facilidad de
uso o costo con la facilidad de desarrollo o su funcionalidad).

Esas contradicciones o desacoplamientos existen debido a que

los usuarios suelen encontrar grandes dificultades para expresar
sus necesidades en una forma en que los desarrolladores puedan
entender. Los usuarios tal vez solo tienen vagas ideas de lo que
quieren del sistema.

Los requerimientos además cambian con frecuencia durante el

desarrollo incluso porque la mera existencia de un proyecto de
solución lo altera al sistema real.

66
Un sistema grande, debido a la inversión financiera que implica,
no puede desecharse y reemplazarse por uno nuevo cada vez
que los requerimientos cambian. Debe evolucionar.

Evolucionar en software significa, responder al cambio de

requerimientos.

Mantenimiento del software significa, corregir errores.

Conservación del software, significa, emplear recursos para

mantener en operación un elemento de software anticuado y
decadente.

La dificultad de gestionar el proceso de desarrollo.

La principal tarea del grupo de desarrollo es dar una ilusión de

simplicidad para defender a los usuarios de esta complejidad
arbitraria del problema.

Se hace lo posible por escribir menos código pero a veces es

imposible eludir el tamaño de un sistema grande. Debe recurrirse
a la aplicación de varias técnicas de re-utilización de código
existente o de la escritura de nuevo software.

Debe también enfrentarse la existencia de miles de módulos

separados y esto implica un grupo de desarrolladores, nunca una
única persona. Esto implica más personas y por consiguiente una

67
comunicación más rigurosa y coordinación más difícil, más aún si
el grupo y el proyecto se extienden geográficamente.

La flexibilidad que se puede alcanzar a través del software.

Un proyecto de software es muy frecuentemente apoyado en

pilares construidos por los mismos desarrolladores pues para que
las mismas aplicaciones tengan la máxima flexibilidad ellos deben
expresar casi cualquier clase de abstracción. Esto empuja al
desarrollador a construir por sí mismo prácticamente todos los
bloques fundamentales sobre los cuales se apoyan tales
abstracciones.

A diferencia de una obra edilicia, por ejemplo, ésta no contiene su

fábrica siderúrgica para fabricar sus propias vigas metálicas. Esto
significa que el desarrollo del proyecto de software sigue siendo
una tarea muy laboriosa. Existen muy pocos estándares para el
desarrollo de software, cuando en la industria de la construcción
tiene normativas uniformes de construcción y estándares para la
calidad de los materiales.

Las consecuencias de la complejidad ilimitada.

Más complejo es el sistema, más abierto está al derrumbamiento

total.

Los usuarios solicitan a toda hora cambios en un sistema ya

armado que lleva a una extremada complejidad y nadie lo
cuestiona. Sólo se dice que es cosa de programar. El fracaso de

68
dominar dicha complejidad lleva a proyectos retrasados, que
exceden al presupuesto y que son deficientes respecto a los
requerimientos fijados. A esto se lo denomina Crisis del software.

Se necesitan muchos buenos programadores para solucionar

esto, y crear todo este nuevo software nuevo que necesitan los
usuarios. Muchos de ellos, se deben dedicar al mantenimiento del
software existente.

¿Qué se puede hacer para solucionar este problema?

Este problema surge de la complejidad que tiene propiamente el

software.

Podríamos ver cómo se comportan o se organizan otros sistemas

complejos en otras disciplinas, por ejemplo, la estructura de las
instituciones sociales.

Los grupos de personas se reúnen para realizar actividades que

por sí solas no podrían realizarlas. Algunas de estas
organizaciones perduran en el tiempo y cuando crecen tienen
una jerarquía diferente. Se dividen en compañías, luego en
delegaciones, a su vez, contienen locales, y así sucesivamente. Si
la organización perdura, las fronteras pueden cambiar y luego
surgir otra organización y así nacer una nueva jerarquía.

Una vez que se ve esta jerarquía, la misma está unificada por una
serie de mecanismos comunes. La relación o el grado de
interacción entre los empleados de una sola oficina es mayor que
entre empleados de oficinas diferentes. Por ejemplo, un jefe de
ventas no interactúa con el director de la empresa pero lo hace
siempre con los vendedores de su local. Ambos, el jefe de ventas

69
como el director de la empresa reciben el sueldo de la misma
organización y comparten el mismo edificio y mismo sistema
telefónico para cumplir con sus objetivos.

Existen ciertas características de los sistemas complejos que

nos pueden ayudan a analizar esta problemática.

La jerarquía.

La complejidad toma la forma de una jerarquía, por lo cual un

sistema complejo está compuesto de subsistemas relacionados
que tiene a su vez sus propios subsistemas, y así sucesivamente,
hasta que se alcanza algún ínfimo nivel de componentes
elementales.

El hecho de tener una estructura jerárquica y casi

descomponible es lo que facilita la comprensión del sistema
complejo. En realidad sólo se puede comprender a los sistemas
que tienen una estructura de jerarquía.

Los componentes.

La elección de qué componentes de un sistema son primitivos

es relativamente arbitraria y queda en gran medida a decisión del
observador.

La arquitectura de un sistema complejo es función de sus

componentes tanto como de sus relaciones jerárquicas entre
sus componentes. Todos los sistemas tienen subsistemas y
todos los sistemas son parte de sistemas mayores.

70
La interacción de los componentes.

Los enlaces internos de los componentes suelen ser más fuertes

que los enlaces entre los componentes.

Esto se refiere a la diferencia entre la interacción intracomponente

y la interacción intercomponente. Además posibilita un estudio de
cada parte del sistema de forma relativamente aislada.

Los componentes pequeños que se reutilizan.

Los sistemas jerárquicos están compuestos usualmente de sólo

unas pocas clases diferentes de subsistemas dispuestos en
varias combinaciones y disposiciones.

Los sistemas complejos tienen patrones comunes. Esto lleva a la

reutilización de componentes pequeños.

La evolución de los componentes de un sistema.

Se encontrará siempre que un sistema complejo que funciona

ha evolucionado de un sistema simple que funcionaba. Un
sistema complejo diseñado desde cero nunca funciona y no
puede parchearse para conseguir que lo haga. Hay que volver a
empezar, partiendo de un sistema simple que funcione.

A medida que los sistemas evolucionan, los objetos que en su

momento se consideraron complejos se convierten en objetos
primitivos sobre los que se construyen sistemas más complejos

71
 aún. Nunca se pueden crear estos objetos primitivos de forma
correcta la primera vez, hay que utilizarlos antes en un contexto,
y mejorarlos entonces con el tiempo cuando se aprende más
sobre el comportamiento real del sistema.

Continuemos analizando nuestro problema anterior,

¿Qué se puede hacer para solucionar este problema?

La técnica de dominar la complejidad se conoce desde tiempos

remotos: divide y vencerás. Cuando se diseña un sistema de
software complejo, es esencial descomponerlo en partes más y
más pequeñas, cada una de las cuales se puede refinar entonces
de forma independiente. Esta es la técnica que se utiliza para
estudiar y trabajar con sistemas complejos.

Así se satisface la restricción fundamental de la capacidad

humana: para entender un nivel dado basta con comprender
unas pocas partes, no necesariamente todas a la vez.

6. Técnicas para dominar la complejidad de los sistemas

complejos.

La mayoría de los profesionales en informática han implementado

sus sistemas con el diseño estructurado descendente y desafían
la descomposición de los sistemas complejos como una simple
cuestión de descomposición algorítmica, en la que cada módulo
del sistema representa a un paso importante de algún proceso
global. Esta visión enfatiza el orden de los eventos.

72
Pero por otro lado, más actualmente, se pude descomponer un
sistema complejo de acuerdo con las abstracciones claves del
dominio del problema. En vez de descomponer el sistema en
pasos, se identifican objetos que se derivan directamente del
vocabulario del dominio del problema.

Cada objeto de esta solución contiene su propio comportamiento

único, y cada uno modela a algún objeto del mundo real. Un
objeto no es más que una entidad tangible que muestra un
comportamiento bien definido. Los objetos hacen cosas y a los
objetos se les pide que hagan lo que hacen enviándoles
mensajes. Esta visión resalta a los objetos que provocan
acciones o son sujetos de estas acciones.

Como esta descomposición está basada en objetos y no en

algoritmos, se le llama descomposición orientada a objetos.

¿Cuál de estas dos descomposiciones es la mejor?

Ambas son buenas, pero hay algo muy importante para resaltar.
La visión algorítmica enfatiza el orden delos eventos y la visión
orientada a objetos resaltan los agentes que o bien causan
acciones o bien son sujetos de estas acciones.

Lo importante es saber que no se puede construir un sistema

complejo bajo los dos conceptos, pues son dos visiones
completamente diferentes. Se debe descomponer un sistema ya
sea por algoritmos o por objetos.

73
7. Método y Metodología.

Método es un proceso disciplinado para generar un conjunto de

modelos que describen varios aspectos de un sistema de software
en desarrollo, utilizando alguna notación bien definida.

Metodología es una colección de métodos aplicados a lo largo

del ciclo de vida del desarrollo del software y unificados por
alguna aproximación general o filosófica.

Los métodos son importantes porque introducen una disciplina en

el desarrollo de sistemas de software complejos. Definen los
productos que sirven como vehículo común para la
comunicación entre miembros de un equipo de desarrollo y
sirven de apoyo a la dirección para medir el progreso y para
gestionar el riesgo.

Los métodos han evolucionado para ayudar a la complejidad del

software. El diseño orientado a objetos es un método y su
concepto es que se debería modelar los sistemas de software
como colecciones de objetos que cooperan, tratando los objetos
individuales como instancias de una clase que está dentro de una
jerarquía de clases.

El diseño orientado a objetos sirve de ayuda para organizar la

complejidad innata de los sistemas de software, y para describir la
complejidad organizada de sistemas complejos.

74
 La descomposición orientada a objetos produce sistemas más
pequeños a través de la reutilización de mecanismos comunes,
economizando expresiones. A su vez, los sistemas orientados a
objetos son también más resistentes al cambio y por lo tanto
están mejor preparados para evolucionar en el tiempo.

La descomposición orientada a objetos reduce el riesgo que

representa construir sistemas de software complejos, porque
están diseñados para evolucionar de forma incremental partiendo
de sistemas más pequeños en los que ya se tiene confianza.

8. Abstracción y jerarquía.

El rol de la abstracción.

Es una técnica muy potente para enfrentarse a la complejidad. Al

ser incapaces de dominar en su totalidad a un objeto complejo,
ignoramos entonces sus detalles no esenciales, tratando en
su lugar con el modelo generalizado e idealizado del objeto.

El rol de la jerarquía.

Reconocer jerarquías de clases y objetos es otra forma de

incrementar el contenido semántico de bloques de información. La
estructura de objetos es importante porque nos muestra como
los objetos colaboran entre sí a través de diferentes
mecanismos, mientras que la estructura de clases resalta la

75
 estructura y comportamiento comunes en el interior del
sistema.

Existe una complejidad inherente entre los diferentes tipos de

objetos. A pesar que pueden ser distintas cada instancia de un
determinado tipo de objeto puede asumirse que comparten la
misma conducta que todas las demás instancias de ese mismo
tipo de objeto. Si ordenamos objetos en grupos de abstracciones
relacionadas, llegamos a distinguir propiedades comunes y
diferentes entre diferentes objetos, que nos llevará a dominar
dicha complejidad inherente.

La identificación de jerarquías en un sistema complejo no es

fácil ya que requiere que se descubran patrones entre muchos
objetos, cada uno de los cuales puede incluir comportamientos
muy complicados.

9. El Proceso Unificado.

Hoy en día se construyen en el ámbito del software sistemas muy

grandes, complejos, más potentes y cada vez se espera más de
los mismos. Esto se debe a que estos productos van mejorando a
medida que sus versiones van avanzando y además los mismos
se adaptan cada vez mejor a los caprichos de los usuarios.

Esta tendencia también se ha visto afectada por el uso creciente

de Internet para el uso de todo tipo de información desde simples
textos sin formatos hasta información multimedia. Obviamente

76
tenemos que agregarle a estos requerimientos el tiempo de
respuesta cada vez más óptimo.

Para llevar a cabo todo este gran proyecto de software los

desarrolladores deben coordinar múltiples cadenas de trabajo y
por lo tanto necesitan necesitan un proceso que integren las
numerosas facetas de dicho trabajo. Necesitan un método común,
un proceso que:

 proporcione una guía para ordenar las actividades de un

equipo,

 dirija las tareas de ada desarrollador por separado y del

equipo como un todo,

 especifique los artefactos que deben desarrollarse,

 ofrezca criterios para el control y la medición de los productos
y las actividades del proyecto.

El Proceso Unificado de Desarrollo es una solución a este

problema de software.

El Proceso Unificado de Desarrollo es un conjunto de

actividades necesarias para transformar los requisitos de un
usuario en un sistema de software.

Requisitos Proceso de Desarrollo Sistema

del usuario de Software Software

77
El Proceso Unificado de Desarrollo ofrece un entorno de trabajo
que sirve para:

 una gran cantidad de de sistemas,

 muchos tipos de empresas u organizaciones,
 diferentes niveles de aplicaciones y
 distintos arquetipos de proyectos.

El Proceso Unificado de Desarrollo utiliza UML (Lenguaje

Unificado de Modelado) para preparar los esquemas de un
sistema de software. Este lenguaje es una parte de este proceso.

El Proceso Unificado de Desarrollo se basa en componentes,

es decir, que el sistema de software en construcción está
formado por componentes de software interconectados a través
de interfaces muy bien definidas.

Definitivamente, el Proceso Unificado de Desarrollo está

dirigido por casos de uso, está centrado en la arquitectura, es
iterativo e incremental. Esto se refiere a las características propias
de este proceso tales como su ciclo de vida, fases, versiones,
iteraciones, iteraciones, flujos de trabajo, y artefactos.

¿Qué significa que Proceso Unificado de Desarrollo está

dirigido por casos de uso?

Un sistema de software existe con el único objetivo de solucionar

o dar servicio a la problemática de los usuarios. Se debe conocer
con seguridad los requerimientos del usuario, es decir lo que
necesita y desea.

78
El usuario es alguien o algo que interactúa con el sistema que se
desarrolla Éste lleva a cabo una interacción con el sistema y
éste lleva a cabo una secuencia de acciones que proporcionan al
usuario un resultado importante.

Por ejemplo una interacción sería una persona que llega a un

hotel para alquilar una habitación. El recepcionista verifica que
haya vacantes, registra los datos del cliente y asigna el cuarto. En
respuesta a lo realizado por el cliente, el sistema lleva a cabo una
secuencia de acciones que proporcionan al usuario un resultado
importante que este caso, sería la asignación del cuarto.

Una interacción de este tipo es un caso de uso, que es un

fragmento de funcionalidad del sistema que proporciona al usuario
un resultado importante. Los casos de uso representan los
requisitos funcionales.

Todos los casos de usos constituyen el Modelo de Casos de Uso

el cual describe la funcionalidad del sistema.

Los casos de uso no sólo guían la funcionalidad del sistema sino

también guían su diseño, implementación y prueba. Esto significa
que los casos de uso guían el proceso de desarrollo. Los
desarrolladores crean a cabo una serie de modelos de diseño e
implementación guiándose en los caso de uso. Luego los revisan
para que están de acuerdo con el modelo de casos de uso. A su
vez, los ingenieros de prueba, prueban la implementación para
garantizar que los componentes del modelo de implementación
implementan correctamente los casos de uso.

79
Los casos de uso inician el proceso y son un hilo conductor, por
eso se dice que el Proceso Unificado de Desarrollo está dirigido
por casos de uso. Los casos de uso se especifican, se diseñan, y
los mismos sirven de base para que los ingenieros de pruebas
generen sus casos de prueba.

Los casos de uso se desarrollan al mismo tiempo que la

arquitectura del mismo sistema, no se desarrollan en forma
separada. Los casos de uso guían la misma arquitectura y ella
influye en la selección de loa casos de uso. Ambos, la arquitectura
y los casos de uso maduran a medida que avanza el ciclo de
desarrollo del sistema.

¿Qué significa que Proceso Unificado de Desarrollo está

centrado en la arquitectura?

La arquitectura en un sistema de software se describe mediante

diferentes vistas del sistema en construcción. Dicho concepto
incluye aspectos dinámicos y estáticos del sistema en cuestión.

La arquitectura depende de:

 las necesidades de la empresa, es decir, influyen los usuarios

y los inversores, por supuesto a través de los casos de uso
 la plataforma en la que tiene que funcionar el sistema, es
decir, el hardware
 el sistema operativo,
 el sistema de gestión de base de datos,
 los protocolos para comunicaciónes en red, el cableado, etc.

80
 los bloques de construcción reutilizables disponibles,
consideraciones de implementación,
 sistemas heredados y
 requisitos no funcionales.

Todo producto, en este caso un sistema posea una función y una

forma, las dos relacionadas entre sí. Los casos de uso tiene que
ver con la función y la arquitectura tiene que ver con la forma.

Para que dicha forma sea válida, los arquitectos deben trabajar
sobre la comprensión general de las funciones claves, es decir
sobre los casos de uso claves del sistema, que en general se
supone que corresponden al cinco o diez por ciento de todos los
casos de uso. Y que son las funciones más significativas del
sistema.

A su vez, debe existir una interacción entre los casos de uso y la

arquitectura. Los casos de uso deben encajar e la arquitectura y
la arquitectura debe permitir el desarrollo de todos los casos de
uso que se requieren.

Ambos, los casos de uso y la arquitectura deben evolucionan en

paralelo.

Para crear la arquitectura se debe seguir los siguientes pasos:

 genera un borrador de la arquitectura, basándose en la

plataforma, independizándose de los casos de uso,
 luego el arquitecto trabaja con los casos de uso que se
especifican como representantes de las funciones claves del
sistema,

81
 después que los casos de uso se especifican y maduran, se
van descubriendo más aún de la arquitectura, es decir, van
apareciendo más casos de uso en la misma arquitectura.

¿Qué significa que Proceso Unificado de Desarrollo es

iterativo e incremental?

Es muy práctico separar todo el trabajo en partes más chicas o

mini proyectos. El desarrollo de un sistema de software puede
perdurar a lo largo de varios meses, incluso más de un año.

Estos mini proyectos se denominan iteraciones que resultan en

un incremento.

Estas iteraciones se refieren a pasos en el flujo de trabajo. Los

incrementos se refieren al crecimiento del sistema.

Las iteraciones deben ser controladas. Estos quiere decir que se

deben seleccionan y deben ser planificadas. Es por eso que son
mini proyectos.

Los desarrolladores basan la selección de cada iteración en dos

factores. Primero la iteración trata un grupo de casos de uso que
todos juntos van ampliando la utilidad del sistema hasta ese
momento. Segundo, la iteración trata los riesgos más
importantes.

Las iteraciones sucesivas se construyen sobre los artefactos de

desarrollo tal como quedaron al final de la última iteración. Al ser
mini proyectos, comienzan con los casos de usos y continúan
con el análisis, diseño, implementación y prueba, y termina

82
convirtiendo los casos de uso en código ejecutable de dicha
iteración.

En cada iteración se identifican y se especifican los casos de uso

más relevantes, se crea un diseño utilizando la arquitectura
seleccionada como guía, se implementan componentes, y se
verifican que dichos componentes satisfacen los casos de uso.

Si la iteración cumple con sus objetivos, el desarrollo sigue

adelante. En caso contrario, se debe revisar y probar con un
nuevo enfoque.

Este proceso iterativo e incremental presenta los siguientes

beneficios:

 se reduce el costo del riesgo de un solo incremento. Esto

se debe a que si hay que repetir la iteración, la empresa
sólo pierde el esfuerzo de una iteración y no del proyecto
completo.
 reduce el riesgo de no sacar al mercado el producto en el
tiempo previsto.
 la iteración controlada acelera el ritmo del esfuerzo de
desarrollo en su totalidad pues los desarrolladores
trabajan en forma clara a corto plazo.
 la iteración controlada reconoce que las necesidades de
los usuarios y sus requerimientos no se pueden definir
completamente al principio. Luego la iteración controlada
ayuda a adaptarse a los requerimientos cambiantes.

83
10. Importancia de los 3 conceptos básicos del Proceso
Unificado.

¿Cuál es la importancia de estos 3 conceptos?

Dirigido por los casos de uso significa que los casos de uso se
utilizan como un artefacto básico para establecer el
comportamiento deseado del sistema, para verificar y validar la
arquitectura del sistema, para las pruebas y para la comunicación
entre las personas involucradas en el proyecto.

Centrado en la arquitectura significa que la arquitectura del

sistema se utiliza como un artefacto básico para conceptualizar,
construir, gestionar y hacer evolucionar el sistema en desarrollo.

Un proceso iterativo es aquel que involucra la gestión de de un

flujo de versiones ejecutables. Un proceso incremental es aquel
que implica la integración contínua de la arquitectura del sistema
para producir esas versiones, donde cada nuevo ejecutable
incorpora mejoras incrementales sobre los otros. En conjunto, un
proceso iterativo e incremental está dirigido por el riesgo, lo que
significa que cada nueva versión se encarga de atacar y reducir
los riesgos más significativos para el éxito del proyecto.

Los conceptos de desarrollo dirigido por los casos de uso,

centrado en la arquitectura, iterativo e incremental son muy
importantes y además tienen la misma importancia.

84
La arquitectura proporciona la estructura sobre la cual se guían
las iteraciones. Los casos de uso definen los objetivos y dirigen el
trabajo de cada iteración.

Si se elimina alguna de estas tres ideas se reduciría el valor del

Proceso Unificado.

85
ANALISIS Y DISEÑO DE SISTEMAS.

UNIDAD 3: La vida del Proceso Unificado.

1. El Modelo o Producto del Proceso Unificado.

2. Los Modelos dentro del Proceso Unificado.
3. Relación entre los Modelos y su Vista Autocontenida.
4. El Proceso y las Personas.
5. La incidencia del Proceso en las Personas.
6. El Proceso y los Flujos de Trabajo.
7. El Proceso y las Fases en un Ciclo.

1. El Modelo o Producto del Proceso Unificado.

En el Proceso Unificado y en su contexto el producto resultado

se le llama sistema software. El producto preparado para su
entrega tiene un código fuente que se compila y que se ejecuta,
con manuales y otros productos asociados.

En el Proceso Unificado este producto hace referencia al sistema

entero y no solamente al código que se entrega. Este producto
no sólo satisface las necesidades de los usuarios sino también a
todas las personas que trabajan con el producto.

El producto consta de requisitos, casos de uso, especificaciones

no funcionales y casos de prueba, utilizando varios tipos de
modelos. Todos estos elementos permiten a los clientes, usuarios,
analistas, diseñadores, programadores, ingenieros de prueba y

86
directores, que especifiquen, que diseñen, que implementen, que
prueben, y que utilicen el sistema.

En función de esto, también podemos decir que un sistema

software está compuesto por todos los artefactos que se
necesitan para representarlo de manera que lo entiendan las
máquinas (herramientas compiladores, ordenadores, etc),
hombres, trabajadores (directores, arquitectos, desarrolladores,
ingenieros de pruebas, administradores, etc) y los interesados
(usuarios, inversores, comerciales, jefes de proyecto, personal de
producción, etc).

Un artefacto es un término muy común para describir a cualquier

tipo de información creada, modificada o utilizada por los
trabajadores en el desarrollo del sistema. Por ejemplo un artefacto
son todos los diagramas y su texto asociado. Existen variados
tipos de artefactos.

Un tipo de artefacto muy utilizado es el modelo en el Proceso

Unificado. En este proceso vemos varios trabajadores y cada una
de sus perspectivas que usan o necesitan. Dichas perspectivas se
recogen en bloques y surgen los modelos.

Un modelo es una abstracción del sistema, especificando al

sistema modelado desde un punto de vista y en un determinado
nivel de abstracción. Los modelos son abstracciones del sistema
que construyen los arquitectos y desarrolladores.

87
2. Los Modelos dentro del Proceso Unificado.

Desde este punto de vista también podemos afirmar que todos los
elementos que componen el producto se organizan en modelos y
en consecuencia el producto está compuesto por varios modelos:

Modelo de casos de uso: contiene todos los casos de uso y su

relación con los usuarios.

Modelo de análisis: depura los casos de uso con más detalle y

comienza a establecer la funcionalidad del sistema con un
conjunto de objetos que brindan el comportamiento.

Modelo de diseño: define la estructura estática del sistema con

subsistemas, clases, e interfaces, y define los casos de uso
reflejados como colaboraciones (realizaciones de los casos de
uso) entre los subsistemas, clases e interfaces.

Modelo de despliegue: o modelo de distribución, define todos los

nodos físicos, que corresponden a os ordenadores, y cómo se
corresponden los componentes con dichos nodos.

Modelo de implementación: incluye componentes que

representan código fuente y la correspondencia de las clases con
dichos componentes.

Modelo de prueba: describe los casos de prueba que verifican

los casos de uso.

Además existen los Modelos de Dominio y de Negocio que

describen el contexto del negocio en el que se encuentra el
sistema.

88
3. Relación entre los Modelos y su vista autocontenida.

Todos estos modelos conforman al sistema total. Todos estos

modelos se relacionan entre sí mediante dependencias entre ellos
llamadas trazas, que permiten enlazar los modelos. La
trazabilidad permite que los usuarios y los desarrolladores
comprendan el sistema el pueden modificarlo fácilmente.

Podemos afirmar también, como consecuencia de esto, que el

sistema contiene relaciones entre elementos que pertenecen a los
distintos modelos. Por eso, un sistema no sólo es una colección
de modelos sino también contiene las relaciones entre ellos.

Dijimos que un modelo es una abstracción cerrada del sistema.

Se dice que constituye una vista autocontenida del sistema. Esto
significa que la información que el modelo contiene sólo basta
para comprender a ese modelo y no a otro.

Por ejemplo, el modelo de casos de uso comprende los casos de

usos y los actores y no necesita más información para
comprenderlo que esa misma. Así también el modelo de diseño
está compuesto por los subsistemas y las clases del sistema y
sus interacciones para llevara a cabo los casos de uso. Las
informaciones que estos modelos contienen son diferentes pero
pues los modelos están pensados para ser utilizados por
diferentes trabajadores que tienen distintos objetivos y tareas.
Uno tiene una vista externa y el otro una vista interna, el modelo
de casos de uso, que captura los requisitos del sistema y el
modelo de diseño, que representa la construcción del sistema.

Foro. Artefacto.

89
4. El Proceso y las Personas.

Finalmente podemos decir que el sistema es un proceso de

construcción de modelos que se utilizan para describir las
diferentes perspectivas del mismo. Estos modelos hacen claro el
sistema a todos los trabajadores desde clientes, usuarios hasta
jefes de proyectos. Y además los modelos fueron elegidos para
satisfacer las necesidades de información de los trabajadores.

Este proceso de desarrollo es un producto que toma forma

gracias a los diferentes tipos de personas que intervienen en él.
Este proceso guía el trabajo y el esfuerzo de todas estas
personas.

Todas estas personas implicadas en el desarrollo del producto

software durante todo su ciclo de vida, financian el producto, lo
planifican, lo desarrollan, lo gestionan, lo prueban, lo utilizan y se
benefician de él. Luego, este proceso debe estar totalmente
orientado a estas personas, funcionando correctamente para que
ellas lo utilicen.

El proyecto es un elemento organizativo a través del cual se

gestiona el desarrollo de software. Su resultado es una versión del
un producto.

El producto está compuesto por los artefactos que se crean

durante la vida del proyecto, como los modelos, códigos fuentes y
ejecutables y documentación.

El proceso es un proceso de ingeniería de software que define al

conjunto completo de actividades necesarias para transformar los
requisitos de usuario en un producto.

90
Las herramientas están constituídas por el software que se
utilizan para automatizar las actividades definidas en el proceso.

Las personas son los arquitectos, desarrolladores, ingenieros de

prueba, y el personal de gestión que les da soporte, además de
los usuarios, clientes y otros interesados. Las personas son seres
humanos.

En la organización de desarrollo de software estas personas

ocupan diversos puestos y su preparación requiere de formación y
entrenamiento.

A estas personas se les asignan y aceptan puestos, los cuales

se denominan trabajador. Un tipo e trabajador es un papel que
una persona puede desempeñar en el desarrollo de software, por
ejemplo, un especificador de casos de uso, un programador, un
arquitecto, un ingeniero de pruebas, etc. El término trabajador
tiene que ver con el puesto que asume una persona. El rol es el
papel que cumple un trabajador.

Un trabajador puede asumir roles en relación con otros

trabajadores en diferentes flujos de trabajo. Por ejemplo, un
trabajador ingeniero de pruebas puede participar en distintas
flujos de trabajo y puede desempeñar distintos roles en cada uno.

Cada trabajador en particular necesita conocer la información

para realizar sus actividades, es decir, necesitan conocer cuáles
son sus roles.

A su vez, cada trabajador puede representar a un conjunto de

personas que trabajan juntas. Por ejemplo, un trabajador

91
 especificador de casos de uso está compuesto por un grupo de
ellos.

Cada trabajador tiene un conjunto de responsabilidades y lleva a

cabo un conjunto de actividades en el desarrollo de software.

Para asignar los trabajadores a un proyecto, los jefes del mismo

deben conocer las aptitudes de las personas para que combinen
con los roles de los trabajadores. Es decir, se deben combinar las
habilidades de los recursos que son las personas reales con las
competencias especificadas por los diferentes trabajadores.

Una persona puede ser varios trabajadores durante toda la vida

del proyecto. Por ejemplo una persona en el proyecto puede
comenzar como especificador de casos de uso y luego pasar a
ser ingeniero de pruebas.

5. La incidencia del Proceso en las Personas.

La forma en la que se organiza y se gestiona un proyecto de

software afecta tremendamente a todas las personas que están
involucradas en él.

Viabilidad del proyecto. Cuando se trabaja iterando a través de

fases en los proyectos que parecen imposibles y no son viables,
se puede detener su marcha, descartando problemas de moral.

92
 Gestión de riesgo. De la misma manera se puede detener el
proyecto en las primeras fases, cuando las personas se sienten
incómodas al no tener analizado los riesgos.

Estructura de los equipos. Un proceso que trabaja organizando

pequeños grupos de trabajo, produce trabajo significativo. Las
personas trabajan en forma más eficaz en grupos pequeños.

Planificación del proyecto. Cuando se trabaja teniendo la

sensación adecuada de los que debería ser el producto final,
puede crearse un plan de proyecto realista. Eso influye
positivamente en la moral de las personas que trabajan.

Facilidad de comprensión del proyecto. Los diagramas, las

descripciones de los modelos y de la arquitectura hacen que las
personas posean una comprensión global de lo que se está
haciendo.

Sensación de cumplimiento. En un ciclo de vida iterativo, las

personas reciben retroalimentación permanentemente y eso le da
sensación de progreso a las personas.

6. El Proceso y los Flujos de Trabajo.

En el Proceso Unificado el proceso de desarrollo de software es

una definición del conjunto completo de actividades necesarias
para convertir los requisitos de usuario en un conjunto consistente
de artefactos que conforman el producto software y para luego
convertir los cambios sobre esos requisitos en un nuevo conjunto
consistente de artefactos.

93
Los requisitos tienen que ver con comprender las necesidades de
los clientes. Además se debe comprender o capturar los requisitos
que tienen que ver con el negocio de los clientes y el entorno en
el que trabajan los usuarios.

El resultado de valor añadido del proceso es un conjunto de

artefactos, una línea base que conforma una aplicación o un
conjunto de ellos que forman el producto software.

Un proceso es una definición de un conjunto de actividades y no

su ejecución. Además, no cubre la primera versión (primer ciclo)
sino también las versiones posteriores (ciclos posteriores). Es
decir, la primera instancia del proceso cambia incrementalmente a
través del tiempo.

Un flujo de trabajo es un conjunto de actividades y como

anteriormente definimos a un proceso, podemos decir que se
descompone en varios flujos de trabajos que interactúan entre sí.

Para definir los flujos de trabajo podemos realizar lo siguiente:

primero, se identifican los distintos tipos de trabajadores que
participan en el proceso y segundo, se identifican los artefactos
que se necesitan crear durante el proceso para cada tipo de
trabajador. Estas identificaciones de trabajadores y artefactos
necesitan de mucha experiencia, pero una vez que se consigue
se puede describir cómo fluye el proceso a través de los distintos
trabajadores y cómo éstos utilizan los artefactos entre los demás.

94
 A partir de esto se puede identificar fácilmente las actividades
que los trabajadores deben llevar a cabo cuando se activan.
Estas actividades son significativas para cada persona que actúa
como trabajador. Además se puede observar fácilmente si un
trabajador necesita participar en más de un flujo de trabajo.

Por eso podemos decir que el proceso se puede describir en

función de flujos de trabajo. Un flujo de trabajo es un estereotipo
donde los trabajadores y los artefactos intervienen o participen.
Por lo tanto, a su vez podemos decir que un trabajador y los que
participan en un flujo de trabajo también pueden participar en otro
flujo de trabajo.

7. El Proceso y las Fases en un Ciclo.

Las Fases en un Ciclo del Proceso Unificado.

El proceso Unificado se repite a lo largo de una serie de ciclos.

Estos ciclos constituyen la vida del sistema y cada ciclo
constituye una versión para los usuarios.

Nacimiento Muerte

Tiempo

Los ciclos concluyen con una versión

95
La vida de un proceso consta de ciclos desde su nacimiento hasta
su muerte.

Cada ciclo está constituído por cuatro fases: inicio, elaboración,

construcción, y transición. Cada fase se subdivide en iteraciones.

Tiempo

Inicio Elaboración Construcción Transición

Iteración Iteración Iteración Iteración
1 2 n-1 n

Versiones

Un ciclo con sus fases e iteraciones.

Pero, ¿qué es una fase?

Este proceso Unificado dirigido por casos de uso, centrado en la

arquitectura, iterativo e incremental puede descomponerse en
fases.

Una fase es el intervalo de tiempo entre dos hitos importantes del

proceso, cuando se cumple un conjunto de objetivos bien
definidos, se completan los artefactos y se toman las decisiones
sobre si pasar o no a la siguiente fase.

96
 Fases

Flujos de
Trabajo
Fundamentales Inicio o Elaboración Construcción Transición
Requisitos Concepción

Análisis Una iteración

en la fase de
elaboración.
Diseño

Implement

Prueba

Iteración Iteración Iteración Iteración

1 2 n-1 N

Iteraciones

En este diagrama se ven los flujos de trabajo frente a estas fases,

mostrando cómo varía a lo largo del tiempo el nivel del atención
que una fase le da a un flujo de trabajo. Por ejemplo, lo que se
observa en azul es una iteración que es un mini proyecto con
todos sus flujos de trabajo, en la fase de elaboración.

Las diferentes fases del Proceso Unificado.

La fase de Inicio o Concepción.

Durante esta fase se desarrolla la descripción del producto final a

partir de una buena idea y se presenta el análisis del negocio para
el producto.

Una de las ideas más importantes en esta fase de inicio es tener

en cuenta las principales funciones del sistema para los usuarios
más importantes. No hay que olvidarse de la arquitectura del
sistema. Y finalmente también recordar cuál es plan l proyecto
cuánto costará desarrollar el proyecto.

97
Todo esto se ve en un modelo de casos de uso simplificado que
tiene los casos de uso más críticos. Luego la arquitectura es
bastante provisional y consiste en un esbozo que contiene los
subsistemas más importantes. Se identifican y se priorizan los
riesgos más importantes.

La fase de Elaboración.

Se especifican la mayoría de los casos de uso de del producto y

se diseña la arquitectura del sistema. Esto significa que se deben
expresar con claridad los requisitos del sistemas, se priorizan y
se utilizan para crear una sólida base arquitectónica. Los
requisitos son simples enunciados de carácter general hasta
criterios precisos de evaluación, que pueden ser funcionales o no
y a su vez se puede dar referencia para las pruebas.

La arquitectura se expresa en función de todos los modelos de

sistemas. Esto significa que hay vistas arquitectónicas del modelo
de casos de uso, del modelo de análisis, del modelo de diseño,
del modelo de implementación y del modelo de despliegue. La
vista del modelo de implementación incluye componentes para
probar que la arquitectura es estable. Durante la fase de
desarrollo se realizan los casos de uso más importantes que se
identificaron en la fase de comienzo. El resultado de esta fase es
una línea base de la arquitectura.

Finalmente, el director del proyecto puede planificar las

actividades y estimar los recursos factibles para terminar el
proyecto.

98
La fase de Construcción.

En esta fase se crea el producto, es decir, se aporta al esqueleto,

que es la arquitectura, añadiendo los músculos que es el software
terminado.

La línea base evoluciona hasta convertirse en un producto

terminado para que se le entregue a la comunidad de usuarios. A
pesar que al final de esta fase el producto presenta la mayoría de
los caos de uso que la dirección y los clientes han acordado,
puede que tenga algún defecto. En este momento es cuando nos
cuestionamos si servirá para llevar a cabo una primera entrega.

La fase de Transición.

Aquí el producto se convierte en versión beta, donde un número

reducido de usuarios con experiencia prueba el producto y
finalmente incorporan algunas mejoras.

En esta etapa, además se llevan a cabo una línea de ayuda y

asistencia y la corrección de los defectos tras la entrega. El
equipo de mantenimiento se divide en corregir los defectos para
justificar una versión incrementada y los que se pueden corregir
posteriormente en una versión normal.

Nuevamente podemos recalcar que el Proceso Unificado está

basado en componentes y se sostiene sobre estas tres ideas

99
básicas, casos de uso, arquitectura y desarrollo iterativo e
incremental.

Para llevar a cabo esto, necesitamos que el proceso esté

constituido por ciclos, fase, flujos de trabajo, gestión del riesgo,
control de calidad, gestión de proyecto, y control de la
configuración. Justamente el Proceso Unificado contiene todos
estos conceptos.

Foro. Iteración y Flujos de trabajo.

100
ANALISIS Y DISEÑO DE SISTEMAS.

Unidad 4: Casos de Uso dirigen el Proceso. Flujos de Trabajo y Modelos.

1. Flujos y Modelos.
2. Los Modelos.
3. Objetivos de los Casos de Uso.
4. Modelo de Casos de Uso.
5. Modelo de Análisis.
6. Modelo de Diseño.
7. Modelo de Implementación.
8. Modelo de Prueba.

1. Flujos y Modelos.

Una de las primeras tareas que se deben llevar a cabo con el

Proceso Unificado es capturar las necesidades de los usuarios de
tal manera que se puedan comunicar fácilmente con todas las
personas implicadas en el proyecto.

Luego, dadas dichas necesidades, se debe poder diseñar la

implementación funcional y finalmente mediante la prueba se
debe verificar que las necesidades del cliente se han cumplido.

Se puede tener una visión de flujos de trabajos que constituyen el

sistema, para describir todo el Proceso. El Proceso Unificado está
dirigido por casos de uso, centrado en la arquitectura, y es
iterativo e incremental. Como ya hemos mencionado, el Proceso
está constituido por flujos (requisitos, análisis, diseño,
implementación y prueba) y modelos (de casos de uso, de

101
 análisis, de diseño, de despliegue, de implementación, de
prueba).

Los desarrolladores comienzan capturando los requisitos en forma

los casos de uso. Aparece el modelo de casos de usos. Luego
analizan y diseñan el sistema para cumplir los casos de uso,
creando el primer modelo de análisis, luego otro de diseño, y
después otro modelo de implementación que contiene los
componentes con el código. Al final se prepara un modelo de
prueba donde el sistema proporcione la funcionalidad descripta
por los casos de uso. Todos ellos se relacionan mediante
dependencias de trazas.

El modelo de casos de uso es el modelo menos formal y se

describe mediante un lenguaje natural.

Los casos de uso sirven para la captura de los requisitos de

sistemas software, pero además constituyen una herramienta muy
importante en todo el Proceso Unificado. Para cada iteración, los
casos de uso nos guían a través de los flujos de trabajos, desde la
captura de requisitos hasta las pruebas, pasando por todos los
flujos trabajo.

2. Los Modelos.

Por una cuestión de simplicidad, veremos al Proceso Unificado

como una secuencia de pasos, detallados en una sola iteración,
una sola pasada a través de los flujos de trabajo de requisitos,
análisis, diseño, implementación, y prueba, (a pesar que un
proyecto completo lo componen una serie de iteraciones).

102
Un sistema tiene muchos tipos de usuarios, cada unos de ellos
representado por un actor, que interactúan con el sistema con los
casos de uso.

Un caso de uso es una secuencia de acciones que el sistema

lleva a cabo para ofrecer algún resultado de valor para algún
actor.

El modelo de casos de uso está compuesto por todos los

actores y todos los casos de uso de un sistema. Durante el
análisis y el diseño, el modelo de casos de uso se transforma en
un modelo diseño a través de un modelo de análisis. Estos dos
modelos, el del análisis y el de diseño son estructuras
compuestas por clasificadores y por realizaciones de casos de
uso que dicen cómo esas estructuras realizan los casos de uso.

El modelo de análisis es una especificación detallada de los

requisitos y funciona como una primera aproximación del modelo
de diseño. Es un modelo con entidad propia y los desarrolladores
lo utilizan para entender mejor los casos de uso que se describen
en el flujo de trabajo de loa requisitos, depurándolos en forma de
colaboraciones. Este modelo se utiliza para crear un sistema
firme y flexible que incluye una arquitectura y que vuelve a utilizar
sus componentes. Este modelo es un modelo conceptual.

En cambio el modelo de diseño es un esquema de la

implementación. Este modelo es jerárquico y contiene relaciones.
Las realizaciones de los casos de uso se llaman estereotipos.
Existe una correspondencia directa entre subsistemas del modelo
de diseño y componentes del modelo de implementación. Se
pueden definir interfaces entre dichos subsistemas.

103
Los desarrolladores también preparan el modelo de despliegue
donde se define la organización física del sistema en términos de
nodos de cómputos que verifican que los casos de uso pueden
implementarse como componentes que se ejecutan en esos
nodos.

Posteriormente, los desarrolladores implementan lo diseñado

mediante archivos de código fuente en el modelo de
implementación a partir del cual se producen elementos
ejecutables. Los casos de uso ayudan a determinar el orden de
implementación i integración de los componentes.

Finalmente, los ingenieros de prueba verifican que el sistema

cumple con la funcionalidad que describen los casos de uso y que
cumplimentan los requisitos del sistema. Este modelo de prueba
lo componen los casos de prueba que definen una colección de
entradas, con condiciones de ejecución y resultados. La mayoría
de los casos de prueba se obtienen directamente de los casos de
uso, por lo tanto existe una dependencia directa de traza entre el
caso de prueba y el caso de uso. Significa que a través de las
pruebas se puede verificar que el sistema haga lo que los
usuarios quieran que hagan, que el sistema ejecuta los casos de
uso.

Se llama pruebas de la caja negra, a aquellas que se planifican al

principio del ciclo de desarrollo, es decir, tan pronto como se
capturan los casos de uso se pueden especificar los casos de
prueba y determinar el orden en que se van a realizar, integrar y
probarlos. Luego, a medida que se van realizando a cabo los
casos de uso en el diseño, se pueden ir detallando las pruebas de
dichos casos de uso y se denominan pruebas de la caja blanca.

104
 Se llama caso de prueba candidato a cada forma de ejecutar un
caso de uso o cada camino a través de una realización de un
caso de uso.

3. Objetivos de los Casos de Uso.

Los casos de uso aportan valor agregado al sistema.

La captura de requisitos tiene dos objetivos fundamentales. Unos

de ellos es encontrar los verdaderos requisitos y el otro es
representarlo de una manera satisfactoriamente adecuada para
los usuarios, clientes y desarrolladores.

El objetivo fundamental del flujo de trabajo de los requisitos es

encontrar verdaderos requisitos. Cuando mencionamos
verdaderos requisitos queremos decir que son aquellos requisitos
que cuando se implementen agregarán el valor esperado para
los usuarios y los clientes.

Al expresar que un caso de uso debe agregar valor agregado para

los usuarios y clientes, se quiere decir que la descripción
obtenida por los requisitos debe ser compresible por usuarios y
clientes.

Además se dice que es un buen caso de uso aquel que agrega

valor al negocio. Y aquellos que aportan poco valor al negocio se
consideran casos sin uso, no se tienen en cuenta si quiera. Para
lograr un buen caso de uso, podríamos escribir una lista de
funciones el sistema y luego reformular la siguiente pregunta al
final de cada función: ¿qué quiere que haga el sistema para cada

105
usuario? De esta manera no sugerimos funciones que
proporcionan valor agregado al sistema.

Los casos de uso deben ser intuitivos y deben tener lenguaje

natural, simple castellano, para que tengan fácil lectura y
comprensión. A su vez, la captura de los casos de uso
comprende a los usuarios, los desarrolladores y a los clientes. Los
usuarios y los clientes son expertos en los requisitos y los
desarrolladores deben colaboran con ellos en que comuniquen
correctamente sus necesidades. El modelo de casos de uso
justamente consigue que los usuarios y los clientes se pongan de
acuerdo sobre lo que el sistema debería hacer.

Los casos de uso ayudan a dirigir el proceso.

El Proyecto Unificado se dice que está dirigido por casos de uso

cuando progresa a través de flujos de trabajo que comienzan con
casos de uso.

Los casos de uso enlazan los flujos de trabajo fundamentales,

requisitos, análisis, diseño, implementación, y prueba.

Los casos de uso ayudan a los jefes de proyectos a planificar,

asignar y controlar las tareas que llevan a cabo los
desarrolladores. Cuando se especifica un caso de uso aparece
una tarea, lo mismo cuando se diseña un caso de uso e
idénticamente cuando se lo prueba. Con lo cual el jefe de
proyecto puede estimar el esfuerzo y el tiempo que se necesitan
para llevar a cabo dichas tareas. Luego se asignan dichas tareas
a desarrolladores concretos que se hacen responsables de las
mismas.

106
Podemos decir que los casos de uso constituyen un elemento que
sirve para brindar trazabilidad al proyecto de desarrollo a través
de todos los modelos. Este aspecto es muy importante para la
gestión de un proyecto. Al modificar un caso de uso, todos los
componentes de los modelos se deben comprobar para ser
actualizados y la trazabilidad entre los casos de uso hace muy
fácil mantener la integridad del sistema y conservar actualizado al
sistema.

Los casos de uso ayudan a idear la arquitectura.

En cada iteración se identifican e implementan varios casos de

uso. Visto de otra forma, cada iteración, excepto la primera de
todas en un proyecto se dirige por los casos de uso a través de
todos los flujos de trabajo, de los requisitos a la prueba, y se tiene
un incremento. Cada uno de estos incrementos del desarrollo es
una realización funcional de un conjunto de casos de uso.

Los casos de uso a su vez, ayudan a construir la arquitectura.

Eligiendo cuidadosamente los casos de uso se llevarán a cabo en
las primeras iteraciones se puede implementar un sistema estable
que se puede utilizar en muchos ciclos subsiguientes.

Los casos de uso son el puntapié inicial para escribir el manual de

usuario. Esto se debe a que cada caso de uso explica cómo el
usuario puede interactuar con el sistema.

107
4. Modelo de Casos de Uso.

En el flujo de trabajo de los requisitos lo importante es la captura

de los requisitos funcionales. Se identifican las necesidades de los
clientes y de los usuarios.

Los requisitos funcionales se expresan como casos de uso en un

modelo de casos de uso y los demás requisitos se adjuntan a los
casos de uso o se guardan en una lista aparte o se describen de
alguna manera.

Expresado de otra manera el modelo de casos representa los

requisitos funcionales.

Este modelo ayuda a los clientes, a los usuarios y a los

desarrolladores a ponerse de acuerdo a cómo utilizar el sistema.

Cada tipo de usuario está representado por un actor. Estos

utilizan el sistema a través de los casos de uso interactuando con
ellos. El modelo de casos de uso lo forman los actores y los
casos de uso.

A su vez, el diagrama de casos de uso sirve para describir parte

del modelo de casos de uso y muestra los casos de usos y los
actores con una asociación entre par de actor/caso de uso que
interactúan.

108
Debe tenerse en cuenta que los actores no son sólo personas,
sino que pueden ser otros sistemas o hardware externo que
interactúa con el mismo sistema. Cada actor tiene asumido un
conjunto de papeles al interactuar con el sistema.

Un usuario físico puede actuar como varios actores y debe

desempeñar sus papeles al interactuar con el sistema. Además
puede haber varios usuarios que desempeñen el mismo actor en
distintas ocurrencias.

Mientras se realizan los casos de uso, los actores se comunican

con el sistema enviando y recepcionando mensajes. Al definir lo
que hacen los actores y los casos de uso, se separan las
responsabilidades de los actores y del sistema, que ayudan a
delimitar el alcance el sistema.

Se encuentran y se especifican los actores, viendo a los usuarios

que utilizan el sistema y a otros sistemas que deben interactuar
con él. Cada categoría de usuario o sistema que interactúan con
el mismo sistema corresponden a actores.

Los casos de uso sirven para cumplir los deseos de los usuarios
cuando utilizan el sistema. El modelo de casos de uso captura los
requisitos funcionales.

Teniendo en cuenta esto, podemos definir a un caso de uso como

a una secuencia de acciones, con sus variantes, que el sistema
puede llevar a cabo, y que produce un resultado observable que
le da valor a un actor concreto.

Para identificar los casos de uso conviene ver a los usuarios y su

forma de utilizar el sistema para llevar a cabo su trabajo. Eso es

109
justamente lo que añade un valor agregado al usuario y se lo
toma como un caso de uso candidato. Estos casos de uso se
ampliarán, se dividirán o se achicarán o integrarán otros casos de
uso más completos.

Se termina el modelo de casos de uso cuando se reúnen todos

los requisitos funcionales de tal manera que los desarrolladores,
los clientes y usuarios puedan entender.

Para poder escribir un caso de uso se debe seguir la secuencia

de acciones realizada por el caso de uso.

En los casos de uso también se escriben los requisitos no

funcionales, a saber, los requisitos de exactitud, de rendimiento,
de disponibilidad, o de seguridad que sean específicos de dicho
caso de uso.

Finalmente en el modelo de casos de uso intervienen los actores,

que son los clientes, usuarios y desarrolladores y los casos de
uso. El diagrama de casos de uso sirve para describir estos
componentes y sus asociaciones que deja ver la interacción entre
el actor y los casos de uso. Esto comprende los requisitos
funcionales. Los no funcionales también están contenidos en este
modelo. Todos los actores lo comprenden. Los desarrolladores lo
utilizan para capturar los requisitos del sistema y luego tomarlos
de entrada para el análisis, diseño, implementación y prueba del
sistema.

110
5. Modelo de Análisis.

Aparece y se incrementa el modelo de análisis cuando se

analizan los casos de uso de a poco. Es decir, se comienza en
cada iteración con un conjunto de casos de uso reflejado en el
modelo de análisis. Luego en las iteraciones posteriores,
aparecen otros casos de uso, que se van sumando a la iteración
anterior, y así sucesivamente.

El modelo de análisis construye el sistema como una estructura

de clasificadores, que corresponden a las clases de análisis, y
relaciones entre ellas. A su vez se describen las colaboraciones,
que son las realizaciones de los casos de uso.

Primero se debe identificar y describir los casos de uso para una

iteración y en segundo lugar leer la descripción de cada caso de
uso y se proponen los clasificadores y las asociaciones para
realizar los casos de uso.

Cada clasificador desempeña uno o varios roles en una

realización de un caso de uso. Esto significa que hay que
establecer las responsabilidades, atributos y demás que el
clasificador debe tener para desempeñar un papel al realizar un
caso de uso. Podemos pensar que el rol es un clasificador en sí
mismo, es decir, el rol de una clase es la vista de una clase.

Para comenzar debemos preparar las realizaciones de pocos

casos de usos. Allí se describe cómo se lleva a cabo un caso
de uso mediante una colaboración, que es la realización de los
casos de uso, se esbozan las clases o clasificadores, sus
relaciones y un estereotipo de dependencia, traza, entre la
colaboración y el caso de uso. Esta traza establece la

111
dependencia entre el modelo de casos de uso y el modelo de
análisis.

Además le agregamos los roles a los clasificadores. Luego

hacemos lo mismo para otros casos de uso y proponemos nuevos
roles a los clasificadores. Puede pasar que los clasificadores ya
existan y se completan sus roles o modifiquen o que se creen
otros nuevos con roles diferentes.

Así volvemos a revisar los que ya hicimos y el modelo de análisis

se va construyendo.

En el modelo de análisis tres tipos diferentes de clasificadores o

clases: de interfaz, de control y de entidad. La clase de interfaz se
utiliza para modelar la interacción entre el sistema y los actores,
es decir, los usuarios y los sistema externos. La clase de control
se utiliza para representar secuenciamiento, coordinación,
transacciones y control de otros objetos y el control relativo a un
caso de uso. La clase de entidad sirve para modelar la
información que tiene larga vida y que a veces es persistente.

Cuando una clase participa en varias realizaciones de casos de

usos en el modelo de análisis, aparecen los diagramas de clases.
En este tipo de diagrama se observan los dos modelos de casos
de usos y el modelo de análisis. Muestra cómo cada caso de uso
se realiza como una estructura de clases de análisis.

En este diagrama de clases se coloca el modelo de casos de uso

con los actores y los casos de uso. Por otro lado, el modelo de
análisis con los actores, las diferentes clases y sus relaciones.
Todas las clases desempeñan roles en todas las realizaciones de

112
los casos de usos. Estos diagramas también pueden utilizarse
para mostrar subsistemas e interfaces.

Todo lo mencionado hasta ahora tiene que ver con la estructura

del sistema, luego se debe ver los diferentes patrones de
interacción necesarios para la realización de cada caso de uso.
Significa que se debe ver cómo se lleva a cabo o cómo se
instancia o cómo se ejecuta una realización de caso de uso. Es
decir, se debe ver cómo los objetos de esas clases interactúan
para llevar a cabo la realización del caso de uso.

Para poder observar esto se utilizan los diagramas de

colaboración. Dicho de otra manera, los diagramas de
colaboración tienen como objetivo modelar las interacciones entre
objetos en el análisis. Este tipo de diagrama es parecido al
diagrama de clases, pero en lugar de clases y asociaciones
contiene instancias y enlaces. Además, en el diagrama de
colaboración se observa interactúan los objetos secuencialmente
o en paralelo, mostrando los mensajes que se envían unos a
otros.

El diagrama de colaboración muestra cómo el control pasa de un

objeto a otro a medida que se lleva a cabo un caso de uso y los
mensajes que se envían entre los objetos. Un mensaje de un
objeto dispara al objeto receptor para que tome el control y lleve a
cabo una de las responsabilidades de su clase. El nombre de un
mensaje índice el motivo del objeto que realiza la llamada en su
interacción con el objeto invocado.

También se puede usar texto como complemento para explicar

cómo interactúan los objetos para llevar a cabo el flujo de
eventos del caso de uso.

113
 Hasta ahora siempre analizamos cada caso de uso y por lo tanto
se observan los roles de clase que corresponden en cada
realización de caso de uso. Luego si juntamos todos los roles de
todas las realizaciones de casos de uso y eliminamos las
repeticiones de roles, se lograrán las responsabilidades y
atributos de la clase.

Los desarrolladores responsables de especificar los roles de las

clase son los responsables de analizar y realizar los casos de uso.
Ellos agrupan todos los roles de la clase en un conjunto completo
de responsabilidades para la clase y luego los integra en un
conjunto consistente de responsabilidades. Finalmente se puede
decir que cada clase debe cumplir todos sus roles de
colaboración.

6. Modelo de Diseño.

El modelo de análisis sirve como una primera aproximación del

modelo de diseño y éste sirve de base o funciona como esquema
para el modelo de implementación.

El sistema de diseño toma como entrada al modelo de análisis,

pero a su vez, se tiene que adaptar a un sistema de
implementación elegido, por ejemplo, un sistema de base de
datos, entornos de trabajos desarrollados para el proyecto, un
sistema heredados y su reutilización.

De la misma manera que el modelo de análisis, el modelo de

diseño define clasificadores, relaciones ente ellos y
colaboraciones que llevan a cabo los casos de uso, realizaciones

114
de esos casos de uso. Pero en este modelo los elementos se
adaptan al entorno de la implementación, es decir, el modelo de
diseño es físico y el modelo de análisis es conceptual.

Como hemos visto, existen realizaciones de casos de uso en

ambos modelos que surgen de un primitivo caso en el modelo de
casos de uso, por lo tanto se puede hacer una traza (un
estereotipo de dependencia) entre ellos.

Las realizaciones de caso de uso en los modelos tienen objetivos

diferentes. Por ejemplo, cuando se diseñan clases o clasificadores
de análisis surgen clases de diseño refinadas que tienen en
cuenta el entorno de implementación.

Existen clases de diseño que tiene una sola traza o varias a una
clase del modelo de análisis.

Una realización de un caso de uso en el modelo de diseño debe

describir cómo se realiza el caso de uso en término de las clases
de diseño correspondientes. Para ello se utiliza un diagrama de
de clases, para la realización de un caso de uso en el modelo de
diseño.

Este diagrama de clases tiene más detalle que el correspondiente

en el modelo de análisis. Esto es debido a que el modelo de
diseño se adapta al entorno de implementación. Cada clase de
diseño participa y asume roles en la realización del caso de uso.

Así como en el modelo de análisis existe el diagrama de

colaboración, en el modelo de diseño se deben identificar las
interacciones entre los objetos del diseño que aparecen cuando
se lleva a cabo un caso de uso, en un diagrama de secuencia.

115
El diagrama de secuencia tiene como objetivo modelar las
interacciones entre los objetos del diseño. Este diagrama muestra
cómo el control pasa de un objeto a otro a medida que se ejecuta
el caso de uso y a medida que se envían mensajes entre objetos.
Cuando un objeto envía un mensaje a otro, hace que este objeto
receptor tome el control y la realización de las operaciones de su
clase.

Si comparamos el diagrama de colaboraciones del modelo de

análisis con el diagrama de secuencia del modelo de diseño, éste
último contiene más complejidad y más cantidad de detalle.

De la misma forma, se puede utilizar texto para complementar en

el diagrama de secuencia, que explica cómo interactúan los
objetos de diseño para llevar a cabo el flujo de eventos del caso
de uso.

El modelo de diseño tiene gran cantidad de clases, por lo tanto, es

necesario o conveniente organizarlas en subsistemas. Se hace
muy complicado comprender el sistema sin una organización de
más alto nivel.

Las clases se agrupan en subsistemas. Un subsistema es un

agrupamiento útil de clase o de otros subsistemas. Un subsistema
posee interfaces, que definen el contexto del subsistema, los
actores y otros subsistemas y clases.

116
7. Modelo de Implementación.

Durante el flujo de trabajo de la implementación se desarrolla todo

lo necesario para obtener un sistema ejecutable. Este modelo de
implementación está compuesto por componentes ejecutables,
archivos de código fuente, componentes de tabla que son
elementos de base de datos, etc.

Un componente constituye una parte física y reemplazable del

sistema que cumple y además proporciona la realización de un
conjunto de interfaces. Es decir, un componente reconoce un
contexto de la arquitectura definido por sus interfaces y es
reemplazable pues se puede intercambiar con otro siempre que el
nuevo necesite y brinde las mismas interfaces.

8. Modelo de Prueba.

El modelo de prueba está compuesto por casos de prueba y

procedimientos de prueba. Con este modelo se verifica si el
sistema implementa correctamente su especificación. Ejecutando
los casos de prueba se chequea que el sistema funciona como se
espera.

Un caso de prueba es un conjunto de entradas de pruebas,

condiciones de ejecución y resultados esperados. Tienen un
objetivo concreto que es el de probar un camino concreto a través
de un caso de uso o chequear que se cumpla un requisito
específico.

117
Un procedimiento de prueba es una especificación de cómo poner
en marcha la preparación, la ejecución y la evaluación de los
resultados de un caso de prueba en particular.

Los casos de prueba pueden derivarse de los casos de uso.

Se identifica un caso de prueba a partir de un caso de uso en el

modelo de prueba utilizando un caso de uso del modelo de uso,
un caso de prueba de modelo de prueba y un estereotipo de
dependencia, traza.

Al evaluar los resultados, los defectos que se encuentran se

analizan para localizar el problema, luego se priorizan y se
corrigen por orden de importancia.

La forma más práctica de implementar la prueba de los casos de

uso que se han implementado correctamente, es la prueba que el
sistema puede utilizarse de manera que tenga sentido para los
usuarios. A pesar que esto lo han hecho todos los desarrolladores
desde todos los tiempos, es una técnica novedosa, ya que el caso
de prueba se identifica durante el flujo de trabajo de los requisitos,
antes que se diseñe el sistema.

Mediante la identificación temprana de los casos de uso, se puede

comenzar al principio la planificación de las tareas de prueba y
proponer los casos de prueba. Luego durante el diseño, estos
casos de uso se detallan un poco más a medida que sepamos
como el sistema llevará a cabo los casos de uso.

Finalmente, hay que asegurarse que el diseño realmente

implemente los casos de uso.

118
ANALISIS Y DISEÑO DE SISTEMAS.

Unidad 5: La arquitectura dirige el Proceso.

1. La arquitectura.
2. Descripción de la arquitectura.
3. Objetivos de la arquitectura.
4. Restricciones de la arquitectura.
5. Desarrollo de la arquitectura.
6. Patrones de la arquitectura.

1. La arquitectura.

Los casos de uso son el puntapié inicial para producir el sistema

y nos muestran el camino pero no son suficientes. Se necesita de
otro elemento para conseguir el sistema.

Es lo que especifica el arquitecto en la descripción de la

arquitectura. Esta descripción le permite controlar el desarrollo
del sistema desde el punto de vista técnico. La arquitectura
software se centra en los elementos estructurales significativos
del sistema como subsistemas, clases, componentes y nodos,
como en las colaboraciones que tienen lugar entre estos
elementos a través de las interfaces.

Como siempre dijimos, los casos de uso dirigen la arquitectura

para hacer que el sistema brinde la funcionalidad requerida por

119
 los usuarios y clientes, tratando de cumplimentar con un objetivo
de rendimiento.

La arquitectura debe ser amplia desde el punto de vista técnico y

capaz de alcanzar la flexibilidad, es decir, ser capaz de incorporar
nuevas funciones, como a su vez también ser capaz de soportar
la reutilización de software existente.

La arquitectura se desarrolla en forma iterativa en la fase de

elaboración pasando por los flujos de trabajo de requisitos,
análisis, diseño, implementación y pruebas. Se toma como base
los casos de uso que son más significativos para la arquitectura y
otro conjunto de entradas que tienen que ver con el esqueleto del
sistema.

La arquitectura describe los cimientos del sistema que son

necesarios como base para comprenderlo, desarrollarlo y
producirlo.

2. Descripción de la arquitectura.

Un sistema software es un conjunto completo pero los

desarrolladores les parece interesante ver el sistema desde
diferentes perspectivas para comprender aún mejor el sistema.
Las denominan vistas del modelo del sistema.

La descripción de la arquitectura es una vista de los modelos del

sistema, de los modelos de casos de uso, análisis, diseño e
implementación y despliegue.

120
Todas las vistas juntas representan la arquitectura.

La arquitectura abarca aspectos importantes que tienen que ver

con la organización del sistema; los elementos estructurales que
compondrán el sistema y sus interfaces, y sus comportamientos,
como se ven en las colaboraciones entre estos elementos; la
composición de los elementos estructurales y del comportamiento
en subsistemas.

Finalmente, la arquitectura tiene un estilo que guía la

organización de los elementos, sus interfaces, sus colaboraciones
y su composición.

A pesar de esto, también la arquitectura está influenciada por el

uso, la funcionalidad, el rendimiento, la flexibilidad, la reutilización,
la facilidad de comprensión, restricciones económicas,
tecnológicas y estéticas.

La arquitectura se representa mediante vistas del modelo. Una

vista del modelo de casos de uso, otra del modelo de análisis, otra
del modelo de diseño, y así sucesivamente. Cada vista es una
parte de cada modelo. Por ejemplo, la vista del modelo de casos
de uso es similar al modelo de casos de uso, tiene actores y
casos de uso, sólo que aquellos que sirven o son significativos a
la arquitectura. Igualmente para los otros modelos. La descripción
de la arquitectura es una descripción completa del sistema pero
más pequeña.

121
3. Objetivos de la arquitectura.

Un sistema software abarca un comportamiento complejo y

necesita de una arquitectura pues el sistema es difícil de abarcar
y ella ayuda a los desarrolladores a comprenderlo.

También se utilizan tecnologías que no están bien probadas,

tienen tecnologías nuevas, o peor aún las tecnologías que utilizan
están a punto de expirar. Es decir, los sistemas son
tecnológicamente complejos.

A su vez el sistema debe preservar las funciones anteriores del

sistema y por otro lado debe ser construido para modificar una
gran cantidad de futuros cambios.

En función de lo mencionado podemos decir que la arquitectura

se necesita para: comprender el sistema, organizar el desarrollo,
fomentar la reutilización, y hacer evolucionar el sistema.

4. Restricciones para la arquitectura.

Para poder construir una arquitectura de un sistema que nos

permita implementar los casos de uso de una forma clara, concisa
y económica, se debe tener en cuenta los casos de uso correctos,
es decir, de alto rendimiento, calidad, y facilidad de utilización.

122
Los casos de uso dirigen la arquitectura pero además debemos
tener en cuenta las restricciones y posibilidades que influyen en la
arquitectura.

Existen otros productos software sobre los que se desarrolla el

sistema, sistema de gestión de base de datos, sistemas
operativos, etc.

Se deben seleccionar productos de capa intermedia que sirven

para la conversión y envío de mensajes a objetos de entornos
diferentes o un sistema software prefabricado con un marco de
trabajo independiente.

El sistema puede heredar un sistema existente y los

desarrolladores deben reutilizar gran parte de su funcionalidad y
la arquitectura debe adaptarse a él.

Por supuesto que la arquitectura también debe adaptarse a los

estándares y políticas de las empresas, como por ejemplo,
lenguajes para interfaces o telecomunicaciones.

El uso de memoria, el tiempo de recuperación o requisitos de

disponibilidad son requisitos no funcionales a los cuales también
la arquitectura debe adaptarse.

La arquitectura debe tener en cuenta la forma en la cual se

distribuye el sistema, una arquitectura cliente/servidor.

También son de ayuda en el diseño de una arquitectura la

experiencia de trabajos anteriores y las estructuras que podamos
identificar como patrones de la arquitectura.

123
5. Desarrollo de la arquitectura.

La arquitectura se desarrolla en iteraciones en la fase de

elaboración. Primero se prepara una arquitectura en capas,
determinando un diseño de alto nivel para la arquitectura.
Posteriormente se forma la arquitectura en un par de
construcciones dentro de la primera iteración.

Primero se trabaja con las partes generales de la aplicación, en lo

que se refiere al dominio. No son específicas del sistema que se
van a desarrollar. Si se selecciona el software del sistema, la capa
intermedia, los sistemas heredados, los estándares y las políticas
de uso. Se especifican los nodos que el sistema contendrá y
cómo interactúan entre ellos. A su vez, se manejan los requisitos
no funcionales y las disponibilidades de los mismos.

En segundo lugar, se trabaja con los aspectos importantes de la

arquitectura en sí. Se toman los casos de uso relevantes para la
arquitectura, se capturan los requisitos, se analizan, se diseñan,
se implementan y se prueban. Como consecuencia, aparecen
nuevos subsistemas que soportan los casos de uso
seleccionados. Si surgen algunos cambios, se vuelve a hacer lo
mismo y surgen nuevas construcciones. Se sigue iterando hasta
el final de la fase de elaboración y se obtendrá una arquitectura
estable.

Finalmente cuando se tiene una arquitectura estable, se continúa

con la funcionalidad del sistema, llevando a cabo el resto de los
caso de uso durante la fase de construcción. En esta etapa se
tiene en cuenta los requisitos de los usuarios y de los clientes
pero la arquitectura elegida en la fase de elaboración influencia
totalmente.

124
 Como ya dijimos, cada iteración, se desarrolla, comenzando con
los requisitos y siguiendo con el análisis, diseño, implementación
y pruebas pero haciendo énfasis en los casos de uso que tienen
que ver con la arquitectura y en otros requisitos. El resultado al
final de la fase de elaboración es la línea base de la arquitectura.

6. Patrones de la arquitectura.

Es grandioso ver que es posible desarrollar una arquitectura

estable durante la fase de elaboración del primer ciclo de vida.
Por otro lado, la gente lleva desarrollando arquitecturas durante
muchos años; tienen muy buena experiencia y conocimiento para
desarrollar buenas arquitecturas. Existen muchas soluciones
genéricas compuestas por estructuras, colaboraciones y
arquitecturas físicas que han ido evolucionando a lo largo de
muchos años y además todos los arquitectos deberían conocerlas
o estar familiarizados con ellas. Estas soluciones se llaman
patrones.

Los arquitectos pueden contar con estos patrones. Se define

como patrón a una solución a un problema de diseño que aparece
con frecuencia.

Muchos de ellos están documentados en los libros, como

plantillas estándar. Los patrones tienen un nombre y tienen un
resumen de los problemas que resuelven, una solución en función
de colaboración de clase que participan e interactúan entre
objetos de esa clase. A su vez, estas plantillas o patrones tienen

125
dan ejemplos de cómo se utiliza el patrón, sus variantes, resumen
con variantes, consecuencias y referencias de los mismos.

Foro. La Trazabilidad.

126
ANALISIS Y DISEÑO DE SISTEMAS.

Unidad 6: Las iteraciones dirigen el Proceso.

1. Iteraciones, fases, hitos y fases del Proceso.

2. Objetivos de las Iteraciones.
3. La iteración.
4. El ciclo de vida y las iteraciones.

1. Iteraciones, fases, hitos y fases del Proceso.

Como ya hemos mencionado, el Proceso está constituido por una

serie de fases. Dentro de cada fase el Proceso pasa por una serie
de iteraciones e incrementos.

Además cada una de estas fases termina con una iteración

especial, llamada hito, que proporciona a los directivos y al
equipo de desarrollo los elementos y criterios necesarios para
autorizar el paso a la fase siguiente dentro del ciclo del producto.

El ciclo del Proceso está constituido por la fase de inicio, la fase

de elaboración, la fase de construcción, y la fase de transición.

La fase de inicio, se caracteriza por la factibilidad. Se realizan la

identificación y la reducción de los riesgos. Se crea una
arquitectura inicial a partir de de los requisitos básicos, que
surgen a partir de los casos de uso. A su vez, se estiman a

127
 grandes rasgos, los costos, los esfuerzos y el calendario. Y
también con límites amplios, se inicia el análisis del negocio.

La fase de elaboración, se caracteriza por la construcción del

sistema, a través de las siguientes tareas: la identificación y la
reducción de los riesgos que afectan a la construcción del
sistema. Se terminan de especificar todos los casos de uso que
tienen que ver con la funcionalidad del sistema. Se sigue
desarrollando la arquitectura hasta la línea base y se prepara el
plan de proyecto. Se termina el análisis del negocio.

La fase de construcción, se caracteriza por la parte operativa

alrededor del usuario. Se prepararan todos los ejecutables a lo
largo de varias iteraciones que llevan a entregas periódicas.

La fase de transición, se caracteriza por realizar que el sistema

alcance una operatividad total. Se modifican todos los elementos
del sistema para mejorar los problemas que no se detectaron en
las fases previas y a su vez se corrigen los defectos.

2. Objetivos de la Iteraciones.

Como ya dijimos anteriormente el Proceso Unificado debe estar

dirigido por los casos de uso y centrado en la arquitectura.

Cuando mencionamos que el Proceso debe estar dirigido por los

casos de uso significa que cada fase en el camino al producto
final tiene que ver con lo que hacen los usuarios y los
desarrolladores justamente garantizan sus necesidades

128
preparando un sistema que se adapte a ellas. Pensamos así en la
función del sistema.

Cuando mencionamos que el Proceso debe estar dirigido por la

arquitectura significa que los desarrolladores basarán su trabajo
en el patrón de la arquitectura elegida para construir el sistema
en las primeras fases. Pensamos así en la forma del sistema.

Al pensar el sistema con estos dos conceptos, se tiene en cuenta

la función y la forma. Los desarrolladores elaboran el sistema, así
a lo largo de varias iteraciones y entonces surge el tercer
concepto. El Proceso debe estar desarrollado en forma iterativa e
incremental.

Este tercer concepto brinda la habilidad para desarrollar el

sistema en forma manejable. Es decir, se planifica, se especifica
se diseña, se implementa, se integra, se prueba, y se ejecuta en
cada iteración. Se ajustan los objetivos para el siguiente paso.
Luego se pasa a la siguiente iteración. Luego a la otra y así
sucesivamente. Al cumplirse lo planificado, se obtiene un producto
desarrollado para entregar a los clientes.

En las primeras iteraciones, las fases cumplen con la

determinación del ámbito del proyecto, se eliminan los riesgos
críticos y se crea la línea base de la arquitectura. Luego a medida
que iteramos se avanza en el proyecto, se reducen los riesgos
restantes y se agregan el resto de los elementos o componentes.

De esta forma dividimos el proyecto en mini proyectos, los

cuales constituyen una iteración. Cada una de estas iteraciones

129
 tiene todo lo que tiene un proyecto de desarrollo de software, una
serie de flujos de trabajo, requisitos, análisis, diseño,
implementación, prueba y entregas.

Estos mini proyectos se asemejan al antiguo ciclo de vida en

cascada pues se desarrolla a través de actividades en cascada. El
nuevo ciclo de vida iterativo produce resultados que se van
entregando y que aportan un incremento al proyecto. Las
iteraciones constituyen una retroalimentación muy importante en
el proyecto.

El objetivo fundamental de preparar un desarrollo iterativo e

incremental es obtener un software mejor, que cumpla con los
hitos principales y secundarios con los que se controla el
proyecto.

Se pueden atenuar los riesgos críticos y significativos desde el

principio del proyecto, crear una arquitectura importante que guíe
el desarrollo del software, proporcionar un marco de trabajo capaz
de gestionar los requisitos cambiantes, permitir cambios tácticos.
De esta manera los desarrolladores pueden trabajar eficazmente
y se consigue una integración continua.

3. La iteración.

Antes de determinar lo que significa una iteración, veremos lo que

no es una iteración. No es un desarrollo aleatorio, no sirve sólo a
los desarrolladores, no sirve sólo para rediseñar una y otra vez lo
mismo hasta el final del proyecto hasta que funcione.

130
Una iteración es un mini proyecto, es decir, un recorrido completo
a lo largo de todos los flujos de trabajo fundamentales, que
obtiene como resultado una versión interna. Los flujos de trabajo
más importantes son requisitos, análisis, diseño, implementación
y prueba. A estos flujos se los denomina flujos de trabajo
fundamentales. Pueden existir algunas iteraciones que contengan
flujos de trabajo más concretos, los cuales se denominan flujos de
trabajo de iteración.

Cada iteración se diferencia de un modelo en cascada tradicional,

se debe a que cada uno de los flujos de trabajo fundamental es
una colaboración entre un conjunto de trabajadores y artefactos, a
pesar de que existen coincidencias entre las iteraciones. Los
trabajadores y los artefactos pueden trabajar en más de un flujo
de trabajo.

Las primeras iteraciones tienen que ver con el diagnóstico y

conocimiento del problema y de la tecnología. En la fase de inicio,
se realiza el análisis del negocio a través de las iteraciones, en la
fase de elaboración las iteraciones se dedican a la línea base de
la arquitectura, en la fase de construcción, las iteraciones se
dedican a la construcción del producto.

Cada iteración al terminar se analiza chequeando los objetivos, es

decir, verificando si han aparecido requisitos nuevos o cambiado
los existentes. Luego esto afecta a las iteraciones siguientes.

Hay que tener en cuenta lo que se llama prueba de regresión.

Antes de terminar cada iteración se debe estar seguro que todo lo
que funcionaba en el sistema en las iteraciones anteriores siga

131
funcionando correctamente. Esto es realmente muy significativo e
importante en el ciclo de vida iterativo e incremental pues cada
iteración produce una adición al incremento previo, al igual que
una cantidad de cambios.

En el ciclo de vida iterativo se requiere más planificación que en

el método en cascada. En el método iterativo no se planifica
plenamente durante la fase de inicio. Justamente la planificación
se apoya en la ventaja de las iteraciones, es decir, se planifica
con el resultado de las iteraciones precedentes. Este tipo de
planificación nos permite un desarrollo iterativo controlado.

La evolución de las iteraciones en el desarrollo de software no

sucede sin un plan que la preceda. Los casos de uso fijan una
meta y la arquitectura establece un patrón. Luego con la meta y el
patrón se planifican la secuencia de iteraciones para el desarrollo
del producto.

Durante las primeras iteraciones se conocen los requisitos, los

riesgos, y el dominio de la solución. Luego, las siguientes
iteraciones producen incrementos aditivos que conforman una
versión externa, lo que se entrega al cliente.

Con las iteraciones siempre se avanza con el desarrollo a pesar

que las iteraciones puedan solaparse en el sentido que una está
por terminar cuando otra está comenzando. Cada vez que se al
final de una iteración se analiza el software de la misma, se
integra y se crea la versión interna.

Un incremento es la diferencia entre la versión interna de una

iteración y la versión interna de la siguiente. Al final de cada

132
 iteración, el conjunto de modelos que representa el sistema
queda en un estado concreto llamado línea base.

Por lo tanto, un incremento, es la diferencia entre dos líneas base

sucesivas.

4. El ciclo de vida y las iteraciones.

Las fases reúnen iteraciones que dan como resultado los hitos
principales sobre los cuales la dirección toma decisiones de
negocios muy importantes. Dependiendo del proyecto este
número de iteraciones puede variar, no es fijo. Es decir, cada una
de las cuatro fases termina con un hito principal.

La fase de inicio culmina con el hito de los objetivos del ciclo de

vida. La fase de elaboración culmina con el hito de de la
arquitectura de del ciclo de vida. La fase de construcción culmina
con el hito de de la funcionalidad operativa inicial. Y la fase de la
transición culmina la versión del producto.

Los objetivos fundamentales de la fase de inicio son establecer el

ámbito de lo que debería hacer el producto, la reducción de los
peores riesgos, la preparación del negocio inicial.

Los objetivos fundamentales de la fase de elaboración son

obtener la línea base de la arquitectura, capturar la mayoría de los
requisitos, y reducir los siguientes peores riesgos.

133
Los objetivos fundamentales de la fase de construcción son el
desarrollo del sistema entero y que el producto pueda comenzar
su transición a los clientes.

Los objetivos fundamentales de la fase de transición son

garantizar que existe un producto preparado para la comunidad
de los usuarios.

Dentro de cada fase hay hitos menores con criterios para cada
uno. Al llegar a los hitos secundarios los directivos y los
desarrolladores deciden cómo continuar con las próximas
iteraciones. Cuando se llega a los hitos principales del final de la
fase, se toman decisiones cruciales tales como seguir o no y
determinar el calendario y el presupuesto.

Estas divisiones ayudan a la dirección y a otros usuarios a

evaluar hecho durante las fases.

Un proyecto de desarrollo de software se puede separar en dos

partes: la primera parte formada por la fase de inicio y
elaboración y la segunda formada por la fase de construcción y
transición.

En la primer parte, se construye el análisis del negocio, se

atenúan los peores riesgos, se crea la línea base de la
arquitectura y se planifica el resto del proyecto.

En la segunda parte, el objetivo es la economía de escala. Se

desarrolla la funcionalidad del sistema, construyendo sobre la
línea de base, la cual se obtuvo en la parte anterior.

134
Las iteraciones construyen los modelos resultantes incremento
por incremento. Cada iteración le aporta un poco más al proyecto,
a cada modelo, a medida que la iteración fluye por los requisitos,
análisis, diseño, implementación y prueba.

Aplicar este método tiene consecuencias muy importantes: crear

el análisis del negocio en la fase de inicio, reduciendo riesgos,
minimizar costos, defectos y tiempos de salida al mercado. La
organización puede apostar para el desarrollo en términos del
negocio pues tiene confianza en el que no existen los riesgos
ocultos, se evita el retraso de la entrega del producto en cada
etapa, etc.

135
ANALISIS Y DISEÑO DE SISTEMAS.

Unidad 7: Captura de Requisitos.

1. Objetivo del flujo de trabajo de los requisitos.

2. Pasos a seguir en el flujo de trabajo de requisitos.
3. Enumerar requisitos candidatos.
4. Comprender el contexto del sistema.
5. Capturar requisitos funcionales.
6. Capturar requisitos no funcionales.
7. Los requisitos en el Ciclo de Vida.
8. Lista de características.
9. Modelo de Dominio.
10. Modelo de Negocio.
11. Requisitos adicionales.

1. Objetivo del flujo de trabajo de los requisitos.

Los usuarios son los que deben transmitir la información a los

desarrolladores de software sobre lo que necesitan o quieren del
sistema para que el mismo los ayude en su gestión. Los
desarrolladores llevan a cabo su tarea para los usuarios y no para
ellos mismos.

En ese punto, los desarrolladores dicen que los usuarios no saben

transmitir lo que necesitan, es decir, constituyen una fuente
imperfecta de información. En una empresa hay muchos usuarios.
Cada uno sabe lo que precisa en particular, en función de lo que
hacen. Pero no tienen una visión más global de lo que tiene que
resolver un sistema.

136
Los usuarios no saben cómo puede hacerse más eficiente la
operación en forma global. Tampoco saben cómo puede
transformarse en software su parte de su trabajo.

En realidad, los usuarios no saben cuáles son los requerimientos

ni tampoco cómo expresarlos de una manera clara.

Para resolver este problema están los analistas, que juegan un

papel de intermediarios, para obtener una lista de requisitos de
cada uno de los usuarios. Esto lo hacen con el objetivo de obtener
una especificación de requisitos completa.

Con la ayuda de los analistas, los usuarios tampoco entienden

del todo lo que el futuro sistema debe hacer hasta que no esté
terminado. Hasta incluso, a medida que el proyecto avanza, los
usuarios empiezan a comprender mejor sus verdaderas
necesidades y comienzan a sugerir una gran cantidad de
cambios, los cuales afectan en los plazos de entrega y en los
costos.

Se dice que los usuarios saben lo que quieren y cuáles son sus
requisitos y los analistas deben entrevistarlos para construir el
sistema propuesto. Así los usuarios les transmiten a los analistas
su experiencia sobre las interacciones que deben tener con el
sistema.

El sistema debería proporcionar valor al negocio y a sus usuarios.

Ese valor agregado es muy difícil de comprender y menos de
averiguarlo. Muchas veces, hasta es más difícil que el sistema lo
brinde. Además esto es muy difícil de conseguir, pues el negocio
de la empresa cambia y por consiguiente dicho valor agregado

137
también se modifica. Puede modificarse la tecnología, las
herramientas, los usuarios, los recursos, etc.

El objetivo fundamental del flujo de trabajo de los requisitos es

hacer que puedan conducir el desarrollo del sistema hacia el
sistema correcto.

¿Cómo se hace esto? Debe existir un acuerdo entre los clientes,

los usuarios y los desarrolladores sobre lo que el sistema debe
hacer y lo que no debe hacer. Se debe poder armar una buena
descripción de los requisitos del sistema.

Luego del momento en que los analistas preparen esta lista de

requisitos, el cliente debe ser capaz de leer y entenderla. Es decir,
el cliente debe ser capaz de entender el resultado de la captura
de requisitos. Este es un gran objetivo a alcanzar.

Para ello, se debe usar un lenguaje que el cliente entienda, su

propio lenguaje. Se debe tener mucha precaución en la
formalidad y en la estructura cuando se arma esta solución inicial
y también cuando se especifican los detalles del funcionamiento
interno del sistema.

Esta captura de requisitos, que se puede ver como el resultado

del flujo de trabajo de los requisitos no sólo ayuda al desarrollador
sino también debe ayudar al jefe de proyecto a planificar las
iteraciones y las versiones del futuro sistema.

Dependiendo de las diferencias en el tipo de empresa, de

sistema, del cliente, del equipo de desarrollo, de la tecnología a
utilizar, también hay diferencias en el proyecto software. Por lo

138
tanto existen también varias y diferentes formas de comenzar con
la captura de requisitos.

¿Cómo son estas diferentes formas de comienzo para la toma de

requisitos? Se podría empezar armando un modelo de negocios
o con uno que ya está empezado.

Un modelo de negocios es la descripción de los procesos de

negocio y los actores que usan dichos procesos, es decir los
clientes.

También se podría comenzar con un proyecto que no tenga que

ver con el sistema de negocio, es decir que no de soporte al
negocio, y por lo tanto, podría comenzarse con un modelo de
dominio. Este modelo está basado en el contexto del sistema, es
decir, las cosas o eventos que suceden en el entorno del sistema.

En otro momento se podría tener especificada la lista de

requisitos que no tengan que ver con modelos pero que la misma
ya se encuentre armada. A partir de allí, se continúan con los
cambios.

Además, otro punto de partida, podía basarse en que los usuarios

no armaron nada y no tienen ni la menor idea de lo que debería
hacer el sistema.

Se ve que existe una gran variedad de puntos de partida para

comenzar con el desarrollo. Y por lo tanto los analistas deben
adaptar sus técnicas a la captura de de requisitos en cada uno de
estos casos.

139
2. Pasos a seguir en el flujo de trabajo de requisitos.

En función de lo mencionado, se puede decir que hay ciertos

pasos factibles para realizar la captura de los requisitos o para
realizar el flujo de trabajo de los requisitos.

Por eso, el flujo de trabajo de los requisitos, se puede llevar a

cabo siguiendo los pasos que se detallan:

 Enumerar los requisitos candidatos.

 Comprender el contexto del sistema.
 Capturar requisitos funcionales.
 Capturar requisitos no funcionales.

3. Enumerar los requisitos candidatos.

Para enumerar los requisitos candidatos se debe ir conservando

una lista de requisitos candidatos que se decidan implementar en
futuras versiones del sistema.

Esta lista se puede armar en el comienzo de vida del sistema a

desarrollar o los clientes, los usuarios, los analistas y
desarrolladores pueden ir preparándola durante la vida del
sistema que se está usando brindando sus ideas al respecto.

4. Comprender el contexto del sistema.

Se debe conocer con bastante exactitud el contexto en el que se

implementará el sistema para poder capturar los requisitos
correctos y luego poder llevar adelante el proyecto.

140
Para enunciar el contexto de un sistema de manera que los
desarrolladores luego puedan utilizarlo, se puede verlo desde dos
puntos de vista, el modelado del dominio y el modelado del
negocio.

En el modelado del dominio existen objetos que se identifican y se

les establece un nombre que sirven para armar un glosario de
términos con el objetivo que todas las personas involucradas en el
proyecto puedan establecer una comunicación significativa. Este
modelado del dominio describe los conceptos importantes del
contexto y ayuda a identificar las clases en el análisis y diseño del
sistema.

El modelado del negocio está compuesto por un conjunto aún

más amplio de los objetos del modelado de dominio. En este
modelado se describen los procesos de de negocio de la empresa
con el objetivo de comprenderlos y mejorarlos.

En modelado del negocio los analistas comprenden el contexto

del sistema y se especifican qué proceso se incluirán en el
sistema a desarrollar. Se identifican los objetos del dominio o del
negocio y además se establecen las competencias que se
necesitan para cada proceso, es decir, los trabajadores, sus
responsabilidades y las operaciones que llevan a cabo.

¿Para qué sirven estos modelos? La información de estos

modelos es totalmente concluyente para decidir cómo se
identificarán los futuros casos de uso. Posteriormente se decidirá
si se arman estos modelos o no. De esto se encargan los jefes del
proyecto.

141
5. Capturar requisitos funcionales.

Para identificar los requisitos funcionales del sistema se ven y se

prepararan los casos de uso.

Un caso de uso es un modo de utilizar el sistema. Los usuarios

necesitan que el sistema lleve a cabo una función que les
resuelva su tarea, es decir que el sistema haga algo para ellos.
Esto significa que el sistema lleve a cabo los casos de uso.

¿Qué tienen que hacer los analistas? Deben describir todos los
casos de uso con el objetivo de conocer lo que el sistema debe
hacer.

Un caso de uso da soporte o ayuda a un usuario durante su

proceso de negocio y representa su forma de usar el sistema.
Cada usuario tiene asociado tal vez varios casos de uso, pues el
usuario utiliza el sistema de varias formas.

En consecuencia para determinar los casos de uso que servirán

de apoyo a los usuarios se comprender el contexto del sistema.
Para ello se deben conocer las necesidades del usuario y del
cliente para que los mismos trabajen con el sistema en una forma
totalmente placentera y agradable.

A su vez, los analistas deben tener en cuenta la interfaz del

usuario, viendo la forma en que la información que se necesita
se mostrará o se ingresará al sistema. Se realizan esbozos a
través de los cuales los usuarios transfieren dicha información
para que ellos puedan probarlo.

142
6. Capturar requisitos no funcionales.

¿Qué es un requisito no funcional? Son restricciones del entorno

o de la implementación, rendimiento de la plataforma, facilidades
de mantenimiento, características de disponibilidad, exactitud,
tiempo medio entre fallas, condiciones sobre los requisitos
funcionales, tales como velocidad, rendimiento, tiempo de
respuesta, uso de memoria.

Como todos estos aspectos afectan a algunos casos de uso, se

pueden describir en la parte derecha o en una sección aparte de
la descripción del caso de uso.

Existen algunos requisitos no funcionales que tienen que ver con

el mundo real, por ejemplo algo relacionado con restricciones
bancarias. Se pueden especificar en el contexto del dominio o del
negocio, en el modelo de contexto del sistema.

Además también existen requisitos no funcionales que no pueden

asociarse a un caso de uso. Los mismos se deben detallar aparte
en una lista de requisitos adicionales.

Finalmente podemos decir que los analistas necesitan varias

técnicas para poder capturar los requisitos del sistema y
luego continuar con los siguientes flujos de trabajo.

Para enumerar los requisitos candidatos del sistema, los analistas

preparan la lista de características.

143
 Para comprender el contexto del sistema, los analistas preparan
el modelo del dominio y el modelo del negocio.

Para capturar los requisitos funcionales del sistema, los analistas

preparan el modelo de casos de uso.

Para capturar los requisitos no funcionales del sistema, los

analistas preparan una lista de requisitos adicionales o
especificaciones adicionales en los casos de uso que así lo
requieran.

Estas dos últimas capturas de requisitos funcionales y no

funcionales definen una especificación de requisitos tradicional.

Hay una cuestión muy importante tener en cuenta. Estos

requisitos cambian constantemente y se necesitan controlarlos.
Esto se lleva a cabo en las iteraciones. Cada una de estas
iteraciones reflejará un cambio en los requisitos.

7. Los requisitos en el Ciclo de Vida.

Durante el ciclo de vida del proyecto, el modelo de casos de uso

se desarrolla a lo largo de incrementos del desarrollo, en las
iteraciones. Estas generan nuevos casos de uso o generar detalle
a las descripciones de los casos de uso que ya existen.

En la fase de inicio, los analistas identifican la mayoría de los

casos de uso para delimitar el sistema y el alcance del sistema.
Constituyen los casos de uso más importantes pero no son todos.

144
 En la fase de elaboración, los analistas terminan de capturar la
mayoría de los casos de uso restantes. Esto sirve para que luego
los desarrolladores puedan continuar con su tarea.

En la fase de construcción, los analistas capturan los casos de

uso que quedan.

En la fase de transición, los analistas ya no capturan casos de uso

a menos que los requisitos se modifiquen.

Todo esto lo visualizamos en el siguiente gráfico.

Fases

Flujos de
Trabajo
Fundamentales Inicio o Elaboración Construcción Transición
Concepción

Requisitos

Análisis
Aquí se
Diseño observa
cómo el flujo
Implement de trabajo de
los requisitos
Prueba y todos sus
artefactos
Iteración Iteración Iteración Iteración resultantes
1 2 n-1 N adquieren
distintas
formas.
Iteraciones

145
8. Lista de características.

Como dijimos anteriormente esta lista se puede armar en el

comienzo de vida del sistema a desarrollar o los clientes, los
usuarios, los analistas y desarrolladores pueden ir preparándola
durante la vida del sistema que se está usando brindando sus
ideas al respecto.

¿Por qué se dice que esta lista de características se usa para la

planificación del nuevo trabajo? Pues esta lista crece a medida
que surgen nuevos elementos y decrece a medida que dichos
requisitos se convierten en casos de uso.

Cada requisito candidato o característica se escribe con un

nombre corto y tiene una explicación corta que juega el papel de
definición que sirve para poder tenerla en cuenta y manipularla
durante toda la planificación del sistema.

Además cada característica tiene valores agregados que sirven

para estimar el tamaño del proyecto y para ver cómo se podrá
dividir el proyecto en una secuencia de iteraciones. Estos valores
son:

 Un estado, que puede ser propuesto, aprobado, incluido,

validado, etc.
 Un costo de implementación estimado, en función de
horas por persona, tipos de recursos, etc.
 Una prioridad, que puede ser crítico, importante,
secundario, etc.
 Un nivel de riesgo asociado a la implementación de cada
característica, que puede ser crítico, significativo,
ordinario, etc.

146
 ¿Para qué sirven estos valores agregados de las características?
Por ejemplo, la prioridad y el riesgo de una característica sirve
para decidir en qué iteración se va a implementar dicha
característica.

9. Modelo de Dominio.

En el modelo de dominio se capturan los tipos más importantes de

objetos en el contexto del sistema. Estos objetos representan las
cosas que existen o los eventos que suceden en el entorno en el
que trabaja el sistema.

Estos objetos de dominio son las clases.

¿De dónde se obtienen dichas clases? Se obtienen de la

especificación de requisitos o entrevistando a especialistas del
dominio.

Estas clases pueden ser de tres tipos y representan lo siguiente:

 Objetos del negocio.

 Objetos del mundo real.
 Sucesos que influyen en el sistema.

Los objetos del negocio representan cosas que se manipulan en

el negocio como pedidos, artículos y facturas.

147
Los objetos del mundo real representan conceptos reales y
aquellos de los que el sistema debe hacer un seguimiento como
aviación enemiga, misiles y trayectorias.

Los sucesos que influyen en el sistema representan los sucesos

que van a ocurrir o que ya ocurrieron, como la llegada de un
avión, su salida y la hora en que suministran la comida.

El modelo de dominio se describe a través de diagramas de

clases. Estos diagramas capturan los conceptos más importantes
de contexto del sistema.

Los diagramas de clases muestran los dichos objetos, las clases,

y cómo se relacionan entre sí mediante asociaciones. Estos
diagramas son de gran utilidad a los clientes, los usuarios y los
desarrolladores para que se familiaricen con el contexto del
sistema.

Las clases se representan mediante rectángulos. Su nombre se

coloca en la parte superior y en la parte inferior se detallan los
atributos de las clases que las caracterizan o ayudan a
identificarlas.

Como dijimos en el diagrama de clases se observa cómo las

clases se relacionan entre sí. Luego en el diagrama aparecen las
asociaciones entre ellas, representadas por líneas entre los
rectángulos. Este concepto se denomina asociación entre clases.

Además en estas líneas aparecen números o asteriscos, que

indican cuántos objetos de una clase se pueden enlazar con un
objeto de otra clase. Este concepto se lo llama multiplicidad entre
clases.

148
También se coloca un texto al final de una línea. Este texto
representa el rol que lleva a cabo una clase con relación a la otra.
Este concepto se denomina rol de asociación.

El objetivo del modelo de dominio es comprender y describir las

clases más importantes dentro del contexto del sistema. Es decir,
contribuir a la comprensión del contexto del sistema.

Además, a veces se guarda las definiciones de algunas clases en

glosarios de términos.

Otras veces, si el dominio de negocio es demasiado pequeño, no

es necesario desarrollar un modelo de dominio con clases y sí
utilizar un glosario con definiciones de términos.

¿Para qué sirven el modelo de dominio y el glosario de términos?

Estos ayudan a los clientes, usuarios, analistas y desarrolladores
a usar un vocabulario en común. Cuando las personas usan un
vocabulario en común, ellos mismos pueden compartir sus
conocimientos en una forma más adecuada. Cuando existe
confusión al comunicarse, la tarea no tiene buenos frutos.

Como dijimos anteriormente, el objetivo del modelo de dominio es

contribuir a la comprensión del contexto del sistema. Pero
también su objetivo es contribuir a la comprensión de los
requisitos del sistema que se desprenden del contexto. Es decir,
el modelado de dominio también debería contribuir a una
comprensión del problema que el sistema resuelve en relación a
su contexto. Pero esta forma interna de resolver el problema se
lleva a cabo en los flujos de análisis, diseño e implementación.

149
 Finalmente, ¿dónde se usa el modelo de dominio? Las clases de
dominio y el glosario de términos se utilizan en el modelo de
casos de uso y de análisis. Esto es para describir los casos de
uso y para diseñar la interfaz del usuario y para sugerir las clases
internas al sistema a desarrollar durante el análisis.

10. Modelo de Negocio.

El modelo de negocios es una técnica para comprender los

procesos de negocio dentro de la empresa. El término negocio es
muy amplio, y a veces confunde un poco.

A veces este término, negocio, tiene que ver con lo que

consideramos un negocio. Y otras veces no tiene ninguna
relación. Por ejemplo, si se trata de un sistema de control de
cámaras de video para la detección de robos o siniestros varios.

En estos casos también se puede modelar el sistema que rodea al

sistema software que se va a desarrollar. Estos sistemas también
son sistemas de negocio a la hora desarrollarlos.

Siempre, el objetivo es identificar los casos de uso de software y

las entidades de negocio relevantes que el sistema usa.

En el modelo de negocio da como resultado un modelo de

dominio que se deriva de la comprensión del funcionamiento del
sistema de negocio que lo rodea.

150
¿Cómo está compuesto el modelo de negocio?

 el modelo de casos de uso.

 el modelo de objetos.

El modelo de casos de uso del negocio describe los procesos

de negocio de una empresa en función de los casos de uso del
negocio y de los actores del negocio, que tienen que ver con los
procesos del negocio y con los clientes

Este modelo presenta un sistema de negocio desde la perspectiva

de su uso y esboza cómo le brinda un valor agregado a sus
usuarios. Este modelo se describe mediante diagramas de casos
de uso, ya descriptos anteriormente.

El modelo de objetos del negocio es un modelo interno a un

negocio. En él se observa cómo cada caso de uso se lleva a cabo
por parte de los trabajadores que utilizan un conjunto de
entidades del negocio y de unidades de trabajo. Cada realización
de un caso de uso del negocio puede verse en un diagrama de
interacción y diagramas de actividad.

Una entidad de negocio representa algo que los trabajadores

utilizan, manipulan, producen o inspeccionan en el caso de uso
del negocio.

Una unidad de trabajo es un conjunto de dichas entidades que

conforman algo reconocible para un usuario final.

151
Las entidades de negocio y las unidades de trabajo se utilizan
para representar los mismos tipos de conceptos que las clases de
dominio. Se confecciona un diagrama de entidades parecida al
diagrama de clases del modelo de dominio. Además se pueden
confeccionar otros diagramas que muestran cómo se utilizan las
entidades de negocio y las unidades de trabajo.

¿Cómo se desarrolla el modelo de negocio?

Un modelo de negocio se desarrolla en dos pasos.

Primero, se confecciona un modelo de casos de uso del negocio

que identifique los actores del negocio y los casos de usos que
utilicen los actores. Este modelo permite comprender mejor qué
valor les proporciona el negocio a sus actores.

Segundo, se desarrolla un modelo de objetos del negocio que se

compone de trabajadores, entidades de negocio y unidades de
trabajo que juntos realizan los casos de uso del negocio. Se
incorporan a los objetos las reglas y normas de negocio.

El modelo de negocio es muy parecido al modelo de dominio. El

de dominio es una versión simplificada del de negocio. Esto es
porque en el modelo de dominio sólo se observan las cosas o
clase de dominio o entidades de negocio que los trabajadores
necesitan usar.

Pero existen diferencias entre el modelo de dominio y el modelo

de negocio.

152
 Las clases de dominio se obtienen del conocimiento de expertos
del dominio o del conocimiento asociado a sistemas similares que
se está desarrollando. Las entidades del negocio se derivan de
los clientes del negocio, identificando los casos de uso y luego las
entidades. A su vez, la asociaciones entre las clase en función de
la experiencia de los expertos de dominio.

En el modelo de negocio, cada entidad debe venir motivada por

su utilización del caso de uso del negocio. En este caso, las
asociaciones se obtienen de la necesidad de cada elemento del
modelo hasta los clientes.

Otra diferencia fundamental es que las clases del dominio tienen

atributos pero muy pocas operaciones asociadas. En el modelo de
negocio, por otro lado, no sólo identifica las entidades, sino
también todos los trabajadores que participan en la realización
del caso de uso del negocio que utilizan a las entidades. Así, en
cada entidad se especifican operaciones que los trabajadores
usan y que dichas entidades ofrecen.

11. Requisitos adicionales.

Los requisitos adicionales son requisitos que no pueden asociarse

a ningún caso de uso en particular. Pero sí, podemos decir, que
estos requisitos afectan a varios casos de uso o a ninguno.

Estos requisitos adicionales pueden ser: el rendimiento, las

interfaces, los requisitos de diseño físico, los requisitos
arquitectónicos de diseño e implementación.

153
Los requisitos adicionales se pueden clasificar de la siguiente
manera:

 Requisitos de interfaz.
 Requisitos físicos.
 Requisitos de diseño.
 Requisitos de implementación.

Un requisito de interfaz especifica la interfaz con un elemento

externo con el que deber interactuar el sistema. También puede
establecer restricciones que condicionan formatos, tiempos u
otros factores de importancia para esa interacción.

Un requisito físico especifica una característica física que debe

poseer un sistema, como su material, forma, tamaño o peso.
Pueden ser requisitos de hardware como configuraciones físicas
de red que se requieren.

Un requisito de diseño son aquellas que tienen que ver con

restricciones de extensibilidad, mantenibilidad o aquellas relativas
a la reutilización de los sistemas heredados o partes esenciales
de los mismos.

Un requisito de implementación limita la codificación de un

sistema. Por ejemplo, estándares requeridos, normas de
codificación, lenguajes de programación, políticas para la
integridad y utilización de las bases de datos, limitaciones de
recurso y entornos operativos.

Foro. Dominio o Negocio.

154
ANALISIS Y DISEÑO DE SISTEMAS.

Unidad 8: Casos de Uso.

1. Modelo de casos de uso.

2. Actor en los casos de uso.
3. Casos de uso.
4. Descripción de la arquitectura, Glosario y Prototipo de Interfaz
de usuario.
5. Trabajadores en los casos de uso.
6. El flujo de trabajo de la captura de requisitos.
7. Encontrar actores y casos de uso.
8. Descripción de cada caso de uso.
9. Descripción del modelo de casos de uso.
10. Priorizar casos de uso.
11. Detallar casos de uso.
12. Interfaces de usuario.
13. Estructuración del Modelo de Casos de Uso.

1. Modelo de caso de uso.

Cuando se quiere construir un sistema, durante la fase de

requisitos, se utilizan los casos de uso para crear ese modelo.

Los casos de uso constituyen una técnica primordial para

estructurar los requisitos funcionales en forma natural. Los casos
de uso son intuitivos para capturar los requisitos funcionales pata
dar un valor agregado a los usuarios. Al crear los casos de uso,
los analistas tienen en cuenta a los usuarios y las necesidades
que los mismos requieren del sistema, como así también los
objetivos del sistema.

155
Los requisitos no funcionales restantes se mantienen en un
documento aparte y constituyen los requisitos adicionales.

La captura de los requisitos se lleva a cabo en el flujo de trabajo

de los requisitos. Este flujo de trabajo de requisitos se describe
teniendo en cuenta los artefactos que se crean, los trabajadores
que participan y además las actividades que realizan los
trabajadores.

Es decir, se deben identificar los trabajadores y los artefactos que

participan en el flujo de trabajo de los requisitos.

Como ya mencionamos, un trabajador representa un puesto que

se le puede asignar a una persona o grupo de personas y
especifica las responsabilidades y habilidades que los mismos
requieren.

Un artefacto constituye un término general para describir

cualquier tipo de información que se crea, que se produce, que se
modifica o que se utiliza por los trabajadores durante su trabajo en
el sistema. Pude ser un modelo, un elemento del modelo o un
documento.

Luego un trabajador es responsable de un grupo de artefactos.

Esto se muestra en un diagrama mostrando los trabajadores y los
artefactos con una asociación que sirve para observar la
responsabilidad de cada trabajador con los artefactos. Así se ve
como los diferentes trabajadores trabajan con los artefactos a
medida que llevan a cabo sus actividades.

156
Una actividad es un fragmento realizado por un trabajador en el
flujo de trabajo, es decir, la ejecución de una de las operaciones
de los trabajadores.

Trabajador

La flecha indica la es responsable de

asociación
Diagrama

Artefacto

Los artefactos más importantes que se utilizan en el flujo de

captura de requisitos son los modelos de caso de uso, los casos
de uso y los actores.

El Modelo de caso de uso es un artefacto. Este modelo permite

que los desarrolladores de software y los clientes se pongan de
acuerdo sobre los requisitos, las condiciones y posibilidades que
debe cumplir el sistema. Además el modelo sirve de base para el
análisis, diseño y las pruebas.

El modelo de caso de uso está compuesto por los actores, los

casos de uso y las relaciones.

157
2. Actor en el caso de uso.

El modelo de caso de uso describe lo que hace el sistema para

cada tipo de usuario. Pasa lo mismo para los sistemas externos
que interactúan con el sistema. Es decir, que uno o más actores
existen y representan un elemento externo que interactúa o
colaboran con el sistema. Cuando se identifican todos los actores,
se tiene identificado el entorno externo del sistema.

Los actores del negocio se corresponden con trabajadores. Un

trabajador tiene un rol. El rol define lo que hace el trabajador en
un proceso de negocio. Los roles que desempeña un trabajador
puede usarse para generar los roles que desempeña el actor del
sistema correspondiente.

Finalmente, se le asigna a cada trabajador un caso de uso del

sistema para que desempeñe sus roles. Esto significa que el caso
de uso le brinda valor al actor cuando representa el papel del
trabajador.

Un actor juega un papel para cada uno de los casos de uso con
los que colabora. Luego, cada vez que un usuario real interactúa
con el sistema, se dice que hay una instancia de un actor. Por lo
tanto cualquier entidad que se ajuste a un actor, puede actuar
también como instancia de ese actor.

3. Caso de uso.

Un caso de uso sirve para representar la forma en que los

actores utilizan el sistema. Por eso, se dice que los casos de uso

158
son fragmentos de funcionalidad que el sistema brinda para darles
un valor a sus actores.

Un caso de uso sirve para especificar una secuencia de acciones

que el sistema puede llevar a cabo interactuando con sus
actores, brindando, si se da alternativas de la secuencia.

Este concepto es muy importante, pues se dice que el caso de

uso es una especificación.

Un caso de uso es un clasificador, pues tiene asociado atributos y

operaciones.

Al describir un caso de uso, se puede incluir diagramas de estado,

diagramas de actividad, colaboraciones y diagramas de
secuencia.

Los diagramas de estados especifican el ciclo de vida de las

instancias de los casos de uso en términos de estados y
transiciones entre los estados. Cada transición es una secuencia
de acciones.

Los diagramas de actividad describen el ciclo de vida con más

detalle y se describe la secuencia temporal de acciones dentro de
cada transición.

Los diagramas de colaboración y los de secuencia se usan para

describir la interacción entre una instancia de un actor y una
instancia de un caso de uso.

Una instancia de un caso de uso es la realización o ejecución de

un caso de uso. Esto significa que una instancia de un caso de

159
uso es lo que el sistema hace cuando obedece a un caso de uso.
Desde otro lugar, esto quiere decir que cuando se lleva a cabo
una instancia de un caso de uso, la misma interactúa con
instancias de actores y ejecuta una secuencia de actores de
acuerdo cómo se especifica el caso de uso.

El caso de uso puede hacer algo similar:

 La instancia del caso de uso se inicia y pasa a estado de
comienzo.
 El caso de uso es invocado por un mensaje externo a un
actor.
 Pasa a otro estado realizando una secuencia de acciones
(puede ser cálculos, selecciones, y mensajes de salida).
 Queda en espera de otro mensaje externo de un actor (en
un nuevo estado).
 Se invoca por un nuevo mensaje. Esto puede pasar sobre
varios estados hasta que se termina una instancia del caso
de uso.

En general, la instancia del caso de uso es invocado por una

instancia de un actor. A veces, también puede ser invocado por
un evento interno al sistema.

Los casos de uso tienen atributos, que representan los valores

que una instancia de un caso de uso usa y manipula durante la
ejecución de un caso de uso. Los valores que representan estos
atributos son locales a la instancia del caso de uso, no las puede
usar otros casos de uso.

160
Las instancias de los casos de uso no interactúan con otras
instancias de casos de uso. En el modelo de casos de uso, las
únicas interacciones que existen se dan entre instancias de los
casos de uso e instancias de los actores. Esto se da para que
permitir que los usuarios finales y otros interesados puedan
comunicarse en forma relevante.

Las instancias de los casos de uso se consideran atómicas, cada

una de ellas se ejecuta en forma completa o no se ejecuta nada,
si que otras instancias de casos de uso interfieran. Esto quiere
decir que cada caso de uso es independiente de otro caso de uso.

Se considera a los casos de uso como atómicos e independencia

con el objetivo que el modelo de casos de uso pueda ser
entendido por todos.

A pesar de esto, no se dejan de lado las interferencias que existen

entre los diferentes usos al sistema. Es por eso, que en este
modelo no se tienen en cuenta dichas interferencia, sino que a
partir de los modelos de análisis y diseño. Allí se resuelven estas
interferencias, al ver que una clase puede participar en varias
realizaciones de los casos de uso

¿Cómo se puede ver el flujo de sucesos de cada caso de uso? Se

puede ver a través de una descripción textual de la secuencia de
casos de uso. En este flujo se ve la forma de interactuar de los
actores con el sistema cuando se lleva a cabo el caso de uso.

Esta descripción de un flujo de suceso tiene un conjunto de

secuencia de acciones que se pueden modificar, revisar, diseñar,
implementar y probar todas juntas. Pueden ser descriptas en una
sección del manual de usuario.

161
 ¿Qué son los requisitos especiales? Constituyen una descripción
textual que agrupa a todos los requisitos no funcionales sobre el
caso de uso y se tratan posteriormente en el flujo de trabajo de
análisis, diseño o implementación.

4. Descripción de la arquitectura, Glosario y Prototipo de

Interfaz de usuario.

La descripción de la arquitectura contiene una vista de la

arquitectura del modelo de casos de uso, que constituye los casos
de uso que tienen importancia para la arquitectura.

La vista de la arquitectura del modelo de casos de uso tiene que

incluir a los casos de uso que describan alguna funcionalidad
importante y crítica o que tengan un requisito importante que se
debe desarrollar en el ciclo de vida del software.

Se usa el glosario para definir términos importantes y comunes

que los analistas de sistemas utilizan al describir el sistema. Esto
es muy útil para que los desarrolladores puedan definir los
distintos conceptos y que disminuyan las confusiones. El glosario
se puede obtener del modelo de negocios o dominio. Aunque
también podría estar basado en el sistema que se construye y no
en su contexto.

Los prototipos de interfaz de usuario nos ayudan a comprender la

interacción entre los actores humanos y el sistema durante la
captura de requisitos. Además ayuda a comprender mejor los
casos de uso, como así también diseñar una interfaz gráfica.

162
5. Trabajadores en los casos de uso.

Luego de comprender los artefactos que se utilizan durante el

modelo de casos de uso, es decir, actor, casos de uso,
descripción de la arquitectura y glosario, lo que hay que hacer es
los trabajadores que son responsables de esos artefactos.

Un trabajador es un puesto al que se le puede asignar una

persona real. Cada uno requiere de una descripción de
responsabilidades y el comportamiento real del mismo.

Una persona puede estar asignada a diferentes trabajadores

durante el proyecto. Un trabajador no se corresponde con un
cargo o puesto de una empresa, sino que el trabajador representa
una abstracción de un ser humano con ciertas capacidades que
se necesitan para un caso de uso del negocio.

Se dice que un trabajador representa el conocimiento y las

habilidades que alguien necesita para hacerse cargo del trabajo
como trabajador del proyecto.

En modelo de casos de uso se pueden encontrar tres

trabajadores, cada uno con sus responsabilidades y operaciones
a desarrollar, el analista de sistemas, el especificador de casos de
uso, el diseñador de interfaz de usuario y el arquitecto.

El trabajador analista de sistemas es el responsable de los

requisitos que se modelan en los casos de uso, relacionados a los
requisitos funcionales y no funcionales. El analista de sistemas es
responsable de delimitar el sistema, encontrando los actores y los

163
casos de uso, haciendo que el modelo de casos de uso sea
consistente y bien completo.
Para que el modelo sea consistente se puede usar el glosario y
hacer que existan acuerdos a la hora de utilizar términos y poder
comunicarse, durante la captura de requisitos.

El analista de sistemas se encarga de dirigir el modelado de

casos de uso y de capturar los requisitos.

El analista de sistemas es responsable del modelo de casos de

uso y de los actores. Pero no lo es de cada caso de uso en
particular. De ello se hace responsable al trabajador especificador
de casos de uso.

El trabajador especificador de casos de uso es aquel que asiste

al analista de sistema y asumen la responsabilidad de describir
detalladamente algunos de los casos de uso. Los especificadores
trabajan estrechamente con los usuarios reales de aquellos casos
de uso que describen.

El trabajador diseñador de interfaz de usuario es aquel que le da

forma visual a la interfaz de los usuarios. Se encarga del
desarrollo de prototipo de interfaces de usuario para algunos
casos de uso. En general, existe un prototipo por cada actor.

El trabajador arquitecto es aquel que le participa en el flujo de

trabajo de captura de requisitos y se encarga de describir la vista
de la arquitectura del modelo de casos de uso.

Al definir todos estos trabajadores, se describe la captura de

requisitos en forma estática.

164
6. El flujo de trabajo de la captura de requisitos.

Utilizaremos el diagrama de actividad para describir la captura de

requisitos desde un punto de vista dinámico, observando su
comportamiento. En la misma se ven calles para mostrar qué
trabajadores llevan a cabo qué actividades. Los trabajadores
ejecutan las actividades y manipulan artefactos.

Los flujos de trabajo se definen como secuencia de actividades

ordenadas, donde la salida de una actividad sirve de entrada a la
siguiente actividad.

A pesar que el diagrama de actividades presenta una secuencia

lógica o flujo lógico de actividades, en la realidad se puede
trabajar por varias vías que producen un resultado final
equivalente.

Una actividad puede ser retomada varias veces y cada una de

éstas puede acarrear la ejecución de una sola parte de la
actividad.

Pasos a seguir en este flujo de trabajo.

 En nuestro caso, el analista de sistemas realiza la actividad

de encontrar actores y casos de uso para preparar la
primera versión del modelo con actores y casos de uso que
se identifican. Hay que asegurarse que el desarrolle el
modelo de casos de uso capture los requisitos que sirven
de entrada al flujo de trabajo. En este caso, se
corresponden con la lista de características y el modelo de
dominio y el modelo de negocio.

165
  Luego, el arquitecto identifica los casos de uso relevantes
para la arquitectura, con el objetivo de brindarle las
entradas a la priorización de los casos de uso que se van a
desarrollar en la iteración actual.

 Posteriormente los especificadores de casos de uso

describen los casos de uso que se priorizaron.

 Luego en forma paralela, los diseñadores de interfaz de

usuario sugieren la interfaz para cada actor basándose en
los casos de uso.

 Finalmente, el analista de sistema reestructura el modelo

de casos de uso y define las generalizaciones entre los
casos de uso con el objetivo de una buena comprensión.

El resultado de todos estos pasos en la primera iteración del flujo

de trabajo de la captura de requisitos lo constituyen la primera
versión del modelo de casos de uso, los casos de uso y cualquier
prototipo de interfaz de usuario.

A lo largo de las diferentes fases del proyecto, las actividades

que intervienen van tomando distintas formas.

7. Encontrar actores y casos de uso.

En la fase de elaboración el encontrar los actores y los casos de

uso tiene el siguiente objetivo:

 Delimitar el sistema de su entorno.

166
  Esbozar los actores que interactúan con el sistema y su
funcionalidad que se espera del mismo a través de los
casos de uso.

 Definir un glosario de términos básicos y comunes para

crear las descripciones detalladas de las funcionalidades
del sistema, es decir, los casos de uso.

El analista de sistemas tiene la responsabilidad de identificar los

actores y los casos de uso y sabe positivamente que es la
actividad más decisiva para obtener en forma adecuada los
requisitos. Para esto, el analista trabaja en conjunto con el cliente,
los usuarios y otros analistas que trabajan con él.

Para llevar a cabo esta tarea, puede pasar que el modelo de

negocio esté preparado y entonces se prepara un borrador del
modelo de casos de uso en forma automática.

También puede pasar que se basen en el modelo de dominio, o

que se tenga una simple descripción general, o una
especificación detallada de los requisitos con las características
que se necesitan.

Además de estas posibilidades, puede pasar que se tenga una

lista con los requisitos adicionales que no pueden ubicarse en los
casos de uso individuales.

Para encontrar los actores y los casos de uso se llevan a cabo

cuatro pasos:

 Encontrar los actores.

167
  Encontrar los casos de uso.
 Describir cada caso de uso en forma breve.
 Describir el modelo de casos de uso completo, con una
preparación de un glosario de términos.

Estos pasos no tienen que llevarse a cabo en forma ordenada,

sino que a veces pueden hacerse en forma simultánea.

Al terminar esta tarea, su resultado es una nueva versión del

modelos de casos de uso con actores y casos de uso nuevos o
modificados. Se puede describir y dibujar el artefacto resultante
modelo de casos de uso. La descripción detallada de los casos de
uso se hace en la actividad siguiente.

Encontrar actores.

Esto va a depender de los artefactos con los que constamos.

Si se tiene un modelo de negocios encontrar los actores es muy

sencillo. Se debe asignar un actor por cada trabajador del
negocio y un actor por cada cliente o actor del negocio que
utilizará la información del sistema.

Si se tiene un modelo de dominio, el analista con el cliente

identifica a los usuarios y los organiza en categorías separadas
por actores.

Tanto para un caso o para el otro, de identifican loas actores que

representan sistemas externos y otros actores para el
mantenimiento y la operación del sistema.

168
Para seleccionar estos actores se pueden seguir dos
razonamientos. Con el primero, se deben identificar por lo menos
un usuario que representa al actor candidato. De esta forma se
encuentran los candidatos los candidatos más relevantes. Con el
segundo, se debe encontrar una coincidencia mínima entre los
roles que desempeñan las instancias de los diferentes actores en
relación con el sistema. No puede haber dos o más actores que
tengan los mismos roles. Si es así, se combinan los papeles en un
conjunto de roles que se asignan a un actor. O se encuentra un
actor generalizado que se le asigne los roles comunes a los
actores que se solapan.

Finalmente el analista de sistemas les da un nombre a los actores

y se hace una descripción breve de los papeles de cada actor. El
nombre que se le asigna a cada actor es importante para
establecer una buena comunicación. Esta descripción de cada
actor debe contener sus responsabilidades y necesidades.

Una vez que se encuentran estos actores, sirve como punto de

partida para encontrar los casos de uso.

Encontrar casos de uso.

Esta tarea se puede comenzar teniendo como base el modelo de

negocio. En este caso, se propone un caso de uso para cada rol
de cada trabajador que participa en la realización del caso de uso
del negocio y que utilizará información del sistema.

Si para encontrar casos de uso, no se tiene como base al modelo

de negocio, el analista lo debe hacer reuniéndose con los
usuarios y los clientes.

169
Luego, debe rectificar cada uno de los actores y luego proponer
los casos de uso para ellos. Puede usar la técnica de entrevista y
gráficos con descripciones para comprender qué casos de uso
son necesarios.

El actor debe llevar a cabo sus tareas para crear, modificar,

buscar, eliminar o estudiar los objetos del negocio y para ello él
necesita caos de uso. A su vez, el actor puede tener que
informarle al sistema lo que pasa con algunos sucesos externos,
como así también puede haber actores que se encarguen de las
tareas de ejecución de inicio, mantenimiento y finalización del
sistema.

Al hacer esto, puede pasar que haya algunos candidatos que no

lleguen a constituir casos de uso, pero pueden llegar a formar
parte de otros casos de uso. El objetivo de esto es crear casos de
uso que sean fáciles de modificar, probar, revisar y modificar,
cada uno en forma separada.

Luego, se debe elegir un nombre para cada caso de uso de forma

que se pueda pensar en la secuencia de acciones que añade
valor agregado al actor. En general, el nombre de los casos de
uso es un verbo que refleje la interacción entre el actor y el
sistema.

Es difícil decidir el ámbito de cada caso de uso, se debe tener

encuentra si el caso de uso es completo por sí mismo o si
continúa de otro casos de uso. Un caso de uso entrega un
resultado que se puede observar y que le añade valor al actor, Es
la mejor manera para buscar un caso de uso e identificar un
ámbito apropiado para el mismo.

170
Para identificar los casos de uso, se tiene en cuenta dos
conceptos importantes: resultado de valor y actor en concreto.

Al hablar de resultado de valor, pensamos en que al ejecutarse un

caso de uso, éste debe proporcionar satisfactoriamente valor al
actor que debe cumplir su objetivo. El que debe recibir un
resultado de valor es el actor que inicia el caso de uso que se está
tratando y hasta a veces el mismo actor quiere pagar por el valor
que le devuelve el caso de uso. Este concepto sirve para evitar
encontrara casos de uso muy pequeños.

Al hablar de un actor en concreto, pensamos al encontrar los

casos de uso, que los mismos le brinden valores a usuarios
individuales reales. Este concepto sirve para encontrar casos de
uso que no sean muy grandes.

Finalmente, como pasa con la identificación de los actores

mismos, los casos de uso deben ser reevaluados varias veces
para que el modelo de casos de uso sea estable.

Hay que tener en cuenta, que los casos de uso y la arquitectura

se desarrollan por iteraciones. Por lo tanto, los casos de uso que
se identifican deben se adaptados a la arquitectura existente. Si
no es así, los casos de uso deben ser modificados para que ello
ocurra.

Para ello, pude pasar que el analista supervise la carga del

sistema, simulando la actuación de un actor que necesita del caso
de uso. Se pueden medir los tiempos de respuestas y otros
requisitos de ejecución, como así también los tiempos en que un
caso de uso permanece en colas internas del sistema. Esto puede
variar dependiendo de la arquitectura del sistema.

171
 Los analistas renegocian los requisitos con el cliente para obtener
un sistema mejor y más fácil de implementar y mantener para los
mismos desarrolladores. A su vez, los clientes ganan con un
sistema que tiene mejor funcionalidad.

8. Descripción de cada caso de uso.

Cuando los analistas llevan a cabo la tarea de identificar los casos

de uso, van armando un borrador con algunas palabras
explicando cada caso de uso o a veces sólo los nombran.

Después se debe armar una breve descripción en forma

resumida que contiene la secuencia de acciones que llevan a
cabo los casos de uso, es decir, lo que el sistema necesita hacer
al interactuar con los actores.

9. Descripción del modelo de casos de uso.

Esta descripción de cada caso por separada no es suficiente para

comprender el cuadro completo. Hay que describirlos en forma
relacionada a todos los casos de uso, constituidos en el modelo
de casos de uso.

Es en este momento, cuando se preparan diagramas y

descripciones para explicar el modelo de casos de uso en forma
completa, con el objetivo de ver cómo los casos de uso se
relacionan entre sí con los actores.

172
 Se puede elegir diagramas de casos de uso que describan el
sistema en forma clara. Se muestran los casos de uso que
participan en el negocio y que ejecuta un actor.

Por otro lado, cuando se describen varios casos de uso en forma

concurrente para asegurar la consistencia, se puede utilizar un
glosario de términos. Estos términos pueden derivar en clases en
un modelo de dominio o un modelo de negocios.

Como resultado de esta tarea se obtiene una descripción general

del modelo de casos de uso, la cual explica el modelo en forma
completa, viendo cómo interactúan los actores y los casos de uso
y la manera de relacionarse los casos de uso.

Cuando se termina la descripción del modelo de casos de uso, se

debe llevar a cabo una revisión dónde la gente que participa en el
equipo de desarrollo, es decir, los usuarios y los clientes den su
visto bueno.

El objetivo de esta revisión es determinar si se han capturado los

requisitos funcionales del sistema en forma de casos de uso y si
la secuencia de acciones es correcta y completa y si es
comprensible parta cada caso de uso. Además, si existe algún
caso de uso que no proporcione ningún valor, en cuyo caso
debería reconsiderarse.

10. Priorizar casos de uso.

El objetivo de esta actividad es brindar entradas a la priorización

de los casos de uso para determinar cuáles de ellos son

173
 necesarios para desarrollar en las primeras iteraciones y cuáles
se dejan para más adelante.

Los resultados se ven en la vista de la arquitectura del modelo de

casos de uso. Luego se revisa con el jefe de proyecto y luego se
toma como entrada para comenzar con la planificación de la
iteración. También hay que tener en cuenta aspectos como los
económicos o los del negocio del sistema que se va a desarrollar.

11. Detallar casos de uso.

Cuando se detalla un caso de uso, el objetivo que hay que tener

en cuenta es describir el flujo de los sucesos en detalle, es decir,
cómo empieza, cómo termina y cómo interactúan los casos de
uso con los actores.

Hay que basarse en el modelo de casos de uso y los diagramas

de casos de uso. Se utiliza esto como punto de partida para que
los especificadores de casos de uso detallen paso a paso la
descripción de cada caso de uso especificando la secuencia de
acciones.

Para ello, se debe estructurar la descripción de unos casos de

uso con todas las alternativas, se debe ver qué se incluye en
dicha descripción y cómo se formaliza dicha descripción en el
caso de ser necesario.

El especificador de los casos de uso debe trabajar con los

usuarios reales de los casos de uso. Tiene que entrevistarse con
ellos, ver cómo los usuarios comprenden los casos de uso,

174
discutir con ellos las propuestas y solicitarles que hagan una
revisión.

Esta descripción detallada se lleva a cabo en forma de texto y con

diagramas.

¿Cómo se estructura la descripción de los casos de uso?

Un caso de uso define los estados que las instancias de los

casos de uso pueden tener y la posible transición entre dichos
estados. Cada transición es una secuencia de acciones que se
ejecutan en una instancia del caso de uso cuando esta instancia
se dispara por efecto de un suceso.

Para poder observar esto se puede utilizar un gráfico de

transición de estados, donde se debe tratar de describir la
transición de estados de manera fácil, simple y concisa. Para ello,
se puede elegir un camino básico y completo desde el estado
inicial hasta el estado final, y describir ese camino en una sección
de descripción. Luego, se describen en secciones separadas de
descripción el resto de los caminos alternativos que se desvían
del camino básico. En general el camino básico se ve en forma
recta y las desviaciones en forma curva.

El objetivo de lo mencionado es poder describir del camino de

casos de uso en forma clara y concisa pero que a su vez sea fácil
de leer. Se puede usar cualquier técnica pero lo que hay que
lograr es describir todas las alternativas.

El camino básico que se elige se considera el camino normal, que

es aquel que el usuario considera como el más habitual de seguir
y el que proporciona el valor más obvio al actor. Cada camino

175
básico debe tener pocas excepciones que el sistema puede
manejar.

Las alternativas, las excepciones o las desviaciones del camino

básico pueden ocurrir por muchas razones:

 El actor puede tener varios caminos para seguir en el caso

de uso.
 Si en el caso de uso hay varios actores, las acciones de
alguno de ellos puede influenciar a las acciones del resto
de los actores.
 El sistema podría detectar varios errores con las entradas
de los actores.
 Pueden funcionar mal algunos recursos del sistema, de tal
manera que el sistema funciona de manera inadecuada.

¿Qué se incluye en una descripción de los casos de uso?

Debe incluir lo siguiente:

 El estado inicial como precondición.

 La primera acción a ejecutar, describiendo cómo y cuándo
empieza el casos de uso.
 El orden en que las acciones se deben ejecutar y se realiza
con una numeración correlativa.
 La última acción a ejecutar, describiendo cómo y dónde se
termina el caso de uso final.
 El estado final como postcondición.
 Los caminos de ejecución que no están permitidos.
 Las descripciones de caminos alternativos que se incluyen
en la descripción del camino básico.

176
  Las descripciones de caminos alternativos que se no
incluyen en la descripción del camino básico.
 La interacción de los actores con el sistema y qué cambios
se ingresan. Describimos la secuencia de acciones del
caso de uso, cómo se invocan los estas acciones por los
actores.
 Se utilizan objetos, valores y recursos del sistema, es decir,
se describen las secuencias de acciones en la utilización
del caso de uso y se le asigna valores a los atributos del
caso de uso.
 Se deben mostrar al describir los casos de uso las
responsabilidades del sistema y la de los actores. Si no la
misma no se podrá utilizar como caso de uso.

Los atributos de los casos de uso se deben utilizar como

inspiración para encontrar las clases y los atributos del análisis y
diseño.

Además de mencionar los requisitos funcionales a través de

casos de uso, los requisitos no funcionales también deben ser
tenidos en cuenta.

También se debe especificar los casos de uso dónde el sistema

interactúa con otros sistemas.

Las descripciones de los casos de uso no se dan por terminadas

hasta que no sean comprensibles y correctas, es decir que
capturan todos los requisitos y si no describen todos los caminos
posibles. Las descripciones son evaluadas por los analistas, los
usuarios y los clientes. Esto se lleva a cabo en reuniones de
revisiones al final de la captura de requisitos. En este caso, los
usuarios son los que deben llevar a cabo esta verificación.

177
¿Cómo se formaliza una descripción de los casos de uso?

Los diagramas muestran como las transiciones hacen pasar las

instancias de un caso de uso de un estado a otro. Cuando un
caso de uso tiene pocos estados, no hace falta describir cada
estado con todo detalle. Pero, de todas maneras, es mejor tener
en mente una máquina de estados para cubrir todas las
situaciones. De todas maneras, si el caso de uso es muy
complejo, es mejor una descripción más estructurada.

Otras veces, los actores al interactuar con los casos de uso,

generan tantos estados y tantas alternativas posibles que son
muy difíciles mantener una descripción textual de los casos de
uso.

Para todo esto, conviene utilizarse los diagramas de estado para

describir los estados y las transiciones entre dichos estados.

También se puede utilizar los diagramas de actividad para

describir las transiciones entre los estados como secuencia de
acciones.

A su vez, se pueden utilizar diagramas de interacción para

describir cómo interactúan las instancias de los actores con las
instancias de un caso de uso, donde se observan el caso de uso y
la participación del o los actores.

Finalmente, podemos decir, que hay que utilizar estos diagramas

con sumo cuidado pues pueden ser complicados de leer y
comprender.

178
 En su lugar, a veces es más conveniente describir con detalle los
flujos de los sucesos de los casos de uso. Incluso, las dos
técnicas se pueden complementar.

12. Interfaces de usuario.

El objetivo de esta actividad es construir un prototipo de interfaz

de usuario.

El modelo de los casos de uso especifican los usuarios que

existen y qué y para qué interactúan con el sistema, con el apoyo
de los modelos de casos de uso, sus descripciones y las
descripciones detalladas de cada caso de uso.

Luego, se debe diseñar una interfaz de usuario que permita que el

usuario realice los casos de uso de manera exitosa.

Lo que primero se lleva a cabo es un diseño lógico de la interfaz

de usuario. Lo que se precisa hacer es empezar con los casos de
uso y ver qué se necesita de la interfaz de usuario para habilitar
los casos de uso para cada actor.

Después, se lleva a cabo un diseño físico de la interfaz de

usuario, desarrollando prototipos que muestren cómo los usuarios
pueden ejecutar el sistema para realizar los casos de uso.

179
El objetivo de esto es especificar qué se necesita antes de decidir
cómo realizar la interfaz de usuario, es decir, se entiende las
necesidades antes de llevarlas a cabo.

Como resultado de esta actividad se obtiene un conjunto de

diagramas o esquemas o prototipos de interfaces de usuario que
muestren la apariencia de las interfaces de los actores más
importantes.

¿Cómo se crea el diseño lógico de la interfaz de usuario?

Los actores interactúan con el sistema utilizando y manipulando

elementos de interface de usuario, que constituyen atributos de
los casos de uso. En general, estos atributos de las interfaces son
términos del glosario y los usuarios utilizan estos atributos como
íconos, listas de elementos, objetos que los mismos los manipulan
por selección, por arrastre o hablando con ellos.

Los diseñadores de las interfaces de usuario deben identificar

estos elementos actor por actor, viendo los casos de uso a los
que el actor puede acceder y luego identificando los elementos de
interfaz de usuario para cada caso de uso.

Puede pasar que exista un elemento de interfaz de usuario que

intervenga en varios casos de uso y desempeñe diferentes roles
en cada uno.

El diseñador de interfaz de usuario debe tener en cuenta las

siguientes preguntas, para cada actor:

 ¿Qué elementos de interfaz de usuario se necesitan para

llevar a cabo los casos de uso?

180
  ¿Cómo se relacionan estos elementos entre ellos?
 ¿Cómo se utilizan los elementos?
 ¿Cómo debería ser la apariencia de cada uno de estos
elementos?
 ¿Cómo se manipulan estos elementos?

Y luego para determinar los elementos de interfaz de usuario que

deben estar a mano de cada actor, el diseñador debe también
responderse a las siguientes preguntas:
 ¿Qué clases del dominio, entidades del negocio o
unidades del trabajo deben tenerse en cuenta para ser
elementos de la interfaz de usuario para caso de uso?
 ¿Con cuál de estos elementos va a trabajar cada actor?
 ¿Qué acciones va a tomar el usuario con estos elementos
y qué decisiones puede llegar a tomar?
 ¿Qué información necesitará el actor antes de realizar
cada acción de los casos de uso?
 ¿Qué información el actor le debe dar al sistema?
 ¿Qué información el sistema le debe dar al actor?
 ¿Cuáles son las cantidades medias de los parámetros de
entrada y salida que se manipulan en los casos de uso?

Todos los elementos se ordenan para simular la apariencia de la

interfaz de usuario. Luego los diseñadores de casos de uso deben
describir la manera en que los actores van a utilizar a estos
elementos al llevar a cabo los casos de uso. Se puede utilizar
notas autoadhesivas, las cuales se podrán ir acomodando y
cambiando para permitir a los usuarios que trabajen en forma
interactiva con los diseñadores.

¿Cómo se crea el diseño físico de la interfaz de usuario?

181
 El diseñador de interfaz de usuario prepara en primer lugar
esquemas aproximados de la configuración de los elementos de
la interfaz de usuario para los actores.

Después, se preparan elementos adicionales para combinar los

elementos de la interfaz de usuario, por ejemplo, carpetas,
ventanas, controles, etc. Esto se hace luego de crear el diseño
lógico de la interfaz de usuario.
Finalmente, el diseñador puede preparar los prototipos, uno para
cada actor que ejecuta los casos de uso. Estos prototipos deben
tener relación directa con el valor de retorno de cada caso de uso.

Estas interfaces de usuario deben validarse utilizando técnicas de

revisiones de prototipos que ayudan a prevenir errores que
conviene detectarlos ante de corregirlos luego. En estas
revisiones se debe tener en cuenta lo siguiente:

 El actor navega en forma adecuada,

 La interfaz tiene buena apariencia y es consistente con la
forma de trabajo.
 Se tiene en cuenta los estándares tales como colores,
tamaños, barras de herramientas, etc.

13. Estructuración del Modelo de Casos de Uso.

El objetivo de esta actividad es extraer descripciones de

funcionalidad generalizadas y compartidas que utilizan
descripciones más específicas. También el objetivo tiene que ver
con extraer descripciones de funcionalidad adicionales u
opcionales que extienden descripciones más específicas.

182
Antes de hacer esta actividad, se identifican los actores y los
casos de uso, usando diagramas y explicando el modelo de casos
de uso.

Luego el analista de sistemas reestructura el modelos de casos

de uso con el objetivo que el modelo sea fácil de entender de
trabajar con él.

Se debe buscar comportamiento compartido y extensiones.

Descripciones de funcionalidad compartidas.

¿Qué es una generalización? Mientras se buscan los casos de

uso, se deben ir identificando aquellas acciones que son comunes
o compartidas por varios casos de uso. Esto se hace con el
objetivo de reducir la redundancia, es decir, en este caso, las
acciones que están descriptas por demás en los casos de uso.
Estas acciones que están compartidas por se extraen y se
describen en un caso de uso aparte para ser reutilizado por el
caso original.

Se denomina generalización a una relación de uso que sirve para

ver la relación de reutilización de estos casos de uso. Esta
relación de uso entre casos de uso o generalización es una clase
de herencia, en la que las instancias de los casos de uso que son
generalizados pueden ejecutar todo el comportamiento que se
describe en el caso de uso generalizador.

La generalización se usa para comprender en forma más

adecuada los casos de uso y luego poder reutilizar estos casos de
uso que se fabrican. Esto se lleva a cabo en el momento de

183
estructurar el modelo de los casos de uso, al revisar los casos de
uso con los usuarios.

Los casos de uso que comienzan los actores y que los mismos
instancian se denominan casos de uso concretos. Los casos de
uso que se fabrican con acciones compartidas que luego se
reutilizan por otros casos de uso, se denominan casos de uso
abstractos.

Estos casos de uso abstractos, que representan el

compartimiento de acciones entre casos de uso, no se instancian
por sí mismos. Es decir, una instancia del caso de uso concreto
que lo reutiliza, exhibe el comportamiento descripto en el caso de
uso abstracto. Esta instancia del caso de uso que el actor percibe
cuando interactúa con el sistema se la denomina instancia real del
caso de uso.

Descripciones de funcionalidad adicional y opcional.

¿Qué es una extensión? La extensión es otra relación de uso

entre casos de uso que modela la adición de una secuencia de
acciones de un caso de uso. Esto quiere decir que, una relación
de extensión de un caso de uso hacia otro, indica que una
instancia de éste último caso de uso puede tener incluir el
comportamiento del primer caso de uso. Cuando se habla de
comportamiento nos referimos a condiciones específicas en las
extensiones.

En la relación de extensión se incluye una condición para la

relación y una referencia a un punto de extensión en el caso de
uso destino. Este punto de extensión sirve para que cuando una

184
instancia del caso de uso destino sigue su secuencia de acciones
y llega a dicho punto se evalúa la condición de la relación. Si la
condición evaluada es verdadera se sigue la secuencia del caso
de uso extendido.

Los casos de uso reales son aquellos que les aportan valor a los
usuarios. Los casos de uso reales son casos de uso que en
general se obtienen utilizando relaciones de generalización y
extensión.

Los casos de uso concretos no deben describir comportamientos

que son compartidos con otros casos de uso concretos. Los
casos de uso abstractos ayudan a la especificación de los casos
de uso concretos. Los casos de uso abstractos le brindan a los
concretos un comportamiento compartido y reutilizable.

185
ANALISIS Y DISEÑO DE SISTEMAS.

Unidad 9: Análisis.

1. Objetivo del análisis.

2. Papel del análisis en el Ciclo de vida.
3. Modelo de Análisis.
4. Clases de análisis.
5. Clases de interfaz, de entidad, de control.
6. Realización de casos de uso – análisis.
7. Trabajadores en el análisis.

1. Objetivo del análisis.

Durante este flujo de trabajo se analizan los requisitos que se

describieron en su captura, depurando y estructurando los
mismos. Por consiguiente el objetivo es obtener una comprensión
más clara de los requisitos y una nueva descripción de los
mismos que sea mantenible fácilmente y que pueda asistir en la
estructuración del sistema entero.

Durante la captura de requisitos se utiliza un lenguaje intuitivo,

con el objetivo de poder comunicarle al cliente de la manera más
eficiente las funciones del sistema.

Para que esto pueda llevarse a cabo, se debe tener en cuenta

que los casos de uso deben mantenerse tan independientes unos
de otros como sea posible, que se describan usando el lenguaje
del cliente y que se estructure cada uno de los casos de uso para

186
obtener una buena especificación de funcionalidad amplia e
intuitiva.

El objetivo más importante del flujo de trabajo del análisis es

resolver los puntos anteriores en forma más profunda pero ahora
con un lenguaje diferente, el lenguaje de los desarrolladores. En
consecuencia, en el análisis se refinan los requisitos. ¿Qué
significa que se refinan los requisitos? Se razona sobre los temas
internos del sistema, para resolver la independencia de los casos
de uso, y se utiliza un lenguaje más formal para detallar más aún
los requisitos. Además, se estructuran los requisitos para que se
puedan comprender mejor y luego se preparen, se mantengan y
se modifiquen.

Esta estructura, basada en clases de análisis y paquetes de

análisis, debe ser independiente de la que se especificó en la
captura de requisitos, basada en los casos de uso. Debe existir
una relación entre dichas estructuras, es decir, lo que se
denomina trazabilidad. Esto se define entre los casos de uso del
modelo de casos de uso y las realizaciones de casos de uso en el
modelo de análisis.

Finalmente, toda esta estructura de requisitos que se lleva a cabo

en el análisis sirve de base y entrada fundamental para crear y
dar forma al sistema entero.

Durante el análisis los trabajadores son responsables de varios

artefactos. El arquitecto es responsable del modelo de análisis y
de la descripción de la arquitectura. El ingeniero de los casos de
uso es responsable de la realización de los casos de uso. Y el
ingeniero de componentes es responsable de las clases de
análisis y del paquete de análisis.

187
El análisis se basa en un modelo de análisis que es un modelo de
objetos conceptual. Este modelo depura los requisitos para
pensar en los aspectos internos del sistema y los recursos
compartidos internos. Un objeto interno de este modelo es la
clase. También este modelo proporciona una mayor formalización,
los diagramas de interacción que describe aspectos dinámicos del
sistema.

El modelo de análisis ayuda a estructurar los requisitos y su

estructura apunta al mantenimiento, basándose en la flexibilidad
ante los cambios y una futura reutilización. Esta estructura del
modelo de análisis se utiliza como entrada a los flujos de trabajo
del diseño y la implementación.

El modelo de análisis se puede considerar como una

aproximación al modelo de diseño haciendo abstracciones y
posponiendo ciertos requisitos y otros problemas a dicho modelo.
Esto se debe a que en el diseño se tratan temas como la
plataforma, el lenguaje de programación, sistemas operativos,
marcos de trabajo o sistemas heredados.

El análisis realiza refinamiento y estructuración de requisitos. En

el diseño se le da forma de dichos requisitos. En el diseño se
toman decisiones a aspectos de rendimiento y de distribución,
software pre planeados, lenguajes de programación, bases de
datos, es decir, requisitos no funcionales.

188
 Por este motivo antes de diseñar e implementar, en la etapa del
análisis, se debe sólo llegar a una comprensión muy completa de
los requisitos.
Podemos decir que:

 El modelo de análisis brinda una especificación más

detallada de la captura de requisitos.

 El modelo de análisis se describe utilizando un lenguaje de

desarrolladores, dando formalismo y se utiliza para pensar
el funcionamiento interno del sistema.

 El modelo de análisis estructura los requisitos capturados

mejorando su comprensión, su preparación y
mantenimiento.

 El modelo de análisis es una aproximación al modelo de

diseño y sirve de entrada a la forma del sistema y a su
posterior implementación. Esto se debe a la descripción de
los requisitos para que luego el sistema pueda ser
mantenible.

2. Papel del análisis en el ciclo de vida.

El análisis sirve de entrada a las primeras iteraciones de la fase

de elaboración y ayuda a comprender muy bien los requisitos y a
tener una arquitectura estable. Luego al final de dicha fase
cuando la arquitectura es estable y se comprendieron los

189
 requisitos, en la fase de la construcción se pase a al diseño e
implementación.

Todo esto lo visualizamos en el siguiente gráfico.

Fases

Flujos de
Trabajo
Fundamentales Inicio o Elaboración Construcción Transición
Concepción

Requisitos

Análisis

Diseño
Aquí se
Implement observa
cómo el flujo
Prueba de trabajo
del análisis
Iteración Iteración Iteración Iteración y todos sus
1 2 n-1 N artefactos
resultantes
adquieren
Iteraciones distintas
formas.

El objetivo del análisis se debe ver durante todo el ciclo de vida

del sistema. A veces se ve de manera diferente.

Algunas veces el modelo de análisis se utiliza durante todo el

proyecto para describir sus resultados y mantener su
consistencia.

Otras veces, el proyecto utiliza el modelo de análisis para

describir sus resultados y lo utiliza para avanzar con el sistema

190
 sólo durante la fase de elaboración. Cuando el sistema pasa por
el diseño y la elaboración el modelo de análisis deja de
actualizarse.

En estos casos, se debe analizar si el actualizar y mantener el

modelo trae provecho en función de un análisis de costo y
beneficio o si conviene no actualizarlo luego de la fase de
elaboración.

A veces, también, el proyecto no utiliza para nada el modelo de

análisis y en su defecto, se analizan los requisitos en su fase de
captura o en el diseño. Si se lleva a cabo en la captura de
requisitos, el modelo de casos de uso es formalizado
ampliamente. Esto se puede hacer si los requisitos son bien
comprendidos por los clientes; en caso contrario, se puede hacer
si los requisitos son muy simples.

En este caso, se pondría total énfasis en colocar el modelo al

principio. De todas maneras, el uso del modelo de análisis es
totalmente ventajoso comparándolo con el no uso del mismo.

3. Modelo de Análisis.

El modelo de análisis se compone o está representado por un

sistema de análisis, el cual muestra un paquete de análisis, que
es un artefacto de más alto nivel del modelo.

El uso de varios paquetes de análisis sirve para organizar el

modelo de análisis en partes más manejable que representan
abstracciones de subsistemas.

191
 Las clases de análisis representan abstracciones de clases y los
casos de uso en este modelo se describen mediante clases de
análisis y sus objetos. Esto se representa por colaboraciones en
el modelo de análisis, las cuales se denominan realizaciones de
casos de uso.

4. Clases de análisis.

Una clase de análisis representa una abstracción de una o varias

clases o subsistemas del diseño del sistema. Esta abstracción
tiene las siguientes características:

 Se guía en el tratamiento de los requisitos funcionales y

deja para más adelante los requisitos no funcionales.

 Es más conceptual, pues la clase de análisis se basa en

el contexto del dominio del problema.

 No define una interfaz en cuanto a lo que se tiene que

operar, sino en cuanto a responsabilidades en una
manera informal. Una responsabilidad es una descripción
textual del comportamiento de una clase, es decir la parte
cohesiva.
 Define atributos y sus tipos son también conceptuales en
el dominio del problema. En las clases de diseño y de
implementación estos atributos y tipos pasan a ser tipos
de lenguajes de programación e incluso pasan a ser
nuevas clases.

192
  En las clases de análisis aparecen las relaciones entre
ellas pero sólo también en forma conceptual.

 Siempre se puede clasificar las clases en tres tipos

básicos: de interfaz, de control o de entidad, lo cual sirve
para describir e identificar las clases.

5. Clases de interfaz, de entidad, de control.

Clases de Interfaz.

Una clase de interfaz se utiliza para modelar la interacción entre el

sistema y sus actores (usuarios y sistemas externos). Esto
significa recibir información de los usuarios o sistemas externos,
es decir, la entrada al sistema. También significa enviar
información hacia los usuarios o sistemas externos, es decir, la
salida del sistema.

Una clase de interfaz modela las partes del sistema que

dependen de sus actores. Estas clases de interfaz aclaran y
juntan los requisitos en los límites del sistema. Esto significa que
si existe un cambio en la interfaz de usuario o de comunicaciones
queda plasmado en una o más clases de interfaz.

En general las clases de interfaz representan abstracciones de

ventanas, formularios, interfaces de comunicaciones, interfaces
de impresora, sensores, terminales y otros objetos. Estas clases
de interfaz son conceptuales, no debe haber extrema
profundización. Es decir, deben describir la interacción entre el
sistema y los actores y con sólo mencionar la información que se
necesita en esa interacción, basta. Tampoco es necesario
describir cómo ejecutar físicamente esa interacción.

193
Cada clase de interfaz se asocia por lo menos con un actor. Un
actor también se asocia con al menos una clase de interfaz.

Las clases de interfaz se asocian con la parte interna del sistema,

es decir con las clase de control y las clases de entidad.

Clases de Entidad.

Una clase de entidad se utiliza para modelar la información que

tiene larga vida y que es persistente.

Una clase de entidad modela la información y el comportamiento

que se asocia a un concepto o fenómeno, por ejemplo, un objeto,
una persona o un suceso de la realidad.

Una clase de entidad depende directamente de una clase de

entidad del dominio o de negocio, que se toman del modelo de
objetos del negocio o del dominio. Esto significa que representan
objetos que están en el negocio y en el dominio del problema.
Esto ayuda a los desarrolladores al diseñar o implementar el
sistema.

Un objeto de la clase de entidad no es siempre pasivo, es decir

tiene un comportamiento que se corresponde con la información
que representa.

Una clase de entidad brinda una estructura de datos lógica y

además ayuda a entender la información de la cual depende el
sistema.

194
 Clases de Control.

Una clase de control se utiliza para representar coordinación,

secuencia, transacciones y control de otros objetos.

Una clase de control se utiliza para encapsular el control de un

caso de uso.

Una clase de control se utiliza para representar derivaciones o

cálculos complejos, es decir corresponde a la lógica del negocio
que no se puede asociar con información ni concreta, ni de larga
duración, ni almacenada por el sistema (clase de entidad).

Una clase de control maneja el dinamismo del sistema, es decir,

manejan y coordinan las acciones y los flujos de control más
importantes y delegan trabajo a otros objetos de interfaz y de
entidad.

Las clases de interfaz y de entidad encapsulan la interacción entre

el sistema y los actores y la información de larga vida y
persistente que maneja el sistema. En cambio, la clase de control
encapsula los cambios de control, la coordinación, la secuencia,
las transacciones y la lógica del negocio que abarca a varios otros
objetos.

6. Realización de casos de uso – análisis.

Una realización de caso de uso- análisis es una colaboración

dentro del modelo de análisis. El objetivo de la realización de caso
de uso se utiliza para describir cómo se lleva a cabo y cómo se
ejecuta un caso de uso determinado teniendo en cuenta las
clases de análisis y los objetos que sirven para la interacción.

195
Una realización de caso de uso- análisis tiene una descripción
textual del flujo de suceso, diagramas de clases y diagramas de
interacción. Los diagramas de clases muestran las clases de
análisis que participan. Los diagramas de interacción muestran la
realización de un flujo del caso de uso en función de los objetos
del análisis. Por este motivo, el de usar las clases de análisis y
sus objetos, la realización del caso de uso se especializa en los
requisitos funcionales, dejando los no funcionales para el diseño e
implementación.

Diagramas de clases.

Puede pasar que una clase de análisis y sus objetos participen en

varias realizaciones de casos de uso. Por lo tanto algunas
responsabilidades, atributos y asociaciones de una clase pueden
ser solo relevantes para una sola realización de caso de uso.

Luego durante el análisis es importante coordinar los requisitos

sobre una clase y sus objetos que tengan diferentes casos de
uso. Así se agregan diagramas de clase a las realizaciones de
casos de uso con el objetivo de ver sus clases y sus relaciones.

Diagramas de interacción

Cuando un actor invoca a un caso de uso, enviando algún tipo de

mensaje al sistema, empieza la secuencia de acciones en un caso
de uso.

Es así que, el objeto de interfaz recibirá dicho mensaje del actor.

Y luego, el objeto de interfaz enviará este mensaje a otro objeto.

196
Así los objetos que estén involucrados interactuarán para llevar a
cabo el caso de uso.

Durante el análisis, toda esta secuencia conviene mostrarla con

diagrama de colaboración. Su objetivo principal es identificar
requisitos y responsabilidades sobre los objetos. Su objetivo no es
identificar secuencias de interacción detalladas y ordenadas en
forma cronológica. Si así fuera, se usaría un diagrama de
secuencia.

Por lo tanto, con los diagramas de colaboración, se ve la

interacción entre los objetos creando enlaces entre ellos y
agregando mensajes en dichos enlaces.

El mensaje debe tener un nombre que indique el objetivo del

objeto que invoca a un objeto en la misma interacción.

En los diagramas de colaboración los diferentes objetos tienen

diferentes ciclos de vida y cumplen lo siguiente:

 Un objeto de interfaz, con frecuencia, se crea y termina

dentro de una sola realización de caso de uso.

 Puede pasar que un objeto de interfaz no sea particular

de una sola realización de caso de uso. Puede pasar
también que aparezca en una misma ventana, por
ejemplo, y participar en más instancias de casos de uso.

 Un objeto de entidad no es particular de una sola

realización de casos de uso.

 Un objeto de entidad tiene, en general, larga vida y

participa en varias realizaciones de casos de uso, antes
de su destrucción.

197
  Una clase de control encapsula el control asociado con un
caso de uso concreto. Esto significa que hay que crear un
objeto de control cuando empieza el caso de uso. Cuando
termina el caso de uso, hay que destruir el objeto.

 Hay excepciones para las clase de control:

o Un objeto de control participa en varias

realizaciones de caso de uso.

o Varios objetos de control participan en una misma

realización de caso de uso.

o Una realización de caso de uso no necesita

ningún objeto de control.

Los diagramas de colaboración de una realización de caso de

uso pueden llegar a ser algo dificultosos para leer. Por lo tanto,
es bueno agregar un texto adicional que lo explique.

Este texto adicional tiene que escribirse en función de los objetos

de control que interactúan para llevar a cabo el caso de uso. No
se menciona ningún atributo, responsabilidad o asociación del
objeto, pues se modifican con mucha frecuencia y, por lo tanto
sería muy difícil de mantenerlo.

También se puede escribir otro texto adicional que corresponden

a los requisitos no funcionales sobre la realización de caso de
uso. Varios ya se habían capturado en el flujo de trabajo de los
requisitos y sólo se deben pasar a una realización de casos de
uso. Algunos de ellos pueden ser requisitos nuevos o los que van
a pareciendo a medida que el flujo de análisis avanza.

198
7. Trabajadores en el análisis.

Durante el flujo e trabajo de análisis existen varios trabajadores: el

arquitecto, el ingeniero de casos de uso y el ingeniero de
componentes.

Arquitecto.

El arquitecto es el responsable de la integridad del módulo de

análisis. Se encarga de que el módulo de análisis sea correcto,
consistente y legible. Es responsable de la descripción de la
arquitectura.

El arquitecto hace que el modelo de análisis sea correcto cuando

el modelo realiza la funcionalidad que se especifica en el modelo
de casos de uso.

El arquitecto es responsable de la arquitectura del modelo de

análisis cuando se hace responsable de las partes significativas
para la arquitectura, es decir, la vista de la arquitectura o la
descripción de la arquitectura del sistema.

El arquitecto no se hace responsable del desarrollo y

mantenimiento continuo de otros artefactos del modelo de
análisis; esto es responsabilidad de los ingenieros de casos de
uso y de componentes.

Ingeniero de casos de uso.

El ingeniero de casos de uso es responsable de la integridad de

una o varias realizaciones de casos de uso. Se encarga de que se
cumplan los requisitos de los mismos casos de uso. Es
responsable de que la realización del caso de uso lleve a cabo el

199
comportamiento del caso de uso correspondiente del modelo de
casos de uso.

El ingeniero de casos de uso se hace responsable de garantizar

que todas las descripciones textuales y los diagramas que
describen la realización del caso de uso cumplan con su objetivo.

El ingeniero de casos de uso no es responsable de las clases de

análisis ni de las relaciones que se usan en la realización del caso
de uso. Esto es responsabilidad del ingeniero de componentes.

El ingeniero de casos de uso se hace responsable del análisis y

también del diseño de las realizaciones de los casos de uso.

Ingeniero de componentes.

El ingeniero de componentes es responsable de definir y

mantener las responsabilidades, atributos, relaciones y requisitos
especiales de las clases de análisis. Se hace responsable de que
cada clase de análisis cumpla con los requisitos de cada una
según las realizaciones de uso en las que participan.

El ingeniero de componentes se encarga de mantener la

integridad de los paquetes de análisis, es decir que todos sus
componentes y sus dependencias con otros paquetes sean
correctas. A su vez, también se hace responsable de las clases
de análisis que componen los paquetes.

El ingeniero de componentes también se hace responsable de los

subsistemas de diseño correspondientes si existe una
correspondencia directa entre los paquetes de análisis y los
subsistemas de diseño.

200
GLOSARIO.

Administrador de base de datos: Persona encargada de velar por

la integridad de los datos y sus asociaciones, así como de autorizar
las modificaciones que se desee hacer.

Administrador de archivos: (File Manager o Manejador de

Archivos): Aplicación utilizada para facilitar distintas tareas con
archivos como la copia, eliminación, movimiento entre otras. Algunos
administradores de archivos permiten la asociación de las
extensiones de los archivos con las aplicaciones preparados para
trabajar con los mismos, permitiendo abrir, reproducir, modificar,
etc. cada archivo con la aplicación asociada.

Alfanumérico: Característica que indica un conjunto de caracteres

que incluye letras, números y signos de puntuación.

Algoritmo: Procedimiento lógico-matemático, aplicado para resolver

un problema.

Almacenamiento aleatorio: Método de almacenamiento que

permite el acceso directo a los datos sin pasar por los anteriores, lo
cual reporta una mayor rapidez.

Análisis de sistemas: Estudio de una tarea o función para

comprenderla y encontrar mejores maneras de realizarla.

Aplicación: Programa diseñado para una determinada función.

Archivo: Conjunto de datos relacionados.

201
Artefacto: Pieza de información tangible que es creada, modificada
y usada por los trabajadores al realizar actividades.

ASCII (American Standard Code for Information Interchange):

Código estándar estadounidense para el intercambio de información.
Código de siete bits adoptado como un estándar mundial para
facilitar el intercambio de datos entre distintos sistemas y máquinas
en ambientes conectados en red.

Automatización: Realización de una combinación específica de

acciones por una máquina, sin la ayuda de personas.

Backup: Copias de archivos, equipos de reemplazo o

procedimientos alternativos disponibles para ser usados en caso de
emergencias producidas por fallas totales o parciales de un sistema
computacional.

Base de datos: Colección de archivos de datos, de tipo histórico,

utilizados para consultas específicas de algún tema en particular.

Base de datos relacional: Colección de datos organizada y

relacionada, para evitar duplicaciones y permitir la obtención de
datos combinados, satisfaciendo la necesidad de usuarios con
diferentes necesidades de información.

Buffer: Área de memoria en que se almacenan datos para

compensar las diferencias de tiempo, al transmitir datos a través de
canales deficientes o entre dispositivos que trabajan a diferentes
velocidades.

Byte: Conjunto de 8 bits usado para designar un caracter, letra o

número.

202
C

CD-ROM: (Compact Disc Read-Only Memory): Tecnología de

almacenamiento óptico sólo de lectura, utilizada por los discos
compactos.

Cliente: Programa que demanda servicios de otra computadora

llamada servidor, y se hace cargo de la interacción necesaria con el
usuario.

Código de barras: Representación de datos impresos, consistente

en líneas que pueden identificarse con un lector óptico.

Código fuente: Programa escrito en un lenguaje de programación

de alto nivel por un programador. Es solo un archivo de texto simple
que contiene la secuencia de operaciones que la computadora
deberá ejecutar, en una forma simple de entender por una persona
que sepa programar en dicho lenguaje.

Código objeto: Programa expresado en lenguaje de máquina (ceros

y unos), de manera que pueda ser ejecutado por una computadora.

Compatibilidad: Habilidad de usar sistemas y dispositivos de una

computadora en otra, sin requerir cambios.

Compilador: Programa que traduce instrucciones escritas en un

lenguaje de programación de alto nivel a un lenguaje de máquina.

Compilar: Generar un programa en lenguaje de máquina a partir de

un lenguaje de programación de alto nivel.

Computadora: Una computadora es un sistema digital con

tecnología microelectrónica capaz de procesar datos a partir de un
grupo de instrucciones denominado programa. La estructura básica
de una computadora incluye microprocesador (CPU), memoria y

203
dispositivos de entrada/salida (E/S), junto a los buses que permiten
la comunicación entre ellos.

Consola: Interfaz de comandos de un sistema operativo que permite

el envío de órdenes a la computadora a través del teclado.

Cursor: es una barra horizontal o vertical que indica la posición de la

entrada de texto en la pantalla de la computadora. En los entornos
gráficos, el cursor y el puntero del ratón pueden aparecer
simultáneamente.

Dato: Representación de un hecho o idea que puede ser manipulado

y al cual se le puede asignar un significado.

Default: Ajustes por defecto. Lo que pasará si no se modifica nada.

Depuración: Detección, localización y eliminación de errores en un

programa. También llamado debugging.

Desarrollador: Trabajador participante en el flujo de trabajo

fundamental. Por ejemplo, un ingeniero de casos de uso o de
componentes, etc.

Diagrama de flujo: Representación gráfica de los tipos y secuencia

de operaciones de un programa o proceso.

Disco rígido: Medio secundario de almacenamiento compuesto por

varios discos superpuestos, con cabezas lecto-grabadoras, alojado
en una unidad cerrada herméticamente.

Disco magnético: Plato circular extendido, cuyas superficies son

magnéticas. Sobre ellas pueden escribirse datos por magnetización

204
de pequeños segmentos. El disco puede ser rígido (hard) o flexible
(floppy).

Diskette: Disco delgado y manipulable que dispone de dos

superficies de grabación magnética. Sus variables más comunes son
los floppy disks o discos flexibles, aunque también existen otros de
mayor capacidad como los discos Zip.

Dominio: El nombre de dominio es un identificador único a través de

la cual las computadoras se vinculan a Internet (por ej. para
identificar sitios web y direcciones de correo electrónico). El sistema
es jerárquico permitiendo la definición de subdominios de un dominio
existente. A veces coloquialmente (y de modo incorrecto) se utiliza
para referirse a las "direcciones Web")

Emulación: Proceso mediante el cual una computadora se hace

funcionar como si fuera otra, para aceptar el mismo tipo de datos,
ejecutar los mismos programas y obtener iguales resultados.

Estímulo: Una operación o una señal.

Evento: La especificación de una ocurrencia significativa que tiene

una ubicación en el tiempo y en el espacio; en el contexto de
máquinas de estados, un evento es una ocurrencia de un estímulo
que puede disparar una transición de estados.

Fiabilidad: Habilidad de un sistema para comportarse correctamente

sobre su entorno de ejecución real.

205
Fibra óptica: Cable compuesto de fibra de vidrio que transporta
señales de luz en lugar de eléctricas, brindando un mayor nivel de
velocidad y confiabilidad.

Firmware: Secuencia de comandos básicos, embebidos dentro del

hardware. Generalmente estos comandos están en las memorias
ROM.

Formato de archivo: Estructura de un archivo que define la forma

en que se guarda y representa la información que contiene en la
pantalla o en la impresora. El formato puede ser muy simple y
común, como el de los archivos guardados como texto ASCII puro, o
puede ser muy complejo e incluir varios tipos de instrucciones y
códigos de control utilizados por programas, impresoras y otros
dispositivos o el modo de compresión de los datos, como algunos
formatos gráficos. En MS-DOS la extensión del nombre del archivo
suele indicar el formato del archivo. Entre los ejemplos se cuentan el
formato RTF (Rich Text Format), DCA (Document Content
Architecture), PICT, DIF (Data Interchange Format), DXF, TIFF (Tag
Image File Format) y EPSF (Encapsulated PostScript Format).

Framework: Marco de trabajo.

Gigabyte (GB): 1.024 Megabytes, o aproximadamente mil millones

de bytes (1.024 x 1.024 x 1.024 bytes).

Hardware: Los componentes físicos de la computadora, así como

sus periféricos.

206
Herencia: Mecanismo mediante el cual elementos más específicos
incorporan la estructura y el comportamiento de elementos más
generales.

Hipertexto: Sistema de organización y consulta de la información

de manera no secuencial. La información se relaciona mediante
enlaces que permiten vincular entre sí documentos o partes de
documentos a través de "saltos".

Hipervínculo: Conexión en distintos puntos de una página de

Internet, que lleva a otro punto determinado del mismo sitio o de otro
dentro de la red.

Ícono: Símbolo que representa un programa, archivo o aplicación y

que sirve para ejecutar al mismo.

Impresora: Periférico diseñado para copiar en un soporte «duro»

(papel, acetato, etc.) texto e imágenes en color o blanco y negro.

Impresora de chorro de tinta: También se conoce por su definición

en inglés (ink-jet). Este tipo de impresoras funcionan mediante una
serie de inyectores que proyectan gotas diminutas de tinta, de
manera que la acumulación de gotas permite la formación de letras,
imágenes, etc. Esta clase de impresoras se ha impuesto por ofrecer
una alta calidad de impresión a un precio aceptable.

Información: Es el resultado del procesamiento de datos. Todo

aquello que permite adquirir cualquier tipo de conocimientos.

Informática: Es la ciencia del tratamiento automático de la

información mediante una computadora. La informática es un amplio
campo que incluye los fundamentos teóricos, el diseño, la
programación y el uso de las computadoras (ordenadores).

207
Instalar: Grabar un programa en el disco rígido y configurarlo de
forma que funcione correctamente. La mayor parte de los programas
incluyen instaladores que realizan esta labor en forma casi
automática.

Instrucción: Conjunto de caracteres que especifica una operación a

realizarse y el valor o ubicación de uno o más operandos requeridos.

Inteligencia artificial: Programas diseñados para que su

funcionamiento imite los procesos humanos de toma de decisiones y
para que aprenda de los eventos pasados.

Interfaz: Conexión entre dos componentes de hardware, entre dos

aplicaciones o entre un usuario y una aplicación. También llamada
por el término en inglés interfase.

Internet: Red mundial de computadoras conectadas a través del

protocolo TCP/IP. Es la más grande e importante red de redes
interconectadas a través de routers. .

Intranet: Denominación utilizada para referirse a la red interna de

una empresa o institución.

Joystick: Literalmente, palanca de juegos. Usado para mover un

objeto por la pantalla. Se compone de una base desde la que sale
una palanca vertical, con la cual se controla el movimiento y también
suelen incluir varios botones.

Key: Clave utilizada para acceder a datos protegidos por

encriptación.

Kilobyte (KB): Medida de información. Contiene 1.024 bytes.

208
L

LAN (Local Área Network): Red de área local. Es la forma en la cual

se interconectan computadoras ubicadas en un mismo lugar a través
de un cable de red.

LCD (Liquid Crystal Display): Pantalla de cristal líquido, utilizadas en

Notebooks y Handhelds.

Lenguaje de programación: Conjunto de sentencias utilizadas para

escribir secuencias de instrucciones para ser ejecutadas en una
computadora.

Lenguaje de programación de alto nivel: Lenguaje de

programación cercano a la notación utilizada en problemas o
procedimientos. Por ejemplo FORTRAN, BASIC, C, PASCAL o
Logo.

Lenguaje de programación de bajo nivel: Lenguaje de

programación orientado a la máquina. Como los lenguajes de
máquina y ensambladores.

Login: Acción de conectarse a un sistema ingresando un nombre de

usuario y una contraseña.

Macro: Instrucción de un programa fuente que realiza un conjunto

de operaciones en otro programa que lo contiene.

Megabyte (MB): Medida de información equivalente a 1.024

kilobytes.

209
Memoria: Almacenamiento primario de una computadora, como la
RAM o la ROM.

Memoria principal: Lugar en el cual se almacenan datos e

instrucciones en una computadora antes y durante su ejecución.

Memoria virtual: Una técnica de administración de memoria que

permite utilizar un espacio del disco duro como si se tratase de
memoria RAM. Esta técnica proporciona a las aplicaciones la
posibilidad de utilizar más memoria de la que el sistema dispone.

Menú: Lista de opciones mostrada sobre una pantalla de las cuales

el usuario puede seleccionar.

Método: La implementación de una operación.

Microcomputadora: Computadora cuya unidad central de proceso

es un microprocesador.

Microprocesador: Circuito integrado de altísimo nivel de integración

capaz de contener más de 100.000.000 de transistores en 1 cm² (al
año 2005).

Módem (MOdulador - DEModulador): Aparato que convierte las

señales digitales en analógicas y viceversa. Permite la comunicación
entre dos computadoras a través de la línea telefónica.

Modelo: Una abstracción de un sistema cerrada semánticamente.

Mouse: Ver Ratón.

Multimedia: Forma de presentar información a través de una

computadora, usando texto, gráficos, sonido o video.

Multiprocesamiento: Técnica para ejecutar dos o más secuencias

de instrucciones simultáneamente en una misma computadora. Se

210
necesita más de un procesador (máquinas grandes) o
microprocesadores especiales.

Multitarea: Ejecución simultánea, en una computadora, de más de

un programa. Las tareas se alternan en la ejecución a tanta
velocidad que el usuario no llega a percibir su interrupción.

Nodo: Computadora o cualquier otro dispositivo conectado a una

red.

Notebook: Microcomputadora portátil de gran potencia de cálculo y

con batería que le proporciona la capacidad de trabajo sin estar
enchufada a la red eléctrica.

Nota: Un comentario asociado a un comentario o a un conjunto de

elementos.

Objeto: Instancia.

Online: Equipos o dispositivos que están en comunicación directa o

encendidos.

Operación: La operación de un servicio que puede ser solicitado por

cualquier objeto de la clase para afectar a su comportamiento.

Ordenador: Término usado en España y en algunos países de

latinoamérica para referirse a una computadora.

Palabra reservada: Palabra que no puede usarse para propósitos

distintos de los establecidos por el programa en uso.

211
Password: Contraseña utilizada para ingresar en una red o en un
sistema de manera segura. Conjunto de caracteres alfanuméricos
requeridos para acceder a una determinada red, sistema, aplicación
o recurso.

Pista: Parte de un medio de almacenamiento, que consiste en un

área de forma circular, que es accesible por medio del
desplazamiento radial la cabeza lectograbadora.

Plotter: Tipo de impresora de gran tamaño, que produce gráficos

por movimientos automáticos de lápices o plumas, o bien a través de
medios electroestáticos.

Procesador de textos: Programa que permite la manipulación de

textos con formato y que permite generar archivos que conserven el
estilo realizado.

Procesamiento de datos: Secuencia sistemática de operaciones

realizadas sobre datos para obtener un resultado deseado.

Procesamiento en tiempo real: Técnica de procesamiento en que

la actualización de los datos afectados por un evento se realiza a
medida que sucede el evento causante.

Proceso: Manipular datos o realizar otras operaciones de acuerdo a

un programa.

Programación: Se llama programación a la creación de un

programa informático, un conjunto concreto de instrucciones que una
computadora u otro dispositivo informático puede ejecutar. El
programa se escribe en un determinado lenguaje de programación,
(con dificultad se puede se puede escribir directamente en lenguaje
de máquina). Un programa puede estar dividido en diversas partes,
que pueden estar escritas en lenguajes distintos.

212
Programa: Secuencia de instrucciones que dirige a la computadora
a realizar operaciones específicas para obtener un resultado
deseado.

Programa de control: Programa del sistema operativo que lee

instrucciones de control.

Programa fuente: Ver código fuente.

Programa intérprete: Programa de computadora que procesa

instrucciones de lenguajes de programación de alto nivel instrucción
por instrucción, determinando las operaciones requeridas y haciendo
que la computadora las realice.

Programa objeto: Ver código objeto.

Programador: Persona que define la solución a un problema y

escribe las instrucciones requeridas por una computadora para llevar
a cabo esa solución. Un programador que también realiza análisis de
sistemas y diseño, suele llamarse Analista/Programador.

Protocolo: Definición del sistema de comunicación de una

computadora. Acuerdo entre diferentes sistemas para trabajar
conjuntamente bajo un estándar común. Conjunto de normas que
permiten estandarizar un procedimiento repetitivo.

Prueba de escritorio: Inspección visual de un programa para

depurarlo antes de ejecutarlo en una computadora. Se realiza a
mano.

RAM (Random-Access Memory): Memoria primaria de una

computadora. En las PCs es accesible por el procesador a través del
puente norte del chipset.

213
Ratón: También conocido como mouse. Puntero manejado a mano
para manipular el cursor en la pantalla. Especialmente útil en las
GUI.

Recuperación: Habilidad para reiniciar el proceso, ante una falla del

equipo, sin pérdida de datos o resultados.

Red: Interconexión de una o más computadoras a través de

hardware y software.

Red de área local (LAN): Ver LAN.

Rol: El comportamiento específico de un entidad que participa en un

contexto particular.

Salida: Output. Resultado del procesamiento.

Señal: La especificación de un estímulo asincrónico comunicado

entre instancias.

Servidor: Computadora o programa que proporciona recursos y

servicios a las computadoras conectadas a una red y al mismo
tiempo gestiona el uso de esa red.

Shareware: Software cedido por su creador con objeto de que sea

utilizado en régimen de prueba y pagado si el usuario lo encuentra
de utilidad.

Simulación: Representación del funcionamiento de un sistema por

otro. Por ejemplo, la representación de un sistema físico por un
modelo matemático.

Sistema: Conjunto de elementos interrelacionados que trabajan

juntos para obtener un resultado deseado.

214
Sistema de Archivo: Un sistema de archivos consta de tipos de
datos abstractos, que son necesarios para el almacenamiento,
organización jerárquica, manipulación, navegación, acceso y
consulta de datos. La mayoría de los sistemas operativos poseen su
propio sistema de archivos. Los sistemas de archivos son
representados ya sea textual o gráficamente utilizando gestores de
archivos o shells. En modo gráfico a menudo son utilizadas las
metáforas de carpetas (directorios) conteniendo documentos,
archivos y otras carpetas. Un sistema de archivos es parte integral
de un sistema operativo moderno. Los sistemas de archivos más
comunes utilizan dispositivos de almacenamiento de datos que
permiten el acceso a los datos como una cadena de bloques de un
mismo tamaño, a veces llamados sectores, usualmente de 512 bytes
de longitud. El software del sistema de archivos es responsable de la
organización de estos sectores en archivos y directorios y mantiene
un registro de qué sectores pertenecen a qué archivos y cuáles no
han sido utilizados. En la realidad, un sistema de archivos no
requiere necesariamente de un dispositivo de almacenamiento de
datos, sino que puede ser utilizado también para acceder a datos
generados dinámicamente, como los recibidos a través de una
conexión de red

Sistema de manejo de base de datos: Software que maneja la

organización, localización, catalogación, almacenamiento,
recuperación y mantención de datos en una base de datos.

Sistema operativo: Programa de control que dirige el hardware de

una computadora. Por lo general es, en realidad, una colección de
programas que interactúan juntos.

Software: Programas escritos en un lenguaje que la computadora

entiende y puede ejecutar para realizar una tarea.

215
Software de aplicación: Programas que realizan las tareas
específicas de procesamiento de datos.

Tarea: Un camino simple de ejecución a través de un programa, un

modelo dinámico o alguna otra representación de un flujo de control;
un hilo o proceso.

Teleprocesamiento: Actividad que involucra funciones de

transmisión y procesamiento de datos. Los datos son recogidos en
uno o más puntos de origen transmitidos a una ubicación central,
procesados y sus resultados distribuídos a uno o más puntos de uso.

Terminal: Dispositivo en un sistema o red de comunicación en el

cual los datos pueden ingresarse o salir, pero no procesarse.

Terminal inteligente: Es una terminal con capacidad de

procesamiento en sí misma.

Testing: La prueba de un programa o un sistema para asegurar que

funciona adecuadamente.

Traza: Una dependencia que indica una relación histórica o de

proceso entre dos elementos que representan el mismo concepto,
sin reglas específicas para derivar una de la otra.

Unidad aritmético/lógica: Es la parte de un procesador que

contiene los circuitos que realizan las operaciones aritméticas y
lógicas.

216
Unidad central de procesamiento (CPU): La Unidad Central de
Proceso (UCP) o CPU (siglas de Central Processing Unit) es la
unidad donde se ejecutan las instrucciones de los programas y se
controla el funcionamiento de los distintos componentes de la
computadora. Suele estar integrada en un chip denominado
microprocesador.

Unidad de control: Es la parte de un procesador que efectúa la

recuperación apropiada, la interpretación de cada instrucción y la
aplicación de las señales necesarias para la unidad aritmética y
lógica y otras partes de la computadora.

USB: Tecnología de bus que permite conectar a la computadora

periféricos externos que requieran gran flujo de datos (como las
cámaras digitales). .

Ventana: Parte de la pantalla usada independientemente del resto.

Virtual: Se dice de la representación en una computadora de algo

que no tiene existencia de materia o no está presente en ese lugar.

Vista: Una proyección de un modelo, la cual es vista desde una

perspectiva determinada o punto estratégico y que omite las
entidades que no son relevantes para esta perspectiva.

Volumen: Entidad física utilizada para almacenar datos e

instrucciones. Puede ser cinta o un disco magnético.

Windows: Denominación genérica de la gama de sistemas

operativos de Microsoft® con prestaciones de GUI.

217
Z

Zip: Disco magnético removible que permite almacenar 100 ó 250

Mb de información, de gran estabilidad y duración.

Zip drive: Periférico de entrada/salida que maneja los discos Zip.

Posee comando remoto y gran velocidad de transferencia. Puede
ser externo (interfaces: serie, paralelo, SCSI o USB) o interno (EIDE
o SCSI).

218
BIBLIOGRAFIA.

BIBLIOGRAFÍA OBLIGATORIA:

- Material desarrollado por la cátedra de Análisis y Diseño de Sistemas -2016

- El Proceso Unificado de Desarrollo de Software. 2000.
Ivar Jacobson. Grady Booch. James Rumbaugh.
Pearson. Addison Wesley.
http://www.freelibros.org/programacion/el-proceso-unificado-de-desarrollo-
de-software-ivar-jacobson-grady-booch-james-rumbaugh.html

BIBLIOGRAFÍA DE CONSULTA:

- Análisis y Diseño de Sistemas de Información. 1992.

James A. Senn. Mc Graw-Hill.

- Análisis y Diseño Orientado a Objetos con aplicaciones. 1996.

Grady Booch.
Pearson. Addison Wesley. Longman.
http://www.fiuxy.com/ebooks-gratis/2652587-descargar-libro-analisis-y-
diseno-orientado-objetos-grady-booch.html

- El Lenguaje Unificado de Modelado. 1999.

Grady Booch. James Rumbaugh. Ivar Jacobson.
Pearson. Addison Wesley.
https://ingenieriasoftware2011.files.wordpress.com/2011/07/el-lenguaje-
unificado-de-modelado-manual-de-referencia.pdf

- UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al

proceso unificado. 2002.
Craig Larman.
Pearson. Prentice Hall.
http://www.ceneinnova.com/eddyesanchez/archivos/ads/UML%20y%20Patro
nes%20%202da%20Edicion.pdf

- Object oriented analisys & design. 2000.

Edward Yourdon.
Yourdon Press Optativa.

- Ingeniería de software; teoría y práctica. 2002.

Pfleeger, Shari Lawrence.
Pearson.

- Ingeniería del Software. Un Enfoque Práctico. 1998.

Pressman. Mc Graw-Hill.

219
- Sistemas de Información. Análisis. Diseño. Puesta a punto. 1987.
Henry C. Lucas, Jr. Editorial Paraninfo.

- Teoría de los Sistemas de Información. 1996.

Borje Langefors. Editorial El Ateneo.

- The Practical Guide to Structured Systems Design. 1988.

Meilir Page-Jones. Prentice-Hall International, Inc.

- Designinig objected-oriented software. 1990.

Wirfs. Brock, Rebecca.
Prentice – Hall.

- UML gota a gota. 1999.

Fowler, M.
Addison Wesley.
https://ingenieriasoftware2011.files.wordpress.com/2011/07/uml-gota-a-
gota.pdf

220
MODELO DE EXAMEN.
Enunciados:

1) En un colegio se necesita desarrollar un sistema para asistencia de

alumnos y de los profesores. El sistema usaría lectores ópticos para
registrar la entrada y salida de los profesores. La asistencia y llegadas de
de loa alumnos se registrarán por parte del preceptor ingresando el dato en
forma interactiva.

Si tuviera que implementar el flujo de trabajo de la captura de requisitos,

¿qué técnica de recopilación de datos usaría? Justifique su respuesta.

2) Mencione y aclare los tres conceptos que guían al Proceso Unificado de

Desarrollo. ¿Cuál cree que es el más importante? Justifique.

3) ¿Qué papel juegan los actores y los trabajadores en esta metodología?

4) Dado el siguiente caso de uso:

Preparar pollo
Cocinero al horno

Y teniendo en cuenta lo siguiente:

El pollo se prepara con sal, pimienta, ají, laurel, pimentón y romero.

El pollo se humecta con oliva.

Si el pollo supera los 3 kilos, se le coloca conservador en polvo.

Horno fuerte 50 – 60 minutos.

Agregar una generalización y una extensión. Explicar el uso de cada uno.

221
5) Para un sistema sencillo para manejo de datos de la asistencia de personal
de limpieza y seguridad de un edificio, definir los actores y sólo 3 items
de la lista de características involucrados en el mismo. Luego armar los
tres casos de uso que lo resuelvan. Finalmente, elegir un caso de uso y
armar las clases de análisis (entidad, interfaz de usuario o de control) que
apoyen al caso de uso a través de la realización del mismo.

Tener en cuenta para este sistema las siguientes restricciones:

El edificio necesita empleados de limpieza, los cuales cumplen dos turnos,

mañana y tarde. Los empleados de seguridad cumplen tres turnos mañana,
tarde y noche. Cada uno puede trabajar en uno o dos turnos, que se
establecen previamente.

Un supervisor carga los datos de los empleados, limpieza y seguridad y sus

horarios a cumplir; carga las distintas bandas horarias y los distintos
horarios de cada uno de los empleados.

Cada empleado debe registrar su horario de entrada y de salida.

Cada 15 días el supervisor controla la asistencia para la posterior
liquidación de sueldos.

222