Página 1

ANÁLISISDESISTEMAS

UNIDAD1

A. CICLO DE VIDA ESTRUCTURADO DEL PROYECTO

Dentro de un ciclo de vida estructurado existen nueve actividades y los tres

terminadores del ciclo de vida del proyecto. Los terminadores son los usuarios, los
administradores y el personal de operaciones, estos son individuos o grupos que
proporcionan las entradas al equipo del proyecto, y son los beneficiarios finales del
sistema, donde estos interactúan con las 9 actividades. Estas son:

1. LA ENCUESTA: También conocido como estudio de factibilidad o como el estudio

inicial de negocios, donde en este empieza cuando el usuario solicita que una o
más partes de su sistema se automaticen. Los principales objetivos de la encuesta
son:

- Identificar a los usuarios responsables y crear un “campo de actividad” inicial

del sistema
- Identificar las deficiencias actuales en el ambiente del usuario
- Establecer metas y objetivos para un sistema nuevo
- Determinar si es factible automatizar el sistema y de ser así, sugerir escenarios
aceptables, donde se llevaran a cabo estimaciones rudimentarias y aproximadas
del costo y el tiempo necesario para construir un sistema nuevo y los beneficios
que se derivarán de ello
- Preparar el sistema que se usará para guiar el resto del proyecto

2. EL ANÁLISIS DE SISTEMAS: El propósito principal de la actividad de análisis de

sistemas es transformar sus dos entradas principales, las políticas del usuario y el
esquema del proyecto en una especificación estructurada. Esto implica modelar el
ambiente del usuario con diagramas de flujo de datos, diagramas de entidad-
relación, diagramas de transición de estado, etc.
Como veremos, el proceso paso a paso implica el desarrollo de un modelo
ambiental y el desarrollo de un modelo de comportamiento. Estos dos modelos se
combinan para formar el modelo esencial que representa una descripción formal
de lo que el nuevo sistema debe hacer, independientemente de la naturaleza de
la tecnología que se use para cubrir los requerimientos

3. EL DISEÑO: Esta se dedica a asignar porciones de la especificación a

procesadores adecuados y a labores apropiadas dentro de cada procesador.
 Página 2

Dentro de cada labor, la actividad de diseño se dedica a la creación de una

jerarquía apropiada de módulos de programas y de interfaces entre ellos para
implantar la especificación proveniente del análisis del sistema

4. IMPLANTACIÓN: Esta actividad incluye la codificación y la integración de módulos

en un esqueleto más completo del sistema final. Por eso, esta actividad incluye
tanto programación estructurada como implantación descendente

5. GENERACIÓN DE PRUEBAS DE ACEPTACIÓN: La especificación estructurada debe

contener toda la información necesaria para definir un sistema que sea
aceptable desde el punto de vista del usuario. Por eso, una vez generada la
especificación, puede comenzar la actividad de producir un conjunto de casos de
prueba de aceptación desde la especificación estructurada

6. GARANTÍA DE CALIDAD: La garantía de calidad también se conoce como la prueba

final o la prueba de aceptación. Esta actividad generada en la actividad 5 y el
sistema integrado producido en la actividad 4

7. DESCRIPCIÓN DEL PROCEDIMIENTO: En esta actividad nos preocupamos por el

desarrollo de un sistema: no sólo de la porción automatizada, sino también de la
parte que llevarán a cabo las personas. Por ello, una de las actividades importantes
a realizar es la generación de una descripción formal de las partes del sistema que
se harán en forma manual, lo mismo que la descripción de cómo interactúan los
usuarios con la parte automatizada del nuevo sistema. El resultado de esta
actividad es un manual para el usuario

8. CONVERSIÓN DE BASES DE DATOS: En algunos proyectos, la conversión de bases

de datos involucraba más trabajo (y más planeación estratégica) que el desarrollo
de programas de computadora para el nuevo sistema. En esta actividad requiere
como entrada la base de datos actual del usuario, al igual que la especificación del
diseño producida por medio de la actividad de diseño

9. INSTALACIÓN: Esta es la actividad final, en donde, sus entradas son el manual del
usuario producido en la actividad 7, la base de datos creada en la actividad 8 y el
sistema aceptado por la actividad 6. En algunos casos, la instalación pudiera
significar simplemente un cambio de noche a la mañana al nuevo sistema ; en
otros casos, la instalación puede ser un proceso gradual, en el que
 Página 3

un grupo tras otro de usuarios van recibiendo manuales y entrenamiento y

comenzando a usar el nuevo sistema

GRÁFICO DEL CICLO DEL VIDA DEL PROYECTO ESTRUCTURADO

- IMPLANTACIÓN RADICAL CONTRA IMPLANTACIÓN DESCENDENTE CONSERVADORA

Se sabe que el ciclo de vida del proyecto estructurado permite que más de una
actividad se lleve a cabo a la vez. En una situación extrema, TODAS las actividades del
ciclo de vida pudieran estarse realizando simultáneamente. En el otro extremo, el
administrador del proyecto pudiera decidir adoptar el enfoque secuencial, que implica
terminar completamente una actividad antes de emprender la siguiente.

EL ENFOQUE RADICAL del ciclo de vida del proyecto estructurado es aquel en que las
actividades 1 a 9 se llevan a cabo paralelamente desde el principio del proyecto, por
ej. : La codificación se inicia el primer día del proyecto, y la encuesta y el análisis
continúan hasta el último

EL ENFOQUE CONSERVADOR del ciclo de vida del proyecto estructurado, la

actividad N completa se termina antes de comenzar con la actividad N + 1
 Página 4

Aquí la clave consiste en que los extremos radical y conservador definidos

anteriormente son los puntos extremos de una gama de opciones, donde existe un
infinito número de opciones entre estos. Un punto importante consiste en determinar
el porcentaje que ha de utilizar la administración para llevar a cabo el proyecto

Dicho esto, ¿qué factores se han de tener en cuenta para determinar el porcentaje de
cada uno?

* ¿Qué tan voluble es el usuario?

* ¿Bajo qué presión trabaja el equipo del proyecto para producir resultados
tangibles o inmediatos?
* ¿Bajo qué presión trabaja el administrador del proyecto para producir un
presupuesto, programa, y estimación de personas y otros recursos?
* ¿Cuáles son los peligros de cometer un error técnico importante?

Si el administrador de proyecto juzga que está tratando con un usuario voluble cuya
personalidad es tal que retrasa la toma de decisiones hasta que el sistema va a
funcionar, entonces probablemente optaría por un enfoque más radical. Por otro lado,
si el administrador trata con un usuario veterano que está absolutamente seguro de lo
que quiere, y si éste último trabaja en un área estable y con poca probabilidad de
cambiar radicalmente de un periodo de tiempo a otro, entonces el administrador
tomará un enfoque más conservador

Otro factor que se debe considerar es la presión a la que se está sometido para
producir resultados tangibles e inmediatos. Si debido a la que se está sometido a las
políticas u otras presiones externas, el equipo que realiza el proyecto debe concluirlo
forzosamente para una fecha determinada, entonces se requiere un enfoque un
enfoque un tanto radical.

Desde luego, todos los proyectos llegan a verse apremiados a llegar a resultados
tangibles donde una de las ventajas de hacer el análisis, diseño, codificación e
implantación del sistema en forma descendente es que se puede suspender una
actividad en cualquier momento y dejar los detalles restantes para consideraciones
posteriores
 Página 5

En la administración de proyectos se tienen que producir programas, estimaciones,

presupuestos, etc. En algunas organizaciones, esto suele hacerse de manera bastante
informal, normalmente porque los proyectos son normalmente pequeños. En cambio,
la mayoría de los proyectos requieren estimaciones relativamente detalladas de
necesidades de personal, recursos computacionales, etc., donde el proyecto tomará
un enfoque conservador

Finalmente, el administrador del proyecto debe considerar el peligro de cometer un

error técnico importante.

B. EL PROCESO

¿QUÉ ES?
Definimos un proceso de software como un marco de trabajo de las tareas que se
requieren para construir un software de alta calidad

¿QUIÉN LO HACE?
Los ingenieros de software y sus gestiones adoptarán el proceso a sus
necesidades y entonces lo siguen. Además las personas que han solicitado el
software tienen un papel a desempeñar en el proceso de software

¿POR QUÉ ES IMPORTANTE?

Porque proporciona estabilidad, control y organización a una actividad que
pueda, si no se controla, volverse caótica

¿CUÁLES SON LOS PASOS?

A un nivel detallado, el proceso que adoptemos depende del software que
estemos construyendo

¿CÚAL ES EL PRODUCTO OBTENIDO?

Los productos obtenidos son programas, documentos y datos que se producen
como consecuencia de las actividades de ingeniería de software definidas por el
proceso
 Página 6

¿CÓMO PUEDO ESTAR SEGURO DE QUE LO HE HECHO CORRECTAMENTE?

Hay una cantidad de mecanismos de evaluación del proceso del software que
permite a las organizaciones determinar la “madurez” de su proceso del software.
Sin embargo, la calidad, oportunidad y vialidad a largo plazo del producto que se
esté construyendo son los mejores indicadores de la eficiencia del proceso que
estemos utilizando

¿CÓMO DEFINIMOS LA INGENIERIA DE SOFTWARE?

La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el
desarrollo y mantenimiento del software

INGENIERIA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA

- Proceso, métodos y herramientas

La ingeniería del software es una tecnología multicapa, donde cualquier enfoque de

ingeniería debe apoyarse sobre un compromiso de organización de calidad

El fundamento de la ingeniería de software es la capa de proceso. El proceso de la

ingeniería de software es aquel en que se deben definir los marcos de trabajo para un
conjunto de ÁREAS CLAVE que se deben establecer para la entrega efectiva de la
tecnología de la ingeniería de software

Los MÉTODOS de la ingeniería de software indican “cómo” construir técnicamente el

software donde estos abarcan una gran cantidad de tareas que incluyen análisis de
requisitos, diseño, construcción de programas, pruebas y mantenimiento donde los
métodos de la ingeniería de software dependen de un conjunto de principios básicos
que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras
técnicas descriptivas

Las HERRAMIENTAS de la Ingeniería de software proporcionan un enfoque automático

o semi-automático para el proceso y para los métodos. Cuando se integran
herramientas para que la información creada por una herramienta la pueda utilizar
otra, se establece un sistema de soporte para el desarrollo de software llamado
Ingeniería del software asistido por computadora (CASE).

- UNA VISIÓN GENERAL DE LA INGENIERÍA DE SOFTWARE

 Página 7

La ingeniería es el análisis, diseño, construcción, verificación y gestión de entidades

técnicas (o sociales). Independientemente de la entidad a la que se va a aplicar la
ingeniería, se deben cuestionar y responder las siguientes preguntas:

* ¿Cuál es el problema a resolver?

* ¿Cuáles son las características de la entidad que se utiliza para resolver el
problema?
* ¿Cómo se realizará la entidad (y la solución)?
* ¿Cómo se construirá la entidad?
* ¿Qué enfoque se va a utilizar para no contemplar los errores que se
cometieron en el diseño y en la construcción de la entidad?
* ¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones en el
diseño, adaptaciones y mejoras en la entidad?

El trabajo que se asocia a la ingeniería de software se puede dividir en tres fases

genéricas con independencia del área de aplicación con independencia del área de
aplicación, tamaño o complejidad del proyecto

- La FASE DE DEFINICIÓN se centra sobre el qué. Es decir, durante la definición el

que desarrolla el software intenta identificar qué información ha de ser
procesada, que función y rendimiento se desea, que comportamiento del
sistema, que interfaces van a ser establecidas, etc.

- La FASE DE DESARROLLO se centra en el cómo. Es decir, durante el desarrollo

un ingeniero del software intenta definir cómo han de diseñarse las estructuras
de datos, como ha de implementarse la función dentro de una arquitectura de
software, cómo han de caracterizarse las interfaces, cómo ha de traducirse el
diseño a un lenguaje de programación

- La FASE DE MANTENIMIENTO se centra en el cambio que va asociado a la

corrección de errores, a las adaptaciones requeridas a medida que
evoluciona el entorno del software y a cambios debidos a las mejores
producidas por los requisitos cambiantes del sistema. Existen 4 tipos de
cambios en la fase de mantenimiento:
o Corrección: cambia el software para corregir los defectos
o Adaptación: produce modificaciones en el software para acomodarlas a
los cambios de su entorno
 Página 8

o Mejoras: Lleva el software más allá de sus requisitos funcionales

originales
o Prevención: permite que el software sirva para las necesidades de los
usuarios finales. Hace cambios en el programa para que se pueda
corregir, adaptar y mejorar más fácilmente

Algunos de los ejemplos son los asistentes técnicos a distancia, teléfonos de

ayuda, sitios de Web y aplicaciones específicas se implementen frecuentemente
como parte de la fase de mantenimiento

EL PROCESO DEL SOFTWARE

Se establece un marco común del proceso definiendo un pequeño número de

actividades del marco de trabajo que son aplicables a todos los proyectos del
software, con independencia de su tamaño o complejidad. Un número de conjunto de
tareas – cada uno es una colección de tareas de ingeniería del software, hitos del
proyecto, productos de trabajo, y puntos de garantía de calidad – que permiten que
las actividades del marco de trabajo se adapte a las características del proyecto y a los
requisitos del equipo del proyecto. Finalmente, las actividades de protección – tales
como garantía de calidad del software, gestión de configuración del software y
medición – abarcan el modelo de procesos. Las actividades de protección son
independientes de cualquier actividad del marco de trabajo y aparecen durante todo
el proceso.

El Software Engineering Institute (SEI) ha desarrollado un modelo completo que se basa

en un conjunto de funciones de ingeniería del software que deberían estar presentes
conforme organizaciones alcanzan diferentes niveles de madurez del proceso. Este
establece 5 niveles de madurez del proceso, que se definen así:

- Nivel 1 – Inicial: Se definen pocos procesos, y el éxito depende del esfuerzo

individual
- Nivel 2 – Repetible: Se establecen los procesos de gestión del proyecto para
hacer seguimiento del coste, de la planificación y de la funcionalidad
- Nivel 3 – Definición: El proceso del software de las actividades de gestión y de
ingeniería se documenta, se estandariza y se integra dentro de un proceso de
software de toda una organización. En este nivel se incluyen todas las
características definidas para el nivel 2
 Página 9

- Nivel 4 – Gestionado: Se recopilan medidas detalladas del proceso de

software y de la calidad del producto. Mediante la utilización de medidas
detalladas, se comprenden y se controlan cuantitativamente tanto los
productos como el proceso de software. En este nivel se incluyen todas las
características definidas para el nivel 3
- Nivel 5 – Optimización: Mediante una retroalimentación cuantitativa del
proceso, ideas y tecnologías innovadoras se posibilita una mejora del
proceso. En este nivel se incluyen todas las características definidas para el
nivel 4

Los cinco niveles definidos por el SEI se obtienen como consecuencia de evaluar las
respuestas del cuestionario de evaluación MCM (Modelo de capacidad de madurez)
donde el SEI ha asociado áreas claves del proceso (ACPs) a cada uno de los niveles de
madurez. Las ACPs describen esas funciones de la ingeniería del software que se
deben presentar para satisfacer para una buena práctica a un nivel en particular. Cada
ACP se describe identificando las características sgtes. :

- Objetivos: los objetivos globales que debe alcanzar la ACP

- Compromisos: requisitos que se deben cumplir para lograr los objetivos y
que proporcionan una prueba del intento por ajustarse a los objetivos
- Capacidades: aquellos elementos que deben encontrarse para permitir que la
organización cumpla los objetivos
- Actividades: las tareas específicas que se requieren para lograr la función
ACP
- Métodos para supervisar la implementación: la manera en que las actividades
son supervisados conforme se aplican
- Métodos para verificar la implementación: la forma en que se puede verificar la
práctica adecuada para la ACP

Las ACPs se deberían lograr en cada nivel de madurez del proceso: Nivel 2

de Madurez del Proceso

 Gestión de configuración del software

 Garantía de calidad del software
 Gestión del subcontratación del software
 Seguimiento y supervisión del proyecto del software
 Planeación del proyecto del software
 Página 10

 Gestión de requisitos

Nivel 3 de Madurez del Proceso

 Revisiones periódicas
 Coordinación entre grupos
 Ingeniería de productos de software
 Gestión de integración del software
 Programa de formación
 Definición del proceso de la organización
 Enfoque del proceso de la organización

Nivel 4 de Madurez del Proceso

 Gestión de calidad del software

 Gestión cualitativa del proceso

Nivel 5 de Madurez del Proceso

 Gestión de cambios del proceso

 Gestión de cambios de tecnología
 Prevención de defectos

MODELOS DE PROCESO DEL SOFTWARE

Para resolver los problemas reales se debe incorporar una estrategia de desarrollo que
acompañe al proceso, métodos y capas de herramientas, y las fases genéricas. Esta
estrategia a menudo se llama MODELO DE PROCESO O PARADIGMA DE INGENIERÍA
DEL SOFTWARE.

Todo el desarrollo del software se puede caracterizar como bucle de resolución de

problemas en el que se encuentran 4 etapas distintas: status quo, definición de
problemas, desarrollo técnico e integración de soluciones.
 Página 11

El status quo representa el estado actual de sucesos; la definición de problemas

identifica el problema específico a resolverse; el desarrollo resuelve el problema a
través de la aplicación de alguna tecnología y la integración de soluciones proporciona
los resultados.

Dada la naturaleza recursiva del desarrollo del software, las cuatro etapas tratadas
anteriormente se aplican igualmente al análisis de una aplicación completa y a la
generación de un pequeño segmento de código

MODELO LINEAL, SECUENCIAL

También llamado “ciclo de vida básico” o “modelo en cascada”, el MODELO LINEAL

sugiere un enfoque sistemático, secuencial, para el desarrollo del software que comienza
en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento

Ingeniería y modelado de Sistemas/Información

Como el software siempre forma parte de un sistema más grande (o empresa), el

trabajo comienza estableciendo requisitos de todos los elementos del sistema y
asignando al software algún subgrupo de estos requisitos. Esta visión del sistema es
esencial cuando el software se debe interconectar con otros elementos como el
hardware, personas y bases de datos

Análisis de los requisitos del software

El proceso de reunión de requisitos se intensifica y se centra especialmente en el

software. Para comprender la naturaleza del (los) programa(s) a construirse, el
ingeniero (analista) del software debe comprender el dominio de información del
software
 Página 12

Diseño

El diseño del software es realmente un proceso de muchos pasos que se centra en

cuatro atributos distintos de programa: estructura de datos, arquitectura de software,
representación de interfaz y detalle procedimental (algoritmo). El proceso de diseño
traduce requisitos en una representación del software donde se puede evaluar su
calidad antes de que comience la codificación

Generación de código

El diseño se debe traducir en una forma legible por la máquina. El paso de generación
de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la
generación de código se realiza mecánicamente

Pruebas

El proceso de pruebas se centra en los procesos lógicos internos del software, que
asegura que todas las secuencias se han comprobado, y en los procesos externos
funcionales, es decir, realizar las pruebas para la detección de errores y asegurar que
la entrada definida produce resultados reales de acuerdo con los resultados
requeridos

Mantenimiento

El software indudablemente sufrirá cambios después de ser entregado al cliente, o

porque al software se le han encontrado errores, o porque el software debe
adoptarse para acoplarse a los cambios de su entorno externo, o porque el cliente
requiere mejoras funcionales o de rendimiento

MODELO DE CONSTRUCCIÓN DE PROTOTIPOS

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero

no identifica los requisitos detallados de entrada, proceso o salida. En esta situación un
PARADIGMA DE CONSTRUCCIÓN DE CONSTRUCCIÓN DE
PROTOTIPOS puede ofrecer un mejor enfoque

El paradigma de construcción de prototipos comienza con la recolección de requisitos.

El desarrollador y el cliente encuentran y definen los objetivos globales para el
software, identifican los requisitos conocidos y las áreas del esquema en donde es
obligatoria más definición. Entonces aparece un “diseño rápido”. El diseño rápido se
centra en una representación de esos aspectos del software que serán
 Página 13

visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un

prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los
requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a
punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el
desarrollador comprenda mejor lo que se necesita hacer

Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los
requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta
hacer uso de los fragmentos del programa ya existente o aplica herramientas

MODELO DRA

El DESARROLLO RÁPIDO DE APLICACIONES (DRA) es un modelo de proceso del

desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo
extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” del
modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una
construcción basada en componentes. Si se comprenden bien los requisitos y se limita
el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un
“sistema completamente funcional” dentro de un periodo corto de tiempo. El
enfoque DRA comprende las siguientes fases:

- Modelado de gestión: El flujo de información entre las funciones de gestión se

modela de forma que responda a las sgtes. Preguntas: ¿Qué información
conduce el periodo de gestión?, ¿Qué información se genera?, ¿Quién la
genera?, ¿Quién la procesa?
- Modelado de Gestión: El flujo de información definida como parte de la fase de
modelado de gestión se define como un conjunto de objetos de datos
necesarios para apoyar la empresa. Se definen las características (llamados
atributos) de cada uno de los objetos y las relaciones entre estos objetos
- Modelado del proceso: Los objetos de datos definidos en la fase de
modelado de datos quedan transformados para lograr el flujo de
información necesario para implementar una función de gestión. Las
descripciones del proceso se crean para añadir, modificar, suprimir, o
recuperar un objeto de datos
- Generación de aplicaciones: En lugar de crear software con lenguajes de
programación de tercera generación, el proceso DRA trabaja para volver a
utilizar componentes de programas ya existentes (cuando es posible) o a
 Página 14

crear componentes reutilizables (cuando sea necesario). En todos los casos se

utilizan herramientas para facilitar la construcción del software
- Pruebas y entrega: Cuando el proceso DRA enfatiza la reutilización, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo
de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se
deben ejecutar todas las interfaces

MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE

Se reconoce que el software, al igual que todos los sistemas complejos, evoluciona con
el tiempo. Las estrictas fechas tope del mercado hacen que sea imposible finalizar un
producto completo, por lo que se debe introducir una versión limitada para cumplir la
presión competitiva y de gestión. En esta situación, los ingenieros de software
necesitan un modelo de proceso que se ha diseñado explícitamente para acomodarse
a un producto que evolucione con el tiempo

Características:

 Iterativo
 Interactivo
 Lineal Secuencial
 Desarrollan versiones cada vez más completas

- El modelo incremental

El MODELO INCREMENTAL es un MODELO OPERACIONAL que combina elementos del

modelo lineal secuencial con la filosofía iterativa de construcción de prototipos. El
modelo incremental aplica secuencias lineales de forma escalonada mientras progresa
el tiempo en el calendario.

Cuando se utiliza un modelo incremental, el primer incremento a menudo es un

producto esencial. Es decir, se afrontan requisitos básicos, pero muchas funciones
suplementarias quedan sin extraer. El cliente utiliza el producto central, como
resultado de la utilización y/o evaluación, se desarrolla un plan para el incremento
siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor
las necesidades del cliente y la entrega de funciones, y características adicionales. Este
proceso se repite siguiendo la entrega de cada incremento hasta que se elabora el
producto completo
 Página 15

El desarrollo incremental es particularmente útil cuando la dotación de personal no

está disponible para una implementación completa en la fecha límite que se haya
establecido para el proyecto, en donde los primeros incrementos se pueden
implementar con menos personal

- Modelo en espiral

El MODELO EN ESPIRAL es un MODELO NO OPERACIONAL de proceso de software

evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los
aspectos controlados y sistemáticos del modelo lineal secuencial. En el modelo en
espiral, el software se desarrolla en una serie de versiones incrementales, durante las
primeras iteraciones se producen versiones cada vez más completas del sistema
diseñado. El modelo en espiral se divide en un número de actividades de marco de
trabajo, también llamadas REGIONES DE TAREAS. Estas son:

 Comunicación con el cliente: las tareas requeridas para establecer

comunicación entre el desarrollador y el cliente
 Planificación: las tareas requeridas para definir recursos, el tiempo y otra
información relacionada con el proyecto
 Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y de
gestión
 Ingeniería: las tareas requeridas para construir una o más representaciones
de la aplicación
 Construcción y aplicación: las tareas requeridas para construir, probar,
instalar y proporcionar soporte al usuario
 Evaluación del cliente: las tareas requeridas para obtener la reacción del
cliente según la evaluación de las representaciones del software cerrados
durante la etapa de ingeniería e implementada durante la etapa de
instalación

Cada una de las regiones está compuesta por un conjunto de tareas del trabajo,
llamado CONJUNTO DE TAREAS, que se adaptan a las características del proyecto que se
va a emprenderse donde el número de tareas variará dependiendo del tamaño del
proyecto a emprender
 Página 16

FIG. Un modelo en espiral típico

- El modelo en espiral WINWIN

El modelo en espiral sugiere una actividad del marco del trabajo que aborda la
comunicación con el cliente. El objetivo de esta actividad es mostrar los requisitos del
cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que
se necesita y el cliente proporciona los detalles suficientes para continuar

Entre el desarrollador y el cliente se realizaran negociaciones en donde las mejores

negociaciones se esfuerzan por obtener “victoria-victoria”. Esto es, el cliente gana
obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el
desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de
entrega realista

Este modelo define un conjunto de actividades de negociación al principio de cada

paso alrededor de la espiral, que son las siguientes:

1. Identificación del sistema o subsistema clave para los directivos

2. Determinación de las “condiciones de victoria” de los directivos
3. Negociación de las condiciones de “victoria” de los directivos para reunirlas
en un conjunto de condiciones “victoria-victoria” para todos los afectados
(incluyendo el equipo del proyecto de software)

El modelo en espiral WINWIN introduce 3 hitos en el proceso llamados PUNTOS DE

FIJACIÓN, que ayudan a establecer la completitud de un ciclo alrededor de la espiral y
proporcionan hitos de decisión antes de continuar el proyecto de software. Los puntos
de fijación representan 3 visiones diferentes del progreso.

El primer punto de fijación llamado OBJETIVOS DEL CICLO DE VIDA define un conjunto
de objetivos para cada actividad principal de ingeniería del software. El segundo
punto de fijación llamado ARQUITECTURA DEL CICLO DE VIDA establece los objetivos
que se deben conocer mientras que se definen la arquitectura del software y el
sistema. LA CAPACIDAD OPERATIVA INICIAL es el tercer punto de fijación y representa
un conjunto de objetivos asociados a la preparación del software para la
instalación/distribución, preparación del lugar previamente a la instalación, y a la
asistencia precisa de todas las partes que utilizará o mantendrá el software
 Página 17

- El modelo de desarrollo concurrente

El modelo de proceso concurrente se puede representar en forma de esquema como

una serie de actividades técnicas importantes, tareas y estados asociados a ellas. En la
actividad “análisis”, por ejemplo, se puede encontrar en uno de los estados
destacados anteriormente en cualquier momento dado (figura). De forma similar,
otras actividades (por ejemplo: diseño o comunicación con el cliente) se pueden
representar de forma análoga. Este modelo define una serie de acontecimientos que
dispararán de estado a estado para cada una de las actividades de la ingeniería en
software.

Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones

cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de
componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso
concurrente define actividades en dos dimensiones: una dimensión de sistemas y una
dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante 3
actividades: DISEÑO, EMBALAJE Y USO. La dimensión de componentes se afronta con
dos actividades: DISEÑO Y REALIZACIÓN. La concurrencia se logra de dos formas: (1)
las actividades de sistemas y de componentes ocurren simultáneamente y pueden
modelarse con el enfoque orientado a objetos; (2) una aplicación cliente/servidor
típica se implementa con muchos componentes, cada uno de los cuales se pueden
diseñar y realizar concurrentemente.

- Desarrollo basado en componentes

El paradigma orientado a objetos enfatiza en la creación de clases que encapsulan

tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se
diseñan y se implementan adecuadamente, las clases orientadas a objetos son
reutilizables por las diferentes aplicaciones de sistemas basados en computadoras

El modelo de desarrollo basado en componentes incorpora muchas de las

características del modelo en espiral. Es evolutivo por naturaleza, y exige un enfoque
iterativo para la creación del software. Sin embargo, este modelo configura
aplicaciones desde componentes preparadas de software llamadas clases.
 Página 18

La actividad de la ingeniería comienza con la identificación de clases candidatas. Esto

se lleva a cabo examinando los datos que se van a manejar por parte de la aplicación y
el algoritmo que se va a aplicar para conseguir el tratamiento. Una vez identificadas
las clases candidatas, la biblioteca de clases se examina para determinar si estas clases
ya existen. En caso de que así fuera, extraen de la biblioteca y se vuelven a utilizar. Si
una clase candidata no existe en la biblioteca, se aplican los métodos aplicados a
objetos para poder crearla. El flujo de proceso vuelve a la espiral y volverá a introducir
por último la iteración ensambladora de componentes a través de la actividad de la
ingeniería.

Este modelo conduce a la reutilización del software, y la reutilización proporciona

beneficios a los ingenieros del software

- Modelo de Métodos Formales

Los métodos formales permiten que un ingeniero de software especifique, desarrolle y

verifique un sistema basado en computadora aplicando una notación rigurosa y
matemática

Cuando se utilizan métodos formales durante el desarrollo, proporcionan un

mecanismo para eliminar muchos de los problemas que son difíciles de superar con
paradigmas de la ingeniería del software. La ambigüedad, lo incompleto y la
inconsistencia se descubren y se corrigen más fácilmente. Cuando se utilizan métodos
formales durante el diseño sirven como base para la verificación y por consiguiente
permiten que el ingeniero del software descubra y corrija errores que no se pudieron
detectar de otra manera

- Técnicas de cuarta generación

El término técnicas de cuarta generación (T4G) abarca un amplio espectro de

herramientas de software que tienen algo en común: todos facilitan al ingeniero del
software la especificación de algunas características de software de alto nivel. Luego,
la herramienta genera automáticamente el código fuente basándose en la
especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el
nivel en el que se especifique el software, más rápido se podrá construir el programa.
Actualmente, un entorno para el desarrollo de software que soporte el
 Página 19

paradigma T4G puede incluir todas o algunas de las siguientes herramientas: lenguajes
no procedimentales de consulta a base de datos, generación de informes, manejo de
datos, generación de códigos, etc.

Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. El
cliente describe los requisitos, que son, a continuación, traducidos directamente a un
prototipo operativo

Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de

requisitos al paso de implementación, usando un lenguaje de cuarta generación no
procedimental (L4G) o un modelo comprimido de red de iconos gráficos. Sin embargo,
es necesario un mayor esfuerzo para desarrollar una estrategia de diseño para el
sistema, incluso si se utilizan un L4G. El uso de T4G sin diseño (para grandes proyectos)
causará las mismas dificultades que se encuentran cuando se desarrolla software
mediante los enfoques convencionales

Al igual que todos los paradigmas de software, el modelo T4G tiene ventajas e
inconvenientes. Los defensores aducen reducciones drásticas en el tiempo de
desarrollo del software y una mejora significativa en la productividad de la gente que
construye el software. Los detractores aducen que las herramientas actuales de T4G no
son más fáciles de utilizar que los lenguajes de programación, que el código fuente
producido por tales herramientas es “ineficiente” y que el mantenimiento de grandes
sistemas de software desarrollados mediante T4G es cuestionable

- Tecnologías de proceso

Las herramientas de tecnología de procesos permiten que una organización de

software construya un modelo automatizado del marco de trabajo común de procesos,
conjunto de tareas y actividades de protección. El modelo, comúnmente presentado
como una red, se puede analizar para determinar el flujo de trabajo típico y para
examinar alternativas de procesos que pudieran llevar a un tiempo o coste de
desarrollo reducidos

Una vez que se ha creado un proceso aceptable se puede utilizar otras herramientas
de tecnología de procesos para asignar, supervisar e incluso controlar todas la tareas
de ingeniería del software definidas como parte del modelo de proceso. Cada uno de
los miembros de un equipo de proyecto de software puede utilizar tales herramientas
para desarrollar una lista de control de tareas de trabajo a realizarse, productos de
trabajo a producirse, y a actividades de garantía de calidad a conducirse
 Página 20

EL PROCESO UNIFICADO: dirigido por casos de uso, centrado en la arquitectura,

iterativo e incremental

El problema del software (en todos sus aspectos) se reduce a la dificultad que
afrontan los desarrolladores para coordinar las múltiples cadenas de trabajo de un
gran proyecto de software. La comunidad de desarrolladores necesita una forma
coordinada de trabajar. Necesita un proceso que integre las múltiples facetas del
desarrollo, donde la presencia de un proceso bien definido y bien gestionado genera
una diferencia esencial entre los proyectos hiper-productivos y los que fracasan. Es
decir, necesitan un método en común, un proceso que:

 Proporcione una guía para ordenar las actividades de un equipo

 Dirija las tareas de cada 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 actividades
del proyecto

- El proceso unificado en pocas palabras

El proceso unificado en un proceso de desarrollo de software donde un PROCESO de

desarrollo de software es el conjunto de actividades necesarias para transformar los
requisitos de un usuario en un sistema software. Sin embargo, el Proceso Unificado es
más que un simple proceso; es un marco de trabajo genérico que puede especializarse
para una gran variedad de sistemas software, para diferentes, para diferentes áreas de
aplicación, diferentes tipos de organizaciones, etc.

El Proceso Unificado está basado en COMPONENTES, lo cual quiere decir que el sistema
software en construcción está formado por componentes software interconectados de
interfaces bien definidas

- El Proceso Unificado está dirigido por casos de uso

Un sistema software ve la luz para dar servicio a sus usuarios. Por tanto, para
construir un sistema con éxito debemos conocer lo que sus futuros usuarios
necesitan y desean. Esta interacción en un caso de uso.
 Página 21

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al

usuario un resultado importante. Los casos de uso representan los requisitos
fundamentales donde todos los casos de uso juntos constituyen el modelo de casos de
uso el cual describe la funcionalidad total del sistema. Sin embargo, los casos de uso no
sólo son una herramienta para especificar los requisitos de un sistema, también guían
su diseño, implementación, y prueba; esto es, GUÍAN EL PROCESO DE DESARROLLO.
Basándose, en el modelo de casos de uso, los desarrolladores crean una serie de
modelos de diseño e implementación que llevan a cabo los casos de uso. Los
desarrolladores revisan cada uno de los sucesivos modelos para que sean conformes a
modelo de casos de uso. DIRIGIDO POR CASOS DE USO quiere decir que el proceso de
desarrollo sigue un hilo – avanza a través de una serie de flujos de trabajo que parten
los casos de uso. Los casos de uso se especifican, se diseñan, y los casos de uso finales
son la fuente a partir de la cual los ingenieros de prueba construyen todos los casos de
uso posibles

- El Proceso Unificado está centrado en la arquitectura

El papel de la arquitectura software es parecido al papel que juega la arquitectura en la

construcción de edificios donde la arquitectura en un sistema software se describe
mediante diferentes vistas del sistema en construcción.

La arquitectura es una viste del diseño completo con las características más importantes
resaltadas, dejando los detalles de lado. Debido a que lo que es significativo depende de
una valoración, que a su vez, se adquiere con la experiencia donde el valor de una
arquitectura depende de las personas que se hayan responsabilizado de su creación. La
arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y
los inversores, y se refleja en los casos de uso. Sin embargo, esta también se ve influida
por muchos otros factores, como la plataforma en la que tiene que funcionar el
software (arquitectura hardware, sistema operativo, sistema de gestión, etc.)

¿Cómo se relacionan los casos de uso y la arquitectura? Ninguna es suficiente por sí

misma. Estas dos fuerzas deben equilibrarse para obtener un producto con éxito donde
la interacción entre estos dos es primordial. Por un lado, los casos de uso de deben
encajar en la arquitectura cuando se llevan a cabo, y por otro lado, la arquitectura debe
permitir el desarrollo de todos los casos de uso requeridos, ahora y en el futuro, por lo
que estos deberán evolucionar en paralelo

Las actividades principales de un arquitecto son:

 Página 22

 Crea un esquema en borrador de la arquitectura, comenzando por la parte de la

arquitectura que no es específica de los casos de uso. Aunque esta parte de la
arquitectura es independiente de los casos de uso, el arquitecto debe poseer una
comprensión general de los casos de uso antes de comenzar la creación del
esquema arquitectónico
 El arquitecto trabaja con un subconjunto de los casos de uso especificados, con
aquellos que representan las funciones claves del sistema en desarrollo. Cada caso
de uso seleccionado se especifica en detalle y se realiza en términos de
subsistemas y componentes
 A medida que los casos de uso se especifican y maduran, se descubre más de la
arquitectura. Esto, a su vez, lleva a la maduración de más casos de uso

- El Proceso Unificado es iterativo e incremental

El desarrollo de un producto software comercial supone un gran esfuerzo que puede

durar entre varios meses hasta posiblemente un año o más. Por lo que, es práctico dividir
el trabajo en partes más pequeñas o mini-proyectos. Cada mini-proyecto es una iteración
que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de
trabajo, y los incrementos, al crecimiento del producto

Los desarrolladores basan la selección de lo que se implementará en una iteración en dos

factores. En primer lugar, la iteración trata un grupo de casos de uso que juntos amplían
la utilidad del producto desarrollado hasta ahora. En segundo lugar, 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 uso y continúan a través del trabajo de desarrollo
subsiguiente –análisis, diseño, implementación y prueba- que termina convirtiendo en
código ejecutable los casos de uso que se desarrollaban en la iteración

En cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes,
crean un diseño utilizando la arquitectura seleccionada como guía, implementan el diseño
mediante componentes, y verifican que los componentes satisfacen los casos de uso. Si
una iteración cumple con los objetivos el desarrollo continúa con la siguiente iteración. En
caso contrario, los desarrolladores deben revisar sus decisiones previas y probar con un
nuevo enfoque
 Página 23

Beneficios de un proceso iterativo controlador:

 Esta reduce el coste de riesgo a los costes de un solo incremento. Si los

desarrolladores tienen que repetir la iteración, la organización sólo pierde el
esfuerzo mal empleado de la iteración, no el valor del producto entero
 Esta reduce el riesgo de no sacar al mercado el producto en el calendario previsto
mediante la identificación de riesgos en fases tempranas del desarrollo, el tiempo
que se gasta en resolverlos se emplea al principio de la planificación, cuando la
gente está menos presionada por cumplir los plazos
 Esta acelera el ritmo de esfuerzo de desarrollo en su totalidad debido a que los
desarrolladores trabajan de manera más eficiente para obtener resultados claros a
corto plazo, en lugar de tener un calendario, que se prolonga eternamente
 Esta reconoce una realidad que a menudo se ignora, que las necesidades del
usuario y sus correspondientes requisitos no pueden definirse completamente al
principio

- La vida del Proceso Unificado

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de
un sistema, como se muestra en la figura. Cada ciclo concluye con una versión del
producto para los clientes

Cada ciclo consta de 4 fases: inicio, elaboración, construcción y transmisión. Cada fase se
subdivide a su vez en iteraciones, como se ha dicho anteriormente
 Página 24

- El Producto

Cada ciclo produce una nueva versión del sistema, y cada versión es un producto
terminado preparado para su entrega. Consta de un cuerpo de código fuente incluido en
componentes que pueden compilarse y ejecutarse. Sin embargo, el producto terminado
no sólo debe ajustarse a las necesidades de los usuarios, sino también a las de todos los
interesados, es decir, toda la gente que trabajará con el producto

El producto terminado incluye los requisitos, casos de uso, especificaciones no

funcionales y casos de prueba. Incluye tanto la arquitectura y el modelo visual como
clientes, usuarios, analistas, diseñadores, programadores, ingenieros de prueba y
directores, que permiten especificar, diseñar, implementar, probar y utilizar un sistema

Aunque los componentes ejecutables sean los artefactos más importantes desde la
perspectiva del usuario, no son suficientes por sí solos. Esto se debe a que el entorno
cambia. A medida que el objetivo del sistema se comprende mejor, los propios
requisitos pueden cambiar. De hecho, el que los requisitos cambien es una de las
constantes del desarrollo de software. Para llevar a cabo el siguiente ciclo de manera
eficiente, los desarrolladores necesitan todas las representaciones del producto
software
 Página 25

 Un modelo de casos de uso, con todos los casos de uso y su relación con los
usuarios
 Un modelo de análisis, con dos propósitos: refinar los casos de uso con más
detalle y establecer la asignación inicial de funcionalidad del sistema a un
conjunto de objetos que proporciona el comportamiento
 Un modelo de diseño que define: (a) la estructura estática del sistema en la forma
de subsistemas, clases e interfaces y (b) los casos de uso reflejados como
colaboraciones entre los subsistemas, clases, e interfaces
 Un modelo de implementación que incluye componentes (que representan al
código fuente) y la correspondencia de las clases con los componentes
 Un modelo de despliegue, que define los nodos físicos (ordenadores) y la
