Optativa II: Modelos de Proceso de Desarrollo de …fbelmont.utj.edu.mx/docum/Optativa_II.pdf ·...

Optativa II: Modelos de Proceso de Desarrollo de Software

M.C.Felipe Belmont Polanco. Pág. 1

UNIVERSIDAD TECNOLÓGICA DE JALISCO

Creación Periodo: Mayo - Agosto 2013 Adecuaciones Periodo: Mayo – Agosto 2016

Por: M.C. Felipe Belmont Polanco



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 ………………...……… 40 % ..... 30 % Tareas / Avances ………………………. 50 % … 60 % .….. 40 % Proyecto …………………………………..…….……………. 50 % Cero faltas/Cumplir reglamento ………. 10 % … 10 % …… 10 %



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.



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.



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

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

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

Usabilidad 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).



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.



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.



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.



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

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



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.



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.



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.



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.



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.



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. Enseguida algunos aspectos que se deben considerar de forma general.

El entorno organizacional: ¿Existe en una localización o varias?, ¿Involucra a un área o a varias?, ¿Los participantes se encuentran en la misma localización o en varias?, ¿Se involucrará a otras organizaciones?. Funcionalidad: ¿Qué hará el sistema?, ¿Cuándo lo hará?, ¿Existen varios modos de operación?, ¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?. Datos: ¿Cuál será el formato de los datos, tanto para la entrada como para la salida?, ¿Cuán a menudo serán recibidos o enviados?, ¿Qué cálculos deben hacerse para?, ¿Cuántos datos fluyen a través del sistema?, ¿Cuál es el período de tiempo con que deben retenerse los datos?.



Recursos: ¿Qué recursos materiales, personales o de otro tipo se requieren para construir, utilizar y mantener el sistema?, ¿Existe alguna restricción de tiempo para el desarrollo?, ¿Existe un límite sobre la cantidad de dinero a gastar en el desarrollo o en hardware y software?.

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.



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 830-1998 (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.



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



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

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, (Objetivos).

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.



Comprar productos

Categoría de la función. Significado.

Evidente. Debe realizarse, y el usuario debería saber que se ha realizado.

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

No. 1 Nombre: Comprar productos.

Ref # Función. Categoría. R1.1 Registra la venta en proceso (actual): los productos

comprados. Evidente.

R1.2 Calcula el total de la venta actual; se incluyen el impuesto y los cálculos de cupón.

Evidente.

R1.3 Captura la información sobre el objeto comprado 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).

Evidente.

R1.4 Reduce las cantidades del inventario cuando se realiza una venta.

Oculta.

R1.5 Se registran las ventas efectuadas. Oculta. R1.6 El cajero debe introducir una identificación y una

contraseña para poder utilizar el sistema. Evidente.

R1.7 Ofrece un mecanismo de almacenamiento persistente.

Oculta.

R1.8 Muestra la descripción y el precio del producto registrado.

Evidente.

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.



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.

Curso normal de eventos Acción del actor Respuesta del sistema.

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.

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.

4. Al terminar de introducir el producto, el Cajero indica a TPDV que se concluyó la captura del producto.

5. Calcula y presenta el total de la venta.

6. El Cajero le indica el total al Cliente.



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

9. Muestra al cliente la diferencia. Genera un recibo.

10. El Cajero deposita el efectivo recibido y extrae el cambio del pago. El Cajero da al Cliente el cambio y el recibo impreso.

11. Registra la venta concluida.

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.



Un caso de uso describe la interacción con un sistema, y es importante definir la frontera del sistema para identificar lo que es interno o externo, así como las responsabilidades del sistema. El ambiente externo está representado únicamente por actores, las fronteras ordinarias del sistema son.

La frontera hardware/software de un dispositivo o sistema de cómputo. El departamento de una organización. La organización entera.

Tipos de casos de uso. Los casos deberían clasificarse en primarios, secundarios u opcionales para establecer prioridades en su desarrollo.

Los casos de uso primarios: Representan los procesos comunes más importantes. Los casos de uso secundarios: Representan procesos menores o raros. Los casos de uso opcionales: Representan procesos que pueden no abordarse.

