Libro de analisis de sistemas_UNMSM.pdf

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA

CARRERA PROFESIONAL DE INGENIERIA DE SISTEMAS

ANÁLISIS DE SISTEMAS

CÉSAR LUZA MONTERO

LIMA-PERÚ, 2012

2

ÍNDICE PRESENTACIÓN ........................................................................................................................................................ 6 INTRODUCCIÓN ....................................................................................................................................................... 7 ORIENTACIONES METODOLÓGICAS ........................................................................................................................ 9 PRIMERA UNIDAD .................................................................................................................................................. 10 LOS SISTEMAS DE INFORMACIÓN EN LAS ORGANIZACIONES ............................................................................... 10

Lección 1 ........................................................................................................................................................... 11 Organización y procesos de negocios ............................................................................................................... 11

1.1 Organización .................................................................................................................................... 11 1.1.1 ¿Qué es una organización? ......................................................................................................... 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 ¿Cómo se describe un proceso de negocio? ............................................................................... 16

Lección 2 ........................................................................................................................................................... 18 Introducción a los Sistemas de información ..................................................................................................... 18

2.1 Concepto de Dato, Información y Conocimiento ............................................................................ 18 2.2 ¿Qué es Sistema de información? ................................................................................................... 19 2.3 Componentes de un Sistema de información ................................................................................. 20 2.4 Tipos de sistemas de información ................................................................................................... 20

Resumen ........................................................................................................................................................... 22 Lectura .............................................................................................................................................................. 23 Actividades ....................................................................................................................................................... 24 Autoevaluación ................................................................................................................................................. 24 Exploración on-line ........................................................................................................................................... 25 Referencias bibliográficas ................................................................................................................................. 25

SEGUNDA UNIDAD ................................................................................................................................................ 26 EL PROCESO DE DESARROLLO, RUP Y UML ........................................................................................................... 26

Lección 3 ........................................................................................................................................................... 27 Proceso de desarrollo de sistemas de información .......................................................................................... 27

3.1 Proceso de desarrollo, una visión genérica ..................................................................................... 27 3.1.1 ¿Qué es un proceso de desarrollo? ............................................................................................. 27 3.1.2 Fase de Definición ....................................................................................................................... 27 3.1.3 Fase de Desarrollo ....................................................................................................................... 28 3.1.4 Fase de Evolución ........................................................................................................................ 28 3.2 Modelos de Proceso de desarrollo de software .............................................................................. 28 3.2.1 Modelo Lineal Secuencial ............................................................................................................ 29 3.2.2 Modelo Construcción de Prototipos ........................................................................................... 29 3.2.3 Modelo Desarrollo Rápido de Aplicaciones (DRA) ...................................................................... 30 3.2.4 Modelo Incremental .................................................................................................................... 31 3.2.5 Modelo Espiral ............................................................................................................................ 32 3.3 Metodologías ................................................................................................................................... 33 3.3.1 RUP .............................................................................................................................................. 33 3.3.2 MÉTRICA V3 ................................................................................................................................. 34 3.3.3 Merisse ........................................................................................................................................ 34 3.3.4 SSADM V4 .................................................................................................................................... 34 3.3.5 MDSI ............................................................................................................................................ 35

Lección 4 ........................................................................................................................................................... 36 Introducción 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

3

Lección 5 ........................................................................................................................................................... 40 Introducción 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 Elaboración .................................................................................................................... 41 5.3.3 Fase de Construcción .................................................................................................................. 41 5.3.4 Fase de Transición ....................................................................................................................... 42 5.4 Flujos................................................................................................................................................ 42


TERCERA UNIDAD .................................................................................................................................................. 49 EL MODELADO DE NEGOCIOS ............................................................................................................................... 49

Lección 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 Análisis del Negocio ...................................................................................................... 51 6.3.1 Trabajador del negocio ............................................................................................................... 51 6.3.2 Entidad del negocio ..................................................................................................................... 52 6.3.3 Realización de caso de uso del negocio ...................................................................................... 52

Lección 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 análisis 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


CUARTA UNIDAD ................................................................................................................................................... 64 EL MODELADO DE DOMINIO ................................................................................................................................. 64

Lección 8 ........................................................................................................................................................... 65 Conceptos asociados al modelo de dominio .................................................................................................... 65

8.1 Clase y Objeto .................................................................................................................................. 65

4

8.2 Atributo ........................................................................................................................................... 65 8.3 Operación ........................................................................................................................................ 65 8.4 Asociación y Enlace .......................................................................................................................... 65 8.5 Generalización y Agregación ........................................................................................................... 66 8.6 ¿Qué es el modelo de domino? ....................................................................................................... 66 8.7 ¿Qué es el diagrama de clases? ....................................................................................................... 67 8.8 Notación UML para modelo de domino .......................................................................................... 67

Lección 9 ........................................................................................................................................................... 71 Proceso de construcción 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 generalización ..................................................................................... 73 9.5 Refinando el modelo ....................................................................................................................... 73


QUINTA UNIDAD .................................................................................................................................................... 78 EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO ....................................................................................... 78 Lección 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 Clasificación de Requerimientos: Modelo FURPS ................................................................................ 80 10.4 Características de los Requerimientos ................................................................................................. 81 10.5 Dificultades para definir los Requerimientos ....................................................................................... 82 10.6 Técnicas para obtener Requerimiento ................................................................................................. 82

10.6.1 Entrevistas ................................................................................................................................... 82 10.6.2 JAD ............................................................................................................................................... 83

Lección 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 Descripción de caso de uso .................................................................................................................. 85 11.5 Diagrama de casos de uso .................................................................................................................... 86 Lección 12 ......................................................................................................................................................... 88 Lección 12 ......................................................................................................................................................... 88 Proceso de construcción 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 descripción de casos de uso ..................................................................................... 89 12.4 Elaborando el diagrama de casos de uso ........................................................................................ 91

Resumen ........................................................................................................................................................... 92 Lectura .............................................................................................................................................................. 93 Actividades ....................................................................................................................................................... 94 Autoevaluación ................................................................................................................................................. 95 Exploración on-line ........................................................................................................................................... 95 Referencias bibliográficas ................................................................................................................................. 95 GLOSARIO ......................................................................................................................................................... 96 BIBLIOGRAFIA ................................................................................................................................................... 97

6

PRESENTACIÓN

7

INTRODUCCIÓN

Las organizaciones están considerando el tema de los Sistemas de Información como factor clave para lograr competitividad. Se están realizando grandes inversiones para su construcción e implantación, de manera eficiente, efectiva y con niveles de calidad pertinentes.

Los sistemas de información, conjunto de componentes software, hardware, base de datos, procedimientos y personal, proveen la información, requerida por las organizaciones para apoyar las actividades de toma de decisión y controlar las operaciones del día a día. Esta información debe transmitirse a todos los niveles de la organización, de manera oportuna y confiable.

El proceso de construcción e implantación de sistemas de información implica esfuerzo conjunto de desarrolladores y clientes-usuarios, quienes realizan una serie de actividades, agrupadas en fases, conocida como “Proceso de desarrollo”, conducente a obtener un sistema de calidad que satisfaga las necesidades de información de los clientes-usuarios.

En general, las primeras actividades del proceso de desarrollo están relacionadas con el análisis de sistemas y la especificación de requerimientos del software. El propósito del análisis de sistemas es definir el papel de cada componente del sistema de información y asignar al software el ámbito que le corresponde desempeñar. Durante la actividad de especificación de requerimientos del software, se detalla el ámbito de funcionalidad del software, de tal manera que cubra la totalidad de necesidades de los usuarios.

La literatura especializada establece que el éxito de un proyecto de desarrollo de sistemas depende, en gran medida, de realizar bien el análisis de sistemas y especificación de requerimientos del software; por lo que es de gran relevancia, para la formación de profesionales del campo de desarrollo de Sistemas de Información, el dominio de métodos, técnicas y herramientas que permitan afrontar con éxito estas actividades.

Precisamente, este libro tiene el propósito de promover y consolidar, en el estudiante, el uso de métodos, técnicas y herramientas para el análisis de sistemas y especificación de requerimientos de software. Se enfatiza en el componente software del sistema de información, se utiliza la notación del lenguaje de modelado unificado (UML) y se sigue el proceso de desarrollo unificado (RUP). En otras palabras, para el análisis de sistemas se desarrolla el flujo de modelado del negocio, y para la especificación de requerimientos, se sigue el flujo de requerimientos que permitirá capturar sistemáticamente los requerimientos usando la técnica de casos de uso del UML.

Los contenidos de este libro se han organizado en cinco unidades temáticas. Éstas se desarrollan en lecciones que incluyen apartados, esquemas y figuras, según cuál sea la necesidad didáctica. Cada unidad consta también de un conjunto de actividades y de evaluación orientados a afianzar el aprendizaje del estudiante y a valorar sus logros.

La primera unidad tiene como propósito que el estudiante comprenda y explique la importancia de los sistemas de información en las organizaciones, definiendo con precisión los conceptos relacionados a la organización, proceso de negocio, datos, información, conocimiento y sistemas de información; valorando la importancia de estos conceptos en el contexto del análisis de sistemas de información.

La segunda unidad comprende los temas relacionados con el proceso de desarrollo de sistemas de información, sus fases y actividades genéricas; muestra los diversos modelos de proceso de desarrollo y las metodologías más conocidas, y brinda una introducción al UML y al RUP.

La tercera unidad ayuda, al estudiante, en el desarrollo de habilidades para la construcción de modelos de negocio. Los artefactos que se elaboran sirven de base para la determinación de

8

requerimientos del sistema. Se utiliza notación UML siguiendo las actividades proporcionadas por el RUP.

La cuarta unidad tiene por finalidad que el estudiante desarrolle habilidades para representar modelos de dominio, mediante la construcción de diagrama de clases de UML. De esta manera, complementa los artefactos del modelo de negocios con una representación de los conceptos o entidades que se manejan en el contexto del negocio o dominio de la aplicación que cubra las necesidades y requerimientos de los usuarios-clientes.

La quinta unidad permite que el estudiante desarrolle habilidades para la especificación de requerimiento usando el modelo de casos de uso del UML. Se tratan, con precisión, los conceptos de requerimientos funcionales y no funcionales, y se elaboran, con claridad los artefactos del modelo de casos de uso: actores, casos de uso, descripción de casos de uso y diagrama de casos de uso.

En todo el libro, las figuras o tablas que no consignan fuente, corresponden a elaboración propia. Las figuras o tablas que no consignan número, representa continuación del texto donde están ubicados.

El autor.

9

ORIENTACIONES METODOLÓGICAS

La asignatura de Análisis de Sistemas es de formación profesional especializada, de naturaleza teórica-practica. Tiene como propósito que el estudiante maneje, adecuadamente, los métodos, técnicas y herramientas para el análisis y especificación de requerimientos de software como componente de un sistema de información.

Para este fin, se desarrollan las siguientes unidades temáticas: Los Sistemas de Información en las Organizaciones, El Proceso de desarrollo con RUP y UML, El Modelado del Negocio, El Modelado de Dominio, y Requerimientos con casos de uso.

Al inicio de cada unidad temática, el estudiante dispone de una serie de preguntas que permitirá valorar sus logros. Al finalizar la unidad, se brinda un resumen del contenido temático, una lectura seleccionada de un tema de interés relacionado con el contenido temático de la unidad, una serie de actividades que el estudiante debe realizar, una autoevaluación que mide el aprendizaje del estudiante, una serie de direcciones Internet para exploración online.

Es fundamental, para el proceso de 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 información. El docente, dispondrá de un horario que permita interactuar con los estudiantes para absolver consultas o dudas, a través de Internet.

En lo que respecta a la evaluación del aprendizaje, al final de cada unidad temática se dispone de una serie de preguntas de autoevaluación que permite al estudiante medir sus logros de aprendizaje conceptual. Además, se presenta una serie de casos que el estudiante desarrollará y que permitirá al docente medir los logros de aprendizaje procedimental.

10

PRIMERA UNIDAD

LOS SISTEMAS DE INFORMACIÓN EN LAS ORGANIZACIONES

¿Qué es una organización, como se estructuran sus actividades, cuáles son sus niveles? ¿Qué son los procesos de negocios, como se clasifican? ¿Cuál es la diferencia entre dato, información y conocimiento? ¿Qué es un sistema de información, cuáles son sus componentes, como se clasifican?

PROPOSITOS Al finalizar esta unidad, el estudiante:

Explica los conceptos y principios asociados a una organización y a la forma de estructurar sus actividades

Comprende las característica de los procesos de negocio y su clasificación

Explica la diferencia entre dato, información y conocimiento

Explica la importancia de los sistemas de información en las organizaciones, sus elementos y su clasificación

11

Lección 1

Organización y procesos de negocios

Los profesionales responsables de automatizar las actividades de una organización deben comprender sus procesos de negocio a fin de identificar aquellas actividades manuales que serán reemplazas por sistemas software.

En esta lección se revisa aspectos básicos de una organización y del enfoque basado en procesos de negocios.

1.1 Organización

1.1.1 ¿Qué es una organización?

Según el Diccionario de la Real Academia de la Lengua, una organización es una asociación de personas reguladas por un conjunto de normas en función de determinados fines.

Se puede considerar que una organización es un sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas de alguna forma (generalmente en departamentos o funciones) con arreglo a ciertas reglas de división del trabajo y comunicación que interactúan para producir bienes o servicios (Figura 1.1).

Figura 1.1 Componentes de una organización

Fuente: Elaboración propia1

Las personas representan el recurso más importante de la organización, juegan distintos roles o responsabilidades cuando realizan las diversas actividades requeridas para cumplir los objetivos de la organización.

Las actividades o tareas son las acciones que en conjunto transforman las entradas en bienes o servicios, se distinguen actividades operativas (realizadas por los obreros o empleados) y actividades de toma de decisión (realizadas por los gerentes).

Los recursos pueden ser dinero, materiales, maquinaria, infraestructura, tecnología que sirven de soporte para realizar las actividades.

Las reglas están dadas por las políticas, normas y procedimientos que rigen el desarrollo de las actividades y uso de los recursos.

1 En lo sucesivo, en este libro, si las figuras, imágenes o tablas no consignan fuente, son de elaboración propia..

ACTIVIDADES

Reglas

Personas/Recursos

Bienes/Servicios Entradas

12

1.1.2 Estructura organizacional

La estructura organizacional representa la forma en que las personas, actividades y recursos se organizan según ciertas reglas.

Se han establecido diversos modelos o enfoques para la estructura de una organización; sin embargo, para el propósito de este texto se pueden considerar dos enfoques: Estructura Funcional y Estructura por Procesos.

Estructura funcional

En la estructura con enfoque funcional, las actividades se organizan verticalmente, en áreas funcionales, de forma altamente jerárquica, con ámbitos de control muy limitados y rígidos (figura 1.2).

Cada función busca optimizar sus propias tareas, inclusive a costa del rendimiento global de la organización. Su foco de análisis es la tarea o función, su objetivo es la optimización de las tareas, se orienta al interior de la organización, tiene una visión fragmentada.

Figura 1.2 Estructura funcional

Estructura por procesos

En la estructura con enfoque por procesos, las actividades se organizan de manera horizontal, facilitando la reunificación de actividades fragmentadas (figura 1.3).

Se percibe las actividades como procesos que rompen las barreras funcionales por medio de los cuales se producen los productos y servicios, notándose las relaciones con el cliente. Se busca satisfacer al cliente, considerando el producto y el flujo de trabajo. Su foco de análisis es el proceso, su objetivo es la mejora de los procesos, se orienta esencialmente al cliente y tiene una visión global.

Gerencia General

Investigación y

Desarrollo

Producción Finanzas Ventas

13

Figura 1.3 Organización por procesos

1.1.3 Niveles Organizacionales

Los roles que las personas desempeñan en la organización se pueden agrupar en diversos niveles organizacionales. Podemos considerar niveles relacionados con la toma de decisiones, que agrupa a los gerentes, y nivel de operaciones, que agrupa a empleados, obreros, etc., quienes realizan actividades rutinarias, sin responsabilidad de toma de decisiones.

Se suele utilizar un modelo de pirámide organizacional para representar los niveles organizacionales relacionados con la toma de decisiones. En la figura 1.4 se visualiza cuatro niveles: Estratégico, Administrativo, de Conocimiento y Operativo (Laudon, 2004).

Figura 1.4 Pirámide organizacional

Fuente: (Adaptado de Laudon, 2004)

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

actividades operacionales o rutinarias que tienen poca tarea de toma de decisiones.

Gerentes

Operativos

Trabajadores del

Conocimiento

Nivel Operativo

Nivel

Administrativo

Nivel de

Conocimiento

Directores

Gerentes de

Nivel Medio

Nivel Estratégico

Gerencia General

Proceso de negocio (Flujo de actividades)



14

Nivel estratégico

En el nivel estratégico, se realizan actividades relacionadas con toma de decisiones de asuntos estratégicos y tendencias a largo plazo, tanto en la empresa como el entorno externo; por ejemplo, se tratan asuntos como determinar los productos a elaborar dentro de cinco años o determinar los niveles de empleo dentro de cinco años. Se puede incluir a Directores, Gerente General, Gerentes de División.

Nivel administrativo

En el nivel administrativo, se realizan actividades de supervisión, control y toma de decisiones de aspectos tácticos en el mediano plazo; por ejemplo, se tratan asuntos de exceso de presupuestos en un periodo o control del rendimiento. Se incluye a los gerentes de nivel medio, como gerente de áreas: Gerente de Ventas, Gerente de Recursos Humanos, Gerente de una Agencia o Sucursal.

Nivel de conocimiento

En el nivel de conocimiento, se realizan actividades relacionadas con la investigación y desarrollo para generar nuevas oportunidades de negocio o controlar el flujo de trabajo de oficina. Las personas que realizan este tipo de actividades son los trabajadores de conocimientos. Se incluye a Analistas Financieros, Expertos en Marketing, Investigadores.

Nivel operativo

En el nivel operativo, se realizan actividades de seguimiento y control de las tareas realizadas por el personal operacional, empleados, obreros, quienes realizan transacciones elementales de la organización como ventas, depósitos en efectivo, nóminas. Se toman decisiones de corto plazo, por ejemplo, reabastecimiento de stock de inventarios, otorgar préstamos bancarios, entre otros. Se incluye a los gerentes operativos: Jefe de Sección de fabricación, Jefe de Cajeros.

Este modelo de pirámide permite, a quienes desarrollan sistemas de información, visualizar el alcance de información requerido por cada nivel; así, en el nivel de gestión operativo, es necesaria la información detallada; mientras que, en el nivel estratégico, conviene proporcionar resúmenes.

1.2 Procesos de negocio

1.2.1 ¿Qué es un proceso de negocio?

La literatura relacionada con los proceso y la reingeniería de procesos señalan 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 más 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 compañías el proceso de ejecución de un pedido requiere la cooperación entre la función de ventas, contabilidad y manufactura. En ventas se recibe el pedido y se inicia su trámite; en contabilidad se verifica el crédito y se factura el pedido) y en manufactura se produce y envía el pedido (figura 1.5).

Algunos ejemplos de proceso de negocios son: Proceso de Admisión, Proceso de Matrícula, Proceso de Contratación de Personal, Proceso de Formulación del Plan Anual de Desarrollo.

15

