2013 46a Hawaii Conferencia Internacional sobre Ciencias de Sistemas
Un análisis comparativo de Ingeniería de Software tradicional
y el desarrollo ágil de software
Ashley School Aitken de Sistemas de
Información de la Universidad de Curtin - Perth,
Australia
A.Aitken@Curtin.Edu.Au
Resumen
Durante la última década (o dos) el péndulo de Mindshare
desarrollador ha oscilado decididamente hacia el desarrollo ágil de
software desde un enfoque de ingeniería más tradicional de desarrollo de
software. Para determinar las diferencias esenciales y cualesquiera
posibles incompatibilidades entre estos dos paradigmas de desarrollo de
software de esta investigación investiga una serie de metodologías
tradicionales y ágiles, métodos y técnicas. Las diferencias esenciales
entre la ingeniería del software tradicional y el desarrollo ágil de software
se encuentran no ser (como una primera puede sospechar de una
consideración superficial) en relación con la iteración longitud o la gestión
de proyectos, sino más relacionado con otros atributos como la variedad
de modelos se emplea, el propósito de los modelos, y el enfoque de
modelado. Al final, aunque los dos enfoques no se observa que son
incompatibles,
1. Introducción
El desarrollo de software ha pasado por un cambio significativo en la última
década o dos. La llegada tarde en el siglo 20 de Extreme Programming (XP)
representó el surgimiento (pero no el nacimiento) de un nuevo enfoque que se
convertiría en Agile de desarrollo de software (ASD). La historia del desarrollo
de software es, por supuesto, mucho más largo y probablemente incluso anterior
a los de los primeros ordenadores digitales electrónicos que llegó en la década
de 1940. Después de un período inicial cuando fue considerado como un arte,
desarrollo de software se piensa comúnmente como un tipo de ingeniería. ASD
parece ofrecer una nueva alternativa (un tanto artesanal como pero más
desarrollada). Sin embargo, todavía hay quienes piensan de ASD como una
forma de ingeniería de software.
Esto parece algo problemático. O bien se ha producido un cambio
significativo en el enfoque y ASD no es la ingeniería de software o la noción
de lo que se entiende actualmente que la ingeniería de software es
diferente a lo que se entendía previamente que la ingeniería de software.
Para aclarar esto este documento se utilizará el término tradicional de
Ingeniería de Software (TSE) para referirse específicamente a esa forma de
desarrollo de software que tomó un enfoque de ingeniería para el desarrollo
de software tal como se entendía antes de la llegada de TEA.
1530-1605 / 12 $ 26.00 © 2012 IEEE DOI
10.1109 / HICSS.2013.31
Vishnu Escuela Ilango de Sistemas
de Información de la Universidad de Curtin - Perth,
Australia
VishnuIlango@gmail.com
Eso por lo tanto es interesante tener en cuenta (sin juicio de valor) lo
que ha cambiado durante este cambio de paradigma. La pregunta que
aborda esta investigación es ¿cuáles son las similitudes esenciales y
diferencias entre TEA y la EET y éstos hacen que sean incompatibles. Se
aborda esta cuestión mediante la realización de una investigación y revisión
de una serie de metodologías de desarrollo de software, métodos y técnicas
dentro de los paradigmas del TSE y ASD. Se considera un conjunto de
atributos de cada uno de ellos para determinar qué, si los hay, son las
diferencias esenciales entre el TSE y ASD. La investigación implica un
análisis comparativo de las metodologías conocidas comúnmente de
desarrollo de software, métodos y técnicas tal como se presentan en la
literatura y utilizados en la industria. También considera si hay espacio para
un terreno común entre la ingeniería del software tradicional y el desarrollo
ágil de software. No pretende ser completa en su cobertura o análisis, pero
pretende centrarse en las metodologías populares, los métodos y las
técnicas y las similitudes y diferencias esenciales esenciales.
La contribución de este trabajo es doble: 1) proporciona una breve
visión general e introducción a una serie de metodologías de desarrollo de
software, métodos y técnicas, y
2) que proporciona una discusión de estas metodologías, métodos y
técnicas en relación con TSE y ASD. Otras investigaciones han realizado
estudios comparativos de diferentes enfoques de desarrollo de software
ágil [1, 2], pero ninguna otra parece haber comparado las EET y ASD con
el objetivo de determinar las similitudes y diferencias esenciales entre los
dos enfoques. La investigación está limitada por la naturaleza un tanto
ad-hoc de los datos recogidos y el hecho de que no es completa o
completa (por ejemplo, que no considera las tareas de análisis u otra
verificación y validación).
La sección siguiente (segundo) de este artículo discute el desarrollo
de software en general, incluyendo las fases de desarrollo,
desarrollo de software ciclos de vida, y
los enfoques para el desarrollo de software. En la siguiente sección se
proporciona una introducción a una serie de EET y ASD metodologías,
métodos y técnicas. En la sección cuarta y penúltima del papel
proporciona un análisis y discusión de diversos aspectos de las
metodologías, métodos y técnicas. La última sección ofrece un resumen
de los resultados y las conclusiones. Los resultados pueden no ser
definitiva o exhaustiva, pero sí ofrecen un punto de partida para
continuar el debate y la investigación sobre la relación entre TEA y TSE.
4749
4751
2. Desarrollo de Software
El desarrollo de software ha implicado siempre la resolución de problemas. En esta
sección se investiga brevemente la naturaleza de la resolución de problemas, el ciclo de
vida de desarrollo de software y, por último, los diversos paradigmas en el desarrollo de
software.
2.1 Fases de desarrollo de software
No importa cómo se lleva a cabo el desarrollo de software o qué enfoque se
toma la tarea esencial que interviene es, como se mencionó anteriormente, la
resolución de problemas. La manera desarrolladores resolver problemas es
generalmente el mismo, no importa cuál es el problema o el enfoque adoptado. La
resolución de problemas consiste en cuatro actividades esenciales: - requisitos
recopilar y documentar la información sobre
el problema; análisis -
la comprensión del problema con el suficiente detalle para asegurar una solución
correcta; de diseño - la búsqueda y la especificación de una solución óptima al
problema; y la aplicación (si es necesario) - implementación de la solución en la
forma que sea.
El problema esencial en el desarrollo de software es cómo poner en práctica,
el uso de ciertas tecnologías y dentro de ciertos límites, un sistema de
procesamiento de la información en particular. 1
Aunque existen problemas asociados de entender el dominio de éstos son por lo
general no relacionados con el software. Se puede argumentar que no importa qué
paradigma o enfoque que se adopte para el desarrollo de software cada una de las
actividades de resolución de problemas tiene que ser llevado a cabo, en cierta
medida. En esencia, todos los desarrolladores pasa a través de los requisitos,
análisis, diseño, y el ciclo de aplicación, ya sea durante un período prolongado, una
semana, un día, una hora o minuto, y si son o no documentan los resultados,
discutirlos con otros en una pizarra, o simplemente tener en cuenta de manera
informal dentro de su cabeza. No hay escapar estas actividades.
2.2 Software ciclos de desarrollo
Un ciclo de vida de desarrollo de software (SDLC) da una perspectiva de
alto nivel de cómo las diferentes actividades de resolución de problemas
pueden ser resueltos a través de las fases de desarrollo de software por un
individuo o un equipo haciendo. McConnell [3] proporcionó una lista bastante
exhaustiva de SDLCs. Los SDLCs populares en alguna forma de uso
contemporáneo son: 1) la cascada, 2) iterativo, 3) iterativo e incremental, 4)
evolutiva de prototipos, y 5) Ad-hoc o Código-Y-Fix SDLC.
2.2.1 Cascada. La cascada SDLC fue presentado por [4] Royce como un método
para el desarrollo de software de enseñanza. Se trata de completar
secuencialmente cada fase en su totalidad y a continuación, pasar a la siguiente
fase. Nunca estaba destinado a ser un enfoque útil en la práctica para el desarrollo
de software. La idea de que los requisitos pueden ser totalmente completado, y
luego
1 Esto no siempre es entendido por los desarrolladores de software o gerentes que perciben a
veces (por lo menos parte de) la tarea de los desarrolladores de software es resolver el
problema de dominio.
4752
4750
análisis totalmente completado, y luego diseñar totalmente completada y luego
aplicación totalmente completado, es prácticamente imposible [5]. No reconoce
que el aprendizaje se produce durante el desarrollo resulta en la necesidad de
modificar las prestaciones anteriores. En realidad, algunos proyectos tienen
como objetivo aproximar la cascada SDLC, con la menor reproceso o corrección
posible (por ejemplo contractual Cascada).
2.2.2 iterativo. El SDLC iterativo implica la atención secuencial para cada fase en
la solución de un problema, sino que permite a los desarrolladores para volver
atrás y repetir la secuencia de nuevo, para favorecer los resultados de cada
actividad. El iterativo SDLC se aproxime más al mundo real en el que se reconoce
la necesidad de volver atrás y modificar los resultados de las fases anteriores, y
reconoce que los desarrolladores de software nunca puede terminar por completo
cualquier actividad. De esta forma pura, el iterativo SDLC ve desarrolladores
tratando de perfeccionar una solución completa al problema a través de cada ciclo.
Puesto que el foco está en la producción de una solución completa, por lo general
se necesitan muchas iteraciones antes de que se logra, y cuándo dejar de iterar es
problemático con cualquier sobrante de alcance.
2.2.3 iterativo e incremental. El SDLC iterativo e incremental es un caso
especial de la SDLC iterativo en el que el objetivo no es iterar sobre el
alcance completo del problema, sino más bien en un pequeño subconjunto
del alcance. Iteraciones por lo general continuará hasta este subconjunto se
trate adecuadamente. Al igual que el SDLC iterativo básico, el iterativo e
incremental SDLC, no tiene nada que decir específicamente sobre la
duración de las iteraciones o el tiempo dedicado a cada actividad - sólo que
algunos requisitos, algunos análisis, algunos de diseño, y algunos de
implementación se repiten en ese general orden. El SDLC iterativo e
incremental es la mejor práctica actual para el desarrollo de software.
2.2.4 Prototipos evolutiva. El evolutiva de prototipos SDLC implica el
desarrollo iterativo e incremental, pero en el caso de que el destino final
para el desarrollo no está bien definido. Es para los casos en los
desarrolladores y las partes interesadas están explorando posibles
soluciones. Los desarrolladores utilizan un enfoque iterativo e
incremental para construir un prototipo y luego buscar retroalimentación
para llevar a cabo un mayor desarrollo en una dirección, posiblemente
diferente. El énfasis está en construcción, a veces implementaciones
rápidas y sucias de una idea, para probarlo y determinar si vale la pena
una investigación adicional. La noción de un prototipo debería significar
que cuando se encuentra el destino final del prototipo se descarta y un
sistema similar está construido con más de un foco en la calidad. Sin
embargo,
2.2.5 Ad-hoc (o Código-Y-Fix). Mientras que el grupo de SDLCs iterativos (2-4 más
arriba) generalmente implica la iteración a través de la diferente resolución de
problemas actividades, el Hoc SDLC Ad- permite cualquier combinación y variación
de estos. Tiene el propósito de describir el SDLC para un individuo o grupo de
desarrolladores de software que trabajan de una manera ad-hoc, es decir,
no después de cualquier enfoque prescrito para las actividades de resolución
de problemas [6]. En tal caso, un desarrollador de software en un solo día
puede pasar unas horas en cada actividad, o en otro caso pasar unos minutos
en cada actividad, o, en general, cualquier variación en el medio. Las
actividades además de codificación puede ser hecho de manera informal (con
lápiz y papel, en un tablero blanco, aunque sólo dentro de los cabeza) o más
formalmente (utilizando varias anotaciones), y puede o no ser persistido como
parte del proyecto. El típico “hacker” podría, por ejemplo, se dice que después
de la Ad-hoc iterativo e incremental SDLC.
2.3 Paradigmas de desarrollo de software
Un paradigma de desarrollo de software es un enfoque general para llevar a
cabo el desarrollo de software, una forma de pensar sobre el desarrollo de
software, y una metáfora para el desarrollo de software. Los tres paradigmas
principales para el desarrollo de software que aquí se consideran son: 1) el
desarrollo de software como un oficio, 2) desarrollo de software como la ingeniería,
y 3) el desarrollo de software como una práctica ágil (y pobre). 2
2.3.1 Software Desarrollo. Cuando software
desarrollo comenzó por ahí eran los que se adiestró en ella a través de la
experiencia y de la artesanía. Como resultado, el desarrollo de software
fue visto como un oficio y los que podía hacerlo
eficazmente como artesanos (y
artesanas). Hubo un énfasis en las técnicas a diferencia de método o
métodos predefinidos (tal vez porque nadie había pasado mucho tiempo
pensando en ellos todavía). La nave pasó a recién llegados a través de
un aprendizaje donde serían aprender del maestro (s) y eventualmente
convertirse en expertos y experimentados en el oficio. Esta forma de
aprender un oficio no es la forma más eficaz o eficiente de transferir
conocimientos y habilidades - un artesano sólo puede mentor de tantos
nuevos desarrolladores de software y el proceso de aprendizaje es lento.
2.3.2 Ingeniería de Software. Como resultado de un aumento significativo en la
capacidad de las computadoras y la llegada de alto nivel
programación idiomas, algunos programas de software
los desarrolladores encontraron la nave ya no es capaz de mantenerse al día con el
aumento de alcance y demandas de desarrollo de software. Había una demanda de
software más complejos y sistemas de software mucho más grandes que no podía ser
desarrollado por artesanos individuales. Estos proyectos de software fueron entregados
a menudo tarde (en su caso), por encima del presupuesto (a menudo de manera
significativa), y no cumplir con todos los requisitos (ya menudo tenían errores
significativos) [8]. Esta situación se conoce generalmente como la “crisis de desarrollo
de software.”
Como resultado, un nuevo paradigma para el desarrollo de software se ganó el
favor en la conferencia de la OTAN en 1968 [9]. Se considera el desarrollo de
software como una forma de ingeniería
2 Otra es “el desarrollo de software como la jardinería” [7] Hunt, A. y Thomas, D. El
programador pragmático: a partir de oficial de dominar. Addison-Wesley
Professional, 2000.
4753
4751
(Por ejemplo, la ingeniería de software fue a la informática como la ingeniería civil fue a
la física). La esperanza era (y, para muchos, todavía lo es) es que si el desarrollo de
software puede desarrollarse como una disciplina de ingeniería, entonces sería posible
desarrollar proyectos de desarrollo de software complejos y grandes a tiempo, dentro
del presupuesto, con menos errores, y para cumplir con la mayoría (si no todos) de los
requisitos. Ingeniería es generalmente considerado como procesos para usar el
conocimiento para lograr objetivos, por lo general en la construcción (o al menos el
diseño) sistemas o estructuras complejas. Ingenieros ponen una gran cantidad de
esfuerzo en la predicción y la planificación de su trabajo y por lo general trabajan con los
requisitos fijos, es decir, que saben lo que se supone que deben construir al comienzo
del proyecto (por ejemplo, un puente o una carretera). Los ingenieros también utilizan
muchos modelos a medida que trabajan.
Hay muchos que no están de acuerdo con esta perspectiva de desarrollo
de software como una forma de ingeniería [10] [11]. Afirman que el desarrollo de
software no es una forma de ingeniería debido a que es más complejo, más
maleable, y que el diseño de software es mucho más de una tarea creativa. Si
bien es cierto que hay una mayor complejidad en el software que es importante
separar el dominio de la complejidad de la asignación del dominio sobre las
tecnologías de desarrollo elegidas para cumplir los requisitos no funcionales
(NFR). Del mismo modo los que dicen que cada pieza de software es bastante
singular que recordar que el desarrollo de software no es un problema de
dominio, pero un problema de traducción. También se argumenta que el
desarrollo de software no es la ingeniería debido a que el compilador realiza
esencialmente el paso de generación en desarrollo de software. Esto confunde
la albañilería con el diseño del edificio. La esencia del desarrollo de software es
el diseño, y el diseño está haciendo el código cumple con los requisitos no
funcionales, al no encontrar una solución a un problema de dominio. Los
desarrolladores de software, incluso aquellos que sólo código, no son sólo la
colocación de ladrillos, que están investigando los requisitos, el análisis del
problema, y ​el diseño de una solución (a menudo al mismo tiempo en su
cabeza).
2.3.3 Desarrollo ágil de software. El enfoque de software ágil desarrollo [12]
[13] [14] (que también incorpora muchos aspectos de desarrollo de software
magra [15] [16] [17]) se caracteriza mediante la adopción de un enfoque
adaptativo al cambio dentro de desarrollo de software.
Ese es, software
el desarrollo se lleva a cabo de una manera que hace que la respuesta al cambio
quizá menos difícil y menos costoso que sería en un enfoque de ingeniería. Por
ejemplo, el desarrollo ágil de software mantiene el proceso de desarrollo y
artefactos como la luz (y mínimo) como sea posible, así que no como para
requerir la reanudación. Ágil también se trata de tener un enfoque de personas
(desarrollador), la eliminación de los residuos (la contribución magra), y la
colaboración en lugar de la negociación contractual entre los desarrolladores y
clientes. En lugar de ver que el desarrollo de software como una forma de
ingeniería, Cockburn [18] lo ve como un juego cooperativo.
TEA es una “iglesia amplio” y puede significar muchas cosas para diferentes
personas. En general se define por el “Manifiesto Ágil” - un manifiesto y un
conjunto de valores y principios declarados por un grupo de los principales
desarrolladores de software. Los valores propuestos en el manifiesto ágil [19]
son:
• Individuos e interacciones sobre procesos y herramientas y modelos gráficos y la arquitectura adelantado que diferencia a partir de
• software que trabaja sobre una amplia documentación los métodos más ágiles.
• Colaboración con el cliente sobre negociación de contratos
3.1.2 Metodología de la familia de cristal. La familia Crystal (CF) de los
• En respuesta a cambiar con el seguimiento de un plan de ASD también se
métodos fue desarrollado por Alistair Cockburn en 1992 [12]. Los métodos
considera como un enfoque para el desarrollo de software que se centra en el
dentro de la familia se eligen en función de varios factores tales como el tamaño
valor del negocio añadiendo gradualmente y de forma iterativa, con el proceso
del equipo, la criticidad del sistema y las prioridades del proyecto. Su objetivo es
de cómo se desarrolla el software se deja en manos del equipo que son
ser, luz ultra-propulsión humana, y estirar-a-fit. Métodos dentro de la familia
responsables de su desarrollo . También adopta el enfoque se apoyan en la
Crystal se compone de cristal transparente, amarillo, naranja y cristal de cristal
reducción de residuos y sólo haciendo actividades o crear artefactos que
rojo con grandes proyectos
añaden valor directamente. ASD ha vuelto muy popular con un 76% de las
requiriendo más
organizaciones de información en 2009 que han adoptado técnicas ágiles [20].
coordinación y metodologías más pesadas que las pequeñas. El proceso
general se centra en el desarrollo iterativo e incremental con la entrega de
forma regular, un enfoque en las entregas de software como hitos (en lugar
de documentos escritos), la participación directa del usuario, la enseñanza de
3. Metodologías, métodos y técnicas
regresión automatizado, dos de visión por la liberación, y talleres para el
producto y el método de inflexión al principio y en el medio de cada
Para esta investigación se examinaron una serie de diferentes
incremento. principios clave incluyen el trabajo en equipo, la comunicación y
metodologías, métodos y técnicas para el desarrollo de software y caracteriza
la simplicidad, así como la reflexión frecuente para la mejora de procesos. La
de acuerdo con un número de diferentes atributos (por ejemplo, historia,
familia de cristal promover la entrega frecuente de software que trabaja,
proceso, artefactos, longitud de iteración, gestión de proyectos, el alcance
participación alta de usuario, la adaptabilidad y la eliminación de la burocracia
dentro de SDLC y aplicabilidad
o distracciones,
en diferentes contextos). metodologías,
métodos y técnicas se distinguen de la siguiente manera:
pero tener un relativamente restringida
técnicas - una forma de hacer algún aspecto o parte de
estructura de comunicación que se adapte a un solo equipo que comparte el edificio.
desarrollo de software [18]. Pueden referirse a los aspectos de desarrollo de
software técnico (por ejemplo, codificación o pruebas) o (por ejemplo, gestión) no
3.2 Métodos
técnico.
métodos - un proceso, sin embargo general o específica, y una
Esta sección proporciona una visión general de una gama de diferentes
notación (conjunto de entregables o artefactos, incluso
métodos (pero predominantemente ASD).
documentación y el código fuente) [21]. Un método generalmente incluye un
número de diferentes técnicas, así.
3.2.1 Extreme Método de programación. Extremo
metodologías - una colección de métodos o una
Programación (XP) [24] se centra la programación a una
marco para determinar un método [18]. Por lo general, una metodología no puede
método de desarrollo de software que tiene la intención de mejorar la calidad del
ser utilizado como es, pero tiene que ser personalizado para adaptarse al
software y la capacidad de respuesta a las cambiantes necesidades de los clientes
proyecto y otras limitaciones.
a través de soluciones de codificación más simples. Kent Beck, Ward Cunningham,
y Ron Jeffries introdujeron XP en la última parte de la década de 1990. XP es
3.1 Metodologías altamente iterativo e incremental e incluye seis etapas (con fases implícitos
incorporados). Utiliza tarjetas de historia para los requisitos y luego modela
En este apartado se tendrá en cuenta sólo dos metodologías para el principalmente a base de código (por
desarrollo de software - la Metodología Proceso Unificado y la Metodología pruebas y
de la familia de cristal. El primero se asocia más comúnmente (pero no implementación). Otros modelos (por ejemplo modelos de diseño de análisis y) son
exclusivamente) con TSE y el segundo con ASD. principalmente para la comunicación y, en general no se conservan. longitudes de
iteración son generalmente 1-4 semanas y no hay enfoque específico de gestión de
proyectos (aunque Scrum se utiliza por lo general). XP es la más adecuada para
3.1.1 Metodología Unificada de Proceso. El Proceso Unificado (UP) es un
pequeñas y medianas proyecto y pequeños equipos co-localizados. Tiene una serie de
nombre genérico para el Proceso Unificado de Rational [22, 23], que es un
prácticas, incluyendo la planificación del juego, TDD, la implicación del cliente,
proceso comercial desarrollado originalmente por la Corporación Racional y
refactorización, la programación en parejas, la propiedad colectiva de código,
luego adquirida por IBM (cuando compraron racional). La UP fue desarrollado
integración continua, ritmo sostenible y estándares de codificación. Es un método
como un proceso para acompañar el Lenguaje de Modelado Unificado (UML),
codificador y el código-centrado que hace un llamamiento a los codificadores sino que
un conjunto de modelos gráficos que cubren la mayoría de todas las fases de
depende de desarrolladores altamente cualificados. Proporciona software que funciona
desarrollo de software. La UP es grande y extensa (como el UML) que contiene
en ciclos cortos, pero es más difícil de escalar a grandes proyectos o para sostener el
muchos procesos y técnicas para ayudar con el desarrollo de muchos tipos
mantenimiento a largo plazo.
diferentes de software. En general, el UP se describe como un iterativo e
incremental, centrado en la arquitectura y el uso de los casos impulsado
metodología. Si hay algo que es este enfoque en Pruebas

