ManualTeoria calidad de software

7/24/2019 ManualTeoria calidad de software

http://slidepdf.com/reader/full/manualteoria-calidad-de-software 1/199

Análisis y Diseño de

Sistemas II - TeoríaAdministración y Sistemas



2

CARRERAS PROFESIONALES CIBERTEC



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


Í NDICE

Presentación 5

Red de contenidos 6

Sesiones de aprendizaje

UNIDAD 1

TEMA 1 : Ingeniería de requisitos. 7

El proceso de la ingeniería de requisitos. 13

Gestión de los requisitos. 17

TEMA 2 : Pirámide de requisitos. 20

Características de un buen requisito. 26

TEMA 3 : Gestión de Requisitos en RUP. 33

Visión general de la Gestión de Requisitos en RUP. 34

TEMA 4 : Documentos – Atributos. 71Documentos de la Ingeniería de Requisitos. 72

Atributos de los tipos de requisitos. 81

TEMA 5 : Trazabilidad de Requisitos. 88

UNIDAD 2

TEMA 6 : Repaso de Modelado del negocio y Captura de Requisitos. 99

Modelado del negocio. 100

Captura de requisitos. 105

Captura de requisitos a partir del Modelado del Negocio. 108

Estructurando el Modelo de casos de uso. 109

Priorización de casos de uso. 112

TEMA 7 Análisis orientado a objetos. 125

Modelo de análisis. 128

Análisis de la Arquitectura. 129

TEMA 8 : Análisis de casos de uso. 137



4


Realizaciones de Análisis. 143

TEMA 9 : Análisis de clases. 156

Tarjetas CRC (Clase – Responsabilidad – Colaboración). 158

TEMA 10 : Modelo conceptual. 168

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

Glosario. 198





PRESENTACIÓN

Análisis y Diseño de Sistemas II pertenece a los cursos de línea formativa y sedicta en la carrera de Administración y Sistemas. El curso imparte conocimientosrelacionados el proceso de la gestión de ingeniería de requisitos y al análisisorientado 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 unade ellas, hallará los logros, que debe alcanzar al final de la unidad; el tematratado, el cual será ampliamente desarrollado; y los contenidos, que debedesarrollar, es decir, los subtemas. Por último, encontrará las actividades quedeberá desarrollar en cada sesión, que le permitirán reforzar lo aprendido en laclase.

El curso es eminentemente práctico: consiste en un taller de desarrollo deproyectos 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 derequisitos a utilizar, además de la gestión de cambios de los requisitos utilizandolas vistas y matrices. Se concluye con la disciplina de análisis orientado a objetosque incluye el modelo de análisis, análisis de la arquitectura, análisis de casos deuso, análisis de clases y modelo conceptual. Durante el curso, con el apoyo dellaboratorio, se utilizarán las herramientas Rational Requisite Pro y RationalSoftware Architect.



6


RED DE CONTENIDOS

Análisis y Diseño de Sistemas II

Análisis orientadoa objetos

Modelo deanálisis

Arquitecturade análisis

Análisis decasos de uso

Análisis declases

Modeloconceptual

Ingeniería derequisitos

Proceso de laingeniería de

requisitos

Pirámide derequisitos

Gestión derequisitossegún RUP

Trazabilidad de

requisitos





INGENIERÍA DE REQUISITOS LOGRO DE LA UNIDAD DE APRENDIZAJE

Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y nofuncionales de un software que da soporte a un proceso de negocio, y controla suscambios haciendo uso de la herramienta CARE IBM Rational Requisite Pro.

TEMARIO

1. Introducción a la Ingeniería de Requisitos2. Proceso de Ingeniería de Requisitos3. 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 laherramienta Rational Requisite Pro.

UNIDAD DE

APRENDIZAJE

TEMA



!


1. INTRODUCCIÓN A LA INGENIERÍA DE REQUISITOSEn el proceso de desarrollo de un sistema, sea web o de escritorio, el equipo dedesarrollo se enfrenta al problema de la identificación de los requisitos. Ladefinición de las necesidades del sistema es un proceso complejo, pues en él hayque 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 yestructurada que ofrezca un marco de desarrollo que garantice la calidad delresultado. Por el contrario, existe un conjunto de técnicas, cuyo uso proponen lasdiferentes metodologías para el desarrollo de aplicaciones y que en general,buscan en recopilar la mayor cantidad de requisitos correctos para así conformaruna 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 losresultados que se obtengan, depende en gran medida tanto del equipo de análisisy desarrollo, como de los propios clientes o usuarios participantes.

La Ingeniería de Requisitos (IR) es un proceso que propone la utilización detécnicas repetibles y sistemáticas para asegurar la completitud, consistencia yrelevancia de los requisitos de un sistema. Este proceso no sólo se realiza en lasprimeras etapas del desarrollo de un proyecto, sino que influye decisivamente enel resto del proceso de desarrollo y mantenimiento.

1.1. Antecedentes

Las principales causas del surgimiento de la IR o gestión de requisitos, comoalgunos autores la denominan, fueron los resultados de las investigacionesrealizadas por diversas entidades a raíz de la denominada "Crisis del

Software1

". Estos resultados brindaron interesantes pistas sobre dóndemejorar el trabajo durante el ciclo de desarrollo de software y porconsiguiente reducir los fracasos y problemas.

Algunas de las instituciones que realizaron informes y análisis estadísticosson los siguientes: GAO2, cuyo personal analizó proyectos de desarrollo desoftware para el gobierno norteamericano; el ESPITI3, que realizóinvestigaciones sobre los principales problemas en el desarrollo de software anivel europeo, y cuyos resultados son muy similares a los obtenidos por TheStandish Group4, indicando que los mayores problemas de proyectos dedesarrollo en Estados Unidos están relacionados con la gestión de requisitos.

La seriedad y el profesionalismo del grupo Standish lo convirtieron en unreferente mundial sobre los factores que inciden en el éxito o fracaso de losproyectos de TI, exponiendo sus análisis periódicas desde 1994 en "TheCHAOS Report5".

1 Crisis del software es un término acuñado al hecho de que muchos desarrollos de software nohan 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 profesionalesde 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 StandishGroup realiza a los responsables de proyectos de desarrollo de software.



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


A continuación se exponen las circunstancias que han convencido a la granparte de la comunidad de la ingeniería del software de la necesidad, cada vezmayor, de una ingeniería de requisitos.

En 1979, GAO realizó un estudio seleccionando nueve proyectos dedesarrollo de software para el gobierno norteamericano cuyos contratossumaban una cantidad total de $ 6,800.000. De esta cantidad, sólo $ 119,000correspondían a un proyecto que se había utilizado tal como se habíaentregado. Dicho proyecto fue desarrollado en COBOL, por lo que era unproblema relativamente simple cuyos requisitos eran comprendidos porclientes 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 figura1.1, en la que puede destacarse el enorme porcentaje de dinero invertido enproyectos cancelados o no satisfactorios.

Figura 1.1. Resultado del informe de GAO (1979)

Después de 15 años, el estudio que el grupo Standish realizó en 1994 fuemucho 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 desoftware y sus principales problemas en Estados Unidos.

Los resultados de estos informes muestran que casi un tercio de losproyectos de desarrollo de software se cancelan durante su desarrollo y que

más del 50 % presenta graves desviaciones respecto a plazos ypresupuestos iniciales.

Los resultados generales, que pueden verse en la figura 1.2, si se comparacon los de GAO, presentan una mejora en los proyectos que se entregancumpliendo todos sus requisitos, 2% frente al 16.2%, pero empeoranligeramente 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 delgasto final fue del 189% del presupuesto original, el tiempo necesario para surealización del 222% del plazo original y se cumplieron una media del 61% delos requisitos iniciales; cifras que se dieron tanto en pequeñas como engrandes compañías.

Fuente: Informe de GAO - 1979.



#


Figura 1.2. Resultado del informe CHAOS (1994)

En este sentido, el grupo consultor citado clasifica los proyectos en trescategorías:• Proyectos exitosos (successful): Aquellos que son completados a

tiempo y, según el presupuesto, con todas las características yfuncionalidades especificadas inicialmente.

• Proyectos con desafíos o problemas (challenged): Aquelloscompletados y en operación pero con retrasos de implementación porencima 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 estudioindicaron que, en su opinión, los tres principales factores de éxito eran lossiguientes:• 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 uninforme similar (el informe ESPITI) realizado en la Unión Europea en 1996. Acontinuació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.

