UNIVERSIDAD TECNOLÓGICA DE JALISCO

Transcripción

1 UNIVERSIDAD TECNOLÓGICA DE JALISCO Creación Periodo: Mayo - Agosto 2013 Adecuaciones Periodo: Por: M.C. Felipe Belmont Polanco M.C.Felipe Belmont Polanco. Pág. 1

2 Temario I.- Introducción a la ingeniería de software. II.- Ingeniería de requerimientos. III.- Diagramas UML IV.- Modelos de proceso. V.- Pruebas y aseguramiento de calidad. Evaluación Criterios / Cortes I II III Examen teórico % % Tareas / Avances. 50 % 60 % % Proyecto % Cero faltas/cumplir reglamento. 10 % 10 % 10 % M.C.Felipe Belmont Polanco. Pág. 2

3 Introducción a la ingeniería de software La noción de ingeniería del software fue propuesta inicialmente en 1968 en una conferencia para discutir lo que en ese entonces se llamó la crisis del software. Esta crisis del software fuel el resultado de la introducción de las nuevas computadoras de circuitos integrados y la combinación del resultado de software de magnitud más grande y más complejo que los sistemas previos. La construcción de los sistemas mostró que se utilizaba un enfoque informal para el desarrollo de software, por lo que los grandes proyectos a menudo tenían años de retraso y costaban mucho más de lo presupuestado, eran irrealizables, difíciles de mantener y con un desempeño pobre. El desarrollo de software estaba en crisis. Se necesitaban nuevas técnicas y métodos para controlar la complejidad inherente a los sistemas grandes. Estas técnicas han llegado a ser parte de la ingeniería del software y son ampliamente utilizadas. Las nuevas tecnologías resultantes de la convergencia de las computadoras y de los sistemas de comunicación y complejas interfaces gráficas de usuario impusieron nuevas demandas a los ingenieros de software. Se han desarrollado métodos efectivos de especificación, diseño e implementación del software, junto con notaciones y herramientas que reducen el esfuerzo requerido para producir sistemas grandes y complejos. Por lo que se sabe que no hay un enfoque ideal en la ingeniería de software sino que se utilizan diversos enfoques, pero las nociones fundamentales de procesos y la organización del sistema son la base de todas estas técnicas. Software El software es el término utilizado para asignar a los programas de computadora y a su documentación asociada que explica cómo utilizar el sistema. Se pueden clasificar de forma general dos tipos de productos de software. Productos genéricos. Son sistemas producidos para cualquier cliente que le sea posible comprarlos, y los requerimientos son controlados por la organización desarrolladora. Productos personalizados (hechos a la medida). Son sistemas requeridos por un cliente particular, y un contratista de software lo desarrolla, en este caso el cliente controlan sus requerimientos. M.C.Felipe Belmont Polanco. Pág. 3

4 Cada vez más compañías de software empiezan con un sistema genérico y lo adaptan a las necesidades de un cliente en particular. Los sistemas de planificación de recursos empresariales (ERP- Enterprise Resource Planning), como los sistemas denominados Sistemas, Aplicaciones y Productos en Procesamiento de datos (SAP- Systems, Applications, Products in Data Processing), son el mejor ejemplo de este enfoque. Aquí, un sistema complejo se adapta a una compañía. Ingeniería del software La ingeniería del software es una disciplina de la ingeniería, donde se aplican teorías, métodos y herramientas, e involucra procesos inherentes a la producción de software, tales como la gestión de proyectos, en el que se adoptan enfoques sistemáticos y organizados para la producción de software de calidad. Proceso del software Un proceso del software es un conjunto de actividades y resultados asociados a la producción de software, existen cuatro actividades fundamentales de procesos que son comunes para todos los desarrollos de software. 1.- Especificación del software: donde los clientes e ingenieros definen el software a producir y las restricciones de su operación. 2.- Desarrollo del software: donde el software se diseña y programa. 3.- Validación del software: donde el software se asegurar que es lo que el cliente requiere. 4.- Evolución del software: donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado. M.C.Felipe Belmont Polanco. Pág. 4

