ManualTeoria calidad de software

Análisis y Diseño de Sistemas II - Teoría Administración y Sistemas

2

CARRERAS PROFESIONALES

CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA)

3

Í NDICE NDICE Presentación Red de contenidos Sesiones de aprendizaje

UNIDAD 1 TEMA 1

TEMA 2 TEMA 3 TEMA 4

TEMA 5 UNIDAD 2 TEMA 6

TEMA 7

TEMA 8

5 6

: Ingeniería de requisitos. El proceso de la ingeniería de requisitos. Gestión de los requisitos. : Pirámide de requisitos. Características de un buen requisito. : Gestión de Requisitos en RUP. Visión general de la Gestión de Requisitos en RUP. : Documentos – Atributos. Documentos de la Ingeniería de Requisitos. Atributos de los tipos de requisitos. : Trazabilidad de Requisitos.

7 13 17 20 26 33 34 71 72 81 88

: Repaso de Modelado del negocio y Captura de Requisitos. Modelado del negocio. Captura de requisitos. Captura de requisitos a partir del Modelado del Negocio. Estructurando el Modelo de casos de uso. Priorización de casos de uso. Análisis orientado a objetos. Modelo de análisis. Análisis de la Arquitectura. : Análisis de casos de uso.


99 100 105 108 109 112 125 128 129 137

CIBERTEC

4

TEMA 9 TEMA 10

Realizaciones de Análisis. : Análisis de clases. Tarjetas CRC (Clase – Responsabilidad – Colaboración). : Modelo conceptual.

Plantillas de documentos de la gestión de requisitos. Glosario.


143 156 158 168 183 198

CIBERTEC


5

PRESENTACIÓN Análisis y Diseño de Sistemas II pertenece a los cursos de línea formativa y se

dicta en la carrera de Administración y Sistemas. El curso imparte conocimientos relacionados el proceso de la gestión de ingeniería de requisitos y al análisis orientado a objetos del software aplicado en la metodología RUP. El manual para el curso ha sido diseñado bajo la modalidad de unidades de aprendizaje, las que se desarrollan durante semanas determinadas. En cada una de ellas, hallará los logros, que debe alcanzar al final de la unidad; el tema tratado, el cual será ampliamente desarrollado; y los contenidos, que debe desarrollar, es decir, los subtemas. Por último, encontrará las actividades que deberá desarrollar en cada sesión, que le permitirán reforzar lo aprendido en la clase. El curso es eminentemente práctico: consiste en un taller de desarrollo de proyectos de software con la metodología RUP. En primer lugar, se inicia con la comprensión de la ingeniería de requisitos, con los documentos y tipos de requisitos a utilizar, además de la gestión de cambios de los requisitos utilizando las vistas y matrices. Se concluye con la disciplina de análisis orientado a objetos que incluye el modelo de análisis, análisis de la arquitectura, análisis de casos de uso, análisis de clases y modelo conceptual. Durante el curso, con el apoyo del laboratorio, se utilizarán las herramientas Rational Requisite Pro y Rational Software Architect.


CIBERTEC

6

RED DE CONTENIDOS

Análisis y Diseño de Sistemas II

Ingeniería de requisitos

Proceso de la ingeniería de requisitos Pirámide de requisitos Gestión de requisitos según RUP Trazabilidad de requisitos

Análisis orientado a objetos

Modelo de análisis Arquitectura de análisis Análisis de casos de uso Análisis de clases Modelo conceptual


CIBERTEC


7

UNIDAD DE APRENDIZAJE

 TEMA

INGENIERÍA DE REQUISITOS



LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite Pro.

TEMARIO 1. Introducción a la Ingeniería de Requisitos 2. Proceso de Ingeniería de Requisitos 3. Gestión de los requisitos.

ACTIVIDADES PROPUESTAS 1. Los alumnos indican los factores que causan problemas a los proyectos de software conocidos como challenged project. 2. Los alumnos indican brevemente la gestión de los requisitos utilizando la herramienta Rational Requisite Pro.


CIBERTEC

!

1. INTRODUCCIÓN A LA INGENIERÍA DE REQUISITOS

En el proceso de desarrollo de un sistema, sea web o de escritorio, el equipo de desarrollo se enfrenta al problema de la identificación de los requisitos. La definición de las necesidades del sistema es un proceso complejo, pues en él hay que identificar los requisitos que el sistema debe cumplir para satisfacer las necesidades de los usuarios finales y de los clientes. Para realizar este proceso, no existe una única técnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado. Por el contrario, existe un conjunto de técnicas, cuyo uso proponen las diferentes metodologías para el desarrollo de aplicaciones y que en general, buscan en recopilar la mayor cantidad de requisitos correctos para así conformar una buena estructura que servirá de base para el desarrollo de un proyecto. Se debe tener en cuenta que la selección de las técnicas y el éxito de los resultados que se obtengan, depende en gran medida tanto del equipo de análisis y desarrollo, como de los propios clientes o usuarios participantes. La Ingeniería de Requisitos (IR) es un proceso que propone la utilización de técnicas repetibles y sistemáticas para asegurar la completitud, consistencia y relevancia de los requisitos de un sistema. Este proceso no sólo se realiza en las primeras etapas del desarrollo de un proyecto, sino que influye decisivamente en el resto del proceso de desarrollo y mantenimiento.

1.1. Antecedentes Las principales causas del surgimiento de la IR o gestión de requisitos, como algunos autores la denominan, fueron los resultados de las investigaciones realizadas por diversas entidades a raíz de la denominada "Crisis del Software1". Estos resultados brindaron interesantes pistas sobre dónde mejorar el trabajo durante el ciclo de desarrollo de software y por consiguiente reducir los fracasos y problemas. Algunas de las instituciones que realizaron informes y análisis estadísticos son los siguientes: GAO 2, cuyo personal analizó proyectos de desarrollo de software para el gobierno norteamericano; el ESPITI 3, que realizó investigaciones sobre los principales problemas en el desarrollo de software a nivel europeo, y cuyos resultados son muy similares a los obtenidos por The Standish Group4, indicando que los mayores problemas de proyectos de desarrollo en Estados Unidos están relacionados con la gestión de requisitos. La seriedad y el profesionalismo del grupo Standish lo convirtieron en un referente mundial sobre los factores que inciden en el éxito o fracaso de los proyectos de TI, exponiendo sus análisis periódicas desde 1994 en "The CHAOS Report5". 1

Crisis del software es un término acuñado al hecho de que muchos desarrollos de software no han concluido, por motivos diversos, satisfactoriamente. 2 Government Account Office - Oficina de Contabilidad del Gobierno de EEUU. 3 European Software Process Improvement Training Initiative. 4 The Standish Group es un grupo consultor, fundado en 1985 por un grupo de profesionales de West Yarmouth, Massachussets. Su visión es obtener información de los proyectos fallidos de TI. Su objetivo es encontrar las causas de los problemas y fracasos de proyectos TI. 5 The CHAOS Report presenta informes de los resultados de encuestas que The Standish Group realiza a los responsables de proyectos de desarrollo de software.


CIBERTEC


"

A continuación se exponen las circunstancias que han convencido a la gran parte de la comunidad de la ingeniería del software de la necesidad, cada vez mayor, de una ingeniería de requisitos. En 1979, GAO realizó un estudio seleccionando nueve proyectos de desarrollo de software para el gobierno norteamericano cuyos contratos sumaban una cantidad total de $ 6,800.000. De esta cantidad, sólo $ 119,000 correspondían a un proyecto que se había utilizado tal como se había entregado. Dicho proyecto fue desarrollado en COBOL, por lo que era un problema relativamente simple cuyos requisitos eran comprendidos por clientes y desarrolladores y que además no cambiaron durante el desarrollo. El resto de los $ 6.8 millones se distribuyeron como puede verse en la figura 1.1, en la que puede destacarse el enorme porcentaje de dinero invertido en proyectos cancelados o no satisfactorios.

Fuente: Informe de GAO - 1979.

Figura 1.1. Resultado del informe de GAO (1979) Después de 15 años, el estudio que el grupo Standish realizó en 1994 fue mucho más amplio y significativo que el del GAO. El grupo consultor realizó encuestas a directores de proyectos de TI sobre la situación del desarrollo de software y sus principales problemas en Estados Unidos. Los resultados de estos informes muestran que casi un tercio de los proyectos de desarrollo de software se cancelan durante su desarrollo y que más del 50 % presenta graves desviaciones respecto a plazos y presupuestos iniciales. Los resultados generales, que pueden verse en la figura 1.2, si se compara con los de GAO, presentan una mejora en los proyectos que se entregan cumpliendo todos sus requisitos, 2% frente al 16.2%, pero empeoran ligeramente respecto a los que se abandonan durante el desarrollo, 28.7% frente a 31.1%. Sin incluir al 16.2% de los proyectos terminados correctamente, la media del gasto final fue del 189% del presupuesto original, el tiempo necesario para su realización del 222% del plazo original y se cumplieron una media del 61% de los requisitos iniciales; cifras que se dieron tanto en pequeñas como en grandes compañías.


CIBERTEC

#

Fuente: Informe CHAOS por The Standish Group [TSG 199!.

Figura 1.2. Resultado del informe CHAOS (1994) En este sentido, el grupo consultor citado clasifica los proyectos en tres categorías: Proyectos exitosos (successful): Aquellos que son completados a tiempo y, según el presupuesto, con todas las características y funcionalidades especificadas inicialmente. Proyectos con desafíos o problemas (challenged): Aquellos completados y en operación pero con retrasos de implementación por encima del presupuesto y/o con menos funcionalidades de las requeridas inicialmente. Proyectos con fracasos (impaired): Aquellos proyectos cancelados en algún momento durante el ciclo de desarrollo. •

•

•

Por otro lado, los directores de los proyectos que participaron en el estudio indicaron que, en su opinión, los tres principales factores de éxito eran los siguientes: Implicación de los usuarios Apoyo de los directivos Enunciado claro de los requisitos.

• • •

Mientras que los tres principales factores de fracaso: Falta de información por parte de los usuarios Especificaciones y requisitos incompletos Especificaciones y requisitos cambiantes.

• • •

Estas mismas causas de fracaso son, también, las identificadas en un informe similar (el informe ESPITI) realizado en la Unión Europea en 1996. A continuación, los principales problemas que se identificaron: Los requisitos no reflejan las necesidades reales del cliente. Los requisitos son inconsistentes y/o incompletos. Es muy caro realizar cambios de requisitos, luego de haberlos acordados con el cliente. • • •


CIBERTEC




Estos informes ponen de manifiesto el hecho de que, a pesar de que las herramientas para construir software han evolucionado enormemente, se sigue produciendo software que no es satisfactorio para los clientes y usuarios. Esto indica que los principales problemas de la crisis del software residen en las primeras etapas del desarrollo, cuando hay que decidir las características del producto software a desarrollar; por lo que no es de extrañar que aquellos proyectos en los que no se determinan correctamente los requisitos y cambian frecuentemente durante el desarrollo, superen con creces el tiempo y presupuesto inicial.

1.2 Definición Existen varias definiciones acerca de la ingeniería de requisitos que nos proporcionan varios autores según su nivel de experiencia, sentido común o simplemente por su forma de ver los requisitos respecto al desarrollo de un determinado proyecto. En esta disciplina principalmente se identifican dos aspectos muy importantes: el primero que es el propósito del sistema que se va a desarrollar y el segundo, el contexto en el que será usado. En base a estas características, se citan algunas definiciones: Según IEEE6 •

Proceso de estudio de las necesidades de los usuarios con el objeto de llegar a una definición del sistema HW/SW.

Según Pamela Zave •

Rama de la ingeniería del software que trata con el establecimiento de los objetivos, funciones y restricciones de los sistemas software. Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer especificaciones precisas.

Según Barry Boehm Ingeniería de Requisitos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizará el sistema.

•

Según Pericles Loucopoulos •

Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y cooperativo de análisis del problema, documentando los resultados en una variedad de formatos y probando la exactitud del conocimiento adquirido.

Según Julio César Sampaio do Prado Leite •

6

Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requisitos.

IEEE, Institute of Electrical and Electronics Engineers.


CIBERTEC

2

1.3. Impacto de la ingeniería de requisitos en los proyectos Para entender el impacto de la IR en los proyectos de desarrollo veamos datos interesantes sobre la situación de dichos proyectos obtenidos del análisis realizado por The Standish Group publicados en The CHAOS Report desde 1994: Evolución de los resultados del análisis CHAOS Report 100% 50% 0%

1994

1996

1998

2000

2002

2004

2006

2009

Failed

31%

40%

28%

23%

15%

18%

19%

24%

Challenged

53%

33%

46%

49%

51%

53%

46%

44%

Successful

16%

27%

26%

28%

34%

29%

35%

32%

Successful

Challenged

Failed

Figura 1.3 - Evolución de los resultados del análisis CHAOS Report . En la figura se observa que a partir del año 2000 existe un incremento continuo del éxito de los proyectos frente al porcentaje de proyectos fracasados. Sin embargo, si nos fijamos en los porcentajes del último año, el 44% de proyectos challenged nos indica que seguimos teniendo problemas en la entrega de los productos. Las causas que provocan el fracaso de un proyecto TI son diversas, las mismas que deben ser gestionadas para minimizar su impacto en los proyectos. El grupo Standish logró identificar, los 10 componentes más importantes que hacen exitoso un proyecto y aquellos que llevan al fracaso. Estos componentes se muestran en la siguiente tabla.

1 2 3 4 5 6 7 8 9 10

Éxito

Fracaso

Usuarios involucrados Apoyo ejecutivo Requisitos claros

Requisitos incompletos No se involucra al usuario Falta de recursos

Planificación adecuada Expectativas realistas Hitos de proyectos pequeños Personal competente

Expectativas no realistas Falta de apoyo ejecutivo am!ios en requisitos y especificaciones Falta de planificación

Propiedad clara del proyecto #isión y o!jetivos claros Equipo de alto rendimiento y !ien orientado

"a no necesitan el sistema Falta de $estión de %& &ncompetencia tecnoló$ica

Tabla 1.1 – Factores de éxito y fracaso de proyectos de software


CIBERTEC


3

1.4. Importancia de la Ingeniería de Requisitos A continuación, se mencionan los principales beneficios que se obtienen de la ingeniería de requisitos. •

•

•

•

•

•

Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo es sumamente caro. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requisitos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.). Mejora la comunicación entre equipos: La especificación de requisitos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso. Evita rechazos de usuarios finales: La ingeniería de requisitos obliga al cliente a considerar sus requisitos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

2. EL PROCESO DE INGENIERÍA DE REQUISITOS

La meta del proceso de la IR es crear y mantener los documentos de requisitos del sistema. Según Ian Sommerville, este proceso se puede dividir en cuatro (4) grandes actividades: 1. Estudio de viabilidad, que corresponde a una evaluación si el sistema es útil para el negocio. 2. Obtención y análisis de requisitos, el cual consiste en el levantamiento de información de los requisitos. 3. Especificación de requisitos, que conlleva a la documentación de los requisitos obtenidos. 4. Validación de requisitos, que consiste en comprobar si los requisitos obtenidos cumplen las necesidades del usuario. La satisfacción de los usuarios (stakeholders) se considera la mejor métrica de la calidad de un sistema. La figura 1.4 ilustra la relación entre estas actividades y los documentos que se elaboran en cada una de ellas.


CIBERTEC

4

Estudio de viabilidad

Obtención y análisis de re uisitos Especificación de requisitos

Informe de viabilidad

Validación de requisitos Modelos del sistema Requisitos del sistema

Documento de requisitos

Figura 1.4 - Proceso de la Ingeniería de Requisitos Las actividades que se muestran para este proceso se refieren al descubrimiento, documentación y validación de requisitos. Sin embargo, en casi todos los sistemas los requisitos cambian. Las personas involucradas desarrollan una mejor comprensión de lo que quieren que haga el software; la organización que compra el sistema cambia; se hacen modificaciones a los sistemas hardware, software y al entorno organizacional. El proceso de gestionar estos cambios en los requisitos se denomina “Gestión de Requisitos”, tema que se abordará al final de esta sección.

2.1. Estudio de viabilidad Esta actividad debería realizarse si el equipo de desarrollo se enfrenta a un sistema nuevo. Consiste en realizar un informe para el equipo de desarrollo del proyecto y al usuario o cliente. En el informe se recomendará si merece o no la pena seguir con la IR y el proceso de desarrollo del sistema. El estudio de viabilidad es un estudio de corto plazo y orientado a resolver varias preguntas, tales como: 1. ¿Contribuye el sistema a los objetivos generales de la organización? 2. ¿Se puede implementar el sistema utilizando la tecnología actual y dentro de las restricciones de costos y tiempo? 3. ¿Puede integrarse el sistema con otros sistemas existentes en la organización? La interrogante si que el sistema contribuye a los objetivos del negocio es crítica, si no contribuye a estos objetivos, entonces no tiene un valor real en el negocio. Llevar a cabo el estudio de viabilidad, que normalmente lleva dos o tres semanas, comprende la evaluación y recopilación de la información, y la


CIBERTEC


5

redacción de informes. Esta fase identifica la información requerida para contestar las tres preguntas anteriores. Una vez que dicha información se ha identificado, se debería hablar con las fuentes de información, como los jefes de los departamentos donde se utilizará el sistema, los ingenieros de software que están familiarizados con el tipo de sistema propuesto, los expertos en tecnología y los usuarios finales del sistema; para descubrir las respuestas a estas preguntas.

2.2. Obtención y análisis de requisitos En esta actividad, el equipo de desarrollo entra en contacto con el usuario final o con el cliente para determinar el alcance del proyecto o del sistema a construir, además, de identificar cuáles son los servicios que prestará el sistema, su rendimiento, sus necesidades y restricciones, y los objetivos esperados. La obtención y análisis de requisitos pueden afectar a varias personas de la organización. El término stakeholder se utiliza para referirse a cualquier persona o grupo que se verá afectado por el sistema, directa o indirectamente. Entre los stakeholders se encuentran los usuarios finales que interactúan con el sistema, los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los gerentes del negocio, los expertos en el dominio del sistema y todos aquellos que puedan verse afectados por su instalación. Obtener y comprender los requisitos de los stakeholders es difícil por varias razones: 1. Los stakeholders a menudo no conocen lo que desean obtener del sistema, solo en términos muy generales; puede resultarles difícil expresar lo que quieren que haga el sistema o pueden hacer pedidos irreales debido a que no conocen el costo de sus peticiones. 2. Los stakeholders expresan los requisitos con sus propios términos, de forma natural y con un conocimiento implícito de su propio trabajo. Los ingenieros de requisitos, sin experiencia en el dominio del cliente, deben comprender estos requisitos. 3. Diferentes stakeholders tienen requisitos distintos, que pueden expresarlo de varias formas. Los ingenieros de requisitos tienen que considerar todas las fuentes potenciales de requisitos, y descubrir las concordancias y los conflictos. 4. Los factores políticos pueden influir en los requisitos. Por ejemplo, los directivos pueden solicitar requisitos específicos del sistema que incrementarán su influencia en la organización. 5. El entorno económico y de negocios en el que se lleva a cabo el análisis es dinámico. Inevitablemente, cambia durante el proceso de análisis. Por lo tanto, la importancia de ciertos requisitos pueden cambiar. Pueden emerger nuevos requisitos de nuevos stakeholders. Es imposible satisfacer completamente a todos los stakeholders. Es labor del ingeniero de requisitos, durante el proceso, organizar frecuentes negociaciones con ellos para llegar a acuerdos. De lo contrario, si algún stakeholder piensa que sus opiniones no se han considerado adecuadamente, deliberadamente puede intentar boicotear el proceso de IR. A continuación, se presenta una “plantilla de requisitos” o “tarjeta de requisitos” (inspirada en el libro de S. Robertson y J. Robertson “Mastering


CIBERTEC

6

the Requirements Process”, Addison-Wesley, 1999) que puede ser útil en proyectos reales. Varias de estas tarjetas, se pueden utilizar para recoger información relevante durante las primeras fases del proceso.

Tabla 1.2. Tarjeta de Requisitos La explicación de cada sección es como siguiente: Requisito #: Número que identifica a cada requisito Clasificación: Indica a qué parte del sistema afecta. Por ejemplo: pedidos, contabilidad, ventas, etc. Tipo: Funcional, no funcional Descripción: Una frase que describe el requisito y tipo “característica (feature). Razón: ¿Por qué es importante este requisito? Origen: ¿quién lo pide? Prioridad: Importancia del requisito. Puede valorarse de 0 a 3, por ejemplo. Dependencias: Otros requisitos de los que depende. Conflictos: Requisitos que, de alguna forma, lo contradicen. Referencias: Especificar qué otros documentos son necesarios para comprender el requisito. Historia: Historia de los cambios al requisito.

• •

• •

• • •

• • •

•

2.3. Especificación de requisitos En esta etapa se debe obtener un documento de especificación de requisitos (ERS, Especificación de Requisitos del Software ), en el cual se llega a definir de una forma completa, precisa y verificable cada uno de los requisitos o necesidades que debe satisfacer el sistema a desarrollar, además de sus respectivas restricciones (software, hardware). La diversidad de personas que forman parte de un proyecto software hace que sea necesario establecer un marco de terminología común. Por esta razón, son muchas las propuestas que abogan por desarrollar un glosario de términos en el que se recogen y definen los conceptos más relevantes y críticos para el sistema.

2.4. Validación de requisitos Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos define el sistema o proyecto. En esta etapa, solamente entran aquellos


CIBERTEC


7

requisitos que se mencionaron en la especificación de requerimientos de software. Pueden utilizarse, en conjunto o de forma individual, varias técnicas de validación de requisitos: 1. Revisiones de requisitos. Los requisitos son analizados sistemáticamente por un equipo de revisores. 2. Construcción de prototipos. Esta técnica muestra un modelo ejecutable del sistema a los usuarios. Éstos pueden experimentar con este modelo para ver si cumple sus necesidades reales. 3. Generación de casos de prueba. Los requisitos deben probarse, a menudo revela los problemas en los requisitos. Si una prueba es difícil o imposible de diseñar, significa que los requisitos serán difíciles de implementar y deberían ser considerados nuevamente. 4. Matrices de trazabilidad. Esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo. Es necesario ir viendo qué objetivos cubre cada requisito, de esta forma se podrán detectar inconsistencias u objetivos no cubiertos. En definitiva, la validación de requisitos realmente significa asegurarse de que el documento de requisitos represente una descripción clara del sistema, y es una verificación final de que los requisitos cubren las necesidades de los usuarios. La diferencia con el análisis es clara, pues mientras que en el análisis se trabaja sobre el boceto del documento de requisitos, en la validación se utiliza el documento final, lo que equivale a decir, los requisitos "depurados".

3. Gestión de los requisitos

Los requisitos cambian y esto persiste durante el proyecto. Estos son los siguientes cambios ocurren: • • • •

• • • •

Cambios tecnológicos Cambios en las estrategias o prioridades del negocio Modificaciones en leyes y/o regulaciones Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas Porque cambió el problema que se estaba resolviendo Porque los usuarios cambiaron su forma de pensar o sus percepciones Porque cambió el ambiente de negocios Porque cambió el mercado en el cual se desenvuelve el negocio.

Los cambios deben controlarse y documentarse. Hay que convivir con el cambio. Por lo tanto, es esencial planear posibles cambios a los requisitos cuando el sistema sea desarrollado y utilizado y este proceso se hace indispensable, más aún, cuando se trata de sistemas grandes. La gestión de requisitos es el conjunto de actividades que ayudan a identificar, controlar y seguir los requisitos y sus cambios en cualquier momento. Básicamente, consiste en planificar la gestión de requisitos y gestionar sus cambios. De este modo, se asegura la consistencia entre los requisitos y el sistema.


CIBERTEC

!

3.1. Planificación de la gestión de requisitos Esta primera etapa es esencial en el proceso de gestión de requisitos, pues como se mencionó anteriormente, la gestión de requisitos tiene un costo elevado. Para cada proyecto, la etapa de planificación establece el nivel de detalle necesario en la gestión de requisitos. Durante la etapa de gestión de requisitos, habrá que decidir sobre los siguientes aspectos: •

La identificación de requisitos

•

Un proceso de gestión del cambio

Políticas de rastreo o trazabilidad: Definen la relación entre requisitos y la de éstos y el diseño del sistema. 3.2. Gestión del cambio de los requisitos La gestión del cambio se debe aplicar a todos los cambios propuestos. La ventaja de ello es que se asegura que todos los cambios propuestos son tratados de forma consistente y todos los cambios en el documento de requisitos se hacen de forma controlada. •

ACTIVIDADES PROPUESTAS 1. Indique cuáles son los factores que causan problemas a los proyectos de software (Project challenged) según el reporte CHAOS del grupo Standish. 2. Investigue cómo la herramienta Rational Requisite Pro apoya en la gestión de Ingeniería de requerimientos. a) ¿Cómo se administran los proyectos? b) ¿Qué paquetes contiene el proyecto? c) ¿Qué documentos se pueden gestionar en la herramienta y con que editor de texto? d) ¿Qué tipos de requisitos podemos crear y efectuar su trazabilidad durante la gestión?


CIBERTEC


"

R$%&'$



La ingeniería de requisitos nace como respuesta a la crisis del software, debido a que de todos los problemas que se presentan en los proyectos de software indudablemente el principal motivo para esos costos y tiempos elevados es la falta de un adecuado manejo o gestión de requisitos.



El proceso de ingeniería de requisitos incluye un estudio de viabilidad, así como la obtención, análisis, especificación, validación y gestión de requisitos.



Los cambios en los negocios, organizacionales y técnicos inevitablemente conducen a cambios en los requisitos de un sistema software . La gestión de requisitos es el proceso de gestionar y controlar estos cambios.



El proceso de gestión de requisitos incluye la gestión de la planificación, en la cual se diseñan las políticas y procedimientos para la gestión de requisitos; y del cambio, en la que se analiza los cambios propuestos en los requisitos y se evalúa su impacto.



Si desea saber más acerca de estos temas, puede consultar los siguientes libros:  “INGENIERÍA

DEL SOFTWARE” de Ian Sommerville, 7ª edición. El capítulo 7 trata el proceso de la ingeniería de requisitos.



Además, puede consultar las siguientes páginas: 

http://www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf Aquí se expone los resultados del reporte CHAOS de 1994.



http://www.materiabiz.com/mbz/ityoperaciones/nota.vsp?nid=29672 Aquí encontrará el artículo “El 71 por ciento de los proyectos de sistemas fracasan. ¿Por qué?”. Escrito por Silvio Szostak, Profesor del Programa de Negocios y Tecnología de la Universidad Torcuato Di Tella, Buenos Aires. Este artículo describe los resultados del reporte CHAOS del 2004.



http://www.standishgroup.com/newsroom/chaos_2009.php En este link el grupo Standish expone un resumen del reporte CHAOS 2009.


CIBERTEC

2#


 TEMA

2 PIRÁMIDE DE REQUISITOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO 1. Pirámide de requisitos 2. Características de un buen requisito.

ACTIVIDADES PROPUESTAS 1. Los alumnos clasifican los requisitos de una lista propuesta según las categorías descritas en la pirámide de requisitos. 2. Los alumnos investigarán a cerca de los atributos de calidad, respecto a FURPS+. Luego, expondrán sus atributos FURPS+ respecto a su proyecto.


CIBERTEC


2

1. PIRÁMIDE DE REQUISITOS

Un requisito se define como una condición o capacidad a la que debe ajustarse el sistema que se construye para satisfacer un contrato, norma, especificación u otro documento formalmente impuesto. Dependiendo del formato, fuente y características comunes, los requisitos pueden dividirse en diferentes tipos. A continuación se indican los tipos de requisitos que son usados en los proyectos: Necesidades del stakeholder Características Casos de uso Requisitos suplementarios Casos de prueba Escenarios. • • • • • •

Estos tipos de requisitos pueden ser presentados en la forma de una pirámide, tal como se muestra en la Figura 2.1.

Figura 2.1 - Pirámide de Requisitos En el nivel superior están las necesidades de stakeholders. En los niveles inferiores, las características, casos de uso y requisitos suplementarios. Los diferentes niveles marcan el nivel de detalle, pues cuanto menor sea el nivel, la exigencia de detalle de un requisito será mayor. Por ejemplo, una necesidad de stakeholder podría ser: "Los datos deben ser persistentes." La característica puede refinar este requisito así: "El sistema debe utilizar una base de datos relacional." Y, en el nivel de requisito suplementario, es aún más específico: "El sistema debe usar el motor de base de datos Oracle 9i." Esto pone de manifiesto que cuanto más se avance a los niveles inferiores de la pirámide, más detallado será el requisito. Una de las mejores prácticas de gestión de requisitos es tener por lo menos dos niveles de abstracción de requisitos.


CIBERTEC

22

1.1. Necesidad del stakeholder Describe lo que el sistema debería hacer para mejorar o reducir el costo de un proceso de negocio, incrementar ganancias o alcanzar regulaciones y otras obligaciones. Es proporcionado por un stakeholder. Ejemplo: ID

Necesidad “Necesito notificar al jefe de soporte cuando una solicitud de soporte es iniciada” “Necesito asignar solicitudes de soporte a un ingeniero de soporte específico” “Necesito mantener informado al cliente del progreso de una solicitud de soporte”

STRQ1 STRQ2 STRQ3

Stakeholder Jefe de soporte Jefe de soporte Cliente

Tabla 2.1 - Ejemplo de Necesidades de stakeholders

1.2. Característica del sistema Es un servicio que el sistema provee para satisfacer una o más necesidades del afectado. Formulada por el analista del negocio. Están descritas en el documento Visión. Estos son algunos ejemplos: Descripción La solicitud de soporte El sistema funcionará FEAT1 pasará por una serie de orientado al trabajo en flujo etapas y asignaciones Un sistema de notificación Capacidad de notificación por de correo centralizado será FEAT2 e-mail utilizado por el flujo de trabajo Tabla 2.2 - Ejemplo de Características del sistema ID

Característica

1.3. Caso de uso Es la descripción del comportamiento del sistema en términos de secuencia de acciones entre el actor y el sistema. El formato de un caso de uso creado por el analista de sistemas y puede ser revisado por el usuario ó stakeholder. El propósito de un caso de uso es facilitar los acuerdos (contrato) entre los desarrolladores, clientes y usuarios acerca de lo que el sistema debe hacer. También es la base para las realizaciones de casos de uso , las cuales juegan un papel importante en las disciplinas de análisis y diseño. Los casos de uso son un buen camino para expresar los requisitos funcionales del sistema; por ello, son utilizados para representar las funcionalidades del sistema mediante un diagrama conocido como Diagrama de casos de uso , en el cual contiene actores (roles de usuarios), casos de uso (funcionalidades) y las relaciones entre ellos. Este diagrama se crea en la disciplina Captura de Requisitos. A continuación se muestra algunos ejemplos de casos de uso para un sistema de control de reservaciones y hospedaje de un hotel:


CIBERTEC


ID UC1

UC2

UC3

UC4

23

Descripción Este caso de uso permite Generar reserva de registrar la reserva de uno o habitaciones más habitaciones disponibles para un cliente que lo solicita. El caso de uso permite la disponibilidad de Consultar disponibilidad de consultar una habitación por algún habitaciones criterio de búsqueda: categoría, tipo y/o rango de precios. El caso de uso permite realizar la búsqueda de un cliente por Buscar clientes algún criterio de búsqueda: nombres, apellido paterno y/o apellido materno. El caso de uso permite mantener actualizado el registro de los clientes del hotel. De acuerdo a su Mantener clientes necesidad, el recepcionista puede agregar, actualizar y desactivar el registro de un cliente. Caso de Uso

Tabla 2.3 - Ejemplo de Casos de uso del sistema

1.4. Requisito suplementario También conocido como requisito de arquitectura e implementación o factores de calidad en el contexto de desarrollo de software. Son todos los requisitos no funcionales que no pueden ser expresados con casos de uso. Para capturar requisitos suplementarios se debe usar el enfoque sugerido por Peter Eeles7: •

• • • •

Crear una lista de categorías de los requisitos suplementarios (según FURPS+, por ejemplo). Crear preguntas para cada categoría. Explicar al cliente el impacto y costo de cada decisión. Capturar la respuesta del cliente a cada pregunta. Asignar prioridad y peso a cada requisito.

Por otro lado, estos tipos de requisitos también se obtienen a partir de las características (features ) del sistema identificado en un nivel anterior de la pirámide de requisitos. Cabe aclarar que existen varios tipos de clasificaciones para los requisitos suplementarios, como McCall and Matsumoto (1984), la clasificación utilizada por ISO (1991), FURSP+ (1992 – adoptado por Rational Software). Nuestro curso sigue las categorías FURSP+, que se muestran en la siguiente tabla. Se consideran los requisitos Funcionalidad (Funcionality), Usabilidad 7

Arquitecto Ejecutivo de TI, trabajando en IBM Rational Software.


CIBERTEC

24

(Usability) Confiabilidad (Reliability), Rendimiento (Performance) y Soportabilidad (Supportability) en categorías. Además de requisitos Plus (+) (requerimientos de diseño, implementación, interfaz, operaciones, empaquetamiento y legales). Categoría Funcionalidad

Facilidad de uso

Confiabilidad

Rendimiento

De soporte

Sub categoría Accesibilidad Estética Consistencia de Interfaz usuario Ergonomía Fácil de usar Disponibilidad Robustez Precisión Recuperación Tolerancia a fallos Seguro Seguridad Corrección Rendimiento Tiempo de respuesta Tiempo de recuperación Tiempo de Inicio/Apagado Capacidad Utilización de recursos Comprobabilidad Adaptabilidad Mantenibilidad Configurabilidad Actualización Fácil de instalar Escalabilidad Portabilidad Reutilización Interoperabilidad Conformidad Fácil de reemplazar Mutabilidad Fácil de analizar Fácil de localizar

de

Restricciones de diseño Requisitos de Interfaz Documentación de usuario en línea y sistema de ayuda Requisitos legales, copyright y otros Tabla 2.4 - Clasificación de Requisitos Suplementarios – FURPS+


CIBERTEC


25

1.5. Caso de prueba Consiste en una especificación de entradas de pruebas, ejecución de condiciones y resultados esperados. Los casos de prueba pueden ir anexos a un Plan de Pruebas Integral. Los casos de prueba son creados para determinar si el requisito de un sistema, funcional o no funcional, es parcial o completamente satisfactorio. Algunos casos de prueba los puede crear el analista (desarrollador), otros los testers (encargados de las pruebas en calidad) y otros los clientes o usuarios (expertos del negocio). Los casos de prueba que se crean pueden ser utilizados para las pruebas manuales, así como para pruebas automatizadas utilizando herramientas, tales como IBM Rational Robot e IBM Rational Functional Tester.

1.6. Escenario Un escenario es una instancia de un caso de uso. Es una secuencia específica de acciones obtenidas del flujo de eventos de un caso de uso (flujo básico – subflujos – flujos alternativos). Por ejemplo, a continuación se muestra los posibles escenarios de un caso de uso que tiene cuatro flujos alternativos A1, A2, A3 y A4. Para encontrar un escenario, se necesita dibujar las posibles líneas que siguen un camino desde el flujo básico B.

Figura 2.2 - Escenarios de un caso de uso


CIBERTEC

26

2. CARACTERÍSTICAS DE UN BUEN REQUISITO

Un requisito debe cumplir varios criterios para ser considerado un "buen requisito". Las características que deben tener los requisitos son: •

• • • •

No ambiguo Verificable Claro Correcto Comprensible

• • • • •

Factible Independiente Atómico Necesario Abstracto.

Además de estos criterios para los requisitos individuales, tres criterios se aplican al conjunto de requisitos. El conjunto debe reunir las siguientes condiciones: Consistente No redundante Completo. • • •

A continuación, se muestran ejemplos de cada uno de las características de un buen requisito.

2.1. No ambiguo Un requisito no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición no debe causar confusiones al lector. A veces la ambigüedad se introduce por utilizar acrónimos o siglas sin definir: REQ1: El sistema será implementado utilizando ASP.

En este ejemplo ¿ASP se refiere a Active Server Pages o Application Service Provider? Para solucionar este problema, es mejor indicar el nombre completo y especificar el acrónimo entre paréntesis: REQ1: El sistema será implementado utilizando Active Server Pages (ASP).

A continuación otro ejemplo: REQ2: El sistema no aceptará contraseñas con más de 15 caracteres.

No está claro lo que el sistema se supone debe hacer: ¿El sistema no permitirá al usuario ingresar más de 15 caracteres? ¿El sistema truncará la cadena ingresada a 15 caracteres? ¿El sistema mostrará un mensaje de error si el usuario ingresa más de 15 caracteres? • • •

El enunciado correcto para este requisito debe ser así: REQ2: El sistema no aceptará las contraseñas de más de 15 caracteres. Si el usuario ingresa más de 15 caracteres, al digitar su contraseña, un mensaje de error le pedirá al usuario que debe corregirlo.

