Libro de Analisis de Sistemas - UNMSM

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA

CARRERA PROFESIONAL DE INGENIERIA DE SISTEMAS
ANLISIS DE SISTEMAS
CSAR LUZA MONTERO
LIMA-PER, 2012
NDICE
PRESENTACIN
6
INTRODUCCIN
7
ORIENTACIONES METODOLGICAS 9
PRIMERA UNIDAD
10
LOS SISTEMAS DE INFORMACIN EN LAS ORGANIZACIONES
10
Leccin 1.......................................................................................................................
Organizacin y procesos de negocios...........................................................................
1.1
Organizacin...................................................................................................
1.1.1
Qu es una organizacin?..........................................................................
1.1.2
Estructura organizacional.............................................................................
1.1.3
Niveles Organizacionales.............................................................................
1.2
Procesos de negocio........................................................................................
1.2.1
Qu es un proceso de negocio?..................................................................
1.2.2
Clases de procesos de negocio....................................................................
1.2.3
Cmo se describe un proceso de negocio?.................................................
Leccin 2.......................................................................................................................
Introduccin a los Sistemas de informacin..................................................................
2.1
Concepto de Dato, Informacin y Conocimiento..............................................
2.2
Qu es Sistema de informacin?....................................................................
2.3
Componentes de un Sistema de informacin..................................................
2.4
Tipos de sistemas de informacin....................................................................
Resumen.......................................................................................................................
Lectura..........................................................................................................................
Actividades...................................................................................................................
Autoevaluacin.............................................................................................................
Exploracin on-line.......................................................................................................
Referencias bibliogrficas.............................................................................................
SEGUNDA UNIDAD 26
EL PROCESO DE DESARROLLO, RUP Y UML26
Leccin 3.......................................................................................................................
Proceso de desarrollo de sistemas de informacin........................................................
3.1
Proceso de desarrollo, una visin genrica......................................................
3.1.1
Qu es un proceso de desarrollo?...............................................................
3.1.2
Fase de Definicin........................................................................................
3.1.3
Fase de Desarrollo........................................................................................
3.1.4
Fase de Evolucin.........................................................................................
3.2
Modelos de Proceso de desarrollo de software................................................
3.2.1
Modelo Lineal Secuencial.............................................................................
3.2.2
Modelo Construccin de Prototipos..............................................................
3.2.3
Modelo Desarrollo Rpido de Aplicaciones (DRA).........................................
3.2.4
Modelo Incremental.....................................................................................
3.2.5
Modelo Espiral..............................................................................................
3.3
Metodologas...................................................................................................
3.3.1
RUP..............................................................................................................
3.3.2
MTRICA V3.................................................................................................
3.3.3
Merisse.........................................................................................................
3.3.4
SSADM V4....................................................................................................
3.3.5
MDSI............................................................................................................
Leccin 4.......................................................................................................................
Introduccin al UML......................................................................................................
4.1
Qu es el UML?..............................................................................................
4.2
Artefacto, Modelo y Diagrama.........................................................................
4.3
Elementos en UML...........................................................................................
4.4
Relaciones en UML...........................................................................................
4.5
Diagramas en UML..........................................................................................
Leccin 5.......................................................................................................................
Introduccin al RUP.......................................................................................................
5.1
Qu es el RUP?...............................................................................................
5.2
Elementos.......................................................................................................
5.2.1
Trabajador (Worker)......................................................................................
5.2.2
Actividad......................................................................................................
5.2.3
Artefacto......................................................................................................
5.2.4
Modelo.........................................................................................................
5.2.5
Flujos de trabajo (Workflow).........................................................................
5.3
Fases...............................................................................................................
5.3.1
Fase de Inicio...............................................................................................
5.3.2
Fase de Elaboracin.....................................................................................
5.3.3
Fase de Construccin...................................................................................
5.3.4
Fase de Transicin........................................................................................
5.4
Flujos...............................................................................................................
Resumen.......................................................................................................................
Lectura..........................................................................................................................
Actividades...................................................................................................................
Autoevaluacin.............................................................................................................
TERCERA UNIDAD
49
EL MODELADO DE NEGOCIOS
49
Leccin 6.......................................................................................................................
Conceptos asociados al modelado del Negocio.............................................................
6.1
Qu es el Modelado del Negocio....................................................................
6.2
Modelo de Casos de Uso del Negocio..............................................................
6.2.1
Actor del Negocio.........................................................................................
6.2.2
Casos de uso del negocio (CUN)...................................................................
6.2.3
Metas del negocio........................................................................................
6.2.4
Diagrama de casos de uso del negocio........................................................
6.3
Modelo de Anlisis del Negocio.......................................................................
6.3.1
Trabajador del negocio.................................................................................
6.3.2
Entidad del negocio.....................................................................................
6.3.3
Realizacin de caso de uso del negocio.......................................................
Leccin 7.......................................................................................................................
Proceso de modelado del Negocio................................................................................
7.1
Elaborar el modelo de casos de uso del negocio.............................................
7.1.1
Identificando Actores del Negocio................................................................
7.1.2
Identificando Casos de Uso del Negocio.......................................................
7.1.3
Identificando Metas del Negocio..................................................................
7.1.4
Elaborando el diagrama de casos de uso del negocio..................................
7.2
Elaborar el modelo de anlisis del negocio......................................................
7.2.1
Identificando trabajadores del negocio........................................................
7.2.2
Identificando entidades del negocio.............................................................
7.2.3
Construyendo las realizaciones de caso de uso del negocio........................
Resumen.......................................................................................................................
Lectura..........................................................................................................................
Actividades...................................................................................................................
Autoevaluacin.............................................................................................................
CUARTA UNIDAD
64
EL MODELADO DE DOMINIO 64
Leccin 8.......................................................................................................................
Conceptos asociados al modelo de dominio..................................................................
8.1
Clase y Objeto.................................................................................................
8.2
Atributo...........................................................................................................
8.3
Operacin........................................................................................................
8.4
Asociacin y Enlace.........................................................................................
8.5
Generalizacin y Agregacin...........................................................................
8.6
Qu es el modelo de domino?........................................................................
8.7
Qu es el diagrama de clases?......................................................................
8.8
Notacin UML para modelo de domino............................................................
Leccin 9.......................................................................................................................
Proceso de construccin del modelo de dominio...........................................................
9.1
Identificando Clases........................................................................................
9.2
Identificando Asociaciones..............................................................................
9.3
Identificando Atributos....................................................................................
9.4
Identificando relaciones de generalizacin......................................................
9.5
Refinando el modelo........................................................................................
Resumen.......................................................................................................................
Lectura..........................................................................................................................
Actividades...................................................................................................................
Autoevaluacin.............................................................................................................
QUINTA UNIDAD
78
EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO 78
Leccin 10
79
Conceptos asociados los requerimientos 79
10.1 Qu es un requerimiento?.................................................................................
10.2 Tipos de Requerimientos.....................................................................................
10.2.1 Requerimiento Funcional..............................................................................
10.2.2 Requerimiento No funcional.........................................................................
10.3 Clasificacin de Requerimientos: Modelo FURPS.................................................
10.4 Caractersticas de los Requerimientos................................................................
10.5 Dificultades para definir los Requerimientos.......................................................
10.6 Tcnicas para obtener Requerimiento.................................................................
10.6.1 Entrevistas...................................................................................................
10.6.2 JAD...............................................................................................................
Leccin 11
84
Conceptos asociados al Modelo de casos de uso 84
11.1 Qu es el modelo de casos de uso?...................................................................
11.2 Actor...................................................................................................................
11.3 Caso de Uso........................................................................................................
11.4 Descripcin de caso de uso.................................................................................
11.5 Diagrama de casos de uso..................................................................................
Leccin 12.....................................................................................................................
Leccin 12.....................................................................................................................
Proceso de construccin del modelo de casos de casos de uso....................................
12.1 Identificando actores.......................................................................................
12.2 Identificando casos de uso..............................................................................
12.3 Elaborando la descripcin de casos de uso.....................................................
12.4 Elaborando el diagrama de casos de uso........................................................
Resumen.......................................................................................................................
Lectura..........................................................................................................................
Actividades...................................................................................................................
Autoevaluacin.............................................................................................................
GLOSARIO.....................................................................................................................
BIBLIOGRAFIA................................................................................................................
PRESENTACIN
INTRODUCCIN
Las organizaciones estn considerando el tema de los Sistemas de Informacin
como factor clave para lograr competitividad. Se estn realizando grandes
inversiones para su construccin e implantacin, de manera eficiente, efectiva
y con niveles de calidad pertinentes.
Los sistemas de informacin, conjunto de componentes software, hardware,
base de datos, procedimientos y personal, proveen la informacin, requerida
por las organizaciones para apoyar las actividades de toma de decisin y
controlar las operaciones del da a da. Esta informacin debe transmitirse a
todos los niveles de la organizacin, de manera oportuna y confiable.
El proceso de construccin e implantacin de sistemas de informacin 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 informacin de los clientes-usuarios.
En general, las primeras actividades del proceso de desarrollo estn
relacionadas con el anlisis de sistemas y la especificacin de requerimientos
del software. El propsito del anlisis de sistemas es definir el papel de cada
componente del sistema de informacin y asignar al software el mbito que le
corresponde desempear. Durante la actividad de especificacin 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 anlisis de sistemas
y especificacin de requerimientos del software; por lo que es de gran
relevancia, para la formacin de profesionales del campo de desarrollo de
Sistemas de Informacin, el dominio de mtodos, tcnicas y herramientas que
permitan afrontar con xito estas actividades.
Precisamente, este libro tiene el propsito de promover y consolidar, en el
estudiante, el uso de mtodos, tcnicas y herramientas para el anlisis de
sistemas y especificacin de requerimientos de software. Se enfatiza en el
componente software del sistema de informacin, se utiliza la notacin del
lenguaje de modelado unificado (UML) y se sigue el proceso de desarrollo
unificado (RUP). En otras palabras, para el anlisis de sistemas se desarrolla el
flujo de modelado del negocio, y para la especificacin de requerimientos, se
sigue el flujo de requerimientos que permitir capturar sistemticamente los
requerimientos usando la tcnica de casos de uso del UML.
Los contenidos de este libro se han organizado en cinco unidades temticas.
stas se desarrollan en lecciones que incluyen apartados, esquemas y figuras,
segn cul sea la necesidad didctica. Cada unidad consta tambin de un
conjunto de actividades y de evaluacin orientados a afianzar el aprendizaje
del estudiante y a valorar sus logros.
La primera unidad tiene como propsito que el estudiante comprenda y
explique la importancia de los sistemas de informacin en las organizaciones,
definiendo con precisin los conceptos relacionados a la organizacin, proceso
de negocio, datos, informacin, conocimiento y sistemas de informacin;
valorando la importancia de estos conceptos en el contexto del anlisis de
sistemas de informacin.
La segunda unidad comprende los temas relacionados con el proceso de

desarrollo de sistemas de informacin, sus fases y actividades genricas;
muestra los diversos modelos de proceso de desarrollo y las metodologas ms
conocidas, y brinda una introduccin al UML y al RUP.
La tercera unidad ayuda, al estudiante, en el desarrollo de habilidades para la
construccin de modelos de negocio. Los artefactos que se elaboran sirven de
base para la determinacin de requerimientos del sistema. Se utiliza notacin
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 construccin de diagrama
de clases de UML. De esta manera, complementa los artefactos del modelo de
negocios con una representacin de los conceptos o entidades que se manejan
en el contexto del negocio o dominio de la aplicacin que cubra las
necesidades y requerimientos de los usuarios-clientes.
La quinta unidad permite que el estudiante desarrolle habilidades para la
especificacin de requerimiento usando el modelo de casos de uso del UML. Se
tratan, con precisin, 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, descripcin de casos de uso y diagrama de casos
de uso.
En todo el libro, las figuras o tablas que no consignan fuente, corresponden a
elaboracin propia. Las figuras o tablas que no consignan nmero, representa
continuacin del texto donde estn ubicados.
El autor.
ORIENTACIONES METODOLGICAS
La asignatura de Anlisis de Sistemas es de formacin profesional
especializada, de naturaleza terica-practica. Tiene como propsito que el
estudiante maneje, adecuadamente, los mtodos, tcnicas y herramientas
para el anlisis y especificacin de requerimientos de software como
componente de un sistema de informacin.
Para este fin, se desarrollan las siguientes unidades temticas: Los Sistemas
de Informacin 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 temtica, el estudiante dispone de una serie de
preguntas que permitir valorar sus logros. Al finalizar la unidad, se brinda un
resumen del contenido temtico, una lectura seleccionada de un tema de
inters relacionado con el contenido temtico de la unidad, una serie de
actividades que el estudiante debe realizar, una autoevaluacin que mide el
aprendizaje del estudiante, una serie de direcciones Internet para exploracin
online.
Es fundamental, para el proceso de auto aprendizaje, 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 informacin. El docente, dispondr de un
horario que permita interactuar con los estudiantes para absolver consultas o
dudas, a travs de Internet.
En lo que respecta a la evaluacin del aprendizaje, al final de cada unidad
temtica se dispone de una serie de preguntas de autoevaluacin que permite
al estudiante medir sus logros de aprendizaje conceptual. Adems, 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 INFORMACIN EN LAS ORGANIZACIONES
Qu es una organizacin, como se estructuran sus actividades, cules son sus
niveles?
Qu son los procesos de negocios, como se clasifican?
Cul es la diferencia entre dato, informacin y conocimiento?
Qu es un sistema de informacin, cules son sus componentes, como se
clasifican?
PROPOSITOS
Al finalizar esta unidad, el estudiante:
Explica los conceptos y principios asociados a una organizacin y a la forma
de estructurar sus actividades
Comprende las caracterstica de los procesos de negocio y su clasificacin
Explica la diferencia entre dato, informacin y conocimiento
Explica la importancia de los sistemas de informacin en las
organizaciones, sus elementos y su clasificacin
Leccin 1
Organizacin y procesos de negocios
Los profesionales responsables de automatizar las actividades de una
organizacin deben comprender sus procesos de negocio a fin de identificar
aquellas actividades manuales que sern reemplazas por sistemas software.
En esta leccin se revisa aspectos bsicos de una organizacin y del enfoque
basado en procesos de negocios.
1.1 Organizacin
1.1.1 Qu es una organizacin?
Segn el Diccionario de la Real Academia de la Lengua, una organizacin es
una asociacin de personas reguladas por un conjunto de normas en funcin
de determinados fines.
Se puede considerar que una organizacin 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
divisin del trabajo y comunicacin que interactan para producir bienes o
servicios (Figura 1.1).
Figura 1.1 Componentes de una organizacin
Reglas
Entradas
ACTIVIDADES
Bienes/Servicios
Personas/Recursos
Fuente: Elaboracin propia1
Las personas representan el recurso ms importante de la organizacin,

juegan distintos roles o responsabilidades cuando realizan las diversas
actividades requeridas para cumplir los objetivos de la organizacin.
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 decisin
(realizadas por los gerentes).
Los recursos pueden ser dinero, materiales, maquinaria, infraestructura,
tecnologa que sirven de soporte para realizar las actividades.
1
En lo sucesivo, en este libro, si las figuras, imgenes o tablas no consignan fuente, son de
elaboracin propia..
10
Las reglas estn dadas por las polticas, 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 segn ciertas reglas.
Se han establecido diversos modelos o enfoques para la estructura de una
organizacin; sin embargo, para el propsito 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 jerrquica, con
mbitos de control muy limitados y rgidos (figura 1.2).
Cada funcin busca optimizar sus propias tareas, inclusive a costa del
rendimiento global de la organizacin. Su foco de anlisis es la tarea o funcin,
su objetivo es la optimizacin de las tareas, se orienta al interior de la
organizacin, tiene una visin fragmentada.
Figura 1.2 Estructura funcional
Gerencia
General
Investigaci
n y
Desarrollo
Producci
n
Finanzas
Ventas
Estructura por procesos

En la estructura con enfoque por procesos, las actividades se organizan de
manera horizontal, facilitando la reunificacin 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, notndose las
relaciones con el cliente. Se busca satisfacer al cliente, considerando el
producto y el flujo de trabajo. Su foco de anlisis es el proceso, su objetivo es
la mejora de los procesos, se orienta esencialmente al cliente y tiene una
visin global.
11
Figura 1.3 Organizacin por procesos

Gerencia
General
Proceso de negocio (Flujo de actividades)

1.1.3 Niveles Organizacionales

Los roles que las personas desempean en la organizacin 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,
que agrupa a empleados, obreros, etc., quienes realizan actividades rutinarias,
sin responsabilidad de toma de decisiones.
Se suele utilizar un modelo de pirmide organizacional para representar los
niveles organizacionales relacionados con la toma de decisiones. En la figura
1.4 se visualiza cuatro niveles: Estratgico, Administrativo, de Conocimiento y
Operativo (Laudon, 2004).
Figura 1.4 Pirmide organizacional
Nivel Estratgico
Directores
Gerentes de Nivel
Medio
Nivel Administrativo
Nivel de Conocimiento
Trabajadores del
Conocimiento
Nivel Operativo
Gerentes
Operativos
Fuente: (Adaptado de Laudon, 2004)
En esta pirmide podramos agregar, debajo de su base, un bloque grande

para representar las actividades operacionales o rutinarias que tienen poca
tarea de toma de decisiones.
12
Nivel estratgico
En el nivel estratgico, se realizan actividades relacionadas con toma de
decisiones de asuntos estratgicos 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 aos o determinar los
niveles de empleo dentro de cinco aos. Se puede incluir a Directores, Gerente
General, Gerentes de Divisin.
Nivel administrativo
En el nivel administrativo, se realizan actividades de supervisin, control y
toma de decisiones de aspectos tcticos 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
investigacin 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
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 organizacin como ventas, depsitos
en efectivo, nminas. Se toman decisiones de corto plazo, por ejemplo,
reabastecimiento de stock de inventarios, otorgar prstamos bancarios, entre
otros. Se incluye a los gerentes operativos: Jefe de Seccin de fabricacin, Jefe
de Cajeros.
Este modelo de pirmide permite, a quienes desarrollan sistemas de
informacin, visualizar el alcance de informacin requerido por cada nivel; as,
en el nivel de gestin operativo, es necesaria la informacin detallada;
mientras que, en el nivel estratgico, conviene proporcionar resmenes.
1.2 Procesos de negocio

