Vous êtes sur la page 1sur 97

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

ANLISIS DE SISTEMAS

CSAR LUZA MONTERO

LIMA-PER, 2012

NDICE
PRESENTACIN ........................................................................................................................................................ 6 INTRODUCCIN ....................................................................................................................................................... 7 ORIENTACIONES METODOLGICAS ........................................................................................................................ 9 PRIMERA UNIDAD.................................................................................................................................................. 10 LOS SISTEMAS DE INFORMACIN EN LAS ORGANIZACIONES ............................................................................... 10 Leccin 1 ........................................................................................................................................................... 11 Organizacin y procesos de negocios ............................................................................................................... 11 1.1 Organizacin .................................................................................................................................... 11 1.1.1 Qu es una organizacin? ......................................................................................................... 11 1.1.2 Estructura organizacional ............................................................................................................ 12 1.1.3 Niveles Organizacionales ............................................................................................................. 13 1.2 Procesos de negocio ........................................................................................................................ 14 1.2.1 Qu es un proceso de negocio? ................................................................................................ 14 1.2.2 Clases de procesos de negocio .................................................................................................... 15 1.2.3 Cmo se describe un proceso de negocio? ............................................................................... 16 Leccin 2 ........................................................................................................................................................... 18 Introduccin a los Sistemas de informacin ..................................................................................................... 18 2.1 Concepto de Dato, Informacin y Conocimiento ............................................................................ 18 2.2 Qu es Sistema de informacin? ................................................................................................... 19 2.3 Componentes de un Sistema de informacin ................................................................................. 20 2.4 Tipos de sistemas de informacin ................................................................................................... 20 Resumen ........................................................................................................................................................... 22 Lectura .............................................................................................................................................................. 23 Actividades ....................................................................................................................................................... 24 Autoevaluacin ................................................................................................................................................. 24 Exploracin on-line ........................................................................................................................................... 25 Referencias bibliogrficas ................................................................................................................................. 25 SEGUNDA UNIDAD ................................................................................................................................................ 26 EL PROCESO DE DESARROLLO, RUP Y UML ........................................................................................................... 26 Leccin 3 ........................................................................................................................................................... 27 Proceso de desarrollo de sistemas de informacin .......................................................................................... 27 3.1 Proceso de desarrollo, una visin genrica ..................................................................................... 27 3.1.1 Qu es un proceso de desarrollo? ............................................................................................. 27 3.1.2 Fase de Definicin ....................................................................................................................... 27 3.1.3 Fase de Desarrollo ....................................................................................................................... 28 3.1.4 Fase de Evolucin ........................................................................................................................ 28 3.2 Modelos de Proceso de desarrollo de software .............................................................................. 28 3.2.1 Modelo Lineal Secuencial ............................................................................................................ 29 3.2.2 Modelo Construccin de Prototipos ........................................................................................... 29 3.2.3 Modelo Desarrollo Rpido de Aplicaciones (DRA) ...................................................................... 30 3.2.4 Modelo Incremental .................................................................................................................... 31 3.2.5 Modelo Espiral ............................................................................................................................ 32 3.3 Metodologas ................................................................................................................................... 33 3.3.1 RUP .............................................................................................................................................. 33 3.3.2 MTRICA V3................................................................................................................................. 34 3.3.3 Merisse ........................................................................................................................................ 34 3.3.4 SSADM V4 .................................................................................................................................... 34 3.3.5 MDSI ............................................................................................................................................ 35 Leccin 4 ........................................................................................................................................................... 36 Introduccin al UML ......................................................................................................................................... 36 4.1 Qu es el UML? .............................................................................................................................. 36 4.2 Artefacto, Modelo y Diagrama ........................................................................................................ 36 4.3 Elementos en UML .......................................................................................................................... 36 4.4 Relaciones en UML .......................................................................................................................... 37 4.5 Diagramas en UML .......................................................................................................................... 38

Leccin 5 ........................................................................................................................................................... 40 Introduccin al RUP .......................................................................................................................................... 40 5.1 Qu es el RUP? ............................................................................................................................... 40 5.2 Elementos ........................................................................................................................................ 40 5.2.1 Trabajador (Worker) ................................................................................................................... 40 5.2.2 Actividad ...................................................................................................................................... 40 5.2.3 Artefacto ..................................................................................................................................... 40 5.2.4 Modelo ........................................................................................................................................ 40 5.2.5 Flujos de trabajo (Workflow) ...................................................................................................... 41 5.3 Fases ................................................................................................................................................ 41 5.3.1 Fase de Inicio ............................................................................................................................... 41 5.3.2 Fase de Elaboracin .................................................................................................................... 41 5.3.3 Fase de Construccin .................................................................................................................. 41 5.3.4 Fase de Transicin ....................................................................................................................... 42 5.4 Flujos................................................................................................................................................ 42 Resumen ........................................................................................................................................................... 43 Lectura .............................................................................................................................................................. 45 Actividades ....................................................................................................................................................... 47 Autoevaluacin ................................................................................................................................................. 47 Exploracin on-line ........................................................................................................................................... 48 Referencias bibliogrficas ................................................................................................................................. 48 TERCERA UNIDAD .................................................................................................................................................. 49 EL MODELADO DE NEGOCIOS ............................................................................................................................... 49 Leccin 6 ........................................................................................................................................................... 50 Conceptos asociados al modelado del Negocio ............................................................................................... 50 6.1 Qu es el Modelado del Negocio ................................................................................................... 50 6.2 Modelo de Casos de Uso del Negocio ............................................................................................. 50 6.2.1 Actor del Negocio ........................................................................................................................ 50 6.2.2 Casos de uso del negocio (CUN) .................................................................................................. 50 6.2.3 Metas del negocio ....................................................................................................................... 51 6.2.4 Diagrama de casos de uso del negocio ....................................................................................... 51 6.3 Modelo de Anlisis del Negocio ...................................................................................................... 51 6.3.1 Trabajador del negocio ............................................................................................................... 51 6.3.2 Entidad del negocio ..................................................................................................................... 52 6.3.3 Realizacin de caso de uso del negocio ...................................................................................... 52 Leccin 7 ........................................................................................................................................................... 55 Proceso de modelado del Negocio ................................................................................................................... 55 7.1 Elaborar el modelo de casos de uso del negocio ............................................................................. 55 7.1.1 Identificando Actores del Negocio .............................................................................................. 55 7.1.2 Identificando Casos de Uso del Negocio ..................................................................................... 55 7.1.3 Identificando Metas del Negocio ................................................................................................ 56 7.1.4 Elaborando el diagrama de casos de uso del negocio ................................................................. 56 7.2 Elaborar el modelo de anlisis del negocio ..................................................................................... 57 7.2.1 Identificando trabajadores del negocio ...................................................................................... 57 7.2.2 Identificando entidades del negocio ........................................................................................... 57 7.2.3 Construyendo las realizaciones de caso de uso del negocio ....................................................... 58 Resumen ........................................................................................................................................................... 59 Lectura .............................................................................................................................................................. 60 Actividades ....................................................................................................................................................... 62 Autoevaluacin ................................................................................................................................................. 63 Exploracin on-line ........................................................................................................................................... 63 Referencias bibliogrficas ................................................................................................................................. 63 CUARTA UNIDAD ................................................................................................................................................... 64 EL MODELADO DE DOMINIO ................................................................................................................................. 64 Leccin 8 ........................................................................................................................................................... 65 Conceptos asociados al modelo de dominio .................................................................................................... 65 8.1 Clase y Objeto .................................................................................................................................. 65

8.2 Atributo ........................................................................................................................................... 65 8.3 Operacin ........................................................................................................................................ 65 8.4 Asociacin y Enlace .......................................................................................................................... 65 8.5 Generalizacin y Agregacin ........................................................................................................... 66 8.6 Qu es el modelo de domino? ....................................................................................................... 66 8.7 Qu es el diagrama de clases? ....................................................................................................... 67 8.8 Notacin UML para modelo de domino .......................................................................................... 67 Leccin 9 ........................................................................................................................................................... 71 Proceso de construccin del modelo de dominio ............................................................................................ 71 9.1 Identificando Clases ......................................................................................................................... 71 9.2 Identificando Asociaciones .............................................................................................................. 72 9.3 Identificando Atributos .................................................................................................................... 72 9.4 Identificando relaciones de generalizacin ..................................................................................... 73 9.5 Refinando el modelo ....................................................................................................................... 73 Resumen ........................................................................................................................................................... 74 Lectura .............................................................................................................................................................. 75 Actividades ....................................................................................................................................................... 76 Autoevaluacin ................................................................................................................................................. 77 Exploracin on-line ........................................................................................................................................... 77 Referencias bibliogrficas ................................................................................................................................. 77 QUINTA UNIDAD.................................................................................................................................................... 78 EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO ....................................................................................... 78 Leccin 10 .............................................................................................................................................................. 79 Conceptos asociados los requerimientos .............................................................................................................. 79 10.1 Qu es un requerimiento? ................................................................................................................. 79 10.2 Tipos de Requerimientos ..................................................................................................................... 79 10.2.1 Requerimiento Funcional ............................................................................................................ 79 10.2.2 Requerimiento No funcional ....................................................................................................... 80 10.3 Clasificacin de Requerimientos: Modelo FURPS ................................................................................ 80 10.4 Caractersticas de los Requerimientos ................................................................................................. 81 10.5 Dificultades para definir los Requerimientos ....................................................................................... 82 10.6 Tcnicas para obtener Requerimiento ................................................................................................. 82 10.6.1 Entrevistas ................................................................................................................................... 82 10.6.2 JAD............................................................................................................................................... 83 Leccin 11 .............................................................................................................................................................. 84 Conceptos asociados al Modelo de casos de uso .................................................................................................. 84 11.1 Qu es el modelo de casos de uso? ................................................................................................... 84 11.2 Actor..................................................................................................................................................... 84 11.3 Caso de Uso.......................................................................................................................................... 84 11.4 Descripcin de caso de uso .................................................................................................................. 85 11.5 Diagrama de casos de uso .................................................................................................................... 86 Leccin 12 ......................................................................................................................................................... 88 Leccin 12 ......................................................................................................................................................... 88 Proceso de construccin del modelo de casos de casos de uso ....................................................................... 88 12.1 Identificando actores ....................................................................................................................... 88 12.2 Identificando casos de uso .............................................................................................................. 88 12.3 Elaborando la descripcin de casos de uso ..................................................................................... 89 12.4 Elaborando el diagrama de casos de uso ........................................................................................ 91 Resumen ........................................................................................................................................................... 92 Lectura .............................................................................................................................................................. 93 Actividades ....................................................................................................................................................... 94 Autoevaluacin ................................................................................................................................................. 95 Exploracin on-line ........................................................................................................................................... 95 Referencias bibliogrficas ................................................................................................................................. 95 GLOSARIO ......................................................................................................................................................... 96 BIBLIOGRAFIA ................................................................................................................................................... 97

PRESENTACIN

INTRODUCCIN
Las organizaciones estn considerando el tema de los Sistemas de Informacin como factor clave para lograr competitividad. Se estn realizando grandes inversiones para su construccin e implantacin, de manera eficiente, efectiva y con niveles de calidad pertinentes. Los sistemas de informacin, conjunto de componentes software, hardware, base de datos, procedimientos y personal, proveen la informacin, requerida por las organizaciones para apoyar las actividades de toma de decisin y controlar las operaciones del da a da. Esta informacin debe transmitirse a todos los niveles de la organizacin, de manera oportuna y confiable. El proceso de construccin e implantacin de sistemas de informacin implica esfuerzo conjunto de desarrolladores y clientes-usuarios, quienes realizan una serie de actividades, agrupadas en fases, conocida como Proceso de desarrollo, conducente a obtener un sistema de calidad que satisfaga las necesidades de informacin de los clientes-usuarios. En general, las primeras actividades del proceso de desarrollo estn relacionadas con el anlisis de sistemas y la especificacin de requerimientos del software. El propsito del anlisis de sistemas es definir el papel de cada componente del sistema de informacin y asignar al software el mbito que le corresponde desempear. Durante la actividad de especificacin de requerimientos del software, se detalla el mbito de funcionalidad del software, de tal manera que cubra la totalidad de necesidades de los usuarios. La literatura especializada establece que el xito de un proyecto de desarrollo de sistemas depende, en gran medida, de realizar bien el anlisis de sistemas y especificacin de requerimientos del software; por lo que es de gran relevancia, para la formacin de profesionales del campo de desarrollo de Sistemas de Informacin, el dominio de mtodos, tcnicas y herramientas que permitan afrontar con xito estas actividades. Precisamente, este libro tiene el propsito de promover y consolidar, en el estudiante, el uso de mtodos, tcnicas y herramientas para el anlisis de sistemas y especificacin de requerimientos de software. Se enfatiza en el componente software del sistema de informacin, se utiliza la notacin del lenguaje de modelado unificado (UML) y se sigue el proceso de desarrollo unificado (RUP). En otras palabras, para el anlisis de sistemas se desarrolla el flujo de modelado del negocio, y para la especificacin de requerimientos, se sigue el flujo de requerimientos que permitir capturar sistemticamente los requerimientos usando la tcnica de casos de uso del UML. Los contenidos de este libro se han organizado en cinco unidades temticas. stas se desarrollan en lecciones que incluyen apartados, esquemas y figuras, segn cul sea la necesidad didctica. Cada unidad consta tambin de un conjunto de actividades y de evaluacin orientados a afianzar el aprendizaje del estudiante y a valorar sus logros. La primera unidad tiene como propsito que el estudiante comprenda y explique la importancia de los sistemas de informacin en las organizaciones, definiendo con precisin los conceptos relacionados a la organizacin, proceso de negocio, datos, informacin, conocimiento y sistemas de informacin; valorando la importancia de estos conceptos en el contexto del anlisis de sistemas de informacin. La segunda unidad comprende los temas relacionados con el proceso de desarrollo de sistemas de informacin, sus fases y actividades genricas; muestra los diversos modelos de proceso de desarrollo y las metodologas ms conocidas, y brinda una introduccin al UML y al RUP. La tercera unidad ayuda, al estudiante, en el desarrollo de habilidades para la construccin de modelos de negocio. Los artefactos que se elaboran sirven de base para la determinacin de