Una cierta ambigüedad puede ocurrir a través de la colocación de una palabra: REQ3: En la pantalla "Vuelos ", el usuario solo puede ver un registro.


CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 27

¿Esto significa que el usuario puede "ver solamente" y no eliminar o actualizar, o significa que el usuario puede “ver solo un registro”, no dos o tres? Una forma de solucionar el problema es volver a escribir el requisito desde el punto de vista del sistema: REQ3: En la pantalla "Vuelos ", el sistema mostrará un solo vuelo.

2.2. Verificable Un requisito es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas. Para que un requisito sea verificable, éste debe ser claro, preciso y no ambiguo. Algunas de estas palabras pueden hacer que un requisito no sea verificable: Algunos adjetivos: robusto, seguro, preciso, eficaz, eficiente, ampliable, flexible, fácil de mantener, confiable, amigable y adecuada. Algunos adverbios y frases adverbiales: rápido, seguro o de manera oportuna. Palabras o acrónimos no específicos: etc., y/o, TBD. Pronombres indefinidos: algunos, muchos, más, mucho, varios, cualquier, cualquiera, cualquier cosa, algunos, alguien, etc. Algunos verbos en infinitivo: gestionar, controlar´… Voz pasiva: el sujeto de la oración recibe la acción del verbo en lugar de su realización.

•

•

• •

• •

El requisito que se enuncia a continuación presenta un pronombre indefinido: REQ4: El sistema deberá resistir el uso concurrente por muchos usuarios.

La pregunta es ¿qué número debe ser considerado "muchos" -10, 100, 1000? Una mejor alternativa de enunciarlo: REQ4: El sistema deberá resistir el uso concurrente de a lo más 500 usuarios.

Otros ejemplos: REQ5: “La facilidad de búsqueda debería permitir al usuario encontrar una reserva basada en el apellido, día, etc.”

En este ejemplo, todos los criterios de búsqueda deberían ser listados explícitamente. El desarrollador no puede adivinar lo que significa “etc”. REQ6: “El código del aeropuerto debe ser ingresado.”

¿Quién ingresa el código, el sistema o el usuario? Forma correcta: REQ6: “El código del aeropuerto debe ser ingresado por el usuario“.

CIBERTEC


2!

2.3. Claro Un requisito es claro si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Por ejemplo esta es una frase compleja para un requisito: REQ7: A veces el usuario introducirá Código del aeropuerto, que el sistema comprenderá, pero, a veces, será sustituida por el nombre de la ciudad más cercana, por lo que el usuario no necesita saber cuál es el código del aeropuerto, y seguirá siendo entendido por el sistema.

Esta frase puede ser sustituida por una más sencilla: REQ7: El sistema deberá identificar el aeropuerto por el Código de Aeropuerto o el Nombre de Ciudad.

2.4. Correcto Si un requisito contiene hechos, éstos deben ser ciertos. Por ejemplo, este requisito no está escrito correctamente: REQ8: El sistema deberá aplicar descuentos en las planillas de los trabajadores (incluyendo el 18% de los aportes del sistema de pensiones).

El porcentaje de aportación depende de la entidad administradora de fondos de pensiones, por lo que la cifra indicada del 18% es incorrecta.

2.5. Comprensible Los requisitos deberían ser gramaticalmente correctos y escritos en un estilo consistente. Un estándar de convenciones debe ser utilizada. Tal es así que la palabra "deberá" se debe utilizar en lugar de "podrá", "debe", o "puede".

2.6. Factible El requisito debería ser factible dentro de las limitaciones existentes, tales como tiempo, dinero y recursos disponibles: REQ9: El sistema tendrá una interfaz de lenguaje natural que comprenderá comandos dados en el idioma Inglés.

Este requisito puede no ser factible en un corto lapso de tiempo de desarrollo (traducir un comando).

2.7. Independiente Para entender un requisito, no debería haber necesidad de conocer a ningún otro requisito: REQ10: La lista de vuelos disponibles incluirá el números de vuelo, hora de salida y tiempo de llegada del vuelo. REQ11: Esta debería ser ordenado por precio.

La palabra "Esta" en la segunda frase se refiere al requisito anterior. Sin embargo, si se cambia el orden de los requisitos, el REQ11no será comprensible. CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 2"

2.8. Atómico El requisito debe contener un elemento de trazabilidad individual: REQ12: El sistema deberá proporcionar la posibilidad de reservar el vuelo, comprar un ticket, reservar una habitación de hotel, reservar un auto, y proporcionar información sobre lugares de interés.

Este requisito se compone de cinco requisitos atómicos, lo que hace muy difícil la trazabilidad. Las oraciones que incluyen las palabras "y" o "pero" debería revisarse para ver si se puede romper en varios requisitos atómicos. Lo correcto sería:

REQ12: El sistema deberá proporcionar la posibilidad de reservar el vuelo. REQ13: El sistema deberá permitir comprar un ticket. REQ14: El sistema deberá proporcionar la opción de reservar una habitación de hotel. REQ15: El sistema deberá permitir reservar un auto. REQ16: El sistema deberá proporcionar información sobre lugares de interés.

2.9. Necesario Un requisito es necesario si su omisión provoca una deficiencia en el sistema a construir, y, además, su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Por ejemplo, el siguiente requisito debe ser removido porque no proporciona ninguna información adicional de lo que el sistema debe hacer: REQ17: Todos los requisitos especificados en el documento Visión deberían ser implementados y probados.

2.10. Abstracto Los requisitos no deben contener información innecesaria de diseño e implementación: REQ18: La información del sistema deberá ser almacenada en un archivo de texto.

En el ejemplo, cómo se almacena la información, es transparente para el usuario y debe ser decisión del diseñador o del arquitecto.

2.11. Consistente Un requisito es consistente si no es contradictorio con otro requisito. Por ejemplo puede darse el caso en que dos requisitos utilicen términos diferentes para un mismo concepto: REQ19: El sistema deberá permitir reservar una habitación. REQ20: El sistema deberá permitir registrar el hospedaje a partir de una separación de habitación registrada.

CIBERTEC


3#

Para evitar esta situación conviene estandarizar términos. Entonces, los requisitos anteriores se escriben mejor así: REQ19: El sistema deberá permitir reservar una habitación. REQ20: El sistema deberá permitir registrar el hospedaje a partir de una reserva de habitación registrada.

Los enunciados siguientes muestran conflictos que pueden resolverse mediante el análisis de las condiciones en las que el requisito se lleva a cabo: REQ21: Las fechas deberán ser mostradas en el formato mm/dd/aaaa. REQ22: Las fechas deberán ser mostradas en el formato dd/mm/aaaa.

Aquí, si el REQ19 fue presentado por un usuario americano y el REQ20 por un usuario francés, los requisitos anteriores podrán ser escritos así: REQ21: Para los usuarios en los EE.UU., las fechas se muestran en el formato mm/dd/aaaa. REQ22: Para los usuarios en Francia, las fechas se muestran en el formato dd/mm/aaaa.

2.12. No redundante Cada requisito debe ser expresado una sola vez y no debe solaparse con otro requisito: REQ23: Un calendario estará disponible para ayudar a la entrada de la fecha de vuelo. REQ24: El sistema deberá mostrar un calendario pop-up para ingresar cualquier fecha.

En estos ejemplos es fácil darse cuenta que el primer requisito (en relación con la fecha, sólo del vuelo) es un subconjunto del segundo (en relación con cualquier fecha introducida por el usuario).

2.13. Completo Un requisito está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión sin necesidad de agregar otro requisito para su entendimiento.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 3

ACTIVIDADES PROPUESTAS De acuerdo a la pirámide de requisitos, a qué tipo de requisito corresponde cada uno de los siguientes enunciados: NOTA: Utilice STRQ, FEAT, UC o SUPL para indicar si se trata de una necesidad de stakeholder, característica del sistema, caso de uso o requisito suplementario respectivamente. R01. El sistema deberá garantizar que su despliegue se pueda realizar, ya sea en el lado del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bits sin que esto afecte el rendimiento del mismo. R02. El sistema deberá contar con un Manual Técnico de Referencia para la Aplicación, el cual estará orientado a profesionales capacitados en aspectos técnicos del área de sistemas. R03. La clave de los usuarios considerará las siguientes políticas: - Expirar según parametrización del sistema - Tener mínimo una longitud de 8 caracteres - Contener letras y números - No puede contener espacios - No pueden repetirse las 3 últimas contraseñas - No contendrá el nombre o apellido de la persona dueña del usuario R04. El código fuente del sistema deberá cumplir con el estándar de codificación definido en el documento “Estándares y Nomenclaturas de Código Fuente”. R05. El sistema utilizará el idioma castellano para los mensajes y textos en la pantalla. R06. El sistema será utilizado por clientes de todo el mundo. Adicionalmente, la Organización Pro-Turismo exige que para anunciar servicios en su portal, éstos deben estar provistos en español, inglés y portugués. Estos tres idiomas deben ser soportados por el producto desarrollado. R07. El sistema deberá permitir la creación, modificación, activación, desactivación y autorización de los roles de usuarios definidos. R08. El sistema deberá prever contingencias que pueden afectar la prestación estable y permanente del servicio. La siguiente es la lista de las contingencias que se deben tener en cuenta y se pueden considerar críticas: Sobrecarga del sistema por volumen de usuarios. Caída del sistema por sobrecarga de procesos. Caída del sistema por sobrecarga de transacciones. Caída del sistema por volumen de datos excedido en la base de datos. • • • •

R09. El sistema deberá contar con el manual de FAQ (Frequent Asked Questions), en línea e impreso, que es un resumen con las respuestas a las preguntas más frecuentes que se hacen los usuarios. R10. El sistema deberá utilizar una base de datos relacional Oracle.

CIBERTEC


32

R$%&'$ 

La pirámide de requisitos muestra una jerarquía de requisitos de acuerdo al nivel de detalle en que se expresan. En los niveles inferiores de la pirámide se encuentran los requisitos con mayor nivel de detalle.



Los requisitos suplementarios son todos los requisitos que no pueden ser expresados con casos de uso.



Un requisito debe presentar las características de un "buen requisito".



Si desea saber más acerca de estos temas, puede consultar el siguiente libro:  “REQUIREMENTS

MANAGEMENT USING IBM RATIONAL REQUISITE PRO” de Peter Zielczynski. El primer capítulo trata la gestión de requisitos, el cual empieza con la descripción de la pirámide de requisitos y características de un buen requisito y termina con una descripción breve del proceso de gestión de requisitos.



Además, puede consultar las siguientes páginas. 

http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html Este artículo ilustra un método formal de derivación de casos de prueba funcional de casos de uso, incluyendo cómo crear un caso de uso, derivar todos los escenarios, y crear casos de prueba razonable, así como el uso de IBM Rational Requisite Pro para la trazabilidad de los casos de uso con escenarios y casos de prueba.




 TEMA

3 GESTIÓN DE REQUISITOS EN RUP LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO 1. Visión General de la Gestión de Requisitos en RUP.

ACTIVIDADES PROPUESTAS 1. Los alumnos, a partir de una lista de necesidades de stakeholder (NEEDS), crean las características del sistema (FEATURES ) indicando las estrategias de transformación utilizadas. 2. Los alumnos crearán una entrevista o cuestionario para capturar los requisitos, por parte de los stakeholders o usuarios. 3. Los alumnos, a partir de una especificación de caso de uso de su proyecto crean los casos de prueba.

CIBERTEC


34

1. VISIÓN GENERAL DE LA GESTIÓN DE REQUISITOS EN RUP

En RUP, una descripción simplificada del proceso de gestión de requisitos contiene los siguientes pasos: • • • • • • • •

Establecimiento de un plan de gestión de requisitos Captura de requisitos Desarrollo del documento Visión Creación de casos de uso Especificación suplementaria Creación de casos de prueba de casos de uso Creación de casos de prueba de la especificación suplementaria Diseño del sistema.

Los siguientes tipos de documentos se utilizan comúnmente en la gestión de requisitos: •

•

•

•

•

•

•

•

Plan de Gestión de Requisitos. Este documento establece los lineamientos para el establecimiento de los documentos de requisitos, tipos, características, y la trazabilidad con el fin de gestionar los requisitos del proyecto. Peticiones de los stakeholders. En este documento se especifican las necesidades de los stakeholders. Visión. Este documento da la visión total del sistema: principales características, necesidades de los stakeholders y servicios esenciales proporcionados. Glosario. Es importante que todos los stakeholders utilicen términos consistentes para expresar sus necesidades. El glosario es una herramienta para capturar y definir los términos utilizados en el proyecto. Especificación de casos de uso. Las especificaciones de casos de uso sirven como un formato para expresar el flujo de eventos de los requisitos funcionales. Un caso de uso es una secuencia de acciones llevadas a cabo por un sistema que produce un resultado observable (una salida de trabajo) de valor a un actor en particular. Especificación de requisitos suplementarios. Este documento captura los requisitos que no pueden vincularse directamente a cualquier caso de uso específico y, sobre todo si se trata de los requisitos no funcionales y restricciones de diseño. Especificación de requisitos de software. Este documento captura todos los requisitos del sistema software , es decir, contiene la lista de los requisitos funcionales y no funcionales. Plan de pruebas. Este documento describe el objetivo de las pruebas

(componentes, aplicaciones, sistemas), las etapas de la prueba, y los tipos de pruebas que serán abordados por este plan.

El primer paso, el plan de gestión de los requisitos, define los requisitos de la pirámide. En cada uno de los siguientes siete pasos, uno de los elementos de la pirámide es construido. En la tabla 3.1 se describe que tipos de requisitos y qué documentos se crean en cada paso. Como puede apreciar, el proceso, a partir del segundo paso, navega a través de la pirámide de arriba hacia abajo y de izquierda a derecha.



Paso 1

Descripción

Establecimiento de un plan de _______________ gestión de requisitos

2 3

Tipo de requisito

Documentos Plan de gestión de requisitos

Captura de requisitos

Necesidades de stakeholders

Peticiones de stakeholders

Desarrollo del documento Visión

Características

Visión, Glosario

Creación de casos de uso

Casos de uso, escenarios

Especificación de caso de uso

Especificación suplementaria

Requisitos suplementarios


Creación de casos de prueba de casos de uso

Casos de prueba

Plan de casos de prueba

Creación de casos de prueba de la especificación suplementaria

Casos de prueba

Plan de casos de prueba

Diseño del sistema

Diagrama de clases, diagramas de interacción

Diagramas UML

4 5

6

7 8

Tabla 3.1 - Requisitos y documentos creados en el proceso de gestión de requisitos según RUP La gestión de requisitos es un proceso iterativo. En una iteración típica, se pasa por todos los niveles de la pirámide. Incluso en la misma iteración, podemos retornar a pasos anteriores y repetir la actividad. Por ejemplo, durante la creación de un caso de prueba, podemos descubrir que aún nos falta información, y necesitamos más información de los stakeholders , por lo tanto retrocedemos un paso a la “captura de requisitos". Para mantener la integridad del modelo, es importante actualizar todos los requisitos afectados. En las iteraciones iniciales se da énfasis en los primeros pasos (nivel superior de la pirámide), y en las últimas iteraciones se pasa más tiempo en el nivel inferior de la pirámide. A continuación se describe brevemente estos pasos.

1.1. Establecimiento de un plan de gestión de requisitos Una de las primeras tareas en el proyecto es el desarrollo de un “Plan de Gestión de Requisitos” 1. Este plan describe el enfoque global de la gestión de requisitos en el proyecto. El documento da detalles de cómo los requisitos son creados, organizados, modificados y rastreados durante el ciclo de vida del proyecto. También se describen todos los tipos de requisitos y sus atributos utilizados en el proyecto. 1

En inglés es conocido como Requirements Management Plan (RMP).

CIBERTEC


36

¿Cuándo se crea el PGR (Plan de Gestión de Requisitos)? La PGR se puede crear a partir de una plantilla plantilla incluida incluida en RequisitePro. Sin embargo para crear un proyecto en RequisitePro tenemos que tomar decisiones documentadas documentadas en el PGR. Tomar en cuenta los siguientes aspectos: 1. Todas las decisiones decisiones sobre sobre el plan plan se documentan. documentan. 2. Un proyecto de RequisitePro RequisitePr o se crea sobre la base al PGR. 3. El PGR es creado a partir de una plantilla de RequisitePro. 4. El documento de Microsoft Word con el el PGR se importa en RequisitePro. RequisitePro. Aquí hay algunas preguntas que pueden ser contestadas en el plan: ¿Se utilizará alguna herramienta de gestión de requisitos? ¿Qué tipos tipos de requisitos serán rastreados en el proyecto? ¿Cuáles son los atributos de estos requisitos? ¿Dónde se crearán los los requisitos, requisitos, únicamente únicamente en una base base de datos o en documentos? ¿Entre qué requisitos necesitamos aplicar la trazabilidad? trazabilidad? ¿Qué documentos se requieren? ¿Qué requisitos y documentos se utilizarán utilizarán como un contrato contrato con los los clientes? Si una parte del proyecto se subcontrata, ¿qué ¿qué requisitos requisitos y documentos serán utilizados como un contrato con un vendedor? ¿Vamos a seguir la metodología RUP o alguna otra? ¿El cliente cliente necesita necesita documentos documentos específicos específicos para cumplir con con su proceso de desarrollo? ¿Cómo la gestión de cambios se llevará a cabo? Suponiendo Suponiendo que se utiliza utiliza RequisitePro, RequisitePro, ¿todo el sistema se almacenará almacenará en en un Proyecto RequisitePro o se crearán varios proyectos? ¿Qué proceso proceso garantizará garantizará que que todos los requisitos serán implementados implementados y verificados? ¿Para qué requisitos o vistas tenemos que generar informes?

• • • •

• • •

•

• •

• •

•

•

1.2. Captura de requisitos Este paso se concentra en capturar todas las necesidades de los stakeholders, stakeholders, utilizando una o más técnicas para recolectar requerimientos que se citan a continuación: •

•

•

•

Entrevistas: Son utilizadas para recopilar información de los interesados (stakeholders). Es conveniente la utilización de preguntas abiertas que no sugieran una determinada determinada respuesta. r espuesta. Cuestionarios: Un conjunto de preguntas preparadas para un gran grupo de stakeholde st akeholders. rs. Workshops (talleres): Reunión de stakeholders por un periodo intensivo. Son coordinados por un experto y a menudo se consigue alentar el compromiso de los participantes, fomentando el espíritu de grupo. Storyboards (guiones gráficos): Uso de una herramienta visual gráfica para mostrar el comportamiento del sistema. Son un conjunto de dibujos que representan las actividades del usuario. Son una especie de prototipos a papel.



•

•

•

•

•

Role-playing (Juego de roles): A cada miembro del grupo se le asigna un rol, usualmente uno de los usuarios. Sesiones de lluvias de ideas (brainstorming): Presentación de ideas durante una sesión breve e intensiva. Es eficaz porque las ideas más creativas y efectivas son el resultado de la combinación de ideas. Prototipos: Desarrollo de un prototipo para obtener retroalimentación. Consiste de una versión rápida del sistema o parte del mismo. Casos de uso: Descripción de la interacción del usuario con el sistema presentado como una secuencia de pasos. Análisis de documentos: Implica documentos: Implica un estudio de documentos que definen la razón de ser del proyecto, tales como planes de negocio, estudio de mercado, contratos, etc.

La técnica a usar dependerá de la naturaleza de los requisitos y el tipo de stakeholder. Es buena práctica especificar el resultado de esta tarea en el documento Peticiones de stakeholder 2 y almacenar cada uno de los requisitos en una base de datos. Esto permitirá asignarles varios atributos, como la prioridad o dificultad. También permite realizar el seguimiento de los requisitos y derivarlos a otros tipos de requisitos. Un punto importante que resaltar es que se debe tener cuidado de no perder o mal interpretar un requisito en este nivel, de lo contrario este problema se propagará durante todo el ciclo de desarrollo. Las necesidades de stakeholders no necesariamente tienen los atributos de un buen requisito mencionados en la sesión anterior; pero los requisitos que se encuentran en niveles inferiores a estas, sí los presentan. Este tipo de requisito se encuentra en el nivel superior de la pirámide, tal como se ilustra en la figura 3.1.

Figura 3.1 - Necesidades de stakeholders en la pirámide

1.3. Desarrollo del documento Visión El documento Visión es uno de documentos más importantes creados en la gestión de requisitos con RUP y el cual puede ser utilizado como un contrato entre los desarrolladores y clientes para los requisitos técnicos. 2

En inglés Stakeholder Requests

CIBERTEC


3!

Los propósitos del documento Visión son los siguientes: Definir los límites del del sistema Identificar restricciones restricciones impuestas impuestas en el sistema Conseguir acuerdos con los clientes sobre el alcance del proyecto Crear una base sobre la cual se definen los documentos: especificaciones de casos de uso y especificaciones de requisitos suplementarios. suplementarios. • • • •

La Visión es un repositorio de los requisititos del tipo “Característica” ( Feature ) y son listados en la sección “Características del Producto” del documento. Este tipo de requisitos se muestra en la pirámide en la figura 3.2.

