SISTEMA

Conjunto de elementos dinámicamente relacionados entre si que realizan una actividad para llegar a una meta, operando
sobre entradas y produciendo salidas al medio circundante. Cada sistema está compuesto por subsistemas, y es, a su vez,
subsistema de un sistema mayor.
El comportamiento de cada elemente de un sistema afecta al sistema y cada una de las partes. Ningún sistema está totalmente
aislado, por lo tanto ningún subsistema tiene un efecto independiente sobre el sistema.
El comportamiento del sistema esta definido por el comportamiento de sus partes y sus interacciones.

 Objetivos: Son necesarios para medir la efectividad de los sistemas.

 Elementos: Son unidades u objetivos que forman el sistema
 Relaciones entre los elementos: Son los lazos que unen los elementos

La jerarquía de los sistemas establece que un sistema es de mayor jerarquía que otro, cuando necesita que este último alcance
sus objetivo para poder alcanzar los propios.

Principales niveles:
 Macrosistema: Es determinado universo o contexto o medio ambiente
 Subsistema: Es un sistema de nivel inclusión inferior o parte del sistema.
 Sistema elemental: Es de menor jerarquía y no es necesita factorizarlo.
 Sistema de caja negra: Sistema que no puede ser factorizado. Ej.: competencia

Los sistemas se pueden clasificar según varios criterios:

 Según su complejidad:
o Simples: Poseen pocos componentes e interrelaciones. Comportamiento previsible. Ej.: Billar
o Complejo: Altamente elaborados y profundamente interrelacionados. Comportamiento previsible. Ej.:
Computadora
o Muy complejos: Extremadamente complicados y que no pueden ser descriptos en forma precisa y
detallada. Ej.: Economía, Cerebro.
 Según su determinación:
o Determinísticos: Conocemos con certeza su comportamiento.
o Probabilísticos: Se puede proveer como será su comportamiento.

 Según su naturaleza:
o Físicos
o Abstractos

 Según su iteración con el medio:

o Abiertos: Presentan intercambio.
o Cerrados: No reciben nada del ambiente y por lo tanto no influyen en él.

 Según su generación: (causa de su nacimiento)

o Artificiales
o Naturales

 Según su dinamismo: (posibilidad de cambiar con el transcurso del tiempo)

o Estables
o Adaptativos
Características de los sistemas:
 Propósito u objetivo: Todo sistema tiene al menos un propósito u objetivo.
 Globalismo o totalidad: Cualquier estimulación en cualquier unidad del sistema afectará todas las demás unidades,
debido a la relación existente entre ellas.
 Entropía: Es la tendencia que los sistemas tienen al desgaste, a la desintegración, y a un aumento de la aleatoriedad.
 Homeostasis: Es el equilibrio dinámico entre las partes del sistema. Los sistemas tienen una tendencia a adaptarse con el
fin de alcanzar un equilibrio interno frente a los cambios externos del ambiente.

Frontera o Límite:
El limite determina unívocamente todo lo que esta bajo el control del sistema y lo que no pertenece a el. Como ningún sistema
esta totalmente aislado, mientras no se defina sus fronteras se corre el peligro de definir uno demasiado grande para los
propósitos del estudio.
Limite Interno es el conjunto de subsistemas que desde el punto de vista del diseño deben considerarse como partes. El límite
interno separa los subsistemas entre sí.

Ambiente o Medio:
Se refiere al conjunto de objetos exteriores que rodean y contienen al sistema en cuestión. Esta integrado por todos los
sistemas sobre los cuales no se tiene control y no están incluidos en el sistema.

SISTEMA DE INFORMACIÓN
Es el conjunto de recursos humanos, tecnológicos, materiales, financieros, metodológicos, organizados para brindar a quienes
toman decisiones en una organización, la información necesaria para llevar a cabo sus respectivas funciones.
Un sistema de información es capaz de recolectar, almacenar, procesar y distribuir todos los datos relativos a la información de
la Empresa.

Clasificación de la SI

Nivel
Estratégico
DSS
Decisiones No Estructuradas

Nivel Táctico
MIS
Decisiones Estructuradas

Nivel Operativo
TPS
Decisiones Acotadas

Al cuadro se puede agregar un nivel más, que es el nivel de dirección operativo.

Decisiones:
No Estructuradas: Cuando no existen procedimientos claros para tomarla y tampoco es posible identificar con anticipación
todos los factores que deben tenerse en cuenta.
Estructurada: Se conocen de antemano los factores a tener en cuenta, como así también las variables con influencia en el
resultado de la decisión.
Acotadas: Cuando se tiene poco tiempo para tomarlas y tienen poco alcance.

Tipos de Sistemas de Información:

Transaction Procesing Systems (TPS): Los TPS liberan del tedio y la rutina de las tareas que se realizan manualmente, sin
embargo el elemento humano realiza la captura de la información. En términos generales los TPS realizan las operaciones
rutinarias de la organización. Brindan velocidad y exactitud, ejecutan tareas como cálculos, clasificación, ordenamiento,
generación de resúmenes, almacenamiento y recuperación.
Management Information Systems (MIS): El MIS ayuda a los directivos a tomar decisiones y a resolver problemas. Los
directivos recurren a los datos almacenados como consecuencia del TPS. Los MIS ayudan a tomar decisiones ESTRUCTURADAS,
combinando la información proporcionada por los TPS con otros de naturaleza externa (tendencia económica, demandas y costo
d préstamos).
Decision Support Systems (DSS): Ayudan a los directivos a tomar decisiones SEMI-ESTRUCTURADAS. Estos sistemas deben
tener una flexibilidad mayor para el soporte de decisiones que los demás sistemas. Además el DSS ayuda pero no reemplaza el
criterio de directivo, la decisión en si depende de la persona responsable.
Office Automation Systems (OAS): Incluye todos los sistemas electrónicos formales e informales cuya función principal es la
comunicación de información entre personas adentro y afuera de la compañía.
Sistemas basados en el conocimiento (IA - SE): El SE captura y en efecto utiliza los conocimientos de un experto para la
solución de un problema particular de la organización. A diferencia del DSS, el SE selecciona la mejor solución al problema y
también tiene la capacidad de explicar la línea de razonamiento que utilizo para llegar a dicho solución.
Executive Support Systems (ESS): Proporciona información del comportamiento global de la empresa. El ESS se caracteriza por
extraer y comprimir un amplio rango de información, ganando tiempo para el ejecutivo, y por su habilidad para remarcar
factores claves.

Rol del sistema de Información dentro de la Organización

Asegurar la máxima flexibilidad de la organización para adaptarse a los cambios de un contexto cuyas características son la
innovación o inestabilidad. Hay que diferenciar muy bien los objetivos de la organización, del sistema de información y del
software.

Objetivos de la Organización

Objetivos del Sistema de Información

Objetivos del Software

Dato e Información
Dato: Es una representación de un hecho o de cifras en bruto. El dato representa un termino de un mensaje que en si mismo
no lleva ninguna información.
Información: Es cualquier conocimiento o mensaje útil para la decisión y la acción, o bien, el significado derivado de los datos.
Cuando un conjunto de datos posee significado tenemos información.
La información reduce la incertidumbre y brinda el conocimiento necesario para la orientación en una decisión.
La principal diferencia entre la información y el dato es que este ultimo no por si solo no tiene significado.

Economía de la información
Es la forma en que la información añade valor a la empresa y la relación entre el valor y el coste de la información.
La información añade valor a través de medios como reducción de costos de producción, unos ingresos incrementados y
mejores decisiones. Pero a su vez cuesta dinero en forma de salarios, equipo, compra de programas, lugar físico, etc.

Eficiencia y Eficacia
La eficiencia depende del equilibrio entre el valor y el coste de un sistema. La eficacia depende solamente del costo de
alcanzar un determinado conjunto de especificaciones. La eficiencia es una cuestión de gestión. La eficacia es una cuestión
técnica.

EFICIENCIA  EFICACIA

Objetivos del SI
Todo sistema organizacional depende, en mayor o menor medida, de un sistema de información que es el medio por el cual
los datos fluyen de una persona o departamento hacia otros.
Los sistemas de información proporcionan servicio a todos los demás sistemas de una organización y enlazan todos los
componentes en forma tal que estos trabajen con eficiencia para alcanzar el mismo objetivo.

Alcance: Es todo lo que forma parte del estudio del análisis de sistemas.

Diferencias entre Estrategia y Táctica: En la estrategia se define el objetivo, la meta. En la táctica se define que se va a hacer
para alcanzar o lograr esos objetivos.

Factores Críticos para el Éxito (FCE): Son actividades que si o si deben cumplirse para lograr los objetivos y estos cambian con
el tiempo.
PROYECTO
Es un conjunto de etapas, actividades y tareas para alcanzar un objetivo que implica un trabajo no inmediato, a un plazo
relativamente largo. Todo proyecto tiene un principio, un final y un objetivo. Sus actividades son únicas y esencialmente no
repetitivas y requieren de un jefe de proyecto, así como también de personal de desarrollo.
Todo proyecto está planificado, y su progreso se mide en comparación al plan. Existen fuerzas internas y externas, que deben
identificarse y tratarse, ya que influyen en él. Un proyecto suele coexistir con otros proyectos contra los cuales compite por
recursos. Esto se debe a que usa diversos recursos finitos y cuenta con un presupuesto.
Un proyecto se diferencia de una operación, en que esta está en constante existencia y son repetitivas.

Proyecto de Software
La finalidad del proyecto es iniciar, administrar, dirigir y controlar las actividades asociadas con el desarrollo de sistemas, para
conseguir mejores resultados por el aprovechamiento óptimo de los recursos de tiempo, capacidad humana y presupuesto. El
software no se fabrica en un sentido clásico, sino que se desarrolla y su construcción es un proceso de resolución de problemas
que implica la transformación de una necesidad en una solución automatizada que satisface la necesidad
Generalmente, las razones para comenzar un proyecto de sistemas de información se pueden dividir en tres categorías,
pudiendo darse más de una a la vez:
Resolver un problema: Las actividades, procesos o funciones actuales no funcionan (o quizá en el futuro) dentro de los
estándares establecidos o no satisfacen las expectativas, debiendo emprender una acción que resuelva las dificultades.
Este motivo de inicio de proyecto no siempre se debe a que haya certeza de que existe un problema, bien pudiendo ser que se
presuma que existe un problema, ó que se lo quiere prevenir.
Aprovechar una oportunidad: El sistema sería un cambio para ampliar o mejorar la capacidad económica del negocio y
aumentar la competitividad de la empresa en el mercado.
Dar repuestas a directivos: El sistema servirá para proporcionar información en respuesta a ordenes, solicitudes o mandados
de una autoridad legislativa o administrativa; llevar a cabo tareas de cierta manera; ó también cambiar la información o el
desempeño.

Las cinco C:

•Mayor velocidad de procesamiento. El uso de la capacidad de la computadora para calcular, ordenar y

recuperar datos e informacion; y efectuar rapidamente tal tarea.
•Incremento en el volumen. Dar la capacidad de procesar varias actividaes para aprovechar oportunidades
Capacidad comerciales que suelen ser producto del crecimiento de la empresa, que exede las capacidades y
procedimientos anteriores.
•Recuperación más rápida de la información. Localización y recuperación de información del sitio donde se
encuentra alamcenada y llevar a cabo búsquedas complejas.

•Mayor exactitud y mejora de la consistencia. Llevar a cabo los pasos de computo de una modo correcto y
estructurado.
Control •Proveer mayor seguridad. Resguardar datos importantes y sensibles tal que solo sea accesible por personal
autorizado.

•Mejorar la comunicación. Acelerar el flujo de información y mensajes enter localidades remotas y

dentro de la oficina.
Comunicación •Integración de las áreas de la empresa. Corrdinar las actividades que llevan a cabo n distintas áreas
mediante la captura y distribución de la información.

•Monitoreo de costos. Seguimiento de costos de todo tipo para determinar su evolución en relación con los
esperados.
Costos •Reducción de costos. Usar la capacidad de cómputo para procesar los datos con un bajo costo y
manteniendo o mejorardo el nivel de desempeño.

•Atraer Clientes. Modificar los servicios proporcionados y la relación con lso clintes de modo que estos
no opten por cambiar de proveedores..
•Dejar fuera a la competencia. Disminuir las chances de que competidores tengan acceso al mismo
mercado como consecuncia del uso que la organización les de a sus sistemas de información.
Competitividad •Mejorar acuerdos con proveedores. Cambios en precios, servicios, condiciones, etc. para el beneficio de
la organización.
•Desarrollo de nuevos productos. Introducir nuevos productos cuyas caracteristicas están influenciadas
por las nuevas tecnologías de información.
 Hay varias fuentes que pueden solicitar el comienzo de un proyecto de sistemas e información, entre ellas:
Jefes de departamento. Frecuentemente, las personas relacionadas con las actividades cotidianas de la empresa buscan
ayuda dentro de sus propios departamentos.
Altos ejecutivos. Usualmente, éstos tienen información que no está disponible para los gerentes y a su vez tienen influencia
sobre la solicitud de un sistema de información.
Analista de sistemas. Ocasionalmente, el analista busca áreas donde debe desarrollarse un sistema de información o anima a
un gerente para que este autorice la elaboración de uno.
Grupos Externos. Los acontecimientos externos a la organización también pueden conducir a la formulación de proyectos.
Diagnostica Sirven para identificar el
problema

Problema Síntomas Causas Proposición de

soluciones

Por eso nos llaman Hay que guiarse por ellas

El proceso de Software
Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para desarrollar el
software. Un pequeño número de actividades estructurales se pueden aplicar a todos los proyectos de software, sin importar el
tamaño o complejidad. Diferentes conjuntos de tareas (hitos, entregas, tareas y garantía de calidad) permiten a las actividades
estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto.

Los participantes del Proceso

El proceso (y los proyectos) de software lo componen ciertos participantes que pueden clasificarse en 5 categorías:

Gestores superiores: definen los aspectos de negocio que a menudo tienen una significativa influencia en el proyecto.
Gestores (técnicos) de proyecto: deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de
software.
Profesionales: proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.
Clientes: especifican los requisitos para la ingeniería de software.
Usuarios finales: interactúan con el software una vez que se ha entregado para la producción.

Equipo de proyecto
El jefe del proyecto
Es la persona que tiene la responsabilidad de planificar, controlar y dirigir las actividades del proyecto. Muchas veces, estas
responsabilidades suponen la coordinación e integración de actividades a través de distintas unidades organizativas y
departamentos. El jefe de proyecto debe poseer ciertas habilidades para el correcto desempeño de éste: habilidades técnicas
(conocimiento y pericia para trabajar con herramientas y técnicas específicas), habilidades humanas (para trabajar con gente y
conseguir el esfuerzo cooperativo del trabajo en equipo), habilidades conceptuales (para ver un panorama completo, reconocer
los elementos relevantes de una situación y entender las relaciones entre los elementos) habilidades de diseño (para ser capaces
de más que sólo ver un problema sino que generar una solución práctica a un problema).

Usuarios
Es aquél (aquellos) para quien se construye el sistema. El analista tendrá que entrevistar con gran detalle a fin de conocer las
características que deberá tener el nuevo sistema. Se puede hacer referencia a ellos con Clientes también.
Generalmente es fácil identificar a los usuarios: característicamente es aquél que formalmente solicita un sistema. Sin
embargo, hay situaciones en las que no se conoce la verdadera identidad del usuario y hay poca oportunidad de que éste
interactúe con el analista. Tales situaciones dan lugar a una gran posibilidad de malos entendidos debido a fallos de
comunicación. Siempre que sea posible el analista debe intentar comunicarse directamente con el usuario, aún si existen
intermediarios. Es mejor si el usuario forma parte activa del equipo encargado del proyecto.
De no ser posible, entonces la documentación generada por el analista toma mayor importancia ya que describe el
comportamiento del sistema de modo riguroso y formal. El uso de estas herramientas es vital para evitar malos entendidos
costosos.
Hay dos maneras de clasificar a lo usuarios:
Por categoría de trabajo: Un analista habitualmente debe interactuar con individuos de tres categorías de trabajo: usuarios
operacionales, usuarios supervisores y usuarios ejecutivos.
 Los primeros son oficinistas, administradores y operadores, quienes probablemente tendrán contacto diario con el nuevo
sistema. Estos se preocupan mucho por las funciones del nuevo sistema pero se preocupan aun mas por los detalles de la
interfaz humana, detalles que son vitales para el éxito del sistema y que deben ser abordados. Además este tipo de usuarios
tienden a poseer un panorama local de su papel en la organización y les cuesta decir como es que su actividad encaja dentro de
la misma, es decir un panorama global. Consecuentemente el analista debe poder desarrollar modelos de sistemas que
permitan ambos panoramas.
Los usuarios supervisores son personas que administran a usuarios operacionales y son responsables de sus logros. Suelen ser
usuarios operacionales que han sido promovidos y, por lo tanto, están al tanto del trabajo de sus subordinados y por lo tanto
están de acuerdo con sus necesidades, preocupaciones y perspectivas; aunque no siempre es así.
Generalmente este tipo de usuario se interesa en un nuevo sistema de información por la posibilidad de incrementar el
volumen de trabajo disminuyendo el costo del procesamiento de las transacciones y los errores en el trabajo.
Generalmente, es el usuario supervisor quien ve al nuevo sistema como una forma de reducir el número de usuarios
operacionales, creando conflicto en los cuales el analista puede encontrarse en el medio.
El usuario supervisor suele actuar de intermediario entre los operacionales y el analista. Esto es peligroso, ya que si este no
atiende las preocupaciones de sus subordinados, nada garantizara que la interfaz humana sea la correcta para ellos.
Es el usuario supervisor con quien el analista tendrá contacto cotidiano primario, y es quien definirá los requerimientos y las
políticas de la empresa que el sistema deberá realizar. Puede ser desde un miembro pasivo del equipo hasta el gerente del
proyecto.
Los usuarios de nivel ejecutivo no se suelen involucrar directamente con el proyecto de desarrollo del sistemas si es que este
no están amplio ni importante como para tener un impacto primordial en al empresa.
Pueden proporcionar la iniciativa para el proyecto pero es más probable que tomen el rol de financiadores de solicitudes que
se dan en niveles inferiores. No se encuentran en una posición que les permita poder definir los requerimientos del sistema ya
que no poseen la experiencia, excepto de que se trate de sistemas orientados a niveles altos de la organización.
Estos usuarios están más preocupados por los detalles estratégicos, las ganancias y pérdidas a largo plazo. A su vez, se
interesan mas por el panorama global del sistema, no se interesan por los detalles. Prefieren de las herramienta de modelados
que dan un panorama global del sistema.
Al usuario no siempre le agrada la perspectiva de un nuevo sistema, y a menudo se opondrán a el.
Por nivel de experiencia: Amateur es aquel que jamás vio una computadora y que no le agrada el contacto con ellas. Es un
reto para el analista debido a que éste no puedo utilizar su jerga para comunicarse con él. Aun cuando se evita la terminología
puede que le resulte difícil comprender las características y las funciones del sistema. Si el usuario no puede entender ni un
modelo del sistema, hay poca probabilidad de que le satisfaga el sistema cuando éste esté terminado.
Otro tipo de usuario es el novato presuntuoso, y es aquél que ha tenido que ver con uno o dos proyectos de desarrollo de
sistemas o que posee una computadora y que ha desarrollado uno o dos programas. Alega saber exactamente que quiere que el
sistema haga y suele señalar todos los errores del analista anterior, pero peca de querer señalar prematuramente las tecnologías
a utilizar.
El restante es el pequeño (pero creciente) grupo de verdaderos expertos.

Auditores
Según el tamaño del proyecto y su naturaleza, puede haber auditores, personal de control de calidad o miembros del
departamento de normas o estándares participando del proyecto. Sin embargo sus objetivos y perspectivas son los mismos.
Sus objetivos son asegurar que el sistema se desarrolle dentro de diverso normas y estándares, los cuales pueden estar
impuestos por la organización y sus miembros o pueden ser gubernamentales, entre otros.
Se deben prever tres problemas al trabajar con este tipo de participantes:
1. Generalmente no se involucran sino hasta el final del proyecto, luego de que se hay finalizado con el trabajo del
análisis, el diseño y la programación., cuando se ha comenzado con la prueba formal. A estas alturas suele ser muy
complicado realizar cambio en el sistema.
2. A menudo están familiarizados con notaciones antiguas para la documentación de requerimiento de sistemas. Debido
a esto, es necesario asegurarse que los modelos de sistemas desarrollados sean comprensibles.
3. Generalmente están más interesados en la forma que en el contenido, por lo que si los documentos no tienen la
presentación exacta podrían ser rechazados.

El analista de sistemas
Personaje clave en todo proyecto de desarrollo de sistemas, el cual desempeña varios roles:
Arqueólogo y escribano: Descubre detalles y documenta la política de un negocio que pueden existir solo como tradiciones
tribales transmitidas entre generaciones de usuarios.
Innovador: Debe distinguir entre síntomas y problemas del usuario y causas. Valiéndose de sus conocimientos de
computación, debe ayudar al usuario a explorar aplicaciones novedosas y útiles tecnológicas así como nuevas maneras de hacer
negocios.
Mediador: A menudo se encuentra entre usuarios, administradores, programadores y otros participantes, que
frecuentemente están en desacuerdo entre si. Puede serle tentador imponer u propia opinión pero su deber principal es
obtener consenso debiendo valerse de la diplomacia y la negociación.
 Jefe de proyecto: Dado que posee más experiencia que los programadores que trabajan en el proyecto, y dado que se lo
asigna al mismo antes de que éstos comiencen a trabajar, hay una tendencia natural a asignar al analista las responsabilidades
de la administración integra.
Se requiere facilidad en el manejo de personas para poder entrevistar a los usuarios, mediar en desacuerdo y sobrevivir a las
inevitables batallas políticas que se dan en todos los proyectos excepto en los triviales. Se necesita tener conocimientos de
aplicación para entender y apreciar los asuntos del usuario. Se requiere habilidad en computación para entender los usos
potenciales de hardware y software en los asuntos del usuario.

Diseñadores de sistemas
Es quien recibe los resultados del trabajo de análisis y su labor es transformar la petición en un diseño arquitectónico de alto
nivel que servirá de base para el trabajo de los programadores.
El analista y el diseñador suelen ser la misma persona o el mismo grupo de personas, y aún cuando no lo fueran es importante
que se mantengan en contacto directo durante el proyecto, debido a que es necesario que el analista ofrezca información
detallada suficiente como para que el diseñador pueda elaborar un diseño tecnológicamente superior, y a su vez es necesario
que el diseñador provea de suficiente información al analista para que este se de cuenta de si los requerimientos que el usuario
esta documentando son tecnológicamente posibles. Mucha retroalimentación rápida y constante entre ambas partes.

Los programadores
Posiblemente no haya comunicación entre el analista y los programadores, siendo los diseñadores quienes probablemente
funcionen como puente o nexo entre ambos. Esta falta de comunicación se debe a que a menudo, se lleva a cabo el trabajo
siguiendo una secuencia estricta en algunos proyectos de desarrollo de sistemas, por lo que el trabajo del analista se hace
primero y se termina por completo antes que comience la labor de programación; siendo probable que el analista ya este
asignado a otro proyecto antes de que el programador intervenga en el actual.
Aún así es probable que exista contacto por los siguientes motivos:
 En proyectos pequeños, los papeles de analista, diseñador y programador se combinan de modo que una sola
persona o grupo de personas realicen todo el trabajo.
 El analista a veces sirve de administrador del proyecto, por lo que, aun cuando su labor como analista haya concluido,
aun estará involucrado en el proyecto y tendrá algún contacto con el programador.
 Generalmente, es el programador quien descubre errores y ambigüedades en la propuesta de requerimientos que
entrega el analista. Entonces el programa puede pedirle aclaraciones al analista o bien hablar con el usuario.
 A la hora de cambiar un sistema anterior, puede ser necesario comunicarse con el programador encargado del
mantenimiento del sistema.

Administración
Existen diversos tipos de administradores:
Administradores usuarios: Son los que están a cargo de varias personas en el área operacional donde se implantara el sistema.
Son, generalmente, administradores de nivel medio que desean sistemas que produzcan una variedad de informes internos y
análisis a corto plazo.
Administradores de informática: Son las personas encargadas del proyecto en si de sistemas, y los encargados de la
administración a nivel global y distribución de recursos al personal técnico de la organización de creación/desarrollo de
sistemas.
Administración general: Administradores de nivel superior que no están involucrados con la organización de informática ni
son de la organización usuaria. Se interesan más por los sistemas de planeación estratégica o d apoyo a las decisiones y se
concentran más en la información externa.
La principal interacción entre el analista y los administradores tiene que ver con los recursos a asignar al proyecto. El deber del
analista es identificar y documentar los requerimientos del usuario y las limitaciones dentro de las que se implementará el
sistema, que generalmente son los recursos.
Generalmente los administradores, cuanto más alto sea el nivel que ocupen, menos probable es que sepan de computación.
Además las metas de lo administradores suelen entrar en conflicto con las de los usuarios pudiendo llegar a imponerles un
nuevo sistema.

El personal de operaciones
El Analista no necesitaría tener contacto con el personal de operaciones encargado 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 de la salida de las impresoras; ya que todo esto sucede luego de que tanto la labor del analista como la del diseñados y
de los programadores ha finalizado. Sin embargo el analista debe comprender las restricciones impuestas al nuevo sistema por
el personal de operaciones ya que tiene un gran impacto. En algunos casos, los detalles operacionales del sistema pueden
reducirse a una cuestión de negociación entre el usuario y el grupo central de operaciones de la computadora.
Todos los asuntos operacionales se documentan como parte de la tarea del análisis.
 Participación del Equipo en las etapas de ciclo de vida
 El cliente participa en el análisis y la planificación
 El análisis de requerimientos se va a realizar con el usuario
 El diseño lo define el diseñador con las restricciones propuestas por el usuario
 En la codificación es todo propio del equipo del proyecto.
 En las pruebas participan todos

El Ciclo de Vida del Desarrollo de Sistemas

Gran parte del enfoque sistemático del analista se incluye en el ciclo de vida del desarrollo de sistemas (SDLC), el cual es un
enfoque por fases para el análisis y el diseño cuya premisa se basa en que los sistemas se desarrollan mejor siguiendo un ciclo
especifico de actividades del analista y el usuario.
El ciclo esta dividido en siete fases, aunque ninguna se realiza aisladamente, siendo posible la realización simultánea y
repetición de algunas.

7. 1. Identificación
Implementación de problemas,
y evaluación del oportunidades y
sistema. objetivos.

2. Determinación
6. Pruebas y
de los
mantenimiento
requerimientos
del sistema.
de información.

5. Desarrollo y 3. Análisis de las

documentación necesidades del
del software. sistema.

4. Diseño del
sistema
recomendado

Identificación de Problemas, Oportunidades y Objetivos

En la primera fase del ciclo de vida el analista se ocupa de identificar problemas, oportunidades y objetivos. Esta etapa es
crítica para el éxito del proyecto ya que no sirve trabajar en un problema que no se quiere resolver.
Requiere que el analista observe objetivamente lo que sucede en un negocio. Luego, con otros miembros de la organización,
determina con precisión cuales son los problemas. Frecuentemente los problemas son detectados por otras personas siendo
esta la razón por la que se llama al analista.
Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información
computarizados, que de ser aprovechadas permitirían que la empresa obtenga alguna ventaja competitiva o establecer un
estándar para la industria.
La identificación de objetivos es la parte en al que el analista intenta averiguar lo que la empresa intenta conseguir y luego
determina si algunas funciones de las aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance
sus objetivos aplicándolas a problemas u oportunidades especificas.
En la primera fase los involucrados son los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto.
Las actividades de esta fase consisten en entrevistar a los encargados de coordinar a los usuarios, sintetizar el conocimiento
obtenido, estimar l alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de viabilidad que
incluye una definición del problema y un resumen de los objetivos. Luego, la administración e quien decide si se sigue adelante
con el proyecto propuesto. El proyecto se puede cancelar por falta de fondos suficientes, si el problema a atacar es incorrecto o
si la solución a tales problemas no amerita un sistema de computo.
Determinación de los Requerimientos de Información
En esta fase el analista debe comprender lo que necesitan los usuarios para llevar a cabo sus actividades, varios de los
métodos para lograr esto implican interactuar directamente con los usuarios.
Los implicados en esta fase son el analista y los usuarios. El analista necesita conocer los detalles de las funciones del sistema
actual (si es que hay alguno): el quién (involucrados), el qué (actividad del negocio), el dónde (entorno en el que se desarrolla tal
actividad), el cuándo (momento oportuno) y el cómo (manera en que se realizan los procedimientos actuales) del negocio que se
estudia. Luego el analista debe preguntar porque se usa el sistema actual, lo cual puede proveer de buena información a tener
en cuenta para el diseño del nuevo sistema. Si la razón es que “siempre se han hecho de esta manera” puede ser necesario que
el analista mejore los procedimientos.
Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de
la gente, los objetivos, los datos y los procedimientos implicados.

Análisis de las Necesidades del Sistema

En esta fase el analista modela el sistema valiéndose de distintas herramientas y analiza las decisiones estructuradas que se
hayan tomado.
Aquí es donde el analista prepara una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de
costo/beneficio de las alternativas y ofrece recomendaciones sobre el curso a seguir. Si la administración lo considera factible, el
analista sigue adelante.

Diseño del Sistema Recomendado

En esta fase el analista usa la información recopilada anteriormente para realizar el diseño lógico del sistema, diseñando
procedimientos precisos para la captura de datos que aseguran que los datos que entran al sistema sean correctos. Otra parte
de esta fase es el diseño de la interfaz del usuario y es sumamente importante.
La fase del diseño también incluye el diseño de archivos o bases de datos que almacenan gran parte de los datos necesarios
para los encargados de la toma de decisiones. En esta fase el analista interactúa con los usuarios para diseñar la salida del
sistema tal que esta satisfaga las necesidades de éstos.
Finalmente, el analista debe diseñar procedimientos de respaldo que protejan al sistema y a los datos, y producir paquetes de
especificaciones de programa para los programadores, los cuales deben contener esquemas para la entrada y la salida,
especificaciones de archivos y detalles del procesamiento, etc.

Desarrollo y Documentación del Software

El analista trabaja en conjunto con los programadores para desarrollar cualquier software original necesario. Hay varias
técnicas a usar en esta fase, valiéndose de ellas para comunicarle al programador lo que se requiere programar.
En esta fase el analista trabaja con los usuarios para desarrollar documentación efectiva para el software, que indica a los
usuarios el modo de uso del software y que hacer en caso de que ocurran problemas derivados del uso.
Los programadores son clave en esta fase, ya que diseñan, codifican y eliminan los errores sintácticos de los programas de
cómputo.

Prueba y Mantenimiento del Sistema

Antes de poner a funcionar el sistema se lo debe probar ya que es menos costoso hallar los problemas antes de entregar el
sistema al usuario final. Primero se hace una serie de prueba con datos de muestra para determinar con precisión cuales son los
problemas y posteriormente se realiza otra con datos reales del sistema actual.
Las pruebas a realizar se dividen en dos o tres etapas:
α testing, realizada por el equipo de desarrollo.
β testing, realizada por usuarios y persona ajenas al equipo.
γ testing, cuando el usuario realiza una prueba sin estar consiente de que es una prueba.
El mantenimiento del sistema y su documentación comienzan en esta fase y se realizan rutinariamente durante toda su vida
útil. Gran parte del trabajo del programador consiste en el mantenimiento. Lo ideal sería que el analista tome las precauciones
debidas durante el SDLC para garantizar que el mantenimiento se mantendrá al mínimo. De cualquier modo el mantenimiento
puede ser:
Correctivo: Se realizan pruebas β, que son las que permiten detectar errores cuando el usuario utiliza el sistema.
Adaptativo: No existen errores, sino que cambia el ambiente y el sistema debe adaptarse, por ejemplo, cambio de hardware.
Perfectivo: Se agregan nuevas funciones, cambiando el alcance del sistema y perfeccionándolo.
Preventivo: Se adapta el sistema para prevenir errores futuros.

Implementación y Evaluación del Sistema

La última fase, en la cual el analista participa en la implementación del sistema de información, capacitando a los usuarios en
el manejo de éste. Parte de la capacitación la imparten los fabricantes, pero la supervisión es responsabilidad del analista, el cual
debe planear una conversión gradual del sistema anterior al actual.
 La implementación del sistema puede darse en paralelo al anterior, es decir que se pone a funcionar al sistema nuevo junto
con el viejo, siendo este desplazado de a poco. Otra manera de hacerlo es más radical e implica eliminar sin etapas el sistema
anterior y poner en funcionamiento al nuevo. Aunque muy riesgoso, este último método es el menos costoso.
La evaluación se lleva a cabo durante cada una de las fases.

Debe hacerse hincapié en que frecuentemente el trabajo de sistemas es cíclico. Cuando el analista da por concluida una fase
del SDLC y avanza a la siguiente, el surgimiento de un problema puede obligarlo a regresar a la fase previa y modificar el trabajo
realizado.

Problemas en la administración
A los administradores no les agrada aceptar que su organización tiene problemas. Sin embargo, un buen administrador es
consiente que para mejorar el rendimiento y mantener a la empresa funcionando se debe ser capaz de reconocer los síntomas
de problemas, diagnosticar problemas y ser capaz de hacerles frente..
Los problemas surgen de distintas maneras. Se los puede considerar como situaciones en las que no se alcanzan las metas
fijadas. Una buena realimentación puede hacer notar la brecha entre el desempeño real y el desempeño pretendido. Aun así hay
problemas ocultos al analista ya que no se realizaron mediciones del desempeño. Pueden notarse problemas también, cuando
se notan cambios malos y bruscos en lo empleados.
La retroalimentación externa también juega un papel importante, ya sea como quejas de los clientes o reclamos. Todo esto
ayuda a la detección de problemas.

