Mastery 14 – OO and Agile

Gestión de proyectos ágiles

La gestión ágil de proyectos es una metodología diseñada para responder al cambio y producir y entregar el trabajo en ráfagas cortas o ‘sprints’. Un equipo ágil puede administrar un proyecto dividiéndolo en varias etapas y entregando una parte utilizable del proyecto en cada etapa. La gestión ágil de proyectos requiere una constante colaboración y comunicación entre los miembros del equipo para responder a las demandas producidas por el cambio. Inicialmente desarrollada para proyectos de software es también adaptable a otras industrias.

El propietario del proyecto especifica qué quiere que su proyecto logre y cómo se usará. Es importante mantener una comunicación constante con los miembros del equipo antes de que comience el proyecto y luego a lo largo del proyecto si cambian sus necesidades o requisitos. El objetivo de la gestión ágil de proyectos es adaptarse al cambio. El equipo comienza a trabajar con un proceso de planificación, ejecución, evaluación y entrega.

Los principios de esta metodología fueron desarrollados y registrados por 17 desarrolladores de software en 2001. El Manifiesto Ágil describe una «proclamación formal de cuatro valores clave y 12 principios para guiar un enfoque iterativo y centrado en las personas para el desarrollo de software.

Gestión de proyectos tradicional

La gestión de proyectos tradicional es un conjunto universal de prácticas que se implementan en cada campo relacionado con proyectos. Se utiliza para proyectos que tienen resultados y vida predecible. El objetivo es crear un producto dentro de un marco de tiempo específico dentro de un presupuesto fijo.

La gestión de proyectos tradicional generalmente sigue los mismos pasos para cada proyecto, independientemente de su naturaleza. Estos pasos son:

Inicio:

• Establecer los resultados del proyecto
• Establecer los objetivos del proyecto
• Encontrar posibles obstáculos

Planificación:

• Estimar el tiempo y presupuesto
• Planificación y asignación de recursos
• Preparación de redes
• Desarrollar un plan de proyecto

Ejecución:

• Llevar a cabo el plan
• Evaluación regular del proyecto
• Comunicación entre los miembros del equipo
• Documentación del trabajo realizado

Control de calidad y monitoreo:

• Controlar el entorno para minimizar el cambio
• Control y control de calidad
• Establecimiento de progreso
• Revisar el proyecto si es necesario

Clausura:

• Presentar el proyecto al cliente
• Garantizar la satisfacción del cliente
• Cierre de contrato y pagos
• Emitir informe final

La razón por la que se llama administración de proyectos «tradicional» es que ha estado en práctica desde que existen trabajos basados en proyectos. Compañías y empresas deben seguir un camino estructurado para garantizar la calidad y la coherencia del producto final.

Diferencias

Ahora mostraré un cuadro comparativo con las diferencias principales de estas metodologías,

SimSe(Waterfall)

HFOOAD Chapter10 – «Putting It All Together»

El término «integración» hace referencia a una actividad de desarrollo de software que combina componentes de software diferentes en un conjunto. La integración se realiza en varios niveles y fases de la implementación.

• La integración del trabajo de un equipo que trabaja en el mismo subsistema de implementación antes de liberar el subsistema para los integradores del sistema.
• La integración de subsistemas en un sistema completo.

La propuesta de integración de Rational Unified Process consiste en integrar el software en incrementos. En la integración incremental, el código se escribe y se prueba en partes pequeñas que, a continuación, se añaden a un conjunto de trabajo de una en una.

Mencionada la prueba unitaria y las pruebas de integración, el proceso de testing pasa por otras fases que resultan relevantes y se deben tener en cuenta para mejores resultados. La prueba funcional es otro de los procesos que se tendrán que gestionar para alcanzar la mayor estabilidad y confianza en que el rendimiento sea el adecuado. Lo que hacemos en este caso, una vez vemos que las conexiones están en forma a través del test integral, es ver que el software que hemos diseñado y gestionado está actuando de manera conveniente teniendo en cuenta el objetivo para el cual fue creado.

Cada fase del testing tiene unas exigencias y unos puntos clave en los que nos debemos fijar. Eso es algo que siempre tenemos que tener en cuenta para que el testing resulte satisfactorio y no terminemos sufriendo demasiadas complicaciones. Por lo tanto, en la fase de la prueba funcional en lo único que nos tendremos que fijar es en que se produzca el tipo de soporte que tenemos en mente cuando hablamos del software en cuestión. Analizaremos las salidas y las entradas que se produzcan al software, así como los resultados. No importa en este caso si en el diseño del software se ha encontrado algún tipo de defecto o posible mejora, dado que la cuestión en esta prueba consiste en comprobar el funcionamiento. Por lo tanto, hemos pasado a un proceso que después de comprobar que todo está en su sitio nos indica si realmente tiene un buen rendimiento, algo clave para poder colocarse en el perfil del cliente y comprobar que vaya a obtener el nivel de satisfacción requerido.