5 Atributos de un buen software El software tiene ciertos atributos asociados que reflejan su calidad. Estos atributos no están directamente asociados con los procesos y resultados que se obtienen del software. Más bien, reflejan en su comportamiento e interacción de manera externa en cuanto a su organización del programa y su documentación asociada. Ejemplos de estos atributos (algunas veces llamados atributos no funcionales) son el tiempo de respuesta del software a una pregunta del usuario, en un sistema bancario debe ser seguro, un juego interactivo debe tener capacidad de respuesta rápida, un interruptor de un sistema telefónico debe ser fiable. Mantenibilidad Confiabilidad Eficiencia Usabilidad El software debe escribirse de tal forma que pueda evolucionar para cumplir las necesidades de cambio de los dientes. Éste es un atributo critico debido a que el cambio en el software es una consecuencia inevitable de un cambio en d entorno de negocios. La confiabilidad del software tiene un gran número de características, incluyendo la fiabilidad, protección y seguridad. El software confiable no debe causar daños físicos o económicos en el caso dé una faya del sistema. El software no debe hacer que se malgasten los recursos del sistema, como la memoria y los tiempos de procesamiento. Por lo tanto, la eficiencia incluye tiempos de respuesta. El software debe ser fácil de utilizar, sin esfuerzo adicional, el usuario para quien está diseñado. Esto significa que debe tener una interfaz de usuario apropiada y una documentación adecuada. Modelos del proceso de software Un modelo del proceso del software es una representación abstracta de un proceso que se pueden utilizar para explicar diferentes enfoques para el desarrollo de software, también llamados paradigmas de proceso, y puede pensarse en ellos como marcos de trabajo que pueden ser extendidos y adaptados para crear procesos más específicos de ingeniería del software (Sommerville). M.C.Felipe Belmont Polanco. Pág. 5

6 Modelos clásicos Los modelos de procesos dependen de las opiniones o creencias de las personas involucradas en un proyecto. El modelo en cascada Se origino entre la década de los 60 y 70, se define como una secuencia de actividades, donde la estrategia es seguir el progreso del desarrollo de software hacia puntos de revisión (milestones o checkpoints) mediante entregas calendarizadas (schedule), dicho modelo también se le conoce como ciclo de vida del software, por sus etapas. 1. Análisis y definición de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven como una especificación del sistema. 2. Diseño del sistema y del software. El proceso de diseño del sistema divide los requerimientos en hardware o software. Establece una arquitectura completa del sistema. 3. Implementación y prueba de unidades. Durante esta etapa, el diseño del software se lleva a cabo como un conjunto o unidades de programas. La prueba de unidades implica verificar que cada una cumpla su especificación. 4. Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. Después de las pruebas, el sistema software se entrega al cliente. 5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), ésta es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento, y se corrigen errores no descubiertos en las etapas anteriores del ciclo de vida. El modelo original planteaba que cada actividad debía completarse antes de poder continuar, sin embargo posteriormente el modelo permitió el regreso a actividades anteriores, como se muestra en la figura 1. M.C.Felipe Belmont Polanco. Pág. 6

7 Figura 1. Secuencia de actividades del modelo en cascada. El modelo evolutivo El desarrollo evolutivo se basa en la idea de desarrollar una implementación inicial, exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones hasta que se desarrolla un sistema adecuado. Las actividades de especificación, desarrollo y validación se entrelazan en vez de separarse, con una rápida retroalimentación entre éstas. El modelo evolutivo es también conocido como desarrollo rápido de aplicaciones (RAD, Rapid Application Development), que se basa en el uso de prototipos, lo que permite tener dos tipos de desarrollos evolutivos. 1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente. 2. Prototipos desechables, donde el objetivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden bien. En la producción de sistemas, un enfoque evolutivo para el desarrollo de software suele ser más efectivo que el enfoque en cascada, ya que satisface las necesidades inmediatas de los clientes. La ventaja de un proceso del software que se basa en un enfoque evolutivo es que la especificación se puede desarrollar de forma creciente como se muestra en la figura 2. M.C.Felipe Belmont Polanco. Pág. 7

