Metodología Goal-Driven Software Development Process ( GDS)

¨Proceso de desarrollo de software orientado a

objetivos¨

Abstracto
Los procesos de desarrollo de software establecidos se enfocan en entregar software
dentro del tiempo y el presupuesto de acuerdo con un conjunto de requisitos. Sin
embargo, las experiencias prácticas muestran que ni los procesos comerciales ni los
requisitos pueden ser completamente entendido en una etapa temprana de un software
realista proyecto. Esto no se debe principalmente a requisitos inadecuados provocación,
pero el hecho de que la implementación técnica constituye una formalización de una
forma más o menos difusa dominio comercial que revela lagunas e inconsistencias.
Además, la tecnología utilizada agrega restricciones y permite nuevos procesos. Por lo
tanto, tratando de establecer los requisitos por adelantado causa solicitudes de cambio,
sobrecostos de tiempo y costo, o incluso la cancelación del proyecto. Este documento
continúa la línea de pensamiento de los modelos de procesos iterativos por el software el
desarrollo como un proceso iterativamente convergente de negocios objetivos y
tecnología de ambos lados. Este "gol conducido" proceso "se aplica con éxito en la vida
real comercial proyectos de software y ha contribuido en varias ocasiones a la baja costo
pero software de alta calidad.

1 convergencia vs. Refinamiento

El papel de la tecnología de la información para los procesos comerciales todavía parece
ser subestimado. El software no es solo es un medio para un fin, pero tiene un rol
habilitador y viceversa, cambia los procesos de negocios. Sobre el último 30 años, la
complejidad rápidamente creciente de los sistemas de software junto con el creciente
impacto económico de la gran escala proyectos de software dieron lugar a un desarrollo
de software disciplinado procesos, como el modelo de cascada [20], la espiral modelo o el
Proceso Unificado Racional [12], más recientemente. Sin embargo, la reciente aparición de
enfoques ágiles [5] promueve estrategias de desarrollo bastante diferentes demuestran
que los procesos de desarrollo de software aún están lejos de tener alcanzó un estado
estable o incluso terminado y significativo las mejoras aún son posibles y necesarias.

1.1 ¿Los requisitos están sobrevalorados?

En este documento, ponemos un aspecto específico del software procesos de desarrollo
en cuestión que es el prevalente fuerte concentración en los requisitos. En cuanto a
nuestra experiencia, el concepto erróneo extendido y el énfasis excesivo de requisitos
como una interfaz entre negocios y software unidades repetitivamente causa costos
excesivos y calidad reducida del resultado Existen dos motivos principales para esto:

1. Los requisitos generalmente no son idénticos a los negocios objetivos porque la

selección de requisitos en la parte del software de la solución general ya está
normalmente acuñado por el conocimiento limitado del autor del documento de
requisitos sobre posibilidades técnicas y sus costos.
P.ej. para las personas con antecedentes no técnicos es difícil de entender que un cierto
comportamiento de un control en una interfaz gráfica de usuario puede convertirse en
excesivamente caro, mientras que un amplio conjunto de estadísticas los análisis pueden
venir casi gratis además de un relacional base de datos. Documentos de requisitos escritos
por estas personas tienden a incluir costos innecesarios desea al tiempo que excluye
características técnicamente simples que proporcionaría un beneficio sustancial.

2. El desarrollo de un sistema de software corresponde a una formalización del proceso

comercial compatible. Esta la formalización generalmente revela inconsistencias y lagunas
dentro del proceso comercial actual u objetivo que en el giro debe ser compensado con
cambios en el negocio proceso o el papel del sistema de software.

El resultado de estos dos efectos suele ser un gran número de solicitudes de cambio
durante y después del desarrollo que implica tiempo que un costo se excede.
Argumentamos que este es uno de las razones principales, por qué la participación del
usuario se encuentra en primer lugar de los factores de éxito del proyecto. Viceversa, la
falta de entrada del usuario como así como los requisitos incompletos o cambiantes están
en la parte superior de la enumerar los factores de desafío del proyecto en los informes de
CHAOS [1].

1.2 Desarrollo orientado a objetivos

