5) Historia de Usuario

Tarjeta (anverso) con ejemplo de una historia de usuario, el cliente es Félix Almendra Hernández.

4) Programación Extrema

Escenario

La empresa el Pato Volador en la que usted labora ha sido contratada por una Agencia Espacial para desarrollar el software de un satélite que se desarrollará en 3 meses como máximo, ya que es el tiempo en que será el lanzamiento del satélite para ponerlo en órbita. El satélite auxiliará el retorno de una las naves espaciales que regresan a la tierra.

La Agencia espacial ha puesto a su disposición a los ingenieros encargados de proporcionar los requerimientos del software de tiempo completo, así como los recursos e instalaciones necesarios para lograr el desarrollo del software en el tiempo establecido.

El Pato Volador ha propuesto a los directivos de la Agencia Espacial la metodología de Programación Extrema (XP por sus siglas en inglés) para la realización del software, ya que es indispensable terminar en tiempo el proyecto.

Usted debe utilizar la metodología XP para organizar a su equipo de trabajo y a los ingenieros de la Agencia, explicándoles la metodología XP y las funciones que deben realizar en las diferentes fases del proceso de desarrollo del software.

Preguntas y Mapa Conceptual

¿Qué es la Programación Extrema?

Es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.

¿Cuáles son los valores y principios de la Programación Extrema?

Los valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained.

¿Cuáles son las actividades, recursos y prácticas de la Programación Extrema?

Equipo completo, planificación, test del cliente, versiones pequeñas, diseño simple, pareja de programadores, desarrollo guiado por las pruebas automáticas, integración continua, el código es de todos, normas de codificación, metáforas y ritmo sostenible.

¿Cuál son las fases del proceso de desarrollo de XP?

Planificación del proyecto, diseño, codificación y pruebas.

¿Qué es una historia de usuario?

Es una representación de un requisito de software escrita por el cliente en 1 a 4 frases en su lenguaje común. Son usadas para la especificación de requerimientos y para estimar tiempos de desarrollo. El tiempo de desarrollo de cada una es entre 1 y 3 semanas.

Presentación

3) Los Métodos Ágiles del Desarrollo de Software

Escenario

La Agencia Espacial en días anteriores ha perdido un satélite de comunicación debido al fallo del software del mismo. La investigación indicó que la falla fue porque no se cubrieron los requisitos de programación del sistema especificados por la propia Agencia.

La Agencia Espacial tiene que remplazarlo lo más pronto posible, ya que las comunicaciones con las naves espaciales dependen del mismo. Afortunadamente para la Agencia, existe un nuevo satélite ya construido que estaba programado para ser lanzado en un año, el inconveniente es que si se carga el mismo software el satélite se volverá a perder.

La empresa el Pato Volador en la que usted labora ha sido contratada para desarrollar el software del satélite en un proyecto de 3 meses como máximo, ya que es el tiempo en que retornará la próxima nave espacial que necesita los servicios del satélite para poder retornar a la tierra.

La Agencia pone a su disposición a los ingenieros encargados de proporcionar los requerimientos del software de tiempo completo, así como los recursos e instalaciones necesarios para lograr el desarrollo del software en el tiempo establecido. No es indispensable entregar la documentación formal del análisis y diseño del software, sin embargo debe haber evidencia que permita el entendimiento del sistema y el funcionamiento del mismo.

Usted debe proponer una metodología de desarrollo de software que permita organizar a su equipo de trabajo y a los ingenieros de la Agencia, mencionando los beneficios y riesgos que puedan existir.

Preguntas y Mapa Conceptual

¿Qué son las metodologías ágiles de desarrollo de software?

Son métodos para desarrollo de software que le dan mayor peso a ciertas dimensiones tales como el factor humano o el producto software. Las metodologías ágiles dan mayor valor al individuo, a la colaboración y al desarrollo incremental del software con iteraciones muy cortas. Se usan generalmente para proyectos un tanto cortos pero sin descuidar la calidad.

¿Cuáles son las características en las que se basan las metodologías ágiles?

Rapidez, flexibilidad, trabajo en equipo y disponibilidad.

¿Cuáles son las ventajas y desventajas del empleo de las metodologías ágiles respecto a las tradicionales?

Una de las ventajas principales es que al utilizar las metodologías ágiles al presentarse algún error de cualquier tipo, el desarrollador no tiene que empezar desde el inicio sino que es fácilmente adaptable. Otra ventaja que se tiene es el hecho de tener al cliente como parte del equipo, pues de esta forma el cliente entiende mejor lo que se está haciendo y que es lo que le beneficiaría, lo cual de manera implícita implica que no es necesario hacer formalmente una documentación.