Figura 1.5 Proceso de ejecución de un pedido

.

1.2.2 Clases de procesos de negocio

Los procesos de negocios se pueden clasificar en: Principales, de Soporte y de Gestión.

Los Procesos Principales o Sustantivos son aquellos que están ligados directamente con la realización del producto y la prestación del servicio para el Cliente. Son los procesos de línea, hacen realidad la misión de la organización.

Ejemplos:

Mediantes estos procesos el cliente interactúa con la organización. En el ejemplo, el proceso Vender Producto permite al cliente recibir de la organización 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 están relacionados con la gestión de recursos.

Ejemplos:

En estos procesos no hay agente externo, cliente, proveedor, etc., que interactúe con la organización. Son procesos que apoyan a los procesos principales.

Los Procesos de Gestión son aquellos que están vinculados al ámbito de las responsabilidades de la dirección. Se relacionan con actividades de planificación y control.

Ejemplos:

Estos procesos son realizados por los niveles gerenciales, no hay interacción entre algún agente externo con la organización. Son proceso que refleja tareas gerenciales..

PLANIFICACIÓN

INVESTIGACIÓN DE MERCADO

DESARRROLLO DE PERSONAL

REVISIÓN

VENDER PRODUCTO GESTIONAR PEDIDO

VENTAS CONTABILIDAD MANUFACTURA

Recibir pedido

Verificar Crédito

Producir pedido

Iniciar

tramite Facturar pedido

Enviar pedido

16

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

Un proceso de negocio se puede describir de manera textual o gráfica. Se han propuestos diversos formatos para describir un proceso, pero los ítems básicos incluyen: la entrada, las actividades, quién o quiénes realizan las actividades, los recursos que se utilizan, las reglas que rigen el flujo de actividades y la salida.

A continuación se muestra un ejemplo textual de descripción de un proceso de Registro de Pedido para una empresa de fabricación:

En la figura 1.6, se describe el proceso de Registrar Pedido de manera grafica, usando la técnica de Diagrama de Actividades de UML. Existen diversas técnicas y herramientas para describir, de manera gráfica, un proceso de negocio. Dependerá del profesional responsable, elegir aquella que se adapte mejor a las necesidades de la organización a la que brinda sus servicios.

1. El cliente envía una orden de pedido, por teléfono, por fax o por correo, al Dpto. Comercial. El pedido debe incluir la fecha de solicitud, datos del cliente y productos solicitados.

2. Un empleado del departamento comercial revisa el pedido (completándolo, si es necesario), y comienza su procesamiento enviándolo al jefe técnico, que está encargado de su análisis.

3. El jefe técnico analiza la viabilidad de cada producto del pedido por separado. Si el producto pedido está en el catálogo, su fabricación es aceptada. En caso contrario, es considerado un producto especial, y el jefe técnico estudia su producción: Si es viable, la fabricación del producto especial es aceptada; Si no es viable, el producto especial no será fabricado.

4. Una vez estudiado el pedido completo, el jefe técnico informa al departamento comercial de la aceptación o rechazo de cada producto pedido; Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo para cada producto, a partir de una plantilla de fabricación (la estándar si el producto estaba catalogado, o una nueva, específicamente diseñada para el producto, si éste no estaba en el catálogo). Cada orden de trabajo es enviada al jefe de producción, y queda pendiente de su lanzamiento.

5. El comercial comunica al cliente el resultado final del análisis de su pedido.

17

Figura 1.6 Descripción Grafica del Proceso Registro de Pedido

LLENAR

PEDIDO

TRAMITAR

PEDIDO

NOTIFICAR

RECHAZO

NOTIFICAR

ACEPTACION

ANALIZAR

VIABILIDAD

[ No es Viable ]

ORDENAR

FABRICACION

PLANIFICAR

PRODUCCION

[ Si es viable ]

JEFE PRODUCCIONJEFE TECNICOCOMERCIALCLIENTE

18

Lección 2

Introducción a los Sistemas de información

Las organizaciones requieren de información para apoyar las actividades de toma de decisión y controlar las operaciones del día a día. La información se transmite en todos los niveles de la organización a través de los sistemas de información.

En esta lección se brinda, a modo introductorio, los conceptos relacionados a los sistemas de información, los componentes y tipos de sistemas de información.

2.1 Concepto de Dato, Información y Conocimiento

Desde años atrás se reconoce que la información es un recurso valioso en las organizaciones. Los gerentes, empleados y todos aquellos que integran una organización la utilizan. Con frecuencia los empleados usan datos detallados para sus actividades de tipo operacional, los gerentes manejan información sumaria para tomar decisiones.

En muchas ocasiones se utilizan los términos datos e información como sinónimos, pero son términos que tiene distinto significado.

Datos

Los datos son registros de hechos observables no procesados que no tienen significado. En la figura 2.1 se aprecia algunos ejemplos de datos.

Figura 2.1 Datos

Información

La información es un conjunto de hechos agrupados para algún propósito en particular. Son datos procesados que tienen significado.

Por ejemplo, agrupando y organizando los datos mostrados en la figura 2.1: Zapato, José Quispe, 456789, 1200 y S/100, tenemos que se refieren a una factura (figura 2.2).

Figura 2.2 Información

Comercial “Vende Barato S.A”

Factura Nro 456789

Cliente: José Quispe

Detalle

Nro. Producto Cantidad Precio

01 Zapatos 1200 S/100

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

1200

S/100

Zapatos José Quispe

456789

19

Conocimiento

El conocimiento es la información conectada a decisiones, procesos y acciones capaces de aplicar esa información.

Para explicar la diferencia entre información y conocimiento, considere una receta de preparación de una torta. Las instrucciones e ingredientes indicados en la receta vendrían a ser información, al igual que el libro de receta es información. Esta información se convierte en conocimiento cuando, una persona elabora una torta siguiendo las instrucciones y utilizando los ingredientes indicados en la receta. En otras palabras, cuando la información se lleva a la acción se convierte en conocimiento.

Desde una perspectiva de niveles, según Harris (1996), se puede considerar que el nivel más bajo de los hechos conocidos son los datos, no tienen un significado intrínseco. En el siguiente nivel, cuando los datos son procesados (ordenados, agrupados, analizados e interpretados), se convierten en información con un propósito. En el tercer nivel, cuando la información 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, información y conocimiento desde una perspectiva de niveles.

Figura 2.3 Dato, Información Y conocimiento

Fuente: (Adaptado de Harris, 1996)

2.2 ¿Qué es Sistema de información?

“Un sistema de información es un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el control en una institución. Los sistemas de información pueden contener datos acerca de personas, lugares y cosas importantes dentro de la institución y el entorno que la rodea” (Laudon, 2004, p.30).

Un sistema de información recibe y procesa los datos de manera eficaz, sin errores, evalúa la calidad de los datos de entrada, almacena los datos de modo que estén disponibles cuando el usuario lo crea conveniente, elimina la información poco útil evitando redundancias, brinda seguridad evitando la perdida de información o la intrusión de personal no autorizado o agentes externo a la compañía y genera información de salida, en el momento oportuno, y útil para los usuarios, ayudando en el proceso de toma de decisiones.

Se suele confundir el concepto de sistemas de información con la computadora y los programas informáticos. Una organización puede adquirir nuevas computadoras, instalar redes, desarrollar páginas Web, etc., pero ello no significa que se implemente sistema de información. El significado

Hechos agrupados para un propósito

Colección de hechos

CONOCIMIENTO

INFORMACIÓN

DATO

Información conectada a decisiones, procesos y acciones capacea de aplicar esa información

20

del término sistema de información abarca más que los elementos computacionales, incluye, también, el modo de organizar dichos elementos, la forma de usarlos y los roles que desempeñan las personas en su explotación para obtener la información que apoye las actividades de la empresa.

2.3 Componentes de un Sistema de información

Se puede considerar que los componentes de un sistema de información son: el hardware, el software, la base de datos, los procedimientos y el personal. Estos elementos interactúan entre sí para lograr el objetivo del: proveer información para apoyar a la empresa (figura 2.4).

Figura 2.4 Componentes de un Sistema de Información

El hardware corresponde al elemento físico del sistema de información incluye las redes computacionales y de telecomunicaciones. El software corresponde a los programas de aplicación. La base de datos representa el almacén de los datos e información requerida por la empresa, las personas puede ser los usuarios finales y el personal de tecnología de información. Los procedimientos establecen las reglas y normas del uso del sistema de información

2.4 Tipos de sistemas de información

De acuerdo con los intereses, especialidades y niveles en una organización, se pueden identificar los siguientes tipos de sistemas de información (Laudon, 2006): de nivel operativo, de nivel del conocimiento, de nivel administrativo y de nivel estratégico.

Los sistemas de información de nivel operativo apoyan a los gerentes operativos en el control de actividades y transacciones elementales de la organización, por ejemplo: ventas, ingresos, depósitos en efectivo, nomina, decisiones de crédito y flujo de materiales en una fábrica. Responden a preguntas de rutina y siguen el flujo de transacciones a través de la organización. Por ejemplo, ¿Cuántas partes hay en inventario? ¿Qué pasó con el pago del señor Gutiérrez?

Los sistemas de información de nivel del conocimiento apoyan a los trabajadores del conocimiento de una organización. Su objetivo es ayudar a las empresas comerciales a integrar el nuevo conocimiento en los negocios y ayudar a la organización a controlar el flujo del trabajo de oficina. Estos tipos de sistemas están entre las aplicaciones de crecimiento más rápidas en los negocios actuales.

Los sistemas de información de nivel administrativo apoyan a las actividades de supervisión, control, toma de decisiones, y administrativas de los gerentes de nivel medio. La pregunta principal que plantean estos sistemas es: ¿Van bien las cosas? Por lo general, este tipo de

Personas

Hardware

Software

Dato/información

datos

Procedimiento datos

Sistema de Información

21

sistemas proporcionan informes periódicos más que información instantánea de operaciones. Apoyan a las decisiones no rutinarias y tienden a enfocarse en decisiones menos estructuradas para las cuales los requisitos de información no siempre son claros.

Los sistemas de información de nivel estratégico apoyan a los directores a enfrentar y resolver aspectos estratégicos y tendencias a largo plazo, tanto en la empresa como en el entorno externo. Su función principal es compaginar los cambios del entorno externo con la capacidad organizacional existente.

Otra forma de clasificar los sistemas de información es según la función que desempeñan o el tipo de usuario final del mismo, pueden ser (Laudon, 2006): Sistema de procesamiento de transacciones, Sistemas de información gerencial, Sistema de soporte a la toma de decisiones, Sistemas de información ejecutiva, Sistemas de automatización de oficinas, Sistemas expertos y Sistemas de Planificación de Recursos Empresariales.

Los Sistemas de procesamiento de transacciones (Transaction Process System - TPS) son aquellos que permiten gestionar la información referente a las transacciones producidas en una empresa u organización.

Los Sistemas de información 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 análisis de las diferentes variables de negocio con la finalidad de apoyar el proceso de toma de decisiones.

Los Sistemas de información ejecutiva (Executive Information System - EIS) son aquellas herramientas orientadas a usuarios de nivel gerencial, que permite monitorizar el estado de las variables de un área o unidad de la empresa a partir de información interna y externa a la misma.

Los Sistemas de automatización de oficinas (Office Automation System - OAS) son aplicaciones destinadas a ayudar al trabajo diario del administrativo de una empresa u organización.

Los Sistemas expertos (Expert System - SE) emulan el comportamiento de un experto en un dominio concreto.

Los Sistemas de Planificación de Recursos Empresariales (Enterprise Resource Planning - ERP) integran la información y los procesos de una organización en un solo sistema.

Todos estos sistemas de información a su vez podrían analizarse según las diferentes áreas de la empresa: ventas y mercadotecnia, manufactura y producción, finanzas, contabilidad y recursos humanos. Para cada una de estas áreas existe un conjunto especifico de aplicaciones informáticas y equipos, los cuales han de estar coordinados entre si. Si ello no se realizara, una empresa tendrá problemas de intercambio de datos entre las diferentes áreas, aparecerá la existencia de redundancia de datos y la existencia de ineficiencias e incrementos de costes de comunicación.

http://es.wikipedia.org/wiki/Sistemas_de_informaci%C3%B3n_ejecutiva

http://es.wikipedia.org/wiki/Sistemas_de_automatizaci%C3%B3n_de_oficinas

http://es.wikipedia.org/wiki/Sistema_experto

http://es.wikipedia.org/wiki/Sistema_Planificaci%C3%B3n_de_Recursos

http://es.wikipedia.org/wiki/Sistema_de_procesamiento_de_transacciones

http://es.wikipedia.org/wiki/Sistemas_de_informaci%C3%B3n_gerencial

http://es.wikipedia.org/wiki/Sistemas_de_soporte_a_decisiones

http://es.wikipedia.org/wiki/Sistemas_de_informaci%C3%B3n_ejecutiva

http://es.wikipedia.org/wiki/Sistemas_de_automatizaci%C3%B3n_de_oficinas

http://es.wikipedia.org/wiki/Sistema_experto

http://es.wikipedia.org/wiki/Sistema_Planificaci%C3%B3n_de_Recursos

22

Resumen

Organización y Procesos de Negocio

Una organización es un sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas de alguna forma con arreglo a ciertas reglas de división del trabajo y comunicación que interactúan para producir bienes o servicios.

La estructura organizacional representa la forma en que las personas, actividades y recursos se organizan. Puede ser de dos tipos; funcional o de procesos.

Funcional: las actividades se organizan verticalmente, en áreas funcionales, de forma altamente jerárquica, con ámbitos de controles muy limitados y rígidos.

Por procesos: las actividades se organizan de manera horizontal, facilitando la reunificación de actividades fragmentadas.

Los roles que las personas desempeñan en la organización se pueden agrupar en niveles organizacionales: Operacionales y Gerenciales. Los Gerenciales pueden ser: estratégico, administrativo, de conocimiento y de control operativo.

Nivel Operacional: Actividades rutinarias. No hay toma de decisión. Empleados, obreros.

Niveles Gerenciales: Actividades caracterizadas por toma de decisiones. o Nivel estratégico, asuntos estratégicos y tendencias a largo plazo. o Nivel administrativo, aspectos tácticos en el mediano plazo. o Nivel de conocimiento, investigación y desarrollo o Nivel operativo, control de tareas del personal operacional. Decisiones de corto plazo.

Un proceso de negocio es un conjunto de actividades que toman uno o más tipos de inputs y crean un output que es de valor para un cliente.

Clases de Procesos de Negocios

Principales: ligados con realización del producto / lprestación del servicio para el Cliente.

De Soporte: apoyan los procesos principales. Relacionados con la gestión de recursos.

De Gestión: vinculados a la dirección. Se relacionan con actividades de planificación y control.

Un proceso de negocio se puede describir en forma grafica o textual.

Introducción a los sistemas de información

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

La información es un conjunto de hechos agrupados para algún propósito en particular. Son datos procesados que tienen significado.

El conocimiento es la información conectada a decisiones, procesos y acciones capaces de aplicar esa información.

Un sistema de información es un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el control en una institución.

Los Componentes de un sistema de información son: Hardware, Software, Base de datos, Personas (usuarios finales y personal de T.I.) y Procedimientos.

Tipos de sistema de información

De acuerdo a intereses: Sistemas de información de nivel operativo, Sistema de información de nivel de conocimientos, Sistema de información de nivel administrativo y Sistema de información de nivel estratégico

Según función que desempeña: Sistema de procesamiento de transacciones (TPS), Sistema de información Gerencial (MIS), Sistema de soporte a las decisiones (DSS), Sistema de información ejecutiva (EIS), Sistema de automatización de oficinas (OAS), Sistema Experto (SE), Sistema de planificación de recursos empresariales (ERP).

.

23

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 organización de los procesos de negocios dentro de una empresa. Internet incrementa la accesibilidad, el almacenamiento y la distribución de la información y el conocimiento para las organizaciones. En esencia, Internet es capaz de disminuir de manera importante los costos de la agencia y de transacción que enfrentan la mayoría de las compañías.

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 dólares en costos de distribución. Una fuerza de ventas global puede recibir casi al instante información actualizada sobre el precio de un producto a través de la Web o instrucciones de la administración a través de correo electrónico. Los proveedores de algunos grandes detallistas pueden acceder a los sitios Web internos de estos últimos para obtener directamente información de ventas actualizada y emitir de manera instantánea órdenes de reabastecimiento.

Las empresas están reconstruyendo rápidamente algunos de sus procesos de negocios esenciales con base en la tecnología de Internet y haciendo de esta tecnología un componente clave de sus infraestructuras de tecnología de la información. Si la experiencia anterior con las redes sirve de guía, un resultado será procesos de negocios más sencillos, menos empleados y organizaciones mucho más planas que el pasado. (*) Fuente: (Laudon, 2004,p.85)

24

Actividades

1 Identifique una organización, de cualquier tipo o tamaño, indique el giro del negocio, obtenga su organigrama y realice la descripción textual o gráfica de uno de sus procesos de negocio de tipo principal.

2 Busque, en internet, un producto comercial de cada tipo de sistema de información.

Autoevaluación

1. Con respecto al concepto de organización como sistema, entre los paréntesis de la siguiente lista, marque V=Verdadero o F=Falso, según corresponda:

a. ( ) Está compuesto por personas, actividades y bienes b. ( ) Tiene reglas de división del trabajo y comunicación c. ( ) Está compuesto por recursos, actividades y personas d. ( ) Está compuesto por personas, recursos, y servicios e. ( ) Las personas realizan actividades y utilizan los recursos

2. Con respecto a la estructura organizacional, entre los paréntesis de la siguiente lista de características, marque F= si corresponde al enfoque Funcional o P= si corresponde al enfoque de Procesos:

a. ( ) Organización Jerárquica de actividades b. ( ) Objetivo es Optimizar actividades c. ( ) Organización horizontal de actividades d. ( ) No se orienta al cliente e. ( ) Visión global

3. En relación a los niveles organizacionales, entre los paréntesis de la siguiente lista coloque E=Nivel Estratégico, A=Nivela Administrativo, C=Nivel de conocimiento, O=Nivel operativo, según corresponda:

a. ( ) Trata asuntos relacionados con tendencias a largo plazo b. ( ) Decisión de aspectos tácticos 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 investigación g. ( ) Decisiones de corto plazo

4. Con respecto al concepto de proceso de negocio, marque V=Verdadero o F=Falso según corresponda: a. ( ) Conjunto de clientes b. ( ) Conjunto de actividades c. ( ) Crea valor para los gerentes d. ( ) Crea valor para un cliente e. ( ) Tiene un comienzo y un Final

5. Con respecto a las clases de proceso de negocio, entre los paréntesis de la siguiente lista coloque P=Proceso Principal, S=Proceso de Soporte, G=Proceso de Gestión, según corresponda:

a. ( ) Relacionado directamente con el Cliente b. ( ) Relacionado con la gestión de Recursos c. ( ) Relacionado con la planificación y control d. ( ) Realizado por Niveles Gerenciales e. ( ) Hacen realidad la misión de la organización

6. Marque V=Verdadero o F=Falso, según corresponda a. ( ) Dato es la representación de un hecho y tiene significado b. ( ) Dato es la materia prima para producir información c. ( ) Dato es la información procesada que tiene significado d. ( ) Información es el conjunto de datos organizados que tiene significado e. ( ) El conocimiento es información llevada a la acción