correspondencia de los componentes con esos nodos
 Un modelo de prueba, que describe los casos de prueba que verifican los casos
de uso
 Una representación de la arquitectura

ESTRATEGIAS

Esta se defina como un plan para lograr un objetivo. Las estrategias afectan a aspectos
como la arquitectura del sistema, el orden en que se llevaran a cabo las actividades del
proceso y las metodologías a utilizarse. Dada la variedad de probabilidades, es necesario
tomar ciertas decisiones iniciales correspondientes a tipo de proyecto a desarrollase.
Estas decisiones son parte de una estrategia de desarrollo, la cual incluye la selección de
una tecnología y lenguaje de programación particular. Otras estrategias aceptadas en la
actualidad son los prototipos y la reutilización.

PROTOTIPOS

Un prototipo es una versión preliminar, intencionalmente incompleta o reducida de un

sistema. El uso de prototipos es una estrategia que puede aplicarse en casi todas las
actividades del proceso de software. El propósito de los prototipos es obtener
rápidamente la información necesaria para ayudar en la toma de decisiones. Algunos de
ellos son:
 Página 26

a. Prototipos de Requisitos: Este permite que los usuarios perciban la

funcionalidad del producto final a través del diseño de interfaces o
pantallas del sistema. El objetivos es ayudar a aclarar los requisitos y
solicitar nuevas ideas
b. Prototipos de análisis: Este hace posible generar rápidamente una
arquitectura general que considere las características principales del
sistema de acuerdo a la especificación de los requisitos
c. Prototipos de diseño: Este permite explorar y comprender la arquitectura
particular del sistema, para poder evaluar aspectos como cuellos de botella
(rendimiento y uso de memoria) o inconsistencias en el diseño
d. Prototipos verticales: Este ayuda a comprender parte de un problema y
desarrollar su solución completa. Esto se hace generalmente cuando los
conceptos básicos no están bien comprendidos, por ejemplo, el
seguimiento de cierta metodología
e. Prototipos de factibilidad: Este demuestra si es posible lograr ciertos
objetivos del proyecto; por ejemplo, aplicar una arquitectura particular,
conectarse a una base de datos bajo ciertas restricciones de rendimiento,
aprender a programar en un lenguaje en un tiempo determinado o predecir
los costos de desarrollo de un proyecto

Los prototipos tienen éxito cuando:

 Se tiene claro el propósito del prototipo y se usa de manera adecuada

 Se comprende la tecnología a utilizarse y su relación con el proceso de
prototipos
 Se integra en un grupo de trabajo apropiado para hacer el prototipo
 Se evalúa el grupo y las entregas finales
 Se involucra a tiempo en el proceso a los usuarios finales
 Se repite el proceso de prototipos para comprender mejor la arquitectura
básica
 Se establecen criterios de evaluación apropiados al comienzo de cada etapa de
prototipos
 Se construyen prototipos basados en una biblioteca de código reusable

Los prototipos fallan cuando:

 No se entiende que es un prototipo y como debe usarse

 Página 27

 No se comprende el proceso lo suficientemente bien como para organizar al

grupo correctamente
 No se sabe hasta cuándo dejar de evolucionar el prototipo y comenzar de
cero, extendiendo demasiado el proyecto
 No se utilizan ambientes o herramientas de apoyo adecuados para el
desarrollo particular
 Se cree que un prototipo razonable es un producto aceptable
 Los prototipos nunca terminan

REUTILIZACIÓN

La reutilización es la explotación de componentes desarrollados anteriormente dentro

de un mismo proyecto e entre proyectos. En un mismo proyecto, la reutilización se
aprovecha mediante estructuras comunes de bajo nivel, como procedimientos, clases
o herencias. Este tipo de reutilización produce generalmente programas más
compactos. Entre proyectos, la reutilización se aprovecha mediante estructuras
comunes de alto nivel como paquetes gráficos y biblioteca de análisis numérico

 Consumo de componentes reutilizables: consumir componentes reutilizables

requiere identificar si ya existe una solución disponible parcial o completa. Las
ventajas de la reutilización incluyen soluciones consistentes entre aplicaciones y
mejoras en la calidad del componente al haber sido probado anteriormente en
múltiples aplicaciones. Para tener éxito con la reutilización, la solución debe
adaptarse a las necesidades del sistema
 Producción de componentes reutilizables: producir componentes reutilizables
significa tener una perspectiva de múltiples proyectos. Generalmente, el
esfuerzo para producir componentes reutilizables es bastante mayor al esfuerzo
de desarrollo de componentes normales

La reutilización es valiosa cuando:

 Se desea apoyar lo común

 Se desea promover la consistencia mediante estándares
 Se desea reducir costos
 Se desea facilitar el inicio del desarrollo
 Se desea acelerar el tiempo de entrega
 Página 28

 Se desea mejorar la calidad del producto

La reutilización no es valiosa cuando:

 Se tienen que ajustar los componentes para satisfacer los requisitos de

rendimiento
 Se tiene que ajustar el tiempo de aprendizaje para consumir y producir
componentes reutilizables a los tiempos del proyecto
 Se tienen que ajustar haciendo demasiados cambios
 Se provee exceso de funcionalidad
 Los componentes son propiedad de un proyecto específico
 Los componentes incluyen demasiada funcionalidad no requerida
 No disminuye la cantidad de código a ser probada

HERRAMIENTAS

Las herramientas son aplicaciones que apoyan la administración del proceso de

software. El conjunto de estas herramientas se conoce como Ingeniería de software
asistida por computadora (CASE), cuyo objetivo es asistir al desarrollador durante las
diferentes actividades del ciclo de vida del proceso de software. Las herramientas
varian en su apoyo a los procesos integrando componentes como editores de texto,
generadores de modelos gráficos (diagramas), generadores de código, compiladores,
depuradores, etc. La selección de estas herramientas debe considerar el apoyo a las
metodologías utilizadas:

 Proveer apoyo explicito para cada paso del método

 Administrar toda la información que el método requiere obtener o especificar
 Permite manejar grandes cantidades de información y ser escalable
 Incluir un mecanismo que permite probar que la información recolectada es
consistente
 Apoyar la organización de los diagramas de manera automática
 Permitir usuarios simultáneos en uno o más proyectos
 Poder generar una implementación inicial junto con la documentación
 Apoyar la ingeniería en reversa para asegurar que los cambios directos en la
implementación sean consistentes con los modelos administrados

UNIDAD II USUARIOS
 Página 29

El usuario es aquél (o aquellos) para quien se construye el sistema. Es la persona a la

que tendrá que entrevistar, a menudo con gran detalle, a fin de conocer las características que
deberá tener el nuevo sistema para tener éxito.

En la mayoría de los casos, es fácil identificar al usuario (o usuarios): de manera característica,

es aquel que solicita el sistema, sin embargo hay un gran número de situaciones en las que no
se conoce la identidad del verdadero usuario o bien en las que hay poca oportunidad de que
este interactúe con el analista, un ejemplo muy común de esto es el de un sistema en proceso
de ser desarrollado por un negocio de consultora o por una compañía de software

Obviamente, en situaciones de este tipo, hay una gran posibilidad de males entendidos; lo que
le usuario quiere que el sistema haga pudiera no serle comunicado de manera correcta al
analista, y lo que este crea que está construyendo para el usuario pudiera no serle comunicado
tampoco de manera correcta, hasta que ya se hubiera terminad, cuando ya sería demasiado
tarde. De esto se pueden sacar 2 conclusiones importantes:

- Siempre que sea posible, el analista debiera tratar de establecer contacto directo
con el usuario. Aun si se encuentran involucradas otras personas como
intermediarios

- Si no es posible comunicarse directamente con el usuario, la documentación

generada por el analista se vuelve aún más importante

Uno de los errores más frecuentes que cometen en el campo de las computadoras sobre todo
los programadores y a veces también hay analistas, es suponer que todos los usuarios son
iguales. Aún cuando sea obvio deberá intervenir más de un usuario, se tiene la tendencia a
pensar en ellos como un grupo de humanos amorfo y homogéneo

Decir simplemente que un usuario difiere de otro es insuficiente. Por lo que aquí hay dos
maneras de clasificar a los usuarios:

- Por categoría de trabajo o nivel de supervisión

- Por nivel de experiencia en el procesamiento de datos

 Clasificación de los usuarios por categoría de trabajo

En un proyecto típico de análisis de sistemas se pasará una considerable cantidad de

tiempo entrevistando a los usuarios para determinar los requerimientos del sistema. Sin
embargo, habitualmente tendrá que interactuar con individuos de tres categorías de
trabajo: usuarios operacionales, usuarios supervisores y usuarios ejecutivos

LOS USUARIOS OPERACIONALES son oficinistas, administradores y operadores que son los
que probablemente tendrán contacto diario con el nuevo sistema (a menos que esté
 Página 30

construyendo un sistema de apoyo a las decisiones, en cuyo caso tendrá poco contacto con
este grupo). Se debe tener tres cosas en mente cuando se trabaja con usuarios de nivel
operacional:

1. Los usuarios de este nivel se preocupan mucho por las funciones que tendrá el
sistema, pero es más probable aún que se preocupe por los detalles de la interfaz
humana. Esto significa que, como analista, necesitará tener comunicación directa
con el usuario operacional o, estar muy seguro de que la persona que representa a
éste tenga presente tales detalles

2. Los usuarios operacionales tienden a poseer un panorama ¨local¨ del sistema;

por lo general son conocedores del trabajo especifica que hacen y de las
personas con las que tiene comunicación directa, lo que implica una dificultad
por parte de estos usuarios a la hora de ver la interrelación de las actividades
dentro de la organización, por lo que el analista deberá generar modelos de
sistemas que permitan que ambos panoramas (descripciones de las partes del
sistema) y descripciones globales (panoramas de alto nivel del sistema entero
que evitan caer en detalles) funcionen correctamente

3. Los usuarios operacionales suelen pensar en los sistemas en términos físicos, es

decir, en términos de puesta en practica que será mejor para implantar o hacer
uso del sistema. Aquí, el analista de sistema pudiera requerir hablar con el
usuario exclusivamente en términos familiares. Luego, podrá traducir esta
descripción física a un ¨modelo esencial¨, es decir, a un modelo de lo que lo el
sistema debe hacer independientemente de la tecnología a emplear

LOS USUARIOS SUPERVISORES son, usualmente, aquellos que administran a un grupo de

usuarios operacionales y son responsables de sus logros. Lo importante acerca de los usuarios
supervisores es que:

 Muchos de ellos son usuarios operacionales que han sido promovidos. Por eso,
están familiarizados con el trabajo de los subordinados operacionales y se puede
suponer que estarán de acuerdo con sus necesidades, preocupaciones y
perspectivas
 También, a menudo se interesa en un nuevo sistema de información por la
posibilidad de incrementar el volumen de trabajo realizado disminuyendo a la vez el
costo de procesar transacciones y reduciendo también los errores en el trabajo
 Por lo general, el usuario supervisor es el que ve al nuevo sistema como una forma
de reducir el número de usuarios operacionales o de evitar que aumente se número al
crecer el volumen de trabajo
 Página 31

 El usuario supervisor a menudo piensa en los mismos términos físicos que el

operacional, y su perspectiva a menudo resulta tan local como la de este último
 Finalmente, será el usuario supervisor con quien usted tendrá el contacto cotidiano
primario. Es el que definirá los requerimientos y las políticas de la empresa que su
sistema deberá realizar

LOS USUARIOS DE NIVEL EJECUTIVO, en general, no se involucran directamente con el

proyecto de desarrollo de sistema. Sin embargo, para un proyecto normal, el usuario
ejecutivo suele estar dos o tres novelos arriba de la acción asociada con el proyecto.
Algunas de las características de estos son:

 Pueden proporcionar la iniciativa del proyecto, pero es más probable que sirvan
como autoridad para financiar las solicitudes que se originan en niveles más bajos
de la organización

 Los usuarios ejecutivos se preocupan más por los detalles estratégicos y las
ganancias/pérdidas a largo plazo. De aquí que, por lo regular, estén menos
interesados en asuntos operacionales

 Los usuarios de nivel ejecutivo se interesan más en el panorama global del sistema,
por lo que suelen no interesarse por los detalles. Por lo que el analista deberá utilizar
las herramientas de modelado que permiten dar un panorama global de sistemas

 Similarmente, los usuarios ejecutivos por lo general pueden trabajar con modelos
abstractos de un sistema

CARACTERISTICAS DE LOS DIFERENTES USUARIOS

Usuario operacional Usuario supervisor Usuario ejecutivo

- Usualmente tienen un - Puede o no tener un - Tiene un panorama global
panorama local panorama local - Provee la iniciativa para el proyecto
- Hace funcionar el sistema - Generalmente están - No tiene experiencia operacional
 Página 32

- Tiene una visión física del familiarizados con la operación directa

sistema - Los rigen consideraciones - Tiene preocupaciones estratégicas
presupuestales
- Actúa a menudo como
intermediario entre los usuarios
y los niveles superiores de
administración

 Clasificación de los usuarios en categorías por nivel de experiencia

Actualmente se pueden diferenciar entre amateurs, novatos presuntuosos y un pequeño

grupo de verdaderos expertos

EL AMATEUR es aquél que jamás ha visto una computadora y que exclama a todo pulmón y
con frecuencia que él “no entiende todo este asunto de las computadoras”. Esto presenta
un reto para el análisis de sistemas al que le encanta hablar del “acceso de línea” y los
“diálogos hombre-máquina dirigidos por menús” y terminologías por el estilo. Pero si el
analista hace bien su trabajo, no hay razón por la cual el usuario deba interesarse por las
computadoras o tener grandes cono conocimientos acerca de ellas.

En realidad, el verdadero problema con el usuario amateur es un tanto más sutil: puede
ser que encuentre difícil de entender el “lenguaje” que el analista usa para describir las
características, funciones y opciones que ofrece el sistema que se va a implantar

Un segundo tipo de usuarios es aquél que pudiéramos llamar EL NOVATO PRESUNTUOSO; es

una persona que ha tenido que ver con uno o dos proyectos de desarrollo de sistemas o es un
usuario que posee una computadora personal y que ha escrito algunos programas en algún
lenguaje de programación

Desde luego, hay algunos usuarios que realmente entienden el análisis de sistemas, y también
la tecnología de computadoras. Es un placer trabajar con tales personas; de hecho, el único
problema pudiera ser que el usuario y el analista obtengan tal placer de la discusión sobre
herramientas y técnicas de análisis, que se olviden por completo de que verdadero objetivo es
implantar un sistema

ADMINISTRACIÓN

Existen diversos tipos de administradores:

 Página 33

 Administradores usuarios: son administradores que están a cargo de varias personas en

el área operacional donde se va a implementar el nuevo sistema. Por lo general, son
administradores de nivel medio que desean sistemas que produzcan una variedad de
informes internos y de análisis a corto plazo

 Administradores de informática: son las personas encargadas del proyecto en sí de

sistemas. Están encargados de la administración global y distribución de los recursos
de todo el personal técnico de la organización de creación y desarrollo de sistemas

 Administración General: son los administradores de nivel superior que no están

directamente involucrados con la organización de informática ni con la organización
usuario. Generalmente se interesan más bien por los sistemas de planeación
estratégica y de apoyo a decisiones. Estos se concentran más en la información
externa, reglas gubernamentales, informes de la competencia por el mercado,
informes sobre nuevos productos y mercados, etc.

La principal interacción entre el analista de sistemas y todos administradores tienen que

ver con los recursos que se asignarán al proyecto. Es tarea del analista identificar y
documentar los requerimientos del usuario y las limitaciones dentro de las cuales se
tendrá que implantar el sistema

Puntos a tener en cuenta acerca de los administradores:

- Cuanto más alto nivel ocupen menos probable es que sepan de la tecnología de las
computadoras.

- Las metas y prioridades de la administración pudieran entrar en conflicto con las

de los usuarios, sobre todo las de los usuarios operacionales y los usuarios
supervisores. La administración pudiera incluso querer imponerles un sistema y
obligarlos a usarlo

- Los administradores tiene diferentes puntos de vista y opiniones, y a menudo

tienen diferentes metas y objetivos, donde a partir de esas diferencias surgen las
discusiones y competencias unos con otros

- También es cómodo suponer que una vez que la administración toma una decisión
colectiva acerca de un determinado proyecto se atiene a dicha decisión. Sin
embargo, no necesariamente sucede así: pudiera ser que fuerzas externas obliguen
a la administración a acelerar determinado proyecto, a quitarle recursos o, de plano
abandonarlo
 Página 34

 AUDITORES, CONTROL DE CALIDAD Y DEPARTAMENTO DE NORMAS O

ESTÁNDARES.

Dependiendo de la dimensión del proyecto y la naturaleza de la organización pueden

existir auditores, personal de control de calidad y miembros del departamento de
normas o estándares participando en el proyecto. Se agrupa a este grupo de personas
en una misma categoría ya que sus objetivos se parecen sino es que son iguales.

El objetivo general de esta categoría es asegurar que su sistema se desarrolle de acuerdo

con diversos estándares o normas externos (al proyecto): estándares de contabilidad
desarrollados por la agencia contable de su organización, estándares desarrollados por
otros departamentos de su organización o por el usuario que va a recibir su sistema; y
posiblemente estándares impuestos por diversas dependencias gubernamentales
reguladoras.

 EL ANALISTA DE SISTEMAS.

Es el personaje clave en cualquier proyecto de desarrollo de sistemas, y en otras partes

de este. El analista desempeña varios papeles:

- Arqueólogo y escribano: Una de sus principales labores es descubrir detalles y

documentar la política de un negocio que pudiera existir sólo como "tradiciones
tribales" transmitidas de generación en generación por los usuarios.

- Innovador: El analista debe distinguir entre síntomas, problemas del usuario y causas:
con sus conocimientos el analista debe ayudar al usuario a explorar aplicaciones
novedosas y más útiles de las computadoras así como nuevas formas de hacer
negocios.

- Mediador: Su labor primordial es obtener un consenso entre usuarios,

administradores, programadores, auditores y otros participantes, los cuales
frecuentemente están en desacuerdo entre sí; para ello, el analista requiere de
diplomacia y saber llevar una negociación.

- Jefe de proyectos: Hay una tendencia de asignar al analista las responsabilidades de

una administración integra, ya que este suele tener más experiencia que los
programadores que trabajan en el proyecto.
-
 DISEÑADORES DE SISTEMAS.
 Página 35

El diseñador de sistemas es el que recibe los resultados del trabajo de análisis realizado
por el analista. Su labor es transformar la petición, libre de consideraciones de
tecnología, que surge de los requerimientos del usuario, en un diseño arquitectónico de
alto nivel que servirá de base para el trabajo de los programadores.

En muchos casos, el analista y el diseñador son la misma persona o el mismo grupo

unificado de personas. Aún cuando sean personas distintas, es importante que se
mantengan en contacto directo a lo largo del proyecto, razón por la cual se necesita
esta RETROALIMENTACIÓN CONTINUA entre el diseñador y el analista

 PROGRAMADORES.

El trabajo de programador suele comenzar cuando termina el trabajo del analista. Son
aquellos que "accionan" el sistema desarrollado por el analista y el diseñador en
conjunto con el usuario.

Su contacto con el usuario es reducido, el cual sólo surge cuando el mismo requiere
especificaciones de bajo nivel, las cuales el analista no suele describir de manera
detallada.

 PERSONAL DE OPERACIONES

Es responsable del centro de cómputo, la red de telecomunicaciones, la seguridad del

hardware y del software, además de la ejecución de los programas, el montaje de los
discos y el manejo de la salida de las impresoras.

ENTREVISTAS UNIDAD 3

TIPO DE INFORMACIÓN BUSCADA

Una entrevista para recolección de información es una conversación dirigida con un
propósito específico que usa un formato de preguntas y respuestas. En la entrevista se
quiere obtener la opinión del entrevistado y sus sentimientos acerca del estado actual del

sistema, los objetivos de la organización, los personales y los procedimientos informales

Además de las opiniones, se debe tratar de capturar los sentimientos del entrevistado.
Recuerde que el entrevistado conoce la organización mejor que usted. Usted puede
comprender la cultura de la organización más a fondo escuchando los sentimientos de

quienes responden
Los objetivos son información importante que puede ser recogida de las entrevistas. Los

hechos que se obtienen de los datos relevantes pueden explicar el desempeño pasado,
 Página 36

pero
comolos
seaobjetivos
posible aproyectan el futuro
partir de las de la organización. Trate de encontrar tanto objetivos
entrevistas