En lugar de refinar los requisitos a una implementación por lo tanto, recomendamos tratar
de encontrar un óptimo mapeo entre los objetivos comerciales y las capacidades de la
plataforma técnica en un proceso iterativo. La Figura 1 ilustra esta sutil diferencia que
tiene consecuencias de largo alcance en varios roles y actividades.
Mientras que los procesos de software establecidos (a la izquierda) refinan requisitos
hasta una implementación (con suerte iterativamente) para reducir los riesgos), el proceso
de desarrollo impulsado por objetivos (derecha) sugerida en este documento igualmente
considera y ajusta los objetivos comerciales y los aspectos técnicos para llegar a un
solución óptima correspondiente a la situación actual.
Resumen La siguiente sección 2 explica los principios clave del proceso impulsado por
objetivos propuesto en este documento antes detallamos actividades concretas del
proceso orientado a objetivos en la sección 3. La sección 4 discute nuestras experiencias
prácticas con el proceso dirigido por metas. Este documento concluye con un visión
general del trabajo relacionado en la sección 5 y un breve resumen en la sección 6.
2 Principios clave del proceso
Identificar objetivos antes de establecer los requisitos influencias varios principios básicos
del proceso. Los siguientes párrafos describir cómo se pueden identificar los objetivos y
cómo esto afecta la orientación de arriba hacia abajo versus de abajo hacia arriba, la
organización del equipo, roles y tamaño del proyecto.

2.1 Identificación colaborativa de objetivos

Nuestra concepción de los objetivos comerciales está estrechamente relacionada con la
Meta-pregunta-paradigma métrico [3]. Se define un objetivo de alto nivel como una
descripción informal de lo que una parte interesada quiere para cambiar o mejorar en su
entorno comercial. Muestra los objetivos son: "aumentar nuestro conocimiento sobre los
artículos en existencia" o "aumentar la rentabilidad de los eventos de marketing". En
contraste con esto, los objetivos no válidos son "el sistema debería proporcionar una lista
de todos los artículos en stock en formato de barra foo. . . ".
Como se muestra en la figura 2, cada objetivo puede tener uno o más Subgoles.
Un conjunto de preguntas está vinculado a cada objetivo, que caracteriza la forma en que
el software será probado contra definido objetivos después de una iteración. Se alcanza
un objetivo, si cada pregunta de la meta se responde positivamente y todos sus objetivos
intermedios se logran Artefactos (como especificaciones de requisitos, documentos,
código fuente, etc.) se pueden asignar a las hojas del árbol de gol. Los interesados y
contratistas deben colaborar estrechamente elaborar objetivos para que las partes
interesadas sepan qué es factible y los contratos obtienen una comprensión profunda del
negocio procesos respectivamente. Mientras que la definición del objetivo es de arriba
hacia abajo impulsado, decidiendo, si un objetivo es factible es de abajo hacia arriba
orientado En otras palabras, la identificación colaborativa de objetivos trae conocimiento
de los usuarios y desarrolladores de software juntos.
2.2 Convergencia descendente y ascendente
La mayoría de los procesos establecidos refinan los requisitos de arriba hacia abajo a la
implementación. La principal ventaja de arriba hacia abajo la orientación es que permite
una organización de equipo horizontal. Por el contrario, los enfoques ascendentes
intentan proporcionar información generalizada y por lo tanto, componente altamente
flexible y reutilizable

componentes o servicios. En un ambiente de cambio constante y evolución, el enfoque de

diseño de abajo hacia arriba produce sistemas que proporcionan una satisfacción superior
a los usuarios en comparación con la parte superior hacia abajo los desarrollados [14, 18].
En el PIB, la identificación colaborativa de objetivos permite para combinar de arriba hacia
abajo con aspectos ascendentes. A esto lo llamamos pensamiento de arriba hacia abajo y
de abajo hacia arriba. Como resultado de una consecuente convergencia descendente y
ascendente un desarrollador de software se ve obligado a mantener todos los artefactos
anexo a un objetivo específico que implica un equipo vertical organización.
2.3 Organización del equipo vertical
A diferencia de los equipos de proyectos organizados horizontalmente, donde los
programadores implementan la solución especificada por el equipo de modelado, la
organización vertical implicada por El PIB requiere generalistas calificados y calificados.
Todo desarrollador de software debe ser creativo para encuentre las mejores soluciones
técnicas correspondientes a un alto objetivo de negocio de nivel, pero también es
responsable de la entrega de la implementación, porque, una vez más, es de esperar que
los objetivos y los objetivos secundarios deben revisarse de abajo hacia arriba de acuerdo
con el conocimiento ganado durante la implementación. Obviamente, a menudo se elige
una organización horizontal en proyectos de software de la vida real, ya que muchas
organizaciones intentan para disminuir el tiempo de desarrollo general aumentando el
número de personas que trabajan en un proyecto de software, aunque esto claramente
ignora la literatura de ingeniería de software [11]. Sin embargo, proporciona posiciones
específicas que solo requieren una calificación estrecha, como modeladores de tiempo
completo, facilita en gran medida sobre los proyectos de software de dotación de
personal. En cuanto a nuestra experiencia una organización de proyecto vertical delgada
es mucho más productivo que un proyecto organizado horizontalmente con numerosos
especialistas y las interfaces de comunicación entre ellos. La Tabla 1 resume algunas
diferencias importantes entre una organización de equipo vertical y horizontal.
El Proceso Unificado es muy claro sobre el hecho de que el individuo los desarrolladores
pueden y deben tomar múltiples roles en un proyecto. Lamentablemente, este consejo
todavía parece caer en la sordera orejas dentro de muchas organizaciones. En realidad, las
organizaciones tienden a llenar cada función, como el especificador de requisitos, el
sistema analista, diseñador de interfaz de usuario y diseñador de base de datos, con
Gente diferente. La sobrecarga de comunicación resultante como así como los conflictos
emergentes aumenta el tiempo de desarrollo y cuesta dramáticamente.