3.2.2 Método de Scrum. Scrum (S) es un método de gestión de proyectos

sobre todo que se concentra en cómo el equipo

4754
4752
miembros deben funcionar con el fin de desarrollar un software flexible
en un entorno en constante cambio [1]. Scrum fue introducido por
Takeuchi y Nanoka en 1986 pero el movimiento contemporáneo fue
introducido por Ken Schwaber y Jeff Sutherland a mediados de la década
de 1990 [25] [26]. Scrum incluye tres etapas antes del juego, el
desarrollo, y el juego posterior, con el pre-juego se divide en dos
sub-etapas llamadas planificación y arquitectura, y la etapa de desarrollo
consiste en una serie de carreras - ciclos iterativos donde se desarrolla la
funcionalidad o mejorado para producir nuevos incrementos. Scrum no
especifica la forma en que características se especifican, sólo que hay
una lista de tales características (llamado el retraso). Iteraciones pueden
durar desde alrededor de una semana para alrededor de un mes, con
tres a ocho carreras antes de un lanzamiento. Scrum también requiere la
implicación del cliente como el “dueño del producto.
Ayuda a mejorar
prácticas de ingeniería y su flexibilidad permite adaptarse a contextos cambiantes.
Algunas nociones tales como equipos de “auto-organización” pueden conducir a
incertidumbre y los riesgos y no siempre puede ser posible “hacer el sprint.”
3.2.3 Característica Driven Development. Driven Development función
(FDD) [27] [28] es un proceso iterativo y
método incremental de desarrollo de software que está centrada en el modelo-,
impulsadas por los requerimientos del negocio y hace hincapié en la calidad a través
del proceso con un informe de estado oportuna, precisa y significativa y el
seguimiento del progreso para todos los niveles de dirección. Jeff Luca, Peter Coad y
Stephan Palmer se desarrollaron en 1997 como una evolución del método de Coad.
Se compone de cinco etapas: 1) desarrollar un modelo general - descripción de alto
nivel del sistema, incluyendo los requisitos y modelos de dominio; 2) construir una
lista de características basado en la funcionalidad de cliente de valor; 3) Plan de por
característica - secuencia de características de acuerdo a sus dependencias; y
entonces
4) Diseño de característica y 5) construir por función, se ejecutan iterativamente para
pequeños grupos de características seleccionadas de la lista de características. FDD
utiliza modelos para la especificación (así como la comunicación)
y alienta frecuente Progreso
la presentación de informes. Iteraciones son por lo general alrededor de 2 semanas de
duración. De acuerdo con Palmer y Felsing [29], FDD es adecuado para la mayoría de los
proyectos, incluso aquellos que requieren considerable agilidad. FDD ofrece previsibilidad si
los requisitos son estables, pero el intercambio de conocimientos pueden verse limitadas por la
propiedad individual dentro de la clase de desarrollo.
3.2.4 Sistemas Dinámicos método de desarrollo. Sistemas método de
desarrollo dinámico (DSDM) es un método de desarrollo de software basado
en la metodología de desarrollo rápido de aplicaciones [30], cuyo objetivo es
entregar los proyectos a tiempo y dentro del presupuesto mientras se adapta a
las necesidades cambiantes [31]. Esto se logra mediante la fijación de tiempo
y recursos y luego ajustando la funcionalidad que puede ser entregado dentro
de esos límites. DSDM consiste en cinco etapas: estudio de viabilidad, estudio
de negocios, modelo funcional
iteración, diseño y construcción iteración y
aplicación, con los dos primeros son secuenciales y siendo los tres
últimos iterativo e incremental. Se fomenta una
4755
4753
número de modelos no basados ​en código, así como la creación de prototipos basada
en el código a través de las etapas de desarrollo. Iteraciones son encajadas en
tiempo desde unos pocos días a unas pocas semanas. Aunque lo mejor trabaja con
pequeños equipos de entre dos y seis desarrolladores, DSDM puede soportar
muchos equipos en un proyecto. DSDM también requiere la participación activa del
usuario. Cuenta con un sólido marco para el diseño, pero es difícil ver cómo los
cambios se pueden incorporar en las etapas no iterativo de desarrollo.
3.2.5 Método de desarrollo de software adaptativo. El método de
desarrollo de software adaptativo (ASD) fue desarrollado por James
Highsmith en 2000 [32] basa en métodos anteriores (por ejemplo, “radical
de desarrollo de software” co-autor con Bayer [33]). Implica el desarrollo
iterativo e incremental con prototipos constante y fomenta la adaptación
continua del proceso para proyectos de alta velocidad y alta de cambio.
Proyectos iterar a través de tres etapas: especular - una forma de
planificación del ciclo de adaptación, colaboran - ingeniería de
componentes concurrente por parte de un equipo, y aprender - revisión
de calidad para aprender de los errores, con el inicio del proyecto al
principio y al aseguramiento de la calidad final y la liberación al final.
Incluye modelos no basados ​en código (por ejemplo, la misión del
proyecto y pliego de condiciones de contorno). longitud de iteración y de
gestión de proyectos detalles no se especifican.
3.2.6 Desarrollo personal y software del equipo de proceso. Estos
son, de hecho, dos métodos relacionados. El Personal Software Process
(PSP) [34] y el Team Software Process (TSP) [35]. Ambos se originó a
partir de la SEI en la Universidad Carnegie Mellon. El PSP, como su
nombre indica, es de unos desarrolladores individuales que crean los
procesos individuales para su desarrollo a nivel de módulo. Clave para la
PSP es el perfeccionamiento de estos procesos basados ​en mediciones
detalladas realizadas mientras que el desarrollo de cada ingeniero (por
ejemplo, tiempo en cada fase, el tipo y número de errores, líneas de
código producida) para mejorar la productividad y la calidad. PSP
probablemente requiere más disciplina de cualquiera de los métodos,
pero los resultados pueden ser llamativo [36] [37]. El TSP es un proceso
relacionado equipo que recae la responsabilidad al equipo para planificar
y estimar su trabajo de desarrollo (utilizando datos agregados de cada
uno de los desarrolladores de PSP).
Esta investigación también considera otros métodos que incluyen el método
de cascada [4], Prototipos método [38], Método espiral [39] Desarrollo, basado en
modelos [40], pero no informan sobre ellos en detalle aquí debido a restricciones
de espacio.
3.3 Técnicas
La investigación considera los siguientes (en su mayoría) ágiles técnicas
de desarrollo de software (con muchos procedentes de [24]): la programación
en parejas, Comportamiento Driven
Desarrollo [41], de casos de uso Driven Development [42] Desarrollo,
Test Driven [43], Test Driven Development Aceptación, Unidad Test
Driven Desarrollo, Planificación juego, de participación del usuario, la
propiedad colectiva, Pace Sostenible, normas de codificación, Reuniones
de pie, simple Diseño,
refactorización, La metáfora del sistema,
Basado en Componentes Desarrollo, Tiempo en caja
Desarrollo, el cambio Tolerante desarrollo, Riesgo Driven Development,
grupos de enfoque al cliente, dominio de modelado de objetos, desarrollo
de funciones, con el poder de Equipos, Entrega frecuente, entrega
continua, Integrado
Pruebas, regular Construye, gestión de la configuración, integración
continua, la administración continua, Dominio de diseño del [44]. El
objetivo era considerar cuál de las técnicas eran compatibles con las
EET y ASD o no.
4. Análisis comparativo y Discusión
Comparando y buscando las similitudes y diferencias entre los paradigmas de
desarrollo de software está plagado de problemas. La primera es que no existe una
clara o acordado definición de cada uno de los paradigmas. La segunda es que cada
paradigma es una lo suficientemente amplio como para permitir que una amplia variedad
de metodologías muy diferentes, los métodos y técnicas dentro de sus límites. Por
ejemplo, el manifiesto ágil es lo suficientemente amplio como para permitir un enfoque
de procesos, herramientas, etc., siempre y cuando hay más de un foco en la gente,
código, etc.
menos completa y mucho menos detallada que lo que se prescribe en cualquiera de los
métodos de EET, o ASD.
4.1 Análisis de Metodologías y Métodos
Esta investigación recoge datos generales durante más de una docena
de diferentes enfoques, ellos (y sus componentes) clasifica
como metodologías, métodos, o sólo
técnicas, y luego los evaluados de acuerdo a su longitud iteración
recomendado y la cantidad de los enfoques alineados con los
planteamientos generales del TSE y ASD. Dos representaciones
pictográficas de encargo se utilizan para resumir estos datos.
La Figura 1 muestra la totalidad de la longitud enfoques y displays
iteración, cómo se clasifica el enfoque, y en el que se encuentra en un
continuo entre completamente TSE y totalmente ASD. Los dos ejes indican
la longitud de la iteración y la posición en un espectro entre TSE y ASE. La
oferta del enfoque también se muestra por su inclusión dentro de las cajas
para la metodología, el método o técnicas. Tenga en cuenta la posición
dentro de cada caja no es importante, sólo el número de miembros de cada
categoría es relevante. Por ejemplo, algunos artículos son sólo técnicas,
algunos son métodos con técnicas y algunos pueden ser metodologías con
técnicas.