8 Figura 2. Secuencia de versiones del modelo evolutivo. El modelo incremental En un proceso de desarrollo incremental, los clientes identifican, a grandes rasgos, los servicios que proporcionará el sistema. Identifican qué servicios son más importantes y cuáles menos. Una vez seleccionados los servicios de mayor importancia, se definen varios incrementos que dependen de la prioridad y la funcionalidad del sistema. La asignación de servicios a los incrementos depende de la prioridad, por lo que la más alta será entregada primero. Cuando los incrementos del sistema se han identificado, los requerimientos para los servicios que se van a entregar en el primer incremento se definen en detalle, y éste se desarrolla. Durante el desarrollo no se aceptan cambios en los requerimientos para el incremento actual. Se puede llevar a cabo un análisis adicional de requerimientos para los requerimientos posteriores. Una vez que un incremento se completa y entrega, los clientes pueden ponerlo en servicio. Esto significa que tienen una entrega temprana de parte de la funcionalidad del sistema. Pueden experimentar con el sistema, lo cual les ayuda a clarificar sus requerimientos para los incrementos posteriores y para las últimas versiones del incremento actual, como se muestra en la figura 3. Figura 3. Entrega incremental. M.C.Felipe Belmont Polanco. Pág. 8

9 En el modelo incremental aprovecha las ventajas de los enfoques en cascada y evolutivo, puesto que en el modelo de desarrollo en cascada se requiere que los clientes cumplan un conjunto de requerimientos antes de iniciar el diseño, y en el enfoque evolutivo permite que los requerimientos y el diseño se retrasen, pero también origina un software que puede estar débilmente estructurado y difícil de mantener. El modelo espiral El modelo en espiral es una extensión del modelo en cascada, originalmente propuesto por Boehm (Boehm, 1988). Más que representar el proceso como una secuencia de actividades, se representa como una espiral. Cada ciclo en la espiral representa una fase del proceso del software. El ciclo más interno podría referirse a la viabilidad del sistema, el siguiente ciclo a la definición de requerimientos, el siguiente al diseño del sistema, y así sucesivamente. Cada ciclo de la espiral se divide en cuatro sectores como se muestra en la figura Definición de objetivos. En esta fase del proyecto se definen los objetivos específicos. Se identifican las restricciones del proceso y el producto, y se traza un plan detallado de gestión. Se identifican los riesgos del proyecto. Dependiendo de estos riesgos, se planean estrategias alternativas. 2. Evaluación y reducción de riesgos. Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto identificados. Se definen los pasos para reducir dichos riesgo. Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se puede desarrollar un prototipo del sistema. 3. Desarrollo y validación. Después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema. Por ejemplo, si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si los riesgos de seguridad son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado, y así sucesivamente. El modelo en cascada puede ser el más apropiado para el desarrollo si el mayor riesgo identificado es la integración de los subsistemas. 4. Planificación. El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. M.C.Felipe Belmont Polanco. Pág. 9

10 La diferencia principal entre el modelo en espiral y los otros modelos del proceso del software es la consideración explícita del riesgo. Informalmente, el riesgo significa sencillamente algo que puede ir mal. Figura 4. Modelo espiral. Modelos recientes El modelo Ganar-ganar (win-win) Este modelo extiende el modelo espiral, donde se crea una estrecha relación cliente-desarrollador, donde ambos buscan lo más conveniente para todos, y de manera individual el cliente busca la satisfacción, reducción de costos, acortar los tiempos de entrega y mejoras del sistemas. En cada giro de esta espiral hay tres puntos claves. 1. Objetivo del ciclo de Vida (OCV). Se definen los objetivos a alcanzarse en cada segmento de la espiral. 2. Arquitectura del ciclo de Vida (ACV). Una vez definido los objetivos se establece la manera en cómo se actuará para llevarse a cabo cada uno de ellos. 3. La Capacidad operativa Inicial (COI). Una vez establecidos objetivos y la forma de atacar cada uno de ellos, se lleva la fase de aplicación y evaluación de resultados. M.C.Felipe Belmont Polanco. Pág. 10