Selección de proyectos
Los proyectos surgen de diversas fuentes y por muchas razones, pero no todos deben seleccionarse para un estudio mas
profundo. Para poder seleccionar con que proyecto avanzar se debe tener en cuenta que éste no debe servir para mejorar su
propia imagen política o poder, o del grupo que la proponga, ya que es probable que el proyecto sea mal concebido y, con el
tiempo, no tenga una buena aceptación.
Los proyectos potenciales se examinan con una perspectiva sistémica, tomando en cuenta el impacto que éste tendrá en la
organización.
Existen cinco criterios específicos para la selección de proyectos:
1. El respaldo de los directivos de la organización.
2. Un periodo adecuado de compromiso para terminar el proyecto.
3. La posibilidad de mejorar la consecución de las metas organizacionales.
4. Factibilidad en cuanto a recursos para el analista de sistemas y la organización.
5. La rentabilidad del proyecto en comparación con otras formas en que la organización podría invertir sus recursos.
El criterio principal es el respaldo de los directivos, ya que no se puede lograr sin el consentimiento de éstos, aunque ellos no
intervengan en el proyecto.

Determinación de la vialidad
Cuando la cantidad de proyectos a considerar se redujo en la etapa anterior, queda por determinar la viabilidad si los
proyectos seleccionados son viables. El estudio de viabilidad se trata de recopilar suficientes datos para que los directivos, a su
vez, tengan los elementos necesarios para decidir si debe procederse a realizar un estudio de sistemas.
Los datos para este estudio se recopilan mediante entrevistas.
Es importante que el analista de sistemas invierta demasiado tiempo en los estudios de viabilidad, porque son muchos los
proyectos a estudiar. Aun así este proceso abarca diversas actividades.
Definición de objetivos. El analista es catalizador y experto de soporte técnico, identificando en primer lugar donde se pueden
mejorar los procesos. Se puede que considerar que las oportunidades son la contraparte de los problemas, pero más aún un
problema para un gerente puede convertirse en una oportunidad para un analista.
Las mejoras pueden ser de muchos tipos:
1. Aceleración de un proceso.
2. Optimización de un proceso al eliminar pasos innecesarios o duplicados.
3. Combinación de procesos.
4. Reducción de errores en la captura de información modificando las interfaces.
5. Reducción de almacenamiento redundante
6. Reducción de salidas redundantes.
7. Mejora en la integración de sistemas y subsistemas.

Aunque es importante que el analista tenga habilidad para reconocer las oportunidades de mejora, quienes están en contacto
diario con el sistema podrían ser más eficaces para brindar información sobre las mejorar por realizar. Si ya están sugeridas las
mejoras, el analista debe juzgar si valen la pena y como se deben implementar.
El analista puede realizar una cuadrícula de impacto de viabilidad (CIV) la cual sirve para comprender o evaluar los impactos
que tendrían las mejoras en el sistema existente.
 Los rótulos laterales corresponder a sistemas existentes o propuestos, organizados en tres categorías: de comercio
electrónico, de información general (MIS) y de procesamiento de transacciones (TPS). En la parte estas los siete objetivos de los
procesos.
También es importante la manera en que las mejoras a los sistemas afectan a los objetivos corporativos, los cuales son:
1. Mejora de las ganancias corporativas.
2. Apoyo a la estrategia competitiva.
3. Mayor cooperación con distribuidores y socios.
4. Incremento del apoyo a las operaciones internas con el fin de producir bienes u servicios de manera mas eficiente.
5. Incremento del apoyo a la toma d decisiones internas para que estas sean mas eficaces.
6. Mejora del servicio al cliente.
7. Incremento en la moral.

Se puede modificar la CIV de modo que en la parte superior estén dispuestos los siete objetivos corporativos y estudiar el
impacto del sistema en ellos.
Reducción de
Aceleración errores en la Reducción de Mejora de la
Componentes de un Optimización Combinación captura de salidas integración de
del sistema proceso de un proceso de procesos información redundantes sistemas
Catálogo en línea
Sistemas de comercio

Procesamiento de
pedidos en línea
electrónico

Soporte técnico en
línea
Anuncios en línea
Agente inteligente de
actualización
automática en Web
Administración de
inventarios
Programación de la
producción
Informes de ventas
MIS

mensuales
Análisis de ventas
regionales
Administración de la
logística
Nómina
Procesamiento de
pedidos
TPS

Seguimiento de
Pedidos
Cuentas por pagar
Cuentas por cobrar

Determinación de recursos. Un proyecto debe satisfacer tres criterios de viabilidad para pasar a la fase de desarrollo. Los
recursos se analizan desde tres área de viabilidad:
Viabilidad Técnica: El analista debe ver si es posible actualizar o incrementar los recursos técnicos actuales de modo
que puedan satisfacer los requerimientos bajo consideración. En ocasiones los “agregados” a los sistemas existentes
suelen ser costosos y no son eficientes. De ser así, el analista debe preguntarse si existe tecnología que cumpla las
especificaciones.
Viabilidad Económica: Los recursos a considerar son el tiempo del analista y del equipo, el costo de realizar un estudio
completo de sistemas completo, el costo del tiempo de los empleados de la empresa, el costo estimado del hardware y
del software comercial o desarrollado. La empresa interesada debe ser capaz de calcular tales valores antes de
comprometerse al estudio completo de sistemas. Si los costos a corto plazo no son opacados por las ganancias a largo
plazo o no producen una reducción inmediata de los costos operativos, el sistema no será económicamente viable.
Viabilidad Operativa: Depende de los recursos humanos disponibles para el proyecto e implica determinar si el sistema
funcionará o se usará una vez instalado. Todo esto suele depende de la predisposición de lo usuarios a que exista un
nuevo sistema de información. Determinar la viabilidad operativa requiere creatividad por parte del analista y de
persuasión.
En otras bibliografías se agregan los estudios de tres viabilidades más: Viabilidad Financiera (separándose se de la viabilidad
económica, su estudio nos indica si se posee el capital necesario para el proyecto); Viabilidad Legal (si el proyecto se desarrolla
dentro de las leyes gubernamentales y empresariales); Viabilidad de Programa (si el proyecto se puede realizar en un lapso de
tiempo conveniente para el usuario).

Evaluación de la viabilidad. La viabilidad de un proyecto no está a cargo del analista sino de los directivos de la organización.
El estudio de la viabilidad se debe realizar en el menor tiempo posible de modo que los recursos asignados a esta tarea sean
mínimos.
Los proyectos que cumplen todos los criterios anteriores deben tomarse en cuenta para un estudio de sistemas detallado.

Planeación y control de actividades

La planeación incluye todas las actividades requeridas para seleccionar un equipo de análisis de sistemas, asignar miembros a
tareas adecuadas, calcular el tiempo necesario para realizar cada tarea y programar el proyecto tal que las tareas terminen a
tiempo.
El control implica usar la retroalimentación para monitorear el proyecto, comparando el plan original con el desempeño real
del proyecto. También implica emprender las acciones apropiadas para agilizar o reprogramar actividades para terminar en
tiempo, a la vez que se estimula a los miembros del equipo a trabajar profesionalmente.

Cálculo del tiempo requerido. La primera decisión del analista de sistemas es determinar el nivel de detalle necesario para
definir las actividades. El nivel más bajo de detalle es el ciclo de vida del desarrollo de aplicaciones y el nivel mas alto incluye
cada paso en detalle. El punto óptimo para la planeación y la programación se encuentra en algún punto medio.
Al considerar tareas y dividirlas en tareas mas pequeñas que las componen, el analista puede estimar mejor el tiempo que
tomará realizar el trabajo completo.

Para una buena planificación hay que tener en cuenta que se deben fijar objetivos y metas, cuantificando el tiempo y espacio
en el que se desea lograr el objetivo. El analista debe poder identificar las actividades que se deben realizar para obtener el
resultado, determinar las actividades críticas y las relaciones entre ellas. También debe poder determinar el tipo y la cantidad de
recursos que requieren tales actividades. El analista debe determinar grandes hitos y objetivos específicos en el desarrollo de
sistemas y establecer la duración de las actividades, fechas de entrega y responsables de los productos.

Hay una serie de problemas que se pueden dar en la planificación:

 Personales: Motivación débil, personal mediocre, hazañas, expectativas poco realistas, fricciones entre usuarios y
desarrolladores, etc.
 De proceso: planificación excesivamente optimista, pérdida de tiempo por inicio difuso, abandonar la planificación bajo
presión, fallo de las contratistas, omitir tareas necesarias en la planificación, etc.
 De producto: Exceso de requerimientos, cambio de prestaciones, desarrolladores meticulosos, desarrolladores
orientados a la investigación, etc.
 Tecnológicos: Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos, cambiar de
herramientas a mitad del proyecto, etc.
Recopilación de información: Métodos interactivos
Hay tres métodos clave utilizables para obtener los requerimientos de información de los miembros de la organización:
Entrevistas, diseño conjuntos de aplicaciones (JAD) y la realización de encuestas mediante cuestionarios. Cada uno de estos
métodos posee su propio proceso establecido para interactuar con los usuarios. Existen también los llamados métodos
discretos. Al utilizarlos en conjunto con los métodos interactivos se obtiene un panorama más completo de los requerimientos
de información de la organización.

Entrevistas
Antes de la entrevista, el analista debe conocer sus prejuicios y como estos afectaran sus precepciones, así como también
debe tomar en cuenta su educación, intelecto, formación, y emociones. Necesita visualizar las preguntas, lo que va a hacer, y lo
que a su juicio hará que la entrevista sea exitosa. Debe también tener en cuenta los factores que harán que la entrevista sea
satisfactoria para el individuo entrevistado.
En la entrevista, el analista debe buscar las opiniones de los entrevistados, ya que estas son más reveladoras que los hechos
en sí. Además debe buscar captar los sentimientos de los entrevistados, lo cual puede servir para comprender la cultura
organizacional de manera más completa. Las metas son información importante que se puede recabar de las entrevistas, ya que
las metas reflejan el futuro del negocio.
Las entrevistas implican entablar una relación con alguien que probablemente sea desconocido para el analista, debiendo
establecer confianza y entendimiento rápidamente pero manteniendo el control de la entrevista. Mientras tanto, debe intentar
vender el sistema, brindándole la información necesaria al entrevistado. Todo esto lo puede conseguir planificando la entrevista,
de modo que la conducción de la misma resulte natural.
Cinco pasos para preparar la entrevista:
Leer los antecedentes: Leer y entender tanto como sea posible los antecedentes de los entrevistados y de la organización. Este
material se puede obtener del sitio web de la organización, de un boletín corporativo, de un informe anual o de cualquier
publicación. Debe prestar atención al lenguaje que usan los miembros de la organización para describirse a si mismos y su
organización. Tal lenguaje conformará el vocabulario con el que expresará las preguntas de manera comprensible. Además, se
ahorra el tiempo de preguntar cosas que podría obtener de leyéndolo.
Establecer los objetivos de la entrevista: Usar los antecedentes recopilados y la propia experiencia para establecer los
objetivos de la entrevista. Debe haber de cuatro a seis áreas clave referentes al procesamiento de la información y el
comportamiento relacionado con la toma de decisiones, sobre las cuales el analista deberá hacer preguntas.
Decidir a quién entrevistar: Es importante incluir gente clave de todos los niveles que vayan a ser afectadas por el sistema,
esforzándose por atender las necesidades de tantos usuarios como sea posible. La persona de contacto dentro de la
organización también tendrá ideas sobre quien debería ser entrevistado.
Preparar al entrevistado: Se puede comunicar de varias maneras anticipadamente con la persona que va a ser entrevistada
para que ésta se prepare para la entrevista. Si el analista va a realizar una entrevista en profundidad, puede enviar sus preguntas
por correo electrónico, así el entrevistado tiene tiempo suficiente de pensar en sus respuestas. Sin embargo, como la entrevista
tiene muchos objetivos que incluyen la interacción directa con el entrevistado, normalmente se evita realizarlas por correo
electrónico. La duración de la entrevista debe ser de 45 minutos a 1 hora como mucho (se debe tener en cuenta que mientras
están siendo entrevistados no están trabajando).
Decidir el tipo de preguntas y su estructura: Escribir preguntas que abarquen áreas clave de la toma de decisiones que haya
descubierto al determinar los objetivos de la entrevista. Las técnicas apropiadas para preguntar son fundamentales en la
entrevista. Las preguntas tienen formas básicas que el analista debe conocer. Cada tipo de pregunta puede lograr resultados
diferentes tienen sus ventajas y desventajas.
 Preguntas Abiertas Preguntas Cerradas
Son las preguntas cuya gama de respuestas
Son las preguntas gama de respuestas
es mucho menor, siendo respuestas que limitan
es bastante amplia para el entrevistado
las opciones del entrevistado.

Ventajas:
·Hacen que el entrevistado se
sienta a gusto.
·Permiten al entrevistador
entender el vocabulario del
entrevistado, lo cual refleja
muchas cosas.
·Proporcionan muchos
detalles
·Revelan preguntas que
pudieron pasar
desapercibidad por el
analista.
·Hacen más interesante la
entrevista y permiten más
espontaneidad.
·Son un buen recurso si el
ntrevistador no está
preparado para la entrevista.
Desventajas:
·Pueden dar muchos detalles
irrelevantes.
·Posible pérdidad de control
de la entrevista.
·La relación entre el tiempo
de la respuesta y la cantidad
útil de información es muy
mala.
·Dan la impresión de que el
entrevistador es inexperto o
que no tiene sus objetivos
bien claros.
Ventajas:
·Ahorrar tiempo. Desventajas:
·Comparar entrevistas ·Aburren al entrevistado.
fácilmente.
·No permiten ahondar n
·Ir al grano. detalles.
·Mantener el control de la ·Olvidar las ideas principales.
entrevista. ·No fomenta una relación
·Cubrir el terreno cercana entre el entrevistado
rápidamente. y el entrevistador.
·Conseguir datos relevantes.

Sondeos
Son preguntas que se utilizan para recabar más información, yendo más allá de la respuesta del individuo. Pueden constar
de preguntas abiertas o cerradas.
El sondeo es fundamental, por lo que no se debe ser reticente a uso.

La entrevista también debe estructurarse, siendo posibles tres modelos.

Uso de estructura de pirámide. Es la organización inductiva de la entrevista. El entrevistador empieza con
preguntas cerradas y detalladas, posteriormente extiende los temas permitiendo preguntas abiertas y
respuestas más generalizadas.
Se debe usar esta estructura si se cree que el entrevistado necesita motivación para profundizar en el
tema, ó si se desea una opinión concluyente del tema.
Uso de estructura de embudo. Es la organización deductiva de la entrevista. El entrevistador comienza
con preguntas generales y abiertas, limitando luego las posibles repuestas con preguntas cerradas.
Proporciona una forma cómoda y sencilla de empezar la entrevista, y es útil cuando el entrevistado tiene
opiniones fuertes respecto del tema y necesita libertad para explayarse.
Uso de estructura de diamante. Frecuentemente es mejor una combinación de las dos anteriores. Esto
implica empezar de modo específico, luego examinar los aspectos generales y terminar con una conclusión
muy específica.
Redacción del informe de la entrevista. El analista necesita captar la esencia de la entrevista a través de un informe escrito. Es
indispensable escribirlo lo más pronto posible, para asegurar la calidad de los datos de la entrevista. Luego de ese resumen
inicial, debe registrar los puntos principales de la entrevista y sus propias opiniones. Después, repasar el informe de entrevista
con el entrevistado.

Diseño conjunto de aplicaciones (JAD)

Las entrevistas personales toman mucho tiempo y están sujetas al error y la mala interpretación. IBM desarrolló un método
alternativo conocido como JAD. Las razones para usarlo son reducir el tiempo y el costo que requieren las entrevistas, mejorar la
calidad de los resultados de la evaluación de los requerimientos de información y generar una mayor identificación del usuario
con los nuevos sistemas de información como resultado de lo procesos participativos.
Normalmente, JAD permite al analista de sistemas realizar el análisis de los requerimientos y diseñar la interfaz de usuario en
conjunto con los usuarios. Las complejidades de esta técnica solo se pueden aprender en seminarios donde se dicten los
métodos patentados por IBM.

Condiciones que apoyan el uso de JAD.

1. Los grupos de usuarios están intranquilos y quieren algo nuevo, no una solución común a un problema típico.
2. La cultura organizacional apoya los métodos conjuntos de resolución de problemas entre distintos niveles de
empleados.
3. Los analistas prevén que la cantidad de ideas generadas por medio de las entrevistas uno a uno no será tan
abundante como la cantidad de ideas que se podrían obtener de un ejercicio en grupo.
4. El flujo de trabajo de la organización permite la ausencia de personal importante durante un periodo de dos a cuatro
días.

Quién está involucrado. Las sesiones de JAD incluyen varios participantes, que aportarán su experiencia y habilidades. El
principal interés del analista es que todos se comprometan e involucren con el enfoque JAD. Debe escoger un patrocinador
ejecutivo, quien presentará y concluirá la sesión de JAD. Esta persona será un símbolo visible e importante del compromiso de la
organización con el proyecto de sistemas.
Al menos un analista del área de sistemas de información debe estar presente, pero tomando un rol pasivo. El analista del
proyecto debe estar presente en la sesión para escuchar lo que dicen los usuarios y lo que necesitan, además deberá dar una
opinión especializada en caso de que en la sesión se proponga una solución de costo desproporcionado, ya que de otro modo las
soluciones poco realistas de costos excesivos podrían colarse en la propuesta y ser difíciles de eliminar posteriormente.
Es conveniente seleccionar de ocho a doce usuarios de cualquier nivel para participar de las sesiones JAD. Debe procurar
seleccionar usuarios por encima del nivel operativo, que tengan capacidad para explicar que información requieren para realizar
sus trabajos, así como las características que le agradarían en un sistema de cómputo nuevo o mejorado.
El líder de la sesión debe ser alguien con habilidades de comunicación excelentes para facilitar las interacciones apropiadas. No
es conveniente seleccionar a un líder de sesión que le reporte a una persona del grupo. Se puede contratar a un consultor
externo como líder de sesión. Debe ser una persona que atraiga la atención del grupo a tratar las cuestiones importantes de los
sistemas, negociar satisfactoriamente y resolver los conflictos, y ayudar a los miembros del grupo a alcanzar un acuerdo general.
La sesión debe incluir a uno o dos observadores que sean analistas o expertos técnicos de otras áreas funcionales áreas para
ofrecer explicaciones y consejos técnicos al grupo durante las sesiones. Además, un miembro del departamento de sistemas de
información debe asistir para redactar formalmente todo lo que se haga.
Dónde realizar las sesiones JAD. Es recomendable que sean sesiones de dos a cuatro días, fuera de las oficinas de la
organización en ambientes cómodos, con el objetivo de minimizar las distracciones y responsabilidades cotidianas inherentes al
trabajo de los participantes. Además se debe tomar en cuenta el equipo de apoyo a la presentación que incluiría un pizarrón,
proyectores, punteros laser, acceso a una fotocopiadora, etc. Las salas deberían tener PCs conectadas a una red, un sistema de
proyección, y software que facilite la interacción de grupos y que minimice su comportamiento improductivo.
Las sesiones de JAD se programan de modo que los participantes puedan comprometerse a asistir. Pueden realizarse
reuniones previas de carácter informativo.

Realización de un análisis estructurado de las actividades del proyecto. Las sesiones deben examinar los siguientes puntos en
el proyecto de sistemas propuesto: Planeación, recepción, procesamiento y seguimiento de recibos, supervisión y asignación,
procesamiento, registro, envío y evaluación. Se deben plantear y responder para cada tema las preguntas quién, qué, cómo,
dónde y porqué. El analista debe recibir las notas del redactor y debe preparar un documento de especificaciones técnicas con
base en lo que haya ocurrido en la reunión. Presentará sistemáticamente los objetivos de los directivos, el alcance y los límites
del proyecto, incluyendo las partes específicas del sistema como detalles sobre los diseños de pantallas e informes.

Beneficios potenciales del JAD contra las entrevistas tradicionales. El primer beneficio potencial es el ahorro de tiempo sobre
las entrevistas tradicionales uno a uno, llegando a estimarse un ahorro del 15% del tiempo. También está la posibilidad de un
desarrollo rápido a través de JAD ya que las entrevistas personales no se realizan consecutivamente, el desarrollo procede con
mayor rapidez.
 El tercer beneficio es poder mejorar el concepto de propiedad del sistema, ya que JAD es de naturaleza interactiva y posee alta
visibilidad, por lo que se logra que los usuarios estén más involucrados y como adición le da más seriedad a la retroalimentación
que proporcionan. JAD ayuda a reflejar bien las ideas del usuario en el diseño final.
El beneficio final es el desarrollo de diseños creativo los cuales pueden evolucionar a través de interacciones simplificadas.

Desventajas potenciales del JAD contra las entrevistas tradicionales. Existen tres desventajas a considerar. La primera es que
requiere que todos los participantes dispongan de una gran cantidad de tiempo, ya que el compromiso requiere de dos a cuatro
días.
El segundo peligro se puede manifestar siempre que la preparación de las sesiones sea inadecuada o si el informe de
seguimiento y la documentación de especificaciones están incompletos. En estos casos los diseños resultantes pueden ser poco
satisfactorios.
Por último, tal vez las habilidades y la cultura que requiere la organización no están totalmente desarrolladas, peligrando el
compromiso de ésta ante el enfoque JAD.

Uso de cuestionarios
Permite a los analistas de sistemas estudiar las actitudes (lo que dicen que quieren), creencias (lo que creen que es verdad),
comportamiento (lo que hacen) y características (atributos) de muchas personas importantes en la organización que podrían
resultar afectadas por los sistemas actuales y los propuesto.
Se puede cuantificar las respuestas conseguidas mediante encuestas que usen preguntas cerradas. Si la encuesta se realiza
mediante un medio computarizado, se puede usar software que convierta las respuestas directamente a tablas de datos para su
análisis. Las respuestas a cuestionarios con preguntas abiertas se analizan de modo distinto.
El analista puede usar el cuestionario como medio para cuantificar lo que se infirió de las entrevistas, permitiendo observar
que tan extendido es en realidad un sentimiento expresado en la entrevista. También se pueden usar las encuestas para
detectar problemas o manifestar cuestiones importantes antes de realizar las entrevistas. Hay muchas similitudes entre las
encuestas y las entrevistas, y lo ideal sería que se las usase en conjunto, aunque no siempre es necesario o conveniente.

Planeación del uso de cuestionarios. Aunque se puede recopilar mucha información a través de los cuestionarios sin invertir
tiempo en entrevistas personales, el desarrollo de una encuesta útil implica mucho tiempo de planeación. Cuando se encuesta a
los usuarios por medio Web o e-mail, el analista se enfrenta a aspectos de planeación adicionales acerca de la confidencialidad,
la autenticación de identidad y problemas de múltiples respuestas.
Primero se debe decidir que fin se persigue al realizar una encuesta, y luego considera si la encuesta es el mejor medio para
obtener la información buscada. Se debe considerar el uso de cuestionarios si:
1. Las personas que necesita encuestar están dispersas.
2. Muchas personas involucradas en el proyecto y se quiere conocer que porcentaje de ellas aprueba o no cierta
característica del sistema propuesto.
3. Durante el estudio preliminar se desea conocer la opinión general antes de que se determine el rumbo que tomara el
proyecto de sistemas.
4. Se quiere tener la certeza de que en las entrevistas de seguimiento se identificará y abordará cualquier problema
relacionado con el sistema actual.

Redacción de preguntas. Las preguntas realizadas en una entrevista permiten la interacción entre las preguntas y sus
significados. En el cuestionario estas oportunidades son casi nulas, por lo que el analista debe formular preguntas claras, el flujo
del cuestionario debe ser convincente, se deben anticipar las preguntas de los encuestados y la aplicación del cuestionario debe
planearse en detalle.
Los tipos de preguntas para los cuestionarios pueden ser tanto abiertas como cerradas. Sabemos que las preguntas abiertas
permiten al encuestado disponer de todas las opciones de respuesta. Aún así, el analista se debe poder anticipar a la respuesta
del encuestado ya que puede suceder que no sea posible el análisis de la respuesta. Cuando se redacta una pregunta abierta,
ésta debe ser lo suficientemente específica para guiar al encuestado a responder de un modo particular. Estas preguntas son
adecuadas para descubrir opiniones de miembros de la organización sobre algún aspecto del sistema.
Las preguntas cerradas limitan las opciones de respuesta, y deben usarse cuando el analista puede listar eficazmente todas las
posibles respuestas a la pregunta, y estas respuestas son mutuamente excluyentes. Se utilizan cuando se desea encuestar una
cantidad considerable de personas, facilitando el procesamiento de las respuestas.
 Elección del vocabulario. Es conveniente que el analista redacte las preguntas de modo que reflejen la terminología del
negocio, ya que esto hará más ameno el proceso para los encuestados y facilitará la interpretación precisa de las respuestas,
logrando que los encuestados se muestren más entusiasmados.
Un modo de lograr esto es mediante un cuestionario sobre un grupo piloto, quién cambiará las palabras y frases. Hay que
considerar los siguientes puntos al realizar un cuestionario:
1. Usar la jerga de los encuestados siempre que sea posible junto con una redacción sencilla.
2. Ser específico en la redacción, pero evitar las preguntas demasiado específicas.
3. Hacer preguntas breves.
4. No ser condescendiente con los encuestados ni subestimarlos con lenguaje de bajo nivel.
5. Evitar la parcialidad en la redacción, en especial las preguntas ofensivas.
6. Dirigir las preguntas a los encuestados adecuados. No dar por sentado que estos poseen demasiado conocimiento.
7. Antes de incluir aspectos técnicos en las preguntas, asegurarse que es realimente preciso.
8. Usar software para cerciorarse de que el nivel de redacción de las preguntas es el adecuado.

Uso de escalas en los cuestionarios. El escalamiento es un proceso que consiste en asignar números u otros símbolos a un
atributo con propósitos de medición. Las escalas son a menudo arbitrarias y a veces no son únicas.

Validez y confiabilidad. La validez es el grado en el que la pregunta mide lo que el analista pretende medir. La confiabilidad
mide la consistencia, es decir, el grado en el que dos aplicaciones del cuestionario en momentos diferentes dan los mismos
resultados, para la consistencia externa y los mismos resultados en los apartados para la consistencia interna.

Construcción de escalas. Una construcción negligente de una escala podrí causar: condescendencia (problema causado por
encuestados que califican a la ligera), tendencia central (problema surgido de encuestados que califican todo como promedio) y
efecto de halo (problema surgido cuando la impresión generada por una pregunta influye en la próxima).
La condescendencia se soluciona moviendo la categoría promedio a izquierda o derecha del centro. La tendencia central se
puede solucionar haciendo más pequeñas las diferencias en los extremos, ajustando la fuerza de los descriptores o creando una
escala con más puntos. La solución al efecto de halo es cambiar el enfoque de cada pregunta.

Diseño de cuestionarios. Un cuestionario bien diseñado puede ayudar a superar parte de la reticencia a responder, si se
siguen algunas reglas:
 Dejar bastante espacio en blanco.
 Proporcionar suficiente espacio para responder las preguntas.
 Facilitar a los encuestados el marcado claro de sus respuestas.
 Mantener un estilo consistente.
Estas reglas también son válidas para cuestionarios Web.

El orden de las preguntas. No existe una manera considerada como la mejor. Conforme se ordenan las preguntas, se deben
pensar en los objetivos que persigue el cuestionario y luego determinar la función de cada pregunta en la consecución de los
objetivos. Es importante considerar el cuestionario desde el punto de vista del encuestado. Algunos lineamientos para ordenar
las preguntas son:
 Colocar primero las preguntas más importantes para los encuestados.
 Agrupar los elementos de contenido similar.
 Incorporar primero las preguntas menos polémicas.

Encuestados. La decisión sobre quién recibirá el cuestionario se toma en conjunto con la tarea de establecer los objetivos que
persiguen los resultados del mismo. Los destinatarios se escogen como representativos por su jerarquía, tiempo en la compañía,
deberes, o interés especial en el sistema actual o propuesto. Se deben incluir una cantidad razonable de encuestados por si se
pierden hojas, o se completan encuestas de manera incorrecta y deben desecharse.
Métodos para aplicar el cuestionario. Hay varias opciones, y el método de administración es determinado por el estado de la
empresa. Entre las opciones se encuentran las siguientes:
 Citar al mismo tiempo a todos los encuestados.
 Entregar y recoger personalmente los cuestionarios.
 Permitir que los encuestados llenen el cuestionario por sí mismos en su trabajo y que lo dejen en una
caja colocada en algún punto central.
 Mandar por correo los cuestionarios a los empleados de las sucursales e indicar una fecha límite para
la entrega.
 Aplicar el cuestionario por e-mail o la Web.
Recopilación de información: Métodos no intrusivos
Los métodos no intrusivos como el muestreo, la investigación y la observación del comportamiento y el entorno físico de un
tomador de decisiones, son métodos menos molestos, pero se consideran deficientes si se usan por sí solos para recopilar
información. La combinación de métodos intrusivos y no intrusivos ofrece un panorama mas completa de los requerimientos de
información.

Muestreo
Consiste en seleccionar sistemáticamente elementos representativos de una población, examinarlos cuidadosamente y
obtener información de la población en general.
El analista debe elegir que información de la disponible (sitios web, informes, memorandos, documentos de resultados, etc.)
debe ignorar o prestar atención. Hay muchos empleados afectados por el sistema propuesto, por lo que el analista debe
considerar a qué personas entrevistar, de cuáles debe buscar información mediante cuestionarios o a cuáles debe observar
durante sus roles de toma de decisiones.

Necesidad del muestreo. Hay varias razones, entre ellas: reducir costos, acelerar la recopilación de datos, mejorar la
efectividad y reducir la parcialidad. El muestreo ayuda a acelerar el proceso de análisis de información mediante la recopilación
de datos seleccionados, ahorrando tiempo de los trabajadores y del analista. La efectividad en la recopilación es importante. El
muestreo puede ayudar a mejorar la efectividad si se pude obtener información mas precisa. También es posible reducir la
parcialidad en la recopilación de datos mediante el muestreo.

Diseño del muestreo. El analista debe seguir cuatro pasos para diseñar una buena muestra:
1. Determinar que datos van a ser recopilados o descritos. Es necesario un plan realista sobre lo que se hará con lo
datos recopilados, para evitar perdidas de tiempo y dinero. El deber del analista es identificar las variables, atributos y
los elementos relacionados con los datos que necesitan recopilarse en la muestra, considerando los objetivos del
estudio y el método de recopilación de datos que se usará.
2. Determinar de que población se van a tomar muestras. El analista de sistemas debe determinar la población, así
como la cantidad y temporalidad de la información que solicitará.
3. Escoger el tipo de muestra. El analista puede escoger de cuatro tipos principales de muestras: de conveniencia,
intencional, aleatoria simple y aleatoria compleja. Las muestras de conveniencia son irrestrictas y no probabilísticas,
es decir que pueden ser fáciles de conseguir pero no muy fiables. La muestra intencional se basa en juicios, es decir
que el analista puede escoger un grupo de personas que crea conocedor e interesado en el nuevo sistema, por lo que
el analista basa la muestra en criterios pero sigue siendo no probabilística y moderadamente confiable.. Una muestra
aleatoria simple requiere una lista numerada de la población para asegure que cada documento o persona en la
población tiene la misma posibilidad de ser seleccionado, lo cual no es práctico. Las muestras aleatorias complejas
más apropiadas para el analista son: el muestreo sistemático, el muestreo estratificado y el muestreo por
conglomerados.
4. Decidir el tamaño de la muestra. Es obvio que el tamaño debe ser mayor a uno pero menor que el tamaño de la
población. En el muestreo se debe tener en cuenta que los números son más importantes que los porcentajes.
El tamaño de la muestra depende del costo involucrado o el tiempo requerido.

Investigación
Consiste en descubrir y analizar datos. Conforme el analista se esfuerza por entender la organización y sus requerimientos de
información, debe examinar los diferentes tipos de datos reales que ofrecen información no disponible mediante otro método
de recopilación de datos. Los datos reales muestran donde se encuentra la organización y hacia donde creen sus miembros que
se dirige, por lo que el analista debe analizar datos reales cualitativos y cuantitativos.
Análisis de documentos cuantitativos. Incluyen informes usados para la toma de decisiones, informes de desempeño, registros
y una variedad de formularios. Cada uno tiene un propósito y un público hacia el que está dirigido.
Informes usados para la toma de decisiones. El analista requiere documentos que se usan para dirigir el negocio.
Muchos de ellos no son complejos, pero sirven como retroalimentación para tomar medidas inmediatas y ayudan al
tomador de decisiones a identificar fácilmente las tendencias.
Aparte de los informes clave, los tomadores de decisiones se vale de muchos informes resumidos para extraer
información histórica, identificar eventos excepcionales y obtener un panorama estratégico de los planes de la
organización.

Informes de desempeño. Reflejan el desempeño real versus el desempeño deseado, sirviendo para determinar si la
brecha entre ambos se expande o contrae. El analista necesitará determinar si el desempeño medido es accesible y
adecuado para las áreas importantes de la organización.