Esta situación hace que sea fácil para los lectores para recoger una parte
ninguna declaración reivindicados en este documento. Por ejemplo, se afirma en
este documento que ASD se centra principalmente en los modelos basados ​en
códigos y generalmente no persiste modelos no basados ​en código, incluso las
historias de usuario. Por supuesto, hay quienes no estarán de acuerdo con esta
declaración y dar evidencia de un método ágil en particular o empresa que utilice
y persisten modelos no basados ​en código. Tales contrademandas son, sin
embargo, faltando el propósito de este trabajo. Se está tratando de buscar la
naturaleza esencial de la ingeniería del software tradicional y desarrollo de
software ágil y luego determinar las similitudes y diferencias entre ellos. Siempre
habrá variaciones específicas que no se ajustan a los criterios esenciales
caracterizados aquí. Tratando de caracterizar estos aspectos esenciales es
importante sin embargo.

Del mismo modo, esta investigación intenta centrarse en las mejores

prácticas en lugar de las prácticas reales (con todas sus variaciones y defectos).
Por ejemplo, se debe explicar que la mejor práctica para TSE fue un ciclo de
vida de desarrollo de software altamente iterativo e incremental. Sin embargo,
muchas organizaciones parecen repliegue en un pseudo cascada o al menos
iteración más largo del ciclo de vida de desarrollo de software. Por otro lado, un
fenómeno similar se ha descrito recientemente en que muchas organizaciones Figura 1 - la agilidad, componentes, y de la longitud de iteración
que emplean ASD con Scrum parece que vuelve a los algo que se llama
La figura 2 representa un resumen de la información recogida acerca
“agua-scrum caída” [45]. En realidad, la mayoría de las empresas parecen
de todos los enfoques con respecto a las fases SDLC y que entregables
desarrollar su propio proceso mínimamente prescriptivo (a nivel de organización
se producen dentro del enfoque (caja de eje x inferior), que fase son
o dentro de los equipos). Este fue el caso de la EET y este es el caso con TEA.
gestionados por el enfoque (eje x cuadro superior), y el año de
No hay nada de malo en “cosecha propia personalizaciones selectivos”, aunque
introducción (eje y). Entre una serie de cosas que demuestra que, si bien
que a menudo son mucho
muchos de los enfoques eran TSE