requerimientos del sistema. Se utiliza notacin UML siguiendo las actividades proporcionadas por el RUP. La cuarta unidad tiene por finalidad que el estudiante desarrolle habilidades para representar modelos de dominio, mediante la construccin de diagrama de clases de UML. De esta manera, complementa los artefactos del modelo de negocios con una representacin de los conceptos o entidades que se manejan en el contexto del negocio o dominio de la aplicacin que cubra las necesidades y requerimientos de los usuarios-clientes. La quinta unidad permite que el estudiante desarrolle habilidades para la especificacin de requerimiento usando el modelo de casos de uso del UML. Se tratan, con precisin, los conceptos de requerimientos funcionales y no funcionales, y se elaboran, con claridad los artefactos del modelo de casos de uso: actores, casos de uso, descripcin de casos de uso y diagrama de casos de uso. En todo el libro, las figuras o tablas que no consignan fuente, corresponden a elaboracin propia. Las figuras o tablas que no consignan nmero, representa continuacin del texto donde estn ubicados. El autor.

ORIENTACIONES METODOLGICAS
La asignatura de Anlisis de Sistemas es de formacin profesional especializada, de naturaleza terica-practica. Tiene como propsito que el estudiante maneje, adecuadamente, los mtodos, tcnicas y herramientas para el anlisis y especificacin de requerimientos de software como componente de un sistema de informacin. Para este fin, se desarrollan las siguientes unidades temticas: Los Sistemas de Informacin en las Organizaciones, El Proceso de desarrollo con RUP y UML, El Modelado del Negocio, El Modelado de Dominio, y Requerimientos con casos de uso. Al inicio de cada unidad temtica, el estudiante dispone de una serie de preguntas que permitir valorar sus logros. Al finalizar la unidad, se brinda un resumen del contenido temtico, una lectura seleccionada de un tema de inters relacionado con el contenido temtico de la unidad, una serie de actividades que el estudiante debe realizar, una autoevaluacin que mide el aprendizaje del estudiante, una serie de direcciones Internet para exploracin online. Es fundamental, para el proceso de auto aprendizaje, que el estudiante planifique el tiempo y esfuerzo requerido por cada unidad. Asimismo, mediante Internet, debe trabajar de manera colaborativa, fomentando el trabajo en equipo y compartiendo informacin. El docente, dispondr de un horario que permita interactuar con los estudiantes para absolver consultas o dudas, a travs de Internet. En lo que respecta a la evaluacin del aprendizaje, al final de cada unidad temtica se dispone de una serie de preguntas de autoevaluacin que permite al estudiante medir sus logros de aprendizaje conceptual. Adems, se presenta una serie de casos que el estudiante desarrollar y que permitir al docente medir los logros de aprendizaje procedimental.

PRIMERA UNIDAD LOS SISTEMAS DE INFORMACIN EN LAS ORGANIZACIONES


Qu es una organizacin, como se estructuran sus actividades, cules son sus niveles? Qu son los procesos de negocios, como se clasifican? Cul es la diferencia entre dato, informacin y conocimiento? Qu es un sistema de informacin, cules son sus componentes, como se clasifican?

PROPOSITOS
Al finalizar esta unidad, el estudiante: Explica los conceptos y principios asociados a una organizacin y a la forma de estructurar sus actividades Comprende las caracterstica de los procesos de negocio y su clasificacin Explica la diferencia entre dato, informacin y conocimiento Explica la importancia de los sistemas de informacin en las organizaciones, sus elementos y su clasificacin

10

Leccin 1 Organizacin y procesos de negocios


Los profesionales responsables de automatizar las actividades de una organizacin deben comprender sus procesos de negocio a fin de identificar aquellas actividades manuales que sern reemplazas por sistemas software. En esta leccin se revisa aspectos bsicos de una organizacin y del enfoque basado en procesos de negocios.

1.1 Organizacin 1.1.1 Qu es una organizacin?


Segn el Diccionario de la Real Academia de la Lengua, una organizacin es una asociacin de personas reguladas por un conjunto de normas en funcin de determinados fines. Se puede considerar que una organizacin es un sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas de alguna forma (generalmente en departamentos o funciones) con arreglo a ciertas reglas de divisin del trabajo y comunicacin que interactan para producir bienes o servicios (Figura 1.1).

Figura 1.1 Componentes de una organizacin

Reglas

Entradas

ACTIVIDADES

Bienes/Servicios

Personas/Recursos
Fuente: Elaboracin propia1

Las personas representan el recurso ms importante de la organizacin, juegan distintos roles o responsabilidades cuando realizan las diversas actividades requeridas para cumplir los objetivos de la organizacin. Las actividades o tareas son las acciones que en conjunto transforman las entradas en bienes o servicios, se distinguen actividades operativas (realizadas por los obreros o empleados) y actividades de toma de decisin (realizadas por los gerentes). Los recursos pueden ser dinero, materiales, maquinaria, infraestructura, tecnologa que sirven de soporte para realizar las actividades. Las reglas estn dadas por las polticas, normas y procedimientos que rigen el desarrollo de las actividades y uso de los recursos.
1

En lo sucesivo, en este libro, si las figuras, imgenes o tablas no consignan fuente, son de elaboracin propia. .

11

1.1.2 Estructura organizacional


La estructura organizacional representa la forma en que las personas, actividades y recursos se organizan segn ciertas reglas. Se han establecido diversos modelos o enfoques para la estructura de una organizacin; sin embargo, para el propsito de este texto se pueden considerar dos enfoques: Estructura Funcional y Estructura por Procesos.

Estructura funcional
En la estructura con enfoque funcional, las actividades se organizan verticalmente, en reas funcionales, de forma altamente jerrquica, con mbitos de control muy limitados y rgidos (figura 1.2). Cada funcin busca optimizar sus propias tareas, inclusive a costa del rendimiento global de la organizacin. Su foco de anlisis es la tarea o funcin, su objetivo es la optimizacin de las tareas, se orienta al interior de la organizacin, tiene una visin fragmentada.

Figura 1.2 Estructura funcional

Gerencia General

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.

12

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, que agrupa a empleados, obreros, etc., quienes realizan actividades rutinarias, sin responsabilidad de toma de decisiones. Se suele utilizar un modelo de pirmide organizacional para representar los niveles organizacionales relacionados con la toma de decisiones. En la figura 1.4 se visualiza cuatro niveles: Estratgico, Administrativo, de Conocimiento y Operativo (Laudon, 2004).
Figura 1.4 Pirmide organizacional

Nivel Estratgico

Directores

Nivel Administrativo Nivel de Conocimiento

Gerentes de Nivel Medio

Trabajadores del Conocimiento

Nivel Operativo

Gerentes Operativos Fuente: (Adaptado de Laudon, 2004)

En esta pirmide podramos agregar, debajo de su base, un bloque grande para representar las actividades operacionales o rutinarias que tienen poca tarea de toma de decisiones.

13

Nivel estratgico
En el nivel estratgico, se realizan actividades relacionadas con toma de decisiones de asuntos estratgicos y tendencias a largo plazo, tanto en la empresa como el entorno externo; por ejemplo, se tratan asuntos como determinar los productos a elaborar dentro de cinco aos o determinar los niveles de empleo dentro de cinco aos. Se puede incluir a Directores, Gerente General, Gerentes de Divisin. Nivel administrativo En el nivel administrativo, se realizan actividades de supervisin, control y toma de decisiones de aspectos tcticos en el mediano plazo; por ejemplo, se tratan asuntos de exceso de presupuestos en un periodo o control del rendimiento. Se incluye a los gerentes de nivel medio, como gerente de reas: Gerente de Ventas, Gerente de Recursos Humanos, Gerente de una Agencia o Sucursal. Nivel de conocimiento En el nivel de conocimiento, se realizan actividades relacionadas con la investigacin y desarrollo para generar nuevas oportunidades de negocio o controlar el flujo de trabajo de oficina. Las personas que realizan este tipo de actividades son los trabajadores de conocimientos. Se incluye a Analistas Financieros, Expertos en Marketing, Investigadores. Nivel operativo En el nivel operativo, se realizan actividades de seguimiento y control de las tareas realizadas por el personal operacional, empleados, obreros, quienes realizan transacciones elementales de la organizacin como ventas, depsitos en efectivo, nminas. Se toman decisiones de corto plazo, por ejemplo, reabastecimiento de stock de inventarios, otorgar prstamos bancarios, entre otros. Se incluye a los gerentes operativos: Jefe de Seccin de fabricacin, Jefe de Cajeros. Este modelo de pirmide permite, a quienes desarrollan sistemas de informacin, visualizar el alcance de informacin requerido por cada nivel; as, en el nivel de gestin operativo, es necesaria la informacin detallada; mientras que, en el nivel estratgico, conviene proporcionar resmenes.

1.2 Procesos de negocio 1.2.1 Qu es un proceso de negocio?


La literatura relacionada con los proceso y la reingeniera de procesos sealan que, en una empresa, los proceso de negocio representan un conjunto de actividades organizadas de tal manera que transforman una serie de entradas (insumos, materia prima, etc.) en resultados (bienes, servicios, etc.) de valor para el cliente (Davenport, 1996; Hammer y Champy, 1995). Un proceso de negocio es un conjunto de actividades que reciben uno o ms tipos de insumos y crean un producto de valor para un cliente (Hammer, 1995, p.37). Muchos procesos de negocios trascienden las reas funcionales tradicionales; por ejemplo, en muchas compaas el proceso de ejecucin de un pedido requiere la cooperacin entre la funcin de ventas, contabilidad y manufactura. En ventas se recibe el pedido y se inicia su trmite; en contabilidad se verifica el crdito y se factura el pedido) y en manufactura se produce y enva el pedido (figura 1.5). Algunos ejemplos de proceso de negocios son: Proceso de Admisin, Proceso de Matrcula, Proceso de Contratacin de Personal, Proceso de Formulacin del Plan Anual de Desarrollo.

14

Figura 1.5 Proceso de ejecucin de un pedido

VENTAS Recibir pedido Iniciar tramite

CONTABILIDAD Verificar Crdito Facturar pedido

MANUFACTURA Producir pedido Enviar pedido

1.2.2 Clases de procesos de negocio


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

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

En estos procesos no hay agente externo, cliente, proveedor, etc., que interacte con la organizacin. Son procesos que apoyan a los procesos principales. Los Procesos de Gestin son aquellos que estn vinculados al mbito de las responsabilidades de la direccin. Se relacionan con actividades de planificacin y control. Ejemplos:
PLANIFICACIN REVISIN

Estos procesos son realizados por los niveles gerenciales, no hay interaccin entre algn agente externo con la organizacin. Son proceso que refleja tareas gerenciales..

15

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.

En la figura 1.6, se describe el proceso de Registrar Pedido de manera grafica, usando la tcnica de Diagrama de Actividades de UML. 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.

16

Figura 1.6 Descripcin Grafica del Proceso Registro de Pedido


CLIENTE COMERCIAL JEFE TECNICO JEFE PRODUCCION

LLENAR PEDIDO TRAMITAR PEDIDO

ANALIZAR VIABILIDAD

NOTIFICAR RECHAZO

[ No es Viable ] [ Si es viable ]

NOTIFICAR ACEPTACION

ORDENAR FABRICACION

PLANIFICAR PRODUCCION

17

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 456789 Jos Quispe 1200 S/100

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. 01 Producto Zapatos Cantidad 1200 Precio S/100

Se puede afirmar que los datos son la materia prima para producir informacin. Entonces, en las organizaciones se procesan datos para obtener informacin.

18