Figura 3.2 - Características Características del sistema en la pirámide Las características se derivan de las necesidades de los stakeholders. Es importante no perder de vista qué característica fue derivada de las necesidades necesidades de stakeholders. Para crear uno o varios requisitos FEAT ( Features ) a partir de los requisitos STRQ (Stakeholders (Stakeholders request ) se aplica alguna de las siguientes estrategias de transformación: •

•

•

•

•

•

Copiar: Copiar: Si no se requieren cambios, el STRQ puede ser copiado a FEAT exactamente como está. Dividir: Dividir: Si el requisito no es atómico, podemos dividirlo en dos o más requisitos. Aclaración: Aclaración Aclaración: Aclaración o explicación, se puede aplicar cuando el requisito inicial es poco claro o ambiguo. Cualificación: Cualificación: Logramos cualificar (cuantificar) mediante la adición de restricciones o condiciones al requisito. Puede ayudar a resolver las necesidades contradictorias. contradictorias. Combinación: Combinación: Si los requisitos son redundantes o se superponen se pueden combinar en un solo requisito. Generalización: Si Generalización: Si la necesidad no es abstracta, e incluye algunos detalles innecesarios, podemos aplicar la generalización.



•

•

•

•

•

Cancelación: A veces un requisito debe ser eliminado. Esto puede suceder cuando el requisito es no viable, innecesario, o incompatible con otro requisito. Completar: Si el conjunto de requisitos es incompleto, puede ser necesario añadir requisitos en esta etapa. Corrección: Corrección puede significar una nueva redacción del requisito para corregir la gramática, ortografía o puntuación; o cambiar una parte de la necesidad que no es cierta. Unificación: Los requisitos que usan un vocabulario inconsistente pueden ser unificados (estandarizados). Adición de detalles: Si el requisito no es lo suficientemente preciso, podemos añadir más detalles. Esta técnica se utiliza a menudo para obtener requisitos verificables de los que no han sido especificados como tal. Una vez creados los requisitos del tipo características (FEAT), se debe especificar sus atributos. Los atributos son las propiedades de un requisito: Ayudan a organizar y analizar los requisitos del proyecto. Se pueden crear reglas para decidir, en base a los atributos, cuáles de los requisitos se implementarán en la siguiente iteración, fase o lanzamiento ( release ). A continuación, se indican los atributos que usualmente se asignan a los tipos de requisitos FEAT: •

•

•

•

•

•

• • •

• • • •

Prioridad: generalmente se usa para determinar el orden de implementación. Estado: seguimiento del progreso del desarrollo del requisito: propuesto, aprobado, incorporado y validado. Dificultad: lo difícil que puede ser la implementación de este requisito, los valores por defecto son de alta, media y baja. Estabilidad: la probabilidad de que el requisito no va a cambiar durante el proyecto. Riesgo: la probabilidad de resultados relacionados con este requisito: problemas con su implementación, incumplimiento de los plazos, etc. Planificación de la iteración: por ejemplo, E1-la primera iteración en la fase de elaboración. Iteración actual. Origen: fuente del requisito. Nombre del contacto: normalmente la persona responsable de este requisito. Mejora de Requisito. Defecto. Autor. Localización: documento en el que el que se encuentra.

Aparte de los atributos enunciados en la lista anterior, el equipo de desarrollo puede agregar otros atributos si así lo prefiere. Por ejemplo, el atributo Importancia, el cual incluye los valores: obligatorio y deseable. En situaciones extremas, múltiples atributos pueden almacenar estos valores de importancia, los cuales no son los mismos que prioridad, porque la importancia según el usuario puede no ser la misma importancia según el gerente del proyecto.

CIBERTEC


4#

1.4. Creación de casos de uso Los requisitos funcionales son mejor descritos en forma de casos de uso. Ellos son derivados de características del sistema y a partir de los casos de uso se derivan sus escenarios, tal como se ilustra en la figura 3.3.

Figura 3.3 - Casos de uso y sus escenarios en la pirámide El propósito de los casos de uso es facilitar acuerdos entre desarrolladores, clientes y usuarios acerca de lo que el sistema debe hacer. De este modo, un caso de uso puede ser usado como un contrato entre los desarrolladores y clientes. Este también es la base para las realizaciones de casos de uso, los cuales juegan un papel importante en análisis y diseño; implementación y casos de prueba. Las características de casos de uso son las siguientes: • • • • • •

Son iniciados por un actor. Modelan una interacción entre el actor y el sistema. Describen una secuencia de acciones. Capturan requisitos funcionales. Proporcionan algún valor a un actor. Representan un completo y significativo flujo de eventos.

La creación de casos de uso incluye las siguientes actividades: 1. Encontrar actores 2. Encontrar casos de uso y detallarlos 3. Estructurar el modelo de casos de uso. 1.4.1. Encontrar actores En esta actividad se identifican a los actores a partir de los stakeholders. Un actor puede ser un rol de usuario o un sistema externo que recibe o entrega información. En algunos casos, representaremos al tiempo como actor para indicar que el caso de uso se inicia en un momento específico (Timer).



1.4.2. Encontrar casos de uso Los casos de uso se identifican a partir de las características especificadas en el paso anterior (desarrollo del documento Visión) y para cada actor identificado hasta el momento. Más casos de uso se pueden obtener, aparte de los derivados de las características, utilizando la técnica workshop con stakeholders. Una vez identificado los casos de uso se procede a describirlos mediante el documento Especificación de Caso de Uso. Por último, se crean diagramas de casos de uso para representar a los actores, casos de uso y las relaciones entre ellos. Estos diagramas se crean en un paquete denominado “Modelo de casos de uso”. Para pequeños sistemas, el modelo de casos de uso puede contener solo un diagrama de casos de uso; mientras que para grandes sistemas, se necesitará dividir el sistema en varios diagramas. No existen reglas estrictas acerca de cómo el modelo debería dividirse. A continuación se indican algunas opciones de agrupación: Todos los casos de uso iniciado por el mismo actor o grupo de actores. Los casos de uso relacionados con el mismo tipo de tareas. Los casos de uso relacionados para dar soporte a un proceso de negocio.

• • •

1.4.3. Estructurar el modelo de casos de uso Después de crear el modelo de casos de uso inicial, se procede a estructurarlo. El objetivo principal de la estructuración del modelo es eliminar redundancias, hacer que los casos de uso sean más fáciles de entender y mantener. En primer lugar, hay que analizar los casos de uso y encontrar las partes de los flujos que contengan pasos similares. Luego podemos aplicar algunos de los tres tipos de relaciones entre casos de uso: •

•

•

CIBERTEC

Incluye / Inclusión: Para representar que un caso de uso incluye el comportamiento de otro. Extend / Ampliar: Para representar que un caso de uso extiende a otro caso de uso, el cual se activa cuando se da una condición. Generalización: Este tipo de relación se da tanto entre casos de uso como entre actores.


42

1.5. Especificación suplementaria La especificación suplementaria captura todos los requisitos que no pueden ser expresados en casos de uso. Sin embargo, esto no significa que todos los requisitos funcionales están en los casos de uso y que todos los requisitos no funcionales están en la Especificación suplementaria. La Especificación de casos de uso también contiene los requisitos no funcionales, si se aplican a un solo caso de uso. La Especificación suplementaria contiene todos los requisitos funcionales genéricos que no están asociadas con ningún caso de uso específico. La tabla 3.2 ilustra qué tipo de requisito se encuentra en un documento. Tipo de requisito Funcional

No Funcional

Especificación de caso de uso Flujo básico y flujos alternativos relacionados a un caso de uso específico. Especificación no funcional relacionada a un solo caso de uso.

Especificación suplementaria Requisitos funcionales relacionados a más de un caso de uso. Requisitos no funcionales relacionados a muchos casos de uso.

Tabla 3.2 - Requisitos en documentos de Especificación Recientemente, el nombre del artefacto fue cambiado en Rational Unified Process (RUP) de "Especificación Complementaria" al plural "Especificaciones suplementarias" para reflejar el hecho de que podemos usar más de un documento para capturar requisitos suplementarios. En la pirámide, los requisitos suplementarios están en el mismo nivel que los casos uso, como se muestra en la figura 3.4.

Figura 3.4 - Requisitos suplementarios en la pirámide



Muchas características que se definen en el documento Visión se convierten en requisitos suplementarios. Su inclusión en la Especificación Suplementaria proporciona una oportunidad para añadir más detalles y organizar los requisitos en la sección apropiada del documento, de acuerdo a la categoría FURPS+ a la que pertenecen. Un método consiste en ir a través de todas las características, identificar cuáles no se abordaron en los casos de uso, y traducirlos a requisitos suplementarios, los cuales son descritos con más detalle y más específicos. Muy a menudo no se necesitan cambios, y podemos usar la misma formulación como en las características.

1.6. Creación de casos de prueba de casos de uso En muchos proyectos la importancia de este paso no es reconocido. A menudo, a los testers se les da una impresión de Especificación de caso de uso y, a continuación, ellos realizan las pruebas manuales. Sin embargo, si descuidamos la creación formal de los casos de prueba, se puede terminar con una cobertura pobre de un universo de pruebas ejecutando muchas pruebas duplicadas.

Figura 3.5 - Casos de prueba para verificar casos de uso Cuando tengamos todos los escenarios derivados de un caso de uso, se crean los casos de prueba. Para ello, se sigue cuatro pasos: 1. Identificar las variables para cada paso del caso de uso. 2. Identificar opciones significativamente diferentes para cada variable. 3. Combinar opciones en estudio en los casos de prueba. 4. Asignar valores a las variables. Para esta parte analizaremos el Especificación de caso de uso “Registrar Reserva de Habitación”.

CIBERTEC


44

Especificación de caso de uso: Registrar Reserva de Habitación 1. Breve Descripción El caso de uso permite a la recepcionista de un hotel generar una reserva de habitación(es). Además de saber en qué estado se encuentra: reservado, ocupado o disponible. 2. Actor(es) Recepcionista 3. Flujo de Eventos 3.1. Flujo Básico 1. El Caso de uso se inicia cuando la Recepcionista selecciona la opción “Reservar Habitación” en la interfaz del menú principal. 2. El sistema muestra la interfaz RESERVA con los siguientes datos: Datos del cliente: Código, nombres y apellidos. Datos de la Reserva: Fecha de llegada, fecha de salida y cantidad de días a hospedarse. Datos de las habitaciones: Número de habitación, Tipo, Costo por día, Nombre del huésped de la Habitación y una opción para Agregar Habitación. Además incluye una cuadrícula que contiene la lista de todas las habitaciones reservadas y las opciones: Buscar Cliente, Agregar Cliente, Buscar Habitación, Eliminar Habitación, Grabar Reserva y Salir. 3. La Recepcionista selecciona “Buscar Cliente”. 4. El sistema Incluye el Caso de Uso Buscar Cliente. 5. El sistema muestra los datos del cliente. 6. La recepcionista ingresa la fecha de llegada y la fecha de salida. 7. El sistema calcula la cantidad de días. 8. La recepcionista solicita “Buscar Habitación” disponible. 9. El sistema Incluye el Caso de Uso Buscar Habitación. 10. El sistema muestra la habitación seleccionada. 11. La Recepcionista ingresa el nombre de la persona para la habitación seleccionada. 12. La Recepcionista selecciona agregar Habitación 13. El sistema calcula el pago de la habitación, el subtotal, el monto total y lo agrega a la cuadricula del detalle de la reserva. 14. Si la Recepcionista quiere seleccionar otra habitación, se repite del paso 7 al 12. 15. La Recepcionista selecciona “Grabar Reserva”. 16. El sistema autogenera un número de reserva. 17. El sistema graba la reserva con su detalle y actualiza la(s) disponibilidad(es) de la(s) habitación(es) en estado “Reservado”. 18. El sistema muestra el número de reserva y el MSG “Reserva generada” con el Nro. 99999”. 19. La recepcionista cierra la interfaz RESERVA y regresa a la interfaz del menú principal del sistema y finaliza el caso de uso. 3.2. Flujos Alternativos 1.1. Cliente no existe El sistema muestra el MSG: “Cliente no existe muestra” y ofrecerá la posibilidad de registrar al nuevo cliente. 1.1. Fechas incorrectas El sistema muestra el MSG: “Fechas incorrectas” y el caso de uso continúa en el paso 5. • •

•



9.1. Habitaciones no disponibles El sistema muestra el MSG: “No hay habitaciones disponibles” y finaliza el caso de uso. Eliminar Habitación de Cuadrícula La recepcionista selecciona una habitación y opta por la opción eliminar, luego, el sistema elimina de la cuadrícula la habitación selecciona y el caso de uso continúa. 4. Precondiciones 1. El Recepcionista está logeado en el sistema. 2. Lista de Clientes disponibles. 3. Lista de habitaciones disponibles. 5. Poscondiciones 1. En el sistema queda registrado la reserva. 2. Las disponibilidades de las habitaciones seleccionadas se actualizan en estado “Reservadas”. 6. Puntos de Extensión 1. En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo básico “Agregar Cliente”. 7. Prototipos 7.1. Interfaz RESERVA

CIBERTEC


46

A continuación, se describe con más detalle cada paso. 1.6.1. Identificar variables para cada paso del caso de uso En primer lugar, tenemos que identificar todas las variables de entrada en los pasos que lo requieran del escenario dado. Por ejemplo, si en algún paso, el usuario introduce un ID de usuario y contraseña, hay dos variables. Una variable es el ID de usuario, y el segundo es la contraseña. La variable puede ser también una selección que el usuario puede hacer (como la selección de un vuelo procedente de una lista). A continuación, se muestra las variables que se utilizan en los pasos del flujo básico del caso de uso “Reservar Habitación”: B5. La recepcionista ingresa la fecha de llegada y la fecha de salida (paso 5). Fecha de llegada de reserva • Fecha de salida de reserva • B10. La Recepcionista ingresa el nombre de la persona para la habitación seleccionada (paso 10). Nombre del huésped de la Habitación •

1.6.2. Identificar opciones significativamente diferentes para cada variable Las opciones son "significativamente diferentes" si se pueden activar diferentes comportamientos del sistema. Las siguientes directrices describen algunos casos específicos: •

Una opción puede ser considerada significativamente diferentes si:  Se activa un flujo de procesos diferentes (por lo general un flujo alternativo). Ejemplo: Ingreso de una contraseña no válida activará el Flujo Alternativo 2. 

Se activa un mensaje de error diferente. Ejemplo 1: Si un e-mail es demasiado largo, el mensaje será "Email no debe tener más de 50 caracteres." Ejemplo 2: Si un e-mail no contiene el @ (arroba), el mensaje será “E-mail no válido."



Se produce un aspecto diferente en la interfaz de usuario. Ejemplo: Si el método de pago es una tarjeta de crédito, la pantalla deberá mostrar los campos donde el usuario puede introducir el número de tarjeta de crédito, fecha de expiración y nombre del titular.



Se produce diferentes selecciones disponibles en las listas desplegables. Ejemplo: La pantalla de registro de cliente deberá contener listas desplegables para el País y Estado/Provincia. Provincia/Estado se rellena en función del país seleccionado: para EE.UU. deberá mostrar todos los estados, para Canadá todas las provincias, y para otros países sucederá lo mismo, es decir, dependiendo del país se cargarán o provincias o estados.



Es una entrada para una regla de negocio.



Ejemplo: Si el pedido se realiza después de las 6 p.m., y el usuario selecciona Envío Nocturno, un mensaje deberá informar al usuario de que el libro llegará pasado mañana.

Esta regla de negocio plantea dos opciones distintas:  Envío nocturno con pedidos antes de las 6 p.m.  Envío nocturno con pedidos después de las 6 p.m.



Es una condición límite. Ejemplo: La contraseña debe tener por lo menos seis caracteres.

En este caso se debe comprobar lo siguiente:  Contraseña con cinco caracteres.  Contraseña con seis caracteres.



Si está probando números, usted puede considerar las siguientes opciones significativamente diferentes:  Número regular, razonable desde el punto de vista de la aplicación.  Cero.  Número negativo.  Un número con dos decimales.  El mayor número que se puede escribir (por ejemplo, 99999999999999 – tantos nueves como puede ingresarse en el campo de texto).

A continuación se muestra algunas opciones de valor de prueba para todas las variables del flujo básico del caso de uso “Reservar Habitación”: B5. La recepcionista ingresa la fecha de llegada y la fecha de salida. Fecha de llegada de reserva •        •

Fecha futura válida ingresada manualmente Fecha futura válida ingresada de un calendario Fecha pasada Fecha actual 30 ó 31 de Febrero Ninguna fecha Válida con una año después de la actual.

Fecha de salida de reserva     



Fecha razonable ingresada manualmente Fecha razonable ingresada de un calendario Fecha pasada Fecha igual a la de llegada 30 ó 31 de Febrero Fecha anterior a la de llegada.

B10. La recepcionista ingresa el nombre de la persona para la habitación seleccionada. Nombre del huésped de la habitación •    

CIBERTEC

Nombre regular Nombre largo (máximo número de caracteres permitido) Nombre conteniendo un apóstrofe (tal como D’ Natali) Nombre con un carácter más del permitido


4!

  

Un carácter En blanco Dos palabras con un espacio entre ellos

1.6.3. Combinar opciones en estudio en los casos de prueba El paso anterior se identificaron todas las opciones significativamente diferentes para las pruebas. Ahora tenemos que combinarlas en la secuencia de pasos del caso de prueba. Una forma de hacerlo es crear una Matriz de Asignación de Casos de Prueba, tal como se ilustra en la tabla 3.3. Paso

Variable

T1

T2

T3

T4

T5

T6

Tabla 3.3 - Matriz de Asignación de Casos de Prueba Las filas de esta matriz contendrán todas las variables para todos los valores que requieran la entrada del usuario. En la primera columna se especificará el número del paso del flujo básico del caso de uso (obtenido de la Especificación de Caso de Uso), en la segunda columna se indicará el nombre de la variable, y las columnas restantes contendrán las pruebas (o tests en inglés) de los casos. Las pruebas pueden ser etiquetadas con T1 o T2 y así sucesivamente. Es necesario estimar cuántos casos de prueba cubrirá un escenario. Una estimación aproximada puede ser el mayor número de opciones significativamente diferentes para una variable. Si calcula de forma incorrecta, no hay problema porque se puede añadir o eliminar una columna, mientras se va llenando la matriz. Por lo general, de cinco a siete casos de prueba cubren escenarios típicos. Sin embargo, algunos casos específicos de aplicación requieren más casos de prueba. Tenemos que crear una matriz por escenario elegido para la prueba. La tabla 3.4 que se muestra, corresponde a la Matriz de Asignación de Casos de Prueba para el flujo básico del caso de uso “Reservar Habitación”:



Paso Variable Fecha de llegada de reserva B5 B5 Fecha de salida de reserva B10 Nombre del huésped de la habitación

4"

T1

T2

T3

T4

T5

T6

Tabla 3.4 - Matriz de Asignación de Casos de Prueba con todas las variables para el Caso de Uso “Registrar Reserva de Habitación” En la primera fila de cada variable, se ingresa todas las opciones que se necesita probar. En cada columna se ingresará una opción diferente, tal como se muestra en la tabla 10.5. Algunas de las opciones son incorrectas porque se necesita probar si el sistema responde con el mensaje de error adecuado o previene al usuario del ingreso incorrecto. Si para una variable existen más opciones que columnas de pruebas, entonces se crea otra fila para ingresar dichas variables, considerando una combinación razonable de opciones válidas, adicionales si se requiere, por cada opción incorrecta de la fila anterior. Por ejemplo, en la segunda fila para la variable “Fecha de llegada de reserva” se ingresaron opciones correctas para las pruebas T3, T5 y T6 que tienen opciones incorrectas en la fila anterior. En otros casos será necesario agregar más filas para completar las pruebas, tal como se hizo en la variable “Fecha de salida de reserva”.

CIBERTEC


5#

Paso B5

Variable Fecha de llegada de reserva

T1 Válida manualmente

T2 Válida de un calendario

T3 Fecha Pasada

T4 Fecha Actual

Válida con una año después de la actual

B5

Fecha de salida de reserva

Válida manualmente

Válida de un calendario

Fecha Pasada Válida con un año después de la actual Válida con una semana después de la fecha de llegada

B10

Nombre del huésped de la Regular habitación

Con máxima longitud

Con un apóstrofe

Igual a la de llegada

T5 Fecha Incorrecta

T6 Ninguna

Válida manualmente


Fecha Incorrecta

Ninguna

Válida manualmente


Válida de un calendario Mayor longitud de la permitida

Válida manualmente Un carácter

Dos palabras

Tabla 3.5 - Matriz con las opciones combinadas para las variables del Caso de Uso “Registrar Reserva de Habitación”


CIBERTEC

En blanco Regular

ANÁLISIS Y DISEÑO DE SISTEMAS I (TEORÍA) 5

1.6.4. Asignar valores a las variables En este paso, se dividen todos los casos de prueba de la Matriz creada en el paso anterior, creando una tabla separada para cada caso de prueba. Luego, se reemplaza las opciones definidas para cada variable con valores para realizar las pruebas. Además, se agregan más filas para las acciones, tales como clic sobre un botón o selección de item de lista desplegable. Por ejemplo para el caso de prueba T1 del caso de uso “Reservar Habitación” se crea la siguiente tabla. Note que se agregaron filas que contienen acciones en los pasos B2, B7, B10, B11 y B14. Paso

Variable

T1

Resultado esperado

B2

Buscar Cliente

Buscar cliente

Datos de un cliente

B5

Fecha de llegada de reserva

01-12-2009

Aceptar

B5

Fecha de salida de reserva

05-12-2009

B7

Buscar Habitación

Buscar Habitación

Cantidad de días de hospedaje Datos de una habitación disponible

B10

Nombre del huésped de la habitación

Miguel Vásquez

Aceptar

B11

Agregar Habitación

Agregar Habitación

B14

Grabar reserva

Grabar reserva

Resultado actual

Pasa/ Falla

Comentarios

Pago de la habitación (subtotal y monto total) en la cuadrícula de detalle de reservas Número de reserva generada

Tabla 3.6 - Caso de prueba con valores

1.7. Creación de casos de prueba de la especificación suplementaria No existe un criterio unificado para crear casos de prueba para requisitos suplementarios debido a que estos requisitos son de diferente naturaleza. A continuación se presenta los métodos de creación de casos de prueba para requisitos suplementarios: Ejecutar casos de prueba seleccionados en diferentes entornos. Agregando una comprobación adicional a todos los casos de uso. Comprobando y modificando casos de uso específicos. Realizar la acción descrita en el requisito. Listas de verificación. Pruebas de caja blanca. Pruebas automatizadas.

• • • • • • •

CIBERTEC



1.7.1. Ejecutar casos de prueba seleccionados en diferentes entornos Este método se utiliza para los requisitos suplementarios que requieren que la aplicación trabaje en diferentes entornos (plataformas) tales como browser de Internet, sistemas operativos, etc. Ejemplo: La interfaz basada en Web será ejecutado en Internet Explorer (versión 6.0 y versiones posteriores) y Netscape (versión 6 y posteriores).

Para realizar la prueba de este requisito se selecciona un escenario de un caso de prueba y luego se ejecuta en los diferentes navegadores: Internet Explorer y luego Netscape. La siguiente figura muestra este método. El escenario seleccionado es probado en diferentes entornos, por lo tanto se tiene un caso de prueba por entorno.

Figura 3.6. Casos de prueba para verificar requisitos suplementarios a partir de un escenario. 1.7.2. Agregando una verificación adicional a todos los casos de uso Muchos requisitos describen la apariencia o el comportamiento de algunos controles en la interfaz de usuario. Algunos ejemplos: • •

•

•

•

•

CIBERTEC

En cada página un botón Siguiente sugerirá un flujo predeterminado. En las pantallas de entrada de datos del sistema deberá indicar qué campos son obligatorios colocando una estrella junto al campo. El sistema deberá mostrar un calendario pop-up cuando se introduce una fecha. Campos de entrada múltiple en una sola página se alinearán verticalmente. Cuando se muestra un cuadro de diálogo, el foco del cursor deberá situarse en el primer campo de texto en el cuadro de diálogo. Por cada entrada no válida para el usuario, el sistema mostrará un mensaje de error significativo, explicando qué formato se espera para el dato ingresado.



•

•

•

Cantidades de moneda se calculan y se almacenan con una precisión de dos cifras decimales. Cada característica del sistema debe ser descrito en ayudas en línea, disponible en el menú en cada página. En las páginas que recogen los datos personales del usuario, habrá un enlace a una página describiendo la política de privacidad.

La mejor manera de incorporar las pruebas de estas características es agregando un control a todos los casos de prueba que se ha creado para casos de uso diferentes. Debido a que los casos de prueba derivados de casos de uso cubren cada posible pantalla de la aplicación, sólo puede agregar los controles pertinentes, durante su visita a cada una de las pantallas específicas. De esta forma, podemos estar seguros de que la función se verificó en todos los lugares en los que sea aplicable. En la figura 3.7 se muestra que todos los casos de prueba se actualizan con un requisito suplementario específico.

Figura 3.7. Verificación adicional a casos de prueba 1.7.3. Comprobando y modificando casos de uso específicos A pesar de que algunos requisitos se describen en las especificaciones suplementarias, están asociadas con algunos casos de uso específico. Esto puede ocurrir cuando dicha funcionalidad no está realmente relacionada con el caso de uso principal, pero desempeña un papel de apoyo o administrativos. Como ejemplo, podemos tener a los requisitos relacionados con la seguridad y acceso protegido con contraseña a algunas partes de la aplicación: •

•

CIBERTEC

Una contraseña será necesaria para acceder a las pantallas del administrador. Para presentar las ofertas, los proveedores de hotel, los proveedores de automóviles, y representantes de las aerolíneas deberán iniciar sesión en el sistema utilizando sus nombres de usuario y contraseñas.



La figura 3.8 muestra la actualización que se hace al caso de uso, y después se propaga a través de escenarios de y casos de prueba.

Figura 3.8 – Impacto de los requisitos suplementarios en otros tipos de requisitos relacionados 1.7.4. Realizar la acción descrita en el requisito Muy a menudo tenemos que realizar la acción descrita en el requisito debido a que en muchos casos, la tarea no requiere la creación de escenarios formales y casos de prueba. Por ejemplo: •

Un error de registro que contiene información sobre todos los errores críticos deberá ser accesible por el administrador del sistema a través de Internet, por lo que se puede comprobar de forma remota en cualquier momento.

Para probar este requisito, alguien que tenga el rol de administrador ingresará al sistema a través de Internet y comprobará si podrá acceder a un registro de errores. 1.7.5. Listas de verificación Algunos requisitos no necesitan ninguna prueba complicada, por lo que sólo puede comprobarse para ver si se han cumplido agregándolo en una lista de verificación. Por ejemplo: •

El sistema usará una base de datos de Oracle.

O se utiliza Oracle, o no - simplemente se marca en la lista de verificación. Algunos otros ejemplos de este tipo de pruebas, simplemente marcando una lista de verificación podrían incluir las siguientes: Todos los errores del sistema se registrarán y se pondrán a disposición del administrador. • Todas las transacciones (compra de tickets, asi como hacer una reserva, actualizar y anular una reserva) se registrarán y se pondrán a disposición del administrador. • El sistema usará una arquitectura JEE. •

CIBERTEC



Si la arquitectura requiere de un servidor de aplicaciones, se utilizará IBM WebSphere. • La Guía del administrador estará disponible en formato PDF. •

1.7.6. Pruebas de caja blanca Algunas pruebas deben hacerse con conocimiento del código fuente de la aplicación o alguna otra aplicación interna. Esto se denomina prueba de caja blanca. •

Al mostrar una lista de habitaciones disponibles, el sistema no puede perder ninguna habitación disponible para las fechas solicitadas.

Para comprobar este requisito, tenemos que acceder directamente a la base de datos y verificar el contenido de la tabla de disponibilidad de habitaciones, Luego se compara los resultados con la lista obtenida a través de nuestro sistema. Otros casos de prueba requieren comprobar si un algoritmo específico se ha aplicado correctamente: •

Para realizar la búsqueda de la lista de los vuelos de retorno deberá incluir el Algoritmo de ruta más corta de Dijkstra.

1.7.7. Pruebas automatizadas La prueba automatizada es muy útil en el control de requisitos de rendimiento y confiabilidad tales como los siguientes: El tiempo promedio de respuesta del sistema deberá ser inferior a dos segundos. • El sistema tendrá capacidad para 1000 vuelos reservados por minuto. • El sistema deberá adaptarse a 5000 usuarios concurrentes. • El sistema puede no estar disponible no más de un minuto por cada 24 horas. •

Para obtener un rendimiento y pruebas de fiabilidad, no es necesario automatizar todos los casos de prueba. Podemos seleccionar entre dos y tres casos de prueba. Vale la pena la selección de un caso de prueba que representa el escenario más utilizado y que contenga varias operaciones. Las herramientas de IBM, disponibles para realizar pruebas, son Rational Robot, Rational Test Manager, Test Manager, Rational Functional Tester y Rational performance Tester.

1.8. Diseño del sistema Los requisitos son la base para el diseño del sistema, el cual es realizado utilizando diagramas de UML. Muchas de las herramientas, tales como Rational Rose, Rational Software Architect, Rational Data Architect y Rational Software Modeler, pueden facilitar la creación de todos los diagramas necesarios. Un método es crear diagramas de interacción de los escenarios (comunicación y/o secuencia) y, al mismo tiempo, asignar funcionalidad a las

CIBERTEC



clases. La siguiente figura utiliza la pirámide de requisitos para representar esta actividad.

Figura 3.9 - Diseño de sistemas

CASO RESUELTO A continuación se describen las necesidades de stakeholders para una Agencia de viajes: Lista de Requerimientos enviados, vía correo, por un usuario de Francia: STRQ1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos. STRQ2: Las fechas deberán ser mostradas en formato dd/ mm / aaaa. STRQ3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios. STRQ4: La capacidad para cancelar una compra de boleto deberá estar disponible. STRQ5: El usuario será capaz de cancelar una reservación de un auto o un hotel. STRQ6: Los vuelos de ida y llegada serán ordenados por el menor número de paradas. STRQ7: El usuario será capaz de seleccionar los asientos. STRQ8: El sistema deberá tener una interfaz de lenguaje natural. STRQ9: El sistema mostrará un calendario emergente cuando se introduzca una fecha. STRQ10: El usuario deberá indicar si necesita un boleto solo de ida o ida y retorno, marcando la casilla de verificación. Lista de Requerimientos obtenidos, a través de un workshop, por un usuario local: STRQ11: Para los vuelos de llegadas y salientes, los usuarios podrán comparar los precios de otros aeropuertos cercanos. STRQ12: A veces un Usuario ingresará un código de aeropuerto, que el sistema entenderá, pero a veces la ciudad más cercana puede reemplazarlo,

CIBERTEC



entonces el Usuario no necesita saber el código del aeropuerto, y todavía no será entendida por el sistema. STRQ13: El sistema deberá tener una navegación clara. STRQ14: Si el usuario compra un boleto una vez, no será necesario repetir la misma información, como dirección o número de tarjeta de crédito. STRQ15: Pago por PayPal estará disponible. STRQ16: Las fechas se muestran en el formato dd / mm / aaaa. STRQ17: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. STRQ18: Será ordenado por precio. STRQ19: La comparación de precios de alquileres de autos de diferentes empresas se facilitará. STRQ20: Los precios de alquiler de autos deben mostrar todos los impuestos aplicables (incluido el 6% IVA del estado). STRQ21: Un calendario estará disponible para ayudar el ingreso de las fechas del vuelo. Lista de Requerimientos del Gerente de la Agencia de Viajes, identificados en una entrevista: STRQ22: El sistema deberá proporcionar la posibilidad de reservar el vuelo, comprar un boleto, reservar una habitación de hotel, reservar un auto, y proporcionar información acerca de las atracciones. STRQ23: El usuario será capaz de comprar un boleto en línea, sin necesidad de llamar a al Agente de viajes. STRQ24: El sistema deberá seguir las guías de implementación prevista en la cadena de nuestras agencias de viajes. STRQ25: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. STRQ26: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad adecuado para las aplicaciones comerciales. STRQ27: El sistema será desarrollado en tres meses. STRQ28: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. Lista de Requerimientos del Representante de Servicio al Cliente, capturados a partir de un Role Playing : STRQ29: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación en base al: apellido, ciudad de destino, fecha, etc. STRQ30: El Agente de Viajes podrá cambiar los detalles de la reservación o cancelar una reservación. Lista de Requerimientos del Gestor de Contenidos, capturados durante un Workshop : STRQ31: Mientras se esté ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML. STRQ32: La información de contenido debe ser almacenado en un archivo de texto.

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 5!

Lista de Requerimientos del Gestor de Contenidos, capturados durante un Workshop : STRQ33: El sistema deberá ser completamente probado solo en versiones específicas de los más populares navegadores. STRQ34: El sistema puede mostrar un mapa del aeropuerto. Lista de Requerimientos del Administrador de la Agencia de Viajes, capturados durante un Workshop : STRQ35: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reserva en base a apellidos y fecha. STRQ36: Todas las actividades en el Site se registran. STRQ37: Varios informes estarán disponibles. Lista de Requerimientos del Proveedor de Servicios de Hotel, identificados a partir de un cuestionario: STRQ38: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación. STRQ39: Mientras se proporcione información acerca del hotel, la siguiente información se mostrará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos, las formas de pago disponibles, etc. STRQ40: Al usuario se le ofrecerá ofertas de vuelos y hoteles. STRQ41: Sólo serán aceptados pagos con tarjeta de crédito. No se aceptan cheques, ni PayPal. A partir de la lista de necesidades de stakeholders para una Agencia de viajes, derive características del sistema (FEATURES ) e indique qué tipo de transformación utilizó;

Solución: No olvidar que para crear uno o varios requisitos FEAT a partir de los STRQ podemos aplicar algunas de las siguientes estrategias de transformación (derivaciones): •

• •

•

•

•

•

•

Copiar: Si no se requieren cambios, el STRQ puede ser copiado a FEAT exactamente como está. Dividir: Si el requisito no es atómico, podemos dividirlo en dos o más requisitos. Aclaración: Aclaración o explicación, se puede aplicar cuando el requisito inicial es poco claro o ambiguo. Cualificación: Logramos cualificar (cuantificar) mediante la adición de restricciones o condiciones al requisito. Puede ayudar a resolver las necesidades contradictorias. Combinación: Si los requisitos son redundantes o se superponen se pueden combinar en un solo requisito. Generalización: Si la necesidad no es abstracta, e incluye algunos detalles innecesarios, podemos aplicar la generalización. Cancelación: A veces un requisito debe ser eliminado. Esto puede suceder cuando el requisito es no viable, innecesario, o incompatible con otro requisito. Completar: Si el conjunto de requisitos es incompleto, puede ser necesario añadir requisitos en esta etapa.

CIBERTEC



•

•

•

Corrección: Este término puede significar una nueva redacción del requisito para corregir la gramática, ortografía o puntuación; o cambiar una parte de la necesidad que no es cierta. Unificación: Los requisitos que usan un vocabulario inconsistente pueden ser unificados (estandarizados). Adición de detalles: Si el requisito no es lo suficientemente preciso, podemos añadir más detalles. Esta técnica se utiliza a menudo para obtener requisitos verificables de los que no han sido especificados como tal.

STRQ1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos. Este requisito es redundante con STRQ11. Se pueden combinar en un solo requisito: FEAT1 El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos (para vuelo de ida y vuelo de llegada). STRQ2: Las fechas deberán ser mostradas en formato dd/mm/aaaa. Este requisito es inconsistente con STRQ 16, que pide al formato mm/dd/aaaa. El requisito STRQ2 vino por parte del Usuario francés y STRQ16 fue suministrada por el Usuario estaunidence. Los requisitos STRQ2 y STRQ16 fueron reemplazados por el siguiente requisito: FEAT2: Las fechas deberán ser mostradas de acuerdo al formato cargado en la configuración del navegador Web. STRQ3: En las pantallas de entrada de datos, el sistema indicará qué campos son obligatorios. En algún momento se tomará la decisión de aquellos campos obligatorios, que serán indicados como campos requeridos. Supongamos que queremos hacerlo ahora, entonces aplicamos la explicación para crear el requisito: FEAT3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios de ingresar colocando un asterisco cerca al campo. STRQ4: La capacidad para cancelar una compra de boleto deberá estar disponible. Por consistencia, es mejor usar construcciones estándares en requisitos, tales como "deberá" en vez de "debería". Usar diferentes palabras como "será", "hará ", "debería", y "podría" pueden ser erróneamente interpretados en los diferentes niveles de necesidad. (Por ejemplo, "se" puede sonar más fuerte que "deberá", y "se" puede sonar más fuerte que "debería". Es necesario una aclaración en cuanto a quién será capaz de cancelar la compra de los boletos (usuario, cliente representante o administrador) y en qué etapa del proceso es requerido: FEAT4: El usuario será capaz de cancelar la compra de un boleto en cualquier momento antes de la confirmación final de la compra. STRQ5: El usuario será capaz de cancelar una reservación de un auto o un hotel. El analista de sistemas decide si un requisito específico es atómico. En este caso, decidió que la cancelación de una reservación de un auto o de una habitación de hotel puede ser considerado el mismo requisito, entonces no hay la necesidad de dividir esto: FEAT5: El usuario será capaz de cancelar una reservación de un auto o un hotel.

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 6#

STRQ6: Los vuelos de ida y llegada serán ordenados por el menor número de paradas. Esta terminología es inconsistente con el STRQ11. El mismo concepto es llamado “Vuelo de retorno” en STRQ6 y “Vuelo de llegada” en STRQ11. Asumiremos que después de consultar hemos decidido usar el término “Vuelo de retorno”. Necesitamos retornar al FEAT1 para cambiar por consistencia: FEAT1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos (para vuelo de ida y vuelo de retorno). Porque tenemos que cambiar el FEAT1 para consistenciarlo con STRQ6, reescribiremos el STRQ6 en FEAT6: FEAT6: Los vuelos de ida y retorno deben ser ordenados por el menor número de paradas. Sin embargo, contradice al STRQ18, porque que los vuelos sean ordenados por precio. Podemos acomodar ambos requisitos en una característica: FEAT6: El usuario será capaz de seleccionar si los vuelos son ordenados por el menos número de paradas o por precio. Como usted puede ver, derivar características es un proceso iterativo, y algunos requisitos necesitan ser cambiados en poco tiempo mientras son consistentes y no redundantes. Como usted puede observar, derivar características es un proceso iterativo , y algunos requisitos, necesitan ser cambiados en poco tiempo, mientras sean consistentes y no redundantes .

STRQ7: El usuario será capaz de seleccionar los asientos. Para la unificación, cambiamos la "voluntad" a "se." Por la obligación de ser completamente independiente, tenemos que añadir alguna explicación: FEAT7: Durante la compra de un boleto de avión, el usuario será capaz de seleccionar los asientos. STRQ8: El sistema deberá tener una interfaz de lenguaje natural. A primera vista, este requisito es correcto. Sin embargo, después de analizar el alcance de las limitaciones del sistema y el tiempo, fue obvio que este requisito no era realista (factible). Es contradictorio con STRQ27, que pide que el sistema se desarrolle en tres meses. – Implementando una interfaz de lenguaje natural se tardaría más de tres meses. Este requisito se cancela, y el usuario que proporciona este requisito es notificado de la cancelación. STRQ9: El sistema mostrará un calendario emergente cuando se introduzca una fecha. Esto se superpone con STRQ21, que pide un calendario cuando la fecha del vuelo se ingrese. Debido al STRQ9 que es más genérico (menciona una fecha, que incluye una estancia en el hotel fecha o un alquiler de la fecha de coches), volveremos a escribir STRQ9 y cancelar STRQ21. Como aclaración, podemos explicar una lista de todas las fechas: FEAT8: El sistema mostrará un calendario emergente en cualquier fecha que se ingrese, tales como una fecha de vuelo, fechas de permanencia en el hotel, o la fecha del alquiler de un auto). STRQ10: El usuario deberá indicar si necesita un boleto solo de ida o ida y retorno, marcando la casilla de verificación.

CIBERTEC



Este requisito contiene el diseño innecesario. Detalles, como si se utiliza un botón o casilla de verificación, debe dejarse en manos del diseñador de la pantalla. En este caso, un botón de opción puede ser más apropiado porque las opciones son excluyentes. FEAT9: El usuario tendrá la oportunidad de indicar si necesita solo un boleto de ida o ida y retorno. STRQ11: Para los vuelos de llegadas y salientes, los usuarios podrán comparar los precios de otros aeropuertos cercanos. Esta solicitud se combina con FEAT1, por lo que puede ser cancelada. STRQ12: A veces un Usuario ingresará un código de aeropuerto, que el sistema entenderá, pero a veces la ciudad más cercana puede reemplazarlo, entonces el Usuario no necesita saber el código del aeropuerto, y todavía no será entendida por el sistema. Esta frase es complicada y poco clara. Podemos sustituirlo por uno más simple: FEAT10: El sistema deberá identificar el aeropuerto en base al código del aeropuerto o al nombre de la ciudad. STRQ13: El sistema deberá tener una navegación clara. Este requisito es vago y no lo suficientemente preciso, sin embargo puede ser probable. Dos características concretas se derivan: FEAT11: Separación por pestañas disponibles para la funcionalidad principal. FEAT12: En cada página un botón “Siguiente” sugiere el flujo pre determinado. STRQ14: Si el usuario compra un boleto una vez, no será necesario repetir la misma información, como dirección o número de tarjeta de crédito. En esta petición se aclara por adición "durante las transacciones futuras": FEAT13: Si el usuario compra un boleto de una vez, no será necesario repetir la misma información (tales como dirección o número de tarjeta de crédito) durante las transacciones futuras. STRQ15: Pago por PayPal estará disponible. Este requisito es contradictorio con STRQ41, que establece que PayPal no puede ser disponible. En este caso, por alguna razón el vendedor no puede proporcionar este servicio, es necesario anular el requisito del usuario. STRQ16: Las fechas se muestran en el formato dd / mm / aaaa. Este requisito fue incluido en FEAT2. STRQ17: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. No hay nada malo con esto, así que simplemente es re-escribir: FEAT14: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. STRQ18: Será ordenado por precio. La palabra "Será" se refiere al requisito anterior. Sin embargo, si el orden de los requisitos cambia, este requisito no será comprensible.

CIBERTEC



Para ser independiente, el requisito tendría que ser redactado como sigue: La lista de los vuelos disponibles deberá ser ordenada por precios. Sin embargo, ya se ha incluido este requisito en FEAT6. STRQ19: La comparación de precios de alquileres de autos de diferentes empresas se facilitará. Este requisito está bien. Sólo tenemos que eliminar la voz pasiva: FEAT15: El sistema deberá proporcionar la comparación de los precios de alquiler de autos de diferentes empresas. STRQ20: Los precios de alquiler de autos deben mostrar todos los impuestos aplicables (incluido el 6% IVA del estado). El impuesto varía según el estado, por lo que el % cifra es incorrecta. Podemos eliminar las palabras entre paréntesis, dejando el cálculo de los impuestos para los diseñadores: FEAT16: Los precios del alquiler de autos deben mostrar todos las Impuestos aplicables. STRQ21: Un calendario estará disponible para ayudar el ingreso de las fechas del vuelo. Este requisito se incorporó en FEAT8. STRQ22: El sistema deberá proporcionar la posibilidad de reservar el vuelo, compra un boleto, reservar una habitación de hotel, reservar un auto y proporcionar información acerca de las atracciones. Este requisito es una combinación de cinco requisitos atómicos, lo que hace trazabilidad muy difícil. Este requisito compuesto se dividirá en cinco requisitos atómicos: FEAT17: El sistema deberá proporcionar la oportunidad de reservar el vuelo. FEAT18: El sistema deberá proporcionar la oportunidad de comprar un boleto de avión. FEAT19: El sistema deberá proporcionar la oportunidad de reservar una habitación de hotel. FEAT20: El sistema deberá proporcionar la oportunidad de reservar un auto. FEAT21: El sistema deberá proporcionar información acerca las atracciones en lugares específicos. STRQ23: El usuario será capaz de comprar un boleto en línea, sin necesidad de llamar a al Agente de viajes. No hay nada malo aquí, así que podemos copiar el requisito. FEAT22: El usuario será el capaz de comprar un boleto en línea, sin necesidad de llamar al Agente de viajes. STRQ24: El sistema deberá seguir las guías de implementación prevista en la cadena de nuestras agencias de viajes. Este requisito no es claro, al menos que otro documento se adjunte, describiendo las directrices de implementación. O todas las pautas pueden ser listadas de forma explicita. Por ejemplo: FEAT23: El sistema utilizará la arquitectura JEE. FEAT24: Si la arquitectura requiere de un servidor de aplicaciones IBM WebSphere deberá utilizar.

CIBERTEC



FEAT25: Si el sistema requiere una base de datos. Oracle deberá utilizar. STRQ25: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. No hay nada malo aquí, así que podemos copiar el requisito. FEAT26: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. STRQ26: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad adecuado para las aplicaciones comerciales. Este requisito no es lo suficientemente precisa para ser probado. En algún momento tenemos que reemplazar con los requisitos detallados en cuanto a fiabilidad. Podemos hacer esto ahora, mientras creamos las características o podemos esperar hasta que creemos las especificaciones suplementarias de las características. Por ahora, mantenemos la exigencia como es: FEAT27: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad apropiado para las aplicaciones comerciales. STRQ27: El sistema será desarrollado en tres meses. Podemos añadir una explicación acerca de cuándo comienza este cálculo del tiempo. FEAT28: El sistema deberá ser desarrollado tres meses a partir de la fecha en que el cliente firme los Casos de Uso y las especificaciones suplementarias. STRQ28: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. Podemos copiar este requisito, porque no hay nada que corregir. FEAT29: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. STRQ29: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación sobre la base del apellido, ciudad de destino, fecha, etc. El "etc" no es lo suficientemente preciso. Después de confirmar con el solicitante de este requerimiento que no se requieren otros criterios de búsqueda, "etc" fue eliminado. FEAT30: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación sobre la base de siguiente: apellido, ciudad de destino y fecha. STRQ30: El Agente de Viajes podrá cambiar los detalles de la reservación o cancelar una reservación. Debido a que este requisito no es atómico, podemos dividirlo en dos: FEAT31: El Agente de Viajes será podrá cambiar los detalles de una reservación. FEAT32: El Agente de Viajes podrá de cancelar una reservación. STRQ31: Mientras se esté ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML.

CIBERTEC



Este requisito está bien, por lo que solo se copia: FEAT33: Mientras se esté ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML. STRQ32: La información de contenido debe ser almacenada en un archivo de texto. Cómo se almacenará la información, debe ser transparente para el usuario, y será decisición del diseñador o arquitecto. Este requisito puede ser cancelado. Esta sugerencia, sin embargo, puede ser pasada a consideración en el diseño. STRQ33: El sistema deberá ser completamente probado solo en versiones específicas de los más populares navegadores. Después de transmitir al cliente que no es realista poner a prueba el sistema en todos los navegadores disponibles, el cliente estuvo de acuerdo con limitar el requerimiento de las pruebas en los navegadores Internet Explorer y Netscape. FEAT34: El sistema deberá ser completamente probado en los siguientes navegadores: Internet Explorer y Netscape. STRQ34: El sistema puede mostrar un mapa del aeropuerto. Este requisito llegó del desarrollador, que no es un cliente ni un usuario. Después de comprobar con el cliente, se confirmó que este requerimiento es innecesario, por lo que se canceló. STRQ35: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reserva en base con apellidos y fecha. Debido a STRQ35 es un subconjunto de STRQ29, que se incorporó en FEAT30, cancelamos el STRQ35. STRQ36: Todas las actividades en el Site se registran. Agregamos algunos detalles y explicación: FEAT35: Todas las transacciones y los errores deberán ser registrados y estarán disponibles para el Administrador. STRQ37: Varios informes estarán disponibles. Este requisito es impreciso. Después de entrevistas adicionales, los detalles fueron añadidos: FEAT36: Los siguientes informes estarán disponibles para el Administrador: Una lista de todos los boletos de avión comprados en un período de tiempo determinado. Una lista de todas las reservas de autos en un período de tiempo determinado. Una lista de todas las reservas de habitaciones de hotel en un periodo de tiempo determinado. STRQ38: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación. Este requisito está bien, por lo que sólo se copia: FEAT37: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación.

CIBERTEC



STRQ39: Mientras se proporcione información acerca del hotel, la siguiente información se mostrará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos, las formas de pago disponibles, etc. El "etc" se elimina: FEAT38: Mientras se proporcione información acerca del hotel, la siguiente información se mostrará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos y las formas de pago disponibles. STRQ40: Al usuario se le ofrecerá ofertas de vuelos y hoteles. Alguna explicación se adiciona: FEAT39: Al usuario se le ofrecerá paquetes de ofertas que constan de vuelos y alojamiento en hoteles. STRQ41: Solo serán aceptados pagos con tarjeta de crédito. No se aceptan cheques, ni PayPal. Algunos cambios en la redacción para aclarar fueron aplicados: FEAT40: Durante el pago del boleto de avión, sólo se aceptará con tarjeta de crédito. Cheques y PayPal no serán aceptados. NOTA.- Una vez identificados las necesidades de stakeholders (STR) y las características (FEAT) para la Agencia de viajes, podemos crear los documentos “Necesidades del stakeholder” y “Visión del Producto” respectivamente en su sesión de laboratorio.

CIBERTEC



Caso Práctico A continuación, se detallan las necesidades del stakeholder y las características del producto, para el caso “Sistema de Ventas y Control de Almacén”: 2.1. Necesidades del Stakeholder 1. El sistema debe permitir crear, cancelar, modificar y ver el detalle de un pedido debe estar disponible. 2. Permitir crear y consultar un pedido vía Web. 3. Consultar los pedidos por estados. 4. Poder autenticar, registrar, modificar y eliminar un cliente. 5. Contar con un catálogo de repuestos actualizado online. 6. El sistema va a permitir al seleccionar el tipo de pago ya sea al contado o crédito. 7. El sistema va a permitir siempre la opción de poder abandonar una interfaz. 8. Existir la posibilidad de imprimir la información de un pedido más la información del pago. 9. Poder registrar las incidencias de almacén, pedido e ingreso de repuestos a almacén. 10. Mostrar una lista de incidencias ordenadas por fecha e imprimirlas. 11. Crear una lista con los ítems agregados a la compra ordenados por código de repuesto. 12. Mostrar las cantidades reales de stock. 13. Comunicación con el Área de Créditos de la empresa. 14. Poder registrar los pagos vía web. 15. Mostrar lista de requerimientos según fecha de elaboración. 16. Asignar prioridad para cada orden de almacén. 17. Asignar cantidad de repuestos a comprar. 18. Permitir enviar requerimientos a uno o más proveedores. 19. Permitir ingresar la cotización de un requerimiento, adjuntar el documento de cotización y ver los detalles. 20. Permita generar una orden de Compra. 21. Mostrar un listado de las órdenes de almacén según estado y ordenadas por prioridad. 22. Permitir la búsqueda de una orden de almacén por fecha de atención. 23. Asignar un estado de atendido, no atendido, listo para envío y enviado a la orden de almacén. 24. Permitir generar, imprimir y ver el detalle de una Orden de Compra de almacén. 25. Mostrar una lista de pedidos ordenados por fecha de facturación. 26. Asignar niveles: urgente, normal o bajo a una orden de almacén. 27. Permitir asignar uno o más operarios de almacén por orden de almacén. 28. Asignar un transportista por Orden de almacén. 29. Mostrar órdenes de compra e imprimir, según estado de recepción. 30. Ver el detalle de una Orden de compra. 31. Ingresar a inventario los nuevos repuestos. 32. Generar reportes de ventas a clientes y compras a proveedores. 2.2. Características del Producto 1. El sistema va a permitir crear un pedido ingresando la información del pedido ítems del pedido y forma de pago 2. El sistema va a permitir cancelar un pedido seleccionado únicamente cuando su estado sea de Elaboración. 3. El sistema va a permitir que el usuario elimine uno o varios ítems por pedido.

CIBERTEC



4. El sistema va a permitir que el usuario agregue un ítem al pedido 5. El detalle del pedido va a incluir la información de pedido, ítems del pedido, forma de pago, y costos totales y subtotales. 6. El sistema va a permitir al cliente realizar un pedido a través de una dirección URL. 7. Consultar un pedido vía web va a incluir los detalles los detalles de un pedido (código, fecha, elaboración, estado) 8. El sistema va a mostrar el estado de un pedido (en elaboración, en atención, enviado) de acuerdo con la situación en la que se encuentre 9. El sistema va a permitir la búsqueda de un pedido en función al estado en que éste se encuentre. 10. El sistema va a permitir al usuario registrar un nuevo cliente indicando los campos de nombre y apellido, DNI, razón social, RUC, dirección, número, puerta, distrito, provincia, teléfono, fax, email, persona contacto, teléfono contacto. 11. Los botones de iniciar y cerrar sesión van a encontrarse disponibles desde la interfaz del ingreso de usuario. 12. El sistema va a permitir al RVRS modificar los datos de un cliente cuando sea necesario. 13. El RVRS va a poder eliminar un cliente del sistema cuando sea necesario. 14. El catálogo de repuestos va a incluir una lista de repuestos con los siguientes datos: Código de repuesto, nombre de repuesto, descripción, precio y stock. 15. El sistema va a tener una lista desplegable la cual permitirá seleccionar el tipo de pago a realizar, ya sea al contado o crédito. 16. El sistema va a contar con un botón de salida para poder abandonar cualquier interfaz. 17. El Sistema va a ser capaz de calcular con un algoritmo el subtotal, el IGV y el total del costo de un pedido. 18. El sistema va a contar en todas las interfaces con las opciones de regresar, los cuales nos permitirán volver a una interfaz previa de la actual. 19. El sistema va a permitir la búsqueda de un cliente ya sea por nombre en caso de ser persona natural o razón social si se trata de una empresa. 20. El sistema va a incluir una opción para imprimir las siguientes informaciones: De pedido y la información de pago. Detalle de requerimiento. Orden de Almacén. Orden de Compra 21. El sistema va a tener una interfaz la cual permita ingresar todo tipo de incidencias. 22. El sistema va a mostrar una lista de incidencias ordenadas según fecha de elaboración desde la antigua hasta la más reciente. 23. El sistema va a ser tener la capacidad de crear una lista según el número de ítems agregados. 24. El sistema va a tener una opción que permita el ingreso masivo de ítems. 25. El sistema va a contar con un algoritmo que permita el cálculo stock disponible. 26. El sistema va a permitir calcular y mostrar un stock mínimo. 27. El sistema tendrá una conexión con el área de créditos de la empresa para tener el resultado de la aprobación o desaprobación del Crédito solicitado. 28. El sistema contará con la opción de impresión detallada de una incidencia. 29. El sistema debe permitir registrar los pagos a través de un browser (Internet Explorer y Mozilla Firefox) ingresando los datos correspondientes obligatorios al pago. • • • •

CIBERTEC



30. El sistema va a ser capaz de generar reportes de compras y ventas con los datos almacenados. 31. El sistema mediante un algoritmo va a ser capaz de determinar el estado de stock de un repuesto. 32. El sistema deberá mostrar una lista de repuestos ordenada según el estado de stock (alto, normal, bajo). 33. El sistema deberá mostrar una lista con todos los requerimientos realizados ordenados según la fecha de elaboración. 34. El sistema tendrá la opción para asignar prioridad a la orden de almacén. 35. El sistema permitirá ingresar la cantidad de repuesto a comprar. 36. El sistema tendrá una opción que asigne de manera inmediata la cantidad que se debe comprar para satisfacer el stock mínimo. 37. El sistema permitirá insertar o eliminar ítems de una compra. 38. El sistema permitirá seleccionar más de un proveedor. 39. El sistema tendrá una opción para enviar cotización a proveedores. 40. El sistema permitirá manejar la selección de proveedores. 41. El sistema permitirá ingresar Fecha, numero de cotización, plazo de entrega, el código de ítem, nombre del producto , descuento , cantidad, unidades de medida, el precio unitario con y sin impuesto. 42. El sistema va a tener una opción para poder adjuntar documento. 43. El sistema tendrá la opción de ver los detalles de un requerimiento con los siguientes campos: código requerimiento, fecha de elaboración, estado, prioridad, comentarios, proveedores y cotización. 44. Se contarán con las siguientes opciones para un requerimiento: Nuevo, modificar, eliminar y ver detalle. 45. El usuario podrá genera una orden de compra a través del sistema y se indicarán los siguientes campos: Código O/C, proveedor, Fecha de elaboración, Fecha de entrega, Forma de pago y estado. 46. El sistema va a permitir mostrar una lista con las órdenes de almacén ordenadas por prioridad con los siguientes datos: Código de O/A, Cliente, Fecha de inicio, prioridad. 47. El sistema tendrá la opción filtrar que permitirá mostrar las órdenes de almacén en función a la fecha de almacén indicada por el usuario. 48. El usuario debe establecer en las órdenes de almacén el estado de atención por pedido (atendido, no atendido y listo para envío). 49. El sistema va a mostrar el detalle de una orden de almacén con los siguientes campos: Código de O/A, Cliente, Fecha de inicio y prioridad. 50. El sistema podrá generar una orden de almacén ingresando previamente los siguientes datos: Código de O/A, Cliente, Fecha de inicio, prioridad. 51. El sistema mostrará una lista de pedidos que serán ordenados de acuerdo con la fecha de facturación registrada. 52. El usuario debe poder asignar en el sistema los niveles de priorización de los pedidos: urgente, normal y bajo. 53. El sistema debe permitir asignar uno o más operarios para el despacho de una orden de almacén. 54. El sistema debe permitir asignar un transportista por orden de almacén presentando la siguiente información: nombre y foto. 55. El sistema debe mostrar una lista de órdenes de compra con los siguientes datos: código O/C, proveedor, fecha de elaboración, fecha de entrega y monto total según los estados de recepción pendiente, observada y completada. 56. El sistema tendrá la opción de ver los detalles de una orden de compra con los siguientes datos: Código O/C, proveedor, fecha de elaboración, fecha de entrega, forma de pago y estado.

CIBERTEC



57. El sistema debe tener la opción de ingresar a inventario un repuesto mostrando los siguientes campos: Código o/c, proveedor fecha de elaboración, fecha de entrega, monto total y estado de recepción. 58. En todos los formularios que soliciten ingresos de datos, el sistema va a indicar qué campos son obligatorios mediante la colocación de un asterisco cerca al campo. 59. Todos los formularios que muestren fechas, se van a mostrar en el formato dd / mm / aaaa. 60. El sistema va a mostrar calendarios para seleccionar una fecha, en las ventanas que lo requieran. NOTA.- Una vez identificados las necesidades de stakeholders (STR) y las características (FEAT) para el caso, podemos crear los documentos “Peticiones del stakeholder” y “Visión del Producto” respectivamente.

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 7#

R$%&'$ 

En RUP, una descripción simplificada del proceso de gestión de requisitos contiene los siguientes pasos: Establecimiento de un plan de gestión de requisitos Captura de requisitos Desarrollo del documento Visión Creación de casos de uso Especificación suplementaria Creación de casos de prueba de casos de uso Creación de casos de prueba de la especificación suplementaria Diseño del sistema • • • • • • • •

 Los

documentos que se utilizan comúnmente en la gestión de requisitos son los siguientes: 1. Plan de gestión de requisitos 2. Peticiones de stakeholders 3. Visión 4. Glosario de términos 5. Especificación de caso de uso 6. Especificación de requisitos suplementarios 7. Especificación de requisitos del software 8. Especificación de caso de prueba.



Cada paso de la gestión de requisitos, a partir del segundo, navega a través de la pirámide de requisitos de arriba hacia abajo y de izquierda a derecha.



Los requisitos son más específicos en los niveles inferiores de la pirámide



Si desea saber más acerca de estos temas, puede consultar el siguiente libro:  “REQUIREMENTS

MANAGEMENT USING IBM RATIONAL REQUISITE PRO” de Peter Zielczynski. Del capítulo 3 al 11 se describe con más detalle cada uno de los pasos de la gestión de requisitos según RUP.

CIBERTEC




 TEMA

4 DOCUMENTOS - ATRIBUTOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO 1. Documentos de la Ingeniería de Requisitos. 2. Atributos de los tipos de requisitos.

ACTIVIDADES PROPUESTAS 1. Los alumnos rinden la Evaluación Continua Nº 3. 2. Los alumnos reconocen los documentos propuestos por el profesor. 3. Los alumnos asignan algunos atributos a los tipos de requisitos.

CIBERTEC



1. DOCUMENTOS DE LA INGENIERIA DE REQUISITOS Según el plan de gestión de los requisitos, se definen los requisitos de la pirámide y cada paso tiene su correspondiente documento a crear. En la tabla 4.1 se muestran los documentos que debemos documentar. Paso 1

Descripción

___________

Plan de Gestión de Requisitos

Captura de requisitos

Necesidades de stakeholders

Peticiones Stakeholders

Desarrollo del documento Visión

Características

Documento Visión, Glosario de Términos.

Creación de casos de uso

Casos de uso y escenarios

Especificación Requisitos Software. Especificación Caso de Uso

de de


Requisitos suplementarios

Especificación Requisitos Suplementarios

de

Creación de casos de prueba de casos de uso

Casos de prueba

Plan de casos de prueba, Especificación de Caso de Prueba.

Creación de casos de prueba de la especificación suplementaria

Casos de prueba

Especificación Caso de Prueba.

4

5

6

7

Documentos

Establecimiento de un plan de gestión de requisitos

2 3

Tipo de requisito

de

de

de

Tabla 4.1 - Documentos de la gestión de requisitos A continuación veremos algunos ejemplos de los documentos a crear en la gestión de requisitos. En el Anexo 1 se tienen todas las plantillas de los documentos con la explicación del contenido de cada uno de sus párrafos.

1. 2. 3. 4. 5. 6.

Plan de Gestión de Requisitos Petición del Stakeholder Documento Visión Especificación de Requisitos de Software Especificación de Caso de Uso Especificación de Requisitos Suplementarios. 7. Especificación de casos de prueba.

CIBERTEC



Petición de los Stakeholders 1. Introducción El documento contiene los requerimientos del Sistema SVGA, los cuales han sido obtenidos según las exigencias y alcance de los Stakeholders interesados en el desarrollo del sistema. 2. Perfil del Stakeholder Nombre: Juan Loarte Pérez Compañía: CIMAQ S.A. Cargo: Gerente General • • •

3. Lista de Requerimientos 1. El sistema debe permitir crear, cancelar, modificar y ver el detalle de un pedido debe estar disponible. 2. Permitir crear y consultar un pedido vía Web. 3. Consultar los pedidos por estados. 4. Poder autenticar, registrar, modificar y eliminar un cliente. 5. Contar con un catálogo de repuestos actualizado online. 6. El sistema va a permitir al seleccionar el tipo de pago ya sea al contado o crédito. 7. El sistema va a permitir siempre la opción de poder abandonar una interfaz. 8. Existir la posibilidad de imprimir la información de un pedido más la información del pago. 9. Poder registrar las incidencias de almacén, pedido e ingreso de repuestos a almacén. 10. Mostrar una lista de incidencias ordenadas por fecha e imprimirlas. 11. Crear una lista con los ítems agregados a la compra ordenados por código de repuesto. 12. Mostrar las cantidades reales de stock. 13. Comunicación con el Área de Créditos de la empresa. 14. Poder registrar los pagos vía Web. 15. Mostrar lista de requerimientos según fecha de elaboración. 16. Asignar prioridad para cada orden de almacén. 17. Asignar cantidad de repuestos a comprar. 18. Permitir enviar requerimientos a uno o más proveedores. 19. Permitir ingresar la cotización de un requerimiento, adjuntar el documento de cotización y ver los detalles. 20. Permita generar una orden de Compra. 21. Mostrar un listado de las órdenes de almacén según estado y ordenadas por prioridad. 22. Permitir la búsqueda de una orden de almacén por fecha de atención. 23. Asignar un estado de atendido, no atendido, listo para envío y enviado a la orden de almacén. 24. Permitir generar, imprimir y ver el detalle de una Orden de Compra de almacén. 25. Mostrar una lista de pedidos ordenados por fecha de facturación. 26. Asignar niveles: urgente, normal o bajo a una orden de almacén. 27. Permitir asignar uno o más operarios de almacén por orden de almacén. 28. Asignar un transportista por Orden de almacén. 29. Mostrar órdenes de compra e imprimir, según estado de recepción. 30. Ver el detalle de una Orden de compra. 31. Ingresar a inventario los nuevos repuestos. 32. Generar reportes de ventas a clientes y compras a proveedores.

CIBERTEC



Especificación de Requisitos de Software 1. Introducción 1.1. Propósito El presente documento tiene como propósito definir las especificaciones funcionales, no funcionales y del sistema para la implementación de una aplicación web que permitirá gestionar de manera adecuada tanto el proceso de ventas y entrega de repuestos, como el de abastecimiento de almacén también. Para lo cual se diseñara un software el cual será utilizado por los diferentes trabajadores y clientes de CIMAQ. 1.2. Alcance El documento Especificaciones de Requerimientos de Software nos permitirá diseñar, desarrollar e implantar del sistema SVGA (Sistema de Ventas y Gestión de Almacén). El SVGA será una aplicación que funcionará en un entorno web que permitirá gestionar de manera adecuada el proceso de ventas, entrega de repuestos y de abastecimiento de almacén de la empresa CIIMAQ. Ésta aplicación dará apoyo a los siguientes procesos: Venta de repuestos Entrega de repuestos y Abastecimiento de almacén. 1.3. Referencias Las referencias al presente documento son: Documento Visión Especificación de Casos de Uso y Especificación de Requerimientos Suplementarios. 1.4. Resumen Ejecutivo La problemática actual es la utilización de los recursos humanos en el área de almacén que se ve afectada negativamente por la falta de control de tiempos empleados y priorización en la entrega de productos. Además, existe una deficiente sincronización entre la elaboración de pedidos del área de ventas y la gestión de existencias e inventarios del área de almacén. Es así que el presente proyecto va a referir el nombre del siguiente sistema: “Sistema de Ventas y Gestión de Almacén” – SVGA El contenido referente al proyecto va a incluir los siguientes capítulos: Estudio de factibilidad. Modelado del Negocio Captura de Requerimientos Análisis Diseño Implementación Administración del Proyecto. Para el desarrollo adecuado del proyecto nos basamos en las diferentes herramientas que ofrece IBM Rational, tales como: IBM Rational RequisitePro, IBM Rational Software Architect, InfoSphere Data Architect; así también como las herramientas del Office. Todos estos mecanismos serán utilizados basándonos en la metodología RUP. • • •

• • •

• • • • • • •

2. Requerimientos Funcionales El sistema debe cumplir con los siguientes requerimientos: 2.1. Asociados a los Casos de Uso del sistema 1. Registrar pedido online 2. Registrar pedido 3. Registarar requerimiento

CIBERTEC



4. Generar Orden de Almacén 5. Ingresar repuestos a inventario 6. Cotizar requerimiento requerimiento 7. Atender Orden de Almacén 8. Registrar Registra r pago 9. Mantaner cliente 10. Asignar proveedores 11. Agregar Item a requerimiento requerimiento 12. Agregar Item a pedido 13. Mantener usuario 14. Registrar incidencia de pedido 15. Registrar incidencia de Ingreso 16. Registrar incidencia de Atención 17. Buscar cliente 18. Generar reporte de almacén 19. Consultar incidencia 20. Generar reporte de compras 21. Generar reporte de ventas 22. Consultar pedido. 2.2. Asociados a aspectos generales 1. Obligar al usuario a que el cambio de contraseña contrase ña sea cada 120 días. 2. Incluir un mecanismo que permita su actualización automática sin la intervención del usuario. 3. Mantener un registro de los los errores (logs). Para cada error error el sistema debe registrar: el código del error, una descripción del error, la fecha y la hora del error. 4. Permitir que se puedan adjuntar documentos documentos al sistema. 5. Permitir que un usuario sea capaz de imprimir algún reporte. 6. Incluir elementos interactivos, como por ejemplo calendarios que van a aparecer en ventanas emergentes. 7. Permitir que el sistema pueda ser utilizado en las distintas variantes de browser que ofrece el internet. 8. Mantener un performance performance estable, para que el usuario usuario no tenga problemas problemas para desenvolverse en el sistema. 3. Requerimientos No Funcionales 3.1. Usabilidad En todos los formularios formularios que soliciten ingresos ingresos de datos, el sistema va a indicar qué campos son obligatorios mediante la colocación de un asterisco cerca al campo. Todos los formularios que muestren fechas, se van van a mostrar en el formato dd/mm/aaaa. El sistema debe mostrar mostrar calendarios calendarios para para seleccionar seleccionar una una fecha, en las las ventanas que lo requieran. El sistema va a contar con un botón de salida para poder abandonar cualquier interfaz. El sistema va a tener una opción que permita el ingreso masivo de items. El sistema va a tener una conexión con el área de créditos de la empresa para tener el resultado de la aprobación o desaprobación del Crédito solicitado. El sistema va a permitir registrar los los pagos pagos a través través de un browser browser ya sea Internet Explorer o Mozilla Firefox (sin importar las versiones). Los siguientes siguientes campos: campos: código código de O/A, cliente, fecha de inicio, prioridad; van a ser mostrados ordenadamente en una lista de ordenes de almacén. •

•

•

•

• •

•

•

CIBERTEC



En todas las interfaces interfaces se se encontrarán encontrarán disponible disponibless los botones de regresar regresar los cuales permitirán volver a una interfaz previa de la actual. El sistema va a tener una opción para poder adjuntar un documento En el caso del ingreso ingreso de datos, los botones de limpiar se encontrarán encontrarán presentes con el objetivo de permitir reanudar el ingreso de información. Las fechas deberán ser mostradas de acuerdo al formato format o cargado en la configuración del navegador Web. En el caso de la búsqueda e ingreso de datos, van a encontrarse disponibles mensajes de ayuda los cuales le brinden al usuario una guía para la toma de decisiones. 3.2. Confiabilidad 3.2.1. Tolerancia de Error El tiempo medio de reparación dependerá de la complejidad de los ajustes necesarios para lo corrección de errores, dicha demora se verá disminuida gracias al registro de mensajes de error, que facilitará la identificación y posible solución a la falla presentada. 3.2.2. Recuperabilidad El tiempo medio de reparación dependerá de la complejidad de los ajustes necesarios para lo corrección de errores, dicha demora se verá disminuida gracias al registro de mensajes de error, que facilitará la identificación y posible solución a la falla presentada. 3.2.3. Disponibilidad El sistema SVGA tendrá una disponibilidad de uso del 41.6% del día (10 horas), es decir, el horario laborable del personal de almacén (8 horas) más 2 horas, en caso que se deseen revisar reportes de las actividades realizadas realizadas en el transcurso del día. 3.2.4. Precisión Las cantidades actuales van a ser calculados y almacenados con una precisión de 2 decimales. 3.2.5. Seguridad El password va a ser requerido por el administrador de interfaces. 3.3. Rendimiento El rendimiento del Sistema de Ventas y Gestión de Almacén SVGA es estimado desde el inicio del proyecto de desarrollo y es ampliado durante su construcción; no obstante, se verá influenciado de acuerdo con la carga de trabajo. 3.3.1. Tiempo de Respuesta El tiempo estimado de respuesta por actividad, de la aplicación web, no debe ser mayor a 5 segundos. 3.3.2. Tiempo de Recuperación Recuperación El tiempo estimado de acceso a la aplicación web no debe ser mayor a 5 segundos. 3.3.3. Tiempo de Encendido y Apagado El tiempo estimado de encendido y apagado del software será de 5 segundos. 3.3.4. Capacidad El sistema va a alojar a 700 usuarios actualmente. 3.3.5. Utilización de Recursos El sistema va a almacenar en la base de datos no más de un millón de transacciones. Si la base de datos crece más del límite, las antiguas transacciones serán eliminadas y suplantados desde la base de datos operacional. •

• •

•

•

CIBERTEC



3.4. Soporte y Mantenimiento M antenimiento 3.4.1. Capacidad de Prueba La interfaz de Usuario no va a contener ningún otro componente que impida el uso de la herramienta IBM Rational Functional Tester. 3.4.2. Adaptabilidad El tiempo de implementación de otras herramientas requeridas para el adecuado funcionamiento del sistema no va a durar más de un día. 3.4.3. Mantenimiento El SVGA va a contar con errores programados que serán mostrados y registrados para hacer uso de éstos en una futura solución al problema. 3.4.4. Compatibilidad Después que SVGA esté en ejecución, las versiones siguientes van a ser compatibles con sus predecesoras. Todas las transacciones ingresadas previamente en versiones previas van a ser disponibles en las nuevas versiones. 3.4.5. Capacidad de Actualización El sistema va a ser provisto de actualizaciones que pueden contener asistencia técnica que contribuya con su operatividad. 3.4.6. Capacidad de Instalación La instalación del sistema no va a requerir alguna otra instalación de alguna estación de trabajo. 3.4.7. Escalabilidad Después de 6 meses de trabajo, el sistema va a ser capaz de alojar un adicional de 500 usuarios más. 3.4.8. Portabilidad Cambiar la base de datos del sistema en el futuro, no va a requerir alguna reescritura de una aplicación lógica. 3.4.9. Capacidad de ser Reusable Las funcionalidades principales del sistema van a ser encapsulados en componentes que van a ser reusados un una aplicación cliente-servidor. 3.4.10. Variabilidad La variabilidad del sistema no va a contener herramientas internas o externas las cuales cambien la funcionalidad del software. 3.4.11. Capacidad de ser Analizado El sistema va a contener un estándar estándar apropiado para el fácil análisis por parte del usuario que lo requiera. 3.4.12. Capacidad de ser Localizado El sistema va a estar disponible en español. 3.5. Consideraciones de diseño e implementación El sistema utilizará utilizará la arquitectura arquitectura JEE. El sistema será desarrollado en Eclipse Helios para su programación y Dreamweaver CS5 para su diseño. Se utilizará IBM WebSphere como servidor servidor de aplicaciones. aplicaciones. Se utilizará SQL Server como base de datos, bajo la plataforma Windows Server 2003 de 64 bits. El sistema funciona bajo bajo la plataforma Windows XP Professional Professional 32 bits. 3.6. Documentación de Usuario en Línea y Sistema de Ayuda El SVGA contará con un espacio web en el cual el usuario podrá encontrar ayuda en línea; además, tendrá disponible un campo en el que pueda dejar sugerencias y reportar cualquier tipo de inconveniente. 3.7. Interfaces 3.7.1. Interfaces de Usuario Las interfaces que serán implementadas por el software, serán de fácil uso y entendimiento para el usuario; además, presentará un entorno • •

• •

•

CIBERTEC



amigable que ofrece una serie de ventajas por su sencillez de operación, que hará que se sientan a gusto utilizando la herramienta. 3.7.2. Interfaces de Hardware El sistema será implementado sobre el servidor netfinity IBM con el que ya cuenta CIMAQ S.A., y será instalado en los módulos que serán ubicados en almacén. 3.7.3. Interfaces de Software EL sistema será desarrollado en Eclipse Helios y diseñado en Dream weaver CS4, y será funcional bajo la plataforma Windows XP Professional 32bits; el servidor de base de datos será SQL Server 2005, bajo la plataforma Windows Server 2003 de 64bits. 3.7.4. Interfaces de Comunicaciones Se hará uso de una Conexión de área local (LAN), utilizando para la comunicación, cables de internet UTP con conectores RJ45. 3.8. Requerimientos de Licencia El sistema será implementado sobre los recursos informáticos que ya existen en CIMAQ S.A., por lo tanto, no será necesario adquirir nuevas licencias. 3.9. Requerimientos legales, Copyright y Otros El SVGA formará parte de los módulos o sistemas ya existentes dentro de las instalaciones de CIMAQ S.A. 3.10. Aplicación de Estándares Los estándares aplicables para la realización del sistema SVGA serán los siguientes: 3.10.1. Hardware Estandarizado al actual que está siendo usado en las instalaciones de CIMAQ S.A. 3.10.2. Software Estandarizado aplicando patrones de diseño (DAO, MVC), interfaces gráficas, web 2.0. 3.10.3. Redes Estandarizado siguiendo el modelo OSI.

CIBERTEC



Especificación de caso de uso: Generar Orden de Almacén 1. Breve descripción El caso de uso permite al Coordinador de Almacén generar una orden de almacén a partir de un pedido facturado. 2. Actores Coordinador de almacén (CO) 3. Flujo de eventos 3.1. Flujo Básico 1. El caso de uso inicia cuando el CO solicita “Generar Orden Almacén” en el menú de Supervisión de Almacén. 2. El sistema muestra la interfaz “Gestión de Orden Almacén” con la siguiente información: Datos de los pedidos facturados ordenados por fecha de facturación (lista): código de pedido, cliente, fecha de elaboración y fecha de facturación y las opciones “Ver Detalle” y “Salir”. 3. El CO selecciona un pedido de la lista de pedidos facturados. 4. El CO solicita “Ver Detalle”. 5. El sistema muestra la interfaz “Detalle de Pedido Facturado” con la siguiente información: Datos de Facturación: representante de facturación, fecha de facturación (no habilitados) Datos de pedido: código del pedido, cliente, fecha de elaboración, representante de ventas, dirección de envió, número, puerta, distrito, provincia, persona de contacto, teléfono de contacto, referencia. (no habilitados) Datos de los repuestos del pedido (lista): código de repuesto, descripción, cantidad y unidad, ordenados por código de repuesto. Datos de pago: forma de pago, subtotal, IGV y total. (no habilitados) Las opciones “Generar Orden de Almacén”, “Imprimir”, “Volver”. 6. Si el CO selecciona la opción “Imprimir”, ir al subflujo “Imprimir Detalle”. 7. Si el CO solicita “Volver”, el flujo continúa en el paso 1 del flujo básico. 8. El CO solicita “Generar Orden Almacén”. 9. El sistema muestra la interfaz “Priorización de Orden de Almacén” con la siguiente información: Datos del cliente: código, nombre o razón social, récord de compras (unid monetarias), récord de pedidos (# pedidos), tiempo promedio de pago (días) y confiabilidad (%). Un campo de selección de Nivel: urgente, normal y bajo. Las opciones “Siguiente” y “Cancelar”. 10. EL CO selecciona el nivel de priorización de la Orden de Almacén. 11. El CO selecciona la opción “Siguiente”. 12. El sistema valida la selección del campo nivel. 13. El sistema graba la prioridad de la Orden de Almacén (en sesión). 14. El sistema muestra la interfaz “Asignación de Operarios” con la siguiente información: Un campo fecha con la opción “Ver disponibilidad”. Datos de operarios asignados a la Orden de Almacén (lista): nombre, horas disponibles y horas asignadas. Un campo duración total (en horas) (no habilitado). Las opciones “Siguiente”, “Volver” y “Cancelar”. 15. El CO ingresa una fecha para ver la disponibilidad de operarios. 16. El CO solicita “Ver Disponibilidad”. •

•

•

•

• •

•

• •

• •

• •

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) !#

17. El sistema muestra la interfaz “Operarios Disponibles” con la siguiente información: Datos de operarios disponibles en dicha fecha (lista): código de operario, nombre, horas disponibles y horas asignadas (habilitado), con las opciones “Asignar” y “Cancelar”. 18. El CO ingresa la cantidad de horas a asignar a cada operario en el campo horas asignadas de la lista de operarios. 19. Si el CO selecciona la opción “Cancelar”, el flujo regresa al paso 14 del flujo básico. 20. El CO solicita “Asignar”. 21. El sistema valida la cantidad de horas ingresadas. 22. El sistema calcula la duración total de atención de la Orden de Almacén. 23. El sistema muestra la interfaz “Asignación de Operarios de Orden de Almacén” con los datos de los operarios y la duración total. 24. Si el CO desea asignar más operarios a la Orden de Almacén, se repiten los pasos del 16 a 23. 25. Si el CO selecciona la opción “Volver”, el flujo regresa al paso 9 del flujo básico. 26. El CO selecciona la opción “Siguiente”. 27. El sistema graba los datos de los operarios asignados a la Orden de Almacén (en sesión). 28. El sistema muestra la interfaz “Asignación de Transporte” con la siguiente información: Datos del Pedido: código de pedido, dirección de envió, numero, puerta, distrito, provincia y referencia (no habilitados). Datos del Transportista: código de transportista, nombre, DNI y zona (no habilitados) con la opción “Asignar Transportista”. Las opciones “Aceptar”, “Volver” y “Cancelar”. 29. El CO selecciona la opción “Asignar Transportista”. 30. El sistema muestra la interfaz “Selección de Transportista” con la siguiente información: Datos de transportistas disponibles (lista): código, nombre, DNI y zona y las opciones “Aceptar” y “Cancelar”. 31. El CO selecciona un transportista de la lista. 32. El CO selecciona la opción “Aceptar”. 33. El sistema valida la selección de transportista. 34. El sistema muestra la interfaz “Asignación de Transporte” con los datos del transportista asignado. 35. Si el CO selecciona la opción “Volver”, el flujo retorna al paso 28 del flujo básico. 36. El CO selecciona la opción “Aceptar”. 37. El sistema muestra el MSG de confirmación (Aceptar o Cancelar) “¿Desea generar Orden de Almacén?” 38. El CO selecciona la opción “Aceptar”. 39. El sistema genera un código de Orden de Almacén. 40. El sistema obtiene los datos de prioridad y de operarios de la sesión. 41. El sistema graba los datos de la Orden de Almacén con su detalle (prioridad, operarios y transportista) y con la fecha actual, en estado de “No Atendida” y muestra el MSG: “Orden de Almacén generada correctamente” 42. El CO selecciona “Salir”, el sistema cierra la interfaz “Gestión de Orden de Almacén” y el caso de uso finaliza. 3.2. Sub Flujos Imprimir Detalle 1. El sistema imprime el detalle del pedido facturado. 2. El flujo continúa en el paso 8 del flujo básico. •

•

•

•

•

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) !