4756
4754
 -Ciclo de vida completo, muchos (pero no todos) de los TEA son más centrado en continuamente. Generalmente no fomentar una

su aplicación. entrega dentro de dos semanas a dos meses.
Iteraciones son más largos.
No anima generalmente equipos
Estimula de entrega o de liberación de
software ciclos cada dos semanas (o menos)
a dos meses (máximo). iteraciones más
cortas.
El software puede ser entregado en su mejor

auto-organizados. momento de los equipos de co-localizados.

Sigue las fases de SDLC formalmente. Por No sigue las fases formalmente. Por
ejemplo, alienta el análisis y la planificación ejemplo, no tiene una fase de análisis o
formal. planificación formal.

Todos los requisitos decididos en la fase de entregas de software cortos para las características

recopilación de requisitos deben ser entregados individuales o historias. Las características o historias

por el software final construida. pueden evolucionar con frecuencia.

No enfatiza ritmo constante entre los
desarrolladores y clientes o usuarios, ya que los
usuarios no están implicados de forma continua
durante todo el proyecto - En los enfoques
tradicionales clientes están involucrados
solamente durante el parto pre y post del software.
Los desarrolladores y los clientes o usuarios deben
ser capaces de mantener un ritmo constante de
forma indefinida para promover el desarrollo
sostenible.