7. Con respecto al concepto de Sistema de Información, entre los paréntesis de la siguiente lista marque V=Verdadero o F= Falso, según corresponda:

a. ( ) Proporciona información para toma de decisiones

25

b. ( ) Abarca solo elementos computacionales c. ( ) Sus componentes son Hardware, Software, Base de datos, Procedimientos y Personas d. ( ) Captura, procesa, almacena y distribuye información e. ( ) Los procedimientos establecen reglas y normas de uso del sistema

8. Coloque la letra en la celda a la derecha del tipo de sistemas de información (S.I.) que relaciona el nombre del tipo de sistema de información con la definición que corresponda:

Tipo de S.I. Definición de tipo de S.I.

1. TPS a) Aplicaciones para ayudar el trabajo del administrativo de una empresa

2. MIS b) Emulan el comportamiento de un experto en un dominio concreto

3. DSS c) Integran información y proceso de una organización en un solo sistema

4. EIS d) Permiten el análisis de variables del negocio para tomar decisiones

5. OAS e) Orientados a solucionar problemas empresariales en general

6. SE f) Gestionan la información de transacciones en una empresa

7. ERP g) Orientado a monitorizar estado de un área o unidad de una empresa

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

Exploración on-line

Portal del CIO, Portal de la Compañía IBM sobre transformación de procesos de negocio para incrementar la flexibilidad empresarial a través de SOA; contiene documentos, videos y casos de estudio. https://www-935.ibm.com/services/es/cio/flexible/

OMG, Object Management Group / Business Process Management Initiative Página de la Organización Internacional OMG (Object Management Group) que contiene información de estándares de modelado de procesos de negocios. http://www.bpmn.org/

Referencias bibliográficas

1 Davenport, Thomas (1996). Innovación de Procesos: Reingeniería del trabajo a través de la tecnología de la información. España. Díaz Santos.

2 Hammer, Michel y James Champy (1995), Reingeniería. Bogota. Grupo Editorial Norma..

3 Harris, David (1996), “Creating a Knowledge Centric Information Technology Environment”. Harris Training & Consulting Services Inc., Seattle, WA, September.

4 Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Información Gerencial. 8ª Ed. México D.F. Pearson Educación.

5 Laudon, Jane y Kenneth (2006). Sistemas de información gerencial, Administración de la empresa digital. México D.F. Pearson Educación- Prentice Hall

https://www-935.ibm.com/services/es/cio/flexible/

http://www.bpmn.org/

http://es.wikipedia.org/w/index.php?title=Sistemas_de_informaci%C3%B3n_gerencial-_Administraci%C3%B3n_de_la_empresa_digital&action=edit&redlink=1


26

SEGUNDA UNIDAD

EL PROCESO DE DESARROLLO, RUP Y UML

¿Qué es un proceso de desarrollo, cuáles son sus fases y actividades genéricas? ¿Cuáles son los modelos de proceso de desarrollo? ¿Qué es metodología, técnica y herramienta de desarrollo? ¿Qué es el UML y cuáles son sus elementos, relaciones y diagramas? ¿Qué es el RUP y cuales sus fases y flujos, artefactos, trabajadores, actividades?


Explica las fases de un proceso de desarrollo y sus actividades genéricas

Describe las características de los diversos modelos de proceso de desarrollo

Comprende los conceptos de metodología, técnica y herramienta

Comprende los elementos, las relaciones y los diagramas del UML

Comprende las fases, flujos, artefactos, trabajadores y actividades del RUP

27

Lección 3

Proceso de desarrollo de sistemas de información

La construcción de un sistema de información implica un esfuerzo conjunto de profesionales de tecnología de información y líderes de la organización. Este esfuerzo 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 metodologías de desarrollo.

Esta lección ayuda a comprender las características de un proceso de desarrollo, los modelos que existen y los conceptos relacionados a las metodologías de desarrollo.

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

3.1.1 ¿Qué es un proceso de desarrollo?

El proceso de desarrollo es una guía acerca de las actividades y tareas necesarias para construir un sistema de información. En el contexto de software, programas de aplicación o aplicaciones informáticas, Pressman (2002) considera al Proceso como un marco de trabajo que define las tareas a realizar para desarrollar software de alta calidad.

Se han establecido diversos modelos de proceso de desarrollo de sistemas de información, con actividades y tareas específicas; pero se puede establecer una serie de actividades comunes que llamaremos “visión genérica”, considerando las siguientes fases (Pressman, 2002): Definición, Desarrollo y Evolución.

Figura 3.1 Fases del proceso de desarrollo: Visión genérica

Fuente: (Pressman, 2002)

3.1.2 Fase de Definición

El propósito de la fase de Definición es identificar las necesidades o requerimientos del cliente/usuario, tales como: la información que debe ser proporcionada, la funcionalidad y rendimiento que se desea, las interfaces que deben establecerse, las restricciones de diseño que existen y los criterios de validación que se necesitan para definir un sistema correcto.

En esta fase, se realizan las siguientes actividades: Análisis del Sistema, Requerimientos del Software y Planificación del Proyecto.

Análisis del sistema. Define el papel de cada elemento del sistema de información, asignando finalmente al software el papel que va a desempeñar.

Requerimientos del software. El ámbito establecido para el software proporciona la dirección a seguir, pero antes de comenzar a trabajar es necesario disponer de una información mas detallada del ámbito de la funcionalidad del software.

Desarrollo

Evolución

Definición

Análisis del

Sistema

Requerimientos

Planificación Diseño

Codificación

Prueba Corrección

Adaptación

Mejora

28

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

3.1.3 Fase de Desarrollo

El propósito de la fase de Desarrollo es determinar cómo han de diseñarse las estructuras de datos y la arquitectura del software, cómo han de implementarse los detalles procedimentales, cómo ha de traducirse el diseño a un lenguaje de programación y cómo ha de realizarse la prueba.

En general se aplicarán tres pasos concretos: Diseño del Software, Codificación y Pruebas del software.

Diseño de software. El diseño traduce los requisitos de software a un conjunto de representaciones (algunas gráficas y otras tabulares o basadas en lenguajes) que describen las estructuras de bases de datos, la arquitectura, el procedimiento algorítmico y las características de la interfaz.

Codificación. Las representaciones del diseño deberán ser traducidas a un lenguaje artificial (un lenguaje de programación convencional o un lenguaje no procedimental T4G), dando como resultado unas instrucciones ejecutables en la computadora.

Prueba del software. Una vez que el software ha sido implementado en una forma ejecutable por la maquina, debe ser probado para descubrir los defectos que puedan existir, en la función, en la lógica y en la implementación.

3.1.4 Fase de Evolución

La fase de Evolución, también llamada fase de mantenimiento, se centra en los cambios que van asociados a la corrección de errores, a las adaptaciones requeridas por la evolución del entorno del software y a las modificaciones debidas a los cambios de requisitos del usuario dirigidos a reforzar o ampliar el sistema.

La fase de mantenimiento vuelve a aplicar las fases de definición y de desarrollo, pero en el contexto del software ya existente.

Se encuentran tres tipos de cambio: Corrección, Adaptación y Mejora.

Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.

Adaptación. Con el paso del tiempo es probable que cambie el entorno original (sistemas operativos, equipos periféricos, etc.) para los que se desarrollo el software. El mantenimiento adaptativo consiste en modificar el software para acomodarlo a los cambios de su entorno externo.

Mejora. Conforme utilice el software, el usuario puede descubrir funciones adicionales que podrían interesar que estuvieran incorporadas en el software. El mantenimiento perfectivo amplia el software más allá de sus requisitos funcionales originales.

3.2 Modelos de Proceso de desarrollo de software

La implementación de un proceso de software puede variar de acuerdo a la naturaleza: del proyecto, de la aplicación de los métodos a seguir y de las herramientas a utilizar. Se han establecido diversos modelos, conocidos como “ciclo de vida del software”.

29

En esencia, los modelos de ciclo de vida del software permiten determinar las fases productivas de un proyecto, los objetivos de cada fase productiva, los productos obtenidos en cada una de estas fases, así como sus características y los roles que se desempeñan en cada fase.

Los modelos de proceso de software se puede clasificar en: Secuencial, Iterativos y Evolutivos.

El modelo secuencial se caracteriza porque las actividades del desarrollo progresan de manera secuencial. Una actividad no puede iniciar si no ha terminado la anterior.

Los modelos iterativos se caracterizan porque las actividades se repiten de manera cíclica. Entre los modelos iterativos podemos mencionar: Construcción de prototipos y Desarrollo Rápido de Aplicaciones.

Los modelos evolutivos se caracterizan porque son iterativos y en cada iteración se agrega nueva funcionalidad (versiones) al sistema. Se ha dado gran impulso a estos modelos pues la realidad demuestra que los requisitos suelen cambiar a medida que el desarrollo avanza, haciendo que no se puedan cumplir con las metas fijadas inicialmente respecto de un producto final completo; otras veces, si bien se han captado claramente los requisitos centrales todavía falta definir los detalles. Entre los modelos evolutivos podemos mencionar el modelo incremental y el modelo espiral.

3.2.1 Modelo Lineal Secuencial

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

Figura 3.2 Modelo lineal secuencial

En este modelo, los requerimientos deben estar claramente identificados desde el inicio. Sin embargo, la realidad señala que raramente el cliente expone todos los requerimientos desde el inicio. En consecuencia, pueden surgir cambios durante el desarrollo lo que afectará la planificación establecida.

Cuando se trata de proyectos grandes, el cliente debe tener paciencia porque no verá una versión operativa del sistema sino hasta que el proyecto esté muy avanzado. Además, esto hace que no exista una validación por parte del cliente hasta muy tarde. Si en estas etapas finales se detectase un error grave las consecuencias son desastrosas.

Aunque este modelo puede tener sus debilidades, siempre es mejor que un enfoque hecho al azar y puede resultar bueno cuando se trate de un proyecto donde todos los requerimientos están claramente definidos desde el comienzo.

3.2.2 Modelo Construcción de Prototipos

Muchas veces, en los proyectos de desarrollo, no todos los requisitos están claros desde el inicio; en esta situación puede resultar conveniente aplicar el Modelo de Construcción de Prototipos.

En este modelo el ciclo comienza con la captura de requerimientos del cliente por parte del desarrollador. Luego, el desarrollador construye un prototipo de “diseño rápido” concentrado en las interfaces de entrada y salida; que se constituye en la primera versión. Este prototipo es

Análisis de Sistemas

Requerimientos de software

Diseño Codificación Prueba Mantenimiento

30

evaluado por el cliente y sirve para refinar los requerimientos. Se inicia nuevamente el ciclo, conocido como iteración (figura 3.3).

Lo ideal es que este prototipo sirva sólo para identificar los requisitos y una vez que esto se logró se lo deseche; generalmente, estos prototipos, si son operativos (working prototype) suelen ser muy lentos o muy grandes o torpes o las tres cosas a la vez. Lo ideal es, ahora, construir una versión rediseñada en la que estos problemas no estén presentes.

Figura 3.3 Modelo Construcción de prototipos

Fuente: (Adaptado de Pressman, 2002)

En este modelo, cuando el cliente observa el prototipo operativo, cree que es la versión final del sistema, sin entender que se trata de solo un prototipo y que el producto no está terminado.

Por la presión de hacer que el prototipo funcione rápidamente, el desarrollador puede elegir, inadecuadamente, el sistema operativo o el lenguaje de programación; incluso, puede usar un algoritmo incorrecto. Después de algún tiempo, puede familiarizarse con estas elecciones y olvidarse las razones por las cuales son inadecuadas, dejándolas luego como una parte integral del sistema.

Aunque pueden surgir estos problemas, éste es un modelo útil a la hora de construir un sistema donde no se tiene claros los requisitos inicialmente. La clave está en establecer claramente, al principio, las reglas de juego con el cliente y llegado el momento, no ceder a la presión de éste para conservarlo como producto final.

3.2.3 Modelo Desarrollo Rápido de Aplicaciones (DRA)

El Modelo de Desarrollo Rápido de Aplicaciones (DRA), Rapid Application Development (RAD), es un modelo lineal secuencial con un ciclo extremadamente corto. La rapidez se logra gracias al reúso de componentes, al empleo de Técnicas de Cuarta Generación, y a la posibilidad de dividir el sistema en módulos o subsistemas, que pueden asignarse a equipos, independientes, que trabaja en paralelo; al finalizar el trabajo de los equipos, los módulos se integran en un solo producto.

Cuando se utiliza para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases: modelo de negocio, modelo de datos, modelo de procesos, generación de aplicaciones, prueba y entrega (figura 3.4.).

Modelo de Negocio: en esta fase se trata de responder a las siguientes preguntas: ¿qué información maneja el proceso de negocio?, ¿qué información se genera?, ¿quién la genera?, ¿a dónde va esa información?, ¿quién la procesa?

Modelo de Datos: a partir del estudio del flujo de información en la fase anterior, se construye un modelo de datos que muestra los objetos, atributos y relaciones entre dichos objetos.

31

Modelo de Procesos: en esta fase se construye un modelo de procesos donde se muestran las transformaciones necesarias sobre los objetos del modelo de datos a los efectos de lograr la funcionalidad deseada.

Generación de Aplicaciones: en esta fase se genera la aplicación con el empleo de técnicas de cuarta generación, además de re-usar componentes existentes (cuando es posible) y la creación de componentes reutilizables (cuando es necesario).

Prueba y Entrega: Dado que enfatiza la reutilización de componentes, los cuales ya han sido probados, el tiempo de prueba se ve reducido. Sin embargo se deben probar todos los componentes nuevos y las interfaces entre módulos.

Figura 3.4 Modelo DRA

Fuente: (Pressman, 2002)

En este modelo, cuando el proyecto es grande, se requiere un gran número de personas para formar equipos paralelos suficientes.

Requiere de un alto compromiso por parte de clientes y desarrolladores en lo que al tiempo se refiere. Si esto falla, el proyecto fracasa.

No todos los tipos de aplicaciones son aptos para aplicar este modelo. Por ejemplo, no son aptos aquellos sistemas que no se pueden modularizar, tampoco funciona bien para aquellos donde existe un bajo reuso de componentes, ya que nuevos deben ser desarrollados y probados.

No es apropiado cuando existen riesgos tecnológicos altos. Por ejemplo, cuando se hace uso de una nueva tecnología, o cuando el software nuevo requiere de una alta interoperabilidad con otros ya existentes.

3.2.4 Modelo Incremental

En el Modelo Incremental, se aplica, repetidamente, el modelo Lineal Secuencial. Cada secuencia lineal entrega una versión operativa, llamada incremento. El primer incremento entrega la funcionalidad correspondiente a los requerimientos básicos, el siguiente agrega nueva funcionalidad a la anterior y así, sucesivamente, hasta obtener el producto final (Figura 3.5).

32

Por ejemplo, para un editor de textos, en el primer incremento podríamos entregar funcionando la gestión de archivos y la producción de documentos, en el segundo incremento las funciones más sofisticadas relacionadas con la edición y en el tercer incremento la revisión ortográfica.

Al finalizar cada incremento, el cliente recibe una versión operativa del producto y lo evalúa. Como resultado de su utilización y evaluación, se desarrolla un plan para el siguiente incremento. Este plan contempla la modificación del producto central para cumplir mejor con las necesidades del cliente y además para agregar nueva funcionalidad.

Figura 3.5 Modelo Incremental

Fuente: (adaptado de Pressman, 2002)

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

3.2.5 Modelo Espiral

El Modelo en Espiral es un modelo iterativo que proporciona en cada iteración una versión evolutiva (incremento) del producto.

Durante las primeras iteraciones la versión incremental podría ser un prototipo o un modelo en papel. Durante las últimas iteraciones se producen versiones cada vez más completas del software.

El modelo divide las actividades en regiones, generalmente entre tres y seis. En la figura 3.6, se observa un modelo espiral que contiene seis regiones: Comunicación con el Cliente, Planificación (se definen recursos y tiempo), Análisis de Riesgos (se evalúan riesgos técnicos y de gestión), Ingeniería (se construyen modelos de la aplicación a desarrollar), Construcción y Entrega (se construye, prueba, instala y proporciona soporte al usuario), Evaluación del Cliente.

El proceso comienza desde el centro, girando en el sentido de las agujas del reloj. En la figura 3.6, el primer circuito, en gris más oscuro alrededor del espiral, podría resultar en el desarrollo de una especificación del producto (pueden ocurrir múltiples iteraciones dentro de un circuito); luego,

circuitos sucesivos podrían ser usadas para desarrollar un prototipo y progresivamente versiones

mas sofisticadas del software.

33

Figura 3.6 Modelo Espiral

Fuente: (adaptado de Pressman, 2002)

A diferencia del modelo lineal secuencial que termina cuando se entrega el software, el modelo en espiral puede ser adaptado para ser aplicado a un proyecto que se encuentre en cualquier punto del ciclo de desarrollo.

Cada cubo en la figura 3.6 representa un punto de entrada para un tipo diferente de proyecto. Podemos arrancar desde el cubo de más adentro para el caso de un proyecto de desarrollo de conceptos hasta que el desarrollo del modelo conceptual haya finalizado. Si el concepto va a ser desarrollado en un producto real, el proceso avanza hasta el próximo cubo, y así sucesivamente para los distintos tipos de proyectos. De esta forma, el proceso puede permanecer parado por un tiempo, pero siempre que un cambio ocurre, el proceso reinicia desde el punto de entrada apropiado (por ejemplo, proyecto de mejora del producto).

3.3 Metodologías

Asociado al concepto de proceso de desarrollo de sistemas de información, software, o aplicaciones informáticas, está el concepto de Metodología de Desarrollo.

Una Metodología es el conjunto de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a realizar nuevo software (Pressman, 2005). Una metodología representa el camino a seguir para desarrollar software o aplicaciones informáticas de una manera sistemática, consiste de un conjunto de fases subdivididas en etapas, actividades y tareas.

Una tarea es una actividad elemental siguiendo algún procedimiento. El procedimiento es la definición de la forma de ejecutar la tarea. La técnica es la herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o varias. Una herramienta es el soporte software que apoya la aplicación de una técnica. Un producto es el resultado de cada fase, etapa o actividad de una metodología.

Se han establecido diversas metodologías para el desarrollo de sistemas de información, algunas de las mas citadas son: RUP, MÉTRICA V3, Merisse, SSADM V4, MDSI.

3.3.1 RUP

Rational Unified Process, de la compañía IBM, es una plataforma de proceso de desarrollo de software configurable que entrega mejores prácticas comprobadas y una arquitectura

34

configurable. Permite seleccionar y desplegar solamente los componentes de proceso que usted necesita para cada etapa de su proyecto.

El RUP es un proceso de desarrollo de software y junto con UML (Lenguaje Unificado de Modelado), constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

Link: http://www-01.ibm.com/software/pe/rational/rup.shtml

3.3.2 MÉTRICA V3

MÉTRICA, versión 3, Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información, del Consejo Superior de Administración Electrónica del Ministerio de la Presidencia del Gobierno de España, ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades del proceso de desarrollo dentro del marco que permite alcanzar los siguientes objetivos:

Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.

Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.

Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.

Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.

Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

Link: http://www.csae.map.es/csi/metrica3/index.html

3.3.3 Merisse

