Pruebas de caja negra

 Son un enfoque a las pruebas donde los examinadores no tienen acceso al código fuente de un sistema o sus componentes. Las pruebas se derivan de la especificación del sistema.

Las pruebas de caja negra, también llamadas pruebas de comportamiento, se enfocan en los requerimientos funcionales del software; es decir, las técnicas de prueba de caja negra le permiten derivar conjuntos de condiciones de entrada que revisarán por completo todos los requerimientos funcionales para un programa. Las pruebas de caja negra no son una alternativa para las técnicas de caja blanca. En vez de ello, es un enfoque complementario que es probable que descubra una clase de errores diferente que los métodos de caja blanca. 

Las técnicas más comunes de caja negra son:

Métodos de prueba basados en gráficos. La prueba de software comienza con la creación de un gráfico de objetos importantes y sus relaciones, y luego diseña una serie de pruebas que cubrirán el gráfico, de modo que cada objeto y relación se revise y se descubran errores.

Partición de equivalencia (posibles valores divididos en clases, valores de entrada y valores de salida). Se agrupan todos los valores para los cuales se espera que el programa tenga un comportamiento común (rango de valores), y esa es una clase de equivalencia, existen clases de equivalencia válidas y clases de

equivalencias inválidas.

Valores límite. Complementan a la partición equivalente, se debe prestar mucha atención en que los

límites deben estar correctamente definidos y programados.

Transición de estado. La transición de estados nos enuncia que todo sistema se mueve por transiciones de

un paso a otro, nos podemos guiar por las transacciones válidas y las transiciones inválidas.

Tablas de decisión. Estas pruebas consideran que para encontrar el resultado esperado deben estar en

conjunto varias condiciones que son los detonadores del resultado, llamado como causa y efecto.

Las pruebas de caja negra intentan encontrar errores en las categorías siguientes: 

1) funciones incorrectas o faltantes

2) errores de interfaz

3) errores en las estructuras de datos o en el acceso a bases de datos externas

4) errores de comportamiento o rendimiento

5) errores de inicialización y terminación.

Pruebas de Caja Blanca

Las inspecciones de programa son una idea antigua y la mayoría de estudios y experimentos indican que las inspecciones son más efectivas para el descubrimiento de defectos, que para las pruebas del programa. 

Sin embargo, las inspecciones no sustituyen las pruebas del software, ya que no son eficaces para descubrir defectos que surjan por interacciones inesperadas entre diferentes partes de un programa, problemas de temporización o dificultades con el rendimiento del sistema.

Las pruebas de caja blanca son un enfoque donde las pruebas se basan en el conocimiento de la estructura del programa y sus componentes. El acceso al código fuente es esencial para las pruebas de caja blanca.

Enlace al mapa:

https://coggle.it/diagram/X5ZteIWuKyqwkkvb/t/-/64673c76328a4e5059f947489c73b386d4aa8fbb1f1736b903e99f68b2a3b7be

Mapa de Telaraña Fundamentos de Pruebas

 

Comparativo pruebas de software

 

Resumen Estrategia de prueba del software

 Estrategia de prueba del software. Visión general.

Una estrategia para probar software puede verse como una espiral. La prueba de unidad comienza en el vértice de la espiral y se concentra en cada unidad del software como se implementó en el código fuente.  La prueba avanza al moverse hacia afuera a lo largo de la espiral, hacia la prueba de integración, donde el enfoque se centra en el diseño y la construcción de la arquitectura del software. Al dar otra vuelta hacia afuera de la espiral, se encuentra la prueba de validación, donde los requerimientos establecidos como parte de su modelado se validan confrontándose con el software que se construyó. Finalmente, se llega a la prueba del sistema, donde el software y otros elementos del sistema se prueban como un todo. Para probar el software de cómputo, se avanza en espiral hacia afuera en dirección de las manecillas del reloj a lo largo de líneas que ensanchan el alcance de las pruebas con cada vuelta. Mientras que para el para desarrollar software de computadoras, se avanza en espiral hacia adentro (contra las manecillas del reloj) a lo largo de una línea que reduce el nivel de abstracción en cada vuelta.

Con la técnica de considerar el proceso desde un punto de vista procedural, las pruebas dentro del contexto de la ingeniería del software en realidad son una serie de cuatro pasos que se implementan de

manera secuencial.

 Inicialmente, las pruebas se enfocan en cada componente de manera individual, lo que garantiza que funcionan adecuadamente como unidad. De ahí el nombre de prueba de unidad. Esta prueba utiliza mucho de las técnicas de prueba que ejercitan rutas específicas en una estructura de control de componentes para asegurar una cobertura completa y la máxima detección de errores. A continuación, los componentes deben ensamblarse o integrarse para formar el paquete de software completo. La prueba de integración aborda los conflictos asociados con los problemas duales de verificación y construcción de programas. 

