2aroana ame Tabla de contenidos Introduccién ‘ema 1 I p EF E campus telesupvirtualcomimad/bookiprint php?¢=266502aroana ame INTRODUCCION Presentacién y contextualizaciin Fl akumno desarrolia una actitud analitica y critica que le permita valorar la etapa de andlsis de requerimientos en el ciclo de vida del desarrollo de los sistemas de informacion, ‘Competencia Aplica las técnicas y métodos de la Ingenieria de Requerimientos para la construceién de sistemas de informacién, expresando sus ideas con coherencia, lbgica, orden, claridad, findamento y buen lenguaje. Capacidades Desartolla casos para capturar los requerimientos de los clientes, Explica las técnicas de entrevistas y encuestas para capturar los requerimientos del cliente. Comprende los principios clave sobre el proceso unificado de desarrollo, Modela casos de uso del negocio aplicado a la realidad empresatal, Actitudes Desartoll una actitud emprendedora mediante la toma de iniciativas, promocién de actividades y toma de decisiones en relaciin a la actividad asignada. ‘Actia con responsabilidad personal, al cumplir con los horatios establecidos y el respeto a ls normas de convivencia ‘Cumple con la presentacién de los trabajos encomendados de manera individual y en equipo, respetando a inciativa y aportes de los integrantes, Desarrolla la creatividad, la innovaciin, la actitud emprendedora y el speto a la honestidad intelectual Ideas bisicas y contenido esenciales de Ia Unidad: La Unidad de Aprendizaje 2: Requerimientos - RUP, comprende el desarrollo de los siguientes temas: 0 Practicos para capturar ls requisitos. TEMA 2 : Métodos de Recokeccin de Informacién. TEMA 3 : Proceso Unificado de desarrollo TEMA 4 : Modelado del Negocio supvirual com/modlbookiprint php?id=26650 3232aroana campus, CASOS PRACTICOS PARA CAPTURAR LOS REQUISITOS CASO 1: SISTEMA BIBLIOTECA ‘Se quiere construir un sisterm de consuita de libros para luna biblioteca. De cada libro la biblioteca almacena: (1) un titulo, (2) una Tita de autores, (3) una referencia bibliogrifica que debe ser timica, (4) una lista de \descriptores y (5) un nimero de ejemplares disponible. |Ademés se permite realizar reservas, de uo 0 varios libros, ‘se sabe que se puede solictar reservas de varios iejemplares, Se registra la informacién completa del libro, ¥ autor, elautor tiene un nombre una nacionalidad, sexo, pais ide origen La gestion del préstamo es un punto central, no se le permitiré el alguiler de un libro a un cliente que! {tiene ejemplares pendientes por devolve. Titulo: ¢Programacién en Java? Autores: 2Luis Pérez?, .Martin Suarez? Referencia ¢SIST-34543-WFR? Descriptores: Java?, Introduccion a la programacién?, ,Computadores?, {Sistemas? Ejemplares disporibles. 20 Dele descripcicn anterior se obtiene los siguientes requerimientos funcionales y no funcionales. EL SISTEMA DEBE SOPORTAR SIETE REQUERIMIENTOS FUNCIONALES: 1. Agregar un nuevo bro. Dbtener fa Ista de libros que tienen ciertas palabras dadas en el tiulo, El sari teclea una 0 varias palabras separadas por un blanco y el sistema le [presenta por pantalla todos los libros que kas incluyen todas en su titulo. Dbtener la Ista de libros escritos por un autor. El usuario teclea el nombre y :pelido de un autor y el sistema le presenta por pantalla todos los Hbros de ls| sales es autor. Dbtener la Ista de libros que tienen alguno de los descriptores dados. El jusuatio teclea hasta 3 descriptores completos y el sistema le presenta por [pantalla todos los libros que incluyen cualquiera de ellos. [Pedir prestado un libro de la biblioteca. El usuario bo debe seleccionar ya sea lesupvirtualcom/modibook!print pp ?id=266502aroan2 name RFOS [por su referencia biblogrifica o a partir de ls listas obtenidas en los voRer un Horo prest bibliogrifica del mismo. lindicar elndmero total de libros dsponibles en la bibboteca y elnamero de libros que se encuentran en préstamo en ese momento. Los Requerimientes Funcionales son los aspectos que tendré que tenerel Software. REQUERIMIENTOS NO FUNCIONALES REQUERIMIENTO NO FUNCIONAL El sistema debe almacenar los libros en una tabla de hashing, con acceso por la referencia bibliogréfica, . Elsistema debe crear indices por palabras del ttulo, autores y descriptores,| utilzando drboles AVL. ‘Solo se pueden utilizar las estructuras de datos de Cupi2 Collections en su forma genérica, sin modificar por ningiin motivo su cédigo. . La actualizacion de la informacién del requerimiento 7 se debe hacer utizando MVC (observable + observador). ‘Todo el disefio debe estar desacoplado utizando interfaces y fibricas. El sistema hace persistir la informacién utilizando serializacién. El ejercicio se debe entregar con al menos 20 libros registrados. - El disefo de la interfaz de usuario corre por cuenta de cada grupo, Debe estar implementada con Visual Editor. Cada grupo debe entregar los documentos detallados de andlisis y disefo, campus, lesupvirtualcom/modibook!print pp ?id=26650 9232aroana ame Aunque los requerimientos no funcionales del ceso sean un poco diffciles de comprender, entiéndase que son las restricclones del sistema. Al final st necesitamos plasmario en un modelo, utilizaremos la netacién de casos de uso que serd explicada mas adelante. CASO 2: RESERVA DE PELICULAS Debe permitir @ los usuarios en general hacer consutas y reservacionas de peliculas, ademas de poder comprar las entradas al cine de manera virtual, sin tener que desplazarse hasta la taguilla del teatro. Se desea que el sistema de reservas esté disponible desde internet AHORA SE DESCRIBEN LOS REQUERIMIENTOS FUNCIONALES: REQUERIMIENTOS FUNCIONALES Consulta de peliculas disponibles. Reserva de peliculas. Pago de boketos para el ingreso. fet horarios de peliculas. Registrar ls tarifs, Registrar bs clientes. Registrar ks peliculas Registrar los cies. REQUERIMIENTOS NO FUNCIONALES REQUERIMIENTO NO FUNCIONAL, ‘La programacidn deberd utilzar el patrin de ddiscfio MVC. ‘Los pagos solo se permiten con tarjetas de rédito. [Elsistema deberd contar con eluso de un titfcado digital, FElsistema deberd instalarse en una plataforma cloud computing. supvirtual comimodIbookiprint phpid=26650 6232aroana METODOS DE RECOLECCION DE INFORMACION LA ENTREVISTA En cl anilsis de sistemas hay que distinguir las formas cualtativas y cuantitativas de informacién. La ‘cualtaiva esté relacionada con opiniones, polticas y descripciones natrativas de actividades 0 problemas y las cuantitativas con nimeros, ffecuencias o cantidades. A menudo las entrevistas son la mejor fuente de informacién cualitatva, [Dentro de las técnicas utiizadas para recopilar informacién, las entrevistas ocupan un lugar preponderante en ‘consideracién con el tiempo que ocupan y el objetivo que tienen. Por lo general, son la mayor fuente de informacién del analista, La entrevista es una forma de conversacién, no de interrogacién, Las entrevistas se pueden realizar sobre la base de un cuestionario rigido o de una guia més © menos, detallada que las orienta hacia puntos bien definidos. Elmétodo de entrevistas para obtener informacién tiene las siguientes ventajas, Permite a los analistas ppresentar sus necesidades de forma ditecta y verificar en las respuestas recibidas, si las preguntas realizadas fucron interpretadas correctamente. Parallevar a efecto una entrevista se deben realizar una serie de pasos y cumplir na serie de raglas para poder asegurar el éxito de la misma. Tee eae ety se deben realizar son: supvirual comimodibookiprint phpid=26650 232aroana ame a Preparaciin 3 Se debe coordinar con el usuario la fecha, la ’ & 9 hora y e! lugar. = i pear 9 3 Se debe garantizar la privacidad, evitar las 4 © interrupciones y cisponer de un tiempo adecuado. BE Se deben obtener criterios previos acerca de las personas que se van a enirevistar para poder desarrolar una conversacién mas natural 3& Se deben preparar cuidadosamente las preguntas a realizar o le guia de la entrevista. 3€ Se debe ser correcto y no preguntar cosas que se pueden obtener por otras vias a menos que se desee comorobar algo 3€ El facto, la imparcialidad e inckiso la vestimenta apropiada yudan a asegurar una entrevista exitosa. 3€ Se debe ser puntual, identificarse y explicar los objetivos de la entrevista 3€ Se debe prestar la maxima atencién durante el desarrollo, crear un clima favorable, evitar caer en discusion con los usuarios, no hacer crticas, uilizer una terminclogia adecuada, no adelantarse a ningin riterio ni opinién de los usuarios y mucho menos sacar Conolusiones instantaneas sobre Ia informacién recibida 3X Diferenciar entre los hechos y las opiniones, entre Ie actividad 0 funcién que realiza y el como la realiza, tratando siemore que la informacién recopilada sea lo mas objetiva posible. € Evitar que la entrevista sea larga o se convierta en inoportunas por razones imprevistas, si esto oourte se debe posponer. 4 Al despedirse se debe mostrar agradecimiento y dejar coordinado otro posivle encuentro. EAL final se debe hacer una pequefia recapitulacién de la informacién recopilada para verificar los hechos registrados. 3. Recapitulacién 3€ Se deten revisar las notas para reordenartas y organizartas por temas, pasarias en impio y comprobar que no existan contradicciones. 36 La recapitulacién de las entrevistas se hace en fl omadain "Ranictn a Aetiarring wv 81232aroana Entrevistar es un arte, asi como una habilidad que se da a través de la préctica y el conocimiento del sistema que se estd investigando. Aquellos que tienen éxito y son efectivos al utitzar Jos métodos de entrevista, durante los estudios de sistemas, estin de acuerdo con las etapas que los analistas deben seguir. Para asegurar que la entrevista sea it, el anata debe seguir las siguientes indicaciones: Do ee eee - Realice una cita por anticpado con quienes vaya a entrevista {[ ss enirevistas son exitosas solo si se han planeado y arreglado con cuidado por anticipado, Entrar en laf oficina de un alto dirgente sin anunciarse antes seria un error. Avisele a los entrevistados sobre la naturaleza [eH ettevisa.Planéese mantener uns entrevista comin por no mis de un hor — I So ee ee 2.- Prepararse conociendo de antemano a bs individuos que va entrevista, Familaricese con el tema de Ia entrevista y prepdrese un conjunto apropiado de preguntas que deben contestarse durante las conversaciones plancadas. SS SS —=— se So [s- Darane le Farevta 1 TF Comience por presentarse subrayando el tema de la entrevista y estableciendo fa naturaleza del I proyecto sobre el cual se trabaja, 1 TF comience con preguntas generales que establecerdn el marco de trabajo con el cual se conduc el I resto de la entrevista I FF continiese com los temas y aspectos que surjan de quienes responden. F3| Asegirese de encontrar por I qué quienes responden ercen que es tan importante cl tema como para comentario. Limitense las notas que se eseriban para evitar dstraer @ quienes responden. WBE cua todos is tes vos com bs eutevistdos ¢ hayan disco, reatbease ous preemies _fsPecteas que se ere deban discus, 4 supvirtual comimodibookiprint phpid=26650 91232aroana ame 1B) alfa de ta entrevista resimase la informaciin recabada durante la misma, Sise considera apropiado, 4 ee, que se preparari para quienes responieron un resumen escrito de la entrevista para que puedan eramnaro. Consiérese Ia posbikad de contimar conlas ermevstas despuis, ay gy at EL CUESTIONARIO Los cuestionarios constituyen la tinica forma posible de poder relacionarse con un gran numero de personas para conocer varios aspectos del sistema, sin tener que estar presente. Los cuestionarios como medio para recoger opiniones o hacer encuestas pueden ser de gran utilidad si se usa en forma adecuada, o sea, si se aplican en una situacién especifica para la cual fueron disefiados especialmente y ademés este disefto retine una serie de requisitos. Entre los principales inconvenientes de los cuestionarios podemos sefalar las siguientes: TF Muchos usuarios que pueden ofrecer una buena cantidad de informacién, se resisten o la dan en poca lcantidad cuando se trata de suministrara por escrito los entrevistados pueden objetar muchas preguntas, interpretarlas a su forma 0 no tomarlas en sero, BE. Es dificil disefar cuestionarios que aseguren obtener exactamente toda la informacién que se desea. TE] A pesar de los inconvenientes anteriores, estos son recomendables utilizarlos cuando: TF | se requiere una pequefia cantidad de informaciin de un gran nimero de personas en un corto periodo de tempo. FE La informacién se desea consolidar en tablas de analistas, TF se deseen respuestas de usuarios que se encuentran dispersas geogrificamente. Se utlizan para recoger sentimientos, opiniones, referencias. Limitan las respuestas posibles a través de un estilo cuidadoso en la pregunta Respuestas de Cuestlonarlo Cerrade: et supvirual comimodibook'print phpid=26650 10282aroana ame * sINO eCree que se cometen muchos errores en la Codificacién de los numeros de cuenta en las facturas? DE ACUERDOJEN DESACUERDO ‘Se cometen muchos errores al codificar DE ACUERDO Ips numeros de cuenta en las facturas, EN DESACUERDO. + NUMERO. De cada 100 facturas que se procesan cuantas tienen errores? Anote el numero: = RANGO {be cada 100 facluras que se procesan | os || cuéntas tienen errores? SELECCION DE RESPUESTAS LIMITADAS. Cuando se presenten errores en la cadificacién de los niimeros de cuenta en las facturas, zcudl es la causa més frecuente? (Anétese el ndmero de la respuesta apropiada) et a2 3 wea2aroana Los buenos cuestionarios se deben disefiar previamente. Un pensamiento cuidadoso, acompatiado de una prucba previa, tanto del formato como de las preguntas, son la base de una recopilacién de datos significativa a través de cuestionarios. Pautas para ayudarles en la conféccién de un cuestionario: R= === = =§ = = = = = = = 1. Determine qué datos necesitan recopilarse y que personas son las mas calificadas para proporcionarlos. Si otros grupos pueden proporcionar datos variantes y mayor visiin identifiquelos también, = ee eee R= == === ss s| = = = 2. Seleccione el tipo de cuestionario (abierto 0 cerrado). Reconozca cuales pueden ser mis ities, si confienen una seccion de respuestas cerradas y otras de respuestas abiertas. ee ee ——= eee [ivesanote un Grupo de_pregunas para inciths en el evstonao, Las pregutas ents que som intencionalmente redundantes, pueden ser iiiles al asegurar [sree —— = sspuestas consistentes por parte de quien r= = = =e eee ee '4.Examine el cuestionario para encontrar falas y defectos como: Tnterrogantes innecesarias. Preguntas que puedan ser mal interpretadas debido a su enfoque o forma de eseritura, Preguntas que el sujeto no pueda responder. Preguntas que estén escritas de forma que se escogeri la respuesta preferida, Preguntas que se interpretaran en forma diferente dependiendo del marco de referencia de cada centrevistado. Preguntas que no proporcionan opciones adecuadas de respuesta. Un ordenamiento no adecuado de las preguntas y respuesta. —— To vvvvy vv —- = = ee eee ee 5.Pruébelo previamente en un Grupo pequefio para detectar otros problemas posibles. i = eee eee ee ——— = (6.Analice la respuesta del Grupo de prueba para asegurar que el anilisis de los datos que se busca se puede evar a cabo con los datos recopilados. Si los datos no revelan algo que el analista no conoce, el [peti puede mo ser necesar —— eS —_ —— eee ee ‘7.Realice cambios finales de edicién e imprimalo en una forma legibk. a ee ee eee eS —=— = ee 8.Distrbuya el cuestionario, Cuando sea posible anote el nombre de cada persona. sik 2 REVISION DE DOCUMENTOS, supvirual comimodibookiprint phpid=26650 v2ea2aroana Toda entidad debe emitir y archivar conjunto de documentos de informacién donde| aparezcan los indicadores principales de | entidad relacionados con su actividad| fundamental Por lo general las entidades| también emiten y archivan un conjunto de informes 0 modes de interés para el jorganismo central 0 ministerio al cus _pertenecen, Ademis, toda entidad debe tener, | Muchos o todos los indicadores que Ud. necesita deben estar reflejados en estos documentos. Pero muchas veces en os documentos nose refkjaexaetamete Jo que wo quiere buscar y debe hacer un procesamiento = de ellos, Medios Basicos, ete. Cada uno de los . Hay que saber obtener la informacién de los modelos estadisticos, 4¢ #2 entidad |A pesar de que se haga un anilsis profindo de los documentos, hay indivadores que la entidad no recopilay son sumamente ites para el analsta; entonces, hay que ir la investigaciin o a realizar ciertos experimentos. supvirual comimodbookiprint phpid=26650 saa2aroana ame PROCESO UNIFICADO DE DESARROLLO (CARACTERISTICAS ESENCIALES Los autores de RUP (Proceso Unificado de Desarrollo) destacan que el proceso de software propuesto por RUP tiene tres caracteristicas esenciaks: estd dirgido por los Casos de Uso, esté centrado en la arquitectura, y ¢s iterativo e incremental, PROCESO DIRIGIDO POR CASOS DE USO Segin [Kru00], los Casos de Uso son una técnica de captura de requisites que fuerza a pensar en términos de importancia para el usuario y no s6lo en términos de fimciones que seria bueno contemplar, Se define un Caso de Uso como un fragmento de fincionalidad del sistema que proporciona al usuario un valor afiadido. Los Casos de Uso representan los requisitos fimeionales del sistema, En RUP bos Casos de Uso no son slo una herramienta para especificar los requisitos del sistema, También _guian su diseio, implementacién y prueba, Los Casos de Uso constituyen un elemento integrador y una guia del trabajo como se muestra en la Figura 1. Capture, dafinir y validar los casos de uso Anilisis & Disefio | alia Realizar los casos de uso Implementacion \Verificar que se satisfacon los i casos deuso Figura 1: Los Casos de Uso integran el trabajo Los Casos de Uso no sélo inician el proceso de desarroly sino que proporcionan un hilo conductor, permitiendo establecer ttazabilidad entre los artefictos que son generados en las diferentes actividades del proceso de desarrollo, ana2aroana ‘Como se muestra en ka Figura 2, basandose en los Casos de Uso se crean los modelos de anilsis y disco, luego fa implementacién que los leva a cabo, y se verifica que eféctivamente el producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso, O=O Realizacion de Anslisis Realizacién de Diserio ' tracer 1 Prabae Unites “2G Pruchas Furcionaes (caso de Procbo Figura 2: Trazabilidad a partir de los Casos de Uso PROCESO CENTRADO EN LA ARQUITECTURA La arquitectura de un sistema es la organizacién o estructura de sus partes més relevantes, lo que permite tener ‘una visién comin entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo [Kr100] La erquitectura iavohera los aspectos estétioos y dinkmicos mis signifcativos =f del sistema, esti relacionada con la toma de decisiones que indicancémo tiene que ser construido el sistema y ayuda a determinar en qué orden. Ademis la dofinicin de ly arquitectra debe tomar en consideraciin elementos de calidad del stem, rendimierto, reutizaciin y capacidad de evohcisn por lo que debe ser flexible durante todo el proceso de desarrollo, La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consieraciones de desarrollo como sistemas heredados. Muchas de estas. restricciones, cconstituyen requisites no fncionales del sistema, supvirtual comimodbookiprint phpid=26650 16282aroana ame En el caso de RUP ademis de utlizar os Casos de Uso para guiar el proceso se presta especial ateneién al establecimiento temprano de una buena arguitectura que no se vea fiertemente impactada ante cambios posteriores durante la construccién y el mantenimient. \ Cada producto tiene tanto una fincién como una forma, La funciin corresponde a la sfimcionalidad refkjada en los Casos de Uso y la forma la proporciona itectura, Existe una interaceién entre los Casos de Uso y la arquitectura, lo Enka Figura 3 se insta Gvolucion de la arquitectura durante las fases de RUP. Se tiene wia arquitetira mv robusta en hs fises finales del proyecto. En ls fises iniciaks fo que se hace es i consolidando la arquitectura® por medio de baselines y se va modificando dependiendo de las necesidades del proyecto,’ 649 el proceso de desarrollo de software. ticrmpo Figura 3: Evolucién de la arquitectura del sistema Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el disefo por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de los demi. Para RUP, todas las vistas juntas forman el lamado modelo 4+1 de la arquitectura [Kru95], el cual recibe este nombre porque lo forman kas vistas Wigica, de implementacion, de proceso y de desplicgue, mis la de Casos de Uso que es la que da cohesién a todas. supvirual comimodbookiprint phpid=26650 16232aroana —--------------------~-------4 Melo Medals Modelo Mode Maelo Modo Model) Modo Mocs Mode Meda Modo Gen Ge de Gade deni te Ge Ge Se Seiden: deinen sos Stiles cefo Hepue mentaccn outta rons all seo logue Merten uch Neel Models Modelo Modo Model Modo eds Moca adel Mot Hoel Mos Ghsce Stiles Seafo feoue mentaccn outta esos ante Steno _plegue ertaconpuete | Figura 4: Los modelos se completan, la arquitectura no cambia drasticamente ‘Al final de la fase de elaboracién se obtiene una baseline de la arquitectura donde fueron seleccionados una serie de Casos de Uso arquitecténicamente relevantes (aquellos que ayudan a mitigar los riesgos més importantes, aquellos que son los mls importantes para el usuario y aquellos que cubran las fincionalidades signiticativas) Como se observa en la Figura 4, durante la construccién los diversos modelos van desarrolkindose hasta completarse (segin se mucstra con las formas rellrnas en la esquina superior derecha), La descripeién de la arquitectura sin embargo, no deberia cambiar signiicativamente (abajo a la derecha) debido a que la mayor parte de la arquitectura se decidiS durante la elaboracién. Se incorporan pocos cambios «a la arquitectura (indicados con mayor densidad de puntos en la figura inferior derecha). PROCESO ITERATIVO E INCREMENTAL Segin el equilbrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de fa forma y la fncién en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que ‘se propone en RUP es tener un proceso iterative e incremental en donde el trabajo se divide en partes més pequetias 0 mini proyectos. Pemmitiendo que el equisrio entre Casos de Uso y arquitectura se vaya logrando. durante cada mini proyecto, asi durante todo el proceso de desarrollo, Cada mini proyecto se puede ver como ‘una iteracién (un recorrido mis 0 menos completo a lo largo de todos los flyjos de trabajo fimdamentales) del cual se obtiene un incremento que produce un crecimiento en el producto. supvirual comimodbookiprint phpid=26650 wea2aroana ame Tiujesioess Una iteracién Loplniacindeloiteadn | Puede realizarse ‘Elana lataraden *Aatdatesespectcas por medio de una cascada como se muestra en la Figura 5. Se pasa por los flujos fundamentales (Requisitos, Andlisis, Disefio, Figura 6: Una iteracion RUP Implementacion y Pruebas), tambien existe una planificacién de la teracion, un andlsis de le teracion algunas actividades especificas de la iteracién. Al finalizar se realiza una integracién de los resultados con lo obtenide de las iteraciones anteriores. Elproceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteracién aborda una parte de la fimcionalidad total, pasando por todos los fujos de trabajo relevantes y refinando la arquitectura. Cada iteracién se analiza cuando termina, Se puede determinar sihan aparecido muevos requisitos o han cambiado bos existentes, afectando a las iteraciones siguientes. Durante la planificacién de los detalles de la siguiente iteracin, el equipo tambign examina cémo afectarén fos riesgos que ain quedan al trabajo en curso. Toda la retroalimentacién de la itcracién pasada permite reajustar los objetivos para ls siguientes itcraciones. Se continia con esta dindmica hasta que se haya finalizado por completo con la versién actual del producto, RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nimero variable segii el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En la Figura 6 se ‘muestra cémo vari el esfierzo asociado a las disciplinas segin ls fase en la que se encuentre el proyecto RUP. supvirual comimodbookiprint phpid=266502aroana supvirual comimodbookiprint phpid=26650 Workflows Business Modeling Requirements Analysis & Design Implementation “Test Deployment Configuration ‘& change Mart Project Management Environment Figura 6: Esfuerzo en actividades segiin fase del proyecto Pwr ==s=s=s= gs ee eg Hg = [ss primeras iteraciones (en las fases de Inicio y Elaboracién) se enfocan hacia la ‘comprensién del problema y la tecnologia, la delimtaciin del émbito del proyecto, la [[cimbson debs rises ericos, yal extbleimcnto de una basen dea argitectra. Durante la fase de inicio las iteraciones hacen ponen mayor énfass en actividades modelado ” negocio y de requis. I I Le r Enh fase de claboracién, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan mis los fjos de trabajo de requerimientos, modelo de negocios | (refinamiento), anaisis, disefo y una parte de implementaciin orientado a la baseline de ff ba arquitectura. ~= = LL ell —=— = = = Tin fase de construccién, se Teva a cabo la construccién del producto por medio de serie de iteraciones. [[ar cada iteracion se seleciona algunos Casos de Uso, serena su ans y deo y se procede a su implementaciin y pruebas. Se realiza una pequefia cascada para cada ciclo, Se realizan tantas iteraciones hasta que se termine la implementacién de la nueva Wversion det producto 9123,2aroana —_——_ eee ee Enla fase de transiciin se pretende garantizar que se tiene un producto preparado para su enttega a pooner. ad! “omo se puede observar en cada fase particpan todas las dsciplinas, pero que dependiendo de ka fase e esfuerzo dedicado a una diseiplina varia ——— ee supvirual comimodbookiprint phpid=26650 ee 201282aroana MODELADO DE NEGOCIO 1. MODELO DE NEGOCIO = = = = = = = [EL modelado del proceso de negocio es una parte esencial de cualquier desarrollo del software. El proceso le! permite al analista capturar los requerimientos ¥ procedimientos con los cuales maneja la empresa, Este modelo proporciona una apreciacién global del negocio, dénde se sacaran conchisiones como esti fimeionando ta empresa, En base a esto se propondran los nuevos sistemas del soflware que encajard en la Jee orginica de la empresa y se reflejaran en ls actividades diariament. = = = = = = = FE. = = = = = = = = Elprimer paso del modelado del negocio consiste en capturar los procesos de negocio de la organizacién bajo estudio, La definicién del conjunto de procesos del negocio es una tarea crucial, ya que define los limites del proceso de modelado posterior. Nos basamos en el concepto de objetivo estratégico, para identiicar de manera adecuada los diferentes procesos de negocio de una organizaciin a partir de la determinaciin | estructuracién de sus objetivos Para cada objetivo que no ha sido descompuesto en ottos, definimos un proceso del negocio cuyo propésito seri dar soporte a dicho objetivo, es decir lograrlo o realzarlo. Representamos cada proceso del negocio Ee ‘un caso de uso del negocio, = = = = = = = 2.- FLUJO DE TRABAJO Evaluar el negocio % Deseribir el negocio : a) Identiticar los procesos del negocio b) Refinar las definiciones de los procesos €) Disefier las Realizaciones de los procesos d) Refinar Roles y Responsabilidades 4 Explorar Ia automatizacin de los procesos © Desarroliar un modelo del dominio 2.1 DESCRIPCION DEL FLUJO DE TRABAJO + En la primera iteracin hay que evahuar de forma preliminar la organizacién para decidir el alcance del esfixerz0 de modelado. {Qué cantidad de modelado necesitamos hacer? + Sino es necesario un modelado en detalles del negocio enfonces es suficiente con modelar el dominio, + Si solamente necesitamos modelar el negocio (no vamos a mejorarlo, solo quetemos entenderlo) entonces hay que tomar el camino del modelado del negocio pero obviando a descripcién del negocio actual + Sies necesario una reingenieria del negocio entonces sitenemos que deseribir el negocio actual, Si es un negocio mevo ay que torr el camino del modelado del negocio pero obviando la descripeién del negocio actual supvirtual comimodibookiprint phpid=26650 21282aroana ame 3. ELEMENTOS DE UML PARA EL MODELADO DEL NEGOCIO: t / ‘etree Proceso de Negocio Meta del Negocio ‘Trabaadordeitegoclo Feauaindel Case Uso de Hepoco Unidad de la Organizacién 4. EVALUAR EL NEGOCIO & Evaluar el estado de la organizacién, & Clasificar el proyecto y decidir cual es el escenario de modelado més apropiado. & Tomar decisiones sobre como continuar trabajando en la iteracién actual y perflar el trabajo de las siguientes. & Definir las metas y los objetivos del modelado del negocio en conformidad con los involuctados y el equipo de modelado del negocio. S- IDENTIFICAR METAS DE NEGOCIO '@ Estrategia de Negocio, define la manera en que la oorganizacién debe actuar reciprocamente con su ambiente, para cumplir con su ambiente. @ La organizacién puede cumplir su propésito una vez que se encuentra en posicién competitiva sustentable. '@ Las metas de negocio describe lo que debe lograrse para alcanzar el deseo de la posicién competiiva, '@ Estrategia y Meta de negocio se preocupan por lo que debe lograrse y no como se lograra. @ Las metas de negocio necesitan ser colocadas en una jerarquia, por consiguiente, cada meta de negocio ya a las metas de nivel superior. Cada Meta de Negocio debe apoyarse ditectamente por lo menos en un proceso de negocio. campus, lesupvirtualcom/modibook!print pp ?id=26650 area