Mastery 13 – Test Driven Development

Desarrollo guiado por pruebas de software, o Test-driven development (TDD) es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que el software cumple con los requisitos que se han establecido.

TDD fue creado por Kent Beck (quien también inventó Extreme Programming y JUnit), y en esencia, es un proceso a seguir, lo cual ya lo hace diferente a un simple enfoque de pruebas primero:

Este ciclo también se lo conoce como rojo (hacer que la prueba falle), verde (hacer que la prueba pase) y refactor. Aunque al principio pueda parecer muy parecido a un enfoque de probar primero, al combinarlo con prácticas de desarrollo ágil, TDD toma un enfoque mucho más amplio, y cambia su atención de las pruebas al diseño.

TDD está mucho más relacionado con el diseño emergente que con las pruebas, de hecho, que TDD genere una gran cantidad de pruebas es un efecto secundario positivo, pero no es su propósito final.

El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:

1. El cliente escribe su historia de usuario.
2. Se escriben junto con el cliente los criterios de aceptación de esta historia, desglosándolos mucho para simplificarlos todo lo posible.
3. Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria.
4. Se comprueba que esta prueba falla.
5. Se escribe el código que hace pasar la prueba.
6. Se ejecutan todas las pruebas automatizadas.
7. Se refactoriza y se limpia el código.
8. Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando.
9. Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación.

Ventajas

Los programadores que utilizan el desarrollo guiado por pruebas en un proyecto virgen encuentran que en raras ocasiones tienen la necesidad de utilizar el depurador o debugger.

A pesar de los elevados requisitos iniciales de aplicar esta metodología, el desarrollo guiado por pruebas (TDD) puede proporcionar un gran valor añadido en la creación de software, produciendo aplicaciones de más calidad y en menos tiempo. Ofrece más que una simple validación del cumplimiento de los requisitos, también puede guiar el diseño de un programa. Centrándose en primer lugar en los casos de prueba uno debe imaginarse cómo los clientes utilizarán la funcionalidad (en este caso, los casos de prueba). Por lo tanto, al programador solo le importa la interfaz y no la implementación. Esta ventaja es similar al diseño por convenio pero se parece a él por los casos de prueba más que por las aserciones matemáticas.

El poder del TDD radica en la capacidad de avanzar en pequeños pasos cuando se necesita. Permite que un programador se centre en la tarea actual y la primera meta es, a menudo, hacer que la prueba pase. Inicialmente no se consideran los casos excepcionales y el manejo de errores. Estos, se implementan después de que se haya alcanzado la funcionalidad principal. Otra ventaja es que, cuando es utilizada correctamente, se asegura de que todo el código escrito está cubierto por una prueba. Esto puede dar al programador un mayor nivel de confianza en el código.

Desventajas

• Interfaces Gráfica de usuario (GUIs): aunque hay soluciones parciales propuestas.
• Objetos distribuidos: aunque los objetos simulados (MockObjects) pueden ayudar.
• Bases de datos: Hacer pruebas de código que trabaja con base de datos es complejo porque requiere poner en la base de datos unos datos conocidos antes de hacer las pruebas y verificar que el contenido de la base de datos es el esperado después de la prueba. Todo esto hace que la prueba sea costosa de codificar, aparte de tener disponible una base de datos que se pueda modificar libremente.

Mastery 12 – Testing in OO

 La programación tradicional consiste en procedimientos que operan sobre datos, mientras que el paradigma orientado a objetos se enfoca en objetos que son instancias de clases. En el paradigma orientado a objetos (OO), los ingenieros de software identifican y especifican los objetos y servicios proporcionados por cada objeto. Además, también se determina la interacción de dos objetos y restricciones en cada objeto identificado. Las principales ventajas del paradigma OO incluyen una mayor capacidad de reutilización, confiabilidad, interoperabilidad y extensibilidad.

Desarrollo de casos de prueba en pruebas orientadas a objetos

Los métodos utilizados para diseñar casos de prueba en pruebas OO se basan en los métodos convencionales. Sin embargo, estos casos de prueba deben incluir características especiales para que puedan usarse en el entorno orientado a objetos. Los puntos que deben tenerse en cuenta al desarrollar casos de prueba en un entorno orientado a objetos se enumeran a continuación.