1.2.1 Qu es un proceso de negocio?
La literatura relacionada con los proceso y la reingeniera de procesos sealan
que, en una empresa, los proceso de negocio representan un conjunto de
actividades organizadas de tal manera que transforman una serie de entradas
(insumos, materia prima, etc.) en resultados (bienes, servicios, etc.) de valor
para el cliente (Davenport, 1996; Hammer y Champy, 1995).
Un proceso de negocio es un conjunto de actividades que reciben uno o ms
tipos de insumos y crean un producto de valor para un cliente (Hammer,
1995, p.37).
13
Muchos procesos de negocios trascienden las reas funcionales tradicionales;

por ejemplo, en muchas compaas el proceso de ejecucin de un pedido
requiere la cooperacin entre la funcin de ventas, contabilidad y
manufactura. En ventas se recibe el pedido y se inicia su trmite; en
contabilidad se verifica el crdito y se factura el pedido) y en manufactura se
produce y enva el pedido (figura 1.5).
Algunos ejemplos de proceso de negocios son: Proceso de Admisin, Proceso
de Matrcula, Proceso de Contratacin de Personal, Proceso de Formulacin del
Plan Anual de Desarrollo.
Figura 1.5 Proceso de ejecucin de un pedido
VENTAS
CONTABILID
AD
MANUFACTUR
A
Recibir
pedido
Verificar
Crdito
Produci
r
pedido
Iniciar
tramit
e
Facturar
pedido
Enviar
pedido
1.2.2 Clases de procesos de negocio

Los procesos de negocios se pueden clasificar en: Principales, de Soporte y de
Gestin.
Los Procesos Principales o Sustantivos son aquellos que estn ligados
directamente con la realizacin del producto y la prestacin del servicio para el
Cliente. Son los procesos de lnea, hacen realidad la misin de la organizacin.
Ejemplos:
VENDER
PRODUCTO
GESTIONAR
PEDIDO
Mediantes estos procesos el cliente interacta con la organizacin. En el

ejemplo, el proceso Vender Producto permite al cliente recibir de la
organizacin el producto requerido y el proceso Gestionar Pedido permite al
cliente realizar el pedido de bienes o servicios requeridos.
Los Procesos de Soporte son aquellos que proporcionan apoyo a los
procesos principales o sustantivos. Usualmente estn relacionados con la
gestin de recursos.
Ejemplos:
INVESTIGACIN DE
MERCADO
DESARRROLLO
DE PERSONAL
14
En estos procesos no hay agente externo, cliente, proveedor, etc., que

interacte con la organizacin. Son procesos que apoyan a los procesos
principales.
Los Procesos de Gestin son aquellos que estn vinculados al mbito de las
responsabilidades de la direccin. Se relacionan con actividades de
planificacin y control.
Ejemplos:
PLANIFICACIN
REVISIN
Estos procesos son realizados por los niveles gerenciales, no hay interaccin
entre algn agente externo con la organizacin. Son proceso que refleja tareas
gerenciales..
1.2.3 Cmo se describe un proceso de negocio?

Un proceso de negocio se puede describir de manera textual o grfica. Se han
propuestos diversos formatos para describir un proceso, pero los tems bsicos
incluyen: la entrada, las actividades, quin o quines realizan las actividades,
los recursos que se utilizan, las reglas que rigen el flujo de actividades y la
salida.
A continuacin se muestra un ejemplo textual de descripcin de un proceso de
Registro de Pedido para una empresa de fabricacin:
1. El cliente enva una orden de pedido, por telfono, 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
(completndolo, si es necesario), y comienza su procesamiento
envindolo al jefe tcnico, que est encargado de su anlisis.
3. El jefe tcnico analiza la viabilidad de cada producto del pedido
por separado. Si el producto pedido est en el catlogo, su
fabricacin es aceptada. En caso contrario, es considerado un
producto especial, y el jefe tcnico estudia su produccin: Si es
viable, la fabricacin del producto especial es aceptada; Si no es
viable, el producto especial no ser fabricado.
4. Una vez estudiado el pedido completo, el jefe tcnico informa al
departamento comercial de la aceptacin 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 fabricacin (la estndar si el producto
estaba catalogado, o una nueva, especficamente diseada para
el producto, si ste no estaba en el catlogo). Cada orden de
trabajo es enviada al jefe de produccin, y queda pendiente de su
lanzamiento.
En la figura 1.6, se describe el proceso de Registrar Pedido de manera grafica,

usando la tcnica de Diagrama de Actividades de UML.
15
Existen diversas tcnicas y herramientas para describir, de manera grfica, un

proceso de negocio. Depender del profesional responsable, elegir aquella que
se adapte mejor a las necesidades de la organizacin a la que brinda sus
servicios.
Figura 1.6 Descripcin Grafica del Proceso Registro de Pedido

CLIENTE
COMERCIAL
JEFE TECNICO
JEFE PRODUCCION
LLENAR
PEDIDO
TRAMITAR
PEDIDO
ANALIZAR
VIABILIDAD
NOTIFICAR
RECHAZO
[ No es Viable ]
[ Si es viable ]
ORDENAR
FABRICACION
NOTIFICAR
ACEPTACION
16
PLANIFICAR
PRODUCCION
Leccin 2
Introduccin a los Sistemas de informacin
Las organizaciones requieren de informacin para apoyar las actividades de
toma de decisin y controlar las operaciones del da a da. La informacin se
transmite en todos los niveles de la organizacin a travs de los sistemas de
informacin.
En esta leccin se brinda, a modo introductorio, los conceptos relacionados a
los sistemas de informacin, los componentes y tipos de sistemas de
informacin.
2.1 Concepto de Dato, Informacin y Conocimiento

Desde aos atrs se reconoce que la informacin es un recurso valioso en las
organizaciones. Los gerentes, empleados y todos aquellos que integran una
organizacin la utilizan. Con frecuencia los empleados usan datos detallados
para sus actividades de tipo operacional, los gerentes manejan informacin
sumaria para tomar decisiones.
En muchas ocasiones se utilizan los trminos datos e informacin como
sinnimos, pero son trminos 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
Jos Quispe
1200
S/100
456789
Informacin
La informacin es un conjunto de hechos agrupados para algn propsito 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 Informacin
Comercial Vende Barato S.A
Factura Nro 456789
Cliente: Jos Quispe
Detalle
Nro
.
Producto
Cantid
ad
Preci
o
01
Zapatos
1200
S/10
0
17
Se puede afirmar que los datos son la materia prima para producir
informacin. Entonces, en las organizaciones se procesan datos para obtener
informacin.
Conocimiento
El conocimiento es la informacin conectada a decisiones, procesos y acciones
capaces de aplicar esa informacin.
Para explicar la diferencia entre informacin y conocimiento, considere una
receta de preparacin de una torta. Las instrucciones e ingredientes indicados
en la receta vendran a ser informacin, al igual que el libro de receta es
informacin. Esta informacin 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 informacin
se lleva a la accin se convierte en conocimiento.
Desde una perspectiva de niveles, segn Harris (1996), se puede considerar
que el nivel ms bajo de los hechos conocidos son los datos, no tienen un
significado intrnseco. En el siguiente nivel, cuando los datos son procesados
(ordenados, agrupados, analizados e interpretados), se convierten en
informacin con un propsito. En el tercer nivel, cuando la informacin es
utilizada y puesta en el contexto o marco de referencia de una persona, se
transforma en conocimiento.
La figura 2.3 trata de explicar las diferencias entre datos, informacin y
conocimiento desde una perspectiva de niveles.
Figura 2.3 Dato, Informacin Y conocimiento
CONOCIMIEN
TO
INFORMACI
N
Informacin conectada a
decisiones, procesos y
acciones capacea de
aplicar esa informacin
Hechos agrupados
para un propsito
DATO
Coleccin de
hechos
Fuente: (Adaptado de Harris, 1996)
2.2 Qu es Sistema de informacin?

Un sistema de informacin es un conjunto de componentes interrelacionados
que permiten capturar, procesar, almacenar y distribuir la informacin para
apoyar la toma de decisiones y el control en una institucin. Los sistemas de
informacin pueden contener datos acerca de personas, lugares y cosas
importantes dentro de la institucin y el entorno que la rodea (Laudon, 2004,
p.30).
18
Un sistema de informacin recibe y procesa los datos de manera eficaz, sin

errores, evala la calidad de los datos de entrada, almacena los datos de modo
que estn disponibles cuando el usuario lo crea conveniente, elimina la
informacin poco til evitando redundancias, brinda seguridad evitando la
perdida de informacin o la intrusin de personal no autorizado o agentes
externo a la compaa y genera informacin 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 informacin con la computadora
y los programas informticos. Una organizacin puede adquirir nuevas
computadoras, instalar redes, desarrollar pginas Web, etc., pero ello no
significa que se implemente sistema de informacin. El significado del trmino
sistema de informacin abarca ms que los elementos computacionales,
incluye, tambin, el modo de organizar dichos elementos, la forma de usarlos
y los roles que desempean las personas en su explotacin para obtener la
informacin que apoye las actividades de la empresa.
2.3 Componentes de un Sistema de informacin

Se puede considerar que los componentes de un sistema de informacin son:
el hardware, el software, la base de datos, los procedimientos y el personal.
Estos elementos interactan entre s para lograr el objetivo del: proveer
informacin para apoyar a la empresa (figura 2.4).
Figura 2.4 Componentes de un Sistema de Informacin
Hardwar
e
Personas
Software
Sistema de
Informaci
n
Dato/informaci
n datos
Procedimien
to datos
El hardware corresponde al elemento fsico del sistema de informacin incluye

las redes computacionales y de telecomunicaciones. El software corresponde a
los programas de aplicacin. La base de datos representa el almacn de los
datos e informacin requerida por la empresa, las personas puede ser los
usuarios finales y el personal de tecnologa de informacin. Los procedimientos
establecen las reglas y normas del uso del sistema de informacin
2.4 Tipos de sistemas de informacin

De acuerdo con los intereses, especialidades y niveles en una organizacin, se
pueden identificar los siguientes tipos de sistemas de informacin (Laudon,
2006): de nivel operativo, de nivel del conocimiento, de nivel administrativo y
de nivel estratgico.
19
Los sistemas de informacin de nivel operativo apoyan a los gerentes

operativos en el control de actividades y transacciones elementales de la
organizacin, por ejemplo: ventas, ingresos, depsitos en efectivo, nomina,
decisiones de crdito y flujo de materiales en una fbrica. Responden a
preguntas de rutina y siguen el flujo de transacciones a travs de la
organizacin. Por ejemplo, Cuntas partes hay en inventario? Qu pas con
el pago del seor Gutirrez?
Los sistemas de informacin de nivel del conocimiento apoyan a los
trabajadores del conocimiento de una organizacin. Su objetivo es ayudar a las
empresas comerciales a integrar el nuevo conocimiento en los negocios y
ayudar a la organizacin a controlar el flujo del trabajo de oficina. Estos tipos
de sistemas estn entre las aplicaciones de crecimiento ms rpidas en los
negocios actuales.
Los sistemas de informacin de nivel administrativo apoyan a las
actividades de supervisin, 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 peridicos ms que informacin instantnea de operaciones. Apoyan
a las decisiones no rutinarias y tienden a enfocarse en decisiones menos
estructuradas para las cuales los requisitos de informacin no siempre son
claros.
Los sistemas de informacin de nivel estratgico apoyan a los directores
a enfrentar y resolver aspectos estratgicos y tendencias a largo plazo, tanto
en la empresa como en el entorno externo. Su funcin principal es compaginar
los cambios del entorno externo con la capacidad organizacional existente.
Otra forma de clasificar los sistemas de informacin es segn la funcin que
desempean o el tipo de usuario final del mismo, pueden ser (Laudon, 2006):
Sistema de procesamiento de transacciones, Sistemas de informacin
gerencial, Sistema de soporte a la toma de decisiones, Sistemas de
informacin ejecutiva, Sistemas de automatizacin de oficinas, Sistemas
expertos y Sistemas de Planificacin de Recursos Empresariales.
Los Sistemas de procesamiento de transacciones (Transaction Process
System - TPS) son aquellos que permiten gestionar la informacin referente a
las transacciones producidas en una empresa u organizacin.
Los Sistemas de informacin gerencial (Management Information System MIS) son aquellos orientados a solucionar problemas empresariales en
general.
Los Sistemas de soporte a decisiones (Decision Suport System - DSS) son
aquellas que sirve de herramienta para realizar el anlisis de las diferentes
variables de negocio con la finalidad de apoyar el proceso de toma de
decisiones.
Los Sistemas de informacin 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 informacin interna y externa a la misma.
Los Sistemas de automatizacin de oficinas (Office Automation System OAS) son aplicaciones destinadas a ayudar al trabajo diario del administrativo
de una empresa u organizacin.
Los Sistemas expertos (Expert System - SE) emulan el comportamiento de
un experto en un dominio concreto.
20
Los Sistemas de Planificacin de Recursos Empresariales (Enterprise

Resource Planning - ERP) integran la informacin y los procesos de una
organizacin en un solo sistema.
Todos estos sistemas de informacin a su vez podran analizarse segn las
diferentes reas de la empresa: ventas y mercadotecnia, manufactura y
produccin, finanzas, contabilidad y recursos humanos. Para cada una de estas
reas existe un conjunto especifico de aplicaciones informticas 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 comunicacin.
21
Resumen
Organizacin y Procesos de Negocio
Una organizacin es un sistema compuesto por un conjunto de personas,

actividades y recursos, distribuidas de alguna forma con arreglo a ciertas reglas
de divisin del trabajo y comunicacin que interactan 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 jerrquica, con mbitos de controles muy limitados y
rgidos.
Por procesos: las actividades se organizan de manera horizontal, facilitando
la reunificacin de actividades fragmentadas.
Los roles que las personas desempean en la organizacin se pueden agrupar
en niveles organizacionales: Operacionales y Gerenciales. Los Gerenciales
pueden ser: estratgico, administrativo, de conocimiento y de control operativo.
Nivel Operacional: Actividades rutinarias. No hay toma de decisin.
Empleados, obreros.
Niveles Gerenciales: Actividades caracterizadas por toma de decisiones.
o Nivel estratgico, asuntos estratgicos y tendencias a largo plazo.
o Nivel administrativo, aspectos tcticos en el mediano plazo.
o Nivel de conocimiento, investigacin 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 ms
tipos de inputs y crean un output que es de valor para un cliente.
Clases de Procesos de Negocios
Principales: ligados con realizacin del producto / lprestacin del servicio
para el Cliente.
De Soporte: apoyan los procesos principales. Relacionados con la
gestin de recursos.
De Gestin: vinculados a la direccin. Se relacionan con actividades de
planificacin y control.
Un proceso de negocio se puede describir en forma grafica o textual.
Introduccin a los sistemas de informacin
Los datos son registros de hechos observables no procesados que no tienen

significado.
La informacin es un conjunto de hechos agrupados para algn propsito en
particular. Son datos procesados que tienen significado.
El conocimiento es la informacin conectada a decisiones, procesos y acciones
capaces de aplicar esa informacin.
Un sistema de informacin es un conjunto de componentes interrelacionados

que permiten capturar, procesar, almacenar y distribuir la informacin para
apoyar la toma de decisiones y el control en una institucin.
Los Componentes de un sistema de informacin son: Hardware, Software, Base

de datos, Personas (usuarios finales y personal de T.I.) y Procedimientos.
Tipos de sistema de informacin
22
De acuerdo a intereses: Sistemas de informacin de nivel operativo,

Sistema de informacin de nivel de conocimientos, Sistema de informacin
de nivel administrativo y Sistema de informacin de nivel estratgico
Segn funcin que desempea: Sistema de procesamiento de transacciones
(TPS), Sistema de informacin Gerencial (MIS), Sistema de soporte a las
decisiones (DSS), Sistema de informacin ejecutiva (EIS), Sistema de
automatizacin de oficinas (OAS), Sistema Experto (SE), Sistema de
planificacin de recursos empresariales (ERP).
Lectura
INTERNET Y LAS ORGANIZACIONES *
Internet, especialmente World Wide Web, est empezando a tener un impacto
importante en las relaciones entre las empresas y las entidades externas, e
incluso en la organizacin de los procesos de negocios dentro de una empresa.
Internet incrementa la accesibilidad, el almacenamiento y la distribucin de la
informacin y el conocimiento para las organizaciones. En esencia, Internet es
capaz de disminuir de manera importante los costos de la agencia y de
transaccin que enfrentan la mayora de las compaas.
Por ejemplo, las empresas de corretaje y los bancos de Nueva York ya pueden
distribuir sus manuales de procedimientos operativos internos a sus
empleados ubicados en lugares lejanos al publicarlos en sus sitios Web
corporativos, ahorrando de esta manera millones de dlares en costos de
distribucin. Una fuerza de ventas global puede recibir casi al instante
informacin actualizada sobre el precio de un producto a travs de la Web o
instrucciones de la administracin a travs de correo electrnico. Los
proveedores de algunos grandes detallistas pueden acceder a los sitios Web
internos de estos ltimos para obtener directamente informacin de ventas
actualizada y emitir de manera instantnea rdenes de reabastecimiento.
Las empresas estn reconstruyendo rpidamente algunos de sus procesos de
negocios esenciales con base en la tecnologa de Internet y haciendo de esta
tecnologa un componente clave de sus infraestructuras de tecnologa de la
informacin. Si la experiencia anterior con las redes sirve de gua, un resultado
ser procesos de negocios ms sencillos, menos empleados y organizaciones
mucho ms planas que el pasado.
(*) Fuente: (Laudon, 2004,p.85)
23
Actividades
1
2
Identifique una organizacin, de cualquier tipo o tamao, indique el giro del

