Você está na página 1de 91

Facultad de Ingeniera de Sistemas, Cmputo y

Telecomunicaciones
Sistema a Distancia

ANLISIS DE SISTEMAS
CSAR LUZA MONTERO

2010

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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.

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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


sistemas de informacin, estableciendo 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 orienta, 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 usuariosclientes.
La quinta unidad permite que el estudiante consolide 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.

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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 autoaprendizaje, que el estudiante planifique el tiempo y
esfuerzo requerido por cada unidad. Asimismo, mediante Internet, debe trabajar de manera
colaborativa, fomentando el trabajo en equipo y compartiendo 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.

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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?

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

Leccin 1
Organizacin y procesos de negocios
Los profesionales responsables de automatizar las actividades de una organizacin deben
comprender los procesos de negocio que sta realiza 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 en la estructura de sus actividades.
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

Bienes/Servicios

ACTIVIDADES

Personas/Recursos
Fuente: Elaboracin propia

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
sirve de soporte para realizar las actividades.
1

Las figuras siguientes que no consignen fuente, son de elaboracin propia

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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 de
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

Investigacin
y
Desarrollo

Produccin

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.

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

Figura 1.3 Organizacin por procesos


Gerencia
General

Proceso de negocio (Flujo de actividades)


Proceso de negocio (Flujo de actividades)
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, agrupa a empleados,
obreros, etc., que 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)

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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.
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 de Financieros, Expertos en Marketing,
Investigadores.
Nivel operativo
En el nivel operativo, se realizan actividades de seguimiento y control de las tareas
realizadas por el personal operacional, empleados, obreros, quienes realizan
transacciones elementales de la 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, la informacin detallada es necesaria; mientras que, en el nivel estratgico,
conviene proporcionar resmenes.

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

1.2 Procesos de negocio


1.2.1 Qu es un proceso de negocio?
Un proceso de negocio es un orden especifico de actividades a travs del tiempo y lugar,
con un comienzo y un fin, inputs y outputs: una estructura para la accin (Davenport,
1996).
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 (Hammer, 1993).
Mediante los procesos de negocio se organizan y coordinan las actividades en funcin al
cliente elaborando productos y servicios de valor.
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).
Figura 1.5 Proceso de ejecucin de un pedido
VENTAS

CONTABILIDAD

MANUFACTURA

Recibir
pedido

Verificar
Crdito

Producir
pedido

Iniciar
tramite

Facturar
pedido

Enviar
pedido

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.
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 dos procesos el cliente interacta con la organizacin. El proceso Vender
Producto permite al cliente recibir de la organizacin el producto requerido. El proceso
Gestionar Pedido permite al cliente solicitar el pedido de bienes /servicios requerido.

10

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

Los Procesos de Soporte son aquellos que proporcionan apoyo a los procesos principales
o sustantivos. Usualmente estn relacionados con la gestin de recursos.
Ejemplos:

DESARRROLLO DE
PERSONAL

INVESTIGACIN DE
MERCADO

En estos dos 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 dos 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.
5. El comercial comunica al cliente el resultado final del anlisis de su pedido.

11

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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


tcnica de Diagrama de Actividades de UML y modelado con la herramienta Rational Rose
de IBM.
Figura 1.6 Descripcin Grafica del Proceso Registro de Pedido

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.

12

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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

1200

Jos Quispe

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

Cantidad

Precio

01

Zapatos

1200

S/100

13

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

Se puede afirmar que los datos son la materia prima para producir informacin. Entonces,
en las organizaciones se procesan datos para obtener informacin.
En base a la informacin se adquiere conocimiento. Actualmente, se considera al
conocimiento como el recurso ms preciado, por ello se habla de gestin del
conocimiento en las organizaciones.
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 se puede considerar que "El nivel ms bajo de los
hechos conocidos son los datos. Los datos no tienen un significado intrnseco. Deben ser
ordenados, agrupados, analizados e interpretados. Cuando los datos son procesados de
esta manera, se convierten en informacin. La informacin tiene una esencia y un
propsito. Cuando la informacin es utilizada y puesta en el contexto o marco de
referencia de una persona, se transforma en conocimiento. El conocimiento es la
combinacin de informacin, contexto y experiencia. (Harris, 1996).
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

CONOCIMIENTO

INFORMACIN

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).

14

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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
Hardware

Personas

Software

Sistema de
Informacin

Dato/informacin

Procedimiento

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