3.3. Flujos Alternativos 10.1. Cancelar Generación de Orden de Almacén 1. El sistema muestra un mensaje de confirmación (Aceptar o Cancelar) “¿Cancelar generación de Orden de Almacén?” 2. El CO selecciona “Aceptar” para cancelar Orden de Almacén. 3. El sistema cancela la Orden de Almacén y finaliza el caso de uso. 12.1. Datos de priorización inválidos Si los datos ingresados en la prioridad (nivel) son nulos o inválidos en el paso 13 del flujo básico. 1. El sistema muestra un mensaje “Selección de nivel de prioridad obligatoria”. 2. El flujo continúa en el paso 10 del flujo básico. 13.1. – 27.1. Error al grabar en sesión Si el sistema no puede grabar el nivel de prioridad y/o los datos de operarios, muestra el MSG “Error al grabar datos en sesión” y finaliza el caso de uso. 21.1. Cantidad Inválida Si la cantidad ingresada es inválida, el sistema muestra el MSG: “Cantidad de horas invalidas” y el caso de uso continúa en el paso 18. 33.1. Datos de transportista inválidos Si los datos ingresados del transportista son nulos o inválidos, el sistema muestra el MSG: “Selección del transportista obligatoria” y el caso de uso continúa en el paso 31. 41.1. Error al grabar Orden de Almacén Si el sistema no puede grabar la Orden de Almacén muestra el MSG: “Error al grabar Orden de Almacén” y el caso de uso continúa en el paso 38. 4. Precondiciones 4.1. El CO debe estar registrado y logueado en el sistema. 5. Post condiciones 5.1. La Orden de Almacén, con su detalle quedará grabado en el sistema. 5.2. El estado del pedido cambiará a “Enviado a Almacén”, en el sistema. 5.3. El estado de la Orden de Almacén cambiará a “No Atendida”, en el sistema. 6. Requerimientos especiales 6.1. La PC del Coordinador debe tener acceso a intranet. 6.2. La PC del Coordinador debe estar conectada a una impresora. 7. Puntos de extensión Ninguno. 8. Prototipo (A ser diseñado por los alumnos)

2. ATRIBUTOS DE LOS TIPOS DE REQUISITOS Para cada tipo de requisito identificado, podemos definir una lista de atributos que se utilizarán durante la gestión de los requisitos. A continuación, se describen los atributos que pueden ser utilizados según el tipo de requisito. Ver tabla 4.2.

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS I (TEORÍA)

CIBERTEC

!2



CIBERTEC

!3



CIBERTEC

!4



!5

Tabla 4.2 – Atributos de los requisitos

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS I (TEORÍA) !6

ACTIVIDADES PROPUESTAS 1. Para la próxima clase los equipos de proyectos presentarán los documentos: Plan de gestión de Requerimientos y Documento Visión de su proyecto. 2. Traer dos (2) de los casos de uso más críticos de su proyecto. 3. Exponer sus documentos Plan de Gestión de Requisitos y Documento Visión de su proyecto. 4. Detallar dos (2) Especificaciones de Casos de Uso de su proyecto. 5. Crear un (1) documento Especificación de Caso de Prueba de una (1) de sus especificaciones de caso de uso del punto 1.

CIBERTEC


A"A#ISIS $ %IS&'O %& SIST&(AS II ) A%(I"IST*ACI+" $ SIST&(AS

,7

R$%&'$  Los

documentos se crean según el Plan de Gestión de Requisitos y según los niveles de la pirámide.



Además, puede consultar las siguientes páginas. 

http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html Este artículo ilustra el uso de IBM Rational Requisite Pro para la trazabilidad de los casos de uso con escenarios y casos de prueba.

__________________________________ __________________________________________ CI&*T&C

CA**&*AS *OF&SIO"A#&S

,,


 TEMA

5 TRAZABILIDAD DE REQUISITOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO 1. Trazabilidad entre requisitos. 2. Caso de Matriz de requisitos.

ACTIVIDADES PROPUESTAS 1.

Los alumnos crean la matriz de necesidades del stakeholder entre las características del sistema.


CI&*T&C


,9

1. TRAZABILIDAD ENTRE REQUISITOS La trazabilidad es una técnica que proporciona una relación entre los diferentes niveles de requisitos en el sistema. Esta técnica ayuda a determinar el origen de cualquier requisito. La siguiente figura ilustra cómo los requisitos se trazan desde el nivel superior hacia abajo. Todas las necesidades por lo general se asignan a algunas características. En general, es una relación de muchos a muchos, porque una necesidad puede rastrear a muchas características, y una característica puede obtenerse de muchas necesidades. Un caso común también es que una necesidad rastrea a una característica. En el siguiente nivel también notamos que las características mapean a los casos de uso en una relación de muchos a muchos. Las características también trazan a los requisitos suplementarios en una relación de muchos a muchos.

Figura 5.1 - Trazabilidad de Requisitos Cada caso de uso traza a uno o más escenarios, así es que existe una relación de uno a muchos entre los casos de uso y escenarios. Los escenarios también tienen una relación de uno a muchos con los casos de prueba. La trazabilidad desempeña varios roles importantes porque permite: 1. Verificar si la aplicación cumple con todos los requisitos: Todo lo que el cliente pidió fue implementado. 2. Verificar si la aplicación hace sólo lo que se pidió: No implementa algo que el cliente nunca solicitó. 3. Realizar un análisis de impacto: ¿Qué elementos se verán afectados si se considera la adición de un nuevo requisito o cambiar una ya existente? 4. Ayudar con la gestión del cambio: Cuando algún requisito cambia, queremos saber qué casos de prueba deben rehacerse para probar este cambio. La trazabilidad es una propiedad de los requisitos aplicable al resto del desarrollo que permite conocer las dependencias entre los distintos artefactos que se van generando.

__________________________________ __________________________________________ CI&*T&C


9/

Cada vez que se crea o cambia un nuevo artefacto (un objetivo, un requisito, un elemento de modelado, un módulo, un fichero de código fuente, una prueba, etc.) se debe registrar de qué elementos de nivel superior y de su mismo nivel depende. Esta tarea es la única forma de poder realizar un análisis de impacto cuando se solicita un cambio, pues todos los que dependen del artefacto, tanto directa como indirectamente, están expuestos a posibles cambios. La siguiente figura muestra la estructura de trazabilidad utilizada en un proyecto.

Figura 5.2 - Diagrama de Trazabilidad Un elemento de la trazabilidad es un elemento del proyecto que debe ser explícitamente trazado a partir de otro elemento textual o modelo para hacer un seguimiento de las dependencias entre ellos. La siguiente tabla describe todos los tipos de requisitos a utilizar en el proyecto.

Tabla 5.1 - Tabla de descripción de elementos de trazabilidad


CI&*T&C


91

ACTIVIDADES RESUELTAS 1.

A partir de la especificación de la lista de requisitos dada por su profesor realice las siguientes matrices de trazabilidad: Necesidades de stakeholder (STRQ) versus características del producto (FEAT).

•