11 Figura 5. Modelo Ganar-ganar (Win-win). El modelo programación extrema (XP) La programación extrema (XP, extreme Programming), es una variante del enfoque incremental. Ésta se basa en el desarrollo y la entrega de incrementos de funcionalidad muy pequeños, reduciendo el riesgo en el ciclo de vida del software, con la participación del cliente en el proceso, en la mejora constante del código como se muestra en la figura 6. XP considera que la mejor manera de tratar la falta de requisitos estables, es mediante la agilidad de un grupo pequeño de desarrollo, pero privilegia el desarrollo de software en pares (pair programming), se guía por sus valores. Simplicidad. Es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento, también se aplica en la documentación, de esta manera el código debe comentarse en su justa medida, para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Comunicación. Se realiza de diferentes formas, para los programadores en el código más simple para entender mejor en la programación por parejas, en las pruebas unitarias se describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad, y la comunicación fluida con el cliente ya que forma parte del equipo. El cliente decide qué características tienen prioridad. M.C.Felipe Belmont Polanco. Pág. 11

12 Retroalimentación (feedback). Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Coraje o valentía. Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar el resto del proyecto, así también es sentirse cómodos con reconstruir su código cuando sea necesario. Respeto. Los miembros respetan su trabajo y el de los demás, porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la reconstrucción del código. Figura 6. Modelo programación extrema. M.C.Felipe Belmont Polanco. Pág. 12

13 Ingeniería de requerimientos Para crear una aplicación de software hay que describir el problema y las necesidades o requerimientos, en qué consiste el conflicto y qué debe hacerse. Las definiciones de requerimientos del sistema especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables, desde la perspectiva de los clientes del sistema y de los usuarios finales. Los requerimientos son lo primero a desarrollar y es la base para construir el software, así que cualquier cambio en la funcionalidad del sistema, es más fácil de hacer y con menores consecuencias en este nivel que en posteriores niveles. La especificación del software o ingeniería de requerimientos es el proceso de comprensión y definición de qué servicios se requieren del sistema y de la identificación de las restricciones de funcionamiento y del desarrollo del mismo. Par cumplir con un correcto desarrollo se involucra el proceso del software considerando el análisis y el diseño de forma implícita. Análisis Para crear una aplicación de software hay que describir el problema y las necesidades o requerimientos. El análisis se centra en una investigación del problema, no en la manera de definir una solución. Procesos de negocios El primer paso consiste en analizar lo que debe hacer una empresa, sus procesos de negocios si quiere seguir funcionando esto es realizar ventas, pagar a empleados y acreedores, desarrollar programas de computación. Desde el punto de vista del método del análisis y el diseño, este paso se refiere al análisis de requerimientos, en el cual los procesos y las necesidades de los negocios se descubren y se expresan en forma de descripciones narrativas textuales de los procesos de una empresa o sistema. M.C.Felipe Belmont Polanco. Pág. 13

14 Diseño Para desarrollar una aplicación, también es necesario contar con descripciones detalladas y de alto nivel de la solución lógica y saber cómo satisface los requerimientos y las restricciones. En el diseño se propone una solución lógica, definiendo los objetos lógicos del software que finalmente serán implementados en un lenguaje de programación orientado a objetos. Requerimientos Los requerimientos para un sistema son la descripción de los servicios proporcionados por el sistema y sus restricciones operativas. El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se denomina ingeniería de requerimientos (RE). El término requerimiento no se utiliza de una forma constante en la industria de software. En algunos casos, es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste. Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación de los diferentes niveles de descripción. Requerimientos funcionales Son declaraciones de los servicios que debe proporcionar el sistema, los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etcétera. Requerimientos no funcionales Son aquellos requerimientos que no se refieren directamente a las funciones que proporciona el sistema, sino a las propiedades emergentes que definen las restricciones del sistema, estas propiedades emergentes pueden variar. Los asociados al producto, delimitan el rendimiento en la rapidez de ejecución del sistema y cuánta memoria se requiere. Los asociados a la organización, que se derivan de políticas y procedimientos de la organización del cliente y en la del desarrollador, como son los lenguajes de programación, y los mecanismos de entrega del producto y su documentación. Los externos, que se derivan de los factores de interoperabilidád con sistemas de otras organizaciones; los legislativos para asegurar que el sistema funcione dentro de la ley, y asegurar que será aceptado por sus usuarios y por el público en general. M.C.Felipe Belmont Polanco. Pág. 14

