Este documento describe tres modelos de ingeniería de software: el modelo en cascada, el modelo de prototipos y el modelo en espiral. El modelo en cascada sigue un flujo ordenado de fases donde la salida de una es la entrada de la siguiente. El modelo de prototipos utiliza versiones preliminares para demostrar y evaluar requisitos. El modelo en espiral es cíclico y permite corregir errores de manera continua a lo largo del desarrollo del proyecto.

1. Modelos de la ingeniería de Software
UNIDAD 2

2. Unidad 2
2.1 MODELO DE CAPACIDAD DE MADUREZ

3. INTRODUCCIÓN
 El modelo de capacidad y madurez o mejor
llamado CMM, CMMI o IMCM, es el modelo de
evaluación de procesos de una organización.
 Fue creado para los procesos elativos al software
por la Universidad Carnegie-Mellon para el SEI
(Software Engineering Institute).

4. EL MODELO CMMI
 A partir de Noviembre de 1986 el SEI desarrollo
una definición de un modelado de madures, la cual
fue publicada en 1987, esto a evolucionado hasta
febrero de 1993.
 Este modelo establece un conjunto de practicas o
procesos clave agrupados en Áreas Clave del
proceso (KPA-Key process Área). Para cada área
de proceso define un conjunto de practicas que
habrán de ser:

5. EL MODELO CMMI (CONT.)
Ejecutadas de
Definidas en Provistas de
un modo
un los medios y
sistemático, Medidas Verificadas
procedimiento formación
universal y
documentado necesarios
uniforme

6. EL MODELO CMMI (CONT.)
 A su vez estas Áreas de Proceso se
agrupan en cinco "niveles de madurez", de
modo que una organización que tenga
institucionalizadas todas las prácticas
incluidas en un nivel y sus inferiores, se
considera que ha alcanzado ese nivel de
madurez.

7. EL MODELO CMMI (CONT.)
• Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen
técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de
las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los
Inicial proyectos es impredecible.
• En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y
un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
Repetible
• Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre
grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se
Definido implementan técnicas de revisión por pares (peer reviews).
• Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de
modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
Gestionado
• La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el
proceso de innovación.
Optimizado

8. EL MODELO CMMI (CONT.)
 CMMI es un modelo para la mejora de procesos que proporciona a las
organizaciones los elementos esenciales para procesos eficaces. Las
mejores prácticas CMMI se publican en los documentos llamados
modelos. En la actualidad hay dos áreas de interés cubiertas por los
modelos de CMMI: Desarrollo y Adquisición.
CMMI para el Desarrollo
(DEV-CMMI): En él se
tratan procesos de CMMI para la adquisición (ACQ-
desarrollo de productos y CMMI): En él se tratan la gestión
servicios. de la cadena de suministro,
adquisición y contratación
externa en los procesos del
gobierno y la industria.

9. ÁREAS DEL PROCESO CMMI
 Análisis de causalidad y solución  Planificación de proyectos
 Configuration Management  Proceso y aseguramiento de
 Decisión de Análisis y Resolución calidad del producto
 Proyecto Integrado de Gestión  Integración de Producto
 Medición y Análisis  Gestión de proyectos
 Innovación organizacional y Cuantitativos
Despliegue  Gestión de requerimientos
 Definición de procesos  Requerimientos de Desarrollo
organizacionales  Gestión de Riesgos
 Enfoque en procesos  Gestión de Proveedores
organizacionales  Solución
 Rendimiento de procesos  Validación
organizacionales  Verificación
 Entrenamiento organizacional
 Vigilancia y Control de proyectos

10. REPRESENTACIONES:

11.  El modelo para ingeniería de sistemas (SE-
CMM) establece 6 niveles posibles de
capacidad para una de las 18 áreas de proceso
implicadas en la ingeniería de sistemas.
 No agrupa los procesos en 5 tramos para definir
el nivel de madurez de la organización, sino que
directamente analiza la capacidad de cada
proceso por separado.
 Es lo que se denomina un modelo continuo.