Merise es un método integrado de análisis, concepción y gestión de proyectos, desarrollado en Francia, que provee un marco metodológico y un lenguaje común riguroso para los desarrollos informáticos.

Es una metodología de modelado de propósito general en el ámbito del desarrollo de sistemas de información, ingeniería de software y gestión de proyectos. Fue introducido en la década de 1980, desarrollado y perfeccionado hasta el punto en que las organizaciones no gubernamentales francesas, comerciales e industriales más grandes la han adoptado como metodología estándar.

Merise separa el tratamiento de datos y de procesos, donde la vista de datos se modela en tres fases: conceptual, lógico y físico. Del mismo modo, la vista de proceso pasa a través de tres etapas: conceptual, organizacional y operacional. Estas etapas en el modelado de proceso son paralelas con las etapas del ciclo de vida: planificación estratégica, el estudio preliminar, un estudio detallado, desarrollo, implementación y mantenimiento.

Link: http://merise.developpez.com/

3.3.4 SSADM V4

El Método de análisis y diseño estructurado de sistemas (SSADM Structured Systems Analysis and Design Method (SSADM) es un enfoque de sistemas para el análisis de sistemas de información; fue producido por Central Computer and Telecommunications Agency (nahora Office of

http://www-01.ibm.com/software/pe/rational/rup.shtml

http://www.csae.map.es/csi/metrica3/index.html

http://merise.developpez.com/

http://en.wikipedia.org/wiki/Office_of_Government_Commerce

35

Government Commerce), una oficina gubernamental de Reino Unido relacionada con el uso de tecnología en el gobierno, a partir de 1980.

Las tres técnicas más importantes que se utilizan en SSADM son: Modelado lógico de Datos, Modelado de flujo de datos y Modelado de comportamiento de entidades.

Desde 1981 SSADM se ha perfeccionado y la versión 4 fue lanzado en 1990. SSADM es un estándar abierto, es decir, que esta disponible gratuitamente para su en la industria y muchas empresas ofrecen servicios de apoyo, formación y herramientas CASE para ello.

3.3.5 MDSI

La metodología MDSI Versión 2.0, es una herramienta desarrollada en base a la metodología de Métrica 3 del Ministerio de Administración Pública de España (MAP) y RUP (Rational Unified Process), han sido revisados y adaptados para su aplicación en las entidades integrantes del Sistema Nacional de Informática por la Oficina Nacional de Gobierno Electrónico e Informática – ONGEI de la Presidencia del Consejo de Ministros - PCM. Es un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software. Incluye: Modelamiento del Negocio, Modelamiento de Requerimientos, Modelamiento de Tecnología, Construcción, Pruebas e Implantación del Sistema de Información

http://en.wikipedia.org/wiki/Office_of_Government_Commerce

36

Lección 4

Introducción al UML

4.1 ¿Qué es el UML?

UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado en una notación gráfica, que permite: especificar, construir, visualizar y documentar los elementos de un sistema software, así como para modelar los procesos de negocios u otros sistemas no software (Jacobson, 2006).

Puede ser utilizado por cualquier metodología de desarrollo orientada a objetos. Este lenguaje es el resultado de la unificación de los métodos de modelado orientados a objetos de: Grady Booch, Jim Rumbaugh, Ivar Jacobson.

Un lenguaje de modelado permite expresar los distintos modelos (artefactos) que se producen en el proceso de desarrollo de software.

4.2 Artefacto, Modelo y Diagrama

Artefacto

Un artefacto representa la información que es utilizada o producida durante un proceso de desarrollo de software. Ejemplo: documento de especificación de requisitos, un modelo, un programa.

Modelo

Un modelo es una representación abstracta de una especificación, un diseño o un sistema desde un punto de vista particular. Representa uno o más diagramas. Ejemplos: modelo de casos de uso, modelo de negocio.

Diagrama

Un diagrama es una representación gráfica de una colección de elementos del modelo. Ejemplos: diagrama de casos de uso, diagrama de clases.

4.3 Elementos en UML

Los elementos del UML se clasifican en: estructurales, de comportamiento, de agrupación y de anotación.

Elementos Estructurales

Los elementos estructurales representan la parte estática del sistema. Se incluyen (figura 4.1): Clase, Interfaz, nodo, caso de uso, interfaz, clase activa, componente, cadena de responsabilidad.

Figura 4.1 Elementos estructurales del UML

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

Clase

Interfaz Componente

Nodo Caso de uso Colaboración

37

La Interfaz representa la definición un conjunto de especificaciones de operaciones

La Colaboración representa una iteración, es una sociedad de roles y otros elementos que colaboran cooperativamente

El Caso de Uso representa una funcionalidad del sistema, es un conjunto de secuencias de acciones que se ejecutan con el objetivo de lograr un resultado de interés para un grupo de usuarios en particular.

El Componente representa es empaquetamiento físico de diferentes elementos lógicos como clases, interfaces, y colaboraciones.

El Nodo representa a un elemento físico del sistema, es decir un recurso computacional.

Elementos de comportamiento

Los elementos de comportamiento representan la parte dinámica del sistema, es decir el comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados.

La Interacción representa un Conjunto de mensajes intercambiados entre objetos.

El Estado Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, recibe cierto tipo de estímulos y especifica la secuencia de estado por las que pasa un objeto.

Elementos de agrupación

Los elementos de agrupación representan la parte organizativa del sistema. Incluye: Paquete.

El Paquete es el mecanismo de propósito general para organizar elementos.

Elementos de anotación

Los elementos de anotación representan la parte explicativa del sistema. Son comentarios. Incluye: la nota

La Nota sirve para hacer comentarios a un conjunto de elementos.

4.4 Relaciones en UML

Las relaciones del UML representan los vínculos entre dos elementos del modelo. Incluye: dependencia, asociación, generalización y realización.

Dependencia

Interacción

Mensaje

Estado

Paquete

38

Representa una relación semántica entre dos elementos, tal que un cambio en uno de ellos (el independiente) puede afectar al otro (el dependiente).

Asociación

Representa una relación estructural que describe un conjunto de links, siendo un link una conexión entre objetos.

Generalización

Representa una relación de generalización/especialización en la que el elemento especializado (descendiente) se construye sobre la especificación del elemento generalizado (ancestro)

Realización

Representa una relación semántica en la que un clasificador, tal como una interfaz o un caso de uso, especifica un “contrato” que otro clasificador, tal como una clase o una colaboración, garantiza llevar a cabo.

4.5 Diagramas en UML

La versión 2.0 del UML (Booch, 2006) considera 13 diagramas (figura 4.2), divididos en Diagramas dinámicos y estáticos.

Figura 4.2 diagramas del UML

Fuente: (Adaptado de Jacobson, 2006)

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

El Diagrama de objetos, muestra una instantánea de un conjunto de objetos y sus relaciones.

El Diagrama de componentes, muestra la organización y dependencias entre un conjunto de componentes conocida como vista de implementación de un sistema. Están relacionados a Diagramas de clases en donde un componente se Corresponde con una o más clases interfaces o colaboraciones.

39

El Diagrama de despliegue, muestra los enlaces de comunicación física entre elementos de hardware y las relaciones entre máquinas físicas y procesos (qué se ejecuta y dónde).

El Diagrama de estructura compuesta, muestra la estructura interna (incluyendo partes y conectores) de un clasificador o una colaboración estructurada.

El Diagrama de paquetes, muestra la descomposición del modelo en unidades de organización y sus dependencias.

El Diagrama de casos de uso, muestra un conjunto de casos de uso y actores y sus relaciones.

El Diagrama de secuencia, es un diagrama de interacción que muestra los objetos y actores que participan en una colaboración poniendo el énfasis en el ordenamiento en el tiempo de los mensajes.

El Diagrama de colaboración, es un diagrama de Interacción que pone el énfasis en la organización estructural de los objetos o roles que envían y reciben mensajes.

El Diagrama de estados, muestra un autómata que consiste de estados, transiciones, eventos y actividades.

El Diagrama de actividades, muestra la estructura de un proceso u otro cálculo como el flujo de control y datos paso a paso en el cálculo.

El Diagrama cronológico, es un diagrama de interacción que muestra tiempos a lo largo de diferentes objetos o roles, y no secuencias relativas de mensajes.

El Diagrama de interacciones general, es un híbrido de diagramas de actividad y de secuencia.

40

Lección 5

Introducción al RUP

5.1 ¿Qué es el RUP?

El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo, es decir define quién hace qué, cuándo y cómo (Jacobson, 2000).

Es un marco de trabajo genérico que puede especializarse. Es iterativo e incremental.

5.2 Elementos

5.2.1 Trabajador (Worker)

Es un rol que debe ser realizada por una persona o equipo. Un “worker” o rol define el comportamiento y responsabilidades de un miembro específico (o equipo específico). Una misma persona puede llevar a cabo diversos roles. Algunos ejemplos de rol son Líder de Proyecto, Analista de sistemas, programador.

5.2.2 Actividad

Es una unidad de trabajo que debe ser ejecutada. Una actividad es la más pequeña pieza de trabajo que es relevante. No es razonable hacer actividades en forma parcial. Dividir el trabajo de esta manera hace más fácil controlar el avance del proyecto. Es mejor saber que hay 3 actividades completas de 5, que saber que llevamos el 60% de una actividad. Ejemplos de actividades son Planificar una Iteración, Revisar el Diseño, Capturar requisitos.

5.2.3 Artefacto

Es una pieza de información que es producida, modificada o usada en un proceso de desarrollo de software. Un artefacto es algo que se produce e el curso del desarrollo de un producto de software. Incluye el código fuente, los modelos, documentos y otros productos del ciclo de vida. UML define la notación para representar la mayor parte de los artefactos.

5.2.4 Modelo

Cada Trabajador, necesita una perspectiva del Sistema. El Artefacto más común para representar una perspectiva es el Modelo. Los principales modelos de RUP son: Modelo del negocio, modelo de casos de uso, modelo de diseño, modelo de implementación, modelo de prueba.

El Modelo de Negocios es el modelo de los procesos de negocio y su medioambiente. Es usado para generar requerimientos de los sistemas de información que lo soportan.

El Modelo de Casos de Uso es un modelo acerca de lo que el sistema debe hacer y su medioambiente.

El Modelo de Diseño es un modelo de objetos que describen la realización de los Casos de Uso. Sirve como una abstracción del Modelo de Implementación y su código fuente.

El Modelo de Implementación es un conjunto de componentes y subsistemas que los contienen.

El Modelo de Test abarca todos los casos de test y procedimientos requeridos para probar el sistema.

41

5.2.5 Flujos de trabajo (Workflow)

Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso. Define una lista de actividades, trabajadores y artefactos.

El RUP trabaja a través de modelos. Se requieren muchos modelos para describir el sistema durante su evolución. Cada uno de los Workflows produce modelos, que se van desarrollando incrementalmente durante las iteraciones (figura 5.1)

Figura 5.1 Flujos y modelos.

Fuente: (Jacobson, 2000)

5.3 Fases

El RUP es un modelo de proceso del software dividido en cuatro fases: Inicio. Elaboración, Construcción y Transición (Figura 5.2). Estas fases están mucho más relacionadas con el funcionamiento de la organización que con aspectos técnicos de la implementación

5.3.1 Fase de Inicio

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

5.3.2 Fase de Elaboración

Los objetivos de esta fase son: Comprender el dominio del problema, Establecer un marco de trabajo arquitectónico para el sistema, Desarrollar el plan del proyecto, Identificar los riesgos clave del proyecto.

Al finalizar esta fase, se obtienen: Un modelo de los requerimientos del sistema (casos de uso UML), Una descripción arquitectónica, Un plan de desarrollo del software,

5.3.3 Fase de Construcción

Comprende fundamentalmente: El diseño del sistema, La implementación, Las pruebas. Durante esta fase se desarrollan e integran las partes del sistema.

42

Al finalizar esta fase, se obtienen: Un sistema software funcional, La documentación correspondiente a éste.

5.3.4 Fase de Transición

Se ocupa de mover el sistema desde la comunidad de desarrollo a la comunidad del usuario. También de hacer trabajar el software en un entorno real. Esta fase es comúnmente ignorada en la mayoría de los modelos de proceso de software, aún cuando es muy importante y pude implicar altos costos.

Al finalizar esta fase, se obtiene: Un sistema de software documentado adecuadamente y que funcione correctamente en su entorno operativo

5.4 Flujos

La perspectiva estática del RUP se centra en las actividades que tienen lugar durante el proceso de desarrollo. Éstas se denominan flujos de trabajo en la descripción del RUP (Figura 5.2).

Existen seis flujos de trabajo del proceso: Modelado de negocio Requerimientos Análisis y diseño Implementación Pruebas Implantación

Existen tres flujos de trabajo de soporte Administración de cambios y configuración Administración del proyecto Entorno

Figura 5.2 Estructura del RUP, fases y flujos.

Fuente: (Jacobson, 2000)

43

Resumen

Proceso de desarrollo de sistemas de información

Un proceso de desarrollo es una guía acerca de las actividades y tareas necesarias para construir un sistema de información. Es un marco de trabajo que define las tareas a realizar para desarrollar software de alta calidad.

Las fases genéricas de un proceso de desarrollo son: Definición, Desarrollo y Evolución.

La fase de definición se centra en el “que”. Su propósito es identificar las necesidades o requerimientos del cliente/usuario. Sus actividades son: Análisis del sistema, Requerimientos de software, y Planificación del proyecto de software.

La fase de desarrollo se centra en el “cómo”. Su propósito es descubrir cómo han de diseñarse las estructuras de datos y la arquitectura del software, etc. Se realizan tres pasos concretos: Diseño del Software, Codificación y Pruebas del software.

La fase de evolución, también llamada fase de mantenimiento, se centra en el “cambio” que va asociado a la Corrección, a la Adaptación y Mejora del software.

Los modelos de proceso de desarrollo de software se clasifican en

Modelo secuencial, se caracteriza porque las actividades del desarrollo progresan de manera secuencial, una actividad no puede inicia sino a terminado la anterior.

Modelos iterativos, se caracterizan porque las actividades se repiten de manera cíclica. Entre los modelos iterativos podemos mencionar: Construcción de prototipos y Desarrollo Rápido de Aplicaciones.

Modelos evolutivos, se caracterizan porque son iterativos y en cada iteración se agrega nueva funcionalidad (versiones) al sistema. Se puede mencionar al modelo incremental y al modelo espiral.

Una metodología representa el camino a seguir para desarrollar software o aplicaciones informáticas de una manera sistemática, consiste de un conjunto de fases subdivididas en etapas, actividades y tareas.

Una tarea es una actividad elemental siguiendo algún procedimiento.

El procedimiento es la definición de la forma de ejecutar la tarea.

La técnica es la herramienta utilizada para aplicar un procedimiento; se pueden utilizar una o varias.

Una herramienta es el soporte software que apoya la aplicación de una técnica.

Un producto es el resultado de cada fase, etapa o actividad de una metodología

Introducción a UML

UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado en una notación gráfica, que permite: especificar, construir, visualizar y documentar los elementos de un sistema software, así como para modelar los procesos de negocios u otros sistemas no software

Un artefacto representa la información que es utilizada o producida durante un proceso de desarrollo de software. Ejemplo: documento de especificación de requisitos, un modelo, un programa.

Un modelo es una representación abstracta de una especificación, un diseño o un sistema desde un punto de vista particular. Representa uno o más diagramas. Ejemplos: modelo de casos de uso, modelo de negocio.

Un diagrama es una representación gráfica de una colección de elementos del modelo. Ejemplos: diagrama de casos de uso, diagrama de clases.

Los elementos del UML se clasifican en: estructurales, de comportamiento, de agrupación y de anotación.

Los elementos estructurales representan la parte estática del sistema. Se incluyen (figura 4.1): Clase, Interfaz, nodo, caso de uso, interfaz, clase activa, componente, cadena de responsabilidad.

44

Los elementos de comportamiento representan la parte dinámica del sistema, es decir el comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados.

Los elementos de agrupación representan la parte organizativa del sistema. Incluye: Paquete.

Los elementos de anotación representan la parte explicativa del sistema. Son comentarios. Incluye: la nota

Las relaciones en UML representan los vínculos entre dos elementos del modelo. Incluye: dependencia, asociación, generalización y realización.

La dependencia representa una relación semántica entre dos elementos, tal que un cambio en uno de ellos (el independiente) puede afectar al otro (el dependiente, clase activa, componente, cadena de responsabilidad

La asociación representa una relación estructural que describe un conjunto de links, siendo un link una conexión entre objetos.

La generalización representa una relación de generalización/especialización en la que el elemento especializado (descendiente) se construye sobre la especificación del elemento generalizado (ancestro)

La realización representa una relación semántica en la que un clasificador, tal como una interfaz o un caso de uso, especifica un “contrato” que otro clasificador, tal como una clase o una colaboración, garantiza llevar a cabo.

Los diagramas en UML, version2.0, son 13, divididos en diagramas estáticos y dinámicos.

Los diagramas estáticos son: diagrama de clases, diagrama de objetos, diagrama de componentes, diagrama de despliegue, diagrama de paquetes y diagrama de estructura.

Los diagramas dinámicos son: diagrama de casos de uso, diagrama de secuencia, diagrama de colaboración, diagrama de estado, diagrama de actividades, diagrama cronológico, diagrama de interacciones.

Introducción a RUP

El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de

software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de

desarrollo, es decir define quién hace qué, cuándo y cómo

Elementos del RUP

Un trabajador es un rol que debe ser realizada por una persona o equipo

Una actividad es una unidad de trabajo que debe ser ejecutada

Un artefacto es una pieza de información que es producida, modificada o usada en un proceso de desarrollo de software

Un modelo es una representación de alguna perspectiva del sistema

Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso, define una lista de actividades, trabajadores y artefactos.

Las fases del RUP son; Inicio, Elaboración, Construcción y Transición.

45

Lectura

Técnicas de cuarta generación (*)

El término técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software que tienen algo en común: todas facilitan al ingeniero del software la especificación de algunas características del software a alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el programa. El paradigma T4G para la ingeniería del software se orienta hacia la posibilidad de especificar el software usando formas de lenguaje especializado o notaciones gráficas que describa el problema que hay que resolver en términos que los entienda el cliente. Actualmente, un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas: lenguajes no procedimentales de consulta a bases de datos, generación de informes, manejo de datos, interacción y definición de pantallas, generación de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo, y generación automatizada de HTML y lenguajes similares utilizados para la creación de sitios web usando herramientas de software avanzado. Inicialmente, muchas de estas herramientas estaban disponibles, pero sólo para ámbitos de aplicación muy específicos, pero actualmente los entornos T4G se han extendido a todas las categorías de aplicaciones del software.

Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. Idealmente, el cliente describe los requisitos, que son, a continuación, traducidos directamente a un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. El cliente puede que no esté seguro de lo que necesita; puede ser ambiguo en la especificación de hechos que le son conocidos, y puede que no sea capaz o no esté dispuesto a especificar la información en la forma en que puede aceptar una herramienta T4G. Por esta razón, el diálogo cliente-desarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G.

Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de requisitos al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G) o un modelo comprimido de red de iconos gráficos. Sin embargo, es necesario un mayor esfuerzo para desarrollar una estrategia de diseño para el sistema, incluso si se utiliza un L4G. El uso de T4G sin diseño (para grandes proyectos) causará las mismas dificultades (poca calidad, mantenimiento pobre, mala aceptación por el cliente) que se encuentran cuando se desarrolla software mediante los enfoques convencionales.

La implementación mediante L4G permite, al que desarrolla el software, centrarse en la representación de los resultados deseados, que es lo que se traduce automáticamente en un código fuente que produce dichos resultados. Obviamente, debe existir una estructura de datos con información relevante y a la que el L4G pueda acceder rápidamente.

Para transformar una implementación T4G en un producto, el que lo desarrolla debe dirigir una prueba completa, desarrollar con sentido una documentación y ejecutar el resto de las actividades de integración que son también requeridas por otros paradigmas de ingeniería del software. Además, el software desarrollado con T4G debe ser construido de forma que facilite la realización del mantenimiento de forma expeditiva.

Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e inconvenientes. Los defensores aducen reducciones drásticas en el tiempo de desarrollo del software y una mejora significativa en la productividad de la gente que construye el software. Los detractores aducen que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de programación, que el código fuente producido por tales herramientas es «ineficiente» y que el mantenimiento de grandes sistemas de software desarrollados mediante T4G es cuestionable.

46

Hay algún mérito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado actual de los enfoques de T4G:

1. El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación. Junto con las herramientas de ingeniería de software asistida por computadora (CASE) y los generadores de código, T4G ofrece una solución fiable a muchos problemas del software.

2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas y de tamaño medio, y que la cantidad de análisis y diseño para las aplicaciones pequeñas también se reduce.

3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería del software), para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminación de la codificación.