Durante la integración, se usan más las técnicas de diseño de casos de  prueba que se enfocan en entradas y salidas, aunque también pueden usarse técnicas que ejercitan rutas de programa específicas para asegurar la cobertura de las principales rutas de control. Después de integrar (construir) el software, se realiza una serie de pruebas de orden superior. Deben evaluarse criterios de validación (establecidos durante el análisis de requerimientos). La prueba de validación proporciona la garantía final de que el software cumple con todos los requerimientos informativos, funcionales, de comportamiento y de rendimiento.

Criterios para completar las pruebas

Cada vez que se analiza la prueba del software, surge una pregunta clásica: “¿cuándo terminan

las pruebas?, ¿cómo se sabe que se ha probado lo suficiente?”.Una respuesta a la pregunta es: “nunca se termina de probar; la carga simplemente pasa de usted (el ingeniero de software) al usuario final”. Cada vez que el usuario ejecuta un programa de cómputo, el programa se pone a prueba. Este instructivo hecho subraya la importancia de otras actividades a fin de garantizar la calidad del software. Otra respuesta (un tanto cínica, mas no obstante precisa) es: “las pruebas terminan cuando se agota el tiempo o el dinero”.

Otro enfoque sugiere la utilización de un método que sea mas confiable que la simple intuición, entonces se han realizado propuestas como: 

• El uso de técnicas estadísticas que ejecutan una serie de pruebas derivadas de una muestra estadística de todas las posibles ejecuciones de programa por parte de todos los usuarios de una población objetivo.
• El uso del modelado estadístico y la teoría de confiabilidad del software para predecir cuándo están completas las pruebas.

ASPECTOS ESTRATÉGICOS

 Una estrategia de software triunfará cuando quienes prueban el software:

• Especifican los requerimientos del producto en forma cuantificable mucho antes de comenzar con las pruebas.
• Establecen de manera explícita los objetivos de las pruebas.
• Entienden a los usuarios del software y desarrollan un perfil para cada categoría de usuario. 
• Desarrollan un plan de prueba que enfatice “pruebas de ciclo rápido”.
• Construyen software “robusto” que esté diseñado para probarse a sí mismo. 
• Usan revisiones técnicas efectivas como filtro previo a las pruebas. 
• Realizan revisiones técnicas para valorar la estrategia de prueba y los casos de prueba.
• Desarrollan un enfoque de mejora continuo para el proceso de prueba.

ESTRATEGIAS DE PRUEBA PARA SOFTWARE CONVENCIONAL

Una estrategia de prueba que eligen la mayoría de los equipos de software se coloca entre los dos extremos. Toma una visión incremental de las pruebas, comenzando con la de unidades de programa individuales, avanza hacia pruebas diseñadas para facilitar la integración de las unidades y culmina con pruebas que ejercitan el sistema construido. 

Prueba de unidad

La prueba de unidad enfoca los esfuerzos de verificación en la unidad más pequeña del diseño de software: el componente o módulo de software. Al usar la descripción del diseño de componente como guía, las rutas de control importantes se prueban para descubrir errores dentro de la frontera del módulo. La relativa complejidad de las pruebas y los errores que descubren están limitados por el ámbito restringido que se establece para la prueba de unidad. Las pruebas de unidad se enfocan en la lógica de procesamiento interno y de las estructuras de datos dentro de las fronteras de un componente.

Consideraciones de las pruebas de unidad.

 La interfaz del módulo se prueba para garantizar que la información fluya de manera adecuada hacia y desde la unidad de software que se está probando.  Las estructuras de datos locales se examinan para asegurar que los datos almacenados temporalmente mantienen su integridad durante todos los pasos en la ejecución de un algoritmo. Todas las rutas independientes a través de la estructura de control se ejercitan para asegurar que todos los estatutos en un módulo se ejecuten al menos una vez. Las condiciones de frontera se prueban para asegurar que el módulo opera adecuadamente en las fronteras establecidas para limitar o restringir el procesamiento. Y, finalmente, se ponen a prueba todas las rutas para el manejo de errores.

Procedimientos de prueba de unidad.

Las pruebas de unidad por lo general se consideran como adjuntas al paso de codificación. El diseño de las pruebas de unidad puede ocurrir antes de comenzar la codificación o después de generar el código fuente. La revisión de la información del diseño proporciona una guía para establecer casos de prueba que es probable que descubran errores en cada una de las categorías analizadas anteriormente. Cada caso de prueba debe acoplarse con un conjunto de resultados esperados.

Puesto que un componente no es un programa independiente, con frecuencia debe desarrollarse software controlador y/o de resguardo para cada prueba de unidad.

