s6 - Analisis - de - Sistemas - II PDF

FACULTAD DE INGENIERIA
RED NACIONAL UNIVERSITARIA
SYLLABUS Facultad de Ingeniera Ingeniera de Sistemas SEXTO SEMESTRE

Gestin Acadmica I / 2011
Syllabus elaborado por: Ing. Gisela Chumacero Tellez
U N
I V E
R S
I D A D
D E 1
A Q
U I N O
B O
L I V I A
UNIVERSIDAD DE AQUINO BOLIVIA Acreditada como PLENA mediante R. M. 288/01
UDABOL
VISION DE LA UNIVERSIDAD
Ser la Universidad lder en calidad educativa.
MISION DE LA UNIVERSIDAD
Desarrollar la Educacin Superior Universitaria con calidad y competitividad al servicio de la sociedad.
Estimado(a) estudiante: El syllabus` que ponemos en tus manos es el fruto del trabajo intelectual de tus docentes, quienes han puesto sus mejores empeos en la planificacin de los procesos de enseanza para brindarte una educacin de la ms alta calidad. Este documento te servir de gua para que organices mejor tus procesos de aprendizaje y los hagas mucho ms productivos. Esperamos que sepas apreciarlo y cuidarlo.
U N
I V E
R S
I D A D
D E
A Q 2
U I N O
B O
L I V I A
I.
SYLLABUS
Asignatura: Cdigo: Requisito: Carga horaria: Horas tericas: Horas prcticas: Crditos: Anlisis de Sistemas II CMP 326 CMP 316 CMP 217 80 horas 80 8
II. OBJETIVOS GENERALES DE LA ASIGNATURA. Dotar al estudiante de los conocimientos fundamentales del anlisis de sistemas, a un nivel general y orientado a objetos, buscando que el estudiante pueda desempearse con propiedad en el anlisis, diseo e implementacin de sistemas orientados a objetos. III. PROGRAMA ANALTICO DE LA ASIGNATURA.
UNIDAD I TEMA 1: ANLISIS Y DISEO ORIENTADO A OBJETOS 1.1 Historia 1.2 Conceptos de objetos y clases 1.3 Ciclo de vida del software 1.4 Proceso Unificado de Software 1.4.1 Fases y pasos de la metodologa 1.4.1.1 Flujos dentro de cada ciclo de desarrollo 1.4.1.2 Fase Inicio 1.4.1.3 Fase de Elaboracin 1.4.1.4 Fase Construccin 1.4.1.5 Fase de Transicin TEMA 2: FASE INICIO 2.1 Obtencin del modelo del negocio 2.2 Definicin del alcance de la aplicacin 2.2.1 Identificacin de los involucrados 2.2.2 Definir los requisitos no funcionales 2.3 Definicin de los casos de uso 2.3.1 Identificar los actores 2.3.2 Identificar los casos de uso 2.3.3 Describir los casos de uso 2.4 Balance de los artefactos 2.5 Revisin y completamiento de la documentacin 2.5.1 Obtencin del modelo del negocio 2.5.2 Definicin del alcance de la aplicacin TEMA 3: FASE REQUISITOS Y FASE ANALISIS 3.1 Flujo o disciplina de requisitos 3.2 Flujo o disciplina de anlisis 3.2.1 Obtencin de los casos de uso detallados 3.2.2 Definicin de las clases preliminares y de las asociaciones
U N
I V E
R S
I D A D
D E 3
A Q
U I N O
B O
L I V I A
3.2.3 Definicin del diagrama de clases del anlisis 3.2.4 Definicin de los diagramas de secuencia 3.2.5 Paquetes de los casos de uso UNIDAD II TEMA 4: FASE DISEO 4.1 Definicin de la arquitectura 4.1.1 Definicin del patrn de arquitectura 4.1.2 Identificar subsistemas 4.2 Refinamiento de las clases 4.3 Aplicacin de patrones de diseo 4.4 Definicin de los diagramas de Transicin de Estado 4.5 Confeccin de los diagramas de componentes 4.6 Definicin de la base de datos relacional 4.7 Balanceo de los artefactos 4.7.1 Diagramas de capas. 4.7.2 Diagramas de paquetes 4.7.3 Definicin de las clases 4.7.4 Base de datos relacional TEMA 5: FASE IMPLEMENTACION Y FASE PRUEBA 5.1 Programacin y prueba de cada clase del subsistema 5.2 Integracin de cada subsistema 5.3 Integracin del software y prueba de la integracin de ste 5.4 Revisin y completamiento de la documentacin 5.4.1 Manual del usuario 5.4.2 Manual de instalacin 5.4.3 Manual de operacin 5.5 Prueba de validacin del software 5.6 Prueba del sistema 5.6.1 Prueba de recuperacin 5.6.2 Prueba de seguridad 5.6.3 Prueba de resistencia 5.6.4 Prueba de rendimiento TEMA 6: FASE TRANSICIN 6.1 Preparacin de condiciones 6.2 Implantacin o despliegue del sistema
IV. SISTEMA DE EVALUACIN DE APRENDIZAJES. El sistema de evaluacin hace hincapi en varios tipos de calificacin: Diagnstica: es la evaluacin de los saberes o conocimientos previos de los y las estudiantes, as como de sus ritmos y estilos de aprendizaje y sus tipos de inteligencia, que sirve al docente como punto de partida para, el desarrollo curricular, para la mejor organizacin y estructuracin de las secuencias de aprendizaje, de modo que estas tengan en cuenta no slo el punto de partida del grupo con el que trabajar durante el semestre sino adems las diferencias y especificidades de cada estudiante para que los aprendizajes resulten ms efectivos y permitan el ptimo desarrollo integral de cada uno(a). Procesual o de desempeo o formativa: en esta forma de evaluacin se valora el avance del o de la estudiante de su nivel de desarrollo real (detectado mediante la evaluacin diagnstica) a su nivel de desarrollo potencial (detectado mediante diversas actividades o tareas).
U N
I V E
R S
I D A D
D E
A Q 4
U I N O
B O
L I V I A
Esta forma de evaluacin, por su naturaleza, es eminentemente cualitativa aunque puede ser valorada cuantitativamente mediante un sistema de puntaje que permita apreciar los avances del o de la estudiante en su zona de desarrollo prximo (zdp) (o, incluso, fuera de ella, en el caso de que el proceso de aprendizaje rebase la misma y d lugar a nuevas zdp). La ponderacin de la asignatura de Ingenieria de Software dentro la Evaluacin Procesual, contempla la realizacin de actividades formativas a desarrollar (Work Papers, Difs, Participacin, Evaluacin Diaria, Investigacin, Congresos, Jornadas Cientficas y Seminarios) y su calificacin es sobre el 50 % de la calificacin del primer y segundo parcial, estimando un promedio de todas las actividades. De resultados del proceso de aprendizaje: es la valoracin de los resultados de los procesos de aprendizaje del o de la, estudiante durante el semestre. Esta forma de evaluacin es tanto cualitativa como cuantitativa, por su naturaleza y por la funcin que cumple dentro de la evaluacin. La evaluacin de resultados en la asignatura especfica se llevar a cabo de forma terica y prctica aplicada a sistemas reales. La ponderacin de esta evaluacin es sobre 50 % de la calificacin del primer y segundo parcial, en el caso del examen final es de 100%, que por disposiciones actuales esta dividido en 50% como prueba final y 50% procesual. . EVALUACION PARCIAL 1 PARCIAL 2 FINAL PROCESUAL 50% 50% 50% DE RESULTADO 50% 50% 50% TOTAL 100% 100% 100% 100%
EVALUACION FINAL PROMEDIO PARCIAL 1, 2 Y FINAL
V. BIBLIOGRAFA. LARMAN CRAIG, UML y PATRONES Introduccin al Anlisis y Diseo Orientado a Objetos, Prentice Hall , Hispanoamericana S.A. 1999, Mxico. BOOCH, GRADY., El Lenguaje de Modelado Unificado RUMBAUGH, JAMES Y OTROS., Modelado y Diseo Orientado a Objetos, Prentice-Hall, 1991. PHILIPPE KRUCHTEN, The Rational Unified Process An Introduction, Addison Wesley, 2001. MARTN, PRENTICE MAY, Anlisis y Diseo Orientado a Objetos BOOCH GRADY, Anlisis y Diseo Orientado a Objetos, Mc. Graw Hill SENN J.A., Anlisis y diseo de sistemas de informacin, Mc.Graw Hill RUMBAUGH, Modelado y Diseo Orientado a Objetos, Prentice Hall LAUDON K.& LAUDON J., Administracin de los Sistemas de Informacin, Prentice Hall., 1997
U N
I V E
R S
I D A D
D E 5
A Q
U I N O
B O
L I V I A
VI. PLAN CALENDARIO

UNIVERSIDAD DE AQUINO-BOLIVIA UNIDAD ACADMICA DE ORURO
CALENDARIO ACADMICO GESTIN I/2011 TURNOS REGULAR-TRABAJO ESTUDIANTES NUEVOS-ANTIGUOS

SEMANA
DEL
AL
ACTIVIDADES
OBSERVACIONES
1ra. 2da. 3ra. 4ta. 5ta. 6ta. 7ma. 8va. 9na. 10ma. 11ra. 12da. 13ra. 14ta. 15ta. 16ta. 17ma. 18va. 19na. 20va. 21ra.
09-mar 14-mar 21-mar 28-mar 04-abr 11-abr 18-abr 25-abr 02-may 09-may 16-may 23-may 30-may 06-jun 13-jun 20-jun 27-jun 04-jul 11-jul 18-jul 25-jul
12-mar 19-mar 26-mar 02-abr 09-abr 16-abr 23-abr 30-abr 07-may 14-may 21-may 28-may 04-jun 11-jun 18-jun 25-jun 02-jul 09-jul 16-jul 23-jul 26-jul
Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia
TEMA 1 TEMA 1 TEMA 2 TEMA 2 TEMA 2

Inicio Primera Evaluacin Parcial Conclusin Primera Evaluacin Parcial
Presentacin de Notas Presentacin de Notas
TEMA 3 TEMA 3 TEMA 4 TEMA 4

Inicio Segunda Evaluacin Parcial
Conclusin Segunda Evaluacin Parcial
Presentacin de Notas Presentacin de Notas
TEMA 5 TEMA 5 TEMA 6 TEMA 6

Inicio Evaluacin Final
Presentacin de Notas Transcripcin de Notas Transcripcin de Notas
Conclusin Evaluacin Final Evaluacin del segundo turno Cierre de Gestin
22 de abril Viernes Santo 1 de mayo Da del Trabajo 23 de junio Corpus Christi
FERIADOS
U N
I V E
R S
I D A D
D E
A Q 6
U I N O
B O
L I V I A
Planificacin de Actividades
Contenidos Mnimos Contenidos Analticos Actividad
Anlisis y diseo Orientado a Objetos
Historia, Conceptos de objetos y clases, Ciclo de vida del software, Proceso Unificado de Software
Fase Inicio
Modelo del negocio, identificacin y descripcin de: casos de uso, actores, actividades, modelo de objetos, requisitos no funcionales
Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares Clases Regulares
Perodos Acadmicos
Recursos Didcticos
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Computador, Data Display, Material Digital e Impreso, ejemplos de Aplicacin y Ejercicios Computador, Data Display, Material Digital e Impreso, ejemplos de Aplicacin y Ejercicios Computador, Data Display, Material Digital e Impreso, ejemplos de Aplicacin y Ejercicios Computador, Data Display, Material Digital e Impreso, ejemplos de Aplicacin y Ejercicios
Fases Requisitos y Anlisis
Fase de Diseo
Revisin y complemento de documentacin, casos de uso detallados, diagrama de clases del anlisis, diagramas de secuencia, balanceo de artefactos, paquetes del anlisis Definicin de la arquitectura, definicin del patrn de la arquitectura, Identificar subsistemas, obtencin del diagrama de clases del diseo, diagramas de interaccin Revisin y complemento de documentacin, prueba de validacin, pruebas del sistema
Fase Implementacin y Prueba
Computador, Data Display, Material Digital e Impreso, ejemplos de Aplicacin y Ejercicios
U N
I V E
R S
I D A D
D E 7
A Q
U I N O
B O
L I V I A
VII. CONTROL DE EVALUACIONES 1 evaluacin parcial Fecha Nota 2 evaluacin parcial Fecha Nota Examen final Fecha Nota APUNTES
U N
I V E
R S
I D A D
D E
A Q 8
U I N O
B O
L I V I A
WORK PAPER # 1
PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO: APRO 07 No. DE HOJAS : 3
ELABOR: Ing. Marisol Muriel Almanza TTULO DEL WORK PAPER: Orientacin Objetos DPTO.: Facultad de Ciencias y Tecnologa DESTINADO A: DOCENTES ALUMNOS X ADMINIST.
CDIGO: CMP 326
OTROS
OBSERVACIONES: Carrera Ingeniera de Sistemas Asignatura Anlisis de Sistemas II Unidad 1
FECHA DE DIFUSIN: Marzo 2011
FECHA DE ENTREGA: Marzo 2011
U N
I V E
R S
I D A D
D E 9
A Q
U I N O
B O
L I V I A
Orientacin objetos La recompensa Los objetos y sus asociaciones conforman la columna vertebral de la funcionalidad de los sistemas. Para modelarlos, necesitar comprender lo que son las asociaciones. Si est consciente de los posibles tipos de asociaciones, tendr una amplia gama de posibilidades cuando hable con los clientes respecto a sus necesidades, obtendr sus requerimientos y crear los modelos de los sistemas que los ayudarn a cumplir con sus retos de negocios. Lo importante es utilizar los conceptos de la orientacin a objetos para ayudarle a comprender el rea de conocimiento de su cliente (su dominio), y esclarecer sus puntos de vista al cliente en trminos que l o ella puedan comprender Es all donde se aplica el UML. Resumen La orientacin a objetos es un paradigma que depende de algunos principios fundamentales. Un objeto es una instancia de una clase: Una clase es una categora genrica de objetos que tienen los mismos atributos y acciones. Cuando crea un objeto, el rea del problema en que trabaje determinar cuntos de los atributos y acciones debe tomar en cuenta. La herencia es un aspecto importante de la orientacin a objetos, un objeto hereda los atributos y operaciones de su clase. Una clase tambin puede heredar atributos y acciones de otra. El polimorfismo es otro aspecto importante, ya que especifica que una accin puede tener el mismo nombre en diferentes clases y cada clase ejecutar tal operacin de forma distinta. Los objetos ocultan su funcionalidad de otros objetos y del mundo exterior. Cada objeto presenta una interfaz para que otros objetos (y personas) puedan aprovechar su funcionalidad. Los objetos funcionan en conjunto mediante el envo de mensajes entre ellos. Los mensajes son peticiones para realizar operaciones. Por lo general, los objetos se asocian entre s y esta asociacin puede ser de diversos tipos. Un objeto en una clase puede asociarse con cualquier cantidad de objetos distintos en otra clase. La agregacin es un tipo de asociacin. Un objeto agregado consta de un conjunto de objetos que lo componen y una composicin es un tipo especial de agregacin. En un objeto compuesto, los componentes slo existen como parte del objeto compuesto. Preguntas y respuestas P Usted dijo que la orientacin a objetos ha tomado por asalto al mundo del software. Qu no hay algunas aplicaciones importantes que no estn orientadas a objetos? R S, y se conocen como sistemas heredados (programas que en muchos casos son ejecutados para mostrar su poca). La orientacin a objetos ofrece diversas ventajas, como la reusabilidad y un rpido periodo de desarrollo. Por tales razones, muy probablemente ver las nuevas aplicaciones (y las versiones rediseadas de varias aplicaciones antiguas) escritas bajo el esquema de la orientacin a objetos. Para repasar lo que ha aprendido de la orientacin a objetos, intente responder a algunas preguntas y realizar los siguientes ejercicios.
U N I V E R S I D A D D E A Q 10 U I N O B O L I V I A
Cuestionario 1. Qu es un objeto? 2. Cmo trabajan los objetos en conjunto? 3. Qu establece la multiplicidad? 4. Pueden asociarse dos objetos entre s en ms de una manera? Fuente: Aprendiendo UML en 24 Horas. Joseph Schmuller. Pearson Educacin, Mexico 2000
U N
I V E
R S
I D A D
D E 11
A Q
U I N O
B O
L I V I A
WORK PAPER # 2
PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO: APRO 07 No. DE HOJAS: 3
ELABOR: Ing. Marisol Muriel Almanza TTULO DEL WORK PAPER: Introduccin al UML DPTO.: Facultad de Ciencias y Tecnologa DESTINADO A: DOCENTES ALUMNOS X ADMINIST.
CDIGO: CMP 326
OTROS
U N
I V E
R S
I D A D
D E
A Q 12
U I N O
B O
L I V I A
INTRODUCCION AL UML Para qu tantos diagramas Como puede ver, los diagramas del UML le permiten examinar un sistema desde distintos puntos de vista. Es importante recalcar que en un modelo UML no es necesario que aparezcan todos los diagramas. De hecho, la mayora de los modelos UML contienen un subconjunto de los diagramas que he indicado. Por qu es necesario contar con diferentes perspectivas de un sistema? Por lo general, un sistema cuenta con diversas personas implicadas las cuales tienen enfoques particulares en diversos aspectos del sistema. Volvamos al ejemplo de la lavadora. Si disean el motor de una lavadora, tendra una perspectiva del sistema; si escribiera las instrucciones de operacin, tendra otra perspectiva. Si diseara la forma general de la lavadora vera al sistema desde una perspectiva totalmente distinta a si tan slo tratara de lavar su ropa. El escrupuloso diseo de un sistema involucra todas las posibles perspectivas, y el diagrama UML le da una forma de incorporar una perspectiva en particular. El objetivo es satisfacer a cada persona implicada. Resumen El desarrollo de sistemas es una actividad humana. Sin un sistema de notacin fcil de comprender, el proceso de desarrollo tiene una gran cantidad de errores. El UML es un sistema de notacin que se ha convertido en estndar en el mundo del desarrollo de sistemas. Es el resultado del trabajo hecho por Grady Booch, James Rumbaugh e Ivar Jacobson. El UML est constituido por un conjunto de diagramas, y proporciona un estndar que permite al analista de sistemas generar un anteproyecto de varias facetas que sean comprensibles para los clientes, desarrolladores y todos aquellos que estn involucrados en el proceso de desarrollo. Es necesario contar con todos esos diagramas dado que cada uno se dinge a cada tipo de persona implicada en el sistema. Un modelo UML indica qu es lo que supuestamente har el sistema, mas no cmo lo har. Preguntas y respuestas P He visto que se refiere al Lenguaje Unificado de Modelado como UME y como el UML. Cul es el correcto? R Los creadores del lenguaje prefieren el uso de el UML. P. Ha indicado que el UML es adecuado para los analistas, diagramas de distribucin no parece ser algo muy til en el desarrollo de un sistema. No sera ms apropiado posterior? No obstante, el la fase de anlisis para una fase. R En realidad nunca ser demasiado pronto para empezar a pensar en la distribucin (u otras cuestiones que, tradicionalmente, se dejan para fases posteriores del desarrollo). Aunque es cierto que el analista se interesa por hablar con los clientes y usuarios, en las fases tempranas del proceso el analista debera pensar en los equipos y componentes que constituiran el hardware del sistema. En algunas ocasiones, el cliente dicta esto; en otras, el cliente desea una recomendacin del equipo de desarrollo. Ciertamente, un arquitecto de sistemas encontrar til al diagrama de distribucin. P. Ha mencionado que es posible hacer diagramas hbridos. UML, perdn, el UML, impone limitaciones respecto a los elementos que podr combinar en un diagrama?
U N I V E R S I D A D D E 13 A Q U I N O B O L I V I A
R. No. El UML no establece lmites, no obstante, con frecuencia se da el caso de que un diagrama contenga un tipo de elemento. Podr colocar smbolos de clases en un diagrama de distribucin, pero ello no ser muy til. Taller Ya se ha iniciado en el UML. Ahora deber reafirmar su conocimiento de esta gran herramienta al responder algunas preguntas y realizar los ejercicios. Cuestionario 1 . Porqu es necesario contar con diversos diagramas en el modelo de un sistema? 2. Cules diagramas le dan una perspectiva esttica de un sistema? 3. Cules diagramas le dan una perspectiva dinmica de un sistema (esto es, muestran el cambio progresivo)? 4 . Suponga que crear un sistema informtico que jugar ajedrez con un usuario. Cules diagramas UML seran tiles para disear el sistema? Por qu? 5. Para el sistema del ejercicio que ha completado, liste las preguntas que formularia a un usuario potencial y por qu las hara. Fuente: Aprendiendo UML en 24 Horas. Joseph Schmuller. Pearson Educacin, Mexico 2000
U N
I V E
R S
I D A D
D E
A Q 14
U I N O
B O
L I V I A
WORK PAPER # 3
PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO: APRO 07 No. DE HOJAS: 6
ELABOR: Ing. Marisol Muriel Almanza TTULO DEL WORK PAPER: Introduccin a los casos de uso DPTO.: Facultad de Ciencias y Tecnologa DESTINADO A: DOCENTES ALUMNOS X ADMINIST.
CDIGO: CMP 326
OTROS
U N
I V E
R S
I D A D
D E 15
A Q
U I N O
B O
L I V I A
INTRODUCCIN A LOS CASOS DE USO Ahora que ha visto lo correspondiente a las clases y sus relaciones, es el momento de volver nuestra atencin a otra rea principal del UML: los casos de uso. Se tratarn los siguientes temas: Qu son los casos de uso Importancia de los casos de uso Inclusin de los casos de uso Extensin de los casos de uso Inicio de un anlisis de un caso de uso Ahora veremos a los diagramas que establecen una idea dinmica y mostraremos la forma en que el sistema y sus clases cambian con el tiempo. Las ideas estticas ayudan a que un analista se comunique con un cliente. La idea dinmica, como ver, ayudar al analista a comunicarse con un grupo de desarrolladores, y ayudar a estos ltimos a crear programas. El cliente y el equipo de desarrollo conforman un importante conjunto de integrantes en un sistema. No obstante, una parte de igual importancia no se ha tomado en cuenta: el usuario. Ni la idea esttica ni la dinmica mostrarn el comportamiento del sistema desde el punto de vista del usuario. Comprender tal punto de vista es clave para generar sistemas que sean tanto tiles como funcionales; esto es, que cumplan con los requerimientos y que sea fcil (e, incluso, divertido) trabajar con ellos. El modelado de un sistema desde el punto de vista de un usuario es el trabajo de los casos de uso. Comprender todo lo relacionado con los casos de uso y su funcin. Qu son los casos de uso Recientemente adquir una mquina de fax. Cuando fui a comprarla, en un almacn de venta de equipo para oficinas, encontr una enorme gama de opciones. Cmo hice para decidirme por una en particular? Me pregunt exactamente qu es lo que deseaba hacer con una mquina de fax. Qu caractersticas deseaba? Cules funciones necesitaba que tuviera? Deseaba utilizar papel comn o trmico? Quera generar copias? Conectarlo a mi computadora? Utilizarlo como digitalizador? Tendra que enviar faxes a tal velocidad que necesitara una funcin de marcado rpido? Querra utilizar la mquina de fax para diferenciar entre una llamada telefnica y un fax entrante? Todos seguimos un procedimiento como ste cuando realizamos una compra que no sea impulsiva. Lo que hacemos es seguir un tipo de anlisis del caso de uso: nos preguntamos cmo utilizaremos el producto o sistema que queremos comprar, de modo que podamos obtener algo que cumpla con nuestras necesidades. Lo importante es saber cules son esos requerimientos. Este tipo de anlisis es particularmente crucial para la fase de anlisis del desarrollo de un sistema. La forma en que los usuarios utilicen un sistema le da la pauta para lo que disear y crear. El caso de uso es una estructura que ayuda a los analistas a trabajar con los usuarios para determinar la forma en que se usar un sistema. Con una coleccin de casos de uso se puede hacer el bosquejo de un sistema en trminos de lo que los usuarios intenten hacer con l. TERMINO NUEVO
U N
I V E
R S
I D A D
D E
A Q 16
U I N O
B O
L I V I A
Imagnese al caso de uso como una coleccin de situaciones respecto al uso de un sistema. Cada escenario describe una secuencia de eventos. Cada secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso del tiempo. A las entidades que inician secuencias se les conoce como actores. El resultado de la secuencia debe ser algo utilizable ya sea por el actor que la inici, o por otro actor. Importancia de los casos de uso As como el diagrama de clases es un buen medio para estimular a un cliente a que hable respecto a un sistema desde su propio punto de vista, el caso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen, de un sistema, desde sus propios puntos de vista. No siempre es fcil para los usuarios explicar cmo pretenden utilizar un sistema. Puesto que el desarrollo tradicional de los sistemas era, con frecuencia, algo as como una ciencia oculta, con muy poca informacin para los usuarios, a aquellos que osaban preguntar se les daba informacin muy poco explcita o ciertamente confusa respecto a lo que utilizaran. La idea es involucrar a los usuarios en las etapas iniciales del anlisis y diseo del sistema. Esto aumenta la probabilidad de que el sistema sea de mayor provecho para la gente a la que supuestamente ayudar, en lugar de ser un manojo de expresiones de computacin incomprensibles e inmanejables por los usuarios finales. Un ejemplo: la mquina de gaseosas Suponga que empezar a disear una mquina despachadora de gaseosas. Para obtener el punto de vista del interesado, entrevistar a varios usuarios potenciales respecto a la manera en que utilizarn dicha mquina. Dado que la funcin principal de una mquina de gaseosas es permitir a un cliente adquirir una lata de gaseosa, probablemente las personas le dirn que se enfrentar a diversos escenarios un caso de uso, en otras palabras que podra etiquetar como Comprar gaseosa. Examinemos cada posible escenario en este caso de uso. Recuerde que tales escenarios podran aparecer durante la conversacin con los usuarios. FIGURA 1 Un caso de uso establece un conjunto de escenarios para realizar algo til para un actor En este ejemplo, un caso de uso es comprar gaseosa .
El caso de uso Comprar gaseosa El actor, en este caso de uso, es un cliente que desea comprar una lata de gaseosa. El escenario iniciar cuando el cliente inserte dinero, posteriormente realizar una seleccin; y si todo funciona bien, la mquina contar con, al menos, una lata de la gaseosa elegida, misma que pondr al alcance del cliente. Adems de la secuencia, hay otros aspectos del escenario anterior que merecen cierta consideracin, Qu condiciones llevaron al cliente a iniciar el escenario en el caso de uso Comprar gaseosa? La sed es la ms obvia. Qu se obtiene como resultado de tal escenario? Nuevamente, lo obvio es que el cliente tenga una gaseosa en su poder.
U N
I V E
R S
I D A D
D E 17
A Q
U I N O
B O
L I V I A
Lo que he descrito es la nica posibilidad de Comprar gaseosa? Habra otras cuestiones que saltaran a la vista; por ejemplo, es posible que la mquina no tenga la gaseosa que desee el cliente; tambin es posible que el cliente no tenga el importe exacto de la gaseosa. Cmo diseara a la mquina de gaseosas para controlar tales escenarios? Veamos el caso en que la mquina se haya quedado sin gaseosa, otra secuencia de pasos en el caso de uso Comprar gaseosa. Imagnelo como una ruta alternativa dentro del caso de uso. El cliente inicia el caso de uso al insertar dinero en la mquina y posteriormente hace una seleccin. La mquina no cuenta con ninguna lata de la gaseosa seleccionada, por lo que mostrar un mensaje al cliente que indicar que no tiene de esa marca. Lo ideal sera que el mensaje le pida al cliente que haga otra seleccin. La mquina tambin debera dar la opcin de devolver el dinero al cliente. En este punto. el cliente selecciona otra marca que la maquina entregar (siempre y cuando cuente con provisiones de esta marca), o devolver el dinero. La condicin previa es un cliente sediento y el resultado es una lata de gaseosa o la devolucin del dinero.
Claro que el escenario de quedarse sin gaseosa sera posible: el mensaje No hay de esta marca podra aparecer en cuanto las provisiones de la mquina se acabaran y permanecer a la vista hasta que la mquina sea reabastecida. En tal caso, el usuario podra no insertar el dinero en primera instancia. El cliente para el que usted disear la mquina podra preferir el primer escenario: si el cliente ya insert dinero, la tendencia podra ser hacer otra seleccin en lugar de pedir a la mquina que lo devuelva.
Analicemos ahora el escenario de la cantidad de dinero incorrecta. Nuevamente, el usuario inicia el caso de uso en la forma usual y posteriormente hace una seleccin. Asumamos que la mquina tiene provisin de la marca elegida. En la mquina hay una reserva de moneda fraccionaria y devuelve la diferencia al despachar la gaseosa. Si la mquina no cuenta con una reserva de moneda fraccionaria, devolver el dinero y mostrar un mensaje que pida al usuario el importe exacto. La condicin previa es la ya indicada. El resultado ser una lata de gaseosa junto con el cambio, o la devolucin dci dinero originalmente depositado. Otra posibilidad es que tan pronto como se agote la moneda fraccionaria, aparezca un mensaje que informe a los clientes que se requiere el importe exacto. El mensaje permanecera a la vista hasta que la mquina sea reabastecida con moneda fraccionaria. Casos de uso adicionales Ya ha examinado a la mquina de gaseosas desde el punto de vista de un usuario: el cliente. Hay otros usuarios que intervienen, como el proveedor que tiene que reabastecer a la mquina. el recolector de dinero (que tal vez sea el mismo que el proveedor) que tiene que recoger el dinero acumulado en la alcanca de la mquina, etctera. Esto nos indica que debemos crear al menos dos casos de uso: Reabastecer y Recolectar dinero, cuyos detalles surgirn durante las entrevistas con los proveedores y los recolectores. Veamos el caso de uso de Reabastecer. El proveedor inicia este caso de uso dado que algn intervalo (digamos, dos semanas) ha pasado. El representante del proveedor le quita el seguro a la mquina (tal vez mediante una llave y un cerrojo. pero eso entra dentro de la implementacin), jala la puerta para abrir la mquina, y llena el compartimiento de cada marca hasta su capacidad. El representante tambin rellena la reserva de moneda fraccionaria. Luego, cierra el frente de la mquina y vuelve a poner el seguro. La condicin previa es el paso del intervalo, el resultado es que el proveedor cuenta con un nuevo conjunto de ventas potenciales. Para el caso de uso de Recolectar el dinero, el recolector inicia debido tambin a que ha pasado cierto tiempo. La persona deber seguir la misma secuencia que en Reabastecer para abrir la mquina. El recolector sacar el dinero de la mquina y seguir los pasos de Reabastecer para cerrar y poner el seguro a la mquina. La condicin previa es el paso del intervalo y el resultado es el dinero en las manos del recolector.
U N
I V E
R S
I D A D
D E
A Q 18
U I N O
B O
L I V I A
Vea que cuando derivamos un caso de uso, no nos preocupamos por la forma de implementarlo. En nuestro ejemplo, no nos interesamos en los aspectos internos de la mquina de gaseosas. Tampoco por la forma en que funcione el mecanismo de refrigeracin, o por la forma en que la mquina controle la cantidad de dinero que contenga. Tan slo intentamos ver la forma en que la mquina lucir para alguien que tenga que utilizarla. El objetivo es derivar una coleccin de casos de uso que, finalmente, mostraremos a las personas que diseen la mquina de gaseosas y a las personas que la construirn. Por aadidura, nuestros casos de uso reflejan lo que los clientes, recolectores y proveedores desean, por lo que el resultado ser una mquina que todos esos grupos puedan utilizar con facilidad. Inclusin de los casos de uso En los casos de uso Reabastecer y Recolectar dinero, tal vez distingui ciertos pasos en comn. Ambos empezaban con abrir la mquina, y finalizaban con el cierre de la mquina y su aseguramiento. Podramos eliminar la duplicacin de pasos de un caso de uso al otro? S podemos. La forma de hacerlo es tomar cada secuencia de pasos en comn y conformar un caso de uso adicional a partir de ellos. Combinemos los pasos necesarios para quitar el seguro y abrir la mquina y llammoslos Exhibir el interior y los pasos cerrar la mquina y asegurarla en otro caso de uso llamado Cubrir el interior. Con estos nuevos casos de uso a la mano, el caso de uso Reabastecer iniciara con el caso de uso Exhibir el interior. Luego, el representante del proveedor seguira los pasos ya indicados, y concluira con el caso de uso Cubrir el interior. De forma similar, el caso de uso Recolectar dinero iniciara con Exhibir el interior, procedera como se indic, y finalizara con el caso de uso Cubrir el interior. Como ve, Reabastecer y Recolectar dinero incluyen los nuevos casos de uso. Por ello, a esta tcnica de aprovechamiento de un caso de uso se le conoce como inclusin de un caso de uso.
La inclusin de un caso de uso tambin se conoce como usar un caso de uso. Creo que el trmino incluir tiene dos ventajas. La primera, es ms clara: los pasos en un caso de uso, incluyen los de otro. La segunda, se evita la confusin potencial de las palabras usar y uso en un contexto tan estrecho. As, no tendremos que decir promover el uso mediante el uso reiterativo de un caso de uso.
Extensin de los casos de uso Es posible volver a utilizar un caso de uso de una forma distinta a una inclusin. En ocasiones crearemos un caso de uso agregndole algunos pasos a un caso de uso existente. Regresemos al caso de uso Reabastecer. Antes de colocar nuevas latas de gaseosas en la mquina, suponga que el representante del proveedor nota las marcas que se han vendido bien, as como las que no se han vendido tan bien. En lugar de slo reabastecer todas las marcas, el representante podra sacar aquellas que no se han vendido bien, y reemplazarlas por latas de las marcas que han probado ser ms populares. De esta forma, tendra que indicar al frente de la mquina el nuevo surtido de marcas disponibles. Si agregamos estos pasos a Reabastecer, tendremos un nuevo caso de uso que llama- riamos Reabastecer de acuerdo a las ventas. Este nuevo caso de uso es una extensin del original, accin a la que se le conoce como extensin de un caso de USO. Inicio del anlisis de un caso de uso
U N
I V E
R S
I D A D
D E 19
A Q
U I N O
B O
L I V I A
En nuestro caso, nos hemos involucrado directamente con los casos de uso y nos hemos enfocado en algunos de ellos. En el mundo real, por lo general, seguir un conjunto de procedimientos cuando empiece un anlisis de casos de uso. Empezar con entrevistas a los clientes (y entrevistas con expertos) que lo lleven a los diagramas iniciales de clases. Esto le dar cierta idea del rea en la que trabajar y una familiaridad con los trminos que utilizar. Posteriormente, contar con un fundamento para hablar con los usuarios. Entrevistar a los usuarios (preferentemente en grupos) y les pedir que le indiquen todo lo que ellos haran con el sistema que usted disear. Sus respuestas conformarn un conjunto candidato de casos de uso. Luego, es importante describir brevemente cada caso de uso. Tambin tendr que derivar una lista de todos los actores que iniciarn y se beneficiarn de los casos de uso. Cuenta ms informacin obtenga en esta fase, aumentar su aptitud para hablar con los usuarios en su propio idioma. Los casos de uso aparecern en varias fases del proceso de desarrollo. Le ayudarn con el diseo de una interfaz del usuario, coadyuvarn con las opciones de desarrollo de los programadores y establecern las bases para probar el sistema recin generado. Resumen El caso de uso es una estructura para describir la forma en que un sistema lucir para los usuarios potenciales. Es una coleccin de escenarios iniciados por una entidad llamada actor (una persona. un componente de hardware, un lapso u otro sistema). Un caso de uso debera dar por resultado algo de valor ya sea para el actor que lo inici o para otro. Es posible volver a utilizar casos de uso. Una forma (inclusin) es utilizar los pasos de un caso de uso como parte de la secuencia de pasos de otro caso de uso. Otra forma (extensin) es crear un nuevo caso de uso mediante la adicin de pasos a un caso de uso existente. La entrevista directa con los usuarios es la mejor tcnica para derivar casos de uso. Cuando se deriva un caso de uso, es importante destacar las condiciones para iniciar el caso de uso, y los resultados obtenidos como consecuencia del mismo. Har las entrevistas a los usuarios despus de entrevistar a los clientes y generar una lista de prospectos de clases. Esto le dar un fundamento en la terminologa que utilizar para hablar con los usuarios. Es una buena idea entrevistar a un grupo de usuarios. El objetivo es derivar un conjunto candidato de casos de uso y todos los posibles actores. Fuente: Aprendiendo UML en 24 Horas, Joseph Schmuller, Perarson Educacin, Mexico 2000 Cuestionario 1. 2. 3. 4. 5. Cmo se llama a la entidad que inicia un caso de uso? Qu se entiende con incluir un caso de uso? Qu se entiende con extender un caso de uso? Un caso de uso es lo mismo que un escenario? En el caso del ejemplo de la mquina de gaseosas, cree otro caso de uso que ncluya a los casos de uso Exhibir el interior y Cubrir el interior. 6. Los casos de uso pueden ayudarle a analizar un negocio y un sistema. Imagine a una gran tienda de equipos de cmputo que venda hardware, perifricos y software. Quines seran los actores? Cules seran algunos de los principales casos de uso? Cules seran algunos de los escenarios dentro de cada caso de uso?
U N
I V E
R S
I D A D
D E
A Q 20
U I N O
B O
L I V I A
WORK PAPER # 4
PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO: APRO07 No. DE HOJAS: 9
ELABOR: Ing. Marisol Muriel Almanza TTULO DEL WORK PAPER: Diagramas de Casos de Uso DPTO.: Facultad de Ciencias y Tecnologa DESTINADO A: DOCENTES ALUMNOS X ADMINIST.
CDIGO: CMP 326
OTROS
U N
I V E
R S
I D A D
D E 21
A Q
U I N O
B O
L I V I A
DIAGRAMAS DE CASOS DE USO El caso de uso es un poderoso concepto que ayuda a un analista a comprender la forma en que un sistema deber comportarse. Le ayuda a obtener los requerimientos desde el punto de vista del usuario. Es necesario aprender a visualizar los conceptos del caso de uso. Se tratarn los siguientes temas: Representacin de un modelo de caso de uso Concepcin de las relaciones entre casos de uso Diagramas de casos de uso en el proceso de anlisis Aplicacin de los modelos de caso de uso Ver la idea general del UML El caso de uso es muy poderoso, pero lo es aun ms cuando se visualiza por medio del UML. Esta visualizacin le permitir mostrar los casos de uso a los usuarios para que ellos le puedan dar mayor informacin. Es un hecho que los usuarios con frecuencia saben ms de lo que dicen: el caso de uso ayuda a romper el hielo. A su vez, una representacin visual le ayuda a combinar los diagramas de casos de uso con otro tipo de diagramas. Una de las finalidades del proceso de anlisis de un sistema es generar una coleccin de casos de uso. La idea es tener la posibilidad de catalogar y hacer referencia a esta coleccin, que sirve como el punto de vista de los usuarios acerca del sistema. Cuando llegue el momento de actualizar el sistema, el catlogo de casos de uso funcionar como un fundamento para obtener los requerimientos de la actualizacin. Representacin de un modelo de caso de uso Hay un actor que inicia un caso de uso y otro (posiblemente el que inici, pero no necesariamente) que recibir algo de valor de l. La representacin grfica es directa. Una elipse representa a un caso de uso, una figura agregada representa a un actor. El actor que inicia se encuentra a la izquierda del caso de uso, y el que recibe a la derecha. El nombre del actor aparece justo debajo de l, y el nombre del caso de uso aparece ya sea dentro de la elipse o justo debajo de ella. Una lnea asociativa conecta a un actor con el caso de uso, y representa la comunicacin entre el actor y el caso de uso. La lnea asociativa es slida, como la que conecta a las clases asociadas. Uno de los beneficios del anlisis del caso de uso es que le muestra los confines entre el sistema y el mundo exterior. Generalmente, los actores estn fuera del sistema, mientras que los casos de uso estn dentro de l. Utilizar un rectngulo (con el nombre del sistema en algn lugar dentro de l) para representar el confn del sistema. El rectngulo envuelve a los casos de uso del sistema.
En un modelo de caso de uso, una figura agregada representa a un actor, una elipse a un caso de uso y una lnea asociativa representa la comunicacin entre el actor y el caso de uso.
TERMINO NUEVO Los actores, casos de uso y lneas de interconexin componen un modelo de caso de uso. La figura le muestra estos smbolos.
U N
I V E
R S
I D A D
D E
A Q 22
U I N O
B O
L I V I A
Una nueva visita a la mquina de gaseosas Apliquemos los smbolos al ejemplo de la hora anterior. Como recuerda, desarroll los casos de uso para una mquina de gaseosas. El caso de uso Comprar gaseosa se encuentra dentro del sistema junto con Reabastecer y Recolectar dinero. Los actores son el Cliente, Representante del proveedor y el Recolector. La figura le muestra un modelo UML de caso de uso para una mquina de gaseosas.
Secuencia de pasos en los escenarios Cada caso de uso es una coleccin de escenarios y cada escenario es una secuencia de pasos. Como puede ver, tales pasos no aparecen en el diagrama. No se encuentran en notas adjuntas a los casos de uso. Aunque el UML no lo prohbe, la claridad es clave en la generacin de cualquier diagrama y el adjuntar notas a cada caso de uso podra volverlo confuso. Cmo y dnde hara la secuencia de pasos? El uso de los diagramas de casos de uso ser, por lo general, parte de un documento de diseo que el cliente y el equipo de diseo tornarn corno referencia. Cada diagrama tendr su propia pgina, de igual manera, cada escenario de caso de uso tendr su propia pgina, donde se listar en modo de texto a: El actor que inicia al caso de uso Condiciones previas para el caso de uso Pasos en el escenario Condiciones posteriores cuando se finaliza el escenario El actor que se beneficia del caso de uso Tambin puede enumerar las conjeturas del escenario (por ejemplo, que un cliente a la vez utilizar la mquina de gaseosas) y una breve descripcin de una sola frase del escenario. Concepcin de las relaciones entre casos de uso TERMINO NUEVO El ejemplo de la hora 6 tambin mostr dos formas en que los casos de uso se pueden relacionar entre s. Una de ellas, la inclusin, le permite volver a utilizar los pasos de un caso de uso dentro de otro. La otra, extensin, le permite crear un caso de uso mediante la adicin de pasos a uno existente. Existen otros dos tipos de relaciones que son generalizacin y agrupamiento.
U N
I V E
R S
I D A D
D E 23
A Q
U I N O
B O
L I V I A
TERMINO NUEVO Como en las clases, la generalizacin cuenta con un caso de uso que se hereda de otro. El agrupamiento es una manera sencilla de organizar los casos de uso. Inclusin Examinemos los casos de uso Reabastecer y Recolectar dinero del ejemplo de la hora 6. Ambos se inician mediante la apertura de la mquina, y finalizan con el cierre y sellado de la misma. El caso de uso Exhibir el interior se cre para capturar el primer par de pasos: y Cubrir el interior para el segundo. Tanto Reabastecer, como Recolectar dinero incluyen este par de casos de uso. Para representar a la inclusin utilizar el smbolo que us para la dependencia entre clases: una lnea discontinua con una punta de flecha que conecta las clases apuntando hacia la clase dependiente. Justo sobre a lnea, agregar un estereotipo: la palabra incluir bordeada por dos pares de parntesis angulares. La figura 7.3 le muestra la relacin de inclusin en el modelo de caso de uso de la mquina de gaseosas.
Tenga en cuenta que un caso de uso incluido nunca aparecer solo. Simplemente funciona corno parte de un caso de uso que lo incluya.
En la notacin de texto que sigue los pasos en la secuencia, indicar los casos de uso incluidos. El primer paso en el caso de uso Reabastecer podra ser incluir (Exhibir el interior). Extensin TERMINO NUEVO La hora 6 mostr que el caso de uso Reabastecer podra ser la base de otro J caso de uso: Reabastecer de acuerdo a las ventas. En Lugar de slo reabastecer la mquina de gaseosas para que todas las marcas tengan la misma cantidad
de latas, el representante podra anotar aquellas que se venden mejor y reabastecer acorde con ello. Por lo que podemos decir que el nuevo caso de uso extiende al original dado que agrega otros pasos a la secuencia del caso de uso original, que se conoce como el caso de uso base. TERMINO NUEVO La extensin slo se puede realizar en puntos indicados de manera especfica dentro de la secuencia del caso de uso base. A estos puntos se les conoce como puntos de extensin. En el caso de uso Reabastecer, los nuevos pasos (anotar las ventas y abastecer de manera acorde) se daran luego que el representante haya abierto la mquina y est listo para llenar los compartimientos de las marcas de gaseosas. En este ejemplo, el punto de extensin es Llenar los compartimientos. Como la inclusin, podr concebir la extensin con una lnea de dependencia (lnea discontinua con punta una punta de flecha), junto con un estereotipo que muestra extender entre parntesis angulares. Dentro del caso de uso bsico, el punto de extensin aparecer debajo del nombre del caso de uso. La figura 7.4 le muestra la relacin de extensin para Reabastecer y Reabastecer de acuerdo a las ventas, junto con la inclusin de relaciones para Reabastecer y Recolectar dinero.
Generalizacin Las clases pueden heredarse entre s y esto tambin se aplica a los casos de uso. En la herencia de los casos de uso, el caso de uso secundario hereda las acciones y significado del primario. y adems agrega sus propias acciones. Puede aplicar el caso de uso secundario en cualquier lugar donde aplique el primario. En el ejemplo, deber imaginar un caso de uso Comprar un vaso de gaseosa que se hereda de Comprar gaseosa. El caso de uso secundario tiene acciones corno agregar hielo y mezclar marcas de gaseosas. Modelar la generalizacin de casos de uso de la misma forma que lo hace con las clases: con lneas continuas y una punta de flecha en forma de tringulo sin rellenar que apunta hacia el caso de uso primario, como se muestra en la figura
La relacin de generalizacin puede establecerse entre actores, as como entre casos de uso. Quiz tenga personificados al representante del proveedor, al recolector y al agente del proveedor. Si cambia ci nombre del representante como Reabastecedor, tanto ste como el Recolector sern secundarios del Agente Proveedor, como muestra la figura.
U N
I V E
R S
I D A D
D E 25
A Q
U I N O
B O
L I V I A
Agrupamiento En ciertos diagramas de casos de uso, podra tener varios casos de uso que querr organizar. Esto puede ocurrir cuando un sistema consta de varios subsistemas. Otra posibilidad sera cuando entrevista a los usuarios para obtener los requerimientos de un sistema. Cada requerimiento podra ser representado como un caso de uso por separado. Necesitar alguna forma de ordenar los requerimientos por categoras. La forma ms directa de organizar sera agrupar en un paquete los casos de uso que se relacionen. Recuerde que un paquete aparece como una carpeta tabular. Los casos de uso agrupados aparecern dentro de la carpeta. Diagramas de casos de uso en el proceso de anlisis Con el ejemplo dado y con el cual ha trabajado, aplic directamente la simbologa del caso de uso. Ahora nos regresaremos un poco y colocaremos los casos de uso en el contexto de un esfuerzo de anlisis. Las entrevistas al cliente debern iniciar el proceso. Estas entrevistas producirn diagramas de clases que fungirn como las bases de su conocimiento para el dominio del sistema (el rea en el cual resolver los problemas). Una vez que conozca la terminologa general del rea del cliente, estar listo para hablar con los usuarios. Las entrevistas con los usuarios comienzan en la terminologa del dominio, aunque debern alternarse hacia la terminologa de los usuarios. Los resultados iniciales de las entrevistas debern revelar a los actores y casos de uso de alto nivel que describirn los requerimientos funcionales en trminos generales. Esta informacin establece los confines y mbito del sistema. Las entrevistas posteriores con los usuarios profundizarn en estos requerimientos, lo que dar por resultado modelos de casos de uso que mostrarn los escenarios y las secuencias detalladamente. Esto podra resultar en otros casos de uso que satisfagan las relaciones de inclusin y extensin. En esta fase, es importante confiar en su comprensin del dominio (a partir de los diagramas de clases derivados de las entrevistas con el cliente). Si no comprende adecuadamente el dominio, podra crear demasiados casos de uso y demasiados detalles (situacin que podra, definitivamente, obstaculizar el diseo y el desarrollo). Aplicacin de los modelos de caso de uso Para ayudarle a comprender con ms profundidad los modelos de casos de uso y cmo aplicarlos, vamos a ver un ejemplo ms complejo que una mquina de gaseosas. Suponga que deber disear una red de rea local (LAN) para una firma de consultora, y que tendr que comprender la funcionalidad para poder crearla. Cmo empezara? Comprensin del dominio
U N
I V E
R S
I D A D
D E
A Q 26
U I N O
B O
L I V I A
Empecemos con las entrevistas al cliente para crear un diagrama de clases que refleje cmo es la vida en el mundo de la consultora. El diagrama de clases podra incluir las siguientes clases: Consultor, Cliente, Proyecto, Propuesta. Datos e Informe. La figura le muestra la forma en que podra lucir el diagrama.
Comprensin de los usuarios Ahora que el dominio est a la mano, vuelva su atencin a los usuarios debido a que el objetivo ser entender los tipos de funcionalidad por crear en el sistema. En el mundo real, entrevistara a los usuarios. En este ejemplo, basar sus ideas en cierto conocimiento general de las LANs y del dominio. No obstante, tenga presente que en el anlisis de sistemas del mundo real, nada puede sustituir a las entrevistas con las personas. Un grupo de usuarios sern consultores, otros podran ser oficinistas. Entre otros usuarios en potencia se encontrarn funcionarios corporativos, vendedores, administradores de red, administradores de oficina y administradores de proyectos. (Se le ocurren otros?) En este punto, sera conveniente a mostrar a los usuarios en una jerarqua de generalizacin. Como se observa en la figura. Comprensin de los casos de uso Qu hay de los casos de uso? Hay algunas posibilidades: Establecer niveles de seguridad, Crear una propuesta, Almacenar una propuesta, Utilizar correo electrnico, Compartir informacin de la base de datos, Realizar la contabilidad, Conectarse a la LAN desde fuera de ella, Conectarse a Internet, Compartir informacin de la base de datos, Indizar las propuestas, Utilizar propuestas previas y Compartir impresoras. De acuerdo con esta informacin, la figura le muestra el diagrama de casos de uso de alto nivel que hemos generado.
U N
I V E
R S
I D A D
D E 27
A Q
U I N O
B O
L I V I A
Este conjunto de casos de uso constituye los requerimientos funcionales de la LAN. Profundizacin Elaboremos uno de los casos de uso de alto nivel y generemos un modelo de caso de uso. Una actividad extremadamente importante en una firma de consultora es la generacin de propuestas, as que examinemos el caso de uso Crear una propuesta. Las entrevistas con los consultores probablemente le indicarn cuntos pasos se necesitan en este caso de uso. Para empezar, el actor inicial es un consultor. El consultor tiene que iniciar una sesin en la LAN y ser verificado como usuario vlido. Luego tendr que utilizar algn software integrado para oficina (procesador de textos, hoja de clculo y grficos) para escribir la propuesta. En el proceso, el consultor podra volver a utilizar porciones de propuestas previas. La firma de consultora podra tener una directiva de que un funcionario corporativo y otros dos consultores revisen una propuesta antes de que llegue a manos del cliente. Para ello, el consultor almacena la propuesta en un rea central
accesible mediante la LAN, y enva a los correos electrnicos de los tres revisores un mensaje que indique que la propuesta se encuentra lista, as como su ubicacin. Luego de recibir los comentarios y hacer las modificaciones necesarias (nuevamente, con el software integrado para oficina), el consultor imprime la propuesta y la enva por correo al cliente. Cuando todo termina, el consultor se retira de la red. El consultor habr completado una propuesta y es el actor que se beneficia del caso de uso. En la secuencia anterior, es claro que ciertos pasos se repetirn de un caso de uso a otro, y ello le llevar a otros casos de uso (posiblemente incluidos) en los que tal vez no haba pensado. Iniciar una sesin y ser verificado son dos pasos que pueden incluir varios casos de uso. Por ello, crear un caso de uso Verificar usuario que incluya Crear una propuesta. Otro par de casos de uso son Utilizar software de oficina y Finalizar sesin de la red. Podran aparecer otros detalles del proceso de una propuesta cuando vea que las propuestas elaboradas para los clientes nuevos son diferentes a las de los clientes constantes. En s, las propuestas a los nuevos clientes probablemente incluyen informacin promocional de la empresa. Con los clientes constantes, no ser necesario enviar tal informacin. As pues, otro nuevo caso de uso, Crear una propuesta para un cliente nuevo extender a Crear una propuesta. La figura le muestra el diagrama de casos de uso que resulta de este anlisis del caso de uso Crear una propuesta.
Este ejemplo aterriza un punto importante, uno que haba destacado anteriormente: El anlisis del caso de uso describe el comportamiento de un sistema. No toca a la implementacin. Esto es particularmente importante en este caso, dado que el diseo de una LAN supera, por mucho, el alcance de este libro! Fuente: Aprendiendo UML en 24 Horas, Joseph Schmuller, Perarson Educacin, Mexico 2000 CUESTIONARIO 1. Mencione dos ventajas de concebir un caso de uso. 2. Describa la generalizacin y el agrupamiento, las relaciones entre los casode uso que ha visto durante esta hora. Mencione dos situaciones en las que usted agrupara los casos de uso. 3. Cules son las similitudes entre las clases y los casos de uso? Cules las diferencias? 4. Bosqueje el diagrama de un modelo de caso de uso para un control remoto de una televisin. Asegrese de incluir todas las funciones del control remoto como casos de uso para su modelo. 5. En el segundo ejercicio de la hora 6 indic a los actores y casos de uso de un almacn de cmputo. Esta vez, dibuje un diagrama de casos de uso de alto nivel con base en el trabajo que realiz en tal ejercicio. Luego, genere un modelo de caso de uso para al menos uno de los casos de uso de alto nivel. En su trabajo, intente incorporar las relaciones incluir o extender que sean necesarias.
WORK PAPER # 5
No. DE PROCEDIMIENTO: APRO07
No. DE HOJAS: 7
ELABOR: Ing. Gisela Chumacero Tellez TTULO DEL WORK PAPER:
CDIGO: CMP 326
Procesos de desarrollo: XP y FDD

DPTO.: Facultad de Ciencias y Tecnologa DESTINADO A: DOCENTES ALUMNOS X ADMINIST. OTROS
OBSERVACIONES: Carrera Ingeniera de Sistemas Asignatura Anlisis de Sistemas II Unidad II
U N
I V E
R S
I D A D
D E
A Q 30
U I N O
B O
L I V I A
Procesos de desarrollo: XP y FDD
XP
Mientras que el RUP intenta reducir la complejidad del software por medio de estructura Procesos de desarrollo: RUP, XP y FDD y la preparacin de las tareas pendientes en funcin de los objetivos de la fase y actividad actual, XP, como toda metodologa gil, lo intenta por medio de un trabajo orientado directamente al objetivo, basado en las relaciones interpersonales y la velocidad de reaccin. XP intenta minimizar el riesgo de fallo del proceso por medio de la disposicin permanente de un representante competente del cliente a disposicin del equipo de desarrollo. Este representante debera estar en condiciones de contestar rpida y correctamente a cualquier pregunta del equipo de desarrollo de forma que no se retrase la tomar de decisiones, de ah lo de competente. XP define UserStories como base del software a desarrollar. Estas historias las escribe el cliente y describen escenarios sobre el funcionamiento del software, que no solo se limitan a la GUI si no tambin pueden describir el modelo, dominio, etc. A partir de las UserStories y de la arquitectura perseguida se crea un plan de releases (dejar el trmino en ingls, pues las habituales traducciones al castellano, liberacin o entrega del software, no son de mi agrado, supongo que son cosas de vivir en el extranjero) entre el equipo de desarrollo y el cliente. Para cada release se discutirn los objetivos de la misma con el representante del cliente y se definirn las iteraciones (de pocas semanas de duracin) necesarias para cumplir con los objetivos de la release. El resultado de cada iteracin es un programa que se transmite al cliente para que lo juzgue. En base a su opinin se definen las siguientes iteraciones del proyecto y si el cliente no esta contento se adaptar el plan de releases e iteraciones hasta que el cliente de su aprobacin y el software este a su gusto. Junto a los UserStories estn los escenarios de pruebas que describen el escenario contra el que se comprueba la realizacin de las UserStories. UserStories y casos de pruebas son la base sobre la que se asienta el trabajo del desarrollador. Como primer paso de cada iteracin se escribirn las pruebas, de tal forma que puedan ser ejecutadas automticamente, de manera que pueda comprobarse la correccin del software antes de cada release. Esto es de vital importancia en XP debido a su apuesta por las iteraciones cortas que generan software que el cliente puede ver y por la refactorizacin para mejorar el cdigo constantemente, que hacen ms que deseable una cantidad considerables de test lo ms automatizables posible. As pues, la funcionalidad concreta del software solo se escribe cuando las pruebas para su correccin estn preparadas.
U N
I V E
R S
I D A D
D E 31
A Q
U I N O
B O
L I V I A
La codificacin del software en XP se produce siempre en parejas (dos programadores, un ordenador), por lo que se espera que la calidad del mismo suba en el mismo momento de escribirlo. Al contrario que muchos otros mtodos, el cdigo pertenece al equipo en completo, no a un programador o pareja, de forma que cada programador puede cambiar cualquier parte del cdigo en cualquier momento si as lo necesita, dejndose en todo caso las mejoras orientadas al rendimiento para el final. Las parejas no se mantienen para todo el proyecto si no que rotan cclicamente a lo largo del mismo, tanto en cuanto a los componentes de la misma como en las partes del software que desarrollan, as cada componente del equipo aprende como trabaja el resto. El objetivo ideal sera que cada componente del equipo trabaje al menos una vez con cada uno de los dems integrantes y con cada componente software, de forma que el conocimiento de la aplicacin completa lo posea el equipo entero y no unos pocos miembros. En XP se programar solo la funcionalidad que es requerida para la release actual. Es decir, una gran flexibilidad y capacidad de configuracin solo ser implementada cuando sea necesaria para cumplir los requerimientos de la release. Se sigue un diseo evolutivo con la siguiente premisa: conseguir la funcionalidad deseada de la forma ms sencilla posible. De ah una variacin educada del famoso KISS (Keep It Simple Stupid), Keep things as simple as possible (mantn las cosas tan sencillas como sea posible). Este diseo evolutivo hace que no se le de apenas importancia al anlisis como fase independiente, puesto que se trabaja exclusivamente en funcin de las necesidades del momento.
FDD
FDD es un proceso diseado por Peter Coad, Erich Lefebvre y Jeff De Luca y se podra considerar a medio camino entre RUP y XP, aunque al seguir siendo un proceso ligero (en mi opinin, si tenemos que distinguir entre pesado/ligero) es ms similar a este ltimo. FDD esta pensado para proyectos con tiempo de desarrollo relativamente cortos (menos de un ao). Se basa en un proceso iterativo con iteraciones cortas (~2 semanas) que producen un software funcional que el cliente y la direccin de la empresa pueden ver y monitorizar. Las iteraciones se deciden en base a features (de ah el nombre del proceso) o funcionalidades, que son pequeas partes del software con significado para el cliente. As, construir el sistema de ventas es algo que requiere mucho tiempo, y construir el sistema de persistencia no tiene significado para el cliente, pero si lo tiene enviar pedido por email. Un proyecto que sigue FDD se divide en 5 fases: 1. Desarrollo de un modelo general 2. Construccin de la lista de funcionalidades 3. Plan de releases en base a las funcionalidades a implementar 4. Disear en base a las funcionalidades 5. Implementar en base a las funcionalidades
3. Fases de FDD
Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones, siendo las dos ltimas las que absorben la mayor parte del tiempo segn va avanzando el proyecto, limitndose las primeras a un proceso de refinamiento.
El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque siempre habr un responsable ltimo (arquitecto jefe o jefe de programadores en funcin de la fase en que nos encontremos), con mayor experiencia, que tendr la ltima palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue que todos formen parte del proyecto y que los menos inexpertos aprendan de las discusiones de los mas experimentados, y al tener un responsable ltimo, se asignan las responsabilidades que todas las empresas exigen. Las funcionalidades a implementar en una release se dividen entre los distintos subgrupos del equipo, y se procede a implementarlas. Las clases escritas tienen propietario (es decir, solo quin las crea puede cambiarlas), es por ello que en el equipo que implementa una funcionalidad dada debern estar todos los dueos de las clases implicadas, pudiendo encontrarse un programador en varios grupos, implementando distintas funcionalidades. Habr tambin un programador jefe (normalmente el ms experimentado) que har las funciones de lder del grupo que implementa esa funcionalidad. En el proceso de implementar la funcionalidad tambin se contemplan como partes del mismo (en otros mtodos se describen como actividades independientes) la preparacin y ejecucin de pruebas, as como revisiones del cdigo (para distribuir el conocimiento y aumentar la calidad) e integracin de las partes que componen el software. FDD tambin define mtricas para seguir el proceso de desarrollo de la aplicacin, tiles para el cliente y la direccin de la empresa, y que pueden ayudar, adems de para conocer el estado actual del desarrollo, a realizar mejores estimaciones en proyectos futuros.
La comparacin
Podramos pensar que no es posible comparar los distintos mtodos de desarrollo, y que todo depende de nuestros gustos personales, pero puesto que todos los procesos se centran en la produccin de software (orientado a objetos mayormente) y que el proceso se implantar para aumentar la calidad del software producido y la eficiencia de los desarrolladores, es deseable una comparacin, pero no en su conjunto, sino segn los medios que emplean y sus resultados. RUP, XP y FDD tienen pocas similitudes entre si, aunque XP y FDD poseen algunas ms al ser ambos ligeros, orientados al cliente y de iteraciones cortas y rpidas. Tambin hay que decir que debido al carcter general de RUP, algunos autores consideran todos los dems procesos de desarrollo como casos particulares de este. RUP esta pensado para proyectos y equipos grandes, en cuanto a tamao y duracin. FDD y XP se implementan mejor para proyectos cortos y equipos ms pequeos, siendo quizs FDD ms escalable que XP, ya que a mayor tamao de cdigo y/o equipo mayor es la necesidad de cierta organizacin.
Tamao de los equipos
Obtencin de requisitos
RUP y XP crean como base UseCases y UserStories, ambos describen los requerimientos de la aplicacin desde el punto de vista del usuario. Ambos definen los requisitos tcnicos sin meterse con detalles de implementacin. FDD por el contrario no define explcitamente esa parte del proyecto sobre la adquisicin de requisitos, y solo define el proceder a partir del momento en que ya se han recogido dichos requisitos, de la forma que queramos, dividiendo los requisitos (de forma similar a las UserStories) en las tres primeras fases del proyecto.
U N
I V E
R S
I D A D
D E 33
A Q
U I N O
B O
L I V I A
Carga de trabajo
XP es un proceso ligero, esto es, que los creadores del proceso han tenido cuidado de no poner demasiadas tareas organizativas sobre los desarrolladores (como modelado, generacin de documentacin externa, etc.), cuyo efecto se minimiza por medio de la presencia de un representante del cliente. En el desarrollo de un proyecto con XP es ms importante la entrega al cliente del software que necesita (lo que muy a menudo no es lo mismo que lo descrito en el documento de especificacin de requisitos) que las funcionalidades que quedan por implementar. Cuando durante el desarrollo se descubre que se deben cambiar las funcionalidades, se acuerda directamente con el representante del cliente. Con esos cambios se ajustar el plan de iteraciones y el de releases y se tomar la nueva direccin en el desarrollo. RUP es un proceso pesado, basado mucho en la documentacin, en la que no son deseables todos esos cambios voltiles. Existen diferentes elementos de planificacin (plan de desarrollo, plan de iteracin, plan de calidad, etc.) con los que se controla el desarrollo del software. A travs de un predefinido esquema de escalabilidad y gestin de riesgos, se pueden reconocer previamente problemas y fallos de forma temprana y prevenirlos/corregirlos. RUP define en cada momento del ciclo de vida del proyecto, que artefactos, con que nivel de detalle, y por qu rol, se deben crear. Se definirn que artefactos son necesarios para poder realizar una actividad y que artefactos se debern crear durante dicha actividad. FDD es por su parte un proceso intermedio, en el sentido de que genera ms documentacin que XP (donde apenas existe fuera del cdigo fuente) pero menos que RUP (que intenta documentar todo). Se entrega bastante libertad a los desarrolladores, pero siempre bajo cierto orden marcado por una jerarqua (arquitecto, programador jefe, etc.), que representa tambin en nivel de responsabilidad existente en cada caso.
Relacin con el cliente
Con RUP se presentarn al cliente los artefactos del final de una fase y se valorarn las precondiciones para la siguiente (definicin de riesgos, aceptacin del plan de iteracin, prototipos, etc.) y solo despus de que el cliente acepte los artefactos generados se pasar a la siguiente fase. La calidad de los artefactos generados ser probada durante la totalidad del ciclo de vida del proyecto a travs de distintas medidas de calidad, como convenciones, revisiones y auditoras peridicas, pruebas, etc. En contrapartida, la aseguracin de la calidad en XP y FDD no se basa en formalismos en la documentacin, si no en controles propios y una comunicacin fluida con el cliente. Tanto en XP como en FDD, el cliente recibe despus de cada iteracin un pedazo funcional del programa. A travs de un ciclo de iteracin corto (pocas semanas) el cliente est informado constantemente sobre la situacin del proyecto y puede intervenir rpidamente si el desarrollo se aleja de sus necesidades. En XP el desarrollo ve en que direccin debe ir gracias al feedback del cliente, sin ningn tipo de restriccin previa. En FDD sin embargo existe el modelo general desarrollado en la primera fase, que si bien evoluciona a lo largo del proyecto, provee un marco general dentro del cual evoluciona el proyecto (mientras no sea necesario cambiarlo). Todos ellos se basan en un proceso iterativo. Esto permite acercarse poco a poco a la solucin sin entrar demasiado rpido en detalles, aunque las iteraciones de XP y FDD tienen por lo general una duracin menor que en RUP, puesto que la carga a llevar por los programadores a parte del desarrollo del propio software es menor. XP esta diseado con los programadores en mente, con facilitar su trabajo y es por ello que define casi todo el proceso de desarrollo al completo, incluido el de pruebas y integracin. RUP y FDD se centran ms en la organizacin global, y muchas de esas actividades, como ejecucin de pruebas, las asumen como obligatorias aunque sin definirlas completamente, dejando libertad a las distintas subunidades del proyecto para implementarlas a su manera (por ejemplo usar la programacin por parejas en partes complejas), aunque las directrices de la empresa suelen marcar el camino a seguir. Debido a que las releases se producen a menudo, XP afirma la necesidad de que se puedan realizar pruebas automticas.
Desarrollo
U N
I V E
R S
I D A D
D E
A Q 34
U I N O
B O
L I V I A
La implementacin de las pruebas antes que la propia funcionalidad hace que el desarrollador tenga que pensar pronto sobre lo que tiene que hacer y como probarlo correctamente. A travs de pruebas automticas se conseguir que la funcionalidad se ajuste a los esperado por cada release, de modo que es importante que solo se enve al cliente cdigo que pase al 100% las pruebas. Este es en todo caso un punto deseable en cualquier proceso de desarrollo. RUP genera tambin releases basados en los artefactos despus de cada fase, pero en su caso no se limitan solo al cdigo, si no que las releases viene acompaada de todo lo que traera el producto final, es decir, notas de la versin, instrucciones de instalacin, ayuda de uso, etc.
Cdigo fuente
XP es el nico que presenta la comparticin del cdigo, mayormente debido a que esta pensado para equipos pequeos que trabajan conjuntamente y con comunicacin constante e inmediata, mientras que los otros dos procesos optan por la propiedad del cdigo, aunque definen grupos y sesiones de trabajo conjuntos de forma que los propietarios de clases relacionadas trabajan juntos, y la comunicacin es directa.
Conocimiento sobre la arquitectura
En XP se conseguir a travs de la programacin a pares que ya en la creacin del cdigo se puedan evitar errores y malos diseos ya que se controlar cada lnea de cdigo y decisin de diseo instantneamente. Se espera que la buena conexin entre ambos desarrolladores genere discusiones que lleven a mejores estructuras y algoritmos y que este proceso aumente la calidad del software de tal manera que compense el coste de la programacin por parejas. Tambin se intentar aumentar el conocimiento sobre el conjunto de la aplicacin a travs de la rotacin de los miembros del equipo sobre los componentes y emparejamientos. En RUP se intentar reducir la complejidad del software a producir a travs de una planificacin intensiva. As se intentar evitar que por la desaparicin de alguna pieza clave del equipo se pierda el conocimiento sobre la aplicacin. En FDD sin embargo se usan las sesiones de trabajo conjuntas en fase de diseo para conseguir una arquitectura sencilla y sin errores y las revisiones de cdigo guiadas por algn programador con ms experiencia. Estas sesiones, habituales en cada equipo e iteracin, estn ms enfocadas al trabajo en conjunto que al intercambio de impresiones y/o estado, como podra ser el caso de las daily meetups de XP. En todo caso, como no podra ser de otra forma, todos los mtodos de desarrollo modernos ponderan la utilizacin frecuente de reuniones entre los miembros del equipo, que pueden ir desde diarias, como propone XP, a semanales o mensuales, de duracin de minutos o de horas, segn los objetivos de la reunin.
Evaluacin del estado del proyecto
FDD es posiblemente el proceso ms adecuado para definir mtricas que definan el estado del proyecto, puesto que al dividirlos en unidades pequeas es bastante sencillo hacer un seguimiento de las mismas. XP tambin define esos componentes pequeos, pero la tarea del reporting recae solo en los jefes de proyecto, mientras que en FDD esta ms distribuida en la jerarqua. RUP por su parte, es tan grande y complejo en este sentido como en el resto, por lo que manejar el volumen de informacin que puede generar requiere mucho tiempo.
Puntos flacos.
Por desgracia ninguno de estos procesos puede ser considerado perfecto, ni ser aplicado en su totalidad en en la mayora de los casos, por lo que tambin es necesario saber donde estn sus puntos dbiles para corregirlos, si es necesario. XP es un proceso muy orientado a la implementacin. Debido al bajo nmero de documentos a generar, se ofrece al desarrollador un escenario ideal para participar en el proyecto. Este proceso es aceptado con el mejor grado por desarrolladores menos experimentados ya que pueden sacar provecho directo de los compaeros ms experimentados.
U N
I V E
R S
I D A D
D E 35
A Q
U I N O
B O
L I V I A
Tambin el cliente esta contento porque recibe un software que se adapta a sus deseos exactamente, mientras disponga de tiempo y dinero, pero ya que la funcionalidad exacta del software final nunca se defini formal y contractualmente (definirlo sera un contrasentido para XP, puesto que impedira el transcurso normal del proyecto guiado por el feedback del cliente), este mtodo de desarrollo es quizs ms aplicable para desarrollos internos, ya que para proyectos externos existe el problema concreto de que se debe realizar muy pronto una oferta concreta que defina que funcionalidad se va a implementar y en que periodo de tiempo, lo que tambin es importante para el cliente, ya que debe estar en la posicin de comprobar tanto el rendimiento como la calidad y el contenido del software y estar seguro de recibirlo cuando lo espera. Se debe, en todo caso, tener una gran confianza entre el cliente y el equipo de desarrollo (o su empresa) para usar el XP para escribir el software. Se podra considerar que la solucin (terica) a este problema es la presencia del representante del cliente junto al equipo de desarrollo, pero es tambin poco probable que el cliente pueda prescindir de los empleados que renen las caractersticas requeridas, puesto que suelen ser poco menos que imprescindibles, y la solucin habitual de que un miembro del equipo tome el rol de representante del cliente no siempre puede ser acertada, ya que aunque la empresa desarrolladora tenga un experto en el dominio del problema, puede desconocer gran parte de las particularidades de la empresa del cliente, como polticas internas o particularidades remarcables. La programacin por parejas es un interesante punto a favor de XP, hasta el punto de que quizs debera ser utilizado por cualquier otro mtodo en determinadas ocasiones (algoritmos complejos, nuevos miembros del equipo con poca experiencia o malos hbitos, etc.), pero esta por ver hasta que punto el coste que supone es asumible por una empresa, y hasta que punto se puede producir el ambiente que presupone XP (a fin de cuentas a nadie le gusta estar mirando mientras otro esta delante de su ordenador). En todo caso, como ya se ha dicho en repetidas ocasiones, en muchos momentos del proceso de desarrollo, el trabajo en equipo solo puede ser beneficioso. Miembros del equipo con menos experiencia pueden aprender a partir de discusiones sobre una arquitectura ms que cuando ya la reciben definida y solo la tienen que implementar y/o completar. Si se debe seguir este modo de trabajo en todas las fases del desarrollo del software depende en gran medida del problema concreto en cuestin y del propio equipo. Lo que es muy poco deseable en XP es el hecho de evitar cualquier tipo de documentacin fuera del cdigo fuente (UML juega un papel prcticamente nulo, por ejemplo). Es asumible y aceptable que solo el propio cdigo contenga la documentacin actualizada, pero esto supone carencias que debemos tener en cuenta ya que puede no representar todo lo que debera (dependencias entre componentes, por ejemplo) y hace difcil utilizar la experiencia ganada en otros desarrollos (con otros equipos o por otras parejas), ya que no se ha anotado o archivado nada y se debe generar todo desde cero. FDD presenta su taln de Aquiles en la necesidad de tener en el equipo miembros con experiencia que marquen el camino a seguir desde el principio, con la elaboracin del modelo global, puesto que no es tan gil como podra serlo XP. Es en todo caso este requisito una necesidad en cualquier proyecto si queremos llevarlo a buen puerto con xito. Su punto intermedio entre la libertad de XP y la rigurosidad de RUP lo hacen sin duda un proceso interesante, pero a pesar de cambiar la forma de afrontar el problema, la jerarqua existente puede hacer que las dependencias de esa gente experimentada sean grandes. El problema de usar RUP esta en otro campo completamente distinto. Para el desarrollo de software por medio de equipos pequeos (hasta unas diez personas) es RUP definitivamente muy grande y prcticamente inalcanzable. Se deben repartir 31 roles y generar ms de 100 artefactos distintos. Esto supone que antes de implantar RUP se debe adaptar hasta el punto de hacerlo parecer otro proceso, lo que tambin requiere su tiempo y tiene su coste. Si el proyecto es suficientemente grande como para compensar la adaptacin a RUP, entonces es una buena base para el proceso, para conseguir una mayor y mejor estructura y disciplina del proceso de desarrollo. Una buena posibilidad de reducir el trabajo a realizar es la reutilizacin de modelos, procesos, etc. ya definidos en utilizaciones previas de RUP en distintos mbitos.
U N
I V E
R S
I D A D
D E
A Q 36
U I N O
B O
L I V I A
Cuestionario
Identifique los puntos clave de cada metodologa? Qu debemos esperar entonces de un proceso de desarrollo? Qu criterios debe cumplir un proceso desarrollo para que aporte algo a la empresa?
U N
I V E
R S
I D A D
D E 37
A Q
U I N O
B O
L I V I A
PROGRAMA DE CALIDAD UDABOL DIF 001 SISTEMAS DE SOPORTE A LA DECISIN: TECNOLOGA AL ALCANCE DE LAS PYMES Por: Ing. Jorge W. Palazuelos wpalazuelos@itesm.mx Jorge W. Palazuelos: Ingeniero en sistemas de informacin por el Instituto Tecnolgico y de Estudios Superiores de Monterrey en el 2001, y actualmente es estudiante de la Maestra en Administracin de Tecnologas de Informacin en la misma institucin. ABSTRACT Las Pymes nacionales representan un aporte muy importante al desarrollo econmico del pas, por lo que debemos estar al pendiente de la manera en la que estas empresas buscan competitividad en un mercado cada vez ms abierto y global. La supervivencia en un mercado que cada vez es ms exigente est haciendo que las empresas busquen maneras de mantenerse a flote y un DSS representa precisamente un salvavidas para estas empresas. Los beneficios esperados a la implementacin de un DSS van desde ahorros en costos hasta la satisfaccin de nuestros clientes, pero el principal problema es que los empresarios Pyme no saben esto. Los requisitos para la implementacin de un DSS en una Pyme no son ms complejos que la iniciativa del empresario y muchas decisiones que tomar, con esto nos damos cuenta de que los DSS son una tecnologa que estn al alcance de las Pymes. PALABRAS CLAVE PYMES, DSS, Sistema de soporte a la decisin, Decisiones, Globalizacin INTRODUCCIN Hoy en da podemos encontrar una gran cantidad de definiciones acerca de lo que son las Pymes (pequeas y medianas empresas), pero para efectos de simplificacin en este trabajo consideraremos como una Pyme a la que dependiendo de su giro y a su nmero de empleados se clasifique como pequea o mediana de acuerdo a la siguiente tabla: Tamao de la empresa Pequea Mediana Grande Industria 1-30 31-100 101 + Comercio 1-5 6-20 21+ Servicios 1-20 21-50 51+
Las Pymes en Mxico, que emplean al 78% de la poblacin econmicamente activa y aportan el 68% al PIB, representan un aporte muy importante al desarrollo econmico del pas, es por eso que debe de preocuparnos la manera de desarrollar una estrategia que les permita sortear la gran cantidad de riesgos y obstculos a los que se enfrentan en una economa globalizada. El presente trabajo busca presentar de manera clara como es que tecnologas de informacin que consideramos tan avanzadas y/o caras, especficamente los sistemas de soporte a la toma de decisiones (DSS, por sus siglas en ingls), estn al alcance de las pequeas y medianas empresas y forman parte esencial de esta estrategia de supervivencia. (Vzquez, 2003) DESARROLLO
Regularmente, la manera ideal en que se debera de llevar a cabo el proceso de toma de decisiones en las Pymes sera de la siguiente manera (Emily, 2002): 1. Determinar la necesidad de la decisin, definir los motivos que nos llevaron a la situacin actual y porque es necesario tomar una decisin para arreglarla. 2. Identificar los criterios de decisin, es decir tener un conocimiento de que variables entrarn en juego al momento de tomar nuestra decisin. 3. Asignar peso a los criterios, una vez definidas las variables pasamos a determinar cuales de ellas son ms importantes para nosotros y nos cuestionamos porqu. 4. Desarrollar todas las alternativas, se deben de generar escenarios todos los escenarios posibles que presenten una posible solucin al problema que se nos presenta. 5. Evaluar las alternativas, se debe de evaluar de manera crtica cada una de las alternativas o escenarios que se desarrollaron en el paso anterior. 6. Seleccionar la mejor alternativa (tomar la decisin), siendo totalmente objetivo y lgico se selecciona la mejor alternativa para la situacin especfica que se nos presenta. Un sistema de soporte a la toma de decisiones tiene como objetivo primordial apoyar este proceso en al menos los ltimos 5 pasos, es decir que los sistemas de este tipo permiten y promueven la manipulacin de datos a fin de poder relacionarlos con distintos criterios y presentar esta informacin de forma tal que permita rpidamente visualizar tendencias, posiciones y ubicaciones con respecto a una planeacin original, con el fin de tener los elementos para tomar una decisin (Bauelos, 2001). En una empresa existen bsicamente tres niveles de administracin (operativo, tctico y estratgico), cada nivel presenta necesidades de informacin particulares por lo que el sistema de soporte para la toma de decisiones debe de estar diseado de manera tal que cubra las necesidades de los tres niveles. A continuacin se muestra una grfica que explica este comportamiento. (Annimo, 2001)
Fig. 1 La necesidad de implementar un DSS, por complejo o simple que este sea, en una Pyme crece da a da. Con la inevitable apertura econmica de nuestro pas el mercado ha sufrido una gran transformacin, las empresas exigen ms calidad a los proveedores, mayor calidad y rapidez en los servicios y con el menor costo, por lo tanto se requiere que las decisiones sean tomadas de manera ms rpida y ms certera (Vzquez, 2003). El destino de una empresa est conformado en base a las decisiones que toma el administrador y que mejor manera de asegurar un futuro prometedor que con una herramienta de apoyo a la toma de decisiones tan poderosa como lo es un DSS. Los beneficios que se esperan obtener por parte de una Pyme al implementar un DSS no estn en relacin directa con su tamao, es decir los beneficios para una Pyme son los mismos que para una empresa de gran tamao. A
continuacin se listan algunos de los beneficios surgidos de una encuesta realizada en ms de 200 organizaciones norteamericanas (Rivera, 2001): Una alta calidad en la toma de decisiones Mayor comunicacin Reduccin de costos Mayor productividad Ahorro de tiempo Satisfaccin de clientes y empleados
Todo lo anterior suena muy lgico y hasta se podra decir que cualquier administrador lo pudiera llevar a cabo utilizado su sentido comn, pero nuestras Pymes se enfrentan a grandes barreras que les impiden poder implementar DSS a fin de ser ms competitivas y mantenerse con vida. La principal de estas barreras es indudablemente la falta de informacin que tienen los administradores de las Pymes que en su mayora cuentan con ms buenas intenciones que preparacin para la direccin de un negocio. La resistencia al cambio es otra de estas barreras que se requiere sean vencidas por las Pymes, ya que la implementacin de un DSS requiere cambios radicales en los procesos que se llevan a cabo en la empresa, desde el administrador al tomar la decisin, hasta los operativos que sern los encargados de acumular la informacin con la cual se alimentar el DSS. Despus de haber hablado de lo que es un DSS, sus beneficios, la necesidad de su uso y las posibles barreras para su implementacin dentro de una Pyme, me resta hablar de los requisitos para el desarrollo e implantacin de un DSS dentro de una empresa de este tipo, a fin de que los administradores puedan darse cuenta de que un sistema de soporte a las decisiones est a su alcance y no es una utopa salida de un libro de negocios. A continuacin se listan estos requisitos: Disponibilidad del administrador Tener informacin histrica y presente de las operaciones Un asesor informtico profesional y sensibilizado con el negocio. Un sistema administrador de bases de datos. Un sistema de informacin que procese los datos de los bases de datos y que muestre la informacin requerida para la toma de decisiones Una inversin en el desarrollo o compra del sistema. y decisiones importantes que tomar Como podemos darnos cuenta estos requisitos no son tan descabellados y podra decir que todas las Pymes los tienen. El punto que podra preocupar ms es la inversin que se tenga que hacer, pero se debe de tener en cuenta que el tamao esta inversin estar en medida de los requerimientos de ayuda en la toma de decisiones y en lo complejo que se quiera el sistema. CONCLUSIONES Hoy en da los administradores se enfrentan a una cantidad inimaginable de retos, pero uno de los ms demandantes para las organizaciones es el de la toma de decisiones. El administrador moderno debe de estar conciente de la importancia que tienen las decisiones que toma hoy para el futuro de la empresa recordemos que los problemas de hoy son consecuencias de las malas decisiones del pasado (Chong et al., 2003). El apoyo que los sistemas de informacin ofrecen a esta proceso de toma de decisiones es muy importante, por no decir que esencial, de aqu la importancia de los DSS en las Pymes. Actualmente las Pymes encuentran un gran apoyo por parte del gobierno a travs de la Secretara de Economa, apoyo que se traduce en capacitacin y asesoras a los administradores de este tipo de negocios. El principal problema aqu es la falta de difusin de estos apoyos combinado con la nula actualizacin y falta de informacin que tienen la mayora de
los empresarios Pyme. El gobierno ya se ha dado cuenta y busca reducir de cierta manera la brecha digital que se est haciendo cada vez ms amplia entre las Pymes y los grandes corporativos para que las Pymes tengan un uso correcto de las tecnologas de informacin tal y como sucede con sus similares en los pases desarrollados. Existen en el mercado una gran cantidad de productos que se pueden utilizar como DSS y que estn alcance de las Pymes. Una sencilla hoja de Microsoft Excel con los datos y las frmulas adecuadas, bien se podra usar como un DSS, pero si lo que se quiere es algo un poco mas formal se puede pensar en una solucin como lo es el paquete Exin de la empresa Computacin en Accin que adems de controlar inventario, gastos y cobranza entre otras cosas, ofrece reportes de todos los rubros de la empresa lo que asiste en gran medida a la toma de decisiones y a un precio bastante accesible. Otro paquete que est accesible para las empresas es la solucin integral vendida por la empresa Aspel, la cual se puede ir comprando por mdulos dependiendo de las necesidades de la empresa. Las Pymes deben aprovechar su principal ventaja ante los grandes corporativos que es la flexibilidad, en gran medida debido a su tamao, y darse cuenta que la implementacin de un DSS o cualquier otro sistema de informacin es ms viable en este tipo empresa que en las grandes. La competitividad dada por el hecho de estar actualizados en el uso de sistemas de informacin y en la toma de decisiones de calidad en tiempo, les permitir a las Pymes sobrevivir a un mercado cada vez mas abierto y duro a la vez. A las Pymes no les debe de preocupar tanto la llegada de los grandes multinacionales, sino la llegada de productos y servicios de Pymes extranjeras que si se supieron adaptar a las condiciones que les ofreca el mercado gracias al uso extendido de los sistemas de informacin. Esperemos pues que nuestras Pymes nacionales no slo sean competitivas en el mercado local, sino que sean capaces de salir a luchar como iguales a los mercados extranjeros.
U N
I V E
R S
I D A D
D E 41
A Q
U I N O
B O
L I V I A
PROGRAMA DE CALIDAD UDABOL DIF 002 SISTEMAS INTELIGENTES DE SOPORTE A LA TOMA DE DECISIONES. ABSTRACT Turban & Aroson.
En el presente documento se aborda el problema de la toma de decisiones que en la actualidad se ha vuelto cada vez ms compleja, debido a las caractersticas del entorno econmico al que se enfrentan las empresas y a la cantidad de informacin que debe manejarse. Por tal razn, en apoyo a quienes toman decisiones se han construido diversas herramientas informticas: como por ejemplo, los sistemas de apoyo a la toma de decisiones (DSS) que permiten a las empresas ser ms flexibles en el entorno global de la nueva economa y asimismo tomar decisiones en forma ms acertada. Desarrollo La aldea global, como se ha denominado al mundo postmoderno, se caracteriza por la interrelacin e interdependencia econmica de todos los pases del orbe, as como el empleo de los avances tecnolgicos en los procesos de produccin y comercializacin; lo cual exige de las empresas un nivel de competitividad fundamentado en sus recursos internos y en las relaciones que pueden establecer con su entorno social, poltico, econmico y cultural. Por lo anterior, la nueva tecnologa ha transformado la forma de hacer negocios. Consideramos que este elemento es importante, ya que actualmente la tecnologa juega un papel esencial en las empresas, principalmente como una herramienta de apoyo para lograr una ventaja competitiva. Con esta idea, la administracin de las empresas se ha visto inmersa en una transformacin radical, ya no podemos pensar en una organizacin vertical donde una sola persona decide el cmo, el cundo, el con qu, etc. del proceso administrativo. La toma de decisiones se ha convertido, por lo tanto en un factor fundamental del proceso administrativo a lo largo y ancho de la organizacin, adems de la importancia que conlleva el compartir datos y tener la informacin en el lugar y en el momento oportunos. Para ello se han instrumentado los sistemas de apoyo a la toma de decisiones (DSS) que permiten de forma ms eficiente lograr lo anterior. Al interior de una organizacin, se deben tomar decisiones en diferentes niveles. En este sentido, Martnez Sarmiento (2002) nos seala los siguientes: La toma estratgica de decisiones que consiste en determinar los objetivos, polticas y recursos de una organizacin, la cual est a cargo de los directivos de las empresas. El control administrativo se refiere a la eficiencia y eficacia con la que se emplean los recursos. Este control est a cargo de las unidades operativas. La toma de decisiones a nivel conocimientos se encarga de la innovacin de nuevos productos, servicios y distribuir la informacin al interior de la organizacin. La toma de decisiones para el control operativo determina la forma de realizar las tareas especficas establecidas a niveles de mediana y alta gerencia. De igual manera, segn los criterios y la forma como se toman las decisiones, stas se pueden organizar en: estructuradas, no estructuradas y semiestructuradas. Las decisiones estructuradas son aquellas que cuentan con un proceso perfectamente definido para llevarse a cabo, es decir, que se realizan rutinariamente, no cambian; por ejemplo, la seleccin de personal en una empresa para un puesto determinado se da siempre de la misma manera. Las decisiones no estructuradas no cuentan con un procedimiento predeterminado, quien debe tomar una decisin se basa en criterios, valoracin y puntos de vista sobre el problema que se presenta, as como en el entorno en el cual se
sita la problemtica a resolver: por ejemplo, las decisiones sobre las inversiones de una empresa cuando genera ganancias extras. Las decisiones semiestructuradas consisten en que parte del problema sea estructurado y algunos otros elementos no lo sean. Un ejemplo de lo anterior lo encontramos en los casos de ascensos de personal, ya que algunos factores estn predeterminados y otros no.
Lo anteriormente sealado se esquematiza en el grfico que a continuacin se presenta. En l se observan las relaciones que se establecen entre los distintos niveles de toma de decisiones y los criterios y la forma en que esas se toman. De acuerdo a la clasificacin anterior, se puede contemplar cmo los DSS nicamente se manejan a nivel de decisiones semiestructuradas y no estructuradas ya que, como sabemos, en estos niveles es donde se requiere el apoyo tecnolgico de esa herramienta informtica. Los sistemas de apoyo a la toma de decisiones son "interactive computer-based systems, which help decision maker utilize data and models to solve unstructured problems" (Gorry and Scott Morton,1971, en Turban & Aronson, 2001:13); es decir, son sistemas interactivos basados en computadora, los cuales ayudan a tomar decisiones utilizando datos y modelos para resolver problemas no estructurados. Estos sistemas son utilizados en los niveles gerenciales de la organizacin en aspectos tcticos o estratgicos como por ejemplo un Sistema de Anlisis de Mercado que tome como datos las condiciones ambientales en las que se desenvuelve la organizacin y ofrezca como salidas informacin estructurada del ambiente para que los tomadores de decisiones puedan elegir el mejor camino a seguir. Los DSS se encuentran compuestos por: Una base de datos, dnde se almacenan los datos que puedan ser tiles para la toma de decisiones. Una base de modelos, los cuales permiten seguir una metodologa en la toma de decisiones. Un administrador de la base de datos, conformado por programas que administran la base de datos (software). Un administrador de la base de modelos que consiste en programas informticos que administran los modelos. Una interfaz de usuario, elemento mediante el cual el usuario interacta con el sistema.
Como se muestra en la siguiente figura.
U N
I V E
R S
I D A D
D E 43
A Q
U I N O
B O
L I V I A
Algunas de sus caractersticas principales son: o Rapidez en el anlisis de datos. o Flexibilidad en el manejo de informacin. o Sensibilidad para el manejo de informacin o Implementa la intuicin y el juicio en el anlisis. o Cuentan con modelos de anlisis de informacin. o Dependen de informacin suministrada por fuentes externas. o Brindan al usuario un acceso rpido y sencillo a la informacin. El manejo de un sistema de apoyo a la toma de decisiones reporta a las empresas una serie de beneficios que consisten, por ejemplo en: el incremento en la velocidad del procesamiento de datos, aumento en la productividad, ahorro de tiempo, mejora la calidad en la toma de decisiones lo que reduce los costos a lo largo de toda la organizacin, as como brinda una gran capacidad de almacenamiento de informacin y el procesamiento de datos. Como se puede observar a lo largo de este trabajo, resulta imprescindible para las empresas en la actualidad contar con el soporte tecnolgico que les permita competir eficientemente en el mercado mundial. Sin embargo como la implementacin de estas herramientas resulta costosa y requiere amplios periodos de tiempo para observar sus beneficios, las pequeas y medianas empresas, sobre todo, pueden optar por implementar sistemas ms pequeos que pueden resolver satisfactoriamente sus necesidades. Reconocemos el valor y la importancia de la tecnologa, pero no olvidemos que el factor humano siempre ser insustituible.
U N
I V E
R S
I D A D
D E
A Q 44
U I N O
B O
L I V I A
PROGRAMA DE CALIDAD UDABOL DIF 003 UNA MUESTRA DE MODELO DINMICO Se presenta aqu una muestra de modelo dinmico de un dispositivo real que muestra la forma en que encajan entre s las distintas estructuras de modelado. Se trata de un modelo del Termostato Programable Fin de Semana fabricado por Sears. Este modelo se ha construido leyendo el manual de instrucciones y experimentando con el dispositivo en s. Este dispositivo controla una caldera y un acondicionador de aire tomando como base unos atributos dependientes del tiempo que el propietario inserta empleando una botonera. Cuando est funcionando, el termostato pone en marcha la caldera o el acondicionador de aire para mantener una temperatura actual igual a la temperatura deseada, que se toma de una tabla de valores de programa proporcionada por el usuario. La tabla especifica temperaturas deseadas para 8 perodos de tiempo diferentes, 4 en los das laborables y 4 en das festivos, con tiempos de comienzo que especifica el usuario. La temperatura deseada se restaura a partir de la tabla al principio de cada perodo de programa. El usuario puede invalidar la temperatura deseada durante el resto del periodo actual, o indefinidamente. Puede programar el termostato empleando una botonera de 10 botones y 3 conmutadores. Los parmetros se ven en una pantalla alfanumrica. Hay un conmutador que ilumina la luz nocturna. El termostato tiene un sensor de temperaturas que lee la temperatura del aire. Adems hace funcionar rels para una caldera y para un acondicionador de aire encendindose un indicador cuando la caldera o el acondicionador estn en funcionamiento. Los botones generan un suceso cada vez que se pulsan. Se asignar un suceso de entrada por botn: SUBIR TEMP eleva la temperatura deseada o de programa BAJAR TEMP reduce la temperatura deseada o de programa AVANCE TIEMPO hace avanzar el tiempo en el reloj o en el programa RETROCESO TIEMPO retrasa el reloj o el tiempo del programa FIJAR RELOJ admite la hora actual FIJAR DA admite el da de la semana EJECUTAR PROG sale del modo de programacin o programa y ejecuta el programa VER PROG entra en el modo de programacin y modifica 8 valores de tiempo de programa y de valores de temperaturas MANTENER TEMP mantiene la temperatura deseada a pesar del programa BOTN F-C conmuta la temperatura visualizada entre Fahrenheit y Celsius Cada conmutador proporciona el valor de un parmetro seleccionado entre dos o tres posibilidades. Se modelar como un subdiagrama concurrente independiente, con un estado por valor del conmutador. Aunque se asignen nombres de sucesos a los cambios de estado, lo que interesa es el estado de los conmutadores. Los conmutadores y sus valores son como sigue: Conmutador de luz Ilumina la pantalla alfanumrica. Valores: luz apagada, luz encendida. Conmutador de estacin: Especifica el dispositivo que controla el termostato. Valores: calor (caldera), fro (aire acondicionado), apagado (ninguno). Conmutador de ventilacin: Especifica cuando funciona el ventilador. Valores: ventilador encendido (funciona continuamente), ventilador automtico (el ventilador slo funciona cuando est encendida la caldera o el aire acondicionado). El termostato controla los rels de la caldera, del acondicionador de aire y del ventilador. Este control se modela mediante las actividades encender caldera, encender acondicionador de aire y encender ventilador.
U N
I V E
R S
I D A D
D E 45
A Q
U I N O
B O
L I V I A
El termostato tiene un sensor de temperatura que la lee continuamente, la cual se modelar mediante un parmetro externo temp. El termostato tiene tambin un reloj interno que lee y visualiza continuamente. El reloj se programa mediante otro parmetro externo, hora, puesto que no interesa construir un modelo de estados del reloj. Al construir un modelo dinmico, es importante incluir solamente los estados que afecten al flujo de control, y modelar las dems informaciones como parmetros o variables. Se introduce una variable interna de estado llamada temp deseada, que representa la temperatura actual que pretende mantener el termostato. Esta variable de estado ser leda para algunas acciones y fijada por otras; permite la comunicacin entre distintas partes del modelo dinmico. La Figura 5.23 muestra el diagrama de estados de ms alto nivel para el termostato programable. Contiene 7 subdiagramas concurrentes. La interfaz de usuario es demasiado grande para mostrarla, y se expande en otro lugar. El diagrama incluye subdiagramas triviales para el conmutador de temporada y el conmutador de ventilador. Los otros 4 subdiagramas muestran la salida del termostato: los rels de caldera, aire acondicionado ventilador, y el indicador de actividad. Todos estos subdiagramas contienen un subestado Apagado y otro subestado Encendido. El estado de cada subdiagrama queda determinado totalmente por condiciones aplicables a los parmetros de entrada y al estado de los dems subdiagramas, tal como pueden ser el conmutador de temporada y el conmutador de ventilador. El estado de los cuatro subdiagramas de la derecha es completamente derivativo, y no contiene informacin adicional. La Figura 5.24 muestra el subdiagrama correspondiente a la interfaz de usuario. El diagrama contiene 3 subdiagramas concurrentes, uno para la pantalla interactiva, para el modo de temperatura, y uno para la luz nocturna. La luz nocturna es controlada mediante un conmutador real, as que el estado inicial por omisin es irrelevante; su valor se puede determinar directamente. El modo de visualizacin de temperatura es controlador por un nico botn que conmuta las unidades de temperatura entre Fahrenheit y Celsius. El estado inicial por omisin es necesario; cuando se suministra corriente al dispositivo, el modo inicial de temperatura es Fahrenheit. El subdiagrama para la pantalla interactiva es ms interesante. El dispositivo o bien est funcionando o est siendo programado. El subestado Funcionamiento contiene dos subestados, Ejecutar y Mantener, adems de otros dos subestados concurrentes, uno de los cuales controla la visualizacin de temperatura deseada y otro que controla la visualizacin de hora y temperatura actuales. Cada 2 segundos, la pantalla alterna entre la hora actual y la temperatura actual.
U N
I V E
R S
I D A D
D E
A Q 46
U I N O
B O
L I V I A
U N
I V E
R S
I D A D
D E 47
A Q
U I N O
B O
L I V I A
U N
I V E
R S
I D A D
D E
A Q 48
U I N O
B O
L I V I A
La temperatura deseada se muestra continuamente, y se modifica mediante los botones subir temp y bajar temp, as como mediante el suceso Fijar blanco que solamente se genera en el estado Ejecutar. Obsrvese que el parmetro temp deseada que se fija mediante este subdiagrama es el mismo que controla los rels de salida. Mientras se encuentre en el estado Funcionamiento, el dispositivo estar en los subestados Ejecutar o Mantener. En el estado Ejecutar, la hora actual se compara cada segundo con las horas de programa almacenadas en la tabla de programa; si son iguales, entonces el programa pasa al siguiente perodo de programa, y se vuelve a entrar en el estado Ejecutar. El estado de ejecucin se alcanza tambin siempre que se pulsa el botn ejecutar programa en cualquier estado, segn se muestra mediante la transicin del contorno al estado Funcionamiento y por la transicin inicial al
U N
I V E
R S
I D A D
D E 49
A Q
U I N O
B O
L I V I A
modo Ejecutar. Siempre que se entra en el estado Ejecutar, la accin de entrada del estado restaura la temperatura deseada a partir de la tabla de programa. Mientras el programa se encuentre en el estado Mantener, la temperatura de programa no podr avanzar automticamente, pero seguir siendo posible modificarla mediante los botones subir temp y bajar temp. El subestado por omisin al producirse la conexin es el subestado Funcionamiento. Si la interfaz se encuentra en alguno de los estados de preparacin durante 90 segundos sin ninguna entrada, entonces el sistema entra en el estado Mantener. Al entrar en el estado Mantener se fuerza tambin la entrada en sus estados iniciales por omisin para los otros dos subdiagramas concurrentes de Funcionamiento. Obsrvese que hay una pequea anomala en el dispositivo: el botn mantener no tiene efecto dentro del estado Preparar, an cuando se puede entrar en el estado Mantener esperando 90 segundos. Los tres subdiagramas de preparacin se muestran en la Figura 5.25. Al pulsar preparar reloj se entra en el subestado Preparar minutos como situacin inicial por omisin. Las pulsaciones subsiguientes de reparar reloj conmutan entre los subestados Preparar horas y Preparar minutos. Los botones avanzar hora y retrasar hora modifican la hora de programa. Al pulsar preparar da se entra en el subestado Preparar da y se muestra el da de la semana. Las pulsaciones subsiguientes incrementan directamente el da. Al pulsar ver programa se entra en el subestado Preparar programa, que tiene tres subestados concurrentes, cada uno de los cuales controla la visualizacin de la hora de programa, temperatura y perodo. El estado Preparar programa siempre comienza por el primer periodo de programa, mientras que los sucesos ver programa subsiguientes efectan un ciclo por los 8 perodos de programa. El suceso ver programa se muestra en los tres subdiagramas, y cada diagrama hace avanzar el valor que controla. Obsrvese que los sucesos avanzar hora y retrasar hora modifican la hora a incrementos de 15 minutos, a diferencia de los mismos sucesos en el estado preparar reloj. Obsrvese tambin que las transiciones subir temp y bajar temp tienen condiciones de proteccin para mantener la temperatura dentro de un intervalo prefijado. Ninguno de los subestados de Pantalla interactiva tiene una transicin de salida explcita. Cada subestado finaliza de forma implcita mediante una transicin a otro subestado desde el contorno Pantalla interactiva.
U N
I V E
R S
I D A D
D E
A Q 50
U I N O
B O
L I V I A

s6 - Analisis - de - Sistemas - II PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

s6 - Analisis - de - Sistemas - II PDF

Uploaded by

Copyright:

Available Formats

FACULTAD DE INGENIERIA

RED NACIONAL UNIVERSITARIA

SYLLABUS Facultad de Ingeniera Ingeniera de Sistemas SEXTO SEMESTRE

Syllabus elaborado por: Ing. Gisela Chumacero Tellez

UNIVERSIDAD DE AQUINO BOLIVIA Acreditada como PLENA mediante R. M. 288/01

EVALUACION FINAL PROMEDIO PARCIAL 1, 2 Y FINAL

VI. PLAN CALENDARIO

CALENDARIO ACADMICO GESTIN I/2011 TURNOS REGULAR-TRABAJO ESTUDIANTES NUEVOS-ANTIGUOS

TEMA 1 TEMA 1 TEMA 2 TEMA 2 TEMA 2

Presentacin de Notas Presentacin de Notas

TEMA 3 TEMA 3 TEMA 4 TEMA 4

Presentacin de Notas Presentacin de Notas

TEMA 5 TEMA 5 TEMA 6 TEMA 6

Presentacin de Notas Transcripcin de Notas Transcripcin de Notas

Conclusin Evaluacin Final Evaluacin del segundo turno Cierre de Gestin

22 de abril Viernes Santo 1 de mayo Da del Trabajo 23 de junio Corpus Christi

Anlisis y diseo Orientado a Objetos

Fases Requisitos y Anlisis

Fase Implementacin y Prueba

Computador, Data Display, Material Digital e Impreso, ejemplos de Aplicacin y Ejercicios

PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO: APRO 07 No. DE HOJAS : 3

CDIGO: CMP 326

OBSERVACIONES: Carrera Ingeniera de Sistemas Asignatura Anlisis de Sistemas II Unidad 1

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO: APRO 07 No. DE HOJAS: 3

CDIGO: CMP 326

OBSERVACIONES: Carrera Ingeniera de Sistemas Asignatura Anlisis de Sistemas II Unidad 1

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO: APRO 07 No. DE HOJAS: 6

CDIGO: CMP 326

OBSERVACIONES: Carrera Ingeniera de Sistemas Asignatura Anlisis de Sistemas II Unidad 1

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO: APRO07 No. DE HOJAS: 9

CDIGO: CMP 326

OBSERVACIONES: Carrera Ingeniera de Sistemas Asignatura Anlisis de Sistemas II Unidad 2

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

No. DE PROCEDIMIENTO: APRO07

ELABOR: Ing. Gisela Chumacero Tellez TTULO DEL WORK PAPER:

CDIGO: CMP 326

Procesos de desarrollo: XP y FDD

OBSERVACIONES: Carrera Ingeniera de Sistemas Asignatura Anlisis de Sistemas II Unidad II

FECHA DE DIFUSIN: Marzo 2011

FECHA DE ENTREGA: Marzo 2011

Procesos de desarrollo: XP y FDD

Tamao de los equipos

Relacin con el cliente

Conocimiento sobre la arquitectura

Evaluacin del estado del proyecto

Como se muestra en la siguiente figura.

You might also like