¿Cuándo es recomendable utilizar metodologías ágiles en el desarrollo de software?

Es recomendable usar metodologías ágiles generalmente cuando se cuenta con un lapso corto para el desarrollo del proyecto.

¿Cuáles son algunos tipos de metodologías ágiles?

Algunos tipos de metodologías ágiles son: programación extrema, SCRUM, Adaptive Software Development, Crystal methodologies y Feature Driven Development.
 

 

Presentación

2) Modelos del Proceso de Software

Introducción

Quién hace qué, cuándo y cómo lo hace para alcanzar cierto objetivo es lo que un proceso define. En general, el éxito de las empresas u organizaciones depende en gran medida de la definición y seguimiento adecuado de sus procesos. En el caso de una empresa que se dedica al desarrollo de software, se requieren procesos especializados que abarquen desde la creación hasta la administración de un sistema de software.

Un modelo de proceso de software define cómo resolver la problemática del desarrollo de sistemas de software. Para desarrollar software se requiere resolver ciertas fases de un proceso que se conocen en su conjunto como el ciclo de vida del desarrollo de software. Un modelo de proceso debe considerar una variedad de aspectos, como el conjunto de personas, estructuras organizacionales, reglas, políticas, actividades, componentes de software, metodologías y herramientas utilizadas.

 

Desarrollo

Modelo de Cascada

Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo.

Análisis del sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. 

 

Desarrollo Evolutivo

Este modelo es efectivo en proyectos pequeños o medianos con poco tiempo para su desarrollo y sin generar documentación para cada versión. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

 

Ingeniería de Software Basada en Componentes

En general, el desarrollo de software basado en componentes puede verse como una extensión natural de la programación orienta a objetos dentro del ámbito de los sistemas abiertos y distribuidos. Este paradigma se basa en el uso de los componentes software como entidades básicas del modelo, entendiendo por componente “una unidad de composición de aplicaciones software que posee un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes, de forma independiente en tiempo y espacio”.

 

A continuación presento un mapa conceptual sobre el proceso de software así como un cuestionario contestado de evaluación.

 

 

Conclusión

Creo que la diversidad de los proyectos que se desarrollan ha sido el principal factor en la creación de distintos métodos de desarrollo de software. Por eso es importante conocer los métodos existentes para así saber cuál utilizar a la hora de desarrollar algún software, eligiendo o creando el que mejor se adapte a las características y necesidades únicas del proyecto; de esta manera garantizaremos nuestra mejor respuesta al problema de desarrollo planteado.

Referencias

• Esteller Víctor, Procesos de desarrollo de software y materiales educativos compuratizados, Revista de Tecnología de Informática, Venezuela, 2012.
• Metodologías y procesos de análisis de software, Capítulo 2, UNAM.
• Bertoa Manuel F., Troya José M., Vallecillo Antonio; Aspectos de Calidad en el Desarrollo de Software Basado en Componentes; Departamento de Lenguajes y Ciencias de la Computación; Universidad de Málaga.
• Weitzenfeld Ridel, Ingeniería de software: el proceso para el desarrollo de software, ITAM, 2007.

1)Métodos Ágiles de Programación

Introducción

En los años 90 hubo varios desarrolladores de software que notaron que los métodos convencionales de planificación de proyectos no se adecuaban de manera correcta a los pequeños y medianos trabajos, por lo que empezaron a desarrollar nuevas métodos de desarrollar estos proyectos. Estos métodos ágiles de programación se basaban en nuevos paradigmas de adaptabilidad, de entregas y de planificación. A continuación presento un mapa conceptual sobre los métodos ágiles de programación y un cuestionario sobre el mismo tema.

Desarrollo

Las metodologías tradicionales de desarrollo de software son orientadas por planeación. Inician el desarrollo de un proyecto con un riguroso proceso de elicitación de requerimientos, previo a etapas de análisis y diseño. Con esto tratan de asegurar resultados con alta calidad circunscritos a un calendario.

 En las metodologías tradicionales se concibe un solo proyecto, de grandes dimensiones y estructura definida; se sigue un proceso secuencial en una sola dirección y sin marcha atrás; el proceso es rígido y no cambia; los requerimientos son acordados de una vez y para todo el proyecto, demandando grandes plazos de planeación previa y poca comunicación con el cliente una vez ha terminado ésta. En cambio las metodologías ágiles son flexibles, pueden ser modificadas para que se ajusten a la realidad de cada equipo y proyecto.