Fuente: Informe CHAOS por The Standish Group [TSG

199!.



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


Estos informes ponen de manifiesto el hecho de que, a pesar de que lasherramientas para construir software han evolucionado enormemente, sesigue produciendo software que no es satisfactorio para los clientes yusuarios.

Esto indica que los principales problemas de la crisis del software residen enlas primeras etapas del desarrollo, cuando hay que decidir las característicasdel producto software a desarrollar; por lo que no es de extrañar que aquellosproyectos en los que no se determinan correctamente los requisitos ycambian frecuentemente durante el desarrollo, superen con creces el tiempoy presupuesto inicial.

1.2 Definición

Existen varias definiciones acerca de la ingeniería de requisitos que nosproporcionan varios autores según su nivel de experiencia, sentido común osimplemente por su forma de ver los requisitos respecto al desarrollo de un

determinado proyecto. En esta disciplina principalmente se identifican dosaspectos muy importantes: el primero que es el propósito del sistema que seva a desarrollar y el segundo, el contexto en el que será usado. En base aestas características, se citan algunas definiciones:

Según IEEE6

• Proceso de estudio de las necesidades de los usuarios con el objeto dellegar 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 establecerespecificaciones precisas.

Según Barry Boehm

• Ingeniería de Requisitos es la disciplina para desarrollar unaespecificación completa, consistente y no ambigua, la cual servirá comobase para acuerdos comunes entre todas las partes involucradas y endonde se describen las funciones que realizará el sistema.

Según Pericles Loucopoulos

• Trabajo sistemático de desarrollo de requisitos, a través de un procesoiterativo y cooperativo de análisis del problema, documentando losresultados en una variedad de formatos y probando la exactitud delconocimiento adquirido.

Según Julio César Sampaio do Prado Leite

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

6 IEEE, Institute of Electrical and Electronics Engineers.



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 veamosdatos interesantes sobre la situación de dichos proyectos obtenidos delanálisis realizado por The Standish Group publicados en The CHAOS Reportdesde 1994:

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 incrementocontinuo del éxito de los proyectos frente al porcentaje de proyectosfracasados. Sin embargo, si nos fijamos en los porcentajes del último año, el44% de proyectos challenged nos indica que seguimos teniendo problemasen la entrega de los productos.

Las causas que provocan el fracaso de un proyecto TI son diversas, lasmismas que deben ser gestionadas para minimizar su impacto en losproyectos. El grupo Standish logró identificar, los 10 componentes másimportantes que hacen exitoso un proyecto y aquellos que llevan al fracaso.Estos componentes se muestran en la siguiente tabla.

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

Éxito Fracaso

1 Usuarios involucrados Requisitos incompletos

2 Apoyo ejecutivo No se involucra al usuario

3 Requisitos claros Falta de recursos

4 Planificación adecuada Expectativas no realistas

5 Expectativas realistas Falta de apoyo ejecutivo

6 Hitos de proyectos pequeños am!ios en requisitos y especificaciones

7 Personal competente Falta de planificación

8 Propiedad clara del proyecto "a no necesitan el sistema

9 #isión y o!jetivos claros Falta de $estión de %&

10 Equipo de alto rendimiento y !ienorientado

&ncompetencia tecnoló$ica

Evolución de los resultados del análisis CHAOS

Report

0%

50%

100%

Successful Challenged Failed

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%

1994 1996 1998 2000 2002 2004 2006 2009





1.4. Importancia de la Ingeniería de Requisitos

A continuación, se mencionan los principales beneficios que se obtienen de laingenierí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 biendefinidos.

• Mejora la capacidad de predecir cronogramas de proyectos, así como susresultados: La IR proporciona un punto de partida para controlessubsecuentes y actividades de mantenimiento, tales como estimación decostos, tiempo y recursos necesarios.

• Disminuye los costos y retrasos del proyecto: Muchos estudios handemostrado que reparar errores por un mal desarrollo no descubierto atiempo 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 requisitosrepresenta una forma de consenso entre clientes y desarrolladores. Sieste consenso no ocurre, el proyecto no será exitoso.

• Evita rechazos de usuarios finales: La ingeniería de requisitos obliga alcliente a considerar sus requisitos cuidadosamente y revisarlos dentro delmarco del problema, por lo que se le involucra durante todo el desarrollodel proyecto.

2. EL PROCESO DE INGENIERÍA DE REQUISITOSLa meta del proceso de la IR es crear y mantener los documentos de requisitos delsistema. 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 útilpara el negocio.

2. Obtención y análisis de requisitos, el cual consiste en el levantamiento deinformación de los requisitos.

3. Especificación de requisitos, que conlleva a la documentación de losrequisitos 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 seelaboran en cada una de ellas.



4


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 lossistemas los requisitos cambian. Las personas involucradas desarrollan una mejorcomprensión de lo que quieren que haga el software; la organización que comprael sistema cambia; se hacen modificaciones a los sistemas hardware, software yal entorno organizacional. El proceso de gestionar estos cambios en los requisitosse denomina “Gestión de Requisitos”, tema que se abordará al final de estasección.

2.1. Estudio de viabilidad

Esta actividad debería realizarse si el equipo de desarrollo se enfrenta a unsistema nuevo. Consiste en realizar un informe para el equipo de desarrollodel proyecto y al usuario o cliente. En el informe se recomendará si merece ono 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 dentrode las restricciones de costos y tiempo?

3. ¿Puede integrarse el sistema con otros sistemas existentes en laorganización?

La interrogante si que el sistema contribuye a los objetivos del negocio escrítica, si no contribuye a estos objetivos, entonces no tiene un valor real en elnegocio.

Llevar a cabo el estudio de viabilidad, que normalmente lleva dos o tressemanas, comprende la evaluación y recopilación de la información, y la

Estudio deviabilidad

Obtención yanálisis dere uisitos

Informe de

viabilidad

Especificaciónde requisitos

Validación derequisitos

Modelos

del sistema

Requisitos

del sistema

Documento

de requisitos





redacción de informes. Esta fase identifica la información requerida paracontestar las tres preguntas anteriores. Una vez que dicha información se haidentificado, se debería hablar con las fuentes de información, como los jefesde los departamentos donde se utilizará el sistema, los ingenieros desoftware que están familiarizados con el tipo de sistema propuesto, losexpertos en tecnología y los usuarios finales del sistema; para descubrir lasrespuestas a estas preguntas.

2.2. Obtención y análisis de requisitos

En esta actividad, el equipo de desarrollo entra en contacto con el usuariofinal o con el cliente para determinar el alcance del proyecto o del sistema aconstruir, además, de identificar cuáles son los servicios que prestará elsistema, su rendimiento, sus necesidades y restricciones, y los objetivosesperados.

La obtención y análisis de requisitos pueden afectar a varias personas de laorganización. El término stakeholder se utiliza para referirse a cualquier

persona o grupo que se verá afectado por el sistema, directa oindirectamente. Entre los stakeholders se encuentran los usuarios finales queinteractúan con el sistema, los ingenieros que desarrollan o danmantenimiento a otros sistemas relacionados, los gerentes del negocio, losexpertos en el dominio del sistema y todos aquellos que puedan verseafectados por su instalación.

Obtener y comprender los requisitos de los stakeholders es difícil por variasrazones:1. Los stakeholders a menudo no conocen lo que desean obtener del

sistema, solo en términos muy generales; puede resultarles difícil expresarlo que quieren que haga el sistema o pueden hacer pedidos irrealesdebido a que no conocen el costo de sus peticiones.

2. Los stakeholders expresan los requisitos con sus propios términos, deforma natural y con un conocimiento implícito de su propio trabajo. Losingenieros de requisitos, sin experiencia en el dominio del cliente, debencomprender estos requisitos.

3. Diferentes stakeholders tienen requisitos distintos, que pueden expresarlode varias formas. Los ingenieros de requisitos tienen que considerar todaslas fuentes potenciales de requisitos, y descubrir las concordancias y losconflictos.

4. Los factores políticos pueden influir en los requisitos. Por ejemplo, losdirectivos 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álisises dinámico. Inevitablemente, cambia durante el proceso de análisis. Porlo tanto, la importancia de ciertos requisitos pueden cambiar. Puedenemerger nuevos requisitos de nuevos stakeholders.

Es imposible satisfacer completamente a todos los stakeholders. Es labor delingeniero de requisitos, durante el proceso, organizar frecuentesnegociaciones con ellos para llegar a acuerdos. De lo contrario, si algúnstakeholder piensa que sus opiniones no se han consideradoadecuadamente, deliberadamente puede intentar boicotear el proceso de IR.

A continuación, se presenta una “plantilla de requisitos” o “tarjeta derequisitos” (inspirada en el libro de S. Robertson y J. Robertson “Mastering



6


the Requirements Process”, Addison-Wesley, 1999) que puede ser útil enproyectos reales. Varias de estas tarjetas, se pueden utilizar para recogerinformació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, porejemplo.• 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 derequisitos (ERS, Especificación de Requisitos del Software ), en el cual sellega a definir de una forma completa, precisa y verificable cada uno de losrequisitos 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 haceque sea necesario establecer un marco de terminología común. Por estarazón, son muchas las propuestas que abogan por desarrollar un glosario detérminos en el que se recogen y definen los conceptos más relevantes ycríticos para el sistema.

2.4. Validación de requisitos

Consiste en mostrar o comprobar que cada uno de los requisitos obtenidosdefine el sistema o proyecto. En esta etapa, solamente entran aquellos





requisitos que se mencionaron en la especificación de requerimientos desoftware.

Pueden utilizarse, en conjunto o de forma individual, varias técnicas devalidación de requisitos:

1. Revisiones de requisitos. Los requisitos son analizados sistemáticamentepor 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 modelopara ver si cumple sus necesidades reales.

3. Generación de casos de prueba. Los requisitos deben probarse, amenudo revela los problemas en los requisitos. Si una prueba es difícil oimposible de diseñar, significa que los requisitos serán difíciles deimplementar y deberían ser considerados nuevamente.

4. Matrices de trazabilidad. Esta técnica consiste en marcar los objetivos delsistema y chequearlos contra los requisitos del mismo. Es necesario irviendo 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 deque 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 losusuarios.

La diferencia con el análisis es clara, pues mientras que en el análisis setrabaja sobre el boceto del documento de requisitos, en la validación se utilizael documento final, lo que equivale a decir, los requisitos "depurados".

3. Gestión de los requisitosLos requisitos cambian y esto persiste durante el proyecto. Estos son los siguientescambios 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 elsistema sea desarrollado y utilizado y este proceso se hace indispensable, másaú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 suscambios. De este modo, se asegura la consistencia entre los requisitos y elsistema.



!


3.1. Planificación de la gestión de requisitos

Esta primera etapa es esencial en el proceso de gestión de requisitos, puescomo se mencionó anteriormente, la gestión de requisitos tiene un costoelevado. Para cada proyecto, la etapa de planificación establece el nivel dedetalle 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 lade é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. Laventaja de ello es que se asegura que todos los cambios propuestos sontratados de forma consistente y todos los cambios en el documento de

requisitos se hacen de forma controlada.

ACTIVIDADES PROPUESTAS1. 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 deIngenierí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?





R$%&'$

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

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

Los cambios en los negocios, organizacionales y técnicos inevitablementeconducen a cambios en los requisitos de un sistema software . La gestión derequisitos 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 cualse diseñan las políticas y procedimientos para la gestión de requisitos; y delcambio, en la que se analiza los cambios propuestos en los requisitos y se evalúasu 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=29672Aquí encontrará el artículo “El 71 por ciento de los proyectos de sistemasfracasan. ¿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.



2#


PIRÁMIDE DE REQUISITOS

LOGRO DE LA UNIDAD DE APRENDIZAJE

Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y nofuncionales de un software que da soporte a un proceso de negocio, y controla suscambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO

1. Pirámide de requisitos2. Características de un buen requisito.


1. Los alumnos clasifican los requisitos de una lista propuesta según las categoríasdescritas 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.

UNIDAD DE

APRENDIZAJE

TEMA

2





1. PIRÁMIDE DE REQUISITOSUn requisito se define como una condición o capacidad a la que debe ajustarse elsistema que se construye para satisfacer un contrato, norma, especificación u otrodocumento formalmente impuesto.

Dependiendo del formato, fuente y características comunes, los requisitos puedendividirse en diferentes tipos. A continuación se indican los tipos de requisitos queson 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, talcomo 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 nivelesinferiores, las características, casos de uso y requisitos suplementarios. Los

diferentes niveles marcan el nivel de detalle, pues cuanto menor sea el nivel, laexigencia de detalle de un requisito será mayor. Por ejemplo, una necesidad destakeholder podría ser: "Los datos deben ser persistentes." La característica puede refinar este requisito así: "El sistema debe utilizar una base de datosrelacional." Y, en el nivel de requisito suplementario, es aún más específico: "Elsistema 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 lapirámide, más detallado será el requisito. Una de las mejores prácticas de gestiónde requisitos es tener por lo menos dos niveles de abstracción de requisitos.



22


1.1. Necesidad del stakeholder

Describe lo que el sistema debería hacer para mejorar o reducir el costo deun proceso de negocio, incrementar ganancias o alcanzar regulaciones yotras obligaciones. Es proporcionado por un stakeholder. Ejemplo:

Tabla 2.1 - Ejemplo de Necesidades de stakeholders

1.2. Característica del sistemaEs un servicio que el sistema provee para satisfacer una o más necesidadesdel afectado. Formulada por el analista del negocio. Están descritas en eldocumento Visión. Estos son algunos ejemplos:

Tabla 2.2 - Ejemplo de Características del sistema

1.3. Caso de uso

Es la descripción del comportamiento del sistema en términos de secuenciade acciones entre el actor y el sistema. El formato de un caso de uso creadopor 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 jueganun papel importante en las disciplinas de análisis y diseño.

Los casos de uso son un buen camino para expresar los requisitosfuncionales del sistema; por ello, son utilizados para representar lasfuncionalidades del sistema mediante un diagrama conocido como Diagramade casos de uso , en el cual contiene actores (roles de usuarios), casos deuso (funcionalidades) y las relaciones entre ellos. Este diagrama se crea en ladisciplina 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:

ID Necesidad Stakeholder

STRQ1“Necesito notificar al jefe de soporte cuandouna solicitud de soporte es iniciada”

Jefe desoporte

STRQ2 “Necesito asignar solicitudes de soporte a uningeniero de soporte específico”

Jefe desoporte

STRQ3 “Necesito mantener informado al cliente delprogreso de una solicitud de soporte”

Cliente

ID Característica Descripción

FEAT1 El sistema funcionaráorientado al trabajo en flujo

La solicitud de soportepasará por una serie deetapas y asignaciones

FEAT2 Capacidad de notificación pore-mail

Un sistema de notificación

de correo centralizado seráutilizado por el flujo detrabajo



24


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

Tabla 2.4 - Clasificación de Requisitos Suplementarios – FURPS+

Categoría Sub categoríaFuncionalidad

Facilidad de uso

AccesibilidadEstéticaConsistencia de Interfaz deusuarioErgonomíaFácil de usar

Confiabilidad

DisponibilidadRobustezPrecisión

RecuperaciónTolerancia a fallosSeguroSeguridadCorrección

Rendimiento

RendimientoTiempo de respuestaTiempo de recuperaciónTiempo de Inicio/ApagadoCapacidadUtilización de recursos

De soporte

ComprobabilidadAdaptabilidadMantenibilidadConfigurabilidadActualizaciónFácil de instalarEscalabilidadPortabilidadReutilizaciónInteroperabilidadConformidadFácil de reemplazarMutabilidadFácil de analizarFácil de localizar

Restricciones de diseñoRequisitos de InterfazDocumentación de usuario enlínea y sistema de ayudaRequisitos legales, copyright yotros





1.5. Caso de prueba

Consiste en una especificación de entradas de pruebas, ejecución decondiciones y resultados esperados. Los casos de prueba pueden ir anexos aun Plan de Pruebas Integral.

Los casos de prueba son creados para determinar si el requisito de unsistema, funcional o no funcional, es parcial o completamente satisfactorio.Algunos casos de prueba los puede crear el analista (desarrollador), otros lostesters (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 pruebasmanuales, 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 secuenciaespecífica de acciones obtenidas del flujo de eventos de un caso de uso (flujobásico – subflujos – flujos alternativos). Por ejemplo, a continuación semuestra los posibles escenarios de un caso de uso que tiene cuatro flujosalternativos A1, A2, A3 y A4. Para encontrar un escenario, se necesita dibujarlas posibles líneas que siguen un camino desde el flujo básico B.

Figura 2.2 - Escenarios de un caso de uso



26


2. CARACTERÍSTICAS DE UN BUEN REQUISITOUn requisito debe cumplir varios criterios para ser considerado un "buenrequisito". 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 aplicanal 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 unbuen requisito.

2.1. No ambiguo

Un requisito no es ambiguo cuando tiene una sola interpretación. El lenguajeusado en su definición no debe causar confusiones al lector. A veces laambigü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 completoy 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 15caracteres?

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.




27

CIBERTEC CARRERAS PROFESIONALES

¿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 elpunto 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 quepermita 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 noambiguo. Algunas de estas palabras pueden hacer que un requisito no seaverificable:

• 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 maneraoportuna.

• 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 listadosexplí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“.



2!

CARRERAS PROFESIONALES

CIBERTEC

2.3. Claro

Un requisito es claro si es fácil de leer y entender. Su redacción debe sersimple y clara para aquellos que vayan a consultarlo en un futuro. Por ejemploesta es una frase compleja para un requisito:

REQ7: A veces el usuario introducirá Código del aeropuerto, que el sistemacomprenderá, 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 depensiones, por lo que la cifra indicada del 18% es incorrecta.

2.5. Comprensible

Los requisitos deberían ser gramaticalmente correctos y escritos en un estiloconsistente. Un estándar de convenciones debe ser utilizada. Tal es así que lapalabra "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, talescomo 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únotro 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. Sinembargo, si se cambia el orden de los requisitos, el REQ11no serácomprensible.




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ícilla trazabilidad. Las oraciones que incluyen las palabras "y" o "pero" deberíarevisarse 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 aconstruir, y, además, su capacidad, características físicas o factor de calidad nopueden ser reemplazados por otras capacidades del producto o del proceso.

Por ejemplo, el siguiente requisito debe ser removido porque no proporcionaninguna 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 eimplementació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 elusuario 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. Porejemplo puede darse el caso en que dos requisitos utilicen términos diferentespara 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.



3#


CIBERTEC

Para evitar esta situación conviene estandarizar términos. Entonces, losrequisitos 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 resolversemediante 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 unusuario 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 otrorequisito:

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 conla fecha, sólo del vuelo) es un subconjunto del segundo (en relación concualquier fecha introducida por el usuario).

2.13. Completo

Un requisito está completo si no necesita ampliar detalles en su redacción, esdecir, si se proporciona la información suficiente para su comprensión sinnecesidad de agregar otro requisito para su entendimiento.




3



De acuerdo a la pirámide de requisitos, a qué tipo de requisito corresponde cada unode los siguientes enunciados:

NOTA: Utilice STRQ, FEAT, UC o SUPL para indicar si se trata de una necesidad destakeholder, característica del sistema, caso de uso o requisito suplementariorespectivamente.

R01. El sistema deberá garantizar que su despliegue se pueda realizar, ya sea en ellado del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bitssin que esto afecte el rendimiento del mismo.

R02. El sistema deberá contar con un Manual Técnico de Referencia para laAplicación, el cual estará orientado a profesionales capacitados en aspectosté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óndefinido 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, laOrganización Pro-Turismo exige que para anunciar servicios en su portal, éstosdeben estar provistos en español, inglés y portugués. Estos tres idiomas debenser soportados por el producto desarrollado.

R07. El sistema deberá permitir la creación, modificación, activación, desactivación yautorización de los roles de usuarios definidos.

R08. El sistema deberá prever contingencias que pueden afectar la prestaciónestable y permanente del servicio.La siguiente es la lista de las contingencias que se deben tener en cuenta y sepueden 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ásfrecuentes que se hacen los usuarios.

R10. El sistema deberá utilizar una base de datos relacional Oracle.



32


CIBERTEC

R$%&'$

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

Los requisitos suplementarios son todos los requisitos que no pueden serexpresados 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 ladescripción de la pirámide de requisitos y características de un buen requisito ytermina 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 pruebafuncional de casos de uso, incluyendo cómo crear un caso de uso, derivar todoslos escenarios, y crear casos de prueba razonable, así como el uso de IBMRational Requisite Pro para la trazabilidad de los casos de uso con escenarios ycasos de prueba.




33


GESTIÓN DE REQUISITOS EN RUPLOGRO 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 suscambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO

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


1. Los alumnos, a partir de una lista de necesidades de stakeholder (NEEDS), crean

las características del sistema (FEATURES ) indicando las estrategias detransformació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.

UNIDAD DE

APRENDIZAJE

TEMA

3



34


CIBERTEC

1. VISIÓN GENERAL DE LA GESTIÓN DE REQUISITOS EN RUPEn RUP, una descripción simplificada del proceso de gestión de requisitos contienelos 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 derequisitos:

• Plan de Gestión de Requisitos. Este documento establece los lineamientospara el establecimiento de los documentos de requisitos, tipos, características,y la trazabilidad con el f in de gestionar los requisitos del proyecto.

• Peticiones de los stakeholders. En este documento se especifican lasnecesidades de los stakeholders.

• Visión. Este documento da la visión total del sistema: principalescaracterísticas, necesidades de los stakeholders y servicios esencialesproporcionados.

• Glosario. Es importante que todos los stakeholders utilicen términosconsistentes para expresar sus necesidades. El glosario es una herramientapara 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 sistemaque produce un resultado observable (una salida de trabajo) de valor a un actoren particular.

• Especificación de requisitos suplementarios. Este documento captura losrequisitos que no pueden vincularse directamente a cualquier caso de usoespecífico y, sobre todo si se trata de los requisitos no funcionales yrestricciones de diseño.

• Especificación de requisitos de software. Este documento captura todos losrequisitos del sistema software , es decir, contiene la lista de los requisitosfuncionales y no funcionales.

• Plan de pruebas. Este documento describe el objetivo de las pruebas

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

El primer paso, el plan de gestión de los requisitos, define los requisitos de lapirámide. En cada uno de los siguientes siete pasos, uno de los elementos de lapirámide es construido.

En la tabla 3.1 se describe que tipos de requisitos y qué documentos se crean encada paso. Como puede apreciar, el proceso, a partir del segundo paso, navega através de la pirámide de arriba hacia abajo y de izquierda a derecha.




35


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 pasapor todos los niveles de la pirámide. Incluso en la misma iteración, podemosretornar a pasos anteriores y repetir la actividad. Por ejemplo, durante la creaciónde un caso de prueba, podemos descubrir que aún nos falta información, ynecesitamos más información de los stakeholders , por lo tanto retrocedemos unpaso a la “captura de requisitos".

Para mantener la integridad del modelo, es importante actualizar todos losrequisitos afectados. En las iteraciones iniciales se da énfasis en los primerospasos (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 deGestión de Requisitos” 1. Este plan describe el enfoque global de la gestión derequisitos en el proyecto. El documento da detalles de cómo los requisitos soncreados, organizados, modificados y rastreados durante el ciclo de vida delproyecto. También se describen todos los tipos de requisitos y sus atributosutilizados en el proyecto.

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

Paso Descripción Tipo de requisito Documentos1 Establecimiento de un plan de

gestión de requisitos _______________Plan de gestiónde requisitos

2

Captura de requisitosNecesidades destakeholders

Peticiones destakeholders

3Desarrollo del documentoVisión

Características Visión, Glosario

4Creación de casos de uso Casos de uso,

escenariosEspecificaciónde caso de uso

5

Especificación suplementaria Requisitossuplementarios

Especificaciónsuplementaria

6Creación de casos de pruebade casos de uso

Casos de pruebaPlan de casos deprueba

7 Creación de casos de pruebade la especificaciónsuplementaria

Casos de pruebaPlan de casos deprueba

8Diseño del sistema

Diagrama de clases,diagramas deinteracción

Diagramas UML



36


CIBERTEC

¿Cuándo se crea el PGR (Plan de Gestión de Requisitos)?La PGR se puede crear a partir de una plantilla incluida en RequisitePro. Sinembargo para crear un proyecto en RequisitePro tenemos que tomardecisiones documentadas en el PGR.

Tomar en cuenta los siguientes aspectos:1. Todas las decisiones sobre el plan se documentan.2. Un proyecto de RequisitePro 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 PGR se importa en RequisitePro.

Aquí hay algunas preguntas que pueden ser contestadas en el plan:• ¿Se utilizará alguna herramienta de gestión de requisitos?

• ¿Qué tipos de requisitos serán rastreados en el proyecto?

• ¿Cuáles son los atributos de estos requisitos?

• ¿Dónde se crearán los requisitos, únicamente en una base de datos o en

documentos?• ¿Entre qué requisitos necesitamos aplicar la trazabilidad?

• ¿Qué documentos se requieren?

• ¿Qué requisitos y documentos se utilizarán como un contrato con losclientes?

• Si una parte del proyecto se subcontrata, ¿qué requisitos y documentosserán utilizados como un contrato con un vendedor?

• ¿Vamos a seguir la metodología RUP o alguna otra?

• ¿El cliente necesita documentos específicos para cumplir con su procesode desarrollo?

• ¿Cómo la gestión de cambios se llevará a cabo?• Suponiendo que se utiliza RequisitePro, ¿todo el sistema se almacenará en

un Proyecto RequisitePro o se crearán varios proyectos?

• ¿Qué proceso garantizará que todos los requisitos serán implementados yverificados?

• ¿Para qué requisitos o vistas tenemos que generar informes?

1.2. Captura de requisitosEste paso se concentra en capturar todas las necesidades de los 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 nosugieran una determinada respuesta.

• Cuestionarios: Un conjunto de preguntas preparadas para un gran grupode stakeholders.

• Workshops (talleres): Reunión de stakeholders por un periodo intensivo.Son coordinados por un experto y a menudo se consigue alentar elcompromiso de los participantes, fomentando el espíritu de grupo.

• Storyboards (guiones gráficos): Uso de una herramienta visual gráficapara mostrar el comportamiento del sistema. Son un conjunto de dibujosque representan las actividades del usuario. Son una especie de prototiposa papel.




37


• Role-playing (Juego de roles): A cada miembro del grupo se le asigna unrol, usualmente uno de los usuarios.

• Sesiones de lluvias de ideas (brainstorming): Presentación de ideasdurante una sesión breve e intensiva. Es eficaz porque las ideas máscreativas 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 un estudio de documentos que definen

la razón de ser del proyecto, tales como planes de negocio, estudio demercado, contratos, etc.

La técnica a usar dependerá de la naturaleza de los requisitos y el tipo destakeholder. Es buena práctica especificar el resultado de esta tarea en eldocumento Peticiones de stakeholder 2 y almacenar cada uno de los requisitosen una base de datos. Esto permitirá asignarles varios atributos, como la

prioridad o dificultad. También permite realizar el seguimiento de los requisitosy derivarlos a otros tipos de requisitos.

Un punto importante que resaltar es que se debe tener cuidado de no perder omal interpretar un requisito en este nivel, de lo contrario este problema sepropagará durante todo el ciclo de desarrollo.

Las necesidades de stakeholders no necesariamente tienen los atributos de unbuen requisito mencionados en la sesión anterior; pero los requisitos que seencuentran en niveles inferiores a estas, sí los presentan. Este tipo derequisito se encuentra en el nivel superior de la pirámide, tal como se ilustra enla 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 lagestió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



3!


CIBERTEC

Los propósitos del documento Visión son los siguientes:• Definir los límites del sistema• Identificar restricciones 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.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. Estetipo de requisitos se muestra en la pirámide en la figura 3.2.

Figura 3.2 - Características del sistema en la pirámide

Las características se derivan de las necesidades de los stakeholders. Esimportante no perder de vista qué característica fue derivada de lasnecesidades de stakeholders.

Para crear uno o varios requisitos FEAT (Features ) a partir de los requisitosSTRQ (Stakeholders request ) se aplica alguna de las siguientes estrategias detransformación:

• Copiar: Si no se requieren cambios, el STRQ puede ser copiado a FEATexactamente como está.

• Dividir: Si el requisito no es atómico, podemos dividirlo en dos o másrequisitos.

• Aclaración: Aclaración o explicación, se puede aplicar cuando el requisitoinicial es poco claro o ambiguo.

• Cualificación: Logramos cualificar (cuantificar) mediante la adición derestricciones o condiciones al requisito. Puede ayudar a resolver lasnecesidades contradictorias.

• Combinación: Si los requisitos son redundantes o se superponen sepueden combinar en un solo requisito.

• Generalización: Si la necesidad no es abstracta, e incluye algunos detallesinnecesarios, podemos aplicar la generalización.




3"


• Cancelación: A veces un requisito debe ser eliminado. Esto puede sucedercuando el requisito es no viable, innecesario, o incompatible con otrorequisito.

• Completar: Si el conjunto de requisitos es incompleto, puede ser necesarioañadir requisitos en esta etapa.

•

Corrección: Corrección puede significar una nueva redacción del requisitopara corregir la gramática, ortografía o puntuación; o cambiar una parte de lanecesidad que no es cierta.

• Unificación: Los requisitos que usan un vocabulario inconsistente puedenser 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 obtenerrequisitos verificables de los que no han sido especificados como tal.

Una vez creados los requisitos del tipo características (FEAT), se debeespecificar 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 seimplementarán en la siguiente iteración, fase o lanzamiento (release ).

A continuación, se indican los atributos que usualmente se asignan a lostipos de requisitos FEAT:

• Prioridad: generalmente se usa para determinar el orden deimplementació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 duranteel 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 lafase 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 desarrollopuede agregar otros atributos si así lo prefiere. Por ejemplo, el atributoImportancia, el cual incluye los valores: obligatorio y deseable.

En situaciones extremas, múltiples atributos pueden almacenar estos valoresde importancia, los cuales no son los mismos que prioridad, porque laimportancia según el usuario puede no ser la misma importancia según elgerente del proyecto.



4#


CIBERTEC

1.4. Creación de casos de uso

Los requisitos funcionales son mejor descritos en forma de casos de uso. Ellosson derivados de características del sistema y a partir de los casos de uso sederivan 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, uncaso de uso puede ser usado como un contrato entre los desarrolladores yclientes. Este también es la base para las realizaciones de casos de uso, loscuales juegan un papel importante en análisis y diseño; implementación ycasos 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 actores2. Encontrar casos de uso y detallarlos3. 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 oentrega información. En algunos casos, representaremos al tiempo comoactor para indicar que el caso de uso se inicia en un momento específico

(Timer).




4


1.4.2. Encontrar casos de uso

Los casos de uso se identifican a partir de las característicasespecificadas en el paso anterior (desarrollo del documento Visión) y paracada actor identificado hasta el momento.

Más casos de uso se pueden obtener, aparte de los derivados de lascaracterísticas, utilizando la técnica workshop con stakeholders. Una vezidentificado los casos de uso se procede a describirlos mediante eldocumento Especificación de Caso de Uso.

Por último, se crean diagramas de casos de uso para representar a losactores, casos de uso y las relaciones entre ellos.

Estos diagramas se crean en un paquete denominado “Modelo de casosde uso”. Para pequeños sistemas, el modelo de casos de uso puedecontener solo un diagrama de casos de uso; mientras que para grandessistemas, se necesitará dividir el sistema en varios diagramas. No existen

reglas estrictas acerca de cómo el modelo debería dividirse. Acontinuació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 aestructurarlo. El objetivo principal de la estructuración del modelo eseliminar redundancias, hacer que los casos de uso sean más fáciles deentender y mantener.

En primer lugar, hay que analizar los casos de uso y encontrar las partesde los flujos que contengan pasos similares. Luego podemos aplicaralgunos de los tres tipos de relaciones entre casos de uso:

• Incluye / Inclusión: Para representar que un caso de uso incluye elcomportamiento de otro.

• Extend / Ampliar: Para representar que un caso de uso extiende a otrocaso 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 usocomo entre actores.



42


CIBERTEC

1.5. Especificación suplementaria

La especificación suplementaria captura todos los requisitos que no puedenser expresados en casos de uso. Sin embargo, esto no significa que todos losrequisitos funcionales están en los casos de uso y que todos los requisitos nofuncionales están en la Especificación suplementaria.

La Especificación de casos de uso también contiene los requisitos nofuncionales, si se aplican a un solo caso de uso.

La Especificación suplementaria contiene todos los requisitos funcionalesgenéricos que no están asociadas con ningún caso de uso específico. La tabla3.2 ilustra qué tipo de requisito se encuentra en un documento.

Tabla 3.2 - Requisitos en documentos de Especificación

Recientemente, el nombre del artefacto fue cambiado en Rational UnifiedProcess (RUP) de "Especificación Complementaria" al plural"Especificaciones suplementarias" para reflejar el hecho de que podemosusar más de un documento para capturar requisitos suplementarios.

En la pirámide, los requisitos suplementarios están en el mismo nivel que loscasos uso, como se muestra en la figura 3.4.

Figura 3.4 - Requisitos suplementarios en la pirámide

Tipo derequisito

Especificaciónde caso de uso Especificación suplementaria

Funcional

Flujo básico y

flujos alternativosrelacionados a uncaso de usoespecífico.

Requisitos funcionalesrelacionados a más de un casode uso.

No Funcional

Especificación nofuncionalrelacionada a unsolo caso de uso.

Requisitos no funcionalesrelacionados a muchos casosde uso.




43


Muchas características que se definen en el documento Visión se convierten enrequisitos suplementarios. Su inclusión en la Especificación Suplementariaproporciona una oportunidad para añadir más detalles y organizar los requisitosen la sección apropiada del documento, de acuerdo a la categoría FURPS+ a laque pertenecen.

Un método consiste en ir a través de todas las características, identificar cuálesno 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 nose necesitan cambios, y podemos usar la misma formulación como en lascaracterísticas.

1.6. Creación de casos de prueba de casos de uso

En muchos proyectos la importancia de este paso no es reconocido. Amenudo, a los testers se les da una impresión de Especificación de caso deuso y, a continuación, ellos realizan las pruebas manuales. Sin embargo, sidescuidamos la creación formal de los casos de prueba, se puede terminar

con una cobertura pobre de un universo de pruebas ejecutando muchaspruebas duplicadas.

Figura 3.5 - Casos de prueba para verificar casos de uso

Cuando tengamos todos los escenarios derivados de un caso de uso, se creanlos 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 “RegistrarReserva de Habitación”.



44


CIBERTEC

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 dehabitación(es). Además de saber en qué estado se encuentra: reservado, ocupadoo disponible.

2. Actor(es)Recepcionista

3. Flujo de Eventos3.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 AgregarHabitación. Además incluye una cuadrícula que contiene la lista de todas lashabitaciones reservadas y las opciones: Buscar Cliente, AgregarCliente, Buscar Habitación, Eliminar Habitación, Grabar Reserva ySalir.

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ón13. 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 existeEl sistema muestra el MSG: “Cliente no existe muestra” y ofrecerá laposibilidad de registrar al nuevo cliente.

1.1. Fechas incorrectasEl sistema muestra el MSG: “Fechas incorrectas” y el caso de uso

continúa en el paso 5.




45


9.1. Habitaciones no disponiblesEl sistema muestra el MSG: “No hay habitaciones disponibles” y finalizael caso de uso.

Eliminar Habitación de CuadrículaLa 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 casode uso continúa.

4. Precondiciones1. El Recepcionista está logeado en el sistema.2. Lista de Clientes disponibles.3. Lista de habitaciones disponibles.

5. Poscondiciones1. 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. Prototipos7.1. Interfaz RESERVA



46


CIBERTEC

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 entradaen los pasos que lo requieran del escenario dado. Por ejemplo, si enalgú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 lacontraseña. La variable puede ser también una selección que el usuariopuede 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 delflujo 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 activardiferentes 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á "E-

mail 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 listasdesplegables.

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.




47


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 siguientesopciones 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 enel campo de texto).

A continuación se muestra algunas opciones de valor de prueba paratodas las variables del flujo básico del caso de uso “ReservarHabitació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

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!


CIBERTEC

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 significativamentediferentes para las pruebas. Ahora tenemos que combinarlas en lasecuencia de pasos del caso de prueba. Una forma de hacerlo es crearuna Matriz de Asignación de Casos de Prueba, tal como se ilustra en latabla 3.3.

Tabla 3.3 - Matriz de Asignación de Casos de Prueba

Las filas de esta matriz contendrán todas las variables para todos losvalores que requieran la entrada del usuario. En la primera columna seespecificará el número del paso del flujo básico del caso de uso(obtenido de la Especificación de Caso de Uso), en la segundacolumna se indicará el nombre de la variable, y las columnasrestantes contendrán las pruebas (o tests en inglés) de los casos. Laspruebas 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 opcionessignificativamente diferentes para una variable. Si calcula de formaincorrecta, no hay problema porque se puede añadir o eliminar unacolumna, mientras se va llenando la matriz.

Por lo general, de cinco a siete casos de prueba cubren escenariostípicos. Sin embargo, algunos casos específicos de aplicación requierenmás casos de prueba. Tenemos que crear una matriz por escenarioelegido para la prueba.

La tabla 3.4 que se muestra, corresponde a la Matriz de Asignación deCasos de Prueba para el flujo básico del caso de uso “ReservarHabitación”:

Paso Variable T1 T2 T3 T4 T5 T6




CIBERTEC

Tabla 3.4 - Matriz de Asignación de Casos de Prueba con todas las variables para el Caso de Uso “R

En la primera fila de cada variable, se ingresa todas las opciones que se necesita probar. En cada columnatal como se muestra en la tabla 10.5. Algunas de las opciones son incorrectas porque se necesita promensaje 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 ingreuna combinación razonable de opciones válidas, adicionales si se requiere, por cada opción incorrecta desegunda fila para la variable “Fecha de llegada de reserva” se ingresaron opciones correctas para las pruebincorrectas en la fila anterior. En otros casos será necesario agregar más filas para completar las prueb

“Fecha de salida de reserva”.

Paso Variable T1 T2 T3 T4 T5 T6

B5 Fecha de llegada de reserva

B5 Fecha de salida de reserva

B10 Nombre del huésped de la habitación



5#


Paso Variable T1 T2 T3 T4

B5Fecha de llegada de

reserva

Válida

manualmente

Válida de

un

calendario

Fecha Pasada Fecha Actual

Válida con una año después

de la actual

B5Fecha de salida de

reserva

Válida

manualmente

Válida de

un

calendario

Fecha Pasada Igual a la de

llegada

Válida con un año después

de la actual

Válida con una semana

después de la fecha de

llegada

Válida de un

calendario

B10 Nombre del huésped de lahabitación Regular

Con

máximalongitud

Con un apóstrofe Mayor longitudde la permitida

Dos palabras

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



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 creadaen el paso anterior, creando una tabla separada para cada caso deprueba. Luego, se reemplaza las opciones definidas para cada variablecon 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 delista desplegable.

Por ejemplo para el caso de prueba T1 del caso de uso “ReservarHabitación” se crea la siguiente tabla. Note que se agregaron filas quecontienen acciones en los pasos B2, B7, B10, B11 y B14.

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 requisitossuplementarios debido a que estos requisitos son de diferente naturaleza. Acontinuación se presenta los métodos de creación de casos de prueba pararequisitos 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.

Paso Variable T1 Resultadoesperado

Resultadoactual

Pasa/Falla

Comen-tarios

B2 Buscar ClienteBuscarcliente

Datos de uncliente

B5 Fecha de llegada dereserva 01-12-2009 Aceptar

B5Fecha de salida de

reserva 05-12-2009Cantidad dedías dehospedaje

B7 Buscar HabitaciónBuscarHabitación

Datos de unahabitacióndisponible

B10 Nombre del huésped

de la habitación MiguelVásquez Aceptar

B11 Agregar Habitación

AgregarHabitación

Pago de lahabitación(subtotal y

monto total) enla cuadrícula dedetalle dereservas

B14 Grabar reservaGrabarreserva

Número dereservagenerada




52


1.7.1. Ejecutar casos de prueba seleccionados en diferentes entornos

Este método se utiliza para los requisitos suplementarios que requierenque la aplicación trabaje en diferentes entornos (plataformas) talescomo 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 deun 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 esprobado en diferentes entornos, por lo tanto se tiene un caso de pruebapor entorno.

Figura 3.6. Casos de prueba para verificar requisitossuplementarios 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 dealgunos controles en la interfaz de usuario.Algunos ejemplos:• 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.




53


• 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 esagregando un control a todos los casos de prueba que se ha creadopara casos de uso diferentes. Debido a que los casos de pruebaderivados de casos de uso cubren cada posible pantalla de laaplicación, sólo puede agregar los controles pertinentes, durante suvisita a cada una de las pantallas específicas. De esta forma, podemosestar seguros de que la función se verificó en todos los lugares en losque sea aplicable. En la figura 3.7 se muestra que todos los casos deprueba 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 especificacionessuplementarias, 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 deapoyo o administrativos.

Como ejemplo, podemos tener a los requisitos relacionados con laseguridad y acceso protegido con contraseña a algunas partes de laaplicación:• 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.




54


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

Figura 3.8 – Impacto de los requisitos suplementarios en otrostipos 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 requisitodebido a que en muchos casos, la tarea no requiere la creación deescenarios 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ésde Internet, por lo que se puede comprobar de forma remota en

cualquier momento.

Para probar este requisito, alguien que tenga el rol de administradoringresará al sistema a través de Internet y comprobará si podrá accedera un registro de errores.

1.7.5. Listas de verificaciónAlgunos requisitos no necesitan ninguna prueba complicada, por lo quesólo puede comprobarse para ver si se han cumplido agregándolo enuna 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 deverificación.

Algunos otros ejemplos de este tipo de pruebas, simplemente marcandouna 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.




55


• 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 dela aplicación o alguna otra aplicación interna. Esto se denomina pruebade 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 labase de datos y verificar el contenido de la tabla de disponibilidad dehabitaciones, Luego se compara los resultados con la lista obtenida através de nuestro sistema.

Otros casos de prueba requieren comprobar si un algoritmo específicose 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 derendimiento 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 necesarioautomatizar todos los casos de prueba. Podemos seleccionar entre dos ytres casos de prueba. Vale la pena la selección de un caso de pruebaque representa el escenario más utilizado y que contenga variasoperaciones.

Las herramientas de IBM, disponibles para realizar pruebas, sonRational Robot, Rational Test Manager, Test Manager, RationalFunctional 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 realizadoutilizando diagramas de UML. Muchas de las herramientas, tales comoRational Rose, Rational Software Architect, Rational Data Architect y RationalSoftware Modeler, pueden facilitar la creación de todos los diagramasnecesarios.

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




56


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

Figura 3.9 - Diseño de sistemas

CASO RESUELTO

A continuación se describen las necesidades de stakeholders para una Agencia deviajes:

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 otrosaeropuertos 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 losprecios de otros aeropuertos cercanos.

STRQ12: A veces un Usuario ingresará un código de aeropuerto, que el sistemaentenderá, pero a veces la ciudad más cercana puede reemplazarlo,




57


entonces el Usuario no necesita saber el código del aeropuerto, y todavía noserá 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 unaentrevista:

STRQ22: El sistema deberá proporcionar la posibilidad de reservar el vuelo, comprarun boleto, reservar una habitación de hotel, reservar un auto, y proporcionarinformación acerca de las atracciones.

STRQ23: El usuario será capaz de comprar un boleto en línea, sin necesidad dellamar a al Agente de viajes.

STRQ24: El sistema deberá seguir las guías de implementación prevista en la cadenade 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 dehotel, los proveedores de automóviles, y los representantes de líneas aéreasdeberá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 defiabilidad 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 partirde un Role Playing :

STRQ29: El servicio de búsqueda permitirá al Agente de Viajes encontrar unareservación en base al: apellido, ciudad de destino, fecha, etc.

STRQ30: El Agente de Viajes podrá cambiar los detalles de la reservación o cancelaruna reservación.

Lista de Requerimientos del Gestor de Contenidos, capturados durante un Workshop :

STRQ31: Mientras se esté ingresando la información de contenidos, el administradorde Contenido podrá ingresar el texto sin etiquetas HTML.

STRQ32: La información de contenido debe ser almacenado en un archivo de texto.




5!


Lista de Requerimientos del Gestor de Contenidos, capturados durante un Workshop :

STRQ33: El sistema deberá ser completamente probado solo en versiones específicasde los más populares navegadores.

STRQ34: El sistema puede mostrar un mapa del aeropuerto.

Lista de Requerimientos del Administrador de la Agencia de Viajes, capturadosdurante un Workshop :

STRQ35: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservaen 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 siguienteinformación se mostrará: dirección, teléfono, fax, correo electrónico, losdescuentos 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, derivecaracterí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 podemosaplicar algunas de las siguientes estrategias de transformación (derivaciones):

• Copiar: Si no se requieren cambios, el STRQ puede ser copiado a FEATexactamente 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 espoco claro o ambiguo.• Cualificación: Logramos cualificar (cuantificar) mediante la adición de

restricciones o condiciones al requisito. Puede ayudar a resolver las necesidadescontradictorias.

• Combinación: Si los requisitos son redundantes o se superponen se puedencombinar en un solo requisito.

• Generalización: Si la necesidad no es abstracta, e incluye algunos detallesinnecesarios, podemos aplicar la generalización.

• Cancelación: A veces un requisito debe ser eliminado. Esto puede sucedercuando 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.




5"


• Corrección: Este término puede significar una nueva redacción del requisito paracorregir la gramática, ortografía o puntuación; o cambiar una parte de la necesidadque no es cierta.

• Unificación: Los requisitos que usan un vocabulario inconsistente pueden serunificados (estandarizados).

•

Adición de detalles: Si el requisito no es lo suficientemente preciso, podemosañadir más detalles. Esta técnica se utiliza a menudo para obtener requisitosverificables de los que no han sido especificados como tal.

STRQ1: El usuario deberá ser capaz de comparar los precios de vuelos de otrosaeropuertos 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 otrosaeropuertos 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. Elrequisito STRQ2 vino por parte del Usuario francés y STRQ16 fue suministrada por elUsuario estaunidence. Los requisitos STRQ2 y STRQ16 fueron reemplazados por elsiguiente requisito:

FEAT2: Las fechas deberán ser mostradas de acuerdo al formato cargado en laconfiguración del navegador Web.

STRQ3: En las pantallas de entrada de datos, el sistema indicará qué campos sonobligatorios.

En algún momento se tomará la decisión de aquellos campos obligatorios, que seránindicados 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 sonobligatorios 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 denecesidad. (Por ejemplo, "se" puede sonar más fuerte que "deberá", y "se" puedesonar más fuerte que "debería".

Es necesario una aclaración en cuanto a quién será capaz de cancelar la compra delos boletos (usuario, cliente representante o administrador) y en qué etapa del procesoes requerido:

FEAT4: El usuario será capaz de cancelar la compra de un boleto en cualquiermomento 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 hotelpuede ser considerado el mismo requisito, entonces no hay la necesidad de dividiresto:

FEAT5: El usuario será capaz de cancelar una reservación de un auto o un hotel.




6#


STRQ6: Los vuelos de ida y llegada serán ordenados por el menor número deparadas.

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 quedespué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 otrosaeropuertos 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 deparadas.Sin embargo, contradice al STRQ18, porque que los vuelos sean ordenados porprecio. Podemos acomodar ambos requisitos en una característica:FEAT6: El usuario será capaz de seleccionar si los vuelos son ordenados por elmenos número de paradas o por precio.

Como usted puede ver, derivar características es un proceso iterativo, y algunosrequisitos necesitan ser cambiados en poco tiempo mientras son consistentes y noredundantes.

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 sercompletamente independiente, tenemos que añadir alguna explicación:

FEAT7: Durante la compra de un boleto de avión, el usuario será capaz de seleccionarlos asientos.

STRQ8: El sistema deberá tener una interfaz de lenguaje natural.

A primera vista, este requisito es correcto. Sin embargo, después de analizar elalcance de las limitaciones del sistema y el tiempo, fue obvio que este requisito no erarealista (factible). Es contradictorio con STRQ27, que pide que el sistema se desarrolleen tres meses. – Implementando una interfaz de lenguaje natural se tardaría más detres meses. Este requisito se cancela, y el usuario que proporciona este requisito esnotificado 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 seingrese. Debido al STRQ9 que es más genérico (menciona una fecha, que incluye unaestancia en el hotel fecha o un alquiler de la fecha de coches), volveremos a escribirSTRQ9 y cancelar STRQ21. Como aclaración, podemos explicar una lista de todas lasfechas:

FEAT8: El sistema mostrará un calendario emergente en cualquier fecha que seingrese, tales como una fecha de vuelo, fechas de permanencia en el hotel, o la fechadel 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.




6


Este requisito contiene el diseño innecesario. Detalles, como si se utiliza un botón ocasilla de verificación, debe dejarse en manos del diseñador de la pantalla. En estecaso, un botón de opción puede ser más apropiado porque las opciones sonexcluyentes.FEAT9: El usuario tendrá la oportunidad de indicar si necesita solo un boleto de ida oida y retorno.

STRQ11: Para los vuelos de llegadas y salientes, los usuarios podrán comparar losprecios 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 sistemaentenderá, pero a veces la ciudad más cercana puede reemplazarlo, entonces elUsuario no necesita saber el código del aeropuerto, y todavía no será entendida por elsistema.

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 aeropuertoo 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 serprobable. 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 mismainformació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 lamisma información (tales como dirección o número de tarjeta de crédito) durante lastransacciones futuras.

STRQ15: Pago por PayPal estará disponible.

Este requisito es contradictorio con STRQ41, que establece que PayPal no puede serdisponible. En este caso, por alguna razón el vendedor no puede proporcionar esteservicio, 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 departida, 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 departida, 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 losrequisitos cambia, este requisito no será comprensible.




62


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 sefacilitará.

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 deautos de diferentes empresas.

STRQ20: Los precios de alquiler de autos deben mostrar todos los impuestosaplicables (incluido el 6% IVA del estado).

El impuesto varía según el estado, por lo que el % cifra es incorrecta. Podemoseliminar las palabras entre paréntesis, dejando el cálculo de los impuestos para losdiseñadores:

FEAT16: Los precios del alquiler de autos deben mostrar todos las Impuestosaplicables.

STRQ21: Un calendario estará disponible para ayudar el ingreso de las fechas delvuelo.

Este requisito se incorporó en FEAT8.

STRQ22: El sistema deberá proporcionar la posibilidad de reservar el vuelo, compraun boleto, reservar una habitación de hotel, reservar un auto y proporcionarinformació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 requisitosató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 dehotel.FEAT20: El sistema deberá proporcionar la oportunidad de reservar un auto.FEAT21: El sistema deberá proporcionar información acerca las atracciones enlugares específicos.


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 dellamar al Agente de viajes.

STRQ24: El sistema deberá seguir las guías de implementación prevista en la cadenade nuestras agencias de viajes.

Este requisito no es claro, al menos que otro documento se adjunte, describiendo lasdirectrices de implementación. O todas las pautas pueden ser listadas de formaexplicita. Por ejemplo:

FEAT23: El sistema utilizará la arquitectura JEE.FEAT24: Si la arquitectura requiere de un servidor de aplicaciones IBM WebSpheredeberá utilizar.




63


FEAT25: Si el sistema requiere una base de datos. Oracle deberá utilizar.

STRQ25: Las páginas donde los proveedores de servicios pueden presentar susofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, losproveedores de automóviles, y los representantes de líneas aéreas deberán usar su IDy 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 susofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, losproveedores de automóviles, y los representantes de líneas aéreas deberán usar su IDy contraseña asignado para acceder a estas páginas.


Este requisito no es lo suficientemente precisa para ser probado. En algún momentotenemos que reemplazar con los requisitos detallados en cuanto a fiabilidad.

Podemos hacer esto ahora, mientras creamos las características o podemos esperarhasta que creemos las especificaciones suplementarias de las características. Porahora, mantenemos la exigencia como es:

FEAT27: El sistema debe estar disponible las 24 horas del día, con un grado defiabilidad 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 elcliente firme los Casos de Uso y las especificaciones suplementarias.

STRQ28: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto deavió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 deavión.

STRQ29: El servicio de búsqueda permitirá al Agente de Viajes encontrar unareservació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 deeste requerimiento que no se requieren otros criterios de búsqueda, "etc" fueeliminado.

FEAT30: El servicio de búsqueda permitirá al Agente de Viajes encontrar unareservació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 cancelaruna 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 administradorde Contenido podrá ingresar el texto sin etiquetas HTML.




64


Este requisito está bien, por lo que solo se copia:

FEAT33: Mientras se esté ingresando la información de contenidos, el administradorde 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. Estasugerencia, sin embargo, puede ser pasada a consideración en el diseño.

STRQ33: El sistema deberá ser completamente probado solo en versiones específicasde los más populares navegadores.

Después de transmitir al cliente que no es realista poner a prueba el sistema en todoslos navegadores disponibles, el cliente estuvo de acuerdo con limitar el requerimientode las pruebas en los navegadores Internet Explorer y Netscape.

FEAT34: El sistema deberá ser completamente probado en los siguientesnavegadores: 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 decomprobar con el cliente, se confirmó que este requerimiento es innecesario, por loque se canceló.

STRQ35: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservaen 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ándisponibles para el Administrador.

STRQ37: Varios informes estarán disponibles.

Este requisito es impreciso. Después de entrevistas adicionales, los detalles fueronañ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 detiempo determinado.

STRQ38: Mientras se reserve una habitación, el cliente deberá proporcionar lasiguiente información: ciudad, días de alojamiento, el número de adultos, número dehijos 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 lasiguiente información: ciudad, días de alojamiento, el número de adultos, número de

hijos y preferencias de habitación.




65


STRQ39: Mientras se proporcione información acerca del hotel, la siguienteinformación se mostrará: dirección, teléfono, fax, correo electrónico, los descuentosofrecidos, las formas de pago disponibles, etc.

El "etc" se elimina:

FEAT38: Mientras se proporcione información acerca del hotel, la siguienteinformación se mostrará: dirección, teléfono, fax, correo electrónico, los descuentosofrecidos 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 yalojamiento 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 lascaracterísticas (FEAT) para la Agencia de viajes, podemos crear losdocumentos “Necesidades del stakeholder” y “Visión del Producto”respectivamente en su sesión de laboratorio.




66


Caso PrácticoA continuación, se detallan las necesidades del stakeholder y las característicasdel 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 unpedido 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 documentode 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 Producto1. El sistema va a permitir crear un pedido ingresando la información del

pedido ítems del pedido y forma de pago2. 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 porpedido.




67


4. El sistema va a permitir que el usuario agregue un ítem al pedido5. 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 encuentre9. 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éfonocontacto.

11. Los botones de iniciar y cerrar sesión van a encontrarse disponibles desdela interfaz del ingreso de usuario.

12. El sistema va a permitir al RVRS modificar los datos de un cliente cuandosea 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 eltipo 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 abandonarcualquier interfaz.

17. El Sistema va a ser capaz de calcular con un algoritmo el subtotal, el IGV yel total del costo de un pedido.

18. El sistema va a contar en todas las interfaces con las opciones deregresar, 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 deincidencias.

22. El sistema va a mostrar una lista de incidencias ordenadas según fecha deelaboració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úmerode í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 correspondientesobligatorios al pago.




6!


30. El sistema va a ser capaz de generar reportes de compras y ventas conlos datos almacenados.

31. El sistema mediante un algoritmo va a ser capaz de determinar el estadode stock de un repuesto.

32. El sistema deberá mostrar una lista de repuestos ordenada según elestado de stock (alto, normal, bajo).

33. El sistema deberá mostrar una lista con todos los requerimientosrealizados 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 seindicarán los siguientes campos: Código O/C, proveedor, Fecha deelaboració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 delos pedidos: urgente, normal y bajo.

53. El sistema debe permitir asignar uno o más operarios para el despacho deuna orden de almacén.

54. El sistema debe permitir asignar un transportista por orden de almacénpresentando la siguiente información: nombre y foto.

55. El sistema debe mostrar una lista de órdenes de compra con los siguientesdatos: código O/C, proveedor, fecha de elaboración, fecha de entrega ymonto total según los estados de recepción pendiente, observada ycompletada.

56. El sistema tendrá la opción de ver los detalles de una orden de compra conlos siguientes datos: Código O/C, proveedor, fecha de elaboración, fechade entrega, forma de pago y estado.




6"


57. El sistema debe tener la opción de ingresar a inventario un repuestomostrando los siguientes campos: Código o/c, proveedor fecha deelaboración, fecha de entrega, monto total y estado de recepción.

58. En todos los formularios que soliciten ingresos de datos, el sistema va aindicar qué campos son obligatorios mediante la colocación de un asteriscocerca al campo.

59. Todos los formularios que muestren fechas, se van a mostrar en el formatodd / mm / aaaa.

60. El sistema va a mostrar calendarios para seleccionar una fecha, en lasventanas que lo requieran.

NOTA.- Una vez identificados las necesidades de stakeholders (STR) y lascaracterísticas (FEAT) para el caso, podemos crear los documentos“Peticiones del stakeholder” y “Visión del Producto” respectivamente.




7#


R$%&'$

En RUP, una descripción simplificada del proceso de gestión de requisitos contienelos 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 lossiguientes:1. Plan de gestión de requisitos2. Peticiones de stakeholders3. Visión4. Glosario de términos5. Especificación de caso de uso6. Especificación de requisitos suplementarios7. 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


“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 lagestión de requisitos según RUP.




7


DOCUMENTOS - ATRIBUTOS


Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y nofuncionales 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.


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.

UNIDAD DE

APRENDIZAJE

TEMA

4




72


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 ycada paso tiene su correspondiente documento a crear.

En la tabla 4.1 se muestran los documentos que debemos documentar.

Tabla 4.1 - Documentos de la gestión de requisitos

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

1. Plan de Gestión de Requisitos2. Petición del Stakeholder3. Documento Visión4. Especificación de Requisitos de Software5. Especificación de Caso de Uso6. Especificación de Requisitos Suplementarios.7. Especificación de casos de prueba.

Paso Descripción Tipo de requisito Documentos1 Establecimiento de un

plan de gestión derequisitos

___________Plan de Gestión deRequisitos

2Captura de requisitos

Necesidades destakeholders

Peticiones deStakeholders

3Desarrollo del documento

Visión

CaracterísticasDocumento Visión,

Glosario de Términos.4

Creación de casos de uso Casos de uso yescenarios

Especificación deRequisitos deSoftware.Especificación deCaso de Uso

5


Requisitossuplementarios

Especificación deRequisitosSuplementarios

6Creación de casos de

prueba de casos de usoCasos de prueba

Plan de casos deprueba, Especificaciónde Caso de Prueba.

7 Creación de casos deprueba de laespecificaciónsuplementaria

Casos de pruebaEspecificación deCaso de Prueba.




73


Petición de los Stakeholders

1. IntroducciónEl documento contiene los requerimientos del Sistema SVGA, los cuales han sidoobtenidos 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 Requerimientos1. 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 laorden 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.




74


Especificación de Requisitos de Software

1. Introducción1.1. Propósito

El presente documento tiene como propósito definir las especificaciones

funcionales, no funcionales y del sistema para la implementación de unaaplicación web que permitirá gestionar de manera adecuada tanto el proceso deventas y entrega de repuestos, como el de abastecimiento de almacéntambién. Para lo cual se diseñara un software el cual será utilizado por losdiferentes trabajadores y clientes de CIMAQ.

1.2. AlcanceEl documento Especificaciones de Requerimientos de Software nos permitirádiseñar, desarrollar e implantar del sistema SVGA (Sistema de Ventas yGestió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 yde 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. ReferenciasLas referencias al presente documento son:• Documento Visión• Especificación de Casos de Uso y• Especificación de Requerimientos Suplementarios.

1.4. Resumen EjecutivoLa problemática actual es la utilización de los recursos humanos en el área dealmacén que se ve afectada negativamente por la falta de control de tiemposempleados y priorización en la entrega de productos. Además, existe unadeficiente sincronización entre la elaboración de pedidos del área de ventas y lagestió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” – SVGAEl 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 diferentesherramientas que ofrece IBM Rational, tales como: IBM Rational RequisitePro,IBM Rational Software Architect, InfoSphere Data Architect; así también comolas herramientas del Office. Todos estos mecanismos serán utilizadosbasándonos en la metodología RUP.

2. Requerimientos FuncionalesEl sistema debe cumplir con los siguientes requerimientos:2.1. Asociados a los Casos de Uso del sistema1. Registrar pedido online2. Registrar pedido3. Registarar requerimiento




75


4. Generar Orden de Almacén5. Ingresar repuestos a inventario6. Cotizar requerimiento7. Atender Orden de Almacén8. Registrar pago9. Mantaner cliente10. Asignar proveedores11. Agregar Item a requerimiento12. Agregar Item a pedido13. Mantener usuario14. Registrar incidencia de pedido15. Registrar incidencia de Ingreso16. Registrar incidencia de Atención17. Buscar cliente18. Generar reporte de almacén19. Consultar incidencia20. Generar reporte de compras

21. Generar reporte de ventas22. Consultar pedido.

2.2. Asociados a aspectos generales1. Obligar al usuario a que el cambio de 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 errores (logs). Para cada error el sistema debe

registrar: el código del error, una descripción del error, la fecha y la hora delerror.

4. Permitir que se puedan adjuntar 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 aaparecer 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 estable, para que el usuario no tenga problemas

para desenvolverse en el sistema.3. Requerimientos No Funcionales

3.1. Usabilidad• En todos los formularios que soliciten ingresos de datos, el sistema va a

indicar qué campos son obligatorios mediante la colocación de un asteriscocerca al campo.

• Todos los formularios que muestren fechas, se van a mostrar en el

formato dd/mm/aaaa.• El sistema debe mostrar calendarios para seleccionar una fecha, en 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éditosolicitado.

• El sistema va a permitir registrar los pagos a través de un browser ya seaInternet Explorer o Mozilla Firefox (sin importar las versiones).

• Los siguientes campos: código de O/A, cliente, fecha de inicio, prioridad;van a ser mostrados ordenadamente en una lista de ordenes de almacén.




76


• En todas las interfaces se encontrarán disponibles los botones de regresarlos 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 de datos, los botones de limpiar se encontrarán

presentes con el objetivo de permitir reanudar el ingreso de información.•

Las fechas deberán ser mostradas de acuerdo al formato cargado en laconfiguració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íapara la toma de decisiones.

3.2. Confiabilidad3.2.1. Tolerancia de Error

El tiempo medio de reparación dependerá de la complejidad de los ajustesnecesarios para lo corrección de errores, dicha demora se verá disminuidagracias al registro de mensajes de error, que facilitará la identificación yposible solución a la falla presentada.

3.2.2. Recuperabilidad

El tiempo medio de reparación dependerá de la complejidad de los ajustesnecesarios para lo corrección de errores, dicha demora se verá disminuidagracias al registro de mensajes de error, que facilitará la identificación yposible solución a la falla presentada.

3.2.3. DisponibilidadEl sistema SVGA tendrá una disponibilidad de uso del 41.6% del día (10horas), 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 actividadesrealizadas en el transcurso del día.

3.2.4. PrecisiónLas cantidades actuales van a ser calculados y almacenados con unaprecisión de 2 decimales.

3.2.5. SeguridadEl password va a ser requerido por el administrador de interfaces.

3.3. RendimientoEl rendimiento del Sistema de Ventas y Gestión de Almacén SVGA es estimadodesde el inicio del proyecto de desarrollo y es ampliado durante suconstrucción; no obstante, se verá influenciado de acuerdo con la carga detrabajo.3.3.1. Tiempo de Respuesta

El tiempo estimado de respuesta por actividad, de la aplicación web, nodebe ser mayor a 5 segundos.

3.3.2. Tiempo de RecuperaciónEl tiempo estimado de acceso a la aplicación web no debe ser mayor a 5segundos.

3.3.3. Tiempo de Encendido y ApagadoEl tiempo estimado de encendido y apagado del software será de 5segundos.

3.3.4. CapacidadEl sistema va a alojar a 700 usuarios actualmente.

3.3.5. Utilización de RecursosEl sistema va a almacenar en la base de datos no más de un millón detransacciones. Si la base de datos crece más del límite, las antiguastransacciones serán eliminadas y suplantados desde la base de datosoperacional.




77


3.4. Soporte y Mantenimiento3.4.1. Capacidad de Prueba

La interfaz de Usuario no va a contener ningún otro componente queimpida el uso de la herramienta IBM Rational Functional Tester.

3.4.2. AdaptabilidadEl tiempo de implementación de otras herramientas requeridas para eladecuado funcionamiento del sistema no va a durar más de un día.

3.4.3. MantenimientoEl SVGA va a contar con errores programados que serán mostrados yregistrados para hacer uso de éstos en una futura solución al problema.

3.4.4. CompatibilidadDespués que SVGA esté en ejecución, las versiones siguientes van a sercompatibles con sus predecesoras. Todas las transacciones ingresadaspreviamente en versiones previas van a ser disponibles en las nuevasversiones.

3.4.5. Capacidad de ActualizaciónEl sistema va a ser provisto de actualizaciones que pueden contener

asistencia técnica que contribuya con su operatividad.3.4.6. Capacidad de InstalaciónLa instalación del sistema no va a requerir alguna otra instalación dealguna estación de trabajo.

3.4.7. EscalabilidadDespués de 6 meses de trabajo, el sistema va a ser capaz de alojar unadicional de 500 usuarios más.

3.4.8. PortabilidadCambiar la base de datos del sistema en el futuro, no va a requeriralguna reescritura de una aplicación lógica.

3.4.9. Capacidad de ser ReusableLas funcionalidades principales del sistema van a ser encapsulados en

componentes que van a ser reusados un una aplicación cliente-servidor.3.4.10. VariabilidadLa variabilidad del sistema no va a contener herramientas internas oexternas las cuales cambien la funcionalidad del software.

3.4.11. Capacidad de ser AnalizadoEl sistema va a contener un estándar apropiado para el fácil análisis porparte del usuario que lo requiera.

3.4.12. Capacidad de ser LocalizadoEl sistema va a estar disponible en español.

3.5. Consideraciones de diseño e implementación• El sistema utilizará la 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 de aplicaciones.• Se utilizará SQL Server como base de datos, bajo la plataforma Windows

Server 2003 de 64 bits.• El sistema funciona bajo la plataforma Windows XP Professional 32 bits.

3.6. Documentación de Usuario en Línea y Sistema de AyudaEl SVGA contará con un espacio web en el cual el usuario podrá encontrarayuda en línea; además, tendrá disponible un campo en el que pueda dejarsugerencias y reportar cualquier tipo de inconveniente.

3.7. Interfaces3.7.1. Interfaces de Usuario

Las interfaces que serán implementadas por el software, serán de fáciluso y entendimiento para el usuario; además, presentará un entorno




7!


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 HardwareEl sistema será implementado sobre el servidor netfinity IBM con el queya cuenta CIMAQ S.A., y será instalado en los módulos que seránubicados en almacén.

3.7.3. Interfaces de SoftwareEL sistema será desarrollado en Eclipse Helios y diseñado en Dreamweaver CS4, y será funcional bajo la plataforma Windows XPProfessional 32bits; el servidor de base de datos será SQL Server 2005,bajo la plataforma Windows Server 2003 de 64bits.

3.7.4. Interfaces de ComunicacionesSe hará uso de una Conexión de área local (LAN), utilizando para lacomunicación, cables de internet UTP con conectores RJ45.

3.8. Requerimientos de LicenciaEl sistema será implementado sobre los recursos informáticos que ya existenen CIMAQ S.A., por lo tanto, no será necesario adquirir nuevas licencias.

3.9. Requerimientos legales, Copyright y OtrosEl SVGA formará parte de los módulos o sistemas ya existentes dentro de lasinstalaciones de CIMAQ S.A.

3.10. Aplicación de EstándaresLos estándares aplicables para la realización del sistema SVGA serán lossiguientes:3.10.1. Hardware

Estandarizado al actual que está siendo usado en las instalaciones deCIMAQ S.A.

3.10.2. SoftwareEstandarizado aplicando patrones de diseño (DAO, MVC), interfacesgráficas, web 2.0.

3.10.3. RedesEstandarizado siguiendo el modelo OSI.




7"


Especificación de caso de uso: Generar Orden de Almacén

1. Breve descripciónEl caso de uso permite al Coordinador de Almacén generar una orden de almacén apartir de un pedido facturado.

2. ActoresCoordinador de almacén (CO)3. Flujo de eventos

3.1. Flujo Básico1. 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 defacturació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 lasiguiente 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. (nohabilitados)

• 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 depago (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”.




!#


17. El sistema muestra la interfaz “Operarios Disponibles” con la siguienteinformación:• Datos de operarios disponibles en dicha fecha (lista): código de

operario, nombre, horas disponibles y horas asignadas (habilitado), conlas opciones “Asignar” y “Cancelar”.

18. El CO ingresa la cantidad de horas a asignar a cada operario en el campohoras asignadas de la lista de operarios.

19. Si el CO selecciona la opción “Cancelar”, el flujo regresa al paso 14 del flujobá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 siguienteinformació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 “NoAtendida” y muestra el MSG: “Orden de Almacén generada correctamente”

42. El CO selecciona “Salir”, el sistema cierra la interfaz “Gestión de Orden deAlmacén” y el caso de uso finaliza.

3.2. Sub Flujos

Imprimir Detalle1. El sistema imprime el detalle del pedido facturado.2. El flujo continúa en el paso 8 del flujo básico.




!


3.3. Flujos Alternativos10.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álidosSi los datos ingresados en la prioridad (nivel) son nulos o inválidos en elpaso 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ónSi el sistema no puede grabar el nivel de prioridad y/o los datos deoperarios, muestra el MSG “Error al grabar datos en sesión” y finaliza elcaso de uso.

21.1. Cantidad Inválida

Si la cantidad ingresada es inválida, el sistema muestra el MSG: “Cantidadde 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 sistemamuestra el MSG: “Selección del transportista obligatoria” y el caso de usocontinúa en el paso 31.

41.1. Error al grabar Orden de AlmacénSi 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 paso38.

4. Precondiciones4.1. El CO debe estar registrado y logueado en el sistema.

5. Post condiciones5.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 especiales6.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ónNinguno.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 quese utilizarán durante la gestión de los requisitos.A continuación, se describen los atributos que pueden ser utilizados según el tipode requisito. Ver tabla 4.2.



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

CIBERTEC CARRERAS PROFES



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






Tabla 4.2 – Atributos de los requisitos




!6



1. Para la próxima clase los equipos de proyectos presentarán los documentos: Plande 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 susespecificaciones de caso de uso del punto 1.



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

____________________________________________________________________________CI&*T&C CA**&*AS *OF&SIO"A#&S

R$%&'$

Los documentos se crean según el Plan de Gestión de Requisitos y según losniveles 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 delos casos de uso con escenarios y casos de prueba.



,,

CA**&*AS *OF&SIO"A#&S CI&*T&C

TRAZABILIDAD DE REQUISITOS LOGRO DE LA UNIDAD DE APRENDIZAJE

Al finalizar la primera unidad, el alumno documenta los requisitos funcionales y nofuncionales de un software que da soporte a un proceso de negocio, y controla suscambios 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.

UNIDAD DE

APRENDIZAJE

TEMA

5



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


1. TRAZABILIDAD ENTRE REQUISITOS

La trazabilidad es una técnica que proporciona una relación entre los diferentesniveles 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 desdeel nivel superior hacia abajo. Todas las necesidades por lo general se asignan aalgunas características. En general, es una relación de muchos a muchos, porqueuna necesidad puede rastrear a muchas características, y una característicapuede obtenerse de muchas necesidades. Un caso común también es que unanecesidad rastrea a una característica. En el siguiente nivel también notamos quelas características mapean a los casos de uso en una relación de muchos amuchos. Las características también trazan a los requisitos suplementarios en unarelació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 deuno a muchos entre los casos de uso y escenarios. Los escenarios también tienenuna 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 clientepidió fue implementado.

2. Verificar si la aplicación hace sólo lo que se pidió: No implementa algo que elcliente nunca solicitó.

3. Realizar un análisis de impacto: ¿Qué elementos se verán afectados si seconsidera 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, queremossaber 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 vangenerando.



9/


Cada vez que se crea o cambia un nuevo artefacto (un objetivo, un requisito, unelemento 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 niveldepende. Esta tarea es la única forma de poder realizar un análisis de impactocuando se solicita un cambio, pues todos los que dependen del artefacto, tantodirecta 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 serexplícitamente trazado a partir de otro elemento textual o modelo para hacer unseguimiento de las dependencias entre ellos. La siguiente tabla describe todos lostipos de requisitos a utilizar en el proyecto.

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



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


ACTIVIDADES RESUELTAS

1. A partir de la especificación de la lista de requisitos dada por su profesor realicelas siguientes matrices de trazabilidad:

•

Necesidades de stakeholder (STRQ) versus características del producto(FEAT).

NECESIDADESSTRQ1: 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 deparadas.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, ytodaví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, yproporcionar información acerca de las atracciones.


STRQ24: El sistema deberá seguir las guías de implementación prevista en lacadena de nuestras agencias de viajes.

STRQ25: Las páginas donde los proveedores de servicios pueden presentar susofertas deberán estar protegidas con contraseñas. Los proveedores dehotel, los proveedores de automóviles, y los representantes de líneas



90


aéreas deberán usar su ID y contraseña asignado para acceder a estaspáginas.


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 unareserva 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 deadultos, número de hijos y preferencias de habitación.

STRQ39: Mientras se proporcione información acerca del hotel, la siguienteinformació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 aceptancheques ni PayPal.

CARACTERISTICASFEAT1: El usuario deberá ser capaz de comparar los precios de vuelos de otrosaeropuertos cercanos (para vuelo de ida y vuelo de retorno).FEAT2: Las fechas deberán ser mostradas de acuerdo al formato cargado en laconfiguración del navegador Web.FEAT3: En las pantallas de entrada de datos, el sistema indicará que campos sonobligatorios de ingresar colocando un asterisco cerca al campo.FEAT4: El usuario será capaz de cancelar la compra de un boleto en cualquiermomento 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 elmenos número de paradas o por precio.FEAT7: Durante la compra de un boleto de avión, el usuario será capaz deseleccionar los asientos.FEAT8: El sistema mostrará un calendario emergente en cualquier fecha que seingrese, tales como una fecha de vuelo, fechas de permanencia en el hotel, o lafecha del alquiler de un auto).FEAT9: El usuario tendrá la oportunidad de indicar si necesita solo un boleto deida o ida y retorno.FEAT10: El sistema deberá identificar el aeropuerto en base al código delaeropuerto 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.





FEAT13: Si el usuario compra un boleto de una vez, no será necesario repetir lamisma información (tales como dirección o número de tarjeta de crédito) durantelas transacciones futuras.FEAT14: La lista de vuelos disponibles deberán incluir número de vuelo, hora departida, hora de llegada en cada etapa del vuelo.FEAT15: El sistema deberá proporcionar la comparación de los precios de alquilerde autos de diferentes empresas.FEAT16: Los precios del alquiler de autos deben mostrar todos las Impuestosaplicables.FEAT17: El sistema deberá proporcionar la oportunidad de reservar el vuelo.FEAT18: El sistema deberá proporcionar la oportunidad de comprar un boleto deavión.FEAT19: El sistema deberá proporcionar la oportunidad de reservar unahabitación de hotel.FEAT20: El sistema deberá proporcionar la oportunidad de reservar un auto.FEAT21: El sistema deberá proporcionar información acerca las atracciones enlugares específicos.

FEAT22: El usuario será el capaz de comprar un boleto en línea, sin necesidad dellamar al Agente de viajes.FEAT23: El sistema utilizará la arquitectura JEE.FEAT24: Si la arquitectura requiere de un servidor de aplicaciones deberá utilizarIBM WebSphere.FEAT25: Si el sistema requiere una base de datos. Oracle deberá utilizar.FEAT26: Las páginas donde los proveedores de servicios pueden presentar susofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, losproveedores de automóviles, y los representantes de líneas aéreas deberán usarsu 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 defiabilidad apropiado para las aplicaciones comerciales.

FEAT28: El sistema deberá ser desarrollado tres meses a partir de la fecha enque el cliente firme los Casos de Uso y las especificaciones suplementarias.FEAT29: Los usuarios recogerán sus ID y contraseñas mientras compran unboleto de avión.FEAT30: El servicio de búsqueda permitirá al Agente de Viajes encontrar unareservació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, eladministrador de Contenido podrá ingresar el texto sin etiquetas HTML.FEAT34: El sistema deberá ser completamente probado en los siguientesnavegadores: Internet Explorer y Netscape.

FEAT35: Todas las transacciones y los errores deberán ser registrados y estarándisponibles 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 detiempo determinado.Una lista de todas las reservas de autos en un período de tiempodeterminado.Una lista de todas las reservas de habitaciones de hotel en un periodo detiempo determinado.

FEAT37: Mientras se reserve una habitación, el cliente deberá proporcionar lasiguiente información: ciudad, días de alojamiento, el número de adultos, númerode hijos y preferencias de habitación.



9


FEAT38: Mientras se proporcione información acerca del hotel, la siguienteinformación se mostrará: dirección, teléfono, fax, correo electrónico, losdescuentos ofrecidos y las formas de pago disponibles.FEAT39: Al usuario se le ofrecerá paquetes de ofertas que constan de vuelos yalojamiento en hoteles.FEAT40: Durante el pago del boleto de avión, solo se aceptará con tarjeta decré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 matricescorrespondientes.

Caso Saga Falabella

“Saga Falabella” es un conocido Centro Comercial que se dedica a las ventas deproductos al crédito, dentro de su política de calidad y mejora continua desea realizarel 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 atendidopor un vendedor que se encarga de llenar sus datos tanto personales como del créditoen el formulario GCC-01 denominado “Solicitud de crédito”.

Para completar el expediente del cliente, además del formulario adjunta la copia delDNI, un recibo de luz, agua o teléfono y las tres últimas boletas o recibos dehonorarios profesionales que acrediten los ingresos del cliente.

Al final del día el vendedor recopila los expedientes y los entrega al coordinador deinspectoría de la central de créditos, quien se encarga de repartir los expedientes a losdiferentes inspectores. Por cada expediente, el inspector debe primero verificar que elsolicitante 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 arealizar la verificación de los datos declarados por el solicitante mediante llamadastelefónicas o visitas personales.

Después de realizar un máximo de tres visitas y de constatar la validez de lainformación declarada por el futuro cliente, prepara un informe de inspectoría que lehace 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 delcrédito. Si su evaluación es positiva le otorgará una línea de crédito de consumomensual 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.

PREGUNTAS1. Usted es el Analista de Sistema y deberá identificar las Necesidades relacionadas

a este proceso, describiendo brevemente cada uno.

Necesidades DescripciónSTRQ1 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.





STRQ4 El Jefe de créditos podrá evaluar una solicitud de crédito paraaprobarlo o rechazarlo.

STRQ5 Debe estar disponible la opción de generar una línea de créditodespués de aprobada una solicitud.

STRQ6 El sistema debe imprimir la tarjeta de crédito para el cliente que se le

aprobó el crédito.STRQ7 Los usuarios podrán consultar trámites pendientes del cliente y

solicitudes por estado.STRQ8 Los usuarios podrán verificar la calificación de un cliente con el sistema

de INFOCORP.STRQ9 La comunicación entre usuarios será por correo electrónico.

STRQ10 Los usuarios del sistema tendrán un Usuario y contraseña paraingresar al sistema.

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

3. De las características identificadas en la pregunta 2, se le pide que ustedidentifique los casos de uso del sistema que deben darle cobertura. Describabrevemente cada uno de ellos.

Característica Caso de Uso DescripciónFEAT1FEAT2

UC1 Registrar solicitud de Crédito.

FEAT3 UC2 Buscar Inspector.

Necesidad Característica DescripciónSTRQ1 FEAT1 El sistema permitirá registrar una solicitud de crédito.

STRQ1 FEAT2 El sistema permitirá registrar los datos personales de uncliente.

STRQ2 FEAT3 Disponibilidad de la lista de inspectores, para subúsqueda.

STRQ2 FEAT4 El sistema permitirá asignar expedientes a losinspectores para su inspección.

STRQ3 FEAT5 El sistema proveerá la oportunidad de registrar unInforme de las inspecciones realizadas a un cliente.

STRQ4 FEAT6 El sistema permitirá evaluar una solicitud de crédito, paraaprobar o rechazar.

STRQ5 FEAT7 El sistema permitirá generar una línea de crédito, si elcrédito fue aprobado.

STRQ7STRQ8

FEAT8 Una vez generado la línea de crédito, el sistema permitiráimprimir una tarjeta de crédito para el cliente.

STRQ8 FEAT9 El sistema tendrá consultas de: trámites pendientes, aINFOCORP solicitudes por estado y solicitudesmensuales

STRQ8 FEAT10 El sistema deberá comunicarse con el sistema deINFOCORP, para verificar la calificación de riego de losclientes.

STRQ9 FEAT11 El sistema permitirá a los usuarios conocer el estado delas solicitudes por correo electrónico.

STRQ10 FEAT12 El sistema verificará el usuario y contraseña para ingresaral aplicativo.

STRQ1STRQ2

FEAT13 El sistema permitirá gestionar los datos de los clientes einspectores.



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 UC8 Consultar trámites pendientes.FEAT9FEAT10

UC9 Consultar Cliente en INFOCORP.

FEAT9 UC10 Consultar solicitudes x estado.

FEAT9 UC11 Consultar solicitudes mensuales.

FEAT11 UC12 Enviar correo.

FEAT12 UC13UC14UC15

Mantener ClienteBuscar ClienteMantener Inspector.

FEAT13 UC16 Ingresar al sistema.

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



9,


R$%&'$

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

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 delos casos de uso con escenarios y casos de prueba.





REPASO DE MODELADO DEL NEGOCIO - CAPTURA

DE REQUISITOS


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, ydiagrama la estructura y el comportamiento de sus funcionalidades mediantediagramas de clases y diagramas de comunicación respectivamente, haciendo uso dela herramienta CASE IBM Rational Software Architect.

TEMARIO - REPASO

1. Modelado de negocio.2. Captura de requisitos.3. Captura de requisitos a partir del Modelado del negocio.4. Estructurando el Modelo de casos de uso.5. Priorización de casos de uso.


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

UNIDAD DE

APRENDIZAJE

2TEMA

6



1//


1. Modelado del Negocio

Es una disciplina opcional de RUP. La necesidad de esta disciplina surge ante elhecho de que muchos de los productos de software que se desarrollanautomatizan 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 unestudio 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 laorganizació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 denegocio de una organización en términos de Actores de Negocio y Casos de usodel Negocio.El Modelo de análisis del negocio (MAN) describe cómo cada caso de uso denegocio es llevado a cabo por un grupo de trabajadores que utilizan entidades delnegocio.Los artefactos creados en estos modelos sirven como entrada y referencia para ladefinición de los requisitos del sistema en la disciplina Captura de Requisitos parael modelo de casos de uso. (Ver figura 6.1).

Figura 6.1 - Artefactos del Modelado de Negocio.



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


1.1. Actividades para realizar un Modelado de NegocioEl 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



1/0


1.2. MODELO DE CASOS DE USO DEL NEGOCIO1.2.1. Determinar la situación de la organización

El objetivo es reconocer el negocio para delimitarlo. Las actividades a realizarson 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 porlos 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 negocioEl equipo debe tener claras las fronteras del negocio. Para ello debeidentificar 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 creaun Diagrama General de Casos de Uso de Negocio .

Cada caso de uso del negocio, tiene una breve descripción en un documentoEspecificación de Caso de Uso del Negocio (ECUN) .

Para describir los actores del negocio y su asociación con los casos de usode negocio, se utiliza el artefacto Actores del Negocio .

1.2.3. Refinar las definiciones de los procesos de negocioConsiste 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 , describiendopaso a paso las actividades que se desarrollan en el proceso de negocio.

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

Consiste en describir como se lleva a cabo las actividades realizadas por losroles (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 deClases de Negocio y un Diagrama de Actividades de Negocio .

En cada documento Especificación de Caso de Uso del Negocio se puedeagregar al final los diagramas de clases y actividades.

1.3.2. Refinar roles y responsabilidadesConsiste en detallar más los documentos Trabajadores del Negocio yEntidades del Negocio.



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


Artefacto Descripción

Situación del Negocio

Documento que contiene la visión del negocio, un glosariode términos del negocio, los objetivos del negocio y reglasdel negocio.

Objetivos del Negocio

Es un requisito que debe ser satisfecho por el negocio.Describe el valor deseado de una medida en particular afuturo, y se utiliza para planear y administrar las actividadesdel negocio. El objetivo debe ser claro, mesurable,alcanzable, realista y sensible al tiempo.Se permite la relación de dependencia entre objetivos delnegocio y la de soporte de un caso de uso del negocio.

Casos de Uso del Negocio

Define un conjunto de acciones que el negocio lleva acabo y provee resultados de valor a quienes interactúan

con el.Describe un proceso de negocio desde un punto de vistaexterno que percibe algún tipo de valor.Definen los límites de la organización.

Actor del Negocio

Representa un rol que algo o alguien externo desempeñaen relación con el negocio.Puede ser asociado a uno o más casos de uso del negocio.

Modelo de Casos de Usodel 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 diagramasque permiten ver cómo interactuar con el entorno.

Actores del Negocio

Documento que contiene información de los actores delnegocio identificados en el modelo de casos de uso delnegocio.

Especificación de Caso deUso del Negocio

Documento que contiene las características de un procesode negocio. Se realiza una especificación por cada caso deuso de negocio.

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



1/



Trabajadores del Negocio

Un trabajador del negocio es un rol interno al negocio.Colabora con trabajadores de otro sector, es notificado sobreacontecimientos del negocio y manipula entidades de negocio

para realizar sus responsabilidades.

Entidades del Negocio

Ente significativo y persistente manipulado por actores delnegocio y trabajadores del negocio.Hay dos tipos de entidades:

- Informativos (Documentos)- Persistentes (Fichas de datos)

Realización de Caso de

Uso del Negocio

Colección de diagramas que muestra cómo los actores y/otrabajadores del negocio y entidades del negocio llevan acabo el caso de uso del negocio.Generalmente se utilizan Diagramas de Clases y Diagramas

de Actividades para realizar el detalle de cada proceso denegocio.

Modelo de Análisis delNegocio

Representa la vista interna del negocio.Es un modelo que describe la realización de los casos de usodel negocio. Es una abstracción de cómo los trabajadores delnegocio y las entidades de negocio se relacionan y de cómocolaboran para realizar los casos del uso del negocio.

Trabajadores del Negocio

Documento que contiene información de los trabajadores delnegocio identificados en el modelo de análisis del negocio.

Entidades del Negocio

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

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





2. Captura de RequisitosEsta disciplina desarrolla el modelo del sistema a construir. Se utilizan los casosde uso para crear este modelo. Los requisitos funcionales se estructuran mediantecasos 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 delsistema.

Figura 6.3 - Artefactos de la Captura de Requisitos.


Visión

Documento que define la opinión de los stakeholders delproducto que se desarrollará, especificada en términos denecesidades y características claves de los stakeholders.Contiene un esquema de los requisitos previstos, el cualproporciona la base contractual para los requisitos técnicosmás detallados.

Especificación derequisitos de Software

La Especificación de Requisitos de Software es un documentoque enfoca la organización completa de los requisitos delproyecto.

Comúnmente conocido como SRS por sus iniciales en inglés.Contiene la lista de requisitos funcionales y no funcionales.



1/3


Paquetes de casos deuso

Es una colección de casos de uso, de actores, de relaciones,de diagramas, y de otros paquetes de ser necesario; y esutilizado para estructurar el modelo de casos de usodividiéndolo en piezas más pequeñas.

Caso de uso

Es una funcionalidad específica del sistema con identidadpropia, el cual define una secuencia de acciones que el sistemarealiza para un actor en particular.Un caso de uso contiene uno o más requisitos funcionales.

Actor

Representa un rol (humano, hardware o software) externo alsistema con el que se establece intercambio directo deinformación.Puede ser asociado a uno o más casos de uso.

Modelo de casos deuso

Es un modelo que captura los requisitos funcionales de los

usuarios a un alto nivel y establece la estructura fundamentaldel sistema. Es un input esencial para las actividades enanálisis, diseño y pruebas.

Actor

Documento que contiene información de los actoresidentificados en el modelo de casos de uso.

Especificación de casode 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. Laespecificación también contiene otra información tal comoprecondiciones, poscondiciones, requisitos especiales yprototipos. Se realiza una especificación por caso de uso.


Documento que especifica los requisitos funcionales que noson 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 RequisitosLa 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.





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. Paradeterminar el alcance inicial del proyecto, los límites del sistema debenser 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 funcionalesson expresados como Casos de uso. Los requisitos no funcionales sondocumentados como Especificaciones suplementarias.

Se utilizan técnicas para capturar requisitos, tales como lasentrevistas, cuestionarios, prototipos, etc. en las primeras iteracionesde esta disciplina.



1/,


2.2.3. Definir el Sistema

Se identifican los actores y los casos de uso a través del Modelo deCasos de uso refinado; además, de los requisitos no funcionalesdefinidos en las especificaciones suplementarias.

2.2.4. Administrar el Alcance del SistemaEl alcance del proyecto es definido por el conjunto de requisitos. Laclave 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 eniteraciones.

2.2.5. Refinar la Definición del Sistema

El resultado es una comprensión más profunda de las funcionalidadesdel sistema expresada en Casos de uso detallados y documentos deEspecificaciones suplementarias, Especificación de requisitos de

software, Especificaciones de casos de uso y Especificacionessuplementarias.

2.2.6. Administrar los Cambios de Requisitos

Los cambios de los requisitos producidos impactan en las disciplinasde análisis, diseño, pruebas, implementación y despliegue. Latrazabilidad es establecida para identificar las relaciones entre losrequisitos y otros artefactos.

3. Captura de requisitos a partir del Modelado de negocioEl 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 serinformatizadas. Luego, con estos requisitos se crean los casos de uso. Losactores 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 ainformatizar, requisitos funcionales y casos de uso. Más aún, si se trata de seguirrequisitos funcionales de casos de uso, el cual es un proceso complicado por elhecho de que existe una relación muchos a muchos entre ellos.

Un caso de uso puede tener muchos requisitos funcionales y unrequerimiento funcional puede estar en varios casos de uso.





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

Tabla 6.4. Plantilla de Matriz de Actividades Vs. Requisitos

No todos los requisitos son explícitos en los procesos de negocio. Aquellosrequisitos que tienen que ver con mantenimientos, consultas, reportes, seguridad,otros lo podemos agregar en la Matriz de Requisitos Adicionales del sistema, talcomo se muestra en la siguiente tabla. Los casos de usos adicionales tambiéndeben ser incluidos en el Diagrama de casos de uso final del sistema.

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 decaso de uso inicial. Luego se detallan los casos de uso a través de laEspecificación de casos de uso. Por último se estructura el modelo, esto quieredecir agregar los casos de uso incluidos, extendidos y generalizados.

Estructurar, significa separar en partes el caso de uso para hacer menos casosde 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.

Matriz de Actividades Vs. Requisitos del Sistema <Nombre del Sistema>

ro4eso de"e5o4io

A4ti6idad de"e5o4io

*esponsa8e de"e5o4io

*euisito Caso de so A4tores

Proceso 'R(' U)('

R(* U)(*

Proceso *

R(+ U)(+

R(, U)(,

R(- U)(-

R(. U)(.

Matriz de Requisitos Adicionales < Nombre del sistema>

Paquete Requisito Funcional Caso de Uso Actores



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 (<<inclusión>>). 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 usoincluido.

• Se extrae comportamiento común del caso de uso y simplifica el casode 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





4.2.2. Relación de Extensión• Dependencia entre dos (2) casos de uso (<<ampliar>>). 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 usoextendido.• 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



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 usoEl propósito de la priorización es identificar los casos de uso primarios para lapresente etapa de desarrollo del proyecto. La priorización permitirá darle la debidaatención (y con mas tiempo) a los casos de uso más complejos e importantes.

5.1. PriorizaciónDistingue 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 norepresentan 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 factorque afecta a cada caso de uso. Los valores que pueden tomar los factoresestá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 a6.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 revelaque las transacciones de la empresa se apoyan considerablemente en lafuncionalidad.

• Complejidad de desarrollo (0.3): Indica la dificultad que se percibe delcaso 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 usocon la lista de riesgos. Un alto valor en este factor indica que el caso de uso





tiene bastantes riesgos asociados. Los casos de uso con alto valor en estefactor pueden ser considerados primarios debido a que deben serenfrentados en las etapas iniciales.

• Impacto de los requerimientos no funcionales (0.1): Indica como afectanlos requerimientos no funcionales (FURSP +) al proceso del negocio y enqué manera se vería comprometido.

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

0.4 0.3 0.2 0.1

CASOS DE USO Importancia Complejidad Riesgo Impacto Total

Caso de uso 1 10 5 7 8 8.1

Caso de uso 2 10 7 9 6 8.68Caso de uso 3 9 7 9 8 8.52

Caso de uso 4 9 7 9 7 8.4

Caso de uso 5 9 4 10 9 8.4

Caso de uso 6 9 6 7 8 7.74


Caso de uso 9 8 7 6 5 6.86



Caso de uso 14 8 5 6 3 6.26

Caso de uso 15 7 5 5 8 6.16

Caso de uso 16 8 3 4 6 5.66

Caso de uso 17 7 4 6 2 5.56

Caso de uso 18 7 5 5 2 5.44

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






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.




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 dealmacén que se ve afectada negativamente por la falta de control de tiempos y lapriorización en la entrega de productos. Además, existe una falta de sincronizaciónentre la elaboración de pedidos del área de ventas y la gestión de existencias einventarios del área de almacén.

El presente proyecto se va a referir al “Sistema de Ventas y Gestión de Almacén” de laempresa CIMAQ SA, la cual se dedica a la compra, venta y alquiler de maquinarialigera, equipos, repuestos y materiales. Además ofrece el servicio de postventa quepermite ofrecer a los clientes la seguridad y tranquilidad que necesitan paraconcentrarse en sus negocios y saber que sus empresas pueden operar al máximo encualquier lugar del Perú.

Mediante la utilización de diferentes herramientas, el objetivo principal será el crear unsistema 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 lasresponsabilidades al personal. Además de integrar un modulo de ventas para generarpedidos basándose en la disponibilidad del stock y un módulo de control deexistencias, que permita saber con exactitud qué productos están disponibles y cualesnecesitan reabastecimiento.

El alcance del proyecto se concentrará en el área de logística. Se van a identificarprocesos, actividades, trabajadores, etc.; y se realizará la captura de requisitos pormedio 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 Repuestos3. Abastecimiento de Almacén.



ANALISIS Y DISEÑO DE SISTEMA II (TEORIA)

6


ECUN – Venta de Repuestos1. Introducción

El presente documento Especificación de Caso de Uso de Negocio proporciona lainformación necesaria para describir el proceso de Venta de Repuesto desde elpunto de vista del negocio.1.1. Propósito

Este documento tiene como propósito definir el flujo básico y alternativo delproceso Venta de Repuesto. También, identificar los objetivos, riesgos,posibilidades, entre otros; de dicho proceso.

1.2. AlcanceEl documento nos ayudará a tener una mejor perspectiva del proceso Venta deRepuesto, facilitando la identificación de quienes intervienen y los roles quecumplen, así como las entidades que son parte del proceso de negocio.

1.3. Definiciones, Acrónimos y AbreviacionesRVRS: 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 Repuestos2.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, hastaque el Analista de Compra de Repuesto envía la documentación a almacén.

3. Objetivos3.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 GCPrime con respecto al año pasado.

4.2 Aumentar las ventas al 40 % en todos los tipos de repuestos con relación aaños anteriores.

4.3 Disminuir el precio de los repuestos en un 10 % para sacar mayor beneficio deestos.

5. Flujo de Trabajo5.1. Flujo Básico

1. El Caso de Uso de Negocio inicia cuando el cliente solicita unrequerimiento 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.




7


5.2. Flujos Alternativos4.1. Rechazar Cotización

El cliente rechaza la cotización entregada por el RVRS y el procesofinaliza.

5.1. Registrar Datos del ClienteSi e cliente es nuevo, el RVRS registra los datos del nuevo cliente.

7.1. Forma de Pago al contadoEl cliente le indica al RVRS que la modalidad de pago será al contado.

8.1. Rechazar créditoEl Jefe de créditos y cobranzas rechaza el crédito para cliente y elproceso finaliza.

11.1. Stock no disponibleEl ACR verifica que no hay stock no disponible11.1.1. Gestionar Compra de Repuestos

El ACR inicia el proceso Abastecimiento de Almacén con unproveedor.

6. Categoría

El caso de uso de negocio, Venta de repuestos, pertenece a la categoría de losprocesos núcleo ya que influye sobre diferentes áreas de la empresa y tienenimpacto 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 gamade posibilidades de elección y un servicio eficiente, rápido y confiable.

9. Propietario del procesoEl propietario, encargado de administrar y manejar este caso de uso de negocio, esel representante de ventas de repuestos y servicios.

10. Pre-condiciónEl 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.





Matriz de Actividades Vs. Requisitos del Sistema - SVGA

.ro4eso de"e5o4io

A4ti6idad de7 "e5o4io*esponsa87e de7

"e5o4io*e9uisito Caso de :

;enta derepuestos

)olicitar requerimientode venta

liente R(' Re$istrar requerimiento de venta U)(' Re$istrar Requ/

Preparar coti1ación deventa

R#R) R(* 2enerar coti1ación de venta U)(* 2enerar ot

#erificar liente R#R) R(+ 3uscar liente U)(+ 3usc

Re$istrar liente R#R) R(, Re$istrar liente U)(, 4ante

2enerar Pedido R#R) R(- 2enerar Pedido de #enta U)(-2enerar /rd

#

Evaluar r5dito 6efe de R(. Apro!ar r5ditoU)(. Evalu

R(7 Rec8a1ar r5dito

#erificar stoc9 AR R(: onsultar stoc9 de repuesto U)(7 onsultar sto

&ntre5a de*epuestos

A8aste4imiento

de A7ma4<n





Matriz de Requisitos Adicionales - SVGA

Paquete Requisito Funcional Caso de Uso

Reuestos

RF09 Buscar Repuesto CUS08 Buscar Repuesto

RF10 Arear Repuesto

CUS09 !antener RepuestoRF11 Actuali"a Repuesto

RF1# $liminar Repuesto





ECUN – ENTREGA DE REPUESTOS 1. Introducción

El presente documento Especificación de Caso de Uso de Negocio proporciona lainformación necesaria para describir el proceso de Entrega de Repuestos desde elpunto de vista del negocio.1.1. Propósito

Este documento tiene como propósito definir el flujo básico y alternativo delproceso Entrega de Repuestos. También, identificar los objetivos, riesgos,posibilidades, entre otros, del proceso.

1.2. AlcanceEl documento nos ayudará a tener una mejor perspectiva del proceso Entregade Repuestos, facilitando la identificación de quienes intervienen y los roles quecumplen, así como las entidades que son parte del proceso de negocio.

1.3. Definiciones, Acrónimos y AbreviacionesO/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 Repuestos2.1. Breve descripción

Este proceso consiste en la entrega de repuesto (s) al cliente, desde elmomento que el personal de almacén recibe la documentación para eldespacho, proveniente de facturación, hasta la entrega al cliente.

3. Objetivos3.1. Reducir el tiempo de atención de repuestos.3.2. Aumentar la satisfacción del cliente.

4. Rendimiento de Objetivos4.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 trabajo5.1. Flujo básico

1. El proceso se inicia cuando el EF envía a almacén el comprobante de pagoy 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 alternativosNinguno.




22


6. CategoríaEl caso de uso de negocio, entrega de repuestos, pertenece a la categoría deprocesos 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 por

el cliente.8. Posibilidades

Lograr satisfacer al cliente a la hora de la entrega del repuesto, sin demoras niretrasos.

9. Propietario del procesoEl propietario, encargado de administrar y manejar este caso de uso de negocio, esel coordinador de almacén.

10. Pre-condiciónLa facturación del pedido del cliente y entrega de la documentación necesaria(guías, facturas).

11. Post-condiciónEntrega de la documentación (cargos firmados) 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 – 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éndesde el punto de vista del negocio.1.1. Propósito

Este documento tiene como propósito definir el flujo básico y alternativo delproceso Abastecimiento de Almacén. También, identificar los objetivos, riesgos,posibilidades, entre otros; de dicho proceso.

1.2. AlcanceEl documento nos ayudará a tener una mejor perspectiva del procesoAbastecimiento de Almacén, facilitando la identificación de quienes intervieneny los roles que cumplen, así como las entidades que son parte del proceso denegocio.

1.3. Definiciones, Acrónimos y AbreviacionesACR: Analista de Compra de Repuestos.O/C: Orden de Compra.

1.4. ReferenciasLas referencias al presente documento son las siguientes:• Entrevista a personal de Logística• Entrevista al Gerente General• Entrevista al Jefe de Proyectos y Procesos.

2. Abastecimiento de Almacén2.1. Breve descripcion

Este proceso consiste en el paso a paso del abastecimiento de almacén, desdeel momento que el Analista de Compra de Repuesto prepara el requerimiento

de compra, hasta el momento que se envian los documentos a facturación.




23


3. ObjetivosAmpliar el stock de repuestos en la línea GC.Aumentar la satisfacción del cliente.

4. Rendimiento de Objetivos4.1. Aumentar la disponibilidad de repuestos de la línea GC en 30%.4.2. Reducir el tiempo de reposición de repuestos a 10 días como máximo.

5. Flujo de trabajo5.1. Flujo básico

1. El proceso se inicia cuando el ACR elabora el requerimiento de compra.2. El ACR envía el requerimiento de compra al proveedor.3. El proveedor recibe el requerimiento de compra y prepara la cotización del

repuesto(s).4. El 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 compra al proveedor y al almacén.8. El Proveedor prepara los repuestos solicitados y los envía adjuntando la

documentacion respectiva.9. El Operario de Almacen recibe los repuestos y la documentacion respectivadel 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 elproveedor.

11. El operario de almacen ingresa los repuestos al inventario generando unanota de ingreso.

12. El operario de almacén envía los documentos (Nota de Ingreso, Factura yGuía) al área de Facturación y finaliza el proceso.

5.2. Flujos Alternativos5.1. Rechazar Cotización

El ACR rechaza la cotización de compra, y el proceso finaliza.

10.1. Entrega no conformeEl 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íade procesos de soporte, ya que da apoyo al proceso núcleo, Venta de Repuesto.

7. Riesgos• No tener el producto solicitado por el cliente y así no poder cumplir con lo pedido.• Retrasar la entrega del repuesto, debido a una mala gestión de la compra.

8. PosibilidadesMantener un óptimo stock de repuestos para satisfacer cualquier pedido del cliente.

9. Propietario del procesoEl propietario, encargado de administrar y manejar este caso de uso de negocio, esel analista de compras de repuesto.

10. Pre-condicionPreparar el requerimiento de compra y entrega de la documentación necesaria.

11. Post-condicionÓptimo stock de almacén y documentación en facturación.

12. Requisitos especialesLa evaluación de la cotización debe ser aceptada para que posteriormente seprepare la orden de compra.

13. Puntos de extensiónNo hay puntos de extensión




24


R$%&'$

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

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

El Modelo de Análisis del Negocio detalla cómo el proceso de negocio es

ejecutado internamente – Roles (Actores y Trabajadores del negocio conEntidades).

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

http://www-128.ibm.com/developerworks/rational/library/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 elsistema debe cumplir.

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

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

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

Si desea saber más acerca de estos temas, puede consultar los siguientes libros: “Ingeniería del Software” de Ian Sommerville

En el capítulo 6 encontrará información sobre requisitos del sistema y en elcapítulo 7, se profundiza el tema de la ingeniería de requisitos.

“UML 2” de Jim Arlow e Ila Neustadt

En el capítulo 3 encontrará información sobre la captura de requisitos.




25


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, ydiagrama la estructura y el comportamiento de sus funcionalidades mediantediagramas de clases y diagramas de comunicación respectivamente, haciendo uso dela herramienta CASE IBM Rational Software Architect.

TEMARIO

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


1. Los alumnos crean la arquitectura de análisis a partir de un diagrama de casos de usoestructurado trabajado en clase, a partir de las disciplinas Modelado del Negocio yCaptura de Requisitos.

UNIDAD DE

APRENDIZAJE

2TEMA

7




26


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 flujosde trabajo Modelado del Negocio y Captura de Requisitos; y los traslada aelementos 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ñobusca transformar la información obtenida de los stakeholders en información quelos analistas programadores podrán usar para su posterior implementación. El flujode 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 establecersi la visión del sistema es factible, y en determinar las tecnologías potencialespara 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ónparecida); entonces, ésta actividad se omite del flujo de trabajo.




27


En la parte inicial de la fase de elaboración se enfoca en crear la Arquitecturainicial del sistema (actividad Define a Candidate Architecture ) la cualproporcionará un punto inicial para todo el trabajo de análisis.Si la arquitectura ya existe (fue creada en iteraciones anteriores o en proyectosanteriores) el trabajo se enfoca en refinar la arquitectura (actividad Refine theArchitecture ), y en analizar el comportamiento y crear un conjunto inicial deelementos los cuales proporcionarán un comportamiento apropiado (actividadAnalyze Behavior ).

Después de que los elementos iniciales son identificados, se refinan eniteraciones futuras. La actividad Design Components produce un conjunto decomponentes los cuales proveen un comportamiento adecuado para satisfacer losrequisitos del sistema.Si el sistema incluye una base de datos, entonces la actividad Design theDatabase se ejecuta en paralelo. El resultado es un conjunto inicial decomponentes, los cuales en un futuro son refinados en la disciplina deImplementación.

1.1. Artefactos del AnálisisEn la disciplina de Análisis y Diseño son muchos los artefactos que definencómo se implementará el sistema. En el curso consideraremos los tipos deartefactos 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.


Modelo de Análisis

Representa la vista interna del sistema. Define unmodelo de objetos que describe la realización decasos de uso, y que sirve como abstracción para elmodelo de diseño.

Paquete de Análisis

Los paquetes del análisis proporcionan un medio paraorganizar los artefactos del modelo de análisis enpiezas manejables.Un paquete de análisis contiene clases y realizacionesde casos de uso a nivel de análisis.

Clase Interfaz

Es una clase utilizada para modelar la interacciónentre el entorno del sistema y su funcionamientointerno. Modela las partes del sistema que dependende su entorno.

Clase Control

Representa la lógica de negocio de la aplicación, esdecir, el control, la coordinación y la secuencia entreobjetos. Encapsula el comportamiento de uno o máscasos de uso.

Tabla 7.1. Artefactos del Análisis.




2!


Clase Entidad

La entidad es una clase utilizada para modelar lainformación y comportamiento asociado que deben seralmacenados.Modela las partes del sistema que son independientes

de su entorno.

Realización de Casode Uso

La realización de análisis de un caso de uso es unacolaboración que describe cómo se realiza el caso deuso en términos de clases de análisis y susinteracciones.

Diagrama de Clases

El diagrama de clases describe la estructura estáticade un caso de uso. Muestra las clases de análisis queparticipan en un caso de uso.

Diagrama deComunicación

Diagrama de interacción que describe elcomportamiento dinámico del caso de uso centrado encómo es la comunicación entre los objetos (instanciade una clase) participantes.

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, elcual es usado para representar la estructura global del sistema, describe lasrealizaciones 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 requisitoscomunes 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 entrela etapa de captura de requisitos y la de diseño ”.

El modelo no es un diagrama final que describe todos los posibles conceptos y susrelaciones. Este artefacto es opcional, pero también tiene a su vez la propiedad deser temporal en el caso en que se planea su desarrollo. Su utilidad radica en quepermite 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.




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 abstraccioneso 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 lospaquetes 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 laestructura y comportamiento del caso de uso respectivamente

• Modelo Conceptual, es un diagrama de clases que muestra todas las clasesdel tipo entity c onocido también como Modelo del Dominio.

2.1. Modelo de Casos de Uso Vs. Modelo de AnálisisEl siguiente cuadro muestra una comparación entre el modelo de casos de usoy el modelo de análisis:

Modelo de Casos de Uso Modelo de Análisis

Descrito con el lenguaje del cliente.Vista externa del sistema. Descrita en el lenguaje de losdesarrolladores. Vista interna delsistema.

Estructurado por los casos de uso. Estructurado por clases y paquetesestereotipados.

Utilizado como contrato entre elcliente y los desarrolladores sobrequé debería y qué NO debería hacerel sistema.

Utilizado por los desarrolladores paracomprender como debería darse formaal sistema, es decir, cómo debe estardiseñado e implementado.

Puede contener redundancias,inconsistencias entre los requisitos.

No debería contener redundancias,inconsistencias entre los requisitos.

Captura la funcionalidad del sistema,incluida la funcionalidad significativapara la arquitectura.

Esboza cómo llevar a cabo lafuncionalidad dentro del sistema,incluida la funcionalidad significativapara la arquitectura.

Define los casos de uso que seanalizarán con más profundidad enel modelo de análisis.

Define las realizaciones de casos deuso, y cada una de ellas representa elanálisis de un caso de uso del modelode casos de uso.

Tabla 7.2. Comparación entre el MCU y MA

3. Análisis de la ArquitecturaEl responsable de esta actividad es el Arquitecto de software. Permite definir unaarquitectura candidata basada en la experiencia obtenida de sistemas similares o

en dominios del problema similares y restringir las técnicas arquitectónicas a serusadas en el sistema.




3#


Se definen los diagramas de las vistas arquitectónicas, mecanismos claves y losmodelos para el sistema. Cabe destacar que analizar la arquitectura resultabeneficioso para sistemas nuevos.

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

3.1. Pasos a realizarEl 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 desoftware que tiene sentido desde el punto de vista de los expertos en eldominio. Una identificación inicial de los paquetes se hace de maneranatural basándonos en los requisitos funcionales y en el dominio delproblema, es decir, en la aplicación o proceso de negocio que estamosconsiderando.

Debido a que los requisitos funcionales se capturan en la forma de casosde uso, una forma directa de identificar paquetes del análisis es asignarla mayor parte de un cierto número de casos de uso a un paquete enconcreto.

Entre las asignaciones adecuadas de casos de uso a un paquete enconcreto 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 actordel 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 actordeben tener contenidos estrechamente relacionados.

c) Los casos de uso que están relacionados mediante relaciones degeneralización deben pertenecer al mismo paquete.

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




3


d) Los casos de uso relacionados mediante relaciones de extensión ysolo se extienden a partir de un caso de uso base deben perteneceral 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 lamayor parte de veces. Si los casos de uso base, que incluyen al casode uso, son funcionalidades con distintos contenidos; entonces, sedebe crear un paquete para el caso de uso incluido.

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 independientesy débilmente acoplados pero que posean una cohesión interna alta. Esinteligente intentar reducir el número de relaciones entre clases enpaquetes diferentes debido a que ello reduce las dependencias entre

paquetes.

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

==in4ude>>




32


Los paquetes identificados se organizarán en la “Capa de Aplicación”, lacual 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 casosde uso estructurado. Esto es con el fin de ubicar las relaciones queexisten entre los casos de uso. Las dependencias se crean a partir de lospaquetes de análisis que contienen los casos de uso base.

A continuación se muestra un ejemplo de distribución de paquetes en lascapas de la aplicación y sus dependencias para definir la arquitectura deaná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 porcada caso de uso.

• La mayoría de las clases se identificarán al crear las realizaciones decaso de uso (en la actividad del análisis de caso de uso).

• Tener cuidado de no identificar demasiadas clases en esta etapa yquedar atrapados en demasiados detalles.

Ejemplo:a) Reserva y Habitación Clases del dominio del problemab) DetalleReserva 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 especialescomunes de forma que los desarrolladores puedan referirse a elloscomo requisitos especiales sobre realizaciones de CU y clases delanálisis determinadas.




33


• Limitaciones o restricciones sobre persistencia, distribución yconcurrencia, características de seguridad, tolerancia de fallos y gestiónde 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 requisitoespecial común. Por ejemplo, las características de un requisito depersistencia 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 laArquitectura de Análisis para el proceso Venta de Repuestos, a partir del siguienteDiagrama de Caso de Uso Estructurado del caso “Sistema de Ventas y Control de

Almacén” de CIMAQ S.A.





Diagrama de caso de uso del proceso - Venta de Repuestos





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 eldiagrama 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 alpaquete Cliente y otro al paquete Repuesto.




36


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 Modelode Diseño.

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

Los paquetes se usan para organizar el modelo de análisis en piezas másmanejables, que representan abstracciones o subsistemas y una primera vista deldiseñ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, lacual 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).


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




37


ANÁLISIS DE CASOS DE USO


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 mediantediagramas de clases y diagramas de comunicación respectivamente, haciendo uso dela herramienta CASE IBM Rational Software Architect.

TEMARIO

1. Análisis de casos de uso2. Realizaciones de análisis de casos de uso.


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

UNIDAD DE

APRENDIZAJE

2TEMA

!




3!


1. ANÁLISIS DE CASOS DE USOEl Análisis de caso de uso permite examinar los casos de uso para descubrir losobjetos y clases de análisis del sistema a desarrollar. Las clases identificadasdeben agruparse en los paquetes de análisis.

El rol responsable de esta actividad es el Diseñador. Esta tarea describe cómodesarrollar las Realizaciones de los Casos de Uso a nivel de análisis de un caso deuso. 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.

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 usoUna realización de análisis (RA) de un caso de uso describe cómo uncaso de uso en particular es primero modelado dentro del análisis ydespués dentro del diseño, en términos de objetos colaboradores.

En una RA se especifica qué clases deben ser construidas paraimplementar cada caso de uso. En UML, las RA se representan concolaboraciones estereotipadas (elipse con líneas punteadas).

Figura 8.2. Colaboración

Análisisde Casosde Uso




3"


1.1.2. Encontrar clases de análisis

Este paso se realiza por cada caso de uso. Para ello, se analizan losescenarios del caso de uso para identificar las clases que participan enellos.

Figura 8.3. Un flujo completo de un caso de uso debe distribuirseen clases de análisis.

En la figura 3, a partir de una especificación de caso de uso se puedenobtener las clases de análisis. Existen tres tipos de clases de análisis:interfaz (boundary), control (control ) y entidad (entity). A continuaciónse describe a cada una de ellas:

• Interfaz. Describe la interacción del sistema con los usuarios y/uotros sistemas externos. Pueden representar abstracciones deformularios, de protocolos de comunicaciones o interfaces deprogramación de aplicaciones (API).

A continuación se presentan las características importantes de estetipo de clase cuando modela un API con otro sistema.a) Las funciones que provee el otro sistemab) La información a ser pasada al otro sistemac) El “protocolo” de comunicación usado para “hablar” con el otro

sistema.Por regla general, al menos una clase interfaz sirve como medio decomunicación entre los un actor y el correspondiente caso de uso.

Ejemplo:

En el caso de uso “Procesar Cierre ” hay información que debe serenviada a un Sistema de Facturación externo. Se puede crear unaclase de interfaz llamada CI_SistemaFacturacion para representarla interfaz al sistema externo.

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




4#


algún fenómeno o concepto, como una persona, un objeto delmundo real o un suceso del mundo real.

El número de clases entidad variará dependiendo de los conceptosque requieren almacenamiento persistente dentro del caso de uso.Estas clases sufren un proceso de refinamiento a medida que seubica a la misma clase entidad dentro de distintas realizaciones decaso de uso.

Ejemplo:

En el caso de uso “Mantener empleados ”, en el cual se puederegistrar, modificar o desactivar empleados, es evidente que lainformació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, queno pueden asociarse a ninguna información concreta de largaduración almacenada por el sistema.

Por regla general se trata de encapsular la lógica de control de uncaso de uso dentro de una clase Control. Suele ser un buen hábitode diseño utilizar únicamente una clase control por cada caso deuso, y así encapsular en un sólo elemento la lógica del caso de usocorrespondiente. Por otro lado, todos los casos de uso ubicados enun mismo paquete de análisis comparten la misma clase control.

Ejemplo:

En un paquete de análisis denominado Evaluación se ubica loscasos de uso “Evaluar empleado ”, “Procesar evaluación dedesempeño ” y “Consultar estadísticas de Evaluaciones ”. Para lostres casos de uso se crea una clase control CC_Evaluacion quecoordina el trabajo de los tres.

Según la metodología OOSE de Ivan Jacobson, las clases de análisisson 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.




4


Cada clase de análisis debe tener un estereotipo1, como mecanismoque el UML provee para extender la notación. Los estereotipos semuestran en el compartimiento del nombre de la clase encerrado entre<<>> (guillemets) o con un icono; también se pueden representar conla forma de la imagen del icono en lugar de una clase. Estasrepresentaciones 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 relacionespara 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 queextiende la semántica del meta modelo, basados en tipos existentes o clases del meta modelo.




42


1.1.4 Crear diagramas de comunicación

Este paso se realiza para describir la secuencia de acciones dentro delcaso de uso. El diagrama de comunicación es un tipo de diagrama deinteracción; en esta etapa, no se usa diagramas de secuencia porqueno es importante la cronología de las interacciones.

La realización de un caso de uso puede tener uno o más diagramas decomunicación, esto es debido a que se representa el flujo básico, sub-flujos y flujos alternativos.

FFigura 8.7. Diagrama de comunicación




43


2. REALIZACIONES DE ANÁLISIS: CASO PRÁCTICO

A continuación se presentan las siguientes especificaciones de casos de uso delSistema de Ventas y Control de Almacén, para identificar las clases de análisis yrealizar los diagramas de clases y diagrama de comunicaciones.

A. ESPECIFICACIÓN DE CASO DE USO: Buscar Repuesto

1. Breve descripciónEl caso de uso permite al Actor buscar un repuesto por descripción. Cuando seencuentra el repuesto el sistema cargará los datos del repuesto en el caso usobase que lo invocó.

2. ActoresUsuario (RVRS, Cliente y ACR)

3. Flujo de eventos3.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 elcriterio 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álidoSi el criterio de búsqueda en el campo descripción es nulo o inválido, elsistema muestra el MSG “Criterio de búsqueda nulo o inválido” y retornaal paso 3.

6.1. Repuesto no encontradoSi el sistema no encuentra ningún repuesto con el criterio ingresado, elsistema muestra el MSG “No se encontraron repuestos para el criteriode búsqueda ingresado” y retorna al paso 3 o el Usuario selecciona laopción “Salir” y finaliza el caso de uso.

11.1. Selección obligatoriaSi el Usuario no selecciona ningún repuesto, el sistema muestra el MSG“Seleccione un repuesto obligatoriamente” y retorna al paso 10.

4. Precondiciones1. El RVRS y el ACR deben estar registrados y logueados en el sistema.




44


2. Lista disponible de repuestos.5. Postcondiciones

Ninguno.6. Requerimientos especiales

Ninguno.7. Puntos de extensión

Ninguno.8. Prototipo

a) Diagrama de Clases





b) Diagrama de Comunicación





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

1. Breve descripciónEl caso de uso permite al Cliente realizar un pedido de venta de repuestos en líneaaccediendo a la página Web de CIMAQ S.A. La empresa le enviará una cotizaciónpara su aprobación.

2. ActoresCliente


1. El caso de uso inicia cuando el Cliente ingresa a la página web de CIMAQS.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 decontacto 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 Repuesto1. 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.




47


3.2.2. Ingresar Información de Pago1. 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 Pedido1. Si el cliente selecciona cancelar, antes de registrar el pedido2. 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 Alternativos13.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 aeliminar” y el caso de uso continúa en el paso 13 del flujo básico.

17.1. Datos de pedido inválidosEl sistema muestra el MSG: “Datos del pedido nulos o inválidos” y el casode uso continúa en el paso 14 del flujo básico.

19.1. Error al grabar pedidoSi el sistema no puede grabar el pedido el sistema muestra el MSG “Erroral grabar pedido” y el caso de uso continúa en el paso 16 del flujo básico.

Error al imprimirSi el sistema no puede imprimir el sistema muestra el MSG: “Error al imprimirdocumento” y el caso de uso continúa en el paso 4 del sub flujo “Información de

Pago”.4. Precondiciones4.1. El Cliente debe estar logeado en el sistema.

5. Postcondiciones5.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 especiales6.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ónNinguno.




4!


8. Prototipo

a) Realización de Análisis