15 Obtención y análisis de requerimientos La obtención y análisis de requerimientos pueden afectar a varias personas de la organización. El término stakeholder (los interesados) se utiliza para referirse a cualquier persona o grupo que se verá afectado por el sistema, directa o indirectamente. Obtención de los requerimientos La obtención de los requerimientos se da en la relación con los stakeholders a través de entrevistas y de la observación (etnografía). En las entrevistas formales o informales con los stakeholders del sistema se usan, las entrevistas cerradas donde solo se responden a un conjunto predefinido de preguntas, mientras que las entrevistas abiertas, no hay un programa predefinido se examina una serie de cuestiones del sistema y se desarrolla una mejor comprensión de sus necesidades. La etnografía es una técnica de observación, que se utiliza para entender los requerimientos sociales y organizacionales, los sistemas de software no existen de forma aislada, se utilizan en un contexto social y organizacional, y los requerimientos se pueden derivar y restringir según ese contexto, una razón del por qué muchos sistemas nunca se utilizan es que no se tiene en cuenta adecuadamente la importancia social. La función es observar el trabajo diario y anotar las tareas reales en las que los participantes están involucrados. Análisis de los requerimientos En el análisis de requerimientos, los procesos y las necesidades del negocio se descubren y se expresan con descripciones narrativas textuales de las actividades de una empresa o sistema, y se deben revisar y validar. Una revisión de requerimientos es un proceso manual que involucra a personas tanto de la organización del cliente como de la del contratista, las revisiones de requerimientos pueden ser informales que implican que los contratistas revisen los requerimientos con tantos stakeholders como sea posible. En la revisión formal, el equipo de desarrollo explica las implicaciones de cada requerimiento a los clientes. La validación de requerimientos trata encontrar problemas con los requerimientos, y de mostrar que las definiciones del sistema coinciden con lo que el cliente desea. La validación de requerimientos es importante debido a que los errores en el documento de requerimientos pueden conducir a importantes costos al repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el sistema esté en uso. M.C.Felipe Belmont Polanco. Pág. 15

16 El documento de requerimientos El documento de requerimientos del software (algunas veces denominado especificación de requerimientos del software o SRS), es la declaración oficial de qué deben implementar los desarrolladores del sistema. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos funcionarios de la organización que pagan por el sistema, hasta los ingenieros responsables de desarrollar el software. El nivel de detalle que se debe incluir en un documento de requerimientos, depende del tipo de sistema que se desarrolle y del proceso de desarrollo utilizado. IEEE/ANSI 830 Varias organizaciones grandes, como el Departamento de Defensa de los Estados Unidos y el IEEE, han definido estándares para los documentos de requerimientos. El estándar más ampliamente conocido es el IEEE/ANSI (IEEE, 1998). Casos de uso Los casos de uso son una técnica de escenarios para la obtención de requerimientos, es basado en Objectory (Jacobson et al. 1992), actualmente ésta metodología es parte del proceso unificado de racional (RUP, Rational Unified Process). Los casos de uso identifican las interacciones particulares con el sistema. Pueden ser documentadas con texto o vinculadas a modelos UML (Unified Modeling Language, Lenguaje Unificado de Modelado), que desarrollan el escenario en más detalle. M.C.Felipe Belmont Polanco. Pág. 16

