Analisis de Sistemas

Facultad de Ingeniería de Sistemas, Cómputo y
Telecomunicaciones
Sistema a Distancia
ANÁLISIS DE SISTEMAS
CÉSAR LUZA MONTERO
2010
Análisis de Sistemas - Unidad I César Luza Montero
INTRODUCCIÓN
Las organizaciones están considerando el tema de los Sistemas de Información como factor
clave para lograr competitividad. Se están realizando grandes inversiones para su
construcción e implantación, de manera eficiente, efectiva y con niveles de calidad
pertinentes.
Los sistemas de información, conjunto de componentes software, hardware, base de datos,
procedimientos y personal, proveen la información, requerida por las organizaciones para
apoyar las actividades de toma de decisión y controlar las operaciones del día a día. Esta
información debe transmitirse a todos los niveles de la organización, de manera oportuna y
confiable.
El proceso de construcción e implantación de sistemas de información implica esfuerzo
conjunto de desarrolladores y clientes-usuarios, quienes realizan una serie de actividades,
agrupadas en fases, conocida como “Proceso de desarrollo”, conducente a obtener un
sistema de calidad que satisfaga las necesidades de información de los clientes-usuarios.
En general, las primeras actividades del proceso de desarrollo están relacionadas con el
análisis de sistemas y la especificación de requerimientos del software. El propósito del
análisis de sistemas es definir el papel de cada componente del sistema de información y
asignar al software el ámbito que le corresponde desempeñar. Durante la actividad de
especificación de requerimientos del software, se detalla el ámbito de funcionalidad del
software, de tal manera que cubra la totalidad de necesidades de los usuarios.
La literatura especializada establece que el éxito de un proyecto de desarrollo de sistemas
depende, en gran medida, de realizar bien el análisis de sistemas y especificación de
requerimientos del software; por lo que es de gran relevancia, para la formación de
profesionales del campo de desarrollo de Sistemas de Información, el dominio de métodos,
técnicas y herramientas que permitan afrontar con éxito estas actividades.
Precisamente, este libro tiene el propósito de promover y consolidar, en el estudiante, el uso
de métodos, técnicas y herramientas para el análisis de sistemas y especificación de
requerimientos de software. Se enfatiza en el componente software del sistema de
información, se utiliza la notación del lenguaje de modelado unificado (UML) y se sigue el
proceso de desarrollo unificado (RUP). En otras palabras, para el análisis de sistemas se
desarrolla el flujo de modelado del negocio, y para la especificación de requerimientos, se
sigue el flujo de requerimientos que permitirá capturar sistemáticamente los requerimientos
usando la técnica de casos de uso del UML.
Los contenidos de este libro se han organizado en cinco unidades temáticas. Éstas se
desarrollan en lecciones que incluyen apartados, esquemas y figuras, según cuál sea la
necesidad didáctica. Cada unidad consta también de un conjunto de actividades y de
evaluación orientados a afianzar el aprendizaje del estudiante y a valorar sus logros.
La primera unidad tiene como propósito que el estudiante comprenda y explique la
importancia de los sistemas de información en las organizaciones, definiendo con precisión
los conceptos relacionados a la organización, proceso de negocio, datos, información,
conocimiento y sistemas de información; valorando la importancia de estos conceptos en el
contexto del análisis de sistemas de información.
2 Sistema a Distancia
La segunda unidad comprende los temas relacionados con el proceso de desarrollo de

sistemas de información, estableciendo sus fases y actividades genéricas; muestra los
diversos modelos de proceso de desarrollo y las metodologías más conocidas, y brinda una
introducción al UML y al RUP.
La tercera unidad orienta, al estudiante, en el desarrollo de habilidades para la construcción
de modelos de negocio; los artefactos que se elaboran sirven de base para la determinación
de requerimientos del sistema. Se utiliza notación UML siguiendo las actividades
proporcionadas por el RUP.
La cuarta unidad tiene por finalidad que el estudiante desarrolle habilidades para
representar modelos de dominio, mediante la construcción de diagrama de clases de UML.
De esta manera, complementa los artefactos del modelo de negocios con una
representación de los conceptos o entidades que se manejan en el contexto del negocio o
dominio de la aplicación que cubra las necesidades y requerimientos de los usuarios-
clientes.
La quinta unidad permite que el estudiante consolide habilidades para la especificación de
requerimiento usando el modelo de casos de uso del UML. Se tratan, con precisión, los
conceptos de requerimientos funcionales y no funcionales, y se elaboran, con claridad los
artefactos del modelo de casos de uso: actores, casos de uso, descripción de casos de uso y
diagrama de casos de uso.
En todo el libro, las figuras o tablas que no consignan fuente, corresponden a elaboración
propia. Las figuras o tablas que no consignan número, representa continuación del texto
donde están ubicados.
El autor.
ORIENTACIONES METODOLÓGICAS
La asignatura de Análisis de Sistemas es de formación profesional especializada, de

naturaleza teórica-practica. Tiene como propósito que el estudiante maneje,
adecuadamente, los métodos, técnicas y herramientas para el análisis y especificación de
requerimientos de software como componente de un sistema de información.
Para este fin, se desarrollan las siguientes unidades temáticas: Los Sistemas de Información
en las Organizaciones, El Proceso de desarrollo con RUP y UML, El Modelado del Negocio, El
Modelado de Dominio, y Requerimientos con casos de uso.
Al inicio de cada unidad temática, el estudiante dispone de una serie de preguntas que
permitirá valorar sus logros. Al finalizar la unidad, se brinda un resumen del contenido
temático, una lectura seleccionada de un tema de interés relacionado con el contenido
temático de la unidad, una serie de actividades que el estudiante debe realizar, una
autoevaluación que mide el aprendizaje del estudiante, una serie de direcciones Internet
para exploración online.
Es fundamental, para el proceso de autoaprendizaje, que el estudiante planifique el tiempo y
esfuerzo requerido por cada unidad. Asimismo, mediante Internet, debe trabajar de manera
colaborativa, fomentando el trabajo en equipo y compartiendo información. El docente,
dispondrá de un horario que permita interactuar con los estudiantes para absolver consultas
o dudas, a través de Internet.
En lo que respecta a la evaluación del aprendizaje, al final de cada unidad temática se
dispone de una serie de preguntas de autoevaluación que permite al estudiante medir sus
logros de aprendizaje conceptual. Además, se presenta una serie de casos que el estudiante
desarrollará y que permitirá al docente medir los logros de aprendizaje procedimental.
PRIMERA UNIDAD
LOS SISTEMAS DE INFORMACIÓN EN LAS ORGANIZACIONES
¿Qué es una organización, como se estructuran sus actividades, cuáles son sus niveles?
¿Qué son los procesos de negocios, como se clasifican?
¿Cuál es la diferencia entre dato, información y conocimiento?
¿Qué es un sistema de información, cuáles son sus componentes, como se clasifican?
Lección 1
Organización y procesos de negocios

Los profesionales responsables de automatizar las actividades de una organización deben
comprender los procesos de negocio que ésta realiza a fin de identificar aquellas
actividades manuales que serán reemplazas por sistemas software.
En esta lección se revisa aspectos básicos de una organización y del enfoque basado en
procesos de negocios en la estructura de sus actividades.
1.1 Organización
1.1.1 ¿Qué es una organización?

Según el Diccionario de la Real Academia de la Lengua, una organización es una
asociación de personas reguladas por un conjunto de normas en función de determinados
fines.
Se puede considerar que una organización es un sistema compuesto por un conjunto de
personas, actividades y recursos, distribuidas de alguna forma (generalmente en
departamentos o funciones) con arreglo a ciertas reglas de división del trabajo y
comunicación que interactúan para producir bienes o servicios (Figura 1.1).
Figura 1.1 Componentes de una organización
Reglas
Entradas ACTIVIDADES Bienes/Servicios
Personas/Recursos
1
Fuente: Elaboración propia
Las personas representan el recurso más importante de la organización, juegan distintos

roles o responsabilidades cuando realizan las diversas actividades requeridas para cumplir
los objetivos de la organización.
Las actividades o tareas son las acciones que en conjunto transforman las entradas en
bienes o servicios, se distinguen actividades operativas (realizadas por los obreros o
empleados) y actividades de toma de decisión (realizadas por los gerentes).
Los recursos pueden ser dinero, materiales, maquinaria, infraestructura, tecnología que
sirve de soporte para realizar las actividades.
1
Las figuras siguientes que no consignen fuente, son de elaboración propia
Las reglas están dadas por las políticas, normas y procedimientos que rigen el desarrollo
de las actividades y uso de los recursos.
1.1.2 Estructura organizacional

La estructura organizacional representa la forma en que las personas, actividades y
recursos se organizan según ciertas reglas. Se han establecido diversos modelos o
enfoques para la estructura de una organización; sin embargo, para el propósito de este
texto se pueden considerar dos enfoques: Estructura Funcional y Estructura por Procesos.
Estructura funcional
En la estructura con enfoque funcional las actividades se organizan verticalmente, en
áreas funcionales, de forma altamente jerárquica, con ámbitos de control muy limitados y
rígidos (figura 1.2).
Cada función busca optimizar sus propias tareas, inclusive a costa del rendimiento de
global de la organización. Su foco de análisis es la tarea o función, su objetivo es la
optimización de las tareas, se orienta al interior de la organización, tiene una visión
fragmentada.
Figura 1.2 Estructura funcional
Gerencia
General
Investigación Producción Finanzas Ventas

y
Desarrollo
Estructura por procesos

En la estructura con enfoque por procesos las actividades se organizan de manera
horizontal, facilitando la reunificación de actividades fragmentadas (figura 1.3).
Se percibe las actividades como procesos que rompen las barreras funcionales por medio
de los cuales se producen los productos y servicios, notándose las relaciones con el
cliente. Se busca satisfacer al cliente, considerando el producto y el flujo de trabajo. Su
foco de análisis es el proceso, su objetivo es la mejora de los procesos, se orienta
esencialmente al cliente y tiene una visión global.
Figura 1.3 Organización por procesos
Gerencia
General
Proceso de negocio (Flujo de actividades)
1.1.3 Niveles Organizacionales

Los roles que las personas desempeñan en la organización se pueden agrupar en diversos
niveles organizacionales. Podemos considerar niveles relacionados con la toma de
decisiones, que agrupa a los gerentes, y nivel de operaciones, agrupa a empleados,
obreros, etc., que realizan actividades rutinarias, sin responsabilidad de toma de
decisiones.
Se suele utilizar un modelo de pirámide organizacional para representar los niveles
organizacionales relacionados con la toma de decisiones. En la figura 1.4 se visualiza
cuatro niveles: Estratégico, Administrativo, de Conocimiento y Operativo (Laudon, 2004).
Figura 1.4 Pirámide organizacional
Nivel Estratégico Directores
Nivel Gerentes de
Administrativo Nivel Medio
Nivel de Trabajadores del

Conocimiento Conocimiento
Nivel Operativo Gerentes

Operativos
Fuente: (Adaptado de Laudon, 2004)
En esta pirámide podríamos agregar, debajo de su base, un bloque grande para

representar las actividades operacionales o rutinarias que tienen poca tarea de toma de
decisiones.
Nivel estratégico
En el nivel estratégico, se realizan actividades relacionadas con toma de decisiones de
asuntos estratégicos y tendencias a largo plazo, tanto en la empresa como el entorno
externo; por ejemplo, se tratan asuntos como determinar los productos a elaborar dentro
de cinco años o determinar los niveles de empleo dentro de cinco años. Se puede incluir a
Directores, Gerente General, Gerentes de División.
Nivel administrativo
En el nivel administrativo, se realizan actividades de supervisión, control y toma de
decisiones de aspectos tácticos en el mediano plazo; por ejemplo, se tratan asuntos de
exceso de presupuestos en un periodo o control del rendimiento. Se incluye a los
gerentes de nivel medio, como gerente de áreas: Gerente de Ventas, Gerente de
Recursos Humanos, Gerente de una Agencia o Sucursal.
Nivel de conocimiento
En el nivel de conocimiento, se realizan actividades relacionadas con la investigación y
desarrollo para generar nuevas oportunidades de negocio o controlar el flujo de trabajo
de oficina. Las personas que realizan este tipo de actividades son los trabajadores de
conocimientos. Se incluye a Analistas de Financieros, Expertos en Marketing,
Investigadores.
Nivel operativo
En el nivel operativo, se realizan actividades de seguimiento y control de las tareas
realizadas por el personal operacional, empleados, obreros, quienes realizan
transacciones elementales de la organización como ventas, depósitos en efectivo,
nóminas. Se toman decisiones de corto plazo, por ejemplo, reabastecimiento de stock de
inventarios, otorgar préstamos bancarios, entre otros. Se incluye a los gerentes
operativos: Jefe de Sección de fabricación, Jefe de Cajeros.
Este modelo de pirámide permite, a quienes desarrollan sistemas de información,

visualizar el alcance de información requerido por cada nivel; así, en el nivel de gestión
operativo, la información detallada es necesaria; mientras que, en el nivel estratégico,
conviene proporcionar resúmenes.
1.2 Procesos de negocio
1.2.1 ¿Qué es un proceso de negocio?

“Un proceso de negocio es un orden especifico de actividades a través del tiempo y lugar,
con un comienzo y un fin, inputs y outputs: una estructura para la acción” (Davenport,
1996).
“Un proceso de negocio es un conjunto de actividades que toman uno o más tipos de
inputs y crean un output que es de valor para un cliente” (Hammer, 1993).
Mediante los procesos de negocio se organizan y coordinan las actividades en función al
cliente elaborando productos y servicios de valor.
Muchos procesos de negocios trascienden las áreas funcionales tradicionales; por
ejemplo, en muchas compañías el proceso de ejecución de un pedido requiere la
cooperación entre la función de ventas, contabilidad y manufactura. En ventas se recibe
el pedido y se inicia su trámite; en contabilidad se verifica el crédito y se factura el
pedido) y en manufactura se produce y envía el pedido (figura 1.5).
Figura 1.5 Proceso de ejecución de un pedido
VENTAS CONTABILIDAD MANUFACTURA
Recibir Verificar Producir

. pedido Crédito pedido
Iniciar Facturar Enviar

tramite pedido pedido
Algunos ejemplos de proceso de negocios son: Proceso de Admisión, Proceso de

Matrícula, Proceso de Contratación de Personal, Proceso de Formulación del Plan Anual
de Desarrollo.
1.2.2 Clases de procesos de negocio

Los procesos de negocios se pueden clasificar en: Principales, de Soporte y de Gestión.
Los Procesos Principales o Sustantivos son aquellos que están ligados directamente con
la realización del producto y la prestación del servicio para el Cliente. Son los procesos de
línea, hacen realidad la misión de la organización.
Ejemplos:
VENDER PRODUCTO GESTIONAR PEDIDO
Mediantes estos dos procesos el cliente interactúa con la organización. El proceso Vender
Producto permite al cliente recibir de la organización el producto requerido. El proceso
Gestionar Pedido permite al cliente solicitar el pedido de bienes /servicios requerido.
Los Procesos de Soporte son aquellos que proporcionan apoyo a los procesos principales
o sustantivos. Usualmente están relacionados con la gestión de recursos.
Ejemplos:
DESARRROLLO DE INVESTIGACIÓN DE
PERSONAL MERCADO
En estos dos procesos no hay agente externo, cliente, proveedor, etc., que interactúe con
la organización. Son procesos que apoyan a los procesos principales.
Los Procesos de Gestión son aquellos que están vinculados al ámbito de las
responsabilidades de la dirección. Se relacionan con actividades de planificación y control.
Ejemplos:
PLANIFICACIÓN REVISIÓN
Estos dos procesos son realizados por los niveles gerenciales, no hay interacción entre
algún agente externo con la organización. Son proceso que refleja tareas gerenciales..
1.2.3 ¿Cómo se describe un proceso de negocio?

Un proceso de negocio se puede describir de manera textual o gráfica. Se han propuestos
diversos formatos para describir un proceso, pero los ítems básicos incluyen: la entrada,
las actividades, quién o quiénes realizan las actividades, los recursos que se utilizan, las
reglas que rigen el flujo de actividades y la salida.
A continuación se muestra un ejemplo textual de descripción de un proceso de Registro
de Pedido para una empresa de fabricación:
1. El cliente envía una orden de pedido, por teléfono, por fax o por correo, al Dpto.
Comercial. El pedido debe incluir la fecha de solicitud, datos del cliente y
productos solicitados.
2. Un empleado del departamento comercial revisa el pedido (completándolo, si es
necesario), y comienza su procesamiento enviándolo al jefe técnico, que está
encargado de su análisis.
3. El jefe técnico analiza la viabilidad de cada producto del pedido por separado. Si
el producto pedido está en el catálogo, su fabricación es aceptada. En caso
contrario, es considerado un producto especial, y el jefe técnico estudia su
producción: Si es viable, la fabricación del producto especial es aceptada; Si no es
viable, el producto especial no será fabricado.
4. Una vez estudiado el pedido completo, el jefe técnico informa al departamento
comercial de la aceptación o rechazo de cada producto pedido; Si todos los
productos de un pedido han sido aceptados, se crea una orden de trabajo para
cada producto, a partir de una plantilla de fabricación (la estándar si el producto
estaba catalogado, o una nueva, específicamente diseñada para el producto, si
éste no estaba en el catálogo). Cada orden de trabajo es enviada al jefe de
producción, y queda pendiente de su lanzamiento.
5. El comercial comunica al cliente el resultado final del análisis de su pedido.
En la figura 1.6, se describe el proceso de Registrar Pedido de manera grafica, usando la

técnica de Diagrama de Actividades de UML y modelado con la herramienta Rational Rose
de IBM.
Figura 1.6 Descripción Grafica del Proceso Registro de Pedido
Existen diversas técnicas y herramientas para describir, de manera gráfica, un proceso de

negocio. Dependerá del profesional responsable, elegir aquella que se adapte mejor a las
necesidades de la organización a la que brinda sus servicios.
Lección 2
Introducción a los Sistemas de información

Las organizaciones requieren de información para apoyar las actividades de toma de
decisión y controlar las operaciones del día a día. La información se transmite en todos los
niveles de la organización a través de los sistemas de información.
En esta lección se brinda, a modo introductorio, los conceptos relacionados a los sistemas
de información, los componentes y tipos de sistemas de información.
2.1 Concepto de Dato, Información y Conocimiento

Desde años atrás se reconoce que la información es un recurso valioso en las
organizaciones. Los gerentes, empleados y todos aquellos que integran una organización
la utilizan. Con frecuencia los empleados usan datos detallados para sus actividades de
tipo operacional, los gerentes manejan información sumaria para tomar decisiones.
En muchas ocasiones se utilizan los términos datos e información como sinónimos, pero
son términos que tiene distinto significado.
Datos
Los datos son registros de hechos observables no procesados que no tienen significado.
En la figura 2.1 se aprecia algunos ejemplos de datos.
Figura 2.1 Datos
Zapatos 1200
José Quispe
456789 S/100
Información
La información es un conjunto de hechos agrupados para algún propósito en particular.
Son datos procesados que tienen significado.
Por ejemplo, agrupando y organizando los datos mostrados en la figura 2.1:Zapato, José
Quispe, 456789, 1200 y S/100, tenemos que se refieren a una factura (figura 2.2).
Figura 2.2 Información
Comercial “Vende Barato S.A”
Factura Nro 456789
Cliente: José Quispe
Detalle
Nro. Producto Cantidad Precio
01 Zapatos 1200 S/100
Se puede afirmar que los datos son la materia prima para producir información. Entonces,
en las organizaciones se procesan datos para obtener información.
En base a la información se adquiere conocimiento. Actualmente, se considera al
conocimiento como el recurso más preciado, por ello se habla de gestión del
conocimiento en las organizaciones.
Conocimiento
El conocimiento es la información conectada a decisiones, procesos y acciones capaces de
aplicar esa información.
Para explicar la diferencia entre información y conocimiento, considere una receta de
preparación de una torta. Las instrucciones e ingredientes indicados en la receta vendrían
a ser información, al igual que el libro de receta es información. Esta información se
convierte en conocimiento cuando, una persona elabora una torta siguiendo las
instrucciones y utilizando los ingredientes indicados en la receta. En otras palabras,
cuando la información se lleva a la acción se convierte en conocimiento.
Desde una perspectiva de niveles se puede considerar que "El nivel más bajo de los
hechos conocidos son los datos. Los datos no tienen un significado intrínseco. Deben ser
ordenados, agrupados, analizados e interpretados. Cuando los datos son procesados de
esta manera, se convierten en información. La información tiene una esencia y un
propósito. Cuando la información es utilizada y puesta en el contexto o marco de
referencia de una persona, se transforma en conocimiento. El conocimiento es la
combinación de información, contexto y experiencia”. (Harris, 1996).
La figura 2.3 trata de explicar las diferencias entre datos, información y conocimiento
desde una perspectiva de niveles.
Figura 2.3 Dato, Información Y conocimiento
CONOCIMIENTO
Información conectada a
decisiones, procesos y
INFORMACIÓN acciones capacea de aplicar
esa información
Hechos agrupados
para un propósito
DATO
Colección de hechos
Fuente: (Adaptado de Harris, 1996)
2.2 ¿Qué es Sistema de información?