Conocimiento El conocimiento es la informacin conectada a decisiones, procesos y acciones capaces de aplicar esa informacin. Para explicar la diferencia entre informacin y conocimiento, considere una receta de preparacin de una torta. Las instrucciones e ingredientes indicados en la receta vendran a ser informacin, al igual que el libro de receta es informacin. Esta informacin se convierte en conocimiento cuando, una persona elabora una torta siguiendo las instrucciones y utilizando los ingredientes indicados en la receta. En otras palabras, cuando la informacin se lleva a la accin se convierte en conocimiento. Desde una perspectiva de niveles, segn Harris (1996), se puede considerar que el nivel ms bajo de los hechos conocidos son los datos, no tienen un significado intrnseco. En el siguiente nivel, cuando los datos son procesados (ordenados, agrupados, analizados e interpretados), se convierten en informacin con un propsito. En el tercer nivel, cuando la informacin es utilizada y puesta en el contexto o marco de referencia de una persona, se transforma en conocimiento. La figura 2.3 trata de explicar las diferencias entre datos, informacin y conocimiento desde una perspectiva de niveles.
Figura 2.3 Dato, Informacin Y conocimiento

CONOCIMIENTO
Informacin conectada a decisiones, procesos y acciones capacea de aplicar esa informacin

INFORMACIN
Hechos agrupados para un propsito

DATO
Coleccin de hechos

Fuente: (Adaptado de Harris, 1996)

2.2 Qu es Sistema de informacin?


Un sistema de informacin es un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la informacin para apoyar la toma de decisiones y el control en una institucin. Los sistemas de informacin pueden contener datos acerca de personas, lugares y cosas importantes dentro de la institucin y el entorno que la rodea (Laudon, 2004, p.30). 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

19

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

Procedimiento datos

Dato/informacin datos

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

2.4 Tipos de sistemas de informacin


De acuerdo con los intereses, especialidades y niveles en una organizacin, se pueden identificar los siguientes tipos de sistemas de informacin (Laudon, 2006): de nivel operativo, de nivel del conocimiento, de nivel administrativo y de nivel estratgico. Los sistemas de informacin de nivel operativo apoyan a los gerentes operativos en el control de actividades y transacciones elementales de la organizacin, por ejemplo: ventas, ingresos, depsitos en efectivo, nomina, decisiones de crdito y flujo de materiales en una fbrica. Responden a preguntas de rutina y siguen el flujo de transacciones a travs de la organizacin. Por ejemplo, Cuntas partes hay en inventario? Qu pas con el pago del seor Gutirrez? Los sistemas de informacin de nivel del conocimiento apoyan a los trabajadores del conocimiento de una organizacin. Su objetivo es ayudar a las empresas comerciales a integrar el nuevo conocimiento en los negocios y ayudar a la organizacin a controlar el flujo del trabajo de oficina. Estos tipos de sistemas estn entre las aplicaciones de crecimiento ms rpidas en los negocios actuales. Los sistemas de informacin de nivel administrativo apoyan a las actividades de supervisin, control, toma de decisiones, y administrativas de los gerentes de nivel medio. La pregunta principal que plantean estos sistemas es: Van bien las cosas? Por lo general, este tipo de

20

sistemas proporcionan informes peridicos ms que informacin instantnea de operaciones. Apoyan a las decisiones no rutinarias y tienden a enfocarse en decisiones menos estructuradas para las cuales los requisitos de informacin no siempre son claros. Los sistemas de informacin de nivel estratgico apoyan a los directores a enfrentar y resolver aspectos estratgicos y tendencias a largo plazo, tanto en la empresa como en el entorno externo. Su funcin principal es compaginar los cambios del entorno externo con la capacidad organizacional existente. Otra forma de clasificar los sistemas de informacin es segn la funcin que desempean o el tipo de usuario final del mismo, pueden ser (Laudon, 2006): Sistema de procesamiento de transacciones, Sistemas de informacin gerencial, Sistema de soporte a la toma de decisiones, Sistemas de informacin ejecutiva, Sistemas de automatizacin de oficinas, Sistemas expertos y Sistemas de Planificacin de Recursos Empresariales. Los Sistemas de procesamiento de transacciones (Transaction Process System - TPS) son aquellos que permiten gestionar la informacin referente a las transacciones producidas en una empresa u organizacin. Los Sistemas de informacin gerencial (Management Information System - MIS) son aquellos orientados a solucionar problemas empresariales en general. Los Sistemas de soporte a decisiones (Decision Suport System - DSS) son aquellas que sirve de herramienta para realizar el anlisis de las diferentes variables de negocio con la finalidad de apoyar el proceso de toma de decisiones. Los Sistemas de informacin ejecutiva (Executive Information System - EIS) son aquellas herramientas orientadas a usuarios de nivel gerencial, que permite monitorizar el estado de las variables de un rea o unidad de la empresa a partir de informacin interna y externa a la misma. Los Sistemas de automatizacin de oficinas (Office Automation System - OAS) son aplicaciones destinadas a ayudar al trabajo diario del administrativo de una empresa u organizacin. Los Sistemas expertos (Expert System - SE) emulan el comportamiento de un experto en un dominio concreto. Los Sistemas de Planificacin de Recursos Empresariales (Enterprise Resource Planning - ERP) integran la informacin y los procesos de una organizacin en un solo sistema. Todos estos sistemas de informacin a su vez podran analizarse segn las diferentes reas de la empresa: ventas y mercadotecnia, manufactura y produccin, finanzas, contabilidad y recursos humanos. Para cada una de estas reas existe un conjunto especifico de aplicaciones informticas y equipos, los cuales han de estar coordinados entre si. Si ello no se realizara, una empresa tendr problemas de intercambio de datos entre las diferentes reas, aparecer la existencia de redundancia de datos y la existencia de ineficiencias e incrementos de costes de comunicacin.

21

Resumen
Organizacin y Procesos de Negocio
Una organizacin es un sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas de alguna forma con arreglo a ciertas reglas de divisin del trabajo y comunicacin que interactan para producir bienes o servicios. La estructura organizacional representa la forma en que las personas, actividades y recursos se organizan. Puede ser de dos tipos; funcional o de procesos. Funcional: las actividades se organizan verticalmente, en reas funcionales, de forma altamente jerrquica, con mbitos de controles muy limitados y rgidos. Por procesos: las actividades se organizan de manera horizontal, facilitando la reunificacin de actividades fragmentadas. Los roles que las personas desempean en la organizacin se pueden agrupar en niveles organizacionales: Operacionales y Gerenciales. Los Gerenciales pueden ser: estratgico, administrativo, de conocimiento y de control operativo. Nivel Operacional: Actividades rutinarias. No hay toma de decisin. Empleados, obreros. Niveles Gerenciales: Actividades caracterizadas por toma de decisiones. o Nivel estratgico, asuntos estratgicos y tendencias a largo plazo. o Nivel administrativo, aspectos tcticos en el mediano plazo. o Nivel de conocimiento, investigacin y desarrollo o Nivel operativo, control de tareas del personal operacional. Decisiones de corto plazo. Un proceso de negocio es un conjunto de actividades que toman uno o ms tipos de inputs y crean un output que es de valor para un cliente. Clases de Procesos de Negocios Principales: ligados con realizacin del producto / lprestacin del servicio para el Cliente. De Soporte: apoyan los procesos principales. Relacionados con la gestin de recursos. De Gestin: vinculados a la direccin. Se relacionan con actividades de planificacin y control. Un proceso de negocio se puede describir en forma grafica o textual.

Introduccin a los sistemas de informacin


Los datos son registros de hechos observables no procesados que no tienen significado. La informacin es un conjunto de hechos agrupados para algn propsito en particular. Son datos procesados que tienen significado. El conocimiento es la informacin conectada a decisiones, procesos y acciones capaces de aplicar esa informacin. Un sistema de informacin es un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la informacin para apoyar la toma de decisiones y el control en una institucin. Los Componentes de un sistema de informacin son: Hardware, Software, Base de datos, Personas (usuarios finales y personal de T.I.) y Procedimientos. Tipos de sistema de informacin 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).

22

Lectura
INTERNET Y LAS ORGANIZACIONES * Internet, especialmente World Wide Web, est empezando a tener un impacto importante en las relaciones entre las empresas y las entidades externas, e incluso en la organizacin de los procesos de negocios dentro de una empresa. Internet incrementa la accesibilidad, el almacenamiento y la distribucin de la informacin y el conocimiento para las organizaciones. En esencia, Internet es capaz de disminuir de manera importante los costos de la agencia y de transaccin que enfrentan la mayora de las compaas. Por ejemplo, las empresas de corretaje y los bancos de Nueva York ya pueden distribuir sus manuales de procedimientos operativos internos a sus empleados ubicados en lugares lejanos al publicarlos en sus sitios Web corporativos, ahorrando de esta manera millones de dlares en costos de distribucin. Una fuerza de ventas global puede recibir casi al instante informacin actualizada sobre el precio de un producto a travs de la Web o instrucciones de la administracin a travs de correo electrnico. Los proveedores de algunos grandes detallistas pueden acceder a los sitios Web internos de estos ltimos para obtener directamente informacin de ventas actualizada y emitir de manera instantnea rdenes de reabastecimiento. Las empresas estn reconstruyendo rpidamente algunos de sus procesos de negocios esenciales con base en la tecnologa de Internet y haciendo de esta tecnologa un componente clave de sus infraestructuras de tecnologa de la informacin. Si la experiencia anterior con las redes sirve de gua, un resultado ser procesos de negocios ms sencillos, menos empleados y organizaciones mucho ms planas que el pasado.

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

23

Actividades
1 Identifique una organizacin, de cualquier tipo o tamao, indique el giro del negocio, obtenga su organigrama y realice la descripcin textual o grfica de uno de sus procesos de negocio de tipo principal. Busque, en internet, un producto comercial de cada tipo de sistema de informacin.

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

2.

3.

4.

5.

6.

7.

24

b. c. d. e. 8.

( ( ( (

) Abarca solo elementos computacionales ) Sus componentes son Hardware, Software, Base de datos, Procedimientos y Personas ) Captura, procesa, almacena y distribuye informacin ) Los procedimientos establecen reglas y normas de uso del sistema

Coloque la letra en la celda a la derecha del tipo de sistemas de informacin (S.I.) que relaciona el nombre del tipo de sistema de informacin con la definicin que corresponda: Tipo de S.I. 1. TPS 2. MIS 3. DSS 4. EIS 5. OAS 6. SE 7. ERP Definicin de tipo de S.I. Aplicaciones para ayudar el trabajo del administrativo de una empresa Emulan el comportamiento de un experto en un dominio concreto Integran informacin y proceso de una organizacin en un solo sistema Permiten el anlisis de variables del negocio para tomar decisiones Orientados a solucionar problemas empresariales en general Gestionan la informacin de transacciones en una empresa Orientado a monitorizar estado de un rea o unidad de una empresa

a) b) c) d) e) f) g)

Respuestas de Control 1. a = F, b = V, c = V, d = F, e = V 2. a = F, b = F, c = P, d = F, e = P 3. a = E, b = A, c = A, d = E, e = A, f = C, g = O 4. a = F, b = V, c = F, d = V, e = V 5. a = P, b = S, c = G, d = G, e = P 6. a = F, b = V, c = F, d = V, e = V 7. a = V, b = F, c = V, d = V, e = V 8. 1 = f, 2 = e, 3 = d, 4 = g, 5 = a, 6 = b, 7 = c

Exploracin on-line
Portal del CIO, Portal de la Compaa IBM sobre transformacin de procesos de negocio para incrementar la flexibilidad empresarial a travs de SOA; contiene documentos, videos y casos de estudio. https://www-935.ibm.com/services/es/cio/flexible/ OMG, Object Management Group / Business Process Management Initiative Pgina de la Organizacin Internacional OMG (Object Management Group) que contiene informacin de estndares de modelado de procesos de negocios. http://www.bpmn.org/

Referencias bibliogrficas
1 2 3 4 5 Davenport, Thomas (1996). Innovacin de Procesos: Reingeniera del trabajo a travs de la tecnologa de la informacin. Espaa. Daz Santos. Hammer, Michel y James Champy (1995), Reingeniera. Bogota. Grupo Editorial Norma.. Harris, David (1996), Creating a Knowledge Centric Information Technology Environment. Harris Training & Consulting Services Inc., Seattle, WA, September. Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Informacin Gerencial. 8 Ed. Mxico D.F. Pearson Educacin. Laudon, Jane y Kenneth (2006). Sistemas de informacin gerencial, Administracin de la empresa digital. Mxico D.F. Pearson Educacin- Prentice Hall

25

SEGUNDA UNIDAD EL PROCESO DE DESARROLLO, RUP Y UML


Qu es un proceso de desarrollo, cules son sus fases y actividades genricas? Cules son los modelos de proceso de desarrollo? Qu es metodologa, tcnica y herramienta de desarrollo? Qu es el UML y cules son sus elementos, relaciones y diagramas? Qu es el RUP y cuales sus fases y flujos, artefactos, trabajadores, actividades?