12. NIVELES DE CAPACIDAD DE LOS
PROCESOS (REPRESENTACIÓN CONTINUA)
Definido: Optimizarte:
Gestionado: Además de Además de ser
Además de ser un un proceso
Cuantitativam
ejecutarse, proceso ente
cuantitativame
Incompleto: nte gestionado,
el proceso gestionado se gestionado:
El proceso Ejecutado: de forma
se planifica, ajusta a la Además de ser
no se El proceso sistemática se
se revisa y política de un proceso
realiza, o no se ejecuta y procesos que definido se
revisa y
se evalúa modifica o
se consiguen se logra su existe en la controla
para cambia para
sus objetivo. organización, utilizando
comprobar adaptarlo a los
objetivos. alineada con técnicas
que cumple cuantitativas.
objetivos del
los las directivas negocio.
requisitos. de la Mejora
empresa. continua.

13. DIAGRAMA

14. COMPONENTES REQUERIDOS
Objetivo genérico: Los objetivos genéricos asociados
a un nivel de capacidad establecen lo que una
organización debe alcanzar en ese nivel de capacidad.
Objetivo específico: Los objetivos específicos se
aplican a una única área de proceso y localizan las
particularidades que describen que se debe
implementar para satisfacer el propósito del área de
proceso.

15. COMPONENTES ESPERADOS
Práctica genérica: Una Práctica específica: Una
práctica genérica se aplica práctica específica es una
a cualquier área de proceso actividad que se considera
porque puede mejorar el importante en la realización
funcionamiento y el control del objetivo específico al
de cualquier proceso. cual está asociado.

16. COMPONENTES INFORMATIVOS
Propósito
Elaboraciones
Notas
de prácticas
introductorias
genéricas
Ampliaciones
Nombres
de disciplina
Tablas de
relaciones
Sub-prácticas
práctica -
objetivo
Productos
Prácticas
típicos

17. Unidad 2
2.2 MARCO DE TRABAJO PARA EL PROCESO

18. INTRODUCCIÓN
 En esta sección es fácil denotar que el
marco de trabajo es sobre el cual se
trabajara, ya que contiene el conjunto de
actividades a realizar, de la cual se
desprenden tareas individuales.

19. PARTES DEL MARCO DE TRABAJO DEL PROCESO
Despliegue: El Comunicación: Esta
software se entrega actividad implica una
al cliente, quien intensa colaboración y
evalúa el producto comunicación con los
recibido y clientes, abarcando la
investigación de
proporciona requisitos y otras
información basada actividades relacionadas.
en su evaluación.
Planeación: Describe
Construcción: las tareas técnicas
Combina la que deben realizarse,
generación del los riesgos probables,
código y la los recursos que
realización de serán requeridos, los
pruebas necesarias productos del trabajo
para descubrir que han de
errores en el código. producirse y un
Modelado: Abarca la programa de trabajo.
creación de modelos
que permiten al
desarrollador y al
cliente entender mejor
los requisitos del
software y el diseño
que lograra
satisfacerlos.

20. PARTES DEL MARCO DE TRABAJO DEL PROCESO (CONT.)
Las actividades anteriores son útiles durante el
desarrollo de programas pequeños, la creación de
grandes aplicaciones en la red, y en la ingeniería de
sistemas basados en computadoras grandes y
complejas.
Los detalles del proceso del software serán muy
diferentes en cada caso, pero las actividades dentro
del marco permanecerán iguales.

21. ACTIVIDADES SOMBRILLA
Seguimiento y Preparación y
Aseguramiento Revisiones Gestión de la
control del Gestión del Gestión de la producción del
de la calidad técnicas Medición configuración
proyecto del riesgo reutilización producto de
del software formales del software
software trabajo

22. SEGUIMIENTO Y CONTROL DEL PROYECTO DEL SOFTWARE
 Permite que el equipo de software evalué el
progreso comparándolo con el plan del
proyecto y así tomar las acciones necesarias
para mantener el programa.

23. GESTIÓN DEL RIESGO
 Evalúa los riesgos que pudieran afectar los
resultados del proyecto o la calidad del
producto

24. ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
 Define y conduce las actividades requeridas
para asegurar la calidad del software

25. REVISIONES TÉCNICAS FORMALES
 Evalúa los productos del trabajo de la
ingeniería del software en un esfuerzo
encaminado a describir y eliminar los errores
antes de que estos se propaguen hacia la
siguiente acción o actividad

26. MEDICIÓN
 Define y recolecta mediciones del proceso,
el proyecto y el producto para ayudar al
equipo a entregar software que satisfaga las
necesidades del cliente; se puede usar en
conjunto con todas las otras actividades del
marco de trabajo o actividades sombrilla

27. GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
 Maneja los efectos del cambio a través del
proceso del software

28. GESTIÓN DE LA REUTILIZACIÓN
 Define los criterios para la reutilización de
productos del trabajo y establece
mecanismos para la creación de
componentes reutilizables.

29. PREPARACIÓN Y PRODUCCIÓN DEL PRODUCTO DE TRABAJO
 Abarca las actividades requeridas para crear
productos del trabajo como modelos,
documentos, registros, formatos y listas.

30. Las actividades sombrilla se aplican en el proceso del
software.
La aplicación inteligente de cualquier modelo de
proceso del software debe reconocer que la
adaptación es esencial para el éxito de esta actividad.

31. El flujo global de
actividades y tareas,
y las
interdependencias
entre las actividades
y las tareas. El grado en el cual
El grado en el cual
las tareas de trabajo
están definidos la
están definidas
organización y las
dentro de cada
responsabilidades
actividad del marco
en el equipo.
de trabajo.
El grado de El grado en el cual
autonomía otorgado se identifican y se
al equipo de solicitan los
proyectos de productos de
software. Pero los trabajo.
modelos de
proceso difieren
de manera
fundamental en:
La forma en la que
El grado en el que
se aplican las
los clientes están
actividades de
comprometidos con
aseguramiento de la
el proyecto.
calidad.
La manera en la que
El grado general de
se aplican las
detalle y el rigor con
actividades de
el que se describe el
seguimiento y
proceso.
control.

32. Unidad 2
2.3 MODELOS DE LA INGENIERÍA DEL
SOFTWARE:
MODELO DE CASCADA, MODELO DE
PROTOTIPOS,
MODELO DE ESPIRAL, MODELO DE PROCESO
UNIFICADO RACIONAL (RUP)

33. MODELOS DE LA INGENIERÍA DE SOFTWARE
 Para el caso de la ingeniería de software los
modelos nos ayudan a poder realizar en
orden una a una las tareas, esto se logra a
través de un ciclo de vida el cual nos ayuda
a poder visualizar cualquier evento de forma
anticipada y así poder llegar a un fin
determinado, lo cual nos dará el producto
deseado.

34. MODELO DE CASCADA
 Mas que nada es un modelo que nos provee
de lo que seria el control de las fechas de
forma ordenada ya que muestra claramente
la salida de una actividad y la entrada a la
siguiente; también nos sirve a la gente con
poca experiencia en el ramo, aunque
presenta poca flexibilidad y no poder mostrar
todo al cliente de forma anticipada y su
impresión es lenta ante lo cual el cliente
debe presentar paciencia.

35. MODELO DE CASCADA

36. MODELO DE PROTOTIPOS
Versión preliminar de un
sistema de información con
fines de demostración o
evaluación.
En si es un modelo menos
formal ya que en cierta
manera se puede eliminar o
se puede mejorar, y claro
que es algo rápido pero
suele crear falsas ilusiones
al usuario con respecto al
tiempo

37. MODELO DE PROTOTIPOS
Identificación
de
Requerimientos
Para
construir los
Revisar y Diseño
Mejorar
prototipos Rápido
solo se
necesita:
Utilizar
el
Prototipo

38. MODELO EN ESPIRAL
 Un modelo que es cíclico en todo sentido ya
que se repiten procesos de forma constante,
lo cual beneficia ya que así se corrigen
errores en el camino aunque tenga de
defecto su dificultad y sobre todo el no saber
cuando definir los limites y los objetivos.

39. MODELO EN ESPIRAL
Validación del Pruebas de Prototipo
Diseño Integración
Análisis Prototipo
de Riesgo
Diseño del
Requerimientos
Producto Requerimientos del Software
Plan de Validación de
Prototipo Desarrollo Requerimientos

40. MODELO DE PROCESO UNIFICADO RACIONAL (RUP).
 Es un proceso de desarrollo que forma
disciplinadamente la asignación de tareas y
responsabilidades.
 Se vigila el cumplimiento de los objetivos,
gestión de riesgos y restricciones para
desarrollaran producto que sea acorde a los
requisitos de los clientes y los usuarios.