2.4 Roles y personas

Debido a su organización vertical, el PIB requiere generalistas calificados con la capacidad
de cumplir muchos roles del proceso. El PIB distingue los siguientes roles clave.

Programadores Es bien sabido que los mejores programadores son hasta mil veces más
productivos que el peor, pero los peores superan a los mejores por un margen similar
[6, 10]. Por lo tanto, los programadores son los más importantes y por lo tanto expertos
más caros. Ellos hacen el diseño preliminar y son responsables de arriba hacia abajo y
convergencia de abajo hacia arriba. Ellos tienen la influencia principal en entrega de
software en tiempo y presupuesto.
Analistas de negocios Los analistas de negocios son importantes para entender los
procesos comerciales de las partes interesadas. El negocio analista colabora con los
programadores durante la meta identificación y más tarde durante la prueba. El analista
de negocios debe tener una comprensión profunda de las partes interesadas dominio de
negocio. Arquitectos de software El papel del arquitecto de software [9] es estrechamente
conectado con los programadores. A diferencia de un programador quien se enfoca en un
objetivo específico, el arquitecto de software mantiene un ojo en todo el proyecto.
Project Manager La tarea principal de un gerente de proyecto es organizar el proyecto
asignando recursos, manteniendo seguimiento de tiempo y esfuerzo, y crear un entorno
productivo para el equipo del proyecto.

Ingeniero de requisitos En la medida de nuestra experiencia, el papel de los ingenieros y

diseñadores de requisitos es a menudo muy sobreestimado. Si una vez el único trabajo es
producir modelos, entonces habrá una fuerte tendencia a modelar cosas, como es natural,
todos quieren hacer un buen trabajo.
Gente Una vez más, sin lugar a dudas los tres más importantes ingredientes para lograr
eficiencia y productividad en los proyectos de software son personas capacitadas,
calificadas y motivadas. Sin duda, esta idea no es nueva por sí misma. Primeros trabajos
en la importancia de las personas para proyectos de software exitosos data de Marcos
Peopleware [8]. Procesos ágiles como XP y otros [5, 4, 2] también se centran en las
habilidades individuales y comunicación. Prácticas como la programación de pares
apuntar a aumentar las habilidades de las personas dentro del equipo, también.
Propiedad del código colectivo y prácticas de refactorización son otros ejemplos de cómo
los métodos ágiles intentan asignar responsabilidad mientras que requiere y aumenta las
habilidades. Como Grady Booch dijo: Las personas son más importantes que los procesos
[7]. Los El PIB sigue esta idea a través de la organización vertical del equipo y planear solo
unos pocos roles diferentes.
2.5 Minimizar el tamaño del proyecto
Otra clave comúnmente conocida para el éxito en proyectos grandes es minimizar el
tamaño del proyecto en todos los aspectos. Minimizando el tamaño del proyecto no solo
significa limitar el número de objetivos y artefactos de software como documentos,
especificaciones de requisitos, modelos, etc., pero también para limitar la cantidad de
personal, para evitar la espera mutua (por ejemplo, los requisitos deben definirse antes
implementación en procesos establecidos) y el tamaño del código Sabemos por
experiencia que por consiguiente elegir una solución simple, el tiempo de desarrollo y el
número de líneas de código puede reducirse alrededor del 50% en comparación con la
aplicación de marcos flexibles que eventualmente podría ser útil una vez en el futuro.
Minimizar el tamaño es la medida más efectiva para aumentar la capacidad de
mantenimiento y la capacidad de cambio del sistema para
Procesos comerciales nuevos y cambiantes en el futuro. Nota, que los procesos
comerciales son el factor más probable para cambiar con el tiempo [17]. Cambios del
sistema de base de datos o el entorno técnico es bastante raro e impredecible para que
los marcos complicados altamente sofisticados puedan difícilmente justificado.