b) Diagrama de clases





c) Diagrama de Comunicación





ACTIVIDADES PROPUESTAS1. A partir de la especificación de caso de uso realice los siguientes diagramas:

a) Diagrama de clases de análisisb) Diagrama de comunicación del flujo básicoc) 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ónEl caso de uso permite al Cliente en el cajero automático (ATM) cancelar un pagocorrespondiente a un tributo de RENIEC.

2. ActorCliente.


1. El caso de uso se inicia cuando el cliente del Banco elige la opción "RENIEC" en elmenú 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 datospresione 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 deTributo-Cta Ahorros MN)

• Título del Servicio (Sistema Electoral – RENIEC)



52


• Campos del cuerpo del voucher : código del tributo, nombre del tributo, tipo dedocumento, número de documento y monto pagado.

• Pie del voucher : secuencia de ATM, dígito de Chequeo, fecha, código decajero, 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 AlternativosTransacción inválidaEn los puntos 10 y 11 del flujo básico, si el sistema registra un error al ejecutar latransacción, muestra el mensaje “Disculpe, en estos momentos no es posibleprocesar su operación” y el caso de uso termina.

4. Precondiciones1. 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 condiciones1. 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 lacuenta.

3. En el sistema el saldo final de la cuenta del cliente será disminuido en base alsaldo inicial menos el monto del tributo pagado y los impuestos y comisionesafectos 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.





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