Las pruebas de unidad se simplifican cuando se diseña un componente con alta cohesión. Cuando un componente aborda una sola función, el número de casos de prueba se reduce y los errores pueden predecirse y descubrirse con mayor facilidad.

Pruebas de integración

Las pruebas de integración son una técnica sistemática para construir la arquitectura del software mientras se llevan a cabo pruebas para descubrir errores asociados con la interfaz. El objetivo es tomar los componentes probados de manera individual y construir una estructura de programa que se haya dictado por diseño.

Con frecuencia existe una tendencia a intentar la integración no incremental, es decir, a construir el programa usando un enfoque de big bang, lo cual ante la aparición de errores y debido a la extensión del desarrollo termina en un caos y un bucle de revisiones. La integración incremental es la antítesis del enfoque big bang. El programa se construye y prueba en pequeños incrementos, donde los errores son más fáciles de aislar y corregir; las interfaces tienen más posibilidades de probarse por completo; y puede aplicarse un enfoque de prueba sistemático. 

Integración descendente.

La prueba de integración descendente es un enfoque incremental a la construcción de la arquitectura de software. Los módulos se integran al moverse hacia abajo a través de la jerarquía de control, comenzando con el módulo de control principal programa principal). Los módulos subordinados al módulo de control principal se incorporan en la estructura en una forma de primero en profundidad o primero en anchura.

 la integración primero en profundidad integra todos los componentes sobre una ruta de control mayor de la estructura del programa.  La integración primero en anchura incorpora todos los componentes directamente subordinados en cada nivel, y se mueve horizontalmente a través de la estructura.

 El proceso de integración se realiza en una serie de cinco pasos:

1. El módulo de control principal se usa como un controlador de prueba y los representantes (stubs) se sustituyen con todos los componentes directamente subordinados al módulo de control principal.
3. Dependiendo del enfoque de integración seleccionado (es decir, primero en profundidad o anchura), los representantes subordinados se sustituyen uno a la vez con componentes reales.
4. Las pruebas se llevan a cabo conforme se integra cada componente.
5. Al completar cada conjunto de pruebas, otro representante se sustituye con el componente real.
6. Las pruebas de regresión (que se analizan más adelante en esta sección) pueden realizarse para asegurar que no se introdujeron nuevos errores.

Integración ascendente. 

La prueba de integración ascendente, como su nombre implica, comienza la construcción y la prueba con módulos atómicos (es decir, componentes en los niveles inferiores dentro de la estructura del programa). Puesto que los componentes se integran de abajo hacia arriba, la funcionalidad que proporcionan los componentes subordinados en determinado nivel siempre está disponible y se elimina la necesidad de representantes (stubs). 

Una estrategia de integración ascendente puede implementarse con los siguientes pasos:

1. Los componentes en el nivel inferior se combinan en grupos (en ocasiones llamados construcciones o builds) que realizan una subfunción de software específica.
2. Se escribe un controlador (un programa de control para pruebas) a fin de coordinar la entrada y salida de casos de prueba.
3. Se prueba el grupo. 
4. Los controladores se remueven y los grupos se combinan moviéndolos hacia arriba en la estructura del programa.

Conforme la integración avanza hacia arriba, se reduce la necesidad de controladores de prueba separados. De hecho, si los dos niveles superiores del programa se integran de manera descendente, el número de controladores puede reducirse de manera sustancial y la integración de grupos se simplifica enormemente.

Prueba de regresión. 

Cada vez que se agrega un nuevo módulo como parte de las pruebas de integración, el software cambia. Se establecen nuevas rutas de flujo de datos, ocurren nuevas operaciones de entrada/salida y se invoca nueva lógica de control. Dichos cambios pueden causar problemas con las funciones que anteriormente trabajaban sin fallas. En el contexto de una estrategia de prueba de integración, la prueba de regresión es la nueva ejecución de algún subconjunto de pruebas que ya se realizaron a fin de asegurar que los cambios no propagaron efectos colaterales no deseados.

 Las pruebas de regresión ayudan a garantizar que los cambios (debidos a pruebas o por otras razones) no introducen comportamiento no planeado o errores adicionales.

Las pruebas de regresión se pueden realizar manualmente, al volver a ejecutar un subconjunto de todos los casos de prueba o usando herramientas de captura/reproducción automatizadas.  Las herramientas de captura/reproducción permiten al ingeniero de software capturar casos de prueba y resultados para una posterior reproducción y comparación.  La suite de prueba de regresión (el subconjunto de pruebas que se va a ejecutar) contiene tres clases diferentes de casos de prueba:

• Una muestra representativa de pruebas que ejercitará todas las funciones de software.
• Pruebas adicionales que se enfocan en las funciones del software que probablemente resulten afectadas por el cambio.
• Pruebas que se enfocan en los componentes del software que cambiaron.