“Un sistema de información es un conjunto de componentes interrelacionados que
permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de
decisiones y el control en una institución. Los sistemas de información pueden contener
datos acerca de personas, lugares y cosas importantes dentro de la institución y el
entorno que la rodea” (Laudon, 2004).
Un sistema de información recibe y procesa los datos de manera eficaz, sin errores,
evalúa la calidad de los datos de entrada, almacena los datos de modo que estén
disponibles cuando el usuario lo crea conveniente, elimina la información poco útil
evitando redundancias, brinda seguridad evitando la perdida de información o la
intrusión de personal no autorizado o agentes externo a la compañía y genera
información de salida, en el momento oportuno, y útil para los usuarios, ayudando en el
proceso de toma de decisiones.
Se suele confundir el concepto de sistemas de información con la computadora y los
programas informáticos. Una organización puede adquirir nuevas computadoras, instalar
redes, desarrollar páginas Web, etc., pero ello no significa que se implemente sistema de
información. El significado del término sistema de información abarca más que los
elementos computacionales, incluye, también, el modo de organizar dichos elementos, la
forma de usarlos y los roles que desempeñan las personas en su explotación para obtener
la información que apoye las actividades de la empresa.
2.3 Componentes de un Sistema de información

Se puede considerar que los componentes de un sistema de información son: el
hardware, el software, la base de datos, los procedimientos y el personal. Estos
elementos interactúan entre sí para lograr el objetivo del: proveer información para
apoyar a la empresa (figura 2.4).
Figura 2.4 Componentes de un Sistema de Información
Hardware
Personas
Software
Sistema de
Información
Procedimiento Dato/información
El hardware corresponde al elemento físico del sistema de información incluye las redes
computacionales y de telecomunicaciones. El software corresponde a los programas de
aplicación. La base de datos representa el almacén de los datos e información requerida
por la empresa, las personas puede ser los usuarios finales y el personal de tecnología de
información. Los procedimientos establecen las reglas y normas del uso del sistema de
información
2.4 Tipos de sistemas de información

De acuerdo con los intereses, especialidades y niveles en una organización, se pueden
identificar los siguientes tipos de sistemas de información (Laudon, 2006): de nivel
operativo, de nivel del conocimiento, de nivel administrativo y de nivel estratégico.
Los sistemas de información de nivel operativo apoyan a los gerentes operativos en el
control de actividades y transacciones elementales de la organización, por ejemplo:
ventas, ingresos, depósitos en efectivo, nomina, decisiones de crédito y flujo de
materiales en una fábrica. Responden a preguntas de rutina y siguen el flujo de
transacciones a través de la organización. Por ejemplo, ¿Cuántas partes hay en
inventario? ¿Qué pasó con el pago del señor Gutiérrez?
Los sistemas de información de nivel del conocimiento apoyan a los trabajadores del
conocimiento de datos de una organización. Su objetivo es ayudar a las empresas
comerciales a integrar el nuevo conocimiento en los negocios y ayudar a la organización a
controlar el flujo del trabajo de oficina. Estos tipos de sistemas están entre las
aplicaciones de crecimiento más rápidas en los negocios actuales.
Los sistemas de información de nivel administrativo apoyan a las actividades de
supervisión, control, toma de decisiones, y administrativas de los gerentes de nivel
medio. La pregunta principal que plantean estos sistemas es: ¿Van bien las cosas? Por lo
general, este tipo de sistemas proporcionan informes periódicos más que información
instantánea de operaciones. Apoyan a las decisiones no rutinarias y tienden a enfocarse
en decisiones menos estructuradas para las cuales los requisitos de información no
siempre son claros.
Los sistemas de información de nivel estratégico apoyan a los directores a enfrentar y
resolver aspectos estratégicos y tendencias a largo plazo, tanto en la empresa como en el
entorno externo. Su función principal es compaginar los cambios del entorno externo con
la capacidad organizacional existente.
Según la función que desempeñan o el tipo de usuario final del mismo, se pueden
clasificar en (Laudon, 2006): Sistema de procesamiento de transacciones, Sistemas de
información gerencia, Sistema de soporte a la toma de decisiones, Sistemas de
información ejecutiva, Sistemas de automatización de oficinas, Sistemas expertos y
Sistemas de Planificación de Recursos Empresariales.
Sistema de procesamiento de transacciones (Transaction Process System- TPS) son
aquellos que permiten gestionar la información referente a las transacciones producidas
en una empresa u organización.
Sistema de información gerencial (Management Information System - MIS) son aquellos
orientados a solucionar problemas empresariales en general.
Sistema de soporte a decisiones (Decision Suport System - DSS) son aquellas que sirve de
herramienta para realizar el análisis de las diferentes variables de negocio con la finalidad
de apoyar el proceso de toma de decisiones.
Sistema de información ejecutiva (Executive Information System - EIS) son aquellas
herramientas orientadas a usuarios de nivel gerencial, que permite monitorizar el estado
de las variables de un área o unidad de la empresa a partir de información interna y
externa a la misma.
Sistema de automatización de oficinas (Office Automation System - OAS) son

aplicaciones destinadas a ayudar al trabajo diario del administrativo de una empresa u
organización.
Sistemas expertos (Expert System - SE) emulan el comportamiento de un experto en un
dominio concreto.
Los Sistemas de Planificación de Recursos Empresariales (Enterprise Resource Planning -
ERP) integran la información y los procesos de una organización en un solo sistema.
Todos estos sistemas de información a su vez podrían analizarse según las diferentes
áreas de la empresa: ventas y mercadotecnia, manufactura y producción, finanzas,
contabilidad y recursos humanos. Para cada una de estas áreas existe un conjunto
especifico de aplicaciones informáticas y equipos, los cuales han de estar coordinados
entre si. Si ello no se realizara, una empresa tendrá problemas de intercambio de datos
entre las diferentes áreas, aparecerá la existencia de redundancia de datos y la existencia
de ineficiencias e incrementos de costes de comunicación.
Resumen
Organización y Procesos de Negocio

• Una organización es un sistema compuesto por un conjunto de personas, actividades y recursos,
distribuidas de alguna forma con arreglo a ciertas reglas de división del trabajo y comunicación que
interactúan para producir bienes o servicios.
• La estructura organizacional representa la forma en que las personas, actividades y recursos se
organizan. Puede ser de dos tipos; funcional o de procesos.
• Funcional: las actividades se organizan verticalmente, en áreas funcionales, de forma
altamente jerárquica, con ámbitos de controles muy limitados y rígidos.
• Por procesos: las actividades se organizan de manera horizontal, facilitando la reunificación de
actividades fragmentadas.
• Los roles que las personas desempeñan en la organización se pueden agrupar en niveles
organizacionales: Operacionales y Gerenciales. Los Gerenciales pueden ser: estratégico,
administrativo, de conocimiento y de control operativo.
• Nivel Operacional: Actividades rutinarias. No hay toma de decisión. Empleados, obreros.
• Niveles Gerenciales: Actividades caracterizadas por toma de decisiones.
o Nivel estratégico, asuntos estratégicos y tendencias a largo plazo.
o Nivel administrativo, aspectos tácticos en el mediano plazo.
o Nivel de conocimiento, investigación y desarrollo
o Nivel operativo, control de tareas del personal operacional. Decisiones de corto plazo.
• Un proceso de negocio es un conjunto de actividades que toman uno o más tipos de inputs y crean
un output que es de valor para un cliente.
• Clases de Procesos de Negocios
• Principales: ligados con realización del producto / lprestación del servicio para el Cliente.
• De Soporte: apoyan los procesos principales. Relacionados con la gestión de recursos.
• De Gestión: vinculados a la dirección. Se relacionan con actividades de planificación y
control.
• Un proceso de negocio se puede describir en forma grafica o textual.
Introducción a los sistemas de información

• Los datos son registros de hechos observables no procesados que no tienen significado.
• La información es un conjunto de hechos agrupados para algún propósito en particular. Son datos
procesados que tienen significado.
• El conocimiento es la información conectada a decisiones, procesos y acciones capaces de aplicar
esa información.
• Un sistema de información es un conjunto de componentes interrelacionados que permiten
capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el
control en una institución.
• Los Componentes de un sistema de información son: Hardware, Software, Base de datos, Personas
(usuarios finales y personal de T.I.) y Procedimientos.
• Tipos de sistema de información
• De acuerdo a intereses: Sistemas de información de nivel operativo, Sistema de información
de nivel de conocimientos, Sistema de información de nivel administrativo y Sistema de
información de nivel estratégico
• Según función que desempeña: Sistema de procesamiento de transacciones (TPS), Sistema de
información Gerencial (MIS), Sistema de soporte a las decisiones (DSS), Sistema de
información ejecutiva (EIS), Sistema de automatización de oficinas (OAS), Sistema Experto (SE),
Sistema de planificación de recursos empresariales (ERP).
Lectura
BACKUS: INTEGRANDO PROVEEDORES A LA CADENA DE SUMINISTROS (*)
La necesidad de automatizar procesos y generar valor en las actividades de las diferentes áreas de
una organización se ha convertido en una tendencia cada vez más frecuente en las empresas, ello
gracias a los beneficios que ofrece el e-business.
Es así, que Unión de Cervecerías Peruanas Backus y Johnston dando un paso adelante con la
tecnología, viene implementando mejoras en todos sus procesos para operar con estándares de
clase mundial que tiendan a la satisfacción de sus clientes y la integración de sus proveedores
como socios de negocios.
Rafael Trucíos, Gerente de Planning y Marketing de ebiz Latin America, empresa especialista en
soluciones e-business y operador tecnológico de Backus, conversó con César Campodónico,
Gerente de Desarrollo de Proveedores con la finalidad de dar a conocer la forma de trabajo con
proveedores y los beneficios obtenidos al implementar ebiz en Backus.
“Desde que empezamos el proyecto e-commerce de ebiz en el año 2004, hemos implementado
nuevas soluciones integradas a nuestro sistema transaccional con la finalidad de agilizar nuestro
proceso de abastecimiento y dar un mejor servicio a nuestros clientes internos, automatizando no
solo nuestros procesos Logísticos, sino también Contables”, comentó César Campodónico.
“En la actualidad, Backus ha implementado el módulo de Peticiones de Oferta, Envío de
cotizaciones, Envío de órdenes de compra, Visualización de estado de comprobantes de pago,
Impresión de comprobantes de retención y próximamente el módulo de Registro de facturas para
proveedores”, agregó.
Por otro lado, Campodónico comentó cuales fueron las características principales del servicio
ofrecido por ebiz que permitió tomar una decisión al momento de hacer la integración en SAP:
• Customización a las exigencias según modelo de negocio de Backus.
• Flexibilidad en la adecuación de las necesidades de Backus.
• Tiempos de implementación adecuados.
• Servicio al cliente BACKUS y sus proveedores.
• Consultas y Soporte a través de Help Desk.
• Apoyo al seguimiento en Call Center.
• Costo vs Beneficio (Inversión vs Ahorro)
• Sinergias del mercado – Comunidad Empresarial electrónica
• Confiabilidad, Confidencialidad y Seguridad (Hosting operaciones en IBM)
Así mismo, dentro de los beneficios obtenidos por la relación Proveedor / Cliente se comentó la
reducción de costos por negociación consolidada, la funcionalidad personalizada a las prácticas
del negocio, el mejor control de la operación logística y el incremento de nivel de servicio al
cliente interno, todo ello orientado a cumplir los objetivos que persigue el modelo de gestión de
cadena de suministro.
Finalmente, resaltó que el uso de herramientas b2b forma parte de los Lineamientos básicos para
proveedores dando a conocer el compromiso de Backus en el establecimiento de una relación
fuerte, perdurable y de lealtad con sus proveedores.
(*) Fuente: ebiz News