Resumiendo, las técnicas de cuarta generación ya se han convertido en una parte importante del desarrollo de software. Cuando se combinan con enfoques de ensamblaje de componentes el paradigma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software. (*)Fuente: (Pressman, 2002, pp. 29-30)

47

Actividades

1. Realice un cuadro comparativo entre los modelos de ciclo de vida de desarrollo de software, indicando criterios de comparación, ventajas y desventajas de cada una de ellas por cada criterio.

2. Busque en internet herramientas de software libre para modelar con el UML 2.0. .

Autoevaluación

1. Con respecto al concepto de Proceso de Desarrollo, entre los paréntesis de la siguiente lista, marque V=Verdadero o F=Falso, según corresponda:

a. ( ) Es una guía acerca de las actividades para desarrollar sistemas de información 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 Métodos para desarrollar software

2. En la celda a la derecha de la actividad de desarrollo de sistemas de información coloque la letra de la descripción que corresponda:

Actividad de desarrollo Descripción de la actividad de desarrollo de S.I.

1. Análisis de sistemas A Se analizan los riegos, se asignan recursos, se estiman costes y se planifica

2. Requerimientos B Se traducen la representación de diseño en instrucción ejecutable (programa)

3. Planificación C Su objetivo es descubrir defectos que puedan existir

4. Diseño D Se traducen los requerimientos en representaciones de diseño

5. Codificación E Se define el papel de cada elemento del sistema de información

6. Prueba F Su resultado es información detallada de la funcionalidad del software

3. En la celda a la derecha del modelo de proceso de desarrollo coloque la letra de la característica que le corresponda:

Modelos de Proceso Características del modelo de desarrollo

1. Secuencial A No son aptos para los sistemas que no se pueden modularizar

2. Prototipos B Es útil cuando no se esta seguro de poder cumplir con los plazos

3. DRA C Es un modelo evolutivo que considera clave el análisis de riesgos

4. Incremental D Una actividad no puede iniciar si no ha terminado la anterior

5. Espiral E Util cuando no se tiene claros los requerimientos desde el inicio.

4. Marque V= Verdadero o F = Falso, según corresponda: a. ( ) Una metodología es un conjunto de personas que coordinan para desarrollar software b. ( ) Una tarea es una actividad fundamental según algún procedimiento c. ( ) Un procedimientos es el soporte software para apoyar una técnica d. ( ) Una técnica es la herramienta utilizada para aplicar un procedimiento e. ( ) Un producto es el resultado de una fase o actividad de una metodología

5. En relación al UML y RUP, en la celda a la derecha del Termino coloque la letra de la Definición o Característica que le corresponda:

Término Definición o Características del Termino

1. Artefacto A. Representa funcionalidad del sistema como secuencia de acciones

2. Clase B. Proceso de desarrollo de software, marco genérico que puede ajustarse

3. Caso de Uso C. Rol que puede ser realizado por una persona o equipo

4. Elemento Estructural D. Representa conjunto de objetos con atributos, operaciones comunes

5. UML E. Define la lista de actividades, trabajadores y artefactos en el RUP

6. RUP F. Representa pieza de información usada o producida en un proceso de desarrollo

7. Trabajador G. Fase del RUP que permite decidir continua o cancelar un proyecto

8. Flujo de Trabajo H. Fase del RUP que permite comprender el dominio del problema

9. Fase de Inicio I . Permite especificar, construir, visualizar y documentar elementos del software

10. Fase de Elaboración J. Representan la parte estática del sistema

48

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


ISO/IEC 12207

Pagina de la organización internacional para la estandarización, ISO http://www.iso.org/iso/catalogue_detail.htm?csnumber=43447

OMG UML

Pagina oficial del Object Management Group, sobre UML, proporciona información y recursos para UML http://www.uml.org/

IBM - RUP

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


Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software. Madrid. Pearson Educación S.A.

Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML. Segunda edición. Madrid. Pearson Educación S.A.

Pressman , Roger S. (2002) Ingeniería de Software. Un enfoque práctico. 5ta.Ed. Mc Graw Hill, España.

http://www.iso.org/iso/catalogue_detail.htm?csnumber=43447

http://www.uml.org/


49

TERCERA UNIDAD

EL MODELADO DEL NEGOCIO

¿Qué es el modelado de negocios, cuáles son sus perspectivas?

¿Qué es un actor del negocio, un caso de uso del negocio, una meta del negocio y un diagrama de caso de uso del negocio?

¿Qué es un trabajador de negocio, una entidad de negocio y una realización de caso de uso del negocio?

¿Cómo se elabora el modelo del negocio?


Explica las características, y elementos del modelado de negocio con UML

Elabora modelos de negocio, considerando modelo de casos de uso del negocio y modelo de análisis del negocio usando el UML

50

Lección 6

Conceptos asociados al modelado del Negocio

6.1 ¿Qué es el Modelado del Negocio

El modelado del Negocio es una técnica para representar procesos del negocio (Jacobson, 2000). Permite asegurar que se construirá el sistema en el contexto de las necesidades de la empresa. El contexto esta dado por: El ambiente en que el sistema trabajará, Los roles y responsabilidades de los empleados que usaran el sistema y Las “cosas” que son manejadas en el negocio.

Tiene dos perspectivas: Externa e Interna. La perspectiva externa se representa con el modelo de casos de uso del negocio y la perspectiva interna se representa con el modelo de análisis del negocio.

6.2 Modelo de Casos de Uso del Negocio

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

6.2.1 Actor del Negocio

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

Figura 6.1 Actor de negocio

Para comprender el contexto de un negocio, se debe conocer quien interactúa con el negocio; por ejemplo, quien solicita un servicio o quien provee un insumo. Algunos ejemplos de actores del negocio son: Clientes, Proveedores y Socios.

6.2.2 Casos de uso del negocio (CUN)

Representa un conjunto de secuencia de acciones que un negocio realiza para producir un resultado observable para un actor del negocio. Un caso de uso del negocio representa un proceso del negocio. La figura 6.2 muestra la notación de caso de uso de negocio.

Figura 6.2 Caso de uso de negocio

Los casos de uso del negocio se clasifican en: Principales, de Soporte y de Gestión. Los casos de uso del negocio principales son aquellos que están ligados directamente con la realización del producto y/o la prestación del servicio para el Cliente. Los casos de uso del negocio de soporte

51

son aquellos que proporcionan apoyo a los procesos principales, usualmente están relacionados con la gestión de recursos. Los casos de uso del negocio de gestión son aquellos que están vinculados al ámbito de las responsabilidades de la dirección, se relacionan con actividades de planificación y control.

Para identificar un caso de uso del negocio principal (proceso de negocio principal) es necesario determinar el servicio o producto de la empresa que recibe el actor del negocio. Para identificar un caso de uso de negocio de soporte (proceso de negocio de soporte) es necesario determinar que se requiere para ofrecer los productos o servicios al cliente. Para identificar casos de uso de negocio de gestión es necesario examinar las actividades relacionadas con la gestión de la empresa en su conjunto.

Algunos ejemplos de Casos de uso del negocio son: Solicitar un pedido, Realizar Venta.

6.2.3 Metas del negocio

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

Figura 6.3 Meta de Negocio

6.2.4 Diagrama de casos de uso del negocio

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

Figura 6.4 Diagrama CUN

6.3 Modelo de Análisis del Negocio

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

6.3.1 Trabajador del negocio

Es una abstracción de una persona o sistema software que representa un rol que se ejecuta dentro de la realización de un CUN (figura 6.5).

Figura 6.5 Trabajador de negocio

52

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

6.3.2 Entidad del negocio

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

Figura 6.6 Entidad de negocio

6.3.3 Realización de caso de uso del negocio

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

Figura 6.7 Realización de caso de uso del negocio

La realización 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 básicos de un diagrama de actividades son: Inicio, fin, actividad, transición, barra de sincronización y bifurcación.

En la figura 6.8 se observa un diagrama de actividades básico, que se puede interpretar como sigue: el proceso se inicia con el llenado del pedido, la flecha de transición entre llenar pedido y tramitar pedido significa que después de la actividad llenar pedido sigue la actividad tramitar pedido. Terminado de tramitar el pedido, sigue 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 aceptación y Ordenar fabricación, luego planificar producción. Para que el flujo finalice correctamente, tiene que terminarse las actividades Notificar aceptación y Planificar producción.

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 reparación, etc.

53

Figura 6.8 Diagrama de actividades simple

LLENAR

PEDIDO

TRAMITAR

PEDIDO

ANALIZAR

VIABILIDAD

NOTIFICAR

ACEPTACION

NOTIFICAR

RECHAZO [ No es viable ]

ORDENAR

FABRICACION

PLANIFICAR

PRODUCCION

Figura 6.9 Diagrama de actividades detallado

Revisar cita aceptada

Asignar numero trabajo interno

Generar orden de reparación

a : Libro de citas

: Numero de trabajo interno

o : Orden de reparación

[original]

z : Libro de citas

[aceptada]

Reparar coche

Elabora parte de trabajo

c : Orden de reparación

[copia]

: Partes de trabajo

Guardar en partes pendientes

p : Partes de trabajo

[pendiente]

: Dpto reparaciones : Jefe de taller

54

Diagrama de clases de negocio

El Diagrama de clases del negocio documenta la estructura interior del negocio. Cada clase en este diagrama representa a un trabajador del negocio (el empleado del negocio) o a una entidad del negocio (una 'cosa' que el negocio manipula). En este diagrama se visualiza las relaciones entre los trabajadores del negocio y las entidades del negocio.

En la figura 6.10 se muestra un diagrama de clases del negocio, se observa al actor de negocio: Cliente, a los trabajadores del negocio: facturador y empleado de mostrador. Asimismo entidades de negocio: Partes de trabajo, inventario de artículos, factura, etc.

Figura 6.10 Diagrama de clases de análisis del negocio

pago con tarjeta

(f rom Entidades del negccio)

Pago en efectivo


Partes de trabajo


Inventario de articulos


Fichero de mecanicos


Cliente

(f rom Business Use-Case Model)

Facturador

(f rom Trabajadores del negocio)

revisa partes pendientesObtiene precios de materiales

Obtiene precio de mano de obra

indica numero de identificacion

pago


Realiza

Factura


Asigna numero factura Calcula importe total

Registra pendiente

Empleado del mostradoir

(f rom Trabajadores del negocio)

Recibe

recibe copia

registrar facturas pagadas

55

Lección 7

Proceso de modelado del Negocio

El proceso de construcción de un modelo de negocio se puede dividir en construcción del modelo de casos de uso del negocio y construcción del modelo de análisis del negocio.

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

7.1 Elaborar el modelo de casos de uso del negocio

Consideremos el siguiente ejemplo para modelar los casos de uso del negocio

7.1.1 Identificando Actores del Negocio

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

Cliente Proveedor

7.1.2 Identificando Casos de Uso del Negocio

Los casos de uso de negocio principales son: Registrar Pedido del Cliente y realizar compra a proveedores. Los casos de uso del negocio de soporte son: Fabricar producto pedido y Controlar almacén. No se identifican casos de uso del negocio de gestión.

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

56

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% Reducir tasa errores a 0.5%Mantener stock adecuado Reducir generación orden compra en 20%

7.1.4 Elaborando el diagrama de casos de uso del negocio

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

Creado por : Cesar Luza

Fecha: Enero 25, 2010

Controlar almacen

(from Casos de uso del negocio)

Fabricar producto

(from Casos de uso del negocio)

Registrar pedido

(from Casos de uso del negocio)Cliente

(f rom Actores del negocio)

Comprar materia prima

(from Casos de uso del negocio)Proveedor

(f rom Actores del negocio)

Mantener stock adecuado

(f rom Metas del negocio)

Reducir generación orden compra en 20%


Reducir tasa errores a 0.5%


Reducir tiempo en 20%(f rom Metas del negocio)

57

7.2 Elaborar el modelo de análisis del negocio

En nuestro ejemplo, de la empresa “Vende barato S.A.” consideremos la siguiente descripción de caso de uso de negocio Registrar pedido:

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 Orden de TrabajoPlantilla de fabricacion Producto especial

1. El Cliente envía su pedido, por teléfono, por fax o por correo, al Dpto. de Ventas. El pedido debe incluir la fecha de solicitud, datos del cliente y producto solicitado.

2. Un Empleado del Dpto. de Ventas revisa el pedido (completándolo, si es necesario). Comienza su procesamiento enviándolo al Jefe Técnico, que está encargado de su análisis.

3. El Jefe Técnico analiza la viabilidad del producto solicitado. Si el producto pedido está en el catálogo, su fabricación es aceptada. En caso contrario, es considerado un producto especial, y el Jefe Técnico estudia su fabricación: Si es viable, la fabricación del producto especial es aceptada; Si no es viable, el producto especial no será fabricado.

4. Una vez estudiado el pedido completo, el Jefe Técnico informa al Dpto. de Ventas de la aceptación o rechazo del producto pedido; Si el producto de un pedido ha sido aceptado, se crea una orden de trabajo, a partir de una plantilla de fabricación (la estándar si el producto estaba catalogado, o una nueva, específicamente diseñada para el producto, si éste no estaba en el catálogo). Cada orden de trabajo es enviada al Jefe de Producción, y queda pendiente de su fabricación.

5. El Empleado del Dpto. de Ventas comunica al cliente el resultado final del análisis de su pedido.

58

7.2.3 Construyendo las realizaciones de caso de uso del negocio

Realización con diagrama de actividades del Caso de Registrar Pedido

Llenar pedido

Tramitar pedido

Informar rechazo

Informar aceptacion

p : Pedido

[propuesto]

: Catalogo

x : Pedido

r : Pedido

[Rechazado]

a : Pedido

[Aceptado]

Analizar viabilidad

[ NO Viable ]

Ordenar Fabricación

: Plantilla de fabricacion

: Plantilla de fabricacion

: Producto especial

Planificar producción

: Orden de Trabajo

[ SI viable ]

: Jefe Produccion : Jefe Tecnico : Empleado de Ventas : Cliente

59

Resumen

Conceptos asociados al modelado del negocio El modelado del negocio es una técnica para representar proceso de negocio, tiene dos

perspectivas: externa (modelo de casos de uso) e interna (modelo de análisis del negocio).

El modelo de casos de uso del negocio representa la forma en que la empresa interactúa con su entorno. Incluye: actores, casos de uso del negocio.

o Un actor de negocio representa un rol que alguien o algo desempeña en relación al negocio.

o Un caso de uso de negocio representa un conjunto de secuencia de acciones que un negocio realiza para producir un resultado observable para un actor de negocio.

o Un diagrama de caso de uso de negocio muestra actores de negocio, casos de uso de negocio y las relaciones entre ellos.

El modelo de análisis del negocio describe la realización de los casos de uso del negocio mediante interacción de los trabajadores del negocio y las entidades del negocio.

o Un trabajador de negocio representa un rol que se ejecuta en la realización de un caso de uso del negocio.

o Una entidad de negocio representa una pieza de información significativa y persistente que es manipulado por trabajadores de negocio o actores de negocio.

o Una realización de casos de uso de negocio describe como los trabajadores y entidades del negocio colaboran para desarrollar un caso de uso del negocio.

Proceso de modelado del negocio Elaboración del modelo de casos de uso del negocio

o Identificar actores de negocio o Identificar casos de uso del negocio o Elaborar diagrama de casos de uso del negocio

Elaboración del modelo de análisis del negocio o Identificar trabajador de negocio o Identificar entidad de negocio o Construir realización de casos de uso del negocio

Con Diagrama de actividades Con diagrama de clases de análisis del negocio

60

Lectura

Manifiesto de Reglas de Negocio (*) Los Principios de la Independencia de las Reglas

The Business Rules Group

Artículo 1. Los requisitos como elementos principales, nunca como secundarios 1.1. Las reglas son un ciudadano de primera clase en el mundo de los Requisitos. 1.2. Las reglas son esenciales para los modelos de negocio y para los modelos de tecnología, y una

parte separada y especifica de los mismos.

Artículo 2. Independientes de los procesos y no contenidas en ellos 2.1. Las reglas son restricciones explicitas de comportamiento y/o proporcionan soporte para la

dirección 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 sistemáticamente en todas las áreas de actividad del negocio.

Artículo 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 términos. 5.2. Los términos 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 ningún concepto o hecho. 5.4. Las reglas son los fundamentos que definen lo que el negocio sabe de si mismo- es decir son

conocimiento básico de negocio. 5.5. Las reglas necesitan ser alimentadas, protegidas y gestionadas.

Artículo 4. Declarativas, no de procedimiento 4.1 Las reglas deben expresarse de forma declarativa en sentencias de lenguaje natural, por la

audiencia conocedora del negocio. 4.2 Si algo no puede ser expresado claramente, entonces no es una Regla. 4.3 Una serie de enunciados solo es declarativa si no contiene una secuencia implícita. 4.4 Cualquier enunciado de reglas que necesite de otros elementos que no sean términos o hechos,

revelan hipótesis sobre la implementación de un sistema. 4.5 Una regla es distinta del nivel de cumplimiento definido para ella. La regla y su nivel de

cumplimiento son dos asuntos diferentes. 4.6 Las reglas deben definirse independientemente de la quien tiene la responsabilidad de su

cumplimiento, y de donde, cuando o como se refuerzan. 4.7 Las excepciones a las reglas se definen mediante otras reglas.

Artículo 5. Expresiones bien formadas, no expresiones creadas con fines específicas para un caso 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 recíprocamente su

coherencia. 5.3 Las lógicas formales, como la lógica de predicados, son fundamentales para la expresión formal de

reglas en términos de negocio, así como para las tecnologías que implementan dichas reglas.

Artículo 6. Arquitectura basada en las reglas, no una implementación indirecta 6.1 Un sistema basado en reglas de negocio se construye intencionadamente para permitir el cambio