Registro. Proporcionan actualizaciones periódicas de lo que ocurre en el negocio. Si están apropiadamente actualizados
le darán información muy útil al analista. Hay varias formas en que un analista revisa un registro:
 Buscar errores en cifras y sumas totales.
 Buscar oportunidades para mejorar el diseño del formulario del registro.
 Observar el número y el tipo de las transacciones.
 Buscar puntos donde una computadora pueda simplificar el trabajo.

Formularios de captura de datos. El analista debe recolectar y catalogar copias en blanco de cada formulario que esté
en uso. Comparando estos formularios en blanco junto con sus instrucciones de llenado y su distribución, contra los
formularios contestados, el analista puede ver que elementos quedan regularmente sin respuesta, y determinar si las
personas que reciben los formularios siguen los procedimientos estandarizados al usarlos, almacenarlos y desecharlos.
Al crear un catalogo de formularios, el analista debe recolectar ejemplos de todos los formularios en uso (oficiales y
extra-oficiales), observar el tipo de formulario, documentar el modelo de distribución deseado y compararlo con quien
realmente recibe el formulario. Otro método consiste en tomar muestras de formularios de captura de datos ya
contestados. Para transacciones de comercio electrónico, el analista debe revisar las bases de datos donde se almacena
la información sobre el cliente.

Análisis de documentos cualitativos. Incluyen correos electrónicos, memorandos, anuncios en carteles, páginas Web,
manuales de procedimientos y de políticas. Muchos de estos son bastante detallados y manifiestan las expectativas de sus
autores en relaciones con el comportamiento que deben observar los demás. Para analizar estos documentos, el analista debe
ver los siguientes detalles:
 Examinar metáforas clave u orientadoras.
 Buscar las mentalidades de internos contra externos.
 Listar los términos que caractericen lo bueno o lo malo, que aparezcan repetidamente en los documentos.
 Buscar mensajes y gráficos significativos.
 Identificar sentido del humor, si lo hay.
Memorandos. Debe considerar quien los envía y quien los recibe. El flujo común de información de una organización es
hacia abajo o hacia los costados, no hacia arriba. El análisis de memorandos proporciona una idea clara de los valores,
actitudes y creencias de los miembros de la organización.

Carteles, pancartas, etc. En tableros de anuncios o en las área de trabajo. Pueden parecen circunstanciales pero sirven
como reforzadores sutiles de valores para los que los leen.

Sitios Web corporativos. El analista debe prestar atención tanto a los sitios de comercio electrónico B2C como a los sitios
de transacciones B2B. Debe examinar el sitio bajo tres dimensiones: estética, técnica y administrativa.. También debe
tomar en cuenta el nivel de interactividad del sitio, la accesibilidad de los mensajes y el nivel de seguridad.

Manuales. Los manuales se deben analizar con los cinco lineamientos previamente mencionados. Hay que recordar que
los manuales indican el ideal, y además, que los manuales impresos generalmente están desactualizados, acumulados en
librerías sin usar.
 Manuales de políticas. Abarcan grandes áreas del comportamiento de los empleados y la organización. El analista puede
ocuparse de los que tratan sobre los servicios, uso, acceso, seguridad y cargas de las computadoras. Este examen permite
comprender los valores, actitudes y creencias que guían a la corporación.

Observación del comportamiento del tomador de decisiones

Este método es importante para el analista, ya que este busca entender lo que realmente se hace, no sólo lo que se
documenta o explica. Permite ver las relaciones que existen entre el tomador de decisiones y los demás miembros de la
organización.

Observación de las actividades de toma de decisiones de un gerente típico. La observación permite ver personalmente la
manera en que el gerente recopila, procesa, comparte y usa la información en su trabajo. El método usado para esta labor se
conoce como guión del analista. Aquí, el actor es quien toma las decisiones y todas las acciones se registran con verbos
conjugados en presente continuo.
El guión es un método organizado y sistemático que exige al analista entender y estructurar las acciones que asume el
tomador de decisiones. Sirve para que el analista pueda determinar que información necesitan las personas observadas para
tomar las decisiones más importantes o frecuentes.

Observación del entorno físico

La observación del entorno físico en el cual se desempeñan los tomadores de decisiones también pone de manifiesto muchos
de sus requerimientos de información. Esto implica examinar sistemáticamente las oficinas de los gerentes, ya que aquí es
donde desarrollan su trabajo principalmente. Los tomadores de decisiones y sus lugares de trabajo influyen entre si
simultáneamente.

Observación estructurada del entorno (STROBE). El STRuctured OBservation of the Environment requiere que el analista
observe siete elementos concretos que generalmente se encuentran en las oficinas. Tales elementos pueden revelar mucho
sobre la forma en que el tomador de decisiones recopila, procesa, almacena y comparte información, así como también sobre su
credibilidad en el lugar de trabajo.
 Ubicación de la oficina. Las oficinas accesible tienden a aunmentar la frecuencia de interacción y los
mensajes informales, mientras que las inaccesibles disminuyen estos aspectos y aumentan los mensajes
orientados a las tareas. Si las oficinas están distribuidas por todo el edificio, los informes y memorandums
quedan detenidos en algunas oficinas, mientras que en edificios con oficinas agrupadas se favorece el
compartir la información. Es posible que para personas cuyas oficinas estén separadas de las de los demás
pudieran ver la organización de forma diferente y sus objetivos podrían alejarse de los de otros miembros
de la organización.

Colocación del escritorio. Ofrece pistas sobre como el tomador de decisiones ejerce su autoridad. Aquellos
ejecutivos que proveen al visitante de un espacio contra la pared, reducido, mucho menor al que ellos
poseen, son quienes adoptan una posición de autoridad más fuerte. El analista debe observar la
distribución de los muebles en la oficina.

Equipo fijo de oficina. Archivos, librería y otros equipos grandes de alamacenamiento de artículo se
incluyen en esta categoría. Si estos no están presentes, es probable que el tomador de decisiones no
almacene muchos artículos de información por sí mismo. Si los hay, se asume que el tomador de decisiones
almacena mucha información y la valora.

Accesorios. Se refiere a todo equipo pequeño usado para almacenar información. La presencia de
Elementos computadoras de bolsillo, calculadoras y PCs sugiere que el tomador de decisiones no sale de su oficina
para procesar los datos.

a Fuentes externas de información. El analita precisa saber que tipo de información usa el tomador de
decisiones. La observación del tipo de artículos almacenados en la oficina revela si el gerente recurre a
observar fuentes externas o se basa más en información interna. También debe observar si el tomador de decisiones
usa información externa de la Web.

Iluminación y color de la oficina. Juegan un rol importante en el modo en el que el gerente recopila
información. Una oficina cálida y radiante indica una inclinación a la comunicación más personal. Un
ejecutivo en esta oficina tien a recopilar información de modo informal. En una oficina más fría la
recopilación se hace con memorandos formales e informes oficiales.

Vestimenta de los tomadores de decisiones. Puede inferirse sobre la credibilidad de los gerentes al
observar la vestimenta que usan en el trabajo. Los líderes que se visten de modo más casual, aparentan que
se da una toma de decisiones más párticipativa, pero se pierde credibilidad en la organización si la cultura
predominante valora la ropa tradicional y conservativa.
Definiciones de requerimientos
 Capacidad o función que el usuario espera que el sistema posea para poder resolver un problema o lograr un
objetivo.
 Capacidad o función que necesariamente debe poseer el sistema, o un módulo del mismo, para cumplimentar con los
términos del contrato, satisfacer estándares, especificaciones, o cualquier otro tipo de documento formalmente
impuesto.

Hay que tomar en cuenta que las especificaciones y requerimientos residen en la “cabeza” de las personas y que cualquier
documentación de las mismas es una representación, sujeta a malinterpretarse.

Niveles de requerimientos
Los requerimientos de software incluyen tres niveles: requerimientos de negocio, requerimientos de usuario y requerimientos
funcionales, así como también varios requerimientos no funcionales. Los requerimientos de negocio representan a los objetivos
de alto nivel de la organización. Se registran en documentos que detallan la visión y alcance del proyecto. Los requerimientos de
usuario describen las funcionalidades que el sistema debe poseer, es decir, las tareas que los usuarios deben poder realizar
usando el sistema. Se registran en casos de uso o descripciones de escenarios. Los requerimientos funcionales definen las
funciones de software que los programadores deben desarrollar para que el producto permita a los usuarios realizar las tareas, y
de ese modo, satisfacer los requerimientos de negocio.

Requerimientos
de negocio

Atributos de
Documento de Visión y
calidad
Alcance
Requerimientos
no funcionales
Requerimientos
de usuario

Restricciones

Documento de Casos de Uso

Requerimientos Requerimientos
del sistema funcionales

Especificaciones de
requerimiento de software

Los requerimientos funcionales se documentan en las especificaciones de requerimientos de software (SRS), la cual describe
del modo más completo posible la conducta externa esperada del sistema de software. La SRS se utiliza en varias etapas como
en el desarrollo, testeo, prueba de calidad, etc. Además de los requerimientos funcionales, que describen la conducta que el
sistema debe exhibir y las operaciones que realiza, la SRS contiene los requerimientos no funcionales: los estándares,
regulaciones y contratos a los cuales un producto debe adherirse; descripciones de las interfaces; requerimientos de
desempeño; restricciones al desarrollo y al diseño.
Es posible que los gerentes o personal de marketing sean capaces de definir los requerimientos de negocio para el software
que ayudará a que la organización opere de un modo más eficiente, o mejorará su competitividad en el mercado. Los
requerimientos de usuario deben estar alineados con los requerimientos de negocio. Los requerimientos de usuario permiten al
analista obtener los lineamientos generales de las funciones que permitirán a los usuarios desempeñar las tareas con el
producto. Los desarrolladores utilizan los requerimientos funcionales para diseñar soluciones que implementen las
funcionalidades necesarias.
Hay que separar el entendimiento de requerimientos de los detalles de diseño e implementación así como también de la
información de la planificación del proyecto, o del testeo. Esto se hace de modo que las actividades de requerimiento se puedan
concentrar en entender lo que hay que desarrollar.

“…if we don’t write down even our implicit and assumed requirements, we shouldn’t be surprised if the software doesn’t meet our
expectations.”

Riesgos del mal desarrollo del proceso de requerimientos

Es un problema serio que el equipo de proyecto se muestre negligente ante el proceso de análisis de requerimientos, ya que
conlleva a los siguientes riesgos:
 Insuficiente involucramiento del usuario lleva a productos inaceptables. Los clientes no suelen entender porque es
tan crucial trabajar duro en la recolección de requerimientos y en asegurar su calidad. Los programadores no suelen
enfatizar el involucramiento con el usuario, ya sea porque les parece aburrido o porque creen que saben lo que ellos
necesitan. Los representantes de los usuarios no suelen saber lo que de verdad necesitan sus representados.
 Aminorar los requerimientos de usuario contribuye a degradar la calidad del producto. Si se realiza una planificación
que no toma en serio los requerimientos, suele suceder que el proyecto y sus requerimientos crecen
proporcionalmente, causando que se excedan los tiempos y el presupuesto. Para evitar esto se deben establecer
claramente los criterios de visión, alcance, objetivos, limitaciones y éxito, ya que serán el marco de referencia para
comparar todas las funciones nuevas o cambios propuestos. Evaluar de modo correcto el impacto de cada cambio
facilitará la toma de decisiones al respecto y reducirá su impacto en el proyecto.
 Requerimientos ambiguos llevan a perdidas de tiempo y a tener que rehacer el trabajo. La ambigüedad lleva a
diferentes expectativas por parte de ambos grupos, y es así como el cliente se sorprende cuando ve lo que recibe y
como resultado hay rehacer el trabajo.
 El perfeccionismo de los desarrolladores y usuarios lleva a añadir funciones innecesarias. Suele ocurrir que los
programadores, creyendo que será bueno, agregan nuevas características al sistema. Frecuentemente esto es útil
para los usuarios, y ese tiempo está mal gastado. Lo útil sería que los programadores presenten ideas, alternativas y
enfoques creativos a los usuarios. No se deben agregar elementos sin la aprobación del cliente. Del mismo modo, los
clientes pueden pedir nuevas características que pueden parecer buenas pero tienen poco valor funcional.
 Especificaciones minimalistas llevan a omitir requerimientos clave. Hay una tendencia a minimizar las descripciones
de los requerimientos. Puede ocurrir que el desarrollador escriba los requerimientos luego de que el proyecto esté en
marcha. Todo esto produce la frustración de ambo lados.
 Atender de reojo las necesidades de usuarios lleva a clientes insatisfechos. Cada producto es usado por distintos
grupos de usuarios, cada uno con sus propias creencias, frecuencias de uso, niveles de experiencia, etc. Si el analista
no puede identificar a todos estos grupos, alguno de ellos se verá insatisfecho.
 Definiciones incompletas de requerimientos hacen que sea imposible planificar y supervisar el proyecto
eficazmente. La mayoría de las causas para malas estimaciones de costo del software se relacionan con cambios
frecuentes en los requerimientos, requerimientos faltantes, comunicación insuficiente con los usuarios,
especificaciones pobres, y análisis insuficiente de lo requerimientos.
Desarrollo y gestión de los requerimientos
Puede ser útil dividir el proceso de la ingeniería de los requerimientos en dos partes: desarrollo de los requerimientos y
gestión de los requerimientos.

Búsqueda de
información
Desarrollo de los
requermientos
Análisis
Ingeniería de los
requrimientos
Gestión de los Especificaciones
requerimientos

Verificación

El desarrollo de requerimientos se subdivide en: búsqueda de información, análisis, especificaciones, y verificación. Estas
actividades incluyen lo siguiente:
 Identificar las clases de usuarios que usarán el producto, e individuos que representen a cada clase.
 Entender las tareas de los usuarios, así como los objetivos y las necesidades del negocio que son satisfechas por tales
tareas.
 Analizar la información recibida por el usuario para distinguir sus necesidades de trabajo respecto de los
requerimientos funcionales, reglamentaciones del negocio, atributos de calidad, soluciones sugeridas e información
complementaria.
 Particionar los requerimientos de sistema en subsistemas y asignar una porción de esos requerimientos a
componentes de software.
 Entender la importancia de los atributos de calidad del software.
 Las prioridades de la negociación la implementación.
 Traducir los requerimientos de usuario en especificaciones escritas y modelos.
 Revisar las especificaciones de los requerimientos para asegurar un acuerdo común respecto de los requerimientos
establecidos por los usuarios y corregir cualquier posible problema antes que el grupo de desarrollo comience su
trabajo.

La gestión de requerimientos se basa en establecer y mantener un acuerdo con el cliente respecto de los requerimientos para
el proyecto de software. Tal acuerdo toma forma en las especificaciones escritas y los modelos. El Sí de los clientes es solo la
mitad de esta etapa. Los desarrolladores también deben aceptar el acuerdo y transformarlo en un producto. Las actividades de
esta etapa son:
 Definir las bases de los requerimientos y controlar los cambios que se les hacen.
 Revisar los requerimientos propuestos y evaluar el posible impacto de los cambios que se le apliquen antes de decidir
si se aplicarán o no.
 Si se incorporan cambios a los requerimientos, hacerlo de un modo controlado.
 Mantener la planificación en sincronía con los requerimientos.
 Rastrear el estado y los cambios durante el proyecto.

El Usuario
Es muy probable que el sistema falle en el futuro si no se le permite al analista obtener los requerimientos de usuario
directamente de los usuarios mismos. Esto suele ocurrir porque el ejecutivo que solicita el proyecto no comprende, o no quiere
comprender las diferencias entre los requerimientos del negocio y los requerimientos del usuario.

¿Quién es el cliente? Es el individuo u organización que se beneficia directa o indirectamente de un producto. El cliente que
pide y paga por el sistema es, generalmente, el responsable de especificar los requerimientos de negocio. Aún así estos
requerimientos no proveen de suficiente detalle al analista como para que este pueda decir que se debe desarrollar.
 El siguiente nivel de requerimientos (requerimientos de usuario) debe recolectarse de la gente que utilizará el producto. Tales
usuarios, también conocidos como usuarios finales, constituyen otro tipo de clientes de software. Los usuarios describen tanto
las funciones que precisan en el sistema para realizar sus tareas, como las características no funcionales que son importantes
para la aceptación del producto.
Desafortunadamente, ambos tipos de clientes pueden sentir que no tienen tiempo para trabajar en el análisis de
requerimientos. Puede ocurrir que esperen que el analista sea quien pueda descifrar lo que los usuarios necesitan sin charla ni
documentación.

La sociedad cliente-desarrollador. Los mejores productos de software son resultado de un diseño bien ejecutado basado en
excelentes requerimientos. Los requerimientos de mejor calidad son resultado de una comunicación efectiva y colaboración
entre el analista/desarrolladores y los clientes. Generalmente esta relación es de carácter adversa. El esfuerzo conjunto solo
funciona cuando ambos equipos saben lo que se necesita para alcanzar el éxito, y cuando respetan y comprender lo que el otro
equipo necesita para llegar al éxito. Los clientes ocupados pueden no querer estar íntimamente involucrados con la ingeniería de
los requerimientos. La falta de compromiso del cliente incrementa el riesgo de desarrollar el producto equivocado. Al menos, se
debe estar seguro de que todos los participantes están al tanto de las consecuencias y pueden asumir las responsabilidades.
Un aspecto importante que deben considerar ambos equipos es que suele ser imposible determinar de antemano todos los
requerimientos. El sistema y su planificación deben ser lo suficientemente flexibles como para aceptar los cambios que se
agreguen en la marcha, siempre que estos estén controlados y aceptados por ambos grupos.

Documentación de los requerimientos

El proceso de requerimientos tiene como producto final un acuerdo documentado en los clientes y el equipo de desarrollo
respecto del producto a construir, en el que se encuentran los tres tipos de requerimientos: de usuario, de negocio y
funcionales. El documento de visión y alcance contiene los requerimientos de negocio, mientras que los requerimientos de
usuario se capturan en documentos de casos de uso. El analista también debe documentar tanto los requerimientos funcionales
capturados en los casos de uso como los requerimientos no funcionales del producto, que incluyen atributos de calidad y
requerimientos de interfaz. Estos requerimientos se deben escribir de modo estilístico y organizado, y debe asegurar que los
clientes clave (quienes aportan el capital) los aprueben.
Hay tres maneras de documentar los requerimientos de software:
 Documentos de texto que usen un lenguaje estructurado, cuidadosamente escrito y natural.
 Modelos gráficos que ilustren procesos de transformación, estados del sistema y los cambios que sufre, relaciones de
datos, clases de objeto y sus relaciones.
 Especificaciones formales que definen los requerimientos mediante un lenguaje matemático, preciso, formal y lógico.
Aún cuando las especificaciones formales proveen rigor y precisión, pocos desarrolladores y aún menos clientes están
familiarizados con la notación formal, por lo tanto el lenguaje natural es la manera más práctica de documentar los
requerimientos para los proyectos de software. Un documento de texto que incluya los requerimientos funcionales y no
funcionales podrá satisfacer las necesidades de la mayoría de los proyectos. Los modelos de análisis gráfico que argumenten las
especificaciones de los requerimientos de software dan otros puntos de vista para los requerimientos.

Las especificaciones de requerimientos de software (SRS)

Las SRS establecen claramente las funciones y capacidades que un sistema de software debe proveer y las restricciones que
debe respetar. Es la base para toda planificación subsecuente de proyecto, diseño y codificación, así como también como los
fundamentos para el testeo del sistema y la documentación para el usuario. Las SRS deben describir del modo mas completo la
conducta externa que pretende ver el usuario en el sistema. No debe contener detalles de diseño, desarrollo, testeo, o gestión,
excepto por las restricciones de diseño e implementación.
Por ser una de las herramientas más importantes las SRS deben contener todas las especificaciones. No se debe asumir nada.
Lo que no se encuentre especificados en las SRS no será parte del acuerdo y por lo tanto nadie debe esperar que esté incluido
dentro del producto.
Todo esto no implica que se deban escribir las SRS completas antes de comenzar el diseño y la construcción, el hecho es que
pueden aparecen nuevos requerimientos. Sin embargo, es importante definir una base de acuerdos para cada conjunto de
requerimientos a ser implementados. Los cambios en la SRS se hacen mediante los procesos de control definidos del proyecto.
Todos los participantes deben trabaja en el mismo conjunto de requerimientos aprobados para evitar tener que rehacer
trabajos y tener malentendidos.
Las SRS se deben reestructurar y escribir de modo que los usuarios y otros lectores la puedan entender. Se deben tomar en
cuenta las siguientes sugerencias:
  Numerar secciones, subsecciones y requerimientos individuales consistentemente.
 Dejar el texto en el margen derecho en ves de justificarlo.
 Usar libremente el espacio en blanco.
 Usar distintos formatos para enfatizar (como cursiva, negrita, subrayado, etc.) de modo coherente y sensato.
 Crear una tabla de contenidos y un índice para ayudar a los lectores a encontrar la información que buscan.
 Numerar y etiquetar todas las figuras y tablas y referirse a ellas por sus números.
 Usar vínculos para hacer referencia a otros elementos o localizaciones dentro del documento.

Etiquetar requerimientos
Para satisfacer los criterios de calidad de las SRS de rastreable (poder buscar y encontrar elementos dentro del documento) y
de modificable, cada requerimiento de software debe tener su identificador único, lo que permite hacer referencia a
requerimientos específicos en pedidos de cambio, historiales de modificación, etc. Hay varios métodos para poder etiquetar los
requerimientos:
Numeración secuencial. La manera más simple es darle a cada requerimiento un número único secuencial que puede estar
compuesto de letras y números. Un prefijo compuesto de letras indica el tipo de requerimiento (UR, FR y BR). Los números no se
reutilizan incluso si se elimina un requerimiento de la base de datos. Este método no provee ningún agrupamiento basado en
jerarquías o lógica para relacionar los requerimientos, y las etiquetas no dan indicios sobre el contenido del requerimiento.

Numeración jerárquica. Es la convención más usada. Por ejemplo, si los requerimientos funcionales aparecen en la sección
3.2, entonces todos tendrán etiquetas que empiecen con tal numeración como 3.2.4 o 3.2.5.2. Más dígitos en la etiqueta indican
un requerimiento mas detallado de menor nivel. Este método es simple y compacto, sin embargo, las etiquetas pueden llegar a
expandirse por muchos dígitos y no dicen nada sobre el propósito de cada requerimiento. También puede producirse cierto caos
cuando se inserta un nuevo requerimiento, ya que la numeración cambia radicalmente.
Una manera de mejorar este método consiste en numerar las secciones mayores de los requerimientos jerárquicamente y
luego identificar los requerimientos funcionales individualmente en cada sección agregando un texto corto seguido de una
secuencia numérica, por ejemplo: “Sección 3.2.5- Funciones del editor,“ y los requerimientos en esa sección pueden etiquetarse
como FE-1, FE-2, y así. De este modo se logra mantener las etiquetas cortas y además se puede dar una idea al lector sobre que
trata el requerimiento.

Etiquetas textuales jerárquicas. Si se considera el siguiente requerimiento: “El sistema deberá pedir al usuario que confirme
cualquier solicitud para imprimir más de diez copias”. Este requerimiento se etiquetaría como IMPRIMIR.COPIAS.CONFIRMAR, lo
cual indica que es parte de las funciones de impresión y se relaciona con la eventual configuración de la cantidad de copias a
imprimir.
Esta jerarquía es estructurada y tiene sentido semánticamente, además no se ve afectada por la adición y remoción de
requerimientos. Su inconveniente más notable es su aspecto burdo.

Tratar con la incompletitud

La notación TBD (“to be determined”) se usa para resaltar la falta de conocimiento, que sea más fácil de encontrar dentro de la
SRS. Es conveniente crear una lista de todas las TDB así como también documentar quien, como y cuando se resolverá tal
inconveniente.
Se deben resolver todas las TDBs antes de proceder con el desarrollo de un grupo de requerimientos. Si no se pueden resolver
y es imperativo proceder con la construcción, se debe hacer al sistema lo suficientemente flexible como para aplicarle cambios
cuando sea necesario.

Interfaces de usuario y las SRS

La incorporación de interfaces de usuario en las SRS tiene tanto ventajas como desventajas. Por el lado negativo, las interfaces
de usuario son descripciones de soluciones (diseños) y no de requerimientos. Si no se establece la base de las SRS antes de que
el diseño de la interfaz esté completo, el proceso de desarrollo de requerimientos tomará más tiempo.
En el lado positivo, explorar las interfaces de usuario potenciales puede ayudar a desarrollar los requerimientos y hacer la
interacción usuario-sistema más tangible tanto para el usuario como para los desarrolladores.
La inclusión de bocetos de las interfaces de usuario seleccionadas es un equilibrio sensato, siempre que no se cree la
expectativa de que se debe seguir obligatoriamente tales modelos.
Escritura de requerimientos
No existe una fórmula para escribir bien los requerimientos, ya que el modo de aprendizaje se da por la experiencia. La
documentación de requerimientos puede mejorarse siguiendo algunas guías de escritura técnica e incorporando la terminología
del usuario. Además es conveniente considerar las siguientes recomendaciones:
 Escribir oraciones y párrafos cortos.
 Evitar la voz pasiva.
 Escribir oraciones completas con una buena gramática, ortografía y puntuación.
 Usar términos consistentemente como están definidos en el glosario.
 Declarar los requerimientos de un modo consistente seguido por un verbo de acción y por un resultado visible.
 Evitar términos subjetivos y vagos para no tener que lidiar con la ambigüedad.
 Evitar términos comparativos que no estén cuantificados.

Como los requerimientos se escriben jerárquicamente se puede descomponer un requerimiento ambiguo en especificaciones
de menor nivel que clarifican y eliminan la ambigüedad. Se deben escribir los requerimientos detalladamente para evitar malos
entendidos. Se debe evitar combinar requerimientos y el uso de “y/o” o “etc.”
Se debe evitar la declaración redundante de requerimientos, ya que al actualizar el documento es fácil olvidarse de actualizar
alguna de esas apariciones.

Priorización de Requerimientos
Cuando las expectativas de los clientes son altas, y sin embargo los recursos y el tiempo son pocos, hay que asegurar que el
producto entregado tendrá las funcionalidades más esenciales lo antes posible. Si se establece la importancia relativa de cada
función, se puede planificar un desarrollo que provea un producto con el mayor valor al menor costo.
El gerente del proyecto debe equilibrar el alcance del proyecto deseado contra las restricciones de tiempo, presupuesto,
recursos de personal, y metas. Una manera de lograrlo es eliminar o dejar para próximas entregas a las funciones de menor
prioridad. Si los clientes no son capaces de diferenciar las prioridades de sus requerimientos y urgencia, esa decisión recae en el
gerente del proyecto. Como los clientes pueden no estar de acuerdo con las decisiones del gerente, deben indicar cuales
requerimientos son necesitados desde un comienzo y cuales pueden esperar.
Los clientes son quienes deciden que funciones son las más importantes en cuanto a su satisfacción. El desarrollador debe
señalarle al cliente el costo, dificultad, riego técnico y otros inconvenientes y detalles asociados a cada requerimiento, de modo
que el cliente reconsidere si tal recurso es esencial o no. El desarrollador también puede señalar al cliente que funciones que
éste considera menores son vitales.

Escalas de prioridad
Se pueden agrupar los requerimientos en cada grupo de las tablas a continuación, para simplificar la tarea de organizar por
prioridades. Se debe tener en cuenta que estas son subjetivas e imprecisas, por lo que se necesita el consenso de todos para
poder decidir el significado de cada nivel de agrupamiento.
La prioridad de cada requerimiento debe estar incluida en las SRS, indicando las convenciones usadas de modo que el lector
sepa si la prioridad asignada a un requerimiento de alto nivel es heredada por todos sus requerimientos subordinados, o si cada
requerimiento individual debe tener su propio atributo de prioridad. Se debe tomar en cuenta que las prioridades pueden
cambiar mientras avanza el proyecto.
Nombres Significados
Alta Un requerimiento critico para la misión del proyecto que se necesita disponible en la siguiente
entrega.
Media Operaciones necesarias para el sistema que son requeridas eventualmente pero pueden
esperar a una próxima entrega de ser necesario.
Baja Una función o atributo que sería bueno tenerlo en algún momento si los recursos lo permiten.

Esencial El producto no sería aceptable a menos que estos requerimientos sean provistos del modo
acordado.
Condicional Mejoraría el producto, pero su ausencia no lo haría inaceptable.
Opcional Un tipo de función que puede o no ser útil.
3 Debe ser implementado a la perfección.
2 Debe funcionar, pero no de un modo espectacular.
1 Puede contener Bugs
 Rastreabilidad de requerimientos
Los vínculos de rastreabilidad permiten rastrear la “vida” de un requerimiento anterior y posterior. Para lograr la
rastreabilidad, cada requerimiento debe tener su etiqueta única para poder referirse a el sin riesgo de ambigüedad.
La mayoría de las aplicaciones incluyen código que no se relaciona directamente con los requerimientos especificados por el
usuario, pero el desarrollador debe saber porque escribe cada línea de código. Si no se puede rastrear un elemento hacia un
requerimiento, entonces puede que algún desarrollador haya querido agregar una característica más al sistema, pero, si estos
elementos representan una funcionalidad legítima, entonces puede que las SRS estén incompletas.
Los vínculos de rastreabilidad ayudan a rastrear parentescos, interconexiones y dependencias entre requerimientos
individuales. Esta información sirve para identificar la ola de cambios que se producirían de eliminarse o modificar algún
requerimiento especifico.
La figura ilustra cuatro tipos de vínculos de rastreabilidad. Las necesidades de los
Necesidades de clientes se rastrean adelante hacia los requerimientos, de modo que se puede ver
Clientes como tales requerimientos se ven afectados si tales necesidades cambian, y además
da la confianza de que la especificación ha atendido todas las necesidades de los
Adelante hacia los Atrás desde los clientes declaradas. También se puede rastrear atrás desde los requerimientos hacia
requerimientos requerimientos las necesidades de los clientes, para poder identificar el origen de cada
requerimiento de software. Mientras los requerimientos de sistema fluyen hacia los
Requerimientos requerimientos de software, diseños, código y otros artefactos durante el desarrollo,
se puede rastrear adelante desde los requerimientos definiendo vínculos entre los
Adelante desde los
requerimientos y elementos específicos del producto, lo cual indica que se han
Atrás hacia los
requerimientos satisfecho todos los requerimientos ya que se sabe a que componente del producto
requerimientos
le corresponde cada uno. El último tipo de vínculo rastrea cada elemento específico
del producto atrás hacia los requerimientos para saber porque se creó cada
Productos
elemento.
Trabajados

Si se mapearon requerimientos específicos en tareas dentro de la estructura del producto, tales tareas van a verse afectadas
cuando un requerimiento cambie o sea borrado.
Hay varios tipos de relaciones de rastreabilidad directa que se pueden definir en un producto, aunque no es necesario
manejarlos todos, se pueden seleccionar cuales vínculos son pertinentes para el proyecto y contribuyen al desarrollo exitoso y al
mantenimiento eficiente.

Motivaciones para la rastreabilidad de requerimientos

Rastrear requerimientos es una tarea manual e intensiva que requiere del compromiso de la organización. Mantener los
vínculos actualizados a medida que se progresa en el desarrollo o se realiza el mantenimiento requiere de disciplina. Una vez la
información de rastreabilidad se vuelve obsoleta probablemente nunca se la reconstruya. Debido a esto es que hay muchos
motivos para realizar esta tarea, la cual trae los siguientes beneficios:
 Certificación. La información de rastreo puede ser usada para certificar que todos los requerimientos fueron
implementados.
 Análisis del impacto de un cambio. Sin la información de rastreo es probable que se omita algún elemento del
sistema que puede ser afectado al añadir, eliminar, o modificar un requerimiento particular.
 Mantenimiento. Información de rastreabilidad confiable facilita la realización correcta de cambios durante el
mantenimiento, lo cual mejora la productividad.
 Rastreo del proyecto. Si se almacenaron correctamente los datos de rastreo durante el desarrollo, se tendrá un
registro preciso del estado de implementación de las funcionalidades planeadas. Los vínculos que faltan indican los
elementos del producto que no se crearon aún.
 Ingeniería Inversa. Se pueden listar las funciones en un legajo del sistema y registrar donde se les hace referencia en
los nuevos requerimientos del sistema y componentes de software.
 Reutilización. Las rastreabilidad facilita la reutilización de componentes de un producto identificando paquetes de
requerimientos relacionados, diseños, código, testeos, etc.
 Reducción del riesgo. Documentar las interconexiones de componentes reduce el riesgo de que haya errores cuando
ocurran eventos como que se vaya un miembro del proyecto.
 Testeo. Los vínculos entre testeos, requerimientos y código apuntan a partes del código que son propensas a tener
bugs cuando el sistema falle.
 Muchos de estos son beneficios a largo plazo, que reducen el costo total del ciclo de vida del producto pero aumentan el costo
del desarrollo debido al esfuerzo que implica la acumulación y la gestión de la información de rastreo. Hay que tener en cuenta
que recolectar la información para los vínculos de rastreo es una tarea mucho más amena si se realiza mientras el sistema se
desarrolla y no cuando este ya está terminado.

Matriz del rastreo de requerimientos