Organización vertical del equipo Organización horizontal del equipo

Pocos pero altamente calificado personal Se puede usar personal poco calificado
necesario
Baja sobrecarga de comunicación El personal es intercambiable
Todos deben estar familiarizados con (sub) Muchos miembros del equipo no conocen
metas para ningún negocio
el cual es asignado objetivos
La paralelización es simple de ganar Paralelización limitada debido al orden
secuencial de
ocupaciones
Alta motivación e identificación fuerte con Menor motivación debido a la menor
el resultado responsabilidad por
resultado general

Tabla 1. Organización del equipo vertical versus horizontal

3 Actividades guiadas por objetivos

La Figura 3 representa las actividades centrales del PIB y muestra cómo su organización en
iteraciones. Cada iteración comienza con la identificación del negocio objetivos y sus
prioridades y termina con una versión en funcionamiento del sistema de software
correspondiente a los objetivos seleccionados. Mientras que el desarrollo incremental del
sistema de software es también hecho en otros procesos, ampliamos el alcance de la
iteración incluir una discusión de los objetivos comerciales después de cada iteración,
porque con frecuencia experimentamos que el negocio los objetivos mismos maduran con
la disponibilidad de implementación utilizable.

3.1 Identificación de objetivos

La definición de objetivos se hace en pequeños grupos de la mayoría de las 5 personas
formadas por partes interesadas y / o empresas analistas y programadores. Las partes
interesadas o el negocio analista tiene la responsabilidad de explicar sus objetivos a la
programadores sin tomar ningún aspecto técnico de una posible solución en cuenta. La
responsabilidad del programador es triple Primero, tienen que mantener el negocio la
atención de las personas se centró en los objetivos comerciales en lugar de tecnología. En
segundo lugar, tienen que ofrecer ideas sobre lo que podría hacerse con la tecnología de
la información para lograr estos objetivos. En tercer lugar, tienen que informar al lado
comercial sobre los diferentes costos de posibles alternativas para permitir la priorización
de los objetivos.
3.2 Distribución vertical de tareas
Basado en las prioridades de los objetivos y habilidades individuales de programadores,
los objetivos seleccionados se asignan a grupos de la mayoría de los 4 programadores.
Dependiendo del proyecto, un programador puede asociarse con varios objetivos de vicio
versa. A partir de ahí, cada equipo de programadores decide dentro de un límite dado,
qué (producto) se construirá cómo (actividad), por quién y cuándo.

3.3 Implementación y prueba

La implementación y las pruebas son el proceso más importante disciplinas y recibir la
mayor cantidad de tiempo porque implementación y prueba son las únicas actividades
que afectar directamente la calidad del producto. En palabras simples, si el software
sistema está bien implementado y corresponde a los objetivos comerciales, ¡el proyecto
tendrá éxito! El PBI distingue entre impulsado por la implementación y pruebas dirigidas
por objetivos. Pruebas impulsadas por la implementación están hechas por el
programador permanentemente durante la implementación. Esto incluye escribir y
ejecutar casos de prueba, así como prueba manual. Las pruebas dirigidas a objetivos se
ejecutan al final de cada iteración y comparar la implementación real con las preguntas
formuladas durante la identificación del objetivo. Nota, que una falta de acuerdo, podría
indicar un defecto en la implementación como en las pruebas convencionales, pero
también podría indicar una debilidad en la definición de objetivos. Ambas posibilidades se
toman en consideración.

Figura 3. Repetición del PIB

Identificación de objetivos (stakeholder / desarrollador)

Priorización de objetivos (stakeholder / desarrollador)

distribución vertical de tareas (desarrollador)

Implementación / prueba (desarrollador)

despliegue (desarrollador)
4 Experiencia práctica
El proceso esbozado en este documento ya ha demostrado sus beneficios en proyectos de
software comercial.
Un ejemplo es un proyecto a gran escala con un total de más más de 50 años-hombre,
interés crítico para las partes interesadas y una fecha límite difícil Aquí, el PIB contribuyó a
un costo del 30% reducción que compara los costos de desarrollo de 2005 con 2004.
Después de la introducción del PIB, el calendario del esfuerzo de desarrollo se consideró
como confiable para la primera vez desde que se inició este proyecto.
Antes de la introducción del PIB, unas treinta personas estuvieron involucrados y
organizados en una estructura de equipo horizontal; yo. mi. los individuos fueron
asignados permanentemente a solo