continuo de las reglas de negocio. La plataforma sobre la que el sistema se ejecuta debe soportar esta evolución.

6.2 Es mejor ejecutar las reglas directamente – por ejemplo utilizando un motor de reglas – antes que transcribirlas en alguna forma embebida dentro de un procedimiento.

6.3 Un sistema de reglas de negocio siempre debe ser capaz de explicar el razonamiento por el cual llega a una conclusión o emprende una acción.

61

6.4 Las reglas se basan en los valores ciertos. La forma en la que certeza de una regla se determina, se mantiene oculta a quienes la utilizan.

6.5 La relación entre eventos y reglas es generalmente de muchos-a-muchos.

Artículo 7. Procesos guiados por reglas, no programación basada en excepciones 7.1 Las reglas definen el límite entre actividad de negocio aceptable y no aceptable. 7.2 Las Reglas requieren a menudo de una gestión especial o especifica de las violaciones detectadas.

Cualquier actividad derivada de la violación de una regla es una actividad como cualquier otra. 7.3 Para asegurar la máxima consistencia y reutilización, el tratamiento de las actividades de negocio

no aceptables, debe separarse de la gestión de actividades de negocio aceptables.

Artículo 8. Al servicio del negocio, no al de la tecnología 8.1 Las Reglas tratan sobre las prácticas de la gestión y gobierno del negocio, por lo tanto son

motivadas por las metas y los objetivos de negocio y se les da forma a través de varios factores internos y externos a la empresa.

8.2 Las reglas suponen siempre un coste a la empresa. 8.3 Este coste de la aplicación de las reglas debe valorarse y balancearse, teniendo en cuenta

los riesgos asumidos por el negocio, y las oportunidades perdidas en caso de no aplicarlas. 8.4 “Más reglas” no es mejor, la abundancia de reglas no beneficia a su aplicación.

Normalmente es mejor un número limitado de reglas bien reflexionadas. 8.5 Un sistema eficaz puede estar basado en un pequeño número de reglas. Adicionalmente,

se pueden añadir reglas más discriminatorias, por las que ha medida que pasa el tiempo el sistema mejore y se hace más inteligente.

Artículo 9. “De, por y para” el personal de negocio. No “de, por y para” el personal de IT. 9.1 Las reglas deben provenir del personal con conocimiento de negocio. 9.2 Los expertos de negocio debe tener disponibles herramientas que les ayuden a formular, validar y

gestionar reglas. 9.3 Los expertos de negocio deben tener disponibles herramientas que les ayuden a verificar la

coherencia reciproca entre las reglas de negocio.

Artículo 10. Gestionando la lógica de negocio, no las plataformas de Hardware/Software 10.1 Las reglas de negocio son un patrimonio vital del negocio. 10.2 A largo plazo, las reglas son más 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

62

Actividades

Elaborar el Modelo del Negocio considerando la siguiente descripción:

La Empresa FABCLM se dedica a la fabricación de productos de consumo masivo. La Gerencia General desea automatizar las principales actividades que la empresa realiza en los procesos de atención de pedidos, control de la fabricación, proceso de facturación y entrega de mercadería.

Proceso de atención de pedidos El cliente envía su pedido por distintos medios (teléfono, correo o fax), son recibidos por la empleada encargada de la Oficina de Atención a Clientes, quien solicita que se realicen las siguientes comprobaciones: Antonio (Dpto de Almacén) se encarga de verificar la disponibilidad de los artículos solicitados, consultando el inventario de artículos. Juan (Dpto. Contabilidad) verifica el estado de la cuenta del cliente para ver si tiene deudas pendientes; y el Dpto. Legal verifica si el cliente tiene antecedentes sospechosos, consultando el archivo de antecedentes. En caso de que los pedidos no cumplan alguna de las condiciones anteriores serán rechazados, notificándoselo al cliente. Pero si todo es correcto, se registrar aceptación del pedido. En ambos casos es la empleada la que informa al cliente.

Proceso de control de fabricación El proceso se inicia cuando el pedido aceptado es recibido por el Jefe de Producción, quien le asigna un número de trabajo interno, luego genera la orden de producción y registra el pedido como pendiente de fabricación. La orden de producción se envía a la sección de fabricación para que empiece a elaborar los productos del pedido. Cuando finaliza el trabajo, el Jefe de Producción elabora una carta donde indica a quién serán enviados los productos que se encuentran listos. Evidentemente, el pedido deja de ser pendiente.

Proceso de Facturación Recibida la carta de productos terminados el Dpto de Facturación procede a elaborar la factura y el talón de embarque. Una copia de la factura se envía al Dpto. de Contabilidad que se encarga de realizar los asientos. Otra copia se añade al archivo de facturas. Este último archivo se emplea únicamente como referencia; no es un archivo activo sino que solo sirve para seguridad.

Proceso de Entrega Los artículos elaborados se reciben en el área de embarque, donde son empaquetados, y el talón de embarque se anexa a la caja de embarque. En base a la información contenida en el talón de embarque se procede a entregar la mercadería a domicilio asignando la movilidad correspondiente o llamar al cliente para indicarle que su mercadería esta lista y se apersone a recogerla.

63

Autoevaluación

1. Con respecto al Modelado del Negocio, entre los paréntesis de la siguiente lista, marque V=Verdadero o F=Falso, según corresponda:

a. ( ) Es una técnica 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 análisis del negocio representa la perspectiva externa

2. En relación al Modelo de casos de uso del negocio y modelo de análisis del negocio, en la celda a la derecha del Termino coloque la letra de la Definición o Característica que le corresponda:


1. Actor del negocio A. Representa un proceso del negocio

2. Casos de uso del negocio B. Representa el valor deseado en una medida particular

3. Meta del negocio C. Muestra actores de negocio, casos de uso de negocio y sus relaciones

4. Trabajador del negocio D. Representa pieza de información significativa

5. Entidad del negocio E. Representa un rol que alguien desempeña en relación al Negocio

6. Diagrama CUN F. Describe la colaboración entre trabajadores, entidades y eventos del negocio

7. Realización de CUN G. Representa un rol dentro de la realización de un CUN

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


Pagina de IBM Rational Unified Process, que ofrece información y recursos sobre la

plataforma de proceso de desarrollo de software configurable




Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML. Segunda edición. Madrid. Pearson Educación S.A.


64

CUARTA UNIDAD

EL MODELADO DE DOMINIO

¿Qué es el modelado de dominio?

¿Qué es un diagrama de clases?

¿Cuáles son sus elementos? y

¿Cómo se construye?


Explica las características, y elementos del modelado de dominio con UML

Elabora modelos de dominio, usando diagrama de clases del UML

65

Lección 8

Conceptos asociados al modelo de dominio

En el contexto de desarrollo de sistemas de información, es frecuente, en las primeras etapas del proceso, construir un modelo del dominio del problema para representar las propiedades más importantes del ámbito del negocio relacionado con el problema.

Una técnica muy utilizada para representar este modelo de domino es el diagrama de clases de UML; precisamente, en esta lección se describen las bases conceptuales para construir adecuadamente un diagrama de clases.

8.1 Clase y Objeto

Un objeto se define como un concepto, abstracción o cosa con límites bien definidos y con significado para el problema que se tenga entre manos. Una clase describe un conjunto de objetos con propiedades similares, relaciones comunes con otros y una semántica común (Rumbaugh, 1996).

Por ejemplo, “Análisis de sistemas”, “Base de datos I”, “Estadística II”, “Matemática Básica I” son objetos de la clase ASIGNATURA, en otras palabras, ASIGNATURA representa al conjunto de todas las asignaturas en el dominio de la gestión académica de una institución educativa.

8.2 Atributo

Una clase tiene una serie de características o propiedades, por ejemplo ASIGNATURA tiene código, nombre, créditos, horas de teoría, horas de practica; a estas propiedades se le conoce como atributos de la 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 específicos para cada uno de los atributos de la clase.

Por ejemplo, la clase AUTOMOVIL, tiene como atributos: número de placa, color, modelo, número de puertas, año, entre otros. Un objeto, de la clase AUTOMOVIL, es el auto de placa SGD345, color azul, modelo Station Wagon, con cuatro puertas, del año 2000. Otro objeto es el auto de placa ERG237, negro, deportivo, 4 puertas, año 2009.

8.3 Operación

Una clase tiene un comportamiento que es definido por las operaciones o responsabilidades que la clase puede realizar. Una operación es algo que la clase puede realizar o que otra clase puede hacer a una clase. Es una función o transformación que se puede aplicar o que puede ser aplicada por los objetos de una clase (Rumbaugh, 1996)..

Por ejemplo, algunas operaciones de la clase automóvil pueden ser: Encender, Apagar, Acelerar, Frenar.

8.4 Asociación y Enlace

Las entidades, 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).

66

Mediante la abstracción de asociación se vincula dos o más clases, creándose un elemento de tipo distinto (Vinculo).

Por ejemplo, “DOCENTE dicta ASIGNATURA”, es una asociación entre la clase DOCENTE y la clase ASIGNATURA. Mientras que “Cesar Luza dicta Análisis de sistemas” es un ejemplo de enlace entre los objetos “Cesar Luza” y “Análisis de sistemas” que pertenecen a las clases DOCENTE y ASIGNATURA, respectivamente.

8.5 Generalización y Agregación

La generalización y agregación son dos tipos especiales de relaciones entre clases (Rumbaugh, 1996)..

La Generalización representa la relación entre clases, donde algunas de ellas son tipos de otra. Por ejemplo, las clases SECRETARIA, TÉCNICO, INGENIERO son tipos de la clase EMPLEADO; en otras palabras, EMPLEADO es una generalización de las clases SECRETARIA, TECNICO, INGENIERO (ver figura 8.1).

Mediante la generalización se abstrae las características comunes a varias clases (subclases) para construir una clase más general (superclase), la generalización define una relación de subconjunto entre elementos de dos o más clases.

Figura 8.1 Ejemplo de generalización

La Agregación representa la relación entre clases, donde algunas de ellas son componentes de otra. Por ejemplo, las clases CPU, TECLADO, MOUSE, MONITOR son componentes de la clase COMPUTADORA; en otras palabras, la clase COMPUTADORA está formada por las clases CPU, TECLADO, MOUSE Y MONITOR (figura 8.2).

Mediante la agregación se construye una nueva clase o tipo o categoría de objetos a partir de un conjunto de otras clases denominadas componentes o partes. La agregación define una nueva clase de objetos a partir de un conjunto de clases (otras, no necesariamente distintas) que representan sus partes componente.

Figura 8.2 Ejemplo de Agregación

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

Una Clase ES PARTE DE otra clase

AGREGACIÓN CPU

TECLADO

MOUSE

MONITOR COMPUTADOR

A

Una Clase ES UN TIPO DE otra clase

GENERALIZACIÓN SECRETARIA TECNICO

INGENIERO

EMPLEADO

67

Por ejemplo, algunas clases conceptuales del dominio de la Gestión Académica son: ALUMNO, DOCENTE, ASIGNATURA y HORARIO.

El modelo de dominio se puede documentar con un Diagrama de Clases.

8.7 ¿Qué es el diagrama de clases?

Un diagrama de clases es un tipo de diagrama estático del UML, que describe la estructura de un sistema mostrando sus clases y sus relaciones. En la figura 8.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 interpretación o lectura de un diagrama de clases permite a desarrolladores y usuarios disponer de un lenguaje uniforme para mostrar características del negocio en el dominio del problema. Por ejemplo, en la figura 8.3, podemos leer la siguiente restricción semántica: “una línea de venta está contenida en una venta y ésta puede contener muchas líneas de venta, nunca ninguna línea de venta”. Además, “cada línea de venta registra la venta de un articulo y un articulo puede o no estar en una línea de venta”.

Figura 8.3 Ejemplo de diagrama de Clases

ArtículoLineaDeVenta

cantidad

10..1

Registra-venta-de

Pago

cantidad

Venta

fecha

hora

1

1..nContenida-en

1

1

Pagada-mediante

Tienda

dirección

tienda

1

*

Almacenado-en

Registro

1

1

Capturada-en

1..*

1

Alberga

1

1..n

1

*

1..*

1

1

1

1

1

10..1

concepto u

objeto del

dominio

asociación

atributos

Fuente: (Larman, 1999)

8.8 Notación UML para modelo de domino

Clase

Para efectos del modelo de dominio, una clase puede considerarse en términos de:

Símbolo, palabras o imágenes que representan a la clase;

Definición del concepto, descripción textual del significado de la clase y

Extensión: conjunto de objetos que pertenecen a la clase.

Por ejemplo, considere la clase Venta de la figura 8.4. El símbolo del concepto es un rectángulo dividió en tres partes, la primera es el nombre de la clase, la segunda los atributos y la tercera las operaciones. La definición del concepto es: Una venta representa el hecho de una transacción de compra, sucede un día y en una hora. La extensión es el conjunto de todas las ventas realizadas en la tienda.

68

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 información.

Por ejemplo, un recibo recoge la información de una venta, incluyendo fecha y hora. La Gerencia de la Tienda quiere conocer fecha y hora de las ventas, entonces, la clase Venta debe incluir los atributos fecha y hora.

Según la notación UML, los atributos se muestran en el segundo compartimento del rectángulo de la clase (figura 8.5).

Figura 8.5 Atributos

Venta

fecha

hora

Asociación

La asociación se representa con una línea que une las clases relacionadas (figura 8.6). En el siguiente ejemplo, se muestra la relación entre las clases ALUMNO y FACULTAD; la semántica señala que un alumno pertenece a una única facultad y una facultad tiene muchos alumnos, por lo menos uno.

Figura 8.6 Asociación

Alumno Facultad11..npertenece a

1..n 1

En una asociación se incluye, opcionalmente, el nombre de la asociación, la navegabilidad, y obligatoriamente, la multiplicidad. La navegabilidad se representa con una flecha que indica la dirección de envío de mensajes de un objeto a otro. La multiplicidad representa la cantidad de objetos de una clase que están vinculados con un objeto de la clase asociada.

Por ejemplo, en la figura 8.6, el nombre de la asociación es: pertenece a. La multiplicidad de la asociación es de “uno a muchos”; significa “Un objeto de 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 categorías típicas de multiplicidad son: “Uno a Uno”, “Uno a Muchos” y “Muchos a Muchos”. En la figura 8.7 se aprecia algunos tipos de multiplicidad.

69

Figura 8.7 Tipos de multiplicidad

Decano Facultad11 Dirige1 1

"Uno a Uno"

Carrera Convenio0..n11 Tiene 0..n

"Uno a Muchos"

Alumno Asignatura1..n1..n1..n 1..nMatriculado En

"Muchos a Muchos"

Aula Proyector0..11 Tiene Instalado1 0..1

Laboratorio Computadoras1..n11 1..nTiene

Clase-Asociación

En algunas ocasiones es necesario representar propiedades propias de la asociación; para tal efecto, se crea una clase especial llamada Clase-Asociación. Por ejemplo, consideremos la asociación ALUMNO matriculado en ASIGNATURA, la multiplicidad de esta asociación es de “muchos a muchos”, 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 asociación; pues si se coloca como atributo de alumno, no se sabría de qué asignatura es; si se coloca como atributo de asignatura, no se sabría de qué alumno es, entonces, se crea una clase especial llamada clase asociación MATRICULA en el que se coloca el atributo nota promedio.

La representación de una clase asociación se hace con una línea discontinua que une la asociación con la clase generada. (Figura 8.8).

Figura 8.8 Ejemplo de Clase-Asociación

70

Generalización

La generalización se representa a través de una línea recta entre las clases subtipos terminados en un triángulo blanco en el extremo cercano a la clase generalizada. Por ejemplo, en la figura 8.9, ANFIBIO, MAMÍFERO y REPTIL son tipos de ANIMAL. A su vez, CABALLO es un tipo de MAMÍFERO.

La Generalización puede encontrarse en aquellas clases que tienen ciertos atributos y operaciones en común. En ese caso se crea una clase nueva que asume dicho comportamiento común.

Figura 8.9 Ejemplo de Generalización

Agregación

La agregación se representa a través de una línea recta entre las clases “partes” terminados en un rombo en el extremo cercano a la clase “todo”. Por ejemplo, en la figura 8.10, MONITOR, CASES, TECLADO y MOUSE son partes o componentes de COMPUTADORA. A su vez, CASES está formado por CPU, RAM,VENTILADOR.

Figura 8.10 Ejemplo de Agregación

71

Lección 9

Proceso de construcción 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 relación de generalización y refinar el modelo.

Consideremos la siguiente descripción para realizar el modelo de dominio.

9.1 Identificando Clases

Muchos de las clases del dominio pueden obtenerse de una especificación de requisitos o mediante la entrevista con los expertos del dominio. Las clases del dominio aparecen en tres formas distintas (Jacobson, 2000):

Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas, contratos, y facturas.

Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento, como la aviación enemiga, misiles y trayectorias.

Sucesos que ocurrirán o han ocurrido, como la llegada de un avión, sus salidas y la hora de la comida.

Otra estrategia es seleccionar los nombres o sustantivos de la descripción del problema como posibles clases candidatas. Se construye una lista de clases candidatas. Se eliminan, de esa lista, las clases redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o construcciones de implementación.

En nuestro ejemplo las clases conceptuales identificadas son:

producto parte vendedor cliente proveedor agenteComercial

Una empresa recién formada se dedica a integrar partes para formar productos con la intención de vender el valor agregado de la integración. Con el objetivo de apoyar sus actividades, mediante una aplicación informática, se ha obtenido las siguientes reglas semánticas:

Un producto tiene un nombre y un precio base. Un producto se forma con muchas partes y cada parte puede formar muchos productos. La definición de cada producto especifica qué cantidad de cada parte forma a un producto dado.

Un vendedor tiene un apellido, nombre y un porcentual de comisión. Tanto un cliente como un proveedor tienen los datos de todo agente comercial; éstos son: cuit, razón social, e-mail, teléfono y dirección. Además, un proveedor tiene un plazo de pago y un cliente un porcentual de descuento.

Un parte puede ser comprado a muchos proveedores y un proveedor puede proveer muchas partes. Cada compra de un parte tiene una fecha y una cantidad. Una venta se realiza entre cualquier vendedor y cualquier cliente, y éste puede comprar cualquier producto. De una venta se quiere saber su fecha.

No se pueden vender productos que estén formados por una única parte, esto es, no se permite vender productos sin elaborar.

72

9.2 Identificando Asociaciones

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

En nuestro caso, las asociaciones identificadas son:

agenteComercial

proveedor

parte

1..n

1..n

1..n

1..n

Se compra

cliente

producto 1..n1..n 1..n1..n se forma

1..n

1..n

1..n

1..n

se vende

vendedor

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 asociación, crear una clase asociación.

En nuestro ejemplo, se señalan los atributos por cada clase y adicionalmente, se identifican atributos para las algunas asociaciones, creándose las clases asociación: definición, compra y venta.

73

9.4 Identificando relaciones de generalización

Se organiza y simplifica el modelo usando el principio de herencia; es decir, se puede generalizar los aspectos comunes de las clases existentes construyendo una superclase, o se puede especializar una clase en varias subclases.

Para nuestro ejemplo se establece relación de generalización entre agente comercia con cliente y proveedor:

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 señalados en la descripción del problema.

74

Resumen

Conceptos asociados al modelo de dominio