La manera más común de representar los vínculos entre requerimientos y componentes del sistema es mediante esta matriz.
Ésta muestra como cada requerimiento funcional se vincula hacia atrás a un caso de uso especifico, y hacia adelante a uno o
mas diseños, código y elementos de testeo. Los elementos de diseño pueden ser objetos en modelos como diagrama de flujo de
datos, tablas en un modelo relacional de datos, o clases de objeto. Las referencias de código pueden ser método dentro de una
clase, nombre de archivos en el código fuente, o procedimientos o funciones dentro del código fuente. Las columnas de la
matriz se agregan para extender los vínculos hacia otros productos, como documentación.
Los vínculos de rastreo pueden definir relaciones uno-a-uno, uno-a-varios, o varios-a-varios entre tipos de elementos del
sistema. Por ejemplo:
 Uno-a-uno. Un elemento del diseño se implementa en un módulo del código.
 Uno-a-varios. Un requerimiento funcional se verifica por múltiples casos de uso.
 Varios-a-varios. Cada caso de uso lleva a varios requerimientos funcionales, y ciertos requerimientos funcionales son
comunes a varios casos de uso.
La realización de la matriz de rastreo de requerimientos es muy útil para pequeños proyectos. Una vez los casos de uso están
definidos, se puede empezar a añadir requerimientos funcionales derivados de cada caso de uso a la matriz. Se sigue
completando la matriz a medida que se procede con el diseño de software, el desarrollo y los testeos.
Otra manera de representar la información de rastreo es mediante un conjunto de matrices que define los vínculos entre
pares de elementos del sistema como:
 Un tipo de requerimiento a requerimientos de otro tipo.
 Un tipo de requerimiento a otros requerimientos del mismo tipo.
 Un tipo de requerimiento a casos de uso.
Esta matrices se pueden usar para definir las distintas relaciones posibles entre pares de requerimientos, tales como
“especifica/es especificado por”, “depende de”, “es pariente de”, “restringe/ es restringido por”, etc.
Cada celda en la matriz en la intersección de dos componentes vinculados se marca para indicar la conexión. Se pueden usar
distintos símbolos para indicar explícitamente “rastreado hacia” y “rastreado desde” u otras relaciones.
Los vínculos de rastreo deberían ser definidos por quien tenga la información apropiada, por lo que es importante definir los
roles y los individuos que proveerán al proyecto de cada tipo de información de rastreo.

Herramientas para el rastreo de requerimientos

El rastreo de requerimientos nunca puede estar completamente automatizado, ya que el conocimiento en el que se basa
proviene de las mentes de los miembros del proyecto. Sin embargo, una vez identificados los vínculos, algunas herramientas
pueden ayudar a gestionar la vasta información de rastreo.
Se pueden almacenar requerimientos y otra información es la base de datos de una herramienta y definir los vínculos entre los
distintos tipos de objetos almacenados, incluyendo pares de vínculos entre dos requerimientos del mismo tipo. Algunas
herramientas permiten diferenciar relaciones del tipo “rastreado hacia” y “rastreado desde” y definir automáticamente los
vínculos complementarios. Otras avisan al usuario que elementos del sistema debe revisar luego de aplicar un cambio.

Procedimiento de rastreo de requerimientos

1. Decidir que tipos de relaciones vinculadas se quiere definir.
2. Usar la matriz de rastreo deseada.
3. Identificar las partes del producto para las cuales se quiere mantener información de rastreo. Comenzado por las
funciones vitales, las partes de alto riesgo, o las porciones que se cree que sufrirán más mantenimiento y evolución a
través del tiempo.
4. Modificar los procedimientos y listas de chequeo para recordar a los desarrolladores que actualicen los vínculos luego
de realizar un cambio.
5. Definir las convenciones de etiquetamiento que se usaran para identificar cada elemento del sistema de modo que
puedan ser vinculados.
6. Identificar los individuos que proveerán cada tipo de información.
 7. Enseñar al equipo los conceptos y la importancia del rastreo de requerimientos, los objetivos para tal actividad,
donde se almacena tal información, y las técnicas usadas para definir los vínculos.
8. Informar a los participantes que los datos de rastreo deben ser actualizados cada vez que alguien termina una tarea
que genere un cambio o un vínculo en la cadena de requerimientos.
9. Revisar la información de rastreo periódicamente mientras el desarrollo progresa para asegurarse de que está
actualizada.

Análisis del impacto (de los cambios)

Es una parte importante de la gestión responsable de los requerimientos. Provee un entendimiento preciso de las
implicaciones de un cambio propuesto, ayudando al analista a tomar decisiones de negocio bien informado sobre que
propuestas aceptar. El análisis examina el contexto de los cambios propuestos para identificar los componentes existentes que
deben ser modificados o descartados. Identifica que nuevos elementos del producto hay que crear y estima el esfuerzo asociado
a cada tarea. La habilidad del analista para realizar el análisis del impacto depende de la calidad y la completitud de la
información de rastreo.

Procedimiento del análisis del impacto. Es conveniente tener una primera lista de control con preguntas diseñadas a ayudar al
analista a comprender las implicaciones de aceptar un cambio. Una segunda lista de control contiene preguntas para ayudar a
identificar los elementos de software que el cambio afectará. Luego de adquirir cierto nivel de experiencia, el analista a puede
modificar o crear sus propias listas de control para adaptarlas a la naturaleza de sus proyectos.
Ejemplos de preguntas de la primera lista de control:
 ¿Algún requerimiento existente entra en conflicto con el cambio propuesto?
 ¿Cuáles son las consecuencias técnicas y del negocio de no adoptar el cambio?
 ¿Acaso el cambio propondrá demandas inaceptables en los recursos de cualquier computadora requerida para el
desarrollo, testeo, entre otras?
 ¿Causará un aumento en el costo unitario del producto?

Ejemplos de preguntas de la segunda lista de control:

 Identificar los componentes de diseño que se deben crear, modificar o eliminar.
 Identificar cualquier cambio requerido en los archivos creados.
 Identificar otras aplicaciones, librerías o componentes de hardware afectados por el cambio.
 Identificar que elementos del producto deben revisarse luego de que se aplique el cambio.

Muchos de los problemas de estimación surgen cuando el encargado no considera todos los pasos para completar una
actividad. El procedimiento para el impacto de análisis puede ser el siguiente:
1. Completar la primera lista de control.
2. Completar la segunda lista de control usando toda la información de rastreo disponible.
3. Usar una lista de trabajo para estimar el esfuerzo requerido para las tareas anticipadas.
4. Estimar el esfuerzo total.
5. Identificar la secuencia en que las tareas deben ser realizadas y como pueden entreverarse con las tareas ya
planificadas.
6. Determinar si el cambio se realiza sobre el sendero crítico del proyecto. Si se realiza un cambio allí el proyecto puede
sufrir un desliz y retrasarse.
7. Estimar el impacto del cambio propuesto en la agenda del proyecto y su costo.
8. Evaluar la prioridad del cambio estimando el beneficio relativo, costo, riesgo técnico, entre otros, comparado con
otros requerimientos.
9. Reportar los resultados del análisis de impacto a quienes toman las decisiones para que decidan si este se acepta o
no.

Requisitos de software
Son las cualidades que debe tener el software para ser aceptado por el usuario, es decir, lo que hará para satisfacer los
requerimientos de éste.
La parte más difícil de la construcción de un sistema de software es decidir qué se quiere construir. Ninguna parte del trabajo
conceptual es más difícil, ni afecta tanto al sistema resultante como la definición de los requisitos.
 Los requisitos pueden ser:
Requisitos funcionales. Aquellos que describen los servicios o funciones que se esperan del sistema.
Requisitos no funcionales. Son más que nada restricciones sobre los requisitos funcionales, y se pueden subdividir en:
requisitos del producto, que son cualidades del software; requisitos del proceso, que son el tiempo y la forma en que se
implementan los estándares a cumplir; y requisitos externos, que son las leyes, la ética, las políticas, entre otros, a los que el
software se debe adherir.
Hay dos modos de ver a los requisitos. Es importante notar que, a pesar que nos indican lo que se debe hacer, implícitamente
nos dicen lo que no se debe hacer. Cuando los requisitos nos limitan el ámbito del sistema, en realidad nos muestran donde no
se deben emplear los recursos. Mantener la distinción liveness/safety (lo que se debe hacer/lo que no se debe hacer) es
fundamental para sistemas críticos.

El proceso de requisitos

Educción de Análisis y Documentación Validación de

Requisitos Negociación de Requisitos Requisitos

Necesidades del usuario

Documento de
Información del dominio
Requisitos
Información sistema actual

Estándares, leyes, etc

Gestión de Requisitos
Atender los nuevos requisitos que van apareciendo, negociando con el usuario

La ingeniería de requisitos es un conjunto estructurado de actividades de cuya ejecución de obtiene, valida y mantiene el
documento de requisitos del sistema. Tal proceso consta de cuatro etapas:
1. Educción de requisitos. Capturar y descubrir cuales son los requisitos. Las fuentes de información pueden ser las
metas o factores críticos de éxito, el conocimiento del dominio de la aplicación, los interesados y afectados por el
sistema, el entorno físico que rodeará al sistema, el entorno organizacional, etc.
Algunos de los problemas que pueden surgir durante la educción pueden ser que los usuarios no puedan o sepan
describir muchas de sus tareas, o que se omita información importante durante una charla porque no se la considera
importante. Debido a esto puede que se tengan que inventar los requisitos. Siempre hay que tomar en cuenta que la
educción es un proceso cooperativo y hay muchas técnicas para lograrlo efectivamente como entrevistas,
brainstorming, escenarios, etc.
2. Análisis y negociación de requisitos. Esta etapa se subdivide en varias partes más:
a. Análisis. Se debe detectar los conflictos entre requisitos e intentar resolverlos, además de su límite y su
relación con el entorno.
b. Clasificación. Se los clasifican según su:
i. Funcionalidad: Funcionales (capacidades) o no funcionales (restricciones).
ii. Importancia: Obligatorios o esenciales, condicionales o deseados, y opcionales.
iii. Prioridad: Alta, baja o media.
iv. Estabilidad relativa: Volátiles (cambian constantemente), estables, o moderados.
v. Costo.
c. Modelación conceptual. Algunos aspectos de los requisitos se deben expresar mediante modelos de datos,
de objetivos, etc. Para entender claramente el problema. Esto depende de la naturaleza del problema y de la
experiencia del modelador, de la disponibilidad de herramientas, y de la imposición del cliente.
d. Negociación de requisitos. En todo el proceso de requisitos intervienen individuos con distintos intereses.
Esto deriva en una negociación para determinar que requisitos se tomarán en cuenta y cuales no. Cuando se
resuelven todos los conflictos se tiene un URD (Documento de requisitos de usuario) completo
 3. Documentación de requisitos. Es el modo habitual de almacenar y comunicar requisitos. Se usan dos documentos
que se diferencian únicamente en el nivel de detalle que contienen.
i. URD: Se lo escribe desde el punto de vista del usuario/cliente. No posee un alto nivel de detalle. En el, se
incluye la descripción del problema actual junto con las razones por la cual el sistema actual es
insatisfactorio, y las metas que se quieren lograr con el desarrollo del nuevo sistema. En síntesis, es un
documento que describe el dominio del problema.
ii. SRS. Contiene el dominio de la solución.
4. Validación de requisitos. El objetivo de esta parte del proceso es descubrir problemas en el documento de requisitos
antes de comprometer recursos en su implementación. El documento se revisa para descubrir omisiones, conflictos
ambigüedades y comprobar la calidad del mismo junto con su grado de adhesión a los estándares.
La fórmula más empleada para validar el documento es la revisión del mismo, y consta de tres fases: la búsqueda de
problema, reunión y acuerdo.

Gestión de requisitos
Consiste en gestionar cambios a los requisitos, asegurando la consistencia entre estos y el sistema desarrollado. Esto consume
mucho tiempo y esfuerzo y abarca todo el ciclo de vida del producto. Aún así s necesario debido a varios motivos: los requisitos
son volátiles, así también como cambia el entorno físico; trasladar un sistema de un entorno a otro requiere modificaciones; si el
entorno organizacional cambia también lo harán las políticas. También se debe considerar que cambios en las reglas y procesos
del negocio generaran cambios en el sistema, pero lo más importante es que la presencia misma del sistema generará cambios
en los usuarios.
La gestión de requisitos implica:
 Definir procedimientos de cambios: definir los pasos y los análisis a realizar antes de aceptar propuestas.
 Cambiar los atributos de los requisitos modificados.
 Mantener la rastreabilidad del sistema.
 Controlar las versiones de los documentos de requisitos.
Modelado de los sistemas
Gran parte del trabajo del analista involucra el modelado del sistema que desea el usuario. Hay muchos tipos de modelos que
se pueden elaborar, la mayoría de ellos son representaciones abstractas de lo que al final será una combinación de hardware y
software.
Los modelos se construyen para enfatizar aspectos críticos del sistema y darle menos importancia a otros aspectos que se
considera que son más triviales, lo cual permite una comunicación enfocada con el usuario. Además, resulta mucho más sencillo
realizar cambios sobre el modelo cuando se lo presenta que sobre el sistema mismo, resaltando la importancia de que primero
conviene modelar y luego, cuando todas las partes están de acuerdo, desarrollar el sistema. Es decir que el analista puede usar
el modelado para discutir cambios y correcciones de los requerimientos del usuario a bajo costo y con el mínimo riesgo, y para
verificar que se comprendió correctamente el ambiente del usuario y se lo respaldó con información documentada para que los
diseñadores y programadores puedan realizar el sistema.
No todas las herramientas de modelado cumplen con esto objetivos, por lo que el analista debe ser cuidadoso al elegir el
modo en que modelará el sistema. Un buen modelo debe tener las siguientes características: ser gráfico y con apoyo textual, ser
posible de ver en forma segmentada, ser lo menos redundante, ser transparente al lector, tener poca variedad de simbología y
reglas simples de escritura.

Diagrama de flujo de datos (DFD)

Consisten en procesos, almacenes de datos, flujos y terminadores.
Los procesos se representan con burbujas y se escriben con frases u oraciones sencillas del tipo verbo-sustantivo. Representan
las diversas funciones individuales que el sistema lleva a cabo. El nombre del proceso debe indicar lo que éste hace, aunque
puede que haya recursos con nombre de personas u grupos.
Los flujos se muestran como flechas curvas que salen y entran a procesos. Se usan para describir el movimiento de bloques o
paquetes de información de una parte del sistema a otra. Los flujos llevan nombre, el cual representa el significado del paquete
que se mueve a lo largo del flujo. Generalmente un flujo puede llevar un solo paquete, aunque pueden haber excepciones. Los
flujos indican otras cosas, como la dirección en la que se mueven los datos. Además, los flujos pueden converger o divergir en un
DFD; un flujo divergente indica que se pueden estar mandando copias de un paquete de datos a diferentes partes del sistema, o
bien que un paquete se divide en varios paquetes individuales que se distribuyen a distintas partes del sistema; mientras que
uno convergente significa que varios paquetes elementales de datos se unen para formar almacenes mas complejos de
paquetes de datos. Los flujos no indican cantidades, ni como suceden las peticiones, entre otras cosas más.
Los almacenes de datos se representan por medio de dos líneas paralelas y muestran colecciones o bases de datos que el
sistema debe recordar por un periodo de tiempo. Generalmente el nombre usado para identificar el almacén es el plural del
que se usa para los paquetes que entran y salen del mismo. Los analistas suelen referirse a los almacenes como archivos o bases
de datos, aunque almacén puede hacer referencia también a datos almacenados en memorias flash, tarjetas perforadas, etc. Los
almacenes se comunican mediante flujos a los procesos. Cuando un flujo conectado a un almacén no está rotulado es porque
contendrá toda la información de un paquete datos que se almacena en el almacén. Los almacenes son pasivos, es decir que los
datos no viajarán desde el almacén por el flujo hasta que el proceso lo solicite explícitamente. Un flujo hacia un almacén
generalmente describe una escritura, actualización o eliminación. Otro detalle importante es que los flujos conectados a un
almacén solo pueden transportar paquetes de información que el almacén pueda guardar.
Los terminadores muestran las entidades externas con las que el sistema se comunica. Se los representa con rectángulos.
Suelen ser individuos o grupos de personas, sistemas de cómputo externos y organizaciones externas, que están fuera del
control del sistema que se está modelando. Los flujos que conectan un terminador con algún elemento del modelo representan
la interfaz de comunicación entre ambos. Es imposible cambiar los contenidos de un terminador o el modo en que este trabaja.
Las relaciones entre terminadores no se muestran en un DFD.

Flujo Almacén
Procesos Terminador
 El proceso de construcción de un DFD.
1. Ponerle nombres significativos a los procesos, flujos, almacenes y terminadores.
2. Numerar los procesos.
3. Redibujar el DFD las veces que sea necesario para que esté organizado y sea comprensible.
4. Evitar DFDs complejos.
5. Asegurar la consistencia interna del DFD.
6. Tomar las siguientes precauciones:
 Evitar bucles de flujos en los procesos.
 Evitar sumideros infinitos (burbujas con entradas y sin salidas).
 Evitar burbujas de generación espontanea (burbujas con salidas y sin entradas).
 No dejar flujos y procesos sin etiquetar.
 Tener cuidado con los almacenes de solo lectura o solo escritura. Un almacén típico debe poder ser tanto
escrito como leído, excepto por los almacenes externos, que sirve de interfaz entre en el sistema y algún
terminador.

El DFD proporciona una visión global bastante conveniente de los componentes funcionales del sistema, pero no da detalles de
éstos. Para detallar qué información se transforma y cómo se transforma se pueden usar dos herramientas textuales de
modelado adicionales.

Diagrama de entidad-relación (DER)

El principal problema del DFD es que solo resalta las funciones del sistema, y en cuanto a la notación de los almacenes, nos
muestra que existen uno o varios grupos de datos almacenados pero dice poco o nada sobre sus detalles. Todo sistema
almacena y usa información que viene del entorno en el que opera y esta suele ser muy compleja. Al implementar el DER, se
logra conocer tanto la información detallada que hay en cada almacén, así como la relación que existe entre almacenes.
El DER es útil por otros motivos. Si, por ejemplo se tienen sistemas de consulta o de almacenamiento de datos ad hoc,
convendrá entonces construir el modelo DER sin si quiera construir un DFD.
El DER consta de cuatro componentes principales: Los tipos de objetos, las relaciones, los indicadores asociativos de tipo de
objeto, los indicadores de supertipo/subtipo.
El tipo de objeto se representa con un rectángulo. Representa un conjunto de objetos del mundo real cuyas instancias tienen
las siguientes características:
 Cada una puede identificarse de manera única por algún medio (como una clave).
 Para que el tipo de objeto sea legítimo, debe poder decirse que el sistema no puede operar sin tener acceso a esas
instancias.
 Cada uno puede describirse por uno o más datos.

Dado que generalmente las personas son tipos de objetos en un sistema, hay que saber que una persona, u otra cosa material,
pudiera ser distintos tipos de objetos en distintos modelos de datos, o incluso en el mismo modelo. Como convenio, los tipos de
objetos se notan con sustantivos.

Tipo de Objeto

Las relaciones representan un conjunto de conexiones entre objetos. Se dibujan con un rombo. Cada instancia de la relación
representa una asociación entre cero o más ocurrencias de un objeto y cero o más ocurrencias del otro, es decir que una
relación conecta dos o más instancias del mismo objeto.

Tipo de Objeto Relación Tipo de Objeto

Una notación alternativa muestra tanto la cardinalidad como la ordinalidad. El círculo en extremo izquierdo indica que ese tipo
de objeto es el punto de ancla u objeto primario, desde cuyo punto de vista debe leerse la relación. En el ejemplo de abajo,
solamente una instancia de A se puede relacionar con N instancias de B; excluyendo la posibilidad de que varios A se relacionen
con un solo B.
 1 N
Tipo de Objeto A Tipo de Objeto B

Una notación especial en el DER es el indicador asociativo de tipo de objeto, que representa una relación de la cual se quiere
mantener alguna información. Por ejemplo, si tenemos la siguiente relación:

Cliente Compra Artículo

Podemos inferir que un CLIENTE realiza una COMPRA de un ARTÍCULO, pero si queremos mantener información del tipo de
COMPRA, o de la hora, ¿dónde se almacena tal información? Ya que la hora no es atributo ni de cliente ni del ARTÍCULO. Si
asociamos la hora del día con la COMPRA misma bajo el siguiente esquema:

Cliente Artículo

Compra

COMPRA ahora se escribe dentro de un rectángulo conectado a la relación CLIENTE-ARTÍCULO mediante una flecha. De esto
podemos inferir que COMPRA funciona como un tipo de objeto capaz de almacenar información, en este caso la hora; a su vez,
COMPRA es una relación que conecta a los tipos de objetos CLIENTE y ARTÍCULO, por lo que ambos existirían con o sin la
COMPRA pero ésta no puede existir sin ambos.
Los tipos de objeto de subtipo/supertipo son tipos de objeto de una o más subcategorías, conectados por una relación. La
siguiente figura muestra un ejemplo típico:

Empleado

Empleado por Empleado

horas asalariado

Los subtipos se conectan al supertipo mediante una relación sin nombre, y el supertipo se conecta a la relación mediante una
línea con una barra. En esta notación el supertipo se describe por dato que se aplican a todos los subtipos, sin embargo, cada
subtipo se describe por media de datos diferentes; de otro modo no tendría sentido distinguirlos.
 Reglas para la construcción del DER.
1. Añadir tipos de objetos adicionales. Ya sea por descubrir nuevos datos aplicables a determinadas instancias de un tipo
de objeto pero no a otros, descubrir datos aplicables todas las instancias, ó datos que describan relaciones entre
tipos de objetos.
2. Eliminar tipos de objetos que consisten en un solo identificador, los que poseen solo una instancia, los tipos asociados
de objetos flotantes, las relaciones derivadas o calculadas. El proceso de eliminar objetos incluidos en otros es parte
de una actividad llamada normalización.

Normalización del DER. Consiste en simplificar el contenido dentro del almacén de datos buscando y eliminando los
elementos de datos redundantes. Hay tres tipos de formas normales establecidas:
1. Primera forma normal (1FN). No deben haber atributos repetitivos.
2. Segunda forma normal (2FN). Los atributos que aparezcan en una clave deben depender de toda la clave y no sólo de
parte de ella.
3. Tercera forma normal (3FN). Todos los atributos deben depender de la clave primaria

Diagrama de transición de estados (DTE)

Existen sistemas grandes y complejos enfocados a negocios que tienen aspectos de comportamiento de tiempo real, por lo
que, aunque el analista no tenga que tratar con problemas de este tipo en cada sistema que construye, debe poder manejar sus
herramientas de modelado.
Los principales componentes del DTE son estados y flechas que representan los cambios de estado.

Estado A

Estado D Estado C Estado B

Cada rectángulo representa un estado en el que se puede encontrar el sistema. Que el sistema se encuentre en un estado
dado suele indicar que está esperando la ocurrencia de algún evento. Las acciones ocurren instantáneamente en el modelo. Un
estado representa una condición observable en la que el sistema se puede encontrar y que dura un tiempo finito.
Un sistema de un solo estado se conoce como sistema estático. Los sistemas que generalmente se modelan tienen varios
estados. Si un sistema tiene reglas ordenadas que gobiernan su comportamiento, entonces generalmente sólo algunos tipos de
cambio de estado serán significativos y válidos. Los cambios de estado se simbolizan con las flechas que unen los estados, las
cuales además muestran a qué estados puede pasar un sistema cuando se encuentra en un estado dado. La mayoría de los
sistemas tienen un estado inicial reconocible y un estado final reconocible, aunque no son obligatorios. Lo que los identifica es
que el estado inicial tiene una flecha cuyo extremo apunta hacia el pero no tiene ningún estado origen, y el estado final es aquel
que no es origen de ninguna flecha.
Para completar el DTE se añaden las condiciones que causan el cambio de estado y las acciones que el sistema toma cuando
cambia de estado
Estado A

Condición
Acción

Estado B

Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de detectar y usualmente hace que el
sistema cambie de un estado de espera X a un estado de espera Y, o de realizar la actividad X a realizar la actividad Y. Como
parte del cambio de estado, normalmente el sistema hará una o más actividades. Las acciones mostradas en el DTE son
respuestas regresadas al ambiente externo o bien cálculos cuyos resultados el sistema recuerda para poder responder a un
acontecimiento futuro.
 Guía de construcción de un DTE.
1. Se identifican todos los estados posibles del sistema y se representa cada uno. Luego se exploran todas las conexiones
significativas entre estados.
2. Se identifica el estado inicial y luego se desarrolla un camino.
3. Se debe verificar:
 Si se definieron todos los estados.
 Si se pudieron alcanzar todos los estados.
 Si todos los estados tienen salidas.
 ¿En qué estado el sistema responde adecuadamente a todas las condiciones posibles? Es preciso identificar
el comportamiento del sistema en condiciones inesperadas.
Generalmente el DTE se usa como herramienta de modelado para las especificaciones de procesos de una burbuja de control,
pero también se puede usar como herramienta de modelado de alto nivel siempre que se lo auxilie con otras herramientas.

Herramientas textuales:
Diccionario de datos (DD)
Es una de las herramientas más importantes. Sin el diccionario de datos cualquier modelado está desde incompleto hasta mal.
Es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el
usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos
intermedios. El diccionario de datos define los datos de varias maneras:
 Describiendo el significado de los flujos y almacenes que se muestran en los DFD.
 Describe la composición de los agregados de paquetes de datos que se mueven a lo largo de los flujos, paquetes
completos que pueden descomponerse en unidades más elementales.
 Describe la composición de los paquetes de datos en los almacenes de datos.
 Especifica los valores y unidades relevantes de piezas elementales de información en los flujos de datos y en los
almacenes de datos.
 Describe los detalles de las relaciones entre almacenes que se enfatizan en un DER.

Existen varios esquemas de notación para un DD, uno de los más comunes es el siguiente:
= está compuesto de
+ y
() el contenido dentro de los paréntesis es opcional
{} el contenido dentro de las llaves es iterado, si se conoce el ´numero mínimo y/o máximo de repeticiones, se lo
antepone a las llaves de la forma m : M, o m { } M
[] se debe escoger una de varias alternativas contenidas dentro de los corchetes
| separa las alternativas dentro de los corchetes
** se incluyen comentarios dentro de los asteriscos
@ se usa como identificados de un campo clave

Para definir un dato, se lo coloca a izquierda del símbolo = para indicar a derecha la composición del dato, es decir: A = B + C
(A se compone de B y C). La definición completa de un dato incluye:
 El significado del dato dentro del contexto de la aplicación de este usuario. Generalmente, para profundizar la
aclaración se realizan comentarios entre **.
 La composición del dato, si se compone de partes elementales con significado.
 Los valores que puede tomar el dato, si es un dato elemental que no puede descomponerse más.
Las partes elementales de los datos son aquellas para las cuales ya no existe una descomposición con significado dentro del
contexto del ambiente del usuario. Al identificar datos elementales se los debe introducir al diccionario, con una breve narrativa
que describa el significado del término en el contexto del usuario. Puede haber términos que se definan solos, o donde el
analista crea que no hace falta aclarar más.
Un dato opcional es aquel que puede estar o no presente en un formato compuesto. Las situaciones de este tipo se deben
verificar con cuidado con el usuario y se deben documentar precisamente en el diccionario de datos.
La notación de iteración se usa para indicar la ocurrencia repetida de un componente de un dato. Se lee como “cero o más
ocurrencias de”. En muchas situaciones el usuario querrá especificar los límites inferior y superior de la iteración, lo cual se
puede indicar de varias formas, siendo las más comunes A = m : M { B } ó A = m { B } M.
 La notación de selección indica que un dato consiste en exactamente un elemento de entre un conjunto de opciones
alternativas. La notación es: A = [ B | C | D ]. Es importante revisar las opciones de selección con el cliente para asegurar que se
han abarcado todas las posibilidades.
Un alias es una alternativa de un nombre para un dato, y es una ocurrencia común cuando se trata con diversos grupos de
usuarios en diferentes departamentos o ubicaciones geográficas que usan distintos nombres para llamar a lo mismo. El alias se
incluye en el DD por cuestiones de completitud y se relaciona con el nombre oficial del dato del siguiente modo: A = * alias
de B *. Todos los detalles deben darse para el nombre primario del dato, para minimizar la redundancia en el modelo. Se debe
evitar el uso del alias hasta donde sea posible para ayudar a la lectura simple del documento.

Especificaciones de proceso
Es la descripción de que lo que sucede en cada burbuja primitiva de nivel más bajo en un DFD. El proceso se basa en definir lo
que debe hacerse para transformar entradas en salidas. Hay varias herramientas para producir una especificación de proceso.
La especificación del proceso debe expresarse de una manera que puedan verificar tanto el usuario como el analista. Se evita
el lenguaje narrativo debido a su naturaleza ambigua, y a que causa gran confusión cuando expresa condiciones booleanas.
El proceso debe especificarse en una forma que pueda ser comunicado efectivamente al público involucrado. En gran medida
esto depende de la personalidad, humor y otros factores de los usuarios con los que se trata.
La mayoría de los analistas usan el lenguaje estructurado como método para escribir las especificaciones de proceso. Esto no
siempre es lo mejor.
Una buena herramienta de especificación de proceso no debe imponer decisiones de diseño e implantación arbitrarias, lo cual
suele ser difícil, porque el usuario, suele escribirla en los términos en los que la lleva a cabo en la realidad.
Las especificaciones de proceso solo se desarrollan para los procesos de más bajo nivel en un conjunto de diagramas por
niveles en un DFD. Los procesos de mayor nivel se definen por medio de la red de procesos de nivel de inmediato inferior.
Hay tres herramientas principales de especificación de proceso:
Lenguaje estructurado. Es un subconjunto de todo idioma con importantes restricciones sobre el tipo de frases que pueden
usarse y la manera en que se pueden juntar dichas frases. Su propósito es hacer un balance razonable entre la precisión del
lenguaje formal de programación y la formalidad y legibilidad del lenguaje cotidiano.
Una frase de lenguaje estructurado puede consistir en una ecuación algebraica o una sencilla frase imperativa que esté
formada por un verbo y un objeto. Los verbos deben escogerse de entre un pequeño grupo de verbos orientados a la acción. En
muchas organizaciones se concluye e que entre 40 y 50 verbos bastan para describir cualquier política dentro de una
especificación de proceso.
Los objetos (el tema de las frases imperativas) deben consistir solo en datos definidos en el diccionario o en términos locales,
que son aquellos que se definen explícitamente en una especificación de proceso individual; solo son conocidos, relevantes y
con significado dentro de dicha especificación.
El lenguaje estructurado permite combinar frases en unas cuantas formas limitadas que se toman de las construcciones
acostumbradas de la programación estructurada:
 La construcción SI-ENTONCES-SINO se usa para describir frases alternativas que se deben realizar según el resultado
de la decisión binaria.
SI condición_1 ENTONCES
frase_1
SINO
frase_2
FIN SI
 La construcción SEGÚN-CASO se usa para describir frases alternativas que se efectuarán basándose en los resultados
de una decisión multivaluada.
SEGÚN variable HACER
CASO variable = valor_1 : frase_1
…
CASO variable = valor_n : frase_n
SINO
frase_i
FIN SEGÚN
  La construcción MIENTRAS se usa para describir una frase que deberá llevarse a cabo repetitivamente hasta que
alguna condición booleana se verifique.
MIENTRAS condición_1 HACER
frase_1
FIN MIENTRAS
Otra construcción posible para representar la iteración es la estructura REPETIR que se caracteriza por que la
repetición se realiza al menos una vez
REPETIR
frase_1
HASTA condición_1

Se pueden componer frases a partir de combinación de frases sencillas y las estructuras sencillas presentadas anteriormente,
siguiendo algunas reglas:
1. Una secuencia lineal de frases sencillas equivale a una frase sencilla.
2. Toda construcción se considera estructuralmente equivalente a una frase única sencilla, lo que permite anidarlas unas
dentro de otras.
Esto permite construir descripciones complejas de políticas de negocios que mantienen un control estricto sobre el
vocabulario, organización y estructura de la descripción. La complejidad en si puede ser una desventaja en cuanto a la legibilidad
del documento.

Pre/post condiciones. Son una manera conveniente de describir la función que debe realizar el proceso. Resulta ser un
enfoque útil cuando el usuario tiene tendencia a expresar la política llevada a cabo por la burbuja en términos de un algoritmo
particular que uso por mucho tiempo, o cuando el analista está seguro de que hay muchos algoritmos distintos que pueden
usarse y desea que el programador explore varios de ellos no quiere involucrarse personalmente con tales detalles ni tener
discusiones con el usuario sobre el merito relativo de cada uno.
Existen dos partes principales del proceso: precondiciones y postcondiciones. Las precondiciones describen todas las cosas que
deben darse antes de que el proceso pueda empezar a ejecutarse, es decir que describen que entradas están disponibles. Tales
entradas llegan mediante un flujo conectado con un proceso. No todos los flujos que entren a un proceso serán precondición
necesaria para que este se active. Las precondiciones también describen la relación entre las entradas, si es que más de una es
necesaria para que proceso comience. A su vez, también describe que relaciones deben existir entre entradas y almacenes de
datos, así como también las relaciones que debe haber entre almacenes o dentro de un mismo almacén.
Las postcondiciones describen lo que debe darse cuando el proceso ha concluido, es decir que describen las salidas que
generará el proceso, las relaciones que existirán entre los valores de salida y los valores originales de entrada, las relaciones
entre valores de salida y los valores en uno o más almacenes, y los cambios que hayan ocurrido en los almacenes.
Cuando se esté construyendo una especificación de pre/post condiciones se empieza por describir cada situación normal del
proceso, cada una de las cuales se expresa como precondición distinguible e individual. Para cada precondición se describe la
condición del proceso cuando se han producido las salidas y se han modificado los almacenes. Luego de describir las situaciones
normales del proceso, se incluyen las pre/post condiciones para los casos de error y los casos anormales.
Aunque este enfoque sea útil y tenga muchas ventajas, puede no ser apropiado debido a la falta de pasos intermedios entre
entradas y salidas, lo cual lo vuelve difícil de comprender para lectores que sean incapaces de visualizar los procesos de
transformación tácitamente.
PRECONDICION i
Ocurre el dato X
POSTCONDICION I
Se genera dato Y

