Ramire
QUINTA UNIDAD
72
72
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Lección 10
73
73
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
El sistema permitirá a los profesores: Consultar los horarios de sus cursos, Consultar la
programación de los exámenes, Actualizar y ver su información personal, Registrar y
modificar las notas de los estudiantes a su cargo, Cerrar un curso
El sistema permitirá a los estudiantes: Consultar los horarios de sus cursos, Consultar la
programación de los exámenes, Actualizar y ver su información personal, Consultar notas
de un curso.
74
74
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Performance (Desempeño), se refieren a las características de rendimiento del sistem.
Incluye tiempos de respuesta específicos. Por ejemplo: Tiempo de respuesta para una
transacción (promedio, máximo); Transacciones por segundo; Capacidad, como por
ejemplo el número de clientes o transacciones que el sistema puede soportar; Modos de
degradación, esto es, cual es el modo aceptable de funcionamiento cuando el sistema ha
sido degradado de alguna manera; Utilización de recursos: memoria, disco,
comunicaciones, etc.
Supportability (Capacidad de Soporte), son requerimientos que refuerzan el soporte y
mantenimiento del sistema que está siendo construido, incluyendo normas de codificación,
convenciones de nombres, librerías, acceso para mantenimiento, utilidades de
mantenimiento si las hay. Como requerimiento que ayuda al mantenimiento se debe hacer
referencia al uso de nomenclatura común para el desarrollo del sistema, y a la metodología
de desarrollo.
75
75
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
1.6.1 Entrevistas
Esta técnica es adecuada para la primera toma de contacto. Es conveniente comenzar por
preguntas de contexto libre, para entender: el problema, a las personas interesadas en la
solución, naturaleza de ésta, y lograr efectividad de la reunión.
Ejemplos de preguntas centradas en el cliente, los objetivos globales y beneficios
¿Quién solicita el trabajo?
¿Quién utilizará la solución?
¿Cuál será el beneficio económico de una buena solución?
¿Existen otras alternativas a esta solución?
76
76
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
1.6.2 JAD
El Diseño en Conjunto de Aplicaciones (JAD, “Joint Application Design”) fue desarrollado
por IBM a finales de los setenta. Es una sesión de trabajo con participación de todos los
involucrados. El resultado de la sesión es un documento de especificación que incluye
definiciones de elementos de datos, flujos de trabajo y pantallas de interfaz.
El resultado de una sesión JAD representa un acuerdo entre usuarios, clientes y
desarrolladores y minimiza los cambios posteriores de requerimientos.
Las actividades de la sesión JAD son: Definición del proyecto, Investigación, preparación,
Sesión, preparación del documento final.
Definición del proyecto: el coordinador se entrevista con gerentes y clientes para
determinar objetivos y alcance del proyecto. Se elabora la “guía de definición
administrativa”.
Investigación: se entrevista a usuarios y se recopila información del dominio, descripción
de flujos de trabajo y asuntos a tratar en la reunión. Se elabora la “agenda de sesión” y la
“especificación preliminar”.
Preparación: el coordinador elabora un “documento de trabajo” o primer borrador del
documento final.
Sesión: el coordinador guía al equipo para crear la especificación del sistema en una
reunión que puede durar varios días. Se definen los flujos de trabajo, elementos de datos,
pantallas, informes,... Las decisiones se documentan en unos formularios.
Preparación de documento final: el coordinador prepara el “documento final” usando los
“formularios” y se distribuye a los asistentes para su revisión. Se realiza una reunión para
discutir revisiones y finalizar el documento.
77
77
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Lección 11
11.2 Actor
Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con él. Una instancia de actor puede ser un individuo o un sistema
externo. La notación UML para el actor se muestra en la figura 11.1.
Por ejemplo, en el Sistema de Académico de la universidad, los actores pueden ser:
Secretario Académico, Alumno y Docente. Todos ellos interactúan con el sistema a través
de alguna de sus funcionalidades. Nótese que el nombre del actor represente el rol que
desempeñan grupos de usuarios, por ejemplo el rol alumno representa a todos los
alumnos; un alumno particular representa una instancia del actor alumno.
78
78
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
79
79
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor. Establecen lo que siempre debe cumplirse antes de comenzar un escenario en un
caso de uso. Normalmente implica que un escenario de otro caso de uso se ha
completado exitosamente. Estas deben redactarse en tiempo verbal pasado. Por ejemplo:
El usuario ha sido aceptado en el sistema con el rol de profesor.
Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la garantía de éxito. Estas deben redactarse en tiempo verbal pasado. Por
ejemplo: Se ha registrado en el sistema las notas de los alumnos.
El flujo básico, es la descripción narrativa de lo que debe ocurrir cuando los actores
interactúan con el sistema para satisfacer la meta u objetivo propuesto, se consideran los
pasos normales, no incluye las alternativas o variaciones.
Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del
flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales,
condiciones de error o violaciones de reglas.
Ejemplo de flujo básico:
1. El Caso de uso comienza cuando el profesor indica “registrar notas.”
2. El sistema muestra un formulario de validación de ingreso al sistema.
3. El usuario ingresa su código y su contraseña.
4. El sistema muestra los cursos asignados al profesor.
5. El profesor selecciona el curso.
6. El sistema muestra un listado de los estudiantes con sus notas.
7. El profesor selecciona el estudiante e ingresa la nota de práctica, del parcial, del
examen final y la nota final. Se repite para cada estudiante.
8. El profesor indica “guardar”.
9. El sistema valida toda la información y muestra un mensaje de confirmación y el
Caso de uso finaliza.
80 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
U suario
Mantener información del profesor
(f rom Actors )
Lección 12
acerca de las ocurrencias del sistema? Las respuestas a estas preguntas reflejan
funcionalidades del sistema para cada actor.
En nuestro caso, el actor Encargado de vuelo debe: Mantener información de unidades,
Registrar vuelo de carga y Registrar vuelo de pasajeros. El Gerente debe: Mantener
información de pilotos y Consultar vuelos por piloto. El Empleado de Ventas: Mantener
información de pasajeros, Registrar reserva de vuelo, Registrar confirmación de vuelo y
Consultar pasajeros que tomaron vuelo.
Mantener información de pilotos Consultar vuelos por pilotos Mantener información de pasajeros
Resumen
Conceptos asociados a los requerimientos
Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se
construye. Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restricción de éste
El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su entorno.
Un requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se
desarrolla. Pueden ser de: usabilidad, fiabilidad, desempeño, capacidad de soporte.
La entrevista es una técnica para obtener requerimientos usados en la primera toma de
contactos con los usuarios-clientes.
El diseño conjunto de aplicaciones, Joint Application Design (JAD) es una sesión con
participación de todos los involucrados, cuyo resultado es un documento de
especificación.
Conceptos asociados al modelo de casos de uso
El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del
sistema en forma de Casos de uso.
Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con él.
Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una
secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a
un actor particular.
Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor
Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la garantía de éxito.
Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del
flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales,
condiciones de error o violaciones de reglas.
Un diagrama de caso de uso muestra los actores los casos de uso y las relaciones entre ellos.
Proceso de construcción del modelo de casos de uso
Identificación de actores
Identificación de casos de uso
Elaboración de descripción de casos de uso
Elaboración de diagrama de casos de uso
86 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Lectura
Crear el diseño lógico de una interfaz de usuario (*)
Cuando los actores interactúan con el sistema, utilizaran y manipularan elementos de interfaces
de usuario que representan atributos (de los casos de uso). A menudo estos son términos del
glosario (por ejemplo, balance de cuenta, fecha de vencimiento y titular de cuenta). Los actores
pueden experimentar estos elementos de las interfaces de usuario como iconos, listas de elementos
u objetos en un mapa 2D, y pueden manipularlos por selección, arrastre o hablando con ellos. El
diseñador de interfaces de usuario identifica y especifica estos elementos actor por actor,
recorriendo todos los casos de uso a los que el actor puede acceder, e identificando los elementos
apropiados de la interfaz de usuario para cada caso de uso. Un único elemento de interfaz de usuario
puede intervenir en muchos casos de uso, desempeñando un papel diferente en cada uno. Así, los
elementos de la interfaz de usuarios pueden diseñarse para jugar varios roles. Deberíamos
responder a las siguientes preguntas por cada actor:
¿Qué elementos de interfaz de usuario se necesitan para posibilitar el caso de uso?
¿Cómo deberían relacionarse unos con otros?
¿Cómo se utilizaran en los diferentes casos de uso?
¿Cuál debería ser su apariencia?
¿Cómo deberían manipularse?
Para determinar qué elementos de interfaz de usuario necesitan ser accesibles al actor en cada caso
de uso, podemos contestar las siguientes preguntas:
¿Qué clases de dominio, entidades del negocio o unidades de trabajo son adecuados
como elementos de la interfaz de usuario para cada caso de uso?
¿Con qué elementos de la interfaz de usuario va a trabajar el actor?
¿Qué acciones puede invocar el actor, y qué decisiones puede tomar?
¿Qué guía o información va a necesitar el actor antes de invocar cada acción de los casos
de uso?
¿Qué información debe proporcionar el actor al sistema?
¿Qué información debe proporcionar el sistema al actor?
¿Cuáles son los valores medios de todos los parámetros de entrada o salida? Por ejemplo,
¿Cuántas facturas manejarán habitualmente un actor durante una sesión y cuál es el saldo
medio de la cuenta? Necesitamos estimaciones aproximadas de estas cosas porque así se
optimizará la interfaz gráfica de usuario para ellas (incluso aunque tengamos que permitir
un rango suficientemente grande).
Una forma práctica de trabajo es representar los elementos de la interfaz de usuario mediante notas
adhesivas, pegadas en una pizarra, y ordenadas para ilustrar la apariencia de la interfaz de usuario.
Seguidamente, los diseñadores de interfaces de usuario describen cómo pueden utilizar los actores
estos elementos cuando trabajen con los caso de uso. La ventaja de utilizar notas adhesivas es que
pueden representar la cantidad necesario a de datos. Además, las notas adhesivas tampoco parecen
permanentes .es fácil moverlas o simplemente eliminarlas-, lo que hace que el usuario se sienta
cómodo proponiendo cambios.
87 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Actividades
1. Desarrollar el modelo de casos de uso para el siguiente sistema para una agencia de alquiler
de autos
Para la segunda etapa de este proyecto se van a incorporar, al sistema, facilidades para
hacer reservas telefónicas. En este caso, el Empleado de Atención al Público tomará los
datos del cliente, la fecha del alquiler, días por los que se va a alquilar y vehículo que reserva.
Una reserva puede ser cancelada con hasta 48 horas de anticipación. Los clientes que hagan
reservas y no retiren el alquiler, no podrán efectuar nuevas reservas ni alquileres.
Al final de cada jornada, el Encargado de Autos lanzara un proceso que analizase las reservas
para el próximo día y marque los autos que corresponda como reservados.
88 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Autoevaluación
1. Un requerimiento es:
2. Las diferencias entre un requerimiento funcional y no funciona son:
3. Los requerimientos se caracterizan por:
4. Cuando usaría las técnicas de entrevista y JAD
5. El modelo de casos de uso representa
6. El actor es
7. El caso de uso es
8. Un escenario de caso de uso es
9. Una precondición es
10. Una poscondición es
11. La diferencia entre flujo básico y flujo normal es
Exploración on-line
Sitio de Alistair Cockburn, sobre recursos e información de casos de uso
http://alistair.cockburn.us/
Referencias bibliográficas
IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
–Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
Jacobson,I., et al, (1993). Object-Oriented Software Engineering: A Use case Driven Approach.
USA. Addison Wesley.
Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos.
Segunda Edición. Madrid. Pearson Educación S.A.
Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial Pearson.
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
GLOSARIO
Actividad Es una unidad de trabajo que debe ser ejecutada en un proceso de desarrollo de
software.
Artefacto Es una pieza de información que es producida, modificada o usada en un proceso
de desarrollo de software.
Flujo de trabajo Es una secuencia de actividades que produce un resultado valioso, define una
lista de actividades, trabajadores y artefactos.
Metodología Es el conjunto de procedimientos, técnicas, herramientas, y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software
Modelo de análisis de negocios Describe la realización de los casos de uso del negocio
mediante la interacción de los trabajadores del negocio y las entidades del negocio.
Modelo de casos de uso Es un modelo que describe los requerimientos funcionales del
sistema en forma de casos de uso.
Modelo de casos de uso del negocio Es una representación de la forma en que la empresa
interactúa con su entorno.
Modelo de dominio Es un modelo conceptual que muestra clases conceptuales de objetos
significativos en un dominio de problema. Las clases conceptuales no muestran componentes
software, ni clases software, ni responsabilidades
Organización Sistema compuesto por un conjunto de personas, actividades y recursos,
distribuidas de alguna forma (generalmente en departamentos o funciones) con arreglo a
ciertas reglas de división del trabajo y comunicación que interactúan para producir bienes o
servicios
Proceso de desarrollo Es una guía acerca de las actividades y tareas necesarias para construir
un sistema de información.
Proceso de negocio Conjunto de actividades que toman uno o más imputs crean un outputs
de valor para el cliente.
RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de
software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de
desarrollo, es decir define quién hace qué, cuándo y cómo.
Trabajador Es un rol que debe ser realizada por una persona o equipo dentro de un proceso de
desarrollo de software..
Sistema de información Conjunto de componentes hardware, software, base de datos,
procedimientos y personas, que permiten capturar, procesar, almacenar y distribuir
información para una organización.
UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado
en una notación gráfica, que permite: especificar, construir, visualizar y documentar los
elementos de un sistema software, así como para modelar los procesos de negocios u otros
sistemas no software.
90 Sistema a Distancia
90
Análisis de Sistemas - Unidad V César Luza Montero
BIBLIOGRAFIA
1 Davenport, Thomas (1996). Innovación de Procesos: Reingeniería del trabajo a través de la
tecnología de la información. España. Díaz Santos.
2 Hammer, Michel y James Champy (1993), Reengineering the Corporation: A Manifesto for
Business Revolution. USA. Collins Business Essentials.
3 Harris, David (1996). Creating a Knowledge Centric Information Technology Environment. USA.
Editorial Harris Training & Consulting Services Inc.
4 IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering
Terminology –Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
5 Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
6 Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML.
Segunda edición. Madrid. Pearson Educación S.A.
7 Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos.
Mexico D.F. Prentice-Hall Hispanoamericana.
8 Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos.
Segunda Edición. Madrid. Pearson Educación S.A.
9 Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Información Gerencial. 8ª Ed. México
D.F. Pearson Educación.
10 Laudon, Jane y Kenneth (2006). Sistemas de información gerencial, Administración de la
empresa digital. México D.F. Pearson Educación- Prentice Hall.
11 Pressman , Roger S. (2002) Ingeniería de Software. Un enfoque práctico. 5ta.Ed. Mc Graw Hill,
España.
12 Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT.
Mexico D.F. Prentice Hall Hispanoamericana.
13 Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial
Pearson.
91 Sistema a Distancia
91