Especificación de Caso de Uso: Cotizar Productos1. 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, elvendedor le cambiará el estado y la enviará vía fax firmada. Con este documentose procederá a generar las notas de pedido y facturación.

2. ActoresVendedor.


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 depago.

• Además se tiene las opciones: “Buscar Cliente”, “Buscar Productos”,“Grabar Cotización”, “Registrar Nuevo Cliente”, “Generar N. Pedido yFacturació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 oal crédito).

14. El sistema calcula y muestra el precio de venta neto (PVN) y el precio deventa 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 elmensaje “Cotización No. 9999999 grabada correctamente”.

18. El Vendedor solicita “Salir”, el sistema cierra la interfaz y el caso de usotermina.

3.2. Flujos Alternativos5.1. Cliente no existe



54


Si el sistema no retorna con datos del cliente, mostrará el mensaje “Cliente noencontrado” y ofrecerá la posibilidad de registrar al nuevo cliente.

8.1. Productos no existenSi el sistema no encuentra el (los) producto(s), enviará el mensaje “Producto noencontrado” y el caso de uso finaliza.

17.1. Cotización no registradaSi 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 Especiales1. Aprovisionamiento de papel para emitir la cotización.

5. Precondiciones1. 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”, enespera de cambio a estado “Aceptada”.

