Facultad de Ingeniería de Sistemas, Cómputo y Telecomunicaciones Sistema a Distancia
ANÁLISIS DE SISTEMAS CÉSAR LUZA MONTERO
2010
Análisis de Sistemas - Unidad I
César Luza Montero
INTRODUCCIÓN Las organizaciones están considerando el tema de los Sistemas de Información como factor clave para lograr competitividad. Se están realizando grandes inversiones para su construcción e implantación, de manera eficiente, efectiva y con niveles de calidad pertinentes. Los sistemas de información, conjunto de componentes software, hardware, base de datos, procedimientos y personal, proveen la información, reuerida por las organizaciones para apoyar las actividades de toma de decisión y controlar las operaciones del d!a a d!a. "sta información debe transmitirse a todos los niveles de la organización, de manera oportuna y confiable. "l proceso de construcción e implantación de sistemas de información implica esfuerzo conjunto de desarrolladores y clientes#usuarios, uienes realizan una serie de actividades, agrupadas en fases, conocida como $Proceso de desarrollo%, conducente a obtener un sistema de calidad ue satisfaga las necesidades de información de los clientes#usuarios. "n general, las primeras actividades del proceso de desarrollo están relacionadas con el análisis de sistemas y la especificación de reuerimientos del software. "l 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 ue le corresponde desempe&ar. 'urante la actividad de especificación de reuerimientos del software, se detalla el ámbito de funcionalidad del software, de tal manera ue cubra la totalidad de necesidades de los usuarios. La literatura especializada establece ue el ()ito de un proyecto de desarrollo de sistemas depende, en gran medida, de realizar bien el análisis de sistemas y especificación de reuerimientos del software* por lo ue 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 ue permitan afrontar con ()ito estas actividades. +recisamente, este libro tiene el propósito de promover p romover y consolidar, en el estudiante, el uso de m(todos, t(cnicas y herramientas para el análisis de sistemas y especificación de reuerimientos de software. Se enfatiza en el componente software del sistema de información, se utiliza la notación del lenguaje de modelado unificado -L/ y se sigue el proceso de desarrollo unificado 0-+/. "n otras palabras, para el análisis de sistemas se desarrolla el flujo de modelado modelado del negocio, y para la especificación especificación de reuerimientos, reuerimientos, se sigue el flujo de reuerimientos ue permitirá capturar sistemáticamente los reuerimientos usando la t(cnica de casos de uso del -L. Los contenidos de este libro se han organizado en cinco unidades temáticas. 1stas se desarrollan en lecciones ue incluyen apartados, esuemas y figuras, seg2n cuál sea la necesidad didáctica. 3ada 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 ue el estudiante comprenda y e)pliue 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 conte)to del análisis de sistemas de información.
2
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
La segunda unidad comprende los temas relacionados con el proceso de desarrollo de sistemas de información, estableciendo sus fases y actividades gen(ricas* muestra los diversos modelos de proceso de desarrollo y las metodolog!as más conocidas, y brinda una introducción al -L y al 0-+. La tercera unidad orienta, al estudiante, en el desarrollo de habilidades para la construcción de modelos de negocio* los artefactos ue se elaboran sirven de base para la determinación de reuerimientos del sistema. Se utiliza notación -L siguiendo las actividades proporcionadas por el 0-+. La cuarta unidad tiene por finalidad ue el estudiante desarrolle habilidades para representar modelos de dominio, mediante la construcción de diagrama de clases de -L. 'e esta manera, complementa los artefactos del modelo de negocios con una representación de los conceptos o entidades ue se manejan en el conte)to del negocio o dominio de la aplicación ue cubra las necesidades y reuerimientos de los usuarios# clientes. La uinta unidad permite ue el estudiante consolide habilidades para la especificación de reuerimiento usando el modelo de casos de uso del -L. Se tratan, con precisión, los conceptos de reuerimientos funcionales y no funcionales, y se elaboran, con claridad los artefactos del modelo de casos de uso4 actores, casos de uso, descripción de casos de uso y diagrama de casos de uso. "n todo el libro, las figuras o tablas ue no consignan fuente, corresponden a elaboración propia. Las figuras o tablas ue no consignan n2mero, representa representa continuación continuación del del te)to te)to donde están ubicados. "l autor.
3
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
ORIENTACIONES METODOLÓGICAS La asignatura de 5nálisis de Sistemas es de formación profesional especializada, de naturaleza teórica#practica. 6iene como propósito ue el estudiante maneje, adecuadamente, los m(todos, t(cnicas y herramientas para el análisis y especificación de reuerimientos de software como componente de un sistema de información. +ara este fin, se desarrollan las siguientes unidades temáticas4 Los Sistemas de Información en las 7rganizaciones, "l +roceso de desarrollo con 0-+ y -L, "l odelado del 8egocio, "l odelado de 'ominio, y 0euerimientos con casos de uso. 5l inicio de cada unidad temática, el estudiante dispone de una serie de preguntas ue permitirá valorar sus logros. 5l 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 ue el estudiante debe realizar, una autoevaluación ue mide el aprendizaje del estudiante, una serie de direcciones Internet para e)ploración online. "s fundamental, para el proceso de autoaprendizaje, ue el estudiante planifiue el tiempo y esfuerzo reuerido por cada unidad. 5simismo, mediante Internet, debe trabajar de manera colaborativa, fomentando el trabajo en euipo y compartiendo información. "l docente, dispondrá de un horario ue permita interactuar con los estudiantes para absolver consultas o dudas, a trav(s de Internet. "n lo ue respecta a la evaluación del aprendizaje, al final de cada unidad temática se dispone de una serie de preguntas de autoevaluación ue permite al estudiante medir sus logros de aprendizaje conceptual. 5demás, se presenta una serie de casos ue el estudiante desarrollará y ue permitirá al docente medir los logros de aprendizaje procedimental.
4
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
PRIMERA UNIDAD LOS SISTEMAS DE INFORMACIÓN EN LAS ORGANIZACIONES 9:u( es una organización, como se estructuran sus actividades, cuáles son sus niveles; 9:u( son los procesos de negocios, como se clasifican; 93uál es la diferencia entre dato, información y conocimiento; 9:u( es un sistema de información, cuáles son sus componentes, como se clasifican;
5
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Lección 1 Organización y procesos de negocios Los profesionales responsables de automatizar las actividades de una organización deben comprender los procesos de negocio ue (sta realiza a fin de identificar auellas actividades manuales ue serán reemplazas por sistemas software. "n esta lección se revisa aspectos básicos de una organización y del enfoue basado en procesos de negocios en la estructura de sus actividades.
1.1 Organización 1.1.1 ¿Qué es una organización? Seg2n el 'iccionario de la 0eal 5cademia de la Lengua, una organización es una asociación de personas reguladas por un conjunto de normas en función de d eterminados fines. Se puede considerar ue 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 ue interact2an para producir bienes o servicios
"ntradas
536I>I'5'"S
@ienes?Servicios
+ersonas?0ecursos
Las personas representan el recurso más importante de la organización, juegan distintos roles o responsabilidades cuando realizan las diversas actividades reueridas para cumplir los objetivos de la organización. Las actividades o tareas son las acciones ue 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, mauinaria, infraestructura, tecnolog!a ue sirve de soporte para realizar las actividades. =
Las figuras siguientes ue no consignen fuente, son de elaboración propia
6
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Las reglas están dadas por las pol!ticas, normas y procedimientos ue rigen el desarrollo de las actividades y uso de los recursos.
1.1.2 Estructura organizacional La estructura organizacional representa la forma en ue las personas, actividades y recursos se organizan seg2n ciertas reglas. Se han establecido diversos modelos o enfoues para la estructura de una organización* sin embargo, para el propósito de este te)to se pueden considerar dos enfoues4 "structura
"n la estructura con enfoue funcional las actividades se organizan verticalmente, en áreas funcionales, de forma altamente jeráruica, con ámbitos de control muy limitados y r!gidos figura =.A/. 3ada función busca optimizar sus propias tareas, inclusive a costa del rendimiento de global de la organización. Su foco de análisis es la tarea o función, su objetivo es la optimización de las tareas, se orienta al interior de la organización, tiene una visión fragmentada.
Investigación y 'esarrollo
+roducción
>entas
Estructura por procesos
"n la estructura con enfoue por procesos las actividades se organizan de manera horizontal, facilitando la reunificación de actividades fragmentadas figura =.B/. Se percibe las actividades como procesos ue 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.
7
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
+roceso de negocio
1.1.3 Niveles Organizacionales Los roles ue las personas desempe&an en la organización se pueden agrupar en diversos niveles organizacionales. +odemos considerar niveles relacionados con la toma de decisiones, ue agrupa a los gerentes, y nivel de operaciones, agrupa a empleados, obreros, etc., ue 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. "n la figura =.D se visualiza cuatro niveles4 "strat(gico, 5dministrativo, de 3onocimiento y 7perativo Laudon, AEED/.
Nivel Estratégico
Directores
Gerentes de Nivel Medio
Nivel Administrativo
Nivel de Conocimiento
Trabajadores del Conocimiento
Nivel Operativo
Gerentes Operativos
8
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
"n esta pirámide podr!amos agregar, debajo de su base, un bloue grande para representar las actividades operacionales o rutinarias ue tienen poca tarea de toma de decisiones. Nivel estratégico
"n 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 e)terno* 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 'irectores, Cerente Ceneral, Cerentes de 'ivisión. Nivel administrativo
"n 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 e)ceso de presupuestos en un periodo o control del rendimiento. Se incluye a los gerentes de nivel medio, como gerente de áreas4 Cerente de >entas, Cerente de 0ecursos Fumanos, Cerente de una 5gencia o Sucursal. Nivel de conocimiento
"n 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 ue realizan este tipo de actividades son los trabajadores de conocimientos. Se incluye a 5nalistas de
"n el nivel operativo, se realizan actividades de seguimiento y control de las tareas realizadas por el personal operacional, empleados, obreros, uienes 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 stocG de inventarios, otorgar pr(stamos bancarios, entre otros. Se incluye a los gerentes operativos4 Hefe de Sección de fabricación, Hefe de 3ajeros. "ste modelo de pirámide permite, a uienes desarrollan sistemas de información, visualizar el alcance de información reuerido por cada nivel* as!, en el nivel de gestión operativo, la información detallada es necesaria* mientras ue, en el nivel estrat(gico, conviene proporcionar res2menes.
9
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
1.2 Procesos de negocio 1.2.1 ¿Qué es un proceso de negocio? $-n proceso de negocio es un orden especifico de actividades a trav(s del tiempo y lugar, con un comienzo y un fin, inputs y outputs4 una estructura para la acción% 'avenport, =J/. $-n proceso de negocio es un conjunto de actividades ue toman uno o más tipos de inputs y crean un output ue es de valor para un cliente% Fammer, =B/. ediante los procesos de negocio se organizan y coordinan las actividades en función al cliente elaborando productos y servicios de valor. uchos procesos de negocios trascienden las áreas funcionales tradicionales* por ejemplo, en muchas compa&!as el proceso de ejecución de un pedido reuiere la cooperación entre la función de ventas, contabilidad y manufactura. "n 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 =.K/.
"865S
.
37865@ILI'5'
58-<536-05
0ecibir pedido
>erificar 3r(dito
+roducir pedido
Iniciar tramite
"nviar pedido
5lgunos ejemplos de proceso de negocios son4 +roceso de 5dmisión, +roceso de atr!cula, +roceso de 3ontratación de +ersonal, +roceso de
1.2.2 Clases de procesos de negocio Los procesos de negocios se pueden clasificar en4 +rincipales, de Soporte y de Cestión. Los Procesos Principales o Sustantivos son auellos ue están ligados directamente con la realización del producto y la prestación del servicio para el 3liente. Son los procesos de l!nea, hacen realidad la misión de la organización. "jemplos4
>"8'"0 +07'-367
C"S6I7850 +"'I'7
ediantes estos dos procesos el cliente interact2a con la organización. "l proceso >ender +roducto permite al cliente recibir de la organización el producto reuerido. "l proceso Cestionar +edido permite al cliente solicitar el pedido de bienes ?servicios reuerido.
10
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Los Procesos de Soporte son auellos ue proporcionan apoyo a los procesos principales o sustantivos. -sualmente están relacionados con la gestión de recursos. "jemplos4
'"S50007LL7 '" +"0S785L
I8>"S6IC53I8 '" "035'7
"n estos dos procesos no hay agente e)terno, cliente, proveedor, etc., ue interact2e con la organización. Son procesos ue apoyan a los procesos principales. Los Procesos de Gestión son auellos ue están vinculados al ámbito de las responsabilidades de la dirección. Se relacionan con actividades de planificación y control. "jemplos4
+L58I
0">ISI8
"stos dos procesos son realizados por los niveles gerenciales, no hay interacción entre alg2n agente e)terno con la organización. Son proceso ue refleja tareas gerenciales..
1.2.3 ¿Cómo se describe un proceso de negocio? -n proceso de negocio se puede describir de manera te)tual o gráfica. Se han propuestos diversos formatos para describir un proceso, pero los !tems básicos incluyen4 la entrada, las actividades, ui(n o ui(nes realizan las actividades, los recursos ue se utilizan, las reglas ue rigen el flujo de actividades y la salida. 5 continuación se muestra un ejemplo te)tual de descripción de un proceso de 0egistro de +edido para una empresa de fabricación4 =. "l cliente env!a una orden de pedido, por tel(fono, por fa) o por correo, al 'pto. 3omercial. "l pedido debe incluir la fecha de solicitud, datos del cliente y productos solicitados. A. -n empleado del departamento comercial revisa el pedido completándolo, si es necesario/, y comienza su procesamiento enviándolo al jefe t(cnico, ue está encargado de su análisis. B. "l 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. "n caso contrario, es considerado un producto especial, y el jefe t(cnico estudia su producción4 Si es viable, la fabricación del producto especial es aceptada* Si no es viable, el producto especial no será fabricado. D. -na 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/. 3ada orden de trabajo es enviada al jefe de producción, y ueda pendiente de su lanzamiento. K. "l comercial comunica al cliente el resultado final del análisis de su pedido.
11
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
"n la figura =.J, se describe el proceso de 0egistrar +edido de manera grafica, usando la t(cnica de 'iagrama de 5ctividades de -L y modelado con la herramienta 0ational 0ose de I@.
")isten diversas t(cnicas y herramientas para describir, de manera gráfica, un proceso de negocio. 'ependerá del profesional responsable, elegir auella ue se adapte mejor a las necesidades de la organización a la ue brinda sus servicios.
12
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Lección 2 Introducción a los Sistemas de información Las organizaciones reuieren 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. "n 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 'esde a&os atrás se reconoce ue la información es un recurso valioso en las organizaciones. Los gerentes, empleados y todos auellos ue integran una organización la utilizan. 3on frecuencia los empleados usan datos detallados para sus actividades de tipo operacional, los gerentes manejan información sumaria para tomar decisiones. "n muchas ocasiones se utilizan los t(rminos datos e información como sinónimos, pero son t(rminos ue tiene distinto significado. Datos
Los datos son registros de hechos observables no procesados ue no tienen significado. "n la figura A.= se aprecia algunos ejemplos de datos.
+roducto
3antidad
+recio
E=
Mapatos
=AEE
S?=EE
13
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Se puede afirmar ue los datos son la materia prima para producir información. "ntonces, en las organizaciones se procesan datos para obtener información. "n base a la información se aduiere conocimiento. 5ctualmente, se considera al conocimiento como el recurso más preciado, por ello se habla de gestión del conocimiento en las organizaciones. Conocimiento
"l conocimiento es la información conectada a decisiones, procesos y acciones capaces de aplicar esa información. +ara e)plicar 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 ue el libro de receta es información. "sta información se convierte en conocimiento cuando, una persona elabora una torta siguiendo las instrucciones y utilizando los ingredientes indicados en la receta. "n otras palabras, cuando la información se lleva a la acción se convierte en conocimiento. 'esde una perspectiva de niveles se puede considerar ue P"l nivel más bajo de los hechos conocidos son los datos. Los datos no tienen un significado intr!nseco. 'eben ser ordenados, agrupados, analizados e interpretados. 3uando los datos son procesados de esta manera, se convierten en información. La información tiene una esencia y un propósito. 3uando la información es utilizada y puesta en el conte)to o marco de referencia de una persona, se transforma en conocimiento. "l conocimiento es la combinación de información, conte)to y e)periencia%. Farris, =J/. La figura A.B trata de e)plicar las diferencias entre datos, información y conocimiento desde una perspectiva de niveles.
37873II"867
I8<7053I8
Información conectada a decisiones, procesos y acciones capacea de aplicar esa información
Fechos agrupados para un propósito
'567 3olección de hechos
2.2 ¿Qué es Sistema de información? $-n sistema de información es un conjunto de componentes interrelacionados ue 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 ue la rodea% Laudon, AEED/.
14
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
-n sistema de información recibe y procesa los datos de manera eficaz, sin errores, eval2a la calidad de los datos de entrada, almacena los datos de modo ue est(n disponibles cuando el usuario lo crea conveniente, elimina la información poco 2til evitando redundancias, brinda seguridad evitando la perdida de información o la intrusión de personal no autorizado o agentes e)terno a la compa&!a y genera información de salida, en el momento oportuno, y 2til 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. -na organización puede aduirir nuevas computadoras, instalar redes, desarrollar páginas Reb, etc., pero ello no significa ue se implemente sistema de información. "l significado del t(rmino sistema de información abarca más ue los elementos computacionales, incluye, tambi(n, el modo de organizar dichos elementos, la forma de usarlos y los roles ue desempe&an las personas en su e)plotación para obtener la información ue apoye las actividades de la empresa.
2.3 Componentes de un Sistema de información Se puede considerar ue los componentes de un sistema de información son4 el hardware, el software, la base de datos, los procedimientos y el personal. "stos elementos interact2an entre s! para lograr el objetivo del4 proveer información para apoyar a la empresa figura A.D/.
Software
Sistema de
Información
'ato?información
+rocedimiento
"l hardware corresponde al elemento f!sico del sistema de información incluye las redes computacionales y de telecomunicaciones. "l software corresponde a los programas de aplicación. La base de datos representa el almac(n de los datos e información reuerida 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
15
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
2.4 Tipos de sistemas de información 'e acuerdo con los intereses, especialidades y niveles en una organización, se pueden identificar los siguientes tipos de sistemas de información Laudon, AEEJ/4 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 ejemplo4 ventas, ingresos, depósitos en efectivo, nomina, decisiones de cr(dito y flujo de materiales en una fábrica. 0esponden a preguntas de rutina y siguen el flujo de transacciones a trav(s de la organización. +or ejemplo, 93uántas partes hay en inventario; 9:u( pasó con el pago del se&or Cuti(rrez; Los sistemas de información de nivel del conocimiento apoyan a los trabajadores del conocimiento de datos de una organización. Su objetivo es ayudar a las empresas comerciales a integrar el nuevo conocimiento en los negocios y ayudar a la organización a controlar el flujo del trabajo de oficina. "stos 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 ue plantean estos sistemas es4 9>an bien las cosas; +or lo general, este tipo de sistemas proporcionan informes periódicos más ue información instantánea de operaciones. 5poyan a las decisiones no rutinarias y tienden a enfocarse en decisiones menos estructuradas para las cuales los reuisitos 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 e)terno. Su función principal es compaginar los cambios del entorno e)terno con la capacidad organizacional e)istente. Seg2n la función ue desempe&an o el tipo de usuario final del mismo, se pueden clasificar en Laudon, AEEJ/4 Sistema de procesamiento de transacciones, Sistemas de información gerencia, Sistema de soporte a la toma de decisiones, Sistemas de información ejecutiva, Sistemas de automatización de oficinas, Sistemas e)pertos y Sistemas de +lanificación de 0ecursos "mpresariales. Sistema de procesamiento de transacciones 6ransaction +rocess System# TPS/ son
auellos ue permiten gestionar la información referente a las transacciones producidas en una empresa u organización. Sistema de información gerencial anagement Information System # MIS/ son auellos
orientados a solucionar problemas empresariales en general. Sistema de soporte a decisiones 'ecision Suport System # DSS/ son auellas ue sirve de
herramienta para realizar el análisis de las diferentes variables de negocio con la finalidad de apoyar el proceso de toma de decisiones. Sistema de información ejecutiva ")ecutive Information System # EIS/ son auellas
herramientas orientadas a usuarios de nivel gerencial, ue permite monitorizar el estado de las variables de un área o unidad de la empresa a partir de información interna y e)terna a la misma.
16
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Sistema de automatización de oficinas 7ffice 5utomation System # OS/ son
aplicaciones destinadas a ayudar al trabajo diario del administrativo de una empresa u organización. Sistemas e!pertos ")pert System # SE/ emulan el comportamiento de un e)perto en un
dominio concreto. Los Sistemas de Planificación de "ecursos Empresariales "nterprise 0esource +lanning # E"P/ integran la información y los procesos de una organización en un solo sistema. 6odos estos sistemas de información a su vez podr!an analizarse seg2n las diferentes áreas de la empresa4 ventas y mercadotecnia, manufactura y producción, finanzas, contabilidad y recursos humanos. +ara cada una de estas áreas e)iste un conjunto especifico de aplicaciones informáticas y euipos, 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 e)istencia de redundancia de datos y la e)istencia de ineficiencias e incrementos de costes de comunicación.
17
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Resumen Organización # Procesos de Negocio •
•
-na 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 ue interact2an para producir bienes o servicios. La estructura organizacional representa la forma en ue las personas, actividades y recursos se organizan. +uede ser de dos tipos* funcional o de procesos.
•
•
• •
•
•
-n proceso de negocio es un conjunto de actividades ue toman uno o más tipos de inputs y crean un output ue es de valor para un cliente. 3lases de +rocesos de 8egocios +rincipales4 ligados con realización del producto ? lprestación del servicio para el 3liente. 'e Soporte4 apoyan los procesos principales. 0elacionados con la gestión de recursos. 'e Cestión4 vinculados a la dirección. Se relacionan con actividades de planificación y control. -n proceso de negocio se puede describir en forma grafica o te)tual. • • •
•
Introducción a los sistemas de información • •
•
•
•
•
Los datos son registros de hechos observables no procesados ue no tienen significado. La información es un conjunto de hechos agrupados para alg2n propósito en particular. Son datos procesados ue tienen significado. "l conocimiento es la información conectada a decisiones, procesos y acciones capaces de aplicar esa información. -n sistema de información es un conjunto de componentes interrelacionados ue permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el control en una institución. Los 3omponentes de un sistema de información son4 Fardware, Software, @ase de datos, +ersonas usuarios finales y personal de 6.I./ y +rocedimientos. 6ipos de sistema de información 'e acuerdo a intereses4 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 Seg2n función ue desempe&a4 Sistema de procesamiento de transacciones 6+S/, Sistema de información Cerencial IS/, Sistema de soporte a las decisiones 'SS/, Sistema de información ejecutiva "IS/, Sistema de automatización de oficinas 75S/, Sistema ")perto S"/, Sistema de planificación de recursos empresariales "0+/. •
•
.
18
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Lectura B ACKUS: INTEGRANDO PROVEEDORES A LA CADENA DE SUMINISTROS (*)
La necesidad de automatizar procesos y generar valor en las actividades de las diferentes áreas de una organización se ha convertido en una tendencia cada vez más frecuente en las empresas, ello gracias a los beneficios ue ofrece el e#business. "s as!, ue -nión de 3ervecer!as +eruanas @acGus y Hohnston dando un paso adelante con la tecnolog!a, viene implementando mejoras en todos sus procesos para operar con estándares de clase mundial ue tiendan a la satisfacción de sus clientes y la integración de sus proveedores como socios de negocios. 0afael 6ruc!os, Cerente de +lanning y arGeting de ebiz Latin 5merica, empresa especialista en soluciones e#business y operador tecnológico de @acGus, conversó con 3(sar 3ampodónico, Cerente de 'esarrollo de +roveedores con la finalidad de dar a conocer la forma de trabajo con proveedores y los beneficios obtenidos al implementar ebiz en @acGus. $'esde ue empezamos el proyecto e#commerce de ebiz en el a&o AEED, hemos implementado nuevas soluciones integradas a nuestro sistema transaccional con la finalidad de agilizar nuestro proceso de abastecimiento y dar un mejor servicio a nuestros clientes internos, automatizando no solo nuestros procesos Log!sticos, sino tambi(n 3ontables%, comentó 3(sar 3ampodónico. $"n la actualidad, @acGus ha implementado el módulo de +eticiones de 7ferta, "nv!o de cotizaciones, "nv!o de órdenes de compra, >isualización de estado de comprobantes de pago, Impresión de comprobantes de retención y pró)imamente el módulo de 0egistro de facturas para proveedores%, agregó. +or otro lado, 3ampodónico comentó cuales fueron las caracter!sticas principales del servicio ofrecido por ebiz ue permitió tomar una decisión al momento de hacer la integración en S5+4 • • • • • • • • •
3ustomización a las e)igencias seg2n modelo de negocio de @acGus.
5s! mismo, dentro de los beneficios obtenidos por la relación +roveedor ? 3liente se comentó la reducción de costos por negociación consolidada, la funcionalidad personalizada a las prácticas del negocio, el mejor control de la operación log!stica y el incremento de nivel de servicio al cliente interno, todo ello orientado a cumplir los objetivos ue persigue el modelo de gestión de cadena de suministro.
LinG4 http4??www.generaccion.com?noticias?online?detalle.php;idVADDDN
19
Sistema a Distancia
Análisis de Sistemas - Unidad I
César Luza Montero
Actividades = A
Identifiue una organización, de cualuier tipo o tama&o, y realice la descripción de uno de sus procesos de negocio de tipo principal. @usue y e)pliue algunas t(cnicas de modelado de procesos de negocio y elabore un ejemplo de cada una.
Autoevaluación 3ontestar las siguientes preguntas4 = -na organización es un sistema compuesto por A La estructura con enfoue de proceso se caracteriza por4 B Los niveles de gestión de una organización son4 D -n proceso de negocio es4 K Los tipos de procesos de negocios son4 J La diferencia entre dato e información es N La diferencia entre información y conocimiento es O -n sistema de información es4 Los componentes de un sistema de información son4 =E Los tipos de sistemas de información son4
Exploración on-line •
•
+ortal del 3I7, +ortal de la 3ompa&!a I@ sobre transformación de procesos de negocio para incrementar la fle)ibilidad empresarial a trav(s de S75* contiene documentos, videos y casos de estudio. https4??www#BK.ibm.com?services?es?cio?fle)ible? 7C, 7bject anagement Croup ? @usiness +rocess anagement Initiative +agina de la 7rganización Internacional 7C 7bject anagement Croup/ ue contiene información de estándares de modelado de procesos de negocios. http4??www.bpmn.org?
Referencias bibliográficas =
'avenport, 6homas =J/. I$$o,ac#-$ de Procesos: Re#$.e$#er/a del 0ra"a1o a 0ra,2s de la 0ec$olo./a de la #$3or4ac#-$. "spa&a. '!az Santos.
A
Fammer, ichel y Hames 3hampy =B/, Ree$.#$eer#$. 0he Corora0#o$: A Ma$#3es0o 3or B!s#$ess Re,ol!0#o$. -S5. 3ollins @usiness "ssentials.
B
Farris, 'avid =J/. Crea0#$. a K$o5led.e Ce$0r#c I$3or4a0#o$ Tech$olo.6 E$,#ro$4e$0 . -S5. "ditorial Farris 6raining W 3onsulting Services Inc.
D
Laudon, Hane y enneth +. Laudon, H. AEED/ Sistemas de Información Cerencial. OX "d. ()ico '.<. +earson "ducación.
K
Laudon, Hane y enneth AEEJ/. S#s0e4as de #$3or4ac#-$ .ere$c#al7 Ad4#$#s0rac#-$ de la e4resa d#.#0al . ()ico '.<. +earson "ducación# +rentice Fall.
20
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
SEGUNDA UNIDAD EL PROCESO DE DESARROLLO, RUP Y UML ¿Qué es un proceso de desarrollo, cuales son sus fases y actividades genéricas? ¿Cuáles son los modelos de proceso de desarrollo? ¿Qué es metodología, técnica y herramienta de desarrollo? ¿Qué es el UML y cuales son sus elementos, relaciones y diagramas? ¿Qué es el U! y cuales sus fases y flu"os, artefactos, tra#a"adores, actividades?
21
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Lección 3 Proceso de desarrollo de sistemas de información La construcci$n de un sistema de informaci$n implica un esfuer%o con"unto de profesionales de tecnología de informaci$n y líderes de la organi%aci$n& 'ste esfuer%o implica reali%ar una serie de actividades conducentes a o#tener un sistema de calidad& 'sta serie de actividades se conoce como proceso de desarrollo (ue deviene en metodologías de desarrollo& 'sta lecci$n ayuda comprender las características de un proceso de desarrollo, los modelos (ue e)isten 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? 'l proceso de desarrollo es una guía acerca de las actividades y tareas necesarias para construir un sistema de informaci$n& 'n el conte)to de soft*are, programas de aplicaci$n o aplicaciones informáticas, !ressman +--. considera al Proceso como un marco de tra#a"o (ue define las tareas a reali%ar para desarrollar soft*are de alta calidad& /e han esta#lecido diversos modelos de proceso de desarrollo de sistemas de informaci$n, con actividades y tareas específicas0 pero se puede esta#lecer una serie de actividades comunes (ue llamaremos visi$n genérica con las siguientes fases +!ressman, --.1 2efinici$n, 2esarrollo y 'voluci$n& 3igura 4&5 3ases del proceso de desarrollo1 6isi$n genérica 2efinici$n Análisis del Sistema • Requerimientos • Planificación •
2esarrollo Diseño • Codificación • Prueba •
'voluci$n Corrección Adaptación • Mejora • •
3uente1 +!ressman, --.
3.1.2 Fase de Definición 'l prop$sito de la fase de 2efinici$n es identificar las necesidades o re(uerimientos del cliente7usuario, tales como1 la informaci$n (ue de#e ser proporcionada, la funcionalidad y rendimiento (ue se desea, las interfaces (ue de#en esta#lecerse, las restricciones de dise8o (ue e)isten y los criterios de validaci$n (ue se necesitan para definir un sistema correcto& 'n esta fase, se reali%an las siguientes actividades1 9nálisis del /istema, e(uerimientos del /oft*are y !lanificaci$n del !royecto&
22
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Análisis del sistema. 2efine el papel de cada elemento del sistema de informaci$n,
asignando finalmente al soft*are el papel (ue va a desempe8ar& Requerimientos del software. 'l ám#ito esta#lecido para el soft*are proporciona la
direcci$n a seguir, pero antes de comen%ar a tra#a"ar es necesario disponer de una informaci$n mas detallada del ám#ito de la funcionalidad del soft*are& Planificación del proyecto de software . Una ve% esta#lecido el ám#ito del soft*are, se
anali%an los riesgos, se asignan los recursos, se estiman los costes, se definen las tareas y se planifica el tra#a"o&
3.1.3 Fase de Desarrollo 'l prop$sito de la fase de 2esarrollo es determinar c$mo han de dise8arse las estructuras de datos y la ar(uitectura del soft*are, c$mo han de implementarse los detalles procedimentales, c$mo ha de traducirse el dise8o a un lengua"e de programaci$n y c$mo ha de reali%arse la prue#a& 'n general se aplicarán tres pasos concretos1 2ise8o del /oft*are, Codificaci$n y !rue#as del soft*are& Diseño de software &
'l dise8o traduce los re(uisitos de soft*are a un con"unto de representaciones +algunas gráficas y otras ta#ulares o #asadas en lengua"es. (ue descri#en las estructuras de #ases de datos, la ar(uitectura, el procedimiento algorítmico y las características de la interfa%& Codificación&
Las representaciones del dise8o de#erán ser traducidas a un lengua"e artificial +un lengua"e de programaci$n convencional o un lengua"e no procedimental :;<., dando como resultado unas instrucciones e"ecuta#les en la computadora& Prueba del software& Una ve% (ue el soft*are ha sido implementado en una forma
e"ecuta#le por la ma(uina, de#e ser pro#ado para descu#rir los defectos (ue puedan e)istir, en la funci$n, en la l$gica y en la implementaci$n&
3.1.4 Fase de Evolución La fase de 'voluci$n, tam#ién llamada fase de mantenimiento, se centra en los cambios (ue van asociados a la correcci$n de errores, a las adaptaciones re(ueridas por la evoluci$n del entorno del soft*are y a las modificaciones de#idas a los cam#ios de re(uisitos del usuario dirigidos a refor%ar o ampliar el sistema& La fase de mantenimiento vuelve a aplicar las fases de definici$n y de desarrollo, pero en el conte)to del soft*are ya e)istente& /e encuentran tres tipos de cam#io1 Correcci$n, 9daptaci$n y Me"ora& Corrección& =ncluso llevando a ca#o las me"ores actividades de garantía de calidad, es
muy pro#a#le (ue el cliente descu#ra defectos en el soft*are& 'l mantenimiento correctivo cam#ia el soft*are para corregir los defectos& Adaptación. Con el paso del tiempo es pro#a#le (ue cam#ie el entorno original +sistemas
operativos, e(uipos periféricos, etc&. para los (ue se desarrollo el soft*are& 'l mantenimiento adaptativo consiste en modificar el soft*are para acomodarlo a los cam#ios de su entorno e)terno&
23
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Mejora. Conforme utilice el soft*are, el usuario puede descu#rir funciones adicionales
(ue podrían interesar (ue estuvieran incorporadas en el soft*are& 'l mantenimiento perfectivo amplia el soft*are más allá de sus re(uisitos funcionales originales&
3.2 Modelos de Proceso de desarrollo de software La implementaci$n de un proceso de soft*are puede variar de acuerdo a la naturale%a1 del proyecto, de la aplicaci$n de los métodos a seguir y de las herramientas a utili%ar& /e han esta#lecido diversos modelos, conocidos como >ciclo de vida del soft*are& 'n esencia, los modelos de ciclo de vida del soft*are permiten determinar las fases productivas de un proyecto, los o#"etivos de cada fase productiva, los productos o#tenidos en cada una de estas fases, así como sus características y los roles (ue se desempe8an en cada fase& Los modelos de proceso de soft*are se puede clasificar en1 /ecuencial, =terativos y 'volutivos& 'l modelo secuencial se caracteri%a por(ue las actividades del desarrollo progresan de manera secuencial& Una actividad no puede iniciar si no ha terminado la anterior& Los modelos iterativos se caracteri%an por(ue las actividades se repiten de manera cíclica& 'ntre los modelos iterativos podemos mencionar1 Construcción de prototipos y Desarrollo Rápido de Aplicaciones& Los modelos evolutivos se caracteri%an por(ue son iterativos y en cada iteraci$n se agrega nueva funcionalidad +versiones. al sistema& /e ha dado gran impulso a estos modelos pues la realidad demuestra (ue los re(uisitos suelen cam#iar a medida (ue el desarrollo avan%a, haciendo (ue no se puedan cumplir con las metas fi"adas inicialmente respecto de un producto final completo0 otras veces, si #ien se han captado claramente los re(uisitos centrales todavía falta definir los detalles& 'ntre los modelos evolutivos podemos mencionar el modelo incremental y el modelo espiral &
3.2.1 Modelo Lineal Secuencial 'ste modelo, tam#ié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& :al como su nom#re lo indica, progresa en forma secuencial desde una primera fase de 9nálisis de /istemas, avan%ando a través de e(uerimientos, el 2ise8o, la Codificaci$n, la !rue#a y el Mantenimiento +figura 4&. & 3igura 4& Modelo lineal secuencial 9nálisis de /istemas
e(uerimientos de soft*are
2ise8o
Codificaci$n
!rue#a
Mantenimiento
'n este modelo, los re(uerimientos de#en estar claramente identificados desde el inicio& /in em#argo, la realidad se8ala (ue raramente el cliente e)pone todos los re(uerimientos desde el inicio& 'n consecuencia, pueden surgir cam#ios durante el desarrollo lo (ue afectará la planificaci$n esta#lecida& Cuando se trata de proyectos grandes, el cliente de#e tener paciencia por(ue no verá una versi$n operativa del sistema sino hasta (ue el proyecto esté muy avan%ado& 9demás,
24
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
esto hace (ue no e)ista una validaci$n por parte del cliente hasta muy tarde& /i en estas etapas finales se detectase un error grave las consecuencias son desastrosas& 9un(ue este modelo puede tener sus de#ilidades, siempre es me"or (ue un enfo(ue hecho al a%ar y puede resultar #ueno cuando se trate de un proyecto donde todos los re(uerimientos están claramente definidos desde el comien%o&
3.2.2 Modelo Construcción de Prototipos Muchas veces, en los proyectos de desarrollo, no todos los re(uisitos están claros desde el inicio0 en esta situaci$n puede resultar conveniente aplicar el Modelo de Construcción de Prototipos& 'n este modelo el ciclo comien%a con la captura de re(uerimientos del cliente por parte del desarrollador& Luego, el desarrollador construye un prototipo de >dise8o rápido concentrado en las interfaces de entrada y salida0 (ue se constituye en la primera versi$n& 'ste prototipo es evaluado por el cliente y sirve para refinar los re(uerimientos& /e inicia nuevamente el ciclo, conocido como iteraci$n +figura 4&4.& Lo ideal es (ue este prototipo sirva s$lo para identificar los re(uisitos y una ve% (ue esto se logr$ se lo deseche0 generalmente, estos prototipos, si son operativos +*or@ing prototype. suelen ser muy lentos o muy grandes o torpes o las tres cosas a la ve%& Lo ideal es, ahora, construir una versi$n redise8ada en la (ue estos pro#lemas no estén presentes. 3igura 4&4 Modelo Construcci$n de prototipos
3uente1 +9daptado de !ressman, --.
'n este modelo, cuando el cliente o#serva el prototipo operativo, cree (ue es la versi$n final del sistema, sin entender (ue se trata de solo un prototipo y (ue el producto no está terminado& !or la presi$n de hacer (ue el prototipo funcione rápidamente, el desarrollador puede elegir, inadecuadamente, el sistema operativo o el lengua"e de programaci$n0 incluso, puede usar un algoritmo incorrecto& 2espués de algAn tiempo, puede familiari%arse con estas elecciones y olvidarse las ra%ones por las cuales son inadecuadas, de"ándolas luego como una parte integral del sistema& 9un(ue pueden surgir estos pro#lemas, éste es un modelo Atil a la hora de construir un sistema donde no se tiene claros los re(uisitos inicialmente& La clave está en esta#lecer claramente, al principio, las reglas de "uego con el cliente y llegado el momento, no ceder a la presi$n de éste para conservarlo como producto final&
25
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
3.2.3 Modelo Desarrollo Rápido de Aplicaciones (DRA) 'l Modelo de Desarrollo Rápido de Aplicaciones (DRA), Rapid Application Development (RAD), es un modelo lineal secuencial con un ciclo e)tremadamente corto& La rapide% se logra gracias al reAso de componentes, al empleo de :écnicas de Cuarta
informaci$n mane"a el proceso de negocio?, ¿(ué informaci$n se genera?, ¿(uién la genera?, ¿a d$nde va esa informaci$n?, ¿(uién la procesa? Modelo de Datos1 a partir del estudio del flu"o de informaci$n en la fase anterior, se
construye un modelo de datos (ue muestra los o#"etos, atri#utos y relaciones entre dichos o#"etos& Modelo de Procesos: en esta fase se construye un modelo de procesos donde se
muestran las transformaciones necesarias so#re los o#"etos del modelo de datos a los efectos de lograr la funcionalidad deseada& Generación de Aplicaciones1 en esta fase se genera la aplicaci$n con el empleo de
técnicas de cuarta generaci$n, además de reBusar componentes e)istentes +cuando es posi#le. y la creaci$n de componentes reutili%a#les +cuando es necesario.& Prueba y Entrega 1 2ado (ue enfati%a la reutili%aci$n de componentes, los cuales ya han
sido pro#ados, el tiempo de prue#a se ve reducido& /in em#argo se de#en pro#ar todos los componentes nuevos y las interfaces entre m$dulos& 3igura 4&; Modelo 29
3uente1 +!ressman, --.
26
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
'n este modelo, cuando el proyecto es grande, se re(uiere un gran nAmero de personas para formar e(uipos paralelos suficientes& e(uiere de un alto compromiso por parte de clientes y desarrolladores en lo (ue al tiempo se refiere& /i esto falla, el proyecto fracasa& o todos los tipos de aplicaciones son aptos para aplicar este modelo& !or e"emplo, no son aptos a(uellos sistemas (ue no se pueden modulari%ar, tampoco funciona #ien para a(uellos donde e)iste un #a"o reuso de componentes, ya (ue nuevos de#en ser desarrollados y pro#ados& o es apropiado cuando e)isten riesgos tecnol$gicos altos& !or e"emplo, cuando se hace uso de una nueva tecnología, o cuando el soft*are nuevo re(uiere de una alta interopera#ilidad con otros ya e)istentes&
3.2.4 Modelo Incremental 'n el Modelo =ncremental, se aplica, repetidamente, el modelo Lineal /ecuencial& Cada secuencia lineal entrega una versi$n operativa, llamada incremento& 'l primer incremento entrega la funcionalidad correspondiente a los re(uerimientos #ásicos, el siguiente agrega nueva funcionalidad a la anterior y así, sucesivamente, hasta o#tener el producto final +3igura 4&D.& !or e"emplo, para un editor de te)tos, 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& 9l finali%ar cada incremento, el cliente reci#e una versi$n operativa del producto y lo evalAa& Como resultado de su utili%aci$n y evaluaci$n, se desarrolla un plan para el siguiente incremento& 'ste plan contempla la modificaci$n del producto central para cumplir me"or con las necesidades del cliente y además para agregar nueva funcionalidad& 3igura 4&D Modelo =ncremental
Fuente: (adaptado de Pressman, 2002)
'ste modelo es particularmente Atil cuando no se está seguro de poder cumplir con los pla%os de tiempo de#ido a falta de personal de desarrollo, o cuando se tenga una fecha
27
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
imposi#le de cam#iar, ya (ue en todos los casos, el cliente se (ueda con una versi$n operativa del producto&
3.2.5 Modelo Espiral 'l Modelo en Espiral es un modelo iterativo (ue proporciona en cada iteraci$n una versi$n evolutiva +incremento. del producto& 2urante las primeras iteraciones la versi$n incremental podría ser un prototipo o un modelo en papel& 2urante las Altimas iteraciones se producen versiones cada ve% más completas del soft*are& 'l modelo divide las actividades en regiones, generalmente entre tres y seis& 'n la figura 4&E, se o#serva un modelo espiral (ue contiene seis regiones1 Comunicaci$n con el Cliente, !lanificaci$n +se definen recursos y tiempo., 9nálisis de iesgos +se evalAan riesgos técnicos y de gesti$n., =ngeniería +se construyen modelos de la aplicaci$n a desarrollar., Construcci$n y 'ntrega +se construye, prue#a, instala y proporciona soporte al usuario., 'valuaci$n del Cliente& 'l proceso comien%a desde el centro, girando en el sentido de las agu"as del relo"& 'n la figura 4&E, 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 mAltiples iteraciones dentro de un circuito. ; luego, circuitos sucesivos podrían ser usadas para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. 3igura 4&E Modelo 'spiral
Fuente: (adaptado de Pressman, 2002)
9 diferencia del modelo lineal secuencial (ue termina cuando se entrega el soft*are, el modelo en espiral puede ser adaptado para ser aplicado a un proyecto (ue se encuentre en cual(uier punto del ciclo de desarrollo& Cada cu#o en la figura 4&E representa un punto de entrada para un tipo diferente de proyecto& !odemos arrancar desde el cu#o de más adentro para el caso de un proyecto de desarrollo de conceptos hasta (ue el desarrollo del modelo conceptual haya finali%ado& /i el concepto va a ser desarrollado en un producto real, el proceso avan%a hasta el pr$)imo cu#o, y así sucesivamente para los distintos tipos de proyectos& 2e esta forma, el proceso puede permanecer parado por un tiempo, pero siempre (ue un cam#io ocurre, el proceso reinicia desde el punto de entrada apropiado +por e"emplo, proyecto de me"ora del producto.&
28
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
3.3 Metodologías 9sociado al concepto de proceso de desarrollo de sistemas de informaci$n, soft*are, o aplicaciones informáticas, está el concepto de Metodología de 2esarrollo& Una Metodolo!a es el con"unto de procedimientos, técnicas, herramientas, y un soporte documental (ue ayuda a los desarrolladores a reali%ar nuevo soft*are +!ressman, --D.& Una metodología representa el camino a seguir para desarrollar soft*are o aplicaciones informáticas de una manera sistemática, consiste de un con"unto de fases su#divididas en etapas, actividades y tareas& Una tarea es una actividad elemental siguiendo algAn procedimiento& 'l procedimiento es la definici$n de la forma de e"ecutar la tarea& La t"cnica es la herramienta utili%ada para aplicar un procedimiento& /e pueden utili%ar una o varias& Una #erramienta es el soporte soft*are (ue apoya la aplicaci$n de una técnica& Un producto es el resultado de cada fase, etapa o actividad de una metodología& /e han esta#lecido diversas metodologías para el desarrollo de sistemas de informaci$n, algunas de las mas citadas son1 U!, MF:=C9 64, Merisse, //92M 6;, M2/=&
3.3.1 RUP ational Unified !rocess, de la compa8ía =GM, es una plataforma de proceso de desarrollo de soft*are configura#le (ue entrega me"ores prácticas compro#adas y una ar(uitectura configura#le& !ermite seleccionar y desplegar solamente los componentes de proceso (ue usted necesita para cada etapa de su proyecto& 'l U! es un proceso de desarrollo de soft*are y "unto con UML +Lengua"e Unificado de Modelado., constituye la metodología estándar más utili%ada para el análisis, implementaci$n y documentaci$n de sistemas orientados a o#"etos& Lin@1 http177***B-5&i#m&com7soft*are7pe7rational7rup&shtml
3.3.2 MÉTRICA V3 MF:=C9, versi$n 4, Metodología de !lanificaci$n, 2esarrollo y Mantenimiento de /istemas de =nformaci$n, del Conse"o /uperior de 9dministraci$n 'lectr$nica del Ministerio de la !residencia del
•
•
•
!roporcionar o definir /istemas de =nformaci$n (ue ayuden a conseguir los fines de la Hrgani%aci$n mediante la definici$n de un marco estratégico para el desarrollo de los mismos& 2otar a la Hrgani%aci$n de productos soft*are (ue satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de re(uisitos& Me"orar la productividad de los departamentos de /istemas y :ecnologías de la =nformaci$n y las Comunicaciones, permitiendo una mayor capacidad de adaptaci$n a los cam#ios y teniendo en cuenta la reutili%aci$n en la medida de lo posi#le& 3acilitar la comunicaci$n y entendimiento entre los distintos participantes en la producci$n de soft*are a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsa#ilidad, así como las necesidades de todos y cada uno de ellos&
29
Sistema a Distancia
Análisis de Sistemas - Unidad II
•
César Luza Montero
3acilitar la operaci$n, mantenimiento y uso de los productos soft*are o#tenidos&
Lin@1 http177***&csae&map&es7csi7metrica47inde)&html
3.3.3 Merisse Merise es un método integrado de análisis, concepci$n y gesti$n de proyectos, desarrollado en 3rancia, (ue provee un marco metodol$gico y un lengua"e comAn riguroso para los desarrollos informáticos& 's una metodología de modelado de prop$sito general en el ám#ito del desarrollo de sistemas de informaci$n, ingeniería de soft*are y gesti$n de proyectos& 3ue introducido en la década de 5IJ-, desarrollado y perfeccionado hasta el punto en (ue las organi%aciones no gu#ernamentales 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 fases1 conceptual, l$gico y físico& 2el mismo modo, la vista de proceso pasa a través de tres etapas1 conceptual, organi%acional y operacional& 'stas etapas en el modelado de proceso son paralelas con las etapas del ciclo de vida1 planificaci$n estratégica, el estudio preliminar, un estudio detallado, desarrollo, implementaci$n y mantenimiento& Lin@1 http177merise&developpe%&com7
3.3.4 SSADM V4 'l Método de análisis y dise8o estructurado de sistemas +//92M /tructured /ystems 9nalysis and 2esign Method +//92M. es un enfo(ue de sistemas para el análisis de sistemas de informaci$n0 fue producido por Central Computer and :elecommunications 9gency +nahora Hffice of
3.3.5 MDSI La metodología M2/= 6ersi$n &-, es una herramienta desarrollada en #ase a la metodología de Métrica 4 del Ministerio de 9dministraci$n !A#lica de 'spa8a +M9!. y U! +ational Unified !rocess., han sido revisados y adaptados para su aplicaci$n en las entidades integrantes del /istema acional de =nformática por la Hficina acional de
30
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Lección 4 Introducción al UML
4.1 ¿Qué es el UML? UML +Unified Modeling Language, Lengua"e de Modelado Unificado. es un lengua"e, #asado en una notaci$n gráfica, (ue permite1 especificar, construir, visuali%ar y documentar los elementos de un sistema soft*are, así como para modelar los procesos de negocios u otros sistemas no soft*are +aco#son, --E.& !uede ser utili%ado por cual(uier metodología de desarrollo orientada a o#"etos& 'ste lengua"e es el resultado de la unificaci$n de los métodos de modelado orientados a o#"etos de1
4.2 Artefacto, Modelo y Diagrama Artefacto
Un artefacto representa la informaci$n (ue es utili%ada o producida durante un proceso de desarrollo de soft*are& '"emplo1 documento de especificaci$n de re(uisitos, un modelo, un programa& Modelo
Un modelo es una representaci$n a#stracta de una especificaci$n, un dise8o o un sistema desde un punto de vista particular& epresenta uno o más diagramas& '"emplos1 modelo de casos de uso, modelo de negocio& Diarama
Un diagrama es una representaci$n gráfica de una colecci$n de elementos del modelo& '"emplos1 diagrama de casos de uso, diagrama de clases&
4.3 Elementos en UML Los elementos del UML se clasifican en1 estructurales, de comportamiento, de agrupaci$n y de anotaci$n& $lementos $structurales
Los elementos estructurales representan la parte estática del sistema& /e incluyen +figura ;&5.1 Clase, =nterfa%, nodo, caso de uso, interfa%, clase activa, componente, cadena de responsa#ilidad& Clase
3igura ;&5 'lementos estructurales del UML Colaboración Interfaz
31
Caso de uso
Nodo Coponente
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
La Clase representa un con"unto de o#"etos (ue comparten los mismos atri#utos, operaciones, relaciones y semántica& La =ntera! representa la definici$n un con"unto de especificaciones de operaciones La Colaboración representa una iteraci$n, es una sociedad de roles y otros elementos (ue cola#oran cooperativamente 'l Caso de "so representa una funcionalidad del sistema, es un con"unto de secuencias de acciones (ue se e"ecutan con el o#"etivo de lograr un resultado de interés para un grupo de usuarios en particular& 'l Componente representa es empa(uetamiento físico de diferentes elementos l$gicos como clases, interfaces, y cola#oraciones& 'l #odo representa a un elemento físico del sistema, es decir un recurso computacional& $lementos de comportamiento
Los elementos de comportamiento representan la parte dinámica del sistema, es decir el comportamiento en el tiempo y el espacio& /e incluyen1 =nteracciones y estados& Estado Interacción Mensa!e
La $nteracción representa un Con"unto de mensa"es intercam#iados entre o#"etos& 'l Estado =dentifica un período de tiempo del o#"eto +no instantáneo. en el cual el o#"eto esta esperando alguna operaci$n, reci#e cierto tipo de estímulos y especifica la secuencia de estado por las (ue pasa un o#"eto& $lementos de arupación
Los elementos de agrupaci$n representan la parte organi%ativa del sistema& =ncluye1 !a(uete& Pa"uete
'l Pa%uete es el mecanismo de prop$sito general para organi%ar elementos& $lementos de anotación
Los elementos de anotaci$n representan la parte e)plicativa del sistema& /on comentarios& =ncluye1 la nota
La #ota sirve para hacer comentarios a un con"unto de elementos&
32
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
4.4 Relaciones en UML Las relaciones del UML representan los vínculos entre dos elementos del modelo& =ncluye1 dependencia, asociaci$n, generali%aci$n y reali%aci$n& Dependencia
epresenta una relaci$n semántica entre dos elementos, tal (ue un cam#io en uno de ellos +el independiente. puede afectar al otro +el dependiente.&
Asociación
epresenta una relaci$n estructural (ue descri#e un con"unto de lin@s, siendo un lin@ una cone)i$n entre o#"etos&
%enerali&ación
epresenta una relaci$n de generali%aci$n7especiali%aci$n en la (ue el elemento especiali%ado +descendiente. se construye so#re la especificaci$n del elemento generali%ado +ancestro.
Reali&ación
epresenta una relaci$n semántica en la (ue un clasificador, tal como una interfa% o un caso de uso, especifica un >contrato (ue otro clasificador, tal como una clase o una cola#oraci$n, garanti%a llevar a ca#o&
4.5 Diagramas en UML La versi$n &- del UML +Gooch, --E. considera 54 diagramas +figura ;&., divididos en 2iagramas dinámicos y estáticos& 3igura ;& diagramas del UML
3uente1 +9daptado de aco#son, --E.
33
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
'l Diarama de Clases, muestra un con"unto de clases, interfaces, cola#oraciones y sus relaciones& 'l Diarama de objetos, muestra una instantánea de un con"unto de o#"etos y sus relaciones& 'l Diarama de componentes, muestra la organi%aci$n y dependencias entre un con"unto de componentes conocida como vista de implementaci$n de un sistema. Están relacionados a Dia&ramas de clases en donde un componente se Corresponde con una o más clases interaces o colaboraciones.
'l Diarama de desplieue, muestra los enlaces de comunicaci$n física entre elementos de hard*are y las relaciones entre má(uinas físicas y procesos +(ué se e"ecuta y d$nde.& 'l Diarama de estructura compuesta, muestra la estructura interna +incluyendo partes y conectores. de un clasificador o una cola#oraci$n estructurada' 'l Diarama de paquetes, muestra la descomposici$n del modelo en unidades de organi%aci$n y sus dependencias& 'l Diarama de casos de uso , muestra un con"unto de casos de uso y actores y sus relaciones& 'l Diarama de secuencia , es un diagrama de interacci$n (ue muestra los o#"etos y actores (ue participan en una cola#oraci$n poniendo el énfasis en el ordenamiento en el tiempo de los mensa"es& 'l Diarama de colaboración, es un diagrama de =nteracci$n (ue pone el énfasis en la organi%aci$n estructural de los o#"etos o roles (ue envían y reci#en mensa"es& 'l Diarama de estados, muestra un aut$mata (ue consiste de estados, transiciones, eventos y actividades& 'l Diarama de actividades, muestra la estructura de un proceso u otro cálculo como el flu"o de control y datos paso a paso en el cálculo& 'l Diarama cronolóico, es un diagrama de interacci$n (ue muestra tiempos a lo largo de diferentes o#"etos o roles, y no secuencias relativas de mensa"es& 'l Diarama de interacciones eneral , es un hí#rido de diagramas de actividad y de secuencia&
34
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Lección 5 Introducción al RUP
5.1 ¿Qué es el RUP? 'l U! +ational Unified !rocess, !roceso Unificado de ational. es un proceso de desarrollo de soft*are, es una forma disciplinada de asignar tareas y responsa#ilidades en una empresa de desarrollo, es decir define (uién hace (ué, cuándo y c$mo +aco#son, ---.& 's un marco de tra#a"o genérico (ue puede especiali%arse& 's iterativo e incremental&
5.2 Elementos 5.2.1 Trabajador (Worker) 's un rol (ue de#e ser reali%ada por una persona o e(uipo& Un > #or$er% o rol define el comportamiento y responsa#ilidades de un miem#ro específico +o e(uipo específico.& Una misma persona puede llevar a ca#o diversos roles& 9lgunos e"emplos de rol son Líder de !royecto, 9nalista de sistemas, programador&
5.2.2 Actividad 's una unidad de tra#a"o (ue de#e ser e"ecutada& Una acti&idad es la más pe(ue8a pie%a de tra#a"o (ue es relevante& o es ra%ona#le hacer actividades en forma parcial& 2ividir el tra#a"o de esta manera hace más fácil controlar el avance del proyecto& 's me"or sa#er (ue hay 4 actividades completas de D, (ue sa#er (ue llevamos el E- de una actividad& '"emplos de actividades son !lanificar una =teraci$n, evisar el 2ise8o, Capturar re(uisitos&
5.2.3 Artefacto 's una pie%a de informaci$n (ue es producida, modificada o usada en un proceso de desarrollo de soft*are& 'n artefacto es algo (ue se produce e el curso del desarrollo de un producto de soft*are& =ncluye 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 :ra#a"ador, necesita una perspectiva del /istema& 'l 9rtefacto más comAn para representar una perspectiva es el Modelo& Los principales modelos de U! son1 Modelo del negocio, modelo de casos de uso, modelo de dise8o, modelo de implementaci$n, modelo de prue#a& 'l Modelo de egocios es el modelo de los procesos de negocio y su medioam#iente& 's usado para generar re(uerimientos de los sistemas de informaci$n (ue lo soportan& 'l Modelo de Casos de Uso es un modelo acerca de lo (ue el sistema de#e hacer y su medioam#iente&
35
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
'l Modelo de 2ise8o es un modelo de o#"etos (ue descri#en la reali%aci$n de los Casos de Uso& /irve como una a#stracci$n del Modelo de =mplementaci$n y su c$digo fuente& 'l Modelo de =mplementaci$n es un con"unto de componentes y su#sistemas (ue los contienen& 'l Modelo de :est a#arca todos los casos de test y procedimientos re(ueridos para pro#ar el sistema&
5.2.5 Flujos de trabajo (Workflow) Un flu"o de tra#a"o es una secuencia de actividades (ue produce un resultado valioso& 2efine una lista de actividades, tra#a"adores y artefactos& 'l U! tra#a"a a través de modelos& /e re(uieren muchos modelos para descri#ir el sistema durante su evoluci$n& Cada uno de los Nor@flo*s produce modelos, (ue se van desarrollando incrementalmente durante las iteraciones +figura D&5. 3igura D&5 3lu"os y modelos&
3uente1 +aco#son, ---.
5.3 Fases 'l U! es un modelo de proceso del soft*are dividido en cuatro fases1 =nicio& 'la#oraci$n, Construcci$n y :ransici$n +3igura D&.& 'stas fases están mucho más relacionadas con el funcionamiento de la organi%aci$n (ue con aspectos técnicos de la implementaci$n
5.3.1 Fase de Inicio /u o#"etivo es el de esta#lecer un caso de negocio para el sistema& /e de#en identificar todas las entidades e)ternas +personas y sistemas. (ue interactuarán con el sistema y definir estas interacciones& 'sta informaci$n se utili%a entonces para evaluar la aportaci$n (ue el sistema hace al negocio& /i 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 o#"etivos de esta fase son1 Comprender el dominio del pro#lema, 'sta#lecer un marco de tra#a"o ar(uitect$nico para el sistema, 2esarrollar el plan del proyecto, =dentificar los riesgos clave del proyecto&
36
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
9l finali%ar esta fase, se o#tienen1 Un modelo de los re(uerimientos del sistema +casos de uso UML., Una descripci$n ar(uitect$nica, Un plan de desarrollo del soft*are,
5.3.3 Fase de Construcción Comprende fundamentalmente1 'l dise8o del sistema, La implementaci$n, Las prue#as& 2urante esta fase se desarrollan e integran las partes del sistema& 9l finali%ar esta fase, se o#tienen1 Un sistema soft*are funcional, La documentaci$n correspondiente a éste&
5.3.4 Fase de Transición /e ocupa de mover el sistema desde la comunidad de desarrollo a la comunidad del usuario& :am#ién de hacer tra#a"ar el soft*are en un entorno real& 'sta fase es comAnmente ignorada en la mayoría delos modelos de proceso de soft*are, aAn cuando es muy importante y pude implicar altos costos& 9l finali%ar esta fase, se o#tiene1 Un sistema de soft*are documentado adecuadamente y (ue funcione correctamente en su entorno operativo
5.4 Flujos La perspectiva estática del U! se centra en las actividades (ue tienen lugar durante el proceso de desarrollo& Fstas se denominan flu"os de tra#a"o en la descripci$n del U! +3igura D&.& ')isten seis flu"os de tra#a"o del proceso1 Modelado de negocio e(uerimientos 9nálisis y dise8o =mplementaci$n !rue#as =mplantaci$n
')isten tres flu"os de tra#a"o de soporte 9dministraci$n de cam#ios y configuraci$n 9dministraci$n del proyecto 'ntorno
3igura D& 'structura del U!, fases y flu"os&
3uente1 +aco#son, ---.
37
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Resumen •
Proceso de desarrollo de sisteas de inforación •
•
Un proceso de desarrollo es una guía acerca de las actividades y tareas necesarias para construir un sistema de informaci$n& 's un marco de tra#a"o (ue define las tareas a reali%ar para desarrollar soft*are de alta calidad& Las fases genéricas de un proceso de desarrollo son1 2efinici$n, 2esarrollo y 'voluci$n& La fase de definici$n se centra en el > %ue& /u prop$sito es identificar las necesidades o re(uerimientos del cliente7usuario& /us actividades son1 9nálisis del sistema, e(uerimientos de soft*are, y !lanificaci$n del proyecto de soft*are& La fase de desarrollo se centra en el > cómo'. /u prop$sito es descu#rir c$mo han de dise8arse las estructuras de datos y la ar(uitectura del soft*are, etc& /e reali%an tres pasos concretos1 2ise8o del /oft*are, Codificaci$n y !rue#as del soft*are& La fase de evoluci$n, tam#ién llamada fase de mantenimiento, se centra en el > cambio' (ue va asociado a la Correcci$n, a la 9daptaci$n y Me"ora del soft*are& •
•
•
•
Los modelos de proceso de desarrollo de soft*are se clasifican en Modelo secuencial, se caracteri%a por(ue las actividades del desarrollo progresan de manera secuencial, una actividad no puede inicia sino a terminado la anterior& Modelos iterativos, se caracteri%an por(ue las actividades se repiten de manera cíclica& 'ntre los modelos iterativos podemos mencionar1 Construcci$n de prototipos y 2esarrollo ápido de 9plicaciones& Modelos evolutivos, se caracteri%an por(ue son iterativos y en cada iteraci$n se agrega nueva funcionalidad +versiones. al sistema& /e puede mencionar al modelo incremental y al modelo espiral& •
•
•
•
Una metodología representa el camino a seguir para desarrollar soft*are o aplicaciones informáticas de una manera sistemática, consiste de un con"unto de fases su#divididas en etapas, actividades y tareas& Una tarea es una actividad elemental siguiendo algAn procedimiento& 'l procedimiento es la definici$n de la forma de e"ecutar la tarea& La tcnica es la herramienta utili%ada para aplicar un procedimiento0 se pueden utili%ar una o varias& Una erramienta es el soporte soft*are (ue 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 'M( •
UML +Unified Modeling Language, Lengua"e de Modelado Unificado. es un lengua"e, #asado en una notaci$n gráfica, (ue permite1 especificar, construir, visuali%ar y documentar los elementos de un sistema soft*are, así como para modelar los procesos de negocios u otros sistemas no soft*are Un arteacto representa la informaci$n (ue es utili%ada o producida durante un proceso de desarrollo de soft*are& '"emplo1 documento de especificaci$n de re(uisitos, un modelo, un programa& Un modelo es una representaci$n a#stracta de una especificaci$n, un dise8o o un sistema desde un punto de vista particular& epresenta uno o más diagramas& '"emplos1 modelo de casos de uso, modelo de negocio& Un dia&rama es una representaci$n gráfica de una colecci$n de elementos del modelo& '"emplos1 diagrama de casos de uso, diagrama de clases& •
•
•
•
Los elementos del UML se clasifican en1 estructurales, de comportamiento, de agrupaci$n y de anotaci$n& Los elementos estructurales representan la parte estática del sistema& /e incluyen +figura ;&5.1 Clase, =nterfa%, nodo, caso de uso, interfa%, clase activa, componente, cadena de responsa#ilidad& Los elementos de comportamiento representan la parte dinámica del sistema, es decir el comportamiento en el tiempo y el espacio& /e incluyen1 =nteracciones y estados& •
•
38
Sistema a Distancia
Análisis de Sistemas - Unidad II
• •
•
César Luza Montero
Los elementos de agrupaci$n representan la parte organi%ativa del sistema& =ncluye1 !a(uete& Los elementos de anotaci$n representan la parte e)plicativa del sistema& /on comentarios& =ncluye1 la nota
Las relaciones en UML representan los vínculos entre dos elementos del modelo& =ncluye1 dependencia, asociaci$n, generali%aci$n y reali%aci$n& La dependencia representa una relaci$n semántica entre dos elementos, tal (ue un cam#io en uno de ellos +el independiente. puede afectar al otro +el dependiente, clase activa, componente, cadena de responsa#ilidad La asociación representa una relaci$n estructural (ue descri#e un con"unto de lin@s, siendo un lin@ una cone)i$n entre o#"etos& La &enerali!ación representa una relaci$n de generali%aci$n7especiali%aci$n en la (ue el elemento especiali%ado +descendiente. se construye so#re la especificaci$n del elemento generali%ado +ancestro. La reali!ación representa una relaci$n semántica en la (ue un clasificador, tal como una interfa% o un caso de uso, especifica un >contrato (ue otro clasificador, tal como una clase o una cola#oraci$n, garanti%a llevar a ca#o& •
•
•
•
•
Los diagramas en UML, version&-, son 54, divididos en diagramas estáticos y dinámicos& Los diagramas estáticos son1 diagrama de clases, diagrama de o#"etos, diagrama de componentes, diagrama de despliegue, diagrama de pa(uetes y diagrama de estructura& Los diagramas dinámicos son1 diagrama de casos de uso, diagrama de secuencia, diagrama de cola#oraci$n, diagrama de estado, diagrama de actividades, diagrama cronol$gico, diagrama de interacciones& •
•
•
Introducción a )'P •
•
'l U! +ational Unified !rocess, !roceso Unificado de ational. es un proceso de desarrollo de soft*are, es una forma disciplinada de asignar tareas y responsa#ilidades en una empresa de desarrollo, es decir define (uién hace (ué, cuándo y c$mo 'lementos del U! Un tra#a"ador es un rol (ue de#e ser reali%ada por una persona o e(uipo Una actividad es una unidad de tra#a"o (ue de#e ser e"ecutada Un arteacto es una pie%a de informaci$n (ue es producida, modificada o usada en un proceso de desarrollo de soft*are Un modelo es una representaci$n de alguna perspectiva del sistema Un lu*o de traba*o es una secuencia de actividades (ue produce un resultado valioso, define una lista de actividades, tra#a"adores y artefactos& • • •
• •
•
Las fases del U! son0 =nicio, 'la#oraci$n, Construcci$n y :ransici$n&
39
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Lectura *+cnicas de cuarta generación ,-
'l término técnicas de cuarta generaci$n +:;<. a#arca un amplio espectro de herramientas de soft*are (ue tienen algo en comAn1 todas facilitan al ingeniero del soft*are la especificaci$n de algunas características del soft*are a alto nivel& Luego, la herramienta genera automáticamente el c$digo fuente #asándose en la especificaci$n del técnico& Cada ve% parece más evidente (ue cuanto mayor sea el nivel en el (ue se especifi(ue el soft*are, más rápido se podrá construir el programa& 'l paradigma :;< para la ingeniería del soft*are se orienta hacia la posi#ilidad de especificar el soft*are usando formas de lengua"e especiali%ado o notaciones gráficas (ue descri#a el pro#lema (ue hay (ue resolver en términos (ue los entienda el cliente& 9ctualmente, un entorno para el desarrollo de soft*are (ue soporte el paradigma :;< puede incluir todas o algunas de las siguientes herramientas1 lengua"es no procedimentales de consulta a #ases de datos, generaci$n de informes, mane"o de datos, interacci$n y definici$n de pantallas, generaci$n de c$digos, capacidades gráficas de alto nivel y capacidades de ho"a de cálculo, y generaci$n automati%ada de O:ML y lengua"es similares utili%ados para la creaci$n de sitios *e# usando herramientas de soft*are avan%ado& =nicialmente, muchas de estas herramientas esta#an disponi#les, pero s$lo para ám#itos de aplicaci$n muy específicos, pero actualmente los entornos :;< se han e)tendido a todas las categorías de aplicaciones del soft*are& 9l igual (ue otros paradigmas, :;< comien%a con el paso de reuni$n de re(uisitos& =dealmente, el cliente descri#e los re(uisitos, (ue son, a continuaci$n, traducidos directamente a un prototipo operativo& /in em#argo, en la práctica no se puede hacer eso& 'l cliente puede (ue no esté seguro de lo (ue necesita0 puede ser am#iguo en la especificaci$n de hechos (ue le son conocidos, y puede (ue no sea capa% o no esté dispuesto a especificar la informaci$n en la forma en (ue puede aceptar una herramienta :;<& !or esta ra%$n, el diálogo clienteBdesarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfo(ue :;<& !ara aplicaciones pe(ue8as, se puede ir directamente desde el paso de recolecci$n de re(uisitos al paso de implementaci$n, usando un lengua"e de cuarta generaci$n no procedimental +L;<. o un modelo comprimido de red de iconos gráficos& /in em#argo, es necesario un mayor esfuer%o para desarrollar una estrategia de dise8o para el sistema, incluso si se utili%a un L;<& 'l uso de :;< sin dise8o +para grandes proyectos. causará las mismas dificultades +poca calidad, mantenimiento po#re, mala aceptaci$n por el cliente. (ue se encuentran cuando se desarrolla soft*are mediante los enfo(ues convencionales& La implementaci$n mediante L;< permite, al (ue desarrolla el soft*are, centrarse en la representaci$n de los resultados deseados, (ue es lo (ue se traduce automáticamente en un c$digo fuente (ue produce dichos resultados& H#viamente, de#e e)istir una estructura de datos con informaci$n relevante y a la (ue el L;< pueda acceder rápidamente& !ara transformar una implementaci$n :;< en un producto, el (ue lo desarrolla de#e dirigir una prue#a completa, desarrollar con sentido una documentaci$n y e"ecutar el resto de las actividades de integraci$n (ue son tam#ién re(ueridas por otros paradigmas de ingeniería del soft*are& 9demás, el soft*are desarrollado con :;< de#e ser construido de forma (ue facilite la reali%aci$n del mantenimiento de forma e)peditiva& 9l igual (ue todos los paradigmas del soft*are, el modelo :;< tiene venta"as e inconvenientes& Los defensores aducen reducciones drásticas en el tiempo de desarrollo del soft*are y una me"ora significativa en la productividad de la gente (ue construye el soft*are& Los detractores aducen (ue las herramientas actuales de :;< no son más fáciles de utili%ar (ue los lengua"es de programaci$n, (ue el c$digo fuente producido por tales herramientas es Pineficiente y (ue el mantenimiento de grandes sistemas de soft*are desarrollados mediante :;< es cuestiona#le&
40
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Oay algAn mérito en lo (ue se refiere a indicaciones de am#os lados y es posi#le resumir el estado actual de los enfo(ues de :;<1 5& 'l uso de :;< es un enfo(ue via#le para muchas de las diferentes áreas de aplicaci$n& unto con las herramientas de ingeniería de soft*are asistida por computadora +C9/'. y los generadores de c$digo, :;< ofrece una soluci$n fia#le a muchos pro#lemas del soft*are& & Los datos recogidos en compa8ías (ue usan :;< parecen indicar (ue el tiempo re(uerido para producir soft*are se reduce mucho para aplicaciones pe(ue8as y de tama8o medio, y (ue la cantidad de análisis y dise8o para las aplicaciones pe(ue8as tam#ién se reduce& 4& /in em#argo, el uso de :;< para grandes tra#a"os de desarrollo de soft*are e)ige el mismo o más tiempo de análisis, dise8o y prue#a +actividades de ingeniería del soft*are., para lograr un ahorro sustancial de tiempo (ue puede conseguirse mediante la eliminaci$n de la codificaci$n& esumiendo, las técnicas de cuarta generaci$n ya se han convertido en una parte importante del desarrollo de soft*are& Cuando se com#inan con enfo(ues de ensam#la"e de componentes el paradigma :;< se puede convertir en el enfo(ue dominante hacia el desarrollo del soft*are&
+R.3uente1 +!ressman, --.
41
Sistema a Distancia
Análisis de Sistemas - Unidad II
César Luza Montero
Actividades 5& ealice un cuadro comparativo entre los modelos de ciclo de vida de desarrollo de soft*are, indicando criterios de comparaci$n, venta"as y desventa"as de cada una de ellas por cada criterio& & Gus(ue en internet herramientas de soft*are li#re para modelar con el UML &-& &
Autoevaluación esponda las siguientes preguntas1 5& Un proceso de desarrollo es & Las fase de un proceso de desarrollo son1 4& =ndi(ue las características de los siguientes modelos de ciclo de vida1 a& /ecuencial #& Construcci$n de prototipos c& 2esarrollo rápido de aplicaciones d& =ncremental e& 'spiral ;& Una definici$n de metodología es D& Un producto, técnica, herramientas son E& 'l UML es S& 'l U! es
Exploración on-line •
•
•
=/H7='C 5-S !agina de la organi%aci$n internacional para la estandari%aci$n, =/H http177***&iso&org7iso7catalogueTdetail&htm?csnum#er;4;;S HM< UML !agina oficial del H#"ect Management
Referencias bibliográficas •
•
•
aco#son, =&, Gooch, <& y um#augh, & +---., El Proceso "niicado de Desarrollo de +otare & Madrid& !earson 'ducaci$n /&9& aco#son, =&, Gooch, <& y um#augh, & +--E., El -en&ua*e "niicado de Modelado "M-. /egunda edici$n& Madrid& !earson 'ducaci$n /&9& !ressman , oger /& +--. $n&eniera de +otare & "n eno%ue práctico & Dta&'d& Mc
42
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
TERCERA UNIDAD EL MODELADO DE NEGOCIOS
• •
•
•
¿Qué es el modelado de negocios, cuales son sus perspectivas? ¿Qué es un actor del negocio, un caso de uso del negocio, una meta del negocio y un diagrama de caso de uso del negocio? ¿Qué es un trabajador de negocio, una entidad de negocio y una realización de caso de uso del negocio? ¿Cómo se elabora el modelo del negocio?
43
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
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 (acobson, !"""#$ %ermite asegurar &ue se construir' el sistema en el conteto de las necesidades de la empresa$ El conteto esta dado por) El ambiente en &ue el sistema trabajar', *os roles y responsabilidades de los empleados &ue usaran el sistema y *as +cosas &ue son manejadas en el negocio$ -iene dos perspectivas) Eterna e .nterna$ *a perspectiva eterna 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 /orma en &ue la empresa interact0a con su entorno$ %rovee una visión general de lo &ue la empresa 1ace con sus clientes y otros participantes$ .ncluye metas del negocio adem's de 2ctores y casos de uso del negocio
6.2.1 Actor del Negocio 3epresenta un rol &ue alguien o algo desempe4a en relación al Negocio$ *a /igura 5$6 muestra la notación de actor de negocio$ 7n candidato a actor de negocios es cual&uier individuo, grupo, organización, empresa, o m'&uina, eterno al negocio, &ue interact0a con ella$ 8igura 5$6 2ctor de negocio
%ara comprender el conteto de un negocio, se debe conocer &uien interact0a con el negocio9 por ejemplo, &uien solicita un servicio o &uien provee un insumo$ 2lgunos ejemplos de actores del negocio son) Clientes, %roveedores y :ocios$
6.2.2 Casos de uso del negocio (CUN) 3epresenta un conjunto de secuencia de acciones &ue un negocio realiza para producir un resultado observable para un actor del negocio$ 7n caso de uso del negocio representa un proceso del negocio$ *a /igura 5$! muestra la notación de caso de uso de negocio$ 8igura 5$! Caso de uso de negocio
44
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
*os casos de uso del negocio se clasi/ican en) %rincipales, de :oporte y de ;estión$ *os casos de uso del negocio principales son a&uellos &ue est'n ligados directamente con la realización del producto y
6.2.3 Metas del negocio 3epresenta el valor deseado en una medida particular &ue puede ser usada para plani/icar y administrar las actividades del negocio (8igura 5$>#$ 8igura 5$> eta de Negocio
6.2.4 Diagrama de casos de uso del negocio El @iagrama de casos de uso del negocio (C7N# muestra a los actores del negocio, casos de uso del negocio y las relaciones entre ellos (8igura 5$A#$ 8igura 5$A @iagrama C7N
6.3 Modelo de Análisis del Negocio El odelo de 2n'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$ :irve como una abstracción de cómo los trabajadores del negocio y las entidades del negocio tienen &ue 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 so/tBare &ue representa un rol &ue se ejecuta dentro de la realización de un C7N (/igura 5$#$
45
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
8igura 5$ -rabajador de negocio
7n trabajador del negocio (business BorDer# es alguien &ue realiza actividades dentro de un caso de uso del negocio, interact0a con otros trabajadores del negocio y manipula entidades del negocio$
6.3.2 Entidad del negocio 3epresenta una pieza de in/ormación signi/icativa y persistente &ue es manipulada por los actores y trabajadores del negocio (/igura 5$5#$ 7na entidad del negocio (business entity# representa a un conjunto de in/ormación con propiedades, comportamiento y sem'ntica similares y &ue es manipulado o manejado por trabajadores del negocio$ 2lgunos ejemplos son) 8actura, :olicitud de pago y -arjeta de crédito$ 8igura 5$5 Entidad de negocio
6.3.3 Realización de caso de uso del negocio @escribe como los trabajadores, entidades y eventos del negocio colaboran para desarrollar un caso de uso del negocio 8igura 5$ Entidad de negocio
*a realización de un caso de uso del negocio puede incluir o se puede representar con) @iagrama de actividades o @iagrama de Clases$ Diagrama de actividades
El @iagrama de actividades permite eplorar el orden en &ue se realizan las actividades en un caso de uso de negocio$ 7na actividad es una tarea manual o automatizada &ue completa una unidad de trabajo$ *os elementos b'sicos de un diagrama de actividades son) .nicio, /in, actividad, transición, barra de sincronización y bi/urcación$ En la /igura 5$F se observa un diagrama de actividades b'sico, &ue se puede interpretar como sigue) el proceso se inicia con el llenado del pedido, la /lec1a de transición entre llenar pedido y tramitar pedido signi/ica &ue después de la actividad llenar pedido sigue la actividad tramitar pedido$ -erminado de tramitar el pedido sigue analizar viabilidad cuyo resultado indica &ue si no es viable, se noti/ica el rec1azo y termina el /lujo con rec1azo9 si es viable, en /orma paralela se
46
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
pueden realizar Noti/icar aceptación y Grdenar /abricación, luego plani/icar producción$ %ara &ue el /lujo /inalice correctamente, tiene &ue terminarse las actividades Noti/icar aceptación y %lani/icar producción$ 8igura 5$F @iagrama de actividades simple Rellenar Pedido
Inicio
Tramitar Pedido
Analizar Viabilidad
[No]
Notificar rechazo
Viable [Si]
Fin NoOK
Notificar Aceptacion
Ordenar fabricacion
Planificar Produccion
Fin OK
En la /igura 5$H se mueAstra un diagrama de actividades detallado, &ue incluye elementos adicionales, como los carriles, &ue permiten representar trabajadores del negocio &ue realizan actividades) e/e de taller y @pto$ reparaciones9 entidades de negocio) libro de citas, numero de trabajo interno, orden de reparación, etc$ 8igura 5$H @iagrama de actividades detallado
: Jefe de taller
: Dpto reparaciones
Revisar cita aceptada
a : Libro de citas
c : Orden de reparación [copia]
z : Libro de citas : Numero de trabajo interno
[aceptada] Reparar coche
Asignar numero trabajo interno Elabora parte de trabajo
: Partes de trabajo
Generar orden de reparación o : Orden de reparación Guardar en partes pendientes
[original]
p : Partes de trabajo [pendiente]
47
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
Diagrama de clases de negocio
El @iagrama 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 IcosaI &ue el negocio manipula#$ En este diagrama se visualiza las relaciones entre los trabajadores del negocio y las entidades del negocio$ En la /igura 5$6" se muestra un diagrama de clases del negocio, se observa al actor de negocio) Cliente, a los trabajadores del negocio) /acturador y empleado de mostrador$ 2simismo entidades de negocio) %artes de trabajo, inventario de artJculos, /actura, etc$ 8igura 5$6" @iagrama de clases de an'lisis del negocio
Partes de trabajo
Obtiene precios de materiales
revisa partes pendientes
Inventario de articulos
(from Entidades del negccio)
(from Entidades del negccio)
Obtiene precio de mano de obra indica nume ro de identificacion
Facturador (from Trabajadores del negocio)
Registra pendiente Asigna num ero factura
Calcul a impo rte total
Fichero de mecanicos recibe copia
(from Entidades del negccio)
Cliente (from Business Us e-Case Model)
Realiza
Factura
registrar facturas paga das
(from Entidades del negccio)
Recibe
Empleado del m ostradoir
pago con tarjeta
(from Trabajadores del negocio)
(from Entidades del negccio)
pago (from Entidades del negccio)
Pago en efectivo (from Entidades del negccio)
48
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
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$ *a construcción del modelo de casos de uso del negocio puede considerar las siguientes actividades) .denti/icar actores del negocio, .denti/icar casos de uso del negocio, opcionalmente identi/icar metas del negocio y elaborar el diagrama de casos de uso del negocio$ *a construcción del modelo de an'lisis del negocio puede incluir las siguientes actividades) .denti/icar trabajadores del negocio, identi/icar 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 *a empresa +=ende Karato :$2$ se dedica a la /abricación de productos bajo demanda$ El gerente general esta interesado en satis/acer 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$ %ara cumplir con el objetivo, es necesario en primer lugar registrar el pedido del cliente, luego /abricar 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 !"L del tiempo actual, reducir la tasa de errores de /abricación a "$L del total, mantener el stocD adecuado de las materias primas y reducir el tiempo de generación de la orden de compra a proveedores en un !"L del actual$
7.1.1 Identificando Actores del Negocio @e acuerdo con la especi/icación, los actores son Cliente y %roveedor$ El Cliente interact0a con la organización a través del pedido$ El %roveedor interact0a con la organización recibiendo la orden de compra de materia prima$
Proveedor
Cliente
7.1.2 Identificando Casos de Uso del Negocio *os casos de uso de negocio principales son) 3egistrar %edido del Cliente y realizar compra a proveedores$ *os casos de uso del negocio de soporte son) 8abricar producto pedido y Controlar almacén$ No se identi/ican casos de uso del negocio de gestión$
49
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
Registrar pedido
Fabricar producto
Controlar almacen Comprar materia prima
7.1.3 Identificando Metas del Negocio %or cada caso de uso se identi/ican las metas del negocio$ Este paso es opcional$
Reducir ti em po en 20%
Mantener stock adecuado
Reducir tas a errores a 0.5% Reducir generación orden compra en 20%
7.1.4 Elaborando el diagrama de casos casos de uso del del negocio :e asocia los actores con cada caso de uso principal y cada caso de uso con su respectiva meta$ Creado por : Cesar Luza Fecha: Enero 25, 2010
Registrar pedido
Cliente
Reducir tiempo en 20%
(from Casos de uso del negocio)
(from Metas del negocio)
(from Actores del negocio)
Fabricar producto
Reducir tasa errores a 0.5%
(from Casos de uso del negocio)
(from Metas del negocio)
Proveedor
Controlar almacen
Mantener s tock adecuado
(from Casos de uso del negocio)
(from Metas del negocio)
Comprar materia prima
Reducir generación orden compra en 20%
(from Casos de uso del negocio)
(from Metas del negocio)
(from Actores del negocio)
7.2 Elaborar el modelo modelo de de análisis del negocio En nuestro ejemplo, de la empresa +=ende barato barato :$2$ consideremos consideremos la siguiente descripción de caso de uso de negocio 3egistrar pedido)
50
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
6$
El Cliente envJa su pedido, por telé/ono, por /a o por correo, al @pto$ de =entas$ El pedido debe incluir la /ec1a de solicitud, datos del cliente y producto solicitado$
!$
7n Empleado del @pto$ de =entas revisa el pedido (complet'ndolo, si es necesario#$ Comienza su procesamiento envi'ndolo al e/e -écnico, &ue est' encargado de su an'lisis$
>$
El e/e -écnico analiza la viabilidad del producto solicitado$ :i el producto pedido est' en el cat'logo, su /abricación es aceptada$ En caso contrario, es considerado un producto especial, y el e/e -écnico estudia su /abricación) :i es viable, la /abricación del producto especial es aceptada9 :i no es viable, el producto especial no ser' /abricado$
A$
7na vez estudiado el pedido completo, el e/e -écnico in/orma al @pto$ de =entas de la aceptación o rec1azo del producto pedido9 :i el producto de un pedido 1a sido aceptado, se crea una orden de trabajo, a partir de una plantilla de /abricación (la est'ndar si el producto estaba catalogado, o una nueva, especJ/icamente dise4ada para el producto, si éste no estaba en el cat'logo#$ Cada orden de trabajo es enviada al e/e de %roducción, y &ueda pendiente de su /abricación$
$
El Empleado del @pto$ de =entas comunica al cliente el resultado /inal del an'lisis de su pedido$
7.2.1 Identificando trabajadores del negocio :e identi/ican los trabajadores del negocio, en nuestro ejemplo solo consideramos el caso de uso de negocio 3egistrar %edido)
Empl eado de Ve Ventas
Jefe Tecnico
Jefe Produccion
7.2.2 Identificando entidades del negocio :e identi/ican las entidades del negocio, en nuestro ejemplo solo del caso de uso de negocio 3egistrar %edido)
Pedido
Catalogo
Plantilla Plantilla de fabricac fabricacion ion
Product Producto o especial especial
Orden de Trabajo
7.2.3 Construyendo las realizaciones de caso de uso del negocio 3ealización con diagrama de actividades del Caso de 3egistrar %edido
51
Sistema a Distancia
Análisis de Sistemas - Unidad III
: Cliente
César Luza Montero
: Empleado de Ve ntas
: Jefe Tecnico
: Catalogo Llenar pedido
: Jefe Produccion
: Plantilla de fabricacion
p : Pedido [propuesto]
Analizar viabilidad x : Ped ido
: Producto especial
Tramitar pedido [ NO Viable ] [ SI viable ] : Plantilla de fabricacion Informar rechazo r : Pedido [Rechazado] Ordenar Fabricación
: Orden de d e Trabajo
Informar aceptacion a : Pedido Planificar producción
[Aceptado]
52
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
Resumen Conceptos asociados al modelado del negocio •
•
•
El modelado del negocio es una técnica para representar proceso de negocio, tiene dos perspectivas) eterna (modelo de casos de uso# e i nterna (modelo de an'lisis del ne gocio#$ El modelo de casos de uso del negocio representa la /orma en &ue la empresa interact0a con su entorno$ .ncluye) actores, casos de uso del negocio$ o 7n actor de negocio representa un rol &ue alguien o algo desempe4a en relación al negocio$ 7n caso de uso de negocio representa un conjunto de secuencia de acciones &ue un o negocio realiza para producir un resultado observable para un actor de negocio$ 7n diagrama de caso de uso de negocio muestra actores de negocio, casos de uso de o 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 7n trabajador de negocio representa un rol &ue se ejecuta en la realización de un caso de uso del negocio$ 7na entidad de negocio representa una pieza de in/ormación signi/icativa y persistente o &ue es manipulado por trabajadores de negocio o actores de negocio$ 7na realización de casos de uso de negocio describe como los trabajadores y entidades del o 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 .denti/icar actores de negocio o .denti/icar casos de uso del negocio o Elaborar diagrama de casos de uso del negocio o Elaboración del modelo de an'lisis del negocio .denti/icar trabajador de negocio o .denti/icar entidad de negocio o Construir realización de casos de uso del negocio o Con @iagrama de actividades Con diagrama de clases de an'lisis del negocio
53
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
Lectura Manifiesto de Reglas de Negocio (*) Los Principios de la Independencia de las Reglas -1e Kusiness 3ules ;roup
2rtJculo 6$ *os re&uisitos como elementos principales, nunca como secundarios 6$6$ *as reglas son un ciudadano de primera clase en el mundo de los 3 e&uisitos$ 6$!$ *as reglas son esenciales para los modelos de negocio y para los modelos de tecnologJa, y una parte separada y especi/ica de los mismos$
2rtJculo !$ .ndependientes de los procesos y no contenidas en ellos 6$6$ *as reglas son restricciones eplicitas de comportamiento y$ *as reglas se aplican a lo largo de los procesos y procedimientos$ @ebe eistir un corpus co1erente de reglas &ue se apli&ue sistem'ticamente en todas las 'reas de actividad del negocio$
2rtJculo >$ %roporcionar conocimiento meditado, no un subproducto 6$6$ *as reglas se construyen sobre 1ec1os, y los 1ec1os sobre conceptos tal y como son epresados mediante términos$ 6$!$ *os términos epresan conceptos de negocio9 los 1ec1os realizan a/irmaciones sobre estos conceptos9 las reglas restringen y apoyan estos 1ec1os$ 6$>$ *as reglas deben ser eplicitas$ No se debe asumir ninguna regla sobre ning0n concepto o 1ec1o$ 6$A$ *as reglas son los /undamentos &ue de/inen lo &ue el negocio sabe de si mismo es decir son conocimiento b'sico de negocio$ 6$$ *as reglas necesitan ser alimentadas, protegidas y gestionadas$
2rtJculo A$ @eclarativas, no de procedimiento A$6 *as reglas deben epresarse de /orma declarativa en sentencias de lenguaje natural, por la audiencia conocedora del negocio$ A$! :i algo no puede ser epresado clar amente, entonces no es una 3egla$ A$> 7na serie de enunciados solo es declarativa si no contiene una secuencia implJcita$ A$A Cual&uier enunciado de reglas &ue necesite de otros elementos &ue no sean términos o 1ec1os, revelan 1ipótesis sobre la implementación de un sistema$ A$ 7na regla es distinta del nivel de cumplimiento de/inido para ella$ *a regla y su nivel de cumplimiento son dos asuntos di/erentes$ A$5 *as reglas deben de/inirse independientemente de la &uien tiene la responsabilidad de su cumplimiento, y de donde, cuando o como se r e/uerzan$ A$ *as ecepciones a las reglas se de/inen mediante otras reglas$
2rtJculo $ Epresiones bien /ormadas, no epresiones creadas con /ines especJ/icas para un caso 6$6 *as reglas de negocio se deben epresar demanera &ue pueda ser validada su eactitud por el personal conocedor del negocio$ 6$! *as reglas de negocio se deben epresar de manera &ue se pueda veri/icar recJprocamente su co1erencia$ 6$> *as lógicas /ormales, como la lógica de predicados, son /undamentales para la epresión /ormal de reglas en términos de negocio, asJ como para las tecnologJas &ue implementan dic1as reglas$
2rtJculo 5$ 2r&uitectura basada en las reglas, no una implementación indirecta 5$6 7n sistema basado en reglas de negocio se construye intencionadamente para permitir el cambio continuo de las reglas de negocio$ *a plata/orma sobre la &ue el sistema se ejecuta debe soportar esta evolución$ 5$! Es mejor ejecutar las reglas directamente O por ejemplo utilizando un motor de reglas O antes &ue transcribirlas en alguna /orma embebida dentro de un procedimiento$ 5$> 7n sistema de reglas de negocio siempre debe ser capaz de eplicar el razonamiento por el cual llega a una conclusión o emprende una acción$
54
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
5$A *as reglas se basan en los valores ciertos$ *a /orma en la &ue certeza de una regla se determina, se mantiene oculta a &uienes la utilizan$ 5$ *a relación entre eventos y reglas es generalmente de muc1osamuc1os$
2rtJculo $ %rocesos guiados por reglas, no programación basada en ecepciones $6 *as reglas de/inen el lJmite entre actividad de negocio aceptable y no aceptable$ $! *as 3eglas re&uieren a menudo de una gestión especial o especi/ica de las violaciones detectadas$ Cual&uier actividad derivada de la violación de una regla es una actividad como cual&uier otra$ $> %ara asegurar la m'ima consistencia y reutilización, el tratamiento de las actividades de negocio no aceptables, debe separarse de la gestión de actividades de negocio aceptables$
2rtJculo F$ 2l servicio del negocio, no al de la tecnologJa F$6 *as 3eglas 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 /orma a través de varios /actores internos y eternos a la empresa$ F$! *as reglas suponen siempre un coste a la empresa$ F$> 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$ F$A +'s reglas no es mejor, la abundancia de reglas no bene/icia a su aplicación$ Normalmente es mejor un n0mero limitado de reglas bien re/leionadas$ F$ 7n sistema e/icaz puede estar basado en un pe&ue4o n0mero de reglas$ 2dicionalmente, se pueden a4adir reglas m's discriminatorias, por las &ue 1a medida &ue pasa el tiempo el sistema mejore y se 1ace m's inteligente$ 2rtJculo H$ +@e, por y para el personal de negocio$ No +de, por y para el personal de .-$ H$6 *as reglas deben provenir del personal con conocimiento de negocio$ H$! *os epertos de negocio debe tener disponibles 1erramientas &ue les ayuden a /ormular, validar y gestionar reglas$ H$> *os epertos de negocio deben tener disponibles 1erramientas &ue les ayuden a veri/icar la co1erencia reciproca entre las reglas de negocio$
2rtJculo 6"$ ;estionando la lógica de negocio, no las plata/ormas de PardBare<:o/tBare 6$6 *as reglas de negocio son un patrimonio vital del negocio$ 6$! 2 largo plazo, las reglas son m's importantes para el negocio &ue las plata/ormas PardBare<:o/tBare$ 6$> *as reglas de negocio deben organizarse y salvaguardarse de /orma &ue puedan ser redesplegadas a nuevas plata/ormas de PardBare<:o/tBare$ 6$A *as reglas, y la 1abilidad para cambiarlas de /orma e/icaz, son /actores clave para mejorar la adaptabilidad de las empresas$
(# -1e Kusiness 3ules ;roup Copyrig1t, !"">$ Kusiness 3ules ;roup$ =ersion !$", November 6, !"">$ Edited by 3onald ;$ 3oss$ BBB$Kusiness3ules;roup$org La reproducción y la distribución de este documento se concede bajo las siguientes condiciones: (a) Se debe incluir mención clara y visible del copyright y del permiso. (b) Se debe mencionar al usiness Rules !roup como la "uente del documento. (c) Se debe respetar la integridad del documento reproducido# incluido el t$tulo# el contenido# el copyright# el p ermiso# sin ninguna modi"icación# abreviación# resumen# n i e%tensión. &raducción a espa'ol versión .# noviembre *+# iniciada y coordinada por ,ntonio -atala. (antonio.catalatheanonymousarchitect.com)
55
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
Actividades Elaborar el odelo del Negocio considerando la siguiente descripción) *a Empresa 82KC* se dedica a la /abricación de productos de consumo masivo$ *a ;erencia ;eneral desea automatizar las principales principales actividades &ue la empresa realiza en los procesos de atención de pedidos, control de la /abricación, proceso de /acturación y entrega de mercaderJa$ Proceso de atención de pedidos El cliente envJa su pedido por distintos medios (telé/ono, correo o /a#, son recibido por la empleada encargada de la G/icina de 2tención a Clientes, &uien solicita &ue se realicen las siguientes comprobaciones) 2ntonio (@pto de 2lmacén# se encarga de veri/icar la disponibilidad de los artJculos solicitados, consultando el inventario de artJculos$ uan (@pto$ Contabilidad# veri/ica el estado de la cuenta del cliente para ver si tiene deudas pendientes9 y el @pto$ *egal veri/ica si el cliente tiene antecedentes sospec1osos, consultando el arc1ivo de antecedentes$ En caso de &ue los pedidos no cumplan alguna de las condiciones anteriores ser'n rec1azados, noti/ic'ndoselo al cliente$ %ero si todo es correcto, se registrar aceptación del pedido$ En ambos casos es la empleada la &ue in/orma al cliente$ Proceso de control de "abricación El proceso se inicia cuando el pedido aceptado es recibido por el e/e de %roducción, &uien le asigna un n0mero de trabajo interno, luego genera la orden de producción y registra el pedido como pendiente de /abricación$ *a orden de producción se envJa a la sección de /abricación para &ue empiece a elaborar los productos del pedido$ Cuando /inaliza el trabajo, el e/e de %roducción elabora una carta donde indica a &uién ser'n enviadas los productos &ue se encuentran listas$ Evidentemente, el pedido deja de ser pendiente$ Proceso de /acturación 3ecibida la carta de productos terminados el @pto de 8acturación procede a elaborar la /actura y el talón de embar&ue$ 7na copia de la /actura se envJa al @pto$ de Contabilidad &ue se encarga de realizar los asientos$ Gtra copia se a4ade al arc1ivo de /acturas$ Este 0ltimo arc1ivo se emplea 0nicamente como re/erencia9 no es un arc1ivo activo sino &ue solo sirve para seguridad$ Proceso de 0ntrega *os artJculos elaborados se reciben en el 'rea de embar&ue, donde son empa&uetadas, y el talón de embar&ue se anea a la caja de embar&ue$ En base a la in/ormación contenida en el talón de embar&ue se procede a entregar la mercaderJa a domicilio asignando la movilidad correspondiente o llamar al cliente para indicarle &ue su mercaderJa esta lista y se apersone a recogerla$
56
Sistema a Distancia
Análisis de Sistemas - Unidad III
César Luza Montero
Autoevaluación 6 ! > A 5
El modelado del negocio es *os elementos del modelo de caso de uso del negocio son 7n actor de negocio es 7n caso de uso de negocio es *os elementos del modelo de an'lisis del negocio son 7n trabajador de negocio es 7na entidad de negocio es
Exploración on-line •
.K 37%
%agina de .K 3ational 7ni/ied %rocess, &ue o/rece in/ormación y recursos sobre la plata/orma de proceso de desarrollo de so/tBare con/igurable 1ttp)<
Referencias bibliográficas •
•
acobson, .$, Kooc1, ;$ y 3umbaug1, $ (!"""#, 0l Proceso 1ni"icado de 2esarrollo de So"t3are $ adrid$ %earson Educación :$2$ acobson, .$, Kooc1, ;$ y 3umbaug1, $ (!""5#, 0l Lenguaje 1ni"icado de 4odelado 14L. :egunda edición$ adrid$ %earson Educación :$2$
57
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
CUARTA UNIDAD EL MODELADO DE DOMINIO
• • • •
¿Qué es el modelado de dominio? ¿Qué es un diagrama de clases? ¿Cuáles son sus elementos? y ¿Cómo se construye?
58
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
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 utiliada para representar este modelo de domino es el diagrama de clases de U!"# 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 %ue se tenga entre manos. Una clase describe un con&unto de ob&etos con propiedades similares, relaciones comunes con otros y una semántica com'n ()umbaug*, +-. /or e&emplo, 01nálisis de sistemas2, 03ase de datos 42, 0Estad$stica 442, 0!atemática 3ásica 42 son ob&etos de la clase 1546718U)1, en otras palabras, 1546718U)1 representa al con&unto de todas las asignaturas en el dominio de la gestión académica de una institución educati9a. 8.2
Atributo
Una clase tiene una serie de caracter$sticas o propiedades, por e&emplo 1546718U)1 tiene código, nombre, créditos, *oras de teor$a, *oras de practica# a estas propiedades se le conoce como atributos de la clases. Un atributo es una propiedad de una clase %ue describe un rango de 9alores %ue la propiedad podrá contener en los ob&etos de la clase ()umbaug*, +-.. /odemos decir %ue una clase representa un con&unto de ob&etos con las mismos atributos y un objeto es una instancia de una clase, es decir es una entidad %ue tiene 9alores espec$ficos para cada uno de los atributos de la clase. /or e&emplo, la clase 1U8:!:;4", tiene como atributos< n'mero de placa, color, modelo, n'mero de puertas, a=o, entre otros. Un ob&eto, de la clase 1U8:!:;4", es el auto de placa 56>@A, color aul, modelo 5tation Bagon, con cuatro puertas, del a=o DDD. :tro ob&eto es el auto de placa E)6, negro, deporti9o, @ puertas, a=o DD. 8.3
Operación
Una clase tiene un comportamiento %ue es definido por las operaciones o responsabilidades %ue la clase puede realiar. Una operación es algo %ue la clase puede realiar o %ue otra clase puede *acer a una clase. Es una función o transformación %ue se puede aplicar o %ue puede ser aplicada por los ob&etos de una clase ()umbaug*, +-.. /or e&emplo, algunas operaciones de la clase automó9il pueden ser< Encender, 1pagar, 1celerar, Frenar.
59
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
8.4 Asociación y Enlace
"as entidades o cosas del mundo real se relacionan con otras entidades ; a las relaciones entre ob&etos se les llama enlaces y a las relaciones entre clases se les llama asociaciones ()umbaug*, +-. !ediante la abstracción de asociación se 9incula dos o más clases, creándose un elemento de tipo distinto (;inculo. /or e&emplo, 0>ocente dicta 1signatura2, es una asociación entre la clase docente y la clase asignatura. 0Cesar "ua dicta 1nálisis de sistemas2 es un enlace entre los ob&etos Cesar "ua y 1nálisis de sistemas. 8.5 Generalización y Agregación
"a generaliación y agregación son dos tipos especiales de relaciones entre clases ()umbaug*, +-.. "a Generalización representa la relación entre clases, donde algunas de ellas son tipos de otra. /or e&emplo, las clases 5EC)E81)41, 8GC74C:, 476E74E): son tipos de la clase E!/"E1>:# en otras palabras, E!/"E1>: es una generaliación de las clases 5EC)E81)41, 8EC74C:, 476E74E): (9er figura H.+. !ediante la generaliación se abstrae las características comunes a 9arias clases (subclases para construir una clase más general (superclase, la generaliación define una relación de subcon&unto entre elementos de dos o más clases. Figura H.+ E&emplo de generaliación 6E7E)1"4K1C4J7 5EC)E81)41
8EC74C:
EMP#EADO
476E74E):
Una Clase ES ! T"PO DE otra
"a Agregación representa la relación entre clases, donde algunas de ellas son componentes de otra. /or e&emplo, las clases C/U, 8EC"1>:, !:U5E, !:748:) son componentes de la clase C:!/U81>:)1# en otras palabras, la clase C:!/U81>:)1 está formada por las clases C/U, 8EC"1>:, !:U5E I !:748:) (figura H.. !ediante la agregación se construye una nue9a clase o tipo o categor$a de ob&etos a partir de un con&unto de otras clases denominadas componentes o partes. "a agregación define una nue9a clase de ob&etos a partir de un con&unto de clases (otras, no necesariamente distintas %ue representan sus partes componente. Figura H. E&emplo de 1gregación
C/U
16)E61C4J7
!:U5E
COMPTADOR
!:748:) 8EC"1>:
Una Clase ES PARTE DE otra clase
60
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
8.6 ¿Qué es el modelo de domino?
El !odelo de dominio es un modelo conceptual %ue muestra clases conceptuales de ob&etos significati9os en un dominio de problema. "as clases conceptuales no muestran componentes softLare, ni clases softLare, ni responsabilidades ("arman, +. /or e&emplo, algunas clases conceptuales del dominio de la 6estión 1cadémica son< 1"U!7:, >:CE78E, 1546718U)1 y M:)1)4:. 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 U!", %ue describe la estructura de un sistema mostrando sus clases y sus relaciones. En la figura H.+ se obser9a un e&emplo de diagrama de clase simplificado para una 8ienda de 9entas. 5e muestra clases conceptuales y relaciones entre ellas# cada clase tiene un nombre y una serie de atributos. "as relaciones se conocen como asociaciones, cada una de ellas tiene un nombre y su multiplicidad. "a interpretación o lectura de un diagrama de clases permite a desarrolladores y usuarios disponer de un lengua&e uniforme para mostrar caracter$sticas del negocio en el dominio del problema. /or e&emplo, en la figura H., podemos leer la siguiente restricción semántica< “una línea de venta está contenida en una venta y esta puede contener muchas líneas de venta, nunca ninguna línea de venta 2. 1demás, 0cada línea de venta registra la venta de un articulo y un articulo puede o no estar en una línea de venta”.
Figura H. E&emplo de diagrama de Clases concepto u objeto del dominio
Registra-venta-de
LineaDeVenta cantidad
0..1
Artículo 1 *
1..n Contenida-en
asociación
Almacenado-en 1 Tienda
1 atributos
dirección tienda
Venta fecha hora
1 1
1 Capturada-en
Pagada-mediante
Alberga 1
1..* Registro
1 Pago cantidad
Fuente< ("arman, +
8.8 Notación UML para modelo de domino Clase
/ara efectos del modelo de dominio, una clase puede considerarse en términos de< Símbolo, palabras o imágenes %ue representan a la clase# De$inición %el concepto, descripción textual del significado de la clase y E&tensión< con&unto de ob&etos %ue pertenecen a la clase. • • •
/or e&emplo, considere la clase ;enta del diagrama de clases de la figura H.@.
61
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
El s$mbolo del concepto es un rectángulo di9idió en tres partes, la primera es el nombre de la clase, la segunda los atributos y la tercera las operaciones. Figura H.@ Clase Venta fecha hora
"a definición del concepto es< Una 9enta representa el *ec*o de una transacción de compra, sucede un d$a y en una *ora. "a extensión es el con&unto de todas las 9entas realiadas en la tienda. Atributo
/ara efectos del modelo de dominio se incluyen a%uellos atributos para los %ue los re%uisitos indican la necesidad de registrar su información. /or e&emplo, un recibo recoge la información de una 9enta, incluyendo fec*a y *ora. "a 6erencia de la 8ienda %uiere conocer fec*a y *ora de las 9entas, la clase Venta necesita los atributos fecha y hora. 5eg'n la notación U!", los atributos se muestran en el segundo compartimento del rectángulo de la clase. Figura H.A 1tributos Venta fecha hora
Asociación
"a asociación se representa con una l$nea %ue une las clases relacionadas. En el siguiente e&emplo, se muestra la relación entre las clases 1"U!7: y F1CU"81># la semántica se=ala %ue un alumno pertenece a una 'nica facultad y una facultad tiene muc*os alumnos. Figura H.- 1sociación
En una asociación se incluye, opcionalmente, el nombre de la asociación, la na9egabilidad, y obligatoriamente, la multiplicidad. "a na9egabilidad se representa con una flec*a %ue indica la dirección de en9$o de mensa&es de un ob&eto a otro. "a multiplici%a% es la cantidad de ob&etos de una clase %ue están 9inculados con un ob&eto de la clase asociada. /or e&emplo, en la figura H.-, el nombre de la asociación es< Pertenece a. "a multiplicidad de la asociación es de 0uno a muc*os2# significa 0Un ob&eto de alumno está 9inculado con
62
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
un solo ob&eto de Facultad, y un ob&eto de Facultad esta 9inculado con 9arios ob&etos de 1"U!7:2. "a multiplici%a% permite representar, en el diagrama de clases, las reglas del negocio definidas en el dominio del problema. "as categor$as t$picas de multiplicidad son< 0Uno a Uno2, 0Uno a !uc*os2 y 0!uc*os a !uc*os2. En la figura H. se aprecia algunos tipos de multiplicidad. Figura H. 8ipos de multiplicidad
Clase-Asociación
En algunas ocasiones es necesario representar propiedades propias de la asociación# para tal efecto, se crea una clase especial llamada Clase'Asociación. /or e&emplo, consideremos la asociación 1"U!7: matriculado en 1546718U)1, la multiplicidad de esta asociación es de 0muc*os a muc*os2, en efecto, un alumno puede lle9ar 9arias asignaturas y una asignatura es lle9ada por 9arios alumnos. Entonces, la nota promedio de un alumno en una asignatura corresponde a la asociación# pues si se coloca como atributo de alumno, no se sabr$a de %ué asignatura es# si se coloca como atributo de asignatura, no se sabr$a de %ué alumno es, entonces, se crea una clase especial llamada clase asociación !18)4CU"1 en el %ue se coloca el atributo nota promedio. "a representación de una clase asociación se *ace con una l$nea discontinua %ue une la asociación con la clase generada. (figura H.H. Figura H.H E&emplo de ClaseN1sociación
Generalización
63
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
"a generaliación se representa a tra9és de una l$nea recta entre las clases subtipos terminados en un triángulo blanco en el extremo cercano a la clase generaliada. /or e&emplo, en la figura H., 17F434:, !1!OFE): y )E/84" son tipos de 174!1". 1 su 9e, C131"": es un tipo de !1!OFE):. "a 6eneraliación puede encontrarse en a%uellas clases %ue tienen ciertos atributos y operaciones en com'n. En ese caso se crea una clase nue9a %ue asume dic*o comportamiento com'n. Figura H. E&emplo de 6eneraliación
Agregación
"a agregación se representa a tra9és de una l$nea recta entre las clases 0partes2 terminados en un rombo en el extremo cercano a la clase 0todo2. /or e&emplo, en la figura H.+D, !:748:), C15E5, 8EC"1>: y !:U5E son partes o componentes de C:!/U81>:)1. 1 su 9e, C15E5 está formado por C/U, )1!,;E784"1>:). Figura H.+D E&emplo de 1gregación
64
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
Lección 9 Proceso de construcción del modelo de dominio !uc*os de las clases del dominio pueden obtenerse de una especificación de re%uisitos o mediante la entre9ista con los expertos del dominio. "as clases del dominio aparecen en tres formas distintas (Pacobson, DDD< :b&etos del negocio %ue representan cosas %ue se manipulan en el negocio, como pedidos, cuentas, contratos, y facturas. :b&etos del mundo real y conceptos de los %ue el sistema debe *acer un seguimiento, como la a9iación enemiga, misiles y trayectorias. 5ucesos %ue ocurrirán o *an ocurrido, como la llegada de un a9ión, sus salidas y la *ora de la comida. •
•
•
/ara construir el modelo de dominio se puede seguir las siguientes acti9idades< 4dentificar las Clases conceptuales o del dominio, 4dentificar las asociaciones, 4dentificar atributos, 4dentifica relación de generaliación y refinar el modelo. Consideremos la siguiente descripción para realiar el modelo de dominio. Una empresa recién formada se dedica a integrar partes para formar productos con la intención de 9ender el 9alor agregado de la integración. Con el ob&eti9o de apoyar sus acti9idades, mediante una aplicación informática, se *a obtenido las siguientes reglas semánticas< n producto tiene un nom!re y un precio !ase. n producto se forma con muchas partes y cada parte puede formar muchos productos. "a definici#n de cada producto especifica $u% cantidad de cada parte forma a un producto dado. n vendedor tiene un apellido, nom!re y un porcentual de comisi#n. &anto un cliente como un proveedor tienen los datos de todo agente comercial; %stos son' cuit, ra(#n social, e)mail, tel%fono y direcci#n. *demás, un proveedor tiene un pla(o de pago y un cliente un porcentual de descuento. n 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. na venta se reali(a entre cual$uier vendedor y cual$uier cliente, y %ste puede comprar cual$uier producto. De una venta se $uiere sa!er su fecha. +o se pueden vender productos $ue est%n formados por una nica parte, esto es, no se permite vender productos sin ela!orar.
9.1 Identificando Clases
5e seleccionan los nombres o sustanti9os de la descripción del problema como posibles clases candidatas. 5e construye una lista de clases candidatas. 5e eliminan, de esa lista, las clases redundantes, irrele9antes o 9agas o bien por ser atributos, operaciones o construcciones de implementación. En nuestro e&emplo las clases conceptuales identificadas son< producto
parte
vendedor
cliente
65
proveedor
agenteComercial
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
9.2 Identificando Asociaciones
5e 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 9erbos en la descripción del problema. 5e le agrega la multiplicidad correcta. 8ambién se puede representar la relación es parte de o agregación. En nuestro caso, las asociaciones identificadas son< vendedor
producto
se forma
1..n
1..n
1..n
parte 1..n
se vende
Se compra
agenteComercial
1..n 1..n
cliente
proveedor
9.3 Identificar Atributos
/or cada clase se indican los atributos necesarios %ue respondan a los re%uerimientos del dominio del problema. 5i los atributos corresponden a una asociación, crear una clase asociación. En nuestro e&emplo, se se=alan los atributos por cada clase y adicionalmente, se identifican atributos para las algunas asociaciones, creándose las clases asociación >efinición, compra y 9enta. vendedor
producto
apellido nombre porcComis
nombre precioBase 1..n
parte se forma
1..n
definición
1
1..n
numParte descripción 1..n
cantidad
participa 0..n
se vende
compra
venta
agenteComercial
fecha
cuit razSocial email telf direcc
1..n
Se compra
fecha cantidad
1..n
cliente
proveedor
porcDesc
plazoPago
66
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
9.4 Identificar relaciones de generalización
5e organia y simplifica el modelo usando el principio de *erencia# es decir, se puede generaliar los aspectos comunes de las clases existentes construyendo una superclase, o se puede especialiar una clase en 9arias subclases. /ara nuestro e&emplo se establece relación de generaliación entre agente comercia con cliente y pro9eedor< vendedor
producto
apellido nombre porcComis
nombre precioBase 1..n
parte se forma
1..n
definición
1
cantidad
1..n
numParte descripción
1..n
participa
0..n
compra
se vende
venta
agenteComercial
fecha
cuit razSocial email telf direcc
Se compra
fecha cantidad
1..n
1..n cliente
proveedor
porcDesc
plazoPago
9.5 Refinar el modelo
5e 9alida %ue el diagrama responda a los re%uerimientos. 5e itera y refina el modelo *asta %ue esté completo# es decir, *asta %ue cumpla todos los re%uerimientos se=alados en la descripción del problema.
67
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
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 %ue se tenga entre manos. Una clase describe un con&unto de ob&etos con propiedades similares, relaciones comunes con otros y una semántica com'n Un atributo es una propiedad de una clase %ue describe un rango de 9alores %ue la propiedad podrá contener en los ob&etos de la clase Un enlace es una relación entre ob&etos Una asociación es la relación entre clases "a multiplici%a% es la cantidad de ob&etos de una clase %ue están 9inculados con un ob&eto de la clase asociada. "a Generalización representa la relación entre clases, donde algunas de ellas son tipos de otra "a Agregación representa la relación entre clases, donde algunas de ellas son componentes de otra El Mo%elo %e %ominio es un modelo conceptual %ue muestra clases conceptuales de ob&etos significati9os en un dominio de problema Un %iagrama %e clases es un tipo de diagrama estático del U!", %ue 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 4dentificar clases 4dentificar asociaciones 4dentificar atributos 4dentificar relaciones de generaliación )efinar el modelo • • • • •
68
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
Lectura Desarrollo %e un mo%elo %e %ominio ()*
El modelado de dominio se realia *abitualmente en reuniones organiadas por los analistas del dominio, %ue utilian U!" y otros lengua&es de modelado para documentar los resultados. /ara formar un e%uipo efica, estas reuniones deber$an incluir tanto a expertos del dominio como a gente con experiencia en modelado. El ob&eti9o del modelado del dominio es com prender y describir las clases más importantes dentro del contexto del sistema. "os dominios de tama=o moderado normalmente re%uieren entre +D y AD de esas clases. "os dominios más grandes pueden re%uerir muc*as más. "os restantes cientos de clases candidatas %ue los analistas pueden extraer del dominio se guardan como definiciones en un glosario de términos, de otra manera, el modelo de dominio se *ará demasiado grande y re%uerir$a más esfuero del necesario para esta parte del proceso. 1lgunas 9eces, como en los dominios del negocio muy pe%ue=os, no es necesario desarrollar un modelo de ob&etos 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 utiliar un 9ocabulario com'n. "a terminolog$a com'n es necesaria para compartir el conocimiento con los otros. Cuando abunda la confusión, el proceso de ingenier$a se *ace dif$cil, si no imposible. /ara construir un sistema softLare de cual%uier tama=o, los ingenieros de *oy en d$a deben 0fundir2 el lengua&e de todos los participantes en uno solo consistente. /or 'ltimo, es necesario una llamada de atención sobre el modelo de dominio. /uede ser bastante fácil el comenar modelando las partes internas de un sistema y no su contexto. /or e&emplo, algunos ob&etos del dominio podr$an tener una representación inmediata en el sistema, y algunos analistas del dominio podr$an a su 9e caer en la trampa de especificar los detalles relati9os a esta representación. En casos como éstos, es muy importante recordar %ue el ob&eti9o 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 re%uisitos del sistema %ue se desprenden de este contexto. En otras palabras, el modelado del dominio deber$a contribuir a una compresión del problema %ue se supone %ue el sistema resuel9e en relación a su contexto. El modo interno por el cual el sistema resuel9e éste problema se trata en los siguientes flu&os de análisis, dise=o e implementación.
(R Pacobson (DDD
69
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
Actividades Desarrollar el modelo de dominio para el siguiente caso
Una 4nstitución Educati9a *a decidido brindar unos cursos extracurriculares, tanto para sus alumnos como para personas externas a la 4nstitución. "as raones para la inclusión de personas no pertenecientes a la 4nstitución son< obtener fondos para la moderniación de las instalaciones y ayudar al pago de los 9iáticos de los profesores in9itados. 5e desea desarrollar una aplicación %ue permita administrar el dictado de los cursos# una primera aproximación del contexto del negocio es el siguiente< 5e brinda 9arios cursos. Cada curso tiene un nombre, un cupo máximo y un cupo m$nimo el cual, si no se alcana, *ace %ue 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. 1 cada alumno se le da un material general, independientemente de la cantidad de cursos en %ue se *aya inscrito, además de un material particular para cada curso en el %ue esta inscrito. 5e desea controlar si se le *a entregado, o no, tanto el material general como los materiales particulares a cada alumno. Un alumno puede asistir a muc*os cursos y cada curso debe tener una cantidad m$nima de inscritos Scupo m$nimoN y no sobrepasar el cupo máximo. >e 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 S'nico para todos los cursosN, forma de pago Nefecti9o, c*e%ue o tar&etaN y monto pagado. 1 cada curso se le asigna una 'nica aula %ue tiene un nombre, una ubicación y una capacidad. 7o puede asignarse un aula a un curso cuyo cupo máximo no entre en la misma. 8ambién se desea controlar si el alumno 9a asistir como oyente Sno se presenta a examen ni realia prácticosN a cada curso en donde se inscribió. Esta información es 'til para %ue el docente organie el dictado.
70
Sistema a Distancia
Análisis de Sistemas - Unidad IV
César Luza Montero
Autoevaluación Conteste las siguientes preguntas 1. La diferencia entre clase y objeto es 2. Proporciones una ejemplo de clase con algunos de sus atributos , y tres ejemplos de objetos de dicha clases 3. Una clase conceptual es 4. La diferencia entre enlace y asociación es 5. La diferencia entre generalización y agregación es 6. El modelo de domino es 7. Un diagrama de clases es 8. La multiplicidad de una asociación representa 9. Una clase-asociación es
Exploración on-line •
Portal del producto IBM Rational Modeler http://www-01.ibm.com/software/awdtools/modeler/
•
Pagina de Craig larman http://www.craiglarman.com/wiki/index.php?title=Main_Page
Referencias bibliográficas •
•
•
"arman, C. (+. -" y patrones' introducci#n al análisis y diseo orientado a o!/etos. !exico >.F. /renticeNMall Mispanoamericana. )umbaug*, P. et. al. (+-. -odelado y diseo orientados a o!/etos. -etodología 0-& . !exico >.F. /rentice Mall Mispanoamericana. Pacobson, 4., 3ooc*, 6. y )umbaug*, P. (DDD, 1l Proceso nificado de Desarrollo de 2oft3are. !adrid. /earson Educación 5.1.
71
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
QUINTA UNIDAD EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO
• • •
¿Qué es un requerimiento?, ¿Cómo se clasifican? ¿Qué es un modelo de casos de uso?¿Cuáles son sus elementos? ¿Cómo se construye un modelo de casos de uso?
72
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
Lección 10 Conceptos asociados los requerimientos La importancia de la especificación y análisis de requerimientos en un proyecto de desarrollo de software es evidente; pues, sirve de base para planificación del proyecto y para verificar si el producto software es de calidad, en otras palabras, si se an cubierto o no las necesidades de los usuarios!clientes" #ucos proyectos fracasan por una mala definición, especificación y administración de requerimientos; la e$periencia a demostrado que las actividades relacionadas con los requerimientos es comple%a, por la falta de participación de los usuarios, len&ua%e distinto entre desarrolladores y usuarios, requerimientos cambiantes, entre otras ra'ones" (or ello, es importante para el profesional involucrado en proyectos de desarrollo de software poseer las suficientes competencias para la captura y administración de los requerimientos a fin de afrontar con é$ito esta tarea" )n esta lección se define y caracteri'a el concepto de requerimientos y se describen técnicas para la captura de los mismos" 1.1 ¿Qué es un requerimiento?
*+n requerimiento es una condición o capacidad a la que debe a%ustarse el sistema que se construye" -.acobson, /0001 2e acuerdo con la 3))) 4td" 560"6/76880, *un requisito es9 -61 +na condición o capacidad necesaria para un usuario para resolver un problema o conse&uir un ob%etivo" -/1 +na 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" -:1 +na representación documentada de una condición o capacidad como las definidas en -61 o -/1 -3))), 68801" *+n requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste -4omerville, /001" 1.2 Tipos de Requerimientos
Los requerimientos se pueden dividir en dos tipos9 o funcionales" 1.2.1 Requerimiento Funcional
+n
73
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
)l sistema permitirá a los profesores9 Consultar los orarios de sus cursos, Consultar la pro&ramación de los e$ámenes, Actuali'ar y ver su información personal,
+n o funcional es un requerimiento que especifica propiedades del sistema, como restricciones del entorno o de implementación, rendimiento, dependencia de la plataforma, mantenibilidad, e$tensibilidad o fiabilidad; especifica restricciones fsicas sobre un requisito funcional -.acobson, /0001" +n requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se desarrolla" Al&unos e%emplos de requerimientos no funcionales son9 •
•
•
)l sistema debe brindar una interfa' de usuario intuitiva y sencilla, con un buen mecanismo de ayuda on7line" )l sistema debe disponer de una documentación adecuada que facilite las tareas de mantenimiento"" La tasa de disponibilidad del sistema debe ser de un 88B"
1.3 Clasificación de Requerimientos: Modelo FURPS
+na manera de cate&ori'ar los requerimientos está descrita en el modelo =+<(4 -Larman, /00/19 Functionality -=uncionalidad1, Usability -Capacidad de +so1, Reliability -=iabilidad1, (erformance -2esempeo1 y Supportability -Capacidad de 4oporte1" Functionality -=uncionalidad1, son aquellos requerimientos que refle%an las caractersticas
fundamentales -requerimiento funcional o funcionalidades del sistema1, además de capacidades y se&uridad" Usability -Capacidad de +so1, son aquellos requerimientos que representan facilidad o
nivel de uso del producto; es decir, el &rado en el que el diseo de un elemento facilita o dificulta su mane%o" 4e incluyen9 =actores umanos, )stética, Consistencia de la interfa' de usuario, Ayudas en lnea, A&entes y wi'ards, 2ocumentación de usuario y material de entrenamiento" (or e%emplo, Disibilidad del te$to a una cierta distancia y Combinación de colores del te$to" Reliability -=iabilidad1, son aquellos que muestran la capacidad de un sistema o
componente para e%ecutar sus funciones requeridas ba%o condiciones normales en un periodo de tiempo especifico" Eiene si&uientes sub7cate&oras9 2isponibilidad, especifica el porcenta%e de tiempo disponible, oras de uso, acceso para mantenimiento, etc"; Eiempo medio entre fallas; Eiempo medio para reparación, cuánto tiempo es posible que el sistema esté inoperante después que falla; )$actitud9 se especifica la precisión y e$actitud -se&Fn al&Fn estándar conocido1 que se requiere para las salidas del sistema; Cantidad má$ima de errores o porcenta%e de defecto, &eneralmente e$presado en términos de errores por miles de lneas de códi&o o errores por punto funcional; )rrores o porcenta%e de defecto, cate&ori'ados en términos de errores menores, si&nificantes y
74
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
crticos -se debe definir que si&nifica error *crtico, por e%emplo pérdida completa de dato o imposibilidad de uso de ciertas funcionalidades del sistema" Performance -2esempeo1, se refieren a las caractersticas de rendimiento del sistem"
3ncluye tiempos de respuesta especficos" (or e%emplo9 Eiempo de respuesta para una transacción -promedio, má$imo1; Eransacciones por se&undo; Capacidad, como por e%emplo el nFmero de clientes o transacciones que el sistema puede soportar; #odos de de&radación, esto es, cual es el modo aceptable de funcionamiento cuando el sistema a sido de&radado de al&una manera; +tili'ación de recursos9 memoria, disco, comunicaciones, etc" Supportability -Capacidad de 4oporte1, son requerimientos que refuer'an el soporte y
mantenimiento del sistema que está siendo construido, incluyendo normas de codificación, convenciones de nombres, libreras, acceso para mantenimiento, utilidades de mantenimiento si las ay" Como requerimiento que ayuda al mantenimiento se debe acer referencia al uso de nomenclatura comFn para el desarrollo del sistema, y a la metodolo&a de desarrollo" ALGUNOS REQUERIMIENTOS FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA FACULTAD DE INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES El sistema permitir al se!retari" a!a#$mi!", i%tr"#&!ir las asi'%at&ras (&e se imparte% e% el semestre a!a#$mi!", l"s #at"s #el #"!e%te asi'%a#" a !a#a se!!i)%, #e te"r*a + pr!ti!a, #e la asi'%at&ra, l"s #at"s #e las a&las #e te"r*a &-i!a!i)% + a."r"/ + #e pr!ti!as &-i!a!i)%, sistemas "perati0"s, s".t1are,222/2 La !"%.i'&ra!i)% #el 3"rari" se lle0a a !a-" #ire!tame%te s"-re &%a pla%tilla 3"raria sema%al, e% la (&e !a#a !asilla represe%tar &%a 3"ra e% &% #etermi%a#" #*a #e la sema%a2 C&a%#" el Se!retari" p&lsa esa !asilla se m"strar% las asi'%at&ras #el !&rs" (&e se est$ !"%.i'&ra%#" e% ese m"me%t"2 U%a 0e4 es!"'i#a las asi'%at&ras se m"strar% las se!!i"%es #e te"r*a + pr!ti!a a l"s (&e t"#a0*a %" se les 3a asi'%a#" &% 3"rari"2 Al es!"'er &%a se!!i)% se m&estra% las a&las #isp"%i-les si es &% 'r&p" #e te"r*a/ " l"s la-"rat"ri"s (&e !&mple% las restri!!i"%es #e sistemas "perati0"s esta-le!i#as para esa materia + (&e %" est% "!&pa#"s a esa 3"ra2 El sistema p"#r ser !"%s<a#" p"r !&al(&ier &s&ari", (&e p"#r !"%s<ar el 3"rari" #e &%a asi'%at&ra, &% !i!l", " #e &% a&la " la-"rat"ri" !"%!ret"s2
ALGUNOS REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA FACULTAD DE INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES La tasa #e #isp"%i-ili#a# #el sistema #e-e ser #e &% 5562 El sistema #e-e te%er &%a i%ter.a4 #e &s" i%t&iti0a + se%!illa, !"mpleme%ta#a !"% &% -&e% sistema #e a+&#a2 El sistema #e-e #isp"%er #e &%a #"!&me%ta!i)% .!ilme%te a!t&ali4a-le (&e permita reali4ar "pera!i"%es #e ma%te%imie%t" !"% el me%"r es.&er4" p"si-le2
1.4 Características de los Requerimientos
+n requerimiento debe ser9 •
•
)specificado por escrito, como todo contrato o acuerdo entre dos partes" (osible de probar o verificar, si un requerimiento no se puede comprobar, entonces, ¿como se sabe si se cumplió con él o no?
75
Sistema a Distancia
Análisis de Sistemas - Unidad V
•
•
•
•
César Luza Montero
Conciso, un requerimiento es conciso si es fácil de leer y entender" 4u redacción debe ser simple y clara para aquello que vayan a consultarlo en el futuro" Completo, un requerimiento esta completo si no es necesario ampliar detalles en su redacción, es decir si se proporciona la información suficiente para su comprensión" Consistente, un requerimiento es consistente si no es contradictorio con otro requerimiento" >o ambi&uo, un requerimiento no es ambi&uo cuando tiene una sola interpretación" )l len&ua%e usado en su definición, no debe causar confusión en el lector"
1.5 Dificultades para definir los Requerimientos •
Los requerimientos no son obvios y vienen de mucas fuentes
•
4on difciles de e$presar en palabras -el len&ua%e es ambi&uo1
•
La cantidad de requerimientos en un proyecto puede ser difcil de mane%ar
•
+n requerimiento puede cambiar a lo lar&o del ciclo de desarrollo"
•
)l usuario no puede e$plicar lo que ace"
•
)l usuario tiende a recordar lo e$cepcional uy olvidar lo rutinario
•
Gablan de lo que no funciona
•
Los usuarios tiene distinto vocabulario que los desarrolladores
•
+san el mismo termino con distinto si&nificado
1.6 Técnicas para obtener Requerimiento 1.6.1 Entrevistas
)sta técnica es adecuada para la primera toma de contacto" )s conveniente comen'ar por pre&untas de !"%te7t" li-re, para entender9 el problema, a las personas interesadas en la solución, naturale'a de ésta, y lo&rar efectividad de la reunión" )%emplos de pre&untas centradas en el cliente, los ob%etivos &lobales y beneficios • • • •
¿Quién solicita el traba%o? ¿Quién utili'ará la solución? ¿Cuál será el beneficio económico de una buena solución? ¿)$isten otras alternativas a esta solución?
)%emplos de pre&untas sobre el problema y la solución • • • •
¿Qué entiende el cliente por una solución *correcta? ¿Qué problemas afrontará esta solución? ¿)n qué entorno se va a implantar la solución? ¿)$isten restricciones o aspectos de rendimiento importantes?
76
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
)%emplo de pre&untas sobre la efectividad de la reunión •
• • •
¿)s usted la persona adecuada para responder a estas pre&untas? ¿4us respuestas son *oficiales? ¿4on relevantes mis pre&untas para su problema? ¿Gay al&uien más que pueda proporcionar información adicional? ¿Gay al&o más que debera pre&untar?
(roblemas de las entrevistas9 (ueden sur&ir malentendidos Hmisión de información #ala relación de traba%o -*nosotros7ellos1 • • •
1.6.2 JAD
)l 2iseo en Con%unto de Aplicaciones -.A2, *.oint Application 2esi&n1 fue desarrollado por 3I# a finales de los setenta" )s una sesión de traba%o con participación de todos los involucrados" )l resultado de la sesión es un documento de especificación que incluye definiciones de elementos de datos, flu%os de traba%o y pantallas de interfa'" )l resultado de una sesión .A2 representa un acuerdo entre usuarios, clientes y desarrolladores y minimi'a los cambios posteriores de requerimientos" Las actividades de la sesión .A2 son9 2efinición del proyecto , 3nvesti&ación, preparación, 4esión, preparación del documento final" Definición del proyecto9 el coordinador se entrevista con &erentes y clientes para
determinar ob%etivos y alcance del proyecto" 4e elabora la *&ua de definición administrativa" Investigación9 se entrevista a usuarios y se recopila información del dominio, descripción
de flu%os de traba%o y asuntos a tratar en la reunión" 4e elabora la *a&enda de sesión y la *especificación preliminar" (reparación9 el coordinador elabora un *documento de traba%o o primer borrador del documento final" Sesión9 el coordinador &ua al equipo para crear la especificación del sistema en una
reunión que puede durar varios das" 4e definen los flu%os de traba%o, elementos de datos, pantallas, informes,""" Las decisiones se documentan en unos formularios" Preparación de documento final9 el coordinador prepara el *documento final usando los
*formularios y se distribuye a los asistentes para su revisión" 4e reali'a una reunión para discutir revisiones y finali'ar el documento"
77
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
Lección 11 Conceptos asociados al Modelo de casos de uso 4e an establecido diversas técnicas para la especificación de requerimientos" La técnica de casos de uso -.acobson, 8:1 se a 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 &ran influencia sobre todas las fases del proceso de desarrollo" 11.1
¿Qué es el modelo de casos de uso?
)l Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del sistema en forma de Casos de uso" 4u ob%etivo es comunicar la funcionalidad y el comportamiento al cliente y usuario" )l modelo de casos de uso esta compuesto por actores, casos de uso, descripción de cada caso de uso y el dia&rama de casos de uso" 11.2
Actor
+n actor define un con%unto coerente de roles que los usuarios del sistema pueden %u&ar cuando interactFan con él" +na instancia de actor puede ser un individuo o un sistema e$terno" La notación +#L para el actor se muestra en la fi&ura 66"6" (or e%emplo, en el 4istema de Académico de la universidad, los actores pueden ser9 4ecretario Académico, Alumno y 2ocente" Eodos ellos interactFan con el sistema a través de al&una de sus funcionalidades" >ótese que el nombre del actor represente el rol que desempean &rupos de usuarios, por e%emplo el rol alumno representa a todos los alumnos; un alumno particular representa una instancia del actor alumno" =i&ura 66"6 Actor
11.3
Caso de Uso
+n caso de uso define un con%unto de escenarios de casos de uso" +n escenario es una secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a un actor particular -.acobson, 8:1" La fi&ura 66"/ muestra la notación +#L de caso de u so" (or e%emplo, consideremos el si&uiente escenario para reali'ar el ormal 6" /" :" J" "
) cliente inserta su tar%eta en la ranura del ca%ero automático )l ca%ero automático solicita in&reso de clave secreta )l cliente in&resa su clave secreta )l ca%ero automático muestra menF de opciones )l cliente selecciona opción *
78
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
5" )l ca%ero automático muestra relación de cuentas del cliente K" )l cliente eli&en cuenta " )l ca%ero automático solicita cantidad 8" )l cliente in&resa cantidad a retirar 60" )l ca%ero automático dispensa el dinero y termina" )sta secuencia de interacciones entre el cliente y el ca%ero automático termina, de forma normal, se dispensa el dinero del cliente" Htras secuencias que no si&uen este flu%o normal, pueden ser9 )scenario9 clave incorrecta 6" /" :" J"
) cliente inserta su tar%eta en la ranura del ca%ero automático )l ca%ero automático solicita in&reso de clave secreta )l cliente in&resa su clave secreta )l ca%ero automático muestra mensa%e de error *Clave incorrecta
)scenario9 4aldo insuficiente 6" ) cliente inserta su tar%eta en la ranura del ca%ero automático /" )l ca%ero automático solicita in&reso de clave secreta :" )l cliente in&resa su clave secreta J" )l ca%ero automático muestra menF de opciones " )l cliente selecciona opción *
11.4
Descripción de caso de uso
4e an establecido diversas plantillas para describir un caso de uso" Larman -/00/1 seala que la descripción de un caso de uso, básicamente, debe contener9 >ombre del caso de uso, Actor, (recondiciones, (oscondiciones, =lu%o básico y =lu%os alternativos" )l nombre del caso de uso debe ser claro e indicar la función requerida que el sistema debe proveer a los actores" (or e%emplo,
79
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el actor" )stablecen lo que siempre debe cumplirse antes de comen'ar un escenario en un caso de uso" >ormalmente implica que un escenario de otro caso de uso se a completado e$itosamente" )stas deben redactarse en tiempo verbal pasado" (or e%emplo9 El &s&ari" 3a si#" a!epta#" e% el sistema !"% el r"l #e pr".es"r " Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de uso a terminado con é$ito; establecen lo que debe cumplirse cuando el caso de uso termina, son la &aranta de é$ito" )stas deben redactarse en tiempo verbal pasado" (or e%emplo9 4e a re&istrado en el sistema las notas de los alumnos" )l flu%o básico, es la descripción narrativa de lo que debe ocurrir cuando los actores interactFan con el sistema para satisfacer la meta u ob%etivo propuesto, se consideran los pasos normales, no incluye las alternativas o variaciones" Los flu!os alternativos, refle%a las diferentes situaciones que provocan una desviación del flu%o básico de eventos, se consideran, condiciones anormales, e$tremas, ocasionales, condiciones de error o violaciones de re&las" )%emplo de flu%o básico9 6" El Cas" #e &s" !"mie%4a !&a%#" el pr".es"r i%#i!a 8re'istrar %"tas29 /" El sistema m&estra &% ."rm&lari" #e 0ali#a!i)% #e i%'res" al sistema2 :" El &s&ari" i%'resa s& !)#i'" + s& !"%trase:a2 J" El sistema m&estra l"s !&rs"s asi'%a#"s al pr".es"r2 " El pr".es"r sele!!i"%a el !&rs"2 5" El sistema m&estra &% lista#" #e l"s est&#ia%tes !"% s&s %"tas2 K" El pr".es"r sele!!i"%a el est&#ia%te e i%'resa la %"ta #e pr!ti!a, #el par!ial, #el e7ame% .i%al + la %"ta .i%al2 Se repite para !a#a est&#ia%te2 " El pr".es"r i%#i!a 8'&ar#ar92 8" El sistema 0ali#a t"#a la i%."rma!i)% + m&estra &% me%sa;e #e !"%.irma!i)% + el Cas" #e &s" .i%ali4a2 )%emplos de flu%os alternativos9 C)#i'" " C"%trase:a erra#"s< E% el pas" =, si !)#i'" " !"%trase:a #i'ita#"s p"r el &s&ari" s"% erra#as, el sistema m&estra me%sa;e #e err"r + 0&el0e a s"li!itar !)#i'" + !"%trase:a2 Pr".es"r si% !&rs"s asi'%a#"s< E% el pas" =, si el sistema #etermi%a (&e el pr".es"r %" tie%e !&rs"s asi'%a#"s, m&estra me%sa;e #e err"r + el !as" #e &s" .i%ali4a2 11.5
Diagrama de casos de uso
+n dia&rama de caso de uso muestra los actores los casos de uso y las relaciones entre ellos" La fi&ura 66": muestra un e%emplo de dia&rama de casos de uso, para un sistema de &estión académica" 4e observa dos actores9 profesor y alumno, mediante la relación de &enerali'ación se puede afirmar que el profesor y el alumno son dos tipos de usuarios, Los casos de uso comunes para ambos son9 consultar orarios, validar acceso y consultar orario de e$ámenes" (articularmente, el estudiante puede consultar notas de un curso y
80
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
mantener información del estudiante" )l profesor puede mantener información de profesor, re&istrar notas de un curso y cerrar un curso" =i&ura 66": 2ia&rama de casos de uso
Consultar notas de un curso Estudiante Consultar horarios de cursos
(from Actors)
Mantener información del es tudiante Cerrar un curso
Validar acceso Usuario
Mantener información del profesor
(f rom Actors)
Consultar horario de exámenes Profesor
Registrar notas de un curso
(from Actors)
Relaciones entre casos de uso
)ntre dos casos de uso puede aber las si&uientes relaciones9 )$tend e includes" +na relación extend se cuando un caso de uso especiali'a a otro e$tendiendo su funcionalidad" +na relación include se usa cuando un caso de uso incluye a otro" 4e representan como una lnea que une a los dos casos de uso relacionados, con una fleca en forma de trián&ulo y con una etiqueta MMe$tiendeNN o MMincludeNN se&Fn sea el tipo de relación"
81
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
Lección 12 Proceso de construcción del modelo de casos de casos de uso
)n esta lección se presentan los pasos a se&uir para la construcción de un modelo de casos de uso; para tal efecto, consideremos la si&uiente descripción de requerimientos9
La )mpresa A34, dedicada al servicio de transportes aéreos, necesita un sistema de información para &estionar y mantener los datos de unidades, vuelos, pilotos, pasa%eros y reservas" 2espués de aber dialo&ado con el )ncar&ado de Duelos se concluyo que es responsable de #antener la información de las distintas unidades9 el nFmero, el tipo de avión, la feca de compra, el modelo, la capacidad de car&a y la capacidad de pasa%eros" 2etermina los vuelos que llevan car&a, para los mismos necesita &uardar la feca, el piloto, el lu&ar de ori&en, el destino, el peso de la car&a y el monto del vuelo" 2efine los vuelos de pasa%eros9 fi%a la feca, el piloto y su tripulación, ori&en, destino y capacidad de pasa%eros" )l &erente nos informó que9 #antiene la información de los pilotos que traba%an en la empresa, para el mismo &uarda el nFmero de piloto, el nombre, dirección, abilitación, feca del Fltimo control médico" >ecesita que el sistema le devuelva dado un piloto, los vuelos que a reali'ado en un periodo dado" )l empleado de ventas nos e$plicó que9 #antiene información de los pasa%eros de los diferentes vuelos, para cada uno se le incorpora un nFmero de identificación, el nombre, profesión, el teléfono y la dirección" Los pasa%eros reali'an reservas para los distintos vuelos, si no ay espacio disponible, se reca'a el pedido de reserva para ese vuelo" Confirma los pasa%eros que toman los vuelos" 4ólo se admiten pasa%eros que ayan reali'ado reservas previas" >ecesita un reporte con los pasa%eros que tomaron un vuelo"
12.1
Identificando actores
(ara identificar actores, podemos pre&untar ¿Quién está interesado en cierto requerimiento o se beneficia o se ve afectado por al&Fn servicio del sistema?, ¿2ónde en la or&ani'ació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 pre&untas pueden considerar &rupo de personas, departamentos u otros sistemas" )n nuestro caso, los actores identificados son9
Encargado de vuelos
12.2
Gerente
Empleado de ventas
Identificando casos de uso
(ara identificar casos de uso se su&iere pre&untar9 ¿Cuáles son las tareas que reali'a el actor?, ¿Que ob%etivos concretos necesita alcan'ar un actor?, ¿(uede el actor crear, almacenar, remover o leer información en el sistema?, )l actor, ¿necesita estar informado
82
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
acerca de las ocurrencias del sistema? Las respuestas a estas pre&untas refle%an funcionalidades del sistema para cada actor" )n nuestro caso, el actor )ncar&ado de vuelo debe9 #antener información de unidades,
Mantener informacion de unidades
Mantener informacino de pilotos
Registrar reservas de vuelo
12.3
Registrar vuelo de carga
Registrar vuelo de pasajeros
Consultar vuelos por pilotos
Mantener informacion de pasajeros
Registrar confirmación de vuelo
Consultar pasajeros que tommaron vuelo
Elaborando la descripción de casos de uso
(or cada caso de uso se elabora su descripción" )n nuestro caso, solo desarrollaremos descripción de al&unos casos de uso" "ombre C#U#S# ctor Precondición Poscondición
Consultar Duelos por (iloto @erente )l usuario a sido admitido en el sistema con el rol de @erente )l sistema muestra los vuelos reali'ados por piloto Flu!o $%sico
6" /" :" J" " 5" K" " 8"
)l caso de uso se inicia cuando el @erente indica *Duelos
Imprimir
)n el paso K, si el &erente indica *3mprimir, el sistema imprime la información consultada" "o &ay vuelos en periodo
)n el paso 5, si no e$isten vuelos del piloto en el periodo seleccionado, el sistema muestra mensa%e *(iloto no tiene re&istrado vuelos en el periodo y re&resa a solicitar información"
83
Sistema a Distancia
Análisis de Sistemas - Unidad V
"ombre C#U#S# ctor Precondición Poscondición
César Luza Montero
#antener información de unidades )ncar&ado de vuelos )l usuario a sido admitido en el sistema con el rol de )ncar&ado de vuelos 4e a re&istrado información de unidades Flu!o $%sico
Ingresar
6"
)l caso de uso comien'a cuando el )ncar&ado de Duelo indica *#antener 3nformación de unidad" )l 4istema muestra las opciones9 *3n&resar, *#odificar y *)liminar" )l )ncar&ado de Duelo eli&e la opción *3n&resar" )l 4istema muestra el formulario para llenar datos de una nueva unidad" )l )ncar&ado de Duelo in&resa datos de la unidad9 el nFmero, el tipo de avión, la feca de compra, el modelo, la capacidad de car&a y la capacidad de pasa%eros" )l )ncar&ado de Duelo indica *@uardar" )l 4istema re&istra la información de la nueva unidad" )l caso de uso finali'a"
/" :" J" " 5" K" "
Flu!os lternativos Modificar
6" /" :" J" " 5" K" "
)l flu%o se inicia cuando el )ncar&ado de Duelo eli&e la opción *#odificar" )l 4istema muestra relación de unidades )l )ncar&ado de Duelo selecciona unidad cuyo datos desea modificar )l 4istema muestra formulario con los datos de la unidad a modificar )l )ncar&ado de Duelo reali'a modificaciones )l )ncar&ado de Duelo indica *@uardar" )l 4istema re&istra las modificaciones" )l caso de uso finali'a"
'liminar
6" /" :" J" " 5" K"
)l flu%o se inicia cuando el )ncar&ado de Duelo eli&e la opción *)liminar" )l 4istema muestra relación de unidades" )l )ncar&ado de Duelo selecciona unidad que desea eliminar" )l 4istema muestra formulario con datos de unidad a eliminar" )l )ncar&ado de Duelo indica *Confirmar )l 4istema re&istra la eliminación de la unidad" )l caso de uso finali'a"
Cancelar
6" )n cualquier momento, el usuario indica *Cancelar, entonces, /" )l sistema no re&istra dato al&uno y el caso de uso finali'a" Código Repetido
6" )n el paso K de in&resar y K de modificar, si el nFmero de unidad se repite, /" )l sistema muestra un error y re&resa a solicitar datos
84
Sistema a Distancia
Análisis de Sistemas - Unidad V
12.4
César Luza Montero
Elaborando el diagrama de casos de uso
4e asocia cada actor con su caso de uso, obteniéndose el si&uiente dia&rama de casos de uso
Registrar vuelo de carga Encargado de vuelos
Mantener información de unidades
Registrar vuelo de pasajeros
Gerente
Consultar vuelos por pilotos
Mantener información de pilotos
Mantener informacion de pasajeros Registrar reservas de vuelo
Empleado de ventas
Consultar pasajeros que tommaron vuelo
Registrar confirmación de vuelo
85
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
Resumen Conceptos asociados a los requerimientos •
• •
•
•
+n requerimiento es una condición o capacidad a la que debe a%ustarse el sistema que se construye" +n requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste )l requerimiento o requisito funcional describe que debe acer el sistema respecto a su entorno" +n requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se desarrolla" (ueden ser de9 usabilidad, fiabilidad, desempeo, capacidad de soporte" La entrevista es una técnica para obtener requerimientos usada en las primeras tomas de
contactos con los usuarios7clientes" )l dise(o con!unto de aplicaciones, .oint Application 2esi&n -.A21 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 )l Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del • •
•
•
•
•
•
sistema en forma de Casos de uso" +n actor define un con%unto coerente de roles que los usuarios del sistema pueden %u&ar cuando interactFan con él" +n caso de uso define un con%unto de escenarios de casos de uso" +n 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 a terminado con é$ito; establecen lo que debe cumplirse cuando el caso de uso termina, son la &aranta de é$ito" Los flu!os alternativos, refle%a las diferentes situaciones que provocan una desviación del flu%o básico de eventos, se consideran, condiciones anormales, e$tremas, ocasionales, condiciones de error o violaciones de re&las" +n dia&rama 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 • • • •
3dentificación de actores 3dentificación de casos de uso )laboración de descripción de casos de uso )laboración de dia&rama de casos de uso
86
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
Lectura Crear el dise(o lógico de una interfa) de usuario *+,
Cuando los actores interactFan con el sistema, utili'aran y manipularan elementos de interfaces de usuario que representan atributos -de los casos de uso1" A menudo estos son términos del &losario -por e%emplo, balance de cuenta, feca de vencimiento y titular de cuenta1" Los actores pueden e$perimentar estos elementos de las interfaces de usuario como iconos, listas de elementos u ob%etos en un mapa /2, y pueden manipularlos por selección, arrastre o ablando con ellos" )l diseador de interfaces de usuario identifica y especifica estos elementos actor por actor, recorriendo todos los casos de uso a los que el actor puede acceder, e identificando los elementos apropiados de la interfa' de usuario para cada caso de uso" +n Fnico elemento de interfa' de usuario puede intervenir en mucos casos de uso, desempeando un papel diferente en cada uno" As, los elementos de la interfa' de usuarios pueden disearse para %u&ar varios roles" 2eberamos responder a las si&uientes pre&untas por cada actor9 • • • • •
¿Qué elementos de interfa' de usuario se necesitan para posibilitar el caso de uso? ¿Cómo deberan relacionarse unos con otros? ¿Cómo se utili'aran en los diferentes casos de uso? ¿Cuál debera ser su apariencia? ¿Cómo deberan manipularse?
(ara determinar qué elementos de interfa' de usuario necesitan ser accesibles al actor en cada caso de uso, podemos contestar las si&uientes pre&untas9 •
• • •
• • •
¿Qué clases de dominio, entidades del ne&ocio o unidades de traba%o son adecuados como elementos de la interfa' de usuario para cada caso de uso? ¿Con qué elementos de la interfa' de usuario va a traba%ar el actor? ¿Qué acciones puede invocar el actor, y qué decisiones puede tomar? ¿Qué &ua 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? (or e%emplo, ¿Cuántas facturas mane%ará abitualmente un actor durante una sesión y cuál es el saldo medio de la cuenta? >ecesitamos estimaciones apro$imadas de estas cosas porque asi se optimi'ará la interfa' &ráfica de usuario para ellas -incluso aunque ten&amos que permitir un ran&o suficientemente &rande1"
+na forma práctica de traba%o es representar los elementos de la interfa' de usuario mediante notas adesivas, pe&adas en una pi'arra, y ordenadas para ilustrar la apariencia de la interfa' de usuario" 4e&uidamente, los diseadores de interfaces de usuario describen cómo pueden utili'ar los actores estos elementos cuando traba%en con los caso de uso" La venta%a de utili'ar notas adesivas es que pueden representar la cantidad necesario a de datos" Además, las notas adesivas tampoco parecen permanentes "es fácil moverlas o simplemente eliminarlas7, lo que ace que el usuario se sienta cómodo proponiendo cambios"
-O1 .acobson -/0001"
87
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
Actividades 6" 2esarrollar el modelo de casos de uso para el si&uiente sistema para una a&encia de alquiler de autos 3nicialmente, entrevistamos al dueo de la a&encia, quien es el que impulsó el proyecto" Pl está, especialmente, interesado en controlar los &astos de la empresa" >ecesita obtener del sistema información del tipo9 2ado un intervalo de tiempo, todas las reparaciones reali'adas por un monto superior al que él impon&a" )l )mpleado de Atención al (Fblico, nos contó que por cada nuevo alquiler actuali'a la fica re&istro del cliente" )n caso de tratarse de un nuevo cliente, abre una nueva fica con los si&uientes datos9 apellido y nombre, dirección personal, localidad, provincia, tipo y nFmero de documento, profesión y nFmero de licencia de conductor" 2e acuerdo con las restricciones que impone el cliente, se busca si e$iste un veculo disponible" +na ve' que el cliente seleccionó un coce, se crea una fica para el nuevo alquiler9 feca del alquiler, cantidad de das por los que se alquila, importe del alquiler y ilometra%e del veculo al momento de ser alquilado" >o se debe autori'ar alquileres a clientes que no devolvieron en el pla'o o en buen estado el veculo que se les prestó" )l )ncar&ado de Autos es el Fnico autori'ado a actuali'ar la fica re&istro de cada auto" Cada veculo tiene su propia información9 códi&o, descripción, marca -por e%9 =ord =iesta1, modelo -por e%9 68851, estado -alquilado, disponible para alquilar o en reparación1" (or cada veculo lleva nota de todas las reparaciones que recibió" 2e cada reparación mantiene la feca, motivo, costo de la reparación, cantidad de das que el auto no estuvo disponible" Eambién atiende a los clientes que traen los veculos" Controla que el mismo se entre&ue en buen estado y en termino, si no es as le informa al encar&ado de atención al pFblico para que no autorice nuevos alquileres a ese cliente y re&istra en la fica del alquiler el ilometra%e final con que se devuelve el coce" Le &ustara poder consultar los autos mas alquilados" /" Continuar el desarrollo con lo que se indica9 (ara la se&unda etapa de este proyecto se van a incorporar, al sistema, facilidades para acer reservas telefónicas" )n este caso, el )mpleado de Atención al (ublico tomará los datos del cliente, la feca del alquiler, das por los que se va a alquilar y veculo que reserva" +na reserva puede ser cancelada con asta J oras de anticipación" Los clientes que a&an reservas y no retiren el alquiler, no podrán efectuar nuevas reservas ni alquileres" Al final de cada %ornada, el )ncar&ado de Autos lan'ara un proceso que anali'ase las reservas para el pró$imo da y marque los autos que corresponda como reservados"
88
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
Autoevaluación 6" /" :" J" " 5" K" " 8" 60" 66"
+n requerimiento es9 Las diferencias entre un requerimiento funcional y no funciona son9 Los requerimientos se caracteri'an por9 Cuando usara las técnicas de entrevista y .A2 )l modelo de casos de uso representa )l actor es )l caso de uso es +n escenario de caso de uso es +na precondición es +na poscondición es La diferencia entre flu%o básico y flu%o normal es
Exploración on-line •
Sitio de Alistair Cockburn, sobre recursos e información de casos de uso http://alistair.cockburn.us/
Referencias bibliográficas •
•
•
•
•
3))) -68801, 3))) 4td 560"6/76880 3))) 4tandard @lossary of 4oftware )n&ineerin& Eerminolo&y R2escription" ttp9!!standards"ieee"or&!readin&!ieee!stdSpublic!description!se!560"6/76880Sdesc"tml. .acobson, 3", Iooc, @" y
89
Sistema a Distancia
Análisis de Sistemas - Unidad V
César Luza Montero
GLOSARIO •
ctividad )s una unidad de traba%o que debe ser e%ecutada en un proceso de desarrollo de
software" •
rtefacto )s una pie'a de información que es producida, modificada o usada en un proceso
de desarrollo de software" •
Flu!o de traba!o )s una secuencia de actividades que produce un resultado valioso, define una
lista de actividades, traba%adores y artefactos" •
Metodolog-a )s el con%unto de procedimientos, técnicas, erramientas, y un soporte
documental que ayuda a los desarrolladores a reali'ar nuevo software •
Modelo de an%lisis de negocios 2escribe la reali'ación de los casos de uso del ne&ocio
mediante la interacción de los traba%adores del ne&ocio y las entidades del ne&ocio" •
Modelo de casos de uso )s un modelo que describe los requerimientos funcionales del
sistema en forma de casos de uso" •
Modelo de casos de uso del negocio )s una representación de la forma en que la empresa
interactFa con su entorno" •
Modelo de dominio )s un modelo conceptual que muestra clases conceptuales de ob%etos
si&nificativos en un dominio de problema" Las clases conceptuales no muestran componentes software, ni clases software, ni responsabilidades •
.rgani)ación 4istema compuesto por un con%unto de personas, actividades y recursos,
distribuidas de al&una forma -&eneralmente en departamentos o funciones1 con arre&lo a ciertas re&las de división del traba%o y comunicación que interactFan para producir bienes o servicios •
Proceso de desarrollo )s una &ua acerca de las actividades y tareas necesarias para construir
un sistema de información" •
Proceso de negocio Con%unto de actividades que toman uno o más imputs crean un outputs
de valor para el cliente" •
RUP -
software, es una forma disciplinada de asi&nar tareas y responsabilidades en una empresa de desarrollo, es decir define quién ace qué, cuándo y cómo" •
/raba!ador )s un rol que debe ser reali'ada por una persoa o equipo dentro de un proceso de
desarrollo de software"" •
Sistema de información Con%unto de componentes ardware, software, base de datos,
procedimientos y personas, que permiten capturar, procesar, almacenar y distribuir información para una or&ani'ación" •
UM0 -+nified #odelin& Lan&ua&e, Len&ua%e de #odelado +nificado1 es un len&ua%e, basado
en una notación &ráfica, que permite9 especificar, construir, visuali'ar y documentar los elementos de un sistema software, as como para modelar los procesos de ne&ocios u otros sistemas no software"
90
Sistema a Distancia