Fecha de `publicacion: 7/6/2009 11:00:00
Link: http://www.generaccion.com/noticias/online/detalle.php?id=24447
Actividades
1 Identifique una organización, de cualquier tipo o tamaño, y realice la descripción de uno de
sus procesos de negocio de tipo principal.
2 Busque y explique algunas técnicas de modelado de procesos de negocio y elabore un
ejemplo de cada una.
Autoevaluación
Contestar las siguientes preguntas:
1 Una organización es un sistema compuesto por
2 La estructura con enfoque de proceso se caracteriza por:
3 Los niveles de gestión de una organización son:
4 Un proceso de negocio es:
5 Los tipos de procesos de negocios son:
6 La diferencia entre dato e información es
7 La diferencia entre información y conocimiento es
8 Un sistema de información es:
9 Los componentes de un sistema de información son:
10 Los tipos de sistemas de información son:
Exploración on-line
• Portal del CIO,
Portal de la Compañía IBM sobre transformación de procesos de negocio para incrementar la
flexibilidad empresarial a través de SOA; contiene documentos, videos y casos de estudio.
https://www-935.ibm.com/services/es/cio/flexible/
• OMG, Object Management Group / Business Process Management Initiative
Pagina de la Organización Internacional OMG (Object Management Group) que contiene
información de estándares de modelado de procesos de negocios.
http://www.bpmn.org/
Referencias bibliográficas
1 Davenport, Thomas (1996). Innovación de Procesos: Reingeniería del trabajo a través de la
tecnología de la información. España. Díaz Santos.
2 Hammer, Michel y James Champy (1993), Reengineering the Corporation: A Manifesto for
Business Revolution. USA. Collins Business Essentials.
3 Harris, David (1996). Creating a Knowledge Centric Information Technology Environment. USA.
Editorial Harris Training & Consulting Services Inc.
4 Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Información Gerencial. 8ª Ed. México
D.F. Pearson Educación.
5 Laudon, Jane y Kenneth (2006). Sistemas de información gerencial, Administración de la
empresa digital. México D.F. Pearson Educación- Prentice Hall.
Análisis de Sistemas - Unidad II César Luza Montero
SEGUNDA UNIDAD
EL PROCESO DE DESARROLLO, RUP Y UML
¿Qué es un proceso de desarrollo, cuales son sus fases y actividades genéricas?

¿Cuáles son los modelos de proceso de desarrollo?
¿Qué es metodología, técnica y herramienta de desarrollo?
¿Qué es el UML y cuales son sus elementos, relaciones y diagramas?
¿Qué es el RUP y cuales sus fases y flujos, artefactos, trabajadores, actividades?
Lección 3
Proceso de desarrollo de sistemas de información

La construcción de un sistema de información implica un esfuerzo conjunto de
profesionales de tecnología de información y líderes de la organización. Este esfuerzo
implica realizar una serie de actividades conducentes a obtener un sistema de calidad.
Esta serie de actividades se conoce como proceso de desarrollo que deviene en
metodologías de desarrollo.
Esta lección ayuda comprender las características de un proceso de desarrollo, los
modelos que existen y los conceptos relacionados a las metodologías de desarrollo.
3.1 Proceso de desarrollo, una visión genérica
3.1.1 ¿Qué es un proceso de desarrollo?

El proceso de desarrollo es una guía acerca de las actividades y tareas necesarias para
construir un sistema de información. En el contexto de software, programas de aplicación
o aplicaciones informáticas, Pressman (2002) considera al Proceso como un marco de
trabajo que define las tareas a realizar para desarrollar software de alta calidad.
Se han establecido diversos modelos de proceso de desarrollo de sistemas de
información, con actividades y tareas específicas; pero se puede establecer una serie de
actividades comunes que llamaremos visión genérica con las siguientes fases (Pressman,
2002): Definición, Desarrollo y Evolución.
Figura 3.1 Fases del proceso de desarrollo: Visión genérica
Definición
• Análisis del
Sistema Desarrollo
• Requerimientos
• Planificación
• Diseño
• Codificación Evolución
• Prueba
• Corrección
• Adaptación
• Mejora
Fuente: (Pressman, 2002)
3.1.2 Fase de Definición

El propósito de la fase de Definición es identificar las necesidades o requerimientos del
cliente/usuario, tales como: la información que debe ser proporcionada, la funcionalidad
y rendimiento que se desea, las interfaces que deben establecerse, las restricciones de
diseño que existen y los criterios de validación que se necesitan para definir un sistema
correcto.
En esta fase, se realizan las siguientes actividades: Análisis del Sistema, Requerimientos
del Software y Planificación del Proyecto.
Análisis del sistema. Define el papel de cada elemento del sistema de información,
asignando finalmente al software el papel que va a desempeñar.
Requerimientos del software. El ámbito establecido para el software proporciona la
dirección a seguir, pero antes de comenzar a trabajar es necesario disponer de una
información mas detallada del ámbito de la funcionalidad del software.
Planificación del proyecto de software. Una vez establecido el ámbito del software, se
analizan los riesgos, se asignan los recursos, se estiman los costes, se definen las tareas y
se planifica el trabajo.
3.1.3 Fase de Desarrollo

El propósito de la fase de Desarrollo es determinar cómo han de diseñarse las estructuras
de datos y la arquitectura del software, cómo han de implementarse los detalles
procedimentales, cómo ha de traducirse el diseño a un lenguaje de programación y cómo
ha de realizarse la prueba.
En general se aplicarán tres pasos concretos: Diseño del Software, Codificación y Pruebas
del software.
Diseño de software. El diseño traduce los requisitos de software a un conjunto de
representaciones (algunas gráficas y otras tabulares o basadas en lenguajes) que
describen las estructuras de bases de datos, la arquitectura, el procedimiento algorítmico
y las características de la interfaz.
Codificación. Las representaciones del diseño deberán ser traducidas a un lenguaje
artificial (un lenguaje de programación convencional o un lenguaje no procedimental
T4G), dando como resultado unas instrucciones ejecutables en la computadora.
Prueba del software. Una vez que el software ha sido implementado en una forma
ejecutable por la maquina, debe ser probado para descubrir los defectos que puedan
existir, en la función, en la lógica y en la implementación.
3.1.4 Fase de Evolución

La fase de Evolución, también llamada fase de mantenimiento, se centra en los cambios
que van asociados a la corrección de errores, a las adaptaciones requeridas por la
evolución del entorno del software y a las modificaciones debidas a los cambios de
requisitos del usuario dirigidos a reforzar o ampliar el sistema.
La fase de mantenimiento vuelve a aplicar las fases de definición y de desarrollo, pero en
el contexto del software ya existente.
Se encuentran tres tipos de cambio: Corrección, Adaptación y Mejora.
Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es
muy probable que el cliente descubra defectos en el software. El mantenimiento
correctivo cambia el software para corregir los defectos.
Adaptación. Con el paso del tiempo es probable que cambie el entorno original (sistemas
operativos, equipos periféricos, etc.) para los que se desarrollo el software. El
mantenimiento adaptativo consiste en modificar el software para acomodarlo a los
cambios de su entorno externo.
Mejora. Conforme utilice el software, el usuario puede descubrir funciones adicionales

que podrían interesar que estuvieran incorporadas en el software. El mantenimiento
perfectivo amplia el software más allá de sus requisitos funcionales originales.
3.2 Modelos de Proceso de desarrollo de software

La implementación de un proceso de software puede variar de acuerdo a la naturaleza:
del proyecto, de la aplicación de los métodos a seguir y de las herramientas a utilizar. Se
han establecido diversos modelos, conocidos como “ciclo de vida del software”.
En esencia, los modelos de ciclo de vida del software permiten determinar las fases
productivas de un proyecto, los objetivos de cada fase productiva, los productos
obtenidos en cada una de estas fases, así como sus características y los roles que se
desempeñan en cada fase.
Los modelos de proceso de software se puede clasificar en: Secuencial, Iterativos y
Evolutivos.
El modelo secuencial se caracteriza porque las actividades del desarrollo progresan de
manera secuencial. Una actividad no puede iniciar si no ha terminado la anterior.
Los modelos iterativos se caracterizan porque las actividades se repiten de manera
cíclica. Entre los modelos iterativos podemos mencionar: Construcción de prototipos y
Desarrollo Rápido de Aplicaciones.
Los modelos evolutivos se caracterizan porque son iterativos y en cada iteración se
agrega nueva funcionalidad (versiones) al sistema. Se ha dado gran impulso a estos
modelos pues la realidad demuestra que los requisitos suelen cambiar a medida que el
desarrollo avanza, haciendo que no se puedan cumplir con las metas fijadas inicialmente
respecto de un producto final completo; otras veces, si bien se han captado claramente
los requisitos centrales todavía falta definir los detalles. Entre los modelos evolutivos
podemos mencionar el modelo incremental y el modelo espiral.
3.2.1 Modelo Lineal Secuencial

Este modelo, también conocido como Modelo de Ciclo de Vida Clásico o Modelo en
Cascada, es el más antiguo y ha sido el más usado. Tal como su nombre lo indica,
progresa en forma secuencial desde una primera fase de Análisis de Sistemas, avanzando
a través de Requerimientos, el Diseño, la Codificación, la Prueba y el Mantenimiento
(figura 3.2) .
Figura 3.2 Modelo lineal secuencial
Análisis de Requerimientos Diseño Codificación Prueba Mantenimiento

Sistemas de software
En este modelo, los requerimientos deben estar claramente identificados desde el inicio.
Sin embargo, la realidad señala que raramente el cliente expone todos los requerimientos
desde el inicio. En consecuencia, pueden surgir cambios durante el desarrollo lo que
afectará la planificación establecida.
Cuando se trata de proyectos grandes, el cliente debe tener paciencia porque no verá una
versión operativa del sistema sino hasta que el proyecto esté muy avanzado. Además,
esto hace que no exista una validación por parte del cliente hasta muy tarde. Si en estas
etapas finales se detectase un error grave las consecuencias son desastrosas.
Aunque este modelo puede tener sus debilidades, siempre es mejor que un enfoque
hecho al azar y puede resultar bueno cuando se trate de un proyecto donde todos los
requerimientos están claramente definidos desde el comienzo.
3.2.2 Modelo Construcción de Prototipos

Muchas veces, en los proyectos de desarrollo, no todos los requisitos están claros desde
el inicio; en esta situación puede resultar conveniente aplicar el Modelo de Construcción
de Prototipos.
En este modelo el ciclo comienza con la captura de requerimientos del cliente por parte
del desarrollador. Luego, el desarrollador construye un prototipo de “diseño rápido”
concentrado en las interfaces de entrada y salida; que se constituye en la primera versión.
Este prototipo es evaluado por el cliente y sirve para refinar los requerimientos. Se inicia
nuevamente el ciclo, conocido como iteración (figura 3.3).
Lo ideal es que este prototipo sirva sólo para identificar los requisitos y una vez que esto
se logró se lo deseche; generalmente, estos prototipos, si son operativos (working
prototype) suelen ser muy lentos o muy grandes o torpes o las tres cosas a la vez. Lo ideal
es, ahora, construir una versión rediseñada en la que estos problemas no estén
presentes.
Figura 3.3 Modelo Construcción de prototipos
Fuente: (Adaptado de Pressman, 2002)
En este modelo, cuando el cliente observa el prototipo operativo, cree que es la versión
final del sistema, sin entender que se trata de solo un prototipo y que el producto no está
terminado.
Por la presión de hacer que el prototipo funcione rápidamente, el desarrollador puede
elegir, inadecuadamente, el sistema operativo o el lenguaje de programación; incluso,
puede usar un algoritmo incorrecto. Después de algún tiempo, puede familiarizarse con
estas elecciones y olvidarse las razones por las cuales son inadecuadas, dejándolas luego
como una parte integral del sistema.
Aunque pueden surgir estos problemas, éste es un modelo útil a la hora de construir un
sistema donde no se tiene claros los requisitos inicialmente. La clave está en establecer
claramente, al principio, las reglas de juego con el cliente y llegado el momento, no ceder
a la presión de éste para conservarlo como producto final.
3.2.3 Modelo Desarrollo Rápido de Aplicaciones (DRA)

El Modelo de Desarrollo Rápido de Aplicaciones (DRA), Rapid Application Development
(RAD), es un modelo lineal secuencial con un ciclo extremadamente corto. La rapidez se
logra gracias al reúso de componentes, al empleo de Técnicas de Cuarta Generación, y a
la posibilidad de dividir el sistema en módulos o subsistemas, que pueden asignarse a
equipos, independientes, que trabaja en paralelo; al finalizar el trabajo de los equipos, los
módulos se integran en un solo producto.
Cuando se utiliza para aplicaciones de sistemas de información, el enfoque DRA
comprende las siguientes fases: modelo de negocio, modelo de datos, modelo de
procesos, generación de aplicaciones, prueba y entrega (figura 3.4.).
Modelo de Negocio: en esta fase se trata de responder a las siguientes preguntas: ¿qué
información maneja el proceso de negocio?, ¿qué información se genera?, ¿quién la
genera?, ¿a dónde va esa información?, ¿quién la procesa?
Modelo de Datos: a partir del estudio del flujo de información en la fase anterior, se
construye un modelo de datos que muestra los objetos, atributos y relaciones entre
dichos objetos.
Modelo de Procesos: en esta fase se construye un modelo de procesos donde se
muestran las transformaciones necesarias sobre los objetos del modelo de datos a los
efectos de lograr la funcionalidad deseada.
Generación de Aplicaciones: en esta fase se genera la aplicación con el empleo de
técnicas de cuarta generación, además de re-usar componentes existentes (cuando es
posible) y la creación de componentes reutilizables (cuando es necesario).
Prueba y Entrega: Dado que enfatiza la reutilización de componentes, los cuales ya han
sido probados, el tiempo de prueba se ve reducido. Sin embargo se deben probar todos
los componentes nuevos y las interfaces entre módulos.
Figura 3.4 Modelo DRA
Fuente: (Pressman, 2002)
En este modelo, cuando el proyecto es grande, se requiere un gran número de personas

para formar equipos paralelos suficientes.
Requiere de un alto compromiso por parte de clientes y desarrolladores en lo que al
tiempo se refiere. Si esto falla, el proyecto fracasa.
No todos los tipos de aplicaciones son aptos para aplicar este modelo. Por ejemplo, no
son aptos aquellos sistemas que no se pueden modularizar, tampoco funciona bien para
aquellos donde existe un bajo reuso de componentes, ya que nuevos deben ser
desarrollados y probados.
No es apropiado cuando existen riesgos tecnológicos altos. Por ejemplo, cuando se hace
uso de una nueva tecnología, o cuando el software nuevo requiere de una alta
interoperabilidad con otros ya existentes.
3.2.4 Modelo Incremental

En el Modelo Incremental, se aplica, repetidamente, el modelo Lineal Secuencial. Cada
secuencia lineal entrega una versión operativa, llamada incremento. El primer incremento
entrega la funcionalidad correspondiente a los requerimientos básicos, el siguiente
agrega nueva funcionalidad a la anterior y así, sucesivamente, hasta obtener el producto
final (Figura 3.5).
Por ejemplo, para un editor de textos, en el primer incremento podríamos entregar
funcionando la gestión de archivos y la producción de documentos, en el segundo
incremento las funciones más sofisticadas relacionadas con la edición y en el tercer
incremento la revisión ortográfica.
Al finalizar cada incremento, el cliente recibe una versión operativa del producto y lo
evalúa. Como resultado de su utilización y evaluación, se desarrolla un plan para el
siguiente incremento. Este plan contempla la modificación del producto central para
cumplir mejor con las necesidades del cliente y además para agregar nueva funcionalidad.
Figura 3.5 Modelo Incremental
Fuente: (adaptado de Pressman, 2002)
Este modelo es particularmente útil cuando no se está seguro de poder cumplir con los
plazos de tiempo debido a falta de personal de desarrollo, o cuando se tenga una fecha
imposible de cambiar, ya que en todos los casos, el cliente se queda con una versión
operativa del producto.
3.2.5 Modelo Espiral

El Modelo en Espiral es un modelo iterativo que proporciona en cada iteración una
versión evolutiva (incremento) del producto.
Durante las primeras iteraciones la versión incremental podría ser un prototipo o un
modelo en papel. Durante las últimas iteraciones se producen versiones cada vez más
completas del software.
El modelo divide las actividades en regiones, generalmente entre tres y seis. En la figura
3.6, se observa un modelo espiral que contiene seis regiones: Comunicación con el
Cliente, Planificación (se definen recursos y tiempo), Análisis de Riesgos (se evalúan
riesgos técnicos y de gestión), Ingeniería (se construyen modelos de la aplicación a
desarrollar), Construcción y Entrega (se construye, prueba, instala y proporciona soporte
al usuario), Evaluación del Cliente.
El proceso comienza desde el centro, girando en el sentido de las agujas del reloj. En la
figura 3.6, el primer circuito, en gris más oscuro alrededor del espiral, podría resultar en
el desarrollo de una especificación del producto (pueden ocurrir múltiples iteraciones
dentro de un circuito); luego, circuitos sucesivos podrían ser usadas para desarrollar un
prototipo y progresivamente versiones mas sofisticadas del software.
Figura 3.6 Modelo Espiral
Fuente: (adaptado de Pressman, 2002)

A diferencia del modelo lineal secuencial que termina cuando se entrega el software, el
modelo en espiral puede ser adaptado para ser aplicado a un proyecto que se encuentre
en cualquier punto del ciclo de desarrollo.
Cada cubo en la figura 3.6 representa un punto de entrada para un tipo diferente de
proyecto. Podemos arrancar desde el cubo de más adentro para el caso de un proyecto
de desarrollo de conceptos hasta que el desarrollo del modelo conceptual haya finalizado.
Si el concepto va a ser desarrollado en un producto real, el proceso avanza hasta el
próximo cubo, y así sucesivamente para los distintos tipos de proyectos. De esta forma, el
proceso puede permanecer parado por un tiempo, pero siempre que un cambio ocurre, el
proceso reinicia desde el punto de entrada apropiado (por ejemplo, proyecto de mejora
del producto).
3.3 Metodologías
Asociado al concepto de proceso de desarrollo de sistemas de información, software, o
aplicaciones informáticas, está el concepto de Metodología de Desarrollo.
Una Metodología es el conjunto de procedimientos, técnicas, herramientas, y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software (Pressman, 2005).
Una metodología representa el camino a seguir para desarrollar software o aplicaciones
informáticas de una manera sistemática, consiste de un conjunto de fases subdivididas en
etapas, actividades y tareas.
Una tarea es una actividad elemental siguiendo algún procedimiento. El procedimiento es
la definición de la forma de ejecutar la tarea. La técnica es la herramienta utilizada para
aplicar un procedimiento. Se pueden utilizar una o varias. Una herramienta es el soporte
software que apoya la aplicación de una técnica. Un producto es el resultado de cada
fase, etapa o actividad de una metodología.
Se han establecido diversas metodologías para el desarrollo de sistemas de información,
algunas de las mas citadas son: RUP, MÉTRICA V3, Merisse, SSADM V4, MDSI.
3.3.1 RUP
Rational Unified Process, de la compañía IBM, es una plataforma de proceso de desarrollo
de software configurable que entrega mejores prácticas comprobadas y una arquitectura
configurable. Permite seleccionar y desplegar solamente los componentes de proceso
que usted necesita para cada etapa de su proyecto.
El RUP es un proceso de desarrollo de software y junto con UML (Lenguaje Unificado de
Modelado), constituye la metodología estándar más utilizada para el análisis,
implementación y documentación de sistemas orientados a objetos.
Link: http://www-01.ibm.com/software/pe/rational/rup.shtml
3.3.2 MÉTRICA V3
MÉTRICA, versión 3, Metodología de Planificación, Desarrollo y Mantenimiento de
Sistemas de Información, del Consejo Superior de Administración Electrónica del
Ministerio de la Presidencia del Gobierno de España, ofrece a las Organizaciones un
instrumento útil para la sistematización de las actividades del proceso de desarrollo
dentro del marco que permite alcanzar los siguientes objetivos:
• Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la
Organización mediante la definición de un marco estratégico para el desarrollo de los
mismos.
• Dotar a la Organización de productos software que satisfagan las necesidades de los
usuarios dando una mayor importancia al análisis de requisitos.
• Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la
Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a
los cambios y teniendo en cuenta la reutilización en la medida de lo posible.
• Facilitar la comunicación y entendimiento entre los distintos participantes en la
producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta
su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
• Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

Link: http://www.csae.map.es/csi/metrica3/index.html
3.3.3 Merisse
Merise es un método integrado de análisis, concepción y gestión de proyectos,
desarrollado en Francia, que provee un marco metodológico y un lenguaje común
riguroso para los desarrollos informáticos.
Es una metodología de modelado de propósito general en el ámbito del desarrollo de
sistemas de información, ingeniería de software y gestión de proyectos. Fue introducido
en la década de 1980, desarrollado y perfeccionado hasta el punto en que las
organizaciones no gubernamentales francesas, comerciales e industriales más grandes la
han adoptado como metodología estándar.
Merise separa el tratamiento de datos y de procesos, donde la vista de datos se modela
en tres fases: conceptual, lógico y físico. Del mismo modo, la vista de proceso pasa a
través de tres etapas: conceptual, organizacional y operacional. Estas etapas en el
modelado de proceso son paralelas con las etapas del ciclo de vida: planificación
estratégica, el estudio preliminar, un estudio detallado, desarrollo, implementación y
mantenimiento.
Link: http://merise.developpez.com/
3.3.4 SSADM V4
El Método de análisis y diseño estructurado de sistemas (SSADM Structured Systems
Analysis and Design Method (SSADM) es un enfoque de sistemas para el análisis de
sistemas de información; fue producido por Central Computer and Telecommunications
Agency (nahora Office of Government Commerce), una oficina gubernamental de Reino
Unido relacionada con el uso de tecnología en el gobierno, a partir de 1980.
Las tres técnicas más importantes que se utilizan en SSADM son: Modelado lógico de
Datos, Modelado de flujo de datos y Modelado de comportamiento de entidades.
Desde 1981 SSADM se ha perfeccionado y la versión 4 fue lanzado en 1990. SSADM es un
estándar abierto, es decir, que esta disponible gratuitamente para su en la industria y
muchas empresas ofrecen servicios de apoyo, formación y herramientas CASE para ello.
3.3.5 MDSI
La metodología MDSI Versión 2.0, es una herramienta desarrollada en base a la
metodología de Métrica 3 del Ministerio de Administración Pública de España (MAP) y
RUP (Rational Unified Process), han sido revisados y adaptados para su aplicación en las
entidades integrantes del Sistema Nacional de Informática por la Oficina Nacional de
Gobierno Electrónico e Informática – ONGEI de la Presidencia del Consejo de Ministros -
PCM. Es un instrumento útil para la sistematización de las actividades que dan soporte al
ciclo de vida del software. Incluye: Modelamiento del Negocio, Modelamiento de
Requerimientos, Modelamiento de Tecnología, Construcción, Pruebas e Implantación del
Sistema de Información
Lección 4
Introducción al UML
4.1 ¿Qué es el UML?
UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje,
basado en una notación gráfica, que permite: especificar, construir, visualizar y
documentar los elementos de un sistema software, así como para modelar los procesos
de negocios u otros sistemas no software (Jacobson, 2006).
Puede ser utilizado por cualquier metodología de desarrollo orientada a objetos. Este
lenguaje es el resultado de la unificación de los métodos de modelado orientados a
objetos de: Grady Booch, Jim Rumbaugh, Ivar Jacobson.
Un lenguaje de modelado permite expresar los distintos modelos (artefactos) que se
producen en el proceso de desarrollo de software.
4.2 Artefacto, Modelo y Diagrama

Artefacto
Un artefacto representa la información que es utilizada o producida durante un proceso
de desarrollo de software. Ejemplo: documento de especificación de requisitos, un
modelo, un programa.
Modelo
Un modelo es una representación abstracta de una especificación, un diseño o un sistema
desde un punto de vista particular. Representa uno o más diagramas. Ejemplos: modelo
de casos de uso, modelo de negocio.
Diagrama
Un diagrama es una representación gráfica de una colección de elementos del modelo.
Ejemplos: diagrama de casos de uso, diagrama de clases.
4.3 Elementos en UML

Los elementos del UML se clasifican en: estructurales, de comportamiento, de agrupación
y de anotación.
Elementos Estructurales
Los elementos estructurales representan la parte estática del sistema. Se incluyen (figura
4.1): Clase, Interfaz, nodo, caso de uso, interfaz, clase activa, componente, cadena de
responsabilidad.
Clase Figura 4.1 Elementos estructurales del UML
Nodo
Colaboración Caso de uso
Componente
Interfaz
La Clase representa un conjunto de objetos que comparten los mismos atributos,

operaciones, relaciones y semántica.
La Interfaz representa la definición un conjunto de especificaciones de operaciones
La Colaboración representa una iteración, es una sociedad de roles y otros elementos que
colaboran cooperativamente
El Caso de Uso representa una funcionalidad del sistema, es un conjunto de secuencias de
acciones que se ejecutan con el objetivo de lograr un resultado de interés para un grupo
de usuarios en particular.
El Componente representa es empaquetamiento físico de diferentes elementos lógicos
como clases, interfaces, y colaboraciones.
El Nodo representa a un elemento físico del sistema, es decir un recurso computacional.
Elementos de comportamiento
Los elementos de comportamiento representan la parte dinámica del sistema, es decir el
comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados.
Estado
Interacción
Mensaje
La Interacción representa un Conjunto de mensajes intercambiados entre objetos.

El Estado Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto
esta esperando alguna operación, recibe cierto tipo de estímulos y especifica la secuencia
de estado por las que pasa un objeto.
Elementos de agrupación
Los elementos de agrupación representan la parte organizativa del sistema. Incluye:
Paquete.
Paquete
El Paquete es el mecanismo de propósito general para organizar elementos.
Elementos de anotación
Los elementos de anotación representan la parte explicativa del sistema. Son
comentarios. Incluye: la nota
La Nota sirve para hacer comentarios a un conjunto de elementos.
4.4 Relaciones en UML

Las relaciones del UML representan los vínculos entre dos elementos del modelo. Incluye:
dependencia, asociación, generalización y realización.
Dependencia
Representa una relación semántica entre dos elementos, tal que un cambio en uno de
ellos (el independiente) puede afectar al otro (el dependiente).
Asociación
Representa una relación estructural que describe un conjunto de links, siendo un link una
conexión entre objetos.
Generalización
Representa una relación de generalización/especialización en la que el elemento
especializado (descendiente) se construye sobre la especificación del elemento
generalizado (ancestro)
Realización
Representa una relación semántica en la que un clasificador, tal como una interfaz o un
caso de uso, especifica un “contrato” que otro clasificador, tal como una clase o una
colaboración, garantiza llevar a cabo.
4.5 Diagramas en UML

La versión 2.0 del UML (Booch, 2006) considera 13 diagramas (figura 4.2), divididos en
Diagramas dinámicos y estáticos.
Figura 4.2 diagramas del UML
Fuente: (Adaptado de Jacobson, 2006)
El Diagrama de Clases, muestra un conjunto de clases, interfaces, colaboraciones y sus

relaciones.
El Diagrama de objetos, muestra una instantánea de un conjunto de objetos y sus
relaciones.
El Diagrama de componentes, muestra la organización y dependencias entre un conjunto
de componentes conocida como vista de implementación de un sistema. Están
relacionados a Diagramas de clases en donde un componente se Corresponde con una o
más clases interfaces o colaboraciones.
El Diagrama de despliegue, muestra los enlaces de comunicación física entre elementos
de hardware y las relaciones entre máquinas físicas y procesos (qué se ejecuta y dónde).
El Diagrama de estructura compuesta, muestra la estructura interna (incluyendo partes y
conectores) de un clasificador o una colaboración estructurada.
El Diagrama de paquetes, muestra la descomposición del modelo en unidades de
organización y sus dependencias.
El Diagrama de casos de uso, muestra un conjunto de casos de uso y actores y sus
relaciones.
El Diagrama de secuencia, es un diagrama de interacción que muestra los objetos y
actores que participan en una colaboración poniendo el énfasis en el ordenamiento en el
tiempo de los mensajes.
El Diagrama de colaboración, es un diagrama de Interacción que pone el énfasis en la
organización estructural de los objetos o roles que envían y reciben mensajes.
El Diagrama de estados, muestra un autómata que consiste de estados, transiciones,
eventos y actividades.
El Diagrama de actividades, muestra la estructura de un proceso u otro cálculo como el
flujo de control y datos paso a paso en el cálculo.
El Diagrama cronológico, es un diagrama de interacción que muestra tiempos a lo largo
de diferentes objetos o roles, y no secuencias relativas de mensajes.
El Diagrama de interacciones general, es un híbrido de diagramas de actividad y de
secuencia.
Lección 5
Introducción al RUP
5.1 ¿Qué es el RUP?
El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de
desarrollo de software, es una forma disciplinada de asignar tareas y responsabilidades
en una empresa de desarrollo, es decir define quién hace qué, cuándo y cómo (Jacobson,
2000).
Es un marco de trabajo genérico que puede especializarse. Es iterativo e incremental.
5.2 Elementos
5.2.1 Trabajador (Worker)

Es un rol que debe ser realizada por una persona o equipo. Un “worker” o rol define el
comportamiento y responsabilidades de un miembro específico (o equipo específico).
Una misma persona puede llevar a cabo diversos roles. Algunos ejemplos de rol son Líder
de Proyecto, Analista de sistemas, programador.
5.2.2 Actividad
Es una unidad de trabajo que debe ser ejecutada. Una actividad es la más pequeña pieza
de trabajo que es relevante. No es razonable hacer actividades en forma parcial. Dividir el
trabajo de esta manera hace más fácil controlar el avance del proyecto. Es mejor saber
que hay 3 actividades completas de 5, que saber que llevamos el 60% de una actividad.
Ejemplos de actividades son Planificar una Iteración, Revisar el Diseño, Capturar
requisitos.
5.2.3 Artefacto
Es una pieza de información que es producida, modificada o usada en un proceso de
desarrollo de software. Un artefacto es algo que se produce e el curso del desarrollo de
un producto de software. Incluye el código fuente, los modelos, documentos y otros
productos del ciclo de vida. UML define la notación para representar la mayor parte de
los artefactos.
5.2.4 Modelo
Cada Trabajador, necesita una perspectiva del Sistema. El Artefacto más común para
representar una perspectiva es el Modelo. Los principales modelos de RUP son: Modelo
del negocio, modelo de casos de uso, modelo de diseño, modelo de implementación,
modelo de prueba.
El Modelo de Negocios es el modelo de los procesos de negocio y su medioambiente. Es
usado para generar requerimientos de los sistemas de información que lo soportan.
El Modelo de Casos de Uso es un modelo acerca de lo que el sistema debe hacer y su
medioambiente.
El Modelo de Diseño es un modelo de objetos que describen la realización de los Casos de

Uso. Sirve como una abstracción del Modelo de Implementación y su código fuente.
El Modelo de Implementación es un conjunto de componentes y subsistemas que los
contienen.
El Modelo de Test abarca todos los casos de test y procedimientos requeridos para probar
el sistema.
5.2.5 Flujos de trabajo (Workflow)

Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso.
Define una lista de actividades, trabajadores y artefactos.
El RUP trabaja a través de modelos. Se requieren muchos modelos para describir el
sistema durante su evolución. Cada uno de los Workflows produce modelos, que se van
desarrollando incrementalmente durante las iteraciones (figura 5.1)
Figura 5.1 Flujos y modelos.
Fuente: (Jacobson, 2000)
5.3 Fases
El RUP es un modelo de proceso del software dividido en cuatro fases: Inicio. Elaboración,
Construcción y Transición (Figura 5.2). Estas fases están mucho más relacionadas con el
funcionamiento de la organización que con aspectos técnicos de la implementación
5.3.1 Fase de Inicio

Su objetivo es el de establecer un caso de negocio para el sistema. Se deben identificar
todas las entidades externas (personas y sistemas) que interactuarán con el sistema y
definir estas interacciones. Esta información se utiliza entonces para evaluar la aportación
que el sistema hace al negocio. Si esta aportación es de poca importancia se puede
cancelar el proyecto después de esta fase.
5.3.2 Fase de Elaboración

Los objetivos de esta fase son: Comprender el dominio del problema, Establecer un marco
de trabajo arquitectónico para el sistema, Desarrollar el plan del proyecto, Identificar los
riesgos clave del proyecto.
Al finalizar esta fase, se obtienen: Un modelo de los requerimientos del sistema (casos de
uso UML), Una descripción arquitectónica, Un plan de desarrollo del software,
5.3.3 Fase de Construcción

Comprende fundamentalmente: El diseño del sistema, La implementación, Las pruebas.
Durante esta fase se desarrollan e integran las partes del sistema.
Al finalizar esta fase, se obtienen: Un sistema software funcional, La documentación
correspondiente a éste.
5.3.4 Fase de Transición

Se ocupa de mover el sistema desde la comunidad de desarrollo a la comunidad del
usuario. También de hacer trabajar el software en un entorno real. Esta fase es
comúnmente ignorada en la mayoría delos modelos de proceso de software, aún cuando
es muy importante y pude implicar altos costos.
Al finalizar esta fase, se obtiene: Un sistema de software documentado adecuadamente y
que funcione correctamente en su entorno operativo
5.4 Flujos
La perspectiva estática del RUP se centra en las actividades que tienen lugar durante el
proceso de desarrollo. Éstas se denominan flujos de trabajo en la descripción del RUP
(Figura 5.2).
Existen seis flujos de trabajo del proceso:
Modelado de negocio
Requerimientos
Análisis y diseño
Implementación
Pruebas
Implantación
Existen tres flujos de trabajo de soporte
Administración de cambios y configuración
Administración del proyecto
Entorno
Figura 5.2 Estructura del RUP, fases y flujos.
Fuente: (Jacobson, 2000)
Resumen
• Proceso de desarrollo de sistemas de información
• Un proceso de desarrollo es una guía acerca de las actividades y tareas necesarias para construir un
sistema de información. Es un marco de trabajo que define las tareas a realizar para desarrollar
software de alta calidad.
• Las fases genéricas de un proceso de desarrollo son: Definición, Desarrollo y Evolución.
• La fase de definición se centra en el “que”. Su propósito es identificar las necesidades o
requerimientos del cliente/usuario. Sus actividades son: Análisis del sistema, Requerimientos
de software, y Planificación del proyecto de software.
• La fase de desarrollo se centra en el “cómo”. Su propósito es descubrir cómo han de diseñarse
las estructuras de datos y la arquitectura del software, etc. Se realizan tres pasos concretos:
Diseño del Software, Codificación y Pruebas del software.
• La fase de evolución, también llamada fase de mantenimiento, se centra en el “cambio” que
va asociado a la Corrección, a la Adaptación y Mejora del software.
• Los modelos de proceso de desarrollo de software se clasifican en
• Modelo secuencial, se caracteriza porque las actividades del desarrollo progresan de manera
secuencial, una actividad no puede inicia sino a terminado la anterior.
• Modelos iterativos, se caracterizan porque las actividades se repiten de manera cíclica. Entre
los modelos iterativos podemos mencionar: Construcción de prototipos y Desarrollo Rápido de
Aplicaciones.
• Modelos evolutivos, se caracterizan porque son iterativos y en cada iteración se agrega nueva
funcionalidad (versiones) al sistema. Se puede mencionar al modelo incremental y al modelo
espiral.
• Una metodología representa el camino a seguir para desarrollar software o aplicaciones
informáticas de una manera sistemática, consiste de un conjunto de fases subdivididas en etapas,
actividades y tareas.
• Una tarea es una actividad elemental siguiendo algún procedimiento.
• El procedimiento es la definición de la forma de ejecutar la tarea.
• La técnica es la herramienta utilizada para aplicar un procedimiento; se pueden utilizar una o
varias.
• Una herramienta es el soporte software que apoya la aplicación de una técnica.
• Un producto es el resultado de cada fase, etapa o actividad de una metodología
• Introducción a UML
• UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado en una
notación gráfica, que permite: especificar, construir, visualizar y documentar los elementos de un
sistema software, así como para modelar los procesos de negocios u otros sistemas no software
• Un artefacto representa la información que es utilizada o producida durante un proceso de
desarrollo de software. Ejemplo: documento de especificación de requisitos, un modelo, un
programa.
• Un modelo es una representación abstracta de una especificación, un diseño o un sistema
desde un punto de vista particular. Representa uno o más diagramas. Ejemplos: modelo de
casos de uso, modelo de negocio.
• Un diagrama es una representación gráfica de una colección de elementos del modelo.
Ejemplos: diagrama de casos de uso, diagrama de clases.
• Los elementos del UML se clasifican en: estructurales, de comportamiento, de agrupación y de
anotación.
• Los elementos estructurales representan la parte estática del sistema. Se incluyen (figura 4.1):
Clase, Interfaz, nodo, caso de uso, interfaz, clase activa, componente, cadena de
responsabilidad.
• Los elementos de comportamiento representan la parte dinámica del sistema, es decir el
comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados.
• Los elementos de agrupación representan la parte organizativa del sistema. Incluye: Paquete.
• Los elementos de anotación representan la parte explicativa del sistema. Son comentarios.
Incluye: la nota
• Las relaciones en UML representan los vínculos entre dos elementos del modelo. Incluye:
dependencia, asociación, generalización y realización.
• La dependencia representa una relación semántica entre dos elementos, tal que un cambio en
uno de ellos (el independiente) puede afectar al otro (el dependiente, clase activa,
componente, cadena de responsabilidad
• La asociación representa una relación estructural que describe un conjunto de links, siendo un
link una conexión entre objetos.
• La generalización representa una relación de generalización/especialización en la que el
elemento especializado (descendiente) se construye sobre la especificación del elemento
generalizado (ancestro)
• La realización representa una relación semántica en la que un clasificador, tal como una
interfaz o un caso de uso, especifica un “contrato” que otro clasificador, tal como una clase o
una colaboración, garantiza llevar a cabo.
• Los diagramas en UML, version2.0, son 13, divididos en diagramas estáticos y dinámicos.
• Los diagramas estáticos son: diagrama de clases, diagrama de objetos, diagrama de
componentes, diagrama de despliegue, diagrama de paquetes y diagrama de estructura.
• Los diagramas dinámicos son: diagrama de casos de uso, diagrama de secuencia, diagrama de
colaboración, diagrama de estado, diagrama de actividades, diagrama cronológico, diagrama
de interacciones.
• Introducción a RUP
• El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de
software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de
desarrollo, es decir define quién hace qué, cuándo y cómo
• Elementos del RUP

• Un trabajador es un rol que debe ser realizada por una persona o equipo
• Una actividad es una unidad de trabajo que debe ser ejecutada
• Un artefacto es una pieza de información que es producida, modificada o usada en un proceso
de desarrollo de software
• Un modelo es una representación de alguna perspectiva del sistema
• Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso, define
una lista de actividades, trabajadores y artefactos.
• Las fases del RUP son; Inicio, Elaboración, Construcción y Transición.
Lectura
Técnicas de cuarta generación (*)
El término técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de
software que tienen algo en común: todas facilitan al ingeniero del software la especificación de
algunas características del software a alto nivel. Luego, la herramienta genera automáticamente
el código fuente basándose en la especificación del técnico. Cada vez parece más evidente que
cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el
programa. El paradigma T4G para la ingeniería del software se orienta hacia la posibilidad de
especificar el software usando formas de lenguaje especializado o notaciones gráficas que
describa el problema que hay que resolver en términos que los entienda el cliente. Actualmente,
un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o
algunas de las siguientes herramientas: lenguajes no procedimentales de consulta a bases de
datos, generación de informes, manejo de datos, interacción y definición de pantallas, generación
de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo, y generación
automatizada de HTML y lenguajes similares utilizados para la creación de sitios web usando
herramientas de software avanzado. Inicialmente, muchas de estas herramientas estaban
disponibles, pero sólo para ámbitos de aplicación muy específicos, pero actualmente los entornos
T4G se han extendido a todas las categorías de aplicaciones del software.
Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. Idealmente, el
cliente describe los requisitos, que son, a continuación, traducidos directamente a un prototipo
operativo. Sin embargo, en la práctica no se puede hacer eso. El cliente puede que no esté seguro
de lo que necesita; puede ser ambiguo en la especificación de hechos que le son conocidos, y
puede que no sea capaz o no esté dispuesto a especificar la información en la forma en que
puede aceptar una herramienta T4G. Por esta razón, el diálogo cliente-desarrollador descrito por
los otros paradigmas sigue siendo una parte esencial del enfoque T4G.
Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de requisitos
al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G) o
un modelo comprimido de red de iconos gráficos. Sin embargo, es necesario un mayor esfuerzo
para desarrollar una estrategia de diseño para el sistema, incluso si se utiliza un L4G. El uso de
T4G sin diseño (para grandes proyectos) causará las mismas dificultades (poca calidad,
mantenimiento pobre, mala aceptación por el cliente) que se encuentran cuando se desarrolla
software mediante los enfoques convencionales.
La implementación mediante L4G permite, al que desarrolla el software, centrarse en la
representación de los resultados deseados, que es lo que se traduce automáticamente en un
código fuente que produce dichos resultados. Obviamente, debe existir una estructura de datos
con información relevante y a la que el L4G pueda acceder rápidamente.
Para transformar una implementación T4G en un producto, el que lo desarrolla debe dirigir una
prueba completa, desarrollar con sentido una documentación y ejecutar el resto de las
actividades de integración que son también requeridas por otros paradigmas de ingeniería del
software. Además, el software desarrollado con T4G debe ser construido de forma que facilite la
realización del mantenimiento de forma expeditiva.
Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e inconvenientes.
Los defensores aducen reducciones drásticas en el tiempo de desarrollo del software y una
mejora significativa en la productividad de la gente que construye el software. Los detractores
aducen que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de
programación, que el código fuente producido por tales herramientas es «ineficiente» y que el
mantenimiento de grandes sistemas de software desarrollados mediante T4G es cuestionable.
Hay algún mérito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado
actual de los enfoques de T4G:
1. El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación.
Junto con las herramientas de ingeniería de software asistida por computadora (CASE) y
los generadores de código, T4G ofrece una solución fiable a muchos problemas del
software.
2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo requerido
para producir software se reduce mucho para aplicaciones pequeñas y de tamaño medio,
y que la cantidad de análisis y diseño para las aplicaciones pequeñas también se reduce.
3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige el
mismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería del software),
para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la
eliminación de la codificación.
Resumiendo, las técnicas de cuarta generación ya se han convertido en una parte importante del
desarrollo de software. Cuando se combinan con enfoques de ensamblaje de componentes el
paradigma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software.
(*)Fuente: (Pressman, 2002)
Actividades
1. Realice un cuadro comparativo entre los modelos de ciclo de vida de desarrollo de
software, indicando criterios de comparación, ventajas y desventajas de cada una de ellas
por cada criterio.
2. Busque en internet herramientas de software libre para modelar con el UML 2.0. .
Autoevaluación
Responda las siguientes preguntas:
1. Un proceso de desarrollo es
2. Las fase de un proceso de desarrollo son:
3. Indique las características de los siguientes modelos de ciclo de vida:
a. Secuencial
b. Construcción de prototipos
c. Desarrollo rápido de aplicaciones
d. Incremental
e. Espiral
4. Una definición de metodología es
5. Un producto, técnica, herramientas son
6. El UML es
7. El RUP es
• ISO/IEC 12207
Pagina de la organización internacional para la estandarización, ISO
http://www.iso.org/iso/catalogue_detail.htm?csnumber=43447
• OMG UML
Pagina oficial del Object Management Group, sobre UML, proporciona información y recursos
para UML
http://www.uml.org/
• IBM - RUP
Pagina de IBM Rational Unified Process, que ofrece información y recursos sobre la
plataforma de proceso de desarrollo de software configurable
http://www-01.ibm.com/software/pe/rational/rup.shtml
• Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
• Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML.
Segunda edición. Madrid. Pearson Educación S.A.
• Pressman , Roger S. (2002) Ingeniería de Software. Un enfoque práctico. 5ta.Ed. Mc Graw Hill,
España.
Análisis de Sistemas - Unidad III César Luza Montero
TERCERA UNIDAD
EL MODELADO DE NEGOCIOS
• ¿Qué es el modelado de negocios, cuales son sus perspectivas?

• ¿Qué es un actor del negocio, un caso de uso del negocio, una meta del negocio y un
diagrama de caso de uso del negocio?
• ¿Qué es un trabajador de negocio, una entidad de negocio y una realización de caso
de uso del negocio?
• ¿Cómo se elabora el modelo del negocio?
Lección 6
Conceptos asociados al modelado del Negocio

6.1 ¿Qué es el Modelado del Negocio
El modelado del Negocio es una técnica para representar procesos del negocio (Jacobson,
2000). Permite asegurar que se construirá el sistema en el contexto de las necesidades de
la empresa. El contexto esta dado por: El ambiente en que el sistema trabajará, Los roles
y responsabilidades de los empleados que usaran el sistema y Las “cosas” que son
manejadas en el negocio.
Tiene dos perspectivas: Externa e Interna. La perspectiva externa se representa con el
modelo de casos de uso del negocio y la perspectiva interna se representa con el modelo
de análisis del negocio.
6.2 Modelo de Casos de Uso del Negocio

Es una representación de la forma en que la empresa interactúa con su entorno. Provee
una visión general de lo que la empresa hace con sus clientes y otros participantes.
Incluye metas del negocio además de Actores y casos de uso del negocio
6.2.1 Actor del Negocio

Representa un rol que alguien o algo desempeña en relación al Negocio. La figura 6.1
muestra la notación de actor de negocio. Un candidato a actor de negocios es cualquier
individuo, grupo, organización, empresa, o máquina, externo al negocio, que interactúa
con ella.
Figura 6.1 Actor de negocio
Para comprender el contexto de un negocio, se debe conocer quien interactúa con el

negocio; por ejemplo, quien solicita un servicio o quien provee un insumo. Algunos
ejemplos de actores del negocio son: Clientes, Proveedores y Socios.
6.2.2 Casos de uso del negocio (CUN)

Representa un conjunto de secuencia de acciones que un negocio realiza para producir un
resultado observable para un actor del negocio. Un caso de uso del negocio representa un
proceso del negocio. La figura 6.2 muestra la notación de caso de uso de negocio.
Figura 6.2 Caso de uso de negocio
Los casos de uso del negocio se clasifican en: Principales, de Soporte y de Gestión. Los
casos de uso del negocio principales son aquellos que están ligados directamente con la
realización del producto y/o la prestación del servicio para el Cliente. Los casos de uso del
negocio de soporte son aquellos que proporcionan apoyo a los procesos principales,
usualmente están relacionados con la gestión de recursos. Los casos de uso del negocio
de gestión son aquellos que están vinculados al ámbito de las responsabilidades de la
dirección, se relacionan con actividades de planificación y control.
Para identificar un caso de uso del negocio principal (proceso de negocio principal) es
necesario determinar el servicio o producto de la empresa que recibe el actor del
negocio. Para identificar un caso de uso de negocio de soporte (proceso de negocio de
soporte) es necesario determinar que se requiere para ofrecer los productos o servicios al
cliente. Para identificar casos de uso de negocio de gestión es necesario examinar las
actividades relacionadas con la gestión de la empresa en su conjunto.
Algunos ejemplos de Casos de uso del negocio son: Solicitar un pedido, Realizar Venta.
6.2.3 Metas del negocio

Representa el valor deseado en una medida particular que puede ser usada para
planificar y administrar las actividades del negocio (Figura 6.3).
Figura 6.3 Meta de Negocio
6.2.4 Diagrama de casos de uso del negocio

El Diagrama de casos de uso del negocio (CUN) muestra a los actores del negocio, casos
de uso del negocio y las relaciones entre ellos (Figura 6.4).
Figura 6.4 Diagrama CUN
6.3 Modelo de Análisis del Negocio

El Modelo de Análisis de Negocios describe la realización de los casos de uso del negocio
mediante la interacción de los trabajadores del negocio y las entidades del negocio. Sirve
como una abstracción de cómo los trabajadores del negocio y las entidades del negocio
tienen que ser relacionados y como ellos necesitan colaborar para la ejecución del caso
de uso del negocio.
6.3.1 Trabajador del negocio

Es una abstracción de una persona o sistema software que representa un rol que se
ejecuta dentro de la realización de un CUN (figura 6.5).
Figura 6.5 Trabajador de negocio
Un trabajador del negocio (business worker) es alguien que realiza actividades dentro de
un caso de uso del negocio, interactúa con otros trabajadores del negocio y manipula
entidades del negocio.
6.3.2 Entidad del negocio

Representa una pieza de información significativa y persistente que es manipulada por los
actores y trabajadores del negocio (figura 6.6). Una entidad del negocio (business entity)
representa a un conjunto de información con propiedades, comportamiento y semántica
similares y que es manipulado o manejado por trabajadores del negocio. Algunos
ejemplos son: Factura, Solicitud de pago y Tarjeta de crédito.
Figura 6.6 Entidad de negocio
6.3.3 Realización de caso de uso del negocio

Describe como los trabajadores, entidades y eventos del negocio colaboran para
desarrollar un caso de uso del negocio
Figura 6.7 Entidad de negocio
La realización de un caso de uso del negocio puede incluir o se puede representar con:
Diagrama de actividades o Diagrama de Clases.
Diagrama de actividades
El Diagrama de actividades permite explorar el orden en que se realizan las actividades en
un caso de uso de negocio. Una actividad es una tarea manual o automatizada que
completa una unidad de trabajo.
Los elementos básicos de un diagrama de actividades son: Inicio, fin, actividad, transición,
barra de sincronización y bifurcación. En la figura 6.8 se observa un diagrama de
actividades básico, que se puede interpretar como sigue: el proceso se inicia con el
llenado del pedido, la flecha de transición entre llenar pedido y tramitar pedido significa
que después de la actividad llenar pedido sigue la actividad tramitar pedido. Terminado
de tramitar el pedido sigue analizar viabilidad cuyo resultado indica que si no es viable, se
notifica el rechazo y termina el flujo con rechazo; si es viable, en forma paralela se
pueden realizar Notificar aceptación y Ordenar fabricación, luego planificar producción.

Para que el flujo finalice correctamente, tiene que terminarse las actividades Notificar
aceptación y Planificar producción.
Figura 6.8 Diagrama de actividades simple
Inicio Rellenar
Pedido
Tramitar Analizar
Pedido Viabilidad
Notificar [No] Viable

rechazo
[Si]
Fin NoOK
Notificar Ordenar
Aceptacion fabricacion
Planificar
Produccion
Fin OK
En la figura 6.9 se mue4stra un diagrama de actividades detallado, que incluye elementos

adicionales, como los carriles, que permiten representar trabajadores del negocio que
realizan actividades: Jefe de taller y Dpto. reparaciones; entidades de negocio: libro de
citas, numero de trabajo interno, orden de reparación, etc.
Figura 6.9 Diagrama de actividades detallado
: Jefe de taller : Dpto reparaciones
Revisar cita aceptada

a : Libro de citas c : Orden de reparación
[copia]
z : Libro de citas
: Numero de trabajo interno [aceptada]
Reparar coche
Asignar numero trabajo interno

Elabora parte de trabajo
: Partes de trabajo
Generar orden de reparación
o : Orden de reparación
Guardar en partes pendientes
[original]
p : Partes de trabajo
[pendiente]
Diagrama de clases de negocio

El Diagrama de clases del negocio documenta la estructura interior del negocio. Cada
clase en este diagrama representa a un trabajador del negocio (el empleado del negocio)
o a una entidad del negocio (una 'cosa' que el negocio manipula). En este diagrama se
visualiza las relaciones entre los trabajadores del negocio y las entidades del negocio.
En la figura 6.10 se muestra un diagrama de clases del negocio, se observa al actor de
negocio: Cliente, a los trabajadores del negocio: facturador y empleado de mostrador.
Asimismo entidades de negocio: Partes de trabajo, inventario de artículos, factura, etc.
Figura 6.10 Diagrama de clases de análisis del negocio
Obtiene precios de materiales

revisa partes pendientes
Partes de trabajo Inventario de articulos
(f rom Entidades del negccio) (f rom Entidades del negccio)
Obtiene precio de m ano de obra

indica numero de identificacion Facturador
(f rom Trabajadores del negocio)
Registra pendiente
Asigna numero factura Calcula importe total
Fichero de mecanicos
(f rom Entidades del negccio)
recibe copia
Cliente
(f rom Business Use-Case Model) Realiz a
registrar facturas pagadas
Factura
Recib e
pago con tarjeta Em pleado del m ostradoir

(f rom Trabajadores del negocio)
pago
Pago en efectivo
Lección 7
Proceso de modelado del Negocio

El proceso de construcción de un modelo de negocio se puede dividir en construcción del
modelo de casos de uso del negocio y construcción del modelo de análisis del negocio.
La construcción del modelo de casos de uso del negocio puede considerar las siguientes
actividades: Identificar actores del negocio, Identificar casos de uso del negocio,
opcionalmente identificar metas del negocio y elaborar el diagrama de casos de uso del
negocio.
La construcción del modelo de análisis del negocio puede incluir las siguientes
actividades: Identificar trabajadores del negocio, identificar entidades del negocio y
construir las realizaciones de los casos de uso del negocio.
7.1 Elaborar el modelo de casos de uso del negocio

Consideremos el siguiente ejemplo para modelar los casos de uso del negocio
La empresa “Vende Barato S.A.” se dedica a la fabricación de productos bajo demanda. El

gerente general esta interesado en satisfacer de la mejor manera los pedidos de los
clientes, estableciéndose el objetivo de disminuir el tiempo de todo el proceso de la
atención del pedido. Para cumplir con el objetivo, es necesario en primer lugar registrar el
pedido del cliente, luego fabricar el producto pedido, llevar el control del almacén de
materias primas, en caso necesario, realizar compra de materia prima a proveedores. El
gerente general estableció las siguientes metas, reducir el tiempo de registro de un pedido
un 20% del tiempo actual, reducir la tasa de errores de fabricación a 0.5% del total,
mantener el stock adecuado de las materias primas y reducir el tiempo de generación de la
orden de compra a proveedores en un 20% del actual.
7.1.1 Identificando Actores del Negocio

De acuerdo con la especificación, los actores son Cliente y Proveedor. El Cliente
interactúa con la organización a través del pedido. El Proveedor interactúa con la
organización recibiendo la orden de compra de materia prima.
Cliente Proveedor
7.1.2 Identificando Casos de Uso del Negocio

Los casos de uso de negocio principales son: Registrar Pedido del Cliente y realizar
compra a proveedores. Los casos de uso del negocio de soporte son: Fabricar producto
pedido y Controlar almacén. No se identifican casos de uso del negocio de gestión.
Registrar pedido Fabricar producto Controlar almacen Comprar materia prima
7.1.3 Identificando Metas del Negocio

Por cada caso de uso se identifican las metas del negocio. Este paso es opcional.
Reducir tiem po en 20% Mantener stock adecuado Reducir tasa errores a 0.5% Reducir generación orden compra en 20%
7.1.4 Elaborando el diagrama de casos de uso del negocio

Se asocia los actores con cada caso de uso principal y cada caso de uso con su respectiva
meta.
Creado por : Cesar Luza

Fecha: Enero 25, 2010
Registrar pedido
Cliente
(from Casos de uso del negocio) Reducir tiempo en 20%
(f rom Actores del negocio) (f rom Metas del negocio)
Fabricar producto Reducir tasa errores a 0.5% Controlar almacen Mantener stock adecuado
(f rom Metas del negocio)
(from Casos de uso del negocio) (f rom Metas del negocio) (from Casos de uso del negocio)
Comprar materia prima Reducir generación orden compra en 20%

Proveedor
(from Casos de uso del negocio) (f rom Metas del negocio)
(f rom Actores del negocio)
7.2 Elaborar el modelo de análisis del negocio

En nuestro ejemplo, de la empresa “Vende barato S.A.” consideremos la siguiente
descripción de caso de uso de negocio Registrar pedido:
1. El Cliente envía su pedido, por teléfono, por fax o por correo, al Dpto. de Ventas. El
pedido debe incluir la fecha de solicitud, datos del cliente y producto solicitado.
2. Un Empleado del Dpto. de Ventas revisa el pedido (completándolo, si es necesario).
Comienza su procesamiento enviándolo al Jefe Técnico, que está encargado de su
análisis.
3. El Jefe Técnico analiza la viabilidad del producto solicitado. Si el producto pedido está en
el catálogo, su fabricación es aceptada. En caso contrario, es considerado un producto
especial, y el Jefe Técnico estudia su fabricación: Si es viable, la fabricación del producto
especial es aceptada; Si no es viable, el producto especial no será fabricado.
4. Una vez estudiado el pedido completo, el Jefe Técnico informa al Dpto. de Ventas de la
aceptación o rechazo del producto pedido; Si el producto de un pedido ha sido aceptado,
se crea una orden de trabajo, a partir de una plantilla de fabricación (la estándar si el
producto estaba catalogado, o una nueva, específicamente diseñada para el producto, si
éste no estaba en el catálogo). Cada orden de trabajo es enviada al Jefe de Producción, y
queda pendiente de su fabricación.
5. El Empleado del Dpto. de Ventas comunica al cliente el resultado final del análisis de su
pedido.
7.2.1 Identificando trabajadores del negocio

Se identifican los trabajadores del negocio, en nuestro ejemplo solo consideramos el caso
de uso de negocio Registrar Pedido:
Empleado de Ventas Jefe Tecnico Jefe Produccion
7.2.2 Identificando entidades del negocio

Se identifican las entidades del negocio, en nuestro ejemplo solo del caso de uso de
negocio Registrar Pedido:
Pedido Catalogo Plantilla de fabricacion Producto especial Orden de Trabajo
7.2.3 Construyendo las realizaciones de caso de uso del negocio

Realización con diagrama de actividades del Caso de Registrar Pedido
: Cliente : Empleado de Ventas : Jefe Tecnico : Jefe Produccion
: Catalogo : Plantilla de fabricacion
Llenar pedido
p : Pedido
[propuesto]
Analizar viabilidad
x : Pedido
: Producto especial
Tramitar pedido
[ NO Viable ]
[ SI viable ]
: Plantilla de fabricacion
Informar rechazo
r : Pedido
[Rechazado]
Ordenar Fabricación : Orden de Trabajo
Informar aceptacion
a : Pedido
Planificar producción
[Aceptado]
Resumen
Conceptos asociados al modelado del negocio
• El modelado del negocio es una técnica para representar proceso de negocio, tiene dos
perspectivas: externa (modelo de casos de uso) e interna (modelo de análisis del negocio).
• El modelo de casos de uso del negocio representa la forma en que la empresa interactúa con su
entorno. Incluye: actores, casos de uso del negocio.
o Un actor de negocio representa un rol que alguien o algo desempeña en relación al
negocio.
o Un caso de uso de negocio representa un conjunto de secuencia de acciones que un
negocio realiza para producir un resultado observable para un actor de negocio.
o Un diagrama de caso de uso de negocio muestra actores de negocio, casos de uso de
negocio y las relaciones entre ellos.
• El modelo de análisis del negocio describe la realización de los casos de uso del negocio mediante
interacción de los trabajadores del negocio y las entidades del negocio.
o Un trabajador de negocio representa un rol que se ejecuta en la realización de un caso de
uso del negocio.
o Una entidad de negocio representa una pieza de información significativa y persistente
que es manipulado por trabajadores de negocio o actores de negocio.
o Una realización de casos de uso de negocio describe como los trabajadores y entidades del
negocio colaboran para desarrollar un caso de uso del negocio.
Proceso de modelado del negocio
• Elaboración del modelo de casos de uso del negocio
o Identificar actores de negocio
o Identificar casos de uso del negocio
o Elaborar diagrama de casos de uso del negocio
• Elaboración del modelo de análisis del negocio
o Identificar trabajador de negocio
o Identificar entidad de negocio
o Construir realización de casos de uso del negocio
Con Diagrama de actividades
Con diagrama de clases de análisis del negocio
Lectura
Manifiesto de Reglas de Negocio (*)
Los Principios de la Independencia de las Reglas
The Business Rules Group
Artículo 1. Los requisitos como elementos principales, nunca como secundarios
1.1. Las reglas son un ciudadano de primera clase en el mundo de los Requisitos.
1.2. Las reglas son esenciales para los modelos de negocio y para los modelos de tecnología, y una
parte separada y especifica de los mismos.
Artículo 2. Independientes de los procesos y no contenidas en ellos
1.1. Las reglas son restricciones explicitas de comportamiento y/o proporcionan soporte para la
dirección de las actividades de negocio.
1.2. Las reglas no son procesos ni procedimientos. Y por tanto no deben estar contenidas en ninguno
de ellos.
1.3. Las reglas se aplican a lo largo de los procesos y procedimientos. Debe existir un corpus coherente
de reglas que se aplique sistemáticamente en todas las áreas de actividad del negocio.
Artículo 3. Proporcionar conocimiento meditado, no un sub-producto
1.1. Las reglas se construyen sobre hechos, y los hechos sobre conceptos tal y como son expresados
mediante términos.
1.2. Los términos expresan conceptos de negocio; los hechos realizan afirmaciones sobre estos
conceptos; las reglas restringen y apoyan estos hechos.
1.3. Las reglas deben ser explicitas. No se debe asumir ninguna regla sobre ningún concepto o hecho.
1.4. Las reglas son los fundamentos que definen lo que el negocio sabe de si mismo- es decir son
conocimiento básico de negocio.
1.5. Las reglas necesitan ser alimentadas, protegidas y gestionadas.
Artículo 4. Declarativas, no de procedimiento
4.1 Las reglas deben expresarse de forma declarativa en sentencias de lenguaje natural, por la
audiencia conocedora del negocio.
4.2 Si algo no puede ser expresado claramente, entonces no es una Regla.
4.3 Una serie de enunciados solo es declarativa si no contiene una secuencia implícita.
4.4 Cualquier enunciado de reglas que necesite de otros elementos que no sean términos o hechos,
revelan hipótesis sobre la implementación de un sistema.
4.5 Una regla es distinta del nivel de cumplimiento definido para ella. La regla y su nivel de
cumplimiento son dos asuntos diferentes.
4.6 Las reglas deben definirse independientemente de la quien tiene la responsabilidad de su
cumplimiento, y de donde, cuando o como se refuerzan.
4.7 Las excepciones a las reglas se definen mediante otras reglas.
Artículo 5. Expresiones bien formadas, no expresiones creadas con fines específicas para un caso
1.1 Las reglas de negocio se deben expresar demanera que pueda ser validada su exactitud por el
personal conocedor del negocio.
1.2 Las reglas de negocio se deben expresar de manera que se pueda verificar recíprocamente su
coherencia.
1.3 Las lógicas formales, como la lógica de predicados, son fundamentales para la expresión formal de
reglas en términos de negocio, así como para las tecnologías que implementan dichas reglas.
Artículo 6. Arquitectura basada en las reglas, no una implementación indirecta
6.1 Un sistema basado en reglas de negocio se construye intencionadamente para permitir el cambio
continuo de las reglas de negocio. La plataforma sobre la que el sistema se ejecuta debe soportar
esta evolución.
6.2 Es mejor ejecutar las reglas directamente – por ejemplo utilizando un motor de reglas – antes que
transcribirlas en alguna forma embebida dentro de un procedimiento.
6.3 Un sistema de reglas de negocio siempre debe ser capaz de explicar el razonamiento por el cual
llega a una conclusión o emprende una acción.
6.4 Las reglas se basan en los valores ciertos. La forma en la que certeza de una regla se determina, se
mantiene oculta a quienes la utilizan.
6.5 La relación entre eventos y reglas es generalmente de muchos-a-muchos.
Artículo 7. Procesos guiados por reglas, no programación basada en excepciones
7.1 Las reglas definen el límite entre actividad de negocio aceptable y no aceptable.
7.2 Las Reglas requieren a menudo de una gestión especial o especifica de las violaciones detectadas.
Cualquier actividad derivada de la violación de una regla es una actividad como cualquier otra.
7.3 Para asegurar la máxima consistencia y reutilización, el tratamiento de las actividades de negocio
no aceptables, debe separarse de la gestión de actividades de negocio aceptables.
Artículo 8. Al servicio del negocio, no al de la tecnología
8.1 Las Reglas tratan sobre las prácticas de la gestión y gobierno del negocio, por lo tanto son
motivadas por las metas y los objetivos de negocio y se les da forma a través de varios
factores internos y externos a la empresa.
8.2 Las reglas suponen siempre un coste a la empresa.
8.3 Este coste de la aplicación de las reglas debe valorarse y balancearse, teniendo en cuenta
los riesgos asumidos por el negocio, y las oportunidades perdidas en caso de no aplicarlas.
8.4 “Más reglas” no es mejor, la abundancia de reglas no beneficia a su aplicación.
Normalmente es mejor un número limitado de reglas bien reflexionadas.
8.5 Un sistema eficaz puede estar basado en un pequeño número de reglas. Adicionalmente,
se pueden añadir reglas más discriminatorias, por las que ha medida que pasa el tiempo el
sistema mejore y se hace más inteligente.
Artículo 9. “De, por y para” el personal de negocio. No “de, por y para” el personal de IT.
9.1 Las reglas deben provenir del personal con conocimiento de negocio.
9.2 Los expertos de negocio debe tener disponibles herramientas que les ayuden a formular, validar y
gestionar reglas.
9.3 Los expertos de negocio deben tener disponibles herramientas que les ayuden a verificar la
coherencia reciproca entre las reglas de negocio.
Artículo 10. Gestionando la lógica de negocio, no las plataformas de Hardware/Software
1.1 Las reglas de negocio son un patrimonio vital del negocio.
1.2 A largo plazo, las reglas son más importantes para el negocio que las plataformas
Hardware/Software.
1.3 Las reglas de negocio deben organizarse y salvaguardarse de forma que puedan ser redesplegadas
a nuevas plataformas de Hardware/Software.
1.4 Las reglas, y la habilidad para cambiarlas de forma eficaz, son factores clave para mejorar la
adaptabilidad de las empresas.
(*) The Business Rules Group

Copyright, 2003. Business Rules Group. Version 2.0, November 1, 2003. Edited by Ronald G. Ross.
www.BusinessRulesGroup.org
La reproducción y la distribución de este documento se concede bajo las siguientes condiciones: (a) Se debe
incluir mención clara y visible del copyright y del permiso. (b) Se debe mencionar al Business Rules Group como
la fuente del documento. (c) Se debe respetar la integridad del documento reproducido, incluido el título, el
contenido, el copyright, el permiso, sin ninguna modificación, abreviación, resumen, ni extensión.
Traducción a español versión 1.0, noviembre 2005, iniciada y coordinada por Antonio Catala.
(antonio.catala@theanonymousarchitect.com)
Actividades
Elaborar el Modelo del Negocio considerando la siguiente descripción:
La Empresa FABCLM se dedica a la fabricación de productos de consumo masivo. La

Gerencia General desea automatizar las principales actividades que la empresa realiza en
los procesos de atención de pedidos, control de la fabricación, proceso de facturación y
entrega de mercadería.
Proceso de atención de pedidos
El cliente envía su pedido por distintos medios (teléfono, correo o fax), son recibido por la
empleada encargada de la Oficina de Atención a Clientes, quien solicita que se realicen las
siguientes comprobaciones: Antonio (Dpto de Almacén) se encarga de verificar la
disponibilidad de los artículos solicitados, consultando el inventario de artículos. Juan
(Dpto. Contabilidad) verifica el estado de la cuenta del cliente para ver si tiene deudas
pendientes; y el Dpto. Legal verifica si el cliente tiene antecedentes sospechosos,
consultando el archivo de antecedentes. En caso de que los pedidos no cumplan alguna de
las condiciones anteriores serán rechazados, notificándoselo al cliente. Pero si todo es
correcto, se registrar aceptación del pedido. En ambos casos es la empleada la que informa
al cliente.
Proceso de control de fabricación
El proceso se inicia cuando el pedido aceptado es recibido por el Jefe de Producción, quien
le asigna un número de trabajo interno, luego genera la orden de producción y registra el
pedido como pendiente de fabricación. La orden de producción se envía a la sección de
fabricación para que empiece a elaborar los productos del pedido. Cuando finaliza el
trabajo, el Jefe de Producción elabora una carta donde indica a quién serán enviadas los
productos que se encuentran listas. Evidentemente, el pedido deja de ser pendiente.
Proceso de Facturación
Recibida la carta de productos terminados el Dpto de Facturación procede a elaborar la
factura y el talón de embarque. Una copia de la factura se envía al Dpto. de Contabilidad
que se encarga de realizar los asientos. Otra copia se añade al archivo de facturas. Este
último archivo se emplea únicamente como referencia; no es un archivo activo sino que
solo sirve para seguridad.
Proceso de Entrega
Los artículos elaborados se reciben en el área de embarque, donde son empaquetadas, y el
talón de embarque se anexa a la caja de embarque. En base a la información contenida en
el talón de embarque se procede a entregar la mercadería a domicilio asignando la
movilidad correspondiente o llamar al cliente para indicarle que su mercadería esta lista y
se apersone a recogerla.
Autoevaluación
1 El modelado del negocio es
2 Los elementos del modelo de caso de uso del negocio son
3 Un actor de negocio es
4 Un caso de uso de negocio es
5 Los elementos del modelo de análisis del negocio son
6 Un trabajador de negocio es
7 Una entidad de negocio es
• IBM - RUP
Pagina de IBM Rational Unified Process, que ofrece información y recursos sobre la
plataforma de proceso de desarrollo de software configurable
http://www-01.ibm.com/software/pe/rational/rup.shtml
• Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML.
Análisis de Sistemas - Unidad IV César Luza Montero
CUARTA UNIDAD
EL MODELADO DE DOMINIO
• ¿Qué es el modelado de dominio?

• ¿Qué es un diagrama de clases?
• ¿Cuáles son sus elementos? y
• ¿Cómo se construye?
Lección 8
Conceptos asociados al modelo de dominio

En el contexto de desarrollo de sistemas de información, es frecuente, en las primeras
etapas del proceso, construir un modelo del dominio del problema para representar las
propiedades más importantes del ámbito del negocio relacionado con el problema.
Una técnica muy utilizada para representar este modelo de domino es el diagrama de
clases de UML; precisamente, en esta lección se describen las bases conceptuales para
construir adecuadamente un diagrama de clases.
8.1 Clase y Objeto

Un objeto se define como un concepto, abstracción o cosa con límites bien definidos y
con significado para el problema que se tenga entre manos. Una clase describe un
conjunto de objetos con propiedades similares, relaciones comunes con otros y una
semántica común (Rumbaugh, 1996).
Por ejemplo, “Análisis de sistemas”, “Base de datos I”, “Estadística II”, “Matemática
Básica I” son objetos de la clase ASIGNATURA, en otras palabras, ASIGNATURA representa
al conjunto de todas las asignaturas en el dominio de la gestión académica de una
institución educativa.
8.2 Atributo
Una clase tiene una serie de características o propiedades, por ejemplo ASIGNATURA
tiene código, nombre, créditos, horas de teoría, horas de practica; a estas propiedades se
le conoce como atributos de la clases. Un atributo es una propiedad de una clase que
describe un rango de valores que la propiedad podrá contener en los objetos de la clase
(Rumbaugh, 1996)..
Podemos decir que una clase representa un conjunto de objetos con las mismos atributos
y un objeto es una instancia de una clase, es decir es una entidad que tiene valores
específicos para cada uno de los atributos de la clase.
Por ejemplo, la clase AUTOMOVIL, tiene como atributos: número de placa, color, modelo,
número de puertas, año, entre otros. Un objeto, de la clase AUTOMOVIL, es el auto de
placa SGD345, color azul, modelo Station Wagon, con cuatro puertas, del año 2000. Otro
objeto es el auto de placa ERG237, negro, deportivo, 4 puertas, año 2009.
8.3 Operación
Una clase tiene un comportamiento que es definido por las operaciones o
responsabilidades que la clase puede realizar. Una operación es algo que la clase puede
realizar o que otra clase puede hacer a una clase. Es una función o transformación que se
puede aplicar o que puede ser aplicada por los objetos de una clase (Rumbaugh, 1996)..
Por ejemplo, algunas operaciones de la clase automóvil pueden ser: Encender, Apagar,
Acelerar, Frenar.
8.4 Asociación y Enlace

Las entidades o cosas del mundo real se relacionan con otras entidades; a las relaciones
entre objetos se les llama enlaces y a las relaciones entre clases se les llama asociaciones
(Rumbaugh, 1996).
Mediante la abstracción de asociación se vincula dos o más clases, creándose un
elemento de tipo distinto (Vinculo).
Por ejemplo, “Docente dicta Asignatura”, es una asociación entre la clase docente y la
clase asignatura. “Cesar Luza dicta Análisis de sistemas” es un enlace entre los objetos
Cesar Luza y Análisis de sistemas.
8.5 Generalización y Agregación

La generalización y agregación son dos tipos especiales de relaciones entre clases
(Rumbaugh, 1996)..
La Generalización representa la relación entre clases, donde algunas de ellas son tipos de
otra. Por ejemplo, las clases SECRETARIA, TÉCNICO, INGENIERO son tipos de la clase
EMPLEADO; en otras palabras, EMPLEADO es una generalización de las clases
SECRETARIA, TECNICO, INGENIERO (ver figura 8.1).
Mediante la generalización se abstrae las características comunes a varias clases
(subclases) para construir una clase más general (superclase), la generalización define una
relación de subconjunto entre elementos de dos o más clases.
Figura 8.1 Ejemplo de generalización
GENERALIZACIÓN
SECRETARIA TECNICO EMPLEADO
INGENIERO
Una Clase ES UN TIPO DE otra
La Agregación representa la relación entre clases, donde algunas de ellas son

componentes de otra. Por ejemplo, las clases CPU, TECLADO, MOUSE, MONITOR son
componentes de la clase COMPUTADORA; en otras palabras, la clase COMPUTADORA
está formada por las clases CPU, TECLADO, MOUSE Y MONITOR (figura 8.2).
Mediante la agregación se construye una nueva clase o tipo o categoría de objetos a
partir de un conjunto de otras clases denominadas componentes o partes. La agregación
define una nueva clase de objetos a partir de un conjunto de clases (otras, no
necesariamente distintas) que representan sus partes componente.
Figura 8.2 Ejemplo de Agregación
CPU AGREGACIÓN
MOUSE
COMPUTADOR
MONITOR
A
TECLADO
Una Clase ES PARTE DE otra clase
8.6 ¿Qué es el modelo de domino?

El Modelo de dominio es un modelo conceptual que muestra clases conceptuales de
objetos significativos en un dominio de problema. Las clases conceptuales no muestran
componentes software, ni clases software, ni responsabilidades (Larman, 1999).
Por ejemplo, algunas clases conceptuales del dominio de la Gestión Académica son:
ALUMNO, DOCENTE, ASIGNATURA y HORARIO.
El modelo de dominio se puede documentar con un Diagrama de Clases.
8.7 ¿Qué es el diagrama de clases?

Un diagrama de clases es un tipo de diagrama estático del UML, que describe la
estructura de un sistema mostrando sus clases y sus relaciones. En la figura 8.1 se
observa un ejemplo de diagrama de clase simplificado para una Tienda de ventas. Se
muestra clases conceptuales y relaciones entre ellas; cada clase tiene un nombre y una
serie de atributos. Las relaciones se conocen como asociaciones, cada una de ellas tiene
un nombre y su multiplicidad.
La interpretación o lectura de un diagrama de clases permite a desarrolladores y usuarios
disponer de un lenguaje uniforme para mostrar características del negocio en el dominio
del problema. Por ejemplo, en la figura 8.3, podemos leer la siguiente restricción
semántica: “una línea de venta está contenida en una venta y esta puede contener
muchas líneas de venta, nunca ninguna línea de venta”. Además, “cada línea de venta
registra la venta de un articulo y un articulo puede o no estar en una línea de venta”.
Figura 8.3 Ejemplo de diagrama de Clases
concepto u LineaDeVenta Registra-venta-de
objeto del Artículo
cantidad
dominio 0..1 1
*
1..n
asociación Contenida-en Al ma cenado-en
1
1 Tienda
atributos Venta dirección
tienda
fecha
hora
1 1
1 Capturada-en
Alb erga
Pagada-median te 1
1.. *
1 Registro
Pago
cantidad
Fuente: (Larman, 1999)
8.8 Notación UML para modelo de domino
Clase
Para efectos del modelo de dominio, una clase puede considerarse en términos de:
• Símbolo, palabras o imágenes que representan a la clase;
• Definición del concepto, descripción textual del significado de la clase y
• Extensión: conjunto de objetos que pertenecen a la clase.
Por ejemplo, considere la clase Venta del diagrama de clases de la figura 8.4.
El símbolo del concepto es un rectángulo dividió en tres partes, la primera es el nombre

de la clase, la segunda los atributos y la tercera las operaciones.
Figura 8.4 Clase
Venta
fecha
hora
La definición del concepto es: Una venta representa el hecho de una transacción de
compra, sucede un día y en una hora.
La extensión es el conjunto de todas las ventas realizadas en la tienda.
Atributo
Para efectos del modelo de dominio se incluyen aquellos atributos para los que los
requisitos indican la necesidad de registrar su información.
Por ejemplo, un recibo recoge la información de una venta, incluyendo fecha y hora. La
Gerencia de la Tienda quiere conocer fecha y hora de las ventas, la clase Venta necesita
los atributos fecha y hora.
Según la notación UML, los atributos se muestran en el segundo compartimento del
rectángulo de la clase.
Figura 8.5 Atributos
Venta
fecha
hora
Asociación
La asociación se representa con una línea que une las clases relacionadas. En el siguiente
ejemplo, se muestra la relación entre las clases ALUMNO y FACULTAD; la semántica
señala que un alumno pertenece a una única facultad y una facultad tiene muchos
alumnos.
Figura 8.6 Asociación
En una asociación se incluye, opcionalmente, el nombre de la asociación, la

navegabilidad, y obligatoriamente, la multiplicidad. La navegabilidad se representa con
una flecha que indica la dirección de envío de mensajes de un objeto a otro. La
multiplicidad es la cantidad de objetos de una clase que están vinculados con un objeto
de la clase asociada.
Por ejemplo, en la figura 8.6, el nombre de la asociación es: Pertenece a. La multiplicidad
de la asociación es de “uno a muchos”; significa “Un objeto de alumno está vinculado con
un solo objeto de Facultad, y un objeto de Facultad esta vinculado con varios objetos de
ALUMNO”.
La multiplicidad permite representar, en el diagrama de clases, las reglas del negocio
definidas en el dominio del problema. Las categorías típicas de multiplicidad son: “Uno a
Uno”, “Uno a Muchos” y “Muchos a Muchos”. En la figura 8.7 se aprecia algunos tipos de
multiplicidad.
Figura 8.7 Tipos de multiplicidad
Clase-Asociación
En algunas ocasiones es necesario representar propiedades propias de la asociación; para
tal efecto, se crea una clase especial llamada Clase-Asociación. Por ejemplo,
consideremos la asociación ALUMNO matriculado en ASIGNATURA, la multiplicidad de
esta asociación es de “muchos a muchos”, en efecto, un alumno puede llevar varias
asignaturas y una asignatura es llevada por varios alumnos. Entonces, la nota promedio
de un alumno en una asignatura corresponde a la asociación; pues si se coloca como
atributo de alumno, no se sabría de qué asignatura es; si se coloca como atributo de
asignatura, no se sabría de qué alumno es, entonces, se crea una clase especial llamada
clase asociación MATRICULA en el que se coloca el atributo nota promedio.
La representación de una clase asociación se hace con una línea discontinua que une la
asociación con la clase generada. (figura 8.8).
Figura 8.8 Ejemplo de Clase-Asociación
Generalización
La generalización se representa a través de una línea recta entre las clases subtipos
terminados en un triángulo blanco en el extremo cercano a la clase generalizada. Por
ejemplo, en la figura 8.9, ANFIBIO, MAMÍFERO y REPTIL son tipos de ANIMAL. A su vez,
CABALLO es un tipo de MAMÍFERO.
La Generalización puede encontrarse en aquellas clases que tienen ciertos atributos y
operaciones en común. En ese caso se crea una clase nueva que asume dicho
comportamiento común.
Figura 8.9 Ejemplo de Generalización
Agregación
La agregación se representa a través de una línea recta entre las clases “partes”
terminados en un rombo en el extremo cercano a la clase “todo”. Por ejemplo, en la
figura 8.10, MONITOR, CASES, TECLADO y MOUSE son partes o componentes de
COMPUTADORA. A su vez, CASES está formado por CPU, RAM,VENTILADOR.
Figura 8.10 Ejemplo de Agregación
Lección 9
Proceso de construcción del modelo de dominio

Muchos de las clases del dominio pueden obtenerse de una especificación de requisitos o
mediante la entrevista con los expertos del dominio. Las clases del dominio aparecen en
tres formas distintas (Jacobson, 2000):
• Objetos del negocio que representan cosas que se manipulan en el negocio, como
pedidos, cuentas, contratos, y facturas.
• Objetos del mundo real y conceptos de los que el sistema debe hacer un
seguimiento, como la aviación enemiga, misiles y trayectorias.
• Sucesos que ocurrirán o han ocurrido, como la llegada de un avión, sus salidas y la
hora de la comida.
Para construir el modelo de dominio se puede seguir las siguientes actividades: Identificar
las Clases conceptuales o del dominio, Identificar las asociaciones, Identificar atributos,
Identifica relación de generalización y refinar el modelo.
Consideremos la siguiente descripción para realizar el modelo de dominio.
Una empresa recién formada se dedica a integrar partes para formar productos con la
intención de vender el valor agregado de la integración. Con el objetivo de apoyar sus
actividades, mediante una aplicación informática, se ha obtenido las siguientes reglas
semánticas:
Un producto tiene un nombre y un precio base. Un producto se forma con muchas partes y
cada parte puede formar muchos productos. La definición de cada producto especifica qué
cantidad de cada parte forma a un producto dado.
Un vendedor tiene un apellido, nombre y un porcentual de comisión. Tanto un cliente como un
proveedor tienen los datos de todo agente comercial; éstos son: cuit, razón social, e-mail,
teléfono y dirección. Además, un proveedor tiene un plazo de pago y un cliente un porcentual
de descuento.
Un parte puede ser comprado a muchos proveedores y un proveedor puede proveer muchas
partes. Cada compra de un parte tiene una fecha y una cantidad. Una venta se realiza entre
cualquier vendedor y cualquier cliente, y éste puede comprar cualquier producto. De una
venta se quiere saber su fecha.
No se pueden vender productos que estén formados por una única parte, esto es, no se
permite vender productos sin elaborar.
9.1 Identificando Clases

Se seleccionan los nombres o sustantivos de la descripción del problema como posibles
clases candidatas. Se construye una lista de clases candidatas. Se eliminan, de esa lista, las
clases redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o
construcciones de implementación.
En nuestro ejemplo las clases conceptuales identificadas son:
producto parte vendedor cliente proveedor agenteComercial
9.2 Identificando Asociaciones

Se establecen las asociaciones según las reglas del negocio en el dominio del problema, se
puede considerar como estrategia para identificar asociaciones la selección de verbos en
la descripción del problema. Se le agrega la multiplicidad correcta. También se puede
representar la relación " es parte de" o agregación.
En nuestro caso, las asociaciones identificadas son:
producto 1..n se forma 1..n parte

vendedor
1..n 1..n
se vende
agenteComercial Se compra
1..n
1..n
cliente
proveedor
9.3 Identificar Atributos

Por cada clase se indican los atributos necesarios que respondan a los requerimientos del
dominio del problema. Si los atributos corresponden a una asociación, crear una clase
asociación.
En nuestro ejemplo, se señalan los atributos por cada clase y adicionalmente, se
identifican atributos para las algunas asociaciones, creándose las clases asociación
Definición, compra y venta.
vendedor producto parte

nombre 1..n se forma 1..n numParte
apellido
nombre precioBase descripción
porcComis
1..n definición 1..n
1 cantidad
participa
se vende
0..n compra
Se compra fecha
venta agenteComercial
cantidad
fecha cuit
razSocial
email
telf
direcc
1..n 1..n
cliente proveedor
porcDesc plazoPago
9.4 Identificar relaciones de generalización

Se organiza y simplifica el modelo usando el principio de herencia; es decir, se puede
generalizar los aspectos comunes de las clases existentes construyendo una superclase, o
se puede especializar una clase en varias subclases.
Para nuestro ejemplo se establece relación de generalización entre agente comercia con
cliente y proveedor:
vendedor producto parte

nombre 1..n se forma 1..n numParte
apellido
nombre precioBase descripción
porcComis
1..n definición
1 1..n
cantidad
participa
0..n se vende compra
fecha
venta agenteComercial Se compra
cantidad
fecha cuit
razSocial
email
telf
direcc
1..n
1..n
cliente proveedor
porcDesc plazoPago
9.5 Refinar el modelo

Se valida que el diagrama responda a los requerimientos. Se itera y refina el modelo hasta
que esté completo; es decir, hasta que cumpla todos los requerimientos señalados en la
descripción del problema.
Resumen
Conceptos asociados al modelo de dominio

• Un objeto se define como un concepto, abstracción o cosa con límites bien definidos y con
significado para el problema que se tenga entre manos.
• Una clase describe un conjunto de objetos con propiedades similares, relaciones comunes con
otros y una semántica común
• Un atributo es una propiedad de una clase que describe un rango de valores que la propiedad
podrá contener en los objetos de la clase
• Un enlace es una relación entre objetos
• Una asociación es la relación entre clases
• La multiplicidad es la cantidad de objetos de una clase que están vinculados con un objeto de la
clase asociada.
• La Generalización representa la relación entre clases, donde algunas de ellas son tipos de otra
• La Agregación representa la relación entre clases, donde algunas de ellas son componentes de otra
• El Modelo de dominio es un modelo conceptual que muestra clases conceptuales de objetos
significativos en un dominio de problema
• Un diagrama de clases es un tipo de diagrama estático del UML, que describe la estructura de un
sistema mostrando sus clases y sus relaciones
• En algunas ocasiones es necesario representar propiedades propias de la asociación; para tal
efecto, se crea una clase especial llamada Clase-Asociación
Proceso de construcción de modelo de dominio

• Identificar clases
• Identificar asociaciones
• Identificar atributos
• Identificar relaciones de generalización
• Refinar el modelo
Lectura
Desarrollo de un modelo de dominio (*)
El modelado de dominio se realiza habitualmente en reuniones organizadas por los analistas del
dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. Para
formar un equipo eficaz, estas reuniones deberían incluir tanto a expertos del dominio como a
gente con experiencia en modelado.
El objetivo del modelado del dominio es com prender y describir las clases más importantes
dentro del contexto del sistema. Los dominios de tamaño moderado normalmente requieren
entre 10 y 50 de esas clases. Los dominios más grandes pueden requerir muchas más.
Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se
guardan como definiciones en un glosario de términos, de otra manera, el modelo de dominio se
hará demasiado grande y requeriría más esfuerzo del necesario para esta parte del proceso.
Algunas veces, como en los dominios del negocio muy pequeños, no es necesario desarrollar un
modelo de objetos para el dominios; en su lugar, puede ser suficiente un glosario de términos.
El glosario y el modelo de dominio ayudan a los usuarios, clientes, desarrolladores, y otros
interesados a utilizar un vocabulario común. La terminología común es necesaria para compartir
el conocimiento con los otros. Cuando abunda la confusión, el proceso de ingeniería se hace
difícil, si no imposible. Para construir un sistema software de cualquier tamaño, los ingenieros de
hoy en día deben “fundir” el lenguaje de todos los participantes en uno solo consistente.
Por último, es necesario una llamada de atención sobre el modelo de dominio. Puede ser bastante
fácil el comenzar modelando las partes internas de un sistema y no su contexto. Por ejemplo,
algunos objetos del dominio podrían tener una representación inmediata en el sistema, y algunos
analistas del dominio podrían a su vez caer en la trampa de especificar los detalles relativos a esta
representación. En casos como éstos, es muy importante recordar que el objetivo del modelado
del dominio es contribuir a la comprensión del contexto del sistema, y por lo tanto también
contribuir a la comprensión de los requisitos del sistema que se desprenden de este contexto. En
otras palabras, el modelado del dominio debería contribuir a una compresión del problema que
se supone que el sistema resuelve en relación a su contexto. El modo interno por el cual el
sistema resuelve éste problema se trata en los siguientes flujos de análisis, diseño e
implementación.
(*) Jacobson (2000)
Actividades
Desarrollar el modelo de dominio para el siguiente caso
Una Institución Educativa ha decidido brindar unos cursos extracurriculares, tanto

para sus alumnos como para personas externas a la Institución. Las razones para la
inclusión de personas no pertenecientes a la Institución son: obtener fondos para la
modernización de las instalaciones y ayudar al pago de los viáticos de los
profesores invitados.
Se desea desarrollar una aplicación que permita administrar el dictado de los
cursos; una primera aproximación del contexto del negocio es el siguiente:
Se brinda varios cursos. Cada curso tiene un nombre, un cupo máximo y un cupo
mínimo el cual, si no se alcanza, hace que el curso no se dicte. Cada curso es
dictado por un único docente y un docente puede dictar más de un curso. Cada
docente tiene apellidos, nombres, cargo y una dedicación.
A cada alumno se le da un material general, independientemente de la cantidad de
cursos en que se haya inscrito, además de un material particular para cada curso en
el que esta inscrito. Se desea controlar si se le ha entregado, o no, tanto el material
general como los materiales particulares a cada alumno.
Un alumno puede asistir a muchos cursos y cada curso debe tener una cantidad
mínima de inscritos –cupo mínimo- y no sobrepasar el cupo máximo.
De los alumnos internos se debe mantener la información de apellidos, nombres y
número de libreta; de los alumnos externos, apellidos, nombres, número de recibo
–único para todos los cursos-, forma de pago -efectivo, cheque o tarjeta- y monto
pagado.
A cada curso se le asigna una única aula que tiene un nombre, una ubicación y una
capacidad. No puede asignarse un aula a un curso cuyo cupo máximo no entre en la
misma.
También se desea controlar si el alumno va asistir como oyente –no se presenta a
examen ni realiza prácticos- a cada curso en donde se inscribió. Esta información es
útil para que el docente organize el dictado.
Autoevaluación
Conteste las siguientes preguntas
1. La diferencia entre clase y objeto es
2. Proporciones una ejemplo de clase con algunos de sus atributos , y tres ejemplos de objetos
de dicha clases
3. Una clase conceptual es
4. La diferencia entre enlace y asociación es
5. La diferencia entre generalización y agregación es
6. El modelo de domino es
7. Un diagrama de clases es
8. La multiplicidad de una asociación representa
9. Una clase-asociación es
• Portal del producto IBM Rational Modeler
http://www-01.ibm.com/software/awdtools/modeler/
• Pagina de Craig larman

http://www.craiglarman.com/wiki/index.php?title=Main_Page
• Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos.
Mexico D.F. Prentice-Hall Hispanoamericana.
• Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT.
Mexico D.F. Prentice Hall Hispanoamericana.
Análisis de Sistemas - Unidad V César Luza Montero
QUINTA UNIDAD
EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO
• ¿Qué es un requerimiento?, ¿Cómo se clasifican?

• ¿Qué es un modelo de casos de uso?¿Cuáles son sus elementos?
• ¿Cómo se construye un modelo de casos de uso?
Lección 10
Conceptos asociados los requerimientos

La importancia de la especificación y análisis de requerimientos en un proyecto de
desarrollo de software es evidente; pues, sirve de base para planificación del proyecto y
para verificar si el producto software es de calidad, en otras palabras, si se han cubierto o
no las necesidades de los usuarios/clientes.
Muchos proyectos fracasan por una mala definición, especificación y administración de
requerimientos; la experiencia ha demostrado que las actividades relacionadas con los
requerimientos es compleja, por la falta de participación de los usuarios, lenguaje
distinto entre desarrolladores y usuarios, requerimientos cambiantes, entre otras
razones.
Por ello, es importante para el profesional involucrado en proyectos de desarrollo de
software poseer las suficientes competencias para la captura y administración de los
requerimientos a fin de afrontar con éxito esta tarea.
En esta lección se define y caracteriza el concepto de requerimientos y se describen
técnicas para la captura de los mismos.
1.1 ¿Qué es un requerimiento?

“Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que
se construye.” (Jacobson, 2000)
De acuerdo con la IEEE Std. 610.12-1990, “un requisito es: (1) Una condición o capacidad
necesaria para un usuario para resolver un problema o conseguir un objetivo. (2) Una
condición o capacidad que debe reunir o poseer un sistema o componente de un sistema
para satisfacer un contrato, estándar, especificación, u otro documento formalmente
impuesto. (3) Una representación documentada de una condición o capacidad como las
definidas en (1) o (2)” (IEEE, 1990).
“Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restricción de éste” (Somerville, 2005).
1.2 Tipos de Requerimientos

Los requerimientos se pueden dividir en dos tipos: Requerimientos Funcionales y
Requerimientos No funcionales.
1.2.1 Requerimiento Funcional

Un Requerimiento funcional es un requerimiento que especifica una acción que debe ser
capaz de realizar el sistema, sin considerar restricciones físicas; es un requisito que
especifica comportamiento de entrada / salida del sistema (Jacobson, 2000).
El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su
entorno. En otras palabras, refleja las necesidades de los usuarios o la interacción con
otros sistemas.
Por ejemplo, los usuarios de un Sistema de Gestión Académica para la Universidad
pueden ser profesores y alumnos, algunos requerimientos funcionales son:
El sistema permitirá a los profesores: Consultar los horarios de sus cursos, Consultar la
programación de los exámenes, Actualizar y ver su información personal, Registrar y
modificar las notas de los estudiantes a su cargo, Cerrar un curso
El sistema permitirá a los estudiantes: Consultar los horarios de sus cursos, Consultar la
programación de los exámenes, Actualizar y ver su información personal, Consultar notas
de un curso.
1.2.2 Requerimiento No funcional

Un Requerimiento No funcional es un requerimiento que especifica propiedades del
sistema, como restricciones del entorno o de implementación, rendimiento, dependencia
de la plataforma, mantenibilidad, extensibilidad o fiabilidad; especifica restricciones
físicas sobre un requisito funcional (Jacobson, 2000).
Un requerimiento no funcional describe atributos del sistema o del ambiente en donde
éste se desarrolla.
Algunos ejemplos de requerimientos no funcionales son:
• El sistema debe brindar una interfaz de usuario intuitiva y sencilla, con un buen
mecanismo de ayuda on-line.
• El sistema debe disponer de una documentación adecuada que facilite las tareas
de mantenimiento..
• La tasa de disponibilidad del sistema debe ser de un 99%.
1.3 Clasificación de Requerimientos: Modelo FURPS

Una manera de categorizar los requerimientos está descrita en el modelo FURPS (Larman,
2002): Functionality (Funcionalidad), Usability (Capacidad de Uso), Reliability (Fiabilidad),
Performance (Desempeño) y Supportability (Capacidad de Soporte).
Functionality (Funcionalidad), son aquellos requerimientos que reflejan las características
fundamentales (requerimiento funcional o funcionalidades del sistema), además de
capacidades y seguridad.
Usability (Capacidad de Uso), son aquellos requerimientos que representan facilidad o
nivel de uso del producto; es decir, el grado en el que el diseño de un elemento facilita o
dificulta su manejo. Se incluyen: Factores humanos, Estética, Consistencia de la interfaz
de usuario, Ayudas en línea, Agentes y wizards, Documentación de usuario y material de
entrenamiento. Por ejemplo, Visibilidad del texto a una cierta distancia y Combinación de
colores del texto.
Reliability (Fiabilidad), son aquellos que muestran la capacidad de un sistema o
componente para ejecutar sus funciones requeridas bajo condiciones normales en un
periodo de tiempo especifico. Tiene siguientes sub-categorías: Disponibilidad, especifica
el porcentaje de tiempo disponible, horas de uso, acceso para mantenimiento, etc.;
Tiempo medio entre fallas; Tiempo medio para reparación, cuánto tiempo es posible que
el sistema esté inoperante después que falla; Exactitud: se especifica la precisión y
exactitud (según algún estándar conocido) que se requiere para las salidas del sistema;
Cantidad máxima de errores o porcentaje de defecto, generalmente expresado en
términos de errores por miles de líneas de código o errores por punto funcional; Errores
o porcentaje de defecto, categorizados en términos de errores menores, significantes y
críticos (se debe definir que significa error “crítico”, por ejemplo pérdida completa de
dato o imposibilidad de uso de ciertas funcionalidades del sistema.
Performance (Desempeño), se refieren a las características de rendimiento del sistem.
Incluye tiempos de respuesta específicos. Por ejemplo: Tiempo de respuesta para una
transacción (promedio, máximo); Transacciones por segundo; Capacidad, como por
ejemplo el número de clientes o transacciones que el sistema puede soportar; Modos de
degradación, esto es, cual es el modo aceptable de funcionamiento cuando el sistema ha
sido degradado de alguna manera; Utilización de recursos: memoria, disco,
comunicaciones, etc.
Supportability (Capacidad de Soporte), son requerimientos que refuerzan el soporte y
mantenimiento del sistema que está siendo construido, incluyendo normas de
codificación, convenciones de nombres, librerías, acceso para mantenimiento, utilidades
de mantenimiento si las hay. Como requerimiento que ayuda al mantenimiento se debe
hacer referencia al uso de nomenclatura común para el desarrollo del sistema, y a la
metodología de desarrollo.
ALGUNOS REQUERIMIENTOS FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA FACULTAD

DE INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES
El sistema permitirá al secretario académico, introducir las asignaturas que se imparten en el semestre
académico, los datos del docente asignado a cada sección, de teoría y práctica, de la asignatura, los datos
de las aulas de teoría (ubicación y aforo) y de prácticas (ubicación, sistemas operativos, software,...).
La configuración del horario se lleva a cabo directamente sobre una plantilla horaria semanal, en la que
cada casilla representará una hora en un determinado día de la semana. Cuando el Secretario pulsa esa
casilla se mostrarán las asignaturas del curso que se esté configurando en ese momento. Una vez escogida
las asignaturas se mostrarán las secciones de teoría y práctica a los que todavía no se les ha asignado un
horario. Al escoger una sección se muestran las aulas disponibles (si es un grupo de teoría) o los
laboratorios que cumplen las restricciones de sistemas operativos establecidas para esa materia y que no
están ocupados a esa hora.
El sistema podrá ser consultado por cualquier usuario, que podrá consultar el horario de una asignatura,
un ciclo, o de un aula o laboratorio concretos.
ALGUNOS REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA

FACULTAD DE INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES
La tasa de disponibilidad del sistema debe ser de un 99%. El sistema debe tener una interfaz de uso
intuitiva y sencilla, complementada con un buen sistema de ayuda. El sistema debe disponer de una
documentación fácilmente actualizable que permita realizar operaciones de mantenimiento con el menor
esfuerzo posible.
1.4 Características de los Requerimientos

Un requerimiento debe ser:
• Especificado por escrito, como todo contrato o acuerdo entre dos partes.
• Posible de probar o verificar, si un requerimiento no se puede comprobar,
entonces, ¿como se sabe si se cumplió con él o no?
• Conciso, un requerimiento es conciso si es fácil de leer y entender. Su redacción

debe ser simple y clara para aquello que vayan a consultarlo en el futuro.
• Completo, un requerimiento esta completo si no es necesario ampliar detalles en
su redacción, es decir si se proporciona la información suficiente para su
comprensión.
• Consistente, un requerimiento es consistente si no es contradictorio con otro
requerimiento.
• No ambiguo, un requerimiento no es ambiguo cuando tiene una sola
interpretación. El lenguaje usado en su definición, no debe causar confusión en el
lector.
1.5 Dificultades para definir los Requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes
• Son difíciles de expresar en palabras (el lenguaje es ambiguo)
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• El usuario no puede explicar lo que hace.
• El usuario tiende a recordar lo excepcional uy olvidar lo rutinario
• Hablan de lo que no funciona
• Los usuarios tiene distinto vocabulario que los desarrolladores
• Usan el mismo termino con distinto significado
1.6 Técnicas para obtener Requerimiento
1.6.1 Entrevistas
Esta técnica es adecuada para la primera toma de contacto. Es conveniente comenzar por
preguntas de contexto libre, para entender: el problema, a las personas interesadas en la
solución, naturaleza de ésta, y lograr efectividad de la reunión.
Ejemplos de preguntas centradas en el cliente, los objetivos globales y beneficios
• ¿Quién solicita el trabajo?
• ¿Quién utilizará la solución?
• ¿Cuál será el beneficio económico de una buena solución?
• ¿Existen otras alternativas a esta solución?
Ejemplos de preguntas sobre el problema y la solución

• ¿Qué entiende el cliente por una solución “correcta”?
• ¿Qué problemas afrontará esta solución?
• ¿En qué entorno se va a implantar la solución?
• ¿Existen restricciones o aspectos de rendimiento importantes?
Ejemplo de preguntas sobre la efectividad de la reunión

• ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas
son “oficiales”?
• ¿Son relevantes mis preguntas para su problema?
• ¿Hay alguien más que pueda proporcionar información adicional?
• ¿Hay algo más que debería preguntar?
Problemas de las entrevistas:

• Pueden surgir malentendidos
• Omisión de información
• Mala relación de trabajo (“nosotros-ellos”)
1.6.2 JAD
El Diseño en Conjunto de Aplicaciones (JAD, “Joint Application Design”) fue desarrollado
por IBM a finales de los setenta. Es una sesión de trabajo con participación de todos los
involucrados. El resultado de la sesión es un documento de especificación que incluye
definiciones de elementos de datos, flujos de trabajo y pantallas de interfaz.
El resultado de una sesión JAD representa un acuerdo entre usuarios, clientes y
desarrolladores y minimiza los cambios posteriores de requerimientos.
Las actividades de la sesión JAD son: Definición del proyecto , Investigación, preparación,
Sesión, preparación del documento final.
Definición del proyecto: el coordinador se entrevista con gerentes y clientes para
determinar objetivos y alcance del proyecto. Se elabora la “guía de definición
administrativa”.
Investigación: se entrevista a usuarios y se recopila información del dominio, descripción
de flujos de trabajo y asuntos a tratar en la reunión. Se elabora la “agenda de sesión” y la
“especificación preliminar”.
Preparación: el coordinador elabora un “documento de trabajo” o primer borrador del
documento final.
Sesión: el coordinador guía al equipo para crear la especificación del sistema en una
reunión que puede durar varios días. Se definen los flujos de trabajo, elementos de datos,
pantallas, informes,... Las decisiones se documentan en unos formularios.
Preparación de documento final: el coordinador prepara el “documento final” usando los
“formularios” y se distribuye a los asistentes para su revisión. Se realiza una reunión para
discutir revisiones y finalizar el documento.
Lección 11
Conceptos asociados al Modelo de casos de uso

Se han establecido diversas técnicas para la especificación de requerimientos. La técnica
de casos de uso (Jacobson, 93) se ha constituido en el estándar universal para capturar
requerimientos de sistemas software. Los casos de uso no solo sirven para captura
requerimientos de sistemas software, sino que tienen gran influencia sobre todas las
fases del proceso de desarrollo.
11.1 ¿Qué es el modelo de casos de uso?

El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del
sistema en forma de Casos de uso. Su objetivo es comunicar la funcionalidad y el
comportamiento al cliente y usuario.
El modelo de casos de uso esta compuesto por actores, casos de uso, descripción de cada
caso de uso y el diagrama de casos de uso.
11.2 Actor
Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con él. Una instancia de actor puede ser un individuo o un sistema
externo. La notación UML para el actor se muestra en la figura 11.1.
Por ejemplo, en el Sistema de Académico de la universidad, los actores pueden ser:
Secretario Académico, Alumno y Docente. Todos ellos interactúan con el sistema a través
de alguna de sus funcionalidades. Nótese que el nombre del actor represente el rol que
desempeñan grupos de usuarios, por ejemplo el rol alumno representa a todos los
alumnos; un alumno particular representa una instancia del actor alumno.
Figura 11.1 Actor
11.3 Caso de Uso

Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una
secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a
un actor particular (Jacobson, 93). La figura 11.2 muestra la notación UML de caso de uso.
Por ejemplo, consideremos el siguiente escenario para realizar el Retiro de Dinero de un
Cajero Automático:
Escenario Normal
1. E cliente inserta su tarjeta en la ranura del cajero automático
2. El cajero automático solicita ingreso de clave secreta
3. El cliente ingresa su clave secreta
4. El cajero automático muestra menú de opciones
5. El cliente selecciona opción “Retiro”
6. El cajero automático muestra relación de cuentas del cliente

7. El cliente eligen cuenta
8. El cajero automático solicita cantidad
9. El cliente ingresa cantidad a retirar
10. El cajero automático dispensa el dinero y termina.
Esta secuencia de interacciones entre el cliente y el cajero automático termina, de forma
normal, se dispensa el dinero del cliente.
Otras secuencias que no siguen este flujo normal, pueden ser:
Escenario: clave incorrecta
4. El cajero automático muestra mensaje de error “Clave incorrecta”
Escenario: Saldo insuficiente
4. El cajero automático muestra menú de opciones
5. El cliente selecciona opción “Retiro”
6. El cajero automático muestra relación de cuentas del cliente
7. El cliente eligen cuenta
8. El cajero automático solicita cantidad
9. El cliente ingresa cantidad a retirar
10. El cajero automático muestra mensaje de error “Saldo Insuficiente”.
Podemos decir que este conjunto de escenarios corresponde al caso de uso Retiro de
Cajero Automático.
En conclusión, un caso de uso proporciona uno o más escenarios que indica como debe
interactuar el usuario con el sistema o con otro sistema para conseguir un objetivo
particular.
Figura 11.2 Caso de uso
11.4 Descripción de caso de uso

Se han establecido diversas plantillas para describir un caso de uso. Larman (2002) señala
que la descripción de un caso de uso, básicamente, debe contener: Nombre del caso de
uso, Actor, Precondiciones, Poscondiciones, Flujo básico y Flujos alternativos.
El nombre del caso de uso debe ser claro e indicar la función requerida que el sistema
debe proveer a los actores. Por ejemplo, Registrar Matricula de estudiante.
El nombre del Actor, por ejemplo Estudiante
Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor. Establecen lo que siempre debe cumplirse antes de comenzar un escenario en un
caso de uso. Normalmente implica que un escenario de otro caso de uso se ha
completado exitosamente. Estas deben redactarse en tiempo verbal pasado. Por ejemplo:
El usuario ha sido aceptado en el sistema con el rol de profesor.
Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la garantía de éxito. Estas deben redactarse en tiempo verbal pasado. Por
ejemplo: Se ha registrado en el sistema las notas de los alumnos.
El flujo básico, es la descripción narrativa de lo que debe ocurrir cuando los actores
interactúan con el sistema para satisfacer la meta u objetivo propuesto, se consideran los
pasos normales, no incluye las alternativas o variaciones.
Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del
flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales,
condiciones de error o violaciones de reglas.
Ejemplo de flujo básico:
1. El Caso de uso comienza cuando el profesor indica “registrar notas.”
2. El sistema muestra un formulario de validación de ingreso al sistema.
3. El usuario ingresa su código y su contraseña.
4. El sistema muestra los cursos asignados al profesor.
5. El profesor selecciona el curso.
6. El sistema muestra un listado de los estudiantes con sus notas.
7. El profesor selecciona el estudiante e ingresa la nota de práctica, del parcial, del
examen final y la nota final. Se repite para cada estudiante.
8. El profesor indica “guardar”.
9. El sistema valida toda la información y muestra un mensaje de confirmación y el
Caso de uso finaliza.
Ejemplos de flujos alternativos:

Código o Contraseña errados:
En el paso 4, si código o contraseña digitados por el usuario son erradas, el sistema
muestra mensaje de error y vuelve a solicitar código y contraseña.
Profesor sin cursos asignados:
En el paso 4, si el sistema determina que el profesor no tiene cursos asignados,
muestra mensaje de error y el caso de uso finaliza.
11.5 Diagrama de casos de uso

Un diagrama de caso de uso muestra los actores los casos de uso y las relaciones entre
ellos. La figura 11.3 muestra un ejemplo de diagrama de casos de uso, para un sistema de
gestión académica. Se observa dos actores: profesor y alumno, mediante la relación de
generalización se puede afirmar que el profesor y el alumno son dos tipos de usuarios,
Los casos de uso comunes para ambos son: consultar horarios, validar acceso y consultar
horario de exámenes. Particularmente, el estudiante puede consultar notas de un curso y
mantener información del estudiante. El profesor puede mantener información de

profesor, registrar notas de un curso y cerrar un curso.
Figura 11.3 Diagrama de casos de uso
Consultar notas de un curso

Estudiante
Consultar horarios de cursos (f rom Actors)
Mantener información del estudiante

Cerrar un curso
Validar acceso
Usuario
Mantener información del profesor
(f rom Actors )
Consultar horario de exámenes

Profesor
Registrar notas de un curso
(f rom Actors)
Relaciones entre casos de uso

Entre dos casos de uso puede haber las siguientes relaciones: Extend e includes. Una
relación extend se cuando un caso de uso especializa a otro extendiendo su
funcionalidad. Una relación include se usa cuando un caso de uso incluye a otro. Se
representan como una línea que une a los dos casos de uso relacionados, con una flecha
en forma de triángulo y con una etiqueta <<extiende>> o <<include>> según sea el tipo de
relación.
Lección 12
Proceso de construcción del modelo de casos de casos de uso

En esta lección se presentan los pasos a seguir para la construcción de un modelo de
casos de uso; para tal efecto, consideremos la siguiente descripción de requerimientos:
La Empresa AIRTRANS, dedicada al servicio de transportes aéreos, necesita un sistema de

información para gestionar y mantener los datos de unidades, vuelos, pilotos, pasajeros y reservas.
Después de haber dialogado con el Encargado de Vuelos se concluyo que es responsable de
Mantener la información de las distintas unidades: el número, el tipo de avión, la fecha de compra,
el modelo, la capacidad de carga y la capacidad de pasajeros. Determina los vuelos que llevan carga,
para los mismos necesita guardar la fecha, el piloto, el lugar de origen, el destino, el peso de la carga
y el monto del vuelo. Define los vuelos de pasajeros: fija la fecha, el piloto y su tripulación, origen,
destino y capacidad de pasajeros.
El gerente nos informó que: Mantiene la información de los pilotos que trabajan en la empresa, para
el mismo guarda el número de piloto, el nombre, dirección, habilitación, fecha del último control
médico. Necesita que el sistema le devuelva dado un piloto, los vuelos que ha realizado en un
periodo dado.
El empleado de ventas nos explicó que: Mantiene información de los pasajeros de los diferentes
vuelos, para cada uno se le incorpora un número de identificación, el nombre, profesión, el teléfono
y la dirección. Los pasajeros realizan reservas para los distintos vuelos, si no hay espacio disponible,
se rechaza el pedido de reserva para ese vuelo. Confirma los pasajeros que toman los vuelos. Sólo se
admiten pasajeros que hayan realizado reservas previas. Necesita un reporte con los pasajeros que
tomaron un vuelo.
12.1 Identificando actores

Para identificar actores, podemos preguntar ¿Quién está interesado en cierto
requerimiento o se beneficia o se ve afectado por algún servicio del sistema?, ¿Dónde en
la organización será usado el sistema?, ¿Quienes usan, eliminan o suministran
información en el sistema?, ¿Quién usa una determinada función del sistema?. Las
respuestas a estas preguntas pueden considerar grupo de personas, departamentos u
otros sistemas.
En nuestro caso, los actores identificados son:
Encargado de Gerente Empleado de

vuelos ventas
12.2 Identificando casos de uso

Para identificar casos de uso se sugiere preguntar: ¿Cuáles son las tareas que realiza el
actor?, ¿Que objetivos concretos necesita alcanzar un actor?, ¿Puede el actor crear,
almacenar, remover o leer información en el sistema?, El actor, ¿necesita estar informado
acerca de las ocurrencias del sistema? Las respuestas a estas preguntas reflejan
funcionalidades del sistema para cada actor.
En nuestro caso, el actor Encargado de vuelo debe: Mantener información de unidades,
Registrar vuelo de carga y Registrar vuelo de pasajeros. El Gerente debe: Mantener
información de pilotos y Consultar vuelos por piloto. El Empleado de Ventas: Mantener
información de pasajeros, Registrar reserva de vuelo, Registrar confirmación de vuelo y
Consultar pasajeros que tomaron vuelo.
Mantener informacion de unidades Registrar vuelo de carga Registrar vuelo de pasajeros
Mantener informacino de pilotos Consultar vuelos por pilotos Mantener informacion de pasajeros
Registrar reservas de vuelo

Registrar confirmación de vuelo Consultar pasajeros que tommaron
vuelo
12.3 Elaborando la descripción de casos de uso

Por cada caso de uso se elabora su descripción. En nuestro caso, solo desarrollaremos
descripción de algunos casos de uso.
Nombre C.U.S. Consultar Vuelos por Piloto

Actor Gerente
Precondición El usuario ha sido admitido en el sistema con el rol de Gerente
Poscondición El sistema muestra los vuelos realizados por piloto
Flujo Básico
1. El caso de uso se inicia cuando el Gerente indica “Vuelos Realizados”.
2. El sistema muestra, en una ventana, relación de pilotos, en otra ventana el calendario
para escoger el periodo (fecha inicio y fecha de fin) y un botón “Aceptar”.
3. El Gerente escoge el nombre de piloto de la relación mostrada.
4. El Gerente escoge el periodo (fecha inicio y fecha de fin).
5. El Gerente indica “Aceptar”.
6. El sistema muestra los datos del piloto, los vuelos realizados por piloto en el periodo
escogido.
7. El sistema habilita botones “Regresar” y “Imprimir”
8. El Gerente indica “Regresar”
9. El caso de uso finaliza.
Flujos Alternativos
Imprimir
En el paso 7, si el gerente indica “Imprimir”, el sistema imprime la información consultada.
No hay vuelos en periodo
En el paso 6, si no existen vuelos del piloto en el periodo seleccionado, el sistema muestra
mensaje “Piloto no tiene registrado vuelos en el periodo” y regresa a solicitar información.
Nombre C.U.S. Mantener información de unidades

Actor Encargado de vuelos
Precondición El usuario ha sido admitido en el sistema con el rol de Encargado de vuelos
Poscondición Se ha registrado información de unidades
Flujo Básico
Ingresar
1. El caso de uso comienza cuando el Encargado de Vuelo indica “Mantener Información
de unidad”.
2. El Sistema muestra las opciones: “Ingresar”, “Modificar” y “Eliminar”.
3. El Encargado de Vuelo elige la opción “Ingresar”.
4. El Sistema muestra el formulario para llenar datos de una nueva unidad.
5. El Encargado de Vuelo ingresa datos de la unidad: el número, el tipo de avión, la fecha
de compra, el modelo, la capacidad de carga y la capacidad de pasajeros.
6. El Encargado de Vuelo indica “Guardar”.
7. El Sistema registra la información de la nueva unidad.
Flujos Alternativos
Modificar
1. El flujo se inicia cuando el Encargado de Vuelo elige la opción “Modificar”.
2. El Sistema muestra relación de unidades
3. El Encargado de Vuelo selecciona unidad cuyo datos desea modificar
4. El Sistema muestra formulario con los datos de la unidad a modificar
5. El Encargado de Vuelo realiza modificaciones
6. El Encargado de Vuelo indica “Guardar”.
7. El Sistema registra las modificaciones.
Eliminar
1. El flujo se inicia cuando el Encargado de Vuelo elige la opción “Eliminar”.
2. El Sistema muestra relación de unidades.
3. El Encargado de Vuelo selecciona unidad que desea eliminar.
4. El Sistema muestra formulario con datos de unidad a eliminar.
5. El Encargado de Vuelo indica “Confirmar”
6. El Sistema registra la eliminación de la unidad.
Cancelar
1. En cualquier momento, el usuario indica “Cancelar”, entonces,
2. El sistema no registra dato alguno y el caso de uso finaliza.
Código Repetido
1. En el paso 7 de ingresar y 7 de modificar, si el número de unidad se repite,
2. El sistema muestra un error y regresa a solicitar datos
12.4 Elaborando el diagrama de casos de uso

Se asocia cada actor con su caso de uso, obteniéndose el siguiente diagrama de casos de
uso
Registrar vuelo de carga

Mantener información de unidades
Encargado de
vuelos
Registrar vuelo de pasajeros
Consultar vuelos por pilotos

Gerente
Mantener información de pilotos
Mantener informacion de pasajeros

Registrar reservas de vuelo
Empleado de
ventas
Consultar pasajeros que tommaron

vuelo
Registrar confirmación de vuelo
Resumen
Conceptos asociados a los requerimientos
• Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se
construye. Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restricción de éste
• El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su entorno.
• Un requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se
desarrolla. Pueden ser de: usabilidad, fiabilidad, desempeño, capacidad de soporte.
• La entrevista es una técnica para obtener requerimientos usada en las primeras tomas de
contactos con los usuarios-clientes.
• El diseño conjunto de aplicaciones, Joint Application Design (JAD) es una sesión con
participación de todos los involucrados, cuyo resultado es un documento de
especificación.
Conceptos asociados al modelo de casos de uso
• El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del
sistema en forma de Casos de uso.
• Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con él.
• Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una
secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a
un actor particular.
• Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor
• Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la garantía de éxito.
• Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del
flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales,
condiciones de error o violaciones de reglas.
• Un diagrama de caso de uso muestra los actores los casos de uso y las relaciones entre
ellos.
Proceso de construcción del modelo de casos de uso
• Identificación de actores
• Identificación de casos de uso
• Elaboración de descripción de casos de uso
• Elaboración de diagrama de casos de uso
Lectura
Crear el diseño lógico de una interfaz de usuario (*)
Cuando los actores interactúan con el sistema, utilizaran y manipularan elementos de interfaces
de usuario que representan atributos (de los casos de uso). A menudo estos son términos del
glosario (por ejemplo, balance de cuenta, fecha de vencimiento y titular de cuenta). Los actores
pueden experimentar estos elementos de las interfaces de usuario como iconos, listas de
elementos u objetos en un mapa 2D, y pueden manipularlos por selección, arrastre o hablando
con ellos. El diseñador de interfaces de usuario identifica y especifica estos elementos actor por
actor, recorriendo todos los casos de uso a los que el actor puede acceder, e identificando los
elementos apropiados de la interfaz de usuario para cada caso de uso. Un único elemento de
interfaz de usuario puede intervenir en muchos casos de uso, desempeñando un papel diferente
en cada uno. Así, los elementos de la interfaz de usuarios pueden diseñarse para jugar varios
roles. Deberíamos responder a las siguientes preguntas por cada actor:
• ¿Qué elementos de interfaz de usuario se necesitan para posibilitar el caso de uso?
• ¿Cómo deberían relacionarse unos con otros?
• ¿Cómo se utilizaran en los diferentes casos de uso?
• ¿Cuál debería ser su apariencia?
• ¿Cómo deberían manipularse?
Para determinar qué elementos de interfaz de usuario necesitan ser accesibles al actor en cada
caso de uso, podemos contestar las siguientes preguntas:
• ¿Qué clases de dominio, entidades del negocio o unidades de trabajo son adecuados
como elementos de la interfaz de usuario para cada caso de uso?
• ¿Con qué elementos de la interfaz de usuario va a trabajar el actor?
• ¿Qué acciones puede invocar el actor, y qué decisiones puede tomar?
• ¿Qué guía o información va a necesitar el actor antes de invocar cada acción de los casos
de uso?
• ¿Qué información debe proporcionar el actor al sistema?
• ¿Qué información debe proporcionar el sistema al actor?
• ¿Cuáles son los valores medios de todos los parámetros de entrada o salida? Por ejemplo,
¿Cuántas facturas manejará habitualmente un actor durante una sesión y cuál es el saldo
medio de la cuenta? Necesitamos estimaciones aproximadas de estas cosas porque asi se
optimizará la interfaz gráfica de usuario para ellas (incluso aunque tengamos que permitir
un rango suficientemente grande).
Una forma práctica de trabajo es representar los elementos de la interfaz de usuario mediante
notas adhesivas, pegadas en una pizarra, y ordenadas para ilustrar la apariencia de la interfaz de
usuario. Seguidamente, los diseñadores de interfaces de usuario describen cómo pueden utilizar
los actores estos elementos cuando trabajen con los caso de uso. La ventaja de utilizar notas
adhesivas es que pueden representar la cantidad necesario a de datos. Además, las notas
adhesivas tampoco parecen permanentes .es fácil moverlas o simplemente eliminarlas-, lo que
hace que el usuario se sienta cómodo proponiendo cambios.
(*) Jacobson (2000).
Actividades
1. Desarrollar el modelo de casos de uso para el siguiente sistema para una agencia de alquiler
de autos
Inicialmente, entrevistamos al dueño de la agencia, quien es el que impulsó el proyecto. Él

está, especialmente, interesado en controlar los gastos de la empresa. Necesita obtener
del sistema información del tipo: Dado un intervalo de tiempo, todas las reparaciones
realizadas por un monto superior al que él imponga.
El Empleado de Atención al Público, nos contó que por cada nuevo alquiler actualiza la
ficha registro del cliente. En caso de tratarse de un nuevo cliente, abre una nueva ficha
con los siguientes datos: apellido y nombre, dirección personal, localidad, provincia, tipo y
número de documento, profesión y número de licencia de conductor. De acuerdo con las
restricciones que impone el cliente, se busca si existe un vehículo disponible. Una vez que
el cliente seleccionó un coche, se crea una ficha para el nuevo alquiler: fecha del alquiler,
cantidad de días por los que se alquila, importe del alquiler y kilometraje del vehículo al
momento de ser alquilado. No se debe autorizar alquileres a clientes que no devolvieron
en el plazo o en buen estado el vehículo que se les prestó.
El Encargado de Autos es el único autorizado a actualizar la ficha registro de cada auto.
Cada vehículo tiene su propia información: código, descripción, marca (por ej: Ford
Fiesta), modelo (por ej: 1996), estado (alquilado, disponible para alquilar o en reparación).
Por cada vehículo lleva nota de todas las reparaciones que recibió. De cada reparación
mantiene la fecha, motivo, costo de la reparación, cantidad de días que el auto no estuvo
disponible. También atiende a los clientes que traen los vehículos. Controla que el mismo
se entregue en buen estado y en termino, si no es así le informa al encargado de atención
al público para que no autorice nuevos alquileres a ese cliente y registra en la ficha del
alquiler el kilometraje final con que se devuelve el coche. Le gustaría poder consultar los
autos mas alquilados.
2. Continuar el desarrollo con lo que se indica:
Para la segunda etapa de este proyecto se van a incorporar, al sistema, facilidades para
hacer reservas telefónicas. En este caso, el Empleado de Atención al Publico tomará los
datos del cliente, la fecha del alquiler, días por los que se va a alquilar y vehículo que
reserva.
Una reserva puede ser cancelada con hasta 48 horas de anticipación. Los clientes que
hagan reservas y no retiren el alquiler, no podrán efectuar nuevas reservas ni alquileres.
Al final de cada jornada, el Encargado de Autos lanzara un proceso que analizase las
reservas para el próximo día y marque los autos que corresponda como reservados.
Autoevaluación
1. Un requerimiento es:
2. Las diferencias entre un requerimiento funcional y no funciona son:
3. Los requerimientos se caracterizan por:
4. Cuando usaría las técnicas de entrevista y JAD
5. El modelo de casos de uso representa
6. El actor es
7. El caso de uso es
8. Un escenario de caso de uso es
9. Una precondición es
10. Una poscondición es
11. La diferencia entre flujo básico y flujo normal es
• Sitio de Alistair Cockburn, sobre recursos e información de casos de uso
http://alistair.cockburn.us/
• IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
–Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
• Jacobson,I., et al, (1993). Object-Oriented Software Engineering: A Use case Driven Approach.
USA. Addison Wesley.
• Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos.
Segunda Edición. Madrid. Pearson Educación S.A.
• Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial Pearson.
GLOSARIO
• Actividad Es una unidad de trabajo que debe ser ejecutada en un proceso de desarrollo de
software.
• Artefacto Es una pieza de información que es producida, modificada o usada en un proceso
de desarrollo de software.
• Flujo de trabajo Es una secuencia de actividades que produce un resultado valioso, define una
lista de actividades, trabajadores y artefactos.
• Metodología Es el conjunto de procedimientos, técnicas, herramientas, y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software
• Modelo de análisis de negocios Describe la realización de los casos de uso del negocio
mediante la interacción de los trabajadores del negocio y las entidades del negocio.
• Modelo de casos de uso Es un modelo que describe los requerimientos funcionales del
sistema en forma de casos de uso.
• Modelo de casos de uso del negocio Es una representación de la forma en que la empresa
interactúa con su entorno.
• Modelo de dominio Es un modelo conceptual que muestra clases conceptuales de objetos
significativos en un dominio de problema. Las clases conceptuales no muestran componentes
software, ni clases software, ni responsabilidades
• Organización Sistema compuesto por un conjunto de personas, actividades y recursos,
distribuidas de alguna forma (generalmente en departamentos o funciones) con arreglo a
ciertas reglas de división del trabajo y comunicación que interactúan para producir bienes o
servicios
• Proceso de desarrollo Es una guía acerca de las actividades y tareas necesarias para construir
un sistema de información.
• Proceso de negocio Conjunto de actividades que toman uno o más imputs crean un outputs
de valor para el cliente.
• RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de
software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de
desarrollo, es decir define quién hace qué, cuándo y cómo.
• Trabajador Es un rol que debe ser realizada por una persoa o equipo dentro de un proceso de
desarrollo de software..
• Sistema de información Conjunto de componentes hardware, software, base de datos,
procedimientos y personas, que permiten capturar, procesar, almacenar y distribuir
información para una organización.
• UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado
en una notación gráfica, que permite: especificar, construir, visualizar y documentar los
elementos de un sistema software, así como para modelar los procesos de negocios u otros
sistemas no software.
Una
Institución Análisis de Sistemas - Unidad V César Luza Montero
Educativa ha
decidido
brindar
BIBLIOGRAFIA
1 Davenport, Thomas (1996). Innovación de Procesos: Reingeniería del trabajo a través de la
tecnología de la información. España. Díaz Santos.
2 Hammer, Michel y James Champy (1993), Reengineering the Corporation: A Manifesto for
Business Revolution. USA. Collins Business Essentials.
3 Harris, David (1996). Creating a Knowledge Centric Information Technology Environment. USA.
Editorial Harris Training & Consulting Services Inc.
4 IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering
Terminology –Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
5 Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
6 Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML.
7 Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos.
Mexico D.F. Prentice-Hall Hispanoamericana.
8 Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos.
Segunda Edición. Madrid. Pearson Educación S.A.
9 Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Información Gerencial. 8ª Ed. México
D.F. Pearson Educación.
10 Laudon, Jane y Kenneth (2006). Sistemas de información gerencial, Administración de la
empresa digital. México D.F. Pearson Educación- Prentice Hall.
11 Pressman , Roger S. (2002) Ingeniería de Software. Un enfoque práctico. 5ta.Ed. Mc Graw Hill,
España.
12 Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT.
Mexico D.F. Prentice Hall Hispanoamericana.
13 Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial
Pearson.

Analisis de Sistemas

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Analisis de Sistemas

Uploaded by

Copyright:

Available Formats

Facultad de Ingeniería de Sistemas, Cómputo y

CÉSAR LUZA MONTERO

La segunda unidad comprende los temas relacionados con el proceso de desarrollo de

La asignatura de Análisis de Sistemas es de formación profesional especializada, de

Organización y procesos de negocios

1.1.1 ¿Qué es una organización?

Figura 1.1 Componentes de una organización

Entradas ACTIVIDADES Bienes/Servicios

Las personas representan el recurso más importante de la organización, juegan distintos

1.1.2 Estructura organizacional

Figura 1.2 Estructura funcional

Investigación Producción Finanzas Ventas

Estructura por procesos

Figura 1.3 Organización por procesos

Proceso de negocio (Flujo de actividades)

Proceso de negocio (Flujo de actividades)

Proceso de negocio (Flujo de actividades)

1.1.3 Niveles Organizacionales

Nivel Estratégico Directores

Nivel de Trabajadores del

Nivel Operativo Gerentes

Fuente: (Adaptado de Laudon, 2004)

En esta pirámide podríamos agregar, debajo de su base, un bloque grande para

Este modelo de pirámide permite, a quienes desarrollan sistemas de información,

1.2 Procesos de negocio

1.2.1 ¿Qué es un proceso de negocio?

VENTAS CONTABILIDAD MANUFACTURA

Recibir Verificar Producir

Iniciar Facturar Enviar

Algunos ejemplos de proceso de negocios son: Proceso de Admisión, Proceso de

1.2.2 Clases de procesos de negocio

1.2.3 ¿Cómo se describe un proceso de negocio?

En la figura 1.6, se describe el proceso de Registrar Pedido de manera grafica, usando la

Existen diversas técnicas y herramientas para describir, de manera gráfica, un proceso de

Introducción a los Sistemas de información

2.1 Concepto de Dato, Información y Conocimiento

Fuente: (Adaptado de Harris, 1996)

2.2 ¿Qué es Sistema de información?

2.3 Componentes de un Sistema de información

2.4 Tipos de sistemas de información

Sistema de automatización de oficinas (Office Automation System - OAS) son

Organización y Procesos de Negocio

Introducción a los sistemas de información

(*) Fuente: ebiz News

EL PROCESO DE DESARROLLO, RUP Y UML

¿Qué es un proceso de desarrollo, cuales son sus fases y actividades genéricas?

Proceso de desarrollo de sistemas de información

3.1 Proceso de desarrollo, una visión genérica

3.1.1 ¿Qué es un proceso de desarrollo?

Fuente: (Pressman, 2002)

3.1.2 Fase de Definición

3.1.3 Fase de Desarrollo

3.1.4 Fase de Evolución

Mejora. Conforme utilice el software, el usuario puede descubrir funciones adicionales

3.2 Modelos de Proceso de desarrollo de software

3.2.1 Modelo Lineal Secuencial

Análisis de Requerimientos Diseño Codificación Prueba Mantenimiento

3.2.2 Modelo Construcción de Prototipos

Fuente: (Adaptado de Pressman, 2002)

3.2.3 Modelo Desarrollo Rápido de Aplicaciones (DRA)

Fuente: (Pressman, 2002)

En este modelo, cuando el proyecto es grande, se requiere un gran número de personas

3.2.4 Modelo Incremental