7. Puntos de extensión

1. En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujobá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





R$%&'$

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

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


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



56


ANÁLISIS DE CLASES


Al finalizar la segunda unidad, el alumno modula la arquitectura de análisis que dasoporte a un proceso de negocio, y diagrama la estructura y el comportamiento de sus

funcionalidades mediante diagramas de clases y diagramas de comunicaciónrespectivamente, haciendo uso de la herramienta CASE IBM Rational SoftwareArchitect.

TEMARIO

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


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

UNIDAD DE

APRENDIZAJE

2TEMA

"





1. ANÁLISIS DE CLASESEl objetivo de esta actividad es describir cada una de las clases que se hanidentificado en el análisis de cada uno de los casos de uso, identificando susresponsabilidades que tienen asociadas, sus atributos, y las relaciones entreellas.

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 atributosrelevantes de una clase de análisis.

Las responsabilidades definen la funcionalidad de una clase, y están basadasen los papeles que desempeñan sus objetos en los diferentes casos de uso. Apartir de estas responsabilidades, se encontrarán las operaciones de la claseen el diseño.

Los atributos de una clase especifican las propiedades de la clase, y seidentifican por estar implicados en sus responsabilidades. Los tipos deatributos deberían ser conceptuales y conocidos en el dominio.

De manera opcional, se elabora una especificación para cada clase, queincluye la lista de sus operaciones y las clases que colaboran para cubrir esasoperaciones y una descripción de las responsabilidades, atributos yoperaciones de esa clase.