PLANEACIÓN DE LA ENTREVISTA

Cinco pasos en la preparación de la entrevista

1. LECTURA DE MATERIAL DE FONDO: Lea y comprenda tanta información de fondo
como sea posible acerca del entrevistado y su organización como le sea posible.
Conforme lea este material, sensibilícese particularmente con el lenguaje que usan
los miembros de la organización. Lo que está tratando de hacer es construir un
vocabulario común, que eventualmente le permitirá redactar las preguntas de la

entrevista en una forma que sea comprensible para el entrevistado

2. ESTABLECIMIENTO DE LOS OBJETIVOS DE LA ENTREVISTA: Use la información de
fondo que recopiló, así como su propia experiencia, para establecer los objetivos
de la entrevista. Debe haber de cuatro a seis áreas principales que se relacionan
con el procesamiento de información y con el comportamiento para la toma de

decisiones acerca de las cuales querrá hacer preguntas. Estas áreas incluyen:
a. Fuentes de información
b. Frecuencia de la toma de decisiones
c. Cualidades de la información
d. Estilo de la toma de decisiones
3. PREPARE AL ENTREVISTADO: Prepare a la persona a ser entrevistada, llamándole
con anticipación y permitiendo que el entrevistado tenga tiempo para pensar
acerca de la entrevista. Acomode tiempo para llamadas telefónicas y reuniones. Las

entrevistas deben durar de 45 minutos a una hora a lo mucho

4. DECIDA SOBRE TIPOS DE PREGUNTAS Y ESTRUCTURAS: Escriba preguntas para
tratar las áreas principales de la toma de decisiones descubiertas cuando se
averiguaron los objetivos de la entrevista. Las técnicas adecuadas de
cuestionamiento son el corazón de la entrevista. Las preguntas tienen formas

básicas que es necesario saber. Los dos tipo de preguntas son abiertas y cerradas

Tipos de preguntas

PREGUNTAS ABIERTAS
“Abierta” describe, de hecho, las opciones del entrevistado para responder. La respuesta

pueden ser 2 o más palabras o párrafos. Los beneficios de usar preguntas abiertas son:
 Pone confortable al entrevistado
 Proporciona riqueza de detalles
 Revela cambios para preguntas posteriores que podrían haber quedado sin atacar

 Hace que sea más interesante para el entrevistado

 Página 37

Y sus desventajas son:

 El hacer preguntas que puedan dar como resultado mucho detalle
 La posibilidad de perder el control de la entrevista
 El permitir respuestas que pueden llevarse demasiado tiempo para la cantidad de

información útil obtenida

PREGUNTAS CERRADAS
Las preguntas cerradas, que tienen la forma básica “¿Qué tantos subordinados tienen? Las
respuestas están cerradas al entrevistado, debido a que solamente puede responder con

un número finito, donde estas limitan las respuestas disponibles del entrevistado

Los beneficios de usar preguntas cerradas de cualquier tipo son:

 Se ahorra tiempo
 Se facilita la comparación de los entrevistados
 Se llega al punto
 Se mantiene control sobre la entrevista

 Se tratan muchos temas rápidamente

Sin embargo, las desventajas del uso de preguntas cerradas son sustanciales. Incluyen:
 Ser aburridas para el entrevistado
 No llegan a obtener grandes detalles
 Se pierde ideal principales por la razón anterior
 No se llega a establecer una relación armoniosa entre el entrevistado y el

entrevistador

AVERIGUACIONES.
es la más simple ¿PorUn qué?
tercer tipo de pregunta es la “averiguación”. La averiguación más fuerte
El objetivo
para de la
aclararlo averiguación
y para obtener es ir más allá de la respuesta inicial para obtener más significado,
pueden ser preguntas abiertasy oexpandir
cerradasel punto de vista del entrevistado. Las averiguaciones
Si se hace
signo en se
de que unaestá
forma sistemática
escuchando y determinada,
lodonde
que seen
está la averiguación
diciendo, pensándoloserá reconocida como
cuidadosamente y un
respondiendo
investigador”, adecuadamente,
deberá averiguar en
en una forma vez
quedeexhiba
usar un
su enfoque
interés y“reportero-
deseo de comprender
las respuestas del entrevistado

FALLAS ENpregunta
cualquier LAS PREGUNTAS. Redactando sus preguntas de antemano será capaz de corregir
pueden arruinar lostonta
datosque haya escrito. Busque tipos de preguntas problemáticas que
 Página 38

 Elusión deque
respuesta preguntas
unotipo conducentes:
parece querer. LaEstas tienden
respuesta es aentonces
dirigir alsugerida,
entrevistado hacia
debido la
a que
está poniendo un de trampa
 Elusión