Tablas de decisión. Si las decisiones se basan en diversas variables que pueden tomar distintos valores entonces es preferible
el uso de una tabla de decisiones. Ésta se crea listando todas las variables relevantes y todas las acciones relevantes en el lado
izquierdo. Suele ser preferible expresar las variables como binarias, pero no por eso no puede ocurrir que se deba realizar una
tabla de variables multivaluadas. Luego se listan en columnas separadas cada combinación posible de valores de las variables; a
cada columna se la suele llamar regla, la cual describe una acción o acciones que deben llevarse a cabo para una combinación
específica de valores de las variables. Se debe especificar al menos una acción por cada regla. Tales reglas se discuten con el
usuario para asegurarse de que se identificaron las acciones correctas para cada combinación de variables. Se debe calcular el
número de combinaciones de las condiciones. Si estas son binarias, entonces hay 2 N combinaciones de N variables. Se debe
identificar cada posible acción que se pide en la especificación. La tabla se crea listando todas las condiciones y acciones en el
lado izquierdo y numerando las combinaciones de las condiciones en la parte superior de la tabla. Se examina cada columna
para identificar las acciones apropiadas que se deben tomar. Finalmente, junto al usuario, identificar las omisiones, restricciones
y ambigüedades.
Se puede usar un árbol de decisión para acompañar y aclarar una tabla de decisión.

Balanceo de modelos
No todos los errores en el modelado ocurren por una mala interpretación de lo que el usuario quería, los errores más difíciles
suelen ocurrir entre modelos, es decir inconsistencia entre un modelo y otro. Cuando todas las herramientas de una
especificación estructural están verificadas entre si para comprobar su consistencia, se dice que está balanceada. Los errores
más comunes de balanceo involucran las definiciones faltantes.
Es importante enfocarse en la inconsistencia de modelos, ya que tarde o temprano todos los errores se detectan pero la
dificultad de corrección crece a medida que el proyecto avanza. Siempre es más económico corregir un error en la etapa de
análisis que en la de diseño.

Tipos de balanceo.
Balanceo de DFD y DD. Cada flujo y cada almacén que aparece en el DFD debe estar definido en el DD. Cada dato y
cada almacén definido en el DD debe aparecer en el DFD, de lo contrario se los considera fantasmas.
Balanceo de DFD y EP. Cada burbuja del DFD debe asociarse con un DFD de nivel inferior ó con una EP, pero no con
ambos. Si ambos existen se considera al modelo como redundante. Cada EP debe tener una burbuja de nivel inferior
asociada en el DFD. Las entradas y salidas deben coincidir. Para las burbujas de control en un DFD existe
correspondencia entre las burbujas y los diagramas de transición de estados asociados.
Balanceo de las EP con el DFD y el DD. Cada referencia de un dato en la especificación de proceso debe satisfacer una
de las siguientes reglas:
o Coincide con el nombre de un flujo de datos o un almacén conectado a la burbuja descrita por la
especificación de proceso.
o Es un término local, definido explícitamente en la especificación de proceso.
o Aparece como componente en una entrada del diccionario de datos para un flujo o almacén conectado con
la burbuja
Balanceo del DD con el DFD y las EP. El diccionario es consistente con el resto del modelo si cada entrada del
diccionario de datos debe tener referencia en una especificación de proceso, un DFD u otro DD. Esto supone que se
modela el comportamiento esencial de un sistema. Un DD complejo y exhaustivo de una implantación existente de un
sistema puede contener algunos datos que ya no se usan. Puede argumentarse que el DD se planea de forma que
permita una expansión futura, y que por eso contiene elementos que no se ocupan en este momento pero que pueden
ser útiles en el futuro.
Balanceo del DER con el DFD y las EP. Cada almacén del DFD debe corresponder con un tipo de objeto, una relación o
un tipo asociativo de objeto en el DER. Los nombres de objetos en el DER y los nombres de almacenes de datos en el
DFD deben coincidir. Las entradas del diccionario de datos deben aplicarse tanto al DFD como al DER. Hay reglas que
aseguran que el DER sea consistente con la porción de la especificación de proceso del modelo orientado a las
funciones. Tales reglas son que el conjunto combinado de todas las especificaciones de proceso deben, en su totalidad:
o Crear y eliminar instancias de cada tipo de objeto y relación que se muestra en el DER.
o Alguna burbuja del DFD define valores para cada dato asignado a cada instancia de cada tipo de objeto, y
algún proceso de DFD usa valores de cada dato.

Balanceo del DFD y el DTE. Cada burbuja de control del DFD se asocia con un DTE como su EP. Cada DTE en el modelo
global del sistema debe asociarse con un proceso de control en el DFD. Cada condición del DTE debe corresponder con
un flujo de datos de entrada al proceso de control asociado con el DTE. Cada flujo de control que entra en la burbuja de
control debe asociarse con una condición apropiada en el diagrama de transición de estados correspondiente. Cada
acción en el DTE debe corresponder con un flujo de control de salida del proceso de control asociado con dicho
diagrama. Cada flujo de control de salida de la burbuja de control debe asociarse con una acción apropiada en el DTE
correspondiente.

Es importante que las reglas de balanceo puedan automatizarse, existen usualmente herramientas que efectúan partes o toda
revisión de errores.
El enfoque del modelo clásico
Se compone de cuatro modelos de sistemas:

Modelo Modelo Modelo

Modelo
lógico lógico físico
físico actual
actual nuevo nuevo

Modelo esencial Modelo de implantación

 Modelo físico actual. Es un modelo del sistema que actualmente está empleando el usuario.
 Modelo lógico actual. Es el modelo de los requerimientos esenciales que necesita el sistema actual del usuario.
Muestra lo que el sistema haría con tecnología ideal.
 Modelo lógico nuevo. Es el modelo de los requerimientos esenciales del sistema que el usuario quiere que se
desarrolle. Puede ocurrir que idealmente sea igual al sistema lógico actual, ya que el usuario solo está disconforme con la
implantación del sistema actual. Lo común es que el usuario desee nuevas funcionalidades.
 Modelo físico nuevo. Modelo que muestra las limitaciones de implantación impuestas por el usuario.

El enfoque clásico se basa en tres suposiciones principales:

1. El analista puede no estar familiarizado con el área de aplicación o del negocio, por eso es importante que comience
con el modelo físico actual. Luego de recopilar la información, puede transformar el modelo físico en el modelo
lógico.
2. El usuario puede estar imposibilitado para trabajar con el nuevo modelo lógico al principio del proyecto. La razón más
común es que desconfía de la capacidad del analista de desarrollar un modelo lógico del nuevo sistema.
3. La transformación del modelo lógico actual al modelo lógico nuevo no requiere de mucho trabajo, y en particular no
requiere de mucho trabajo desperdiciado, ya que solo requiere que el usuario añada o no nuevas funciones a las
existentes.

Tales suposiciones ignoran algo muy importante: el proceso de desarrollar un modelo del sistema actual puede requerir
mucho tiempo y esfuerzo pudiendo hacer que el usuario se frustre e impaciente, cancelando el proyecto. Esto es debido a que
muchos usuarios y administradores consideran al análisis de sistemas como una pérdida de tiempo, y que el usuario duda de los
beneficios del modelado cuidadoso de un sistema.
El problema ocurre con mayor frecuencia porque el analista se distrae con el modelado del sistema actual, perdiendo tiempo,
llegando a poder desecharse un 75% del modelo físico en la transición hacia el modelo lógico actual debido a la redundancia y a
la verificación, validación y revisión de errores apropiada en el sistema físico actual pero no en el lógico actual. Los analistas se
involucran tanto en el modelado que olvidan que el objetivo del usuario es producir un nuevo sistema.
Yourdon recomienda que el analista evite el modelado del sistema actual de ser posible, y que se usen las herramientas de
modelado para comenzar tan pronto como sea posible a desarrollar el modelo del nuevo sistema que el usuario desea. A este
modelo se lo conoce como modelo esencial.

El enfoque moderno propone no modelar el sistema actual, aplicando un diseño de tipo top-down (de lo general a lo
específico) y no tiene etapas definidas. Ni siquiera está definido un punto de partida, ya que depende de la situación. Lo único
importante es disponer de los recursos para desarrollar el sistema.

El modelo esencial
Es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos de usuario, diciendo lo mínimo posible acerca
de cómo se implantará; es decir que el modelo supone que se posee una tecnología ideal.
Al hablar con el usuario, el analista debe evitar describir implantaciones específicas de procesos en el sistema. Lo mismo
ocurre con los flujos y almacenes de datos. El modelo esencial debe describir su contenido sin describir el medio u organización
física de los datos.
Resulta difícil eliminar todos los detalles de la implantación en el modelo. Se deben evitar:
 Las secuencias arbitrarias de las actividades en un DFD. El único secuenciado debe ser el que requieren los datos o
acontecimientos externos al sistema.
 Los archivos innecesarios (almacenes innecesarios si se posee una tecnología perfecta).
 La revisión de errores y validación innecesaria de datos y procesos dentro del sistema.
 Los datos redundantes o derivados (los que se pueden calcular u obtener a partir de otros).
 Componentes del modelo esencial.

Declaración de
propósito

Modelo ambiental Diagrama de

contexto

Lista de
acontecimientos
Modelo esencial

Modelo preliminar
Modelo de
comportamiento
Modelo terminal

El modelo ambiental define la frontera del sistema y el ambiente. Consiste en un diagrama de contexto, una lista de
acontecimientos y una declaración de propósito.
El modelo de comportamiento describe el comportamiento que se requiere del sistema para que interactúe de modo exitoso
con el ambiente. Consiste en los DFD, DER, DTE, EP y el DD.
Puede que sea necesario construir un modelo de implantación antes del modelo esencial, porque el usuario no esta
convencido de que se entendió su labor en el negocio lo suficientemente bien como para comenzar a modelar el sistema nuevo,
o porque el analista precisa estudiar el ambiente actual antes de realizar el sistema. Hay que recordar que el objetivo primario
es llegar a un entendimiento y a la visión general del sistema existente, no de documentar detalladamente el sistema actual.

Modelo ambiental
Define las interfaces entre el sistema y el ambiente, es decir que modela el exterior del sistema.
Es importante definir que información entra al sistema y cual se produce como salida. Los sistemas que se construyen son
racionales su propósito es producir una salida en respuesta a un acontecimiento que ocurre en el ambiente del sistema, por lo
que otro aspecto crítico del modelo ambiental consiste en identificar los acontecimientos que ocurren en el ambiente.
Generalmente el usuario tiene una idea de la frontera entre el sistema y el ambiente, pero existe un área gris, de la cual el
usuario no estará seguro o no la había considerado.

El ambiente

El sistema

Es importante escoger una perspectiva adecuada o el proyecto estará condenado a fracasar, ya que si se escoge una
demasiado pequeña, el usuario puede haber identificado sin darse cuenta el síntoma del problema en lugar de la causa, y si
escoge una perspectiva demasiado amplia se tratará con una situación política mucho más compleja, intentando desarrollar un
sistema demasiado grande.
Es importante dedicar el tiempo y tener la suficiente participación del usuario en la declaración de una frontera. En un sistema
grande se pueden tomar en cuenta varios factores para escoger la perspectiva del proyecto. Los más importantes suelen ser: El
deseo del usuario de lograr una cierta participación en el mercado para el producto o incrementarla a más de su nivel actual; la
legislación establecida por alguna agencia gubernamental; deseo del usuario de minimizar gastos operativos de algún área de su
negocio; deseo del usuario por lograr alguna ventaja estratégica para la línea de productos o área de negocios que opera.
El área dentro de la frontera del sistema a veces se conoce como el dominio de cambios, ya que todo lo que se encuentra
dentro del sistema está sujeto a cambios, mientras que lo externo no es de mucha incumbencia para el analista.
Herramientas usadas para definir el ambiente.
La declaración de propósitos. Declaración textual breve y concisa del propósito del sistema, dirigida al nivel administrativo
superior, la administración de los usuarios y otros que no están directamente involucrados con el desarrollo del sistema. Puede
constar de una o varias frases pero no debe superar el párrafo. La declaración debe ser deliberadamente vaga en cuanto a
detalles.
Aunque el documento de declaración de propósitos no responde las preguntas detalladas sobre el comportamiento,
generalmente basta con responder a una serie de preguntas de alto nivel. Algunos analistas consideran que el documento
también debe resumir los beneficios tangibles y cuantificables que se logren con el nuevo sistema, lo cual es fácil para proyectos
pequeños y no tanto para proyectos grandes, en su lugar se suele requerir un análisis de costo-beneficio.

El diagrama de contexto. Es un caso especial de DFD, en donde una sola burbuja representa todo el sistema enfatizando varias
características importantes del sistema:
 Las personas, organizaciones y sistemas con los que se comunica el sistema (terminadores).
 Los datos que el sistema recibe del mundo exterior y debe ser procesado de alguna manera.
 Los datos que el sistema produce y que se envían al mundo exterior.
 Los almacenes de datos que el sistema comparte con los terminadores (almacenes externos).
 La frontera entre el sistema y el resto del mundo.

La lista de acontecimientos. Es una lista narrativa de los estímulos que ocurren en el mundo exterior a los que el sistema debe
responder. Cada acontecimiento se etiqueta como F, T o C; para indicar si se lo asocia con un flujo de datos (F), es decir que el
sistema se da cuenta de que el acontecimiento ocurrió cuando llegan uno o varios datos ; para indicar si se asocian con
acontecimientos temporales (T), es decir que los acontecimientos arrancan con la llegada de un momento dado en el tiempo; o
para indicar si se los asocia con un acontecimiento de control (C), que son un caso especial del acontecimiento temporal: un
estimulo externo que ocurre en algún momento impredecible.

Para la mayoría de los proyectos estos componentes bastan, pero dependiendo de la complejidad y la naturaleza del sistema,
pueden ser útiles dos componentes adicionales: el diccionario de datos inicial, que define todos los flujos y almacenes externos;
y el modelo de entidad-relación de los almacenes externos. Aún cuando los flujos de datos se definen en el modelo de
comportamiento, puede ser importante comenzar antes la construcción del DD si, por ejemplo, las interfaces entre el sistema y
los diversos terminadores están sujetas a cambios y a negociación, por lo que cuanto antes se comiencen a definir formalmente
las interfaces más rápido se finalizarán. Del mismo modo se puede hacer un DER de los almacenes externos (si los hay), lo que
puede ayudar a dejar al descubierto las relaciones entre almacenes, que de otro modo no serían evidentes hasta que se
desarrollara el modelo de comportamiento. Esto permite revisar las interacciones entre los terminadores y el sistema mismo.

Construcción del modelo ambiental

Su construcción requiere una gran cantidad de tiempo y energía, especialmente porque suele ser la única parte del modelo
global del sistema que es vista por usuarios y administradores de alto nivel. Generalmente se desarrolla como una serie de
refinamientos iterativo, con datos adicionales que se añaden y refinan, lo cual es importante ya que una sola persona no puede
comprender la perspectiva completa del sistema.

Construcción del diagrama de contexto. La parte del DC es el proceso, el cual es una única burbuja con el nombre del sistema
completo (o un acrónimo convenido). Los terminadores se comunican con el sistema a través de flujos de datos o de control, o a
través de almacenes externos. Las comunicaciones entre terminadores son irrelevantes para el sistema. Cuando se tienen
terminadores con muchos flujos se pueden dibujar duplicados de esos terminadores (indicados con un * al lado de su nombre), a
los cuales se les asignarán algunos flujos como para no sobrecargar un solo terminador. Si el terminador es una sola persona,
conviene más indicar su rol que su nombre ya que esta persona puede realizar varios trabajos distintos. Los terminadores deben
indicar la fuente de datos y no el medio que los genera. Se deben tener en cuenta todas las consideraciones que se hacen al
construir un DFD.

Construcción de la lista de acontecimientos. El analista debe asegurarse de distinguir los acontecimientos de los flujos
relacionados a un acontecimiento. Se debe tratar de describir los acontecimientos desde el punto de vista del ambiente (de
afuera hacia adentro) y no desde el punto de vista del sistema, ya que se pueden identificar erróneamente flujos entrantes que
no son acontecimientos.
La manera más fácil identificar los acontecimientos relevantes para un sistema es visualizándolo en acción, es decir, examinar
cada terminador y preguntar que efecto pueden tener sus acciones en el sistema.
La lista de acontecimientos no solo debe contener las interacciones normales entre el sistema, y los terminadores, sino que
también debe incluir situaciones de falla causada por terminadores.

No es relevante si se realiza primero la lista de acontecimientos o si se empieza con el DC, siempre que al final se produzcan
ambos componentes y estén revisados de modo que sean consistentes.
Al finalizar con ambos componentes, el analista debe cerciorarse de que:
  El sistema necesita cada flujo de entrada del DC para reconocer que ocurrió un acontecimiento, para producir una
respuesta a un acontecimiento, o ambas cosas.
 Cada flujo de salida debe ser respuesta a un acontecimiento.
 Cada acontecimiento no temporal debe tener entradas a partir de las cuales el sistema pueda detectarlo.
 Cada acontecimiento debe producir salidas inmediatas como respuesta o bien almacenar los datos que luego serán
salidas, o deberá ocasionar un cambio en el estado del sistema.

El modelo de comportamiento
Diferencias con el enfoque clásico. El enfoque clásico supone que el diagrama de contexto ya está dibujado y que se
procederá directamente de la burbuja única del DC a un DFD de nivel superior (Figura 0), donde cada burbuja representa un
subsistema principal. Cada burbuja de la figura de nivel 0 se divide en burbujas de nivel inferior, las cuales se puede dividir más,
hasta alcanzar burbujas atómicas indivisibles.
Aunque ese enfoque es útil presenta los siguientes inconvenientes:
 Parálisis del análisis. En sistemas grandes y complejos, simplemente no existe una guía para que el analista dibuje la
figura 0 apropiada a partir del DC.
 El fenómeno de los seis analistas. En un sistema grande y complejo suele haber más de un analista viendo el DC, y
resulta difícil dividir las tareas equitativamente sin estorbarse entre sí, llevando a que arbitrariamente cada uno cree
una figura 0.
 Una partición física arbitraria. Un sistema nuevo se basa en uno existente o representa la computarización de una
organización existente. La partición del sistema actual debe usarse como parámetro para la partición del nuevo
sistema, aún cuando esta no sea la manera más eficaz de partir al sistema.

El enfoque que Yourdon describe no es puramente descendente, ni ascendente; sino intermedio, ya que después de
desarrollar el modelo ambiental, requiere nivelación ascendente y luego podría requerir una descendente.

Modelo Esencial

Modelo de Comportamiento
Modelo
Ambiental
Nivelación Figura de nivel Nivelación
Particionados
ascendente 0 descendente

Identificación de respuestas a acontecimientos. El enfoque de partición por acontecimientos incluye los siguientes cuatro
pasos:
1. Se dibuja una burbuja o proceso para cada acontecimiento de la lista.
2. La burbuja se nombra describiendo la respuesta que el sistema debe dar al acontecimiento asociado.
3. Se dibujan las entradas y salidas apropiadas de modo que cada burbuja pueda dar la respuesta requerida, y se dibujan
los almacenes para la comunicación entre burbujas.
4. El borrador de DFD resultante se compara con el DC y la lista de acontecimientos para asegura su consistencia y
completitud.

Conexión de las respuestas a acontecimientos. Las burbujas se comunican entre sí a través de otros almacenes de datos
debido a que las burbujas del DFD preliminar representan respuestas a un acontecimiento, y aquellos que ocurren en el
ambiente externo no están sincronizados. Y, dado que las respuestas a un acontecimiento pueden requerir datos producidos por
otro, y que no hay manera de saber cuando ocurrirán; además, se supone en el modelo esencial que cada proceso realiza su
tarea instantáneamente y cada flujo de datos los transmite instantáneamente; la única forma de sincronizar múltiples
acontecimientos interdependientes es mediante un almacén.

Desarrollo del modelo inicial de datos. Mientras que se realiza el DFD preliminar, alguien debería haber comenzado a
construir la versión inicial del DER independientemente y en paralelo al desarrollo del DFD inicial. Al realizarlos paralelamente,
se pueden usar para revisarse entre sí. Los almacenes definidos en el DFD puede servir para sugerir objetos en el DER; y esos
objetos se pueden usar para elegir almacenes apropiados en el DFD. Ninguno predomina sobre el otro, cada uno provee de
asistencia invaluable al otro.
 La lista de acontecimientos puede ser similarmente útil para crear el DER inicial. Los sustantivos de la lista serán objetos del
DER. Similarmente, se puede usar una lista de acontecimientos para verificar el DER inicial, todos los tipos de objetos del DER se
deben corresponder con los sustantivos de la lista.

Terminado del modelo del proceso.

Nivelación del DFD. Ascendente: Consiste en agrupar procesos relacionados en una burbuja con significado, cada uno de los
cuales representa una burbuja de nivel superior. Hay tres reglas a tener en mente para realizar esto:
1. Se deben agrupan burbujas con funciones y entradas/salidas similares.
2. Buscar la oportunidad de esconder almacenes, cuando existan procesos que usen un almacén en común y ningún otro
proceso lo use.
3. Repetir el proceso gasta lograr 7 ± 2 procesos, que se convertirán en la figura de nivel 0.

La agrupación de datos en torno a datos comunes y la búsqueda de oportunidades para esconder almacenes locales son los
parámetros principales para la nivelación ascendente, y no alguna regla aritmética.

Descendente: Este paso solo es necesario si las burbujas de la figura de nivel 0 no son elementales y es necesario explotar las
burbujas a un nivel inferior. Las reglas a tener en cuenta son:
 Si una burbuja de proceso realiza una función compleja trate de identificar sus funciones, cada una de las cuales puede
ser echa por una burbuja de nivel inferior.
 Los flujos de datos de entrada y salida proporcionan una guía para la nivelación descendente.

p
X
X p
Y q
Y q

Z r
r
Z

Al realizar esta actividad de nivelación ascendente y descendente se debe tener en cuenta que el balanceo es importante, es
decir, se debe asegurar que las entradas y salidas de la burbuja de alto nivel sean consistntes con las del diagrama de nivel
inferior.
 Completado del DD. Se debe continuar completando el diccionario de datos que inicialmente se empezó en el modelo
preliminar. Al realizar esto se debe verificar que este completo y sea consistente, que ninguna parte contradiga a otra, que este
balanceado con los DFD, con el DER y las EP

Completado de las EP. No es aconsejable realizar EP al desarrollar los particionados, ya que el mismo esta sujeto a muchos
cambios, correcciones y revisiones, lo ideal es empezar a hacerlo cuando el DFD empieza a estabilizarse, luego de haber pasado
la nivelación ascendente y no se hayan descubierto fallas importantes en el modelo. Esto a menudo es un esfuerzo largo que
consume mucho tiempo, ya que cada burbuja elemental debe especificarse, teniendo en cuanta que están balanceadas con
todos los demás.

Terminado de los modelos de datos. Como dijimos el DER se desarrolla al mismo tiempo que es DFD por lo que se debe ir
refinando y mejorando a lo lardo del modelado. Los conocimientos que se obtienen del DFD deben usarse para refinar y mejorar
el DER. Por ultimo se debe tener en cuanta las reglas de normalización del DER.
Terminado del DTE. Si un sistema tiene características de tiempo real estará desarrollando un DTE, el conocimiento detallado
del comportamiento del sistema ayudara a refinar el DTE siguiendo las reglas apropiadas para su construcción

Una vez concluido todos estos pasos se llaga al final del modelo esencial, el cual debe tener un modelo completo, detallado,
formal y riguroso de todo lo que el sistema tiene que hacer para lograr los requisitos del usuario.

El ciclo de vida del proyecto

El ciclo de vida del proyecto clásico. El tipo de ciclo de vida de proyecto usado en la mayoría de las organizaciones difiere del
descripto por Yourdon, aunque todos difieren levemente entre sí, en una o varias de las siguientes formas:
 Las fases de exploración y análisis pueden juntarse en una sola.
 No habrá estudio de hardware si un sistema puede instalarse en las computadoras existentes.
 Las fases de diseño preliminar y de diseño de detalles pueden juntarse en una fase de diseño.
 Diversas fases de prueba pueden juntarse en una sola, hasta incluirse en la codificación.
Lo que caracteriza el ciclo de vida del proyecto clásico, son dos aspectos: una fuerte tendencia a la implantación ascendente
del sistema y la progresión secuencial de una fase a la siguiente.

Implantación ascendente. Es una de las grandes debilidades del CVP clásico. Se espera que los programadores lleven a cabo
primero las pruebas modulares, luego las pruebas del subsistema y finalmente las pruebas del sistema mismo. Esto se conoce
como ciclo de vida de cascada.
La implantación ascendente presenta muchas dificultades para organización es que producen sistemas únicos:
 No se hace nada hasta que todo esté terminado.
 Las fallas más triviales se encuentran al comienzo del periodo de prueba y las más graves al final. Esto es malo para,
debido a que detectar grandes fallas al final e intentar eliminarlas puede llevar a modificaciones muy grandes que
llevarían a rehacer el proyecto.
 La necesidad de prueba con la computadora aumenta exponencialmente en las últimas etapas de prueba, lo cual
retrasa mucho el proyecto.

Progresión secuencial. Querer que las fases sucedan secuencialmente es una tendencia natural humana, es decir que se
espera que al terminar una fase del sistema nunca más se tendrá que preocupar por ella. Esto se conoce como congelar la
especificación o congelar el documento de diseño. El único problema que trae esto que no es nada realista. Particularmente, no
permite el tratamiento de fenómenos como los relacionados con el personal, la política de la organización, o la economía.
Comúnmente surgen otros problemas asociados: durante el tiempo que toma desarrollar el sistema el usuario puede cambiar
de parecer al respecto a aspectos del sistema, o pueden cambiar aspectos del ambiente que interactúa con el sistema. Un
problema adicional, es que el CVP clásico se apoya en técnicas antiguas, aunque esto no significa que no se puedan usar técnicas
modernas.

El ciclo de vida semiestructurado. La tendencia a usar el diseño y programación estructurada y la implantación descendente
crece, lo cual ha llevado al CVP semiestructurado, que presenta dos detalles que no están en el enfoque clásico:
 La secuencia ascendente de codificación, la prueba de módulos y prueba de sistema se reemplazan por una
implantación top-down, en el que los módulos de alto nivel se codifican y prueban primero, luego se prueban los de
menor nivel. También hay fuertes indicios de que la programación estructurada debe usarse para codificar el sistema.
 El diseño clásico se reemplaza por uno estructurado, que es un enfoque de diseño formal de sistemas.
La implantación descendente implica el tener que realizar partes de la codificación y las pruebas en paralelo, lo cual genera
retroalimentación entre la codificación, las pruebas, y la eliminación de fallas. Además, tienta a los miembros del proyecto a no
hablar con los usuarios hasta después de haberse congelado las especificaciones, por lo que el usuario puede señalar errores o
malentendidos en la especificación, o incluso deseo de cambiarla.
 El ciclo de vida estructurado del proyecto.

USUARIOS ADMINISTRACION OPERACIONES

Bases de datos
Requerimientos Política del existentes
Restricciones Restricciones
del sistema usuario
operacionales

8.
Especificación CONVERSION
Documento estructurada
1. 2. 3. DE BASES DE
ENCUESTA ANALISIS DISEÑO DATOS
Especificación
Reporte del de diseño
Informe
costo-beneficio
tentativo de Especificación Bases de
costo-beneficio Restricciones estructurada datos
7.
4. convertida
DESCRIPCION
DE PROCE- IMPLANTACION
ADMINISTRACION DIMIENTOS
5.
Sistema
GENERACION
Sistema instalado
DE PRUEBA
Manual del integrado
DE usuario
ACEPTACION

6.
Conjunto de 9.
Pruebas de CONTROL
INSTALACION
control de DE
CALIDAD
calidad

Los terminadores del CVP estructurado son individuos o grupos que proporcionan las entradas al equipo del proyecto y son los
beneficiados finales del sistema. Ellos interactúan con las nueve actividades que se listan a continuación:

1. La encuesta. Estudio de factibilidad o inicial de negocios. Empieza cuando el usuario solicita que una o más partes de su
sistema se automaticen. Los principales objetivos de la encuesta son los siguientes:
 Identificar a los usuarios responsables y crear un campo de actividad inicial del sistema, lo cual comprende una
serie de actividades de recolección de.
 Identificar las deficiencias actuales en el ambiente del usuario.
 Establecer metas y objetivos para el sistema nuevo.
 Determinar si es factible automatizar el sistema y de ser así sugerir escenarios aceptables, lo que implica
estimaciones del costo y tiempo necesarios y de los beneficios.
 Preparar el esquema que se usará para guiar el resto del proyecto e identificar al administrador responsable del
proyecto.

Generalmente esta etapa ocupa en 5-10% del tiempo y de los recursos de todo el proyecto. Para proyectos pequeños esta
etapa es casi imperceptible, pero en proyectos grandes y complejos esta etapa es crítica y debe realizarse con mucho
detalle.

2. El análisis de sistemas. El propósito principal de esta actividad 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 DFDs, DERs, DTEs y otras herramientas de modelado.
Esta etapa también implica el desarrollo del modelo esencial, y la descripción de los requerimientos del usuario mediante
la preparación de un conjunto de presupuestos y cálculos de costos y beneficios más precisos y detallados al final de la
actividad.

3. El diseño. Esta actividad se dedica a asignar porciones de la especificación a procesadores adecuados y a labores
apropiadas dentro de cada procesador. 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 e interfaces entre ellos para implantar la especificación creada durante el
análisis. Además se ocupa de la transformación de modelos de datos de entidad-relación en un diseño de base de datos.
El analista estará interesado durante esta etapa en el desarrollo del modelo de implantación del usuario, que describe los
asuntos relacionados con la implantación que le importa al usuario al grado que no se los quiera confiar al diseñador o al
programador. Estos son los asuntos relacionados con la especificación de la frontera humano-máquina y su interfaz. Tal
frontera separa las partes del modelo esencial que llevara a cabo una persona, de las partes que se implantarán en una o
más computadoras. Similarmente, la interfaz hombre-maquina es una descripción del formato y de la secuencia de
entradas que los usuarios proporcionan a la computadora, además del formato y la secuencia de salidas que la
computadora proporción al usuario.
4. La implantación. Esta actividad incluye la codificación y la integración de módulos en un esqueleto progresivamente mas
completo del sistema final, por lo que incluye tanto la programación estructurada como implantación descendente.
El analista típicamente no se verá involucrado en esta actividad, salvo que todo el trabajo lo haga una sola persona.

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 para el usuario. Una vez generada la especificación, comienza la producción de un
conjunto de casos de prueba de aceptación desde la especificación estructurada.
Esto puede suceder simultáneamente a las actividades de diseño e implantación, por lo que el analista puede ser asignado
a esta labor.

6. Garantía de calidad. Prueba final o de aceptación. Requiere como entradas los datos de la actividad 5 y el sistema
integrado producido en la actividad 4. Generalmente el analista no esta involucrado en esta actividad.

7. Descripción del procedimiento. 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 interactuarán los usuarios
con la parte automatizada del nuevo sistema. El resultado de esta actividad es un manual para el usuario.
Esta es una actividad en la que el analista puede participar.

8. Conversión de bases de datos. Esta actividad requiere como entrada la base de datos actual del usuario, al igual que la
especificación del diseño producida por la actividad 3.
Según la naturaleza del proyecto, el analista podría tener que ver con esta actividad.

9. Instalación. Esta es la actividad final. Sus entradas son el manual de la actividad 7, la base de datos de la actividad 8 y el
sistema aceptado por la actividad 6. Este puede ser un proceso gradual o instantáneo, todo depende del analista y del
usuario.
Concepto de Orientación a objetos
La programación orientada a objetos (OOP) es un paradigma cuyo mayor beneficio es la reutilización de código. Se basa en:
Objeto: Un objeto es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos
datos. Puede estar compuesto por otros objetos, lo cual permite definir objetos muy complejos.

Tipo de objeto: Un tipo de objeto es una categoría de objeto. Un objeto es una instancia de un tipo de objeto. El mundo
orientado a objetos define tipos de objetos e instancias de ellos. Un objeto se refiere a los datos y los métodos mediante los
cuales se controlan. La estructura de datos y los métodos de cada tipo de objeto se manejan juntos. No se puede acceder o
controlar la estructura sino es mediante un método que forme parte del tipo de objeto.

Métodos: Especifican la forma en que se controlan los datos de un objeto. Los métodos de un tipo de objeto solo hacen
referencia a las estructuras de datos de ese tipo de objeto. Para acceder a las estructuras de datos de otro tipo de objeto deben
de enviarle un mensaje. Un objeto tiene sus atributos representados por tipos de datos y su comportamiento definido por
métodos. Una característica particular de los métodos es el polimorfismo, el cual permite que dentro de una clase existan
métodos con el mismo nombre, cuya única diferencia está en el contexto de su aplicación.

Encapsulado: El empaque conjunto de datos y métodos se llama encapsulado, y es el resultado de ocultar los detalles de
implantación de un objeto respecto de su usuario. El objeto esconde sus datos de los demás y permite el acceso a ellos
mediante sus métodos. A esto se lo conoce como ocultamiento de la información. El encapsulamiento evita la corrupción de los
datos de un objeto. A su vez, oculta los detalles del desarrollo de las actividades a los usuarios, quienes pueden notar que las
operaciones se llevan a cabo, pero tienen modo de saber como.
El encapsulado es importante porque separa el comportamiento de un objeto de su implantación, lo que permite modificarla
sin modificar las aplicaciones que lo utilizan, permitiendo aislar el área de efecto de un cambio.