41. Proveer un marco de trabajo
para gestionar riesgos.
Brinda una especificación
de las herramientas que
se van a necesitar
encada momento, así Configuración y control de
como definir la instancia cambios
concreta del proceso que
se va a seguir.
El control de cambios
permite mantener la
La finalidad de esta
integridad de todos los
actividad es dar soporte
artefactos que se crean
al proyecto con las
en el proceso, así como
adecuadas herramientas,
de mantener información
procesos y métodos.
del proceso evolutivo que
han seguido.

42. Unidad 2
2.4 TENDENCIAS MODERNAS DE MODELOS
DE LA INGENIERÍA DEL SOFTWARE

43. XP (EXTREMA PROGRAMACIÓN)
La XP empieza con Construye sobre ellos
cuatro valores: una docena de
comunicación, prácticas que los
retroalimentación, proyectos XP deben
simplicidad y coraje. seguir.
Muchas de estas
prácticas son técnicas Además de resucitar
antiguas, tratadas y estas técnicas, la XP
probadas, aunque a las teje en un todo
menudo olvidadas por sinérgico dónde cada
muchos, incluyendo la una refuerza a las
mayoría de los demás.
procesos planeados.

44. XP (EXTREMA PROGRAMACIÓN) [CONT.]
En esta plataforma XP construye un proceso de diseño
evolutivo que se basa en refractora un sistema simple en
cada iteración.
Todo el diseño se centra en la iteración actual y no se
hace nada anticipadamente para necesidades futuras.
El resultado es un proceso de diseño disciplinado, lo
que es más, combina la disciplina con la adaptabilidad
de una manera que indiscutiblemente la hace la más
desarrollada entre todas las metodologías adaptables.

45. XP (EXTREMA PROGRAMACIÓN) [CONT.]
En el último par de
Kent beck escribió
años ha habido una
extreme programming
epidemia de libros
explained, el manifiesto
XP ha desarrollado un sobre xp brillantemente
clave de la xp que
liderazgo amplio, coloreados la mayoría
Como resultado hay explica las razones
muchos de ellos de los cuales son
muchas fuentes para detrás de la
provenientes del bastante similares en
más información. metodología y bastante
proyecto fundamental que describen el
explicación como para
c3. proceso entero desde
que la gente pueda
el punto de vista de
saber si se interesan
varios seguidores
en seguirla.
tempranos.

46. LA FAMILIA DE CRISTAL DE COCKBURN
Cada metodología
encaja en una parte
diferente de la reja, de
Es una familia porque él Él mira esta variación a
modo que para un
cree que los tipos lo largo de dos ejes: el
proyecto de 40 personas
diferentes de proyectos número de personas en
que puede perder dinero
requieren tipos el proyecto, y las
discrecionalmente tiene
diferentes de consecuencias de los
una metodología
metodologías. errores.
diferente a la de un
proyecto vital de seis
personas.

47. Alistair considera que las personas
encuentran difícil seguir un proceso
Los cristales comparten con la disciplinado, así que más que seguir Él considera que aunque cristal
XP una orientación humana, la alta disciplina de la XP, Alistair es menos productivo que la XP,
pero esta centralización en la explora la metodología menos
disciplinada que aun podría tener más personas serán capaces
gente se hace de una manera
éxito, intercambiando de seguirlo.
diferente.
conscientemente productividad por
facilidad de ejecución.

48. Esto pone más
énfasis en la gente
supervisando su
proceso y
afinándolo
conforme
desarrollan.
Su aserción es
que el desarrollo
iterativo está para
encontrar los
problemas
temprano, y
entonces permitir Alistair también
corregirlos. pone mucho peso
en las revisiones
al final de la
iteración,
animando al
proceso a ser
automejorante.

49. CÓDIGO ABIERTO
Sin embargo hay
una manera
En particular su
definida de hacer
proceso se
las cosas haciendo
engrana a equipos
Después de todo el en la comunidad de
físicamente
código abierto es código abierto, y
distribuidos, lo qué
un estilo de mucho de su
es importante
software, no tanto acercamiento es
porque la mayoría
un proceso. tan aplicable a los
de los procesos
proyectos de
adaptables exigen
código cerrado
equipos locales.
como a los de
código abierto.