Los proyectos ágiles se subdividen en proyectos más pequeños mediante una lista ordenada de características. Cada proyecto es tratado de manera independiente y desarrolla un subconjunto de características durante un periodo de tiempo corto, de entre dos y seis semanas. La comunicación con el cliente es constante al punto de requerir un representante de él durante el desarrollo. Los proyectos son altamente colaborativos y se adaptan mejor a los cambios; de hecho, el cambio en los requerimientos es una característica esperada y deseada, al igual que las entregas constantes al cliente y la retroalimentación por parte de él. Tanto el producto como el proceso son mejorados frecuentemente. Los métodos ágiles más conocidos y empleados son:

Extreme Programming

La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de algunas prácticas como el juego de la planificación, entregas pequeñas, metáfora, diseño simple, pruebas, refactorización, programación en parejas, propiedad colectiva del código, integración continua entre otros.

Scrum

Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.

Adaptive Software Development

Esta metodología parte de la idea de que las necesidades del cliente son siempre cambiantes durante el desarrollo del proyecto (y posteriormente a su entrega). Su impulsor es Jim Highsmith, la novedad de esta metodología es que en realidad no es una metodología de desarrollo de software, sino un mé- todo (como un caballo de troya) a través del cual inculcar una cultura adaptativa a la empresa, ya que su velocidad de adaptación a los cambios marcará la diferencia entre una empresa próspera y una en declive. Los objetivos de esta metodología son cuatro:

1. Concienciar a la organización de que debe esperar cambio e incertidumbre y no orden y estabilidad.
2. Desarrollar procesos iterativos de gestión del cambio.
3. Facilitar la colaboración y la interacción de las personas a nivel interpersonal, cultural y estructural.
4. Marcar una estrategia de desarrollo rápido de aplicaciones pero con rigor y disciplina

Crystal methodologies

No se trata de una única metodología sino de un conjunto de ellas centradas en las personas que tienen que desarrollar el software, el equipo es la base de estas metodologías creadas por Alistair Cockburn. Desarrollar aplicaciones ha de ser como un juego en el que todos cooperan, aportan su parte de invención y se comunican. ¿Por qué olvidamos esta parte? Crystal establece una serie de políticas de trabajo en equipo (Methods) orientadas a fomentar la mejora de estas habilidades. Dependiendo del tamaño del equipo, se establece una metodología u otra designadas por color: Crystal Clear (para 3-8 personas), Crystal Yellow (para 10-20 personas), Crystal Orange (para 25-50), etc.

Feature Driven Development

Se basa en un ciclo muy corto de iteración, nunca superior a dos semanas, y en el que el análisis y los desarrollos están orientados a cumplir una lista de "características" (features) que tiene que tener el software a desarrollar.

A continuación se presenta un mapa conceptual realizado con el software cmap tools además de algunas preguntas resueltas.

1. Los métodos ágiles se utilizan en: --Desarrollo de Software
2. ¿Qué modelo de desarrollo de software utilizan los métodos ágiles? --Iterativo
3. ¿Cuáles son las principales características en las que se basa el método ágil? --Trabajo en equipo, adaptable, avances funcionales
4. ¿Cuáles son las características que diferencian al método ágil del convencional? --Adaptable en cualquier etapa del proyecto
5. En los métodos ágiles el cliente: --Se incorpora al equipo de trabajo

Conclusión

Es notorio que los métodos ágiles de programación son de inmensa utilidad cuando deseamos llevar a cabo proyectos cortos o medianos, y por eso es importante conocerlos y estar preparado para usarlos. Es de primordial importancia que los proyectos se realicen de la manera más efectiva posible, y estos métodos son una herramienta poderosa para ayudarnos a lograr nuestro cometido.

Referencias

• http://www.willydev.net/descargas/prev/TodoAgil.Pdf
• Dingsøyr, Torgeir; Dybå, Tore; Brede Moe, Nils. Agile Software Development: Current Research and Future Directions. 2010.
• http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf
• Jorge F., Introducción a las metodologías ágiles, otras formas de analizar y desarrollar, Universitat Oberta de Catalunya.

4) Pruebas de Integración y Sistema

Introducción

Las pruebas del software sirven para detectar posibles errores en las aplicaciones. Podemos dividir las pruebas de software en:

• Pruebas unitarias.
• Pruebas de integración
• Pruebas de sistema
• Pruebas de aceptación

 

Desarrollo

 

Pruebas de Integración