Mensajes: Para que un objeto haga algo se le envía una solicitud. Una solicitud invoca una operación específica, con uno o más
objetos como parámetros. Esto hace que se produzca una operación, que ejecuta el método apropiado y, de manera opcional,
produce una respuesta. El mensaje que constituye la solicitud contiene el nombre del objeto, el nombre de un método y a veces
un grupo de parámetros. Un mensaje es una solicitud para que se lleve a cabo la operación indicada y se produzca el resultado.

CLASE Clases: Se refiere a la implantación en software de un tipo de objeto. Especifica una estructura de
datos y los métodos operativos posibles que se aplican a cada uno de sus objetos. El tipo de objeto es
·Atributo_1
·Atributo_2
una noción de concepto, que especifica una familia de objetos sin estipular la forma en que se
·Atributo_n implanten. La implantación de clases especifica la estructura de datos para cada uno de sus objetos.
Los métodos y los atributos se almacenan una sola vez en una clase y todos los objetos instanciados a
+Método_1 partir de ella los comparten. Llamamos bibliotecas de clases a los depósitos de las clases existentes
+Método_2
que un analista o diseñador podría usar.
+Método_3

Herencia: Una subclase hereda de una clase de mayor jerarquía, llamándose clase hija de esta última, y a ésta se conoce por
superclase. Cuando una clase hereda, obtiene las propiedades de la clase padre, es decir que puede heredar la estructura de
datos y los métodos, aunque también puede tener sus propios métodos e incluso tipos de datos. Cuando una clase hereda
propiedades de más de una superclase tenemos un caso de herencia múltiple. También puede ocurrir u caso de anulación, en el
cual los métodos heredados son modificados según las necesidades de la clase que los hereda. No todas las clases se ven
obligadas a heredar. Una clase puede surgir de la nada.

Análisis de la estructura de objetos (AEO)

El AEO define categorías de los objetos que se perciben y las formas en que se los asocian.
Objetos y tipos de objetos. Durante el análisis de la estructura de objetos el equipo de análisis se preocupa más por identificar
los tipos de objetos que por identificar los objetos individuales en un sistema. Los tipos de objetos son importantes para el
diseño de sistemas, ya que crean los bloques conceptuales de construcción para el diseño de sistemas. En la OOP, tales bloques
guían al diseñador en la definición de las clases y sus estructuras de datos. Además, los tipos de objetos son un índice para los
procesos del sistema, es decir que un objeto solo debe ser controlado mediante las funciones asociadas con su tipo, de modo
que las operaciones no se pueden definir de manera apropiada sin los tipos de objetos.
Los tipos de objetos que se definen y utilizan son variados, ya que se eligen basándose en la comprensión del mundo, es decir
que las categorías las elige cada persona arbitrariamente según sus percepciones del entorno. Un objeto, por lo tanto, se puede
llegar a categorizar de varias maneras.
 Asociaciones de objetos. Los tipos de objetos que clasifican los objetos de nuestro entorno son vitales en el análisis OO.
También es importante modelar la manera en que los objetos se relacionan entre sí, como se ve en las figuras.

1 B
A
2

D
3 C
Representa
tipos de objetos

Número Letra

Representa
una asociación

Aunque la figura ilustra las asociaciones entre ambos tipos de objetos, no muestra el significado de tal asociación, ni la
cantidad de objetos con los que un objeto dado puede y debe asociarse. En el análisis es útil nombrar de alguna manera a las
asociaciones e indicar la cantidad de objetos de un tipo dado que se deben asociar con los objetos de otro tipo, ya que esto le
da significado y comprensión a la asociación.
Un pedido es ordenado por
Cliente un solo cliente
Un cliente ordena desde
Producto
cero hasta n pedidos
Ordena Un pedido contiene desde uno
Pedidos hasta varios artículos de línea
Ordenado por

Contiene Elementos
del renglón

Jerarquías de generalización. Una de las manera más comunes de organizar la información es jerarquizándola de los más
general a lo más específico. Para el caso del AEO, la jerarquía establece que de un supertipo parten subtipos, que a la vez pueden
ser supertipos de subtipos de menor jerarquía. Todas las propiedades de un tipo de objeto también se aplican a sus subtipos.
La generalización es el acto de distinguir un tipo de objeto como más general, o incluso, que es más que otro. Todo lo que se
aplique a un tipo de objeto también se aplica a sus subtipos. Cada instancia de un tipo de objeto es también una instancia de sus
supertipos.
Puede ocurrir que un tipo tenga más de un supertipo y por lo tanto no todas las jerarquías serán de árbol. Las jerarquías de
generalización son importantes para el desarrollador OO por dos razones: primero, el uso de supertipos y subtipos proporciona
una herramienta útil para describir el mundo del sistema de aplicación; segundo, indica las direcciones de herencia entre las
clases en los lenguajes de OOP.
 Jerarquías compuestas. Algunos tipos de objetos se pueden considerar como complejos, es decir que están formados por
otros. En el análisis OO, la composición de un objeto nos ayuda a describir el hecho de que todo está compuesto por partes más
pequeñas y la división depende del analista.
Una forma de representar el aspecto compuesto de los objetos es mediante sus diagramas, como se ve en la figura.

Unidad de línea
de iluminación

Símbolo de
composición

Pantalla de
Fuente lámpara

Porta-
lámparas Lámpara

Diagramas de relación entre los objetos. Los tipos de objetos se relacionan con otros tipos de objetos. Los DER se son muy
usados en el análisis convencional de sistemas, y muestran la relación entre los tipos de entes. Un diagrama de relación entre
objetos es muy similar al DER. En la figura se puede suponer que cada cuadro es un tipo de objeto en el AEO.

Cliente Pedidos

Línea de
pedidos

Esquemas de objetos. La comprensión de un modelo suele ser más sencilla si los tipos de objetos y las relaciones se
representan mediante un diagrama de relación de objetos; los supertipos y subtipos se representan en un diagrama de jerarquía
de generalización y las estructuras compuestas en un diagrama compuesto. Para usuarios mas sofisticados lo más conveniente
sería presentarlo todo en un mismo diagrama, al cual se conoce como esquema de objetos.

Análisis del comportamiento de objetos (ACO)

En el ACO se realizan esquemas de eventos que los muestran en la secuencia que ocurren y como cambian el estado de los
objetos. Así, los esquemas de eventos se deben expresar en términos de esquemas de objetos, ya que los eventos cambian los
estaos de determinados tipos de objetos. El AEO y el ACO están íntimamente relacionados, ya que se desarrollan juntos para
formar modelos y diseños integrados.

Estados de un objeto. Un objeto puede existir en varios estados. Un objeto puede ser instancia de distintos tipos de objeto, y
tales tipos de objetos se suelen percibir como estados posibles del ciclo vital de un objeto. Sin embargo un objeto puede tener
una gran variedad de perspectivas de ciclos vitales, es decir que el mismo objeto podría ser instancia de varios tipos de objeto al
mismo tiempo. El estado de un objeto es la colección de los tipos de objeto que se aplican a el.
Al implantarlo en un lenguaje OOP, el estado se registra en los datos almacenados con relación al objeto. Se determina
mediante las clases y valores de los campos de los datos asociados con el objeto. Generalmente los programadores OO usan
otra definición de estados: el estado de un objeto es la colección de asociaciones que tiene un objeto. En la OOP, las solicitudes
se envían y provocan la activación de métodos, los cuales cambian el estado del objeto, y este se registra en los datos del objeto.
 Eventos. En el análisis OO el mundo se describe en términos de los objetos y sus estados, así como de los eventos que cambian
tales estados. Llamamos eventos al cambio del estado de un objeto.
Los eventos sirven como indicadores de los instantes en que ocurren los cambios de estado. Como se desea saber de esos
cambios y reaccionar en forma adecuada ante ellos, debemos entender y modelar los eventos.

Tipos de eventos. Al analista OO no le sirve conocer todos los eventos que ocurren en la organización, más bien quiere
conocer los tipos de eventos. Los tipos de eventos indican los cambios sencillos en el estado de un objeto, indicando las
siguientes formas:
 Un objeto se crea.
 Un objeto se termina.
 Un objeto se clasifica como instancia de un tipo de objeto.
 Un objeto se desclasifica como una instancia de un tipo de objeto.
 Un objeto cambia de clasificación.
 El atributo de un objeto se cambia.
Los eventos pueden asociar un objeto con otro.
Algunos eventos requieren que ocurra otro antes de que poder ocurrir ellos mismos.
A veces un objeto puede crear una reacción en cadena de otros eventos.
Una operación hace que los eventos ocurran.
Las operaciones se representan como un cuadro con esquinas redondas, ya que los eventos indican los puntos en el tiempo en
que se da el cambio de estado de un objeto. Los tipos de eventos se representan como triángulos negros generalmente unidos a
la operación.
Según el área que se modele, puede ocurrir más de un evento al terminar una operación, y cada uno de estos puede activar
operaciones independientes.

El ciclo vital de un objeto. La mayoría de los objetos tiene un ciclo vital en el que una sucesion de eventos pueden ocurrirle y
cada uno de estos modifica su estado. En el analisis OO, se dibuja un diagrama que muestre el ciclo vital de un objeto. La figura
expresa el ciclo vital de un objeto. Además de mostrar los estados posibles del objeto, el diagrama también muestra los cambios
de estados permisibles.
A

Interacciones entre tipos de objetos. Los DTE son útiles para representar el ciclo de vida de un objeto particular. Sin embargo
la mayoría de los procesos requieren la interacción de varios objetos. El diagrama de red muestra como los distintos tipos de
objetos cambian de estado y pueden solicitar a otros objetos que cambien su estado en el proceso.
Cuando los diagramas se expresan así es fácil ver la forma de implantarlos como estructuras de un programa OO: los tipos de
objetos se implantan como clases y las operaciones se convierten en métodos del programa OO. Si durante el análisis el usuario
puede expresar los requisitos de procesamiento de esta forma, se facilita el trabajo del diseñador de lenguajes OOP. Sin
embargo, los usuarios no piensan en el procesamiento de aplicación en términos de tipos de objetos, saturados de operaciones
y que hacen distintos tipos de solicitudes. Es preferible un formato de guión cuando se dan eventos que activan operaciones, las
cuales a su vez producen eventos que activan otras operaciones, etc. Ese formato de guión, llamado esquema de eventos,
representa los cambios en el ciclo vital de un objeto particular, el cual activa cambios en el ciclo vital de otro objeto.

Operaciones. En el análisis OO, el término operación hace referencia a una unidad de procesamiento que puede ser solicitada.
El procedimiento se implanta mediante un método, el cual es la especificación de cómo llevar a cabo la operación., es decir que
es el guión de la operación. A nivel programa, el método es el código Que implanta la operación.
 Las operaciones se invocan, y son una instancia de una operación. Una operación puede cambiar o no el estado de un objeto,
pero si lo cambia ocurre un evento.

Fuentes externas de eventos. Los eventos son cambios de estado que un sistema debe conocer y poder reaccionar ante ellos
de algún modo. Muchas operaciones que producen eventos suelen ser externas al sistema. En tales casos, el símbolo de
operación se representa con una caja sombreada con esquinas redondeadas.
Un reloj externo es una forma particular de fuente externa. Indica que un proceso externo emitirá señales de reloj con cierta
frecuencia determinada con anterioridad. De modo que el evento se da cuando tal señal aparece. Se los representa con un
dibujo de reloj, indicando la periodicidad de la señal.

Reglas de activación. Cuando un evento ocurre, lo usual es que el cambio de estado active el llamado a una o más
operaciones. Así, las reglas de activación definen la relación entre la causa y el efecto. Siempre que ocurra un evento de cierto
tipo, la regla de activación invoca a una operación ya definida. Un tipo de evento puede tener varias reglas de activación, cada
una de las cuales invoca a su operación en paralelo, que pueden producir diferentes cambios de estado en forma simultanea.
Una operación puede ser invocada por varias reglas de activación, es decir que cualquier forma de activación hace que se
ejecute la operación.

Condiciones de control. Siempre que haya que verificar una condición de control antes de invocar a una operación, esta se
representa mediante un rombo antes de la operación.
Condición Tipo de
de control evento

Las condiciones de control también pueden actuar como puntos de sincronización para el procesamiento en paralelo, ya que
garantizan que un conjunto de eventos este completo antes de proceder con una operación.

Subtipos y supertipos de eventos. Los tipos ajenos se expresan como particiones de tipo, es decir que son mutuamente
excluyentes. La palabra partición implica la división de algo en subconjuntos ajenos. En OOP, ese algo es un supertipo. Las
particiones de eventos no son operaciones independientes que coordinan las condiciones de bifurcación para las formas de
activación ajenas, sino que indican los objetivos y distintos subobjetivos de las operaciones a las que están asociadas.

Esquemas jerárquicos. La operación que hace que ocurra un evento puede ser compleja, es decir que pude estar compuesta
por suboperaciones. Esto permite descomponer jerárquicamente los esquemas de eventos. Se pueden colocar fronteras en
torno a un esquema complejo de eventos y considerarlo como operación de alto nivel. Así, el esquema de eventos de bajo nivel
se convierte en el método para la operación que descompone.

Aislamiento de la causa y el efecto. Cada operación lleva a cabo su tarea sin importar lo que ocurra en otra parte. Una
operación es invocada por varios mecanismos de activación, ejecuta su método y se espera que esta modifique el estado de un
objeto. Una operación no sabe que evento la activo ni porque, ni si se activaran otras operaciones a partir de su evento. Este
aislamiento de las consideraciones de causa y efecto es necesario para que la operación pueda volver a utilizarse en muchas
otras aplicaciones.
En el AEO se hacen diagramas para representar la estructura de los tipos de objetos, en el ACO se trazan diagramas que
muestran la interacción dinámica de los eventos. Un esquema de objetos expresa el tipo de objeto y sus asociaciones en un
sistema dado. Los esquemas de eventos deben expresarse en términos de los esquemas de objetos, ya que los eventos se
expresan al cambiar el estado de determinados tipos de objetos.

Modularización clara. Las técnicas OO proporcionan dos maneras importantes de dividir el software complejo en
procedimientos sencillos. Primero, los métodos deben producir cambios en el estado de un objeto, el cual es fácil y sencillo de
programar: segundo, cada operación se puede volver a usar en distinto software y en varios procesadores que interactúen entre
sí.
Las técnicas OO proporcionan una clara modularización, más sencilla y precisa que la de las técnicas estructuradas
convencionales. Los objetos de gran complejidad se pueden usar mediante solicitudes simples, e interactúan en una parte del
software o en las maquinas de una red. El mantenimiento del software OO es mucho más sencillo.

La analogía del análisis y del diseño. Los analistas, diseñadores y técnicos deben poseer el mismo modelo del sistema. Con las
técnicas OO, se utiliza el mismo paradigma en el análisis, diseño e implantación. El analista identifica los tipos de objetos y su
herencia y piensa en los eventos que cambian los estados de los objetos. El diseñador añade detalles a este modelo, diseñando
pantalla, interacción con el usuario, etc. El proceso fluye tan naturalmente, que es difícil definir donde termina el análisis y
empieza el diseño.
Los usuarios finales deberían pensar también en términos de tipos de objetos, de eventos, de cambios de estado en los
objetos y las reglas de la empresa que activan y controlan los eventos; aunque es difícil que logren pasar a un pensamiento OO.
Es importante que los esquemas diseñados ayuden al usuario a poder pensar de esa manera.
Los analistas y los usuarios, en conjunto deberían crear un modelo de la empresa donde se muestre la forma en que se desea
que funcione la organización y que ayude a reinventar los procedimientos.

Diagrama de flujo de objetos (DFO). Los esquemas de eventos son adecuados para describir procesos en términos de eventos,
de reglas de activación, de condiciones, y de operaciones. Sin embargo puede no ser adecuado expresar de esa manera los
procesos grandes y complejos, y en cambio se opte por usar el DFO. Éstos son parecidos a los DFD, ya que muestran las
actividades que interactúan con otras. El diagrama debe representar cualquier cosa que se transfiera de una actividad a otra.
El DFO indica los objetos que se producen y las actividades que los producen e intercambian. EL producto es el resultado final
que satisface el propósito de la actividad, sin embargo no se producen solamente en aras de la producción. Se producen para el
consumo de otras actividades que le añaden valor al producto consumido. De esta manera el DFO se puede usar para la
planificación estratégica de la empresa.
El DFO es muy útil para los modelos de organizaciones en forma descendente a nivel estratégico. Sin embargo, n un nivel mas
detallado del ACO, también es correcto expresar los aspectos dinámicos de los esquemas de eventos. Una actividad puede
expresarse en términos de un DFO, de un esquema de eventos, o de ambos.
Para expresar un proceso de manera más rigurosa y poder generar un código, lo adecuado es un esquema de eventos. Un DFO
es útil para representar las estructuras básicas de control y el flujo de procesamiento.
Casos de uso
Es una descripción de un conjunto de secuencia de acciones, incluyendo variantes, que ejecuta un sistema para producir un
resultado observable de valor para un actor. Cada secuencia de acciones representa la interacción de los elementos externos al
sistema (los actores) con el propio sistema.
Los casos de uso se emplean para capturar el comportamiento del sistema, de un subsistema o de una clase, sin tener que
especificar como se implementa ese comportamiento. Los casos de uso bien estructurados denotan solo comportamientos
esenciales del sistema o de un subsistema, y nunca deben ser excesivamente genéricos ni demasiado específicos.
Un caso de uso siempre describe tres cosas: un actor que inicia un evento; el evento que activa un caso de uso, y el caso de uso
que desempeña las acciones activadas por el evento. El actor que usa el sistema comienza un evento que empieza una serie
relacionada de interacciones en el sistema. Los casos de uso se utilizan para documentar una sola transacción o evento.
Es conveniente crear no incluir consultas e informas y crear pocos casos de uso. 20 casos de uso (y nos mas de 40 o 50) son
suficientes para un sistema grande. Los casos de uso también se podrían anidar, de ser necesario. Se puede incluir un caso de
uso en varios diagramas, pero el caso de uso real se define una única vez en el diccionario.
Un caso de uso se nombra con un verbo y un sustantivo.

Características de los casos de uso.

 Están expresados desde el punto de vista del actor
 Se documentan con texto informal. Describen el qué y no el cómo.
 Describen tanto lo que el actor hace como lo que el sistema hace cuando interactúa con él, enfatizando la interacción.
 Un caso de uso es una clase. Un escenario es una instancia de un caso de uso.
 Los casos de uso están inicializados por un actor.

Actores
El termino actor se refiere a un papel particular de un usuario del sistema, por lo que si una persona realiza más de un trabajo,
estará representada por más de un actor. El actor existe fuera del sistema e interactúa con éste de una forma específica. Un
actor puede ser humano, otro sistema o un dispositivo. Los actores pueden iniciar una instancia de caso de uso, y podría
interactuar con uno o más casos de uso y viceversa.
Los actores se pueden dividir en dos grupos. Los actores principales proporcionan datos o reciben información del sistema y se
benefician de éste. Los actores secundarios ayudan a mantener el sistema en ejecución o proporcionan ayuda, es decir que
actúan de forma pasiva y no obtienen beneficios directos del sistema.

Relaciones del caso de uso

Las relaciones activas se denominan como relaciones de comportamiento y se emplean principalmente en los diagramas de
caso de uso. Los actores solo se pueden conectar a los casos de uso mediante estas asociaciones, las cuales indican que hay una
comunicación entre ambos y que se pueden enviar y recibir mensajes. Hay cuatro tipos básicos de relaciones de
comportamiento:

Comunica. Se usa para conectar a un actor con un caso de uso. La tarea del caso es dar alguna clase de resultado benéfico para
el actor en el sistema.

Un actor se comunica
con un caso de uso por Matricularse en
una línea sin puntas el curso
Estudiante

Incluye. Describe la situación en que un caso de uso contiene un comportamiento que es común para más de un caso de uso,
es decir que al caso de uso común se lo incluye en otros casos de uso. La secuencia común es un caso de uso abstracto y no
puede instanciarse por sí mismo, lo casos que incluyen a esta secuencia común son casos de uso concretos y pueden
instanciarse. Esta relación es una relación de dependencia.
Matricularse en
el curso
<<Incluir>>
Un caso de uso contiene un comportamiento
que es más común que otro caso de uso.
Pagos de cuotas La flecha apunta al caso de uso común y es
del estudiante una flecha compuesta por guiones y rotulada.
<<Incluir>>
Arreglar
residencia
estudiantil
 Extiende. Describe la situación en el que un caso de uso posee el comportamiento que permite al nuevo caso de uso manejar
una variación o excepción del caso de uso básico. Siempre se instancia un caso de uso base, mientras que las extensiones son
instanciadas bajo determinadas condiciones. Las extensiones modelan comportamientos opcionales a los comportamientos
obligatorios de los casos de usos. Representan una parte de la funcionalidad del caso que no siempre ocurre, pero son un caso
de uso en sí mismos y no necesariamente provienen de un error o excepción.

Un caso de uso diferente maneja las

Seguro médico <<Extender>> Pagos de cuotas
excepciones del caso de uso básico. La
del estudiante del estudiante
flecha apunta desde el caso de uso
extendido hacia el básico y el igual a la
de incluir, excepto por el rótulo.

Generaliza. Implica que una cosa es más típica que otra. Esta relación podría existir entre dos actores o dos casos de uso. Un
caso de uso se puede especializar en uno o más casos de uso hijos (también aplicable a los actores). La relación de
generalización también se puede llamar como “es un tipo de” con el nombre del elemento hijo a izquierda y del elemento
general a derecha. Para este tipo de relación se verifican las propiedades de herencia.

Una cosa de UML es más

general que otra cosa. La
flecha apunta a la cosa general

Estudiante de Estudiante
tiempo parcial

Flujo de eventos o caminos

El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos o caminos de forma textual. Hay
dos tipos de caminos: El camino estándar, el cual es una descripción secuencial de todas las actividades que deben realizarse en
forma normal sin describir el proceso de excepciones; y el camino alternativo, que describe casos inusuales de procesamiento y
manejo de excepciones o errores.

Diferencias entre casos de uso y eventos. Los eventos se centran en describir que hace el sistema cuando el evento ocurre,
mientras que los casos de uso describen como es el dialogo usuario-sistema. Además, los eventos se pueden considerar como
atómicos: Entrada  Proceso  Salida, mientras que un caso de uso se prolonga a través del tiempo. Para los eventos, lo más
importante los las entradas y las salidas del sistema cuando el evento ocurre, mientras que para los casos de uso esto es
secundario.

Escenarios
Un escenario es una secuencia específica de acciones que ilustra un comportamiento, siendo básicamente una instancia de un
caso de uso. En otras palabras, es una combinación exacta de lo que hace el actor en un momento determinado, es una
secuencia específica de un caso de uso.

Desarrollo de diagrama de casos de uso

El caso de uso principal consiste de un flujo estándar de eventos en el sistema que describe un comportamiento estándar del
sistema. Representa la realización normal, esperada y exitosa del caso de uso. Las variaciones o excepciones, conocidas como
caminos alternativos, también se pueden diagramar y describir.
Al diagramar un caso de uso, se pide a los usuarios que mencionen todo lo que el sistema debe hacer para ellos. Se debe
escribir quien está involucrado con cada caso de uso y las responsabilidades o servicios que el caso de uso debe proporcionar a
lo actores u otros sistemas. Es conveniente usar los siguientes lineamientos:
 Revisar las especificaciones del negocio e identificar los actores en el dominio del problema.
 Identificar los eventos de alto nivel y desarrollar los casos de uso principales que describen dichos eventos y como los
inician los actores. Examinar los papeles jugados por los actores para identificar todos los posibles casos de uso
principales iniciados por cada actor. No se necesita mostrar los casos de uso con poca o ninguna interacción del
usuario.
 Revisar cada caso de uso principal para determinar las posibles variaciones de flujo a través del caso de uso.
Establecer las rutas alternativas. Como el flujo de eventos normalmente es diferente en cada caso, se debe buscar
actividades que el pueden tener éxito o fallar. También hay que buscar ramas en la lógica del caso de uso en que son
posibles resultados diferentes.
Si se crea un DFD de nivel de contexto, puede ser un punto de partido para crear un caso de uso. Las entradas externas son
actores potenciales. Entonces se examina el flujo de datos para determinar si iniciara un caso de uso sería producido por uno.
Los diagramas de caso de uso son un buen uso son un buen punto de partida, pero se necesita una descripción mas completa
de ellos para su documentación. Un caso de uso completo incluirá un diagrama de caso de uso y una serie de descripciones.

A la hora de construir los diagramas se deben tener en cuenta algunas consideraciones:

  Un gráfico no debe mostrar más de 15 casos de uso.
 Si se debe particionar más el gráfico, se lo puede hacer por actor.
 Si las relaciones de uso y las extensiones entran en el diagrama principal cumpliendo con la primera consideración, se
las debe dejar allí. Esto también se aplica a los actores abstractos.
 Si las relaciones de uso no entran en el diagrama principal, se deben mostrar en gráficos teniendo en cuenta que
siempre deben mostrarse todos los casos de uso que usan a otro en un mismo diagrama.
 Si se tiene un caso de uso que es usado por gran parte de los otros casos de uso, es probable que no haga falta mostrar
tal relación de uso en un grafico.

Desarrollo de escenarios de caso de uso.

Cada caso de uso tiene una descripción, la cual se conoce como escenario de caso de uso. El caso de uso principal representa
el flujo estándar de eventos del sistema y las rutas alternativas describen las variaciones para el comportamiento.
No hay formato estándar de escenario de caso de uso, de modo que cada organización se enfrenta con especificar que
estándares se deben incluir. Frecuentemente los casos de uso se documentan con una plantilla de documento de caso de uso
predeterminada por la organización, la cual hace los casos de uso fáciles de leer y proporciona información estándar para cada
caso de uso en el modelo.
Algunas de las áreas incluidas en el escenario son opcionales y no se podrían usar en todas las organizaciones. Las tres áreas
principales son:
 Identificadores e iniciadores de caso de uso. Orientan al lector y contiene el nombre de caso de uso y una ID única; el
área de aplicación o sistema que le pertenece a este caso de uso; los actores involucrados en el caso de uso; una
breve descripción de lo que logra el caso de uso, y la activación del evento, es decir, lo que ocasionó que empezara el
caso de uso, y el tipo de activación, externo o temporal.
 Pasos desempeñados. Incluye los pasos desempeñados y la información requerida para cada uno de los pasos. Tales
declaraciones representan el flujo estándar de eventos y los pasos tomados para la realización exitosa del caso de
uso. Se desea escribir un caso de uso para la ruta principal y después escribir uno por separado para cada uno de los
caminos alternativos, en vez de usar declaraciones condicionales (SI ENTONCES).
 Condiciones, suposiciones y preguntas. Incluye las precondiciones o la condición del sistema antes de que se pudiera
desempeñar el caso de uso; las postcondiciones, o el estado del sistema después de que el caso de uso haya
terminado; cualquier suposición hecha que pudiera afectar el método del caso de uso; cualquier asunto excelente o
preguntas que se deben responder antes de la implementación del caso de uso; una declaración opcional de prioridad
del caso de uso, y una declaración opcional de riesgo involucrada al crear el caso de uso.

Una vez desarrollados los escenarios de caso de uso, hay que asegurarse de revisar los resultados con los expertos de negocios
para verificar y refinar los casos de uso si es necesario. Luego de finalizar el proceso de verificación y de que todos los expertos
de negocios coincidan en que los casos de uso son precisos, puede procederse a usar técnicas de diagramación de UML para
completar el análisis y diseño de sistemas.

Clasificación de los casos de uso

Caso de uso esencial. Excluye aspectos específicos de la interfaz. Capturan la intención de los usuarios y se centran en la
interacción y su propósito. Solo describe la secuencia de interacción.
Caso de uso elaborado. Expandido para incluir detalles de la interfaz. Se usa para identificar los requerimientos. Se pueden
tener más de un caso de uso elaborado asociado a un solo caso de uso esencial.
Caso de uso abstractico. Nunca se ejecuta fuera del contexto de otro caso de uso. No se pueden instanciar por si mismo, solo
tiene sentido como parte de otros casos de uso.
Caso de uso de trazo grueso. Identifica todos los casos de uso del sistema, solo a nivel de su nombre. Una vez identificados, se
los expresa en trazo grueso, esto es: se ignoran los detalles sobre la forma de la interacción entre el actor y el sistema y solo se
incluyen las alternativas más relevantes, ignorando la mayoría de los errores que aparecen en el uso del sistema.
Caso de uso de trazo fino. Aquellos que se especifican una vez que se toma la decisión de implementarlos. Es este momento
se deben completar todos los detalles que pasan por alto:
 A medida que se hacen prototipos de las interfaces con los usuarios, se incluyen detalles sobre la forma de la interfaz
en la descripción del caso.
 Se incluyen otras alternativas, particularmente especificamos todos los errores o excepciones que provienen de
requerimientos de los usuarios.
 Se debe tener en cuenta que un sistema tiene dos tipos de excepciones o errores: las que provienen de las
definiciones del negocio y las que provienen del procesamiento interno del sistema.
Casos primarios. Son aquellos que se corresponden con procesos del negocio.
Casos secundarios. Son aquellos que no corresponden con procesos del negocio y cuya ejecución solo es necesaria para que el
sistema funcione normalmente.

El proceso de análisis de requerimientos con casos de uso

Identificar los actores. El analista pregunta a los usuarios quienes usarán el sistema o para quien es el sistema. Se deben tratar
de identificar todos los tipos de usuarios diferentes que tiene el sistema.
 Identificar los principales casos de uso de cada actor. El siguiente paso es enunciar los nombres de los principales casos de
uso de cada uno de los actores identificados anteriormente. No se precisa especificar cuales son las acciones dentro del caso de
uso. Se deben diferenciar los objetos del usuario de las interacciones del sistema.
Identificar nuevos casos a partir de los existentes. Esta técnica se basa en el análisis de cuatro situaciones posibles a partir de
los casos ya identificados:
 Variaciones significativas de casos de uso existentes en función del actor que los ejecuta, o del tipo de objeto sobre el
que se apliquen.
 Casos de uso opuestos: hay dos formas de buscar casos de uso opuestos. La primera es buscar la función opuesta a la
descrita por el caso. La segunda es buscar casos de uso opuestos es pensar en la negación de la acción principal del
caso de uso.
 Casos de uso que preceden a casos existentes.
 Casos de uso que suceden a casos existentes.
Crear descripciones de casos de uso de trazo grueso.
Definir prioridades y seleccionar casos de la primera iteración.
 Los requerimientos imprescindibles e importantes son aquellos que de no implementarse harían que el sistema no
tenga sentido.
 Los deseables son aquellos que se deberían implementar si se dispone del tiempo y de los recursos suficientes.
Escribir los casos de uso de trazo fino y crear prototipos de interfaces. Cuando se crean prototipos de implementación de los
casos de uso, se debe tener en cuenta que son descartables, y que se esta tratando de validar el estilo de la iteración, no toda la
iteración, se quiere que el usuario tenga una idea de cómo se verá el sistema, no que apruebe todas las pantallas y listados

Diagramas de UML
Diagramas de casos de uso. Se emplean para visualizar el comportamiento de un sistema, un subsistema, o una clase, de
modo que los usuarios puedan comprender como usar tal elemento y que los desarrolladores puedan implementarlo.
Tales diagramas muestran un conjunto de casos de uso, actores y sus relaciones. Además se usan para modelar la vista estática
de los casos de uso un sistema (la cual cubre principalmente el comportamiento del sistema). Cuando se modela esta vista,
normalmente se emplean los diagramas de casos de uso de una de las dos formas siguientes:
 Para modelar el contexto de un sistema.
 Para modelar los requisitos de un sistema.

NOMBRE DEL SISTEMA

Nombre del
caso de uso

Cliente
Nombre del
caso de uso

Nombre del
Cliente Cliente caso de uso
individual Corporativo

Diagrama de interacción. Muestra una interacción que consiste en un conjunto de objetos y sus relaciones, incluyendo los
mensajes que se pueden enviar entre ellos. Hay dos tipos de diagramas de interacción.
 Diagrama de secuencia. Destacan la ordenación temporal de los mensajes. Estos se forman colocando en primer
lugar los objetos que participan en la interacción en la parte superior del diagrama a los largo de un eje horizontal.
Normalmente se coloca a la izquierda el objeto que inicia la interacción, y los objetos subordinados a la derecha. A
continuación se colocan los mensajes que estos objetos envían y reciben a lo largo del eje vertical, en orden de
sucesión temporal, desde arriba hasta abajo
Tienen dos características: la línea de vida, la cual es una línea discontinua vertical que representa la existencia de un
objeto a lo largo de un periodo de tiempo; y el foco de control, que es un rectángulo delgado y estrecho que
representa el periodo de tiempo durante el cual un objeto ejecuta una acción.
 Diagrama de colaboración. Destaca la organización de los objetos que participan en una interacción. Estos se forman
colocando en primer lugar los objetos que participan en la colaboración como nodos del grafo, luego se representan
los enlaces que conectan esos objetos como arcos del grafo. Por ultimo, estos enlaces se adornan con los mensajes
que envían y reciben los objetos.
 Tienen dos características: el camino, que indica el enlace de un objeto a otro; y el número de secuencia, que indica