17 Diagramas UML El UML (Unified Modeling Language, Lenguaje Unificado de Modelado) es una herramienta que sirven como enlace entre quien tiene la idea y el desarrollador, ya que le ayuda a capturar la idea de un sistema para comunicarla posteriormente a quien esté involucrado en su proceso de desarrollo; esto se lleva a cabo mediante un conjunto de símbolos y diagramas. Cada diagrama tiene fines distintos dentro del proceso de desarrollo. UML es el sucesor de la ola de métodos de análisis y diseño orientado a objetos que aparecieron a finales de los 80 y principios de los 90, UML unifica principalmente los métodos de Booch, Rumbaught (OMT) y Jacobson. UML está en proceso de estandarización por el OMG (Object Management Group), UML es un lenguaje de modelado, no un método. El modelo UML El UML es un estándar para construir modelos orientados a objetos. Nació en 1994 por iniciativa de Grady Booch y Jim Rumbaugh para combinar sus dos famosos métodos: el de Booch y el OMT (Object Modeling Technique, Técnica de Modelado de Objetos). Más tarde se les unió Ivar Jacobson, creador del método OOSE (Object-Oriented Software Engineering, Ingeniería de Software Orientada a Objetos). En respuesta a una petición de OMG (Object Management Group, asociación para fijar los estándares de la industria) para definir un lenguaje y una notación estándar del lenguaje de construcción de modelos, en 1997 propusieron el UML como candidato. En esta sección no se incluye todos los detalles de UML, un conjunto relativamente amplio de notaciones. Se centra en los diagramas de uso frecuente y en las características que más se utilizan dentro de ellos. Existen diversos fabricantes que cuentan con paquetes que le permitirán generar diagramas UML y coordinarlos en un modelo. Los más notables son Rational Rose y SELECT Enterprise, a demás de Visual UML (en Visual Studio Ultimate), y otras herramientas disponibles como son ArgoUML, y BOUML. Un sistema del mundo real como en el mundo del software, suele ser extremadamente complejo; por ello es necesario dividir el sistema en partes o fragmentos si queremos entender y administrar su complejidad. Estas partes podemos representarlas como modelos que describan y abstraigan sus aspectos esenciales [Rumbaugh97]. M.C.Felipe Belmont Polanco. Pág. 17

18 Casos de uso Los procesos de la organización pertenecientes al sistema se pueden expresar en casos de uso, o sea, en una descripción narrativa de los procesos del dominio en un formato estructurado, con el siguiente formato. Caso de uso: Participantes: Descripción: Requerimientos y casos de uso Un proyecto no puede ser exitoso sin una especificación correcta y exhaustiva de los requerimientos. Para ello se presentará un caso de estudio que integra el documento de requerimientos que se integrará posterior mente con los casos de uso. Presentación general: Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizará en las ventas al menudeo. Clientes: Juguete Feliz, Inc., detallista multinacional de objetos. Metas: Una mayor automatización del pago en las cajas registradoras, servicios más rápidos, mejorar los procesos de negocios. En concreto: Pago rápido de los clientes, Análisis rápido y exacto de las ventas, y Control automático del inventario. Las funciones del sistema: son lo que éste habrá de hacer, por ejemplo autorizar los pagos a crédito. Hay que identificarlas y listarlas en grupos cohesivos y lógicos. Con el objeto de verificar que alguna acción es de verdad una función del sistema, la siguiente oración deberá tener sentido, El sistema deberá autorizar los pagos a crédito. Los atributos del sistema son cualidades no funcionales: entre ellas la facilidad de uso que a menudo se confunden con las funciones. Nótese que "facilidad de uso" no encaja en la oración de verificación, El sistema deberá la facilidad de uso. Las funciones han de clasificarse por categorías a fin de establecer prioridades entre ellas e identificarlas. M.C.Felipe Belmont Polanco. Pág. 18

19 Categoría de la función. Evidente. Oculta. Significado. Debe realizarse, y el usuario debería saber que se ha realizado. Debe realizarse, aunque no es visible para los usuarios. Esto se aplica a muchos servicios técnicos subyacentes, como guardar información en un mecanismo persistente de almacenamiento. Las funciones ocultas no se deberían omitir en la obtención de los requerimientos. Superflua. Opcionales; su inclusión no repercute significativamente en el costo ni en otras funciones. Para nuestro caso de estudio se muestran las siguientes a manera de ejemplo. Ref # Función. Categoría. R1.1 Registra la venta en proceso (actual): los productos Evidente. comprados. R1.2 Calcula el total de la venta actual; se incluyen el Evidente. impuesto y los cálculos de cupón. R1.3 Captura la información sobre el objeto comprado Evidente. usando su código de barras y un lector o usando una captura manual de un código del producto; por ejemplo, un código universal de producto (UPC). R1.4 Reduce las cantidades del inventario cuando se Oculta. realiza una venta. R1.5 Se registran las ventas efectuadas. Oculta. R1.6 El cajero debe introducir una identificación y una Evidente. contraseña para poder utilizar el sistema. R1.7 Ofrece un mecanismo de almacenamiento Oculta. persistente. R1.8 Muestra la descripción y el precio del producto Evidente. registrado. El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso, existen de alto nivel que muestra un proceso de forma general o los expandidos que muestran a detalle las actividades de un proceso se representa mediante un ovalo. Comprar productos M.C.Felipe Belmont Polanco. Pág. 19