NECESIDADES STRQ1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos. STRQ2: Las fechas deberán ser mostradas en formato dd/ mm / aaaa. STRQ3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios. STRQ4: La capacidad para cancelar una compra de boleto deberá estar disponible. STRQ5: El usuario será capaz de cancelar una reservación de un auto o un hotel. STRQ6: Los vuelos de ida y llegada serán ordenados por el menor número de paradas. STRQ7: El usuario será capaz de seleccionar los asientos. STRQ8: El sistema deberá tener una interfaz de lenguaje natural. STRQ9: El sistema mostrará un calendario emergente cuando se introduzca una fecha. STRQ10: El usuario deberá indicar si necesita un boleto solo de ida o ida y retorno, marcando la casilla de verificación. STRQ11: Para los vuelos de llegadas y salientes, los usuarios podrán comparar los precios de otros aeropuertos cercanos. STRQ12: A veces un Usuario ingresará un código de aeropuerto, que el sistema entenderá, pero a veces la ciudad más cercana puede reemplazarlo, entonces el Usuario no necesita saber el código del aeropuerto, y todavía no será entendida por el sistema. STRQ13: El sistema deberá tener una navegación clara. STRQ14: Si el usuario compra un boleto una vez, no será necesario repetir la misma información, como dirección o número de tarjeta de crédito. STRQ15: Pago por PayPal estará disponible. STRQ16: Las fechas se muestran en el formato dd / mm / aaaa. STRQ17: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. STRQ18: Será ordenado por precio. STRQ19: La comparación de precios de alquileres de autos de diferentes empresas se facilitará. STRQ20: Los precios de alquiler de autos deben mostrar todos los impuestos aplicables (incluido el 6% IVA del estado). STRQ21: Un calendario estará disponible para ayudar el ingreso de las fechas del vuelo. STRQ22: El sistema deberá proporcionar la posibilidad de reservar el vuelo, compra un boleto, reservar una habitación de hotel, reservar un auto, y proporcionar información acerca de las atracciones. STRQ23: El usuario será capaz de comprar un boleto en línea, sin necesidad de llamar a al Agente de viajes. STRQ24: El sistema deberá seguir las guías de implementación prevista en la cadena de nuestras agencias de viajes. STRQ25: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas __________________________________ __________________________________________ CI&*T&C


90

aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. STRQ26: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad adecuado para las aplicaciones comerciales. STRQ27: El sistema será desarrollado en tres meses. STRQ28: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. STRQ29: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación en base al: apellido, ciudad de destino, fecha, etc. STRQ30: El Agente de Viajes podrá cambiar los detalles de la reservación o cancelar una reservación. STRQ31: Mientras se este ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML. STRQ32: La información de contenido debe ser almacenado en un archivo de texto. STRQ33: El sistema deberá ser completamente probado solo en versiones específicas de los más populares navegadores. STRQ34: El sistema puede mostrar un mapa del aeropuerto. STRQ35: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reserva en base a los apellidos y fecha. STRQ36: Todas las actividades en el Site se registran. STRQ37: Varios informes estarán disponibles. STRQ38: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación. STRQ39: Mientras se proporcione información acerca del hotel, la siguiente información se desplayará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos, las formas de pago disponibles, etc. STRQ40: Al usuario se le ofrecerá ofertas de vuelos y hoteles. STRQ41: Sólo serán aceptados pagos con tarjeta de crédito. No se aceptan cheques ni PayPal. CARACTERISTICAS FEAT1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos (para vuelo de ida y vuelo de retorno). FEAT2: Las fechas deberán ser mostradas de acuerdo al formato cargado en la configuración del navegador Web. FEAT3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios de ingresar colocando un asterisco cerca al campo. FEAT4: El usuario será capaz de cancelar la compra de un boleto en cualquier momento antes de la confirmación final de la compra. FEAT5: El usuario será capaz de cancelar una reservación de un auto o un hotel. FEAT6: El usuario será capaz de seleccionar si los vuelos son ordenados por el menos número de paradas o por precio. FEAT7: Durante la compra de un boleto de avión, el usuario será capaz de seleccionar los asientos. FEAT8: El sistema mostrará un calendario emergente en cualquier fecha que se ingrese, tales como una fecha de vuelo, fechas de permanencia en el hotel, o la fecha del alquiler de un auto). FEAT9: El usuario tendrá la oportunidad de indicar si necesita solo un boleto de ida o ida y retorno. FEAT10: El sistema deberá identificar el aeropuerto en base al código del aeropuerto o al nombre de la ciudad. FEAT11: Separación por pestañas disponibles para la funcionalidad principal. FEAT12: En cada página un botón “Siguiente” sugiere el flujo pre determinado.


CI&*T&C


9

FEAT13: Si el usuario compra un boleto de una vez, no será necesario repetir la misma información (tales como dirección o número de tarjeta de crédito) durante las transacciones futuras. FEAT14: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. FEAT15: El sistema deberá proporcionar la comparación de los precios de alquiler de autos de diferentes empresas. FEAT16: Los precios del alquiler de autos deben mostrar todos las Impuestos aplicables. FEAT17: El sistema deberá proporcionar la oportunidad de reservar el vuelo. FEAT18: El sistema deberá proporcionar la oportunidad de comprar un boleto de avión. FEAT19: El sistema deberá proporcionar la oportunidad de reservar una habitación de hotel. FEAT20: El sistema deberá proporcionar la oportunidad de reservar un auto. FEAT21: El sistema deberá proporcionar información acerca las atracciones en lugares específicos. FEAT22: El usuario será el capaz de comprar un boleto en línea, sin necesidad de llamar al Agente de viajes. FEAT23: El sistema utilizará la arquitectura JEE. FEAT24: Si la arquitectura requiere de un servidor de aplicaciones deberá utilizar IBM WebSphere. FEAT25: Si el sistema requiere una base de datos. Oracle deberá utilizar. FEAT26: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. FEAT27: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad apropiado para las aplicaciones comerciales. FEAT28: El sistema deberá ser desarrollado tres meses a partir de la fecha en que el cliente firme los Casos de Uso y las especificaciones suplementarias. FEAT29: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. FEAT30: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación en basado en lo siguiente: apellido, ciudad de destino y fecha. FEAT31: El Agente de Viajes será podrá cambiar los detalles de una reservación. FEAT32: El Agente de Viajes podrá de cancelar una reservación. FEAT33: Mientras se este ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML. FEAT34: El sistema deberá ser completamente probado en los siguientes navegadores: Internet Explorer y Netscape. FEAT35: Todas las transacciones y los errores deberán ser registrados y estarán disponibles para el Administrador. FEAT36: Los siguientes informes estarán disponibles para el Administrador: Una lista de todos los boletos de avión comprados en un período de tiempo determinado. Una lista de todas las reservas de autos en un período de tiempo determinado. Una lista de todas las reservas de habitaciones de hotel en un periodo de tiempo determinado. FEAT37: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación.

__________________________________ __________________________________________ CI&*T&C


9

FEAT38: Mientras se proporcione información acerca del hotel, la siguiente información se mostrará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos y las formas de pago disponibles. FEAT39: Al usuario se le ofrecerá paquetes de ofertas que constan de vuelos y alojamiento en hoteles. FEAT40: Durante el pago del boleto de avión, solo se aceptará con tarjeta de crédito. Cheques y PayPal no serán aceptados. 2.

A partir del siguiente caso, identificar las necesidades del stakeholder, características del sistema y casos de uso. Luego crear las matrices correspondientes.

Caso Saga Falabella “Saga Falabella” es un conocido Centro Comercial que se dedica a las ventas de productos al crédito, dentro de su política de calidad y mejora continua desea realizar el estudio de sus procesos. El Centro Comercial “Saga Falabella” tiene dos (2) diferentes tipos de clientes que son: individuales (titulares) y familiares (dependientes). Para obtener una tarjeta de crédito, cualquier solicitante debe acercarse a una de las tiendas del Centro donde es atendido por un vendedor que se encarga de llenar sus datos tanto personales como del crédito en el formulario GCC-01 denominado “Solicitud de crédito”. Para completar el expediente del cliente, además del formulario adjunta la copia del DNI, un recibo de luz, agua o teléfono y las tres últimas boletas o recibos de honorarios profesionales que acrediten los ingresos del cliente. Al final del día el vendedor recopila los expedientes y los entrega al coordinador de inspectoría de la central de créditos, quien se encarga de repartir los expedientes a los diferentes inspectores. Por cada expediente, el inspector debe primero verificar que el solicitante no tiene ningún trámite de crédito pendiente ni se encuentra calificado como “Inhabilitado para créditos” en la base de datos de INFOCORP, luego procede a realizar la verificación de los datos declarados por el solicitante mediante llamadas telefónicas o visitas personales. Después de realizar un máximo de tres visitas y de constatar la validez de la información declarada por el futuro cliente, prepara un informe de inspectoría que le hace llegar, junto con el expediente del solicitante, al jefe de créditos. El jefe de créditos tiene la última palabra acerca de la aprobación o denegación del crédito. Si su evaluación es positiva le otorgará una línea de crédito de consumo mensual y comunicará al asistente de créditos que genere una tarjeta con una clave secreta para el cliente, la cual será remitida en sobre sellado. PREGUNTAS 1. Usted es el Analista de Sistema y deberá identificar las Necesidades relacionadas a este proceso, describiendo brevemente cada uno. Necesidades Descripción STRQ1 El usuario podrá registrar una solicitud de crédito con los datos personales del cliente. STRQ2 El sistema permitirá asignar expedientes a los inspectores. STRQ3


La capacidad de registrar informes de las inspectorias a los clientes.

CI&*T&C


STRQ4

92

El Jefe de créditos podrá evaluar una solicitud de crédito para aprobarlo o rechazarlo. Debe estar disponible la opción de generar una línea de crédito después de aprobada una solicitud. El sistema debe imprimir la tarjeta de crédito para el cliente que se le aprobó el crédito. Los usuarios podrán consultar trámites pendientes del cliente y solicitudes por estado. Los usuarios podrán verificar la calificación de un cliente con el sistema de INFOCORP. La comunicación entre usuarios será por correo electrónico.

STRQ5 STRQ6 STRQ7 STRQ8 STRQ9 STRQ10

Los usuarios del sistema tendrán un Usuario y contraseña para ingresar al sistema.

2. En función a las necesidades identificar las características del producto. Necesidad STRQ1

Característica

STRQ1

FEAT2

STRQ2

FEAT3

STRQ2

FEAT4

STRQ3

FEAT5

STRQ4

FEAT6

STRQ5

FEAT7

STRQ7 STRQ8 STRQ8

FEAT8

STRQ8

FEAT10

STRQ9

FEAT11

STRQ10

FEAT12

STRQ1 STRQ2

FEAT13

FEAT1

Descripción El sistema permitirá registrar una solicitud de crédito. El sistema permitirá registrar los datos personales de un cliente. Disponibilidad de la lista de inspectores, para su búsqueda. El sistema permitirá asignar expedientes a los inspectores para su inspección. El sistema proveerá la oportunidad de registrar un Informe de las inspecciones realizadas a un cliente. El sistema permitirá evaluar una solicitud de crédito, para aprobar o rechazar. El sistema permitirá generar una línea de crédito, si el crédito fue aprobado. Una vez generado la línea de crédito, el sistema permitirá imprimir una tarjeta de crédito para el cliente. El sistema tendrá consultas de: trámites pendientes, a INFOCORP solicitudes por estado y solicitudes mensuales El sistema deberá comunicarse con el sistema de INFOCORP, para verificar la calificación de riego de los clientes. El sistema permitirá a los usuarios conocer el estado de las solicitudes por correo electrónico. El sistema verificará el usuario y contraseña para ingresar al aplicativo. El sistema permitirá gestionar los datos de los clientes e inspectores.

FEAT9

3. De las características identificadas en la pregunta 2, se le pide que usted identifique los casos de uso del sistema que deben darle cobertura. Describa brevemente cada uno de ellos. Característica FEAT1 FEAT2 FEAT3

Caso de Uso UC1

Descripción Registrar solicitud de Crédito.

UC2

Buscar Inspector.

__________________________________ __________________________________________ CI&*T&C


93

FEAT4

UC3

Asignar Expediente.

FEAT5

UC4

Registrar Inspectorias

FEAT6

UC5

Evaluar Crédito.

FEAT7

UC6

Generar Línea de Crédito.

FEAT8

UC7

Generar Tarjeta de Crédito.

FEAT9 FEAT9 FEAT10 FEAT9

UC8 UC9

Consultar trámites pendientes. Consultar Cliente en INFOCORP.

UC10

Consultar solicitudes x estado.

FEAT9

UC11

Consultar solicitudes mensuales.

FEAT11

UC12

Enviar correo.

FEAT12

UC13 UC14 UC15 UC16

Mantener Cliente Buscar Cliente Mantener Inspector. Ingresar al sistema.

FEAT13

4. Elaborar el diagrama estructurado de casos de uso. Asuma los casos de uso incluidos y/o extendidos y justifíquelos.


CI&*T&C


97

__________________________________ __________________________________________ CI&*T&C


9,

R$%&'$ 

La trazabilidad es una propiedad de los requisitos aplicable al resto del desarrollo que permite conocer las dependencias entre los distintos artefactos que se van generando.



Además, puede consultar las siguientes páginas: 

http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html Este artículo ilustra el uso de IBM Rational Requisite Pro para la trazabilidad de los casos de uso con escenarios y casos de prueba.


CI&*T&C


99


2 TEMA

6 REPASO DE MODELADO DEL NEGOCIO - CAPTURA DE REQUISITOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno modela los artefactos de la disciplina Análisis. Además modula la arquitectura de análisis que da soporte a un proceso de negocio, y diagrama la estructura y el comportamiento de sus funcionalidades mediante diagramas de clases y diagramas de comunicación respectivamente, haciendo uso de la herramienta CASE IBM Rational Software Architect.

TEMARIO - REPASO 1. 2. 3. 4. 5.

Modelado de negocio. Captura de requisitos. Captura de requisitos a partir del Modelado del negocio. Estructurando el Modelo de casos de uso. Priorización de casos de uso.

ACTIVIDADES PROPUESTAS 1. Los alumnos crean los artefactos de las disciplinas modelado de negocio y captura de requerimientos del (los) proceso (s) de negocio mostrados en clase.

__________________________________ __________________________________________ CI&*T&C


1//

1. Modelado del Negocio Es una disciplina opcional de RUP. La necesidad de esta disciplina surge ante el hecho de que muchos de los productos de software que se desarrollan automatizan algunos o todas las actividades de un proceso. Hay que entender cómo funciona el negocio que se desea automatizar y, por esto, se hace un estudio del dominio. Los objetivos de esta disciplina son los siguientes: Entender los problemas actuales en la organización para identificar los aspectos a mejorar. Estudiar el impacto que pueden producir los cambios a nivel organizativo. Asegurar que los involucrados (clientes, usuarios finales, desarrolladores, otros) tengan una visión común de la organización. Obtener los requisitos del sistema de software que darán soporte a los procesos de la organización.

•

• •

•

El Modelo del Negocio proporciona una vista estática de la estructura de la organización y una vista dinámica de los procesos dentro de la organización. El Modelado del Negocio está soportado por dos (2) modelos: Modelo de casos de uso del negocio. Modelo de análisis del negocio.

• •

El Modelo de casos de uso de negocio (MCUN) describe los procesos de negocio de una organización en términos de Actores de Negocio y Casos de uso del Negocio. El Modelo de análisis del negocio (MAN) describe cómo cada caso de uso de negocio es llevado a cabo por un grupo de trabajadores que utilizan entidades del negocio. Los artefactos creados en estos modelos sirven como entrada y referencia para la definición de los requisitos del sistema en la disciplina Captura de Requisitos para el modelo de casos de uso. (Ver figura 6.1).

Figura 6.1 - Artefactos del Modelado de Negocio.


CI&*T&C


1/1

1.1. Actividades para realizar un Modelado de Negocio

El Modelado de Negocio comprende las siguientes actividades (Ver figura 6.2): Modelo de casos de uso del negocio Determinar la situación de la organización Describir el actual negocio Identificar los procesos de negocio Refinar las definiciones de los procesos de negocio • • • •

Modelo de análisis del negocio Diseñar las realizaciones de los procesos de negocio Refinar roles y responsabilidades Explorar procesos automatizados Desarrollar un modelado de dominio • • • •

Figura 6.2 - Actividades del Modelado del Negocio

__________________________________ __________________________________________ CI&*T&C


1/0

1.2. MODELO DE CASOS DE USO DEL NEGOCIO 1.2.1. Determinar la situación de la organización

El objetivo es reconocer el negocio para delimitarlo. Las actividades a realizar son las siguientes: a) Identificar la misión y visión de la organización y/o áreas de estudio que correspondan y plasmarlo en el documento Visión del Negocio. b) Identificar los objetivos del negocio. Los objetivos son determinados por los stakeholders y responsables del negocio. c) Identificar las reglas del negocio. d) Elaborar una lista de glosario de terminos. Se prefiere unir todo lo identificado en el documento Situación del Negocio .

1.2.2. Identificar los procesos de negocio

El equipo debe tener claras las fronteras del negocio. Para ello debe identificar y priorizar los casos de uso del negocio y los actores de negocio. Para mostrar la interacción entre actores y casos de uso del negocio se crea un Diagrama General de Casos de Uso de Negocio . Cada caso de uso del negocio, tiene una breve descripción en un documento Especificación de Caso de Uso del Negocio (ECUN) . Para describir los actores del negocio y su asociación con los casos de uso de negocio, se utiliza el artefacto Actores del Negocio .

1.2.3. Refinar las definiciones de los procesos de negocio

Consiste en los siguientes aspectos: a) Detallar los casos de uso del negocio en su ECUN . b) Describir cómo los casos de uso del negocio soportan los objetivos de negocio. c) Verificar que los casos de uso del negocio representan correctamente cómo el negocio es conducido. Aquí se refina la Especificación de Caso de Uso del Negocio , describiendo paso a paso las actividades que se desarrollan en el proceso de negocio.

1.3. MODELO DE ANÁLISIS DEL NEGOCIO 1.3.1. Diseñar las realizaciones de los procesos de negocio

Consiste en describir como se lleva a cabo las actividades realizadas por los roles (actores y trabajadores del negocio) y las entidades (con sus estados) que fluyen en el proceso. Para la realización de cada proceso del negocio se crea un Diagrama de Clases de Negocio y un Diagrama de Actividades de Negocio . En cada documento Especificación de Caso de Uso del Negocio se puede agregar al final los diagramas de clases y actividades.

1.3.2. Refinar roles y responsabilidades

Consiste en detallar más los documentos Trabajadores del Negocio y Entidades del Negocio.


CI&*T&C


Artefacto

1/

Descripción Documento que contiene la visión del negocio, un glosario de términos del negocio, los objetivos del negocio y reglas del negocio.

Situación del Negocio

Objetivos del Negocio

Casos de Uso del Negocio

Es un requisito que debe ser satisfecho por el negocio. Describe el valor deseado de una medida en particular a futuro, y se utiliza para planear y administrar las actividades del negocio. El objetivo debe ser claro, mesurable, alcanzable, realista y sensible al tiempo. Se permite la relación de dependencia entre objetivos del negocio y la de soporte de un caso de uso del negocio. Define un conjunto de acciones que el negocio lleva a cabo y provee resultados de valor a quienes interactúan con el. Describe un proceso de negocio desde un punto de vista externo que percibe algún tipo de valor. Definen los límites de la organización. Representa un rol que algo o alguien externo desempeña en relación con el negocio. Puede ser asociado a uno o más casos de uso del negocio.

Actor del Negocio

Modelo de Casos de Uso del Negocio

Representa la vista externa del negocio. Modelo que describe la dirección e intención del negocio. La dirección es provista por los objetivos del negocio. Mientras que la intención es expresada por los diagramas que permiten ver cómo interactuar con el entorno. Documento que contiene información de los actores del negocio identificados en el modelo de casos de uso del negocio.

Actores del Negocio

Documento que contiene las características de un proceso de negocio. Se realiza una especificación por cada caso de uso de negocio. Especificación de Caso de Uso del Negocio

Tabla 6.1. Artefactos del Modelo de Casos de Uso del Negocio

__________________________________ __________________________________________ CI&*T&C


1/

Artefacto

Trabajadores del Negocio

Entidades del Negocio

Realización de Caso de Uso del Negocio

Modelo de Análisis del Negocio

Descripción Un trabajador del negocio es un rol interno al negocio. Colabora con trabajadores de otro sector, es notificado sobre acontecimientos del negocio y manipula entidades de negocio para realizar sus responsabilidades. Ente significativo y persistente manipulado por actores del negocio y trabajadores del negocio. Hay dos tipos de entidades: - Informativos (Documentos) - Persistentes (Fichas de datos) Colección de diagramas que muestra cómo los actores y/o trabajadores del negocio y entidades del negocio llevan a cabo el caso de uso del negocio. Generalmente se utilizan Diagramas de Clases y Diagramas de Actividades para realizar el detalle de cada proceso de negocio. Representa la vista interna del negocio. Es un modelo que describe la realización de los casos de uso del negocio. Es una abstracción de cómo los trabajadores del negocio y las entidades de negocio se relacionan y de cómo colaboran para realizar los casos del uso del negocio. Documento que contiene información de los trabajadores del negocio identificados en el modelo de análisis del negocio.

Trabajadores del Negocio

Documento que contiene información de las entidades del negocio identificadas en el modelo de análisis del negocio. Entidades del Negocio

Tabla 6.2. Artefactos del Modelo de Análisis del Negocio


CI&*T&C


1/2

2. Captura de Requisitos

Esta disciplina desarrolla el modelo del sistema a construir. Se utilizan los casos de uso para crear este modelo. Los requisitos funcionales se estructuran mediante casos de uso. Un caso de uso puede contener uno o más requisitos funcionales. Los propósitos de la disciplina Captura de Requisitos son los siguientes: Establecer y mantener los acuerdos con los stakeholders sobre lo que el sistema debe hacer. Proporcionar un mejor entendimiento de los requisitos del sistema a los desarrolladores. Definir las fronteras del sistema. Proveer la base para planificar las iteraciones. Proporcionar la base para estimar los costos y tiempos de desarrollo. Definir las interfaces de usuario.

•

•

• • • •

2.1. Artefactos de la Captura de Requisitos

Los artefactos de la captura de requisitos, mostrado en la siguiente figura, sirven como entrada para el análisis, diseño, implementación y pruebas del sistema.

Figura 6.3 - Artefactos de la Captura de Requisitos.

Artefacto

Visión

Especificación de requisitos de Software

Descripción Documento que define la opinión de los stakeholders del producto que se desarrollará, especificada en términos de necesidades y características claves de los stakeholders. Contiene un esquema de los requisitos previstos, el cual proporciona la base contractual para los requisitos técnicos más detallados. La Especificación de Requisitos de Software es un documento que enfoca la organización completa de los requisitos del proyecto. Comúnmente conocido como SRS por sus iniciales en inglés. Contiene la lista de requisitos funcionales y no funcionales.

__________________________________ __________________________________________ CI&*T&C


1/3

Paquetes de casos de uso

Caso de uso

Es una colección de casos de uso, de actores, de relaciones, de diagramas, y de otros paquetes de ser necesario; y es utilizado para estructurar el modelo de casos de uso dividiéndolo en piezas más pequeñas. Es una funcionalidad específica del sistema con identidad propia, el cual define una secuencia de acciones que el sistema realiza para un actor en particular. Un caso de uso contiene uno o más requisitos funcionales. Representa un rol (humano, hardware o software) externo al sistema con el que se establece intercambio directo de información. Puede ser asociado a uno o más casos de uso.

Actor

Modelo de casos de uso

Es un modelo que captura los requisitos funcionales de los usuarios a un alto nivel y establece la estructura fundamental del sistema. Es un input esencial para las actividades en análisis, diseño y pruebas. Documento que contiene información de los actores identificados en el modelo de casos de uso.

Actor

Especificación de caso de uso

Documento que contiene las características de un caso de uso. Contiene primordialmente una descripción del flujo de eventos que describen la interacción entre los actores y el sistema. La especificación también contiene otra información tal como precondiciones, poscondiciones, requisitos especiales y prototipos. Se realiza una especificación por caso de uso. Documento que especifica los requisitos funcionales que no son traducidos a casos de uso y los requisitos no funcionales.


Tabla 6.3. Artefactos del Modelo de Casos de Uso

2.2. Actividades para realizar la Captura de Requisitos

La disciplina Captura de Requisitos comprende las siguientes actividades: Analizar el problema Entender las necesidades de stakeholders Definir el sistema Administrar el alcance del sistema Refinar la definición del sistema Administrar cambios de requisitos. • • • • • •


CI&*T&C


1/7

Figura 6.4. Disciplina - Captura de Requisitos 2.2.1. Analizar el Problema En el documento Visión se documenta el problema en análisis. Para determinar el alcance inicial del proyecto, los límites del sistema deben ser definidos. El analista de sistema identifica los usuarios y sistemas externos, representado por actores, los cuales interactúan con el sistema. 2.2.2. Entender las Necesidades del Stakeholder El documento visión es refinado. También los requisitos funcionales son expresados como Casos de uso. Los requisitos no funcionales son documentados como Especificaciones suplementarias. Se utilizan técnicas para capturar requisitos, tales como las entrevistas, cuestionarios, prototipos, etc. en las primeras iteraciones de esta disciplina.

__________________________________ __________________________________________ CI&*T&C


1/,

2.2.3. Definir el Sistema Se identifican los actores y los casos de uso a través del Modelo de Casos de uso refinado; además, de los requisitos no funcionales definidos en las especificaciones suplementarias. 2.2.4. Administrar el Alcance del Sistema El alcance del proyecto es definido por el conjunto de requisitos. La clave para manejar el proyecto con éxito es cumpliendo con el tiempo, la gente y el presupuesto. La priorización de los casos de uso permite planificar el proyecto en iteraciones. 2.2.5. Refinar la Definición del Sistema El resultado es una comprensión más profunda de las funcionalidades del sistema expresada en Casos de uso detallados y documentos de Especificaciones suplementarias, Especificación de requisitos de software, Especificaciones de casos de uso y Especificaciones suplementarias. 2.2.6. Administrar los Cambios de Requisitos Los cambios de los requisitos producidos impactan en las disciplinas de análisis, diseño, pruebas, implementación y despliegue. La trazabilidad es establecida para identificar las relaciones entre los requisitos y otros artefactos.

3. Captura de requisitos a partir del Modelado de negocio

El analista construirá un diagrama de casos de uso inicial, tomando como punto de partida los diagramas de actividades de los casos de uso del negocio. Los requisitos funcionales se obtienen a partir de las actividades candidatas a ser informatizadas. Luego, con estos requisitos se crean los casos de uso. Los actores se identificarán a partir de los roles (trabajadores o actores del negocio) que ejecutan las actividades a informatizar.

Figura 6.5 - Del Modelo del Negocio al Modelo de Casos de Uso Es importante documentar el seguimiento de estos elementos: actividades a informatizar, requisitos funcionales y casos de uso. Más aún, si se trata de seguir requisitos funcionales de casos de uso, el cual es un proceso complicado por el hecho de que existe una relación muchos a muchos entre ellos. Un caso de uso puede tener muchos requisitos funcionales y un requerimiento funcional puede estar en varios casos de uso.


CI&*T&C


1/9

Un buen enfoque es crear una matriz (en excel) denominada Matriz de Actividades Vs. Requisitos. La plantilla se muestra en la siguiente Tabla:

Matriz de Actividades Vs. Requisitos del Sistema ro4eso de "e5o4io

A4ti6idad de "e5o4io

*esponsa8e de "e5o4io