En el ámbito del desarrollo de software, estas pruebas se realizan posteriores a las pruebas unitarias y antes de de las pruebas de sistema. Consisten en realizar pruebas para verificar que un conjunto de elementos unitarios de software funcionan juntos. En esta fase de las pruebas, los módulos individuales son combinados y probados como un grupo.

 Pruebas de Sistema

Cualquier pieza de software completo, desarrollado o adquirido, puede verse como un sistema que debe probarse, ya sea para decidir acerca de su aceptación, para analizar efectos globales o para estudiar aspectos específicos de su comportamiento, tales como seguridad y rendimiento. A éste tipo de pruebas donde se estudia el producto completo se les llama Pruebas de Sistema.

Usualmente es de caja negra, especialmente si quien prueba no tiene acceso al código fuente del producto a probar, que es lo más frecuente.

Conclusión

Las pruebas tanto de integración como de sistema son cruciales para poder llevar a cabo un proyecto exitoso, ya que es muy necesario que las partes desarrolladas individualmente se comuniquen de manera correcta entre sí, y que puedan funcionar en su conjunto como una unidad.

Referencias

• G. Myers. The art of software testing. Wiley, 2004.
• Jacobson, Ivar, Booch, Grady, Rumbaugh, James. El Proceso Unificado de Desarrollo de Software. Addison Wesley, 2000.
• Lambuth, Mark. Bug Fishing. http://embedded.com.

3) Casos de Prueba

Introducción

 

En el campo de la gestión tradicional de proyectos de software, surgió hace poco una filosofía estratégica que se centra en mejorar el diseño de los casos de prueba, y que llamó la atención generalizada de los interesados en la gestión de proyectos y en la prueba del software.

Actualmente, la gestión de proyectos de software es una de las tareas más importantes en la industria de las tecnologías de la información, y más aún si el objetivo es desarrollar productos de calidad. En esa gestión, la prueba es una de las fases más importantes, y en ésta, lo que requiere más cuidado y dedicación es el diseño de los casos de prueba, por lo que es necesario estudiar cómo diseñarlos y escribirlos mejor.  (Aristegui, 2010).

Desarrollo

 

 Pruebas de Caja Blanca

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. El testeador escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados. Al estar basadas en una implementación concreta, si ésta se modifica, por regla general las pruebas también deberán rediseñarse.
Aunque las pruebas de caja blanca son aplicables a varios niveles —unidad, integración y sistema—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden testear los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema. A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Pruebas de Caja Negra

En teoría de sistemas y física, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

En programación modular, donde un programa (o un algoritmo) es dividido en módulos, en la fase de diseño se buscará que cada módulo sea una caja negra dentro del sistema global que es el programa que se pretende desarrollar, de esta manera se consigue una independencia entre los módulos que facilita su implementación separada por un equipo de trabajo donde cada miembro va a encargarse de implementar una parte (un módulo) del programa global; el implementador de un módulo concreto deberá conocer como es la comunicación con los otros módulos (la interfaz), pero no necesitará conocer como trabajan esos otros módulos internamente; en otras palabras, para el desarrollador de un módulo, idealmente, el resto de módulos serán cajas negras. En pruebas de software, conociendo una función específica para la que fue diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la función, actuando sobre ella como una caja negra, proporcionando unas entradas y estudiando las salidas para ver si concuerdan con las esperadas.

Diagramas

A continuación tomaré un diagrama de flujo ejemplificando un software, a partir de este construiré un grafo del cual obtendré todos los caminos posibles para el programa.

Diagrama de flujo

Diagrama de Nodos (Grafo)

 Caminos
A continuación una lista de todos los caminos del programa, usando el número de proceso, en total encontré 11 caminos:

• I,F
• I,1,2,F
• I,1,2,3,F
• I,1,3,F
• I,1,3,2,F
• I,2,F
• I,2,3,F
• I,3,F
• I,3,2,F
• I,4,5,F
• I,4,6,F

Conclusión

Al desarrollar cualquier tipo de software es muy importante esforzarse en realizar el diseño de pruebas de la mejor manera posible, ya que son estas nuestra principal herramienta para evitar posibles desastres y fallos en el software. Ser riguroso y trabajar en este aspecto puede prevenir que posteriormente se deba realizar un trabajo aún más extenso de corrección de errores.

Referencias

1. Aristegui, José. Los casos de prueba en la prueba del software, Revista Digital Lámpsakos, No.3, pp. 27-34, Chile 2010.
2. Williams, Laurie. White-Box Testing. 2006.