negocio, obtenga su organigrama y realice la descripcin textual o grfica de uno
de sus procesos de negocio de tipo principal.
Busque, en internet, un producto comercial de cada tipo de sistema de
informacin.
Autoevaluacin
1. Con respecto al concepto de organizacin como sistema, entre los parntesis de la
siguiente lista, marque V=Verdadero o F=Falso, segn corresponda:
a. ( ) Est compuesto por personas, actividades y bienes
b. ( ) Tiene reglas de divisin del trabajo y comunicacin
c. ( ) Est compuesto por recursos, actividades y personas
d. ( ) Est compuesto por personas, recursos, y servicios
e. ( ) Las personas realizan actividades y utilizan los recursos
2. Con respecto a la estructura organizacional, entre los parntesis de la siguiente
lista de caractersticas, marque F= si corresponde al enfoque Funcional o P= si
corresponde al enfoque de Procesos:
a. ( ) Organizacin Jerrquica de actividades
b. ( ) Objetivo es Optimizar actividades
c. ( ) Organizacin horizontal de actividades
d. ( ) No se orienta al cliente
e. ( ) Visin global
3. En relacin a los niveles organizacionales, entre los parntesis de la siguiente lista
coloque E=Nivel Estratgico, A=Nivela Administrativo, C=Nivel de conocimiento,
O=Nivel operativo, segn corresponda:
a. ( ) Trata asuntos relacionados con tendencias a largo plazo
b. ( ) Decisin de aspectos tcticos
c. ( ) Incluye a gerentes de nivel medio
d. ( ) Incluye a Directores
e. ( ) Trata asuntos de presupuesto en un periodo
f. ( ) Trata asuntos relacionados con la investigacin
g. ( ) Decisiones de corto plazo
4. Con respecto al concepto de proceso de negocio, marque V=Verdadero o F=Falso
segn corresponda:
a. ( ) Conjunto de clientes
b. ( ) Conjunto de actividades
c. ( ) Crea valor para los gerentes
d. ( ) Crea valor para un cliente
e. ( ) Tiene un comienzo y un Final
5. Con respecto a las clases de proceso de negocio, entre los parntesis de la
siguiente lista coloque P=Proceso Principal, S=Proceso de Soporte, G=Proceso de
Gestin, segn corresponda:
a. ( ) Relacionado directamente con el Cliente
b. ( ) Relacionado con la gestin de Recursos
c. ( ) Relacionado con la planificacin y control
d. ( ) Realizado por Niveles Gerenciales
e. ( ) Hacen realidad la misin de la organizacin
6. Marque V=Verdadero o F=Falso, segn corresponda
a. ( ) Dato es la representacin de un hecho y tiene significado
b. ( ) Dato es la materia prima para producir informacin
c. ( ) Dato es la informacin procesada que tiene significado
d. ( ) Informacin es el conjunto de datos organizados que tiene significado
e. ( ) El conocimiento es informacin llevada a la accin
24
7. Con respecto al concepto de Sistema de Informacin, entre los parntesis de la

siguiente lista marque V=Verdadero o F= Falso, segn corresponda:
a. ( ) Proporciona informacin para toma de decisiones
b. ( ) Abarca solo elementos computacionales
c. ( ) Sus componentes son Hardware, Software, Base de datos,
Procedimientos y Personas
d. ( ) Captura, procesa, almacena y distribuye informacin
e. ( ) Los procedimientos establecen reglas y normas de uso del sistema
8. Coloque la letra en la celda a la derecha del tipo de sistemas de informacin (S.I.)
que relaciona el nombre del tipo de sistema de informacin con la definicin que
corresponda:
Tipo de S.I.
1.
TPS
2.
MIS
3.
DSS
4.
EIS
5.
OAS
6.
SE
7.
ERP
Definicin de tipo de S.I.

a) Aplicaciones para ayudar el trabajo del administrativo de una
empresa
b) Emulan el comportamiento de un experto en un dominio
concreto
c) Integran informacin y proceso de una organizacin en un
solo sistema
d) Permiten el anlisis de variables del negocio para tomar
decisiones
e) Orientados a solucionar problemas empresariales en general
f)
Gestionan la informacin de transacciones en una empresa
g) Orientado a monitorizar estado de un rea o unidad de una

empresa
Respuestas de Control
1. a = F, b = V, c = V,
2. a = F, b = F, c = P,
3. a = E, b = A, c = A,
4. a = F, b = V, c = F,
5. a = P, b = S, c = G,
6. a = F, b = V, c = F,
7. a = V, b = F, c = V,
8. 1 = f, 2 = e, 3 = d,
d = F,
d = F,
d = E,
d = V,
d = G,
d = V,
d = V,
4 = g,
e=V
e=P
e = A, f = C, g = O
e=V
e=P
e=V
e=V
5 = a, 6 = b, 7 = c
Exploracin on-line
Portal del CIO,

Portal de la Compaa IBM sobre transformacin de procesos de negocio
para incrementar la flexibilidad empresarial a travs 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

Pgina de la Organizacin Internacional OMG (Object Management Group)
que contiene informacin de estndares de modelado de procesos de
negocios.
http://www.bpmn.org/
Referencias bibliogrficas
1
Davenport, Thomas (1996). Innovacin de Procesos: Reingeniera del

trabajo a travs de la tecnologa de la informacin. Espaa. Daz Santos.
25
Hammer, Michel y James Champy (1995), Reingeniera. Bogota. Grupo

Editorial Norma..
Harris, David (1996), Creating a Knowledge Centric Information

Technology Environment. Harris Training & Consulting Services Inc.,
Seattle, WA, September.
Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Informacin

Gerencial. 8 Ed. Mxico D.F. Pearson Educacin.
Laudon, Jane y Kenneth (2006). Sistemas de informacin gerencial,

Administracin de la empresa digital. Mxico D.F. Pearson EducacinPrentice Hall
26
SEGUNDA UNIDAD
EL PROCESO DE DESARROLLO, RUP Y UML
Qu es un proceso de desarrollo, cules son sus fases y actividades
genricas?
Cules son los modelos de proceso de desarrollo?
Qu es metodologa, tcnica y herramienta de desarrollo?
Qu es el UML y cules son sus elementos, relaciones y diagramas?
Qu es el RUP y cuales sus fases y flujos, artefactos, trabajadores,
actividades?
PROPOSITOS
Explica las fases de un proceso de desarrollo y sus actividades genricas
Describe las caractersticas de los diversos modelos de proceso de
desarrollo
Comprende los conceptos de metodologa, tcnica y herramienta
Comprende los elementos, las relaciones y los diagramas del UML
Comprende las fases, flujos, artefactos, trabajadores y actividades del RUP
27
Leccin 3
Proceso de desarrollo de sistemas de informacin
La construccin de un sistema de informacin implica un esfuerzo conjunto de
profesionales de tecnologa de informacin y lderes de la organizacin. Este
esfuerzo significa 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 metodologas de desarrollo.
Esta leccin ayuda a comprender las caractersticas de un proceso de
desarrollo, los modelos que existen y los conceptos relacionados a las
metodologas de desarrollo.
3.1 Proceso de desarrollo, una visin genrica

3.1.1 Qu es un proceso de desarrollo?
El proceso de desarrollo es una gua acerca de las actividades y tareas necesarias para
construir un sistema de informacin. En el contexto de software, programas de
aplicacin o aplicaciones informticas, 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
informacin, con actividades y tareas especficas; pero se puede establecer una serie
de actividades comunes que llamaremos visin genrica, considerando las
siguientes fases (Pressman, 2002): Definicin, Desarrollo y Evolucin.
Figura 3.1 Fases del proceso de desarrollo: Visin genrica
Definicin
Anlisis del Sistema
Requerimientos
Planificacin
Desarrollo
Diseo
Codificacin
Prueba
Evolucin
Correccin
Adaptacin
Mejora
Fuente: (Pressman, 2002)
3.1.2 Fase de Definicin

El propsito de la fase de Definicin es identificar las necesidades o
requerimientos del cliente/usuario, tales como: la informacin que debe ser
proporcionada, la funcionalidad y rendimiento que se desea, las interfaces que
deben establecerse, las restricciones de diseo que existen y los criterios de
validacin que se necesitan para definir un sistema correcto.
En esta fase, se realizan las siguientes actividades: Anlisis del Sistema,
Requerimientos del Software y Planificacin del Proyecto.
Anlisis del sistema. Define el papel de cada elemento del sistema de
informacin, asignando finalmente al software el papel que va a desempear.
28
Requerimientos del software. El mbito establecido para el software