Prueba de humo. 

La prueba de humo es un enfoque de prueba de integración que se usa cuando se desarrolla software de producto. Se diseña como un mecanismo de ritmo para proyectos críticos en el tiempo, lo que permite al equipo del software valorar el proyecto de manera frecuente.

En esencia, el enfoque de prueba de humo abarca las siguientes actividades:

• Los componentes de software traducidos en código se integran en una construcción. 
• Se diseña una serie de pruebas para exponer los errores que evitarán a la construcción realizar adecuadamente su función.
• La construcción se integra con otras construcciones, y todo el producto (en su forma actual) se somete a prueba de humo diariamente.

La prueba de humo proporciona algunos beneficios cuando se aplica sobre proyectos de

software complejos y cruciales en el tiempo:

• Se minimiza el riesgo de integración. 
• La calidad del producto final mejora. 
• El diagnóstico y la corrección de errores se simplifican.
• El progreso es más fácil de valorar.

Opciones estratégicas. 

La selección de una estrategia de integración depende de las características del software y, en ocasiones, del calendario del proyecto. En general, un enfoque combinado (a veces llamado prueba sándwich), que usa pruebas descendentes para niveles superiores de la estructura del programa acopladas con pruebas ascendentes para niveles subordinados, puede ser el mejor arreglo.

Conforme se realiza la integración, quien efectúa la prueba debe identificar los módulos críticos. Un módulo crítico tiene una o más de las siguientes características: 1) aborda muchos requerimientos de software, 2) tiene un alto nivel de control (reside relativamente alto en la estructura del programa), 3) es complejo o proclive al error o 4) tiene requerimientos de rendimiento definidos. Los módulos críticos deben probarse tan pronto como sea posible. Además, las pruebas de regresión deben enfocarse en la función del módulo crítico.

Productos de trabajo de las pruebas de integración.

Un plan global para integración del software y una descripción de las pruebas específicas se documentan en una Especificación de pruebas. Este producto de trabajo incorpora un plan de prueba y un procedimiento de prueba, y se vuelve parte de la configuración del software. La prueba se divide en fases y construcciones que abordan características del software funcionales y de comportamiento específicas.

.Los siguientes criterios y pruebas correspondientes se aplican a todas las fases de prueba:

• Integridad de interfaz. Las interfaces internas y externas se prueban conforme cada módulo (o grupo) se incorpora en la estructura.
• Validez funcional. Se realizan pruebas diseñadas para descubrir errores funcionales ocultos.
• Contenido de la información. Se realizan pruebas diseñadas para descubrir errores ocultos asociados con las estructuras de datos locales o globales.
• Rendimiento. Se realizan pruebas diseñadas para verificar los límites del rendimiento establecidos durante el diseño del software.

Como parte del plan de prueba, también se discute un calendario para la integración, el desarrollo de software de sobrecarga del sistema y temas relacionados. Una breve descripción del software de sobrecarga (representantes y controladores) se concentra en las características que pueden requerir de un esfuerzo especial. Finalmente, se describe el entorno y los recursos de la prueba. Configuraciones inusuales de hardware, simuladores peculiares y herramientas o técnicas de prueba especial son algunos de los muchos temas que también pueden analizarse.

A continuación se describe el procedimiento de prueba detallado que se requiere para lograr el plan de prueba. Se señala el orden de la integración y las pruebas correspondientes en cada paso de ésta. También se incluye una lista de todos los casos de prueba (anotados para referencia posterior) y los resultados esperados.

En un Reporte de prueba, que puede anexarse a la Especificación pruebas si se desea, se registra una historia de resultados, problemas o peculiaridades de prueba reales. La información contenida en esta sección puede ser vital durante el mantenimiento del software. También se presentan las referencias y apéndices apropiados.

Referencia:

Pressman, Roger, S. (2010). Ingeniería de software. McGRAW-HILL. 

Mapa mental V&V del software

 

https://coggle.it/diagram/X4fYxDJL5oztUOJd/t/pruebas-de-software/17928de7a10e85681885cc663da07096e10ad5df669cd2d64147d90f95e0636e

Resumen de la implementación de una metodología ágil

Se propone una metodología llamada AgEnD que del Ingles Agile Enhanced Development significa Desarrollo Mejorado por Agilidad. En este resumen se hace un recuento por la descripción de esta metodología.

Roles definidos

En el uso de las metodologías ágiles es muy importante definir los roles de todas las personas que intervienen en el proyecto. Los roles son los que aglutinan todas las actividades realizadas de las personas que están incluidas en el desarrollo del software pero también a todas aquellas que se vean afectados por el proyecto.