Para aquellas clases, cuyo comportamiento dependan del estado en el que seencuentren, se realiza, también, de manera opcional, un diagrama detransición de estados.

1.1.2. Identificar las asociaciones y agregaciones

En esta tarea, se estudian los mensajes establecidos entre los objetos deldiagrama de comunicación para determinar qué asociaciones existen entre lasclases correspondientes. Estas asociaciones suelen corresponderse con

expresiones verbales incluidas en las especificaciones.

Las relaciones surgen como respuesta a las demandas en los distintos casosde uso, y, para ello, puede existir la necesidad de definir agregaciones yherencia 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 loscasos de uso.



5!


1.1.3. Identificar las generalizaciones

El objetivo de esta tarea es representar una organización de las clases quepermita una implementación sencilla de la herencia y una agrupaciónsemántica de las diferentes clases.

2. Tarjetas CRCEs 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 figuraNo. 5.1. En el compartimiento superior izquierdo se escribe el nombre de laclase a analizar; en el compartimiento inferior izquierdo, lasresponsabilidades; y en el derecho, las colaboradores.

Figura 9.1. Tarjeta de Clase – Responsabilidad - Colaboración (CRC)

Las responsabilidades de una clase pueden recopilarse combinando todoslos 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 (flujosbásico y alternativos), un mensaje refleja el propósito del objeto invocante enla interacción con el objeto invocado. Este propósito es el origen de unaresponsabilidad del objeto receptor y podría llegar hacer el nombre de unaresponsabilidad.