*euisito R(' R(* R(+ R(, R(R(.

Proceso '

Proceso *

Caso de so

A4tores

U)(' U)(* U)(+ U)(, U)(U)(.

Tabla 6.4. Plantilla de Matriz de Actividades Vs. Requisitos No todos los requisitos son explícitos en los procesos de negocio. Aquellos requisitos que tienen que ver con mantenimientos, consultas, reportes, seguridad, otros lo podemos agregar en la Matriz de Requisitos Adicionales del sistema, tal como se muestra en la siguiente tabla. Los casos de usos adicionales también deben ser incluidos en el Diagrama de casos de uso final del sistema. Matriz de Requisitos Adicionales < Nombre del sistema> Paquete

Requisito Funcional

Caso de Uso

Actores

Tabla 6.5. Plantilla de requisitos adicionales

4. Estructurando el Modelo de Caso de Uso 4.1. ¿Qué es estructurar?

Se realiza después de identificar los actores y casos de uso en un diagrama de caso de uso inicial. Luego se detallan los casos de uso a través de la Especificación de casos de uso. Por último se estructura el modelo, esto quiere decir agregar los casos de uso incluidos, extendidos y generalizados. Estructurar, significa separar en partes el caso de uso para hacer menos casos de uso. Esto se hace para… Simplificar el caso de uso original Fácil entendimiento y mantenimiento Reutilizar el comportamiento Compartir entre los casos de uso. • • • •

__________________________________ __________________________________________ CI&*T&C


11/

4.2. Relaciones

Figura 6.6. Relaciones entre casos de uso 4.2.1. Relación de Inclusión Dependencia entre dos (2) casos de uso (<>). El caso de uso base depende del caso de uso incluido. El caso de uso incluido ocurre obligatoriamente en el caso de uso base. Al caso de uso base le interesa el resultado del caso de uso incluido. Se extrae comportamiento común del caso de uso y simplifica el caso de uso complejo El caso de uso incluido es ABSTRACTO, es decir sólo ocurre en el contexto de otro. No puede ser iniciado de forma independiente por un Actor. •

•

•

•

•

Figura 6.7. Relación de Inclusión


CI&*T&C


111

4.2.2. Relación de Extensión Dependencia entre dos (2) casos de uso (<>). El caso de uso extendido depende del caso de uso base. El caso de uso extendido ocurre excepcionalmente (opcional) en el caso de uso base. Al caso de uso base le interesa el resultado del caso de uso extendido. Extrae el comportamiento opcional y simplifica un caso de uso complejo El caso de uso excepcional es ABSTRACTO En ocasiones puede ser iniciado de forma independiente por un Actor. •

•

•

•

• •

Figura 6.8. Relación de Extensión 4.2.3. Relación de Generalización entre Casos de Uso Relación de un caso de uso hijo con un caso de uso padre. Describe el comportamiento general compartido por el padre Describe el comportamiento especializado en el Hijo • • •

Figura 6.9. Relación de Generalización entre Casos de uso __________________________________ __________________________________________ CI&*T&C


110

4.2.4. Relación de Generalización entre Actores Actores con característica comunes. •

Figura 6.10. Relación de Generalización entre Actores

5. Priorización de casos de uso

El propósito de la priorización es identificar los casos de uso primarios para la presente etapa de desarrollo del proyecto. La priorización permitirá darle la debida atención (y con mas tiempo) a los casos de uso más complejos e importantes. 5.1. Priorización Distingue los casos de uso críticos o primarios de los secundarios. Nivel crítico (o primario), agrupa los casos de uso que tienen que ver con las funciones básicas del sistema. Nivel de baja importancia (o secundario), agrupa a los casos de uso que tienen que ver con las funciones de soporte del sistema y que no representan mayor riesgo para el proyecto. •

•

5.2. Factores tomados en cuenta en la priorización Se toman en cuenta los pesos (que representan porcentaje) por cada factor que afecta a cada caso de uso. Los valores que pueden tomar los factores están en la escala del 1 al 10 (1: menor importancia; 10: mayor importancia). Se considerarán primarios a los casos de uso que tengan un puntaje mayor a 6.5. Importancia en el proceso del negocio (0.4): Indica la relevancia que tiene la funcionalidad en el proceso de negocio. Una alta puntuación revela que las transacciones de la empresa se apoyan considerablemente en la funcionalidad. Complejidad de desarrollo (0.3): Indica la dificultad que se percibe del caso de uso, en cuanto a las tareas de análisis, diseño, implementación, pruebas e integración del mismo. Riesgo Asociado (0.2): Indica la relación que se percibe del caso de uso con la lista de riesgos. Un alto valor en este factor indica que el caso de uso •

•

•


CI&*T&C


•

11

tiene bastantes riesgos asociados. Los casos de uso con alto valor en este factor pueden ser considerados primarios debido a que deben ser enfrentados en las etapas iniciales. Impacto de los requerimientos no funcionales (0.1): Indica como afectan los requerimientos no funcionales (FURSP +) al proceso del negocio y en qué manera se vería comprometido.

5.3. Tabla de priorización de los casos de uso Como se mencionó anteriormente, los USE CASE primarios serán aquellos que presenten un puntaje mayor a 6.5. Los valores que se ponen a los criterios van de 1 a 10. Cada criterio tiene un ponderado (de 0.1. a 0.4), tal como se muestra en la siguiente tabla. 0.4

0.3

0.2

0.1

Importancia

Complejidad

Riesgo

Impacto

10

5

7

8

8.1

Caso de uso 2 Caso de uso 3 Caso de uso 4 Caso de uso 5

10 9 9 9

7 7 7 4

9 9 9 10

6 8 7 9

8.68 8.52 8.4 8.4

Caso de uso 6

9

6

7

8

7.74

Caso de uso 7 Caso de uso 8 Caso de uso 9 Caso de uso 10 Caso de uso 11 Caso de uso 12 Caso de uso 13 Caso de uso 14 Caso de uso 15 Caso de uso 16 Caso de uso 17 Caso de uso 18

6 10 8 7 7 7 7 8 7 8 7 7

8 4 7 5 5 7 6 5 5 3 4 5

9 7 6 8 7 7 7 6 5 4 6 5

8 4 5 6 8 5 4 3 8 6 2 2

7.5 7.3 6.86 6.82 6.76 6.76 6.46 6.26 6.16 5.66 5.56 5.44

CASOS DE USO Caso de uso 1

Total

Tabla 6.6. Lista de Priorización de casos de uso

__________________________________ __________________________________________ CI&*T&C



ACTIVIDADES PROPUESTAS En base al caso propuesto, identificar los siguientes artefactos: 1. Modelo de casos de Uso del negocio Objetivos del negocio Actores del negocio Casos de uso del negocio Diagrama de casos de uso del negocio. 2. Modelo de análisis de negocio Trabajadores del negocio Entidades del negocio Realizaciones del negocio – Diagrama de actividades. 3. Modelo de caso de uso del sistema Matriz de actividades del negocio Vs. requisitos Matriz de requisitos adicionales Diagrama general de caso de uso estructurado. Lista de priorización de casos de uso. • • • •

• • •

• • • •

Nota.- Esta actividad es un repaso de las disciplinas Modelado del Negocio y Captura de Requisitos.

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 5

CASO – SISTEMA DE VENTAS Y CONTROL DE ALMACÉN La problemática actual es la utilización de los recursos humanos en el área de almacén que se ve afectada negativamente por la falta de control de tiempos y la priorización en la entrega de productos. Además, existe una falta de sincronización entre la elaboración de pedidos del área de ventas y la gestión de existencias e inventarios del área de almacén. El presente proyecto se va a referir al “Sistema de Ventas y Gestión de Almacén” de la empresa CIMAQ SA, la cual se dedica a la compra, venta y alquiler de maquinaria ligera, equipos, repuestos y materiales. Además ofrece el servicio de postventa que permite ofrecer a los clientes la seguridad y tranquilidad que necesitan para concentrarse en sus negocios y saber que sus empresas pueden operar al máximo en cualquier lugar del Perú. Mediante la utilización de diferentes herramientas, el objetivo principal será el crear un sistema el cual de solución a los problemas ya señalados. Una aplicación que controle las actividades del almacén, asignando tiempos a las tareas e indicando las responsabilidades al personal. Además de integrar un modulo de ventas para generar pedidos basándose en la disponibilidad del stock y un módulo de control de existencias, que permita saber con exactitud qué productos están disponibles y cuales necesitan reabastecimiento. El alcance del proyecto se concentrará en el área de logística. Se van a identificar procesos, actividades, trabajadores, etc.; y se realizará la captura de requisitos por medio de entrevistas que se realizarán a los responsables de las áreas afectadas. Los procesos identificados son las siguientes: 1. Venta de Repuestos 2. Entrega de Repuestos 3. Abastecimiento de Almacén.

CIBERTEC


ANALISIS Y DISEÑO DE SISTEMA II (TEORIA) 6

ECUN – Venta de Repuestos

1. Introducción El presente documento Especificación de Caso de Uso de Negocio proporciona la información necesaria para describir el proceso de Venta de Repuesto desde el punto de vista del negocio. 1.1. Propósito Este documento tiene como propósito definir el flujo básico y alternativo del proceso Venta de Repuesto. También, identificar los objetivos, riesgos, posibilidades, entre otros; de dicho proceso. 1.2. Alcance El documento nos ayudará a tener una mejor perspectiva del proceso Venta de Repuesto, facilitando la identificación de quienes intervienen y los roles que cumplen, así como las entidades que son parte del proceso de negocio. 1.3. Definiciones, Acrónimos y Abreviaciones RVRS: Representante de ventas de repuestos y servicios. ACR: Analista de compra de repuestos. 1.4. Referencias Las referencias al presente documento son las siguientes: Entrevista con el personal de Ventas Entrevista al Gerente General Entrevista al Jefe de Proyectos y Procesos 2. Venta de Repuestos 2.1. Breve descripción Este proceso consiste en el paso a paso de la venta del repuesto al cliente, desde el momento que el cliente realiza un requerimiento de repuesto, hasta que el Analista de Compra de Repuesto envía la documentación a almacén. 3. Objetivos 3.1. Aumentar las ventas de la línea GC PRIME. 3.2. Incrementar las ventas en general. 3.3. Lograr una mayor rentabilidad sobre el patrimonio. 4. Rendimiento de Objetivos 4.1 Cerrar las ventas del año vigente con un incremento del 30 % en la línea GC Prime con respecto al año pasado. 4.2 Aumentar las ventas al 40 % en todos los tipos de repuestos con relación a años anteriores. 4.3 Disminuir el precio de los repuestos en un 10 % para sacar mayor beneficio de estos. 5. Flujo de Trabajo 5.1. Flujo Básico 1. El Caso de Uso de Negocio inicia cuando el cliente solicita un requerimiento de repuesto al RVRS. 2. El RVRS evalúa el requerimiento solicitado. 3. El RVRS prepara la cotización del pedido. 4. El cliente revisa la cotización y acepta las condiciones establecidas. 5. El RVRS verifica si el cliente es nuevo. 6. El RVRS genera un pedido de repuestos. 7. El cliente le indica al RVRS que la modalidad de pago es a crédito. 8. El Jefe de créditos y cobranzas aprueba el crédito del cliente por la compra del repuesto. 9. El RVRS recopila toda la información del pedido. 10. El ACR revisa las condiciones del pedido. 11. El ACR verifica disponibilidad de stock en almacén. 12. El RVRS envía el pedido a facturación y finaliza el proceso. • • •


CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 7

5.2. Flujos Alternativos 4.1. Rechazar Cotización El cliente rechaza la cotización entregada por el RVRS y el proceso finaliza. 5.1. Registrar Datos del Cliente Si e cliente es nuevo, el RVRS registra los datos del nuevo cliente. 7.1. Forma de Pago al contado El cliente le indica al RVRS que la modalidad de pago será al contado. 8.1. Rechazar crédito El Jefe de créditos y cobranzas rechaza el crédito para cliente y el proceso finaliza. 11.1. Stock no disponible El ACR verifica que no hay stock no disponible 11.1.1. Gestionar Compra de Repuestos El ACR inicia el proceso Abastecimiento de Almacén con un proveedor. 6. Categoría El caso de uso de negocio, Venta de repuestos, pertenece a la categoría de los procesos núcleo ya que influye sobre diferentes áreas de la empresa y tienen impacto en el cliente. 7. Riesgos No poder abastecer a los clientes con los repuestos requeridos, cuando exista una mayor demanda en el mercado. 8. Posibilidades Mejorar la atención al cliente en la venta de repuestos, facilitándole una gran gama de posibilidades de elección y un servicio eficiente, rápido y confiable. 9. Propietario del proceso El propietario, encargado de administrar y manejar este caso de uso de negocio, es el representante de ventas de repuestos y servicios. 10. Pre-condición El requerimiento de compra del cliente. 11. Post-condición Generación y envío de la Orden de almacén. 12. Requisitos especiales El presente caso de uso de negocio no presenta requisitos especiales. 13. Puntos de extensión El proceso extiende a Abastecimiento de Almacén. •

CIBERTEC



CIBERTEC



"

Matriz de Actividades Vs. Requisitos del Sistema - SVGA .ro4eso de "e5o4io

A4ti6idad de7 "e5o4io )olicitar requerimiento de venta Preparar coti1ación de venta #erificar liente

;enta de repuestos

*esponsa87e de7 "e5o4io

*e9uisito

Caso de :so

A4tores

liente

R(' Re$istrar requerimiento de venta

U)('

Re$istrar Requerimiento de #enta /n 0ine

liente

R#R)

R(* 2enerar coti1ación de venta

U)(*

2enerar oti1ación de #enta

R#R)

R#R)

R(+ 3uscar liente

U)(+

3uscar liente

R#R)

Re$istrar liente

R#R)

R(, Re$istrar liente

U)(,

R#R)

2enerar Pedido

R#R)

R(- 2enerar Pedido de #enta

U)(-

4antener liente 2enerar /rden de Pedido de #enta

Evaluar r5dito

6efe de 

#erificar stoc9

AR

R(. Apro!ar r5dito R(7 Rec8a1ar r5dito R(: onsultar stoc9 de repuesto

U)(.

Evaluar r5dito

6efe 

U)(7

onsultar stoc9 de repuestos

AR

&ntre5a de *epuestos

A8aste4imiento de A7ma4
CIBERTEC

R#R)


ANALISIS Y DISEÑO DE SISTEMA II (TEORIA)

2#

Matriz de Requisitos Adicionales - SVGA Paquete

Reuestos


Requisito Funcional

Caso de Uso

Actores

RF09 Buscar Repuesto

CUS08 Buscar Repuesto

Jefe de Almacén, Operario de Almacén, Cliente

RF10 Arear Repuesto RF11 Actuali"a Repuesto RF1# $liminar Repuesto

CUS09

Jefe de Almacén, Operario de Almacén

!antener Repuesto

CIBERTEC


ECUN – ENTREGA DE REPUESTOS

1. Introducción El presente documento Especificación de Caso de Uso de Negocio proporciona la información necesaria para describir el proceso de Entrega de Repuestos desde el punto de vista del negocio. 1.1. Propósito Este documento tiene como propósito definir el flujo básico y alternativo del proceso Entrega de Repuestos. También, identificar los objetivos, riesgos, posibilidades, entre otros, del proceso. 1.2. Alcance El documento nos ayudará a tener una mejor perspectiva del proceso Entrega de Repuestos, facilitando la identificación de quienes intervienen y los roles que cumplen, así como las entidades que son parte del proceso de negocio. 1.3. Definiciones, Acrónimos y Abreviaciones O/A: Orden para Almacén. EF: Encargado de Facturación. 1.4. Referencias Las referencias al presente documento son las siguientes: Entrevista a personal de almacén Entrevista al Gerente General Entrevista al Jefe de Proyectos y Procesos. 2. Entrega de Repuestos 2.1. Breve descripción Este proceso consiste en la entrega de repuesto (s) al cliente, desde el momento que el personal de almacén recibe la documentación para el despacho, proveniente de facturación, hasta la entrega al cliente. 3. Objetivos 3.1. Reducir el tiempo de atención de repuestos. 3.2. Aumentar la satisfacción del cliente. 4. Rendimiento de Objetivos 4.1. Realizar el empaque de repuesto en un máximo de 2 horas. 4.2. Disminuir el tiempo de entrega de repuesto (s) en un 50%. 5. Flujo de trabajo 5.1. Flujo básico 1. El proceso se inicia cuando el EF envía a almacén el comprobante de pago y la ficha de pedido. 2. El coordinador de almacén elabora la O/A a partir de la ficha de pedido. 3. El Coordinador de almacén deja la O/A en la bandeja de Almacén. 4. El Operario de almacén recepciona la O/A en la bandeja del Almacén. 5. El Operario de Almacén pone en cajas los repuestos que pertenecen a una misma O/A. 6. El Operario de almacén avisa al Coordinador de Almacén que está lista la O/A para entregar. 7. El coordinador del Almacén ordena la entrega de los repuestos. 8. El operario de almacén elabora la guía de remisión para la entrega de los repuestos. 9. El operario de almacén envía los repuestos y la documentación (comprobante de pago y guía de remisión) al transportista. 10. El transportista entrega los repuestos al cliente y trae la guía con cargo firmado. 11. El operario de almacén envía la guía de remisión con cargo firmado y la copia de comprobante de pago al EF y finaliza el proceso. 5.2. Flujos alternativos Ninguno. • • •

CIBERTEC


ANALISIS Y DISEÑO DE SISTEMA II (TEORIA) 22

6. Categoría El caso de uso de negocio, entrega de repuestos, pertenece a la categoría de procesos de soporte, ya que da apoyo al proceso núcleo Venta de Repuestos. 7. Riesgos Retrasar la entrega del repuesto, o peor aún, que el producto no llegue a su destino. Entregar un paquete de repuestos que no contenga los repuestos solicitados solicitad os por el cliente. 8. Posibilidades Lograr satisfacer al cliente a la hora de la entrega del repuesto, sin demoras ni retrasos. 9. Propietario del proceso El propietario, encargado de administrar y manejar este caso de uso de negocio, es el coordinador de almacén. 10. Pre-condición La facturación del pedido del cliente y entrega de la documentación necesaria (guías, facturas). 11. Post-condición Entrega de la documentación documentación (cargos firmados) f irmados) a facturación. 12. Requisitos especiales El área de créditos debe aprobar el crédito del cliente para despachar el producto. 13. Puntos de extensión No hay puntos de extensión. •

•

____________________ ______________________________ ____________________ ___________________ ___________________ ____________________ __________

ECUN – ECUN – ABASTECIMIENTO DE ALMACÉN

1. Introducción El presente documento Especificación de Caso de Uso de Negocio proporciona la información necesaria para describir el proceso de Abastecimiento de Almacén desde el punto de vista del negocio. 1.1. Propósito Este documento tiene como propósito definir el flujo básico y alternativo del proceso Abastecimiento de Almacén . También, identificar los objetivos, riesgos, posibilidades, entre otros; de dicho proceso. 1.2. Alcance El documento nos ayudará a tener una mejor perspectiva del proceso Abastecimiento de Almacén, facilitando la identificación de quienes intervienen y los roles que cumplen, así como las entidades que son parte del proceso de negocio. 1.3. Definiciones, Acrónimos y Abreviaciones Abreviaciones ACR: Analista de Compra de Repuestos. O/C: Orden de Compra. 1.4. Referencias Las referencias al presente documento son las siguientes: Entrevista a personal de Logística Logística Entrevista al al Gerente Gerente General General Entrevista al Jefe Jefe de Proyectos Proyectos y Procesos. Procesos. 2. Abastecimiento de Almacén 2.1. Breve descripcion Este proceso consiste en el paso a paso del abastecimiento de almacén, desde el momento que el Analista de Compra de Repuesto prepara el requerimiento de compra, hasta el momento que se envian los documentos a facturación. f acturación. • • •


CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 23

3. Objetivos Ampliar el stock de repuestos en la línea GC. Aumentar la satisfacción del cliente. 4. Rendimiento de Objetivos 4.1. Aumentar la disponibilidad de repuestos de la línea GC en 30%. 4.2. Reducir el tiempo t iempo de reposición de repuestos a 10 días como máximo. 5. Flujo de trabajo 5.1. Flujo básico 1. El proceso se inicia cuando el ACR elabora el requerimiento requerimient o de compra. 2. El ACR envía el requerimiento requerimi ento de compra al proveedor. 3. El proveedor recibe el requerimiento requerimien to de compra y prepara la cotización del repuesto(s). 4. El proveedor proveedor envía la cotización de compra al ACR. 5. El ACR recibe y evalúa la cotización de compra y acepta la cotización. 6. El ACR prepara la orden de compra de repuestos. 7. El ACR envía la orden de de compra al proveedor y al almacén. 8. El Proveedor prepara los repuestos solicitados solicitados y los envía adjuntando la documentacion documentacion respectiva. 9. El Operario de Almacen recibe recibe los repuestos y la documentacion documentacion respectiva respectiva del proveedor y el ACR. (O/C, Guia, Comprobante de pago). 10. El operario de almacén verifica la O/C con los repuestos entregados por el proveedor. 11. El operario de almacen ingresa los repuestos al inventario generando una nota de ingreso. 12. El operario de almacén envía los documentos (Nota de Ingreso, Factura y Guía) al área de Facturación y finaliza el proceso. 5.2. Flujos Alternativos 5.1. Rechazar Cotización El ACR rechaza la cotización de compra, y el proceso finaliza. finaliza. 10.1. Entrega no conforme El operario de almacén se percata de que la entrega no está conforme. 10.1.1. Elaborar incidencia El operario de almacén elabora una incidencia de entrega. 10.1.2. Notificar Incidencia El operario de almacén notifica de la incidencia al ACR. 6. Categoría El caso de uso de negocio, abastecimiento de almacen, pertenece a la categoría de procesos de soporte, ya que da apoyo al proceso núcleo, Venta de Repuesto. 7. Riesgos No tener el producto solicitado solicitado por el cliente y así no poder cumplir con lo pedido. pedido. Retrasar Retrasa r la entrega del repuesto, debido a una mala gestión de la compra. 8. Posibilidades Mantener un óptimo stock de repuestos para satisfacer cualquier pedido del cliente. 9. Propietario del proceso El propietario, encargado de administrar y manejar este caso de uso de negocio, es el analista de compras de repuesto. 10. Pre-condicion Preparar el requerimiento de compra y entrega de la documentación necesaria. 11. Post-condicion Óptimo stock de almacén almacén y documentación en facturación. facturación. 12. Requisitos especiales La evaluación de la cotización debe ser aceptada para que posteriormente se prepare la orden de compra. 13. Puntos de extensión No hay puntos de extensión • •

CIBERTEC



R$%&'$ 

El Modelado del Negocio nos permite comprender comprender los procesos de negocio de la organización en estudio.



El Modelo de Casos de Uso del Negocio es un modelo elaborado bajo una perspectiva externa del negocio – Actores del negocio con Casos de Uso del Negocio.



El Modelo de Análisis del Negocio detalla cómo el proceso de negocio es ejecutado internamente – Roles (Actores y Trabajadores del negocio con Entidades).



Si desea saber más acerca de estos temas, puede consultar las siguientes páginas.

http://www-128.ibm.com/developerworks/rational/library http://www-128.ibm.com/developerworks/ra tional/library/5167.html /5167.html Aquí hallará una descripción de los elementos del modelado de negocio.  En la Captura de Requisitos se describe las condiciones o capacidades que el sistema debe cumplir. 



La identificación de los requisitos funcionales llevará a la proyección de las funciones del sistema (casos de uso).

 La

descripción de los requisitos no funcionales facilitarán la construcción de la plataforma del sistema.



La Matriz de Actividades Vs. Requisitos es una técnica técnica utilizada para documentar documentar la trazabilidad de actividades Vs. requisitos funcionales y de requisitos funcionales Vs. casos de uso.



Si desea saber más acerca de estos temas, temas, puede consultar los siguientes siguientes libros: del Software” de Ian Sommerville Sommerville  “Ingeniería del En el capítulo 6 encontrará información sobre requisitos del sistema y en el capítulo 7, se profundiza el tema de la ingeniería de requisitos.  “UML 2” de Jim Jim Arlow e Ila Ila Neustadt En el capítulo 3 encontrará información sobre la captura de requisitos.


CIBERTEC



2 TEMA

7 ANÁLISIS ORIENTADO A OBJETOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno modela los artefactos de la disciplina Análisis. Además modula la arquitectura de análisis que da soporte a un proceso de negocio, y diagrama la estructura y el comportamiento de sus funcionalidades mediante diagramas de clases y diagramas de comunicación respectivamente, haciendo uso de la herramienta CASE IBM Rational Software Architect.

TEMARIO 1. Análisis Orientado a Objetos. 2. Modelo de Análisis. 3. Análisis de la arquitectura.

ACTIVIDADES PROPUESTAS 1. Los alumnos crean la arquitectura de análisis a partir de un diagrama de casos de uso estructurado trabajado en clase, a partir de las disciplinas Modelado del Negocio y Captura de Requisitos.

CIBERTEC



1. ANÁLISIS ORIENTADO A OBJETOS El Análisis Orientado a Objetos es parte de la disciplina Análisis y Diseño de RUP, la cual tiene como propósito: Transformar los requisitos en un diseño del sistema a crear. Definir una arquitectura robusta para el sistema. Adaptar el diseño para que funcione en el ambiente de implementación, diseñándolo para el desempeño esperado.

• • •

El flujo de trabajo de Análisis y Diseño toma artefactos documentados en los flujos de trabajo Modelado del Negocio y Captura de Requisitos; y los traslada a elementos de análisis y/o diseño que serán usados para construir el sistema. Realizando varias actividades y modelos, el flujo de trabajo de Análisis y Diseño busca transformar la información obtenida de los stakeholders en información que los analistas programadores podrán usar para su posterior implementación. El flujo de trabajo de esta disciplina se muestra en la siguiente figura.

Figura 7.1 - Flujo de Trabajo de la disciplina Análisis y Diseño En la fase de inicio, la disciplina de Análisis y Diseño se preocupa por establecer si la visión del sistema es factible, y en determinar las tecnologías potenciales para la solución de software (actividad Perform Architectural Synthesis ). Si se considera que el desarrollo tiene pocos riesgos asociados (porque el dominio se entiende muy bien, el sistema no es novedoso o cualquier otra razón parecida); entonces, ésta actividad se omite del flujo de trabajo.


CIBERTEC


En la parte inicial de la fase de elaboración se enfoca en crear la Arquitectura inicial del sistema (actividad Define a Candidate Architecture ) la cual proporcionará un punto inicial para todo el trabajo de análisis. Si la arquitectura ya existe (fue creada en iteraciones anteriores o en proyectos anteriores) el trabajo se enfoca en refinar la arquitectura (actividad Refine the Architecture ), y en analizar el comportamiento y crear un conjunto inicial de elementos los cuales proporcionarán un comportamiento apropiado (actividad Analyze Behavior ). Después de que los elementos iniciales son identificados, se refinan en iteraciones futuras. La actividad Design Components produce un conjunto de componentes los cuales proveen un comportamiento adecuado para satisfacer los requisitos del sistema. Si el sistema incluye una base de datos, entonces la actividad Design the Database se ejecuta en paralelo. El resultado es un conjunto inicial de componentes, los cuales en un futuro son refinados en la disciplina de Implementación.

1.1. Artefactos del Análisis

En la disciplina de Análisis y Diseño son muchos los artefactos que definen cómo se implementará el sistema. En el curso consideraremos los tipos de artefactos orientados al análisis, éstos son: Modelo de Análisis. Elementos del modelo de análisis: paquetes de análisis, clases de análisis y realizaciones de análisis de casos de uso. Diagramas de realizaciones de análisis de casos de uso: diagrama de clases y diagramas de comunicación. • •

•

Artefacto

Modelo de Análisis

Paquete de Análisis

Clase Interfaz

Clase Control

Descripción Representa la vista interna del sistema. Define un modelo de objetos que describe la realización de casos de uso, y que sirve como abstracción para el modelo de diseño. Los paquetes del análisis proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables. Un paquete de análisis contiene clases y realizaciones de casos de uso a nivel de análisis. Es una clase utilizada para modelar la interacción entre el entorno del sistema y su funcionamiento interno. Modela las partes del sistema que dependen de su entorno. Representa la lógica de negocio de la aplicación, es decir, el control, la coordinación y la secuencia entre objetos. Encapsula el comportamiento de uno o más casos de uso. Tabla 7.1. Artefactos del Análisis.

CIBERTEC


ANALISIS Y DISEÑO DE SISTEMA II (TEORIA) 2!

Clase Entidad

Realización de Caso de Uso

La entidad es una clase utilizada para modelar la información y comportamiento asociado que deben ser almacenados. Modela las partes del sistema que son independientes de su entorno. La realización de análisis de un caso de uso es una colaboración que describe cómo se realiza el caso de uso en términos de clases de análisis y sus interacciones. El diagrama de clases describe la estructura estática de un caso de uso. Muestra las clases de análisis que participan en un caso de uso.

Diagrama de Clases

Diagrama de interacción que describe el comportamiento dinámico del caso de uso centrado en cómo es la comunicación entre los objetos (instancia de una clase) participantes. Diagrama de Comunicación

Tabla 7.1. Artefactos del Análisis (Continuación).

2. Modelo de Análisis

La disciplina de análisis orientado a objetos lo contiene el Modelo de Análisis, el cual es usado para representar la estructura global del sistema, describe las realizaciones de casos de uso y sirve como una abstracción del Modelo de Diseño. Durante el análisis, se identifican los paquetes del análisis, las clases y requisitos comunes a medida que el modelo evoluciona. Las actividades que se realizan en el modelo son las siguientes: Análisis de la Arquitectura Análisis de Casos de Uso Análisis de Clases y Análisis de Paquetes. • • • •

Según Ivar Jacobson “El modelo de análisis es un nivel de diseño intermedio entre la etapa de captura de requisitos y la de diseño ”. El modelo no es un diagrama final que describe todos los posibles conceptos y sus relaciones. Este artefacto es opcional, pero también tiene a su vez la propiedad de ser temporal en el caso en que se planea su desarrollo. Su utilidad radica en que permite una apreciación global conceptual del sistema. A diferencia del Modelo de Casos de Uso que captura la funcionalidad del sistema, el Modelo de Análisis da forma a la arquitectura para soportar las funcionalidades que en el anterior modelo se expresa.


CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 2"

Características principales: Proporciona un diseño preliminar, pues contiene paquetes que se usan para organizar el modelo en piezas más manejables, que representan abstracciones o subsistemas y es una primera vista del diseño. Puede ayudar a descubrir la necesidad de clases adicionales Ayuda a completar los casos de uso antes de pasar al diseño Proporciona un diseño preliminar de la arquitectura del sistema, denotando los paquetes de análisis de alto nivel. •

• • •

El modelo de análisis contiene los siguientes artefactos: Diagrama de Arquitectura de Análisis, el cual muestra los paquetes de análisis y sus dependencias. Paquete de análisis, el cual contiene realizaciones de casos de uso y clases de análisis Clases de análisis, son de tres tipos: boundary, control y entity y los cuales representan elementos del patrón MVC (Model View Controller) Realización de caso de uso a nivel de análisis, es una colaboración que contiene diagramas de clases y diagramas de interacción para definir la estructura y comportamiento del caso de uso respectivamente Modelo Conceptual, es un diagrama de clases que muestra todas las clases del tipo entity c onocido también como Modelo del Dominio. •

•

•

•

•

2.1. Modelo de Casos de Uso Vs. Modelo de Análisis

El siguiente cuadro muestra una comparación entre el modelo de casos de uso y el modelo de análisis: Modelo de Casos de Uso

Descrito con el lenguaje del cliente. Vista externa del sistema. Estructurado por los casos de uso. Utilizado como contrato entre el cliente y los desarrolladores sobre qué debería y qué NO debería hacer el sistema. Puede contener redundancias, inconsistencias entre los requisitos. Captura la funcionalidad del sistema, incluida la funcionalidad significativa para la arquitectura. Define los casos de uso que se analizarán con más profundidad en el modelo de análisis.

Modelo de Análisis

Descrita en el lenguaje de los desarrolladores. Vista interna del sistema. Estructurado por clases y paquetes estereotipados. Utilizado por los desarrolladores para comprender como debería darse forma al sistema, es decir, cómo debe estar diseñado e implementado. No debería contener redundancias, inconsistencias entre los requisitos. Esboza cómo llevar a cabo la funcionalidad dentro del sistema, incluida la funcionalidad significativa para la arquitectura. Define las realizaciones de casos de uso, y cada una de ellas representa el análisis de un caso de uso del modelo de casos de uso.

Tabla 7.2. Comparación entre el MCU y MA

3. Análisis de la Arquitectura El responsable de esta actividad es el Arquitecto de software. Permite definir una arquitectura candidata basada en la experiencia obtenida de sistemas similares o en dominios del problema similares y restringir las técnicas arquitectónicas a ser usadas en el sistema.

CIBERTEC


ANALISIS Y DISEÑO DE SISTEMA II (TEORIA) 3#

Se definen los diagramas de las vistas arquitectónicas, mecanismos claves y los modelos para el sistema. Cabe destacar que analizar la arquitectura resulta beneficioso para sistemas nuevos. El propósito del análisis de la arquitectura es esbozar el modelo de análisis y la arquitectura mediante la identificación de paquetes del análisis, clases de análisis de entidad evidentes y requisitos especiales comunes.

3.1. Pasos a realizar

El Análisis de la Arquitectura se realiza de la siguiente manera: Identificar los paquetes de análisis Definir las dependencias entre los paquetes de análisis Identificar las clases de entidad obvias por cada paquete de análisis Identificar los requisitos especiales comunes Identificar las características fundamentales de un requisito especial. 3.1.1. Identificar los paquetes de análisis Los paquetes de análisis constituyen una división del sistema de software que tiene sentido desde el punto de vista de los expertos en el dominio. Una identificación inicial de los paquetes se hace de manera natural basándonos en los requisitos funcionales y en el dominio del problema, es decir, en la aplicación o proceso de negocio que estamos considerando. • • • • •

Debido a que los requisitos funcionales se capturan en la forma de casos de uso, una forma directa de identificar paquetes del análisis es asignar la mayor parte de un cierto número de casos de uso a un paquete en concreto. Entre las asignaciones adecuadas de casos de uso a un paquete en concreto se tienen las siguientes: a) Los casos de uso requeridos para dar soporte a un determinado proceso de negocio. b) Los casos de uso requeridos para dar soporte a un determinado actor del sistema. La identificación de los paquetes se basa en lo siguiente: a) Tener un diagrama de casos de uso con los roles bien definidos. b) Los casos de uso que estén bajo la responsabilidad de un actor deben tener contenidos estrechamente relacionados. c) Los casos de uso que están relacionados mediante relaciones de generalización deben pertenecer al mismo paquete.

Figura 7.2. Casos de Uso con relación de generalización


CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 3

d) Los casos de uso relacionados mediante relaciones de extensión y solo se extienden a partir de un caso de uso base deben pertenecer al mismo paquete del caso de uso base.

Figura 7.3. Casos de uso con relación de Extend e) Los casos de uso incluidos tienden a generar su propio paquete la mayor parte de veces. Si los casos de uso base, que incluyen al caso de uso, son funcionalidades con distintos contenidos; entonces, se debe crear un paquete para el caso de uso incluido.

==in4ude>>

Figura 7.4. Casos de uso con relación de include 3.1.2. Definir las dependencias entre paquetes de análisis El objetivo es conseguir paquetes que sean relativamente independientes y débilmente acoplados pero que posean una cohesión interna alta. Es inteligente intentar reducir el número de relaciones entre clases en paquetes diferentes debido a que ello reduce las dependencias entre paquetes.

Figura 7.5. Características de los paquetes de análisis

CIBERTEC



Los paquetes identificados se organizarán en la “ Capa de Aplicación”, la cual se subdivide en dos capas internas: Capa Específica: Aquí se ubican los paquetes identificados con excepción de los reutilizables (Nivel Superior). Capa General: Aquí se ubican los paquetes reutilizables y los paquetes de servicio (Nivel Inferior). •

•

Las dependencias entre los paquetes se identifican del diagrama de casos de uso estructurado. Esto es con el fin de ubicar las relaciones que existen entre los casos de uso. Las dependencias se crean a partir de los paquetes de análisis que contienen los casos de uso base. A continuación se muestra un ejemplo de distribución de paquetes en las capas de la aplicación y sus dependencias para definir la arquitectura de análisis.

Figura 7.6. Capas y dependencias entre paquetes de análisis 3.1.3. Identificar las clases de entidad obvias •

•

•

Solo se debe concentrar en identificar las clases del tipo entity por cada caso de uso. La mayoría de las clases se identificarán al crear las realizaciones de caso de uso (en la actividad del análisis de caso de uso). Tener cuidado de no identificar demasiadas clases en esta etapa y quedar atrapados en demasiados detalles.

Ejemplo: a) Reserva y Habitación b) DetalleReserva

Clases del dominio del problema Clase de la asociación entre Reserva y Habitación

3.1.4. Identificar los requisitos especiales comunes El arquitecto es el responsable de identificar los requisitos especiales comunes de forma que los desarrolladores puedan referirse a ellos como requisitos especiales sobre realizaciones de CU y clases del análisis determinadas.

•


CIBERTEC


•

Limitaciones o restricciones sobre persistencia, distribución y concurrencia, características de seguridad, tolerancia de fallos y gestión de transacciones.

3.1.5. Identificar características fundamentales de un requisito especial común En esta etapa se debe indicar las características de cada requisito especial común. Por ejemplo, las características de un requisito de persistencia son rango de tamaño, volumen, periodo de persistencia, frecuencia de actualización y fiabilidad.

•

ACTIVIDAD RESUELTA 1. Identifique los paquetes de análisis y sus dependencias para realizar la Arquitectura de Análisis para el proceso Venta de Repuestos, a partir del siguiente Diagrama de Caso de Uso Estructurado del caso “Sistema de Ventas y Control de Almacén” de CIMAQ S.A.

CIBERTEC



Diagrama de caso de uso del proceso - Venta de Repuestos

CIBERTEC



Para el caso en el paquete “Venta” se asignan los siguientes casos de uso: Registrar Pedido On-Line Generar Cotización de Venta Generar Orden de Pedido de Venta. • • •

En el paquete “Cliente”: Mantener Cliente Buscar Cliente. • •

En el paquete “Repuesto” Mantener Repuesto Buscar Repuesto Consultar stock de repuesto. • • •

En el paquete “Créditos” Evaluar Crédito •

Las dependencias se obtienen de las relaciones entre casos de uso, según el diagrama de casos de uso estructurado. Los casos de uso del paquete Venta tienen una relación de Incluye con buscar cliente y buscar repuesto; por lo tanto, el paquete Ventas tiene dos (2) dependencias , uno al paquete Cliente y otro al paquete Repuesto.

CIBERTEC



R$%&'$ El modelo de análisis, es usado para representar la estructura global del sistema, describe la realización de casos de uso y sirve como una abstracción del Modelo de Diseño.



 El

propósito del análisis de la arquitectura es esbozar el modelo de análisis y la arquitectura mediante la identificación de paquetes del análisis, clases análisis del tipo entidad evidentes y requisitos especiales comunes.



Los paquetes se usan para organizar el modelo de análisis en piezas más manejables, que representan abstracciones o subsistemas y una primera vista del diseño. Un paquete de análisis debe ser débilmente acoplado y altamente cohesivo. Los paquetes de análisis identificados se organizarán en la Capa de Aplicación, la cual se subdivide en dos capas internas: Capa Específica: Aquí se ubican los paquetes identificados con excepción de los reutilizables (Nivel Superior). Capa General: Aquí se ubican los paquetes reutilizables y los paquetes de servicio (Nivel Inferior). •

•



Si desea saber más acerca de estos temas, puede consultar el siguiente libro:  VISUAL

MODELING WITH IBM RATIONAL ARCHITECT SOFTWARE ARCHITECT AND UML por Terry Quatrani y Jim Palistrant En el capítulo 6 de este libro se describe cómo crear un modelo de análisis.


CIBERTEC



2 TEMA

! ANÁLISIS DE CASOS DE USO LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno modela los artefactos de la disciplina Análisis. Además modula la arquitectura de análisis que da soporte a un proceso de negocio, y diagrama la estructura y el comportamiento de sus funcionalidades mediante diagramas de clases y diagramas de comunicación respectivamente, haciendo uso de la herramienta CASE IBM Rational Software Architect.

TEMARIO 1. Análisis de casos de uso 2. Realizaciones de análisis de casos de uso.

ACTIVIDADES PROPUESTAS 1. Los alumnos crean la realización de un caso de uso.

CIBERTEC



1. ANÁLISIS DE CASOS DE USO

El Análisis de caso de uso permite examinar los casos de uso para descubrir los objetos y clases de análisis del sistema a desarrollar. Las clases identificadas deben agruparse en los paquetes de análisis. El rol responsable de esta actividad es el Diseñador. Esta tarea describe cómo desarrollar las Realizaciones de los Casos de Uso a nivel de análisis de un caso de uso. Tiene los siguientes propósitos: Identificar las clases que llevan a cabo el flujo de eventos de un caso de uso. Distribuir el comportamiento de casos de uso a las clases identificadas, usando realizaciones de casos de uso a nivel de análisis. Identificar los atributos, responsabilidades y relaciones entre las clases. Observar los mecanismos arquitectónicos.

• •

•

•

Análisis de Casos de Uso

Figura 8.1. Análisis de Casos de Uso

1.1. Pasos a realizar Para llevar a cabo el análisis de casos de uso se realiza lo siguiente: • • • •

Crear la realización de análisis de casos de uso. Encontrar clases de análisis del comportamiento de casos de uso. Crear el diagrama de clases (estructura del caso de uso). Crear el diagrama de comunicación (comportamiento del caso de uso).

1.1.1. Crear la realización de análisis de casos de uso Una realización de análisis (RA) de un caso de uso describe cómo un caso de uso en particular es primero modelado dentro del análisis y después dentro del diseño, en términos de objetos colaboradores. En una RA se especifica qué clases deben ser construidas para implementar cada caso de uso. En UML, las RA se representan con colaboraciones estereotipadas (elipse con líneas punteadas).

Figura 8.2. Colaboración


CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 3"

1.1.2. Encontrar clases de análisis Este paso se realiza por cada caso de uso. Para ello, se analizan los escenarios del caso de uso para identificar las clases que participan en ellos.

Figura 8.3. Un flujo completo de un caso de uso debe distribuirse en clases de análisis. En la figura 3, a partir de una especificación de caso de uso se pueden obtener las clases de análisis. Existen tres tipos de clases de análisis: interfaz (boundary), control (control ) y entidad (entity). A continuación se describe a cada una de ellas: •

Interfaz. Describe la interacción del sistema con los usuarios y/u otros sistemas externos. Pueden representar abstracciones de formularios, de protocolos de comunicaciones o interfaces de programación de aplicaciones (API). A continuación se presentan las características importantes de este tipo de clase cuando modela un API con otro sistema. a) Las funciones que provee el otro sistema b) La información a ser pasada al otro sistema c) El “protocolo” de comunicación usado para “hablar” con el otro sistema. Por regla general, al menos una clase interfaz sirve como medio de comunicación entre los un actor y el correspondiente caso de uso. Ejemplo: En el caso de uso “Procesar Cierre ” hay información que debe ser enviada a un Sistema de Facturación externo. Se puede crear una clase de interfaz llamada CI_SistemaFacturacion para representar la interfaz al sistema externo.

•

CIBERTEC

Entity. Se emplean para modelar aquella información que posee una vida larga en el sistema. Normalmente, están asociadas a


ANALISIS Y DISEÑO DE SISTEMA II (TEORIA) 4#

algún fenómeno o concepto, como una persona, un objeto del mundo real o un suceso del mundo real. El número de clases entidad variará dependiendo de los conceptos que requieren almacenamiento persistente dentro del caso de uso. Estas clases sufren un proceso de refinamiento a medida que se ubica a la misma clase entidad dentro de distintas realizaciones de caso de uso. Ejemplo: En el caso de uso “Mantener empleados ”, en el cual se puede registrar, modificar o desactivar empleados, es evidente que la información que debe ser manipulada es del empleado. Para ello, se crea una clase entidad Empleado. •

Control. Se utilizan para modelar la coordinación, secuencia, transacciones y control de otros objetos. También para representar derivaciones y cálculos complejos, como la lógica de negocio, que no pueden asociarse a ninguna información concreta de larga duración almacenada por el sistema. Por regla general se trata de encapsular la lógica de control de un caso de uso dentro de una clase Control. Suele ser un buen hábito de diseño utilizar únicamente una clase control por cada caso de uso, y así encapsular en un sólo elemento la lógica del caso de uso correspondiente. Por otro lado, todos los casos de uso ubicados en un mismo paquete de análisis comparten la misma clase control. Ejemplo: En un paquete de análisis denominado Evaluación se ubica los casos de uso “Evaluar empleado ”, “Procesar evaluación de desempeño ” y “Consultar estadísticas de Evaluaciones ”. Para los tres casos de uso se crea una clase control CC_Evaluacion que coordina el trabajo de los tres.

Según la metodología OOSE de Ivan Jacobson, las clases de análisis son clases estereotipadas. Esta metodología se basa en el patrón MVC (Model-View-Controller / Modelo Vista Controlador).

Figura 8.4. Clases de análisis enfocadas al patrón MVC.


CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) 4

Cada clase de análisis debe tener un estereotipo 1, como mecanismo que el UML provee para extender la notación. Los estereotipos se muestran en el compartimiento del nombre de la clase encerrado entre <<>> (guillemets) o con un icono; también se pueden representar con la forma de la imagen del icono en lugar de una clase. Estas representaciones se muestran a continuación:

Figura 8.5. Estereotipos de Clases de entidad (entity) 1.1.3. Crear el diagrama de clases Este paso permite representar las clases participantes y sus relaciones para un determinado caso de uso. Es un diagrama estático.

Figura 8.6. Diagrama de clases de análisis 1

Un estereotipo (Stereotype en inglés), es un nuevo tipo de elemento de modelado que extiende la semántica del meta modelo, basados en tipos existentes o clases del meta modelo.

CIBERTEC