Los roles en los equipos ágiles no son exclusivamente llevados a cabo por una sola persona como los desarrolladores, por otro lado hay personas que realizan diferentes roles por ejemplo arquitecto/Escritor técnico. El rol del líder lo realiza una sola persona y dirige los recursos según sus aptitudes en cada iteración.

Patrocinante (Executive Sponsor)

Actividades:  tiene a su cargo el soporte gerencial del proyecto; es el encargado de proveer, comunicar y mantener actualizada la Visión del proyecto; provee el presupuesto para la viabilidad económica del desarrollo; es responsable por la consecución del proyecto del lado del cliente. 

Importancia del rol: es esencial para el éxito del mismo, ya que un software que no tiene aceptación dentro de la organización que lo financia jamás llegará a ser construido en tiempo, forma y con

consentimiento de los usuarios, no siendo utilizado eventualmente si se concreta el proyecto.

Líder del Proyecto (Project Manager)

Actividades:  está a su cargo la planificación del proyecto a lo largo de todo el ciclo de vida,  asignar recursos y delegar responsabilidades en el equipo ágil, incluida la planificación en detalle de cada iteración. Es el responsable de un trabajo en equipo eficiente, monitorea el progreso y establece estrategias y metas.

Importancia del rol: es el líder de proyecto y representa la cara visible del equipo de desarrollo, es el nexo existente entre la gerencia y el equipo de desarrollo.

Experto en el Dominio (Domain Expert)

Actividades: Es la persona que tiene el conocimiento del negocio y la encargada de brindar asesoría contribuyendo al modelado del sistema que llevan a cabo los Analistas durante la ingeniería de requerimientos. Participará junto con los Testers en la definición del contenido de las pruebas funcionales a ser

realizadas; será el responsable de la aprobación de las pruebas de aceptación por cada release entregado. 

Importancia del rol: el Experto en el Dominio permite al Equipo de Desarrollo aprender sobre el negocio para el cual está siendo construida la aplicación; son encargados de resolver cualquier cuestión relacionada con la funcionalidad de la aplicación junto con los Analistas.

Destrezas:  el Experto en el Dominio deberá conocer en detalle el negocio para prestar respuesta a cualquier duda que pueda surgir del mismo. En general será un miembro de la empresa Cliente. 

Coordinador (Mentor)

Actividades: tiene a su cargo la supervisión del proceso, y cualquier actividad orientada al mejoramiento del mismo. Durante las primeras etapas de utilización de AgEnD supervisará la implementación del proceso. 

Importancia del rol: en las metodologías ágiles este rol permite reforzar la adherencia al proceso en aquellos momentos en que el tiempo apremia y se suele caer en el modelo Codificar y Probar. 

Destrezas:  el Experto en el Dominio deberá conocer en detalle el negocio para prestar respuesta a cualquier duda que pueda surgir del mismo.

Analista (Functional Analyst)

Actividades: tiene a su cargo el relevamiento, mediante el cual se obtienen los requerimientos de la aplicación a ser construidos en cada iteración; realiza la especificación de los requerimientos; prepara el

documento de Visión.

Importancia del rol:  el aprendizaje del dominio de la aplicación y de los requerimientos que deberá tener la misma son claves para el éxito del proyecto y la aceptación del mismo por parte del usuario.

Destrezas: el Analista deberá tener amplio conocimiento de técnicas de relevamiento, así como aptitudes sociales que le permitan vencer el “Síndrome del Usuario y el Desarrollador”.

Arquitecto (Architect)

Actividades: tiene a su cargo la definición de la arquitectura que guiará el desarrollo, y de la continua refinación de la misma en cada iteración; deberá construir cualquier prototipo necesario para probar aspectos riesgosos desde el punto de vista técnico en el proyecto; definirá los lineamientos generales del diseño y la implementación. 

Importancia del rol: el arquitecto puede ser considerado como el Experto en la parte técnica del

desarrollo y debe mantener a todo el equipo en conocimiento de los lineamientos fundamentales de la construcción.

Destrezas: el Arquitecto deberá tener una buena formación técnica, contar con experiencia en las herramientas y técnicas utilizadas; aptitudes comunicacionales son deseadas para que la arquitectura sea comunicada a todos los miembros del equipo.

Programador o Desarrollador (Designer - Programmer) 

Actividades: tiene a su cargo la codificación de los componentes a desarrollar en la iteración; debe crear y ejecutar los tests unitarios realizados sobre el código desarrollado; es responsable de las clases que

ha desarrollado debiendo documentarlas, actualizarlas ante cambios y mantenerlas bajo el control de configuración de las mismas mediante la herramienta de SCM utilizada. 

Importancia del rol: el Programador es la persona que tiene los materiales y lleva a cabo la implementación de los casos de uso en el lenguaje de programación elegido; como en general, es el paradigma de objetos el que está imponiéndose en la industria de IS/IT, el Programador definirá las clases y métodos que realicen los correspondientes casos de uso.