Las colaboradoras son otras clases que apoyan con esta clase para realizaruna parte de la funcionalidad del sistema.

Uno de los principales beneficios de las tarjetas de CRC es saber cómo van aimplementar 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 lasclases como simples repositorios de datos, y ayuda a que el equipo se centreen 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 paraempezar el diseño, tienen limitaciones inherentes. El primer problema es queno tienen un escalamiento exitoso. En un proyecto muy complejo, puedeagobiarse con las tarjetas CRC; el simple hecho de mantener un registro de

todas ellas puede ser difícil.



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


El problema se torna más difícil aun al tratar de mantener sincronizados entresí, a las tarjetas y los modelos de UML de las clases.

En resumen, las tarjetas CRC son un buen inicio por mantener documentadaslas clases de análisis, pues a partir de ellas se tendrá una visión general delcomportamiento de una clase con respecto de otras, pero una vez que setenga conocimiento de las clases y lleguen a su etapa de diseño, estastarjetas ya no les será útil y quizá ya no necesitará actualizarlas.

3. Caso PrácticoA continuación, se explicará cómo confeccionar las tarjetas CRC para las clasesparticipantes del caso de uso “Registrar Pedido On – Line”, a partir del diagrama decomunicación.

ESPECIFICACIÓN DE CASO DE USO: Registrar Pedido On Line1. 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 unacotización para su aprobación.2. Actores

Cliente3. Flujo de eventos3.1. Flujo Básico

1. El caso de uso inicia cuando el Cliente ingresa a la página web de CIMAQS.A.


campos:• Datos del Pedido: Número del Pedido (no habilitado), Dirección de envió,

número, puerta, distrito, provincia, referencia, persona de contacto ytelé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),


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.



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 Flujos3.2.1. Eliminar Repuesto

1. El sistema elimina el(los) repuestos(s) seleccionado(s) de la lista derepuestos 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.


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 Pedido1. Si el cliente selecciona cancelar, antes de registrar el pedido2. 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 obligatoriaSi el cliente no selecciona ningún repuesto y solicita “Eliminar Repuesto”,el sistema muestra el MSG: “Seleccione por lo menos un repuesto aeliminar” y el caso de uso continúa en el paso 13 del flujo básico.

17.1. Datos de pedido inválidosEl sistema muestra el MSG: “Datos del pedido nulos o inválidos” y el casode uso continúa en el paso 14 del flujo básico.


Error al imprimirSi 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 dePago”.

4. Precondiciones4.1. El Cliente debe estar logeado en el sistema.








Diagrama de Comunicación





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. Primeroempezaremos con los boundary, luego con la clase control y al final con los entity.

Nombre de Clase: CI_Site

Responsabilidad Colaboradores1. Ingresa al Site. CC_Pedido

Nombre de Clase: CI_Home

Responsabilidad Colaboradores1. Muestra el Home2. Selecciona “Registrar Pedido”.

CC_Pedido

Nombre de Clase: CI_NuevoPedidoClienteResponsabilidad Colaboradores

1. Muestra interfaz2. Ingresa datos del pedido3. Selecciona “Buscar Repuesto”4. Muestra repuesto5. Ingresa cantidad6. Selecciona “Agregar repuesto”7. Solicita adicionar detalle8. Selecciona repuesto9. Seleccionar “Eliminar”10. Selecciona forma de pago11. Solicita registrar Pedido12. Muestra MSG.

CC_Pedido

Nombre de Clase: CC_Pedido

Responsabilidad Colaboradores2. Invoca al home3. Invoca interfaz4. Calcula subtotal5. Calcula total6. Valida pedido.

CI_SiteCI_HomeCI_Nuevo_Pedido_ClientePedidoDetalle_Pedido.

Nombre de Clase: Pedido

Responsabilidad Colaboradores1. Genera código2. Graba pedido.

CC_Pedido





Nombre de Clase: DetallePedido

Responsabilidad Colaboradores1. Graba detalle. CC_Pedido

Nombre de Clase: InformaciónDePago

Responsabilidad Colaboradores1. Graba información de pago. CC_Pedido



64


ACTIVIDADES PROPUESTASA 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, puedetambién actualizar sus datos, también, puede realizar giros a nivel nacional, registrarpagos de servicios de telefonía y solicitar tarjetas de crédito. El administrador decréditos evalúa las solicitudes previa verificación del cliente y él también se encarga deadministrar 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 deTelefonía con cargo en su Cuenta de Ahorros para cancelar sus recibospendientes.

3. ActorCliente.


1. El caso de uso comienza cuando el Cliente selecciona la opción Pago detelefoní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 servicio4. El cliente selecciona el servicio5. El cliente ingresa el número del servicio6. El cliente selecciona una de las cuentas para realizar el pago.7. El cliente selecciona Continuar8. 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 cuentaasociada para el pago, también se muestra el ingreso de clave, la opción

Aceptar y Cancelar9. El Cliente ingresa su clave10. 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 cancelado14. 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 efectuadocorrectamente”

15. El cliente selecciona “Terminar Sesión”, se cierra la interfaz y el caso de usofinaliza.

2.2. Flujos Alternativos

7.1. Numero de servicio no existeEl sistema muestra el MSG: “Numero de servicio no existe”.





5. Pre Condiciones1. 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



66






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 colaboradoresde 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 superiorizquierdo se escribe el nombre de la clase candidata; en el compartimiento inferiorizquierdo, 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.



6!


MODELO CONCEPTUAL


Al finalizar la segunda unidad, el alumno modula la arquitectura de análisis que dasoporte a un proceso de negocio, y diagrama la estructura y el comportamiento de sus

funcionalidades mediante diagramas de clases y diagramas de comunicaciónrespectivamente, haciendo uso de la herramienta CASE IBM Rational SoftwareArchitect.

TEMARIO

1. Modelo Conceptual.


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

UNIDAD DE

APRENDIZAJE

2TEMA

#





1. MODELO CONCEPTUALLas clases del modelo conceptual se obtienen a partir de los objetos deinformación (entidades) que fluyen entre las 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, estoes crucial para obtener casos de uso correctos, puesto que es necesarioentender bien el dominio para poder escribir casos de uso que seanrealmente útiles.

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

1.1. Importancia del Modelo ConceptualEl Modelo Conceptual Orientado a Objetos beneficiará a dos equipos detrabajo:• Equipo de Desarrolladores

En esta etapa del desarrollo, merece la pena detenerse en la identificaciónde los conceptos y no tanto en las relaciones entre ellos. Este modeloincluirá los conceptos y sus relaciones y se describirá mediante un diagramade clases UML, en el que los conceptos se representan mediante clases (deldominio).

• Equipo de Base de DatosEn esta etapa luego del modelo conceptual, se obtiene el proceso del

modelo lógico al diseño físico donde se podrá identificar las tablasrelacionales del proyecto de Base de Datos como componente RUP.

Definición de la1ra. Capa:A licación Realización de

los casos de uso:Diagramas deClases yDiagramas deComunicación

Modelo Conceptual

Modelo LógicoModelo Físico

Revisión de lospaquetes y suscontenidos





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 quereflejan las características de los objetos en el mundo real y losidentificadores 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 Atributoso Las clases poseen información descriptivas; los atributos, no.o Los atributos multivaluados deben ser clasificados como clases.o Identificar clases asociativas de una relación muchos-a-uno entre

dos clases.o Asociar atributos a las clases que los describen directamente. Los

atributos deben ser inherentes (propias) a la clase.o 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 elModelo 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 yreduzcan la duplicación de código fuente.



72


Figura 10.5. Jerarquía de clases

• Permiten gestionar la complejidad mediante un ordenamientológico.

• Se obtiene usando los mecanismos de abstracción deGeneralización y/o Especialización.

• La Generalización consiste en factorizar las propiedades comunesde 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, esdecir, los atributos y operaciones (y asociaciones) de la superclaseestán disponibles en sus subclases.

Figura 10.6. Notación de la generalización





Ejemplos:

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 yAgregació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 agregadoy cada uno de sus objetos componentes.

Figura 10.8. Agregaciones entre clases

a) Agregación CompartidaEs un tipo de relación utilizada para modelar la relación todo-parteentre objetos. La parte puede estar simultáneamente en variasinstancias del todo.

La agregación existe de preferencia entre conceptos no físicos.

Libro Video

AlumnoRecursoPrestamo

es solicitado por

Pago

Pago C reditoTarjetaCredito

se paga con

motor

coche

1

1

1

1



74


Ejemplo:

Figura 10.9. Agregación Compartida o Débil

b) Agregación CompuestaEs un tipo de relación utilizada para modelar la relación todo-parteentre objetos. Significa que la parte es miembro de solamente un

objeto todo, es decir, la existencia de la parte depende del todo. Lacomposición se representa con un diamante relleno.

El objeto todo es el único dueño del objeto parte.

Ejemplo:

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ónsignificativa e interesante.

• Está representada como una línea entre clases con nombre. Laasociación es inherentemente bidireccional.

• Es convencional leer la asociación de izquierda a derecha o de arribahacia abajo.

• Las asociaciones pueden ser binarias, ternarias o de mayor grado.• Criterios para identificar asociacioneso Enfocarse en aquellas asociaciones para las cuales el