el orden temporal de un mensaje, se precede de un numero que crece secuencialmente por cada nuevo mensaje en
el flujo de control.

Los diagramas de secuencia y de colaboración muestran las mismas interacciones pero enfatizan distintos aspectos El primero.
Enfatiza la secuencia en el tiempo de los mensajes intercambiados pero no pone relevancia en la relación entre objetos, cosa
que el segundo pone en manifiesto descuidando las secuencias temporales.

Diagramas de actividades. Muestran las secuencias de actividades de un proceso, incluyendo las actividades secuenciales,
paralelas y decisiones que se toman. Generalmente, se elabora un diagrama de actividades para un caso de uso y podría reflejar
distintos escenarios posibles.
Un rectángulo de esquinas redondeadas representa una actividad, ya sea manual o automatizada. Una flecha representa un
evento, los cuales ocurren en un momento y lugar determinado. Un diamante representa una rama de decisión o una fusión. Las
decisiones tienen una flecha que entra en el diamante y varias que salen de él. Una fusión representa varios eventos que se
combinan para formar uno solo. Un rectángulo largo y plano representa una barra de sincronización, utilizada para representar
actividades paralelas y podría representar u n evento entrando en ella y varios saliendo, lo cual se llama bifurcación. Una
sincronización en la que varios eventos se fusionan en uno solo se conoce como unión. Dos símbolos representan el inicio y el
final del diagrama: el estado inicial es un círculo solido y el final como un círculo negro rodeado por uno blanco. Los rectángulos
que rodean otros símbolos llamados carriles indican un particionamiento y se usan para mostrar cuáles actividades se realizan
en qué plataformas, o para mostrar actividades realizadas por distintos grupos de usuarios. Los carriles son útiles para mostrar
como deben transmitirse o convertirse los datos.
Se crean preguntando la sucesión de eventos que ocurre. Se debe determinar se las actividades se realizan en secuencia o en
paralelo. Una guía útil son los DFDs. Conviene observar cada lugar en el que se toma una decisión y las consecuencias de tales
decisiones. Los diagramas de actividades se pueden crear observando todos los escenarios posibles para un caso de uso dado.
Cada ruta a través de las diversas decisiones incluidas en el caso de uso es un escenario diferente.

Diagramas de estados. Son otra manera de determinar los métodos de una clase. Se usan para examinar los diferentes
estados que puede tener un objeto. Un diagrama de estados se crea para una sola clase. Los objetos existen en cualquiera de
estos estados, que son las condiciones de un objeto en un momento determinado. El estado esta definido por lo valores de los
atributos del objeto. Cada estado tiene su propio nombre único y significativo. También, tiene acciones de entrada salida.
Los eventos causan cambios en el estado de un objeto disparando una transición cada vez que se cumple una condición, las
cuales se muestran entre corchetes junto a la etiqueta del evento. Los estados separan eventos. También hay eventos diferidos
o eventos que solo ocurren cuando un objeto cambia a un estado que puede aceptarlos. Hay tres tipos de eventos: señales o
mensajes asincrónicos, que ocurren cuando el programa no espera un mensaje de respuesta; mensajes sincrónicos, que son
llamadas a funciones o subrutinas; y eventos temporales.
Los objetos materiales tienen persistencia (existen durante un largo periodo de tiempo), algunos objetos son temporales, es
decir que no duran mucho tiempo.
Cuando un objeto cambia de estado, algunos atributos cambian sus valores, y esto ocurre mediante un método, lo cuales
pueden precisar de una interfaz para realizar el cambio convirtiéndose en los objetos de la interfaz.
Los diagramas de estados no se crean para todas las clases, sino cuando:
 Una clase tiene ciclo de vida complejo.
 Una instancia de una clase podría actualizar sus atributos de varias maneras a través de su ciclo de vida.
 Una clase tiene ciclo de vida operacional.
 Dos clases son interdependientes.
 El comportamiento actual del objeto depende de lo que haya ocurrido antes.
Al examinar el diagrama de estados se pueden encontrar errores y excepciones, viendo si los eventos ocurren en momentos
equivocados, si todos los eventos y estados están representados.
Un diagrama de estado solo debe lidiar con dos problemas: que un estado no tenga todas las transiciones dirigidas hacia el
estado o todas sus transiciones saliendo del mismo. Todo estado debe tener al menos una transición saliendo y entrando en el.
Historia del proceso unificado.
Es un proceso equilibrado, producto de varias décadas de desarrollo y uso práctico. Su desarrollo fue influenciado por varias
fuentes especialmente por los métodos Ericsson y Rational.

El método de Ericsson. Ericsson modelaba el sistema entero como un conjunto de bloques interconectados (en UML son
subsistemas implementados mediante componentes). Luego ensamblaba los bloques de más bajo nivel en subsistemas de más
alto nivel, para hacer al sistema más manejable. Identificaba los bloques estudiando los casos de negocio (hoy casos de uso),
previamente especificados, identificando para cada uno los bloques con los que debía cooperar. Con los conocimientos de las
responsabilidades de cada bloque, realizaba su especificación. Sus actividades de diseño producían un conjunto de diagramas de
bloques (que corresponden a los diagramas de clases) estáticos con sus interfaces, agrupados en subsistemas. Para cada caso de
uso se preparaba un diagrama de secuencia o colaboración que mostraban la comunicación entre bloques para llevar a acabo el
caso de uso. La especificación se preparaba como un grafo de estados y un grafo de transición de estados. Con este método se
podía crear una nueva configuración del sistema cambiando bloques que proporcionasen las mismas interfaces. Esencialmente
este método se conoce hoy como desarrollo basado en componentes. El creador de este método fue Ivar Jacobson.

EL lenguaje de descripción y especificación (SDL). Este estándar influenciado por el método de Ericsson, especificaba un
sistema como un conjunto de bloques interconectados que se comunicaban con otros solo mediante mensajes. Cada bloque
tenía un conjunto de procesos (término SDL para designar a las clases activas), el cual tenia instancias que interactuaban
mediante mensajes. SDL proponía Diagramas que eran especializaciones de los diagramas de clases, diagramas de actividad, de
colaboración y de secuencia. SDL sería sustituido por UML.

Objectory. Empresa fundada por Jacobson en la que desarrollaría el método del mismo nombre. En el se le daba un nombre al
concepto de caso de uso, se había desarrollado una técnica de representación y la idea se amplio para abarcar varias
aplicaciones
Los flujos de trabajo sucesivos se representaron en una serie de modelos: requisitos-casos de uso, análisis, diseño,
implementación y prueba. Se concibió al modelo como perspectiva del sistema, dándole importancia a las relaciones entre
modelos. La trazabilidad se volvió un requisito del desarrollo dirigido por casos de uso.

El método Rational. Rational compró Objectory con la tarea de unificar los principios básicos subyacentes en los procesos de
desarrollo existentes. En su trabajo decían que eran importantes el diseño OO, la abstracción, el encapsulamiento, la
reutilización y el prototipado.
Rational puso énfasis en la arquitectura y en el desarrollo iterativo. La idea de tener un conjunto de vistas en vez de meter
todo en un único diagrama, también vio la luz. Las vistas múltiples permitieron encontrar tanto a los usuarios como a los
desarrolladores lo que necesitaban para realizar sus objetivos con la vista adecuada.
El desarrollo iterativo fue visto como caótico y anárquico. El método de cuatro fases (comienzo, elaboración, construcción y
transición) se diseño para estructurar mejor y controlar el proceso durante las iteraciones.
Cuando se realizó la adquisición, se creo el proceso Objectory de Rational, añadiéndose sus características para
complementarse, principalmente ampliando el concepto de desarrollo iterativo pasando a ser un método dirigido por los riesgos
que consideraba la arquitectura en primer lugar, la cual obtuvo una definición precisa, considerada como la parte mas
significativa de la organización del sistema.

El lenguaje unificado de modelado. Este permitía expresar los resultados de las numerosas metodologías de OO existentes.

El proceso unificado
Es un proceso de desarrollo de software y un marco de trabajo genérico que puede especializarse para una gran variedad de
sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaños de proyecto. Se basa en componentes, lo que quiere decir que el sistema de software a construir esta
formado por componentes de software interconectados mediante interfaces bien definidas. Utiliza UML para preparar todos los
esquemas de un sistema de software.
Los verdaderos aspectos definitivos del PU son: dirigido por casos de uso, centrado en la arquitectura, e iterativo e
incremental.

Requisitos del Proceso de desarrollo de Sistema de

Usuario software Software
 Está dirigido por casos de uso. El término usuario se aplica a alguien o algo que interactúa con el sistema que se está
desarrollando. En respuesta a los estímulos del usuario el sistema lleva a cabo una secuencia de acciones que le dan al usuario
un resultado importante.
Las interacciones son casos de uso, fragmentos de funcionalidad del sistema que proporcionan al usuario un resultado
importante. Representan los requisitos funcionales. El conjunto de todos los casos de uso forma el modelo de casos de uso, que
describe la funcionalidad total del sistema. Si las especificaciones funcionales contestan la pregunta ¿Qué debe hacer el
sistema?, la estrategia de casos de uso se puede describir añadiendo a la pregunta ¿… para cada usuario? Lo cual cambia el
enfoque de pensamiento hacia la importancia para el usuario y no solo en términos de funciones que sería bueno tener. Además
de ser una herramienta para especificar los requisitos de un sistema, los casos de uso también guían su diseño, implementación
y prueba, es decir, todo 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. Revisan cada uno de los sucesivos modelos para que
sean conformes al modelo de casos de uso. Se prueba la implementación para garantizar que los componentes del modelo de
implementación implementan correctamente los casos de uso. Dirigido por casos de uso hace referencia a que el proceso de
desarrollo sigue el trayecto marcado por éstos. Los casos de uso se especifican, se diseñan y los casos finales son la fuente de la
creación de los casos de prueba.
Los casos de uso no se desarrollan aisladamente, sino a la par de la arquitectura del sistema. Los casos de uso guían la
arquitectura mientras que ésta influye en la selección de los casos de uso.

Centrado en la arquitectura. El concepto de arquitectura de software incluye los aspectos estáticos y dinámicos más
significativos del sistema. Surge de las necesidades de la empresa, como la perciben usuarios e inversores, y se refleja en los
casos de uso, aunque también está influenciada por otros factores, como la plataforma sobre la que funcionará el software, los
bloques de construcción reutilizables disponibles, consideraciones de implantación, sistemas heredados y requisitos no
funcionales. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando de
lado los detalles. El valor de la arquitectura esta dado por su comprensibilidad, adaptabilidad y reutilización.
Todo producto tiene función y forma. Ambas se deben equilibrar para el éxito del producto. La función corresponde a los casos
de uso y la forma a la arquitectura. Los primeros deben encajar en la arquitectura cuando se llevan a cabo, y la arquitectura
debe permitir el desarrollo de todos los CU requeridos, por lo que ambos deben evolucionar en paralelo. La forma debe
diseñarse para permitir al sistema evolucionar en todo momento. Para hallar tal forma se trabaja sobre la comprensión general
de los casos de uso claves del sistema (generalmente son el 5-10% de los CU).
Los arquitectos crean esquemas preliminares de la arquitectura comenzando por la parte que no es específica de los casos de
uso. Aunque se debe poseer una comprensión general de los casos de uso antes de comenzar la creación del esquema
arquitectónico. Luego se trabaja con un subconjunto de los casos de uso especificados con aquellos que representen las
funciones clave del sistema en desarrollo. Cada caso de uso seleccionado se especifica en detalle y se realiza en términos de
subsistemas, clases y componentes. A medida que los casos de uso se especifican y maduran, se descubre mas de la arquitectura
lo cual lleva a la maduración de mas casos de uso. Generando un proceso continúo.

Iterativo e incremental. Debido a que el proyecto puede durar mucho tiempo, es práctico dividir el trabajo en partes más
pequeñas o miniproyectos, cada uno de los cuales es una iteración que resulta en un incremento. Las iteraciones hacer
referencia a pasos en el flujo de trabajo y los incrementos al crecimiento del producto. Las iteraciones deben estar controladas,
es decir deben seleccionarse y ejecutarse de forma planificada.
Los desarrolladores basan la selección de los que se implementara en una iteración en dos factores. Primero, la iteración trata
un grupo de casos de uso que juntos amplían la utilidad del producto. Segundo, la iteración trata 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
miniproyectos, comienzan con los casos de uso y continúan a través del trabajo de desarrollo siguiente, que termina
convirtiendo en código ejecutable lo casos de uso que se desarrollaban en la iteración. Los incrementos no siempre son aditivos,
también pueden reemplazar los diseños anteriores.
En cada iteración se identifican y especifican los casos de uso relevantes, se crea un diseño utilizando la arquitectura
seleccionada como guía, se implementa el diseño mediante componentes, y se verifica que los componentes satisfacen los casos
de uso. Si una iteración cumple con sus objetivos el desarrollo sigue con la siguiente iteración.
Para tener el mayor grado de economía en el desarrollo, un equipo de proyecto debe seleccionar solo las iteraciones
requeridas para lograr el objetivo del proyecto, luego secuenciarlas en un orden lógico. Un proyecto exitoso solo debe tener
pequeñas desviaciones planificadas. Luego se irán añadiendo iteraciones nuevas junto con más desviaciones.
Hay muchos beneficios de un proceso iterativo controlado:
  Reduce el costo de riesgo a los costos de un solo incremento. Al repetir una iteración se pierde solo el esfuerzo de esa
única iteración.
 Reduce el riesgo de no sacar el producto a tiempo. Mediante la identificación temprana de riesgos es más fácil
resolverlos.
 Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan de manera más
eficiente para tener resultados claros a corto plazo.
 Reconoce que las necesidades y requisitos de los usuarios no se pueden definir completamente al principio. Hace más
fácil la adaptación de requisitos en iteraciones sucesivas.

La vida del proceso unificado

El PU se repite a lo largo de ciclos que constituyen la vida del sistema. Cada ciclo concluye con una versión del producto. Cada
ciclo consta de cuatro fases: inicio, elaboración, construcción, y transición. Cada fase se subdivide en iteraciones.

Nacimiento Muerte

Cada ciclo se desarrolla a lo largo del tiempo en cuatro fases. Mediante una secuencia de modelos,
Tiempo se visualiza lo que sucede
en tales fases. En cada fase se puede descomponer más el trabajo en iteraciones con sus incrementos correspondientes. Cada
fase termina con un hito, el cual se determina por la disponibilidad de un conjunto de artefactos; es decir, ciertos modelos o
documentos han sido desarrollados hasta alcanzar un estado predefinido.

Disciplinas. Conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área especifica dentro del proyecto total.
Las más importantes son: requerimientos, análisis, diseño, implementación y prueba. El agrupamiento de actividades en
disciplinas ayuda a comprender el proyecto en una visión de cascada.

Cada disciplina está asociada con un conjunto de modelos que se desarrollan, los cuales están compuestos por artefactos. Los
artefactos más importantes que cada disciplina realiza son:

El PU consiste en una serie de disciplinas o flujos de trabajo que van desde los requisitos hasta las pruebas. Los flujos de
trabajo desarrollan modelos desde el de casos de uso hasta el modelo de prueba.
 Hitos. Puntos de control en que los participantes del proyecto revisan el progreso del proyecto. Cada fase finaliza con un hito,
el cual se determina por la disponibilidad de un conjunto de artefactos. Los hitos tienen muchos objetivos. El más crítico es que
los directores deben tomar ciertas decisiones antes de que el trabajo continúe con la siguiente fase. También permite controlar
dirección y progreso del trabajo según pasa por los puntos clave. Los distintos tipos de hitos son: principales, los que se obtienen
al final de cada fase; y secundarios, los que se obtienen al final de cada iteración.
Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumido en cada fase, los cuales son
útiles para estimar tiempos y recursos en otros proyectos, en la asignación de recursos durante el transcurso del proyecto y para
el control del proyecto contrastado con las planificaciones.
La figura muestra en la columna izquierda los flujos de trabajo, las curvas son aproximaciones de hasta donde se llevan a cabo
los flujos de trabajo en cada fase

Durante la fase de inicio se desarrolla una descripción del producto final a partir de una buena idea y se presenta el análisis de
negocio para el producto. Se crea un modelo de casos de uso simplificado que contenga los casos de uso más críticos. La
arquitectura consiste típicamente en un simple esbozo que muestra los subsistemas más importantes. En esta fase se identifican
y priorizan los riesgos mas importantes, se planifica detalladamente la fase de elaboración y se estima el proyecto.
Durante la fase de elaboración, se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura
del sistema, ya que la relación entre ésta y el sistema es primordial. La arquitectura se expresa en forma de vistas de todo los
modelos del sistema representados junto al sistema entero. Durante esta fase se realizan los casos de uso más críticos
identificados en la primera fase. El resultado de esta fase es una línea base de la arquitectura. Al final de esta fase, se podrán
planificar las actividades y estimar los recursos necesarios para terminar el proyecto. Se debe considerar si la arquitectura, el
plan y los casos de uso son lo suficientemente estables y los riesgos están bien controlados.
Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece hasta convertirse en un sistema
completo. La descripción evoluciona hasta convertirse en un producto preparado para ser entregado a los usuarios. Al final de
esta fase, el producto contiene todos los casos de uso acordados para el desarrollo de la versión del producto correspondiente,
aunque puede no estar libre de defectos, la mayoría de los cuales se descubrirán y eliminaran en la fase de transición. La
pregunta clave en esta fase es si el sistema cumple suficientemente las necesidades de algunos usuarios como para realizar la
entrega.
La fase de transición cubre el periodo durante el cual el producto se convierte en versión beta. Los desarrolladores corrigen los
defectos y se incorporan algunas mejoras en una versión general que se dirige a toda la comunidad de usuarios. Esta fase
consiste en la fabricación, formación del cliente, proporcionar ayuda y asistencia, y la colección de los defectos. Los defectos se
dividen en dos categorías: los que tienen suficiente impacto como para justificar una nueva versión incrementada (versión delta)
y los que se pueden corregir en una próxima entrega normal.

Las cuatro “P” en el desarrollo de software

El resultado final de un proyecto es un producto que toma forma gracias a la intervención de muchos tipos de personas. Un
proceso de desarrollo de software guía los esfuerzos de las personas implicadas en el proyecto, a modo de plantilla que explica
los pasos necesarios para terminar el proyecto. Generalmente el proceso está automatizado por un conjunto de herramientas.
  Personas. Los principales autores del proyecto de software son los arquitectos, desarrolladores, ingenieros y el personal
de gestión que le da soporte; además de los usuarios, clientes, inversores, y demás personas interesadas.
 Proyecto. Elemento organizativo a través del cual se gestiona el desarrollo de software. Su resultado es una versión del
producto.
 Producto. Artefacto creado durante la vida del proyecto, como los modelos, código fuente, ejecutables y
documentación.
 Proceso. Definición del conjunto completo de actividades necesarias para transformar los requisitos de usuarios en un
producto. Un proceso es una plantilla para crear proyecto.
 Herramientas. Software usado para automatizar las actividades definidas del proceso.

Proceso

Plantilla

Proceso Participantes
Proceso Automatización Proceso

Resultado

Proceso

Personas. Hay muchas personas implicadas en el desarrollo del producto durante toda su vida, de distintas maneras, como
financiándolo, planificándolo, desarrollándolo, etc. Por lo tanto, el proceso que guía tal desarrollo debe estar orientado a las
personas que lo utilizan.
El modo en que se organiza y gestiona un proyecto de software afecta profundamente a las personas implicadas en él. Hay
conceptos que tienen un papel muy importante, como:
 Viabilidad del proyecto. La mayoría de la gente no disfruta de trabajar en proyectos imposibles. Una aproximación
iterativa en el desarrollo permite juzgar la viabilidad del proyecto tempranamente, lo cual es bueno para descartar los
imposibles rápidamente.
 Gestión del riesgo. Cuando la gente siente que los riesgos no están analizados y reducidos, se genera cierta
incomodidad. Explorar riesgos significativos en fases tempranas atenúa el problema.
 Estructura de los equipos. Las personas trabajan más eficientemente en grupos pequeños (6-8 personas). Una buena
arquitectura, con interfaces bien definidas entre subsistemas y componentes hace posible una división del esfuerzo
de este tipo.
 Planificación del proyecto. La moral de la gente tiende a caer si siente que la planificación no es realista. Las técnicas
usadas en las fases de inicio y elaboración permiten a los desarrolladores tener una buena noción de cual debería ser
el resultado del proyecto. Esto permite crear un plan de proyecto realista para el esfuerzo requerido y una definición
del tiempo necesario para lograr los objetivos.
 Facilidad de comprensión del proyecto. La gente quiere saber lo que está haciendo. La descripción de la arquitectura
da una visión general para cualquiera que esté implicado en el proyecto.
 Sensación de cumplimiento. En un ciclo de vida iterativo, las personas reciben retroalimentación frecuentemente, lo
cual hace que lleguen a conclusiones. Esto acelera el ritmo de trabajo generando una sensación de progreso.

Convertir recursos en trabajadores. Las personas pueden ocupar muchos puestos diferentes en una organización de
desarrollo de software. Una organización se enfrenta con una tarea esencial siempre que haga que una persona pase de recurso
latente aun puesto de trabajador.
El término trabajador denomina a los puestos a los que se pueden asignar personas. Un trabajador también puede representar
a un grupo de personas que trabajan juntas. Una persona puede ser muchos trabajadores durante la vida del proyecto. Un tipo
de trabajador es un papel que un individuo puede desempeñar en el desarrollo de software. El término rol hace referencia a los
papeles que cumple un trabajador.
Cada trabajador es responsable de un conjunto de actividades. Para trabajar eficazmente, los trabajadores necesitan, la
información requerida para llevar a cabo sus actividades, comprender sus roles en relaciones con los de otros trabajadores. Las
herramientas que emplean deben ser las adecuadas y no solo deben ayudar a los trabajadores a realizar sus actividades, sino
también deben aislarles de la información que no les es relevante.
Al asignar los trabajadores a un proyecto, el líder del proyecto debe identificar las aptitudes de las personas y emparejarlas con
las aptitudes requeridas de los trabajadores. Algunas aptitudes se pueden conseguir mediante formación, otras mediante
experiencia.
Al asignar recursos se debería minimizar el trasiego de artefactos de un recurso a otro de modo que el flujo del proceso sea lo
más continuo posible.

Los proyectos construyen el producto. Un proyecto en desarrollo da como resultado una nueva versión del producto. A través
de su ciclo de vida, un equipo de proyecto debe preocuparse del cambio, las iteraciones y el patrón organizativo dentro del cual
se conduce el proyecto:
 Una secuencia de cambio. Los proyectos de desarrollo de sistemas obtienen productos como resultados, pero el
camino hasta ellos es una serie de cambios. Cada ciclo, fase e iteración, modifica el sistema.
 Una serie de iteraciones. Dentro de cada fase de un ciclo, los trabajadores llevan a cabo las actividades de la fase a
través de una serie de iteraciones, cada una de las cuales implementa un conjunto de casos de uso relacionados o
atenúa algunos riesgos. Cada iteración se considera un miniproyecto.
 Un patrón organizativo. Un proyecto requiere que un equipo logre un resultado dentro de las restricciones del
negocio (tiempo, costo y calidad). La idea de proceso es proporcionar un patrón dentro del cual las personas en su
papel de trabajadores ejecutan un proyecto, el cual indica los tipos de trabajadores que el proyecto necesita y los
artefactos por lo cuales hay que trabajar. El proceso también ofrece un montón de guías heurísticas y practicas de
documentación que ayudan a las personas a realizar su trabajo.

El producto. En el contexto del PU, el producto es un sistema de software. El término producto se refiere al sistema entero y
no solo al código que se entrega.
El sistema de software son todos los artefactos necesarios para representarlo de forma comprensible para máquinas u
hombres. Las maquinas son las herramientas, compiladores u ordenadores destinatarios. Los hombres son los trabajadores y los
interesados. Entre los trabajadores están los directores, arquitectos, analistas, diseñadores, etc. Entre los interesados se
encuentran los inversores, usuarios, jefes de proyecto, personal de producción, etc.

Artefactos. Cualquier tipo de información creada, cambiada, producida o utilizada por los trabajadores en el desarrollo del
sistema.
Hay dos tipos de artefactos: artefactos de ingeniería y artefactos de gestión. Los artefactos de ingeniería se crean durante las
distintas fases del proceso, sin embargo el desarrollo de software también requiere de artefactos de gestión. Varios de estos
artefactos tienen un tiempo de vida corto. Los artefactos de gestión incluyen las especificaciones del entorno de desarrollo.
El tipo de artefacto más usado en el PU es el modelo. Cada trabajador necesita una perspectiva diferente del sistema. Cuando
se diseña el PU se identifican todos los trabajadores y cada una de las perspectivas que podrían necesitar, las cuales se
estructuran en unidades más grandes, de modo que un trabajador puede tomar una perspectiva concreta del conjunto de
modelos.
La construcción de un sistema es un proceso de construcción de modelos, usados para describir todas las perspectivas
diferentes del sistema. El PU proporciona un conjunto de modelos cuidadosamente seleccionados con el cual empezar, el cual
hace claro el sistema para los trabajadores, incluyendo a los clientes, usuarios y jefes de proyecto. El modelo no se preocupa por
la composición del sistema sino por lo que este puede hacer para los usuarios, además el usuario de un modelo no precisa de
otros modelos para interpretarlo. Debe describir las interacciones entre el sistema y su entorno.

El proceso. El término proceso se refiere a los procesos de negocio claves en una empresa de desarrollo de software. Hace
referencia a un contexto que sirve como plantilla que puede reutilizarse para crear instancias de ella. Se considera que el
proyecto es una instancia del proceso.
El proceso de desarrollo de software es una definición del conjunto completo de actividades necesarias para convertir los
requisitos de usuario en un conjunto consistente de artefactos que conforman un producto software, y para convertir los
cambios sobre esos requisitos en un nuevo conjunto consistente de artefactos.
El resultado del proceso es un conjunto de artefactos, una línea base que conforma una aplicación o una familia de ellas que
forman un producto de software.
Un proceso es una definición de un conjunto de actividades, no su ejecución.
 Un proceso cubre todos los ciclos más comunes de desarrollo. En versiones posteriores, una instancia del proceso toma
cambios incrementales en los requisitos y produce cambios incrementales en el conjunto de artefactos. Se describe en términos
de flujos de trabajo. Describe como fluye el proceso a través de los diferentes trabajadores, y como ellos crean, producen y usan
los artefactos de los demás.

Una colaboración de trabajadores y

Requisitos artefactos usado para describir el
flujo de requisitos del proceso
Notación de flujo de trabajo
Ningún proceso es de aplicación universal, por lo tanto un proceso de desarrollo de software del debe ser adaptable y
configurable. El PU se diseñó para ser adaptable. Es un proceso genérico, y cada organización que lo use lo especializará para
ajustarlo a su situación.
Los factores principales que influyen en como se diferenciará el proceso son:
 Factores organizativos. La estructura organizativa, la cultura de la empresa, la organización y la gestión del proyecto,
las aptitudes y habilidades disponibles, experiencias previas y sistemas de software existentes.
 Factores del dominio. El dominio de la aplicación, procesos de negocio que se deben soportar, la comunidad de
usuarios y las ofertas disponibles de la competencia.
 Factores del ciclo de vida. El tiempo de salida al mercado, el tiempo de vida esperado del software, la tecnología y la
experiencia de las personas en el desarrollo de software, y las versiones planificadas y futuras.
 Factores técnicos. Lenguaje de programación, herramientas de desarrollo, base de datos, marcos de trabajo y
arquitecturas estándar subyacentes, comunicaciones y distribución.

Las herramientas. Sin soporte de las herramientas un proceso debe sostenerse por mucho trabajo manual, será difícil
mantener actualizados los modelos y la implementación. El desarrollo iterativo e incremental será más difícil y terminará siendo
inconsistente. Todo esto terminaría disminuyendo la productividad del equipo aumentando los tiempos.
Las herramientas se desarrollan para automatizar los procesos, para incrementar la productividad y la calidad, y para reducir el
tiempo de desarrollo. A medida que se introduce el soporte por herramientas se tiene un proceso más formal. Se pueden incluir
nuevas actividades que no serían prácticas de realizar sin herramientas.

El proceso dirige las herramientas. El proceso especifica la funcionalidad de las herramientas. La existencia del proceso es el
único motivo para necesitar las herramientas.
Un proceso automatizado proporciona un medio eficiente de permitir el trabajo concurrente del conjunto completo de los
trabajadores, y proporciona una forma de comprobar la consistencia de todos los artefactos. Las herramientas deben ser fáciles
de usar, sencilla de comprender y de manejar para los trabajadores.
Debe haber un equilibrio entre proceso y herramientas. El desarrollo del proceso y su soporte por herramientas debe ser
simultáneo. El proceso debe aprender de las herramientas y las herramientas deben soportar un proceso bien pensado.
El objeto del flujo de trabajo de los requisitos
El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto a partir de una
descripción de los requisitos del sistema suficientemente buena como para llegar a un acuerdo entre el cliente y los
desarrolladores sobre que debe y que no debe hacer el sistema.
El cliente debe ser capaz de leer y entender el resultado de la captura de requisitos, para lo cual se debe usar el lenguaje del
cliente para describir esos resultados, cuidándose a la hora de introducir formalidad y estructura, y detalles del funcionamiento
del sistema.

Visión general de la captura de requisitos. Así como cada sistema es diferente, hay diferentes puntos de partida para la
captura de requisitos. Ciertos pasos son factibles en la mayoría de los casos, lo que permite sugerir un flujo de trabajado
arquetípico, que incluye los siguientes pasos que en realidad no se llevan a cabo separadamente:
 Enumerar los requisitos candidatos. Durante la vida del sistema, los clientes, usuarios, analistas y desarrolladores
aparecen con muchas ideas que pueden convertirse en requisitos candidatos, por lo que se los lista. Esa lista crece a
medida que se añaden nuevos elementos y decrece cuando alguno de ellos se convierten en requisitos y se
transforman en artefactos como casos de uso.
 Comprender el contexto del sistema. Un modo de expresar el contexto es mediante el modelo del dominio, que
describe los conceptos importantes del contexto como objetos del dominio, y los enlaza entre sí. Otra manera de
expresar el contexto es el modelo de negocio que se describe como un supraconjunto de un modelo del dominio cuyo
objetivo es describir los procesos para entenderlos. Especifica que procesos de negocio soportará el sistema.
 Capturar requisitos funcionales. Los casos de uso capturan tanto los requisitos funcionales como los no funcionales.
Cada casos de uso representa una forma de usar el sistema y cada usuario necesita de varios casos de uso distintos.
 Capturar requisitos no funcionales. Especifican propiedades del sistema como restricciones del entorno o de la
implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, etc. Un requisito de
rendimiento impone condiciones sobre los requisitos funcionales y afectan solo a ciertos casos de uso.
 Requisitos adicionales. Son requerimientos no funcionales que no pueden asociarse a ningún caso de uso en
particular. Se capturan de forma muy parecida a como se hacía en la especificación de requisitos tradicional, es decir
con una lista de requisitos. Luego se utilizan durante el análisis junto al modelo de casos de uso.

Modelo del dominio

Un modelo del dominio captura los tipos más importantes de objetos (clases) en el contexto del sistema, que representan las
cosas que existen o los eventos que suceden en el entorno del sistema.
Muchas de las clases se pueden obtener de una especificación de requisitos o mediante entrevistas a los expertos del dominio.
Generalmente aparecen en tres formas: Objetos del negocio, que representan cosas que se manipulan en el negocio; Objetos del
mundo real y conceptos de los que el sistema debe hacer un seguimiento; y sucesos que ocurrirán o ya ocurrieron.
El modelo de dominio se describe mediante diagramas de UML, que muestran a los clientes, usuarios, revisores y a otros
desarrolladores las clases del dominio y como se relacionan mediante asociaciones.
Desarrollo. Se realiza habitualmente en reuniones organizadas por los analistas del dominio que usan lenguajes de modelado
para documentar los resultados. Esas reuniones incluyen tanto a los analistas del dominio como a expertos en el modelado. Su
objetivo es comprender y describir las clases más importantes dentro del contexto del sistema. De entre los cientos de clases
candidatas extraídas del dominio solo entre 10 y 50 (para un sistema medio) serán las escogidas para el modelo. Las restantes se
guardan como definiciones en un glosario de términos.
A veces, si el dominio del negocio es muy pequeño, no hará falta un modelo del dominio, ya que con el glosario sería
suficiente. Tanto el glosario como el modelo ayudan al equipo a usar un vocabulario común, lo cuál acelera y facilita el compartir
la información.
El objetivo del modelo del dominio es contribuir a la comprensión del contexto del sistema, y por ende a la comprensión de los
requisitos que se desprenden del contexto, debe contribuir a la comprensión del problema que el sistema resuelve en relación a
su contexto.

Modelo del Negocio

El modelo del negocio es una técnica para comprender los procesos de negocio de la organización. Si no se conoce el
funcionamiento del negocio, entonces se modela el sistema que rodea al sistema de software que se está desarrollando. El
objetivo es identificar los casos de uso del software y las entidades de negocio relevantes que el software debe soportar, de
modo que se puede modelar solo lo necesario para comprender el contexto. El resultado de esta actividad es un modelo del
dominio derivado de la comprensión del funcionamiento del sistema de negocio que lo rodea.
 El modelado del negocio esta soportado por dos tipos de modelos de UML: modelos de casos de uso y modelos de objetos.