1.1.4 Crear diagramas de comunicación Este paso se realiza para describir la secuencia de acciones dentro del caso de uso. El diagrama de comunicación es un tipo de diagrama de interacción; en esta etapa, no se usa diagramas de secuencia porque no es importante la cronología de las interacciones. La realización de un caso de uso puede tener uno o más diagramas de comunicación, esto es debido a que se representa el flujo básico, subflujos y flujos alternativos.

F


Figura 8.7. Diagrama de comunicación

CIBERTEC


2. REALIZACIONES DE ANÁLISIS: CASO PRÁCTICO A continuación se presentan las siguientes especificaciones de casos de uso del Sistema de Ventas y Control de Almacén, para identificar las clases de análisis y realizar los diagramas de clases y diagrama de comunicaciones.

A. ESPECIFICACIÓN DE CASO DE USO: Buscar Repuesto 1. Breve descripción El caso de uso permite al Actor buscar un repuesto por descripción. Cuando se encuentra el repuesto el sistema cargará los datos del repuesto en el caso uso base que lo invocó. 2. Actores Usuario (RVRS, Cliente y ACR) 3. Flujo de eventos 3.1. Flujo Básico 1. El caso de uso inicia cuando es invocado por un caso de uso base. 2. El sistema muestra la interfaz “Búsqueda de Repuestos” con los siguientes campos: Un campo descripción con la opción “Buscar Repuesto”. Datos de los repuestos (lista): código de repuesto, descripción, precio unitario, stock disponible, stock mínimo y unidad. Un campo de nivel de stock (Todos, Alto, Normal y Bajo) con la opción “Filtrar”. Además de las opciones “Aceptar” y “Salir”. 3. El Usuario ingresa el criterio de búsqueda (descripción). 4. El Usuario selecciona la opción “Buscar Repuesto”. 5. El sistema valida el criterio ingresado. 6. El sistema muestra una relación de repuestos que coinciden con el criterio de búsqueda. 7. El Usuario selecciona el nivel de stock. 8. El Usuario solicita “Filtrar”. 9. El sistema muestra la lista de repuestos con el nivel de stock seleccionado. 10. El Usuario selecciona un repuesto. 11. El Usuario solicita “Aceptar” 12. El sistema carga los datos de los repuestos en la interfaz del caso de uso base que lo invocó y finaliza el caso de uso. 3.2. Flujo alternativo 5.1. Criterio de Búsqueda Inválido Si el criterio de búsqueda en el campo descripción es nulo o inválido, el sistema muestra el MSG “Criterio de búsqueda nulo o inválido” y retorna al paso 3. 6.1. Repuesto no encontrado Si el sistema no encuentra ningún repuesto con el criterio ingresado, el sistema muestra el MSG “No se encontraron repuestos para el criterio de búsqueda ingresado” y retorna al paso 3 o el Usuario selecciona la opción “Salir” y finaliza el caso de uso. 11.1. Selección obligatoria Si el Usuario no selecciona ningún repuesto, el sistema muestra el MSG “Seleccione un repuesto obligatoriamente” y retorna al paso 10. 4. Precondiciones 1. El RVRS y el ACR deben estar registrados y logueados en el sistema. • •

•

•

CIBERTEC



2. Lista disponible de repuestos. 5. Postcondiciones Ninguno. 6. Requerimientos especiales Ninguno. 7. Puntos de extensión Ninguno. 8. Prototipo

a) Diagrama de Clases


CIBERTEC


b) Diagrama de Comunicación

CIBERTEC



B. ESPECIFICACIÓN DE CASO DE USO: Registrar Pedido On Line 1. Breve descripción El caso de uso permite al Cliente realizar un pedido de venta de repuestos en línea accediendo a la página Web de CIMAQ S.A. La empresa le enviará una cotización para su aprobación. 2. Actores Cliente 3. Flujo de eventos 3.1. Flujo Básico 1. El caso de uso inicia cuando el Cliente ingresa a la página web de CIMAQ S.A. 2. El sistema muestra el Home de la página web. 3. El Cliente selecciona la opción “Registrar Pedido”. 4. El sistema muestra la interfaz “Nuevo Pedido - Cliente” con los siguientes campos: Datos del Pedido: Número del Pedido (no habilitado), Dirección de envió, número, puerta, distrito, provincia, referencia, persona de contacto y teléfono de contacto (habilitados). Datos de los repuestos (detalle): código de repuesto, descripción, cantidad (habilitado), unidad, precio unitario y total, con las opciones “Buscar Repuesto”, “Agregar Repuesto” y “Eliminar Repuesto”. Forma de pago (Contado o Crédito). Subtotal, IGV y Total del pedido (no habilitados). Además, las opciones “Siguiente” y “Cancelar”. 5. El Cliente ingresa los datos del pedido. 6. El Cliente selecciona la opción “Buscar Repuesto”. 7. El sistema incluye el caso de uso “Buscar Repuesto”. 8. El sistema muestra los datos del repuesto. 9. El Cliente ingresa la cantidad de unidades requeridas para el repuesto. 10. El Cliente selecciona la opción “Agregar Repuesto”. 11. El sistema calcula el sub total por repuesto (precio unitario x cantidad), calcula el total del pedido y adiciona al detalle. 12. Si el Cliente desea agregar otro repuesto se repiten los pasos 6 a 11. 13. Si el Cliente selecciona un repuesto y la opción “Eliminar Repuesto”, ir al subflujo Eliminar Repuesto. 14. El Cliente selecciona la forma de pago (crédito o contado). 15. Si el Cliente seleccionó forma de pago al contado ir al subflujo Ingresar información de pago. 16. El Cliente selecciona la opción “Registrar”. 17. El sistema valida los datos del pedido ingresados. 18. El sistema genera un código de pedido. 19. El sistema graba el pedido con la fecha actual y en estado de “por cotizar” y su detalle, muestra el MSG “Pedido registrado exitosamente”. 20. El sistema muestra la interfaz el Home de la página Web y el caso de uso finaliza. 3.2. Sub Flujos 3.2.1. Eliminar Repuesto 1. El sistema elimina el(los) repuestos(s) seleccionado(s) de la lista de repuestos que se han agregado al pedido. 2. Si el Cliente desea eliminar más repuestos, se repiten los pasos 1 a 3. 3. El flujo retorna al paso 14 del flujo básico. •

•

• •

CIBERTEC



3.2.2. Ingresar Información de Pago 1. El sistema muestra la interfaz “Información de Pago” con los siguientes campos: Código de cliente, forma de pago, fecha de pago, número de cuenta y monto. Además de las opciones “Imprimir” y “Aceptar”. 2. El cliente solicita la opción “Imprimir”. 3. El sistema imprime la información de pago. 4. El Cliente selecciona la opción “Aceptar”. 5. El flujo continúa en el paso 16 del flujo básico. 3.2.3. Cancelar Pedido 1. Si el cliente selecciona cancelar, antes de registrar el pedido 2. El sistema muestra el MSG: “Confirmar la cancelación” 3. El Cliente selecciona “SI” para cancelar pedido. 4. El sistema cancela el pedido y finaliza el caso de uso. 3.3. Flujos Alternativos 13.1. Selección obligatoria Si el cliente no selecciona ningún repuesto y solicita “Eliminar Repuesto”, el sistema muestra el MSG: “Seleccione por lo menos un repuesto a eliminar” y el caso de uso continúa en el paso 13 del flujo básico. 17.1. Datos de pedido inválidos El sistema muestra el MSG: “Datos del pedido nulos o inválidos” y el caso de uso continúa en el paso 14 del flujo básico. 19.1. Error al grabar pedido Si el sistema no puede grabar el pedido el sistema muestra el MSG “Error al grabar pedido” y el caso de uso continúa en el paso 16 del flujo básico. Error al imprimir Si el sistema no puede imprimir el sistema muestra el MSG: “Error al imprimir documento” y el caso de uso continúa en el paso 4 del sub flujo “Información de Pago”. 4. Precondiciones 4.1. El Cliente debe estar logeado en el sistema. 5. Postcondiciones 5.1. El pedido con el detalle de los repuestos quedará grabado en el sistema. 5.2. En el sistema, el estado del pedido será “Por cotizar”. 6. Requerimientos especiales 6.1. La PC del cliente debe tener acceso a internet. 6.2. La PC del cliente debe estar conectada a una impresora. 7. Puntos de extensión Ninguno. •

CIBERTEC



8. Prototipo

a) Realización de Análisis


CIBERTEC


b) Diagrama de clases

CIBERTEC


ANALISIS Y DISEÑO DE SISTEMA II (TEORIA)

c) Diagrama de Comunicación


CIBERTEC

5#


1.

ACTIVIDADES PROPUESTAS

A partir de la especificación de caso de uso realice los siguientes diagramas: a) Diagrama de clases de análisis b) Diagrama de comunicación del flujo básico c) Diagrama de comunicación de los subflujos d) Diagrama de comunicación de los flujos alternativos.

ESPECIFICACIÓN DE CASO DE USO: Pagar Tributos de RENIEC por ATM 1. Breve Descripción El caso de uso permite al Cliente en el cajero automático (ATM) cancelar un pago correspondiente a un tributo de RENIEC. 2. Actor Cliente. 3. Flujo de Eventos 3.1. Flujo Básico 1. El caso de uso se inicia cuando el cliente del Banco elige la opción "RENIEC" en el menú principal del ATM. 2. El sistema muestra el mensaje “Elija el pago a realizar” en la interfaz “Pago de RENIEC”; además, de los tributos disponibles para pagar: Inscripción / Reinscripción Renovación por Caducidad / Canje LE x DNI Certificado/Constancia de nombres iguales Cambio de lugar entrega DNI Duplicado DNI / Mayor de Edad 3. El cliente elige un tributo. 4. El sistema muestra el concepto, el monto y el mensaje “Ingrese el número de documento del interesado”. Además, de la aclaración “Para corregir sus datos presione la tecla Borrar” y la opción Aceptar. 5. El cliente ingresa el número de documento del interesado. 6. El sistema muestra las cuentas relacionadas a la tarjeta, para efectuar el pago. 7. El sistema muestra el mensaje “Elija la cuenta para realizar el pago” 8. El cliente elige una cuenta y “Acepta” la transacción. 9. El sistema verifica que el ATM tiene papel para imprimir el voucher. 10. El sistema debita el monto del pago de la cuenta elegida y registra el pago, incluyendo los movimientos de fondos y comisiones si aplica. 11. El sistema envía una trama al Sistema de RENIEC con los datos de la transacción realizada. 12. El sistema muestra el mensaje: “Su transacción ha concluido satisfactoriamente”. 13. El sistema imprime el voucher con los siguientes datos: Cabecera del Servicio (Banco ABC, Tu Banco Amigo, Multired-Pago de Tributo-Cta Ahorros MN) Título del Servicio (Sistema Electoral – RENIEC) • • • • •

•

•

CIBERTEC


52

Campos del cuerpo del voucher : código del tributo, nombre del tributo, tipo de documento, número de documento y monto pagado. Pie del voucher : secuencia de ATM, dígito de Chequeo, fecha, código de cajero, código de agencia, hora y secuencia de ATM. 14. El sistema muestra el mensaje “¿Desea continuar?” 15. Si el cliente elige SI, vuelve al menú principal, sino el caso de uso termina. 3.2. Flujos Alternativos Transacción inválida En los puntos 10 y 11 del flujo básico, si el sistema registra un error al ejecutar la transacción, muestra el mensaje “Disculpe, en estos momentos no es posible procesar su operación” y el caso de uso termina. 4. Precondiciones 1. En el sistema la tarjeta del cliente existía y se encontraba en estado “Activa”. 2. El cliente ingresó el PIN correcto de la tarjeta. 3. La cuenta a pagar tenía el saldo suficiente para cubrir el monto del pago. 5. Post condiciones 1. En el sistema quedará registrado el pago del tributo a través de un registro en la tabla de movimientos. 2. En el sistema quedarán registrados los impuestos y comisiones afectos a la cuenta. 3. En el sistema el saldo final de la cuenta del cliente será disminuido en base al saldo inicial menos el monto del tributo pagado y los impuestos y comisiones afectos a la cuenta. 4. El sistema de RENIEC recibirá una trama con los datos del pago del cliente. 5. El sistema generará un voucher que será dispensado por el ATM al cliente conteniendo los datos de la transacción. 6. Puntos de Extensión Ninguna. 7. Prototipos A ser diseñado por los alumnos. •

•


CIBERTEC


2.

53

A partir de la Especificación de Caso de Uso realice los siguientes diagramas: a) Diagrama de clases de análisis b) Diagrama de comunicación del flujo básico c) Diagrama de comunicación de los flujos alternativos.

Especificación de Caso de Uso: Cotizar Productos 1. Breve Descripción Este caso de uso consiste en registrar una cotización para el cliente que lo solicite. Esta cotización se emitirá en estado pendiente y cuando el cliente la apruebe, el vendedor le cambiará el estado y la enviará vía fax firmada. Con este documento se procederá a generar las notas de pedido y facturación. 2. Actores Vendedor. 3. Flujo de Eventos 3.1. Flujo Básico 1. El Caso de Uso se inicia cuando el Vendedor selecciona “Cotizar Productos” en la interfaz del menú principal. 2. El sistema muestra la interfaz “Cotización de Productos” con los campos: Datos del cliente: RUC/DNI, apellidos, nombres, dirección y teléfono. Datos de los productos a cotizar: código, descripción, margen de ganancia (MG), precio de venta unitario (PVU), precio de costo unitario (PCU). Datos de la cotización: Número de Cotización, precio de venta neto (PVN), el precio de venta total (PVT), la disponibilidad de entrega y el Tipo de pago. Además se tiene las opciones: “Buscar Cliente”, “Buscar Productos”, “Grabar Cotización”, “Registrar Nuevo Cliente”, “Generar N. Pedido y Facturación” y “Salir”. 3. El vendedor solicita buscar al cliente. 4. El sistema Incluye el caso de uso “Buscar Cliente”. 5. El sistema muestra los datos del cliente: nombres, apellidos, dirección y teléfono. 6. El vendedor solicita buscar Productos. 7. El sistema Incluye el caso de uso “Buscar Productos”. 8. El sistema muestra la descripción y PCU del producto seleccionado. 9. El Vendedor ingresa el PVU (tentativo) del producto negociado con el Cliente. 10. El sistema muestra el margen de ganancia (PVU – PCU). 11. El Vendedor acepta el precio de venta PVU (acordado). 12. Si el Vendedor quiere adicionar otro producto se repite el flujo del paso 5 al 9. 13. El Vendedor ingresa la disponibilidad de entrega de los productos cotizados (inmediata o en un tiempo determinado) y el tipo de pago (adelanto, %pago o al crédito). 14. El sistema calcula y muestra el precio de venta neto (PVN) y el precio de venta total (PVT). 15. El Vendedor solicita “Grabar Cotización”. 16. El sistema obtiene el último número de Cotización y autogenera un código. 17. El sistema graba la cotización en estado “Pendiente” con su detalle (por producto), muestra el Nro. de Cotización, imprime la cotización y muestra el mensaje “Cotización No. 9999999 grabada correctamente”. 18. El Vendedor solicita “Salir”, el sistema cierra la interfaz y el caso de uso termina. • •

•

•

3.2. Flujos Alternativos 5.1. Cliente no existe CARRERAS PROFESIONALES

CIBERTEC

54

Si el sistema no retorna con datos del cliente, mostrará el mensaje “Cliente no encontrado” y ofrecerá la posibilidad de registrar al nuevo cliente. 8.1. Productos no existen Si el sistema no encuentra el (los) producto(s), enviará el mensaje “Producto no encontrado” y el caso de uso finaliza. 17.1. Cotización no registrada Si el sistema no llega a grabar la cotización y/o detalles enviará el mensaje “Cotización no registrada” y el caso de uso finaliza. 4. Requisitos Especiales 1. Aprovisionamiento de papel para emitir la cotización. 5. Precondiciones 1. Tener registrados los productos con sus respectivos códigos y precios de costos unitarios. 6. Poscondiciones 1. La cotización queda registrado con su detalle en estado “Pendiente”, en espera de cambio a estado “Aceptada”. 7. Puntos de extensión 1. En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo básico “Registrar Cliente”. 2. En el punto 17, el sistema extiende al caso de uso “Generar Nota de Pedido y Facturación” si el Cliente aprueba por teléfono la cotización. 8. Prototipo


CIBERTEC


55

R$%&'$



Una realización de casos de uso describe cómo un caso de uso en particular es modelado dentro del modelo de análisis primero y después dentro del modelo de diseño en términos de objetos colaboradores.

 Existen

tres tipos de clases de análisis: Interfaz (boundary), Control (control) y Entidad (entity).



Si desea saber más acerca de estos temas, puede consultar el siguiente libro:  VISUAL

MODELING WITH IBM RATIONAL ARCHITECT SOFTWARE ARCHITECT AND UML por Terry Quatrani y Jim Palistrant En el capítulo 6 de este libro se describe cómo crear un modelo de análisis.


CIBERTEC

56


2 TEMA

" ANÁLISIS DE CLASES LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno modula la arquitectura de análisis que da soporte a un proceso de negocio, y diagrama la estructura y el comportamiento de sus funcionalidades mediante diagramas de clases y diagramas de comunicación respectivamente, haciendo uso de la herramienta CASE IBM Rational Software Architect.

TEMARIO 1. Análisis de Clases. 2. Tarjetas CRC (Clase – Responsabilidades – Colaboradoras).

ACTIVIDADES PROPUESTAS 1. Los alumnos confeccionan las tarjetas CRC de las clases que participan en el caso de uso especificado.


CIBERTEC


57

1. ANÁLISIS DE CLASES

El objetivo de esta actividad es describir cada una de las clases que se han identificado en el análisis de cada uno de los casos de uso, identificando sus responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas.

1.1. Pasos a realizar A continuación, se presentan los pasos que se realizan en esta actividad. • •

•

Identificar las responsabilidades y atributos Identificar las asociaciones y agregaciones Identificar las generalizaciones.

1.1.1. Identificar las responsabilidades y atributos El objetivo de esta tarea es identificar las responsabilidades y atributos relevantes de una clase de análisis. Las responsabilidades definen la funcionalidad de una clase, y están basadas en los papeles que desempeñan sus objetos en los diferentes casos de uso. A partir de estas responsabilidades, se encontrarán las operaciones de la clase en el diseño. Los atributos de una clase especifican las propiedades de la clase, y se identifican por estar implicados en sus responsabilidades. Los tipos de atributos deberían ser conceptuales y conocidos en el dominio. De manera opcional, se elabora una especificación para cada clase, que incluye la lista de sus operaciones y las clases que colaboran para cubrir esas operaciones y una descripción de las responsabilidades, atributos y operaciones de esa clase. Para aquellas clases, cuyo comportamiento dependan del estado en el que se encuentren, se realiza, también, de manera opcional, un diagrama de transición de estados. 1.1.2. Identificar las asociaciones y agregaciones En esta tarea, se estudian los mensajes establecidos entre los objetos del diagrama de comunicación para determinar qué asociaciones existen entre las clases correspondientes. Estas asociaciones suelen corresponderse con expresiones verbales incluidas en las especificaciones. Las relaciones surgen como respuesta a las demandas en los distintos casos de uso, y, para ello, puede existir la necesidad de definir agregaciones y herencia entre objetos. Una asociación está caracterizada por las siguientes condiciones: • • •

Los papeles que desempeña. Su direccionalidad, que representa el sentido en el que se debe interpretar. Su cardinalidad, que representa el número de instancias implicadas en la asociación.

Dichas características pueden obtenerse a partir de la especificación de los casos de uso. CARRERAS PROFESIONALES

CIBERTEC

5!

1.1.3. Identificar las generalizaciones El objetivo de esta tarea es representar una organización de las clases que permita una implementación sencilla de la herencia y una agrupación semántica de las diferentes clases.

2. Tarjetas CRC

Es la técnica de las tarjetas de Clase-Responsabilidad-Colaboración (CRC).

2.1. Descripción de las tarjetas CRC La tarjeta se divide en tres compartimientos, tal como se muestra en la figura No. 5.1. En el compartimiento superior izquierdo se escribe el nombre de la clase a analizar; en el compartimiento inferior izquierdo, las responsabilidades; y en el derecho, las colaboradores.

Figura 9.1. Tarjeta de Clase – Responsabilidad - Colaboración (CRC) Las responsabilidades de una clase pueden recopilarse combinando todos los roles que cumple en las diferentes realizaciones de caso de uso. Identificar los diagramas de clases y comunicación. En el diagrama de comunicación cuando se describen los escenarios (flujos básico y alternativos), un mensaje refleja el propósito del objeto invocante en la interacción con el objeto invocado. Este propósito es el origen de una responsabilidad del objeto receptor y podría llegar hacer el nombre de una responsabilidad. Las colaboradoras son otras clases que apoyan con esta clase para realizar una parte de la funcionalidad del sistema. Uno de los principales beneficios de las tarjetas de CRC es saber cómo van a implementar las clases en el diseño. Los desarrolladores escogen tarjetas a medida que cada clase colabora en el caso de uso. Es importante pensar en las responsabilidades, ya que evita pensar en las clases como simples repositorios de datos, y ayuda a que el equipo se centre en comprender el comportamiento de alto nivel de cada clase.

2.2. Limitaciones de las tarjetas CRC Aunque las tarjetas CRC pueden ser una herramienta poderosa para empezar el diseño, tienen limitaciones inherentes. El primer problema es que no tienen un escalamiento exitoso. En un proyecto muy complejo, puede agobiarse con las tarjetas CRC; el simple hecho de mantener un registro de todas ellas puede ser difícil.


CIBERTEC


5"

El problema se torna más difícil aun al tratar de mantener sincronizados entre sí, a las tarjetas y los modelos de UML de las clases. En resumen, las tarjetas CRC son un buen inicio por mantener documentadas las clases de análisis, pues a partir de ellas se tendrá una visión general del comportamiento de una clase con respecto de otras, pero una vez que se tenga conocimiento de las clases y lleguen a su etapa de diseño, estas tarjetas ya no les será útil y quizá ya no necesitará actualizarlas.

3. Caso Práctico

A continuación, se explicará cómo confeccionar las tarjetas CRC para las clases participantes del caso de uso “Registrar Pedido On – Line”, a partir del diagrama de comunicación.

ESPECIFICACIÓN DE CASO DE USO: Registrar Pedido On Line

1. Breve descripción El caso de uso permite al Cliente realizar un pedido de venta de repuestos en línea accediendo a la página Web de CIMAQ S.A. La empresa le enviara una cotización para su aprobación. 2. Actores Cliente 3. Flujo de eventos 3.1. Flujo Básico 1. El caso de uso inicia cuando el Cliente ingresa a la página web de CIMAQ S.A. 2. El sistema muestra el Home de la página web. 3. El Cliente selecciona la opción “Registrar Pedido”. 4. El sistema muestra la interfaz “Nuevo Pedido - Cliente” con los siguientes campos: Datos del Pedido: Número del Pedido (no habilitado), Dirección de envió, número, puerta, distrito, provincia, referencia, persona de contacto y teléfono de contacto (habilitados). Datos de los repuestos (detalle): código de repuesto, descripción, cantidad (habilitado), unidad, precio unitario y total, con las opciones “Buscar Repuesto”, “Agregar Repuesto” y “Eliminar Repuesto”. Forma de pago (Contado o Crédito). Subtotal, IGV y Total del pedido (no habilitados). Además, las opciones “Siguiente” y “Cancelar”. 5. El Cliente ingresa los datos del pedido. 6. El Cliente selecciona la opción “Buscar Repuesto”. 7. El sistema incluye el caso de uso “Buscar Repuesto”. 8. El sistema muestra los datos del repuesto. 9. El Cliente ingresa la cantidad de unidades requeridas para el repuesto. 10. El Cliente selecciona la opción “Agregar Repuesto”. 11. El sistema calcula el sub total por repuesto (precio unitario x cantidad), calcula el total del pedido y adiciona al detalle. 12. Si el Cliente desea agregar otro repuesto se repiten los pasos 6 a 11. 13. Si el Cliente selecciona un repuesto y la opción “Eliminar Repuesto”, ir al subflujo Eliminar Repuesto. 14. El Cliente selecciona la forma de pago (crédito o contado). 15. Si el Cliente seleccionó forma de pago al contado ir al su flujo Ingresar información de pago. 16. El Cliente selecciona la opción “Registrar”. 17. El sistema valida los datos del pedido ingresados. •

•

• •


CIBERTEC

6#

18. El sistema genera un código de pedido. 19. El sistema graba el pedido con la fecha actual y en estado de “Por cotizar” y su detalle, muestra el MSG “Pedido registrado exitosamente”. 20. Si la forma de pago es al contado, el sistema graba la Información del pago. 21. El sistema muestra la interfaz el Home de la página Web y el caso de uso finaliza. 3.2. Sub Flujos 3.2.1. Eliminar Repuesto 1. El sistema elimina el(los) repuestos(s) seleccionado(s) de la lista de repuestos que se han agregado al pedido. 2. Si el Cliente desea eliminar más repuestos se repiten los pasos 1 a 3. 3. El flujo retorna al paso 14 del flujo básico. 3.2.2. Ingresar Información de Pago 2. El sistema muestra la interfaz “Información de Pago” con los siguientes campos: código de cliente, forma de pago, fecha de pago, número de cuenta y monto. Además de las opciones “Imprimir” y “Aceptar”. 3. El cliente solicita la opción “Imprimir”. 4. El sistema imprime la información de pago. 5. El Cliente selecciona la opción “Aceptar”. 6. El flujo continúa en el paso 16 del flujo básico. 3.2.3. Cancelar Pedido 1. Si el cliente selecciona cancelar, antes de registrar el pedido 2. El sistema muestra el MSG: “Confirmar la cancelación” 3. El Cliente selecciona “SI” para cancelar pedido. 4. El sistema cancela el pedido y finaliza el caso de uso. 3.3. Flujos Alternativos 13.1. Selección obligatoria Si el cliente no selecciona ningún repuesto y solicita “Eliminar Repuesto”, el sistema muestra el MSG: “Seleccione por lo menos un repuesto a eliminar” y el caso de uso continúa en el paso 13 del flujo básico. 17.1. Datos de pedido inválidos El sistema muestra el MSG: “Datos del pedido nulos o inválidos” y el caso de uso continúa en el paso 14 del flujo básico. 19.1. Error al grabar pedido Si el sistema no puede grabar el pedido el sistema muestra el MSG “Error al grabar pedido” y el caso de uso continúa en el paso 16 del flujo básico. Error al imprimir Si el sistema no puede imprimir el sistema muestra el MSG: “Error al imprimir documento” y el caso de uso continúa en el paso 4 del sub flujo “Información de Pago”. 4. Precondiciones 4.1. El Cliente debe estar logeado en el sistema. 5. Postcondiciones 5.1. El pedido con el detalle de los repuestos quedará grabado en el sistema. 5.2. En el sistema, el estado del pedido será “Por cotizar”. 6. Requerimientos especiales 6.1. La PC del cliente debe tener acceso a internet. 6.2. La PC del cliente debe estar conectada a una impresora. 7. Puntos de extensión Ninguno. •

•


CIBERTEC


Diagrama de Comunicación

CIBERTEC



Confeccionar las tarjetas CRC por cada clase de análisis. Se empezará a realizar las tarjetas CRC en orden alfabético por tipo de clase. Primero empezaremos con los boundary, luego con la clase control y al final con los entity. Nombre de Clase: CI_Site Responsabilidad 1. Ingresa al Site. Nombre de Clase: CI_Home Responsabilidad 1. Muestra el Home 2. Selecciona “Registrar Pedido”. Nombre de Clase: CI_NuevoPedidoCliente Responsabilidad 1. Muestra interfaz 2. Ingresa datos del pedido 3. Selecciona “Buscar Repuesto” 4. Muestra repuesto 5. Ingresa cantidad 6. Selecciona “Agregar repuesto” 7. Solicita adicionar detalle 8. Selecciona repuesto 9. Seleccionar “Eliminar” 10. Selecciona forma de pago 11. Solicita registrar Pedido 12. Muestra MSG. Nombre de Clase: CC_Pedido Responsabilidad 2. Invoca al home 3. Invoca interfaz 4. Calcula subtotal 5. Calcula total 6. Valida pedido. Nombre de Clase: Pedido Responsabilidad 1. Genera código 2. Graba pedido.

CIBERTEC

Colaboradores CC_Pedido



Colaboradores CI_Site CI_Home CI_Nuevo_Pedido_Cliente Pedido Detalle_Pedido.




63

Nombre de Clase: DetallePedido Responsabilidad 1. Graba detalle.


Nombre de Clase: InformaciónDePago Responsabilidad 1. Graba información de pago.



CIBERTEC

64

ACTIVIDADES PROPUESTAS

A partir del caso y la especificación de caso de uso realice los siguientes artefactos: 1. Diagrama de clases de análisis. 2. Diagrama de comunicación del flujo básico. 3. Diagrama de comunicación de los flujos alternativos. 4. Tarjeta CRC de la clase controladora. El cliente bancario puede registrar transferencia de dinero entre sus cuentas, puede también actualizar sus datos, también, puede realizar giros a nivel nacional, registrar pagos de servicios de telefonía y solicitar tarjetas de crédito. El administrador de créditos evalúa las solicitudes previa verificación del cliente y él también se encarga de administrar las tasas de los intereses. A continuación se muestra la ECU de Registrar pago de telefonía: Especificación de Caso de uso: Registrar Pago de Telefonía 2. Breve descripción El caso de uso permite a un Cliente del Banco efectuar el pago del servicio de Telefonía con cargo en su Cuenta de Ahorros para cancelar sus recibos pendientes. 3. Actor Cliente. 4. Flujo de Eventos 4.1. Flujo Básico 1. El caso de uso comienza cuando el Cliente selecciona la opción Pago de telefonía en la interfaz del menú principal. 2. El sistema muestra la interfaz “Pago de Telefonía” Muestra una lista de empresas proveedoras de servicio de telefonía (americatel, claro, nextel, telefónica. etc.) Muestra una lista de servicios de las empresas. Posee un campo para el ingreso del número del servicio y una lista desplegable con las cuentas por las cuales se puede realizar el pago. 3. El Cliente selecciona una empresa y se refresca el tipo de servicio 4. El cliente selecciona el servicio 5. El cliente ingresa el número del servicio 6. El cliente selecciona una de las cuentas para realizar el pago. 7. El cliente selecciona Continuar 8. El sistema muestra la interfaz “Verificación de Pago”, en la interfaz se muestra el titular del servicio de la cuenta , el monto a pagar y la cuenta asociada para el pago, también se muestra el ingreso de clave, la opción Aceptar y Cancelar 9. El Cliente ingresa su clave 10. El cliente selecciona aceptar. 11. El sistema registra la transacción autogenera Número de Operación, 12. El sistema actualiza el monto de la cuenta de ahorros. 13. El sistema actualiza el recibo a cancelado 14. El sistema muestra la interfaz “Constancia “ en la interfaz se muestra número de la operación y muestra el MSG:”Pago de Telefonía efectuado correctamente” 15. El cliente selecciona “Terminar Sesión”, se cierra la interfaz y el caso de uso finaliza. 2.2. Flujos Alternativos 7.1. Numero de servicio no existe El sistema muestra el MSG: “Numero de servicio no existe”. •

• •


CIBERTEC


65

5. Pre Condiciones 1. El cliente logeado al sistema con su número de tarjeta y clave. 2. Disponible las empresas de servicios, tipos de servicios, cuentas de ahorro y teléfonos afiliados. 6. Post Condiciones 3. En el sistema quedará registrado la transacción. 4. En el sistema quedará actualizado el monto de la cuenta. 7. Prototipo


CIBERTEC

66


CIBERTEC


67

R$%&'$



Para llevar a cabo el análisis de clases se realiza lo siguiente: Identificar las responsabilidades y atributos Identificar las asociaciones y agregaciones Identificar las generalizaciones

• • •



La tarjeta CRC es una técnica para identificar responsabilidades y colaboradores de una clase. Su objetivo es facilitar la comunicación y documentar los resultados del análisis.



La tarjeta se divide en tres compartimientos. En el compartimiento superior izquierdo se escribe el nombre de la clase candidata; en el compartimiento inferior izquierdo, las responsabilidades; y en el derecho, los colaboradores.



Si desea saber más acerca de estos temas, puede consultar el siguiente enlace: 

http://c2.com/doc/oopsla89/paper.html En este link muestra un paper sobre las Tarjetas CRC.


CIBERTEC

6!


2 TEMA

MODELO CONCEPTUAL

#

LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno modula la arquitectura de análisis que da soporte a un proceso de negocio, y diagrama la estructura y el comportamiento de sus funcionalidades mediante diagramas de clases y diagramas de comunicación respectivamente, haciendo uso de la herramienta CASE IBM Rational Software Architect.

TEMARIO 1. Modelo Conceptual.

ACTIVIDADES PROPUESTAS 1. Los alumnos alumnos desarrollan desarrollan el Modelo Modelo Conceptual Conceptual de un un caso propuesto. 2. Los alumnos rinden la evaluación continua No. 2.


CIBERTEC


6"

1. MODELO CONCEPTUAL Las clases del modelo conceptual se obtienen a partir de los objetos de información (entidades) que fluyen entre las realizaciones realizaciones de análisis. Una característica importante que resaltar es que el modelado de los casos de uso del sistema y el modelado conceptual se realizan en paralelo, esto es crucial para obtener casos de uso correctos, puesto que es necesario entender bien el dominio para poder escribir casos de uso que sean realmente útiles.

Definición de la 1ra. Capa: A licaci cación ón

Realización de los casos de uso: Diagramas de Clases y Diagramas de Comunicación

Revisión de los paquetes y sus contenidos Modelo Conceptual Modelo Lógico Modelo Físico

Figura 10.1. El Modelo Conceptual en el Análisis y Diseño

1.1. Importancia del Modelo Conceptual

El Modelo Conceptual Orientado a Objetos beneficiará a dos equipos de trabajo: Equipo de Desarrolladores Desarrolladores En esta etapa del desarrollo, merece la pena detenerse en la identificación de los conceptos y no tanto en las relaciones entre ellos. Este modelo incluirá los conceptos y sus relaciones y se describirá mediante un diagrama de clases UML, en el que los conceptos se representan mediante clases (del dominio). Equipo de Base de Datos En esta etapa luego del modelo conceptual, se obtiene el proceso del modelo lógico al diseño físico donde se podrá identificar las tablas relacionales relacionales del proyecto de Base de Datos como componente RUP.

•

•


CIBERTEC

7#

Figura 10.2. Diagrama de clases - Modelo Conceptual

1.2. Construcción del Modelo Conceptual Los pasos que se realizan en esta actividad son los siguientes: • • • • • • • •

Identificar las clases persistentes con sus atributos Definir jerarquías Identificar agregaciones agregaciones Asociar clases Analizar las multiplicidades multiplicidades Identificar clases asociativas asociativas Definir operaciones Documentar reglas de negocio.

1.2.1. Identificar las clases persistentes con sus atributos La Clase es la unidad básica que encapsula toda la información de un objeto (instancia de una clase). A través de ella podemos modelar el concepto en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). Los Atributos representan las propiedades de la clase que se encuentran en todas las instancias de la clase. Asimismo, definen la estructura de una clase y de sus objetos. Los atributos corresponden corresponden a sustantivos y sus valores pueden ser sustantivos o adjetivos. Dentro de una clase, los nombres de los atributos deben ser únicos (aunque puede aparecer el mismo nombre de atributo en diferentes clases). Los atributos pueden representarse solo mostrando su nombre, su tipo e, incluso, su valor por defecto. Public: Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos todos lados. Prívate: Prívate: Indica que el atributo solo será accesible dentro de la clase (solo sus métodos lo pueden acceder). Protected: Protected: Indica que el atributo no será accesible desde fuera de la clase, pero si podrá estar disponible para métodos de la clase, además de las subclases que se deriven. •

•

•

•

•

o

o

o


CIBERTEC


7

Figura 10.3. Partes de una clase •

Para los Identificadores, en el momento de incluir atributos en la descripción de una clase, se debe distinguir entre los atributos que reflejan las características de los objetos en el mundo real y los identificadores que son utilizados por razones de implementación.

Figura 10.4. Clase con identificador Vs. clase sin identificador • Guías prácticas para la definición de Clases y Atributos o o o

o

o

Las clases poseen información descriptivas; los atributos, no. Los atributos multivaluados deben ser clasificados como clases. Identificar clases asociativas de una relación muchos-a-uno entre dos clases. Asociar atributos a las clases que los describen directamente. Los atributos deben ser inherentes (propias) a la clase. Evitar los identificadores compuestos en la medida que sea posible.

1.2.2 Definir Jerarquías Generalización y Especialización son conceptos fundamentales en el Modelo Conceptual que permiten la reducción de la expresión. Las jerarquías de clases son a menudo las bases de inspiración para las jerarquías de las clases de software que exploten la herencia y reduzcan la duplicación de código fuente.