1-Debido a los acuerdos de no divulgación, no hay detalles que permitan dibujar

conclusión sobre el sitio y el propósito de estos proyectos pueden ser publicados.

roles como arquitecto de software, diseñador o desarrollador. Muchos de los miembros

del equipo fueron contratados de un muy respetado proveedor de servicios de software
en Alemania para aumentar la calificación dentro del equipo del proyecto. Después de un
año de trabajo y se gastó cerca de 1 millón de euros, cientos de documentos fueron
escritos, pero casi ningún software implementado.
Como consecuencia, el proyecto fue cancelado y debido a su importancia se reinició con el
PIB y un equipo reducido tamaño de 8 programadores y 2 analistas de negocios. Dentro de
cinco meses 200000 líneas de código fueron escritas, probadas y sobre
100 solicitudes de cambio se integraron correctamente en el sistema.
Las partes interesadas ahora sienten que el software resultante mejora sus procesos
comerciales y está muy satisfecho.
Como parte de este éxito, las partes interesadas han decidido proceder con el PIB.

5 Trabajo relacionado
El trabajo descrito en este documento obviamente tiene un fuerte relación con modelos
de proceso como la cascada modelo [20], el V-Model2 [16], o proceso orientado a objetos
modelos como el proceso unificado racional [13]. Declaraciones como la necesidad de
personal calificado, minimizando el proyecto tamaño y entrega temprana y, a menudo
también se puede encontrar en ágil métodos [2] como Scrum [19] o XP [4].
Sin embargo, hay al menos una diferencia significativa entre el PIB descrito en este
documento y otro proceso modelos. Prácticamente todos los demás procesos (incluso
métodos ágiles) centrarse en los requisitos y tratar de mapearlos de arriba hacia abajo
para una implementación. El PIB se refiere a los objetivos en lugar de a los requisitos y los
combina con capacidades técnicas, lo que conduce a un enfoque integrado de arriba hacia
abajo y de abajo hacia arriba que produce un beneficio superior para el usuario.
Organizativo cambios, como la organización vertical del equipo, son consecuencia de esta
orientación a los objetivos.
La idea de incorporar una orientación ascendente en el proceso de desarrollo se ve
influenciada y respaldada por el trabajo sobre la evolución del software [15]. Por ejemplo,
el informe sobre el desarrollo y uso exitoso a largo plazo de McIDAS [14] llega a la
conclusión de que a) "requisitos no son de suma importancia, la satisfacción del usuario es
"y b) que el éxito a largo plazo no fue posible sin una obstinado enfoque ascendente. [18]
da más ejemplos por las ventajas de la orientación ascendente.

6 Resumen
Este documento presentó los conceptos básicos de una iterativa e incremental proceso de
desarrollo de software, llamado el objetivo impulsado proceso de desarrollo (GDP).
Claramente, el PIB es sin revolución y tiene muchas similitudes con otros procesos
modelos. Sin embargo, las diferencias sutiles del PIB tienen varias consecuencias y pueden
hacer una gran diferencia para la salida del proceso.
Las dos contribuciones clave del PIB son su concentración en los objetivos comerciales en
lugar de los requisitos y la explícita integración de una parte de abajo arriba. La
combinación de estos dos principios reflejan la dependencia mutua entre procesos de
negocio y tecnología de la información desde la información la tecnología no es solo un
medio para un fin sino también permite nuevos procesos comerciales. Experiencias
prácticas muestran que el PIB es capaz de entregar software de alta calidad a bajo costo
En cuanto a nuestra experiencia, el principal desafío pero también uno de los principales
beneficios junto con el PIB se mantiene el usuario del software se centró en aspectos
comerciales en su lugar de tecnología. En la actualidad, los empresarios todavía están
poniendo una enfoque increíblemente fuerte en los aspectos técnicos en sus requisitos
especificaciones, como requerir el uso de ciertos idiomas, marcos, arquitecturas y
productos estándar.
De hecho, la tecnología parece ser la única motivación para muchos proyectos, como una
migración a una solución basada en web.
Lo que el PIB está tratando de sugerir es que el negocio los usuarios estarían mucho mejor
si se mantuvieran enfocados en su experiencia empresarial y colaboración con técnicos
especializados personas para la implementación de sus objetivos.