15

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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.
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 datos 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.
Segn la funcin que desempean o el tipo de usuario final del mismo, se pueden
clasificar en (Laudon, 2006): Sistema de procesamiento de transacciones, Sistemas de
informacin gerencia, 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.
Sistema 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.
Sistema de informacin gerencial (Management Information System - MIS) son aquellos
orientados a solucionar problemas empresariales en general.
Sistema de soporte a decisiones (Decision Suport System - DSS) son aquellas que sirve de
herramienta para realizar el anlisis de las diferentes variables de negocio con la finalidad
de apoyar el proceso de toma de decisiones.
Sistema 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.

16

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

Sistema de automatizacin de oficinas (Office Automation System - OAS) son


aplicaciones destinadas a ayudar al trabajo diario del administrativo de una empresa u
organizacin.
Sistemas expertos (Expert System - SE) emulan el comportamiento de un experto en un
dominio concreto.
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.

17

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

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


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).

18

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

Lectura
BACKUS: INTEGRANDO PROVEEDORES A LA CADENA DE SUMINISTROS (*)
La necesidad de automatizar procesos y generar valor en las actividades de las diferentes reas de
una organizacin se ha convertido en una tendencia cada vez ms frecuente en las empresas, ello
gracias a los beneficios que ofrece el e-business.
Es as, que Unin de Cerveceras Peruanas Backus y Johnston dando un paso adelante con la
tecnologa, viene implementando mejoras en todos sus procesos para operar con estndares de
clase mundial que tiendan a la satisfaccin de sus clientes y la integracin de sus proveedores
como socios de negocios.
Rafael Trucos, Gerente de Planning y Marketing de ebiz Latin America, empresa especialista en
soluciones e-business y operador tecnolgico de Backus, convers con Csar Campodnico,
Gerente de Desarrollo de Proveedores con la finalidad de dar a conocer la forma de trabajo con
proveedores y los beneficios obtenidos al implementar ebiz en Backus.
Desde que empezamos el proyecto e-commerce de ebiz en el ao 2004, hemos implementado
nuevas soluciones integradas a nuestro sistema transaccional con la finalidad de agilizar nuestro
proceso de abastecimiento y dar un mejor servicio a nuestros clientes internos, automatizando no
solo nuestros procesos Logsticos, sino tambin Contables, coment Csar Campodnico.
En la actualidad, Backus ha implementado el mdulo de Peticiones de Oferta, Envo de
cotizaciones, Envo de rdenes de compra, Visualizacin de estado de comprobantes de pago,
Impresin de comprobantes de retencin y prximamente el mdulo de Registro de facturas para
proveedores, agreg.
Por otro lado, Campodnico coment cuales fueron las caractersticas principales del servicio
ofrecido por ebiz que permiti tomar una decisin al momento de hacer la integracin en SAP:

Customizacin a las exigencias segn modelo de negocio de Backus.


Flexibilidad en la adecuacin de las necesidades de Backus.
Tiempos de implementacin adecuados.
Servicio al cliente BACKUS y sus proveedores.
Consultas y Soporte a travs de Help Desk.
Apoyo al seguimiento en Call Center.
Costo vs Beneficio (Inversin vs Ahorro)
Sinergias del mercado Comunidad Empresarial electrnica
Confiabilidad, Confidencialidad y Seguridad (Hosting operaciones en IBM)