Un modelo de casos de uso del negocio describe los procesos de negocio de una empresa en términos de casos de uso del
negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes, respectivamente. Presenta un
sistema desde la perspectiva de su uso y esquematiza como proporciona valor a sus usuarios.
Una entidad del negocio representa algo que lo trabajadores toman, producen o usan en un caso de uso del negocio. Una
unidad de trabajo es un conjunto de esas entidades que conforma un todo reconocible para un usuario final. Ambos se usan
para representar los tipos de conceptos que las clases del dominio. Cada trabajador, entidad del negocio y unidad de trabajo
puede participar en más de casos de uso del negocio.
Desarrollo. Su desarrollo se realiza 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 usen los actores. Ese modelo permite a los modeladores comprender
mejor que valor da 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. A tales objetos se asocian las reglas
del negocio y otras normas. 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.

Etapas del modelado de negocio:

1. Identificar y definir los procesos de negocio según los objetivos de la organización.
2. Definir un caso de uso del negocio para cada proceso del negocio (diagrama de casos de uso del negocio puede
mostrar el contexto y los límites de la organización).
3. Identificar los roles implicadas en los diferentes procesos del negocio (diagrama de roles).
4. Modelar el flujo de tareas asociado a cada proceso de negocio mediante escenarios (diagramas de secuencia) y
diagramas de procesos (diagramas de actividades) que muestran la interacción entre roles para conseguir el
objetivo.
5. Especificar las informaciones y actividades incluidas en cada diagrama de actividades.

Diagramas de casos de usos: Dibujar casos de uso, identificando actores. Muestra las relaciones de dependencia, herencia y
asociación. Se utiliza para modelar los requerimientos (captura requisitos funcionales) y el contexto del sistema (determina la
frontera).
Diagramas de Roles: Identifica los roles, significa que varios usuarios distintos desempeñan ese rol.
Diagrama de Secuencia: Se instancian los roles y se crea un escenario y se muestran las colaboraciones entre objetos.
Diagrama de Proceso: Muestra en detalle la información que necesita.

Hay varias diferencias importantes entre el modelado del negocio y el modelado del dominio que hacen que sea más
recomendable la realización completa del modelo del negocio:
 Las clases del dominio se obtienen mediante el conocimiento de varios expertos del dominio o del conocimiento
asociado con sistemas similares al que se desarrolla. Las entidades se derivan de los clientes del negocio,
identificando los casos de uso del negocio y luego buscando las entidades. Cada entidad debe venir motivada por su
uso en un caso de uso del negocio.
 Las clases del dominio tiene atributos pero normalmente pocas o ninguna operación. Las entidades del negocio son
identificadas junto con los trabajadores que participaran en la realización de los casos de uso que utilizan a las
entidades. Además se identifican como usaran los trabajadores las entidades mediante operaciones que ofrece cada
entidad, las cuales se derivan de los clientes y se las pueden rastrear hasta ellos.
 Los trabajadores identificados se usan como punto de partida para derivar un primer conjunto de actores y casos de
uso para el sistema en desarrollo. Esto permite el rastreo de cada caso de uso.

Captura de requisitos como casos de uso

El esfuerzo en la fase de requisitos es desarrollar un sistema y el uso de los casos de uso es una forma adecuada de crearlo
debido a que los requisitos funcionales se estructuran de forma natural mediante casos de uso y la mayoría de los otros
requisitos no funcionales son específicos de un solo casos de uso y pueden tratarse en el contexto de éste. Los requisitos no
funcionales que son comunes a muchos o a todos los casos de uso se documentan aparte llamándose requisitos adicionales.
Los casos de uso dan un método intuitivo y sistemático para capturar los requisitos funcionales con un énfasis especial en el
valor añadido para cada usuario individual o cada sistema externo. Usar los casos de uso implica pensar quiénes son los usuarios
y qué necesidades u objetivos de la empresa pueden cumplir.
 Los trabajadores y artefactos implicados en la captura de requisitos mediante casos de uso.

Artefactos
Los artefactos fundamentales que se usan en la captura de requisitos son el modelo de casos de uso, que incluye a los casos de
uso y a los actores; aunque también puede haber otros artefactos como prototipos de interfaz de usuario.

Modelo de casos de uso. Permite a los desarrolladores de software y a los clientes llegar a un acuerdo sobre los requisitos, o
sea las condiciones y posibilidades que debe cumplir el sistema; y proporciona la entrada fundamental para el análisis, el diseño
y las pruebas.
Básicamente es un modelo del sistema que contiene actores, casos de uso y sus relaciones. Se puede hacer bastante grande y
difícil de comprender a primera vista, de modo que es necesario un medio para abordarlo en partes más pequeñas. UML
permite presentar el modelo en diagramas que muestran los actores y los casos de uso desde distintos puntos de vista con
diferentes propósitos.

Actor. El modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario, los cuales se representan
mediante uno o más actores. Cada sistema externo que interactúa con el sistema también esta representado por uno o más
actores. Es decir que los actores representan terceros fuera del sistema que colaboran con el, y una vez se los identifica, se
tendrá identificado el entorno externo al sistema.
Los actores suelen corresponderse con trabajadores. Los roles que desempeña un trabajador pueden emplearse para obtener
los roles que cumple el actor del sistema correspondiente. Luego, se dota a cada trabajador con un casos de uso del sistema
para cada uno de sus roles. Tal caso de uso proporciona un valor al actor cuando representa el papel del trabajador.
Un actor juega un papel por cada caso de uso con el que colabora. Cuando un usuario concreto interactúa con el sistema, la
instancia correspondiente del actor está desarrollando ese papel. Cualquier entidad que se ajuste a un actor puede actuar como
una instancia del actor.

Caso de uso. La forma en que un actor usa el sistema se representa con un caso de uso, que son fragmentos de funcionalidad
que el sistema ofrece para aportar un resultado de valor para sus actores. Especifica una secuencia de acciones que el sistema
puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia.
Especifica el comportamiento de instancias de los casos de uso.
Según el vocablo UML, un caso de uso es un clasificador, por lo que contiene operaciones y atributos. Una descripción de un
caso de uso puede incluir diagramas de estados, de actividad, colaboración, y secuencia.
Una instancia de caso de uso es la ejecución de un caso de uso, es decir lo que el sistema lleva a cabo al obedecer a un caso de
uso. Cuando se lleva a cabo una instancia de un caso de uso, ésta interactúa con instancias de actores, y ejecuta una secuencia
de acciones según se especifica en el caso de uso. Tal secuencia puede tener alternativas, y son distintos caminos a lo largo del
caso de uso, pudiendo ser similar a lo siguiente:
1. La instancia del caso de uso se inicia y pasa a estado de comienzo.
2. El caso de uso es invocado por un mensaje externo de un actor.
3. Transita a otro estado mediante una secuencia de acciones, la cual contiene cálculos internos, selección del camino y
mensajes de salida hacia un actor.
4. Queda a la espera de otro mensaje externo.
5. Es invocado por un nuevo mensaje. Esto puede continuar sobre muchos estados hasta que se termina la instancia del
caso de uso.

Generalmente es una instancia de un actor la que invoca a la instancia del caso de uso, pero también puede ser un evento
interno la que la invoque.
 Los atributos de los casos de uso representan los valores que las instancias de casos de uso manipulan durante su ejecución.
Tales valores son locales a la instancia.
Las instancias de casos de uso no interactúan entre sí, más bien lo hacen a través de instancias de actores. Esto se hace para
mantener la simplicidad del modelo de casos de uso, su legibilidad y comprensión.

Descripción de la arquitectura. La descripción de la arquitectura contiene una vista de la arquitectura del modelo de casos de
uso, que representa los casos de uso significativos para la arquitectura. Ésta debería incluir los casos de uso que describan
alguna funcionalidad importante y crítica, o que impliquen algún requisito importante a desarrollarse pronto dentro del ciclo de
vida del software. Esa vista de la arquitectura funciona como entrada cuando se priorizan los casos de uso para su desarrollo
dentro de cada iteración.

Glosario. El glosario se usa para definir términos comunes importantes que el equipo usa al describir el sistema. Esto es muy
útil para alcanzar un consenso entre los desarrolladores relativo a la definición de conceptos y reducir el riesgo de confusiones.
El glosario se suele obtener a partir de un modelo del negocio o del dominio, pero al ser mas informal, es mas fácil de
mantener y mas intuitivo a la hora de ser usado. El glosario debe centrarse más en el sistema que en su contexto.

Prototipo de interfaz de usuario. Ayudan a comprender y especificar las interacciones entre actores humanos y el sistema
durante la captura de requisitos. No solo ayuda a desarrollar una interfaz grafica mejor, sino también a comprender mejor los
casos de uso.

Trabajadores
Es un puesto al cual se puede asignar a una persona. Con cada trabajador hay una descripción de las responsabilidades y
comportamiento esperado del mismo. Cuando se asignan los recursos humanos a un proyecto, un trabajador representa el
conocimiento y las habilidades que alguien necesita para hacerse cargo del trabajo como trabajador del proyecto. Se pueden
identificar tres trabajadores que participan en el modelado de casos de uso, cada uno con su conjunto de operaciones y con
diferentes responsabilidades requeridas:
Analista de sistemas. Responsable del conjunto de requisitos que están modelados en los casos de uso, lo que incluye todos
los requisitos funcionales y no funcionales que son casos de uso específicos. El analista de sistemas es responsable de delimitar
el sistema, hallando los actores y los casos de uso y asegurando que el modelo de casos de uso es completo y consistente. Para
la consistencia, el analista de sistemas puede utilizar un glosario para acordar términos.
Aunque el analista de sistemas es responsable del modelo de casos de uso y de los actores que contiene, no es responsable de
cada caso de uso en particular. Esto es una responsabilidad aparte. El analista también dirige el modelado y coordina la captura
de requisitos.
Hay un analista de sistemas para cada sistema. No obstante está respaldado por un equipo.

Especificador de casos de uso. Habitualmente la captura de requisitos puede no estar dirigida por un solo individuo. El analista
suele estar asistido por otros trabajadores que asumen las responsabilidades de las descripciones detalladas de uno o más casos
de uso. Estos trabajadores son los especificadores de casos de uso.
Cada especificador de casos de uso necesita trabajar estrechamente con los usuarios reales de sus casos de uso.
 Diseñador de interfaz de usuario. Dan forma visual a las interfaces de usuario, lo que puede implicar el desarrollo de
prototipos de interfaces de usuario para algunos casos de uso, habitualmente un prototipo para cada actor. Es conveniente que
de forma a las interfaces de usuario de uno o más actores.

Arquitecto. Participa en el flujo de trabajo de requisitos para describir la vista de la arquitectura del modelo de casos de uso.
Esta vista es una entrada importante para planificar las iteraciones.

Flujo de trabajo

El diagrama muestra qué trabajadores ejecutan qué actividades, cada una situada en el mismo campo que el trabajador que la
ejecuta. Cuando los trabajadores ejecutan las actividades, crean y modifican artefactos. Los flujos de trabajo son una secuencia
de actividades que están ordenados, así que una actividad produce una salida que le sirve de entrada a la siguiente actividad. El
diagrama muestra solo el flujo lógico. En la realidad no es necesario trabajar mediante actividades en secuencia, se puede
trabajar por múltiples vías que producen un resultado final equivalente.
Una actividad puede ser retomada varias veces, y cada una de estas puede acarrear la ejecución de una sola fracción de la
actividad.
Primero el analista ejecuta la actividad encontrar actores y casos de uso para preparar una primera versión del modelo de
casos de uso, con los actores y casos de uso identificados. Debe asegurar que el desarrollo del modelo captura todos los
requisitos que son entradas del flujo de trabajo, es decir, la lista de características y el modelo de dominio/negocio. Entonces el
arquitecto identifica los casos de uso relevantes arquitectónicamente para dar entradas a la priorización de casos de uso que
van a ser desarrollados en la iteración actual. Luego los especificadores de casos de uso describen todos los casos de uso
priorizados, mientras que los diseñadores de interfaz de usuario sugieren las interfaces adecuadas para cada actor basándose en
los casos de uso. Luego el analista reestructura el modelo definiendo generalizaciones entre los casos de uso para hacerlo lo más
comprensible posible.
Los resultados de la primera iteración a través de este flujo de trabajo son una primera versión del modelo de casos de uso, los
casos de uso y cualquier prototipo de interfaz de usuario asociado. Las siguientes iteraciones generaran nuevas versiones,
recordando que los artefactos se completan y mejoran en cada iteración.
Actividades
Encontrar actores y casos de uso. Se identifican los actores y los casos de uso para: delimitar el sistema de su entorno; esbozar
quién y qué (actores) interactuaran con el sistema y que funcionalidad se espera del sistema; y capturar y definir el glosario para
la creación de descripciones detalladas de las funcionalidades del sistema.
La identificación de actores y casos de uso es decisiva para obtener los requisitos y es responsabilidad del analista, aunque no
hará todo el trabajo solo, ya que requiere entradas de un equipo que incluye al cliente, los usuarios, y otros analistas.
Consta de 4 pasos: encontrar los actores, encontrar los casos de uso, describir brevemente los casos de uso, y describir el
modelo de casos de uso completo. Estos pasos no tienen que seguir ningún orden y pueden hacerse simultáneamente.
El resultado de esta actividad es una nueva versión del modelo de casos de uso con actores y casos de uso nuevos o
modificados.

Priorizar casos de uso. Su propósito es dar entradas a la priorización de los casos de uso para determinar cuales son necesarios
para el desarrollo. Los resultados se recogen en la vista de la arquitectura del modelo de casos de uso, la cual es revisada y usada
como entrada al planificar una iteración. La vista de la arquitectura del modelo de casos de uso debe mostrar los casos de uso
significativos arquitectónicamente.

Detallar un caso de uso. El objetivo es describir el flujo de sucesos de cada casos de uso en detalle, es decir, su comienzo, final
e interacciones con actores.
Con el modelo de casos de uso y los diagramas de casos de uso asociados como punto de comienzo, el especificador de u caso
de uso individual puede ya describir cada caso de uso en detalle. Debe trabajar estrechamente con los usuarios reales de los
casos de uso, necesita entrevistarse con usuarios, tomar notas de su comprensión de los casos de uso, discutir propuestas con
ellos, y solicitarles que revisen las descripciones de los casos de uso.
El resultado de la actividad es la descripción detallada de un caso de uso en particular en forma de texto y diagramas.

Prototipar la interfaz de usuario. Su objetivo es construir un prototipo de interfaz de usuario, la cual les permitirá llevar a cabo
los casos de uso de modo eficiente. Esto se hace en varios pasos, comenzando con los casos de uso e intentamos discernir que
se necesita de las interfaces de usuario para habilitar los casos de uso para cada actor. Este es el diseño lógico de la interfaz de
usuario. Luego se crea el diseño físico y se desarrollan prototipos que ilustren como pueden usar el sistema los usuarios para
ejecutar los casos de uso. Mediante la especificación de que se necesita antes de decidir como realizar la interfaz de usuario, se
llegan a comprender las necesidades antes de intentar realizarlas.
El resultado final de esta actividad es un conjunto de esquemas de interfaces de usuario y prototipos de interfaces de usuario
que especifican la apariencia de esas interfaces de cara a los actores más importantes.

Estructurar el modelo de casos de uso. Esto se hace para:

 Extraer descripciones de funcionalidad generales y compartidas que pueden usarse por descripciones más
específicas.
 Extraer descripciones de funcionalidad adicionales u opcionales que pueden extender descripciones mas especificas.

Antes de que tenga lugar esta actividad, el analista ya identificó los actores y los casos de uso, dibujándolos en diagramas, y
explicando el modelo de casos de uso como un todo. Los especificadores de casos de uso desarrollaron una descripción
detallada de cada caso de uso. En este punto el analista de sistemas puede reestructurar el conjunto completo de casos de uso
para hacer que el modelo sea más fácil de entender y de trabajar con él. El analista debe buscar comportamientos compartidos y
extensiones.

Todos los resultados obtenidos son un buen punto de partida para los siguientes flujos de trabajo: análisis, diseño,
implementación, y prueba. Los casos de uso dirigirán el trabajo a lo largo de estos flujos de trabajo iteración por iteración. Po
cada caso de uso del modelo de casos de uso, se identifica una realización de casos de uso correspondiente en las fases de
análisis y diseño y un conjunto de casos de prueba en la fase de pruebas. Entonces, los casos de uso enlazaran directamente los
diferentes flujos de trabajo.

Modelo de análisis
Nos ayuda a refinar los requisitos. Analizar los requisitos en la forma de un modelo de análisis es importante ya que:
  Un modelo de análisis ofrece una especificación más precisa de los requisitos que la que tenemos como resultado de
la captura de requisitos, incluyendo al modelo de casos de uso.
 Un modelo de análisis se describe utilizando el lenguaje de los desarrolladores, y se puede por tanto introducir un
mayor formalismo y ser utilizado para razonar sobre los funcionamientos internos del sistema.
 Un modelo de análisis estructura los requisitos de un modo que facilita su comprensión, su preparación, su
modificación, y en general, su mantenimiento.
 Un modelo de análisis puede considerarse como una primera aproximación al modelo de diseño (aunque es un
modelo por sí mismo), y es por tanto una entrada fundamental cuando se da forma al sistema en el diseño y en la
implementación.

Creación del modelo de análisis a partir de los casos de uso. En él, se describen un conjunto de Clases del Análisis que se
utilizan para realizar una descripción abstracta de la realización de los casos de uso del modelo de casos de uso. Las clases del
análisis luego evolucionan hacia otras clases más detalladas en el Modelo del Diseño. El modelo de análisis crece
incrementalmente a medida que se analizan más y más casos de uso. En cada iteración elegimos un conjunto de casos de uso y
los reflejamos en el modelo de análisis. Construimos el sistema como una estructura de clasificadores (clases del análisis) y
relaciones entre ellas. También describimos las colaboraciones que llevan a cabo los casos de uso, es decir las realizaciones de
los casos de uso.

Tipo de clases

 Entidad: Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos.
Representan la memoria esencial del negocio. Los objetos del negocio (business objects) son normalmente objetos
entidad. Ejemplos de objetos entidad pueden ser empleado, alumno, etc.
 Interfaz: Representan lo objetos técnicos requeridos para vincular la aplicación con el entorno. Representan el vínculo a
través del cual el sistema recibe o suministra datos e información al entorno. Típicamente incluyen interfaces con el
usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones.

 Control: Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de interfaz. Son
normalmente objetos transitorios, como ser un controlador de reportes.
Desarrollo ágil del Software
Los procesos de desarrollo del software rápido se diseñan para producir rápidamente un software útil. El software se
desarrolla como una serie de incrementos, cada uno de los cuales agrega funcionalidades al sistema. Las siguientes son las
características compartidas por los distintos enfoques del desarrollo ágil:
1. La especificación, el diseño y la implementación están entrelazadas. La especificación no es detallada y la
documentación del diseño es mínima o autogenerada por el IDE. El documento de requerimientos de usuario solo
define las características más importantes del sistema.
2. El sistema se desarrolla en diferentes versiones. Los usuarios finales y otros colaboradores intervienen en la
especificación y evaluación de cada versión, proponiendo cambios y nuevos requerimientos a implementar en
versiones posteriores.
3. Las UI de usuario se desarrollan usando un sistema interactivo, que permita que el diseño de la interfaz se realice
rápidamente.
Los métodos agiles son métodos de desarrollo incremental donde los incrementos son mínimos, y las versiones nuevas se
liberan cada dos o tres semanas. Implican un alto involucramiento de los clientes para conseguir una retroalimentación rápida
de los requerimientos. Minimizan la documentación con el uso de comunicación informal.

Métodos Ágiles
En la década de 1980 y a inicios de la siguiente, había una visión difundida sobre cual forma era la mas adecuada para lograr un
mejor software. Usando métodos de análisis y diseño apoyados por herramientas CASE, así como procesos de desarrollo
rigurosos y controlados. Requerían grandes equipos que incluso podían estar geográficamente dispersos, y tardaban mucho en
especificar e implementar el software. Tales enfoques incluyen costos operativos significativos, que se ven recompensados
siempre que el trabajo se realice entre diversas compañías y el sistema sea de gran porte.
Esto no resulta conveniente cuando se aplica a sistemas de negocios pequeños y medianos. Los costos monetarios y de tiempo
no justifican el producto final.
En la década de 1990 el descontento generado por los enfoques existentes condujo a que se propusieran métodos agiles para
enfocar el desarrollo en el software en vez del diseño y la documentación. Los métodos agiles se apoyan universalmente en el
enfoque incremental para la especificación, el desarrollo y la entrega de software. Son adecuados para el desarrollo de
aplicaciones en la que los requerimientos cambian rápidamente durante el proceso de desarrollo. Tienen la intención de
entregar con prontitud el software a los clientes, quienes a cambio propondrán nuevos requerimientos para incluir en
posteriores implementaciones del sistema. Estos métodos simplifican la burocracia y eliminan la documentación que nunca se
empleará.
Los métodos agiles son muy exitosos para ciertos tipos de desarrollos de sistemas:
1. Una compañía de software desarrolla un producto pequeño o mediano para su venta.
2. Diseño de sistemas a la medida dentro de una organización con un claro compromiso del cliente por intervenir en el
proceso de desarrollo y en un ambiente con pocas reglas y restricciones que afecten al software.

Principios de los métodos ágiles.

Participación del cliente. Los clientes deben intervenir estrechamente durante el proceso de desarrollo, ofreciendo y
priorizando nuevos requerimientos del sistema y evaluando las iteraciones del mismo.
Entrega incremental. El desarrollo se realiza en incrementos y es el cliente quien especifica los requerimientos que se van a
incluir en cada iteración.
Personas, no procesos. Deben reconocerse y aprovecharse las habilidades del equipo de desarrollo. Debe permitirse a los
miembros del equipo desarrollar sus propias formas de trabajar sin procesos establecidos.
Adoptar el cambio. Estar siempre preparado para que los requerimientos cambien y saber diseñar el sistema para que se
adapte a dichos cambios.
Mantener la simplicidad. Enfocarse en la simplicidad, tanto en el software a desarrollar como en el proceso de desarrollo.
Siempre que se pueda, trabajar de manera activa para eliminar la complejidad del sistema.
Sin embargo, en la práctica tales principios son difíciles de cumplir. Aunque es importante que el cliente se involucre en el
proceso de desarrollo del software, se debe considerar que es necesario un cliente que desee y pueda pasar tiempo con el
equipo de desarrollo, y que sepa representar a todo el grupo de usuarios. Esto es tan difícil como improbable. Puede ocurrir que
los miembros del equipo no tengan la personalidad necesaria para participar intensamente como lo requieren los métodos
agiles. Cuantos más participantes tenga el proyecto, más difícil será priorizar los cambios. Cuanto más cerca se esté de la fecha
de entrega, será más difícil mantener la simpleza debido a las diferentes presiones que surgen. Debido a la formalidad que
poseen las organizaciones, y que les ha costado años de desarrollo d cultura organizacional, puede que les sea muy dificultoso
cambiar a un esquema informal de comunicación o documentación.
Otro tipo de problema son los contratos. Generalmente el documento de requerimientos del software forma parte del
contrato entre cliente y proveedor. Como la especificación incremental es inherente en los métodos agiles, puede ser difícil
elaborar contratos para este tipo de desarrollo. Por lo tanto los métodos agiles se apoyan en contratos en los que el cliente paga
por el tiempo requerid para el desarrollo del sistema en vez de hacerlo por el desarrollo de un conjunto especifico de
requerimientos. Esto no traerá problemas siempre y cuando todo marche a la perfección.

Manifesto ágil.
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a
terceros. A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación extensiva.
Colaboración con el cliente sobre negociación contractual.
Respuesta ante el cambio sobre seguir un plan.
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Mantenimiento y Evolución.
¿Los sistemas que se desarrollan usando un enfoque ágil se mantienen, a pesar del énfasis en el proceso de desarrollo de
minimizar la documentación formal?
¿Los métodos ágiles pueden usarse con efectividad para evolucionar un sistema como respuesta a requerimientos de cambio
por parte del cliente?
En la práctica, frecuentemente, la documentación se mantiene desactualizada y no refleja con precisión al código del sistema.
Algunos de los metodólogos sugieren que escribir la documentación es una perdida de tiempo y que la clave del éxito está en
producir un código legible de alta calidad. Así es que las prácticas ágiles enfatizan la importancia de escribir un código bien
estructurado y destinar los esfuerzos a mejorar el código. Es por esto que la falta de documentación nunca debe ser un
problema. Sin embargo, la documentación que nunca debe faltar es el documento de requerimientos del sistema. Sin él, es
difícil valorar el efecto de los cambios propuestos al sistema. Llevar una documentación incremental e informal puede hacer que
el mantenimiento del sistema sea muy difícil.

Desarrollo dirigido por un plan y desarrollo ágil.

Tanto el diseño como la implementación sin las actividades centrales de este enfoque. A su vez incorporan otras actividades en
el diseño y la implementación, como la adquisición de requerimientos y pruebas. En los enfoques basados en planificación, se
identifican etapas separadas en el proceso de software con salidas asociadas a cada etapa. Las salidas de una etapa sirven para
planear la etapa siguiente.
En un la iteración ocurre dentro de las actividades con documentos formales usados como medio de comunicación entre
etapas. EN un enfoque ágil, la iteración ocurre a través de las actividades. Los requerimientos y el diseño se desarrollan en
conjunto, no por separado.
Un proceso ágil no está inevitablemente enfocado al código, pudiendo generar cierta documentación. La mayoría de los
proyectos de software incluyen prácticas de los enfoques ágil y basado en un plan. Uno siempre puede plantearse distintas
preguntas en distintos aspectos del desarrollo para poder definir que tan balanceada es esta relación en el proyecto que desea
llevar a cabo.
Programación eXtrema.
Es probablemente el método ágil más conocido y utilizado. Desarrollado por Beck en el año 2000, lleva ese nombre debido a
que lleva al extremo las prácticas reconocidas.

Seleccionar
Desglosar la Planear la
historia de
historia en liberacion
usuario para la
tareas
liberación.

Desarrollar/integr
Evaluar el Liberación ar/poner a
sistema del software prueba el
software
 En la programación extrema, los requerimientos se expresan como escenarios llamados historias de usuario, que se
implementan de modo directo como una serie de tareas. Los programadores trabajan de a pares y antes de escribir el código
desarrollan pruebas para cada tarea. Entre liberaciones del sistema existen lapsos breves.
El desarrollo incremental se apoya en pequeñas y frecuentes liberaciones del sistema. Los requerimientos se fundamentan en
simples historias de cliente o en escenarios que se usan como base para decidir que funcionalidad incluir. La inclusión del cliente
se apoya a través de un enlace continuo entre él y el equipo de desarrollo. El representante del cliente participa activamente,
definiendo las pruebas de aceptación para el sistema. Las personas, no los procesos, se basan en la programación en pares, en la
propiedad colectiva del código del sistema y en un proceso de desarrollo sustentable que no incluya jornadas laborales largas. El
cambio se acepta mediante liberaciones regulares del sistema a los clientes, desarrollo de primera prueba, refactorización para
evitar degeneración del código e integración continua de nueva funcionalidad. La simplicidad se mantiene mediante la
refactorización constante, que mejora la calidad del código, y con el uso de diseños simples que no anticipan innecesariamente
futuros cambios al sistema.
El cliente discute los cambios con el equipo de desarrollo, debatiendo los posibles escenarios. En conjunto, desarrollan una
tarjeta de historia que encapsula las necesidades del cliente. Luego, el equipo de desarrollo implementa dicho escenario en una
liberación futura del software. Las tarjetas de historia son las entradas principales al proceso de planeación XP. Una vez
diseñadas, las descomponen en tareas y se estiman los esfuerzos. En conjunto con el cliente se deciden las prioridades, y luego
se llevan a cabo. Conforme cambian los requerimientos, las historias no desarrolladas se cambian o desechan.
Si durante el desarrollo surgen preguntas que no se pueden responder fácilmente y requieren trabajo adicional para explorar
posibles soluciones, se pueden elaborar prototipos para tratar de entender tanto el problema como la solución. En XP esto se
conoce como spike, o sea un incremento donde no se realiza programación. También suelen ocurrir a la hora de diseñar la
arquitectura o la documentación del sistema.
Unos de los preceptos fundamentales de la ingeniería del software tradicional es que se debe diseñar para cambiar. La
programación extrema desecha esta idea ya que al diseñar para el cambio con frecuencia se desperdicia esfuerzo. Los cambios
anticipados casi nunca se materializan y en realidad pueden hacerse pedidos de cambios opuestos a los anticipados. En XP se
acepta que los cambios sucederán, y cuando ocurran, se reorganizará el software.
Otro de los problemas con el desarrollo incremental es su tendencia a degradar la estructura del software, de modo que los
cambios se vuelven cada vez más difíciles de implementar. XP aborda el problema sugiriendo una continua refactorización del
software. El equipo busca inmediatamente mejoras para realizar al software y las implementa al instante. En principio, el
software debe ser fácil de comprender y de cambiar a medida que se implementan nuevas historias.

Pruebas en XP.
Para evitar problemas de prueba y validación del sistema, XP enfatiza la importancia de la prueba de programa. Su enfoque de
prueba reduce las posibilidades de introducir errores no detectados en la versión actual del sistema. Las características clave de
poner a prueba en XP son:
1. Desarrollo de primera prueba.
2. Desarrollo de pruebas incrementales a partir de escenarios.
3. Involucramiento del usuario en el desarrollo y la validación de pruebas.
4. El uso de marcos de pruebas automatizadas.
El desarrollo de la primera prueba y las pruebas automatizadas por lo general dan por resultado un gran número de pruebas
que se escriben y ejecutan. Sin embargo, esto no conduce a pruebas minuciosas del programa por tres razones:
1. Los programadores prefieren programar que probar, y suelen tomar atajos a la hora de escribir pruebas.
2. Algunas pruebas pueden ser muy difíciles de escribir de forma incremental.
3. Es difícil juzgar la totalidad de un conjunto de pruebas.

Programación en pares.
Los programadores trabajan en la misma estación para desarrollar el software, aunque los mismos pares no siempre
programan juntos. Los pares se crean dinámicamente de modo que todos los miembros del equipo trabajen ente si durante el
proceso de desarrollo.
La programación de a pares tiene ciertas ventajas:
1. Apoya la idea de propiedad y responsabilidad colectiva.
2. Actúa como proceso informal de revisión, ya que al menos dos personas observan cada línea de código, lo cual
aumenta en mucho la taza de detección de errores.
3. Ayuda a refactorizar, ya que todos se benefician de la refactorización del código.
 Los estudios muestran resultados mixtos en cuanto a la efectividad de esta técnica, de modo que es difícil de juzgar si es útil o
no.

Cuatro valores.
Comunicación. Los proyectos de sistemas que requieren actualización constante y un diseño técnico son muy propensos a
errores. Las prácticas como la programación en parejas, estimación de las tareas y el desarrollo de pruebas requieren de una
buena comunicación. Todo tipo de error y problema es más fácil de solucionar si existe interacción entre las partes.
Simpleza. Significa que uno no debe abrumarse por las tareas que se deben realizar, y tener en mente que se debe empezar
por lo más simple, sabiendo que mañana se puede cambiar un poco. La simpleza lleva tiempo y requiere un enfoque claro de as
metas del proyecto.
Retroalimentación. Se relaciona con el concepto de tiempo. Una buena retroalimentación, útil para el desarrollador y el
cliente, puede ocurrir en el marco de tiempo que sea necesario dependiendo de lo que se necesita, quien se comunica y lo que
se hará con dicha retroalimentación. Ayuda a los desarrolladores a hacer los ajustes y permite a los negocios tener una
experiencia a tiempo de lo que el nuevo sistema será.
Valentía. Tomar un decisión basándose en presentimientos cuando se cree tener una forma mas simple y*o rápida de alcanzar
una meta. Es un valor de alto riesgo que anima a la experimentación. Implica confianza mutua entre desarrolladores y clientes.

Cuatro actividades básicas.

Codificar. Es la más obvia y es imposible realizar algo sin ella. El proceso es simple, se piensa, se codifica y se prueba. El código
fuente es la base para la supervivencia del sistema y esencial para el desarrollo.
Probar. Las pruebas automatizadas son muy importantes. XP se apoya en la generación de pruebas escritas para verificar la
codificación, funcionalidad, rendimiento y la conformidad con los objetivos. Las pruebas requieren de actualización constante.
Escuchar. Los desarrolladores deben escuchar de manera activa tanto a sus pares como al cliente. XP depende mucho de la
comunicación informal.
Diseñar. Es una actividad evolutiva, y requiere de su reiteración para ser efectiva. El diseño debe ser simple y flexible.

Cuatro variables de control de recursos.

Se pueden ajustar cuatro recursos para completar el proyecto antes de una fecha límite: tiempo, costo, calidad, alcance. Si se
las incluye adecuadamente en la planeación, habrá un estado de equilibrio entre los recursos y las actividades.

Cuatro prácticas esenciales.

Liberación limitada. Reducir el tiempo entre liberaciones, incluyendo primero las funciones más importantes, y mejorándolo
después.
Semana de trabajo de 40 horas. Trabajar horas extra por más de una semana en un turno es muy malo para la salud del
proyecto y los desarrolladores. Motiva a trabajar intensamente durante esas 40 horas y permite el descanso suficiente para
mantener la creatividad y bajar el stress.
Cliente in situ. Un usuario experto en los aspectos de negocios del proyecto en desarrollo está en el sitio durante el proceso,
escribiendo historias de usuario, comunicando a los miembros del equipo, ayudando a priorizar y equilibrar las necesidades de
largo plazo del negocio y sobre las funcionalidades a incluir.
Programación en parejas.