proporciona la direccin a seguir, pero antes de comenzar a trabajar es
necesario disponer de una informacin mas detallada del mbito de la
funcionalidad del software.
Planificacin 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 propsito de la fase de Desarrollo es determinar cmo han de disearse las
estructuras de datos y la arquitectura del software, cmo han de
implementarse los detalles procedimentales, cmo ha de traducirse el diseo a
un lenguaje de programacin y cmo ha de realizarse la prueba.
En general se aplicarn tres pasos concretos: Diseo del Software, Codificacin
y Pruebas del software.
Diseo de software. El diseo traduce los requisitos de software a un
conjunto de representaciones (algunas grficas y otras tabulares o basadas en
lenguajes) que describen las estructuras de bases de datos, la arquitectura, el
procedimiento algortmico y las caractersticas de la interfaz.
Codificacin. Las representaciones del diseo debern ser traducidas a un
lenguaje artificial (un lenguaje de programacin 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 funcin, en la lgica y en la implementacin.
3.1.4 Fase de Evolucin

La fase de Evolucin, tambin llamada fase de mantenimiento, se centra en
los cambios que van asociados a la correccin de errores, a las adaptaciones
requeridas por la evolucin 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 definicin y de
desarrollo, pero en el contexto del software ya existente.
Se encuentran tres tipos de cambio: Correccin, Adaptacin y Mejora.
Correccin. Incluso llevando a cabo las mejores actividades de garanta de
calidad, es muy probable que el cliente descubra defectos en el software. El
mantenimiento correctivo cambia el software para corregir los defectos.
Adaptacin. Con el paso del tiempo es probable que cambie el entorno
original (sistemas operativos, equipos perifricos, 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 podran interesar que estuvieran incorporadas en el software.
El mantenimiento perfectivo amplia el software ms all de sus requisitos
funcionales originales.
29
3.2 Modelos de Proceso de desarrollo de software

La implementacin de un proceso de software puede variar de acuerdo a la
naturaleza: del proyecto, de la aplicacin de los mtodos 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 caractersticas y
los roles que se desempean 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 cclica. Entre los modelos iterativos podemos mencionar:
Construccin de prototipos y Desarrollo Rpido de Aplicaciones.
Los modelos evolutivos se caracterizan porque son iterativos y en cada
iteracin 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 todava 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, tambin conocido como Modelo de Ciclo de Vida Clsico o
Modelo en Cascada, es el ms antiguo y ha sido el ms usado. Tal como su
nombre lo indica, progresa en forma secuencial desde una primera fase de
Anlisis de Sistemas, avanzando a travs de Requerimientos, el Diseo, la
Codificacin, la Prueba y el Mantenimiento (figura 3.2) .
Figura 3.2 Modelo lineal secuencial
Anlisis de
Sistemas
Requerimient
os de
software
Diseo
Codificaci
n
Prueba
Mantenimient
o
En este modelo, los requerimientos deben estar claramente identificados

desde el inicio. Sin embargo, la realidad seala que raramente el cliente
expone todos los requerimientos desde el inicio. En consecuencia, pueden
surgir cambios durante el desarrollo lo que afectar la planificacin
establecida.
Cuando se trata de proyectos grandes, el cliente debe tener paciencia porque
no ver una versin operativa del sistema sino hasta que el proyecto est muy
avanzado. Adems, esto hace que no exista una validacin por parte del
cliente hasta muy tarde. Si en estas etapas finales se detectase un error grave
las consecuencias son desastrosas.
30
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 estn claramente definidos desde el comienzo.
3.2.2 Modelo Construccin de Prototipos

Muchas veces, en los proyectos de desarrollo, no todos los requisitos estn
claros desde el inicio; en esta situacin puede resultar conveniente aplicar el
Modelo de Construccin 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
diseo rpido concentrado en las interfaces de entrada y salida; que se
constituye en la primera versin. Este prototipo es evaluado por el cliente y
sirve para refinar los requerimientos. Se inicia nuevamente el ciclo, conocido
como iteracin (figura 3.3).
Lo ideal es que este prototipo sirva slo 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 versin rediseada
en la que estos problemas no estn presentes.
Figura 3.3 Modelo Construccin de prototipos
Fuente: (Adaptado de Pressman, 2002)
En este modelo, cuando el cliente observa el prototipo operativo, cree que es

la versin final del sistema, sin entender que se trata de solo un prototipo y
que el producto no est terminado.
Por la presin de hacer que el prototipo funcione rpidamente, el desarrollador
puede elegir, inadecuadamente, el sistema operativo o el lenguaje de
programacin; incluso, puede usar un algoritmo incorrecto. Despus de algn
tiempo, puede familiarizarse con estas elecciones y olvidarse las razones por
las cuales son inadecuadas, dejndolas 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 presin de ste para conservarlo
como producto final.
3.2.3 Modelo Desarrollo Rpido de Aplicaciones (DRA)

El Modelo de Desarrollo Rpido de Aplicaciones (DRA), Rapid Application
Development (RAD), es un modelo lineal secuencial con
un ciclo
extremadamente corto. La rapidez se logra gracias al reso de componentes,
31
al empleo de Tcnicas de Cuarta Generacin, y a la posibilidad de dividir el

sistema en mdulos o subsistemas, que pueden asignarse a equipos,
independientes, que trabaja en paralelo; al finalizar el trabajo de los equipos,
los mdulos se integran en un solo producto.
Cuando se utiliza para aplicaciones de sistemas de informacin, el enfoque
DRA comprende las siguientes fases: modelo de negocio, modelo de datos,
modelo de procesos, generacin de aplicaciones, prueba y entrega (figura
3.4.).
Modelo de Negocio: en esta fase se trata de responder a las siguientes
preguntas: qu informacin maneja el proceso de negocio?, qu informacin
se genera?, quin la genera?, a dnde va esa informacin?, quin la
procesa?
Modelo de Datos: a partir del estudio del flujo de informacin 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.
Generacin de Aplicaciones: en esta fase se genera la aplicacin con el
empleo de tcnicas de cuarta generacin, adems de re-usar componentes
existentes (cuando es posible) y la creacin de componentes reutilizables
(cuando es necesario).
Prueba y Entrega: Dado que enfatiza la reutilizacin 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 mdulos.
Figura 3.4 Modelo DRA
Fuente: (Pressman, 2002)
En este modelo, cuando el proyecto es grande, se requiere un gran nmero de

personas para formar equipos paralelos suficientes.
32
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 tecnolgicos altos. Por ejemplo,
cuando se hace uso de una nueva tecnologa, 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 versin operativa, llamada
incremento. El primer incremento entrega la funcionalidad correspondiente a
los requerimientos bsicos, 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 podramos
entregar funcionando la gestin de archivos y la produccin de documentos,
en el segundo incremento las funciones ms sofisticadas relacionadas con la
edicin y en el tercer incremento la revisin ortogrfica.
Al finalizar cada incremento, el cliente recibe una versin operativa del
producto y lo evala. Como resultado de su utilizacin y evaluacin, se
desarrolla un plan para el siguiente incremento. Este plan contempla la
modificacin del producto central para cumplir mejor con las necesidades del
cliente y adems 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 versin operativa del producto.
33
3.2.5 Modelo Espiral

El Modelo en Espiral es un modelo iterativo que proporciona en cada iteracin
una versin evolutiva (incremento) del producto.
Durante las primeras iteraciones la versin incremental podra ser un prototipo
o un modelo en papel. Durante las ltimas iteraciones se producen versiones
cada vez ms 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:
Comunicacin con el Cliente, Planificacin (se definen recursos y tiempo),
Anlisis de Riesgos (se evalan riesgos tcnicos y de gestin), Ingeniera (se
construyen modelos de la aplicacin a desarrollar), Construccin y Entrega (se
construye, prueba, instala y proporciona soporte al usuario), Evaluacin 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 ms oscuro alrededor del
espiral, podra resultar en el desarrollo de una especificacin del producto
(pueden ocurrir mltiples iteraciones dentro de un circuito); luego, circuitos
sucesivos podran 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 ms 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 prximo 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).
34
3.3 Metodologas
Asociado al concepto de proceso de desarrollo de sistemas de informacin,
software, o aplicaciones informticas, est el concepto de Metodologa de
Desarrollo.
Una Metodologa es el conjunto de procedimientos, tcnicas, herramientas, y
un soporte documental que ayuda a los desarrolladores a realizar nuevo
software (Pressman, 2005). Una metodologa representa el camino a seguir
para desarrollar software o aplicaciones informticas de una manera
sistemtica, consiste de un conjunto de fases subdivididas en etapas,
actividades y tareas.
Una tarea es una actividad elemental siguiendo algn procedimiento. El
procedimiento es la definicin de la forma de ejecutar la tarea. La tcnica es
la herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una
o varias. Una herramienta es el soporte software que apoya la aplicacin de
una tcnica. Un producto es el resultado de cada fase, etapa o actividad de
una metodologa.
Se han establecido diversas metodologas para el desarrollo de sistemas de
informacin, algunas de las mas citadas son: RUP, MTRICA V3, Merisse,
SSADM V4, MDSI.
3.3.1 RUP
Rational Unified Process, de la compaa IBM, es una plataforma de proceso de
desarrollo de software configurable que entrega mejores prcticas
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 metodologa estndar ms utilizada para
el anlisis, implementacin y documentacin de sistemas orientados a objetos.
Link: http://www-01.ibm.com/software/pe/rational/rup.shtml
3.3.2 MTRICA V3
MTRICA, versin 3, Metodologa de Planificacin, Desarrollo y Mantenimiento
de Sistemas de Informacin, del Consejo Superior de Administracin
Electrnica del Ministerio de la Presidencia del Gobierno de Espaa, ofrece a
las Organizaciones un instrumento til para la sistematizacin de las
actividades del proceso de desarrollo dentro del marco que permite alcanzar
los siguientes objetivos:
Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los

fines de la Organizacin mediante la definicin de un marco estratgico
para el desarrollo de los mismos.
Dotar a la Organizacin de productos software que satisfagan las

necesidades de los usuarios dando una mayor importancia al anlisis de
requisitos.
Mejorar la productividad de los departamentos de Sistemas y Tecnologas

de la Informacin y las Comunicaciones, permitiendo una mayor capacidad
de adaptacin a los cambios y teniendo en cuenta la reutilizacin en la
medida de lo posible.
35
Facilitar la comunicacin y entendimiento entre los distintos participantes

en la produccin 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 operacin, 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 mtodo integrado de anlisis, concepcin y gestin de proyectos,
desarrollado en Francia, que provee un marco metodolgico y un lenguaje
comn riguroso para los desarrollos informticos.
Es una metodologa de modelado de propsito general en el mbito del
desarrollo de sistemas de informacin, ingeniera de software y gestin de
proyectos. Fue introducido en la dcada de 1980, desarrollado y perfeccionado
hasta el punto en que las organizaciones no gubernamentales francesas,
comerciales e industriales ms grandes la han adoptado como metodologa
estndar.
Merise separa el tratamiento de datos y de procesos, donde la vista de datos
se modela en tres fases: conceptual, lgico y fsico. Del mismo modo, la vista
de proceso pasa a travs de tres etapas: conceptual, organizacional y
operacional. Estas etapas en el modelado de proceso son paralelas con las
etapas del ciclo de vida: planificacin estratgica, el estudio preliminar, un
estudio detallado, desarrollo, implementacin y mantenimiento.
Link: http://merise.developpez.com/
3.3.4 SSADM V4
El Mtodo de anlisis y diseo estructurado de sistemas (SSADM Structured
Systems Analysis and Design Method (SSADM) es un enfoque de sistemas para
el anlisis de sistemas de informacin; fue producido por Central Computer
and Telecommunications Agency (nahora Office of Government Commerce),
una oficina gubernamental de Reino Unido relacionada con el uso de
tecnologa en el gobierno, a partir de 1980.
Las tres tcnicas ms importantes que se utilizan en SSADM son: Modelado
lgico de Datos, Modelado de flujo de datos y Modelado de comportamiento de
entidades.
Desde 1981 SSADM se ha perfeccionado y la versin 4 fue lanzado en 1990.
SSADM es un estndar abierto, es decir, que esta disponible gratuitamente
para su en la industria y muchas empresas ofrecen servicios de apoyo,
formacin y herramientas CASE para ello.
3.3.5 MDSI
La metodologa MDSI Versin 2.0, es una herramienta desarrollada en base a la
metodologa de Mtrica 3 del Ministerio de Administracin Pblica de Espaa
(MAP) y RUP (Rational Unified Process), han sido revisados y adaptados para su
aplicacin en las entidades integrantes del Sistema Nacional de Informtica
por la Oficina Nacional de Gobierno Electrnico e Informtica ONGEI de la
Presidencia del Consejo de Ministros - PCM. Es un instrumento til para la
sistematizacin de las actividades que dan soporte al ciclo de vida del
36
software.
Incluye:
Modelamiento
del
Negocio,
Modelamiento
de
Requerimientos, Modelamiento de Tecnologa, Construccin, Pruebas e
Implantacin del Sistema de Informacin
37
Leccin 4
Introduccin al UML
4.1 Qu es el UML?
UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un
lenguaje, basado en una notacin grfica, 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 metodologa de desarrollo orientada a
objetos. Este lenguaje es el resultado de la unificacin de los mtodos 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 informacin que es utilizada o producida durante un
proceso de desarrollo de software. Ejemplo: documento de especificacin de
requisitos, un modelo, un programa.
Modelo
Un modelo es una representacin abstracta de una especificacin, un diseo o
un sistema desde un punto de vista particular. Representa uno o ms
diagramas. Ejemplos: modelo de casos de uso, modelo de negocio.
Diagrama
Un diagrama es una representacin grfica de una coleccin 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
agrupacin y de anotacin.
Elementos Estructurales
Los elementos estructurales representan la parte esttica 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
Colaboraci Caso de
uso
Interfaz
n
38
Nodo
Componente
La Clase representa un conjunto de objetos que comparten los mismos

atributos, operaciones, relaciones y semntica.
La Interfaz representa la definicin un conjunto de especificaciones de
operaciones
La Colaboracin representa una iteracin, 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 inters para un grupo de usuarios en particular.
El Componente representa es empaquetamiento fsico de diferentes elementos
lgicos como clases, interfaces, y colaboraciones.
El Nodo representa a un elemento fsico del sistema, es decir un recurso
computacional.
Elementos de comportamiento
Los elementos de comportamiento representan la parte dinmica del sistema,
es decir el comportamiento en el tiempo y el espacio. Se incluyen:
Interacciones y estados.
Estado
Interacci
n
Mensaje
La Interaccin representa un Conjunto de mensajes intercambiados entre

objetos.
El Estado Identifica un perodo de tiempo del objeto (no instantneo) en el cual
el objeto esta esperando alguna operacin, recibe cierto tipo de estmulos y
especifica la secuencia de estado por las que pasa un objeto.
Elementos de agrupacin
Los elementos de agrupacin representan la parte organizativa del sistema.
Incluye: Paquete.
Paquete
El Paquete es el mecanismo de propsito general para organizar elementos.

Elementos de anotacin
Los elementos de anotacin representan la parte explicativa del sistema. Son
comentarios. Incluye: la nota
La Nota sirve para hacer comentarios a un conjunto de elementos.
39
4.4 Relaciones en UML

Las relaciones del UML representan los vnculos entre dos elementos del
modelo. Incluye: dependencia, asociacin, generalizacin y realizacin.
Dependencia
Representa una relacin semntica entre dos elementos, tal que un cambio en
uno de ellos (el independiente) puede afectar al otro (el dependiente).
Asociacin
Representa una relacin estructural que describe un conjunto de links, siendo
un link una conexin entre objetos.
Generalizacin
Representa una relacin de generalizacin/especializacin en la que el
elemento especializado (descendiente) se construye sobre la especificacin
del elemento generalizado (ancestro)
Realizacin
Representa una relacin semntica 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 colaboracin, garantiza llevar a cabo.
4.5 Diagramas en UML

La versin 2.0 del UML (Booch, 2006) considera 13 diagramas (figura 4.2),
divididos en Diagramas dinmicos y estticos.
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.
40
El Diagrama de objetos, muestra una instantnea de un

objetos y sus relaciones.
conjunto de
El Diagrama de componentes, muestra la organizacin y dependencias

entre un conjunto de componentes conocida como vista de implementacin de
un sistema. Estn relacionados a Diagramas de clases en donde un
componente se Corresponde con una o ms clases interfaces o
colaboraciones.
El Diagrama de despliegue, muestra los enlaces de comunicacin fsica
entre elementos de hardware y las relaciones entre mquinas fsicas y
procesos (qu se ejecuta y dnde).
El Diagrama de estructura compuesta, muestra la estructura interna
(incluyendo partes y conectores) de un clasificador o una colaboracin
estructurada.
El Diagrama de paquetes, muestra la descomposicin del modelo en
unidades de organizacin 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 interaccin que muestra los
objetos y actores que participan en una colaboracin poniendo el nfasis en el
ordenamiento en el tiempo de los mensajes.
El Diagrama de colaboracin, es un diagrama de Interaccin que pone el
nfasis en la organizacin estructural de los objetos o roles que envan y
reciben mensajes.
El Diagrama de estados, muestra un autmata que consiste de estados,
transiciones, eventos y actividades.
El Diagrama de actividades, muestra la estructura de un proceso u otro
clculo como el flujo de control y datos paso a paso en el clculo.
El Diagrama cronolgico, es un diagrama de interaccin que muestra
tiempos a lo largo de diferentes objetos o roles, y no secuencias relativas de
mensajes.
El Diagrama de interacciones general, es un hbrido de diagramas de
actividad y de secuencia.
41
Leccin 5
Introduccin 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 quin hace
qu, cundo y cmo (Jacobson, 2000).
Es un marco de trabajo genrico 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 especfico (o
equipo especfico). Una misma persona puede llevar a cabo diversos roles.
Algunos ejemplos de rol son Lder de Proyecto, Analista de sistemas,
programador.
5.2.2
Actividad
Es una unidad de trabajo que debe ser ejecutada. Una actividad es la ms

pequea pieza de trabajo que es relevante. No es razonable hacer actividades
en forma parcial. Dividir el trabajo de esta manera hace ms fcil 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 Iteracin, Revisar el Diseo, Capturar requisitos.
5.2.3
Artefacto
Es una pieza de informacin 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 cdigo fuente, los
modelos, documentos y otros productos del ciclo de vida. UML define la
notacin para representar la mayor parte de los artefactos.
5.2.4
Modelo
Cada Trabajador, necesita una perspectiva del Sistema. El Artefacto ms

comn para representar una perspectiva es el Modelo. Los principales modelos
de RUP son: Modelo del negocio, modelo de casos de uso, modelo de diseo,
modelo de implementacin, 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
informacin que lo soportan.
El Modelo de Casos de Uso es un modelo acerca de lo que el sistema debe
hacer y su medioambiente.
42
El Modelo de Diseo es un modelo de objetos que describen la realizacin de

los Casos de Uso. Sirve como una abstraccin del Modelo de Implementacin y
su cdigo fuente.
El Modelo de Implementacin 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 travs de modelos. Se requieren muchos modelos para
describir el sistema durante su evolucin. 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.
Elaboracin, Construccin y Transicin (Figura 5.2). Estas fases estn mucho
ms relacionadas con el funcionamiento de la organizacin que con aspectos
tcnicos de la implementacin
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
interactuarn con el sistema y definir estas interacciones. Esta informacin se
utiliza entonces para evaluar la aportacin que el sistema hace al negocio. Si
esta aportacin es de poca importancia se puede cancelar el proyecto despus
de esta fase.
43
5.3.2
Fase de Elaboracin
Los objetivos de esta fase son: Comprender el dominio del problema,

Establecer un marco de trabajo arquitectnico 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 descripcin arquitectnica, Un plan de
desarrollo del software,
5.3.3
Fase de Construccin
Comprende fundamentalmente: El diseo del sistema, La implementacin, Las

pruebas. Durante esta fase se desarrollan e integran las partes del sistema.
Al finalizar esta fase, se obtienen: Un sistema software funcional, La
documentacin correspondiente a ste.
5.3.4
Fase de Transicin
Se ocupa de mover el sistema desde la comunidad de desarrollo a la

comunidad del usuario. Tambin de hacer trabajar el software en un entorno
real. Esta fase es comnmente ignorada en la mayora de los modelos de
proceso de software, an 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 esttica del RUP se centra en las actividades que tienen lugar
durante el proceso de desarrollo. stas se denominan flujos de trabajo en la
descripcin del RUP (Figura 5.2).
Existen seis flujos de trabajo del proceso:
Modelado de negocio
Requerimientos
Anlisis y diseo
Implementacin
Pruebas
Implantacin
Existen tres flujos de trabajo de soporte
Administracin de cambios y configuracin
Administracin del proyecto
Entorno
Figura 5.2 Estructura del RUP, fases y flujos.
44
Fuente: (Jacobson, 2000)
45
Resumen
Proceso de desarrollo de sistemas de informacin
Un proceso de desarrollo es una gua acerca de las actividades y tareas

necesarias para construir un sistema de informacin. Es un marco de trabajo
que define las tareas a realizar para desarrollar software de alta calidad.
Las fases genricas de un proceso de desarrollo son: Definicin, Desarrollo y

Evolucin.
La fase de definicin se centra en el que. Su propsito es identificar las
necesidades o requerimientos del cliente/usuario. Sus actividades son:
Anlisis del sistema, Requerimientos de software, y Planificacin del
proyecto de software.
La fase de desarrollo se centra en el cmo. Su propsito es descubrir
cmo han de disearse las estructuras de datos y la arquitectura del
software, etc. Se realizan tres pasos concretos: Diseo del Software,
Codificacin y Pruebas del software.
La fase de evolucin, tambin llamada fase de mantenimiento, se centra en
el cambio que va asociado a la Correccin, a la Adaptacin 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 cclica. Entre los modelos iterativos podemos mencionar:
Construccin de prototipos y Desarrollo Rpido de Aplicaciones.
Modelos evolutivos, se caracterizan porque son iterativos y en cada
iteracin se agrega nueva funcionalidad (versiones) al sistema. Se puede
mencionar al modelo incremental y al modelo espiral.
Una metodologa representa el camino a seguir para desarrollar software o

aplicaciones informticas de una manera sistemtica, consiste de un conjunto
de fases subdivididas en etapas, actividades y tareas.
Una tarea es una actividad elemental siguiendo algn procedimiento.
El procedimiento es la definicin de la forma de ejecutar la tarea.
La tcnica es la herramienta utilizada para aplicar un procedimiento; se
pueden utilizar una o varias.
Una herramienta es el soporte software que apoya la aplicacin de una
tcnica.
Un producto es el resultado de cada fase, etapa o actividad de una
metodologa
Introduccin a UML

lenguaje, basado en una notacin grfica, 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 informacin que es utilizada o producida durante
un proceso de desarrollo de software. Ejemplo: documento de especificacin
de requisitos, un modelo, un programa.
Un modelo es una representacin abstracta de una especificacin, un
diseo o un sistema desde un punto de vista particular. Representa uno o
ms diagramas. Ejemplos: modelo de casos de uso, modelo de negocio.
Un diagrama es una representacin grfica de una coleccin de elementos
del modelo. Ejemplos: diagrama de casos de uso, diagrama de clases.
46
Los elementos del UML se clasifican en: estructurales, de comportamiento, de

agrupacin y de anotacin.
Los elementos estructurales representan la parte esttica 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 dinmica del
sistema, es decir el comportamiento en el tiempo y el espacio. Se incluyen:
Interacciones y estados.
Los elementos de agrupacin representan la parte organizativa del sistema.
Incluye: Paquete.
Los elementos de anotacin representan la parte explicativa del sistema.
Son comentarios. Incluye: la nota
Las relaciones en UML representan los vnculos entre dos elementos del
modelo. Incluye: dependencia, asociacin, generalizacin y realizacin.
La dependencia representa una relacin semntica 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 asociacin representa una relacin estructural que describe un conjunto
de links, siendo un link una conexin entre objetos.
La generalizacin representa una relacin de generalizacin/especializacin
en la que el elemento especializado (descendiente) se construye sobre la
especificacin del elemento generalizado (ancestro)
La realizacin representa una relacin semntica 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 colaboracin, garantiza llevar a cabo.
Los diagramas en UML, version2.0, son 13, divididos en diagramas estticos y

dinmicos.
Los diagramas estticos son: diagrama de clases, diagrama de objetos,
diagrama de componentes, diagrama de despliegue, diagrama de paquetes
y diagrama de estructura.
Los diagramas dinmicos son: diagrama de casos de uso, diagrama de
secuencia, diagrama de colaboracin, diagrama de estado, diagrama de
actividades, diagrama cronolgico, diagrama de interacciones.
Introduccin a RUP
El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso

qu, cundo y cmo
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 informacin que es producida, modificada o
usada en un proceso de desarrollo de software
Un modelo es una representacin 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, Elaboracin, Construccin y Transicin.
47
Lectura
Tcnicas de cuarta generacin (*)
El trmino tcnicas de cuarta generacin (T4G) abarca un amplio espectro de
herramientas de software que tienen algo en comn: todas facilitan al
ingeniero del software la especificacin de algunas caractersticas del software
a alto nivel. Luego, la herramienta genera automticamente el cdigo fuente
basndose en la especificacin del tcnico. Cada vez parece ms evidente que
cuanto mayor sea el nivel en el que se especifique el software, ms rpido se
podr construir el programa. El paradigma T4G para la ingeniera del software
se orienta hacia la posibilidad de especificar el software usando formas de
lenguaje especializado o notaciones grficas que describa el problema que hay
que resolver en trminos 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, generacin de informes, manejo de datos,
interaccin y definicin de pantallas, generacin de cdigos, capacidades
grficas de alto nivel y capacidades de hoja de clculo, y generacin
automatizada de HTML y lenguajes similares utilizados para la creacin de
sitios web usando herramientas de software avanzado. Inicialmente, muchas
de estas herramientas estaban disponibles, pero slo para mbitos de
aplicacin muy especficos, pero actualmente los entornos T4G se han
extendido a todas las categoras de aplicaciones del software.
Al igual que otros paradigmas, T4G comienza con el paso de reunin de
requisitos. Idealmente, el cliente describe los requisitos, que son, a
continuacin, traducidos directamente a un prototipo operativo. Sin embargo,
en la prctica no se puede hacer eso. El cliente puede que no est seguro de lo
que necesita; puede ser ambiguo en la especificacin de hechos que le son
conocidos, y puede que no sea capaz o no est dispuesto a especificar la
informacin en la forma en que puede aceptar una herramienta T4G. Por esta
razn, el dilogo cliente-desarrollador descrito por los otros paradigmas sigue
siendo una parte esencial del enfoque T4G.
Para aplicaciones pequeas, se puede ir directamente desde el paso de
recoleccin de requisitos al paso de implementacin, usando un lenguaje de
cuarta generacin no procedimental (L4G) o un modelo comprimido de red de
iconos grficos. Sin embargo, es necesario un mayor esfuerzo para desarrollar
una estrategia de diseo para el sistema, incluso si se utiliza un L4G. El uso de
T4G sin diseo (para grandes proyectos) causar las mismas dificultades (poca
calidad, mantenimiento pobre, mala aceptacin por el cliente) que se
encuentran cuando se desarrolla software mediante los enfoques
convencionales.
La implementacin mediante L4G permite, al que desarrolla el software,
centrarse en la representacin de los resultados deseados, que es lo que se
traduce automticamente en un cdigo fuente que produce dichos resultados.
Obviamente, debe existir una estructura de datos con informacin relevante y
a la que el L4G pueda acceder rpidamente.
Para transformar una implementacin T4G en un producto, el que lo desarrolla
debe dirigir una prueba completa, desarrollar con sentido una documentacin
y ejecutar el resto de las actividades de integracin que son tambin
requeridas por otros paradigmas de ingeniera del software. Adems, el
software desarrollado con T4G debe ser construido de forma que facilite la
realizacin del mantenimiento de forma expeditiva.
48
Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e
inconvenientes. Los defensores aducen reducciones drsticas 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 ms fciles de utilizar que los lenguajes de
programacin, que el cdigo fuente producido por tales herramientas es
ineficiente y que el mantenimiento de grandes sistemas de software
desarrollados mediante T4G es cuestionable.
Hay algn mrito 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 aplicacin. Junto con las herramientas de ingeniera de software
asistida por computadora (CASE) y los generadores de cdigo, T4G
ofrece una solucin fiable a muchos problemas del software.
2. Los datos recogidos en compaas que usan T4G parecen indicar que el
tiempo requerido para producir software se reduce mucho para
aplicaciones pequeas y de tamao medio, y que la cantidad de anlisis
y diseo para las aplicaciones pequeas tambin se reduce.
3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de
software exige el mismo o ms tiempo de anlisis, diseo y prueba
(actividades de ingeniera del software), para lograr un ahorro sustancial
de tiempo que puede conseguirse mediante la eliminacin de la
codificacin.
Resumiendo, las tcnicas de cuarta generacin 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, pp. 29-30)
49
Actividades
1. Realice un cuadro comparativo entre los modelos de ciclo de vida de
desarrollo de software, indicando criterios de comparacin, 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. .
Autoevaluacin
1. Con respecto al concepto de Proceso de Desarrollo, entre los parntesis de la
siguiente lista, marque V=Verdadero o F=Falso, segn corresponda:
a. (
) Es una gua acerca de las actividades para desarrollar sistemas de
informacin
b. ( ) Marco de trabajo que define tareas para desarrollar software
c. ( ) Es un proyecto de desarrollo de software
d. ( ) Conjunto de herramientas para desarrollar software
e. ( ) Conjunto de Mtodos para desarrollar software
2. En la celda a la derecha de la actividad de desarrollo de sistemas de informacin
coloque la letra de la descripcin que corresponda:
Actividad de
desarrollo
1. Anlisis de
sistemas
2.
Requerimientos
3. Planificacin
4. Diseo
5. Codificacin
6. Prueba
Descripcin de la actividad de desarrollo de S.I.

A Se analizan los riegos, se asignan recursos, se estiman costes y
se planifica
B Se traducen la representacin de diseo en instruccin
ejecutable (programa)
C Su objetivo es descubrir defectos que puedan existir
D Se traducen los requerimientos en representaciones de diseo
E Se define el papel de cada elemento del sistema de informacin
F Su resultado es informacin detallada de la funcionalidad del
software
3. En la celda a la derecha del modelo de proceso de desarrollo coloque la letra de la

caracterstica que le corresponda:
Modelos de Proceso
1. Secuencial
2. Prototipos
3. DRA
4. Incremental
5. Espiral
Caractersticas del modelo de desarrollo

A No son aptos para los sistemas que no se pueden modularizar
B Es til cuando no se esta seguro de poder cumplir con los plazos
C Es un modelo evolutivo que considera clave el anlisis de riesgos
D Una actividad no puede iniciar si no ha terminado la anterior
E Util cuando no se tiene claros los requerimientos desde el inicio.
4. Marque V= Verdadero o F = Falso, segn corresponda:

a. (
) Una metodologa es un conjunto de personas que coordinan para
desarrollar software
b. ( ) Una tarea es una actividad fundamental segn algn procedimiento
c. ( ) Un procedimientos es el soporte software para apoyar una tcnica
d. ( ) Una tcnica es la herramienta utilizada para aplicar un procedimiento
e. ( ) Un producto es el resultado de una fase o actividad de una metodologa
5. En relacin al UML y RUP, en la celda a la derecha del Termino coloque la letra de la
Definicin o Caracterstica que le corresponda:
Trmino
1. Artefacto
2. Clase
3. Caso de Uso
4. Elemento
Estructural
Definicin o Caractersticas del Termino

A. Representa funcionalidad del sistema como secuencia de
acciones
B. Proceso de desarrollo de software, marco genrico que puede
ajustarse
C. Rol que puede ser realizado por una persona o equipo
D. Representa conjunto de objetos con atributos, operaciones
comunes
50
5. UML
6. RUP
7. Trabajador
8. Flujo de Trabajo
9. Fase de Inicio
10. Fase de
Elaboracin
E. Define la lista de actividades, trabajadores y artefactos en el RUP

F. Representa pieza de informacin usada o producida en un
proceso de desarrollo
G. Fase del RUP que permite decidir continua o cancelar un
proyecto
H. Fase del RUP que permite comprender el dominio del problema
I . Permite especificar, construir, visualizar y documentar elementos
del software
J. Representan la parte esttica del sistema
1.
2.
3.
4.
5.
a = V,
1 = E,
1 = D,
a = F,
1 = F,
b = V,
2 = F,
2 = E,
b = V,
2 = D,
c = F, d = F, e = F
3 = A, 4 = D, 5 = B, 6 = C
3 = A, 4 = B, 5 = C
c = F, d = V, e = V
3 = A 4 = J, 5 = I, 6 = B , 7 = C , 8 = E, 9 = G , 10 = H
Exploracin on-line
ISO/IEC 12207
Pagina de la organizacin internacional para la estandarizacin, ISO
http://www.iso.org/iso/catalogue_detail.htm?csnumber=43447
OMG UML
Pagina oficial del Object Management Group, sobre UML, proporciona
informacin y recursos para UML
http://www.uml.org/
IBM - RUP
Pagina de IBM Rational Unified Process, que ofrece informacin 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 Educacin S.A.
Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de
Modelado UML. Segunda edicin. Madrid. Pearson Educacin S.A.
Pressman , Roger S. (2002) Ingeniera de Software. Un enfoque prctico.
5ta.Ed. Mc Graw Hill, Espaa.
51
TERCERA UNIDAD
EL MODELADO DEL NEGOCIO
Qu es el modelado de negocios, cules 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
realizacin de caso de uso del negocio?
Cmo se elabora el modelo del negocio?
PROPOSITOS
Explica las caractersticas, y elementos del modelado de negocio con UML
Elabora modelos de negocio, considerando modelo de casos de uso del
negocio y modelo de anlisis del negocio usando el UML
52
Leccin 6
Conceptos asociados al modelado del Negocio
6.1Qu es el Modelado del Negocio
El modelado del Negocio es una tcnica 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 anlisis del negocio.
6.2Modelo de Casos de Uso del Negocio

Es una representacin de la forma en que la empresa interacta con su
entorno. Provee una visin general de lo que la empresa hace con sus clientes
y otros participantes. Incluye metas del negocio adems de Actores y casos de
uso del negocio
6.2.1 Actor del Negocio

Representa un rol que alguien o algo desempea en relacin al Negocio.
La figura 6.1 muestra la notacin de actor de negocio. Un candidato a
actor de negocios es cualquier individuo, grupo, organizacin, empresa,
o mquina, externo al negocio, que interacta con ella.
Figura 6.1 Actor de negocio
Para comprender el contexto de un negocio, se debe conocer quien interacta

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 notacin
de caso de uso de negocio.
Figura 6.2 Caso de uso de negocio
53
Los casos de uso del negocio se clasifican en: Principales, de Soporte y de

Gestin. Los casos de uso del negocio principales son aquellos que estn
ligados directamente con la realizacin del producto y/o la prestacin del
servicio para el Cliente. Los casos de uso del negocio de soporte son aquellos
que proporcionan apoyo a los procesos principales, usualmente estn
relacionados con la gestin de recursos. Los casos de uso del negocio de
gestin son aquellos que estn vinculados al mbito de las responsabilidades
de la direccin, se relacionan con actividades de planificacin 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 gestin es necesario examinar las actividades
relacionadas con la gestin 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 Anlisis del Negocio

El Modelo de Anlisis de Negocios describe la realizacin de los casos de uso
del negocio mediante la interaccin de los trabajadores del negocio y las
entidades del negocio. Sirve como una abstraccin de cmo los trabajadores
del negocio y las entidades del negocio tienen que ser relacionados y como
ellos necesitan colaborar para la ejecucin del caso de uso del negocio.
6.3.1 Trabajador del negocio

Es una abstraccin de una persona o sistema software que representa un rol
que se ejecuta dentro de la realizacin de un CUN (figura 6.5).
Figura 6.5 Trabajador de negocio
54
Un trabajador del negocio (business worker) es alguien que realiza actividades

dentro de un caso de uso del negocio, interacta con otros trabajadores del
negocio y manipula entidades del negocio.
6.3.2 Entidad del negocio

Representa una pieza de informacin 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 informacin
con propiedades, comportamiento y semntica similares y que es manipulado
o manejado por trabajadores del negocio. Algunos ejemplos son: Factura,
Solicitud de pago y Tarjeta de crdito.
Figura 6.6 Entidad de negocio
6.3.3 Realizacin 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 Realizacin de caso de uso del negocio
La realizacin de un caso de uso del negocio (figura 6.7) 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 bsicos de un diagrama de actividades son: Inicio, fin,
actividad, transicin, barra de sincronizacin y bifurcacin.
En la figura 6.8 se observa un diagrama de actividades bsico, que se puede
interpretar como sigue: el proceso se inicia con el llenado del pedido, la flecha
de transicin entre llenar pedido y tramitar pedido significa que despus de la
actividad llenar pedido sigue la actividad tramitar pedido. Terminado de
tramitar el pedido, sigue la actividad 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 aceptacin y Ordenar
fabricacin, luego planificar produccin. Para que el flujo finalice
55
correctamente, tiene que terminarse las actividades Notificar aceptacin y

Planificar produccin.
En la figura 6.9 se muestra 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; y entidades de negocio: libro de citas, numero de trabajo
interno, orden de reparacin, etc.
Figura 6.8 Diagrama de actividades simple
LLENAR
PEDIDO
TRAMITAR
PEDIDO
NOTIFICAR
RECHAZO
ANALIZAR
VIABILIDAD
[ No es viable ]
NOTIFICAR
ACEPTACION
ORDENAR
FABRICACION
PLANIFICAR
PRODUCCION
Figura 6.9 Diagrama de actividades detallado
56
: Jefe de taller
: Dpto reparaciones
Revisar cita aceptada
a : Libro de citas
c : Orden de reparacin
[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 reparacin

o : Orden de reparacin
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 artculos, factura, etc.
Figura 6.10 Diagrama de clases de anlisis del negocio
57
Partes de trabajo
Obtiene precios de materiales
revisa partes pendientes
Inventario de articulos
(f rom Entidades del negccio)
Obtiene precio de mano de obra

indica numero de identificacion
Facturador
(f rom Trabajadores del negocio)
Registra pendiente
Asigna numero factura
Calcula importe total

Fichero de mecanicos
recib e copia
Cliente
(f rom Business Use-Case Model)
Realiz a
Factura
registrar facturas pagadas
Recib e
Em pleado del mostradoir
pago con tarjeta
(f rom Trabajadores del negocio)
pago
Pago en efectivo
58
Leccin 7
Proceso de modelado del Negocio
El proceso de construccin de un modelo de negocio se puede dividir en
construccin del modelo de casos de uso del negocio y construccin del
modelo de anlisis del negocio.
La construccin 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 construccin del modelo de anlisis 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 fabricacin de productos
bajo demanda. El gerente general esta interesado en satisfacer de la
mejor manera los pedidos de los clientes, establecindose el objetivo de
disminuir el tiempo de todo el proceso de la atencin 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
almacn 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 fabricacin a 0.5% del total,
mantener el stock adecuado de las materias primas y reducir el tiempo
de generacin de la orden de compra a proveedores en un 20% del
7.1.1 Identificando Actores del Negocio

De acuerdo con la especificacin, los actores son Cliente y Proveedor. El
Cliente interacta con la organizacin a travs del pedido. El Proveedor
interacta con la organizacin recibiendo la orden de compra de materia
prima.
Proveedor
Cliente
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:
59
Fabricar producto pedido y Controlar almacn. No se identifican casos de uso

del negocio de gestin.
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 tiempo en 20%
Mantener stock adecuado
Reducir tasa errores a 0.5% Reducir generacin 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.
60
Creado por : Cesar Luza

Fecha: Enero 25, 2010
Cliente
(f rom Actores del negocio)
Registrar pedido
(from Casos de uso del negocio)
Reducir tiempo en 20%

(f rom Metas del negocio)
Fabricar producto
Reducir tasa errores a 0.5%
Proveedor
(f rom Actores del negocio)
Controlar almacen
Mantener stock adecuado
Comprar materia prima
Reducir generacin orden compra en 20%
7.2 Elaborar el modelo de anlisis del negocio

En nuestro ejemplo, de la empresa Vende barato S.A. consideremos la
siguiente descripcin de caso de uso de negocio Registrar pedido:
1. El Cliente enva su pedido, por telfono, 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 (completndolo, si es
necesario). Comienza su procesamiento envindolo al Jefe Tcnico, que
est encargado de su anlisis.
3. El Jefe Tcnico analiza la viabilidad del producto solicitado. Si el
producto pedido est en el catlogo, su fabricacin es aceptada. En
caso contrario, es considerado un producto especial, y el Jefe Tcnico
estudia su fabricacin: Si es viable, la fabricacin del producto especial
es aceptada; Si no es viable, el producto especial no ser fabricado.
4. Una vez estudiado el pedido completo, el Jefe Tcnico informa al Dpto.
de Ventas de la aceptacin 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 fabricacin (la estndar si el producto estaba
catalogado, o una nueva, especficamente diseada para el producto, si
ste no estaba en el catlogo). Cada orden de trabajo es enviada al Jefe
de Produccin, y queda pendiente de su fabricacin.
5. El Empleado del Dpto. de Ventas comunica al cliente el resultado final
61
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

Realizacin con diagrama de actividades del Caso de Registrar Pedido
62
: Cliente
: Empleado de Ventas
: Jefe Tecnico
: Catalogo
Llenar pedido
: Jefe Produccion
: Plantilla de fabricacion
p : Pedido
[propuesto]
Analizar viabilidad
x : Pedido
: Producto especial
Tramitar pedido
[ NO Viable ]
[ SI viable ]
: Plantilla de fabricacion
Informar rechazo
r : Pedido
[Rechazado]
Ordenar Fabricacin
: Orden de Trabajo
Informar aceptacion
a : Pedido
Planificar produccin
[Aceptado]
63
Resumen
Conceptos asociados al modelado del negocio
El modelado del negocio es una tcnica para representar proceso de negocio,

tiene dos perspectivas: externa (modelo de casos de uso) e interna (modelo de
anlisis del negocio).
El modelo de casos de uso del negocio representa la forma en que la empresa
interacta con su entorno. Incluye: actores, casos de uso del negocio.
o Un actor de negocio representa un rol que alguien o algo desempea en
relacin 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 anlisis del negocio describe la realizacin de los casos de uso del
negocio mediante interaccin de los trabajadores del negocio y las entidades
del negocio.
o Un trabajador de negocio representa un rol que se ejecuta en la
realizacin de un caso de uso del negocio.
o Una entidad de negocio representa una pieza de informacin
significativa y persistente que es manipulado por trabajadores de
negocio o actores de negocio.
o Una realizacin 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
Elaboracin 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
Elaboracin del modelo de anlisis del negocio
o Identificar trabajador de negocio
o Identificar entidad de negocio
o Construir realizacin de casos de uso del negocio
Con Diagrama de actividades
Con diagrama de clases de anlisis del negocio
64
Lectura
Manifiesto de Reglas de Negocio (*)
Los Principios de la Independencia de las Reglas
The Business Rules Group
Artculo 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 tecnologa, y una parte separada y especifica de los mismos.
Artculo 2. Independientes de los procesos y no contenidas en ellos

2.1.Las reglas son restricciones explicitas de comportamiento y/o proporcionan
soporte para la direccin de las actividades de negocio.
2.2.Las reglas no son procesos ni procedimientos. Y por tanto no deben estar
contenidas en ninguno de ellos.
2.3.Las reglas se aplican a lo largo de los procesos y procedimientos. Debe existir
un corpus coherente de reglas que se aplique sistemticamente en todas las
reas de actividad del negocio.
Artculo 3. Proporcionar conocimiento meditado, no un sub-producto

5.1.
Las reglas se construyen sobre hechos, y los hechos sobre conceptos tal
y como son expresados mediante trminos.
5.2.
Los trminos expresan conceptos de negocio; los hechos realizan
afirmaciones sobre estos conceptos; las reglas restringen y apoyan estos
hechos.
5.3.
Las reglas deben ser explicitas. No se debe asumir ninguna regla sobre
ningn concepto o hecho.
5.4.
Las reglas son los fundamentos que definen lo que el negocio sabe de si
mismo- es decir son conocimiento bsico de negocio.
5.5.
Las reglas necesitan ser alimentadas, protegidas y gestionadas.
Artculo 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
implcita.
4.4 Cualquier enunciado de reglas que necesite de otros elementos que no sean
trminos o hechos, revelan hiptesis sobre la implementacin 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.
Artculo 5. Expresiones bien formadas, no expresiones creadas con fines

especficas para un caso
5.1 Las reglas de negocio se deben expresar demanera que pueda ser validada su
exactitud por el personal conocedor del negocio.
5.2 Las reglas de negocio se deben expresar de manera que se pueda verificar
recprocamente su coherencia.
5.3 Las lgicas formales, como la lgica de predicados, son fundamentales para la
expresin formal de reglas en trminos de negocio, as como para las
tecnologas que implementan dichas reglas.
Artculo 6. Arquitectura basada en las reglas, no una implementacin 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 evolucin.
65
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 conclusin o emprende una accin.
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 relacin entre eventos y reglas es generalmente de muchos-a-muchos.
Artculo 7. Procesos guiados por reglas, no programacin basada en

excepciones
7.1 Las reglas definen el lmite entre actividad de negocio aceptable y no
aceptable.
7.2 Las Reglas requieren a menudo de una gestin especial o especifica de las
violaciones detectadas. Cualquier actividad derivada de la violacin de una
regla es una actividad como cualquier otra.
7.3 Para asegurar la mxima consistencia y reutilizacin, el tratamiento de las
actividades de negocio no aceptables, debe separarse de la gestin de
actividades de negocio aceptables.
Artculo 8. Al servicio del negocio, no al de la tecnologa

8.1Las Reglas tratan sobre las prcticas de la gestin y gobierno del
negocio, por lo tanto son motivadas por las metas y los objetivos de
negocio y se les da forma a travs de varios factores internos y externos
a la empresa.
8.2Las reglas suponen siempre un coste a la empresa.
8.3Este coste de la aplicacin 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.4Ms reglas no es mejor, la abundancia de reglas no beneficia a su
aplicacin. Normalmente es mejor un nmero limitado de reglas bien
reflexionadas.
8.5Un sistema eficaz puede estar basado en un pequeo nmero de reglas.
Adicionalmente, se pueden aadir reglas ms discriminatorias, por las
que ha medida que pasa el tiempo el sistema mejore y se hace ms
inteligente.
Artculo 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.
Artculo 10. Gestionando la lgica de negocio, no las plataformas de

Hardware/Software
10.1
Las reglas de negocio son un patrimonio vital del negocio.
10.2
A largo plazo, las reglas son ms importantes para el negocio que las
plataformas Hardware/Software.
10.3
Las reglas de negocio deben organizarse y salvaguardarse de forma que
puedan ser redesplegadas a nuevas plataformas de Hardware/Software.
10.4
Las reglas, y la habilidad para cambiarlas de forma eficaz, son factores
clave para mejorar la adaptabilidad de las empresas.
66
(*) Business Rules Group. Version 2.0, November 1, 2003. Edited by Ronald G. Ross.
www.businessrulesgroup.org/brmanifesto/BRManifiesto.pdf
67
Actividades
Elaborar el Modelo del Negocio considerando la siguiente descripcin:
La Empresa FABCLM se dedica a la fabricacin de productos de consumo
masivo. La Gerencia General desea automatizar las principales
actividades que la empresa realiza en los procesos de atencin de
pedidos, control de la fabricacin, proceso de facturacin y entrega de
mercadera.
Proceso de atencin de pedidos
El cliente enva su pedido por distintos medios (telfono, correo o fax),
son recibidos por la empleada encargada de la Oficina de Atencin a
Clientes, quien solicita que se realicen las siguientes comprobaciones:
Antonio (Dpto de Almacn) se encarga de verificar la disponibilidad de los
artculos solicitados, consultando el inventario de artculos. 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
sern rechazados, notificndoselo al cliente. Pero si todo es correcto, se
registrar aceptacin del pedido. En ambos casos es la empleada la que
informa al cliente.
Proceso de control de fabricacin
El proceso se inicia cuando el pedido aceptado es recibido por el Jefe de
Produccin, quien le asigna un nmero de trabajo interno, luego genera
la orden de produccin y registra el pedido como pendiente de
fabricacin. La orden de produccin se enva a la seccin de fabricacin
para que empiece a elaborar los productos del pedido. Cuando finaliza el
trabajo, el Jefe de Produccin elabora una carta donde indica a quin
sern enviados los productos que se encuentran listos. Evidentemente, el
pedido deja de ser pendiente.
Proceso de Facturacin
Recibida la carta de productos terminados el Dpto de Facturacin procede
a elaborar la factura y el taln de embarque. Una copia de la factura se
enva al Dpto. de Contabilidad que se encarga de realizar los asientos.
Otra copia se aade 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 artculos elaborados se reciben en el rea de embarque, donde son
empaquetados, y el taln de embarque se anexa a la caja de embarque.
68
Autoevaluacin
1. Con respecto al Modelado del Negocio, entre los parntesis de la siguiente lista,
marque V=Verdadero o F=Falso, segn corresponda:
a. ( ) Es una tcnica para representar un sistema software
b. (
) Permite asegurar que se construir el sistema en el contexto de
necesidades de la empresa
c. ( ) Es un Marco de trabajo que define los procesos de negocio
d. ( ) Tiene dos perspectivas, una externa y otra interna
e. ( ) El modelo de casos de uso del negocio representa la perspectiva interna
f. ( ) El modelo de anlisis del negocio representa la perspectiva externa
2. En relacin al Modelo de casos de uso del negocio y modelo de anlisis del negocio,
en la celda a la derecha del Termino coloque la letra de la Definicin o
Caracterstica que le corresponda:
Trmino
1. Actor del negocio
2. Casos de uso del
negocio
3. Meta del negocio
4. Trabajador del
negocio
5. Entidad del
negocio
6. Diagrama CUN
7. Realizacin de CUN

A. Representa un proceso del negocio
B. Representa el valor deseado en una medida particular
C. Muestra actores de negocio, casos de uso de negocio y sus
relaciones
D. Representa pieza de informacin significativa
E. Representa un rol que alguien desempea en relacin al
Negocio
F. Describe la colaboracin entre trabajadores, entidades y
eventos del negocio
G. Representa un rol dentro de la realizacin de un CUN
1. a = F, b = V, c = F, d = V, e = F, f = F
2. 1 = E, 2 = A, 3 = B, 4 = G, 5 = D, 6 = C, 7 = F
Exploracin on-line
Pagina de IBM Rational Unified Process, que ofrece informacin y recursos

sobre la plataforma de proceso de desarrollo de software configurable
http://www-01.ibm.com/software/pe/rational/rup.shtml
69
CUARTA UNIDAD
EL MODELADO DE DOMINIO
Qu es el modelado de dominio?
Qu es un diagrama de clases?
Cules son sus elementos? y
Cmo se construye?
PROPOSITOS
Explica las caractersticas, y elementos del modelado de dominio con UML
Elabora modelos de dominio, usando diagrama de clases del UML
70
Leccin 8
Conceptos asociados al modelo de dominio
En el contexto de desarrollo de sistemas de informacin, es frecuente, en las
primeras etapas del proceso, construir un modelo del dominio del problema
para representar las propiedades ms importantes del mbito del negocio
relacionado con el problema.
Una tcnica muy utilizada para representar este modelo de domino es el
diagrama de clases de UML; precisamente, en esta leccin se describen las
bases conceptuales para construir adecuadamente un diagrama de clases.
8.1 Clase y Objeto

Un objeto se define como un concepto, abstraccin o cosa con lmites 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 semntica comn (Rumbaugh, 1996).
Por ejemplo, Anlisis de sistemas, Base de datos I, Estadstica II,
Matemtica Bsica I son objetos de la clase ASIGNATURA, en otras palabras,
ASIGNATURA representa al conjunto de todas las asignaturas en el dominio de
la gestin acadmica de una institucin educativa.
8.2
Atributo
Una clase tiene una serie de caractersticas o propiedades, por ejemplo

ASIGNATURA tiene cdigo, nombre, crditos, horas de teora, horas de
practica; a estas propiedades se le conoce como atributos de la clase. 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 especficos para cada uno de los atributos de la
clase.
Por ejemplo, la clase AUTOMOVIL, tiene como atributos: nmero de placa,
color, modelo, nmero de puertas, ao, entre otros. Un objeto, de la clase
AUTOMOVIL, es el auto de placa SGD345, color azul, modelo Station Wagon,
con cuatro puertas, del ao 2000. Otro objeto es el auto de placa ERG237,
negro, deportivo, 4 puertas, ao 2009.
8.3
Operacin
Una clase tiene un comportamiento que es definido por las operaciones o

responsabilidades que la clase puede realizar. Una operacin es algo que la
clase puede realizar o que otra clase puede hacer a una clase. Es una funcin
o transformacin que se puede aplicar o que puede ser aplicada por los
objetos de una clase (Rumbaugh, 1996)..
Por ejemplo, algunas operaciones de la clase automvil pueden ser: Encender,
Apagar, Acelerar, Frenar.
71
8.4 Asociacin y Enlace

Las entidades, objetos 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 abstraccin de asociacin se vincula dos o ms clases, crendose
un elemento de tipo distinto (Vinculo).
Por ejemplo, DOCENTE dicta ASIGNATURA, es una asociacin entre la clase
DOCENTE y la clase ASIGNATURA. Mientras que Cesar Luza dicta Anlisis de
sistemas es un ejemplo de enlace entre los objetos Cesar Luza y Anlisis
de sistemas que pertenecen a las clases DOCENTE y ASIGNATURA,
respectivamente.
8.5 Generalizacin y Agregacin

La generalizacin y agregacin son dos tipos especiales de relaciones entre
clases (Rumbaugh, 1996)..
La Generalizacin representa la relacin entre clases, donde algunas de ellas
son tipos de otra. Por ejemplo, las clases SECRETARIA, TCNICO, INGENIERO
son tipos de la clase EMPLEADO; en otras palabras, EMPLEADO es una
generalizacin de las clases SECRETARIA, TECNICO, INGENIERO (ver figura
8.1).
Mediante la generalizacin se abstrae las caractersticas comunes a varias
clases (subclases) para construir una clase ms general (superclase), la
generalizacin define una relacin de subconjunto entre elementos de dos o
ms clases.
Figura 8.1 Ejemplo de generalizacin
GENERALIZACIN
SECRETARI
EMPLEADO
TECNIC
INGENIER
Una Clase ES UN TIPO DE otra
clase
La Agregacin representa la relacin 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 agregacin se construye una nueva clase o tipo o categora de
objetos a partir de un conjunto de otras clases denominadas componentes o
partes. La agregacin 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 Agregacin
CPU
AGREGACIN
MOUSE
COMPUTAD
ORA
MONITO
TECLAD
72
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 Gestin Acadmica
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 esttico del UML, que describe
la estructura de un sistema mostrando sus clases y sus relaciones. En la figura
8.3 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 interpretacin o lectura de un diagrama de clases permite a desarrolladores
y usuarios disponer de un lenguaje uniforme para mostrar caractersticas del
negocio en el dominio del problema. Por ejemplo, en la figura 8.3, podemos
leer la siguiente restriccin semntica: una lnea de venta est contenida en
una venta y sta puede contener muchas lneas de venta, nunca ninguna lnea
de venta. Adems, cada lnea de venta registra la venta de un articulo y un
articulo puede o no estar en una lnea de venta.
Figura 8.3 Ejemplo de diagrama de Clases
concepto u
objeto del
dominio
asociacin
Registra-venta-de
LineaDeVenta
cantidad
0..1
Artculo
1
*
1..n
Contenida-en
Almacenado-en
1
Tienda
direccin
tienda
1
atributos
Venta
fecha
hora
Capturada-en
Pagada-mediante
1
Pago
cantidad
Alberga
1
1..*
Registro
Fuente: (Larman, 1999)
8.8 Notacin UML para modelo de domino

Clase
Para efectos del modelo de dominio, una clase puede considerarse en trminos
de:
Smbolo, palabras o imgenes que representan a la clase;
73
Definicin del concepto, descripcin textual del significado de la

clase y
Extensin: conjunto de objetos que pertenecen a la clase.
Por ejemplo, considere la clase Venta de la figura 8.4. El smbolo del concepto
es un rectngulo dividi en tres partes, la primera es el nombre de la clase, la
segunda los atributos y la tercera las operaciones. La definicin del concepto
es: Una venta representa el hecho de una transaccin de compra, sucede un
da y en una hora. La extensin es el conjunto de todas las ventas realizadas
en la tienda.
Figura 8.4 Clase

Venta
fecha
hora
Atributo
Para efectos del modelo de dominio se incluyen aquellos atributos para los que
los requisitos indican la necesidad de registrar su informacin.
Por ejemplo, un recibo recoge la informacin de una venta, incluyendo fecha y
hora. La Gerencia de la Tienda quiere conocer fecha y hora de las ventas,
entonces, la clase Venta debe incluir los atributos fecha y hora.
Segn la notacin UML, los atributos se muestran
compartimento del rectngulo de la clase (figura 8.5).
en
el
segundo
Figura 8.5 Atributos

Venta
fecha
hora
Asociacin
La asociacin se representa con una lnea que une las clases relacionadas
(figura 8.6). En el siguiente ejemplo, se muestra la relacin entre las clases
ALUMNO y FACULTAD; la semntica seala que un alumno pertenece a una
nica facultad y una facultad tiene muchos alumnos, por lo menos uno.
Figura 8.6 Asociacin
Alumno
1..n
pertenece a
74
Facultad
En una asociacin se incluye, opcionalmente, el nombre de la asociacin, la

navegabilidad, y obligatoriamente, la multiplicidad. La navegabilidad se
representa con una flecha que indica la direccin de envo de mensajes de un
objeto a otro. La multiplicidad representa la cantidad de objetos de una clase
que estn vinculados con un objeto de la clase asociada.
Por ejemplo, en la figura 8.6, el nombre de la asociacin es: pertenece a. La
multiplicidad de la asociacin es de uno a muchos; significa Un objeto de la
clase Alumno est vinculado con un solo objeto de la clase Facultad, y un
objeto de Facultad est 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 categoras tpicas 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
1
Decano
Dirige
Facultad
"Uno a Uno"
Aula
"Uno a Muchos"
Carrera
Laboratorio
"Muchos a Muchos"
Alumno
Tiene Instalado 0..1
Tiene
Tiene
0..n
1..n
1..n Matriculado En 1..n
Proyector
Convenio
Computadoras
Asignatura
Clase-Asociacin
En algunas ocasiones es necesario representar propiedades propias de la
asociacin; para tal efecto, se crea una clase especial llamada ClaseAsociacin. Por ejemplo, consideremos la asociacin ALUMNO matriculado en
ASIGNATURA, la multiplicidad de esta asociacin es de muchos a muchos,
significa que un alumno puede llevar varias asignaturas y una asignatura es
llevada por varios alumnos; y la nota promedio de un alumno en una
asignatura corresponde a la asociacin; pues si se coloca como atributo de
alumno, no se sabra de qu asignatura es; si se coloca como atributo de
asignatura, no se sabra de qu alumno es, entonces, se crea una clase
especial llamada clase asociacin MATRICULA en el que se coloca el atributo
nota promedio.
75
La representacin de una clase asociacin se hace con una lnea discontinua

que une la asociacin con la clase generada. (Figura 8.8).
Figura 8.8 Ejemplo de Clase-Asociacin
Alumno
1..n Matriculado En 1..n
Asignatura
Matricula
notaPromedio
Generalizacin
La generalizacin se representa a travs de una lnea recta entre las clases
subtipos terminados en un tringulo blanco en el extremo cercano a la clase
generalizada. Por ejemplo, en la figura 8.9, ANFIBIO, MAMFERO y REPTIL son
tipos de ANIMAL. A su vez, CABALLO es un tipo de MAMFERO.
La Generalizacin puede encontrarse en aquellas clases que tienen ciertos
atributos y operaciones en comn. En ese caso se crea una clase nueva que
asume dicho comportamiento comn.
Figura 8.9 Ejemplo de Generalizacin
Agregacin
La agregacin se representa a travs de una lnea 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 Agregacin
76
77
Leccin 9
Proceso de construccin del modelo de dominio
Para construir el modelo de dominio se puede seguir las siguientes
actividades: Identificar las Clases conceptuales o del dominio, Identificar las
asociaciones, Identificar atributos, Identificar relacin de generalizacin y
refinar el modelo.
Consideremos la siguiente descripcin para realizar el modelo de dominio.
Una empresa recin formada se dedica a integrar partes para formar
productos con la intencin de vender el valor agregado de la integracin.
Con el objetivo de apoyar sus actividades, mediante una aplicacin
informtica, se ha obtenido las siguientes reglas semnticas:
Un producto tiene un nombre y un precio base. Un producto se forma con
muchas partes y cada parte puede formar muchos productos. La definicin
de cada producto especifica qu cantidad de cada parte forma a un
producto dado.
Un vendedor tiene un apellido, nombre y un porcentual de comisin. Tanto
un cliente como un proveedor tienen los datos de todo agente comercial;
stos son: cuit, razn social, e-mail, telfono y direccin. Adems, 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 estn formados por una nica parte,
9.1 Identificando Clases
Muchos de las clases del dominio pueden obtenerse de una especificacin 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 aviacin enemiga, misiles y trayectorias.
Sucesos que ocurrirn o han ocurrido, como la llegada de un avin, sus
salidas y la hora de la comida.
Otra estrategia es seleccionar los nombres o sustantivos de la descripcin 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
implementacin.
En nuestro ejemplo las clases conceptuales identificadas son:
producto
parte
vendedor
cliente
78
proveedor
agenteComercial
9.2 Identificando Asociaciones

Se establecen las asociaciones segn las reglas del negocio en el dominio del
problema, se puede considerar como estrategia para identificar asociaciones la
seleccin de verbos en la descripcin del problema. Se le agrega la
multiplicidad correcta. Tambin se puede representar la relacin " es parte de"
o agregacin.
En nuestro caso, las asociaciones identificadas son:
vendedor
producto
se forma
1..n
1..n
1..n
parte
1..n
se vende
Se compra
agenteComercial
1..n
1..n
proveedor
cliente
9.3 Identificando Atributos

Por cada clase se indican los atributos necesarios que respondan a los
requerimientos del dominio del problema. Si los atributos corresponden a una
asociacin, crear una clase asociacin.
En nuestro ejemplo, se sealan los atributos por cada clase y adicionalmente,
se identifican atributos para las algunas asociaciones, crendose las clases
asociacin: definicin, compra y venta.
vendedor
apellido
nombre
porcComis
producto
nombre
precioBase
1..n
1
participa
0..n
1..n
se forma
definicin
cantidad
1..n
parte
numParte
descripcin
1..n
se vende
agenteComercial
cuit
razSocial
email
telf
direcc
venta
fecha
1..n
Se compra
1..n
cliente
porcDesc
proveedor
plazoPago
79
compra
fecha
cantidad
9.4 Identificando relaciones de generalizacin

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 relacin de generalizacin entre agente
comercia con cliente y proveedor:
vendedor
apellido
nombre
porcComis
producto
nombre
precioBase
1..n
1..n
se forma
definicin
cantidad
1..n
parte
numParte
descripcin
1..n
participa
0..n
se vende
agenteComercial
cuit
razSocial
email
telf
direcc
venta
fecha
Se compra
compra
fecha
cantidad
1..n
1..n
proveedor
plazoPago
cliente
porcDesc
9.5 Refinando 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 sealados en la descripcin del problema.
80
Resumen
Conceptos asociados al modelo de dominio
Un objeto se define como un concepto, abstraccin o cosa con lmites 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 semntica comn
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 relacin entre objetos
Una asociacin es la relacin entre clases
La multiplicidad es la cantidad de objetos de una clase que estn vinculados
con un objeto de la clase asociada.
La Generalizacin representa la relacin entre clases, donde algunas de ellas
son tipos de otra
La Agregacin representa la relacin 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 esttico 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
asociacin; para tal efecto, se crea una clase especial llamada ClaseAsociacin
Proceso de construccin de modelo de dominio
Identificar clases
Identificar asociaciones
Identificar atributos
Identificar relaciones de generalizacin
Refinar el modelo
81
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
deberan incluir tanto a expertos del dominio como a gente con experiencia en
modelado.
El objetivo del modelado del dominio es comprender y describir las clases ms
importantes dentro del contexto del sistema. Los dominios de tamao
moderado normalmente requieren entre 10 y 50 de esas clases. Los dominios
ms grandes pueden requerir muchas ms.
Los restantes cientos de clases candidatas que los analistas pueden extraer
del dominio se guardan como definiciones en un glosario de trminos, de otra
manera, el modelo de dominio se har demasiado grande y requerira ms
esfuerzo del necesario para esta parte del proceso.
Algunas veces, como en los dominios del negocio muy pequeos, no es
necesario desarrollar un modelo de objetos para el dominios; en su lugar,
puede ser suficiente un glosario de trminos.
El glosario y el modelo de dominio ayudan a los usuarios, clientes,
desarrolladores, y otros interesados a utilizar un vocabulario comn. La
terminologa comn es necesaria para compartir el conocimiento con los otros.
Cuando abunda la confusin, el proceso de ingeniera se hace difcil, si no
imposible. Para construir un sistema software de cualquier tamao, los
ingenieros de hoy en da deben fundir el lenguaje de todos los participantes
en uno solo consistente.
Por ltimo, es necesario una llamada de atencin sobre el modelo de dominio.
Puede ser bastante fcil el comenzar modelando las partes internas de un
sistema y no su contexto. Por ejemplo, algunos objetos del dominio podran
tener una representacin inmediata en el sistema, y algunos analistas del
dominio podran a su vez caer en la trampa de especificar los detalles relativos
a esta representacin. En casos como stos, es muy importante recordar que
el objetivo del modelado del dominio es contribuir a la comprensin del
contexto del sistema, y por lo tanto tambin contribuir a la comprensin de los
requisitos del sistema que se desprenden de este contexto. En otras palabras,
el modelado del dominio debera contribuir a una compresin del problema
que se supone que el sistema resuelve en relacin a su contexto. El modo
interno por el cual el sistema resuelve ste problema se trata en los siguientes
flujos de anlisis, diseo e implementacin.
(*) Jacobson (2000, pp. 114-115)
82
Actividades
Desarrollar el modelo de dominio para el siguiente caso
Una Institucin Educativa ha decidido brindar unos cursos
extracurriculares, tanto para sus alumnos como para personas
externas a la Institucin. Las razones para la inclusin de personas
no pertenecientes a la Institucin son: obtener fondos para la
modernizacin de las instalaciones y ayudar al pago de los viticos
de los profesores invitados.
Se desea desarrollar una aplicacin que permita administrar el
dictado de los cursos; una primera aproximacin del contexto del
negocio es el siguiente:
Se brinda varios cursos. Cada curso tiene un nombre, un cupo
mximo y un cupo mnimo 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 ms de un curso. Cada docente tiene
apellidos, nombres, cargo y una dedicacin.
A cada alumno se le da un material general, independientemente
de la cantidad de cursos en que se haya inscrito, adems 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 mnima de inscritos cupo mnimo- y no sobrepasar el
cupo mximo.
De los alumnos internos se debe mantener la informacin de
apellidos, nombres y nmero de libreta; de los alumnos externos,
apellidos, nombres, nmero 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
ubicacin y una capacidad. No puede asignarse un aula a un curso
cuyo cupo mximo no entre en la misma.
83
Autoevaluacin
1. Entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn
corresponda:
a. ( ) Un objeto define un conjunto de clases con las mismas caractersticas
b. ( ) Pedro, Juan y Mara son ejemplos de objetos de la clase Persona
c. ( ) Tcnico, Obrero, Empleado son objetos de la clase PERSONAL
d. ( ) Una asociacin es una relacin entre clases
e. ( ) Una clase conceptual incluye elementos software
2. En relacin al Modelo de Dominio, en la celda a la derecha del Termino coloque la
letra de la Definicin o Caracterstica que le corresponda:
Trmino
1. Clase
2. Atributo
3. Asociacin
4. Multiplicidad
5. Clase
asociacin
6. Generalizacin
7. Agregacin

A. Representa una caracterstica o propiedad de una clase
B. Cantidad de objetos de una clase vinculados con un objeto de
clase asociada
C. Representa atributos propios de la asociacin
D. Representa un conjunto de objetos con las mismas
caractersticas
E. Representa relacin entre clase, algunas de ellas son tipos de
otra
F. Representa relacin entre clases, algunas de ellas son
componentes de otra
G. Representa vinculo entre dos o ms clases
1. a = F, b = V, c = F, d = V, e = F
2. 1 = D, 2 = A, 3 = G, 4 = B, 5 = C, 6 = E, 7 = F
Exploracin on-line
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: introduccin al anlisis y diseo
orientado a objetos. Mexico D.F. Prentice-Hall Hispanoamericana.
Rumbaugh, J. et. al. (1996). Modelado y diseo orientados a objetos.
Metodologa OMT. Mexico D.F. Prentice Hall Hispanoamericana.
84
QUINTA UNIDAD
EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO
Qu es un requerimiento?, Cmo se clasifican?

Qu es un modelo de casos de uso?Cules son sus elementos?
Cmo se construye un modelo de casos de uso?
PROPOSITOS
Al
finalizar esta unidad, el estudiante:

Explica el concepto de requerimiento y su clasificacin
Explica las caractersticas y elementos del modelo de casos de uso del UML
Elabora modelos de caso de uso usando el UML.
85
Leccin 10
Conceptos asociados los requerimientos
La importancia de la definicin, especificacin, anlisis y administracin de
requerimientos en un proyecto de desarrollo de software es ampliamente
reconocida; pues permite establecer las funcionalidades que deber tener el
producto software a desarrollar, que correspondan con las necesidades del
cliente/usuario; asimismo, sirve de base para la planificacin del proyecto y
para verificar si el producto software es de calidad.
Muchos proyectos fracasan por una mala definicin, especificacin, analisis y
administracin de requerimientos; la experiencia ha demostrado que las
actividades relacionadas con los requerimientos son complejas debido a la
poca participacin de los usuarios, al uso de lenguajes distintos entre
desarrolladores y usuarios, a los cambios de requerimientos, entre otras
razones.
Por ello, es importante para el profesional involucrado en proyectos de
desarrollo de software poseer las suficientes competencias para la definicin,
especificacin, anlisis y administracin de los requerimientos a fin de afrontar
con xito estas tareas.
En esta leccin se define y caracteriza el concepto de requerimientos y se
describen tcnicas para la captura de los mismos.
10.1
Qu es un requerimiento?
Un requerimiento es una condicin o capacidad a la que debe ajustarse el

sistema que se construye. (Jacobson, 2000, p.94)
De acuerdo con la IEEE Std. 610.12-1990, un requisito es: (1) Una condicin o
capacidad necesaria para un usuario para resolver un problema o conseguir un
objetivo. (2) Una condicin o capacidad que debe reunir o poseer un sistema o
componente de un sistema para satisfacer un contrato, estndar,
especificacin, u otro documento formalmente impuesto. (3) Una
representacin documentada de una condicin o capacidad como las definidas
en (1) o (2) (IEEE, 1990, p.64).
Un requerimiento es simplemente una declaracin abstracta de alto nivel de
un servicio que debe proporcionar el sistema o una restriccin de ste
(Somerville, 2005, p.108).
10.2
Tipos de Requerimientos
Los requerimientos se pueden dividir en dos tipos: Requerimientos Funcionales

y Requerimientos No funcionales.
10.2.1 Requerimiento Funcional

Un Requerimiento funcional es un requerimiento que especifica una accin que
debe ser capaz de realizar el sistema, sin considerar restricciones fsicas; 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 interaccin con otros sistemas.
86
Por ejemplo, los usuarios de un Sistema de Gestin Acadmica para la

Universidad pueden ser profesores y alumnos,
algunos requerimientos
funcionales son:
El sistema permitir a los profesores:
Consultar los horarios de sus asignaturas,
Consultar la programacin de los exmenes,
Actualizar y ver su informacin personal,
Registrar y modificar las notas de los estudiantes a su cargo,
El sistema permitir a los estudiantes:
Consultar los horarios de sus asignaturas,
Consultar la programacin de los exmenes,
Actualizar y ver su informacin personal,
Consultar notas de una asignatura.
10.2.2 Requerimiento No funcional

Un Requerimiento No funcional es un requerimiento que especifica
propiedades del sistema, como restricciones del entorno o de implementacin,
rendimiento, dependencia de la plataforma, mantenibilidad, extensibilidad o
fiabilidad; especifica restricciones fsicas 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:
10.3
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 documentacin adecuada que facilite
las tareas de mantenimiento..
La tasa de disponibilidad del sistema debe ser de un 99%.
Clasificacin de Requerimientos: Modelo FURPS
Una manera de categorizar los requerimientos est descrita en el modelo

FURPS (Larman, 2002), los requerimientos se clasifican en requerimientos de:
Functionality (Funcionalidad), Usability (Capacidad de Uso), Reliability
(Fiabilidad), Performance (Desempeo) y Supportability (Capacidad de
Soporte).
Los Requerimientos de Funcionabilidad (Functionality) son aquellos
requerimientos que reflejan las caractersticas fundamentales (requerimiento
funcional o funcionalidades del sistema), adems de capacidades y seguridad.
Los requerimientos de usabilidad o Capacidad de Uso (Usability), son aquellos
requerimientos que representan facilidad o nivel de uso del producto; es decir,
el grado en el que el diseo de un elemento facilita o dificulta su manejo. Se
incluyen: Factores humanos, Esttica, Consistencia de la interfaz de usuario,
Ayudas en lnea, Agentes y wizards, Documentacin de usuario y material de
entrenamiento. Por ejemplo, Visibilidad del texto a una cierta distancia y
Combinacin de colores del texto.
87
Los requerimientos de Fiabilidad (Reliability, son aquellos que muestran la

capacidad de un sistema o componente para ejecutar las funciones requeridas
bajo condiciones normales en un periodo de tiempo especifico. Tiene las
siguientes sub-categoras: Disponibilidad (el porcentaje de tiempo disponible,
horas de uso, acceso para mantenimiento, etc.); Tiempo medio entre fallas;
Tiempo medio para reparacin, cunto tiempo es posible que el sistema est
inoperante despus que falla; Exactitud (precisin y exactitud, segn algn
estndar conocido) que se requiere para las salidas del sistema; Cantidad
mxima de errores o porcentaje de defectos, generalmente expresado en
trminos de errores por miles de lneas de cdigo o errores por punto
funcional; Errores o porcentaje de defecto, categorizados en trminos de
errores menores, significantes y crticos (se debe definir que significa error
crtico, por ejemplo prdida completa de dato o imposibilidad de uso de
ciertas funcionalidades del sistema.
Los requerimientos de Desempeo (Performance), se refieren a las
caractersticas de rendimiento del sistema. Incluye tiempos de respuesta
especficos. Por ejemplo: Tiempo de respuesta para una transaccin
(promedio, mximo); Transacciones por segundo; Capacidad, como por
ejemplo el nmero de clientes o transacciones que el sistema puede soportar;
Modos de degradacin, esto es, cual es el modo aceptable de funcionamiento
cuando el sistema ha sido degradado de alguna manera; Utilizacin de
recursos: memoria, disco, comunicaciones, etc.
Los requerimientos de Capacidad de Soporte (Supportability), son
requerimientos que refuerzan el soporte y mantenimiento del sistema que est
siendo construido, incluyendo normas de codificacin, convenciones de
nombres, libreras, acceso para mantenimiento, utilidades de mantenimiento si
las hay. Como requerimiento que ayuda al mantenimiento se debe hacer
referencia al uso de nomenclatura comn para el desarrollo del sistema, y a la
metodologa de desarrollo.
ALGUNOS REQUERIMIENTOS FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS
PARA LA FACULTAD DE INGENIERIA DE SISTEMAS, CMPUTO Y
TELECOMUNICACIONES
El sistema permitir al secretario acadmico, introducir las asignaturas que se
imparten en el semestre acadmico, los datos del docente asignado a cada seccin,
de teora y prctica, de la asignatura, los datos de las aulas de teora (ubicacin y
aforo) y de prcticas (ubicacin, sistemas operativos, software,...).
La configuracin del horario se lleva a cabo directamente sobre una plantilla horaria
semanal, en la que cada casilla representar una hora en un determinado da de la
semana. Cuando el Secretario pulsa esa casilla se mostrarn las asignaturas del
curso que se est configurando en ese momento. Una vez escogida las asignaturas
se mostrarn las secciones de teora y prctica a los que todava no se les ha
asignado un horario. Al escoger una seccin se muestran las aulas disponibles (si es
un grupo de teora) o los laboratorios que cumplen las restricciones de sistemas
operativos establecidas para esa materia y que no estn ocupados a esa hora.
El sistema podr ser consultado por cualquier usuario, que podr consultar el horario
ALGUNOS REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA DE GESTION DE
HORARIOS PARA LA FACULTAD DE INGENIERIA DE SISTEMAS, CMPUTO 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 documentacin fcilmente actualizable que permita
realizar operaciones de mantenimiento con el menor esfuerzo posible.
88
10.4
Caractersticas 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, cmo se sabe si se cumpli con l o no?
Conciso, un requerimiento es conciso si es fcil de leer y entender. Su

redaccin debe ser simple y clara para aquellos que vayan a consultarlo
en el futuro.
Completo, un requerimiento esta completo si no es necesario ampliar

detalles en su redaccin, es decir si se proporciona la informacin
suficiente para su comprensin.
Consistente, un requerimiento es consistente si no es contradictorio con

otro requerimiento.
No ambiguo, un requerimiento no es ambiguo cuando tiene una sola

interpretacin. El lenguaje usado en su definicin, no debe causar
confusin en el lector.
10.5
Dificultades para definir los Requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes
Son difciles de expresar en palabras (el lenguaje es ambiguo)
La cantidad de requerimientos en un proyecto puede ser difcil 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 y olvidar lo rutinario
Hablan de lo que no funciona
Los usuarios tiene distinto vocabulario que los desarrolladores
Usan el mismo termino con distinto significado
10.6
Tcnicas para obtener Requerimiento
10.6.1 Entrevistas
Esta tcnica 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 solucin, naturaleza de sta, y lograr efectividad de
la reunin.
Ejemplos de preguntas centradas en el cliente, los objetivos globales y
beneficios
Quin solicita el trabajo?
89
Quin utilizar la solucin?

Cul ser el beneficio econmico de una buena solucin?
Existen otras alternativas a esta solucin?
Ejemplos de preguntas sobre el problema y la solucin
Qu entiende el cliente por una solucin correcta?

Qu problemas afrontar esta solucin?
En qu entorno se va a implantar la solucin?
Existen restricciones o aspectos de rendimiento importantes?
Ejemplo de preguntas sobre la efectividad de la reunin
Es usted la persona adecuada para responder a estas preguntas? Sus

respuestas son oficiales?
Son relevantes mis preguntas para su problema?
Hay alguien ms que pueda proporcionar informacin adicional?
Hay algo ms que debera preguntar?
Problemas de las entrevistas:
Pueden surgir malentendidos

Omisin de informacin
Mala relacin de trabajo (nosotros-ellos)
10.6.2 JAD
El Diseo en Conjunto de Aplicaciones (JAD, Joint Application Design) fue
desarrollado por IBM a finales de los setenta. Es una sesin de trabajo con
participacin de todos los involucrados. El resultado de la sesin es un
documento de especificacin que incluye definiciones de elementos de datos,
flujos de trabajo y pantallas de interfaz.
El resultado de una sesin JAD representa un acuerdo entre usuarios, clientes y
desarrolladores y minimiza los cambios posteriores de requerimientos.
Las actividades de la sesin JAD son: Definicin del proyecto, Investigacin,
preparacin, Sesin, preparacin del documento final.
Definicin del proyecto: el coordinador se entrevista con gerentes y clientes
para determinar objetivos y alcance del proyecto. Se elabora la gua de
definicin administrativa.
Investigacin: se entrevista a usuarios y se recopila informacin del dominio,
descripcin de flujos de trabajo y asuntos a tratar en la reunin. Se elabora la
agenda de sesin y la especificacin preliminar.
Preparacin: el coordinador elabora un documento de trabajo o primer
borrador del documento final.
Sesin: el coordinador gua al equipo para crear la especificacin del sistema
en una reunin que puede durar varios das. Se definen los flujos de trabajo,
elementos de datos, pantallas, informes, etc. Las decisiones se documentan en
unos formularios.
90
Preparacin de documento final: el coordinador prepara el documento

final usando los formularios y se distribuye a los asistentes para su revisin.
Se realiza una reunin para discutir revisiones y finalizar el documento.
91
Leccin 11
Conceptos asociados al Modelo de casos de uso
Se han establecido diversas tcnicas para la especificacin de requerimientos.
La tcnica de casos de uso (Jacobson, 1993) se ha constituido en el estndar
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.1Qu 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 est compuesto por actores, casos de uso,
descripcin de cada caso de uso y el diagrama de casos de uso.
11.2Actor
Un actor define un conjunto coherente de roles que los usuarios del sistema
pueden jugar cuando interactan con l. Una instancia de actor puede ser un
individuo o un sistema externo. La notacin UML para el actor se muestra en la
figura 11.1.
Por ejemplo, en el Sistema de Acadmico de la universidad, los actores pueden
ser: Secretario Acadmico, Alumno y Docente. Todos ellos interactan con el
sistema a travs de alguna de sus funcionalidades. Ntese que el nombre del
actor represente el rol que desempean 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.3Caso 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, 1993). La figura
11.2 muestra la notacin UML de caso de uso.
Por ejemplo, consideremos el siguiente escenario para realizar el Retiro de
Dinero de un Cajero Automtico:
Escenario Normal
1.
2.
3.
4.
5.
6.
7.
E cliente inserta su tarjeta en la ranura del cajero automtico

El cajero automtico solicita ingreso de clave secreta
El cliente ingresa su clave secreta
El cajero automtico muestra men de opciones
El cliente selecciona opcin Retiro
El cajero automtico muestra relacin de cuentas del cliente
El cliente elige cuenta
92
8. El cajero automtico solicita cantidad

9. El cliente ingresa cantidad a retirar
10.El cajero automtico dispensa el dinero y termina.
Esta secuencia de interacciones entre el cliente y el cajero automtico
termina, de forma normal, se dispensa el dinero del cliente.
Otras secuencias que no siguen este flujo normal, pueden ser:
Escenario: clave incorrecta
1.
2.
3.
4.
E cliente inserta su tarjeta en la ranura del cajero automtico

El cajero automtico solicita ingreso de clave secreta
El cliente ingresa su clave secreta
El cajero automtico muestra mensaje de error Clave incorrecta
Escenario: Saldo insuficiente

1. E cliente inserta su tarjeta en la ranura del cajero automtico
2. El cajero automtico solicita ingreso de clave secreta
3. El cliente ingresa su clave secreta
4. El cajero automtico muestra men de opciones
5. El cliente selecciona opcin Retiro
6. El cajero automtico muestra relacin de cuentas del cliente
7. El cliente elige cuenta
8. El cajero automtico solicita cantidad
9. El cliente ingresa cantidad a retirar
10.El cajero automtico muestra mensaje de error Saldo Insuficiente.
Podemos decir que este conjunto de escenarios corresponde al caso de uso
Retiro de Cajero Automtico.
En conclusin, un caso de uso proporciona uno o ms escenarios que indican
cmo debe interactuar el usuario con el sistema para conseguir un objetivo
particular.
Figura 11.2 Caso de uso
11.4Descripcin de caso de uso

Se han establecido diversas plantillas para describir un caso de uso. Larman
(2002) seala que la descripcin de un caso de uso, bsicamente, debe
contener: Nombre del caso de uso, Actor, Precondiciones, Poscondiciones, Flujo
bsico y Flujos alternativos.
El nombre del caso de uso debe ser claro e indicar la funcin 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, deben
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.
93
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 garanta de xito. Estas deben
redactarse en tiempo verbal pasado. Por ejemplo: Se ha registrado en el
sistema las notas de los alumnos.
El flujo bsico, es la descripcin narrativa de lo que debe ocurrir cuando los
actores interactan 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
desviacin del flujo bsico de eventos, se consideran, condiciones anormales,
extremas, ocasionales, condiciones de error o violaciones de reglas.
Ejemplo de flujo bsico:
1. El Caso de uso comienza cuando el profesor indica registrar notas.
2. El sistema muestra un formulario de validacin de ingreso al sistema.
3. El usuario ingresa su cdigo y su contrasea.
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 prctica, 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 informacin y muestra un mensaje de
confirmacin y el Caso de uso finaliza.
Ejemplos de flujos alternativos:
Cdigo o Contrasea errados:
En el paso 4, si cdigo o contrasea digitados por el usuario son erradas,
el sistema muestra mensaje de error y vuelve a solicitar cdigo y
contrasea.
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.5Diagrama 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 gestin acadmica. Se observa dos actores:
profesor y alumno, mediante la relacin de generalizacin 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 exmenes. Particularmente, el estudiante puede consultar notas de
un curso y mantener informacin del estudiante. El profesor puede mantener
informacin de profesor, registrar notas de un curso y cerrar un curso.
94
Figura 11.3 Diagrama de casos de uso
Consultar notas de un curso

Estudiante
Consultar horarios de cursos
(f rom Actors)
Mantener informacin del estudiante

Cerrar un curso
Validar acceso
Usuario
Mantener informacin del profesor
(f rom Actors)
Consultar horario de exm enes

Profesor
(f rom Actors)
95
Registrar notas de un curso
Leccin 12
Proceso de construccin del modelo de casos de casos de uso
En esta leccin se presentan los pasos a seguir para la construccin de un
modelo de casos de uso; para tal efecto, consideremos la siguiente descripcin
de requerimientos:
La Empresa AIRTRANS, dedicada al servicio de transportes areos, necesita un
sistema de informacin para gestionar y mantener los datos de unidades, vuelos,
pilotos, pasajeros y reservas.
Despus de haber dialogado con el Encargado de Vuelos se concluyo que es
responsable de Mantener la informacin de las distintas unidades: el nmero, el
tipo de avin, 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 tripulacin, origen, destino y capacidad de pasajeros.
El gerente nos inform que: Mantiene la informacin de los pilotos que trabajan
en la empresa, para el mismo guarda el nmero de piloto, el nombre, direccin,
habilitacin, fecha del ltimo control mdico. 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 informacin de los pasajeros
de los diferentes vuelos, para cada uno se le incorpora un nmero de
identificacin, el nombre, profesin, el telfono y la direccin. 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. Slo se admiten pasajeros que hayan realizado reservas previas.
12.1
Identificando actores
Para identificar actores, podemos preguntar Quin est interesado en cierto

requerimiento o se beneficia o se ve afectado por algn servicio del sistema?,
Dnde en la organizacin ser usado el sistema?, Quienes usan, eliminan o
suministran informacin en el sistema?, Quin usa una determinada funcin
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
vuelos
12.2
Gerente
Empleado de
ventas
Identificando casos de uso
Para identificar casos de uso se sugiere preguntar: Cules son las tareas que
realiza el actor?, Que objetivos concretos necesita alcanzar un actor?, Puede
el actor crear, almacenar, remover o leer informacin en el sistema?, El actor,
necesita estar informado acerca de las ocurrencias del sistema?. Las
96
respuestas a estas preguntas reflejan funcionalidades del sistema para cada

actor.
En nuestro caso, el actor Encargado de vuelo debe: Mantener informacin de
unidades, Registrar vuelo de carga y Registrar vuelo de pasajeros. El Gerente
debe: Mantener informacin de pilotos y Consultar vuelos por piloto. El
Empleado de Ventas: Mantener informacin de pasajeros, Registrar reserva de
vuelo, Registrar confirmacin de vuelo y Consultar pasajeros que tomaron
vuelo.
Mantener informacion de unidades
Mantener informacino de pilotos
Registrar reservas de vuelo
12.3
Registrar vuelo de carga
Registrar vuelo de pasajeros
Consultar vuelos por pilotos
Mantener informacion de pasajeros
Registrar confirmacin de vuelo
Consultar pasajeros que tommaron

vuelo
Elaborando la descripcin de casos de uso
Para cada caso de uso se elabora su descripcin. En nuestro caso,

desarrollaremos descripcin de algunos casos de uso.
Nombre
C.U.S.
Actor
Precondicin
Poscondicin
1.
2.
3.
4.
5.
6.
7.
8.
Consultar Vuelos por Piloto

Gerente
El usuario ha sido admitido en el sistema con el rol de
Gerente
El sistema muestra los vuelos realizados por piloto
Flujo Bsico
El caso de uso se inicia cuando el Gerente indica Vuelos Realizados.

El Sistema muestra relacin de pilotos.
El Gerente escoge el nombre de piloto de la relacin mostrada.
El Sistema muestra calendario para escoger el periodo (fecha inicio y
fecha de fin)
El Gerente escoge el periodo (fecha inicio y fecha de fin).
El Gerente indica Aceptar.
El Sistema muestra los vuelos realizados por el piloto en el periodo
escogido.
El caso de uso finaliza.
Flujos Alternativos
Imprimir
En el paso 7, si el gerente indica Imprimir, el sistema imprime la
97
solo
informacin consultada y el caso de uso finaliza.

No hay vuelos en periodo
En el paso 7, 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 seleccionar otro piloto.
Nombre
C.U.S.
Actor
Precondici
n
Poscondici
n
Mantener informacin de unidades

Encargado de vuelos
El usuario ha sido admitido en el sistema con el rol de
Encargado de vuelos
Se ha registrado informacin de unidades
Flujo Bsico
Ingresar
1. El caso de uso comienza cuando el Encargado de Vuelo indica
Mantener Informacin de unidad.
2. El Sistema muestra las opciones: Ingresar, Modificar y Eliminar.
3. El Encargado de Vuelo elige la opcin 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 nmero, el tipo
de avin, 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 informacin de la nueva unidad.
8. El caso de uso finaliza.
Flujos Alternativos
Modificar
1. El flujo se inicia cuando el Encargado de Vuelo elige la opcin
Modificar.
2. El Sistema muestra relacin 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 opcin
Eliminar.
2. El Sistema muestra relacin 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 eliminacin 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.
Cdigo Repetido
1. En el paso 7 de ingresar y 7 de modificar, si el nmero de unidad se
repite,
2. El sistema muestra un error y regresa a solicitar datos
98
12.4
Elaborando el diagrama de casos de uso
Se asocia cada actor con su caso de uso, obtenindose el siguiente diagrama

de casos de uso
Registrar vuelo de carga

Encargado de
vuelos
Mantener informacin de unidades
Registrar vuelo de pasajeros
Mantener informacin de pilotos
Gerente
Consultar vuelos por pilotos
Mantener informacion de pasajeros

Registrar reservas de vuelo
Empleado de
ventas
Consultar pasajeros que tommaron

vuelo
Registrar confirmacin de vuelo
99
Resumen
Conceptos asociados a los requerimientos
Un requerimiento es una condicin o capacidad a la que debe ajustarse el

sistema que se construye. Un requerimiento es simplemente una declaracin
abstracta de alto nivel de un servicio que debe proporcionar el sistema o una
restriccin 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,
desempeo, capacidad de soporte.
La entrevista es una tcnica para obtener requerimientos usada en las

primeras tomas de contactos con los usuarios-clientes.
El diseo conjunto de aplicaciones, Joint Application Design (JAD) es
una sesin con participacin de todos los involucrados, cuyo resultado
es un documento de especificacin.
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 interactan 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 garanta de xito.
Los flujos alternativos, refleja las diferentes situaciones que provocan
una desviacin del flujo bsico 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 construccin del modelo de casos de uso
Identificacin de actores
Identificacin de casos de uso
Elaboracin de descripcin de casos de uso
Elaboracin de diagrama de casos de uso
100
Lectura
Crear el diseo lgico de una interfaz de usuario (*)
Cuando los actores interactan con el sistema, utilizaran y manipularan
elementos de interfaces de usuario que representan atributos (de los casos de
uso). A menudo estos son trminos 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 seleccin,
arrastre o hablando con ellos. El diseador 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, desempeando un papel
diferente en cada uno. As, los elementos de la interfaz de usuarios pueden
disearse para jugar varios roles. Deberamos responder a las siguientes
preguntas por cada actor:
Qu elementos de interfaz de usuario se necesitan para posibilitar el

caso de uso?
Cmo deberan relacionarse unos con otros?
Cmo se utilizaran en los diferentes casos de uso?
Cul debera ser su apariencia?
Cmo deberan 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 gua o informacin va a necesitar el actor antes de invocar cada
accin de los casos de uso?
Qu informacin debe proporcionar el actor al sistema?
Qu informacin debe proporcionar el sistema al actor?
Cules son los valores medios de todos los parmetros de entrada o
salida? Por ejemplo, Cuntas facturas manejar habitualmente un actor
durante una sesin y cul es el saldo medio de la cuenta? Necesitamos
estimaciones aproximadas de estas cosas porque asi se optimizar la
interfaz grfica de usuario para ellas (incluso aunque tengamos que
permitir un rango suficientemente grande).
Una forma prctica 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 diseadores
de interfaces de usuario describen cmo 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.
Adems, las notas adhesivas tampoco parecen permanentes .es fcil moverlas
o simplemente eliminarlas-, lo que hace que el usuario se sienta cmodo
proponiendo cambios.
101
(*) Jacobson (2000, pp. 153-154).
102
Actividades
1. Desarrollar el modelo de casos de uso para el siguiente sistema para una
agencia de alquiler de autos
Inicialmente, entrevistamos al dueo 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 informacin del tipo: Dado un intervalo
de tiempo, todas las reparaciones realizadas por un monto superior al que l
imponga.
El Empleado de Atencin al Pblico, 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, direccin
personal, localidad, provincia, tipo y nmero de documento, profesin y nmero
de licencia de conductor. De acuerdo con las restricciones que impone el
cliente, se busca si existe un vehculo disponible. Una vez que el cliente
seleccion un coche, se crea una ficha para el nuevo alquiler: fecha del alquiler,
cantidad de das por los que se alquila, importe del alquiler y kilometraje del
vehculo al momento de ser alquilado. No se debe autorizar alquileres a clientes
que no devolvieron en el plazo o en buen estado el vehculo que se les prest.
El Encargado de Autos es el nico autorizado a actualizar la ficha registro de
cada auto. Cada vehculo tiene su propia informacin: cdigo, descripcin,
marca (por ej: Ford Fiesta), modelo (por ej: 1996), estado (alquilado, disponible
para alquilar o en reparacin). Por cada vehculo lleva nota de todas las
reparaciones que recibi. De cada reparacin mantiene la fecha, motivo, costo
de la reparacin, cantidad de das que el auto no estuvo disponible. Tambin
atiende a los clientes que traen los vehculos. Controla que el mismo se
entregue en buen estado y en termino, si no es as le informa al encargado de
atencin al pblico 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.
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 telefnicas. En este caso, el Empleado de
Atencin al Publico tomar los datos del cliente, la fecha del alquiler, das por
los que se va a alquilar y vehculo que reserva.
Una reserva puede ser cancelada con hasta 48 horas de anticipacin. Los
clientes que hagan reservas y no retiren el alquiler, no podrn efectuar nuevas
reservas ni alquileres.
Al final de cada jornada, el Encargado de Autos lanzara un proceso que
analizase las reservas para el prximo da y marque los autos que corresponda
103
Autoevaluacin
1. En la celda a la derecha del Termino coloque la letra de la Definicin o
Caracterstica que le corresponda:
Trmino
1. Requerimiento
2. Req. Funcional
3. Req. No
Funcional
4. Usabilidad
5. Entrevista
6. JAD
7. Actor
8. Caso de uso
9. Precondicin
10. Flujo bsico

A. Requerimiento que especifica propiedades del sistema
B. Tcnica adecuada en primera toma de contacto para obtener
requerimiento
C. Sesin de trabajo con participacin de todos los involucrados
D. Condicin o capacidad a la que debe ajustarse el sistema que
se construye
F. Conjunto coherente de roles que usuarios del sistema pueden
jugar
G. Conjunto de escenarios, secuencia de acciones entre actor y
sistema
H. Restriccin que debe cumplirse para que se inicie un caso de
uso
I. Requerimiento que especifica comportamiento de entrada /
salida del sistema
J. Se considera los pasos normales, no incluye alternativas o
variaciones
K. Requerimiento que representa facilidad de uso del producto
1. 1 = D, 2 = I , 3 = A , 4 = K, 5 = B, 6 = C, 7 = F, 8 = G , 9 = H , 10 = J
Exploracin on-line
Sitio de Alistair Cockburn, sobre recursos e informacin 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.121990_desc.html.
Jacobson,I., et al, (1993). Object-Oriented Software Engineering: A Use case
Driven Approach. USA. Addison Wesley.
orientado a objetos. Segunda Edicin. Madrid. Pearson Educacin S.A.
Sommerville, Ian (2005), Ingeniera de Software. Stima edicin. Mexico D.F.
Editorial Pearson.
104
GLOSARIO
Actividad Es una unidad de trabajo que debe ser ejecutada en un proceso

de desarrollo de software.
Artefacto Es una pieza de informacin 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.
Metodologa Es el conjunto de procedimientos, tcnicas, herramientas, y

un soporte documental que ayuda a los desarrolladores a realizar nuevo
software
Modelo de anlisis de negocios Describe la realizacin de los casos de

uso del negocio mediante la interaccin 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 representacin de la forma

en que la empresa interacta 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
Organizacin 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 divisin del
trabajo y comunicacin que interactan para producir bienes o servicios
Proceso de desarrollo Es una gua acerca de las actividades y tareas

necesarias para construir un sistema de informacin.
Proceso de negocio Conjunto de actividades que toman uno o ms

imputs crean un outputs de valor para el cliente.
RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso

qu, cundo y cmo.
Trabajador Es un rol que debe ser realizada por una persoa o equipo
dentro de un proceso de desarrollo de software..
Sistema de informacin Conjunto de componentes hardware, software,

base de datos, procedimientos y personas, que permiten capturar,
procesar, almacenar y distribuir informacin para una organizacin.

lenguaje, basado en una notacin grfica, 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.
105
BIBLIOGRAFIA
1
Davenport, Thomas (1996). Innovacin de Procesos: Reingeniera del

trabajo a travs de la tecnologa de la informacin. Espaa. Daz Santos.
Hammer, Michel y James Champy (1995), Reingeniera. Bogot. Grupo

Editorial Norma..
Harris, David (1996). Creating a Knowledge Centric Information Technology

Environment. USA. Editorial Harris Training & Consulting Services Inc.
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.121990_desc.html.



orientado a objetos. Mexico D.F. Prentice-Hall Hispanoamericana.

orientado a objetos. Segunda Edicin. Madrid. Pearson Educacin S.A.
Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Informacin

Gerencial. 8 Ed. Mxico D.F. Pearson Educacin.
10 Laudon, Jane y Kenneth (2006). Sistemas de informacin gerencial,

Administracin de la empresa digital. Mxico D.F. Pearson EducacinPrentice Hall.
11 Pressman , Roger S. (2002) Ingeniera de Software. Un enfoque prctico.
5ta.Ed. Mc Graw Hill, Espaa.
12 Rumbaugh, J. et. al. (1996). Modelado y diseo orientados a objetos.
Metodologa OMT. Mexico D.F. Prentice Hall Hispanoamericana.
13 Sommerville, Ian (2005), Ingeniera de Software. Stima edicin. Mexico
D.F. Editorial Pearson.
106

Libro de Analisis de Sistemas - UNMSM

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

Libro de Analisis de Sistemas - UNMSM

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA

CSAR LUZA MONTERO

La segunda unidad comprende los temas relacionados con el proceso de

Las personas representan el recurso ms importante de la organizacin,

1.1.2 Estructura organizacional

Estructura por procesos

Figura 1.3 Organizacin por procesos

Proceso de negocio (Flujo de actividades)

1.1.3 Niveles Organizacionales

En esta pirmide podramos agregar, debajo de su base, un bloque grande

1.2 Procesos de negocio

Muchos procesos de negocios trascienden las reas funcionales tradicionales;

Figura 1.5 Proceso de ejecucin de un pedido

1.2.2 Clases de procesos de negocio

Mediantes estos procesos el cliente interacta con la organizacin. En el

En estos procesos no hay agente externo, cliente, proveedor, etc., que

1.2.3 Cmo se describe un proceso de negocio?

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

Existen diversas tcnicas y herramientas para describir, de manera grfica, un

Figura 1.6 Descripcin Grafica del Proceso Registro de Pedido

2.1 Concepto de Dato, Informacin y Conocimiento

Fuente: (Adaptado de Harris, 1996)

2.2 Qu es Sistema de informacin?

Un sistema de informacin recibe y procesa los datos de manera eficaz, sin

2.3 Componentes de un Sistema de informacin

El hardware corresponde al elemento fsico del sistema de informacin incluye

2.4 Tipos de sistemas de informacin

Los sistemas de informacin de nivel operativo apoyan a los gerentes

Los Sistemas de Planificacin de Recursos Empresariales (Enterprise

Una organizacin es un sistema compuesto por un conjunto de personas,

Introduccin a los sistemas de informacin

Los datos son registros de hechos observables no procesados que no tienen

Un sistema de informacin es un conjunto de componentes interrelacionados

Los Componentes de un sistema de informacin son: Hardware, Software, Base

Tipos de sistema de informacin

De acuerdo a intereses: Sistemas de informacin de nivel operativo,

(*) Fuente: (Laudon, 2004,p.85)

Identifique una organizacin, de cualquier tipo o tamao, indique el giro del

7. Con respecto al concepto de Sistema de Informacin, entre los parntesis de la

Definicin de tipo de S.I.

Gestionan la informacin de transacciones en una empresa

g) Orientado a monitorizar estado de un rea o unidad de una

Portal del CIO,

OMG, Object Management Group / Business Process Management Initiative

Davenport, Thomas (1996). Innovacin de Procesos: Reingeniera del

Hammer, Michel y James Champy (1995), Reingeniera. Bogota. Grupo

Harris, David (1996), Creating a Knowledge Centric Information

Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Informacin

Laudon, Jane y Kenneth (2006). Sistemas de informacin gerencial,

3.1 Proceso de desarrollo, una visin genrica

Fuente: (Pressman, 2002)

3.1.2 Fase de Definicin

Requerimientos del software. El mbito establecido para el software

3.1.3 Fase de Desarrollo

3.1.4 Fase de Evolucin

3.2 Modelos de Proceso de desarrollo de software

3.2.1 Modelo Lineal Secuencial

En este modelo, los requerimientos deben estar claramente identificados

3.2.2 Modelo Construccin de Prototipos

Fuente: (Adaptado de Pressman, 2002)

En este modelo, cuando el cliente observa el prototipo operativo, cree que es

3.2.3 Modelo Desarrollo Rpido de Aplicaciones (DRA)