PROPOSITOS
Al finalizar esta unidad, el estudiante: Explica las fases de un proceso de desarrollo y sus actividades genricas Describe las caractersticas de los diversos modelos de proceso de desarrollo Comprende los conceptos de metodologa, tcnica y herramienta Comprende los elementos, las relaciones y los diagramas del UML Comprende las fases, flujos, artefactos, trabajadores y actividades del RUP

26

Leccin 3 Proceso de desarrollo de sistemas de informacin


La construccin de un sistema de informacin implica un esfuerzo conjunto de profesionales de tecnologa de informacin y lderes de la organizacin. Este esfuerzo significa realizar una serie de actividades conducentes a obtener un sistema de calidad. Esta serie de actividades se conoce como proceso de desarrollo que deviene en metodologas de desarrollo. Esta leccin ayuda a comprender las caractersticas de un proceso de desarrollo, los modelos que existen y los conceptos relacionados a las metodologas de desarrollo.

3.1 Proceso de desarrollo, una visin genrica 3.1.1 Qu es un proceso de desarrollo?


El proceso de desarrollo es una gua acerca de las actividades y tareas necesarias para construir un sistema de informacin. En el contexto de software, programas de aplicacin o aplicaciones informticas, Pressman (2002) considera al Proceso como un marco de trabajo que define las tareas a realizar para desarrollar software de alta calidad. Se han establecido diversos modelos de proceso de desarrollo de sistemas de informacin, con actividades y tareas especficas; pero se puede establecer una serie de actividades comunes que llamaremos visin genrica, considerando las siguientes fases (Pressman, 2002): Definicin, Desarrollo y Evolucin. Figura 3.1 Fases del proceso de desarrollo: Visin genrica

Definicin
Anlisis del Sistema Requerimientos Planificacin

Desarrollo
Diseo Codificacin Prueba

Evolucin
Correccin Adaptacin Mejora

Fuente: (Pressman, 2002)

3.1.2 Fase de Definicin


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

27

Planificacin del proyecto de software. Una vez establecido el mbito del software, se analizan los riesgos, se asignan los recursos, se estiman los costes, se definen las tareas y se planifica el trabajo.

3.1.3 Fase de Desarrollo


El propsito de la fase de Desarrollo es determinar cmo han de disearse las estructuras de datos y la arquitectura del software, cmo han de implementarse los detalles procedimentales, cmo ha de traducirse el diseo a un lenguaje de programacin y cmo ha de realizarse la prueba. En general se aplicarn tres pasos concretos: Diseo del Software, Codificacin y Pruebas del software. Diseo de software. El diseo traduce los requisitos de software a un conjunto de representaciones (algunas grficas y otras tabulares o basadas en lenguajes) que describen las estructuras de bases de datos, la arquitectura, el procedimiento algortmico y las caractersticas de la interfaz. Codificacin. Las representaciones del diseo debern ser traducidas a un lenguaje artificial (un lenguaje de programacin convencional o un lenguaje no procedimental T4G), dando como resultado unas instrucciones ejecutables en la computadora. Prueba del software. Una vez que el software ha sido implementado en una forma ejecutable por la maquina, debe ser probado para descubrir los defectos que puedan existir, en la funcin, en la lgica y en la implementacin.

3.1.4 Fase de Evolucin


La fase de Evolucin, tambin llamada fase de mantenimiento, se centra en los cambios que van asociados a la correccin de errores, a las adaptaciones requeridas por la evolucin del entorno del software y a las modificaciones debidas a los cambios de requisitos del usuario dirigidos a reforzar o ampliar el sistema. La fase de mantenimiento vuelve a aplicar las fases de definicin y de desarrollo, pero en el contexto del software ya existente. Se encuentran tres tipos de cambio: Correccin, Adaptacin y Mejora. Correccin. Incluso llevando a cabo las mejores actividades de garanta de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos. Adaptacin. Con el paso del tiempo es probable que cambie el entorno original (sistemas operativos, equipos perifricos, etc.) para los que se desarrollo el software. El mantenimiento adaptativo consiste en modificar el software para acomodarlo a los cambios de su entorno externo. Mejora. Conforme utilice el software, el usuario puede descubrir funciones adicionales que podran interesar que estuvieran incorporadas en el software. El mantenimiento perfectivo amplia el software ms all de sus requisitos funcionales originales.

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.

28

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

29

evaluado por el cliente y sirve para refinar los requerimientos. Se inicia nuevamente el ciclo, conocido como iteracin (figura 3.3). Lo ideal es que este prototipo sirva slo para identificar los requisitos y una vez que esto se logr se lo deseche; generalmente, estos prototipos, si son operativos (working prototype) suelen ser muy lentos o muy grandes o torpes o las tres cosas a la vez. Lo ideal es, ahora, construir una versin rediseada en la que estos problemas no estn presentes.
Figura 3.3 Modelo Construccin de prototipos

Fuente: (Adaptado de Pressman, 2002)

En este modelo, cuando el cliente observa el prototipo operativo, cree que es la versin final del sistema, sin entender que se trata de solo un prototipo y que el producto no est terminado. Por la presin de hacer que el prototipo funcione rpidamente, el desarrollador puede elegir, inadecuadamente, el sistema operativo o el lenguaje de programacin; incluso, puede usar un algoritmo incorrecto. Despus de algn tiempo, puede familiarizarse con estas elecciones y olvidarse las razones por las cuales son inadecuadas, dejndolas luego como una parte integral del sistema. Aunque pueden surgir estos problemas, ste es un modelo til a la hora de construir un sistema donde no se tiene claros los requisitos inicialmente. La clave est en establecer claramente, al principio, las reglas de juego con el cliente y llegado el momento, no ceder a la presin de ste para conservarlo como producto final.

3.2.3 Modelo Desarrollo Rpido de Aplicaciones (DRA)


El Modelo de Desarrollo Rpido de Aplicaciones (DRA), Rapid Application Development (RAD), es un modelo lineal secuencial con un ciclo extremadamente corto. La rapidez se logra gracias al reso de componentes, 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.

30

Modelo de Procesos: en esta fase se construye un modelo de procesos donde se muestran las transformaciones necesarias sobre los objetos del modelo de datos a los efectos de lograr la funcionalidad deseada. Generacin de Aplicaciones: en esta fase se genera la aplicacin con el empleo de tcnicas de cuarta generacin, adems de re-usar componentes existentes (cuando es posible) y la creacin de componentes reutilizables (cuando es necesario). Prueba y Entrega: Dado que enfatiza la reutilizacin de componentes, los cuales ya han sido probados, el tiempo de prueba se ve reducido. Sin embargo se deben probar todos los componentes nuevos y las interfaces entre mdulos.
Figura 3.4 Modelo DRA

Fuente: (Pressman, 2002)

En este modelo, cuando el proyecto es grande, se requiere un gran nmero de personas para formar equipos paralelos suficientes. 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).

31

Por ejemplo, para un editor de textos, en el primer incremento podramos entregar funcionando la gestin de archivos y la produccin de documentos, en el segundo incremento las funciones ms sofisticadas relacionadas con la edicin y en el tercer incremento la revisin ortogrfica. Al finalizar cada incremento, el cliente recibe una versin operativa del producto y lo evala. Como resultado de su utilizacin y evaluacin, se desarrolla un plan para el siguiente incremento. Este plan contempla la modificacin del producto central para cumplir mejor con las necesidades del cliente y adems para agregar nueva funcionalidad.
Figura 3.5 Modelo Incremental

Fuente: (adaptado de Pressman, 2002)

Este modelo es particularmente til cuando no se est seguro de poder cumplir con los plazos de tiempo debido a falta de personal de desarrollo, o cuando se tenga una fecha imposible de cambiar, ya que en todos los casos, el cliente se queda con una versin operativa del producto.

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.

32

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

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

33

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

34

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

35

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. Figura 4.1 Elementos estructurales del UML Clase
Colaboracin Interfaz
Caso de uso Nodo Componente

La Clase representa un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.

36

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.

4.4 Relaciones en UML Las relaciones del UML representan los vnculos entre dos elementos del modelo. Incluye: dependencia, asociacin, generalizacin y realizacin.
Dependencia

37

Representa una relacin semntica entre dos elementos, tal que un cambio en uno de ellos (el independiente) puede afectar al otro (el dependiente).

Asociacin
Representa una relacin estructural que describe un conjunto de links, siendo un link una conexin entre objetos.

Generalizacin
Representa una relacin de generalizacin/especializacin en la que el elemento especializado (descendiente) se construye sobre la especificacin del elemento generalizado (ancestro)

Realizacin
Representa una relacin semntica en la que un clasificador, tal como una interfaz o un caso de uso, especifica un contrato que otro clasificador, tal como una clase o una colaboracin, garantiza llevar a cabo.

4.5 Diagramas en UML


La versin 2.0 del UML (Booch, 2006) considera 13 diagramas (figura 4.2), divididos en Diagramas dinmicos y estticos.
Figura 4.2 diagramas del UML

Fuente: (Adaptado de Jacobson, 2006)

El Diagrama de Clases, muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones. 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.

38

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.

39

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

40

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

41

Al finalizar esta fase, se obtienen: Un sistema software funcional, La documentacin correspondiente a ste. 5.3.4 Fase de Transicin

Se ocupa de mover el sistema desde la comunidad de desarrollo a la comunidad del usuario. Tambin de hacer trabajar el software en un entorno real. Esta fase es comnmente ignorada en la mayora de los modelos de proceso de software, an cuando es muy importante y pude implicar altos costos. Al finalizar esta fase, se obtiene: Un sistema de software documentado adecuadamente y que funcione correctamente en su entorno operativo 5.4 Flujos La perspectiva esttica del RUP se centra en las actividades que tienen lugar durante el proceso de desarrollo. stas se denominan flujos de trabajo en la descripcin del RUP (Figura 5.2). Existen seis flujos de trabajo del proceso: Modelado de negocio Requerimientos Anlisis y diseo Implementacin Pruebas Implantacin Existen tres flujos de trabajo de soporte Administracin de cambios y configuracin Administracin del proyecto Entorno Figura 5.2 Estructura del RUP, fases y flujos.

Fuente: (Jacobson, 2000)

42

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.

43

Los elementos de comportamiento representan la parte dinmica del sistema, es decir el comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados. Los elementos de agrupacin representan la parte organizativa del sistema. Incluye: Paquete. Los elementos de anotacin representan la parte explicativa del sistema. Son comentarios. Incluye: la nota