conocimiento de la relación necesita ser conservado en el tiempo.

(Asociaciones que se necesitan saber).o Demasiadas asociaciones tienden a confundir.

PaqueteUML

ElementoUML

VentanroVentafechaname

LineaVentanroItemcant idadsubtota l

1. .*

11

1..*





o Evitar mostrar asociaciones redundantes o derivables.o Pueden existir múltiples asociaciones entre dos clases.

• Tipos de Asociaciones:o Asociación Binariao Asociación Ternariao Asociación Reflexiva.

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 sepueden implicar en una relación determinada en cualquier momentoen el tiempo.

• Define cuántas instancias de la clase A pueden estar asociadas conuna instancia de la clase B.

• En el siguiente ejemplo, se visualiza que en cualquier momento en eltiempo un objeto Ítem esta alojado por exactamente un objetoAlmacén. Sin embargo, con el tiempo un objeto Ítem podría estaralojado por una serie de objetos Almacén. Se puede resumir diciendoque un objeto Almacén aloja varios objetos de Ítem.

Cliente

Recepcionista

Orden Serviciogenera

registra



76


**

Item

1..*1..*

Item

1..40

Item1..40

55Item

3,5,83,5,8Item

0..*0..* Item

0..10..1Item

Muchos

Uno o muchos

Cero o muchos

Cero o uno

1 a 40

Exactamente 5

3 – 5 ó 8

Figura 10.14. Análisis de multiplicidad

• La multiplicidad presenta las relaciones con valores de datos deacuerdo al detalle siguiente :

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.

Figura 10.16. Clase asociativa

Almacen Item*1

aloja

*1

Clientenombre

ContactoTelefonicot ipoContacto1. .*1..* 1 . .*1..*

t iene registrado

DetalleTelefoniconroTelefono





1.2.7. Definir Operaciones

Las operaciones son funciones o transformaciones que se aplican atodos los objetos de una clase particular. La operación puede ser unaacción ejecutada por el objeto o sobre el objeto. Esta tarea es opcionalen 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 NegocioLas reglas del negocio identificadas durante el análisis de los requisitosse continuarán refinando a lo largo de la elaboración del modeloconceptual.

Es importante que la documentación de cada regla del negocio seaejemplificada con una situación real.



7!


Caso PrácticoA 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 entidadidentificadas 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 Line1. Breve descripción

El caso de uso permite al Cliente realizar un pedido de venta de repuestos enlínea accediendo a la página Web de CIMAQ S.A. La empresa le enviara unacotización para su aprobación.

2. ActoresCliente


1. El caso de uso se inicia cuando el Cliente ingresa a la página web deCIMAQ S.A.


campos:• Datos del Pedido: Número del Pedido (no habilitado), Dirección de envío,

número, puerta, distrito, provincia, referencia, persona de contacto ytelé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),


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.





3.2. Sub Flujos3.2.1. Eliminar Repuesto

4. El sistema elimina el(los) repuestos(s) seleccionado(s) de la lista derepuestos 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.


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 pedido6. 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 Alternativos13.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 aeliminar” y el caso de uso continúa en el paso 13 del flujo básico.

17.1. Datos de pedido inválidosEl sistema muestra el MSG: “Datos del pedido nulos o inválidos” y el casode uso continua en el paso 14 del flujo básico.


Error al imprimirSi el sistema no puede imprimir, se muestra el MSG: “Error al imprimirdocumento” y el caso de uso continúa en el paso 4 del sub flujo “Información dePago”.

4. Precondiciones4.1. El Cliente debe estar logeado en el sistema.








Modelo conceptual (parcial)




!



1. A partir de la Especificación del Caso de Uso “Cotizar Productos”, confeccione elModelo 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.




!2


R$%&'$

En el modelo conceptual, las clases se obtienen a partir de los objetos deinformación que fluyen en los casos de uso. Nos gustaría subrayar, como unacaracterística importante de nuestro enfoque, que el modelado de los casos de usodel sistema y el modelado conceptual se realizan en paralelo, esto es crucial paraobtener casos de uso correctos, puesto que es necesario entender bien el dominiopara 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 delos conceptos y no tanto en las relaciones entre ellos. Este modelo incluirá losconceptos y sus relaciones y se describirá mediante un diagrama de clasesUML, 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 modelológico al diseño físico donde se podrá identificar las tablas relacionales delproyecto 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 lamultiplicidad.




!3


PLANTILLAS DE DOCUMENTOS DE LA GESTIÓN DE

REQUISITOS 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.

ANEO




!5


Glosario (GLS) Usado para capturar elvocabulario común

Glossary Item (TERM)

Especificación deRequerimientosSuplementarios

(SUP)

Describe los requisitos delsistema que no son fácilmentecapturados por los casos de

uso

SupplementaryRequirement (SUPL)

Plan de Gestión deRequisitos (PGR)

Describe los requisitos yestratégias específicas para lagestión y el desarrollo delproyecto

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 amedida que los crea]

3.3. Atributos

[Para cada tipo de requisito que ha identificado, defina una lista de atributosque se utilizarán y explique brevemente lo que significan.Usted puede describir los atributos y sus valores por cada tipo de requisito endiferentes secciones.A continuación, se describen cada uno de los a utilizar por cada tipo derequisito de su proyecto.]

3.4. Trazabilidad

[Para cada tipo de requisito que usted ha identificado, liste algunas reglasadicionales o directrices que se aplican a los enlaces de trazabilidad. Describalas limitaciones aplicables, tales como "todas las características aprobadasdeben rastrear a uno o más Casos de Uso o a uno o más RequisitosSuplementarios.”]

Tipo de Requisito Directrices NotasStakeholderRequest (STRQ)Feature (FEAT)

Use Case (UC)Glossary Item

Característica

Caso de Uso Requerimiento Suplementario

Necesidad del Stakeholder




!6


(TERM)SupplementaryRequirement(SUPL)

.

3.5. Informes / Medidas[Describa el contenido, formato y propósito de los informes y medidas derequisitos.Use las plantillas de la tabla para describir los informes que usted generausando RequisitePro’s Requirements Metrics tool. Para más información reviseRequisitePro online help]

Descripciones de la Vista:[Use esta sección para describir las vistas que has creado para tu proyecto]

Nombre de laVista de

Trazabilidad

Descripción Tipo deRequisito

Atributos Rango devalor del

atributoFEAT no trazadasde STRQ

FEAT, STRQ n/a No trazado

SUPL no trazadasde FEAT

SUPL, FEAT n/a No trazado

UC no trazadas deFEAT

UC, FEAT n/a No trazado

Todas los FEAT FEAT todo todo

FEAT trazadas deSTRQ

FEAT, STRQ n/a todo

Todos los TERM TERM todo todo

FEAT impactadospor cambios deSTRQ

FEAT, STRQ n/a Solosospechoso

SUPL impactadospor cambios deFEAT

SUPL, FEAT n/a Solosospechoso

UC impactados porcambios de FEAT

UC, FEAT n/a Solosospechoso

Todas las STRQ STRQ todo todo

Todos los SUPL SUPL todo todo

SUPL trazadas deFEAT

SUPL, FEAT n/a todo

Estudio de los UC UC nombre,brevedescripción

nombre,brevedescripción

UC trazadas deFEAT

UC, FEAT n/a todo




!7


Petición del Stakeholder

1. Introducción[Este documento describe las necesidades del o los stakeholder (s) de laorganizació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 <Una necesidad del stakeholder>

[Descripción de una característica software, ámbito y propiedades de la misma]

3.2 <Otra necesidad del stakeholder>

[Descripción de una característica software, ámbito y propiedades de la misma]




!!


Documento Visión1. 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 losatributos de las mismas, por ejemplo. También reflejar si el sistema que semodela está dividido en otros subsistemas o bien el propósito general de laempresa.]

1.2. Alcance

[Definición del alcance del presente documento, es decir, todo ámbito del querecoge características o detalles.]

1.3. Definiciones, Acrónimos, y Abreviaciones

[RUP: Son las siglas de Rational Unified Process. Se trata de una metodologíapara 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 lasnecesidades de los usuarios, es necesario identificar e involucrar a todos losparticipantes 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 elconjunto de participantes en el proyecto los representa adecuadamente. Estasección muestra un perfil de los participantes y de los usuarios involucrados en elproyecto, así como los problemas más importantes que éstos perciben paraenfocar la solución propuesta hacia ellos. No describe sus requisitos específicos yaque é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 deestos stakeholders.]

3.2. Resumen de Usuarios

[Hay varios usuarios con un interés en el desarrollo. Presente una lista deellos.]




"#


Glosario de Términos1. Introducción

[Este documento es usado para definir la terminología específica para el dominiodel problema, explicando términos que no pueden ser familiares para leer la

descripción de un caso de uso u otro documento del proyecto. Frecuentementeeste 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 ordenaen orden alfabético.]

2.1. <Un Término>

[La definición de un término es presentado aquí, para entender el concepto.]2.2. <Otro Término>

[La definición de otro término es presentado aquí, para entender el concepto.]




"


Especificación de Requisitos de Software

1. Introducción[La introducción de la Especificación de Requerimientos de Software debe serun resumen del documento completo. Debe incluir el propósito, ámbito,

definiciones, acrónimos, abreviaciones, referencias, y resumen ejecutivo de estedocumento]

1.1. Propósito[El propósito de este documento es capturar todos los requerimientos de softwaredel sistema, o un subconjunto del sistema.]

1.2. Ámbito[Párrafo obligatorio.]

[Una descripción del entorno afectado; qué proyectos se ven afectados oinfluenciados 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 laEspecificación de Requerimientos de Software. Esta información puede serentregada 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. Cadadocumento debe ser identificado por título, edición (si es aplicable), fecha, yeditorial. Especificar las fuentes de donde se pueden obtener estas referencias,esta información puede ser entregada como referencia a un apéndice o a otrodocumento.]

1.5. Resumen Ejecutivo[Párrafo NO obligatorio.]

[Esta subsección debe describir el resto del documento conteniendo y explicandocomo esta organizado.]

2. Descripción General

[Se considera en esta parte la descripción de los factores principales que afectanal espacio de la solución. Incluya aquellos ítems como perspectiva del producto,funciones del producto, características de usuario, limitaciones, supuestos ydependencias. No se incluye en esta sección la descripción de losrequerimientos.]

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ásrepresentativo del mismo. Esto incluye una lista de nombres y brevesdescripciones de los casos de uso, actores, diagramas aplicables y relaciones.

En caso de no existir modelo de caso de uso se deben referenciar todas lasdescripciones existentes de las funcionalidades, ya sean minutas de reunión,




"2


correos electrónicos, etc. Es necesario agregar esas descripciones en estasección y en la sección 1.4 Referencias del documento se necesitan mencionartodos los fuentes de los requerimientos.]

[Este punto se puede reemplazar con la plantilla Excel de Administración deRequerimientos haciendo referencia.]

2.2. Supuestos y Dependencias[Párrafo obligatorio.]

[Esta sección describe cualquier factibilidad técnica clave, disponibilidad decomponentes o subsistemas, u otros supuestos realizados en los cuales laviabilidad del software descrito en esta Especificación de Requerimientos deSoftware 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 pararealizar posibles cambios en los requerimientos. Este impacto se mide en lacantidad 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 losrequerimientos como también a los testeadores diseñar un plan de testingadecuado para poder verificar el cumplimiento de los mismos. Cuando se usa elmodelado 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 decasos de uso, la definición de especificaciones adicionales debe insertarsedirectamente aquí.]

3.1. Reportes de Casos de Uso[Párrafo obligatorio.]

[En modelado de casos de uso, ellos definen la mayoría de los requerimientosfuncionales del sistema y algunos requerimientos no funcionales. Para cada casode uso en el modelo superior, o subconjunto del mismo, refiérase o cierre elreporte de caso de uso en esta sección. Asegúrese de que cada requerimientoesta claramente etiquetado.]

[Para proyectos pequeños, de duración menor a un mes y un equipo de menos de3 personas, este párrafo se puede reemplazar con una referencia a documentoAnálisis Preliminar.]

3.2. Requerimientos Funcionales[Párrafo obligatorio.]

[En esta sección se deben describir todos los requerimientos funcionales en formadetallada, esta sección debe ser usada cuando las funcionalidades no sontransacciones de algún framework transaccional. La descripción debe sersuficientemente clara para permitir a los diseñadores hacer un diseño apropiado,los programadores entender funcionalidad y a los testeadores elaborar un plan detesting apropiado.]

[Este punto se puede reemplazar haciendo referencia a la plantilla Excel deAdministración de Requerimientos.]

3.3. Requerimientos no Funcionales[Párrafo obligatorio.]




"3


[En esta sección se describen los aspectos no funcionales, tales como tiempo derespuesta, estética de la aplicación, facilidad de navegación, etc.]


3.4. Requerimientos Técnicos[Párrafo obligatorio.]

[En esta sección se describen los requerimientos técnicos, tales como sistemaoperativo, plataforma de arquitectura, por ejemplo WebSphere, .NET, etc.]

[Este punto se puede reemplazar referenciando a la plantilla Excel deAdministración de Requerimientos.]

3.5. Requerimientos de Proceso[Párrafo obligatorio.]

[En esta sección se describen los requerimientos de proceso. Por ejemplo, paradesarrollo se necesita usar proceso de desarrollo en cascadas, RUP, XP, ITDA-

KP,… Este párrafo se puede relacionar con artefacto Configuración del Proceso ocon el Plan del Proyecto.]


4. Administración de Requerimientos[Párrafo obligatorio.]

[En esta sección se especifica cómo se realizará el seguimiento de losrequerimientos, y los documentos asociados a este seguimiento, así mismo, enesta sección, se describen cómo se realizarán los posibles cambios o nuevasmodificaciones existentes durante el proyecto. Esto normalmente se puede seguir

con la plantilla Excel de Administración de Requerimientos al cual se debereferenciar en esta sección.]




"4


Especificación de caso de uso: <Nombre del caso de uso>

1. Breve Descripción[Breve descripción en líneas generales de la funcionalidad del caso de uso, de losactores que intervienen y del entorno de invocación]

2. Actores[Indicar los actores que interactúan con el caso de uso]


[Detallar la secuencia de pasos entre el actor (es) y el sistema. Aquí se puedenhacer referencia a casos de uso incluidos. Además que pueden invocarse a lossubflujos.]1.2.

3.2. Sub Flujos<Un sub flujo>

[Detallar la secuencia de pasos entre el actor (es) y el sistema. Aquí se puedenhacer referencia a casos de uso incluidos. Además que pueden invocarse a lossubflujos.]

1. …<Otro sub flujo>[Descripción del sub flujo, bifurcación del flujo básico y también detallainteracción entre el actor y el sistema.]

3.3. Flujos Alternativos<Un flujo alternativo>[Descripción del flujo alternativo, en qué punto se puede producir, qué acciones serealizarán, mensajes, etc. Pueden generar casos de uso extendidos.]

<Otro flujo alternativo>[Descripción del flujo alternativo, en qué punto se puede producir, qué acciones serealizará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 deuso Las precondiciones se pueden eliminar si no son relevantes]<Una Precondición><Otra precondición>

5. Poscondiciones[Indica las condiciones a futuro, cómo quedará el sistema después que se ejecuteel caso de uso. Las poscondiciones se pueden eliminar si no son relevantes]<Una poscondición><Otra poscondición>

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. Laspuntos de extensión se pueden eliminar si no son relevantes]<Un punto de extensión><Otro punto de extensión>

8. Prototipos[Aquí se diseñan las pantallas, reportes, etc. que permitirá la interacción del actorcon el sistema y/o lo que se obtenga como resultado en pantallas o reportes.]




"5


Especificación de Requisitos Suplementarios

1. Introducción[La introducción debe proporcionar una visión general del documentoRequerimientos Suplementarios .

Los Requerimientos Suplementarios capturan los requerimientos del sistema queno 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 yrestricciones de diseño.]1.1. Propósito

[Esta sección debe indicar el propósito de los RequerimientosSuplementarios y la audiencia esperada para este documento.]

1.2. Alcance[Esta sección debe contener una breve descripción del alcance de losRequerimientos Suplementarios y todo lo que es afectado o influenciado poreste documento.]

1.3. Definiciones, siglas y abreviaturas.[Esta sección debe proporcionar las definiciones de todos los términos, lassiglas y abreviaciones requeridas para interpretar apropiadamente eldocumento Requerimientos Suplementarios . Esta información puedeproporcionarse por la referencia al Glosario del proyecto.]

1.4. Referencias[Esta sección debe proporcionar una lista completa de todos los documentos alos que se hace referencia en el documento Requerimientos

Suplementarios . Cada documento debe identificarse por el título, número delinforme (si se aplica), fecha, y organización que lo publica. Especifique lasfuentes de las que pueden obtenerse las referencias. Esta información puedeproporcionarse 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 RequerimientosSuplementarios y explica cómo se organiza este documento.]

2. Funcionalidad[Esta sección describe los requerimientos funcionales del sistema que se expresanen lenguaje natural. Generalmente, se organiza por funcionalidad pero se puedeorganizar alternativamente por usuario, por subsistema. Los requisitos funcionalespueden 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 yespecializados para ser productivos en determinadas funciones.• especificar tiempos mensurables para tareas típicas.• especificar requerimientos para cumplir con los estándares comunes deusabilidad.]3.1. [Requerimiento de usabilidad 1]

[Descripción del requerimiento]




"6


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 errorespor punto funcional.

• Errores o porcentaje de defecto: categorizados en términos de erroresmenores, significantes y críticos (se debe definir qué significa error “crítico”,por ejemplo, pérdida completa de dato o imposibilidad de uso de ciertasfuncionalidades 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 delsistema. Incluye tiempos de respuesta específicos. Si se aplica, haga referencia alCaso de Uso relacionado por su nombre. Un ejemplo de contenido de esta secciónserí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 delsistema que está siendo construido, incluyendo normas de codificación,convenciones de nombres, librerías, acceso para mantenimiento, utilidades demantenimiento si las hay.

Como requerimiento que ayuda al mantenimiento se debe hacer referencia al uso denomenclatura común para el desarrollo del sistema, y a la metodología de desarrolloen lo que refiere a organización de Bases de Conocimiento y cómo se nombranorganizan y denominan los objetos en cada Base de Conocimiento. Adjunte o hagareferencia 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 compatibilidado interoperabilidad o interfases estándares.]

8. Requerimientos de Autorización (licenciamiento)

[Define requerimientos de autorización o restricción de uso que debe tener elsoftware.]




"7


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




"!


*+,%-./,

AbstracciónCaracterísticas esenciales de una entidad que la distingue de otros tipos de entidades.Define una frontera desde la perspectiva del observador.

APIUna API representa una interfaz de comunicación entre componentes de software. Setrata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertosservicios desde los procesos y representa un método para conseguir abstracción en laprogramación, generalmente (aunque no necesariamente) entre los niveles o capas

inferiores y los superiores del software.

ArtefactoPieza discreta de información que es utilizada o producida por un proceso dedesarrollo de software.

AspectoMódulo software que no puede ser encapsulado en un procedimiento. Los aspectos noson unidades funcionales en las que se pueda dividir un sistema, sino propiedadesque afectan a la ejecución o semántica de los componentes. Son conocidos tambiéncomo intereses transversales.

ElementoConstituyente atómico de un modelo.

EspecificaciónDescripción textual de la sintaxis y la semántica de un bloque de construcciónespecífico; descripción declarativa de lo que algo es o hace.

EstereotipoExtensión del vocabulario de UML que permite crear nuevos bloques de construcciónderivados a partir de los existentes pero específicos a un problema concreto.

Gestión de RequisitosActividad para gestionar los cambios en los requisitos del sistema. La gestión implicael control de cambios y el impacto de los cambios.

Ingeniería de RequisitosEs 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 SoftwareRama de la ingeniería que aplica los principios de la ciencia de la computación y lasmatemáticas para lograr soluciones costo-efectivas a los proyectos de desarrollo omantenimiento de software de calidad.




""

NotaciónSistema de signos convencionales que se adoptan para expresar un conjunto deconceptos sobre el sistema de software por desarrollar.

OMG Object Management GroupConsorcio del cual forman parte las empresas más importantes que se dedican aldesarrollo de software.

RefinamientoRelación que representa una especificación más completa de algo que ya ha sidoespecificado a cierto nivel de detalle.

RequisitoCaracterística, propiedad o comportamiento deseado de un sistema.

RUP Rational Unified ProcessProceso Unificado de Rational, metodología del proceso de ingeniería de software que

proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro deuna organización del desarrollo.

ManualTeoria calidad de software

Documents

Transcript of ManualTeoria calidad de software