CIBERTEC

72

Figura 10.5. Jerarquía de clases Permiten gestionar la complejidad mediante un ordenamiento lógico. • Se obtiene usando los mecanismos de abstracción de Generalización y/o Especialización. • La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general. • Nombres usados: clase padre - clase hija, superclase - subclase, clase base - clase derivada • Las subclases heredan características de sus superclases, es decir, los atributos y operaciones (y asociaciones) de la superclase están disponibles en sus subclases. •

Figura 10.6. Notación de la generalización


CIBERTEC


73

Ejemplos: Recurso Prestamo

Libro

es solicitado por

Alumno

Video

Pago

Pago C redito se paga con

Tarjeta Credito

Figura 10.7. Ejemplo de generalizaciones 1.2.3. Identificar Agregaciones • La agregación indica una relación de “un todo conformado por partes” o “parte de”. • Existen 2 tipos de agregaciones: Agregación Débil o Compartida y Agregación Fuerte o Compuesta. • La agregación representa una relación parte de entre objetos. • Puede ser caracterizada con precisión determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes.

coche 1

1 motor Figura 10.8. Agregaciones entre clases a) Agregación Compartida Es un tipo de relación utilizada para modelar la relación todo-parte entre objetos. La parte puede estar simultáneamente en varias instancias del todo. La agregación existe de preferencia entre conceptos no físicos.


CIBERTEC

74

Ejemplo:

PaqueteUML

ElementoUML Figura 10.9. Agregación Compartida o Débil b) Agregación Compuesta Es un tipo de relación utilizada para modelar la relación todo-parte entre objetos. Significa que la parte es miembro de solamente un objeto todo, es decir, la existencia de la parte depende del todo. La composición se representa con un diamante relleno. El objeto todo es el único dueño del objeto parte.

Ejemplo: Venta nroVenta fecha name 1 1..*

LineaVenta nroItem cantidad subtotal

Figura 10.10. Agregación Compuesta o Fuerte 1.2.4. Asociar Clases • La asociación es una relación entre clases que indica una conexión significativa e interesante. • Está representada como una línea entre clases con nombre. La asociación es inherentemente bidireccional. • Es convencional leer la asociación de izquierda a derecha o de arriba hacia abajo. • Las asociaciones pueden ser binarias, ternarias o de mayor grado. • Criterios para identificar asociaciones Enfocarse en aquellas asociaciones para las cuales el conocimiento de la relación necesita ser conservado en el tiempo. (Asociaciones que se necesitan saber). Demasiadas asociaciones tienden a confundir. o

o


CIBERTEC


o o

•

75

Evitar mostrar asociaciones redundantes o derivables. Pueden existir múltiples asociaciones entre dos clases. Tipos de Asociaciones: Asociación Binaria Asociación Ternaria Asociación Reflexiva. o o o

Recepcionista

registra Cliente

genera

Orde n S ervicio

Figura 10.11. Asociación Binaria

Figura 10.12. Asociación Ternaria

Figura 10.13. Asociación Reflexiva 1.2.5. Analizar la Multiplicidad La multiplicidad restringe el número de objetos de una clase que se pueden implicar en una relación determinada en cualquier momento en el tiempo. Define cuántas instancias de la clase A pueden estar asociadas con una instancia de la clase B. En el siguiente ejemplo, se visualiza que en cualquier momento en el tiempo un objeto Ítem esta alojado por exactamente un objeto Almacén. Sin embargo, con el tiempo un objeto Ítem podría estar alojado por una serie de objetos Almacén. Se puede resumir diciendo que un objeto Almacén aloja varios objetos de Ítem.

•

•

•


CIBERTEC

76

aloja

Almacen 1

Item *

Figura 10.14. Análisis de multiplicidad La multiplicidad presenta las relaciones con valores de datos de acuerdo al detalle siguiente :

•

Item

Muchos

*

Item

Uno o muchos

Item

Cero o muchos

1..*

0..* 0..1

Item

Cero o uno

Item

1 a 40

Item

Exactamente 5

1..40 5

Item

3–5ó8

3,5,8

Figura 10.15. Tipos de Multiplicidades 1.2.6. Identificar clases Asociativas • •

•

Un atributo está relacionado con la asociación. Las instancias de la clase asociativa dependen del tiempo de vida de la asociación. En una asociación de muchos a muchos entre dos clases y existe información asociada con la propia asociación.

Cliente nombre

tiene registrado 1..*

1..*

Contacto Telefonico tipoContacto

Detalle Telefonico nroTelefono

Figura 10.16. Clase asociativa


CIBERTEC


77

1.2.7. Definir Operaciones Las operaciones son funciones o transformaciones que se aplican a todos los objetos de una clase particular. La operación puede ser una acción ejecutada por el objeto o sobre el objeto. Esta tarea es opcional en el modelo de análisis, se usa más en el diseño. Ejemplo:

Figura 10.17. Operaciones de una clase 1.2.8. Documentar Reglas de Negocio Las reglas del negocio identificadas durante el análisis de los requisitos se continuarán refinando a lo largo de la elaboración del modelo conceptual. Es importante que la documentación de cada regla del negocio sea ejemplificada con una situación real.


CIBERTEC

7!

Caso Práctico

A continuación se explicará cómo confecciona el modelo conceptual para el sistema “Sistema de Ventas y Control de Almacén” en base a las clases entidad identificadas en la especificación de caso de uso “Registrar Pedido On – Line” y “Buscar Repuesto” (caso de uso incluido).

ESPECIFICACIÓN DE CASO DE USO: Registrar Pedido On Line

1. Breve descripción El caso de uso permite al Cliente realizar un pedido de venta de repuestos en línea accediendo a la página Web de CIMAQ S.A. La empresa le enviara una cotización para su aprobación. 2. Actores Cliente 3. Flujo de eventos 3.1. Flujo Básico 1. El caso de uso se inicia cuando el Cliente ingresa a la página web de CIMAQ S.A. 2. El sistema muestra el Home de la página web. 3. El Cliente selecciona la opción “Registrar Pedido”. 4. El sistema muestra la interfaz “Nuevo Pedido - Cliente” con los siguientes campos: Datos del Pedido: Número del Pedido (no habilitado), Dirección de envío, número, puerta, distrito, provincia, referencia, persona de contacto y teléfono de contacto (habilitados). Datos de los repuestos (detalle): código de repuesto, descripción, cantidad (habilitado), unidad, precio unitario y total, con las opciones “Buscar Repuesto”, “Agregar Repuesto” y “Eliminar Repuesto”. Forma de pago (Contado o Crédito). Subtotal, IGV y Total del pedido (no habilitados). Además las opciones “Siguiente” y “Cancelar”. 5. El Cliente ingresa los datos del pedido. 6. El Cliente selecciona la opción “Buscar Repuesto”. 7. El sistema incluye el caso de uso “Buscar Repuesto”. 8. El sistema muestra los datos del repuesto. 9. El Cliente ingresa la cantidad de unidades requeridas para el repuesto. 10. El Cliente selecciona la opción “Agregar Repuesto”. 11. El sistema calcula el sub total por repuesto (precio unitario por cantidad), calcula el total del pedido y adiciona al detalle. 12. Si el Cliente desea agregar otro repuesto se repiten los pasos 6 a 11. 13. Si el Cliente selecciona un repuesto y la opción “Eliminar Repuesto”, ir al subflujo Eliminar Repuesto. 14. El Cliente selecciona la forma de pago (crédito o contado). 15. Si el Cliente selecciono forma de pago al contado ir al su flujo Ingresar información de pago. 16. El Cliente selecciona la opción “Registrar”. 17. El sistema valida los datos del pedido ingresados. 18. El sistema genera un código de pedido. 19. El sistema graba el pedido con la fecha actual y en estado de “Por cotizar” y su detalle, muestra el MSG “Pedido registrado exitosamente”. 20. Si la forma de pago es al contado, el sistema graba la Información del pago. 21. El sistema muestra la interfaz el Home de la página Web y el caso de uso finaliza. •

•

• •


CIBERTEC


7"

3.2. Sub Flujos 3.2.1. Eliminar Repuesto 4. El sistema elimina el(los) repuestos(s) seleccionado(s) de la lista de repuestos que se han agregado al pedido. 5. Si el Cliente desea eliminar más repuestos se repiten los pasos 1 a 3. 6. El flujo retorna al paso 14 del flujo básico. 3.2.2. Ingresar Información de Pago 7. El sistema muestra la interfaz “Información de Pago” con los siguientes campos: código de cliente, forma de pago, fecha de pago, número de cuenta y monto. Además, de las opciones “Imprimir” y “Aceptar”. 8. El cliente solicita la opción “Imprimir”. 9. El sistema imprime la información de pago. 10. El Cliente selecciona la opción “Aceptar”. 11. El flujo continúa en el paso 16 del flujo básico. 3.2.3. Cancelar Pedido 5. Si el cliente selecciona cancelar, antes de registrar el pedido 6. El sistema muestra el MSG: “Confirmar la cancelación” 7. El Cliente selecciona “SI” para cancelar pedido. 8. El sistema cancela el pedido y finaliza el caso de uso. 3.3. Flujos Alternativos 13.1. Selección obligatoria Si el cliente no selecciona ningún repuesto y solicita “Eliminar Repuesto”, el sistema muestra el MSG: “Seleccione por lo menos un repuesto a eliminar” y el caso de uso continúa en el paso 13 del flujo básico. 17.1. Datos de pedido inválidos El sistema muestra el MSG: “Datos del pedido nulos o inválidos” y el caso de uso continua en el paso 14 del flujo básico. 19.1. Error al grabar pedido Si el sistema no puede grabar el pedido el sistema muestra el MSG “Error al grabar pedido” y el caso de uso continúa en el paso 16 del flujo básico. Error al imprimir Si el sistema no puede imprimir, se muestra el MSG: “Error al imprimir documento” y el caso de uso continúa en el paso 4 del sub flujo “Información de Pago”. 4. Precondiciones 4.1. El Cliente debe estar logeado en el sistema. 5. Postcondiciones 5.1. El pedido con el detalle de los repuestos quedará grabado en el sistema. 5.2. En el sistema, el estado del pedido será “Por cotizar”. 6. Requerimientos especiales 6.1. La PC del cliente debe tener acceso a internet. 6.2. La PC del cliente debe estar conectada a una impresora. 7. Puntos de extensión Ninguno. •


CIBERTEC


Modelo conceptual (parcial)

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS I (TEORÍA) !

ACTIVIDADES PROPUESTAS 1. A partir de la Especificación del Caso de Uso “Cotizar Productos”, confeccione el Modelo Conceptual. Ver página 63. 2. A partir de la Especificación del Caso de Uso “Registrar Pago de Telefonía”, confeccione el Modelo Conceptual. Ver página 73.

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) !2

R$%&'$



En el modelo conceptual, las clases se obtienen a partir de los objetos de información que fluyen en los casos de uso. Nos gustaría subrayar, como una característica importante de nuestro enfoque, que el modelado de los casos de uso del sistema y el modelado conceptual se realizan en paralelo, esto es crucial para obtener casos de uso correctos, puesto que es necesario entender bien el dominio para poder escribir casos de uso que sean realmente útiles.



El modelo conceptual orientado a objetos beneficiará a dos equipos de trabajo:  Equipo de Desarrolladores En esta etapa del desarrollo, merece la pena detenerse en la identificación de los conceptos y no tanto en las relaciones entre ellos. Este modelo incluirá los conceptos y sus relaciones y se describirá mediante un diagrama de clases UML, en el que los conceptos se representan mediante clases (del dominio). 



Equipo de Base de Datos. En esta etapa luego del modelo conceptual, se obtiene el proceso del modelo lógico al diseño físico donde se podrá identificar las tablas relacionales del proyecto de Base de Datos como componente RUP.

Si desea saber más acerca de estos temas, puede consultar la siguiente página: http://www.gdl.cinvestav.mx/telecom/uploads/Prope_2008/Programacion/Programa cion%20OOP-1.pdf Aquí hallará en síntesis la información relacionada al modelo conceptual y la multiplicidad.

CIBERTEC



ANEO

 PLANTILLAS REQUISITOS

DE

DOCUMENTOS

DE LA

GESTIÓN

DE

CONTENIDO • • • • • • •

Plan de Gestión de Requisitos Petición del Stakeholder Documento Visión Glosario de Términos Especificación de Requisitos de Software Especificación de Casos de Uso Especificación de Requisitos Suplementarios.

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS I (TEORÍA) !4

Plan de Gestión de Requisitos

1. Introducción [Este documento describe los criterios que utiliza el proyecto para establecer documentos de requisitos estándar, tipos de requisitos, atributos de requisito, y trazabilidad. Se define una estrategia general para la gestión de requisitos y sirve como un recurso para todas las personas que participan en este proyecto] 1.1. Propósito [El propósito de este plan es establecer y documentar un enfoque sistemático para capturar, organizar y documentar los requisitos del sistema. Este plan también establece y mantiene un acuerdo entre el cliente y el equipo del proyecto sobre las necesidades cambiantes del sistema] 1.2. Alcance [Este plan proporciona la guía para la gestión del [nombre del proyecto] 1.3. Descripción [Este documento contiene detalles específicos y estrategias para la gestión de los requisitos de [nombre del proyecto]. El documento detalla cómo los requisitos están organizados y administrados dentro de nuestro proyecto. También se describe cómo los requisitos son identificados, atributos asignados, rastreados, y modificados] [El documento describe la gestión de los procesos de cambio de los requisitos. En él se describen los flujos de trabajo y actividades relacionadas con el mantenimiento del control de los requisitos de proyecto] [Se especifican los hitos que deben alcanzarse y las normas que deben ser respetadas de manera que podamos garantizar y evaluar el cumplimiento de los requisitos que se especifican] 2. Herramientas, Entorno e Infraestructura [Describe el entorno de computación y herramientas de software para ser utilizados en el cumplimiento de las funciones de gestión de requisitos a través del proyecto o del ciclo de vida del producto] Herramienta

Descripción

Rational RequisitePro

Para gestión de requisitos

Información de Licencia

Soporte Técnico

Website

[email protected] www.rati onal.co m

3. Artefactos de los Requisitos 3.1. Tipo de Documentos [Esta tabla describe los tipos de documento por defecto incluido en esta plantilla, y sus tipos requisito asociado por defecto. Usted debe agregar sus tipos de documentos personalizados a esta tabla a medida que los crea] Tipo de Documento Peticiones del Stakeholder (PSH) Vision (VIS) Especificación de Caso de Uso (ECU)

CIBERTEC

Descripción Peticiones claves de los Stakeholders Condiciones o capacidades de la versión del sistema. Elaboración y descripción del caso de uso.

Tipo de requisito por defecto Stakeholder Request (STRQ) Feature (FEAT) Use Case (UC)



Glosario (GLS) Especificación de Requerimientos Suplementarios (SUP) Plan de Gestión de Requisitos (PGR)

Usado para capturar el vocabulario común Describe los requisitos del sistema que no son fácilmente capturados por los casos de uso Describe los requisitos y estratégias específicas para la gestión y el desarrollo del proyecto

Glossary Item (TERM) Supplementary Requirement (SUPL) Ninguno (NONE)

3.2. Tipos de Requisitos [Esta tabla describe los tipos de requisitos por defecto incluido en esta plantilla. Usted debería agregar sus tipos requisitos personalizados a esta tabla a medida que los crea] 3.3. Atributos [Para cada tipo de requisito que ha identificado, defina una lista de atributos que se utilizarán y explique brevemente lo que significan. Usted puede describir los atributos y sus valores por cada tipo de requisito en diferentes secciones. A continuación, se describen cada uno de los a utilizar por cada tipo de requisito de su proyecto.] 3.4. Trazabilidad Necesidad del Stakeholder

Característica

Caso de Uso

Requerimiento Suplementario

[Para cada tipo de requisito que usted ha identificado, liste algunas reglas adicionales o directrices que se aplican a los enlaces de trazabilidad. Describa las limitaciones aplicables, tales como "todas las características aprobadas deben rastrear a uno o más Casos de Uso o a uno o más Requisitos Suplementarios.”] Tipo de Requisito Stakeholder Request (STRQ) Feature (FEAT) Use Case (UC) Glossary Item

CIBERTEC

Directrices

Notas



(TERM) Supplementary Requirement (SUPL)

.

3.5. Informes / Medidas [Describa el contenido, formato y propósito de los informes y medidas de requisitos. Use las plantillas de la tabla para describir los informes que usted genera usando RequisitePro’s Requirements Metrics tool. Para más información revise RequisitePro online help] Descripciones de la Vista: [Use esta sección para describir las vistas que has creado para tu proyecto] Nombre de la Descripción Vista de Trazabilidad FEAT no trazadas de STRQ

Tipo de Atributos Requisito FEAT, STRQ

n/a

Rango de valor del atributo No trazado

SUPL no trazadas de FEAT UC no trazadas de FEAT Todas los FEAT

SUPL, FEAT

n/a

No trazado

UC, FEAT

n/a

No trazado

FEAT

todo

todo

FEAT, STRQ

n/a

todo

TERM

todo

todo

FEAT impactados por cambios de STRQ SUPL impactados por cambios de FEAT

FEAT, STRQ

n/a

Solo sospechoso

SUPL, FEAT

n/a

Solo sospechoso

UC impactados por cambios de FEAT Todas las STRQ

UC, FEAT

n/a

STRQ

todo

Solo sospechoso todo

Todos los SUPL

SUPL

todo

todo

SUPL trazadas de FEAT Estudio de los UC

SUPL, FEAT

n/a

todo

UC

nombre, breve descripción n/a

nombre, breve descripción todo

FEAT trazadas de STRQ Todos los TERM

UC trazadas de FEAT

CIBERTEC

UC, FEAT



Petición del Stakeholder 1. Introducción [Este documento describe las necesidades del o los stakeholder (s) de la organización a través de técnicas de recolección de captura de requisitos] 2. Perfil del Stakeholder Nombre: [Indicar el nombre del stakeholder] Compañía: [Indicar el nombre de la compañía] Cargo: [Indicar el cargo del stakeholder] • • •

3. Lista de requerimientos 3.1 [Descripción de una característica software, ámbito y propiedades de la misma] 3.2 [Descripción de una característica software, ámbito y propiedades de la misma]

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) !!

Documento Visión 1. Introducción 1.1. Propósito [Breve descripción del propósito del presente documento, como puede ser servir de soporte a la especificación de las características software y de los atributos de las mismas, por ejemplo. También reflejar si el sistema que se modela está dividido en otros subsistemas o bien el propósito general de la empresa.] 1.2. Alcance [Definición del alcance del presente documento, es decir, todo ámbito del que recoge características o detalles.] 1.3. Definiciones, Acrónimos, y Abreviaciones [RUP: Son las siglas de Rational Unified Process. Se trata de una metodología para describir el proceso de desarrollo de software.] 1.4. Referencias - Glosario. - Plan de desarrollo de software. - RUP (Rational Unified Process). - Diagrama de casos de uso. 2. Posicionamiento Oportunidad de Negocio [Ventajas que obtendrá la empresa al implantar el sistema informático.] Sentencia que define el problema Sentencia que define la posición del Producto 3. Descripción de Stakeholders y Usuarios [Para proveer de una forma efectiva productos y servicios que se ajusten a las necesidades de los usuarios, es necesario identificar e involucrar a todos los participantes en el proyecto como parte del proceso de modelado de requisitos. También es necesario identificar a los usuarios del sistema y asegurarse de que el conjunto de participantes en el proyecto los representa adecuadamente. Esta sección muestra un perfil de los participantes y de los usuarios involucrados en el proyecto, así como los problemas más importantes que éstos perciben para enfocar la solución propuesta hacia ellos. No describe sus requisitos específicos ya que éstos se capturan mediante otro artefacto. En lugar de esto proporciona la justificación de por qué estos requisitos son necesarios.] 3.1. Resumen de Stakeholders [Hay varios stakeholders con un interés en el desarrollo. Presente una lista de estos stakeholders.] 3.2. Resumen de Usuarios [Hay varios usuarios con un interés en el desarrollo. Presente una lista de ellos.]

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) !"

3.3. Entorno de usuario [Descripción del entorno de trabajo del usuario, características de los PC’s a utilizar, sistemas operativos, etc.] 3.4. Perfil de los Stakeholders [Describa cada stakeholder en el sistema rellenando la tabla siguiente para cada stakeholder. Recuerde que los tipos de stakeholder pueden ser usuarios, departamentos o diseñadores técnicos. Un perfil completo cubriría los temas siguientes para cada tipo de stakeholder.] 3.4.1 3.5. Perfiles de Usuario 3.5.1 4. Descripción Global del Producto 4.1 Perspectiva del producto [Ámbito de aplicación del sistema y expectativas del mismo] 4.2 Resumen de características [A continuación se mostrará un listado con los beneficios que obtendrá el cliente a partir del producto:] 4.3 Suposiciones y dependencias [Todas las suposiciones y dependencias deben ser definidas por el cliente] 4.4 Costo y precio [El costo y precio del sistema con todas las características software son decisión entre cliente y empresa de desarrollo software] 5. Características Globales del Producto 5.1 [Descripción de una característica software, ámbito y propiedades de la misma] 5.2 [Descripción de una característica software, ámbito y propiedades de la misma] 5.2.1 [Descripción de una característica software que deriva de una característica software jerárquicamente superior, ámbito y propiedades de la misma] 6. Requisitos de Documentación 6.1 Manual de Usuario [A definir por el cliente] 6.2 Ayuda en Línea [A definir por el cliente] 6.3 Guías de Instalación, Configuración, y Fichero Léame [A definir por el cliente]

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) "#

Glosario de Términos

1. Introducción [Este documento es usado para definir la terminología específica para el dominio del problema, explicando términos que no pueden ser familiares para leer la descripción de un caso de uso u otro documento del proyecto. Frecuentemente este documento puede ser usado como un diccionario de datos informal, capturando definiciones de datos.] 2. Definiciones [Los términos definidos aquí son la escencia sustancial del documento. Se ordena en orden alfabético.] 2.1. [La definición de un término es presentado aquí, para entender el concepto.] 2.2. [La definición de otro término es presentado aquí, para entender el concepto.]

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) "

Especificación de Requisitos de Software 1. Introducción [La introducción de la Especificación de Requerimientos de Software debe ser un resumen del documento completo. Debe incluir el propósito, ámbito, definiciones, acrónimos, abreviaciones, referencias, y resumen ejecutivo de este documento] 1.1. Propósito [El propósito de este documento es capturar todos los requerimientos de software del sistema, o un subconjunto del sistema.] 1.2. Ámbito [Párrafo obligatorio.] [Una descripción del entorno afectado; qué proyectos se ven afectados o influenciados por esta Especificación de Requerimientos de Software.] 1.3. Definiciones, Acrónimos y Abreviaciones [Párrafo obligatorio si existen términos, definiciones acrónimos o abreviaciones.] [Esta subsección debe proporcionar las definiciones de todos los términos, acrónimos, y abreviaciones requeridas para interpretar correctamente la Especificación de Requerimientos de Software. Esta información puede ser entregada a modo de referencia al Glosario del proyecto.] [Recomendación: Se sugiere mantener solo un glosario para el proyecto.] 1.4. Referencias [Párrafo obligatorio si existen referencias.] [Esta subsección debe entregar una lista de todos los documentos referenciados en cualquier lugar de esta Especificación de Requerimientos de Software. Cada documento debe ser identificado por título, edición (si es aplicable), fecha, y editorial. Especificar las fuentes de donde se pueden obtener estas referencias, esta información puede ser entregada como referencia a un apéndice o a otro documento.] 1.5. Resumen Ejecutivo [Párrafo NO obligatorio.] [Esta subsección debe describir el resto del documento conteniendo y explicando como esta organizado.] 2. Descripción General [Se considera en esta parte la descripción de los factores principales que afectan al espacio de la solución. Incluya aquellos ítems como perspectiva del producto, funciones del producto, características de usuario, limitaciones, supuestos y dependencias. No se incluye en esta sección la descripción de los requerimientos.] 2.1. Especificación de Funcionalidades [Párrafo obligatorio.] [Si usa el modelado de casos de uso, esta sección debe contener la referencia de éste, y una descripción o resumen del modelo o del subconjunto más representativo del mismo. Esto incluye una lista de nombres y breves descripciones de los casos de uso, actores, diagramas aplicables y relaciones. En caso de no existir modelo de caso de uso se deben referenciar todas las descripciones existentes de las funcionalidades, ya sean minutas de reunión,

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) "2

correos electrónicos, etc. Es necesario agregar esas descripciones en esta sección y en la sección 1.4 Referencias del documento se necesitan mencionar todos los fuentes de los requerimientos.] [Este punto se puede reemplazar con la plantilla Excel de Administración de Requerimientos haciendo referencia.] 2.2. Supuestos y Dependencias [Párrafo obligatorio.] [Esta sección describe cualquier factibilidad técnica clave, disponibilidad de componentes o subsistemas, u otros supuestos realizados en los cuales la viabilidad del software descrito en esta Especificación de Requerimientos de Software se base.] 2.3. Acuerdos con el Cliente para la Administración de Requerimientos [Párrafo obligatorio.] [En esta sección se define cómo se tratarán los cambios de los requerimientos. Normalmente, en la Orden de Servicio se define un porcentaje como cuota para realizar posibles cambios en los requerimientos. Este impacto se mide en la cantidad de horas/hombre que requiera esta modificación.] 3. Especificación de Requerimientos [Esta sección debe describir detalladamente todos los requerimientos de software, de forma de permitir a los analistas, diseñar el sistema para satisfacer los requerimientos como también a los testeadores diseñar un plan de testing adecuado para poder verificar el cumplimiento de los mismos. Cuando se usa el modelado de casos de uso, estos requerimientos se capturan en los casos de uso, y en las especificaciones adicionales aplicables, Si no se usa el modelado de casos de uso, la definición de especificaciones adicionales debe insertarse directamente aquí.] 3.1. Reportes de Casos de Uso [Párrafo obligatorio.] [En modelado de casos de uso, ellos definen la mayoría de los requerimientos funcionales del sistema y algunos requerimientos no funcionales. Para cada caso de uso en el modelo superior, o subconjunto del mismo, refiérase o cierre el reporte de caso de uso en esta sección. Asegúrese de que cada requerimiento esta claramente etiquetado.] [Para proyectos pequeños, de duración menor a un mes y un equipo de menos de 3 personas, este párrafo se puede reemplazar con una referencia a documento Análisis Preliminar.] 3.2. Requerimientos Funcionales [Párrafo obligatorio.] [En esta sección se deben describir todos los requerimientos funcionales en forma detallada, esta sección debe ser usada cuando las funcionalidades no son transacciones de algún framework transaccional. La descripción debe ser suficientemente clara para permitir a los diseñadores hacer un diseño apropiado, los programadores entender funcionalidad y a los testeadores elaborar un plan de testing apropiado.] [Este punto se puede reemplazar haciendo referencia a la plantilla Excel de Administración de Requerimientos.] 3.3. Requerimientos no Funcionales [Párrafo obligatorio.]

CIBERTEC



[En esta sección se describen los aspectos no funcionales, tales como tiempo de respuesta, estética de la aplicación, facilidad de navegación, etc.] [Este punto se puede reemplazar haciendo referencia a la plantilla Excel de Administración de Requerimientos.] 3.4. Requerimientos Técnicos [Párrafo obligatorio.] [En esta sección se describen los requerimientos técnicos, tales como sistema operativo, plataforma de arquitectura, por ejemplo WebSphere, .NET, etc.] [Este punto se puede reemplazar referenciando a la plantilla Excel de Administración de Requerimientos.] 3.5. Requerimientos de Proceso [Párrafo obligatorio.] [En esta sección se describen los requerimientos de proceso. Por ejemplo, para desarrollo se necesita usar proceso de desarrollo en cascadas, RUP, XP, ITDA- KP,… Este párrafo se puede relacionar con artefacto Configuración del Proceso o con el Plan del Proyecto.] [Este punto se puede reemplazar haciendo referencia a la plantilla Excel de Administración de Requerimientos.] 4. Administración de Requerimientos [Párrafo obligatorio.] [En esta sección se especifica cómo se realizará el seguimiento de los requerimientos, y los documentos asociados a este seguimiento, así mismo, en esta sección, se describen cómo se realizarán los posibles cambios o nuevas modificaciones existentes durante el proyecto. Esto normalmente se puede seguir con la plantilla Excel de Administración de Requerimientos al cual se debe referenciar en esta sección.]

CIBERTEC



Especificación de caso de uso: 1. Breve Descripción [Breve descripción en líneas generales de la funcionalidad del caso de uso, de los actores que intervienen y del entorno de invocación] 2. Actores [Indicar los actores que interactúan con el caso de uso] 3. Flujo de Eventos 3.1. Flujo Básico [Detallar la secuencia de pasos entre el actor (es) y el sistema. Aquí se pueden hacer referencia a casos de uso incluidos. Además que pueden invocarse a los subflujos.] 1. 2. 3.2. Sub Flujos [Detallar la secuencia de pasos entre el actor (es) y el sistema. Aquí se pueden hacer referencia a casos de uso incluidos. Además que pueden invocarse a los subflujos.] 1. … [Descripción del sub flujo, bifurcación del flujo básico y también detalla interacción entre el actor y el sistema.] 3.3. Flujos Alternativos [Descripción del flujo alternativo, en qué punto se puede producir, qué acciones se realizarán, mensajes, etc. Pueden generar casos de uso extendidos.] [Descripción del flujo alternativo, en qué punto se puede producir, qué acciones se realizarán, mensajes, etc. Pueden generar casos de uso extendidos.] 4. Precondiciones [Indica las condiciones del sistema en el pasado, antes que se ejecute el caso de uso Las precondiciones se pueden eliminar si no son relevantes] 5. Poscondiciones [Indica las condiciones a futuro, cómo quedará el sistema después que se ejecute el caso de uso. Las poscondiciones se pueden eliminar si no son relevantes] 6. Requerimientos especiales [Aquí se pueden indicar requerimientos no funcionales para el caso de uso.] 7. Puntos de Extensión [En este párrafo se hacen las referencias a los casos de uso extendidos. Las puntos de extensión se pueden eliminar si no son relevantes] 8. Prototipos [Aquí se diseñan las pantallas, reportes, etc. que permitirá la interacción del actor con el sistema y/o lo que se obtenga como resultado en pantallas o reportes.]

CIBERTEC



Especificación de Requisitos Suplementarios 1. Introducción [La introducción debe proporcionar una visión general del documento Requerimientos Suplementarios . Los Requerimientos Suplementarios capturan los requerimientos del sistema que no son prontamente capturados en los casos de uso del Modelo de Casos de Uso. Estos requerimientos incluyen los siguientes aspectos: Requerimientos legales y reguladores, incluyendo los estándares de la aplicación. Atributos de calidad del sistema a ser construido, incluyendo usabilidad, fiabilidad, performance y requerimientos de soporte. Requerimientos tales como sistemas operativos y entorno, compatibilidad y restricciones de diseño.] 1.1.Propósito [Esta sección debe indicar el propósito de los Requerimientos Suplementarios y la audiencia esperada para este documento.] 1.2.Alcance [Esta sección debe contener una breve descripción del alcance de los Requerimientos Suplementarios y todo lo que es afectado o influenciado por este documento.] 1.3. Definiciones, siglas y abreviaturas. [Esta sección debe proporcionar las definiciones de todos los términos, las siglas y abreviaciones requeridas para interpretar apropiadamente el documento Requerimientos Suplementarios . Esta información puede proporcionarse por la referencia al Glosario del proyecto.] 1.4.Referencias [Esta sección debe proporcionar una lista completa de todos los documentos a los que se hace referencia en el documento Requerimientos Suplementarios . Cada documento debe identificarse por el título, número del informe (si se aplica), fecha, y organización que lo publica. Especifique las fuentes de las que pueden obtenerse las referencias. Esta información puede proporcionarse por la referencia a un apéndice o a otro documento.] 1.5. Visión general [Esta sección describe qué contiene el resto del documento Requerimientos Suplementarios y explica cómo se organiza este documento.] 2. Funcionalidad [Esta sección describe los requerimientos funcionales del sistema que se expresan en lenguaje natural. Generalmente, se organiza por funcionalidad pero se puede organizar alternativamente por usuario, por subsistema. Los requisitos funcionales pueden incluir conjuntos de funcionalidades, capacidades y seguridad.] 2.1. [Requerimiento Funcional 1] [Descripción del requerimiento] 3. Usabilidad [Esta sección incluye los requerimientos que afectan la usabilidad. Por ejemplo: especificar el tiempo requerido para capacitación de usuarios normales y especializados para ser productivos en determinadas funciones. especificar tiempos mensurables para tareas típicas. especificar requerimientos para cumplir con los estándares comunes de usabilidad.] 3.1. [Requerimiento de usabilidad 1] [Descripción del requerimiento] •

• •

CIBERTEC



4. Fiabilidad [En esta sección se describen los requerimientos de fiabilidad. Por ejemplo: Disponibilidad: especifica el porcentaje de tiempo disponible, horas de uso, acceso para mantenimiento, etc. Tiempo medio entre fallas. Tiempo medio para reparación: cuánto tiempo es posible que el sistema esté inoperante después que falla. Exactitud: especificar la precisión y exactitud (según algún estándar conocido) que se requiere para las salidas del sistema. Cantidad máxima de errores o porcentaje de defecto: generalmente expresado en términos de errores por miles de líneas de código o errores por punto funcional. Errores o porcentaje de defecto: categorizados en términos de errores menores, significantes y críticos (se debe definir qué significa error “crítico”, por ejemplo, pérdida completa de dato o imposibilidad de uso de ciertas funcionalidades del sistema).] 4.1. [Requerimiento de Fiabilidad 1] [Descripción del requerimiento] •

• •

•

•

•

5. Performance [En esta sección se deben especificar las características de performance del sistema. Incluye tiempos de respuesta específicos. Si se aplica, haga referencia al Caso de Uso relacionado por su nombre. Un ejemplo de contenido de esta sección sería: 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, cuál es el modo aceptable de funcionamiento cuando el sistema ha sido degradado de alguna manera. Utilización de recursos: memoria, disco, comunicaciones, etc.] 5.1. [Requerimiento de Performance 1] [Descripción del requerimiento] • • •

•

•

6. Soporte [Esta sección incluye requerimientos que refuercen 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 en lo que refiere a organización de Bases de Conocimiento y cómo se nombran organizan y denominan los objetos en cada Base de Conocimiento. Adjunte o haga referencia a los documentos de Metodología Genexus y Nomenclatura.] 6.1. [Requerimiento de Soporte 1] [Descripción del requerimiento] 7. Componentes comprados [Esta sección describe los componentes comprados que se usarán con el sistema, las licencias necesarias o restricciones de uso y todo lo asociado con compatibilidad o interoperabilidad o interfases estándares.] 8. Requerimientos de Autorización (licenciamiento) [Define requerimientos de autorización o restricción de uso que debe tener el software.]

CIBERTEC



9. Leyes, derechos de propiedad literaria y avisos [Esta sección describe cualquier restricción legal necesaria, garantías, avisos de propiedad literaria, aviso de patente, marca de fábrica o logotipo que deba incluir el software.] Estándares aplicables [Esta sección describe mediante referencia a todos los estándares que serán aplicados y las secciones específicas donde serán aplicados en el sistema que se describe.]

CIBERTEC


ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA) "!

*+,%-./, Abstracción Características esenciales de una entidad que la distingue de otros tipos de entidades. Define una frontera desde la perspectiva del observador. API Una API representa una interfaz de comunicación entre componentes de software. Se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los procesos y representa un método para conseguir abstracción en la programación, generalmente (aunque no necesariamente) entre los niveles o capas inferiores y los superiores del software. Artefacto Pieza discreta de información que es utilizada o producida por un proceso de desarrollo de software. Aspecto Módulo software que no puede ser encapsulado en un procedimiento. Los aspectos no son unidades funcionales en las que se pueda dividir un sistema, sino propiedades que afectan a la ejecución o semántica de los componentes. Son conocidos también como intereses transversales. Elemento Constituyente atómico de un modelo. Especificación Descripción textual de la sintaxis y la semántica de un bloque de construcción específico; descripción declarativa de lo que algo es o hace. Estereotipo Extensión del vocabulario de UML que permite crear nuevos bloques de construcción derivados a partir de los existentes pero específicos a un problema concreto. Gestión de Requisitos Actividad para gestionar los cambios en los requisitos del sistema. La gestión implica el control de cambios y el impacto de los cambios. Ingeniería de Requisitos Es un área de investigación que procura atacar un punto fundamental en el proceso, que es la definición de lo que se quiere producir. Ingeniería de Software Rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas a los proyectos de desarrollo o mantenimiento de software de calidad.

CIBERTEC


ManualTeoria calidad de software

Recommend Documents