Tenga en cuenta los valores del Manifiesto Ágil (AM):

4.2.1 Los individuos e interacciones sobre procesos y herramientas. A

principios de ASD se produjo un importante rechazo de los procesos y las

Figura 2 - Fases SDLC, gestión de proyectos, herramientas (generalmente de una revuelta contra la UP). Sin embargo, con el

Entregables y año de introducción
En la siguiente parte de esta sección, TSE y ASD (se compararon en
base a la revisión precedente. Ellos serán comparados de acuerdo con
los valores y principios y características del enfoque ASD. Por último, las
similitudes esenciales y diferencias entre TSE y ASD y se discutirán las
compatibilidades (e incompatibilidades) entre los diferentes paradigmas.
4.2 Comparación de Valores y Principios
creciente número de procesos y herramientas asociadas con TEA no es tan claro
ahora que siempre tienen un descuento en comparación con los individuos y las
interacciones. Por otro lado el trabajo en equipo y las interacciones siempre han
sido una parte del TSE. Si los individuos y sus interacciones no siempre han
funcionado tan bien, es probable que sea un fallo de la gestión de proyectos en
lugar del enfoque TSE sí. No está claro entonces que las EET es incompatible con
las personas y las interacciones más importantes que los procesos y las
herramientas. También se podría decir que ha TSE procesos y herramientas como
ayudas para los individuos y sus interacciones visto siempre (por ejemplo,
considere los carriles de natación en la UP).

La Tabla 1 indica la forma general en que son percibidos valores y

principio que difieren entre TSE y ASD. Sin embargo, no está claro, que 4.2.2 Trabajo software terminado exhaustivo
este debe ser el caso. En este apartado se tendrá en cuenta los valores y documentación. Este valor parece utilizar la documentación como un
principios de ASD para ver si son tan incompatibles con las EET. término peyorativo, en comparación con el código (que se convierte en el
software de trabajo). Esto es inapropiado porque el código es tanto una
Tabla 1 Valores y Principios La comparación de las EET y TEA forma de documentación como los requisitos, análisis, o documento de
Fuente: (Adaptado de [19]) diseño. En realidad se trata de todos los modelos, el código sólo pasa a
ser el modelo que es generalmente más cercano al software ejecutable
Ingeniería de Software Desarrollo Ágil de Software
tradicional (TSE) (ASD) final. También es falso sugerir que los modelos que no sean el código
Proceso y herramientas motorizadas. La gente y la colaboración impulsadas. son menos importantes o simplemente “la documentación para el motivo
Documento impulsada. Cada actividad se Código o programación impulsadas. el documentación.” Del mismo modo que el código ha sido desarrollado
mide por la documentación intensiva o software de trabajo se utiliza como una
para producir el software de trabajo necesario, también lo son los otros
entregables. medida de progreso. Destaca más
importancia al diseño del código.
modelos de la EET. TSE construye requisitos, análisis y modelos de
diseño, ya que es cree que estos modelos permiten este enfoque para
No involucra a los clientes de forma Involucra a los clientes de forma continua. construir un mejor software y construir más rápido (por ejemplo,
continua.
No son bienvenidas en los requerimientos Da la bienvenida a los requisitos cambiantes durante
cambiantes durante el progreso de los proyectos. el desarrollo de proyectos. Fácil de cambiar de
Difícil cambiar de dirección una vez se firmen los dirección como los cambios en los requisitos.
contratos.
No anima a la entrega de software que Entrega de software que trabaja de forma 4.2.3 cliente colaboración terminado contrato
trabaja para clientes continua a los clientes
negociación. Este valor parece un poco ingenuos, así,

4757
4755
es decir, asumir que TSE prefiere la negociación del contrato de
colaboración con el cliente. Es cierto que la negociación del contrato es
común en virtud de las EET pero sería justo decir que es común en virtud
de ASD también. La mayor parte del mundo de los negocios no está listo
para el desarrollo de software “tiempo y materiales”. En todo caso el
enfoque ASD acaba de incluir dos elementos (un tercio será discutido a
continuación) en el contrato. Siendo estos: 1) que no pueden garantizar
la terminación de todos los requisitos, pero 2) garantizar que agregar
valor casi de inmediato y continuar haciendo eso (menos el contrato ser
terminado). En realidad, muchos proyectos EET han sido contratados de
esta forma, así, con la entrega por etapas (de los requisitos de alta
prioridad en primer lugar), y fuera de las cláusulas Si etapas no fueron
satisfactorios.
4.2.4 En respuesta a cambiar con el seguimiento de un plan. Es cierto
que las EET en general se construye alrededor de la planificación de
todo el proyecto de desarrollo. Gran parte de este fue el resultado de la
negociación del contrato discutido anteriormente. En primer lugar, sin
embargo, cualquier plan de cualquier valor real es un documento vivo
que cambia a medida que avanza el proyecto. TSE pudo haber planeado
un proyecto completo, pero ningún plan sobrevive a su primer encuentro
con el trabajo real y los planes son casi garantizado para cambiar
después de cada iteración o liberación. En segundo lugar, no hay
ninguna razón para creer que las EET no podía trabajar en un ambiente
que sólo se planeó cada iteración (aunque fueran iteraciones muy
cortas). Incluso ASD trabajar dentro de un contrato negociado tiene
planes para el proyecto en general, si son más ligeros y menos
detallados planes o no.
4.3 Comparación de Metodologías, métodos y técnicas
Al comparar las metodologías no es fácil porque por su propia naturaleza que
necesitan para personalizar antes de que puedan ser utilizados, y con frecuencia
hay espacio para un amplio grado de variación en todos los aspectos del método
personalizado. Así, por ejemplo, la metodología Proceso Unificado (UP) que se
mantiene a menudo para ser el arquetipo de TSE se puede personalizar para
proporcionar métodos magras y ágiles, por ejemplo, el método dX [46, 47], el
Proceso Unificado Ágil [48, 49], y el Proceso Unificado esencial [50]. Así que en
lugar de comparar las metodologías, métodos o incluso, directamente del artículo
discutirá una serie de diferentes características de los métodos. Estos son:
4.3.1 Gestión de Proyectos. Hay dos aspectos de la gestión de proyectos que
son relevantes para esta comparación: 1) que gestiona el proyecto, es decir,
quién es el responsable del éxito del proyecto, y 2) lo que la dirección se
utilizan técnicas. TSE es a menudo descrita como teniendo la gestión de arriba
hacia abajo del proyecto, por ejemplo, con un director de proyecto
4758
4756
papel, mientras que ASD es retratado como devolver la responsabilidad al equipo
(tal vez con la ayuda de los entrenadores y los Maestros.) La última forma de
gestión de proyectos es, sin duda no se limita a ASD sin embargo. El TSP era
fuerte en hacer que el equipo responsable de gestionar el desarrollo, a partir de
la estimación de horarios para la realización del trabajo. Muchos métodos (ASD y
TSE) ya la autonomía de los equipos para asumir la responsabilidad de
iteraciones de planificación (o lanzamientos) y la entrega de esos planes.
4.3.2 Longitud de iteración. Aparentemente, un ciclo de vida de desarrollo de software
altamente iterativo e incremental parece ser una de las características definitorias de
TEA. Esto también se debe probablemente al hecho de que los TEA es a menudo
comparado con una cascada SDLC (a menudo atribuido a TSE). Por desgracia, esto es
algo así como una comparación del hombre de paja. La mayoría (si no todos) los
métodos de desarrollo de software contemporánea emplean SDLCs iterativo e
incremental. Dicho esto, al igual que el desarrollo TSE menudo no puede cumplir con las
mejores prácticas y cae de nuevo a la pseudo cascada, también lo puede ASD caer de
nuevo a “Agua de melé caída”, como se mencionó anteriormente. Así que la idea de que
la TEA se diferencia de EET en que es altamente iterativo (es decir, longitudes de
iteración son de unas pocas semanas a algunos meses), mientras que las EET es
predominantemente cascada es incorrecta. Incluso el prototipo de los métodos de
detección de la EET,
Proceso Unificado,
sugiere longitudes de iteración de unas pocas semanas a un mes o así.
4.3.3 Incrementos funcionales. TSE ha permitido cualquier forma de
incremento en el desarrollo, por ejemplo, componentes o rebanadas
horizontales de funcionalidad en capas de la arquitectura de software.
ASD ha sido enfático en la necesidad de incrementos verticales de
funcionalidad que completan una historia de usuario. La razón de esto es
doble: 1) para proporcionar un valor directamente utilizable para el
cliente, y 2) para asegurar que ningún residuo se produce en exceso de
ingeniería o mal ingeniería cualquier parte de la solución. El único código
que se desarrolla en cada capa es la necesaria para cumplir con la
historia de usuario actual. Esto puede ser un enfoque más delgado pero
no está claro que conduce al diseño más eficaz de cada capa, al menos
no de la manera más directa. Claramente, el TSE no es incompatible con
el desarrollo de las rebanadas verticales si se desea. EET, sin embargo,
4.3.4 Modelos (Documentación aka). TSE ha estado comprometida con el
desarrollo de modelos en todas las fases de desarrollo de software. Si bien estos
han sido tradicionalmente en forma de documentación (incluyendo figuras y texto),
esta no es la única manera de construir modelos. Como se mencionó anteriormente,
el TSE considera que la construcción de estos modelos antes de implementar el
código se puede encontrar errores y corregirlos antes con menos esfuerzo. TEA
(como se evidencia en varios de los métodos, por ejemplo, DSDM) no están en
contra de los modelos adicionales, sólo que los métodos más populares prefieren
código de texto y figuras, y prefieren no persistir cualquier cosa menos código.
También en ASD modelos temporales y fragmentados se utilizan generalmente para
ayudar a la comunicación entre los individuos y dentro de la
equipo en lugar de especificar el sistema de una manera alternativa (o dentro de una
fase diferente) como es el caso de las EET.
4.3.5 Arquitectura. EET procesos implican casi siempre el diseño inicial
de la arquitectura. Esta es seguido
caracterizado por ASD como “arquitectura de gran adelantado (o diseño)” e hizo
sonar sinónimo de perder e incluso un mal diseño. Sin embargo, no es necesario
para el diseño de toda la aplicación de software que se completará en la delantera.
El reclamo por ASD surge que la arquitectura también es difícil de comprender.
Grandes decisiones como el enfoque de la persistencia o necesitan una arquitectura
de varios niveles o de múltiples capas que hacerse algún tiempo al principio del
proyecto de desarrollo de software, ya que son fundamentales para la estructura de
la solución. ASD afirma que tales decisiones arquitectónicas son hechos justo a
tiempo en ASD mientras que a menudo demasiado temprano en la EET.
4.3.6 Técnicas. La comparación de la aplicabilidad de las técnicas de ASD
para TSE también es interesante. Para esta investigación se investigaron
una lista de técnicas (descritos en la sección anterior) que están
predominantemente asociados con el desarrollo de software ágil. Para
cada técnica se consideró si la técnica sólo era útil con TEA o TSE o con
éxito podría ser utilizado tanto dentro de paradigma. Se encontró que casi
todas las prácticas que se asocia con TEA podría aplicarse en el contexto
de las EET. Esto quiere decir que estas prácticas no son realmente
definen diferencias entre TEA y TSE. La única técnica sobresaliente es el
desarrollo basado en componentes (CDB), que en realidad no es
compatible con el enfoque de TEA en vertical,
característica
desarrollo, es decir, desarrollo de una característica particular en todas las capas
en una aplicación, en lugar de centrarse en un componente o subsistema en
particular dentro de una capa.
5. Resumen y trabajos futuros
Esta investigación ha revisado ágiles de desarrollo de software (ASD)
metodologías, métodos y técnicas en un contexto de ingeniería de software
tradicional (TSE). El objetivo de esta investigación era tratar de determinar si
estos enfoques para el desarrollo de software eran compatibles,
considerando sus similitudes y diferencias. Se ha encontrado que en las
zonas donde se podría, tal vez, inicialmente asumir hay diferencias (por
ejemplo, una longitud de iteración porque está tan a menudo mencionado)
TSE y ASD son muy similares. Donde sí parecen diferir es más sutil (por
ejemplo, en el uso de modelos).
EET no es incompatible con los individuos y
interacciones sobre los procesos y las herramientas de software, que trabajan
sobre una amplia documentación, colaboración de los clientes sobre la negociación
del contrato, o que responden a cambiar con el seguimiento de un plan. TSE
abarca la creencia de que la creación (y persistente) requisitos, análisis y diseño de
modelos mejorará todos los resultados de los proyectos (como la hora, el
presupuesto, la funcionalidad y la calidad). Del mismo modo, la CIA no parece estar
en contra de los modelos más modelado o no de código, aun persistiendo esos
modelos, siempre y cuando se agregan valor. Abarca otros modelos, en particular,
por ejemplo, diversos
4759
4757
actividades de prueba (aunque éstos siguen siendo a menudo en el código).
ASD ha revolucionado la gestión de desarrollo de software, aunque un número
de las técnicas se han utilizado anteriormente en las EET (por ejemplo, en
TSP).
TSE y ASD como mejor se practica son similares en su búsqueda de longitudes
cortas de iteración. Ambos tienen que emplear todas las fases de desarrollo de
software, aunque de manera más informal y sin “documentación” dentro de ASD.
Ambos buscan la participación significativa de clientes, aunque cuando TEA exige, en
general, sólo TSE ha deseado que (y ambos menudo tienen dificultades para lograrlo).
Tanto el desarrollo de modelos (también conocido como documentación) para la
comunicación entre los individuos (o dentro de los equipos). Y, finalmente, ambos
tienen como objetivo ofrecer un valor todo el tiempo, aunque la forma de este valor
puede ser diferente.
Las diferencias comienzan con el hecho de que ASD requiere que valor
entregado es directamente visible para el usuario, mientras que TSE es
generalmente feliz con valor que no es inmediatamente visible para el usuario (por
ejemplo, en componentes o capas ocultas). TEA es mejor en el modelado solamente
a un nivel de detalle que se necesita, mientras que las EET generalmente trata de
construir modelos completos (iterativa). TSE le gusta hacer el mayor conocimiento
sobre el problema y solución explícita dentro de los modelos, mientras que los TEA,
en términos generales, está feliz por ese conocimiento para vivir dentro de las
cabezas de los desarrolladores (e indirectamente en el código). ASD apoya y
fomenta la arquitectura emergente y en evolución, mientras TSE fomentar la
arquitectura inicial (con la justificación y la evaluación de las opciones). La mayoría
de los modelos que persisten en los TEA son a menudo basados ​en código, mientras
TSE alienta a muchos modelos de especificación.
Al final parece que no hay nada realmente incompatible con la
aplicación de todos los principios y valores de TEA, junto con la mayoría
(si no todos) de las prácticas, a las EET. La única razón por la que parece
que los TEA sería infeliz con múltiples modelos
para especificación (no sólo
la comunicación) es si ellos no se pueden mostrar para mejorar la
eficiencia y eficacia del desarrollo global de software. Por lo tanto, parece
que hay espacio y la posibilidad de una fusión de estos dos enfoques, tal
vez una ágil Ingeniería de Software (ASE). Se necesitan investigaciones
adicionales para considerar lo que sería necesario para hacer esto una
realidad.
6. Referencias
[1] Pekka, A., Outi, S., Jussi, R. y Juhani, W. ágil de software
Métodos de desarrollo - revisión y análisis. Publicaciones VTT, Ciudad, 2002.
[2] Awad, MA Una comparación entre los ágiles y tradicional
Tecnologías de desarrollo de software. La Universidad de Western Australia,
2005. [3] McConnell, S. El rápido desarrollo: el software fierecilla salvaje
horarios. Microsoft Press Redmond, WA, EE.UU., 1996. [4] Royce, WW La
gestión del desarrollo de software de gran
Los sistemas. Ciudad, 1970.
[5] Laplante, PA y Neill, CJ La desaparición de la cascada
modelo es inminente y otros mitos urbanos. ACM cola, 1, 10
2004), 10-15.
[6] McConnell, S. y Tripp, Introducción de L. Evaluación Editor:
Profesional de Ingeniería de Software - ¿realidad o ficción? IEEE Software ( Noviembre el color con UML: componentes de la empresa y proceso.
/ Diciembre 1999). [7] Hunt, A. y Thomas, D. El programador pragmático: desde
oficial de dominar. Addison-Wesley Professional, 2000. [8] Gibbs, crisis
crónica de WW Software. Científico americano,
271, 3 (1994), 72-81.
[9] Naur, P. y Randell, B. Ingeniería de Software: Informe de una
conferencia patrocinada por el Comité de Ciencia de la OTAN (7-11 de octubre 1968),
Garmisch, Alemania. División de Bruselas, Asuntos Científicos, la OTAN ( 1969).
[10] DeMarco, T. Ingeniería de Software: Una idea cuyo tiempo ha
ido y venido. IEEE Software, 26, 4 (2009), 95-96.
[11] Loka, desarrollo de software RR: ¿Cuál es el problema?
Computadora, 40, 2 (2007), 112-111.
[12] Cockburn, A. y Highsmith, J. Desarrollo Ágil de Software.
Mensajes de las personas y telecomunicaciones Publishing House,
2003.
[13] Cohen, D., Lindvall, M. y Costa, P. ágil de software
desarrollo. 2003.
[14] Martin, RC desarrollo ágil de software: principios,
patrones y prácticas. Prentice Hall PTR, 2003. [15] Poppendieck, M. y
Poppendieck, T. lean software
el desarrollo: Un conjunto de herramientas ágiles. Addison-Wesley Professional,
2003.
[16] Poppendieck, M. y Poppendieck, T. La implementación de Lean
Desarrollo de software: del concepto a la caja (Addison-Wesley La serie de la
firma). Addison-Wesley Professional,
2006.
[17] Ebert, C., Abrahamsson, P. y Oza, Lean Software N.
Desarrollo. IEEE Software 2012), 22-25.
[18] Cockburn, A. Desarrollo Ágil de Software. Ciudad, 2000-2001. [19] Beck, K.,
Beedle, M., Bennekum, A. v., Cockburn, A.,
Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries,
R., Kern, J., Marick, B., Martin, RC, Mellor, S., Schwaber , K., Sutherland, J. y
Thomas, D.
Manifiesto de desarrollo de software ágil. Ciudad, 2001. [20] Ambler, SW Agilidad en la
Escala: convertirse en tan ágil como sea posible
ser. 2009.
[21] Paige, RF Cuando son complementarios métodos? Información
Software y Tecnología, 41, 3 (1999), 157-162.
Rational Unified Process [22] RationalSoftware: Buenas Prácticas
para los equipos de desarrollo de software (1998). [23] Kruchten, P. El proceso
unificado racional: una introducción.
Addison-Wesley Professional, 2004. [24] Beck, K. La programación extrema
explicó: aceptar el cambio.
Addison-Wesley Professional, 2000.
[25] Schwaber, Proceso K. SCRUM Desarrollo (1987). [26] Schwaber, K. y
Sutherland, J. ¿Qué es Scrum. URL:
http://www.scrumalliance.org/system/resource/file/275/whatIs
Scrum.pdf2007) .
4760
4758
[27] Coad, P., Lefebvre, E. y De Luca, J. modelado en Java
Prentice Hall, 1999.
[28] Anderson, DJ-Feature Driven Development (2004). [29] Palmer, SR y
Felsing, M. Una guía práctica para feature-
el desarrollo impulsada. Pearson Educación, 2001. [30] Martin, J. Desarrollo
rápido de aplicaciones. Macmillan
Publishing Co., Inc., 1991. [31] Stapleton, J. DSDM, sistemas dinámicos método
de desarrollo:
el método en la práctica. Addison-Wesley Professional, 1997. [32] Highsmith,
JA desarrollo de software adaptativo. Dorset
Casa, 2000.
[33] Bayer, S. y Highsmith, J. desarrollo de software radicales.
Programador de América, 7 (1994), 35-35. [34] Humphrey, W. Introducción al
Software Personal
Proceso. Addison-Wesley, Reading, MA, 1997. [35] Humphrey, Proceso WS
Software Team (2000). [36] Humphrey, WS El uso de un definido y medido
personal
procesos de software. Software, IEEE, 13, 3, 1996), 77-88.
[37] Humphrey, W. Una disciplina de Ingeniería de Software.
Addison-Wesley, Sydney, 1995. [38] Naumann, J. Prototyping: El nuevo
paradigma para Sistemas
Desarrollo. sistemas de información de gestión trimestrales, 6,
3 1982), 29-44.
[39] Boehm, B. Un modelo espiral de desarrollo de software y
mejora. SIGSOFT n del software. Ing. notas, 11, 4, 1986), 14-
24.
[40] Beydeda, S., libro, M. y Gruhn, V. de software basada en modelos
desarrollo. Springer Verlag, 2005. [41] del Norte, C. Intoducing BDD. Dannorth.net,
Ciudad, 2006-2011. [42] Jacobson,
YO. Orientada a Objetos Ingeniería de Software.
Addison-Wesley, 1992.
desarrollo impulsado por la prueba [43] Janzen, D. y Saiedian, H.
conceptos, taxonomía, y la dirección futura. Computadora, 38, 9 (2005), 43-50. [44]
Evans, E. Diseño guiado por el dominio: hacer frente a la complejidad de la
corazón del software. Addison-Wesley Professional, 2004. [45] West, D.,
Gilpin, M., Grant, T. y Anderson, A. Agua-
Scrum El otoño es la realidad de ágil para la mayoría de las organizaciones hoy en día. 2011.
[46] Booch, G., Maksimchuk, R., Engle, M., Young, B., Conallen,
J. y Houston, K. análisis orientado a objetos y el diseño con aplicaciones. Addison-Wesley
Professional, 2007. [47] Ambler, SW RUP más delgada. City, 2006. [48] Ambler,
S., Nalbone, J. y Vizdos, M. empresarial unificada
proceso, el: extender el proceso unificado racional. Prentice Hall Press, 2005.
[49] Van Baelen, H. Agile (Proceso Unificado). 2011. [50] Jacobson, I. EssUP:
The Essential Unified Process-Un
Introducción. Ciudad.