que de preguntas
de hecho dobles:
son dosque Son separadas.
preguntas aquellas enUna
las que se usa doble
problema una sola pregunta
es una para lo
alternativa
propósito odebido
no) o sea puede
el entrevistado
caer en errorpuede responder
sobre el solamente
cual pregunta unamala
pregunta y(a
está respondiendo
sacar una conclusión equivocada

ACOMODO DE LAS PREGUNTAS EN UNA SECUENCIA LOGICA. Así como hay dos formas
reconocidas generalmente para razonar: inductiva y deductiva, hay dos formas similares

para organizar las entrevistas.

 USO DE UNA ESTRUCTURA DE PIRÁMIDE: La organización inductiva de las
preguntas de la entrevista puede ser visualizado como si tuviera una forma de
pirámide. Mediante el uso de esta forma el entrevistador comienza con preguntas
muy detalladas y frecuentemente cerradas. El entrevistador luego expande el tema

permitiendo preguntas abiertas y respuestas más generalizadas

 USO DE UNA ESTRUCTURA DE EMBUDO: En este el entrevistador toma un enfoque
deductivo, comenzando con preguntas generales y abiertas y estrechando las
respuestas posibles usando preguntas cerradas. El uso de la estructura embudo
proporciona una forma fácil y no intimidante para comenzar una entrevista. Un
beneficio del uso de una estructura de embudo es que el organizar la entrevista en
tal forma puede dilucidar tanta información detallada que es innecesaria las

secuencias largas de preguntas cerradas y averiguaciones

 USO DE UNA ESTRUCTURA DE ROMBO: Frecuentemente es mejor una combinación
de las estructuras anteriores. En este caso, el entrevistador comienza con
preguntas cerradas fáciles que proporcionan un calentamiento al proceso de la
entrevista. A la mitad de la entrevista se le pide al entrevistado opiniones sobre
temas amplios, que obviamente no tienen respuestas “correcta”. Luego el
entrevistador estrecha las preguntas nuevamente para hacer que se respondan,
preguntas específicas, proporcionando así un cierre para el entrevistado y el
entrevistador. La desventaja de esta estructura es la de consumir más tiempo y la
ventaja principal es conservar el interés y la atención del entrevistado por medio

de una diversidad de preguntas

ENTREVISTAS ESTRUCTURADAS CONTRA NO ESTRUCTURADAS

La conciencia de los compromisos entre las entrevistas estructuradas y no estructuradas
le permitirá tomar una mejor decisión acerca de cuál tipo de entrevista es más adecuado

para una situación particular. Aunque se decida seguir la ruta no estructurada, de todas
 Página 39

formas
Para el deberá
enfoqueestar preparado para
no estructurado la entrevista tal como se dijo en los
quepasos anteriores.
preguntas redactadas precisamentesugerimos al en
en la forma menos un breve
que serán guión
preguntadas incluya muchas

Registro de la entrevista
Se realiza sobre los aspectos más importantes de la entrevista. El que se tomen notas o se
use una grabadora de cinta depende, en parte, de a quién se está entrevistando y de lo que
se hará con la información una vez que haya pasado la entrevista.
 Grabadora de cinta: Tiene como ventajas que el registro es exacto, libera al
entrevistador para escuchar y responder más rápidamente, permite mejor
contacto visual, y permite una reproducción exacta de la entrevista para otros
miembros del equipo. Tiene como desventajas que hace posiblemente inquietante
la entrevista, la dificultad de buscar diálogos determinados en la cinta, y el

relevamiento de datos.
 Toma de Notas: Se utiliza cuando el entrevistado se rehúsa a la petición de la
grabación en cinta. Tiene como ventajas que mantiene alerta al entrevistador,
ayuda a recordar preguntas importantes, demuestra preparación e interés del
entrevistador. Como desventajas, tenemos la pérdida de contacto visual y del hilo

de la conversación, y un exceso de atención sobre los hechos.

Antes y durante la entrevista
Se debe vestir adecuadamente, ya que las respuestas del entrevistado están orientadas por
su percepción inicial. Debe llegar temprano a la entrevista. Salude de mano y con firmeza
al entrevistado, para establecer credibilidad y confianza. Recuérdele al entrevistado su
nombre, y describa una vez más brevemente el motivo por el cual está ahí y el por qué
escogió entrevistarlo.
En cuanto se siente, tome inmediatamente la grabadora y/o su cuaderno de notas. Dígale
al entrevistado lo que hará con los datos que recolecte y vuelva a afirmarle la
confidencialidad.
Al comenzar la entrevista, trate de captar el vocabulario y jerga. Mencione el tipo de
detalle que le gustaría recibir en las respuestas. De vez en cuando, regrese algunas de las
respuestas del entrevistado por medio de parafraseo o sumarización, para volver a
confirmar que se comprendió lo que quería decir. Si en cualquier otro momento no está
seguro, inmediatamente pida definiciones o aclaraciones.
Al final de la entrevista, pregunte “¿Hay algo de lo que no hayamos hablado y que usted
siente que es importante que yo sepa?”. Resuma y haga saber sus impresiones generales.
Infórmele al entrevistado acerca de los pasos siguientes a tomar y qué es lo que harán a
continuación con usted y otros miembros del equipo. Fije citas futuras para entrevistas de
seguimiento, dele las gracias al entrevistado por haberle dado su tiempo y despídase con
un apretón de mano. Tan pronto como sea posible se debe realizar la escritura del reporte

de la entrevista.

DISEÑO CONJUNTO DE APLICACIONES

 Página 40

Sin importar qué

experimentará tan adeptodonde
situaciones lleganlasa ser usted como
entrevistas entrevistador, inevitablemente
como
yusuariosuno quisiera.
sus datos son Las entrevistas
propensos a malas personales sonpersona
interpretaciones. Un
a personan
consumidoras
enfoque
no parecen
de tiempo,
alternativo
tan útiles
apropensas a error
la entrevista
uso del de es
JAD unoreducir
en unoelllamado
tiempo Diseño
(y por conjunto
lo tanto el de aplicaciones
costo) requerido(JAD).
para La
lasmotivación
entrevistas para de
el
personales,
información mejorar la calidad de los resultados de la valoración de requerimientos de
información ya la creación de del
consecuencia másproceso
identificación del usuario con el nuevo sistema de
participativo
Aunque
durante el
el JAD
ciclopuede
de vidaser
de sustituido con entrevistas personales en cualquier ocasión adecuada
una técnica
la interfaz deque permita
usuario al desarrollo
analista dede
conjuntamente
sistemalograr
sistemas
con
el JAD
los usuarios en
harequerimientos
los sido utilizado,
un grupo
por lo general,
de análisis comode
y diseño
 Condiciones
Considere el JADque dan soporte al uso de JAD
cuando:
1. Los grupos un de problema
usuario están impacientes y quieren algo nuevo, y no una solución
2. estándar
La culturaaorganizacional típico
da soporte a los conocimientos
de empleadosde la solución de
3. problemas
Los analistas
persona
enpredicen
conjuntoque
adepersona
entre
noamplio
varios niveles
será tancantidad
la abundante de ideas
comogeneradas
la cantidadpordemedio de entrevistas
ideas posibles del
ejercicio
4. durante
El flujo de un grupo
untrabajo
bloqueorganizacional
de tiempo de dos permite la ausencia
a cuatro días de personas importante

Quienes están involucrados

Las sesiones de JAD incluyen una gran variedad de participantes, analistas, ejecutivos, etc.

Que contribuirán con sus diferentes experiencias y aptitudes a las sesiones.

 Un patrocinador ejecutivo: una persona de alto nivel que abra y cierre las sesiones
de JAD. De preferencia, seleccione a un ejecutivo del grupo de usuarios que tenga
algún tipo de autoridad sobre las gentes del sistema de información que están
trabajando en el proyecto. Esta persona será un símbolo visible e importante de la

disposición organizacional al proyecto de sistema.

 8 a 12 usuarios de cualquier rango.

 Al menos un analista de sistemas de información, pero tomando un papel pasivo,
escuchando lo que dicen los usuarios y lo que requieren. Adicionalmente, se querrá
dar una opinión de experto acerca de cualquier costo desproporcionado o

soluciones propuestas durante la sesión.

 Página 41

 El líder de la sesión
comunicación debe serlas
para facilitar alguien que tenga
interacciones habilidades excelentes de
adecuadas.
 1 o 2 observadores
funcionales que sean analistas
para proporcionar o expertos
explicaciones técnicos
técnicas de otras
y consejos áreas
al grupo.
 Un escribano
escribano para escribir
publique formalmente
el registro todo lo de
de los resultados queJAD
se rápidamente.
hace. Asegúrese que el

Planificación de la sesión de JAD

Se deben definir el alcance del proyecto, seleccionar los participantes, y el líder.

Se recomienda que las sesiones se realicen de 2 a 4 días en un lugar aparte, fuera de la
organización, en ambientes agradables. La idea es minimizar las distracciones y
responsabilidades diarias del trabajo regular de los participantes.
Dé la importancia adecuada a la creación de confort para los participantes. Disponga de
suficiente comida y bebidas durante los cortes planeados.
Calendarice las sesiones de JAD cuando todos los participantes puedan estar dispuestos a
asistir. Esto es crítico para el éxito de las sesiones.
Considere la realización de una reunión de orientación, con duración de medio día, una
semana antes aproximadamente, para que los que estén involucrados sepan lo que se
espera de ellos. Esto permite que usted se mueva rápidamente y actúe con confianza una

vez que ha sido convenida la reunión actual.

Logro de un análisis estructurado de las actividades del Proyecto

Siendo el analista involucrado con las sesiones JAD, usted debe recibir las notas del
escribano y preparar un documento de las especificaciones, basado en lo que sucedió en la
reunión. Presente los objetivos de administración, así como el alcance y las fronteras del

proyecto.

Beneficios potenciales del uso de JAD en vez de entrevistas tradicionales

1. Ahorro de tiempo sobre las entrevistas uno a uno

2. Posibilidad de una propiedad mejorada de sistema de información, ya que el JAD
involucra a los usuarios desde el principio en el proyecto de sistema, con lo cual tratan la

retroalimentación seriamente

3. Desarrollo creativo de los diseños: hay una “lluvia de ideas”

Desventajas potenciales del uso de JAD

1. Requiere la dedicación de un gran bloque de tiempo por parte de los 18/20

participantes
 Página 42

2. Cuando la ypreparación
seguimiento de las sesiones
la documentación JAD es inadecuada o cuando el reporte de
esnecesarias
incompleta
3. Las habilidades
desarrolladas lo organizacionales
suficiente para el esfuerzo y la cultura
concertado queorganizacional pueden
se requiere para no estar en
ser productivo
un ambiente JAD

CUESTIONARIOS

Los cuestionarios permiten que los analistas estudien actitudes, creencias,

comportamientos y características de varias personas principales en la organización que
pueden ser afectadas por los sistemas actual y propuesto. Las actitudes son lo que la gente
de la organización dice que quiere, las creencias son lo que la gente piensa que es, el
comportamiento es lo que hacen los miembros de la organización y las características son
propiedades de las personas o cosas. Mediante el uso de cuestionarios el analista puede
estar buscando cuantificar lo que ha encontrado en las entrevistas. En forma inversa, los
cuestionarios pueden ser usados para investigar a una gran muestra de usuarios de
sistemas, para tratar de encontrar problemas o recoger cosas importantes antes de que las

entrevistas sean realizadas.

El desarrollo de un cuestionario útil requiere gran tiempo de planeación. Algunos

lineamientos que ayudarán a decidir si es adecuado el uso de cuestionarios son:

1- Las personas a preguntarles están dispersas
2- En el proyecto de sistema está involucrada gran cantidad de personas y tiene sentido
saber qué proporción de un grupo dado aprueba o desaprueba una característica
particular del sistema propuesto
3- Se está haciendo un estudio exploratorio y se quiere medir la opinión general antes de
darle al proyecto de sistema una dirección específica
4- Se desea asegurar que cualquier problema con el sistema actual esté identificado y

atacado en las entrevistas de averiguación

Una vez decidido a utilizar cuestionario, se puede comenzar a formular preguntas. En los
cuestionarios, a diferencia de las entrevistas, es muy difícil refinar o aclarar preguntas
dudosas. Lo que significa que las preguntas deben ser muy claras, el flujo de preguntas
coherente, las preguntas del interlocutor anticipadas y la administración del cuestionario

planeada a detalle. Recordemos que había 2 tipos de preguntas:

 Preguntas Abiertas: En un cuestionario, se deben anticipar el tipo de respuesta que se
va a obtener. Es importante que las respuestas que reciba sean capaces de una
interpretación correcta. Este tipo de preguntas es adecuado para situaciones en las
cuales se quiere obtener la opinión de los miembros de la organización acerca de

algún aspecto del sistema. También se utilizan en situaciones exploratorias

 Preguntas Cerradas: Deben ser usadas cuando el analista de sistemas sea capaz de
listar efectivamente todas las respuestas posibles a la pregunta y cuando todas las

respuestas listadas sean mutuamente excluyentes, para que la selección de una

 Página 43

impida la selección
de personas, debidodea la
cualquier
cantidadotra. Se deben
de datos que usar para investigar a una gran muestra
se obtendrán.
Cabe desatacar
aprecian losdel que es muy importante la selección de palabras, ya que los interlocutores
esfuerzos
propio uso lenguaje.de alguien que se preocupa por escribir un cuestionario que refleje su
Para confirmar si el lenguaje usado es el adecuado, puede probarlo sobre un grupo piloto. Uso
de Escalas
El
conescalamiento
objeto es el proceso de asignar números Las
u otros símbolos a un atributo o arbitrarias
característica
pueden no de
sermedir
únicas.ese
Seatributo o característica.
utilizan escalas para: escalas son frecuentemente y

 Medir las actitudes o características de quienes responden el cuestionario

 Hacer que los interlocutores juzguen los temas del cuestionario

Las escalas son medibles, y hay 4 formas diferentes para la medición:

1- Escala Nominal: Son la forma más débil de medición. Sólo se pueden obtener
totales. Ej.: ¿Qué programa usa más? 1=Proc. Texto; 2=P. Cálculos; 3=BD
2- Escala Ordinal: Permiten clasificación, implica ordenamiento de rango. Son útiles
debido a que una clase es mayor o menor que otra. Ej.: El personal de secretaría es:
1. Extremadamente útil; 2.Muy útil; 3.No muy útil; 4.Inútil
3- Escala de Intervalo: Los intervalos entre c/u de los nº son iguales. Debido a esto, se
pueden realizar operaciones matemáticas sobre los datos. Ej.: ¿Qué tan útil es el
soporte dado por el personal de Laboratorio? Inútil Extremadamente útil 1 2 3 4 5
4- Escala de Relación: No permite jerarquización, aunque dan una idea general. Ej.:

¿Qué tantas horas usa la computadora? 0 2 4 6 8

Validez y Confiabilidad: Hay dos mediciones de desempeño en la construcción de escalas:
validez y confiabilidad. Validez es el grado con el cual la pregunta mide lo que el analista
trata de medir. Ej.: Si el objetivo del cuestionario es determinar si la organización se

encuentra lista para un cambio, ¿mide eso las preguntas?

Confiabilidad mide consistencia: Si el cuestionario fue administrado una vez, y luego
nuevamente bajo las mismas condiciones se obtuvieron los mismos resultados, se dice que
el instrumento tiene consistencia externa. Si el cuestionario contiene sub-partes y estas
tienen resultados equivalentes, se dice que tiene consistencia interna. Tanto la

consistencia interna como la externa son importantes.

Construcción de escalas
Se presentan 3 problemas cuando se construyen escalas:
1- Lenidad: Es cuando los interlocutores califican a la ligera. Se puede evitar moviendo la

categoría “promedio” a la izquierda o derecha del centro

 Página 44

2- Tendencia
creando Central: Lospuntos,
interlocutores califican todo como
etc. promedio. Se puede arreglar
3- Efectoescalas
siguiente de con
halo:
pregunta
más
Cuando achicando
la impresión diferencias,
formada en una pregunta se transporta a la

Diseño y Administración del cuestionario

Se debe poner mucha atención a esto para evitar que los interlocutores lo contesten a
desgano o simplemente no lo contesten.
Un cuestionario relevante y bien diseñado puede ayudar a superar algo de esta resistencia
a responder.
Algunas consideraciones:
 Dejar bastante espacio en blanco
 Dejar suficiente espacio para las respuestas
 Pedir al interlocutor que encierre con un círculo las respuestas
 Usar objetivos que ayuden a determinar el formato
 Ser consistente en estilo
 Guardar un orden en las preguntas
 Colocar las preguntas importantes para los interlocutores al principio
 Agrupar conceptos de contenido similar
 Emplear las tendencias asociativas de los interlocutores

 Poner primero los conceptos menos controvertidos

Una vez diseñado el cuestionario, se deben determinar a los interlocutores. Hay que
asegurarse de que haya suficientes interlocutores para permitir una muestra razonable en
caso de que se pierdan cuestionarios o que sean llenados incorrectamente, y deban ser

desechados.
Existen 4 formas de administrar el cuestionario:
1- Reunir a todos los interlocutores involucrados a la vez: No hay tiempo de espera y no se
pierden cuestionarios. Sin embargo, tiene como desventaja la presión del grupo
2- Manejar personalmente cuestionarios en blanco y recoger los llenos: Requiere mucho
tiempo y suele haber escepticismo en las respuestas.
3- Permitir a los interlocutores que administren el cuestionario por sí mismos y los
depositen
en una caja: Tiene como ventaja que las personas se sienten en el anonimato, pero sin
embargo pueden perderse cuestionarios
4- Enviar por correo los cuestionarios, con instrucciones para el retorno: Tiene muy baja

tasa de respuesta
OBSERVACIÓN DEL COMPORTAMIENTO DE LOS TOMADORES DE DECISIONES Y EL AMBIENTE DE
OFICINA
El analista examina
influencia los elementos físicos del espacio de trabajo del tomador para ver su
elementos sobre
físicosel comportamiento
sobre del mismo.
los que el tomador Además,
de decisiones mediante
tiene control,laelobservación de los
analista puede
 Página 45

determinar el mensaje
provoca sobre que
las demás está enviando
personas este tomador de decisiones, y la influencia que
de la organización.

Observación del comportamiento del tomador de decisiones

La observación también ayuda a confirmar o negar e invertir lo que ha sido encontrado
por medio de entrevistas, cuestionarios y otros métodos. La observación debe ser
estructurada y sistemática si es que se quiere que los hallazgos sean interpretables.
Para que el analista de sistemas aprecie adecuadamente la forma en que los gerentes
caracterizan su trabajo se usan las entrevistas y cuestionarios. Sin embargo, la observación
permite que el analista vea de primera mano cómo los gerentes recopilan, procesan,
comparten y usan la información para hacer que el trabajo se realice.
Los pasos para la observación de las actividades típicas de un gerente son:
1- Decidir lo que va a ser observado
2- Decidir a qué nivel de concreción van a ser observadas las actividades
3- Crear categorías que capturen adecuadamente las actividades principales
4- Preparar escalas, listas de verificación y otros materiales adecuados

5- Decidir cuándo observar

Muestreo de tiempo Muestreo de eventos

Visitas aleatorias
en intervalos frecuentes
cortos de Visitas
eventosprogramadas en
tiempo
Def. especiales.

-aleatoriedad
Elimina la tendencia
de con la -comportamientos
Permite la observación de
conforme
observaciones
-representativa
Permite una vista suceden
-un
Permite laconsiderado
observación de
de
actividades frecuentes evento
importante
Ventajas

-fragmentada
Recolecta datos
que en
no forma
da -tiempo
Se lleva gran
del cantidad de
analista
tiempo
para que se desarrolle una
decisión
- Se pierde una muestra
Desventajas - Se pierden decisiones
representativa de
importantes
poco frecuentes decisiones

frecuentes

Observación del Lenguaje corporal del tomador de decisiones

Hay 2 formas de realizar este análisis:

 Página 46

1- Pares de Adjetivos yconfiado/desconfiado,

decidido/indeciso, Categorías: Se listan categorías deeligiendo
la siguiente forma:
2- El guión del Puede
decisiones. analista:
agregarse una tablaetc.
Se listanlaenfrecuencia, las y se va
tareas
total, que realiza
porcentaje,
la correcta
etc.el tomador de

Observación del ambiente físico

Más frecuentemente, esto significa examinar sistemáticamente las oficinas de los

tomadores de decisiones, debido a que las oficinas constituyen su lugar de trabajo
principal. Los tomadores de decisiones influencian y a la vez son influenciados por sus
ambientes físicos.
La observación estructurada del ambiente de trabajo del tomador de decisiones se realiza
mediante el método STROBE. Este método se integra por 7 elementos, que pueden revelar
mucho acerca de la forma en que el tomador de decisiones recopila, procesa, guarda y
comparte información, así como acerca de la credibilidad del tomador de decisiones en el

espacio de trabajo. Los 7 elementos son:

1- Ubicación de la oficina respecto a las demás oficinas: Dan un panorama de la
accesibilidad hacia otras personas del tomador de decisiones
2- Ubicación del escritorio: Dan una idea de cómo consideran su poder
3- Equipo de oficina fijo: (Archiveros, libreros, etc.). Permiten saber con qué grado
valora la información
4- Propiedades: (calculadoras, PC, etc.). Da idea sobre el grado de delegación
5- Revistas y periódicos del negocio: Permiten saber si se apoya en información
interna o externa para tomar las decisiones
6- Iluminación y color de la oficina: Indican la manera que recopila información

7- Vestimenta usada por los tomadores de decisiones: Dan credibilidad

Mediante el uso de STROBE el analista puede obtener una mejor comprensión sobre la
manera en que los gerentes recopilan, procesan, almacenan y usan información.
Los analistas pueden usar el enfoque STROBE utilizando distintas estrategias, que varían

desde muy estructuradas hasta sin estructurar. Estas estrategias son:

1- Análisis de fotografías: Se fotografía el ambiente y luego se analiza. Tiene como
ventajas que se puede hacer referencia a las fotografías repetidamente; permite al
analista enfocarse en otras cosas; reducen limitaciones de espacio/tiempo; la
fotografía puede proporcionar detalles que fácilmente se descuidan. Como
desventajas, está el decidir qué fotografiar; y que el tomador de decisiones puede
reubicar elementos ante la visita del analista
2- Enfoque de la lista de verificación / Escala Likert: Son escalas de 1 a 5 puntos en
relación con 7 características del tomador de decisiones que fueron observables
por elementos físicos en los ambientes organizacionales
3- Listas anecdóticas (con símbolos): Es una lista de verificación donde se comparan

hechos dichos por los miembros de la organización, contra lo que dice el tomador
 Página 47

de decisiones.en
Según se confirme/niegue/invierta lo que seaveriguar
dijo, se coloca un símbolo
4- determinado
Comparación
examina el delalacaracterística
ambiente y se compara
y se determina
observación/narrativa:
con las Es si
elsemétodo
debe
narraciones, y menos más.
mediante estructurado.
el resultado de Se
la
comparación se determina el investigar más o no.

MUESTREO
El muestreo es el proceso de seleccionar sistemáticamente elementos representativos de
una población. Cuando estos elementos seleccionados son examinados de cerca, se supone
que el análisis revelará información útil acerca de la población como un todo.
El analista de sistemas tiene que tomar una decisión sobre 2 puntos. Primero, hay muchos
reportes, formas, documentos, que han sido generados por los miembros de la
organización ¿A cuáles de éstos debe prestar atención el analista de sistemas y cuáles debe
ignorar? Segundo, gran cantidad de empleados pueden ser afectados por el sistema de

información propuesto. ¿A qué personas debe entrevistar el analista?

El muestreo es necesario debido a:

Los costos contenidos
La agilización en la recolección de datos
La mejora de la efectividad en la recolección de datos

La reducción de la ascendencia

Diseño del muestreo

1- Determinar los datos a ser recolectados o descritos: El analista debe identificar las
variables, atributos y conceptos de datos asociados que necesitan ser recolectados en la
muestra. Se deben considerar los objetivos del estudio, así como el método de recolección
de datos a ser usado.
2- Determinar la población a ser muestreada

3- Seleccionar el tipo de muestra: Hay 4 tipos principales de muestras:

 Muestras de conveniencia: Son muestras no restringidas y no probables. La
muestra es la más fácil que se podría recolectar, pero al mismo tiempo es la menos
confiable. Ej.: el analista pone una noticia en el boletín de la compañía pidiendo a
cualquier interesado en el nuevo reporte de desempeño de ventas que asista a una
reunión el 2/4/08 a las 1:00pm.
 Muestras intencionadas: Un analista puede seleccionar a un grupo de individuos
que parecen tener conocimiento e interés en el nuevo sistema de información. Es
moderadamente confiable
 Muestras aleatorias simples: El analista obtiene una lista numerada de la población,
y elige una cierta cantidad al azar.

 Muestras aleatorias complejas: Se pueden elegir 3 enfoques

 Página 48

 Muestreo
lista Sistemático:
de empleados de laEj.: Elegir entrevistar a cada enésima persona de una
compañía
 Muestreo Estratificado

 Muestreo Aglomerado:
4- Decidir el tamaño de la muestra: El tamaño de la muestra depende frecuentemente del
costo involucrado en el tiempo requerido por el analista de sistemas, o hasta el tiempo

disponible de las personas de la organización

Tipos de información buscada en la investigación

Conforme el analista de sistemas trabaja para comprender a la organización y a sus
requerimientos de información, llega a ser importante el examen de diferentes tipos de
datos impresos que proporcionan información que no se encuentra disponible por ningún
otro método de recopilación de datos. Los datos impresos revelan dónde ha estado la
organización y hacia donde creen sus miembros que están yendo. El analista necesita

examinar los datos en forma:

 Cuantitativa: Reportes usados para la toma de decisiones, reportes de desempeño,
registros, formas para la captura de datos. Mediante éste análisis se puede
descubrir que los datos no fluyen como se pretende, que hay cuellos de botella, que

se duplica innecesariamente el trabajo, etc.

 Cualitativa: Este análisis es crítico para la comprensión de la manera en que los
miembros de la organización engranan en el proceso o en la organización. Los
documentos cualitativos incluyen memorándums (reflejan la política), consignas
en tableros de noticias y en áreas de trabajo (reflejan los valores/cultura
organizacional), manuales de procedimientos y manuales de política. Un

lineamiento a seguir para iniciar la interpretación de los documentos es:

1- Examinar los documentos en busca de claves o metáforas de lineamientos, ya que puede
ser persuasivas en la organización, así como para comprender cómo puede ser
caracterizado metafóricamente el nuevo sistema
2- Buscar referencia a mentalidad “nosotros vs ellos” en documentos, a fin de conocer de
antemano posibles problemas de cooperación del personal
3- Listar términos que caractericen el bien y el mal, y aparezcan repetidamente en los
documentos, para saber qué es bueno y qué malo en el negocio
4- Reconocer el sentido del humor en caso de estar presente, a fin de determinar la

moral/cultura de una persona de la organización

Otra fuente de información, además de los recién mencionados datos impresos, son los

datos archivados.
Ventajas del uso de datos
archivados
Desventajas del uso de datos archivados
 Ya fueron pagados por alguien más  Existe incertidumbre sobre si los datos son un
 Página 49

 Los
que datos no sonno
el productor cambiados, debidodea
está consciente
que está siendo estudiado subconjunto de los datos originales
 Los registros que sobreviven pueden no ser los
más importantes
 Pueden tener ascendencias, ya que alguien
decidió originalmente lo que había que
archivar
 Es difícil obtener nuevos datos de muestras

equivalentes

UNPROCESODIRIGIDOPORCASOSDEUSO
El objetivo del
distribución Proceso
eficiente deUnificado
sistemas es
queguiar a los desarrolladores
se ajusten a las necesidadesen la
deimplementación
los clientes.no y
El es
paso
desde la determinación
En primer lugar, debede las necesidades
se comunicarse
encontrar del cliente
algún modo hastalas
de capturar la necesidades
implementación del usuario trivial.
de
forma que
Después, puedan
debemos ser capaces fácilmente a todas
de diseñarmediante las personas
una implementación implicadas en
funcionalDebido el proyecto.
que se aajuste a las
necesidades
complejidad, del
el cliente
proceso se
sehan cumplido
describe como una serie pruebas
de del
flujos de sistema.
trabajo que esta
construyen el
sistema gradualmente

Fig. El Proceso
consiste en unaUnificado
serie de
flujos
desde de
lostrabajo quehasta
requisitos van
las pruebas.
trabajo Los flujos
desarrollan de
modelos,
de casos desde
de uso el modelo
hasta el
modelo de prueba

Los
uso desarrolladores
ende
eluso,
modelo decomienzan
casos capturando
de uso. Después los requisitos
analizan del cliente
yanálisis,
diseñan en lapara
el sistema forma de casos
cumplir los de
casos creando
implementación, enincluye
el cual primer lugar
todo elun modelo
código, es de
decir, después
los componentes.uno de diseño,
Porelúltimo,otro
los de
desarrolladores preparan un modelo de prueba que les
proporciona la funcionalidad descrita en los casos de uso permite verificar que sistema
¿Por qué casos de uso?
 Página 50

 Para
de capturar
uso permite los requisitos que aportan valor que
añadido: En los
primer lugar,del
la idea de caso
casos de
usuarios. uso sonlalas
Tomando
identificación
lafunciones
del proporciona
que
perspectiva
software uncumple
sistema objetivos
para añadir usuario.
valor alos Los
suscasos
de uso que necesitan para hacer sudetrabajo
cada tipo de usuario, podemos capturar
Los mejores casos de uso son aquellos que añaden valor al negocio que implanta el
sistema. Un caso de uso que aporta un valor negativo o que permite hacer al usuario

cosas que no debería hacer no es un caso de uso

Podríamos llamarlo “caso de abuso”, ya que especifica forma de visualizar el sistema
que deben prohibirse. Un ejemplo de un caso de uso de este tipo sería permitir a un

cliente de un banco transferir dinero de la cuenta de otro a la suya

El modelo de casos de uso se utiliza para conseguir un acuerdo con los usuarios y
clientes sobre que debería ser el sistema para los usuarios. Podemos pensar en el
modelo de casos de uso como en una especificación completa de todas las formas
posibles de utilizar un sistema. Esta especificación puede utilizarse como parte del

contrato con el cliente a comunicar sus necesidades

 Para dirigir el proceso: El que un proceso este dirigido por casos de uso significa que
progresa a través de una serie de flujos de trabajo que inician a partir de los casos de
uso. Los casos de uso ayudan a los desarrolladores a encontrar las clases. Las clases
de recogen de las descripciones de los casos de uso a medida que las desarrolladores,
buscando clases que sean adecuadas para la realización de los casos de uso. Estos
también ayudan a los jefes de proyecto a planificar, asignar y controlar muchas de las
tareas que los desarrolladores realizan. Por cada caso de uso, un jefe de proyecto
puede identificar unas cuantas tareas. Cada caso de uso a especificar es una tarea,
cada caso de uso a diseñar es una tarea, y cada caso de uso es una tarea. Entonces
estar pueden asignarse a desarrolladores concretos que se hacen responsables de

ellas
 Para idear la arquitectura y más…: Los casos de uso nos ayudan a llevar a cabo el
desarrollo. En otras palabras, en cada iteración se identifican e implementan unos
cuantos casos de uso. Mediante la selección del conjunto correcto de casos de uso
para llevarlos a cabo durante las primeras iteraciones, podemos implementar un
sistema con una arquitectura estable, que pueda utilizarse en muchos ciclos de
desarrollo subsiguientes. Los casos de uso también se utilizan como punto de partida
para escribir el manual de usuario. Ya que cada caso de uso describe una forma de
utilizar el sistema, son el punto de partida ideal para explicar cómo puede el usuario

interactuar con el sistema.

LACAPTURADECASOSDEUSO

 EL MODELO DE CASOS DE USO REPRESENTA LOS REQUISITOS FUNCIONALES

 Página 51

El modelosobre
acuerdo de casos
cómode uso ayuda al cliente, a los usuarios y a los desarrolladores a tipos
llegarde
a un
usuarios
sistema donde
al cada utilizar
interactuartipo
con de el
los
sistema.
usuario
casos de
La mayoría
seuso.
representa
Todos
de los sistemas
mediante
los actores un
y
tienenestos
ACTOR,
casos de
muchos
uso utilizan
del sistemael
forman un
modelo de modelo
casos dede
usocasos de uso.un
y muestra Unconjunto
diagramadedecasos
casosdedeuso
usoy describe parte
actores con delasociación
una modelo de
entre cada par actor/caso de uso que interactúan

 LOS ACTORES SON EL ENTORNO DEL SISTEMA

No todos los actores representan a personas. Pueden ser actores otros sistemas o
hardware externo que interactuará con el sistema. Cada actor asume un conjunto
coherente de papeles cuando interactúa con el sistema. Un usuario físico puede actuar
como uno o varios actores, desempeñando los papeles de esos actores en su intersección

con el sistema. Vario usuarios concretos pueden actuar como ocurrencias del mismo actor.
Los actores se comunican con el sistema mediante el envío y recepción de mensajes hacia
y desde el sistema según éste lleva a cabo los casos de uso. A medida que definimos que
hacen los actores y lo que hacen los casos de uso, se trazará una clara separación entre las
responsabilidades de los actores y las del sistema. Esta separación nos ayuda a delimitar el

alcance del sistema

 LOS CASOS DE USO ESPECIFICAN EL SISTEMA

Los casos de uso están diseñados para cumplir los deseos del usuario cuando utiliza el
sistema. El modelo de casos de uso captura todos los requisitos funcionales del sistema.

Definiremos un caso de uso de manera precisa como sigue:

“Un caso de uso especifica una secuencia de acciones, incluyendo variaciones, que el sistema
puede llevar a cabo, y que producen un resultado observable de valor para un actor

concreto”
Cada uno de los diferentes modos de utilizar el sistema que añaden valor al usuario es un
caso de uso candidato. Estos candidatos se ampliarán, se cambiarán, se dividirán en casos
de uso más pequeños, o se integrarán en casos de uso más completos. El modelo de casos

de uso recoge todos los requisitos que pueden comprender los clientes, usuarios y
 Página 52

desarrolladores.
es un camino de La secuencia
específico de del
a través acciones realizada
caso de uso. por un
Puede casomuchos
haber de uso caminos,
durante su operación
ser variantes
hacer que un la ejecución
modelo de dede
casos la uso
secuencia
sea de acciones
comprensible, especificadas
podemos agrupar casoestos pueden
en eldescripciones
de uso. Para
de
caminos variantes parecidas en un solo caso de uso
Los
comocasos de uso también
losderequisitos se utilizan como
de rendimiento, “contenedores”
disponibilidad, deylos
exactitud requisitos
seguridad quenoson
funcionales, tales
específicos de
un caso uso.

CAPTURADEREQUISITOSCOMOCASOSDEUSO
El esfuerzoy principal
construir, en ladefase de de
requisitos es desarrollar un modelo del ese
sistema que Esto
se vaesa
debido quelalos
que laamayoría
yy pueden
utilización
requisitos casos
funcionalesuso en
seno una formadeadecuada
estructuran forma de crear
natural mediante modelo.
un solocasos de uso,
tratarsede enlos otros
el contextorequisitos
de ese caso funcionales
de uso son específicos de caso de uso,
Los casos decon
funcionales usoun
proporcionan un medio
énfasis especial intuitivo
en el de
valor y sistemático para capturar los requisitos
sistema
pensar externo.
en Mediante
términos la utilización
de quiénes son los losañadido
usuarios casos
y quéde para
uso,cada
necesidades
usuario
los analistas
ude
individual
se ven
objetivos
o para acada
deobligados
la empresa
pueden
motivo importante para su aceptación en la mayoría de los métodos de la ingeniería sido
cumplir. Su papel clave en la dirección del resto del trabajo desarrollo ha un
moderna
de software
Vamos a describir
Los artefactos el flujo
creados en de trabajo
el flujo de los requisitos
de trabajo en 3 pasos: 1-
de los requisitos
2- Los trabajadores participantes en el flujo de trabajo de los requisitos

3- El flujo de trabajo de captura de requisitos, incluyendo cada actividad en más detalle

ARTEFACTOS

ARTEFACTO: MODELO DE CASOS DE USO

El modelo de casos de uso permite que los desarrolladores de software y los clientes

lleguen a un acuerdo sobre los requisitos, es decir, sobre las condiciones y posibilidades
 Página 53

que debe cumplir

proporciona un sistema.
la entrada Este sirve
fundamental como
para un acuerdo
el análisis, entre
el diseño clientes
y las y desarrolladores, y
pruebas

ARTEFACTO: ACTOR

Un actor es una idealización de una persona externa, de un proceso, o de una cosa que
interactúa con un sistema, un subsistema, o una clase. Un actor caracteriza las
interacciones que los usuarios pueden tener con el sistema. Diferentes usuarios pueden
estar ligados al mismo actor y por lo tanto pueden representar casos múltiples de la

misma definición de actor

Cada actor participa en uno o más casos de uso. Interactúa con el caso de uso (y por lo
tanto con el sistema o la clase que posee el caso de eso), intercambiando mensajes. La
implementación interna de un actor no es relevante en el caso de uso; un actor puede ser

caracterizado suficientemente por un conjunto de atributos que definen su estado

Los actores pueden
descripción abstractaser definidos en jerarquías de generalización, en las cuales una
específicas del actor del actor es compartida y aumentada por una o más descripciones
Un actor puede ser un ser humano, otro sistema informático, o un cierto proceso
ejecutable

ARTEFACTO: CASOS DE USO

Un caso de uso por
proporcionada es una unidad coherente deyfuncionalidad,porexternamente de visible,
intercambiados
es definirLa
una poruna
pieza de
unidaddel
la unidad delsistema
sistema
comportamiento
expresada
y uno o más
coherente, sin
secuencias
actores.
revelar la
mensajes
El estructura
propósito de un caso de uso
sistema.
líneas definición
principales, las de un caso
diferentes de uso incluye
variaciones todo
sobre el el comportamiento
comportamiento queinterna
normal;
dellas
implica:
ycon
todas las
condiciones excepcionales,
respuesta adecuada que pueden ocurrir con tal comportamiento, junto la
 Página 54

En el modelo, la ejecución
implementación deuso
de casos de cada paso crear
puede es independiente deimplícitas
dependencias las demás, aunque
entre ellas,una
debido a los
objetos compartidos
Aunque
puede cada instancia de un casodedeotros
uso es independiente, la descripciónesdesimilar
un caso de uso se
en quedescomponer
la descripción
descripción de las
en
defactores
una clase
superclases. Un se puede
caso de
casos
uso
de uso
definir
puede
más simples.
incrementalmente
incorporar
Esto
a partir
simplemente de laa la manera
el
comportamiento
se deDE
otros casos de En
usoeste
como fragmentos de sude
propio comportamiento. Esto
delllama RELACIÓN
caso de INCLUSIÓN.
uso original, y no se puede caso,
sustituir el nuevo
por él caso uso no es un caso especial
Un caso
base. de uso
ESTO se puede tambiénDEdefinir como una extensión incremental de un caso de uso
caso de
agregan uso,SEque
LLAMA RELACIÓN
pueden EXTENSIÓN.
ser aplicadas Puede
conjuntamente. haber varias extensiones
Las extensiones delbase
a un caso mismo
se
extensióna su semántica; que es el caso de uso base instanciado, no los casos de uso de la

TRABAJADORES Y RESPONSABILIDADES
 Página 55

FLUJO DE TRABAJO
El diagrama utiliza calles para mostrar que trabajadores ejecutan qué actividades; cada
actividad (representada por ruedas dentadas) se sitúa en el mismo campo que el
trabajador la ejecuta. Cuando los trabajadores ejecutan las actividades, crean y modifican
artefactos. Describimos los flujos de trabajo como una secuencia de actividades que están
ordenadas, así que una actividad produce una salida que sirve de entrada para la próxima

actividad. No obstante, el diagrama de actividad presenta solamente el flujo lógico

Fig. El flujo incluyendo

de trabajo para la captura
trabajadores de requisitosy sus
participantes en forma de casos de uso,
actividades
Una actividad
ejecución puede
de una solaser retomada
de lamuchas veces,
Porytanto,
cada una de éstasde
puede acarrear laa
otra, ilustran
ejecución de una solo fracción
tanactividad
la secuencia actividad.
lógica
como entrada deejecutar
para actividades los caminos una actividad
otra.utilizando los resultados de la
Los resultados
primera versióndedel
la modelo
primeradeiteración a través
casosdede decasos
uso, los este flujo
de usodeytrabajo consisten
cualquier en de
prototipo unainterfaz
de usuario
en nuevas asociado.
versiones Losestos
de resultados
artefactos cualquier iteración subsiguiente consistirán entonces

 ACTIVIDAD 1: ENCONTRAR ACTORES Y CASOS DE USO

 Página 56

Identificamos los actores y los casos de uso para:

 Delimitar el sistema de su entorno
 Esbozar quién y qué actores interactúan con el sistema, y que funcionalidad (casos
de uso) se espera del sistema
 Capturar y definir un glosario de términos comunes esenciales para la creación de
descripciones detalladas de las funcionalidades del sistema (es decir, de los casos

de uso)
Esta actividad consta de 4 pasos:
 Encontrar los actores
 Encontrar los casos de uso
 Describir brevemente cada caso de uso

 Describir el modelo de casos de uso completo

El resultado de esta actividad es una nueva versión del modelo de casos de uso con actores
y casos de uso nuevos o cambiados. Podemos describir y dibujar superficialmente el
artefacto modelo de casos de uso resultante, hasta el punto de poder describir cada caso
de uso en detalle, que es lo que hace la siguiente actividad: detallar un Caso de Uso

PASO 1: ENCONTRAR LOS ACTORES

Cuando tenemos un modelo de negocio del cual parte, encontrar los actores resulta
sencillo. El analista de sistema puede asignar un actor a cada trabajador del negocio y un
actor a actor del negocio que utilizará la información del sistema. En otro caso, con o sin
un modelo de dominio, el analista de sistemas, junto con el cliente, identifica los usuarios e

intenta organizarlos en categorías representadas por actores

En ambosycasos,
externos debemos
los actores paraidentificar los actores
el mantenimiento identificardel
y operación lossistema
actores que representan sistemas
Hay dos criterios
identificar al menosútiles
a aunalos
la hora de
usuario queelegir
pueda losrepresentar
candidatosala actor
actores: 1ro., debería
candidato. ser posible
encontrar
en nuestrasolamente
imaginación. actores
2dode relevantes,
, debería y eliminará
existir actores
una a los
coincidencia actores
mínima queEsto
entre sólo
los
nos
sonayudará
roles
a
fantasmas
que
desempeñan las instancias los diferentes
dos o más actores que en esencia tengan los mismos roles en relación con el sistema. No queremos
 Página 57

PASO 2: ENCONTRAR LOS CASOS DE USO

“Búsqueda de casos de uso a partir de un modelo de negocio”. Se propone un caso de uso
para cada rol de cada trabajador que participa en la realización de casos de uso del
negocio y que utilizará información del sistema. En otros casos, el analista de sistemas
identifican los casos de uso a través de talleres con los clientes y los usuarios. El analista
de sistemas va repasando los actores uno por uno y proponiendo los casos de uso para
cada actor, donde algunos de los candidatos no llegarán a ser casos de uso por si mismos;

en cambio, pueden ser partes de otros casos de uso.

Algunas veces es difícil decidir el ámbito de los casos de uso. Una secuencia de interacciones
usuario-sistema se puede especificar en un caso de uso o en varios, los cuales el actor invoca
uno tras otro. Cuando decidimos si un caso de uso candidato debe ser un caso de uso como
tal, tenemos que considerar si es completo por sí mismo o si siempre se ejecuta como
continuación de otro caso de uso. Obsérvese que hay dos frases claves en estas directrices
que contribuyen criterios útiles para la identificación de casos de uso, resultado de valor y

un actor en concreto:
 RESULTADO DE VALOR: Cada ejecución satisfactoria de un caso de uso debe
proporcionar algún valor al actor para alcanzar su objetivo. En algunos casos, el
actor quiere pagar por el valor devuelto. En este caso, el criterio par “un resultado
de valor observable” debe ser aplicado al actor iniciador. Este criterio de
“resultado de valor” nos ayuda a encontrar casos de uso de uso demasiados

pequeños
 UN ACTOR EN CONCRETO: Identificando casos de uno que proporcionen valores a
usuarios individuales reales, nos aseguramos que los casos de uso no se harán

demasiados grandes
Estos
ser dosdiferente
muy enfoquesdependiendo
pueden dar valores similares, pero
de la arquitectura el costeAsí
existente. de su implementación puede
puede necesitar
construir que mejor,
un sistema se renegocien
más fácillos
derequisitos
implementar(casos de uso y que
y mantener
el analista
demás)
para los con
de sistemas
el cliente
desarrolladorespara
PASO 3: uso
caso de Describir brevemente cada caso de uso: Consiste en describir aisladamente un
PASO
debe 4: Descripción
incluir del modelo
en eleldiagrama. de casos
Demodelo
hecho, de uso: el
elegimos Noconjunto
hay una de
regla estricta sobre
diagramas lo que se
que plano.
describan
más claramente
También
uso. sistema. El
puede organizarse de
en conjuntos casos de uso
de casos requiere
de uso ser un
llamados modelo
paquetes de casos de
La salida
Esta de este paso
descripción es el
explica también
modelouna
de descripción
casos dese
usogeneral
como undeltodo.
modelo de casos
Describe de uso.
cómo
interactúan los actores y casos de uso y cómo relacionan entre sí los casos de uso.
 Página 58

Cuandodel
bueno la descripción
modelo del modelo
de casos de usode casos de
la gente queuso
noesté
formapreparada,
parte dejamos que
deldeterminar
equipo de dé el visto
desarrollo (es
decir, clientes y usuarios), convocando una revisión informal para si:
 Se han capturado como casos de uso todos los requisitos funcionales
necesarios
 La
usosecuencia de acciones es correcta, completa y comprensible para cada caso de
 Se identifica
uso algún caso de uso que no proporcione valor. Si es así, ese caso de
debería reconsiderarse

 ACTIVIDAD 2: PRIORIZAR CASOS DE USO:

El propósito de esta actividad es determinar cuáles casos de uso son necesarios para el
desarrollo en las primeras iteraciones, y cuáles pueden dejarse para más tarde. Los
resultados se recogen en la vista de la arquitectura del modelo de casos de uso.
Después, esta vista se revisa con el jefe de proyecto, y se utiliza como entrada al hacer
la planificación de lo que debe desarrollarse dentro de una iteración. Hay que darse
cuenta de que esta planificación también necesita la consideración de otros aspectos
no técnicos, como los aspectos económicos o del negocio del sistema que va a ser
desarrollado. La vista de la arquitectura del modelo de casos de uso debe mostrar los

casos de uso significativos desde el punto de vista de la arquitectura.

 Página 59

 ACTIVIDAD 3: DETALLAR LOS CASOS DE USO

El objetivo principal de detallar cada caso de uso es describir su flujo de sucesos en detalle

incluyendo cómo comienza, termina e interactúan con los actores.

Con el modelo de casos de uso y los diagramas de casos de uso asociados como punto de
partida, el especificador de un caso de uso individual puede ya describir cada caso de uso
en detalle. Este detalla paso a paso la descripción de cada caso de uso en una

especificación precisa de la secuencia de acciones

 ESTRUCTURACIÓN DE LA DESCRIPCIÓN DE CASOS DE USO:

Ya hemos visto que un caso de uso define los estados que las instancias de los casos de uso

pueden tener y la posible transición entre estos estados. Cada transición es una secuencia
 Página 60

de acciones
efecto de unque se ejecutan
suceso, en unaser
cómo podría instancia del caso de uso cuando ésta se dispara por
un mensaje
Aquí debemos
técnica probadadescribir laun
es elegir posible
caminotransición
básico de estados
completo de manera
desde simple
el estado inicialydescribir
precisa.
hacia Una y
el en
final,
describir
secciones ese camino
separadas
camino básico enresto
el una sección de la descripción.
de los caminos Entonces,
como caminos podemos
alternativos o desviaciones del
Las alternativas,
muchas razones:desviaciones, o excepciones del camino básico pueden ocurrir por

 El actor puede elegir entre diferentes caminos del caso de uso

 Si está implicado más de un actor en el caso de uso, las acciones de uno de ellos
pueden influenciar el camino de las acciones del resto de actores

 El sistema puede detectar entradas erróneas de los actores

 Página 61

- ¿QUÉ INCLUIR EN UNA DESCRIPCIÓN DE CASO DE USO?

 Cómo y cuando comienza el caso de uso
 El orden requerido en el que las acciones se deben ejecutar
 Cómo y cuando terminan los casos de uso
 Los posibles estados finales
 Los caminos de ejecución que no están permitidos, es decir, que el usuario no
puede tomar
 Las descripciones de caminos alternativos que están incluidos con la descripción
del camino básico
 Las descripciones de los caminos alternativos que han sido extraídas de la
descripción del camino básico
 La interacción del sistema con los actores y que cambios producen
 La utilización de objetos, valores y recursos del sistema. Dicho de otra forma,
hemos descrito la secuencia de acciones en la utilización de un caso de uso, y
hemos asignado valores a los atributos de un caso de uso
 Debemos describir explícitamente qué hace el sistema. Debemos ser capaces de

separar las responsabilidades del sistema y las de los actores

Hemos hablado a menudo sobre los requisitos funcionales y cómo representarlos
mediante casos de uso, pero también necesitamos especificar los requisitos no
funcionales. Estos requisitos se asocian como requisitos especiales con el caso de uso en
cuestión. Si el sistema interactúa con algunos otros sistemas (actores no humanos), es
necesario especificar esta interacción. Esto se debe hacer en las primeras iteraciones,
durante la fase de elaboración, debido a que la realización de comunicaciones entre

sistemas tiene habitualmente influencia en la arquitectura.

La descripción de casos de uso se da por finalizada cuando se consideran las
descripciones comprensibles, correctas, completas y consistentes. Solamente los clientes

y los usuarios pueden verificar si los casos de uso son los correctos.

- Actividad 4: Prototipar la interfaz de usuario:

El objetivo de esta actividad es construir un prototipo de interfaz de usuario. Necesitamos
diseñar la interfaz de usuario que permita al usuario llevar a cabo los casos de uso de
manera eficiente. Lo haremos en varios pasos. Comenzamos con los casos de uso e

intentamos discernir qué se necesita de las interfaces de usuario para habilitar los casos
 Página 62

de uso para
creamos cada actor.
el diseño físico Esto
de laes, hacemos
interfaz un diseño
de usuario lógico de la interfaz de usuario. Después,
cómo pueden
especificación utilizar
de qué el
sesistema
necesita los usuarios
antes de parayejecutar
decidir
desarrollamos
cómo realizar la
prototipos
los casos de uso.de
interfaz
que ilustren
Mediante
usuario, la
llegamos aescomprender
actividad las necesidades
esquemasdedeantes de intentar realizarlas. El resultado final de esta
usuario que un conjuntola
especifican deapariencia interfaces
esas de usuario
interfaces de cara ya prototipos
los actoresdemásinterfaces de
importantes.

Unidad 4 - CAPTURA DE REQUISITOS

Llamamos CAPTURA DE REQUISTOS a ese acto de descubrimiento. Es el proceso de
averiguar, normalmente en circunstancias difíciles, lo que se debe construir. De hecho, es
tan difícil que todavía no es poco común para los equipos de proyecto el comenzar a
escribir código antes de que hayan firmado simplemente lo que se supone que debe hacer

el código

 POR QUÉ LA CAPTURA DE REQUISITOS ES COMPLICADA

Los desarrolladores de software normalmente crean código para otros y no para sí
mismos – lo hacen para los usuarios de software- . Sin embargo, una mínima experiencia
intentando recoger requisitos de los usuarios pronto los revela como una fuente
imperfecta de información. De uno u otro modo, normalmente cualquier sistema tiene
muchos usuarios (o tipos de usuarios) y mientras que cada uno de ellos puede saber lo
que él o ella hacen, ninguno tiene una visión global. Francamente, con frecuencia los
usuarios no saben cuáles son los requisitos ni tampoco como especificarlos de una forma

precisa
La aproximación tradicional a este problema ha sido asignar intermediarios – analistas –
para obtener una lista de requerimientos de cada usuario para poder obtener una visión
de conjunto y de componer una especificación de requisitos completa, correcta y
consistente. Pero es absurdo pensar que la mente humana es capaz de conseguir una lista
consiste y relevante de requisitos del tipo “El sistema debe…”. Es más, estas
especificaciones de requisitos no se transformaban fácilmente en especificaciones de

diseño e implementación
Incluso con la ayuda de los analistas, los usuarios no comprendían del todo lo que el
sistema software debería hacer hasta que el sistema estaba casi terminado. A medida que
el proyecto avanzaba, los usuarios, los intermediarios y los propios desarrolladores
podían ver cómo se parecería el sistema, y por tanto llegaban a comprender mejor las
verdaderas necesidades sugiriéndose gran cantidad de cambios. Muchos de esos cambios
eran deseables pero su implementación tenía con frecuencia un impacto importante en los

plazos y en los costos

 EL OBJETO DEL FLUJO DE TRABAJO DE LOS REQUISITOS

 Página 63

El propósito
sistema fundamental
correcto. del flujo de
Estoosecapacidades
consigue trabajouna
mediante de los requisitosde
descripción eslos
guiar el desarrollo
requisitos hacia el
del sistema (es
decir,
como las
paracondiciones
que pueda llegarse a un que el sistema
acuerdo entre debe
el cumplir)
cliente suficientemente
(incluyendo a los buena
usuarios) y los
desarrolladores sobre qué debe y qué no debe hacer el sistema
Un
las reto fundamental
veces seráde para conseguirlo
unrequisitos.
especialista es quedebe
no informático, el cliente, que asumimos
ser capaz de leer que la mayor
y comprender el parte de
resultado
de la
CLIENTEcaptura
para describir Para
estosal alcanzardonde
resultados, este objetivo debemos
losplanificar
resultados del utilizar
flujo deeltrabajo
LENGUAJE
de losDEL
requisitos
cliente también ayudan jefe de proyectos a las iteraciones y las versiones del

 VISIÓN GENERAL DE LA CAPTURA DE REQUISITOS

Sabemos que cada proyecto es diferente, pero de igual forma hay diferentes puntos de
partida para la captura de requisitos. En algunas ocasiones, comenzamos haciendo un
modelo del negocio, o comenzamos con un modelo del negocio que ya está en desarrollo
por parte de alguna empresa. En otros casos, el software es un sistema empotrado que no
da soporte directamente al negocio. Entonces podríamos tener como entrada un modelo
de objetos sencillo. Y en otros casos, el cliente incluso puede haber ya desarrollado una
especificación de requisitos completa y detallada que no esté basada en un modelo de

objetos, a partir de la cual podemos comenzar y negociar los cambios

La posibilidad de tener puntos de partida tan dispares como una vaga noción y una
especificación de requisitos detallada sugiere que los analistas necesitan ser capaces de
adaptar sus técnicas a la captura de requisitos en cada situación. Los diferentes puntos de
partida plantean tipos diferentes de riesgos, por lo que los analistas deberían elegir las

técnicas que reduzcan esos riesgos de la mejor forma

Aparte de las diferencias en los puntos de partida, ciertos pasos son factibles en la mayoría
de los casos, lo que nos permite sugerir un flujo de trabajo arquetípico. Este flujo de

trabajo incluye los siguientes pasos:

 ENUMERAR los REQUISITOS CANDIDATOS
 COMPRENDER el CONTEXTO DEL SISTEMA
 CAPTURAR REQUISITOS FUNCIONALES

 CAPTURAR REQUISITOS NO FUNCIONALES

ENUMERAR LOS REQUISITOS CANDIDATOS

Durante la vida del sistema, los clientes, usuarios, analistas y desarrolladores aparecen con
muchas buenas ideas que podrían convertirse en verdaderos requisitos. Esta LISTA DE

CARACTERÍSTICAS crece a medida que se añaden nuevos elementos y mengua cuando

 Página 64

algunas
como características
casos de uso. se convierten
La lista detiene en requisitos
características y se SÓLO
se utiliza transforman LAenPLANIFICACIÓN
otros artefactos
PARAexplicación DEL
TRABAJO. Cada
información característica
suficiente para poder un nombre
hablar de ellacorto y unalabreve
durante planificación o definición,
del proyecto

COMPRENDER EL CONTEXTO DEL SISTEMA

Para capturar los requisitos correctos y para construir el sistema correcto se requiere un

firme conocimiento del contexto en el que se empalma el sistema

Hay por lo menos dos aproximaciones para expresar el contexto de un sistema en una
forma utilizable para desarrolladores de software: modelado del dominio y modelado del
negocio. Un modelo de dominio describe los conceptos importantes del contexto como
objetos del dominio, y enlaza estos objetos unos con otros. La identificación y la asignación
de un nombre para estos objetos nos ayudan a desarrollar un glosario de términos que

permitirán comunicarse mejor a todos los que están trabajando en el sistema

El objetivo del modelado del negocio es DESCRIBIR LOS PROCESOS - existentes u

observados – con el objetivo de comprenderlos

A medida que los analistas modelan el negocio aprenden mucho sobre el contexto del
sistema software, y lo describen en un modelo de negocio. El modelo de negocio especifica
qué procesos de negocio soportará el sistema. Aparte de identificar los objetos del
dominio o del negocio implicados en el negocio, este modelado también establece las
competencias requeridas en cada proceso: sus trabajadores, sus responsabilidades, y las
operaciones que llevan a cabo. Por supuesto, este conocimiento es decisivo en la

identificación de los casos de uso

CAPTURAR REQUISITOS FUNCIONALES

La técnica inmediata para identificar los requisitos del sistema se basa en los casos de uso.
Estos casos de uso capturan tanto los requisitos funcionales como los no funcionales que

son específicos de cada caso de uso

Para el usuario, un caso de uso en un modo de utilizar el sistema. En consecuencia, si los
analistas pueden describir todos los casos de uso que necesita el usuario, entonces saben

lo que debe hacer el sistema

Cada caso de uso representa una forma de usar el sistema. Cada usuario necesita varios
casos de uso distintos, cada uno de los cuales representa los modos diferentes en los
cuales él o ella utilizan el sistema. La captura de los casos de uso que realmente se quieren
para el sistema, como aquellos que soportarán el negocio y que el usuario le permiten

trabajar “cómodamente” requiere que conozcamos en profundidad las necesidades del

 Página 65

usuario y del
entrevistar cliente.
a los Paradiscutir
usuarios, hacerlopropuestas,
tenemos que comprender el contexto del sistema,
etc.
Página 66
 Página 67

 DESARROLLO DE UN MODELO DE DOMINIO

El objetivo del modelado del dominio es comprender y describir las clases más importantes
dentro del contexto del sistema. Los dominios de tamaño moderado normalmente requieren

entre 10 y 50 de esas clases. Los dominios más grandes pueden requerir muchas más.
Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se
guardan en definiciones en un glosario de términos; de otra manera, el modelo de dominio
de haría demasiado grande y requerirían más esfuerzo del necesario para esa parte del
proceso. El glosario y el modelo del dominio ayudan a los usuarios, clientes,

desarrolladores, y otros interesados a utilizar un vocabulario común

También es necesaria una llamada de atención sobre el modelado del dominio. Puede ser
bastante fácil el comenzar modelando las partes internas de un sistema y no su contexto.
Por ejemplo, algunos objetos del dominio podrían tener una representación inmediata en
el sistema, y algunos analistas del dominio podrían a su vez caer en la trampa de
especificar los detalles relativos a esa representación. En casos como éstos, es muy
importante recordar que el objetivo del modelado del dominio es contribuir a la
comprensión del contexto del sistema, y por lo tanto también contribuir a la comprensión
de los requisitos del sistema que se desprenden de este contexto. En otras palabras, el
modelado del dominio debería contribuir a una comprensión del problema que se supone

que el sistema resuelve en relación al contexto

 USO DEL MODELO DEL DOMINIO

 Página 68

 LA COMPRENSIÓN
MODELO DEL CONTEXTO DEL SISTEMA MEDIANTE UN
DEL NEGOCIO
El modelado del
organización. negocio
Pero, ¿qué es una
pasa si técnica
tratamospara
concomprender
un sistema los procesos
que no¿qué de negocio
tienedeberíamos
nada que verdecon
la lo
que la mayoría
desarrollo de undemarcapasos,
nosotros considera
de un un negocio?
sistema de Por anti-bloqueos,
frenos ejemplo, etc.? En hacer
estos en el
casos,
también
Este podemos
sistema (partemodelar
del el sistema
cuerpo humano, que rodea
parte de el
unsistema software
coche, etc.) es elque vamos DE
“SISTEMA a desarrollar.
NEGOCIO”
del sistema software empotrado.
El objetivo esel identificar
comprender contexto. Ellos casos dedeuso
resultado estaque podríamos
actividad modelar
es un que
modelo sólo
de lo necesario
dominio para
derivado de
la comprensión del funcionamiento del “sistema de negocio” lo rodea

 ¿QUÉ ES UN MODELO DE NEGOCIO?

En primer lugar, un modelo de casos de uso del negocio describe los procesos de negocio
de una empresa en término de casos de uso del negocio y actores del negocio que se
corresponden con los procesos del negocio y los clientes, respectivamente. Al igual que le
modelo de casos de uso para un sistema software, el modelo de casos de uso del negocio
presenta un sistema (en este caso, el negocio) desde la perspectiva de su uso, y

esquematiza cómo proporciona valor a los usuarios (en este caso, sus clientes y socios)
Un modelo de objetos del negocio es un modelo interno a un negocio. Describe cómo caso
de uso de negocio es llevado a cabo por parte de un conjunto de 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 mostrarse en diagramas de interacción y de diagramas de

actividad
Una ENTIDAD del negocio representa algo, como una factura, que lo trabajadores toman,
inspeccionan, manipulan, producen o utilizan en un caso de uso del negocio. Una UNIDAD
DE TRABAJO es un conjunto de esas entidades que conforman un todo reconocible para

un usuario final
 Página 69

 CÓMO DESARROLLAR UN MODELO DE NEGOCIO

Un modelo del negocio ser desarrolla, por tanto, en dos pasos:

1. Los modeladores del negocio deben confeccionar un modelo de casos de uso del
negocio que identifique los actores del negocio y los casos de uso del negocio que
utilicen los actores. Este modelo de casos de uso del negocio permite a los

modeladores comprender mejor qué valor proporciona el negocio a sus actores

2. Los modeladores deben desarrollar un modelo de objetos del negocio compuesto
por trabajadores, entidades del negocio, y unidades de trabajo que juntos realizan
los casos de uso del negocio. El objetivo es crear trabajadores, entidades del
negocio, y unidades de trabajo que realicen los casos de uso del negocio de la

manera más eficaz posible

El modelado
podemos del negocio
pensar y el modelado del dominio se parecen en muchos aspectos. De hecho
del negocio,
entidades delen laencual
negocio
el modelado del dominio
nosnecesitan
que centramosusarsólo
como
los en
en una variante
las “cosas”,
trabajadores es decir,simplificada del dominio
las clases de modeladoo
Sin embargo,
modelado delexisten
dominioalgunas diferencias importantes entre el modelado del negocio y el
 Las clases delodominio
del dominio, se obtienen
posiblemente de la base del
del conocimiento conocimiento
asociado de unos
conlado,
sistemas pocos expertos
similares al quede
estamos
los desarrollando.
clientes delEstas
negocio, Las entidades
identificando del casos
los negocio,
de por del
uso otro seyderivan
negocio, después a buscando
partir
las entidades.
clases, asociaciones, dos técnicas
atributos y normalmente
operaciones. acaban
La técnicacon
de conjuntos
modelado diferentes
del de
dominio
puede hacer
técnica dedella traza de
modelado las clases puede
hasta la experiencia de los expertos del dominio. La
elemento modelodelhastanegocio
los clientes hacer la traza de la necesidad de cada
 Página 70

 Las clases delNodominio

operaciones. tienelasatributos
entidadespero
del normalmente ninguna o muy pocas
negocio no sólo es
participarán
así para
identifica las entidades sino negocio.
también La técnica
todos de modelado
los trabajadores del
que
entidades en la realización de los casos de uso del negocio que utilizan a las
 Los trabajadores
partida para en identificados
derivar un primerEstoen el modelado
conjunto del negocio
de actores y casos se utilizan
dedeuso como
para punto de
el sistema
información
casos uso delconstrucción.
denegocio, sistema de nos permite
información, hacer
a través de la traza
los cada
trabajadores uno
y losde los dede
casos
uso del
modelado hasta
del negocio los clientes
ypermite
la técnica del negocio. Por tanto,
de Ingeniería de Software podemos concluir
combinadosdel en el el a
que
Proceso
lo Unificado nos a hacer
travéseldeseguimiento
procesos dede las necesidades
trabajadorescliente
delardo del camino
uso, hasta completo
el código del software negocio, y casos

- BÚSQUEDA DE CASOS DE USO A PARTIR DE UN MODELO DEL NEGOCIO

Mediante la utilización de un modelo del negocio como entrada, un analista emplea una

técnica sistemática para crear un modelo de casos de uso tentativo.

 En primer lugar, el analista identifica un ACTOR por cada trabajador y por cada

actor del negocio que se convertirá en usuario del sistema de información

 Cada trabajador que vaya a ser usuario del sistema de información requerirá un

soporte por parte del mismo

 Para cada trabajador, identificamos todas las realizaciones de casos de uso del
negocio diferentes en las que participa. El trabajador cumple un papel en cada una,
de forma muy parecida al papel que desempeña una clase en cada realización de

cada caso de uso

Una vez que hemos encontrado todos los roles de un trabajador o de un actor de negocio,
uno por cada caso de uso del negocio en el que participa, podemos encontrar los casos de

uso de los actores del sistema en el sistema de información

 Cada trabajador y cada actor del negocio se corresponde con un actor del sistema de
información. Por cada papel de un trabajador o un actor del negocio, necesitamos un

caso de uso para el actor del sistema correspondiente

 Por lo tanto la manera más directa de identificar un conjunto tentativo de casos de
uso es crear un caso de uso para el actor correspondiente a cada rol de cada
trabajador y de cada actor del negocio un caso de uso por cada trabajador y por cada

actor del sistema

 Página 71

INSTANCIAS O OBJETOS
Una INSTANCIA es una manifestación concreta de una abstracción a la que se puede
aplicar un conjunto de operaciones y que posee un estado que almacena de efecto de las

operaciones
NOTA: Normalmente, la manifestación concreta de una clase se llama objeto. Los objetos
son instancias de clases, por lo que es perfectamente apropiado decir que todos los objetos
son instancias, aunque instancias no son objetos (por ejemplo, una instancia de una

asociación no es un objeto, es sólo una instancia, también llamada enlace)

ABSTRACCIONES E INSTANCIAS
Las instancias no aparecen aisladas; casi siempre están ligadas a una abstracción. La
mayoría de las instancias que se modelen en UML serán instancias de clases (y éstas se
llaman objetos), aunque se pueden tener instancias de otros elementos, como

componentes, nodos, casos de uso y asociaciones

 Página 72

UML también
abstracta, por se utiliza para
definición, no modelar cosas
puede tener que no son
instancias tan concretas.
directas. Sin Por ejemplo,
embargo, unamodelar
seprototípica
pueden clase
instancias
clase directas
abstracta. de clases
Literalmente, abstractas
un objetopara mostrar
así no puedeelexistir.
uso dePero
una instancia
en la práctica, esa de esa
instancia
permite
abstractadar nombre a una de las instancias potenciales de los hijos concretos de esa clase

TIPOS
Una instancia tiene un tipo. El tipo de una instancia real debe ser un clasificador concreto,
pero la especificación de una instancia (que no representa a una instancia en particular)
puede ter un tipo abstracto. En la notación, el nombre de la instancia va seguido de dos

puntos y del tipo, por ejemplo, t: Transacción

El clasificador de una instancia es normalmente estático. Por ejemplo, una vez creada una
instancia de una clase, su clase no cambiará durante la vida del objeto. Sin embargo, en
algunas situaciones de modelado y en algunos lenguajes de programación, es posible
cambiar la abstracción de una instancia. Por ejemplo, un objeto Oruga podría convertirse

en un objeto Mariposa, pero de una diferente abstracción

NOTA: Durante el desarrollo es posible tener instancias sin ningún clasificador asociado,
que se puede representa como un objeto sin nombre de abstracción. Estos objetos
huérfanos se pueden introducir cuando se necesite modelar un comportamiento muy
abstracto, aunque finalmente se deben ligar instancias de abstracción si se quiere imponer

algún grado de semántica sobre el objeto

NOMBRES
Cada instancia debe tener un nombre que la distinga de las otras instancias dentro de un
contexto. Normalmente, un objeto existe en el contexto de una operación, un componente
o un nodo. Un NOMBRE es una cadena de texto, como t y miCliente. Ese nombre se le
nombre simple. La abstracción de la instancia puede tener un nombre simple (como
Transacción) o puede tener un NOMBRE CALIFICADO (como Multimedia: :Audio-Stream),
el cual consta de la abstracción precedido por el nombre del paquete en el que ésta se

encuentra
 Página 73

El nombre y elPara
Transacción. tipoun
deobjeto
un objeto forman una
(en oposición cadena
a un en la de
rol dentro notación, porestructurada),
una clase ejemplo, t: se
debe subrayar la cadena completa
 Página 74

CLASES
Una CLASE es una descripción de un conjunto de objetos que comparten los

mismos atributos, operaciones, relaciones y semántica

 Página 75

NOMBRE

ATRIBUTOS
Un ATRIBUTO es una propiedad de una clase identificada con un nombre, que describe un
rango de valores que pueden tomar las instancias de la propiedad. Una clase puede tener
cualquier número de atributos o no tener ninguno. Un atributo representa alguna
propiedad del elemento que se está modelando que es compartida por todos los objetos de
esa clase. Por ejemplo, toda pared tiene una altura, una anchura y un grosor. Un atributo es
por tanto, una abstracción de un tipo de dato o estado que puede incluir un objeto de la
clase. En un momento dado, un objeto de una clase tendrá calores específicos para cada

uno de los atributos de la clase

OPERACIONES
Una OPERACIÓN es la implementación de un servicio que puede ser requerido a cualquier
objeto de la clase para que muestre un comportamiento. En otras palabras, una operación
es una abstracción de algo que se puede hacer a un objeto y que es compartido por todos

los objetos de la clase. Una clase puede tener cualquier número de operaciones o ninguna.
 Página 76

ORGANIZACIÓN DE ATRIBUTOS Y OPERACIONES

Cuando se dibuja una clase, no hay por qué mostrar todos los atributos y todas las
operaciones de una vez, por lo que se puede abreviar una clase, es decir, se puede decidir
mostrar sólo algunos, o incluso ninguno, de sus atributos y operaciones, por lo que un
comportamiento vacio no implica que no haya operaciones o atributos, sino que se ha
decidido no mostrarlos. Se puede especificar explícitamente que hay más atributos o

propiedades que los mostrados acabando la lista con puntos suspensivos (”…”)
Para organizar mejor las listas largas de atributos y operaciones, se pueden utilizar

estereotipos para anteponer a cada grupo una categoría descriptiva

 Página 77

RESPONSABILIDADES
Una RESPONSABILIDAD es un contrato o una obligación de una clase. Al crear una clase, se
está expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el
mismo comportamiento. A un nivel más abstracto, estos atributos y operaciones son
simplemente las características por medio de las cuales se lleva a cabo las
responsabilidades de la clase, una clase SensordeTemperatura es responsable de medir la

temperatura y disparar una alarma si ésta alcanza un punto determinado

Gráficamente, las responsabilidades se pueden expresar en un compartimiento separado

al final del icono de la clase

MODELOS
Un modelo es una representación, en cierto medio, de algo en el mismo u otro medio. El
modelo capta los aspectos importantes de lo que estamos modelando, desde cierto punto
de vista, y simplifica u omite el resto. Un modelo se expresa en un medio adecuado para el
trabajo que se está realizando. Un modelo de un sistema software está construido en un
lenguaje de modelado, como UML. El modelo tiene semántica y notación y puede adoptar
varios formatos que incluyen texto y gráficos. El modelo pretende ser más fácil de usar

para ciertos propósitos que el sistema final.

¿PARA QUÉ SIRVEN LOS MODELOS?

 Para captar y enumerar exhaustivamente los requisitos y el dominio de
conocimiento de forma que todos los implicados pueden entenderlos y estar de
acuerdo con ellos
 Para pensar el diseño de un sistema
 Para capturar decisiones del diseño de una forma mutable a partir de los
requisitos
 Para generar productos aprovechables para el trabajo
 Para organizar, encontrar, filtrar, recuperar, examinar, y corregir la información en
grandes sistemas
 Para explorar económicamente múltiples soluciones

 Para simplificar visualmente los sistemas complejos

¿QUÉ HAY EN UN MODELO?

 Página 78

 SEMÁNTICA:
de El aspecto
construcciones semántico
lógicas. capta elsemánticos
Los elementos significadodel
de una aplicación como unalared
generación
El aspecto del código,
visual es la comprobación
irrelevante para la de la validez,
mayoría de las las modelo
métricassedeque
herramientas
utilizan para
complejidad,
procesan etc.
modelos. La información semántica a menudo es llamada el modelo
 PRESENTACIÓN
considerada, VISUAL:
hojeada Muestra lapor
y corregida información
los seres semánticaNo
humanos. deagrega
modo significado,
que pueda ser
sino
que
útil. organiza la presentación
Por lo tanto, para acentuar
dirigen la comprensión la organización
humana del modelo
del modelo de una manera

 CONTEXTO:
de Los más
un contexto modelos
grandesonque
artefactos
les parteen un sistema
dé significado informático
completo. y seque
utilizan
no sedentro
construyen ni de
herramientas utilizan aislados.
modelado, Son
lenguajes de un entorno
y compiladores, más Es decir,
grande
sistemas que incluye
operativos, redes, etc.

¿CUÁL ES EL SIGNIFICADO DE UN MODELO?

Un modelo es un generador de potenciales configuraciones de sistemas: los posibles
sistemas son sus extensiones o valores. Un modelo es siempre una abstracción a un cierto

nivel. Captura los aspectos esenciales de un sistema y omite algunos de los detalles.

En los modelos hay que considerar los siguientes aspectos:

 Abstracción frente al detalle
 Especificación frente a la implementación
 Descripción frente a la instancia

 Variaciones en la interpretación

NIVELES DE LOS MODELOS

Los modelos adquieren diversas formas para diferentes propósitos, y aparecen en
diversos niveles de abstracción. La cantidad de detalle del modelo debe adaptarse a uno de

los siguientes propósitos:

 GUÍAS AL PROCESO DE PENSAMIENTO: los modelos de alto nivel construidos al
principio de un proyecto sirven para enfocar el proceso del pensamiento de los

participantes y destacar determinadas opciones. Capturan requisitos y

 Página 79

representan
ayudan a los un puntoade
autores partidalashacia
explorar un diseño
opciones del sistema.
posibles Los primeros
antes demodelos
converger modelos
concepto de sistema.
por otros modelos másSegún progresa
exactos. el diseño, los primeros sonen un
sustituidos

 ESPECIFICACIONES ABSTRACTAS DE LA ESTRUCTURA ESENCIAL DE UN SISTEMA:

Los modelos es en análisis o las etapas preliminares del diseño se centran en los
conceptos y mecanismos claves del probable sistema. Se corresponden de cierta
manera con el sistema final, pero faltan los detalles que se deben agregar
explícitamente durante el proceso de diseño. El propósito de los modelos
abstractos es conseguir que los aspectos de alto nivel estén correctos, antes de

abordar los detalles más localizados

 ESPECIFICACIONES COMPLETAS DE UN SISTEMA FINAL: Un modelo de
implementación incluye suficiente información para construir el sistema. Debe
incluir, no solamente la semántica lógica del sistema y los algoritmos, las
estructuras de datos y los mecanismos que aseguran funcionamiento apropiado,
sino también las decisiones de organización sobre los artefactos del sistema que
son necesarios, permitiendo así el trabajo cooperativo de las personas y el

procesamiento por parte de las herramientas.

 EJEMPLOS DE SISTEMAS TÍPICOS O POSIBLES: Algunos bien elegidos pueden
facilitar el entendimiento a las personas, y pueden validar las especificaciones e
implementación del sistema. Una gran colección de ejemplos, sin embargo, no

elimina la necesidad de una descripción definitiva

 DESCRIPCIONES COMPLETAS O PARCIALES DEL SISTEMA: Un modelo puede ser
una descripción completa de un solo sistema, sin referencias externas. Más a
menudo se organiza como un conjunto de unidades distintas, discretas, cada una
de las cuales se puede almacenar y manipular por separado, como parte de la

descripción completa.

METAMODELO ESPECIFICACIÓN DE REQUISITOS

MODELOS DEL DOMINIO

 Página 80

Un modelo
mundo delun
real en dominio
dominio muestra (a los (o
del problema modeladores) clases
de interés). Es conceptuales
el artefacto significativas
más importante quedel
se
crea durante el análisis orientado a objetos.
La
Un identificación
modelo delunde las clases
dominio no de conceptuales
muestra forma parte
componentes del estudiobases
software, del dominio delo problema.
no se trata de
responsabilidades. conjunto diagramas que describen clasescomo
software ude datos
objetos métodos;
software con
Un
del MODELO DELenDOMINIO
mundo real es una
un dominio representación
de interés. visual de las clasesMODELOS
conceptuales u objetos
CONCEPTUALES, MODELO DE OBJETOS EL También
DOMINIOseY los denomina
MODELO DE OBJETOS DE ANÁLISIS.
Este se representa
OPERACIÓN. Puedencon un conjunto de diagramas de clases en los que NO SE DEFINE NINGUNA
mostrar:

 Objetos del dominio o clases conceptuales

 Asociaciones entre clases conceptuales

 Atributos de las clases conceptuales

PODEMOS CONSIDERAR EL MODELO DEL DOMINIO COMO UN DICCIONARIO VISUAL DE
LAS ABSTRACCIONES RELEVANTES, VOCABULARIO E INFORMACIÓN DEL DOMINIO Y
OTRA COSA A CONSIDERAR, ES QUE UN MODELO DE DOMINIO NO MUESTRA CLASES NI

ARTEFACTOS SORTWARE

MODELOS Y DESCOMPOSICIÓN DEL DOMINIO

Como los problemas del software pueden ser complejos, la descomposición es una
estrategia común para tratar ésta complejidad mediante la división del espacio del
problema en unidades fáciles de comprender, donde en el análisis orientado a objetos, la

dimensión de descomposición es fundamentalmente por cosas o entidades del dominio

CLASES CONCEPTUALES
El modelo de dominio muestra las clases conceptuales o vocabulario del dominio.
Informalmente, una clase conceptual es una idea, cosa u objeto. Más formalmente, una

clase conceptual podría considerarse en términos de su símbolo, intensión y extensión

 SÍMBOLO: palabras o imágenes que representan una clase conceptual

 INTENSIÓN: la definición de una clase conceptual

 EXTENSIÓN: el conjunto de ejemplos a los que se aplica la clase conceptual

 Página 81

IDENTIFICACIÓN DE LAS CLASES CONCEPTUALES

En el desarrollo iterativo, uno incrementalmente construye un modelo del dominio a lo
largo de varias iteraciones en la fase de elaboración. En cada una, el modelo del dominio se
limita a los escenarios anteriores y el actual en estudio, en lugar de un modelo de “gran
explosión”, en que en las primeras etapas intenta capturar todas las posibles clases
conceptuales y las relaciones. Por ejemplo, esta iteración está limitada al escenario de
pago en efectivo de Procesar Venta:, por tanto, se creará un modelo de dominio parcial

únicamente para reflejar eso

La tarea central es, por tanto, identificar las clases conceptuales relacionadas con el
escenario que se está diseñando, donde es mejor especificar en exceso un modelo de

dominio con muchas clases conceptuales de grano fino que especificar por defecto

ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES

Algunas estrategias para identificar clases conceptuales son:
 Siguiendo una lista de categorías que por lo general, son clases (esta lista está
hecha en base a la experiencia previa de otros analistas

 Identificando frases nominales en la descripción del problema

A partir del análisis anterior, obtendremos una lista de clases conceptuales candidatas del
dominio. No existe una lista “correcta”. Es una colección algo arbitraria de abstracciones y
vocabulario del dominio que el modelador considera relevantes. Luego de identificar las
clases conceptuales, se deben representar éstas en un modelo del dominio, y se deben
agregar las asociaciones y atributos que se consideren necesarios para satisfacer los

requisitos del problema.

 Página 82

UTILIZACION DE UNA LISTA DE CATEGORÍAS DE CLASES CONCEPTUALES

Categoría Clases candidatas
Tarjeta, cajero
automático
Objetos tangibles
Lugares Sucursal banco
Roles de la gente Cajero humano
Organizaciones Banco
Hechos Extracción, depósito
Registros
contratos,de finanzas,
legales Comprobante
extracción, de
resumen
saldos, cuenta de

DESCUBRIMIENTO
NOMINALES DE CLASES CONCEPTUALES MEDIANTE LA IDENTIFICACIÓN DE FRASES
Otra técnica útil
descripciones es el análisis
unlingüístico: identificar los como
nombres y frases nominales en las
candidatos. Setextuales
correspondenciadebe de cuidado
tener
mecánica
dominio
con yeste
de nombres
considerarlos
método:
a clases, y las no
clases
es posible
palabras
conceptuales
realizar
en lenguaje una o atributos
natural son
ambiguas.
aEn cualquier
departir de la caso,
uso Procesar
los casos
cal Venta
extraer estede uso enPor
análisis. formato completo
ejemplo, constituyen
se puede utilizar eluna descripción
escenario actualexcelente
del caso
 Página 83

GUIAS PARA EL MODELADO DEL DOMINIO

COMO HACER UN MODELO DE DOMINIO

Aplique los siguientes pasos para crear un modelo de dominio:

1. Liste las clases conceptuales candidatas utilizando las técnicas de la Lista de
Categorías de Clases Conceptuales y la identificación de frases nominales

relacionadas con los requisitos actuales en estudio

2. Represéntelos en un modelo de dominio

3. Añada las asociaciones necesarias para registrar las relaciones que hay que

mantener en memoria

4. Añada los atributos necesarios para satisfacer los requisitos de información

ERROR TÍPICO EN LA IDENTIFICACIÓN DE LAS CLASES CONCEPTUALES

Quizás el error más típico al crear el modelo del dominio es representar algo como un
atributo cuando debería hacer sido un concepto. Una regla empírica para ayudar a

prevenir este error es:

Si no consideramos alguna clase conceptual X que sea un número o texto en el mundo
real, X es probablemente una clase conceptual, no un atributo
Como ejemplo,
separada ¿debería
de Tienda ? ser la tienda un atributo de Ventas, o una clase conceptual

En el mundo real, una tienda no se considera un número o un texto – el término sugiere una
conceptolegal, una organización, y algo que ocupa espacio –. Por tanto, Tienda debe ser un
entidad

MODELADO DEL MUNDO IRREAL

Algunos sistemas son para dominios que presentan muy poca analogía con dominios
naturales. Se puede de todas formas crear un modelo del dominio, pero requiere un alto

grado de abstracción y olvidarse de diseños familiares.

 Página 84

Por ejemplo, algunasson:

telecomunicaciones de las clases conceptuales
Mensaje, candidatas
Conexión, Puerto, relacionadas
Diálogo, con conmutadores de
Ruta, Protocolo.

UMLysusvistas

UML es un lenguaje para

 Visualizar: cada símbolo de la notación UML tiene una semántica, para que se
pueda interpretar.
 Especificar: construye modelos específicos, no ambiguos, completos.
 Construir: permite realizar ingeniería directa a lenguajes de programación,
ingeniería inversa, simulación.

 Documentar: produce artefactos que son entregables durante todo el proceso.

los artefactos de un sistema con gran cantidad de software

Un LENGUAJE DE MODELADO es un lenguaje cuyo vocabulario y reglas se centran en la

representación conceptual y física de un sistema

El modelo de UML proporciona una comprensión de los sistemas; a veces para
comprender cualquier cosa, a menudo se necesitan múltiples modelos conectados entre sí.
Para sistemas con gran cantidad de software, se requiere un lenguaje que abarque las
diferentes vistas de la arquitectura de un sistema conforme evoluciona a través del ciclo

de vida del desarrollo de software

Un proceso bien definido guiará a sus usuarios al decidir qué artefactos producir, qué
actividades y qué personal se debe emplear para gestionarlos, y cómo usar esos artefactos

para medir y controlar el proyecto de forma global

UML es un lenguaje para visualizar

Muchos programadores piensan algo y luego lo codifican, dejando muy poco o casi nula
documentación de lo que realizó. Sin embargo, esto plantea algunos problemas. 1ro, la
comunicación de esos modelos conceptuales a otros está sujeta a errores a menos que
cualquier persona implicada hable el mismo lenguaje. Normalmente, los proyectos y las
organizaciones desarrollan su propio lenguaje, y es difícil comprender lo que está pasando

para alguien nuevo en la empresa.

2do, hay cuestiones sobre un sistema software que no se puede entender a menos que se

construyan modelos que trasciendan el lenguaje de programación textual

3ro, si el desarrollador que escribió el código no dejó documentación escrita sobre los
modelos que había en su cabeza, esa información se perderá, o será parcialmente

reproducido a partir de la implementación, una vez que el desarrollador se haya marchado

Algunas cosas se modelan mejor textualmente; otras se modelan de forma gráfica. En

realidad, en todos los sistemas interesantes hay estructuras que trascienden de lo que
 Página 85

puede serUML
gráficos, representado
tiene una en un lenguaje
semántica bien de programación.
definida, y se estáUML
bienesdesarrollado,
un de estos lenguajes
se puede
interpretar sin ambigüedad

UML es un lenguaje para construir

UML no es un lenguaje de programación visual, pero sus modelos pueden conectarse de

forma directa a una gran variedad de lenguajes de programación. Esto significa que es
posible establecer correspondencias desde un modelo UML a un lenguaje de programación

como JAVA, C++ o Visual Basic

Esta correspondencia permite ingeniería directa: la generación de código a partir de
modelo de UML en un lenguaje programación. Lo contrario también se posible: se puede

reconstruir un modelo en UML a partir de una implementación

UML es un lenguaje para documentar

Una organización de software que trabaje bien produce toda clase de artefactos, además

de código ejecutable. Estos artefactos incluyen:

 Requisitos
 Arquitectura
 Dueño
 Diseño
 Código fuente
 Planificación de proyectos
 Pruebas
 Prototipos

 Versiones
UML cubre la documentación de la arquitectura de un sistema y todos sus detalles. Este
también proporciona un lenguaje para expresar requisitos y pruebas. Por último,
proporciona un lenguaje para modelar las actividades de planificación de proyectos y

gestión de versiones

BLOQUES BÁSICOS DE UML

El vocabulario de UML incluye tres clases de bloques básicos

1. Elementos: son abstracciones que constituyen los ciudadanos de primera clase en
un modelo
2. Relaciones: son aquellos que ligan estos elementos entre sí

3. Diagramas: estos agrupan colecciones interesantes de elementos

 Página 86

ELEMENTOS EN UML

Elementos Estructurales o Clasificadores: Son las partes estáticas de los modelos

 CLASE: Es una descripción de un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semántica, donde una clase implementa una o

más interfaces
 INTERFAZ: Es una colección de operaciones que especifican un servicio de una
clase o componente. Por tanto, una interfaz describe el comportamiento visible
externamente de ese elemento. Este puede representar el comportamiento
completo de una clase o componente o sólo una parte de ese comportamiento. La

interfaz define un conjunto de especificaciones de operaciones

 COLABORACIÓN: Define una interacción y es una sociedad de roles y otros
elementos que colaboran para proporcionar un comportamiento cooperativo
mayor que la suma de los comportamientos de sus elementos. Una clase dada o un
objeto puede participar en varias colaboraciones. Estas colaboraciones

representan la implementación de patrones que configuran un sistema

 CASO DE USO
- Clase Activa: Es una clase cuyos objetos tienen uno o más procesos o hilos de

ejecución y, por tanto, pueden dar origen a actividades de control.

- Componente: Es una parte modular del diseño del sistema que oculta su

implementación tras un conjunto de interfaces externas.

- Artefacto: Es una parte física y reemplazable de un sistema que contiene
información física. Un artefacto representa típicamente el empaquetamiento

físico de código o información en tiempo de ejecución.

- Nodo: Es un elemento físico que existe en tiempo de ejecución y representa un
recurso computacional, que por lo general dispone de algo de memoria y/o

capacidad de procesamiento.

Elementos de Comportamiento: Son las partes dinámicas de los modelos

 Interacción: Es un comportamiento que comprende un conjunto de mensajes
intercambiados entre un conjunto de objetos, dentro de un contexto particular,

para alcanzar un propósito específico.

 Página 87

 Máquina
por depasa
las que Estados: Es un comportamiento
un objeto durante su vida enque especifica
respuesta las secuencias
a eventos. Puede de estados
incluir
transiciones, eventos, acciones.
 Actividad:
proceso. Es un comportamiento que especifica la secuencia de pasos que ejecuta un

Elementos de Agrupación: Son las partes organizativas de los modelos UML

 Paquete: Es puramente conceptual (sólo existe en tiempo de desarrollo).

Elementos de Anotación: Son las partes explicativas de los modelos UML

 Nota: Muestra comentarios

Relaciones
 Dependencia: Es una relación semántica entre 2 elementos, en la cual un cambio al

elemento independiente puede afectar a la semántica del elemento dependiente

 Asociación: Es una relación estructural entre clases que describe un conjunto de
enlaces, los cuales son conexiones entre objetos. Algunos tipos especiales de

asociación son la composición y agregación.

 Generalización: Es una relación de especialización, en la cual el elemento
especializado (hijo) se basa en la especificación del elemento generalizado

(padre). El hijo comparte la estructura y el comportamiento del padre

 Realización: Es una relación semántica entre clasificadores, en donde un

clasificador especifica un contrato que otro clasificador garantiza que cumplirá.

 Existen variaciones entre las cuatro anteriores, como la inclusión y extensión.

Diagramas de…
 Clases: Muestra un conjunto de clases, interfaces y colaboraciones, así como sus

relaciones. Abarcan la vista de diseño estática de un sistema

 Objetos: Muestra un conjunto de objetos y sus relaciones. Representan

instantáneas estáticas de instancias de los elementos de un diagrama de clases.

 Componentes: Representa la encapsulación de una clase, juntos con sus interfaces,
puertos y estructura interna. Abarcan la vista de implementación estática del

diseño de un sistema
 Casos de Uso: Muestra un conjunto de CU, sus actores y relaciones. Abarcan la vista

de casos de uso estática de un sistema.

 Página 88

 De interacción
dinámica de un(Secuencia y Comunicación/Colaboración):
sistema. Muestran Cubren
el flujo de mensajes entre la vista
objetos.

 Estados: Muestra una máquina de estados. Abarca la vista dinámica de un objeto.

 Actividades: Muestra la estructura de un proceso. Abarca la vista dinámica.

 Despliegue: Muestra la configuración de nodos de procesamiento en tiempo de
ejecución y los artefactos que residen en ellos. Abarcan la vista de despliegue

estática de una arquitectura.

 Paquetes: Muestra la descomposición del propio modelo en unidades organizativas

y sus dependencias
 Tiempos: Es un diagrama de interacción que muestra las tiempos reales en el

sistema.
 Visión Global de Interacciones: Es un híbrido entre un diagrama de actividades y

uno de secuencia.

REGLAS DE COMBINACIÓN DE BLOQUES

UML tiene reglas sintácticas y semánticas para:

 Nombres: Cómo llamar a los elementos, nombres y diagramas
 Alcance: El contexto que da un significado específico a un nombre
 Visibilidad: Cómo se pueden ver y utilizar esos nombres por otros
 Integridad: Cómo se relacionan apropiada y consistentemente unos elementos con
otros

 Ejecución: Qué significa ejecutar o simular un modelo dinámico

MECANISMOS COMUNES EN UML

UML incorpora 4 mecanismos para simplificar la modelización:

Especificaciones: Implica la representación de un concepto mediante una figura. Ej: El

óvalo de caso de uso, rectángulo de 3 compartimientos de clase, etc.

Adornos: Ej: símbolos +,-,# en atributos de clase

Divisiones Comunes: Utilizar con una misma forma gráfica 2 conceptos

Mecanismos de Extensibilidad

 Estereotipos: Construcción de nuevos bloques a partir de bloques ya existentes

 Página 89

 Valores Etiquetados: Son detalles agregados

 Restricciones

ARQUITECTURA

La arquitectura de un sistema puede describirse mediante 5 vistas:

1. Vista de Casos de Uso: Comprende los casos de uso que describen el comportamiento del
sistema tal y como es percibido por los usuarios finales, analistas y encargados de las
pruebas. Esta vista no especifica realmente la organización de un sistema software.
a. Aspectos Estáticos Diagrama de Casos de Uso

b. Aspectos Dinámicos Diagramas de Interacción, Estados y Actividades

2. Vista de Diseño: Comprende las clases, interfaces y colaboraciones que forman el
vocabulario del problema y su solución. Esta vista soporta principalmente los requisitos
funcionales del sistema.
a. Aspectos Estáticos Diagramas de Clases y Objetos

b. Aspectos Dinámicos Diagramas de Interacción, Estados y Actividades

3. Vista de Interacción: Muestra el flujo de control entre sus diversas partes. Abarca el
rendimiento, escalabilidad y capacidad de procesamiento del sistema. Los aspectos son los

mismos que en la vista de diseño.

4. Vista de Implementación: Comprende los artefactos que se utilizan para ensamblar y
poner en producción el sistema físico.
a. Aspectos Estáticos Diagramas de Artefactos

b. Aspectos Dinámicos Diagramas de Interacción, Estados y Actividades

5. Vista de Despliegue: Contiene los nodos que forman la topología hardware sobre la que
se ejecuta el sistema. Esta vista se ocupa de la distribución, entrega e instalación de las
partes que constituyen el sistema físico.
a. Aspectos Estáticos Diagramas de Despliegue

b. Aspectos Dinámicos Diagramas de Interacción, Estados y Actividades

LA VISTA ESTÁTICA
La vista estática es la base de UML. Los elementos de la vista estática de un modelo son
todo tipo de conceptos encontrados en los sistemas. Esta vista captura la estructura del
objeto, e incluye todo lo concerniente a las estructuras de datos tradicionales, así como la
organización de las operaciones sobre los datos. Los datos y las operaciones son

cuantificados en clases.
 Página 90

La vista estática describe

comportamiento entidades
dinámico. Los tratade comportamiento,
como pero
elementos para serno contiene los
nombrados, detallespor
poseídos de las
su
clases e invocados.

Hay 2 elementos clave en esta vista:

1. Clasificadores

Un clasificador es un concepto discreto en el modelo, que tiene identidad, estado,

comportamiento y relaciones. Algunos clasificadores son las clases, actores, rol,

componente, caso de uso, nodo, señal, interfaz, etc.

2. Relaciones
 Asociación: Lleva la información entre objetos en un sistema. Sin asociaciones,
habrían sólo clases aisladas. Una clase se puede asociar a sí misma, o hacia otra
clase. Los extremos de la asociación pueden tener multiplicidad, es decir, cuántas
instancias de una clase se pueden relacionar con una instancia de otra. Si una
asociación puede tener atributos por sí misma, surge una clase asociativa. Durante
el análisis, las asociaciones representan relaciones lógicas entre objetos. La

asociación se representa con una línea continua.

Hay 2 subtipos:
o Agregación: Es una asociación que representa una relación todo-parte. Se muestra
adornado

con un diamante hueco en el extremo de la trayectoria unida a la clase agregada

o Composición: Es una asociación más fuerte, en la cual el compuesto es el responsable
único
de gestionar sus partes. Se muestra con un diamante relleno adornando el extremo

compuesto.
 Generalización: Es una relación taxonómica entre una descripción más general
(padre) y una descripción más específica (hijo), que se construye sobre ella y la
extiende. La descripción más específica es completamente consistente con la más
general, y puede contener información adicional. En el caso de clases, se habla de
superclase y subclase. Una generalización se dibuja como una flecha que va desde

el padre al hijo, con un triángulo hueco en el extremo del padre.

La generalización tiene 2 propósitos:
o Principio de sustitución (del padre por el hijo, que es más especializado), lo que
posibilita el polimorfismo

o Permitir la herencia
 Página 91

 Realización: Conecta
comportamiento, unno
pero elemento del modelo
su estructura con otro que especifica
o implementación. su una flecha de
Se indica con
línea discontinua con una punta hueca cerrada
 Dependencia:
Indica una Indica una
situación, en larelación
cual semántica
cambio al entre dos oproveedor
más elementos del modelo.
cambio o indicar un cambio en un
el significado elemento
del elemento cliente puede requerir un
en la dependencia.