50. La mayoría de los proyectos de código abierto tienen uno o más mantenedores.
Un mantenedor es la única persona a la que se le permite integrar un cambio en el almacén de código
fuente.
Sin embargo otras personas pueden hacer cambios a la base del código.
La diferencia importante es que estas otras personas necesitan enviar su cambio al mantenedor que
entonces lo revisa y lo aplica a la base del código.
Normalmente estos cambios son hechos en forma de archivos de parches que hacen este proceso más
fácil.
El mantenedor así es responsable de coordinar los parches y mantener la cohesión en el diseño del
software.

51. Proyectos diferentes manejan el papel del mantenedor de diferentes
maneras.
Algunos tienen un mantenedor para el proyecto entero, algunos lo
dividen en módulos y tiene un mantenedor por módulo, algunos rolan
el mantenedor, algunos tienen múltiples mantenedores sobre el mismo
código, otros tienen una combinación de estas ideas.
La mayor parte de la gente de código abierto son de tiempo parcial,
así que hay una duda en qué tan bien se coordina un equipo así para
un proyecto de tiempo completo.

52. Un rasgo
particular del
desarrollo de
código abierto Cuando También es
es que la encuentran un bueno para
depuración es bug pueden gente sin mucha
altamente enviar el parche destreza en
paralelizable. al mantenedor. programación.
Muchas Esto es un buen
personas papel para los
pueden no
involucrarse en mantenedores
el depurado. ya que la mayor
parte del tiempo
se gasta en
encontrar bugs.

53. El proceso para el código abierto aun no se escribe
bien. La referencia más famosa es el artículo de Eric
Raymond the catedral and the bazar, que aunque es
una descripción excelente también es bastante
informal.
El libro de karl fogel sobre el almacén de código cvs
también contiene varios buenos capítulos sobre el
proceso de código abierto que incluso serían
interesantes para aquéllos que no quieren hacer una
actualización cvs.

54. EL DESARROLLO DE SOFTWARE ADAPTABLE DE HIGHSMITH
Jim Highsmith ha pasado muchos años trabajando con metodologías predictivas.
Él las desarrolló, instaló, enseñó, y concluyó que son profundamente defectuosas:
particularmente para los negocios modernos.
Su reciente libro se enfoca en la naturaleza adaptable de las nuevas metodologías, con un
énfasis particular en aplicar las ideas que se originaron en el mundo de los sistemas
complejos adaptables (normalmente conocida como teoría del caos.)
No proporciona el tipo de prácticas detalladas como lo hace la XP, pero proporciona la base
fundamental de por qué el desarrollo adaptable es importante y las consecuencias a los más
profundos niveles de la organización y la gerencia.

55. En el corazón del ASD hay tres fases solapadas, no lineales: especulación, colaboración, y
aprendizaje.
Ve la planificación como una paradoja en un ambiente adaptable, ya que los resultados son
naturalmente imprevisibles. En la planificación tradicional, las desviaciones del plan son
errores que deben corregirse. En un el ambiente adaptable, sin embargo, las desviaciones
nos guían hacia la solución correcta.
En ambientes predictivos, el aprendizaje se desalienta a menudo. Las cosas se ponen de
antemano y entonces se sigue ese diseño.
En un ambiente adaptable, aprender desafía a todos - desarrolladores y sus clientes - a
examinar sus asunciones y usar los resultados de cada ciclo de desarrollo para adaptar el
siguiente.

56. Se enfoca directamente en fomentar las partes
difíciles del desarrollo adaptable, en particular
cómo fomentar la colaboración y el aprendizaje
dentro del proyecto (XP, FDD y cristal).
Como tal su libro ayuda a dar ideas para
fomentar estas áreas "suaves" que hacen un
buen complemento a los acercamientos
basados en una práctica

57. SCRUM
Scrum ha estado durante algún tiempo
Scrum divide un proyecto en
en los círculos orientados a objetos,
iteraciones (que ellos llaman carreras
aunque confesaré que yo no estoy
cortas) de 30 días. Antes de que
muy al tanto de su historia o
comience una carrera se define la
desarrollo. De nuevo se enfoca en el
funcionalidad requerida para esa
hecho de que procesos definidos y
carrera y entonces se deja al equipo
repetibles sólo funcionan para atacar
para que la entregue. El punto es
problemas definidos y repetibles con
estabilizar los requisitos durante la
gente definida y repetible en
carrera.
ambientes definidos y repetibles.