También se pueden clasificar de acuerdo a su nivel de descripción. Los casos de uso esenciales: son casos expandidos que se expresan con poco detalles de implementación; las decisiones de diseño se posponen y se abstraen de la realidad, especialmente las concernientes a la interfaz para el usuario. Un caso de este tipo describe el proceso a partir de sus actividades y motivos esenciales. El grado de abstracción con que se describe existe puede ser más o menos esencial. Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y abstracción. Los caso de uso real: describe el proceso a partir de su diseño concreto actual, sujeto a las tecnologías de entrada y de salida, cuando se trata de la interfaz para el usuario, a menudo ofrece presentaciones de pantalla y explica la interacción con el resto de los artefactos.



Acciones de los actores Respuesta del sistema 1. El Cliente introduce su tarjeta. 2. Pide el número de identificación

personal (NIP). 3. Introduce el NIP con un teclado numérico.

4. Muestra el menú de opciones.

5. y así sucesivamente. 6. y así sucesivamente.

Proceso de Diseño El diseño, es un proceso iterativo donde es necesario contar con el análisis y desarrollar un diseño preliminar. Antes de emprender el diseño lógico de cómo funcionará una aplicación de software, es necesario investigar y definir su comportamiento como "caja negra". El comportamiento de un sistema es una descripción de lo que hace, sin explicar cómo lo hace, describen el comportamiento de un sistema a partir de cómo cambia el estado de un sistema cuando se llama una operación. Durante el ciclo de desarrollo iterativo es posible pasar a la fase de diseño, una vez terminados los documentos del análisis. Durante este paso se logra una solución lógica que se funda en el paradigma orientado a objetos. Su esencia es la elaboración de diagramas de interacción, que muestran gráficamente cómo los objetos se comunicarán entre ellos a fin de cumplir con los requerimientos. Casos de uso reales Un caso de uso real describe el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida, así como de su implementación global. Por ejemplo, si interviene una interfaz gráfica para el usuario, el caso de uso real incluirá diagramas de las ventanas en cuestión y una explicación de la interacción de bajo nivel con los artefactos de la interfaz. Tal vez no sea necesario generarlos. Una alternativa podría consistir en que el diseñador realizara storyboards o secuencias de las pantallas de la interfaz general para el usuario y que después fuera incorporando los detalles durante la implementación. En el siguiente ejemplo se utiliza un esquema de codificación con los artefactos de ventana para obtener una descripción fluida.



Casos de uso: Comprar productos: versión 1 (efectivo exclusivamente) Actores: Cliente (iniciador). Cajero. Propósito: Capturar una venta y su pago en efectivo. Resumen:

Un Cliente llega a la caja con productos que desea comprar. El Cajero registra los productos de la compra y recibe el pago en efectivo. Al terminar la transacción, el Cliente se marcha con los productos comprados.

Tipo: Primario y real. Referencias cruzadas: Funciones: R1.1, R1.2, RI.3, R1.7, R1.9, R2.1.

Diagramas de la secuencia del sistema Los casos de uso indican cómo los actores interactúan con el sistema de software que es lo que en realidad deseamos crear. Durante la interacción un actor genera eventos dirigidos a un sistema, solicitando alguna operación a cambio. Por ejemplo, cuando un cajero introduce un código universal de producto de un artículo, está pidiendo al sistema TPDV registrar la compra. Con el evento de esa petición se inicia una operación del sistema. El diagrama de la secuencia de un sistema es una representación que muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. A todos los sistemas se les trata como una caja negra; los diagramas se centran en los eventos que trascienden las fronteras del sistema y que fluyen de los actores a los sistemas. Los eventos del sistema pueden incluir parámetros. El ejemplo adjunto se refiere al curso normal de los eventos en el caso Comprar Productos. Indica que el cajero es el único actor en el sistema TPDV y que genera los eventos del sistema introducirProducto, terminarVenta y efectuarPago.



La identificación y ordenamiento de los eventos de un sistema para incluirlos en los diagramas de secuencia se logran de la revisión de los casos de uso.



Diagrama que representa el pago con tarjeta de crédito.

Optativa II: Modelos de Proceso de Desarrollo de …fbelmont.utj.edu.mx/docum/Optativa_II.pdf ·...

Documents

Transcript of Optativa II: Modelos de Proceso de Desarrollo de …fbelmont.utj.edu.mx/docum/Optativa_II.pdf ·...