As mismo, dentro de los beneficios obtenidos por la relacin Proveedor / Cliente se coment la
reduccin de costos por negociacin consolidada, la funcionalidad personalizada a las prcticas
del negocio, el mejor control de la operacin logstica y el incremento de nivel de servicio al
cliente interno, todo ello orientado a cumplir los objetivos que persigue el modelo de gestin de
cadena de suministro.
Finalmente, resalt que el uso de herramientas b2b forma parte de los Lineamientos bsicos para
proveedores dando a conocer el compromiso de Backus en el establecimiento de una relacin
fuerte, perdurable y de lealtad con sus proveedores.
(*) Fuente: ebiz News
Fecha de `publicacion: 7/6/2009 11:00:00
Link: http://www.generaccion.com/noticias/online/detalle.php?id=24447

19

Sistema a Distancia

Anlisis de Sistemas - Unidad I

Csar Luza Montero

Actividades
1
2

Identifique una organizacin, de cualquier tipo o tamao, y realice la descripcin de uno de


sus procesos de negocio de tipo principal.
Busque y explique algunas tcnicas de modelado de procesos de negocio y elabore un
ejemplo de cada una.

Autoevaluacin
Contestar las siguientes preguntas:
1 Una organizacin es un sistema compuesto por
2 La estructura con enfoque de proceso se caracteriza por:
3 Los niveles de gestin de una organizacin son:
4 Un proceso de negocio es:
5 Los tipos de procesos de negocios son:
6 La diferencia entre dato e informacin es
7 La diferencia entre informacin y conocimiento es
8 Un sistema de informacin es:
9 Los componentes de un sistema de informacin son:
10 Los tipos de sistemas de informacin son:

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


Pagina 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.

Hammer, Michel y James Champy (1993), Reengineering the Corporation: A Manifesto for
Business Revolution. USA. Collins Business Essentials.

Harris, David (1996). Creating a Knowledge Centric Information Technology Environment. USA.
Editorial Harris Training & Consulting Services Inc.

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 Educacin- Prentice Hall.

20

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

SEGUNDA UNIDAD
EL PROCESO DE DESARROLLO, RUP Y UML
Qu es un proceso de desarrollo, cuales 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 cuales son sus elementos, relaciones y diagramas?
Qu es el RUP y cuales sus fases y flujos, artefactos, trabajadores, actividades?

21

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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
implica realizar una serie de actividades conducentes a obtener un sistema de calidad.
Esta serie de actividades se conoce como proceso de desarrollo que deviene en
metodologas de desarrollo.
Esta leccin ayuda 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 con 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.

22

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

Anlisis del sistema. Define el papel de cada elemento del sistema de informacin,
asignando finalmente al software el papel que va a desempear.
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.

23

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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.
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

Requerimientos
de software

Diseo

Codificacin

Prueba

Mantenimiento

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,

24

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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.
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.

25

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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, 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)

26

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

En este modelo, cuando el proyecto es grande, se requiere un gran nmero de personas


para formar equipos paralelos suficientes.
Requiere de un alto compromiso por parte de clientes y desarrolladores en lo que al
tiempo se refiere. Si esto falla, el proyecto fracasa.
No todos los tipos de aplicaciones son aptos para aplicar este modelo. Por ejemplo, no
son aptos aquellos sistemas que no se pueden modularizar, tampoco funciona bien para
aquellos donde existe un bajo reuso de componentes, ya que nuevos deben ser
desarrollados y probados.
No es apropiado cuando existen riesgos 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

27

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

imposible de cambiar, ya que en todos los casos, el cliente se queda con una versin
operativa del producto.
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).

28

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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.

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.

29

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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 software. Incluye: Modelamiento del Negocio, Modelamiento de
Requerimientos, Modelamiento de Tecnologa, Construccin, Pruebas e Implantacin del
Sistema de Informacin

30

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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


Colaboracin
Interfaz

31

Caso de uso

Nodo
Componente

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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
Interaccin
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.

32

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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)

33

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

El Diagrama de Clases, muestra un conjunto de clases, interfaces, colaboraciones y sus


relaciones.
El Diagrama de objetos, muestra una instantnea de un conjunto de objetos y sus
relaciones.
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.

34

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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.

35

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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.
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.

36

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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 delos 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.

Fuente: (Jacobson, 2000)

37

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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

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
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.

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.

38

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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 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

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.

39

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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.
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.

40

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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)

41

Sistema a Distancia

Anlisis de Sistemas - Unidad II

Csar Luza Montero

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
Responda las siguientes preguntas:
1. Un proceso de desarrollo es
2. Las fase de un proceso de desarrollo son:
3. Indique las caractersticas de los siguientes modelos de ciclo de vida:
a. Secuencial
b. Construccin de prototipos
c. Desarrollo rpido de aplicaciones
d. Incremental
e. Espiral
4. Una definicin de metodologa es
5. Un producto, tcnica, herramientas son
6. El UML es
7. El RUP es

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

Referencias bibliogrficas
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.

42

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

TERCERA UNIDAD
EL MODELADO DE NEGOCIOS

Qu es el modelado de negocios, cuales son sus perspectivas?


Qu es un actor del negocio, un caso de uso del negocio, una meta del negocio y un
diagrama de caso de uso del negocio?
Qu es un trabajador de negocio, una entidad de negocio y una realizacin de caso
de uso del negocio?
Cmo se elabora el modelo del negocio?

43

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

Leccin 6
Conceptos asociados al modelado del Negocio
6.1 Qu 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.2 Modelo 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

44

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

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).

45

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

Figura 6.5 Trabajador de negocio

Un trabajador del negocio (business worker) es alguien que realiza actividades dentro de
un caso de uso del negocio, 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 Entidad de negocio

La realizacin de un caso de uso del negocio puede incluir o se puede representar con:
Diagrama de actividades o Diagrama de Clases.
Diagrama de actividades
El Diagrama de actividades permite explorar el orden en que se realizan las actividades en
un caso de uso de negocio. Una actividad es una tarea manual o automatizada que
completa una unidad de trabajo.
Los elementos 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 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

46

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

pueden realizar Notificar aceptacin y Ordenar fabricacin, luego planificar produccin.


Para que el flujo finalice correctamente, tiene que terminarse las actividades Notificar
aceptacin y Planificar produccin.
Figura 6.8 Diagrama de actividades simple
Rellenar
Pedido

Inicio

Tramitar
Pedido

Analizar
Viabilidad

[No]

Notificar
rechazo

Viable
[Si]

Fin NoOK

Notificar
Aceptacion

Ordenar
fabricacion

Planificar
Produccion

Fin OK

En la figura 6.9 se mue4stra un diagrama de actividades detallado, que incluye elementos


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

: 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]

47

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

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

Partes de trabajo

Obtiene precios de materiales

revisa partes pendientes

Inventario de articulos

(f rom Entidades del negccio)

(f rom Entidades del negccio)

Obtiene precio de m ano de obra


indica numero de identificacion

Facturador
(f rom Trabajadores del negocio)

Registra pendiente
Asigna numero factura

Calcula importe total


Fichero de mecanicos
recibe copia

(f rom Entidades del negccio)

Cliente
(f rom Business Use-Case Model)

Realiz a
Factura

registrar facturas pagadas

(f rom Entidades del negccio)

Recib e
Em pleado del m ostradoir

pago con tarjeta

(f rom Trabajadores del negocio)

(f rom Entidades del negccio)

pago
(f rom Entidades del negccio)

Pago en efectivo
(f rom Entidades del negccio)

48

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

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 actual.

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: Fabricar producto
pedido y Controlar almacn. No se identifican casos de uso del negocio de gestin.

49

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

Registrar pedido

Fabricar producto

Controlar almacen Comprar materia prima

7.1.3 Identificando Metas del Negocio


Por cada caso de uso se identifican las metas del negocio. Este paso es opcional.

Reducir tiem po en 20%

Mantener stock adecuado

Reducir tasa errores a 0.5% Reducir 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.
Creado por : Cesar Luza
Fecha: Enero 25, 2010

Registrar pedido

Cliente

Reducir tiempo en 20%

(from Casos de uso del negocio)

(f rom Metas del negocio)

(f rom Actores del negocio)

Fabricar producto

Reducir tasa errores a 0.5%

(from Casos de uso del negocio)

(f rom Metas del negocio)

Proveedor

Controlar almacen

Mantener stock adecuado

(from Casos de uso del negocio)

(f rom Metas del negocio)

Comprar materia prima

Reducir generacin orden compra en 20%

(from Casos de uso del negocio)

(f rom Metas del negocio)

(f rom Actores del negocio)

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:

50

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

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 del anlisis de su
pedido.

7.2.1 Identificando trabajadores del negocio


Se identifican los trabajadores del negocio, en nuestro ejemplo solo consideramos el caso
de uso de negocio Registrar Pedido:

Empleado de Ventas

Jefe Tecnico

Jefe Produccion

7.2.2 Identificando entidades del negocio


Se identifican las entidades del negocio, en nuestro ejemplo solo del caso de uso de
negocio Registrar Pedido:

Pedido

Catalogo

Plantilla de fabricacion

Producto especial

Orden de Trabajo

7.2.3 Construyendo las realizaciones de caso de uso del negocio


Realizacin con diagrama de actividades del Caso de Registrar Pedido

51

Sistema a Distancia

Anlisis de Sistemas - Unidad III

: Cliente

Csar Luza Montero

: 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]

52

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

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

53

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

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


1.1. Las reglas son restricciones explicitas de comportamiento y/o proporcionan soporte para la
direccin de las actividades de negocio.
1.2. Las reglas no son procesos ni procedimientos. Y por tanto no deben estar contenidas en ninguno
de ellos.
1.3. Las reglas se aplican a lo largo de los procesos y procedimientos. Debe existir un corpus coherente
de reglas que se aplique sistemticamente en todas las reas de actividad del negocio.

Artculo 3. Proporcionar conocimiento meditado, no un sub-producto


1.1. Las reglas se construyen sobre hechos, y los hechos sobre conceptos tal y como son expresados
mediante trminos.
1.2. Los trminos expresan conceptos de negocio; los hechos realizan afirmaciones sobre estos
conceptos; las reglas restringen y apoyan estos hechos.
1.3. Las reglas deben ser explicitas. No se debe asumir ninguna regla sobre ningn concepto o hecho.
1.4. Las reglas son los fundamentos que definen lo que el negocio sabe de si mismo- es decir son
conocimiento bsico de negocio.
1.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
1.1 Las reglas de negocio se deben expresar demanera que pueda ser validada su exactitud por el
personal conocedor del negocio.
1.2 Las reglas de negocio se deben expresar de manera que se pueda verificar recprocamente su
coherencia.
1.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.
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.

54

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

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.1 Las 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.2 Las reglas suponen siempre un coste a la empresa.
8.3 Este 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.4 Ms reglas no es mejor, la abundancia de reglas no beneficia a su aplicacin.
Normalmente es mejor un nmero limitado de reglas bien reflexionadas.
8.5 Un 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


1.1 Las reglas de negocio son un patrimonio vital del negocio.
1.2 A largo plazo, las reglas son ms importantes para el negocio que las plataformas
Hardware/Software.
1.3 Las reglas de negocio deben organizarse y salvaguardarse de forma que puedan ser redesplegadas
a nuevas plataformas de Hardware/Software.
1.4 Las reglas, y la habilidad para cambiarlas de forma eficaz, son factores clave para mejorar la
adaptabilidad de las empresas.

(*) The Business Rules Group


Copyright, 2003. Business Rules Group. Version 2.0, November 1, 2003. Edited by Ronald G. Ross.
www.BusinessRulesGroup.org
La reproduccin y la distribucin de este documento se concede bajo las siguientes condiciones: (a) Se debe
incluir mencin clara y visible del copyright y del permiso. (b) Se debe mencionar al Business Rules Group como
la fuente del documento. (c) Se debe respetar la integridad del documento reproducido, incluido el ttulo, el
contenido, el copyright, el permiso, sin ninguna modificacin, abreviacin, resumen, ni extensin.
Traduccin a espaol versin 1.0, noviembre 2005, iniciada y coordinada por Antonio Catala.
(antonio.catala@theanonymousarchitect.com)

55

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

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 recibido 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 enviadas los
productos que se encuentran listas. 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 empaquetadas, y el
taln de embarque se anexa a la caja de embarque. En base a la informacin contenida en
el taln de embarque se procede a entregar la mercadera a domicilio asignando la
movilidad correspondiente o llamar al cliente para indicarle que su mercadera esta lista y
se apersone a recogerla.

56

Sistema a Distancia

Anlisis de Sistemas - Unidad III

Csar Luza Montero

Autoevaluacin
1
2
3
4
5
6
7

El modelado del negocio es


Los elementos del modelo de caso de uso del negocio son
Un actor de negocio es
Un caso de uso de negocio es
Los elementos del modelo de anlisis del negocio son
Un trabajador de negocio es
Una entidad de negocio es

Exploracin on-line

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
Referencias bibliogrficas
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.

57

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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?

58

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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 clases. Un atributo es una propiedad de una clase que
describe un rango de valores que la propiedad podr contener en los objetos de la clase
(Rumbaugh, 1996)..
Podemos decir que una clase representa un conjunto de objetos con las mismos atributos
y un objeto es una instancia de una clase, es decir es una entidad que tiene valores
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.

59

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

8.4 Asociacin y Enlace


Las entidades o cosas del mundo real se relacionan con otras entidades; a las relaciones
entre objetos se les llama enlaces y a las relaciones entre clases se les llama asociaciones
(Rumbaugh, 1996).
Mediante la 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. Cesar Luza dicta Anlisis de sistemas es un enlace entre los objetos
Cesar Luza y Anlisis de sistemas.
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
SECRETARIA

TECNICO

EMPLEADO

INGENIERO

Una Clase ES UN TIPO DE otra

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

COMPUTADOR
A

MONITOR
TECLADO

Una Clase ES PARTE DE otra clase

60

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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.1 se
observa un ejemplo de diagrama de clase simplificado para una Tienda de ventas. Se
muestra clases conceptuales y relaciones entre ellas; cada clase tiene un nombre y una
serie de atributos. Las relaciones se conocen como asociaciones, cada una de ellas tiene
un nombre y su multiplicidad.
La 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 esta 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

Al ma cenado-en
1
Tienda

1
atributos

Venta
fecha
hora

direccin
tienda
1

1
Capturada-en

Pagada-median te

Alb erga
1

1.. *
Registro

1
Pago
cantidad

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;
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 del diagrama de clases de la figura 8.4.

61

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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.
Figura 8.4 Clase
Venta
fecha
hora

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.
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, la clase Venta necesita
los atributos fecha y hora.
Segn la notacin UML, los atributos se muestran en el segundo compartimento del
rectngulo de la clase.
Figura 8.5 Atributos
Venta
fecha
hora

Asociacin
La asociacin se representa con una lnea que une las clases relacionadas. 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.
Figura 8.6 Asociacin

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 es 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 alumno est vinculado con

62

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

un solo objeto de Facultad, y un objeto de Facultad esta vinculado con varios objetos de
ALUMNO.
La multiplicidad permite representar, en el diagrama de clases, las reglas del negocio
definidas en el dominio del problema. Las 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

Clase-Asociacin
En algunas ocasiones es necesario representar propiedades propias de la asociacin; para
tal efecto, se crea una clase especial llamada Clase-Asociacin. Por ejemplo,
consideremos la asociacin ALUMNO matriculado en ASIGNATURA, la multiplicidad de
esta asociacin es de muchos a muchos, en efecto, un alumno puede llevar varias
asignaturas y una asignatura es llevada por varios alumnos. Entonces, la nota promedio
de un alumno en una asignatura corresponde a la 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.
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

Generalizacin

63

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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

64

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

Leccin 9
Proceso de construccin del modelo de dominio
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.
Para construir el modelo de dominio se puede seguir las siguientes actividades: Identificar
las Clases conceptuales o del dominio, Identificar las asociaciones, Identificar atributos,
Identifica 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, esto es, no se
permite vender productos sin elaborar.
9.1 Identificando Clases

Se seleccionan 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

65

proveedor

agenteComercial

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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 Identificar Atributos

Por cada clase se indican los atributos necesarios que respondan a los requerimientos del
dominio del problema. Si los atributos corresponden a una 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

se forma

1..n

definicin
cantidad

1..n

parte
numParte
descripcin
1..n

participa
0..n

se vende
agenteComercial
cuit
razSocial
email
telf
direcc

venta
fecha

1..n

Se compra

compra
fecha
cantidad

1..n

cliente
porcDesc

proveedor
plazoPago

66

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

9.4 Identificar 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

se forma

1..n

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 Refinar el modelo

Se valida que el diagrama responda a los requerimientos. Se itera y refina el modelo hasta
que est completo; es decir, hasta que cumpla todos los requerimientos sealados en la
descripcin del problema.

67

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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 Clase-Asociacin

Proceso de construccin de modelo de dominio

Identificar clases
Identificar asociaciones
Identificar atributos
Identificar relaciones de generalizacin
Refinar el modelo

68

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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 com prender 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)

69

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

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.
Tambin se desea controlar si el alumno va asistir como oyente no se presenta a
examen ni realiza prcticos- a cada curso en donde se inscribi. Esta informacin es
til para que el docente organize el dictado.

70

Sistema a Distancia

Anlisis de Sistemas - Unidad IV

Csar Luza Montero

Autoevaluacin
Conteste las siguientes preguntas
1. La diferencia entre clase y objeto es
2. Proporciones una ejemplo de clase con algunos de sus atributos , y tres ejemplos de objetos
de dicha clases
3. Una clase conceptual es
4. La diferencia entre enlace y asociacin es
5. La diferencia entre generalizacin y agregacin es
6. El modelo de domino es
7. Un diagrama de clases es
8. La multiplicidad de una asociacin representa
9. Una clase-asociacin es

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

Referencias bibliogrficas
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.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educacin S.A.

71

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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?

72

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

Leccin 10
Conceptos asociados los requerimientos
La importancia de la especificacin y anlisis de requerimientos en un proyecto de
desarrollo de software es evidente; pues, sirve de base para planificacin del proyecto y
para verificar si el producto software es de calidad, en otras palabras, si se han cubierto o
no las necesidades de los usuarios/clientes.
Muchos proyectos fracasan por una mala definicin, especificacin y administracin de
requerimientos; la experiencia ha demostrado que las actividades relacionadas con los
requerimientos es compleja, por la falta de participacin de los usuarios, lenguaje
distinto entre desarrolladores y usuarios, requerimientos cambiantes, entre otras
razones.
Por ello, es importante para el profesional involucrado en proyectos de desarrollo de
software poseer las suficientes competencias para la captura y administracin de los
requerimientos a fin de afrontar con xito esta tarea.
En esta leccin se define y caracteriza el concepto de requerimientos y se describen
tcnicas para la captura de los mismos.
1.1 Qu es un requerimiento?
Un requerimiento es una condicin o capacidad a la que debe ajustarse el sistema que
se construye. (Jacobson, 2000)
De acuerdo con la IEEE Std. 610.12-1990, un requisito es: (1) Una 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).
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).
1.2 Tipos de Requerimientos
Los requerimientos se pueden dividir en dos tipos: Requerimientos Funcionales y
Requerimientos No funcionales.
1.2.1 Requerimiento Funcional
Un Requerimiento funcional es un requerimiento que especifica una 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.
Por ejemplo, los usuarios de un Sistema de Gestin Acadmica para la Universidad
pueden ser profesores y alumnos, algunos requerimientos funcionales son:

73

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

El sistema permitir a los profesores: Consultar los horarios de sus cursos, Consultar la
programacin de los exmenes, Actualizar y ver su informacin personal, Registrar y
modificar las notas de los estudiantes a su cargo, Cerrar un curso
El sistema permitir a los estudiantes: Consultar los horarios de sus cursos, Consultar la
programacin de los exmenes, Actualizar y ver su informacin personal, Consultar notas
de un curso.
1.2.2 Requerimiento No funcional
Un Requerimiento No funcional es un requerimiento que especifica propiedades del
sistema, como restricciones del entorno o de 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:

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%.

1.3 Clasificacin de Requerimientos: Modelo FURPS


Una manera de categorizar los requerimientos est descrita en el modelo FURPS (Larman,
2002): Functionality (Funcionalidad), Usability (Capacidad de Uso), Reliability (Fiabilidad),
Performance (Desempeo) y Supportability (Capacidad de Soporte).
Functionality (Funcionalidad), son aquellos requerimientos que reflejan las caractersticas
fundamentales (requerimiento funcional o funcionalidades del sistema), adems de
capacidades y seguridad.
Usability (Capacidad de Uso), son aquellos requerimientos que representan facilidad o
nivel de uso del producto; es decir, el grado en el que el 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.
Reliability (Fiabilidad), son aquellos que muestran la capacidad de un sistema o
componente para ejecutar sus funciones requeridas bajo condiciones normales en un
periodo de tiempo especifico. Tiene siguientes sub-categoras: Disponibilidad, especifica
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: se especifica la precisin y
exactitud (segn algn estndar conocido) que se requiere para las salidas del sistema;
Cantidad mxima de errores o porcentaje de defecto, 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

74

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

crticos (se debe definir que significa error crtico, por ejemplo prdida completa de
dato o imposibilidad de uso de ciertas funcionalidades del sistema.
Performance (Desempeo), se refieren a las caractersticas de rendimiento del sistem.
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.
Supportability (Capacidad de Soporte), 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 de una asignatura,
un ciclo, o de un aula o laboratorio concretos.

ALGUNOS REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA


FACULTAD DE INGENIERIA DE SISTEMAS, 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.

1.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, como se sabe si se cumpli con l o no?

75

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

Conciso, un requerimiento es conciso si es fcil de leer y entender. Su redaccin


debe ser simple y clara para aquello que vayan a consultarlo en el futuro.
Completo, un requerimiento esta completo si no es necesario ampliar detalles en
su 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.
1.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 uy olvidar lo rutinario
Hablan de lo que no funciona
Los usuarios tiene distinto vocabulario que los desarrolladores
Usan el mismo termino con distinto significado
1.6 Tcnicas para obtener Requerimiento
1.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?


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?

76

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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)
1.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,... Las decisiones se documentan en unos formularios.
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.

77

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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, 93) 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.1 Qu es el modelo de casos de uso?
El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del
sistema en forma de Casos de uso. Su objetivo es comunicar la funcionalidad y el
comportamiento al cliente y usuario.
El modelo de casos de uso esta compuesto por actores, casos de uso, descripcin de cada
caso de uso y el diagrama de casos de uso.
11.2 Actor
Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando 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.3 Caso de Uso


Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una
secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a
un actor particular (Jacobson, 93). La figura 11.2 muestra la 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.

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

78

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

6. El cajero automtico muestra relacin de cuentas del cliente


7. El cliente eligen cuenta
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 eligen 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 indica como debe
interactuar el usuario con el sistema o con otro sistema para conseguir un objetivo
particular.
Figura 11.2 Caso de uso

11.4 Descripcin 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

79

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor. Establecen lo que siempre debe cumplirse antes de comenzar un escenario en un
caso de uso. Normalmente implica que un escenario de otro caso de uso se ha
completado exitosamente. Estas deben redactarse en tiempo verbal pasado. Por ejemplo:
El usuario ha sido aceptado en el sistema con el rol de profesor.
Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con xito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la 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.5 Diagrama de casos de uso
Un diagrama de caso de uso muestra los actores los casos de uso y las relaciones entre
ellos. La figura 11.3 muestra un ejemplo de diagrama de casos de uso, para un sistema de
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

80

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

mantener informacin del estudiante. El profesor puede mantener informacin de


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

Consultar notas de un curso


Estudiante
Consultar horarios de cursos

(f rom Actors)

Mantener informacin del estudiante


Cerrar un curso

Validar acceso
Usuario

Mantener informacin del profesor

(f rom Actors )

Consultar horario de exmenes


Profesor

Registrar notas de un curso

(f rom Actors)

Relaciones entre casos de uso


Entre dos casos de uso puede haber las siguientes relaciones: Extend e includes. Una
relacin extend se cuando un caso de uso especializa a otro extendiendo su
funcionalidad. Una relacin include se usa cuando un caso de uso incluye a otro. Se
representan como una lnea que une a los dos casos de uso relacionados, con una flecha
en forma de tringulo y con una etiqueta <<extiende>> o <<include>> segn sea el tipo de
relacin.

81

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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. Necesita un reporte con los pasajeros que
tomaron un vuelo.

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

82

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

acerca de las ocurrencias del sistema? Las respuestas a estas preguntas reflejan
funcionalidades del sistema para cada actor.
En nuestro caso, el actor Encargado de vuelo debe: Mantener 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

Por cada caso de uso se elabora su descripcin. En nuestro caso, solo desarrollaremos
descripcin de algunos casos de uso.
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
1. El caso de uso se inicia cuando el Gerente indica Vuelos Realizados.
2. El sistema muestra, en una ventana, relacin de pilotos, en otra ventana el calendario
para escoger el periodo (fecha inicio y fecha de fin) y un botn Aceptar.
3. El Gerente escoge el nombre de piloto de la relacin mostrada.
4. El Gerente escoge el periodo (fecha inicio y fecha de fin).
5. El Gerente indica Aceptar.
6. El sistema muestra los datos del piloto, los vuelos realizados por piloto en el periodo
escogido.
7. El sistema habilita botones Regresar y Imprimir
8. El Gerente indica Regresar
9. El caso de uso finaliza.
Flujos Alternativos
Imprimir
En el paso 7, si el gerente indica Imprimir, el sistema imprime la informacin consultada.
No hay vuelos en periodo
En el paso 6, si no existen vuelos del piloto en el periodo seleccionado, el sistema muestra
mensaje Piloto no tiene registrado vuelos en el periodo y regresa a solicitar informacin.
Nombre C.U.S.
Actor
Precondicin
Poscondicin

83

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Nombre C.U.S.
Actor
Precondicin
Poscondicin

Csar Luza Montero

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.
8. El caso de uso finaliza.
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.
7. El caso de uso finaliza.
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

84

Sistema a Distancia

Anlisis de Sistemas - Unidad V

12.4

Csar Luza Montero

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

Gerente

Consultar vuelos por pilotos

Mantener informacin de pilotos

Mantener informacion de pasajeros


Registrar reservas de vuelo

Empleado de
ventas

Consultar pasajeros que tommaron


vuelo

Registrar confirmacin de vuelo

85

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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

86

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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.

(*) Jacobson (2000).

87

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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. Le gustara poder consultar los
autos mas alquilados.
2. Continuar el desarrollo con lo que se indica:
Para la segunda etapa de este proyecto se van a incorporar, al sistema, facilidades para
hacer reservas 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 como reservados.

88

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

Autoevaluacin
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Un requerimiento es:
Las diferencias entre un requerimiento funcional y no funciona son:
Los requerimientos se caracterizan por:
Cuando usara las tcnicas de entrevista y JAD
El modelo de casos de uso representa
El actor es
El caso de uso es
Un escenario de caso de uso es
Una precondicin es
Una poscondicin es
La diferencia entre flujo bsico y flujo normal es

Exploracin on-line
Sitio de Alistair Cockburn, sobre recursos e informacin de casos de uso
http://alistair.cockburn.us/
Referencias bibliogrficas
IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educacin S.A.
Jacobson,I., et al, (1993). Object-Oriented Software Engineering: A Use case Driven Approach.
USA. Addison Wesley.
Larman, C. (2002). UML y patrones: introduccin al anlisis y diseo orientado a objetos.
Segunda Edicin. Madrid. Pearson Educacin S.A.
Sommerville, Ian (2005), Ingeniera de Software. Stima edicin. Mexico D.F. Editorial Pearson.

89

Sistema a Distancia

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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 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.

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.

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.

90

Sistema a Distancia

Una
Institucin
Educativa ha
decidido
brindar

Anlisis de Sistemas - Unidad V

Csar Luza Montero

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 (1993), Reengineering the Corporation: A Manifesto for
Business Revolution. USA. Collins Business Essentials.

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.12-1990_desc.html.

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.

Larman, C. (1999). UML y patrones: introduccin al anlisis y diseo orientado a objetos.


Mexico D.F. Prentice-Hall Hispanoamericana.

Larman, C. (2002). UML y patrones: introduccin al anlisis y diseo 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 Educacin- Prentice 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.

91

Sistema a Distancia