1. Debe especificarse explícitamente con cada caso de prueba qué clase debe probar.
2. Se debe mencionar el propósito de cada caso de prueba.
3. Las condiciones externas que deben existir al realizar una prueba deben indicarse claramente con cada caso de prueba.
4. Se deben especificar todos los estados de objeto que se van a probar.
5. Se deben proporcionar instrucciones para comprender y realizar los casos de prueba con cada caso de prueba.

Métodos para Verificar OO.

Pruebas basadas en fallas

Las pruebas basadas en fallas se utilizan para determinar o descubrir un conjunto de fallas plausibles. En otras palabras, el enfoque del probador en esta prueba es detectar la presencia de posibles fallas. Las pruebas basadas en fallas comienzan por examinar los modelos de análisis y diseño del software OO, ya que estos modelos pueden proporcionar una idea de los problemas en la implementación del software. Con el conocimiento del sistema bajo prueba y la experiencia en el dominio de la aplicación, el probador diseña casos de prueba en los que cada caso de prueba se enfoca en descubrir algunas fallas particulares.

La efectividad de esta prueba depende en gran medida de la experiencia del probador en el dominio de la aplicación y del sistema bajo prueba. Esto se debe a que si no percibe que las fallas reales en el sistema sean plausibles, las pruebas pueden dejar muchas fallas no detectadas. Sin embargo, examinar los modelos de análisis y diseño puede permitir al probador detectar una gran cantidad de errores con menos esfuerzo. Como las pruebas solo prueban la existencia y no la ausencia de errores, este enfoque de prueba se considera un método eficaz y, por lo tanto, a menudo se utiliza cuando se debe probar la seguridad o la seguridad de un sistema.

Pruebas de integración aplicadas a objetivos de software OO para descubrir las posibles fallas en las llamadas de operación y varios tipos de mensajes (como un mensaje enviado para invocar un objeto). Estas fallas pueden ser salidas inesperadas, mensajes u operaciones incorrectos e invocación incorrecta. Las fallas pueden reconocerse determinando el comportamiento de todas las operaciones realizadas para invocar los métodos de una clase.

Pruebas basadas en escenarios

Las pruebas basadas en el escenario se utilizan para detectar errores causados ​​por especificaciones incorrectas e interacciones inadecuadas entre varios segmentos del software. Las interacciones incorrectas a menudo conducen a salidas incorrectas que pueden causar un mal funcionamiento de algunos segmentos del software. El uso de escenarios en las pruebas es una forma común de describir cómo un usuario puede realizar una tarea o lograr un objetivo dentro de un contexto o entorno específico. Tenga en cuenta que estos escenarios son más específicos del contexto y del usuario en lugar de ser específicos del producto. Generalmente, la estructura de un escenario incluye los siguientes puntos.

1. Una condición bajo la cual se ejecuta el escenario.
2. Un objetivo a alcanzar, que también puede ser un nombre del escenario.
3. Un conjunto de pasos de acciones.
4. Una condición final en la que se logra el objetivo.
5. Un posible conjunto de extensiones escritas como fragmentos de escenario.

Mastery 11 – Verification and Validation

La verificación y la validación, dentro del ámbito de desarrollo de software, no son la misma cosa, aunque es muy fácil confundirlas.

• Verificación: ¿Estamos construyendo correctamente el producto? El papel de la verificación comprende comprobar que el software está de acuerdo con su especificación.
• Validación: ¿Estamos construyendo el producto correcto? La validación es un proceso más general. Se debe asegurar que el software cumple las expectativas del cliente.

En la Validación el resultado final del desarrollo software se debe ajustar a lo que el usuario quería (sus necesidades)? En la mayoría de las ocasiones el producto desarrollado no casa con la ideas del cliente, normalmente porque a éste suele faltarle capacidad técnica de expresión.

En la Verificación el código que estamos construyendo debe estar en armonía con la especificación que hemos tomado del usuario. El resultado final del desarrollo software debe concordar con la especificación (requisitos) del sistema, por lo que debemos asegurarnos que el desarrollo final coincida con dicha especificación

Un sistema puede pasar la validación, sin embargo, no pasa la verificación. Cumple con la especificación del usuario, con lo que él quería, cubre sus necesidades pero internamente puede adolecer de graves detalles como: un precario diseño en la base de datos; uso de un excesivo e innecesario número de líneas de código, por desconocer las potencialidades del lenguaje de desarrollo o de técnicas avanzadas de programación como la POO y uso incorrecto en la BD de instrucciones propias del lenguaje de desarrollo, en lugar de las sentencias adecuadas de SQL.