58. La literatura de SCRUM se enfoca
principalmente en la planeación
Todos los días el equipo sostiene una
iterativa y el seguimiento del proceso.
junta corta (quince minutos), llamada
Es muy cercana a las otras
SCRUM, dónde el equipo discurre lo
metodologías agiles en muchos
que hará al día siguiente.
aspectos y debe funcionar bien con
las prácticas de código de la xp.

59. DESARROLLO MANEJADO POR RASGOS
Como las otras metodologías
El desarrollo manejado por
adaptables, se enfoca en
rasgos (FDD por sus siglas en
iteraciones cortas que entregan
inglés) fue desarrollado por Jeff
funcionalidad tangible. En el
de Luca y el viejo gurú de la
caso del FDD las iteraciones
OO Peter Coad.
duran dos semanas.

60. El FDD tiene cinco procesos. Los primeros
tres se hacen al principio del proyecto.
Construir
Desarrollar
una lista Planear Diseñar Construir
un modelo
de los por rasgo por rasgo por rasgo
global
rasgos
Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da
un criterio de comprobación.

61. Los desarrolladores entran en dos tipos: dueños de clases y programadores jefe.
Los programadores jefe son los desarrolladores más experimentados. A ellos se les
asignan rasgos a construir.
Sin embargo ellos no los construyen solos.
Solo identifican qué clases se involucran en la implantación de un rasgo y juntan a
los dueños de dichas clases para que formen un equipo para desarrollar ese rasgo.
El programador jefe actúa como el coordinador, diseñador líder y mentor mientras
los dueños de clases hacen gran parte de la codificación del rasgo.

62. DSDM (MÉTODO DE DESARROLLO DE SISTEMA DINÁMICO)
El método empieza con un estudio de viabilidad y
negocio. El estudio de viabilidad considera si DSDM es
apropiado para el proyecto.
El estudio de negocio es una serie corta de talleres para
entender el área de negocio dónde tiene lugar el
desarrollo. También propone arquitecturas de esbozos
del sistema y un plan del proyecto.

63. DSDM tiene principios
El resto del proceso forma tres subyacentes que incluyen una
ciclos entretejidos: el ciclo del interacción activa del usuario,
modelo funcional produce entregas frecuentes, equipos
documentación de análisis y autorizados, pruebas a lo largo
prototipos, el ciclo de diseño del del ciclo. Como otros métodos
modelo diseña el sistema para ágiles usan ciclos de plazos
uso operacional, y el ciclo de cortos de entre dos y seis
implantación se ocupa del semanas. Hay un énfasis en la
despliegue al uso operacional. alta calidad y adaptabilidad
hacia requisitos cambiantes.

64. MANIFIESTO PARA EL DESARROLLO DE SOFTWARE ÁGIL
Con tanta similitud entre
estos métodos, sería
justo un poco de interés
en alguna forma de
trabajo colaborativo.
Los representantes de
cada una de estas
metodologías fueron
invitados a un taller de
dos días en Snowbird,
Utah en febrero de 2001.

65. Todos estábamos conscientes
del hecho de que había mucho
en común, y este
reconocimiento era mucho
mayor que las diferencias
entre los procesos.
Además de un contacto útil
entre los líderes de procesos,
había también la idea de emitir
una declaración conjunta.

66. COMPROBACIÓN DIRIGIDA POR EL CONTEXTO
Desde el principio han sido los desarrolladores de software quienes han
conducido a la comunidad ágil.
Sin embargo muchas otras personas envueltas en el desarrollo de software
son afectadas por este nuevo movimiento.
Un grupo obvio es el de los verificadores que a menudo viven en un mundo
dominado por el pensamiento de cascada.
Con pautas comunes que declaran que el papel de la comprobación es
asegurar la conformidad del software con las especificaciones escritas de
antemano, el papel de los verificadores en el mundo ágil esta lejos de ser
claro.

67. En lo que se aclara eso, varias personas en la
comunidad de verificadores han estado
cuestionando mucho de la corriente principal del
pensamiento en comprobación por un tiempo ya.
Esto ha llevado a un grupo conocido como la
comprobación conducida por el contexto. La mejor
descripción de esto es el libro lecciones aprendidas
en comprobación de software.
Esta comunidad es también muy activa en la web,
eche una mirada a sitios organizados por Brian
Marick (uno de los autores del manifiesto ágil),
Brett Pettichord, James Bach, y Cem Kaner.