20 El siguiente caso de uso de alto nivel describe clara y concisamente el proceso de comprar artículos en una tienda cuando se emplea una terminal en el punto de venta. Caso de uso: Comprar productos Actores: Cliente, Cajero. Tipo: Primario. Descripción: Un Cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos. Los encabezados y la estructura de este caso de uso son representativos. Sin embargo, el UML no especifica un formato rígido; puede modificarse para atender las necesidades y ajustarse al espíritu de la documentación: ante todo, una comunicación clara. Conviene comenzar con los casos de uso de alto nivel para lograr rápidamente entender los principales procesos globales. Un caso expandido de uso muestra más detalles que uno de alto nivel; este tipo de casos suelen ser útiles para alcanzar un conocimiento más profundo de los procesos y de los requerimientos. Caso de uso: Comprar productos en efectivo. Actores: Cliente (Iniciador). Cajero. Propósito: Capturar una venta y su pago en efectivo. Resumen: Un Cliente llega a la caja registradora con artículos que desea comprar. El Cajero registra los productos y recibe un pago en efectivo. Al terminar la operación, el Cliente se marcha con los productos comprados. Tipo: Primario y esencial. Referencias cruzadas: Funciones: Rl.l. R1.2. R1.3. R1.7, Rl.9, R2.1. Acción del actor 1. Este caso de uso comienza cuando un Cliente llega a una caja de TPDV (Terminal Punto de Venta) con pro ductos que desea comprar. 2. El Cajero registra el identificador de cada producto. Si hay varios productos de una misma categoría, el Cajero también puede introducir la cantidad. 4. Al terminar de introducir el producto, el Cajero indica a TPDV que se concluyó la captura del producto. 6. El Cajero le indica el total al Cliente. Curso normal de eventos Respuesta del sistema. 3. Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presentan la descripción y el precio del producto actual. 5. Calcula y presenta el total de la venta. M.C.Felipe Belmont Polanco. Pág. 20

21 Curso normal de eventos Acción del actor Respuesta del sistema. 7. El Cliente efectúa un pago en efectivo posiblemente mayor que el total de la venta. 8. El Cajero registra la cantidad de efectivo 9. Muestra al cliente la diferencia. Genera recibida. un recibo. 10. El Cajero deposita el efectivo recibido y 11. Registra la venta concluida. extrae el cambio del pago. El Cajero da al Cliente el cambio y el recibo impreso. 12. El Cliente se marcha con los artículos comprados. Cursos alternos Linea 2: introducción de identificador inválido. Indicar error. Línea 7: el cliente no tenía suficiente dinero. Cancelar la transacción de venta. La sección intermedia, curso normal de los eventos, es la parte medular del formato expandido; describe los detalles de la conversión interactiva entre los actores y el sistema. La última sección, curso alterno de los eventos, describe importantes opciones o excepciones que pueden presentarse en relación con el curso normal. El actor es una entidad externa del sistema que de alguna manera participa en la historia del caso de uso. Por lo regular estimula el sistema con eventos de entrada o recibe algo de él. Los actores están representados por el papel que desempeñan en el caso: Cliente, Cajero u otro. Conviene escribir su nombre con mayúscula en la narrativa del caso para facilitar la identificación. Un diagrama de casos de uso explica gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre éstos y los casos de uso. Estos últimos se muestran en óvalos y los actores son figuras estilizadas. Hay líneas de comunicaciones entre los casos y los actores; las flechas indican el flujo de la información o el estimulo. M.C.Felipe Belmont Polanco. Pág. 21