Las dos utilizan métodos de diseño de casos de prueba y estrategias de prueba, para la validación usamos Pruebas de Caja Negra (Grafos, partición equivalente y prueba de valores límites) para la verificación empleamos Pruebas de Caja Blanca (Prueba de Camino crítico: Grafo de flujo, complejidad ciclomática; prueba de Condición: ramificaciones, dominio, operador relacional y de ramificación; Prueba de Flujo de datos y Prueba de Bucles).

HFOOAD Chapter 9 – «The Software is Still for the Customer»

La creación de un proyecto requiere la interacción con el usuario porque a pesar de todo el proyecto sigue siendo del cliente y no nuestro y puedes enfocarte en cosas especificas del proyecto o en el comportamiento general; probarlo y corregirlo; por eso se usa el caso de Uso, ya que es de una interacción constante con el usuario donde en etapas del proceso se puede complementar con el uso que el usuario le va a dar. Aquí dejo el link a la explicación del caso de uso.

Después de este proceso es importante tomar las consecuencias ya que el programa debe estar diseñado para el usuario haciéndolo tolerante para manejar los errores que el usuario puede cometer con la información. Por tanto proyecto debe estar adaptado para que funcione con los errores que el usuario puede tener, de esta forma el proyecto tiene una mejor calidad. Aquí hay un vídeo para entender el porque de la prueba para el usuario final.

HFOOAD Chapter 8 – «Originality is Overrated»

La originalidad y querer crear nuevos procesos es una buena iniciativa de parte de todos los programadores, sin embargo una practica que es buena es el reutilizar código que se adapta a nuestras necesidades que funciona y que para nuestro intereses de evitar que el presupuesto se incremente de forma exponencial con el tiempo. De esta forma se aprovecha el trabajo anterior, se economiza tiempo, y se reduce la redundancia.

La reutilización de código se refiere al comportamiento y a las técnicas que garantizan que una parte o la totalidad de un programa informático existente se pueda emplear en la construcción de otro programa.

Un ejemplo es la herencia mostrada en la figura sería así:

La manera más fácil de reutilizar código es copiarlo total o parcialmente desde el programa antiguo al programa en desarrollo. Pero es trabajoso mantener múltiples copias del mismo código, por lo que en general se elimina la redundancia dejando el código reusable en un único lugar, y llamándolo desde los diferentes programas. Este proceso se conoce como abstracción. La abstracción puede verse claramente en las bibliotecas de software, en las que se agrupan varias operaciones comunes a cierto dominio para facilitar el desarrollo de programas nuevos. Hay bibliotecas para convertir información entre diferentes formatos conocidos, acceder a dispositivos de almacenamiento externos, proporcionar una interfaz con otros programas, manipular información de manera conocida (como números, fechas, o cadenas de texto).

Mastery 10 – Code Revision

La revisión al momento de ir pasando el programa al código fuente es un punto crítico de la aplicación, ya que pueden reducir los errores al momento de ejecución final del proyecto y evitar errores cómo el de pantalla azul u otros errores.

Esta practica se hace con el objetivo de mejorar la calidad del código que se genera en el proceso de desarrollo del software, mediante la detección temprana de errores en el código de los programas o alternativas más eficientes a la implementación inicial. También se utiliza como técnica para mejorar las cualidades de los desarrolladores involucrados en la práctica, mediante la discusión abierta de posibles mejoras en el programa.

La revisión del código de una aplicación puede ser llevada en diferentes etapas del proceso de desarrollo. Si bien lo ideal es que cada nueva iteración del desarrollo de lugar a la validación de aspectos de seguridad y calidad de software, la mayoría de las empresas se plantean integrar revisiones en cada spring de la aplicación.

Blogging and me

Los blogs representan una herramienta muy útil para aquellas personas extrovertidas o introvertidas que les gusta compartir su opinión de manera espontanea y continua en la red, sin embargo es una herramienta de difusión que permanece hasta el día de hoy a pesar del tiempo que este lleva en vigencia y no solo se encuentra WordPress para crear contenido desde cero, existen otras plataformas como lo es Medium donde se crea únicamente el texto y las imágenes y se te da una plantilla personalizada.

En el blog Ana se puede ver cómo muestra interés tambien por la adaptación de los blogs a diferentes dispositivos computadoras de escritorios y móviles. También desde sus perspectivas se ve cómo piensa que escribir blogs acerca de temas reafirma el conocimiento y ayuda a la persona para aprender. Por tanto se puede decir que la autora apoya los blogs para la educación.

En mi opinión los blogs son un gran medio de difusión ya que están al alcance de todos y en principio son un medio informal de difusión de información que permite compartir lo que el usuario guste adaptándolo a su personalidad. También al igual que la autora, considero que es bueno para la educación ya que los estudiantes podemos escribir y tenerlo guardado, aunque no sea el mayor usuario de este medio es una gran herramienta.