Destrezas: el Analista deberá tener amplio conocimiento de las herramientas de desarrollo, del lenguaje de programación, de los aspectos técnicos involucrados. 

Tester

Actividades: tiene a su cargo la generación de pruebas funcionales a partir de los requerimientos extraídos por los Analistas. 

Importancia del rol: crea, ejecuta, analiza y mantiene el conjunto de pruebas automatizadas y manuales que son utilizados.

Destrezas: el Tester deberá tener amplio conocimiento de técnicas de testing, deberá conocer a fondo la aplicación que testeará. Asimismo, deberá tener conocimientos de programación para trabajar con las

pruebas automatizadas.

Administrador del Conocimiento (Knowledge Manager)

Actividades: tiene a su cargo la captura, refinamiento, empaquetamiento, y transferencia del conocimiento, ya sea tácito o explícito, en la organización. 

Importancia del rol: Su importancia consiste en la capacidad del equipo de desarrollo de aprender de la experiencia que éste y que otros equipos dentro de la organización generan a diario durante el transcurso de los proyectos. Mediante esta disciplina se logra el reuso de dicho conocimiento.

Destrezas: el Administrador del Conocimiento debe poseer aptitudes en comunicación para poder capturar el conocimiento de aquellas personas que lo generan. 

Referencia:

Hernan, Schenone. (2004). Diseño de una metodología ágil de desarrollo de software. Facultad de Ingeniería. Universidad de Buenos Aires. 

Diseño de una metodología ágil

 Resumen de los temas estudiados.

Metodologías ágiles de proyectos de software.

Las evolución de los sistemas de software esta en un continuo perfeccionamiento y una búsqueda de eficiencia en los métodos de producción. Siguiendo la ley de Moore los componentes de hardware acaban duplicando su capacidad al doble cada año, entonces cada vez tenemos equipos más avanzados, más potentes con una alta capacidad de procesamiento. Por tanto se  reducen los costos de producción de hardware y a su vez esto acelera la popularización del uso de los computadores sacándolos de los laboratorios académicos y militares.

Durante la época de los 80's la necesidad de procesos de desarrollo ágil son cada vez mayores debido a la necesidad de aumentar la adaptabilidad de los proyectos a los cambios frecuentes de los requerimientos del mercado y así mismo basar los sistemas de producción y adecuarlos al cambio constante.

Debido a que las metodologías de producción industria estas no se pueden usar de la misma manera en personas que en máquinas, ya que la producción de software incluye a los primeros y el desarrollo de un producto requiere mayormente de máquinas. Las metodologías tradicionales estaban basadas en grandes esfuerzos divididos en etapas y que se basan en la producción de documentación extensa que comunica cada etapa del proceso y presenta un manejo rígido que hace que las personas y equipos se adecuen a la necesidad del proyecto aumentando las posibilidades de fracaso debido a la incompatibilidad de los procesos de producción.

En algunos tipos de software, como los sistemas de control críticos para la seguridad, donde es esencial un análisis completo del sistema, resulta oportuno un enfoque basado en un plan. Sin embargo, en un ambiente empresarial de rápido movimiento, esto llega a causar verdaderos problemas. Al momento en que el software esté disponible para su uso, la razón original para su adquisición quizás haya variado tan radicalmente que el software sería inútil a todas luces. Por lo tanto, para sistemas empresariales, son esenciales en particular los procesos de diseño que se enfocan en el desarrollo y la entrega de software rápidos.

En la década de 1980 IBM introdujo el desarrollo incremental. La entrada de los llamados lenguajes de cuarta generación, también en la misma década, apoyó la idea del software de desarrollo y entrega rápidos. Sin embargo, la noción prosperó realmente a finales de la década de 1990, con el desarrollo de la noción de enfoques ágiles como el DSDM, Scrum y la programación extrema. Los procesos de desarrollo del software rápido se diseñan para producir rápidamente un software útil. El software no se desarrolla como una sola unidad, sino como una serie de incrementos, y cada uno de ellos incluye una nueva funcionalidad del sistema.

En este contexto en 2001, 17 representantes de nuevas metodologías y críticos de los modelos de mejora basados en procesos se reunieron, convocados por Kent Beck, para discutir sobre el desarrollo de software. Estos profesionales, con una dilatada experiencia como aval, llevaban ya alrededor de una década utilizando técnicas que les fueron posicionando como líderes de la industria del desarrollo software. Conocían perfectamente las desventajas del clásico modelo en cascada donde primero se analiza, luego se diseña, después se implementa y, por ´ultimo (en algunos casos), se escriben algunos tests automáticos y se martiriza a un grupo de personas para que ejecuten manualmente el software, una y otra vez hasta la saciedad. En esta reunion se compone un documento llamado El manifiesto ágil que se compone de cuatro principios. Es pequeño pero bien cargado de significado:

Estamos descubriendo mejores formas para desarrollar software, al hacerlo y al ayudar a otros a hacerlo. Gracias a este trabajo llegamos a valorar:

• A los individuos y las interacciones sobre los procesos y las herramientas.
• Al software operativo sobre la documentación exhaustiva.
• La colaboración con el cliente sobre la negociación del contrato.
• La respuesta al cambio sobre el seguimiento de un plan.

Esto es, aunque exista valor en los objetos a la derecha, valoraremos más los de la izquierda.

 Probablemente el método ágil más conocido sea la programación extrema. Otros enfoques ágiles incluyen los de Scrum, Crystal Methodologies, Desarrollo de Software Adaptativo, DSDM y el desarrollo dirigido por características. El éxito de dichos métodos condujo a cierta integración con métodos más tradicionales de desarrollo, basados en el modelado de sistemas, lo cual resulta en la noción de modelado ágil y ejemplificaciones ágiles del Proceso Racional Unificado.

Principios y políticas del desarrollo ágil.

Los enfoques ágiles en el desarrollo de software consideran el diseño y la implementación como las actividades centrales en el proceso del software. Incorporan otras actividades en el diseño y la implementación, como la adquisición de requerimientos y pruebas. En contraste, un enfoque basado en un plan para la ingeniería de software identifica etapas separadas en el proceso de software con salidas asociadas a cada etapa. Las salidas de una etapa se usan como base para planear la siguiente actividad del proceso. La figura muestra las distinciones entre los enfoques ágil y el basado en un plan para la especificación de sistemas.

En un enfoque basado en un plan, la iteración ocurre dentro de las actividades con documentos formales usados para comunicarse entre etapas del proceso. Por ejemplo, los requerimientos evolucionarán y, a final de cuentas, se producirá una especificación de aquéllos. Esto entonces es una entrada al proceso de diseño y la implementación. En un enfoque ágil, la iteración ocurre a través de las actividades. Por lo tanto, los requerimientos y el diseño se desarrollan en conjunto, no por separado.

Un proceso de software dirigido por un plan soporta el desarrollo y la entrega incrementales. Es perfectamente factible asignar requerimientos y planear tanto la fase de diseño y desarrollo como una serie de incrementos. Un proceso ágil no está inevitablemente enfocado al código y puede producir cierta documentación de diseño. Para cierta parte del proyecto el equipo de desarrollo ágil puede incluir un “pico” de documentación donde, en vez de producir una nueva versión de un sistema, el equipo generará documentación del sistema.

De hecho, la mayoría de los proyectos de software incluyen prácticas de los enfoques ágil y basado en un plan. Para decidir sobre el equilibrio entre un enfoque basado en un plan y uno ágil, se deben responder algunas preguntas técnicas, humanas y organizacionales:

1. ¿Es importante tener una especificación y un diseño muy detallados antes de dirigirse a la implementación? Siendo así, probablemente usted tenga que usar un enfoque basado en un plan.
2. ¿Es práctica una estrategia de entrega incremental, donde se dé el software a los clientes y se obtenga así una rápida retroalimentación de ellos? De ser el caso, considere el uso de métodos ágiles.
3.  ¿Qué tan grande es el sistema que se desarrollará? Los métodos ágiles son más efectivos cuando el sistema logra diseñarse con un pequeño equipo asignado que se comunique de manera informal. Esto sería imposible para los grandes sistemas que precisan equipos de desarrollo más amplios, de manera que tal vez se utilice un enfoque basado en un plan.
4. ¿Qué tipo de sistema se desarrollará? Los sistemas que demandan mucho análisis antes de la implementación (por ejemplo, sistema en tiempo real con requerimientos de temporización compleja), por lo general, necesitan un diseño bastante detallado para realizar este análisis. En tales circunstancias, quizá sea mejor un enfoque basado en un plan.
5. ¿Cuál es el tiempo de vida que se espera del sistema? Los sistemas con lapsos de vida prolongados podrían requerir más documentación de diseño, para comunicar al equipo de apoyo los propósitos originales de los desarrolladores del sistema. Sin embargo, los defensores de los métodos ágiles argumentan acertadamente que con frecuencia la documentación no se conserva actualizada, ni se usa mucho para el mantenimiento del sistema a largo plazo. 
6. ¿Qué tecnologías se hallan disponibles para apoyar el desarrollo del sistema? Los métodos ágiles se auxilian a menudo de buenas herramientas para seguir la pista de un diseño en evolución. Si se desarrolla un sistema con un IDE sin contar con buenas herramientas para visualización y análisis de programas, entonces posiblemente se requiera más documentación de diseño.
7. ¿Cómo está organizado el equipo de desarrollo? Si el equipo de desarrollo está distribuido, o si parte del desarrollo se subcontrata, entonces tal vez se requiera elaborar documentos de diseño para comunicarse a través de los equipos de desarrollo. Quizá se necesite planear por adelantado cuáles son. 
8. ¿Existen problemas culturales que afecten el desarrollo del sistema? Las organizaciones de ingeniería tradicionales presentan una cultura de desarrollo basada en un plan, pues es una norma en ingeniería. Esto requiere comúnmente una amplia documentación de diseño, en vez del conocimiento informal que se utiliza en los procesos ágiles. 
9. ¿Qué tan buenos son los diseñadores y programadores en el equipo de desarrollo? Se argumenta en ocasiones que los métodos ágiles requieren niveles de habilidad superiores a los enfoques basados en un plan, en que los programadores simplemente traducen un diseño detallado en un código. Si usted tiene un equipo con niveles de habilidad relativamente bajos, es probable que necesite del mejor personal para desarrollar el diseño, siendo otros los responsables de la programación. 
10. ¿El sistema está sujeto a regulación externa? Si un regulador externo tiene que aprobar el sistema (por ejemplo, la Agencia de Aviación Federal [FAA] estadounidense aprueba el software que es crítico para la operación de una aeronave), entonces, tal vez se le requerirá documentación detallada como parte del sistema de seguridad.

