TEORÍA 3 USO DE HERRAMIENTAS CASE PDF

TEORÍA 3 USO DE HERRAMIENTAS CASE Los analistas que adoptan la metodología SDLC a menudo se benefician de las herramientas de productividad, conocidas como herramientas de Ingeniería de Software Asistida por Computadora (CASE), las...

TEORÍA 3 USO DE HERRAMIENTAS CASE Los analistas que adoptan la metodología SDLC a menudo se benefician de las herramientas de productividad, conocidas como herramientas de Ingeniería de Software Asistida por Computadora (CASE), las cuales se crearon de manera explícita para mejorar el trabajo rutinario a través d el uso del soporte automatizado. Los analistas emplean herramientas CASE para aumentar la productividad, comunicarse con los usuarios de una manera más efectiva e integrar el trabajo que realizan en el sistema, desde el inicio hasta el fin del ciclo de vida. Visible Analyst (VA) es un ejemplo de herramienta CASE que permite a los analistas de sistemas realizar planificación, análisis y diseño en forma gráfica para crear bases de datos y aplicaciones cliente/servidor complejas. Visible Analyst, aunado a otro producto de software conocido como Microsoft Visio, permite a los usuarios dibujar y modificar diagramas con facilidad. Los analistas y usuarios en general reportan que las herramientas CASE les ofrecen un medio de comunicación relacionado con el sistema durante su conceptualización. Mediante el uso de soporte automatizado que incluye resultados en pantalla, los clientes pueden ver de inmediato la forma en que fluyen los datos y cómo se representan otros conceptos del sistema, para así poder solicitar correcciones o modificaciones que hubieran requerido de mucho más tiempo si se utilizaran herramientas anteriores. Algunos analistas marcan la diferencia entre las herramientas CASE superiores e inferiores. Una herramienta CASE superior permite al analista crear y modificar el diseño del sistema. Toda la información sobre el proyecto se almacena en una enciclopedia conocida como repositorio CASE, una extensa colección de registros, elementos, diagramas, pantallas, informes y demás información relacionada (vea la figura 1.6). Es posible producir informes del análisis mediante el uso de la información del repositorio para mostrar en qué partes está incompleto el diseño o dónde hay errores. Las herramientas CASE superiores también ayudan a sustentar el modelado de los requerimientos funcionales de una organización, auxiliar a los analistas y usuarios para dibujar los límites de un proyecto dado y ayudarlos a visualizar la forma en que el proyecto encaja con otras partes de la organización. Las herramientas CASE inferiores se utilizan para generar código fuente de computadora, con lo cual se elimina la necesidad de programar el sistema. La generación de código ofrece varias ventajas: 1) el sistema se puede producir con más rapidez que si se escribieran programas compu tacionales; 2) la cantidad de tiempo invertido en el mantenimiento se reduce con la generación de código; 3) se puede generar código en más de un lenguaje computacional, por lo que es más sencillo migrar los sistemas de una plataforma a otra; 4) la generación de código provee una manera efectiva en costo de personalizar los sistemas que se compran a terceros distribuidores para ajustarlos a las necesidades de la organización, y 5) el código generado está libre de los errores típicos de los programas computacionales. Página 1|6 LA METODOLOGÍA ÁGIL Aunque este texto tiende a enfocarse en el SDLC —la metodología más utilizada en la práctica—, el analista deberá reconocer algunas veces que la organización podría beneficiarse de una metodología alternativa. Tal vez recientemente un proyecto de sistemas en el que se utilizaba una metodología estructurada falló o quizás las subculturas de la organización, compuestas por varios grupos de usuarios distintos, parecen identificarse más con el uso de un método alternativo. Es imposible hacer justicia a estos métodos en un espacio pequeño; cada uno merece y ha inspirado sus propios libros e investigaciones. Sin embargo, mencionamos estas metodologías con la esperanza de que tome conciencia de que, bajo ciertas circunstancias, tal vez su organización quiera considerar una alternativa o suplemento al análisis y diseño estructurado y al SDLC. La metodología ágil es una metodología de desarrollo de software que se basa en valores, principios y prácticas básicas. Los cuatro valores son comunicación, simpleza, retroalimentación y valentía. Recomendamos que los analistas de sistemas adopten estos valores en todos los proyectos que emprendan y no sólo cuando adopten la metodología ágil. Para poder terminar un proyecto, a menudo hay que realizar ciertos ajustes en la administración del mismo. En el capítulo 6 veremos que los métodos ágiles pueden asegurar que un proyecto se complete con éxito me diante un ajuste en los importantes recursos de tiempo, costo, calidad y alcance. Cuando se incluyen estas cuatro variables de control en forma apropiada en la planificación, hay un estado de equilibrio entre los recursos y las actividades necesarias para completar el proyecto. Es más notable llevar las prácticas de desarrollo al extremo cuando se per siguen prácticas únicas para el desarrollo ágil. En el capítulo 6 hablaremos sobre cuatro prácticas ágiles básicas: liberaciones de versiones cortas, la semana de trabajo de 40 horas, hospedar un cliente en el sitio y utilizar programación en pareja. A primera vista estas prácticas parecen extremas, pero como veremos más adelante, podemos aprender ciertas lecciones importantes al incorporar muchos de los valores y prácticas de la metodología ágil a los proyectos de análisis y diseño de sistemas. Proceso de desarrollo para un proyecto ágil Hay actividades y comportamientos que determinan la manera en que actúan los miembros del equipo y los clientes durante el desarrollo de un proyecto ágil. Dos palabras que caracterizan a un proyecto realizado mediante una metodología ágil son interactivo e incremental, hay cinco etapas: exploración, planeación, iteraciones para la liberación de la primera versión, puesta en producción y mantenimiento. Observe que las primeras tres flechas grises que iteran de vuelta a la caja “Iteraciones” simbolizan los cambios incrementales creados por medio de los procesos repetidos de prueba y retroalimentación que en cierto momento conducen a un sistema estable, pero en evolución. Observe ademá s que el ritmo de iteraciones aumenta una vez que se libera el producto. La flecha sale de la etapa de mantenimiento y regresa a la etapa de planeación, de manera que hay un ciclo continuo de retroalimentación que involucra a los clientes y al equipo de desarrollo a medida que se ponen de acuerdo para alterar el sistema en evolución. P ágina 2|6 EXPLORACIÓN Durante ella usted explorará su entorno para evaluar su convicción de que puede y debe lidiar con el problema mediante el desarrollo ágil, ensamblará el equipo y evaluará las habilidades de sus miembros. Esta etapa puede requerir desde unas cuantas semanas (si conoce de antemano a los miembros de su equipo y la tecnología que va a usar) hasta unos cuantos meses (si todo es nuevo). También tendrá que examinar activamente las tecnologías potenciales necesarias para crear el sistema. Durante esta etapa debe practicar con la estimación del tiempo necesario para realizar varias tareas. En la exploración, los clientes también experimentan escribiendo historias de los usuarios. El punto es hacer que el cliente refine una historia con el detalle suficiente como para que usted pueda estimar en forma competente la cantidad de tiempo necesaria para crear la solución y convertirla en el sistema que está planeando. Todo en esta etapa tiene que ver con adoptar una actitud juguetona y curiosa hacia el entorno de trabajo, sus problemas, tecnologías y personas. PLANEACIÓN La siguiente etapa del proceso de desarrollo ágil se llama planeación. Al contrario de la primera etapa, la planeaci ón tal vez sólo requiera de unos cuantos días. En esta etapa, usted y sus clientes se ponen de acuerdo en una fecha, que puede ser cualquier día a partir de dos meses hasta medio año después de la fecha en curso, para entregar soluciones a sus problemas em presariales más estresantes (usted se concentrará en el conjunto más pequeño y valioso de historias). Si sus actividades de exploración fueron suficientes, esta etapa debe ser muy corta. Todo el proceso de planeación ágil se ha caracterizado mediante la idea de un juego de planeación según la idea de Beck. El juego de planeación establece reglas que pueden ayudar a formular la relación del equipo de desarrollo ágil con sus clientes empresariales. Aunque las reglas forman una idea de cómo quiere usted que actúe cada una de las partes durante el desarrollo, no están diseñadas para sustituir una relación. Son la base para crear y mantener una relación. Entonces, utilizamos la metáfora de un juego. Para ello hablaremos en términos del objetivo del juego, la estrategia a perseguir, las piezas a mover y los jugadores involucrados. El objetivo del juego es maximizar el valor del sistema producido por el equipo ágil. Para poder averiguar el valor, usted debe deducir los costos de desarrollo y el tiempo, los gastos y la incertidumbre requeridos para que el proyecto de desarrollo pueda continuar. La estrategia que persigue el equipo de desarrollo ágil siempre tiene una incertidumbre limitante (minimización del riesgo). Para hacer esto, el equipo diseña la solución más simple posible, pone el sistema en producción tan pronto como sea posible, obtiene retroalimentación del cliente empresarial sobre lo que está funcionando y adapta su diseño a partir de ahí. Las tarjetas de historias se convierten en las piezas del juego de planeación que describen con brevedad la tarea, proveen anotaciones y un área para rastrear las tareas. Hay dos jugadores principales en el juego de planeación: el equipo de desarrollo y el cliente empresarial. No siempre es fácil decidir qué grupo empr esarial en particular será el cliente empresarial, ya que el proceso ágil es un rol excepcionalmente exigente para el cliente. Los clientes deciden qué debe abordar P ágina 3|6 primero el equipo de desarrollo. Sus decisiones establecerán prioridades y revisarán la funcionalidad durante todo el proceso. ITERACIONES PARA LA LIBERACIÓN DE LA PRIMERA VERSIÓN La tercera etapa en el proceso de desarrollo ágil está compuesta por las iteraciones para la liberación de la primera versión. Por lo general éstas son iteraciones (ci clos de prueba, retroalimentación y modificación) de aproximadamente tres semanas de duración. Usted se esforzará en bosquejar toda la arquitectura del sistema, aun y cuando sólo esté en forma de bosquejo o esqueleto. Uno de los objetivos es realizar pruebas funcionales escritas por el cliente al final de cada iteración. Durante la etapa de las iteraciones también debe preguntarse si hay que alterar el itinerario de trabajo o si está lidiando con demasiadas historias. Convierta cada iteración exitosa en pequeños rituales e involucre en ellos tanto a los clientes como a los desarrolladores. Celebre siempre su progreso, aunque éste sea pequeño, debido a que esto forma parte de la cultura de motivar a todos a que trabajen lo más duro que puedan en el proyecto. PUESTA EN PRODUCCIÓN Durante esta fase se llevan a cabo varias actividades. El ciclo de retroalimentación se agiliza de manera que en vez de recibir retroalimentación por una iteración cada tres semanas, las revisiones de software se entregan en una semana. Puede instituir sesiones informativas diarias para que todos sepan lo que los demás están haciendo. El producto se libera durante esta fase, pero se puede mejorar si se le agregan otras características. Poner un sistema en producción es un suceso emocionante; disponga de tiempo para celebrar con sus compañeros de equipo la ocasión. Uno de los lemas de la metodología ágil con el que todos estamos sinceramente de acuerdo es que ¡desarrollar sistemas debe ser divertido! MANTENIMIENTO Una vez liberado el sist ema, debe seguir funcionando sin problemas. Es posible agregar características, considerar las sugerencias más riesgosas de los clientes y a rotar los miembros del equipo. La actitud que usted debe tomar en este punto del proceso de desarrollo es más conservadora que en cualquier otro. Ahora tiene que desempeñar el papel de “guardián de la llama” en vez de ser el juguetón y curioso de la fase de exploración. ANÁLISIS Y DISEÑO DE SISTEMAS ORIENTADO A OBJETOS El análisis y diseño de sistemas orientado a objetos (O-O) es una metodología diseñada para facilitar el desarrollo de sistemas que deben cambiar con rapidez en respuesta a los entornos empresariales dinámicos. El capítulo 10 le ayudará a comprender lo que es el análisis y diseño de sistemas orientado a objetos, la diferencia entre esta metodología y la metodología estructurada del SDLC y cuándo puede ser apropiado utilizar una metodología orientada a objetos. Se cree que las técnicas orientadas a objetos funcionan bien en situaciones en las que los sistemas de in- formación complejos pasan a través de un continuo proceso de mantenimiento, adaptación y rediseño. Las metodologías orientadas a objetos utilizan el estándar de la industria para modelar sistemas orientados a objetos, conocido como lenguaje de modelado unificado (UML), para descomponer un sistema en un modelo de caso de uso. P ágina 4|6 La programación orientada a objetos difiere de la programación tradicional por procedimientos en cuanto a que examina a los objetos que forman parte de un sistema. Cada objeto es una representación computacional de una cosa o evento real. Los objetos pueden ser clientes, artículos, pedidos, etcétera. Los objetos se representan y agrupan mediante clases, las cuales son ideales para la reutilización y la facilidad de mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos que se encuentran en cada objeto de la clase. Las fases en el UML son similares a las del SDLC. Como estos dos métodos comparten un modelado rígido y exigente, se realizan a un ritmo más lento y reflexivo que las fases del modelado ágil. El analista pasa por las fases del problema y de identificación, una fase de análisis y una fase de diseño, l os siguientes pasos muestran una descripción breve del proceso del UML. Definir el modelo de caso de uso. En esta fase, el analista identifica a los actores y los eventos principales iniciados por los actores. A menudo el analista empieza por dibujar un diagrama con figuras hechas con líneas que representan a los actores y flechas que muestran las relaciones entre ellos. A esto se le conoce como diagrama de caso de uso y representa el flujo estándar de eventos en el sistema. Después de esto, el analista por lo general escribe un escenario de caso de uso, que describe con palabras los pasos que se llevan a cabo comúnmente. Durante la fase de análisis de sistemas, empezar a dibujar diagramas de UML. En la segunda fase, el analista dibujará Diagramas de actividad, los cuales ilustran todas las principales actividades en el caso de uso. Además, el analista creará uno o más diagramas de secuencia para cada caso de uso, los cuales muestran la secuencia de actividades y su sincronización. Ésta es una oportunidad para regresar y revisar los casos de uso, replantearlos y modificarlos si es necesario. Continuar en la fase de análisis, desarrollar diagramas de clases. Los sustantivos en los casos de uso son objetos que se pueden agrupar potencialmente en clases. Por ejemplo, todo automóvil es un objeto que comparte características con otros automóviles. En conjunto conforman una clase. Aún en la fase de análisis, dibujar diagramas de estado. Los diagramas de clases se utilizan para dibujar diagramas de estado, los cuales ayudan a comprender procesos complejos que no se pueden derivar completamente mediante los diagramas de secuencia. Los diagramas de estado son en extremo útiles para modificar los diagramas de clases, por lo que continúa el proceso iterativo de modelado de UML. Empezar el diseño de sistemas mediante la modificación de los diagramas de UML; después, completar las especificaciones. El diseño de sistemas significa modificar el sistema existente, para lo cual hay que modificar los diagramas que se dibujaron en la fase anterior. Es posible usar estos diagramas para derivar clases, sus atributos y métodos (éstos son simplemente P ágina 5|6 operaciones). El analista tendrá que escribir especificaciones de clase para cada una de las clases e incluir los atributos, métodos y sus descripciones. También desarrollará especificaciones de los métodos en las que se detallen los requerimientos de entrada y salida para cada método, junto con una descripción detallada del procesamiento interno del método. Desarrollar y documentar el sistema. UML es, obviamente, un lenguaje de modelado. Un analista podrá crear modelos maravillosos, pero si el sistema no se desarrolla no tiene mucho sentido crearlos. La documentación es imprescindible. Entre más completa sea la información que usted proporcione al equipo de desarrollo por medio de la documentación y los diagramas de UML, más rápido será el desarrollo y más sólido será el sistema de producción final. A menudo las metodologías o rientadas a objetos se enfocan en iteraciones pequeñas y rápidas de desarrollo, a lo que algunas veces se le conoce como el modelo de espiral. El análisis se lleva a cabo en una parte pequeña del sistema, en donde por lo general se empieza con un elemento de alta prioridad o tal vez con uno que represente el mayor riesgo. A esto le sigue el diseño y la implementación. El ciclo se repite con el análisis de la siguiente parte, el diseño y algo de implementación, y esto se repite hasta completar el proyect o. Es normal rediseñar los diagramas y los componentes mismos. El UML es una potente herramienta de modelado que puede mejorar en forma considerable la calidad del análisis y diseño de sistemas, así como del producto final. CÓMO ELEGIR QUÉ MÉTODO DE DESARROLLO DE SISTEMAS USAR Las diferencias entre las tres metodologías antes descritas no son tan grandes como parecen en un principio. En las tres metodologías, el analista necesita comprender primero a la organización. Después el analista o el equipo del proyecto necesitan elaborar un presupuesto del tiempo y los recursos necesarios para desarrollar la propuesta del proyecto. A continuación, deben entrevistar a los miembros de la organización y recopilar información detallada mediante el uso de cuestionarios, obtener muestras de los datos de los informes existentes y observar cómo se lleva a cabo la actividad empresarial actual. Las tres metodologías tienen todas estas actividades en común. Incluso los mismos métodos tienen similitudes. La metodología SDLC y la metodología orientada a objetos requieren de un proceso exhaustivo de planeación y elaboración de diagramas. La metodología ágil y la metodología orientada a objetos permiten crear subsistemas uno a la vez hasta que se complete todo el sistema. La metodología ágil y la metodología SDLC se interesan por la forma lógica en que los datos se desplazan a través del sistema. Entonces, dada la opción de desarrollar un sistema mediante el uso de una metodología SDLC, una metodología ágil o una metodología orientada a objetos, ¿cuál escogería usted?. P ágina 6|6