Las relaciones en UML representan los vnculos entre dos elementos del modelo. Incluye: dependencia, asociacin, generalizacin y realizacin. La dependencia representa una relacin semntica entre dos elementos, tal que un cambio en uno de ellos (el independiente) puede afectar al otro (el dependiente, clase activa, componente, cadena de responsabilidad La asociacin representa una relacin estructural que describe un conjunto de links, siendo un link una conexin entre objetos. La generalizacin representa una relacin de generalizacin/especializacin en la que el elemento especializado (descendiente) se construye sobre la especificacin del elemento generalizado (ancestro) La realizacin representa una relacin semntica en la que un clasificador, tal como una interfaz o un caso de uso, especifica un contrato que otro clasificador, tal como una clase o una colaboracin, garantiza llevar a cabo. Los diagramas en UML, version2.0, son 13, divididos en diagramas estticos y dinmicos. Los diagramas estticos son: diagrama de clases, diagrama de objetos, diagrama de componentes, diagrama de despliegue, diagrama de paquetes y diagrama de estructura. Los diagramas dinmicos son: diagrama de casos de uso, diagrama de secuencia, diagrama de colaboracin, diagrama de estado, diagrama de actividades, diagrama cronolgico, diagrama de interacciones.

Introduccin a RUP
El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso 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.

44

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.

45

Hay algn mrito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado actual de los enfoques de T4G: 1. El uso de T4G es un enfoque viable para muchas de las diferentes reas de aplicacin. Junto con las herramientas de ingeniera de software asistida por computadora (CASE) y los generadores de cdigo, T4G ofrece una solucin fiable a muchos problemas del software. 2. Los datos recogidos en compaas que usan T4G parecen indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeas y de tamao medio, y que la cantidad de anlisis y diseo para las aplicaciones pequeas tambin se reduce. 3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o ms tiempo de anlisis, diseo y prueba (actividades de ingeniera del software), para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminacin de la codificacin. Resumiendo, las tcnicas de cuarta generacin ya se han convertido en una parte importante del desarrollo de software. Cuando se combinan con enfoques de ensamblaje de componentes el paradigma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software.

(*)Fuente: (Pressman, 2002, pp. 29-30)

46

Actividades
1. Realice un cuadro comparativo entre los modelos de ciclo de vida de desarrollo de software, indicando criterios de comparacin, ventajas y desventajas de cada una de ellas por cada criterio. 2. Busque en internet herramientas de software libre para modelar con el UML 2.0. .

Autoevaluacin
1. Con respecto al concepto de Proceso de Desarrollo, entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn corresponda: a. ( ) Es una gua acerca de las actividades para desarrollar sistemas de informacin b. ( ) Marco de trabajo que define tareas para desarrollar software c. ( ) Es un proyecto de desarrollo de software d. ( ) Conjunto de herramientas para desarrollar software e. ( ) Conjunto de Mtodos para desarrollar software En la celda a la derecha de la actividad de desarrollo de sistemas de informacin coloque la letra de la descripcin que corresponda:
Actividad de desarrollo 1. Anlisis de sistemas 2. Requerimientos 3. Planificacin 4. Diseo 5. Codificacin 6. Prueba Descripcin de la actividad de desarrollo de S.I. A Se analizan los riegos, se asignan recursos, se estiman costes y se planifica B Se traducen la representacin de diseo en instruccin ejecutable (programa) C Su objetivo es descubrir defectos que puedan existir D Se traducen los requerimientos en representaciones de diseo E Se define el papel de cada elemento del sistema de informacin F Su resultado es informacin detallada de la funcionalidad del software

2.

3.

En la celda a la derecha del modelo de proceso de desarrollo coloque la letra de la caracterstica que le corresponda:
Modelos de Proceso 1. Secuencial 2. Prototipos 3. DRA 4. Incremental 5. Espiral Caractersticas del modelo de desarrollo A No son aptos para los sistemas que no se pueden modularizar B Es til cuando no se esta seguro de poder cumplir con los plazos C Es un modelo evolutivo que considera clave el anlisis de riesgos D Una actividad no puede iniciar si no ha terminado la anterior E Util cuando no se tiene claros los requerimientos desde el inicio.

4.

Marque V= Verdadero o F = Falso, segn corresponda: a. ( ) Una metodologa es un conjunto de personas que coordinan para desarrollar software b. ( ) Una tarea es una actividad fundamental segn algn procedimiento c. ( ) Un procedimientos es el soporte software para apoyar una tcnica d. ( ) Una tcnica es la herramienta utilizada para aplicar un procedimiento e. ( ) Un producto es el resultado de una fase o actividad de una metodologa En relacin al UML y RUP, en la celda a la derecha del Termino coloque la letra de la Definicin o Caracterstica que le corresponda:
Trmino 1. Artefacto 2. Clase 3. Caso de Uso 4. Elemento Estructural 5. UML 6. RUP 7. Trabajador 8. Flujo de Trabajo 9. Fase de Inicio 10. Fase de Elaboracin Definicin o Caractersticas del Termino A. Representa funcionalidad del sistema como secuencia de acciones B. Proceso de desarrollo de software, marco genrico que puede ajustarse C. Rol que puede ser realizado por una persona o equipo D. Representa conjunto de objetos con atributos, operaciones comunes E. Define la lista de actividades, trabajadores y artefactos en el RUP F. Representa pieza de informacin usada o producida en un proceso de desarrollo G. Fase del RUP que permite decidir continua o cancelar un proyecto H. Fase del RUP que permite comprender el dominio del problema I . Permite especificar, construir, visualizar y documentar elementos del software J. Representan la parte esttica del sistema

5.

47

Respuestas de Control
1. 2. 3. 4. 5. a = V, b = V, c = F, d = F, e = F 1 = E, 2 = F, 3 = A, 4 = D, 5 = B, 6 = C 1 = D, 2 = E, 3 = A, 4 = B, 5 = C a = F, b = V, c = F, d = V, e = V 1 = F, 2 = D, 3 = A 4 = J, 5 = I, 6 = B , 7 = C , 8 = E, 9 = G , 10 = H

Exploracin on-line
ISO/IEC 12207 Pagina de la organizacin internacional para la estandarizacin, ISO http://www.iso.org/iso/catalogue_detail.htm?csnumber=43447 OMG UML Pagina oficial del Object Management Group, sobre UML, proporciona informacin y recursos para UML http://www.uml.org/ IBM - RUP Pagina de IBM Rational Unified Process, que ofrece informacin y recursos sobre la plataforma de proceso de desarrollo de software configurable http://www-01.ibm.com/software/pe/rational/rup.shtml

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.

48

TERCERA UNIDAD EL MODELADO DEL NEGOCIO

Qu es el modelado de negocios, cules son sus perspectivas? Qu es un actor del negocio, un caso de uso del negocio, una meta del negocio y un diagrama de caso de uso del negocio? Qu es un trabajador de negocio, una entidad de negocio y una realizacin de caso de uso del negocio? Cmo se elabora el modelo del negocio?

PROPOSITOS
Al finalizar esta unidad, el estudiante: Explica las caractersticas, y elementos del modelado de negocio con UML Elabora modelos de negocio, considerando modelo de casos de uso del negocio y modelo de anlisis del negocio usando el UML

49

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

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

50

son aquellos que proporcionan apoyo a los procesos principales, usualmente estn relacionados con la gestin de recursos. Los casos de uso del negocio de gestin son aquellos que estn vinculados al mbito de las responsabilidades de la direccin, se relacionan con actividades de planificacin y control. Para identificar un caso de uso del negocio principal (proceso de negocio principal) es necesario determinar el servicio o producto de la empresa que recibe el actor del negocio. Para identificar un caso de uso de negocio de soporte (proceso de negocio de soporte) es necesario determinar que se requiere para ofrecer los productos o servicios al cliente. Para identificar casos de uso de negocio de gestin es necesario examinar las actividades relacionadas con la gestin de la empresa en su conjunto. Algunos ejemplos de Casos de uso del negocio son: Solicitar un pedido, Realizar Venta.

6.2.3 Metas del negocio


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

6.2.4 Diagrama de casos de uso del negocio


El Diagrama de casos de uso del negocio (CUN) muestra a los actores del negocio, casos de uso del negocio y las relaciones entre ellos (Figura 6.4).
Figura 6.4 Diagrama CUN

6.3 Modelo de Anlisis del Negocio


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

6.3.1 Trabajador del negocio


Es una abstraccin de una persona o sistema software que representa un rol que se ejecuta dentro de la realizacin de un CUN (figura 6.5).
Figura 6.5 Trabajador de negocio

51

Un trabajador del negocio (business worker) es alguien que realiza actividades dentro de un caso de uso del negocio, interacta con otros trabajadores del negocio y manipula entidades del negocio.

6.3.2 Entidad del negocio


Representa una pieza de informacin significativa y persistente que es manipulada por los actores y trabajadores del negocio (figura 6.6). Una entidad del negocio (business entity) representa a un conjunto de informacin con propiedades, comportamiento y semntica similares y que es manipulado o manejado por trabajadores del negocio. Algunos ejemplos son: Factura, Solicitud de pago y Tarjeta de crdito.
Figura 6.6 Entidad de negocio

6.3.3 Realizacin de caso de uso del negocio


Describe como los trabajadores, entidades y eventos del negocio colaboran para desarrollar un caso de uso del negocio
Figura 6.7 Realizacin de caso de uso del negocio

La realizacin de un caso de uso del negocio (figura 6.7) puede incluir o se puede representar con: Diagrama de actividades o Diagrama de Clases. Diagrama de actividades El Diagrama de actividades permite explorar el orden en que se realizan las actividades en un caso de uso de negocio. Una actividad es una tarea manual o automatizada que completa una unidad de trabajo. Los elementos bsicos de un diagrama de actividades son: Inicio, fin, actividad, transicin, barra de sincronizacin y bifurcacin. En la figura 6.8 se observa un diagrama de actividades bsico, que se puede interpretar como sigue: el proceso se inicia con el llenado del pedido, la flecha de transicin entre llenar pedido y tramitar pedido significa que despus de la actividad llenar pedido sigue la actividad tramitar pedido. Terminado de tramitar el pedido, sigue la actividad analizar viabilidad cuyo resultado indica que si no es viable, se notifica el rechazo y termina el flujo con rechazo; si es viable, en forma paralela se pueden realizar Notificar aceptacin y Ordenar fabricacin, luego planificar produccin. Para que el flujo finalice correctamente, tiene que terminarse las actividades Notificar aceptacin y Planificar produccin. En la figura 6.9 se muestra un diagrama de actividades detallado, que incluye elementos adicionales, como los carriles, que permiten representar trabajadores del negocio que realizan actividades: Jefe de taller y Dpto. reparaciones; y entidades de negocio: libro de citas, numero de trabajo interno, orden de reparacin, etc.

52

Figura 6.8 Diagrama de actividades simple


LLENAR PEDIDO

TRAMITAR PEDIDO

ANALIZAR VIABILIDAD

NOTIFICAR RECHAZO

[ No es viable ]

NOTIFICAR ACEPTACION

ORDENAR FABRICACION

PLANIFICAR PRODUCCION

Figura 6.9 Diagrama de actividades detallado


: Jefe de taller : Dpto reparaciones

a : Libro de citas

Revisar cita aceptada 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 [original] Guardar en partes pendientes p : Partes de trabajo [pendiente]

53

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
(f rom Entidades del negccio)

revisa partes pendientes

Obtiene precios de materiales Inventario de articulos


(f rom Entidades del negccio)

Obtiene precio de mano de obra indica numero de identificacion Facturador


(f rom Trabajadores del negocio)

Registra pendiente Asigna numero factura Calcula importe total Fichero de mecanicos recibe copia Cliente
(f rom Business Use-Case Model) (f rom Entidades del negccio)

Realiza Factura registrar facturas pagadas

(f rom Entidades del negccio)

Recib e Empleado del mostradoir


(f rom Trabajadores del negocio)

pago con tarjeta


(f rom Entidades del negccio)

pago
(f rom Entidades del negccio)

Pago en efectivo
(f rom Entidades del negccio)

54

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.

Cliente

Proveedor

7.1.2 Identificando Casos de Uso del Negocio


Los casos de uso de negocio principales son: Registrar Pedido del Cliente y realizar compra a proveedores. Los casos de uso del negocio de soporte son: Fabricar producto pedido y Controlar almacn. No se identifican casos de uso del negocio de gestin.

55

Registrar pedido

Fabricar producto

Controlar almacen Comprar materia prima

7.1.3 Identificando Metas del Negocio


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

Reducir tiempo en 20%

Mantener stock adecuado

Reducir tasa errores a 0.5% Reducir generacin orden compra en 20%

7.1.4 Elaborando el diagrama de casos de uso del negocio


Se asocia los actores con cada caso de uso principal y cada caso de uso con su respectiva meta.

Creado por : Cesar Luza Fecha: Enero 25, 2010

Cliente
(f rom Actores del negocio)

Registrar pedido
(from Casos de uso del negocio)

Reducir tiempo en 20%


(f rom Metas del negocio)

Fabricar producto
(from Casos de uso del negocio)

Reducir tasa errores a 0.5%


(f rom Metas del negocio)

Controlar almacen

Mantener stock adecuado


(f rom Metas del negocio)

(from Casos de uso del negocio)

Proveedor
(f rom Actores del negocio)

Comprar materia prima


(from Casos de uso del negocio)

Reducir generacin orden compra en 20%


(f rom Metas del negocio)

56

7.2 Elaborar el modelo de anlisis del negocio


En nuestro ejemplo, de la empresa Vende barato S.A. consideremos la siguiente descripcin de caso de uso de negocio Registrar pedido:

1. 2.

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. 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. 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. 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. El Empleado del Dpto. de Ventas comunica al cliente el resultado final del anlisis de su pedido.

3.

4.

5.

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

57

7.2.3 Construyendo las realizaciones de caso de uso del negocio


Realizacin con diagrama de actividades del Caso de Registrar Pedido
: Cliente : Empleado de Ventas : Jefe Tecnico : Jefe Produccion

: Catalogo Llenar pedido

: Plantilla de fabricacion

p : Pedido [propuesto]

Analizar viabilidad x : Pedido Tramitar pedido [ NO Viable ] [ SI viable ] : Plantilla de fabricacion Informar rechazo r : Pedido [Rechazado] Ordenar Fabricacin : Orden de Trabajo : Producto especial

Informar aceptacion a : Pedido [Aceptado] Planificar produccin

58

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

Proceso de modelado del negocio

59

Lectura
Manifiesto de Reglas de Negocio (*) Los Principios de la Independencia de las Reglas
The Business Rules Group

Artculo 1. Los requisitos como elementos principales, nunca como secundarios


1.1. Las reglas son un ciudadano de primera clase en el mundo de los Requisitos. 1.2. Las reglas son esenciales para los modelos de negocio y para los modelos de tecnologa, y una parte separada y especifica de los mismos.

Artculo 2. Independientes de los procesos y no contenidas en ellos


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

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


5.1. Las reglas se construyen sobre hechos, y los hechos sobre conceptos tal y como son expresados mediante trminos. 5.2. Los trminos expresan conceptos de negocio; los hechos realizan afirmaciones sobre estos conceptos; las reglas restringen y apoyan estos hechos. 5.3. Las reglas deben ser explicitas. No se debe asumir ninguna regla sobre ningn concepto o hecho. 5.4. Las reglas son los fundamentos que definen lo que el negocio sabe de si mismo- es decir son conocimiento bsico de negocio. 5.5. Las reglas necesitan ser alimentadas, protegidas y gestionadas.

Artculo 4. Declarativas, no de procedimiento


4.1 Las reglas deben expresarse de forma declarativa en sentencias de lenguaje natural, por la audiencia conocedora del negocio. 4.2 Si algo no puede ser expresado claramente, entonces no es una Regla. 4.3 Una serie de enunciados solo es declarativa si no contiene una secuencia implcita. 4.4 Cualquier enunciado de reglas que necesite de otros elementos que no sean trminos o hechos, revelan hiptesis sobre la implementacin de un sistema. 4.5 Una regla es distinta del nivel de cumplimiento definido para ella. La regla y su nivel de cumplimiento son dos asuntos diferentes. 4.6 Las reglas deben definirse independientemente de la quien tiene la responsabilidad de su cumplimiento, y de donde, cuando o como se refuerzan. 4.7 Las excepciones a las reglas se definen mediante otras reglas.

Artculo 5. Expresiones bien formadas, no expresiones creadas con fines especficas para un caso
5.1 Las reglas de negocio se deben expresar demanera que pueda ser validada su exactitud por el personal conocedor del negocio. 5.2 Las reglas de negocio se deben expresar de manera que se pueda verificar recprocamente su coherencia. 5.3 Las lgicas formales, como la lgica de predicados, son fundamentales para la expresin formal de reglas en trminos de negocio, as como para las tecnologas que implementan dichas reglas.

Artculo 6. Arquitectura basada en las reglas, no una implementacin indirecta


6.1 Un sistema basado en reglas de negocio se construye intencionadamente para permitir el cambio continuo de las reglas de negocio. La plataforma sobre la que el sistema se ejecuta debe soportar esta evolucin. 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.

60

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


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

(*) Business Rules Group. Version 2.0, November 1, 2003. Edited by Ronald G. Ross. www.businessrulesgroup.org/brmanifesto/BRManifiesto.pdf

61

Actividades
Elaborar el Modelo del Negocio considerando la siguiente descripcin: La Empresa FABCLM se dedica a la fabricacin de productos de consumo masivo. La Gerencia General desea automatizar las principales actividades que la empresa realiza en los procesos de atencin de pedidos, control de la fabricacin, proceso de facturacin y entrega de mercadera. Proceso de atencin de pedidos El cliente enva su pedido por distintos medios (telfono, correo o fax), son recibidos por la empleada encargada de la Oficina de Atencin a Clientes, quien solicita que se realicen las siguientes comprobaciones: Antonio (Dpto de Almacn) se encarga de verificar la disponibilidad de los artculos solicitados, consultando el inventario de artculos. Juan (Dpto. Contabilidad) verifica el estado de la cuenta del cliente para ver si tiene deudas pendientes; y el Dpto. Legal verifica si el cliente tiene antecedentes sospechosos, consultando el archivo de antecedentes. En caso de que los pedidos no cumplan alguna de las condiciones anteriores sern rechazados, notificndoselo al cliente. Pero si todo es correcto, se registrar aceptacin del pedido. En ambos casos es la empleada la que informa al cliente. Proceso de control de fabricacin El proceso se inicia cuando el pedido aceptado es recibido por el Jefe de Produccin, quien le asigna un nmero de trabajo interno, luego genera la orden de produccin y registra el pedido como pendiente de fabricacin. La orden de produccin se enva a la seccin de fabricacin para que empiece a elaborar los productos del pedido. Cuando finaliza el trabajo, el Jefe de Produccin elabora una carta donde indica a quin sern enviados los productos que se encuentran listos. Evidentemente, el pedido deja de ser pendiente. Proceso de Facturacin Recibida la carta de productos terminados el Dpto de Facturacin procede a elaborar la factura y el taln de embarque. Una copia de la factura se enva al Dpto. de Contabilidad que se encarga de realizar los asientos. Otra copia se aade al archivo de facturas. Este ltimo archivo se emplea nicamente como referencia; no es un archivo activo sino que solo sirve para seguridad. Proceso de Entrega Los artculos elaborados se reciben en el rea de embarque, donde son empaquetados, y el taln de embarque se anexa a la caja de embarque. 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.

62

Autoevaluacin
1. Con respecto al Modelado del Negocio, entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn corresponda: a. ( ) Es una tcnica para representar un sistema software b. ( ) Permite asegurar que se construir el sistema en el contexto de necesidades de la empresa c. ( ) Es un Marco de trabajo que define los procesos de negocio d. ( ) Tiene dos perspectivas, una externa y otra interna e. ( ) El modelo de casos de uso del negocio representa la perspectiva interna f. ( ) El modelo de anlisis del negocio representa la perspectiva externa En relacin al Modelo de casos de uso del negocio y modelo de anlisis del negocio, en la celda a la derecha del Termino coloque la letra de la Definicin o Caracterstica que le corresponda:
Definicin o Caractersticas del Termino A. Representa un proceso del negocio B. Representa el valor deseado en una medida particular C. Muestra actores de negocio, casos de uso de negocio y sus relaciones D. Representa pieza de informacin significativa E. Representa un rol que alguien desempea en relacin al Negocio F. Describe la colaboracin entre trabajadores, entidades y eventos del negocio G. Representa un rol dentro de la realizacin de un CUN

2.

Trmino 1. Actor del negocio 2. Casos de uso del negocio 3. Meta del negocio 4. Trabajador del negocio 5. Entidad del negocio 6. Diagrama CUN 7. Realizacin de CUN

Respuestas de Control
1. 2. a = F, b = V, c = F, d = V, e = F, f = F 1 = E, 2 = A, 3 = B, 4 = G, 5 = D, 6 = C, 7 = F

Exploracin on-line
Pagina de IBM Rational Unified Process, que ofrece informacin y recursos sobre la plataforma de proceso de desarrollo de software configurable
http://www-01.ibm.com/software/pe/rational/rup.shtml

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.

63

CUARTA UNIDAD EL MODELADO DE DOMINIO

Qu es el modelado de dominio? Qu es un diagrama de clases? Cules son sus elementos? y Cmo se construye?

PROPOSITOS
Al finalizar esta unidad, el estudiante: Explica las caractersticas, y elementos del modelado de dominio con UML Elabora modelos de dominio, usando diagrama de clases del UML

64

Leccin 8 Conceptos asociados al modelo de dominio


En el contexto de desarrollo de sistemas de informacin, es frecuente, en las primeras etapas del proceso, construir un modelo del dominio del problema para representar las propiedades ms importantes del mbito del negocio relacionado con el problema. Una tcnica muy utilizada para representar este modelo de domino es el diagrama de clases de UML; precisamente, en esta leccin se describen las bases conceptuales para construir adecuadamente un diagrama de clases.

8.1 Clase y Objeto


Un objeto se define como un concepto, abstraccin o cosa con lmites bien definidos y con significado para el problema que se tenga entre manos. Una clase describe un conjunto de objetos con propiedades similares, relaciones comunes con otros y una semntica comn (Rumbaugh, 1996). Por ejemplo, Anlisis de sistemas, Base de datos I, Estadstica II, Matemtica Bsica I son objetos de la clase ASIGNATURA, en otras palabras, ASIGNATURA representa al conjunto de todas las asignaturas en el dominio de la gestin acadmica de una institucin educativa.

8.2

Atributo

Una clase tiene una serie de caractersticas o propiedades, por ejemplo ASIGNATURA tiene cdigo, nombre, crditos, horas de teora, horas de practica; a estas propiedades se le conoce como atributos de la clase. Un atributo es una propiedad de una clase que describe un rango de valores que la propiedad podr contener en los objetos de la clase (Rumbaugh, 1996).. Podemos decir que una clase representa un conjunto de objetos con las mismos atributos y un objeto es una instancia de una clase, es decir es una entidad que tiene valores especficos para cada uno de los atributos de la clase. Por ejemplo, la clase AUTOMOVIL, tiene como atributos: nmero de placa, color, modelo, nmero de puertas, ao, entre otros. Un objeto, de la clase AUTOMOVIL, es el auto de placa SGD345, color azul, modelo Station Wagon, con cuatro puertas, del ao 2000. Otro objeto es el auto de placa ERG237, negro, deportivo, 4 puertas, ao 2009.

8.3

Operacin

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

8.4 Asociacin y Enlace


Las entidades, objetos o cosas del mundo real se relacionan con otras entidades; a las relaciones entre objetos se les llama enlaces y a las relaciones entre clases se les llama asociaciones (Rumbaugh, 1996).

65

Mediante la abstraccin de asociacin se vincula dos o ms clases, crendose un elemento de tipo distinto (Vinculo). Por ejemplo, DOCENTE dicta ASIGNATURA, es una asociacin entre la clase DOCENTE y la clase ASIGNATURA. Mientras que Cesar Luza dicta Anlisis de sistemas es un ejemplo de enlace entre los objetos Cesar Luza y Anlisis de sistemas que pertenecen a las clases DOCENTE y ASIGNATURA, respectivamente.

8.5 Generalizacin y Agregacin


La generalizacin y agregacin son dos tipos especiales de relaciones entre clases (Rumbaugh, 1996).. La Generalizacin representa la relacin entre clases, donde algunas de ellas son tipos de otra. Por ejemplo, las clases SECRETARIA, TCNICO, INGENIERO son tipos de la clase EMPLEADO; en otras palabras, EMPLEADO es una generalizacin de las clases SECRETARIA, TECNICO, INGENIERO (ver figura 8.1). Mediante la generalizacin se abstrae las caractersticas comunes a varias clases (subclases) para construir una clase ms general (superclase), la generalizacin define una relacin de subconjunto entre elementos de dos o ms clases. Figura 8.1 Ejemplo de generalizacin GENERALIZACIN
SECRETARIA INGENIERO TECNICO

EMPLEADO

Una Clase ES UN TIPO DE otra

clase
La Agregacin representa la relacin entre clases, donde algunas de ellas son componentes de otra. Por ejemplo, las clases CPU, TECLADO, MOUSE, MONITOR son componentes de la clase COMPUTADORA; en otras palabras, la clase COMPUTADORA est formada por las clases CPU, TECLADO, MOUSE Y MONITOR (figura 8.2). Mediante la agregacin se construye una nueva clase o tipo o categora de objetos a partir de un conjunto de otras clases denominadas componentes o partes. La agregacin define una nueva clase de objetos a partir de un conjunto de clases (otras, no necesariamente distintas) que representan sus partes componente. Figura 8.2 Ejemplo de Agregacin

CPU MONITOR

MOUSE TECLADO

AGREGACIN

COMPUTADOR A
Una Clase ES PARTE DE otra clase

8.6 Qu es el modelo de domino?


El Modelo de dominio es un modelo conceptual que muestra clases conceptuales de objetos significativos en un dominio de problema. Las clases conceptuales no muestran componentes software, ni clases software, ni responsabilidades (Larman, 1999).

66

Por ejemplo, algunas clases conceptuales del dominio de la Gestin Acadmica son: ALUMNO, DOCENTE, ASIGNATURA y HORARIO. El modelo de dominio se puede documentar con un Diagrama de Clases.

8.7 Qu es el diagrama de clases?


Un diagrama de clases es un tipo de diagrama esttico del UML, que describe la estructura de un sistema mostrando sus clases y sus relaciones. En la figura 8.3 se observa un ejemplo de diagrama de clase simplificado para una Tienda de ventas. Se muestra clases conceptuales y relaciones entre ellas; cada clase tiene un nombre y una serie de atributos. Las relaciones se conocen como asociaciones, cada una de ellas tiene un nombre y su multiplicidad. La interpretacin o lectura de un diagrama de clases permite a desarrolladores y usuarios disponer de un lenguaje uniforme para mostrar caractersticas del negocio en el dominio del problema. Por ejemplo, en la figura 8.3, podemos leer la siguiente restriccin semntica: una lnea de venta est contenida en una venta y sta puede contener muchas lneas de venta, nunca ninguna lnea de venta. Adems, cada lnea de venta registra la venta de un articulo y un articulo puede o no estar en una lnea de venta. Figura 8.3 Ejemplo de diagrama de Clases
concepto u objeto del dominio LineaDeVenta cantidad Registra-venta-de 0..1 1 * Almacenado-en 1 Tienda direccin tienda 1 Capturada-en 1 Alberga 1 Artculo

asociacin

1..n Contenida-en

1 atributos Venta fecha hora 1

Pagada-mediante 1 Pago cantidad

1..* Registro

Fuente: (Larman, 1999)

8.8 Notacin UML para modelo de domino Clase


Para efectos del modelo de dominio, una clase puede considerarse en trminos de: Smbolo, palabras o imgenes que representan a la clase; Definicin del concepto, descripcin textual del significado de la clase y Extensin: conjunto de objetos que pertenecen a la clase. Por ejemplo, considere la clase Venta de la figura 8.4. El smbolo del concepto es un rectngulo dividi en tres partes, la primera es el nombre de la clase, la segunda los atributos y la tercera las operaciones. La definicin del concepto es: Una venta representa el hecho de una transaccin de compra, sucede un da y en una hora. La extensin es el conjunto de todas las ventas realizadas en la tienda.

67

Figura 8.4 Clase


Venta fecha hora

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

Asociacin
La asociacin se representa con una lnea que une las clases relacionadas (figura 8.6). En el siguiente ejemplo, se muestra la relacin entre las clases ALUMNO y FACULTAD; la semntica seala que un alumno pertenece a una nica facultad y una facultad tiene muchos alumnos, por lo menos uno.

Figura 8.6 Asociacin

Alumno

1..n

pertenece a

Facultad

En una asociacin se incluye, opcionalmente, el nombre de la asociacin, la navegabilidad, y obligatoriamente, la multiplicidad. La navegabilidad se representa con una flecha que indica la direccin de envo de mensajes de un objeto a otro. La multiplicidad representa la cantidad de objetos de una clase que estn vinculados con un objeto de la clase asociada. Por ejemplo, en la figura 8.6, el nombre de la asociacin es: pertenece a. La multiplicidad de la asociacin es de uno a muchos; significa Un objeto de la clase Alumno est vinculado con un solo objeto de la clase Facultad, y un objeto de Facultad est vinculado con varios objetos de Alumno. La multiplicidad permite representar, en el diagrama de clases, las reglas del negocio definidas en el dominio del problema. Las categoras tpicas de multiplicidad son: Uno a Uno, Uno a Muchos y Muchos a Muchos. En la figura 8.7 se aprecia algunos tipos de multiplicidad.

68

Figura 8.7 Tipos de multiplicidad


1 Dirige 1

Decano "Uno a Uno" Aula 1

Facultad

Tiene Instalado 0..1

Proyector

"Uno a Muchos"

Carrera

Tiene

0..n

Convenio

Laboratorio

Tiene

1..n

Computadoras

"Muchos a Muchos" Alumno

1..n Matriculado En 1..n

Asignatura

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, significa que un alumno puede llevar varias asignaturas y una asignatura es llevada por varios alumnos; y la nota promedio de un alumno en una asignatura corresponde a la asociacin; pues si se coloca como atributo de alumno, no se sabra de qu asignatura es; si se coloca como atributo de asignatura, no se sabra de qu alumno es, entonces, se crea una clase especial llamada clase asociacin MATRICULA en el que se coloca el atributo nota promedio. 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

69

Generalizacin
La generalizacin se representa a travs de una lnea recta entre las clases subtipos terminados en un tringulo blanco en el extremo cercano a la clase generalizada. Por ejemplo, en la figura 8.9, ANFIBIO, MAMFERO y REPTIL son tipos de ANIMAL. A su vez, CABALLO es un tipo de MAMFERO. La Generalizacin puede encontrarse en aquellas clases que tienen ciertos atributos y operaciones en comn. En ese caso se crea una clase nueva que asume dicho comportamiento comn.

Figura 8.9 Ejemplo de Generalizacin

Agregacin
La agregacin se representa a travs de una lnea recta entre las clases partes terminados en un rombo en el extremo cercano a la clase todo. Por ejemplo, en la figura 8.10, MONITOR, CASES, TECLADO y MOUSE son partes o componentes de COMPUTADORA. A su vez, CASES est formado por CPU, RAM,VENTILADOR. Figura 8.10 Ejemplo de Agregacin

70

Leccin 9 Proceso de construccin del modelo de dominio


Para construir el modelo de dominio se puede seguir las siguientes actividades: Identificar las Clases conceptuales o del dominio, Identificar las asociaciones, Identificar atributos, Identificar relacin de generalizacin y refinar el modelo. Consideremos la siguiente descripcin para realizar el modelo de dominio. Una empresa recin formada se dedica a integrar partes para formar productos con la intencin de vender el valor agregado de la integracin. Con el objetivo de apoyar sus actividades, mediante una aplicacin informtica, se ha obtenido las siguientes reglas semnticas: Un producto tiene un nombre y un precio base. Un producto se forma con muchas partes y cada parte puede formar muchos productos. La definicin de cada producto especifica qu cantidad de cada parte forma a un producto dado. Un vendedor tiene un apellido, nombre y un porcentual de comisin. Tanto un cliente como un proveedor tienen los datos de todo agente comercial; stos son: cuit, razn social, e-mail, telfono y direccin. Adems, un proveedor tiene un plazo de pago y un cliente un porcentual de descuento. Un parte puede ser comprado a muchos proveedores y un proveedor puede proveer muchas partes. Cada compra de un parte tiene una fecha y una cantidad. Una venta se realiza entre cualquier vendedor y cualquier cliente, y ste puede comprar cualquier producto. De una venta se quiere saber su fecha. No se pueden vender productos que estn formados por una nica parte, esto es, no se permite vender productos sin elaborar. 9.1 Identificando Clases Muchos de las clases del dominio pueden obtenerse de una especificacin de requisitos o mediante la entrevista con los expertos del dominio. Las clases del dominio aparecen en tres formas distintas (Jacobson, 2000): Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas, contratos, y facturas. Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento, como la aviacin enemiga, misiles y trayectorias. Sucesos que ocurrirn o han ocurrido, como la llegada de un avin, sus salidas y la hora de la comida. Otra estrategia es seleccionar los nombres o sustantivos de la descripcin del problema como posibles clases candidatas. Se construye una lista de clases candidatas. Se eliminan, de esa lista, las clases redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o construcciones de implementacin. En nuestro ejemplo las clases conceptuales identificadas son:
producto

parte

vendedor

cliente

proveedor

agenteComercial

71

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 1..n se vende agenteComercial 1..n se forma 1..n parte 1..n

Se compra

1..n cliente 1..n proveedor

9.3 Identificando Atributos Por cada clase se indican los atributos necesarios que respondan a los requerimientos del dominio del problema. Si los atributos corresponden a una asociacin, crear una clase asociacin. En nuestro ejemplo, se sealan los atributos por cada clase y adicionalmente, se identifican atributos para las algunas asociaciones, crendose las clases asociacin: definicin, compra y venta.

72

9.4 Identificando relaciones de generalizacin Se organiza y simplifica el modelo usando el principio de herencia; es decir, se puede generalizar los aspectos comunes de las clases existentes construyendo una superclase, o se puede especializar una clase en varias subclases. Para nuestro ejemplo se establece relacin de generalizacin entre agente comercia con cliente y proveedor:

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

73

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

74

Lectura
Desarrollo de un modelo de dominio (*) El modelado de dominio se realiza habitualmente en reuniones organizadas por los analistas del dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. Para formar un equipo eficaz, estas reuniones deberan incluir tanto a expertos del dominio como a gente con experiencia en modelado. El objetivo del modelado del dominio es comprender y describir las clases ms importantes dentro del contexto del sistema. Los dominios de tamao moderado normalmente requieren entre 10 y 50 de esas clases. Los dominios ms grandes pueden requerir muchas ms. Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se guardan como definiciones en un glosario de trminos, de otra manera, el modelo de dominio se har demasiado grande y requerira ms esfuerzo del necesario para esta parte del proceso. Algunas veces, como en los dominios del negocio muy pequeos, no es necesario desarrollar un modelo de objetos para el dominios; en su lugar, puede ser suficiente un glosario de trminos. El glosario y el modelo de dominio ayudan a los usuarios, clientes, desarrolladores, y otros interesados a utilizar un vocabulario comn. La terminologa comn es necesaria para compartir el conocimiento con los otros. Cuando abunda la confusin, el proceso de ingeniera se hace difcil, si no imposible. Para construir un sistema software de cualquier tamao, los ingenieros de hoy en da deben fundir el lenguaje de todos los participantes en uno solo consistente. Por ltimo, es necesario una llamada de atencin sobre el modelo de dominio. Puede ser bastante fcil el comenzar modelando las partes internas de un sistema y no su contexto. Por ejemplo, algunos objetos del dominio podran tener una representacin inmediata en el sistema, y algunos analistas del dominio podran a su vez caer en la trampa de especificar los detalles relativos a esta representacin. En casos como stos, es muy importante recordar que el objetivo del modelado del dominio es contribuir a la comprensin del contexto del sistema, y por lo tanto tambin contribuir a la comprensin de los requisitos del sistema que se desprenden de este contexto. En otras palabras, el modelado del dominio debera contribuir a una compresin del problema que se supone que el sistema resuelve en relacin a su contexto. El modo interno por el cual el sistema resuelve ste problema se trata en los siguientes flujos de anlisis, diseo e implementacin.

(*) Jacobson (2000, pp. 114-115)

75

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.

76

Autoevaluacin
1. Entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn corresponda: a. ( ) Un objeto define un conjunto de clases con las mismas caractersticas b. ( ) Pedro, Juan y Mara son ejemplos de objetos de la clase Persona c. ( ) Tcnico, Obrero, Empleado son objetos de la clase PERSONAL d. ( ) Una asociacin es una relacin entre clases e. ( ) Una clase conceptual incluye elementos software En relacin al Modelo de Dominio, en la celda a la derecha del Termino coloque la letra de la Definicin o Caracterstica que le corresponda:
Trmino 1. Clase 2. Atributo 3. Asociacin 4. Multiplicidad 5. Clase asociacin 6. Generalizacin 7. Agregacin Definicin o Caractersticas del Termino A. Representa una caracterstica o propiedad de una clase B. Cantidad de objetos de una clase vinculados con un objeto de clase asociada C. Representa atributos propios de la asociacin D. Representa un conjunto de objetos con las mismas caractersticas E. Representa relacin entre clase, algunas de ellas son tipos de otra F. Representa relacin entre clases, algunas de ellas son componentes de otra G. Representa vinculo entre dos o ms clases

2.

Respuestas de Control
1. 2. a = F, b = V, c = F, d = V, e = F 1 = D, 2 = A, 3 = G, 4 = B, 5 = C, 6 = E, 7 = F

Exploracin on-line
Portal del producto IBM Rational Modeler http://www-01.ibm.com/software/awdtools/modeler/ Pagina de Craig larman http://www.craiglarman.com/wiki/index.php?title=Main_Page

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.

77

QUINTA UNIDAD EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO

Qu es un requerimiento?, Cmo se clasifican? Qu es un modelo de casos de uso?Cules son sus elementos? Cmo se construye un modelo de casos de uso?

PROPOSITOS
Al finalizar esta unidad, el estudiante: Explica el concepto de requerimiento y su clasificacin Explica las caractersticas y elementos del modelo de casos de uso del UML Elabora modelos de caso de uso usando el UML.

78

Leccin 10 Conceptos asociados los requerimientos


La importancia de la definicin, especificacin, anlisis y administracin de requerimientos en un proyecto de desarrollo de software es ampliamente reconocida; pues permite establecer las funcionalidades que deber tener el producto software a desarrollar, que correspondan con las necesidades del cliente/usuario; asimismo, sirve de base para la planificacin del proyecto y para verificar si el producto software es de calidad. Muchos proyectos fracasan por una mala definicin, especificacin, analisis y administracin de requerimientos; la experiencia ha demostrado que las actividades relacionadas con los requerimientos son complejas debido a la poca participacin de los usuarios, al uso de lenguajes distintos entre desarrolladores y usuarios, a los cambios de requerimientos, entre otras razones. Por ello, es importante para el profesional involucrado en proyectos de desarrollo de software poseer las suficientes competencias para la definicin, especificacin, anlisis y administracin de los requerimientos a fin de afrontar con xito estas tareas. En esta leccin se define y caracteriza el concepto de requerimientos y se describen tcnicas para la captura de los mismos.

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

10.2 Tipos de Requerimientos


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

10.2.1 Requerimiento Funcional


Un Requerimiento funcional es un requerimiento que especifica una accin que debe ser capaz de realizar el sistema, sin considerar restricciones fsicas; es un requisito que especifica comportamiento de entrada / salida del sistema (Jacobson, 2000). El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su entorno. En otras palabras, refleja las necesidades de los usuarios o la interaccin con otros sistemas. Por ejemplo, los usuarios de un Sistema de Gestin Acadmica para la Universidad pueden ser profesores y alumnos, algunos requerimientos funcionales son: El sistema permitir a los profesores: Consultar los horarios de sus asignaturas,

79

Consultar la programacin de los exmenes, Actualizar y ver su informacin personal, Registrar y modificar las notas de los estudiantes a su cargo,

El sistema permitir a los estudiantes: Consultar los horarios de sus asignaturas, Consultar la programacin de los exmenes, Actualizar y ver su informacin personal, Consultar notas de una asignatura.

10.2.2 Requerimiento No funcional


Un Requerimiento No funcional es un requerimiento que especifica propiedades del sistema, como restricciones del entorno o de implementacin, rendimiento, dependencia de la plataforma, mantenibilidad, extensibilidad o fiabilidad; especifica restricciones fsicas sobre un requisito funcional (Jacobson, 2000). Un requerimiento no funcional describe atributos del sistema o del ambiente en donde ste se desarrolla. Algunos ejemplos de requerimientos no funcionales son: 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%.

10.3 Clasificacin de Requerimientos: Modelo FURPS


Una manera de categorizar los requerimientos est descrita en el modelo FURPS (Larman, 2002), los requerimientos se clasifican en requerimientos de: Functionality (Funcionalidad), Usability (Capacidad de Uso), Reliability (Fiabilidad), Performance (Desempeo) y Supportability (Capacidad de Soporte). Los Requerimientos de Funcionabilidad (Functionality) son aquellos requerimientos que reflejan las caractersticas fundamentales (requerimiento funcional o funcionalidades del sistema), adems de capacidades y seguridad. Los requerimientos de usabilidad o Capacidad de Uso (Usability), son aquellos requerimientos que representan facilidad o nivel de uso del producto; es decir, el grado en el que el diseo de un elemento facilita o dificulta su manejo. Se incluyen: Factores humanos, Esttica, Consistencia de la interfaz de usuario, Ayudas en lnea, Agentes y wizards, Documentacin de usuario y material de entrenamiento. Por ejemplo, Visibilidad del texto a una cierta distancia y Combinacin de colores del texto. Los requerimientos de Fiabilidad (Reliability, son aquellos que muestran la capacidad de un sistema o componente para ejecutar las funciones requeridas bajo condiciones normales en un periodo de tiempo especifico. Tiene las siguientes sub-categoras: Disponibilidad (el porcentaje de tiempo disponible, horas de uso, acceso para mantenimiento, etc.); Tiempo medio entre fallas; Tiempo medio para reparacin, cunto tiempo es posible que el sistema est inoperante despus que falla; Exactitud (precisin y exactitud, segn algn estndar conocido) que se requiere para las salidas del sistema; Cantidad mxima de errores o porcentaje de defectos, generalmente expresado en trminos de errores por miles de lneas de cdigo o errores por punto funcional;

80

Errores o porcentaje de defecto, categorizados en trminos de errores menores, significantes y crticos (se debe definir que significa error crtico, por ejemplo prdida completa de dato o imposibilidad de uso de ciertas funcionalidades del sistema. Los requerimientos de Desempeo (Performance), se refieren a las caractersticas de rendimiento del sistema. Incluye tiempos de respuesta especficos. Por ejemplo: Tiempo de respuesta para una transaccin (promedio, mximo); Transacciones por segundo; Capacidad, como por ejemplo el nmero de clientes o transacciones que el sistema puede soportar; Modos de degradacin, esto es, cual es el modo aceptable de funcionamiento cuando el sistema ha sido degradado de alguna manera; Utilizacin de recursos: memoria, disco, comunicaciones, etc. Los requerimientos de Capacidad de Soporte (Supportability), son requerimientos que refuerzan el soporte y mantenimiento del sistema que est siendo construido, incluyendo normas de codificacin, convenciones de nombres, libreras, acceso para mantenimiento, utilidades de mantenimiento si las hay. Como requerimiento que ayuda al mantenimiento se debe hacer referencia al uso de nomenclatura comn para el desarrollo del sistema, y a la metodologa de desarrollo.

ALGUNOS REQUERIMIENTOS FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA FACULTAD DE INGENIERIA DE SISTEMAS, CMPUTO Y TELECOMUNICACIONES El sistema permitir al secretario acadmico, introducir las asignaturas que se imparten en el semestre acadmico, los datos del docente asignado a cada seccin, de teora y prctica, de la asignatura, los datos de las aulas de teora (ubicacin y aforo) y de prcticas (ubicacin, sistemas operativos, software,...). La configuracin del horario se lleva a cabo directamente sobre una plantilla horaria semanal, en la que cada casilla representar una hora en un determinado da de la semana. Cuando el Secretario pulsa esa casilla se mostrarn las asignaturas del curso que se est configurando en ese momento. Una vez escogida las asignaturas se mostrarn las secciones de teora y prctica a los que todava no se les ha asignado un horario. Al escoger una seccin se muestran las aulas disponibles (si es un grupo de teora) o los laboratorios que cumplen las restricciones de sistemas operativos establecidas para esa materia y que no estn ocupados a esa hora. El sistema podr ser consultado por cualquier usuario, que podr consultar el horario 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.

10.4 Caractersticas de los Requerimientos


Un requerimiento debe ser: Especificado por escrito, como todo contrato o acuerdo entre dos partes. Posible de probar o verificar, si un requerimiento no se puede comprobar, entonces, cmo se sabe si se cumpli con l o no? Conciso, un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en el futuro.

81

Completo, un requerimiento esta completo si no es necesario ampliar detalles en su redaccin, es decir si se proporciona la informacin suficiente para su comprensin. Consistente, un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo, un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusin en el lector.

10.5 Dificultades para definir los Requerimientos


Los requerimientos no son obvios y vienen de muchas fuentes Son difciles de expresar en palabras (el lenguaje es ambiguo) La cantidad de requerimientos en un proyecto puede ser difcil de manejar Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. El usuario no puede explicar lo que hace. El usuario tiende a recordar lo excepcional y olvidar lo rutinario Hablan de lo que no funciona Los usuarios tiene distinto vocabulario que los desarrolladores Usan el mismo termino con distinto significado

10.6 Tcnicas para obtener Requerimiento 10.6.1 Entrevistas


Esta tcnica es adecuada para la primera toma de contacto. Es conveniente comenzar por preguntas de contexto libre, para entender: el problema, a las personas interesadas en la solucin, naturaleza de sta, y lograr efectividad de la reunin. Ejemplos de preguntas centradas en el cliente, los objetivos globales y beneficios Quin solicita el trabajo? Quin utilizar la solucin? Cul ser el beneficio econmico de una buena solucin? Existen otras alternativas a esta solucin?

Ejemplos de preguntas sobre el problema y la solucin Qu entiende el cliente por una solucin correcta? Qu problemas afrontar esta solucin? En qu entorno se va a implantar la solucin? Existen restricciones o aspectos de rendimiento importantes?

Ejemplo de preguntas sobre la efectividad de la reunin Es usted la persona adecuada para responder a estas preguntas? Sus respuestas son oficiales? Son relevantes mis preguntas para su problema? Hay alguien ms que pueda proporcionar informacin adicional? Hay algo ms que debera preguntar?

82

Problemas de las entrevistas: Pueden surgir malentendidos Omisin de informacin Mala relacin de trabajo (nosotros-ellos)

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

83

Leccin 11 Conceptos asociados al Modelo de casos de uso


Se han establecido diversas tcnicas para la especificacin de requerimientos. La tcnica de casos de uso (Jacobson, 1993) se ha constituido en el estndar universal para capturar requerimientos de sistemas software. Los casos de uso no solo sirven para captura requerimientos de sistemas software, sino que tienen gran influencia sobre todas las fases del proceso de desarrollo.

11.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 est 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, 1993). La figura 11.2 muestra la notacin UML de caso de uso. Por ejemplo, consideremos el siguiente escenario para realizar el Retiro de Dinero de un Cajero Automtico: Escenario Normal 1. 2. 3. 4. 5. 6. 7. 8. 9. E cliente inserta su tarjeta en la ranura del cajero automtico El cajero automtico solicita ingreso de clave secreta El cliente ingresa su clave secreta El cajero automtico muestra men de opciones El cliente selecciona opcin Retiro El cajero automtico muestra relacin de cuentas del cliente El cliente elige cuenta El cajero automtico solicita cantidad El cliente ingresa cantidad a retirar

84

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. 2. 3. 4. 5. 6. 7. 8. 9. 10. E cliente inserta su tarjeta en la ranura del cajero automtico El cajero automtico solicita ingreso de clave secreta El cliente ingresa su clave secreta El cajero automtico muestra men de opciones El cliente selecciona opcin Retiro El cajero automtico muestra relacin de cuentas del cliente El cliente elige cuenta El cajero automtico solicita cantidad El cliente ingresa cantidad a retirar El cajero automtico muestra mensaje de error Saldo Insuficiente.

Podemos decir que este conjunto de escenarios corresponde al caso de uso Retiro de Cajero Automtico. En conclusin, un caso de uso proporciona uno o ms escenarios que indican cmo debe interactuar el usuario con el sistema para conseguir un objetivo particular.
Figura 11.2 Caso de uso

11.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 Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se inicie, se definen relativas al sistema no a su entorno, deben ser estados observables por el actor. Establecen lo que siempre debe cumplirse antes de comenzar un escenario en un caso de uso. Normalmente implica que un escenario de otro caso de uso se ha completado exitosamente. 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

85

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

86

Consultar notas de un curso Estudiante Consultar horarios de cursos


(f rom Actors)

Mantener informacin del estudiante Validar acceso Usuario


(f rom Actors)

Cerrar un curso

Mantener informacin del profesor

Consultar horario de exmenes Profesor


(f rom Actors)

Registrar notas de un curso

87

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

Gerente

Empleado de ventas

12.2

Identificando casos de uso

Para identificar casos de uso se sugiere preguntar: Cules son las tareas que realiza el actor?, Que objetivos concretos necesita alcanzar un actor?, Puede el actor crear, almacenar, remover o leer informacin en el sistema?, El actor, necesita estar informado acerca de las ocurrencias del sistema?. Las respuestas a estas preguntas reflejan funcionalidades del sistema para cada actor.

88

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

Registrar vuelo de carga

Registrar vuelo de pasajeros

Mantener informacino de pilotos

Consultar vuelos por pilotos

Mantener informacion de pasajeros

Registrar reservas de vuelo

Registrar confirmacin de vuelo

Consultar pasajeros que tommaron vuelo

12.3

Elaborando la descripcin de casos de uso solo desarrollaremos

Para cada caso de uso se elabora su descripcin. En nuestro caso, descripcin de algunos casos de uso.
Nombre C.U.S. Actor Precondicin Poscondicin

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. 2. 3. 4. 5. 6. 7. 8.

El caso de uso se inicia cuando el Gerente indica Vuelos Realizados. El Sistema muestra relacin de pilotos. El Gerente escoge el nombre de piloto de la relacin mostrada. El Sistema muestra calendario para escoger el periodo (fecha inicio y fecha de fin) El Gerente escoge el periodo (fecha inicio y fecha de fin). El Gerente indica Aceptar. El Sistema muestra los vuelos realizados por el piloto en el periodo escogido. El caso de uso finaliza. Flujos Alternativos

Imprimir En el paso 7, si el gerente indica Imprimir, el sistema imprime la informacin consultada y el caso de uso finaliza. No hay vuelos en periodo En el paso 7, si no existen vuelos del piloto en el periodo seleccionado, el sistema muestra mensaje Piloto no tiene registrado vuelos en el periodo y regresa a seleccionar otro piloto.

89

Nombre C.U.S. Actor Precondicin Poscondicin

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

90

12.4

Elaborando el diagrama de casos de uso

Se asocia cada actor con su caso de uso, obtenindose el siguiente diagrama de casos de uso

Registrar vuelo de carga Encargado de vuelos Mantener informacin de unidades

Registrar vuelo de pasajeros

Consultar vuelos por pilotos Gerente Mantener informacin de pilotos

Mantener informacion de pasajeros Registrar reservas de vuelo Empleado de ventas

Registrar confirmacin de vuelo

Consultar pasajeros que tommaron vuelo

91

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

92

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, pp. 153-154).

93

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.

94

Autoevaluacin
1. En la celda a la derecha del Termino coloque la letra de la Definicin o Caracterstica que le corresponda:
Trmino 1. Requerimiento 2. Req. Funcional 3. Req. No Funcional 4. Usabilidad 5. Entrevista 6. JAD 7. Actor 8. Caso de uso 9. Precondicin 10. Flujo bsico Definicin o Caractersticas del Termino A. Requerimiento que especifica propiedades del sistema B. Tcnica adecuada en primera toma de contacto para obtener requerimiento C. Sesin de trabajo con participacin de todos los involucrados D. Condicin o capacidad a la que debe ajustarse el sistema que se construye F. Conjunto coherente de roles que usuarios del sistema pueden jugar G. Conjunto de escenarios, secuencia de acciones entre actor y sistema H. Restriccin que debe cumplirse para que se inicie un caso de uso I. Requerimiento que especifica comportamiento de entrada / salida del sistema J. Se considera los pasos normales, no incluye alternativas o variaciones K. Requerimiento que representa facilidad de uso del producto

Respuestas de Control
1. 1 = D, 2 = I , 3 = A , 4 = K, 5 = B, 6 = C, 7 = F, 8 = G , 9 = H , 10 = J

Exploracin on-line
Sitio de Alistair Cockburn, sobre recursos e informacin de casos de uso http://alistair.cockburn.us/

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.

95

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.

96

BIBLIOGRAFIA
1 2 3 4 Davenport, Thomas (1996). Innovacin de Procesos: Reingeniera del trabajo a travs de la tecnologa de la informacin. Espaa. Daz Santos. Hammer, Michel y James Champy (1995), Reingeniera. Bogot. Grupo Editorial Norma.. Harris, David (1996). Creating a Knowledge Centric Information Technology Environment. USA. Editorial Harris Training & Consulting Services Inc. IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology Description. http://standards.ieee.org/reading/ieee/std_public/description/se/610.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.

5 6 7 8 9

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.

97