Importancia de las metodologías ágiles.

Las empresas operan ahora en un entorno global que cambia rápidamente. En ese sentido, deben responder frente a nuevas oportunidades y mercados, al cambio en las condiciones económicas, así como al surgimiento de productos y servicios competitivos. El software es parte de casi todas las operaciones industriales, de modo que el nuevo software se desarrolla rápidamente para aprovechar las actuales oportunidades, con la finalidad de responder ante la amenaza competitiva. En consecuencia, en la actualidad la entrega y el desarrollo rápidos son por lo general el requerimiento fundamental de los sistemas de software. De hecho, muchas empresas están dispuestas a negociar la calidad del software y el compromiso con los requerimientos, para lograr con mayor celeridad la implementación que necesitan del software.

Debido a que dichos negocios funcionan en un entorno cambiante, a menudo es prácticamente imposible derivar un conjunto completo de requerimientos de software estable. Los requerimientos iniciales cambian de modo inevitable, porque los clientes encuentran imposible predecir cómo un sistema afectará sus prácticas operacionales, cómo interactuará con otros sistemas y cuáles operaciones de usuarios se automatizarán. Es posible que sea sólo hasta después de entregar un sistema, y que los usuarios adquieran experiencia con éste, cuando se aclaren los requerimientos reales. Incluso, es probable que debido a factores externos, los requerimientos cambien rápida e impredeciblemente. En tal caso, el software podría ser obsoleto al momento de entregarse.

Los procesos de desarrollo del software rápido se diseñan para producir rápidamente un software útil. El software no se desarrolla como una sola unidad, sino como una serie de incrementos, y cada uno de ellos incluye una nueva funcionalidad del sistema.

Los métodos de desarrollo ágil presentan las siguientes caracteristicas:

1. Los procesos de especificación, diseño e implementación están entrelazados. No existe una especificación detallada del sistema, y la documentación del diseño se minimiza o es generada automáticamente por el entorno de programación que se usa para implementar el sistema. El documento de requerimientos del usuario define sólo las características más importantes del sistema.

2. El sistema se desarrolla en diferentes versiones. Los usuarios finales y otros colaboradores del sistema intervienen en la especificación y evaluación de cada versión. Ellos podrían proponer cambios al software y nuevos requerimientos que se implementen en una versión posterior del sistema.

3. Las interfaces de usuario del sistema se desarrollan usando con frecuencia un sistema de elaboración interactivo, que permita que el diseño de la interfaz se cree rápidamente en cuanto se dibujan y colocan iconos en la interfaz. En tal situación, el sistema puede generar una interfaz basada en la Web para un navegador o una interfaz para una plataforma específica, como Microsoft Windows.

Métodos (Marcos de las metodologías ágiles).

XP.

Desarrollo adaptativo de software (DAS).

Scrum.

Método de desarrollo de sistemas dinámicos (MDSD) o (DSDM en Ingles)

Crystal Methods.

Desarrollo impulsado por las características (DIC) o (FDD en Ingles)

Bibliografia y referencias:

Jurado Carlos. Diseño ágil con TDD, iExpertos. 2010.

Pressman Roger. S, Ingeniería de Software, McGraw Hill, 2010.

Sommerville, Ian. Ingeniería de Software, Pearson Education, 2011.

Cockburn, A., Agile Software Development, Addison-Wesley, 2002.