Un objeto se define como un concepto, abstracción o cosa con límites bien definidos y con significado para el problema que se tenga entre manos.

Una clase describe un conjunto de objetos con propiedades similares, relaciones comunes con otros y una semántica común

Un atributo es una propiedad de una clase que describe un rango de valores que la propiedad podrá contener en los objetos de la clase

Un enlace es una relación entre objetos

Una asociación es la relación entre clases

La multiplicidad es la cantidad de objetos de una clase que están vinculados con un objeto de la clase asociada.

La Generalización representa la relación entre clases, donde algunas de ellas son tipos de otra

La Agregación representa la relación entre clases, donde algunas de ellas son componentes de otra

El Modelo de dominio es un modelo conceptual que muestra clases conceptuales de objetos significativos en un dominio de problema

Un diagrama de clases es un tipo de diagrama estático del UML, que describe la estructura de un sistema mostrando sus clases y sus relaciones

En algunas ocasiones es necesario representar propiedades propias de la asociación; para tal efecto, se crea una clase especial llamada Clase-Asociación

Proceso de construcción de modelo de dominio Identificar clases

Identificar asociaciones

Identificar atributos

Identificar relaciones de generalización

Refinar el modelo

75

Lectura

Desarrollo de un modelo de dominio (*)

El modelado de dominio se realiza habitualmente en reuniones organizadas por los analistas del dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. Para formar un equipo eficaz, estas reuniones deberían incluir tanto a expertos del dominio como a gente con experiencia en modelado.

El objetivo del modelado del dominio es comprender y describir las clases más importantes dentro del contexto del sistema. Los dominios de tamaño moderado normalmente requieren entre 10 y 50 de esas clases. Los dominios más grandes pueden requerir muchas más.

Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se guardan como definiciones en un glosario de términos, de otra manera, el modelo de dominio se hará demasiado grande y requeriría más esfuerzo del necesario para esta parte del proceso.

Algunas veces, como en los dominios del negocio muy pequeños, no es necesario desarrollar un modelo de objetos para el dominios; en su lugar, puede ser suficiente un glosario de términos.

El glosario y el modelo de dominio ayudan a los usuarios, clientes, desarrolladores, y otros interesados a utilizar un vocabulario común. La terminología común es necesaria para compartir el conocimiento con los otros. Cuando abunda la confusión, el proceso de ingeniería se hace difícil, si no imposible. Para construir un sistema software de cualquier tamaño, los ingenieros de hoy en día deben “fundir” el lenguaje de todos los participantes en uno solo consistente.

Por último, es necesario una llamada de atención sobre el modelo de dominio. Puede ser bastante fácil el comenzar modelando las partes internas de un sistema y no su contexto. Por ejemplo, algunos objetos del dominio podrían tener una representación inmediata en el sistema, y algunos analistas del dominio podrían a su vez caer en la trampa de especificar los detalles relativos a esta representación. En casos como éstos, es muy importante recordar que el objetivo del modelado del dominio es contribuir a la comprensión del contexto del sistema, y por lo tanto también contribuir a la comprensión de los requisitos del sistema que se desprenden de este contexto. En otras palabras, el modelado del dominio debería contribuir a una compresión del problema que se supone que el sistema resuelve en relación a su contexto. El modo interno por el cual el sistema resuelve éste problema se trata en los siguientes flujos de análisis, diseño e implementación.

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

76

Actividades Desarrollar el modelo de dominio para el siguiente caso

Una Institución Educativa ha decidido brindar unos cursos extracurriculares, tanto para sus alumnos como para personas externas a la Institución. Las razones para la inclusión de personas no pertenecientes a la Institución son: obtener fondos para la modernización de las instalaciones y ayudar al pago de los viáticos de los profesores invitados.

Se desea desarrollar una aplicación que permita administrar el dictado de los cursos; una primera aproximación del contexto del negocio es el siguiente:

Se brinda varios cursos. Cada curso tiene un nombre, un cupo máximo y un cupo mínimo el cual, si no se alcanza, hace que el curso no se dicte. Cada curso es dictado por un único docente y un docente puede dictar más de un curso. Cada docente tiene apellidos, nombres, cargo y una dedicación.

A cada alumno se le da un material general, independientemente de la cantidad de cursos en que se haya inscrito, además de un material particular para cada curso en el que esta inscrito. Se desea controlar si se le ha entregado, o no, tanto el material general como los materiales particulares a cada alumno.

Un alumno puede asistir a muchos cursos y cada curso debe tener una cantidad mínima de inscritos –cupo mínimo- y no sobrepasar el cupo máximo.

De los alumnos internos se debe mantener la información de apellidos, nombres y número de libreta; de los alumnos externos, apellidos, nombres, número de recibo –único para todos los cursos-, forma de pago -efectivo, cheque o tarjeta- y monto pagado.

A cada curso se le asigna una única aula que tiene un nombre, una ubicación y una capacidad. No puede asignarse un aula a un curso cuyo cupo máximo no entre en la misma.

También se desea controlar si el alumno va asistir como oyente –no se presenta a examen ni realiza prácticos- a cada curso en donde se inscribió. Esta información es útil para que el docente organize el dictado.

77

Autoevaluación

1. Entre los paréntesis de la siguiente lista, marque V=Verdadero o F=Falso, según corresponda: a. ( ) Un objeto define un conjunto de clases con las mismas características b. ( ) Pedro, Juan y María son ejemplos de objetos de la clase Persona c. ( ) Técnico, Obrero, Empleado son objetos de la clase PERSONAL d. ( ) Una asociación es una relación entre clases e. ( ) Una clase conceptual incluye elementos software

2. En relación al Modelo de Dominio, en la celda a la derecha del Termino coloque la letra de la Definición o Característica que le corresponda:


1. Clase A. Representa una característica o propiedad de una clase

2. Atributo B. Cantidad de objetos de una clase vinculados con un objeto de clase asociada

3. Asociación C. Representa atributos propios de la asociación

4. Multiplicidad D. Representa un conjunto de objetos con las mismas características

5. Clase asociación E. Representa relación entre clase, algunas de ellas son tipos de otra

6. Generalización F. Representa relación entre clases, algunas de ellas son componentes de otra

7. Agregación G. Representa vinculo entre dos o más clases

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


Portal del producto IBM Rational Modeler

http://www-01.ibm.com/software/awdtools/modeler/

Pagina de Craig larman

http://www.craiglarman.com/wiki/index.php?title=Main_Page


Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos. Mexico D.F. Prentice-Hall Hispanoamericana.

Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT. Mexico D.F. Prentice Hall Hispanoamericana.


http://www-01.ibm.com/software/awdtools/modeler/

http://www.craiglarman.com/wiki/index.php?title=Main_Page

78

QUINTA UNIDAD

EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO

¿Qué es un requerimiento?, ¿Cómo se clasifican?

¿Qué es un modelo de casos de uso?¿Cuáles son sus elementos?

¿Cómo se construye un modelo de casos de uso?


Explica el concepto de requerimiento y su clasificación

Explica las características y elementos del modelo de casos de uso del UML

Elabora modelos de caso de uso usando el UML.

79

Lección 10

Conceptos asociados los requerimientos

La importancia de la definición, especificación, análisis y administración 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 planificación del proyecto y para verificar si el producto software es de calidad.

Muchos proyectos fracasan por una mala definición, especificación, analisis y administración de requerimientos; la experiencia ha demostrado que las actividades relacionadas con los requerimientos son complejas debido a la poca participación 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 definición, especificación, análisis y administración de los requerimientos a fin de afrontar con éxito estas tareas.

En esta lección se define y caracteriza el concepto de requerimientos y se describen técnicas para la captura de los mismos.

10.1 ¿Qué es un requerimiento?

“Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se construye.” (Jacobson, 2000, p.94)

De acuerdo con la IEEE Std. 610.12-1990, “un requisito es: (1) Una condición o capacidad necesaria para un usuario para resolver un problema o conseguir un objetivo. (2) Una condición o capacidad que debe reunir o poseer un sistema o componente de un sistema para satisfacer un contrato, estándar, especificación, u otro documento formalmente impuesto. (3) Una representación documentada de una condición o capacidad como las definidas en (1) o (2)” (IEEE, 1990, p.64).

“Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste” (Somerville, 2005, 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 acción que debe ser capaz de realizar el sistema, sin considerar restricciones físicas; es un requisito que especifica comportamiento de entrada / salida del sistema (Jacobson, 2000).

El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su entorno. En otras palabras, refleja las necesidades de los usuarios o la interacción con otros sistemas.

Por ejemplo, los usuarios de un Sistema de Gestión Académica para la Universidad pueden ser profesores y alumnos, algunos requerimientos funcionales son:

El sistema permitirá a los profesores:

Consultar los horarios de sus asignaturas,

80

Consultar la programación de los exámenes,

Actualizar y ver su información personal,

Registrar y modificar las notas de los estudiantes a su cargo,

El sistema permitirá a los estudiantes:

Consultar los horarios de sus asignaturas,

Consultar la programación de los exámenes,

Actualizar y ver su información 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 implementación, rendimiento, dependencia de la plataforma, mantenibilidad, extensibilidad o fiabilidad; especifica restricciones físicas sobre un requisito funcional (Jacobson, 2000).

Un requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se desarrolla.

Algunos ejemplos de requerimientos no funcionales son:

El sistema debe brindar una interfaz de usuario intuitiva y sencilla, con un buen mecanismo de ayuda on-line.

El sistema debe disponer de una documentación adecuada que facilite las tareas de mantenimiento..

La tasa de disponibilidad del sistema debe ser de un 99%.

10.3 Clasificación 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 (Desempeño) y Supportability (Capacidad de Soporte).

Los Requerimientos de Funcionabilidad (Functionality) son aquellos requerimientos que reflejan las características fundamentales (requerimiento funcional o funcionalidades del sistema), además 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 diseño de un elemento facilita o dificulta su manejo. Se incluyen: Factores humanos, Estética, Consistencia de la interfaz de usuario, Ayudas en línea, Agentes y wizards, Documentación de usuario y material de entrenamiento. Por ejemplo, Visibilidad del texto a una cierta distancia y Combinación de colores del texto.

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-categorías: Disponibilidad (el porcentaje de tiempo disponible, horas de uso, acceso para mantenimiento, etc.); Tiempo medio entre fallas; Tiempo medio para reparación, cuánto tiempo es posible que el sistema esté inoperante después que falla; Exactitud (precisión y exactitud, según algún estándar conocido) que se requiere para las salidas del sistema; Cantidad máxima de errores o porcentaje de defectos, generalmente expresado en términos de errores por miles de líneas de código o errores por punto funcional;

81

Errores o porcentaje de defecto, categorizados en términos de errores menores, significantes y críticos (se debe definir que significa error “crítico”, por ejemplo pérdida completa de dato o imposibilidad de uso de ciertas funcionalidades del sistema.

Los requerimientos de Desempeño (Performance), se refieren a las características de rendimiento del sistema. Incluye tiempos de respuesta específicos. Por ejemplo: Tiempo de respuesta para una transacción (promedio, máximo); Transacciones por segundo; Capacidad, como por ejemplo el número de clientes o transacciones que el sistema puede soportar; Modos de degradación, esto es, cual es el modo aceptable de funcionamiento cuando el sistema ha sido degradado de alguna manera; Utilización de recursos: memoria, disco, comunicaciones, etc.

Los requerimientos de Capacidad de Soporte (Supportability), son requerimientos que refuerzan el soporte y mantenimiento del sistema que está siendo construido, incluyendo normas de codificación, convenciones de nombres, librerías, acceso para mantenimiento, utilidades de mantenimiento si las hay. Como requerimiento que ayuda al mantenimiento se debe hacer referencia al uso de nomenclatura común para el desarrollo del sistema, y a la metodología de desarrollo.

10.4 Características de los Requerimientos

Un requerimiento debe ser:

Especificado por escrito, como todo contrato o acuerdo entre dos partes.

Posible de probar o verificar, si un requerimiento no se puede comprobar, entonces, ¿cómo se sabe si se cumplió con él o no?

Conciso, un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en el futuro.

ALGUNOS REQUERIMIENTOS FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA FACULTAD DE INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES

El sistema permitirá al secretario académico, introducir las asignaturas que se imparten en el semestre académico, los datos del docente asignado a cada sección, de teoría y práctica, de la asignatura, los datos de las aulas de teoría (ubicación y aforo) y de prácticas (ubicación, sistemas operativos, software,...).

La configuración del horario se lleva a cabo directamente sobre una plantilla horaria semanal, en la que cada casilla representará una hora en un determinado día de la semana. Cuando el Secretario pulsa esa casilla se mostrarán las asignaturas del curso que se esté configurando en ese momento. Una vez escogida las asignaturas se mostrarán las secciones de teoría y práctica a los que todavía no se les ha asignado un horario. Al escoger una sección se muestran las aulas disponibles (si es un grupo de teoría) o los laboratorios que cumplen las restricciones de sistemas operativos establecidas para esa materia y que no están ocupados a esa hora.

El sistema podrá ser consultado por cualquier usuario, que podrá consultar el horario de una asignatura, un ciclo, o de un aula o laboratorio concretos.

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

FACULTAD DE INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES

La tasa de disponibilidad del sistema debe ser de un 99%. El sistema debe tener una interfaz de uso intuitiva y sencilla, complementada con un buen sistema de ayuda. El sistema debe disponer de una documentación fácilmente actualizable que permita realizar operaciones de mantenimiento con el menor esfuerzo posible.

82

Completo, un requerimiento esta completo si no es necesario ampliar detalles en su redacción, es decir si se proporciona la información suficiente para su comprensión.

Consistente, un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo, un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusión en el lector.

10.5 Dificultades para definir los Requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes

Son difíciles de expresar en palabras (el lenguaje es ambiguo)

La cantidad de requerimientos en un proyecto puede ser difícil de manejar

Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

El usuario no puede explicar lo que hace.

El usuario tiende a recordar lo excepcional 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 Técnicas para obtener Requerimiento

10.6.1 Entrevistas

Esta técnica es adecuada para la primera toma de contacto. Es conveniente comenzar por preguntas de contexto libre, para entender: el problema, a las personas interesadas en la solución, naturaleza de ésta, y lograr efectividad de la reunión.

Ejemplos de preguntas centradas en el cliente, los objetivos globales y beneficios

¿Quién solicita el trabajo?

¿Quién utilizará la solución?

¿Cuál será el beneficio económico de una buena solución?

¿Existen otras alternativas a esta solución?

Ejemplos de preguntas sobre el problema y la solución

¿Qué entiende el cliente por una solución “correcta”?

¿Qué problemas afrontará esta solución?

¿En qué entorno se va a implantar la solución?

¿Existen restricciones o aspectos de rendimiento importantes? Ejemplo de preguntas sobre la efectividad de la reunión

¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son “oficiales”?

¿Son relevantes mis preguntas para su problema?

¿Hay alguien más que pueda proporcionar información adicional?

¿Hay algo más que debería preguntar?

83

Problemas de las entrevistas:

Pueden surgir malentendidos

Omisión de información

Mala relación de trabajo (“nosotros-ellos”)

10.6.2 JAD

El Diseño en Conjunto de Aplicaciones (JAD, “Joint Application Design”) fue desarrollado por IBM a finales de los setenta. Es una sesión de trabajo con participación de todos los involucrados. El resultado de la sesión es un documento de especificación que incluye definiciones de elementos de datos, flujos de trabajo y pantallas de interfaz.

El resultado de una sesión JAD representa un acuerdo entre usuarios, clientes y desarrolladores y minimiza los cambios posteriores de requerimientos.

Las actividades de la sesión JAD son: Definición del proyecto, Investigación, preparación, Sesión, preparación del documento final.

Definición del proyecto: el coordinador se entrevista con gerentes y clientes para determinar objetivos y alcance del proyecto. Se elabora la “guía de definición administrativa”.

Investigación: se entrevista a usuarios y se recopila información del dominio, descripción de flujos de trabajo y asuntos a tratar en la reunión. Se elabora la “agenda de sesión” y la “especificación preliminar”.

Preparación: el coordinador elabora un “documento de trabajo” o primer borrador del documento final.

Sesión: el coordinador guía al equipo para crear la especificación del sistema en una reunión que puede durar varios días. Se definen los flujos de trabajo, elementos de datos, pantallas, informes, etc. Las decisiones se documentan en unos formularios.

Preparación de documento final: el coordinador prepara el “documento final” usando los “formularios” y se distribuye a los asistentes para su revisión. Se realiza una reunión para discutir revisiones y finalizar el documento.

84

Lección 11

Conceptos asociados al Modelo de casos de uso

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

11.1 ¿Qué es el modelo de casos de uso?

El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del sistema en forma de Casos de uso. Su objetivo es comunicar la funcionalidad y el comportamiento al cliente y usuario.

El modelo de casos de uso está compuesto por actores, casos de uso, descripción de cada caso de uso y el diagrama de casos de uso.

11.2 Actor

Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar cuando interactúan con él. Una instancia de actor puede ser un individuo o un sistema externo. La notación UML para el actor se muestra en la figura 11.1.

Por ejemplo, en el Sistema de Académico de la universidad, los actores pueden ser: Secretario Académico, Alumno y Docente. Todos ellos interactúan con el sistema a través de alguna de sus funcionalidades. Nótese que el nombre del actor represente el rol que desempeñan grupos de usuarios, por ejemplo el rol alumno representa a todos los alumnos; un alumno particular representa una instancia del actor alumno.

Figura 11.1 Actor

11.3 Caso de Uso

Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a un actor particular (Jacobson, 1993). La figura 11.2 muestra la notación UML de caso de uso.

Por ejemplo, consideremos el siguiente escenario para realizar el Retiro de Dinero de un Cajero Automático:

Escenario Normal

1. E cliente inserta su tarjeta en la ranura del cajero automático 2. El cajero automático solicita ingreso de clave secreta 3. El cliente ingresa su clave secreta 4. El cajero automático muestra menú de opciones 5. El cliente selecciona opción “Retiro” 6. El cajero automático muestra relación de cuentas del cliente 7. El cliente elige cuenta 8. El cajero automático solicita cantidad 9. El cliente ingresa cantidad a retirar

85

10. El cajero automático dispensa el dinero y termina.

Esta secuencia de interacciones entre el cliente y el cajero automático termina, de forma normal, se dispensa el dinero del cliente.

Otras secuencias que no siguen este flujo normal, pueden ser:

Escenario: clave incorrecta

1. E cliente inserta su tarjeta en la ranura del cajero automático 2. El cajero automático solicita ingreso de clave secreta 3. El cliente ingresa su clave secreta 4. El cajero automático muestra mensaje de error “Clave incorrecta”

Escenario: Saldo insuficiente

1. E cliente inserta su tarjeta en la ranura del cajero automático 2. El cajero automático solicita ingreso de clave secreta 3. El cliente ingresa su clave secreta 4. El cajero automático muestra menú de opciones 5. El cliente selecciona opción “Retiro” 6. El cajero automático muestra relación de cuentas del cliente 7. El cliente elige cuenta 8. El cajero automático solicita cantidad 9. El cliente ingresa cantidad a retirar 10. El cajero automático muestra mensaje de error “Saldo Insuficiente”.

Podemos decir que este conjunto de escenarios corresponde al caso de uso Retiro de Cajero Automático.

En conclusión, un caso de uso proporciona uno o más escenarios que indican cómo debe interactuar el usuario con el sistema para conseguir un objetivo particular.

Figura 11.2 Caso de uso

11.4 Descripción de caso de uso

Se han establecido diversas plantillas para describir un caso de uso. Larman (2002) señala que la descripción de un caso de uso, básicamente, debe contener: Nombre del caso de uso, Actor, Precondiciones, Poscondiciones, Flujo básico y Flujos alternativos.

El nombre del caso de uso debe ser claro e indicar la función requerida que el sistema debe proveer a los actores. Por ejemplo, Registrar Matricula de estudiante.

El nombre del Actor, por ejemplo Estudiante

Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se inicie, se definen relativas al sistema no a su entorno, 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

86

garantía de éxito. Estas deben redactarse en tiempo verbal pasado. Por ejemplo: Se ha registrado en el sistema las notas de los alumnos.

El flujo básico, es la descripción narrativa de lo que debe ocurrir cuando los actores interactúan con el sistema para satisfacer la meta u objetivo propuesto, se consideran los pasos normales, no incluye las alternativas o variaciones.

Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales, condiciones de error o violaciones de reglas.

Ejemplo de flujo básico: 1. El Caso de uso comienza cuando el profesor indica “registrar notas.” 2. El sistema muestra un formulario de validación de ingreso al sistema. 3. El usuario ingresa su código y su contraseña. 4. El sistema muestra los cursos asignados al profesor. 5. El profesor selecciona el curso. 6. El sistema muestra un listado de los estudiantes con sus notas. 7. El profesor selecciona el estudiante e ingresa la nota de práctica, del parcial, del examen

final y la nota final. Se repite para cada estudiante. 8. El profesor indica “guardar”. 9. El sistema valida toda la información y muestra un mensaje de confirmación y el Caso de

uso finaliza.

Ejemplos de flujos alternativos:

Código o Contraseña errados: En el paso 4, si código o contraseña digitados por el usuario son erradas, el sistema muestra mensaje de error y vuelve a solicitar código y contraseña.

Profesor sin cursos asignados: En el paso 4, si el sistema determina que el profesor no tiene cursos asignados, muestra mensaje de error y el caso de uso finaliza.

11.5 Diagrama de casos de uso

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

Figura 11.3 Diagrama de casos de uso

87

Consultar notas de un curso

Estudiante

(f rom Actors)

Mantener información del estudiante

Cerrar un curso

Mantener información del profesor

Profesor

(f rom Actors)

Registrar notas de un curso

Consultar horario de exámenes

Validar acceso

Usuario

(f rom Actors)

Consultar horarios de cursos

88

Lección 12

Proceso de construcción del modelo de casos de casos de uso

En esta lección se presentan los pasos a seguir para la construcción de un modelo de casos de uso; para tal efecto, consideremos la siguiente descripción de requerimientos:

12.1 Identificando actores

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

En nuestro caso, los actores identificados son:

Encargado de

vuelosGerente Empleado de

ventas

12.2 Identificando casos de uso

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

La Empresa AIRTRANS, dedicada al servicio de transportes aéreos, necesita un sistema de información para gestionar y mantener los datos de unidades, vuelos, pilotos, pasajeros y reservas.

Después de haber dialogado con el Encargado de Vuelos se concluyo que es responsable de Mantener la información de las distintas unidades: el número, el tipo de avión, la fecha de compra, el modelo, la capacidad de carga y la capacidad de pasajeros. Determina los vuelos que llevan carga, para los mismos necesita guardar la fecha, el piloto, el lugar de origen, el destino, el peso de la carga y el monto del vuelo. Define los vuelos de pasajeros: fija la fecha, el piloto y su tripulación, origen, destino y capacidad de pasajeros.

El gerente nos informó que: Mantiene la información de los pilotos que trabajan en la empresa, para el mismo guarda el número de piloto, el nombre, dirección, habilitación, fecha del último control médico. Necesita que el sistema le devuelva dado un piloto, los vuelos que ha realizado en un periodo dado.

El empleado de ventas nos explicó que: Mantiene información de los pasajeros de los diferentes vuelos, para cada uno se le incorpora un número de identificación, el nombre, profesión, el teléfono y la dirección. Los pasajeros realizan reservas para los distintos vuelos, si no hay espacio disponible, se rechaza el pedido de reserva para ese vuelo. Confirma los pasajeros que toman los vuelos. Sólo se admiten pasajeros que hayan realizado reservas previas. Necesita un reporte con los pasajeros que tomaron un vuelo.

89

En nuestro caso, el actor Encargado de vuelo debe: Mantener información de unidades, Registrar vuelo de carga y Registrar vuelo de pasajeros. El Gerente debe: Mantener información de pilotos y Consultar vuelos por piloto. El Empleado de Ventas: Mantener información de pasajeros, Registrar reserva de vuelo, Registrar confirmación de vuelo y Consultar pasajeros que tomaron vuelo.

Mantener informacion de unidades Registrar vuelo de carga Registrar vuelo de pasajeros

Mantener informacino de pilotos Consultar vuelos por pilotos Mantener informacion de pasajeros

Consultar pasajeros que tommaron

vuelo

Registrar confirmación de vueloRegistrar reservas de vuelo

12.3 Elaborando la descripción de casos de uso

Para cada caso de uso se elabora su descripción. En nuestro caso, solo desarrollaremos descripción de algunos casos de uso.

Nombre C.U.S. Consultar Vuelos por Piloto

Actor Gerente

Precondición El usuario ha sido admitido en el sistema con el rol de Gerente

Poscondición El sistema muestra los vuelos realizados por piloto

Flujo Básico

1. El caso de uso se inicia cuando el Gerente indica “Vuelos Realizados”. 2. El Sistema muestra relación de pilotos. 3. El Gerente escoge el nombre de piloto de la relación mostrada. 4. El Sistema muestra calendario para escoger el periodo (fecha inicio y fecha de fin) 5. El Gerente escoge el periodo (fecha inicio y fecha de fin). 6. El Gerente indica “Aceptar”. 7. El Sistema muestra los vuelos realizados por el piloto en el periodo escogido. 8. El caso de uso finaliza.

Flujos Alternativos

Imprimir En el paso 7, si el gerente indica “Imprimir”, el sistema imprime la información 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.

90

Nombre C.U.S. Mantener información de unidades

Actor Encargado de vuelos

Precondición El usuario ha sido admitido en el sistema con el rol de Encargado de vuelos

Poscondición Se ha registrado información de unidades

Flujo Básico

Ingresar 1. El caso de uso comienza cuando el Encargado de Vuelo indica “Mantener Información

de unidad”. 2. El Sistema muestra las opciones: “Ingresar”, “Modificar” y “Eliminar”. 3. El Encargado de Vuelo elige la opción “Ingresar”. 4. El Sistema muestra el formulario para llenar datos de una nueva unidad. 5. El Encargado de Vuelo ingresa datos de la unidad: el número, el tipo de avión, la fecha

de compra, el modelo, la capacidad de carga y la capacidad de pasajeros. 6. El Encargado de Vuelo indica “Guardar”. 7. El Sistema registra la información de la nueva unidad. 8. El caso de uso finaliza.

Flujos Alternativos

Modificar 1. El flujo se inicia cuando el Encargado de Vuelo elige la opción “Modificar”. 2. El Sistema muestra relación de unidades 3. El Encargado de Vuelo selecciona unidad cuyo datos desea modificar 4. El Sistema muestra formulario con los datos de la unidad a modificar 5. El Encargado de Vuelo realiza modificaciones 6. El Encargado de Vuelo indica “Guardar”. 7. El Sistema registra las modificaciones. 8. El caso de uso finaliza.

Eliminar 1. El flujo se inicia cuando el Encargado de Vuelo elige la opción “Eliminar”. 2. El Sistema muestra relación de unidades. 3. El Encargado de Vuelo selecciona unidad que desea eliminar. 4. El Sistema muestra formulario con datos de unidad a eliminar. 5. El Encargado de Vuelo indica “Confirmar” 6. El Sistema registra la eliminación de la unidad. 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.

Código Repetido 1. En el paso 7 de ingresar y 7 de modificar, si el número de unidad se repite, 2. El sistema muestra un error y regresa a solicitar datos

91

12.4 Elaborando el diagrama de casos de uso

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

Mantener información de unidades

Registrar vuelo de carga

Encargado de

vuelos

Registrar vuelo de pasajeros

Consultar vuelos por pilotosGerente

Mantener información de pilotos

Mantener informacion de pasajerosRegistrar reservas de vuelo

Registrar confirmación de vuelo

Empleado de

ventas

Consultar pasajeros que tommaron

vuelo

92

Resumen

Conceptos asociados a los requerimientos

Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se construye. Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste

El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su entorno.

Un requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se desarrolla. Pueden ser de: usabilidad, fiabilidad, desempeño, capacidad de soporte.

La entrevista es una técnica para obtener requerimientos usada en las primeras tomas de contactos con los usuarios-clientes.

El diseño conjunto de aplicaciones, Joint Application Design (JAD) es una sesión con participación de todos los involucrados, cuyo resultado es un documento de especificación.

Conceptos asociados al modelo de casos de uso

El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del sistema en forma de Casos de uso.

Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar cuando interactúan con él.

Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a un actor particular.

Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el actor

Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso termina, son la garantía de éxito.

Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales, condiciones de error o violaciones de reglas.

Un diagrama de caso de uso muestra los actores los casos de uso y las relaciones entre ellos.

Proceso de construcción del modelo de casos de uso

Identificación de actores

Identificación de casos de uso

Elaboración de descripción de casos de uso

Elaboración de diagrama de casos de uso

93

Lectura

Crear el diseño lógico de una interfaz de usuario (*)

Cuando los actores interactúan con el sistema, utilizaran y manipularan elementos de interfaces de usuario que representan atributos (de los casos de uso). A menudo estos son términos del glosario (por ejemplo, balance de cuenta, fecha de vencimiento y titular de cuenta). Los actores pueden experimentar estos elementos de las interfaces de usuario como iconos, listas de elementos u objetos en un mapa 2D, y pueden manipularlos por selección, arrastre o hablando con ellos. El diseñador de interfaces de usuario identifica y especifica estos elementos actor por actor, recorriendo todos los casos de uso a los que el actor puede acceder, e identificando los elementos apropiados de la interfaz de usuario para cada caso de uso. Un único elemento de interfaz de usuario puede intervenir en muchos casos de uso, desempeñando un papel diferente en cada uno. Así, los elementos de la interfaz de usuarios pueden diseñarse para jugar varios roles. Deberíamos responder a las siguientes preguntas por cada actor:

¿Qué elementos de interfaz de usuario se necesitan para posibilitar el caso de uso?

¿Cómo deberían relacionarse unos con otros?

¿Cómo se utilizaran en los diferentes casos de uso?

¿Cuál debería ser su apariencia?

¿Cómo deberían manipularse?

Para determinar qué elementos de interfaz de usuario necesitan ser accesibles al actor en cada caso de uso, podemos contestar las siguientes preguntas:

¿Qué clases de dominio, entidades del negocio o unidades de trabajo son adecuados como elementos de la interfaz de usuario para cada caso de uso?

¿Con qué elementos de la interfaz de usuario va a trabajar el actor?

¿Qué acciones puede invocar el actor, y qué decisiones puede tomar?

¿Qué guía o información va a necesitar el actor antes de invocar cada acción de los casos de uso?

¿Qué información debe proporcionar el actor al sistema?

¿Qué información debe proporcionar el sistema al actor?

¿Cuáles son los valores medios de todos los parámetros de entrada o salida? Por ejemplo, ¿Cuántas facturas manejará habitualmente un actor durante una sesión y cuál es el saldo medio de la cuenta? Necesitamos estimaciones aproximadas de estas cosas porque asi se optimizará la interfaz gráfica de usuario para ellas (incluso aunque tengamos que permitir un rango suficientemente grande).

Una forma práctica de trabajo es representar los elementos de la interfaz de usuario mediante notas adhesivas, pegadas en una pizarra, y ordenadas para ilustrar la apariencia de la interfaz de usuario. Seguidamente, los diseñadores de interfaces de usuario describen cómo pueden utilizar los actores estos elementos cuando trabajen con los caso de uso. La ventaja de utilizar notas adhesivas es que pueden representar la cantidad necesario a de datos. Además, las notas adhesivas tampoco parecen permanentes .es fácil moverlas o simplemente eliminarlas-, lo que hace que el usuario se sienta cómodo proponiendo cambios.

(*) Jacobson (2000, pp. 153-154).

94

Actividades 1. Desarrollar el modelo de casos de uso para el siguiente sistema para una agencia de alquiler

de autos

2. Continuar el desarrollo con lo que se indica:

Inicialmente, entrevistamos al dueño de la agencia, quien es el que impulsó el proyecto. Él está, especialmente, interesado en controlar los gastos de la empresa. Necesita obtener del sistema información del tipo: Dado un intervalo de tiempo, todas las reparaciones realizadas por un monto superior al que él imponga.

El Empleado de Atención al Público, nos contó que por cada nuevo alquiler actualiza la ficha registro del cliente. En caso de tratarse de un nuevo cliente, abre una nueva ficha con los siguientes datos: apellido y nombre, dirección personal, localidad, provincia, tipo y número de documento, profesión y número de licencia de conductor. De acuerdo con las restricciones que impone el cliente, se busca si existe un vehículo disponible. Una vez que el cliente seleccionó un coche, se crea una ficha para el nuevo alquiler: fecha del alquiler, cantidad de días por los que se alquila, importe del alquiler y kilometraje del vehículo al momento de ser alquilado. No se debe autorizar alquileres a clientes que no devolvieron en el plazo o en buen estado el vehículo que se les prestó.

El Encargado de Autos es el único autorizado a actualizar la ficha registro de cada auto. Cada vehículo tiene su propia información: código, descripción, marca (por ej: Ford Fiesta), modelo (por ej: 1996), estado (alquilado, disponible para alquilar o en reparación). Por cada vehículo lleva nota de todas las reparaciones que recibió. De cada reparación mantiene la fecha, motivo, costo de la reparación, cantidad de días que el auto no estuvo disponible. También atiende a los clientes que traen los vehículos. Controla que el mismo se entregue en buen estado y en termino, si no es así le informa al encargado de atención al público para que no autorice nuevos alquileres a ese cliente y registra en la ficha del alquiler el kilometraje final con que se devuelve el coche. Le gustaría poder consultar los autos mas alquilados.

Para la segunda etapa de este proyecto se van a incorporar, al sistema, facilidades para hacer reservas telefónicas. En este caso, el Empleado de Atención al Publico tomará los datos del cliente, la fecha del alquiler, días por los que se va a alquilar y vehículo que reserva.

Una reserva puede ser cancelada con hasta 48 horas de anticipación. Los clientes que hagan reservas y no retiren el alquiler, no podrán efectuar nuevas reservas ni alquileres.

Al final de cada jornada, el Encargado de Autos lanzara un proceso que analizase las reservas para el próximo día y marque los autos que corresponda como reservados.

95

Autoevaluación

1. En la celda a la derecha del Termino coloque la letra de la Definición o Característica que le corresponda:


1. Requerimiento A. Requerimiento que especifica propiedades del sistema

2. Req. Funcional B. Técnica adecuada en primera toma de contacto para obtener requerimiento

3. Req. No Funcional C. Sesión de trabajo con participación de todos los involucrados

4. Usabilidad D. Condición o capacidad a la que debe ajustarse el sistema que se construye

5. Entrevista F. Conjunto coherente de roles que usuarios del sistema pueden jugar

6. JAD G. Conjunto de escenarios, secuencia de acciones entre actor y sistema

7. Actor H. Restricción que debe cumplirse para que se inicie un caso de uso

8. Caso de uso I. Requerimiento que especifica comportamiento de entrada / salida del sistema

9. Precondición J. Se considera los pasos normales, no incluye alternativas o variaciones

10. Flujo básico 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


Sitio de Alistair Cockburn, sobre recursos e información de casos de uso http://alistair.cockburn.us/


IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology –Description. http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.


Jacobson,I., et al, (1993). Object-Oriented Software Engineering: A Use case Driven Approach. USA. Addison Wesley.

Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos. Segunda Edición. Madrid. Pearson Educación S.A.

Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial Pearson.

http://alistair.cockburn.us/

http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html

96

GLOSARIO

Actividad Es una unidad de trabajo que debe ser ejecutada en un proceso de desarrollo de software.

Artefacto Es una pieza de información que es producida, modificada o usada en un proceso de desarrollo de software.

Flujo de trabajo Es una secuencia de actividades que produce un resultado valioso, define una lista de actividades, trabajadores y artefactos.

Metodología Es el conjunto de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a realizar nuevo software

Modelo de análisis de negocios Describe la realización de los casos de uso del negocio mediante la interacción de los trabajadores del negocio y las entidades del negocio.

Modelo de casos de uso Es un modelo que describe los requerimientos funcionales del sistema en forma de casos de uso.

Modelo de casos de uso del negocio Es una representación de la forma en que la empresa interactúa con su entorno.

Modelo de dominio Es un modelo conceptual que muestra clases conceptuales de objetos significativos en un dominio de problema. Las clases conceptuales no muestran componentes software, ni clases software, ni responsabilidades

Organización Sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas de alguna forma (generalmente en departamentos o funciones) con arreglo a ciertas reglas de división del trabajo y comunicación que interactúan para producir bienes o servicios

Proceso de desarrollo Es una guía acerca de las actividades y tareas necesarias para construir un sistema de información.

Proceso de negocio Conjunto de actividades que toman uno o más imputs crean un outputs de valor para el cliente.

RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo, es decir define quién hace qué, cuándo y cómo.

Trabajador Es un rol que debe ser realizada por una persoa o equipo dentro de un proceso de desarrollo de software..

Sistema de información Conjunto de componentes hardware, software, base de datos, procedimientos y personas, que permiten capturar, procesar, almacenar y distribuir información para una organización.

UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado en una notación gráfica, que permite: especificar, construir, visualizar y documentar los elementos de un sistema software, así como para modelar los procesos de negocios u otros sistemas no software.

97

BIBLIOGRAFIA

1 Davenport, Thomas (1996). Innovación de Procesos: Reingeniería del trabajo a través de la tecnología de la información. España. Díaz Santos.

2 Hammer, Michel y James Champy (1995), Reingeniería. Bogotá. Grupo Editorial Norma..

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

4 IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology –Description.

http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.

5 Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software. Madrid. Pearson Educación S.A.

6 Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML. Segunda edición. Madrid. Pearson Educación S.A.

7 Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos. Mexico D.F. Prentice-Hall Hispanoamericana.

8 Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos. Segunda Edición. Madrid. Pearson Educación S.A.

9 Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Información Gerencial. 8ª Ed. México D.F. Pearson Educación.

10 Laudon, Jane y Kenneth (2006). Sistemas de información gerencial, Administración de la empresa digital. México D.F. Pearson Educación- Prentice Hall.

11 Pressman , Roger S. (2002) Ingeniería de Software. Un enfoque práctico. 5ta.Ed. Mc Graw Hill, España.

12 Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT. Mexico D.F. Prentice Hall Hispanoamericana.

13 Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial Pearson.

http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html



Libro de analisis de sistemas_UNMSM.pdf

Documents

Transcript of Libro de analisis de sistemas_UNMSM.pdf