SUPERVISIN (OVERSCOPING).

Contexto: La gestin del mbito es una parte esencial de la gestin de la

liberacin de software y, a menudo, un factor clave para liberar productos
de software exitosos al mercado. En un caso basado en el mercado, cuando
slo se conocen a priori unos pocos requisitos, el riesgo de overscoping
puede aumentar.
Objetivo: En este trabajo se presentan los hallazgos de un estudio de caso
destinado a comprender el overscoping en proyectos de desarrollo de
software a gran escala y orientados al mercado, y cmo las prcticas
ingeniosas de ingeniera de requisitos pueden afectar esta situacin.
Mtodo: Con base en una hiptesis de los factores que pueden estar
involucrados en una situacin de sobreescote, se realizaron entrevistas
semiestructuradas con nueve practicantes en una gran compaa de
software impulsada por el mercado. Los resultados de las entrevistas fueron
validados por seis (otros) profesionales de la compaa de casos a travs de
un cuestionario.
Resultados: Los resultados proporcionan un cuadro detallado de la
superposicin como un fenmeno que incluye una serie de causas, causas y
efectos, e indican que el sobreescote se debe principalmente al operar en
un dominio impulsado por el mercado y cmo este cambio incesante de
Requisitos. La dbil conciencia de los objetivos globales, en combinacin
con una baja participacin en el desarrollo en las primeras fases, puede
contribuir a "morder" ms de lo que un proyecto puede "masticar". Adems,
la superposicin puede dar lugar a una serie de consecuencias
potencialmente graves y costosas, incluidas cuestiones de calidad, retrasos
y falta de satisfaccin de las expectativas de los clientes. Por ltimo, el
estudio indica que el exceso ocurre tambin cuando se aplican prcticas
giles de ingeniera de requisitos, aunque la sobrecarga es ms manejable y
se percibe como resultado de menos esfuerzo desperdiciado al aplicar una
priorizacin de alcance continuo, en combinacin con requisitos detallados y
una estrecha cooperacin dentro de cross- Equipos funcionales.
Conclusin: Los resultados proporcionan una mayor comprensin del escopo
como una actividad compleja y continua, incluyendo un anlisis de las
causas, efectos, y una discusin sobre el posible impacto de las prcticas de
ingeniera de los requisitos giles a la cuestin del overscoping. Los
resultados presentados en este documento pueden utilizarse para identificar
factores potenciales a abordar con el fin de lograr un alcance de proyecto
ms realista.
1. Introduccin
Maximizar el valor de negocio de un producto y un conjunto de recursos
disponibles puede sonar como una simple tarea de seleccionar
caractersticas de acuerdo con el mayor retorno de la inversin. Sin
embargo, en la ingeniera de requisitos impulsada por el mercado (MDRE)
[38,59] los gerentes de productos de software enfrentan el desafo de
gestionar continuamente las necesidades cambiantes del mercado [1] con

un gran nmero de nuevos y cambiantes requisitos [28] causados tanto por

un caprichoso La situacin del mercado [19] y la evolucin de las
tecnologas. En esta situacin, la seleccin de los requisitos que deben
incluirse en la siguiente versin de un producto de software (tambin
denominada alcance [66] o alcance de proyecto [56]) es una tarea compleja
y continua de evaluar y reevaluar cmo afectan estos cambios de alcance al
comn Cdigo base de la lnea de productos de software [54] en la que se
construyen esos productos [71]. Este mbito de mbito se considera parte
del alcance de la lnea de productos [66], que desciende el valor de las
oportunidades de reutilizar la funcionalidad de la lnea de productos. Estos
factores, combinados con el aumento de la competencia en el mercado y la
impredecible respuesta del mercado a los nuevos productos, obligan a los
responsables de la toma de decisiones a enfrentarse continuamente a la
tarea de hacer y reevaluar las decisiones en un mundo en constante
evolucin [5].
Determinar el alcance de un producto para cumplir con un calendario
requerido es un riesgo conocido en la gestin de proyectos [13] y en nuestro
trabajo anterior [71] encontramos que el alcance del proyecto en una gran
empresa de software cambi significativamente durante todo el ciclo de
vida del proyecto. Estos cambios se debieron en parte a la superposicin, es
decir, establecer un mbito que requiere ms recursos de los que estn
disponibles. Varios investigadores se han centrado en la expansin del
alcance donde el alcance es aumentado por los desarrolladores, y destac
esto como un serio proyecto de riesgo [16, 17, 31]. Otros han investigado el
alcance como parte de la planificacin de la liberacin [66, 68, 71]. Sin
embargo, ningn estudio todava ha intentado investigar las causas y los
efectos de la superposicin aunque la toma de decisiones de ingeniera de
requisitos (ER) es un reto reconocido [2,5,50]. En este estudio, hemos
investigado este fenmeno de overscoping un proyecto, o mordiendo ms
que usted puede masticar, en particular en un contexto RE (VLSRE) basado
en el mercado y de gran escala [58].
Los procesos de desarrollo giles afirman abordar varios de los retos que
implica el alcance de los requisitos que cambian con frecuencia. Por
ejemplo, en la programacin de eXtreme (XP) [7] y Scrum [67], el equilibrio
entre el alcance y los recursos disponibles se gestiona mediante una
priorizacin extrema y una (re) planificacin constante del alcance en
combinacin con el tiempo-boxeo de las iteraciones individuales de
desarrollo. Sin embargo, tambin se ha descubierto que las prcticas giles
de ingeniera de requisitos plantean nuevos retos, por ejemplo, para lograr
un consenso sobre las prioridades entre mltiples partes interesadas y para
crear planes de proyecto precisos (costo y calendario) para todo un proyecto
[57].
El principal objetivo del estudio de caso presentado en este trabajo fue
aumentar la comprensin de los factores involucrados en la superposicin y,
por lo tanto, destacar este riesgo y dar un paso hacia el abordaje y evitar el
exceso de proyectos. Para lograr esto, el estudio fue diseado para
responder a las siguientes preguntas: (RQ1) Qu causa el exceso de
alcance? (RQ2) cules son los efectos resultantes de overscoping? Y (RQ3)
cmo pueden las prcticas agiles de ER impactar las causas y los efectos

del overscoping? El estudio de caso se ha llevado a cabo en una gran

empresa de desarrollo de software impulsada por el mercado que ha
comenzado a cambiar hacia una forma de trabajo ms gil. El estudio
incluye entrevistas con nueve profesionales que trabajan con ingeniera de
requisitos, desarrollo de software y pruebas de productos. Los resultados de
la entrevista fueron luego validados a travs de un cuestionario con otros
seis practicantes de la compaa de casos. La contribucin del trabajo
presentado incluye ocho causas principales de overscoping complementado
por una serie de causas de raz, y nueve efectos principales de overscoping.
Adems, los resultados indican que tres de las prcticas giles de ER
adoptadas por la compaa de casos pueden afectar algunas de estas
causas y causas raz y, por lo tanto, tambin pueden reducir los efectos de
la sobreescote.
Los resultados parciales de este estudio se han publicado previamente como
publicaciones de talleres en [11] donde el overscoping se investig
preliminarmente y en [10] donde se publicaron resultados preliminares
sobre los beneficios y efectos secundarios de las prcticas giles de RE. Para
este artculo, los resultados se amplan con (1) causas adicionales, causas
de raz y efectos de overscoping; (2) resultados empricos adicionales sobre
el overscoping de 6 (otros) profesionales; Y (3) detalles sobre el impacto de
las prcticas giles de RE especficamente en el overscoping. Estas
extensiones se lograron mediante un anlisis ms detallado del material
completo de la entrevista y una posterior validacin de los resultados
mediante un cuestionario.
El resto de este artculo est estructurado de la siguiente manera: La
seccin 2 describe el trabajo relacionado. La seccin 3 describe la compaa
de casos, mientras que el mtodo de investigacin se describe en la Seccin
4. Los resultados se informan en la Seccin 5 para las entrevistas y en la
Seccin 6 para el cuestionario de validacin. En la Seccin 7, los resultados
se interpretan y se relacionan con otros trabajos, y se discuten las
limitaciones y las amenazas de validez. Por ltimo, la seccin 8 contiene
conclusiones y trabajos ulteriores.
2. Trabajo relacionado
Planes y presupuestos poco realistas se encuentran entre los diez
principales riesgos en ingeniera de software [13] y se han sugerido algunas
razones para sobrecargar proyectos con alcance. Por ejemplo, DeMarco y
Lister mencionaron que un fracaso entre las partes interesadas en coincidir
con los objetivos del proyecto [20] (tambin uno de los retos de la ER gil
[57]) puede resultar en una carga excesiva de alcance en un proyecto. La
sobrecarga del proyecto tambin puede resultar de que el personal de
ventas acepte entregar caractersticas no realistas de gran tamao sin
considerar las implicaciones de programacin [29]. Adems, Iaconou y
Dexter [31] afirman que el alcance que se extiende ms all de los
requisitos formales de los desarrolladores, es decir, la fluencia del alcance,
es un factor que conduce a fallas en los proyectos. Tambin se menciona
que la expansin del alcance tiene un gran impacto en el riesgo y la gestin
de riesgos en los proyectos de almacenes de datos empresariales [43].
Adems, se enumera como uno de los cinco riesgos centrales durante la

fase de requisitos y es una consecuencia directa de cmo se recogen los

requisitos [20]. Por otra parte, Gemmer argumenta que la percepcin de
riesgo y el comportamiento posterior de las personas se pasa por alto en la
gestin del riesgo y que una mayor conciencia de las causas y los efectos de
los riesgos puede conducir a una mejor discusin y gestin de estos riesgos.
Algunos mtodos y herramientas para mitigar y gestionar los riesgos
relacionados con el mbito se han presentado [17]. Por ejemplo, Carter et
al. [16] sugiri la combinacin de prototipos evolutivos y la estrategia de
mitigacin de riesgos para mitigar los efectos negativos de la fluencia del
alcance. Sin embargo, la cuestin completa de overscoping no se menciona
explcitamente como un riesgo en el trabajo relacionado, ni se investiga
empricamente por sus causas y consecuencias.
La ingeniera de los requisitos (RE) es una parte intensa de la decisin del
proceso de la ingeniera de software [5], que puede apoyar y aumentar la
probabilidad de xito en el proceso de desarrollo [4]. Sin embargo, la
eficiencia y la efectividad de la toma de decisiones en ER tienen limitaciones
cognitivas [5], debido a ser una actividad intensiva en conocimiento. Por
otra parte, la investigacin en el campo de la toma de decisiones RE todava
est en su infancia [2,50]. Un desafo importante en esta investigacin (de
acuerdo con Alenljung y Persson) radica en la comprensin de la naturaleza
de la toma de decisiones de ER y la identificacin de sus obstculos [2] y
varios autores [2,4,5,50] mencionan la necesidad de: ) Identificar los
problemas de decisin en el proceso de ER; (2) realizar estudios empricos
de la toma de decisiones de RE; Y (3) examinar cmo las cuestiones no
tcnicas afectan o in fl uyen en la toma de decisiones. Las lagunas en la
comunicacin son un ejemplo de cuestiones no tcnicas que se ha
informado de que afectan negativamente a la toma de decisiones y
contribuyen a definir un alcance poco realista [12].
Hay dos caractersticas del MDRE [59] que agrava an ms la toma de
decisiones de ER, a saber, la falta de clientes reales con los que negociar
requisitos [37,55] y un flujo continuo de requisitos de mltiples canales [28,
38]. En consecuencia, en lugar de negociar con clientes especficos, las
demandas y exigencias de un mercado consumidor annimo tienen que ser
inventadas [55] a travs de estudios de mercado. Por otra parte, el xito
del producto fi nal es validado principalmente por el mercado con la
incertidumbre [59] de lo bien que los requisitos "inventados" se comparan
con las necesidades del mercado. Comnmente, la investigacin de
mercado emite continuamente ms requisitos [59] que los que se pueden
manejar con los recursos disponibles. Un estado de congestin entonces
ocurre en el proceso MDRE [38] y el conjunto de requisitos para
implementar en el prximo proyecto tiene que ser seleccionado utilizando
tcnicas de priorizacin basadas en predicciones de mercado y estimaciones
de esfuerzo [15, 33, 37].
La gestin del alcance se considera como una de las funciones bsicas de la
planificacin de la liberacin de software y una actividad clave para lograr
beneficios econmicos en el desarrollo de la lnea de productos [66]. La
planificacin precisa de la liberacin es vital para lanzar productos dentro de
la ventana ptima del mercado. Y, este es un factor crtico de xito para los
productos en el dominio MDRE [64]. La falta de esta ventana podra causar

tanto prdidas en ventas como costos adicionales para un desarrollo

prolongado y campaas de promocin desactualizadas. Sin embargo, la
elaboracin de planes de liberacin fiables basados en estimaciones
inciertas [38] y frecuentemente con caractersticas con dependencias con
otras caractersticas [14] es un desafo en s mismo. Adems, una situacin
de mercado que cambia rpidamente puede obligar a un proyecto a
considerar las nuevas necesidades del mercado en una etapa tarda del
proyecto. La planificacin de la liberacin es entonces un compromiso en el
que las caractersticas ya comprometidas pueden necesitar sacrificarse a
expensas del esfuerzo desperdiciado [71] del trabajo ya realizado. El rea de
planificacin de la liberacin est bien investigada y Svahnberg et al.
Inform sobre 24 modelos estratgicos de planificacin de liberacin
presentados en artculos acadmicos destinados al desarrollo de software
impulsado por el mercado [68]. Adems, Wohlin y Aurum investigaron lo que
es importante al decidir incluir un requisito de software en un proyecto o
liberacin [73]. A pesar de ello, la comprensin de los desafos relacionados
con la gestin del alcance y sus causas y efectos sigue siendo baja.
El alcance de los proyectos de desarrollo gil involucra principalmente tres
de las prcticas giles RE identificadas por Ramesh et al., A saber, la
priorizacin extrema, la planificacin constante y RE iterativa [57]. Los
requisitos de alto nivel se priorizan y las caractersticas con el mayor valor
de mercado se desarrollan primero. Este enfoque asegura que si el proyecto
se retrasa el lanzamiento todava puede ser posible ya que los requisitos
ms crticos para el negocio ya se desarrollarn. Ramesh et al. Identific
una serie de bene fi cios para las empresas que aplican estas prcticas
giles de RE, pero tambin desafos y efectos variables en los riesgos de los
proyectos. Los beneficios identificados incluyen la capacidad de adaptarse a
la priorizacin cambiante de los requisitos, as como una comprensin ms
clara de lo que los clientes desean, reduciendo as la necesidad de cambios
importantes [57]. Por otro lado, se encontr que las prcticas giles de ER
incluan retos en (1) estimar y programar correctamente el alcance
completo del proyecto (que cambia continuamente), (2) una tendencia a
omitir los requisitos de calidad y las cuestiones arquitectnicas (con el
riesgo De problemas serios y costosos a lo largo del tiempo), y 3) una
reorientacin constante de los requisitos (con posterior inestabilidad y
residuos) [57].
3. La empresa del caso
La compaa de casos tiene alrededor de 5000 empleados y desarrolla
sistemas integrados para un mercado global usando un enfoque de lnea de
productos [54]. Los proyectos en foco para este estudio de caso son
inversiones tecnolgicas en una base de cdigo comn en evolucin de una
lnea de productos (plataforma a.k.a.) en la que se basan mltiples
productos. Hay varios lanzamientos consecutivos de esta plataforma donde
cada lanzamiento es la base para uno o ms productos. Los productos
reutilizan principalmente la funcionalidad y las cualidades de la plataforma,
y contienen muy poco software especfico del producto. Una versin de la
plataforma principal tiene un plazo de ejecucin de aproximadamente 2
aos desde el inicio hasta el lanzamiento y se centra en el crecimiento de la
funcionalidad y las mejoras de calidad para una portada de producto. Para

tales proyectos tpicamente alrededor de 60-80 nuevas caractersticas se

agregan, para lo cual aproximadamente 700-1000 requisitos de sistema se
producen. Estos requisitos son entonces implementados por 2025 equipos de desarrollo diferentes con, en total, alrededor de 40-80
desarrolladores por equipo asignado a diferentes proyectos. La base de
datos de legado de requerimientos equivale a un conjunto de requisitos muy
complejos y grandes, a varios niveles de abstraccin, en el orden de
magnitud de 20.000 entidades. Esto hace que sea un ejemplo de la VLSRE
(muy grande escala RE) contexto [58]. Tanto el flujo de nuevos
requerimientos (agregados y eliminados del alcance de los proyectos de la
plataforma) como las decisiones de alcance asociadas con este flujo pueden
cambiar con frecuencia y rapidez. Esto expone a la direccin del proyecto a
una serie de decisiones imprevistas, ya menudo difciles, en las que los
compromisos anteriores tienen que ser cambiados o cancelados.
3.1. Organizacin de la organizacin

Varias unidades organizativas dentro de la empresa estn involucradas en el

desarrollo. Para este estudio de caso, las unidades relevantes son: la unidad
de necesidades que gestiona el alcance y los requisitos; La unidad de
software que desarrolla el software para la plataforma; Y la unidad de
producto que desarrolla productos basados en la plataforma libera. Adems,
hay una unidad de diseo de usabilidad responsable de disear la interfaz
de usuario. Dentro de cada unidad hay varios grupos de especialistas
divididos por rea tcnica. Estos especialistas son responsables del trabajo
en varias etapas del proceso de desarrollo. Para este estudio, los grupos
ms esenciales son los equipos de requerimientos (RTs) (parte de la unidad
de requerimientos) que definen el alcance, especifican los requisitos del
sistema y los equipos de desarrollo (DTs) (Parte de la unidad de software)
que disean, desarrollan y mantienen software para los requisitos
(previamente definidos). Cada RT tiene un lder de equipo que gestiona el
equipo. Otro papel que pertenece a la unidad de requisitos es el arquitecto
de requisitos que es responsable de la gestin del alcance global, que
incluye la coordinacin de las RT. En los DT hay varios roles, a saber:

Lder del equipo de desarrollo que lidera y planifica el trabajo del equipo
para las fases de implementacin y mantenimiento;
Coordinador de necesidades del equipo de desarrollo que dirige el trabajo
del equipo durante la fase de gestin y diseo de los requisitos y coordina
los requisitos con las RT;
Desarrollador que disea, desarrolla y mantiene el software;
Probador que verifica el software.

La unidad de software tambin cuenta con un equipo de gestin de

proyectos compuesto por (entre otros): gerentes de calidad que establecen

los niveles de calidad objetivo y seguimiento de los mismos y gerentes de

proyectos de software que monitorean y coordinan los DT e interactan con
los arquitectos de requerimientos . Para la unidad de desarrollo de producto
en este estudio, nos centramos en la tarea de pruebas del sistema desde el
punto de vista de la funcionalidad y calidad de la plataforma producida por
la unidad de software.

3.2. Proceso basado en fases

La empresa utiliz un modelo de puerta de escenario. Hubo hitos (MS) para

controlar y monitorear el progreso del proyecto. En particular, hubo cuatro
hitos para la gestin y el diseo de los requisitos (MS1-MS4) y tres hitos
para la implementacin y el mantenimiento (MS5-MS7). Para cada uno de
estos hitos, el alcance del proyecto se actualiz y se bas. Los criterios
fundamentales fueron los siguientes:

MS1: Al comienzo de cada proyecto, se extrajeron los documentos de hoja

de ruta de RT para formular un conjunto de caractersticas para un prximo
proyecto de plataforma. Una caracterstica en este caso es un concepto de
agrupacin de requisitos que constituyen una nueva mejora funcional de la
plataforma. En esta fase, las caractersticas contenan una descripcin
suficiente para permitir la estimacin de su valor de mercado y su esfuerzo
de ejecucin, ambos obtenidos utilizando un enfoque de costo-valor [37].
Estos valores fueron la base para la inclusin inicial del alcance para cada
rea tcnica cuando las caractersticas fueron revisadas, priorizadas y
aprobadas. El alcance inicial se decidi y baselined por RT, guiado por una
directiva de proyecto y basado en estimaciones de recursos iniciales dadas
por el DT de recepcin principal (principal). El alcance se mantuvo en un
documento denominado lista de caractersticas que se actualizaba cada
semana despus de una reunin del panel de control de cambios (CCB). El
papel del CCB era decidir sobre la adicin o remocin de caractersticas de
acuerdo a los cambios que se producen.
MS2: Las caractersticas fueron ajustadas a los requisitos y especificadas
por los RTs, y asignadas a sus DTs principales, responsables de disear e
implementar la caracterstica. Los requisitos se revisaron con los principales
DT y luego se aprobaron. Otros DTs (secundarios) que tambin fueron
afectados por las caractersticas fueron identificados. Los DTs hacen una
estimacin de esfuerzo por caracterstica tanto para DT principal como
secundaria.
MS3: Los DTs haban re fi nido los requisitos del sistema y comenzaron a
disear el sistema. Se ajust el conjunto de DTs secundarios junto con las
estimaciones de esfuerzo, y se actualiz y se bas el alcance.
MS4: Se finalizaron los trabajos de reestructuracin de los requisitos y el
diseo del sistema, y se produjeron planes de implementacin. El alcance

final se decidi y acord con los recursos de desarrollo, es decir, la unidad

de software.
MS5: Todos los requisitos se han desarrollado y entregado a la plataforma.
MS6: El software de la plataforma se haba estabilizado y preparado para
las pruebas de los clientes.
MS7: Los problemas reportados por el cliente haban sido manejados y el
software actualizado. El software estaba listo para ser lanzado.
Segn las pautas de proceso de la compaa, la mayor parte del trabajo de
determinacin de alcance debera haber sido realizado por MS2. Los
requerimientos se expresaron usando un lenguaje natural especfico del
dominio, y contenan muchos trminos especiales que requeran
conocimiento contextual para ser entendidos. En las primeras fases, los
requisitos contenan una descripcin orientada al cliente, mientras que
posteriormente se ajustaban a los requisitos detallados de implementacin.
3.3. Proceso de desarrollo gil

Con el fin de enfrentar los retos de la gestin de alta volatilidad de los

requisitos, la compaa de casos estaba introduciendo un nuevo proceso de
desarrollo en el momento de este estudio. El tamao y la complejidad del
desarrollo del software, incluyendo el uso de lneas de productos,
permanecieron los mismos independientemente del proceso utilizado. El
nuevo proceso ha sido influenciado por ideas y principios de los pro- cesos
de desarrollo agiles eXtreme programming (XP) [7] y Scrum [67]. El proceso
basado en fases fue reemplazado por un modelo de desarrollo continuo con
una estructura de puerta de peaje para las versiones de software de la lnea
de productos de software (para permitir la coordinacin con los proyectos de
hardware y productos, vase P1 a continuacin). La responsabilidad de la
gestin de los requisitos se transfiri de la unidad de requisitos (anterior),
en parte a la unidad de negocio y en parte a la unidad de software. Se
estaban introduciendo las siguientes prcticas giles de ER:

Un flujo continuo de planificacin y alcance de planificacin (P1). El

alcance de todas las versiones de software se planifica y gestiona
continuamente a travs de una lista basada en prioridades (comparable a
una cartera de productos). La unidad de negocio rene y prioriza las
caractersticas desde una perspectiva de negocio. Todos los nuevos
requisitos de alto nivel son colocados continuamente en esta lista y
priorizados por la unidad de negocio. La unidad de software calcula el
esfuerzo y la fecha de entrega potencial para cada caracterstica segn la
capacidad de recursos de software prioritarios y disponibles. El desarrollo se
planifica y ejecuta segn orden de prioridad. La planificacin y la asignacin
de recursos se gestiona a travs de un plan general que contiene todos los
recursos de la unidad de software. El alcance de las versiones de la
plataforma se sincroniza con las versiones del producto mediante un
compromiso gradual con diferentes partes del mbito. Se solicita que el

alcance crtico se comprometa para liberaciones especficas de productos,

mientras que las caractersticas no crticas se asignan a las liberaciones de
productos cuando se implementan y estn listas para integrarse en la
plataforma.
Los equipos de desarrollo multifuncional (P2) que incluyen un
representante del cliente asignado por la unidad de negocio (comparable a
la prctica gil de proxy de cliente) tienen la responsabilidad completa de
definir requisitos detallados, implementar y probar una caracterstica (de la
lista comn basada en prioridades) ). Cada nueva caracterstica es
desarrollada por un equipo multifuncional especficamente compuesto para
esa caracterstica. Las diferentes disciplinas y fases de ingeniera de
software (por ejemplo, requisitos, diseo y prueba) se realizan de manera
integrada y dentro del mismo equipo. El equipo tiene el mandato de decidir
sobre los cambios dentro del valor, el esfuerzo y los plazos asignados para
la caracterstica.
Detalle gradual e iterativo de los requisitos (P3). Los requisitos se definen
primero en el nivel alto (como caractersticas de la lista basada en la
prioridad) y luego se re fi rizan iterativamente en los equipos de desarrollo
en requisitos ms detallados a medida que avanza el diseo y la
implementacin.
Ingeniera de requisitos integrada (P4). Las tareas de ingeniera de
requisitos se integran con las otras actividades de desarrollo. Los requisitos
son detallados, acordados y documentados durante el diseo y desarrollo
dentro del mismo equipo de desarrollo transversal a travs de una estrecha
interaccin entre el representante del cliente y otros miembros del equipo,
p. Diseadores, desarrolladores y probadores.
Las historias de usuarios y los criterios de aceptacin (P5) se utilizan para
documentar formalmente los requisitos acordados para el desarrollo. Las
historias de usuarios definen las metas de los usuarios y los criterios de
aceptacin definen los requisitos detallados para cumplir una historia de
usuario que se acepta como plenamente implementada. Los criterios de
aceptacin deben ser cubiertos por casos de prueba.
Este estudio se centra principalmente en la situacin anterior a la
introduccin de la nueva forma gil de trabajo, es decir, para los proyectos
de trabajo como se describe en la Seccin 3.2. Las prcticas giles de RE
que se describen en este documento se definieron en el proceso de
desarrollo interno de la empresa en el momento del estudio. Las prcticas
P1 y P2 se estaban utilizando en los proyectos, mientras que P3 se
implement en parte, y P4 y P5 estaban en el proceso de implementacin.
Por lo tanto, no fue posible investigar el impacto total de las nuevas
prcticas giles RE en el momento de este estudio. Sin embargo, el estudio
investiga cmo se cree que estas (nuevas) prcticas afectan la situacin
excesiva, es decir, cules son las causas y las causas raz pueden verse
afectadas por las prcticas giles de ER y, por lo tanto, conducir a la
reduccin del exceso y sus efectos.
4. Mtodo de investigacin

El estudio se inici debido a una mayor transicin que tiene lugar dentro de
la compaa de casos y con el objetivo de entender las diferencias entre los
procesos de alcance del proceso basado en la fase y el nuevo proceso de
desarrollo gil. Nuestras investigaciones previas sobre el alcance [71]
sirvieron como base para identificar preguntas de investigacin
encaminadas a buscar una comprensin ms profunda del fenmeno del
overscoping. Con el fin de obtener informacin detallada, se adopt un
enfoque explicativo [60] y el diseo del estudio se bas en el contexto
especfico de la empresa y en la precomprensin de los autores. (Estas
investigaciones pueden ser ampliadas en futuros estudios.) Los
conocimientos existentes de la literatura se tuvieron en cuenta en la
interpretacin y validacin de los resultados.
Se realiz un estudio de caso explicativo de una sola compaa [60]
utilizando principalmente un enfoque de investigacin cualitativa
complementado por un mtodo cuantitativo para algunos de los datos
recogidos. La investigacin cualitativa es adecuada para investigar un
fenmeno complejo (como la sobreescote) en un contexto real donde existe
[48] (como la de nuestro caso). En este estudio, las percepciones de los
practicantes de overscoping se estudiaron a travs de entrevistas donde los
pensamientos verbalizados de los individuos con una gama de papeles
diferentes en la empresa de casos fueron capturados [48, 60]. En la Fig. 1 se
muestra una visin general del mtodo de investigacin. 1.
El estudio de caso se realiz en tres fases, ver fig. 1. En la primera fase, se
utiliz la experiencia industrial de uno de los autores para formular una
hiptesis sobre posibles causas (supues- tas) de efectos excesivos y
(asumidos) que pueden resultar de la sobreescote. Esta hiptesis se utiliz
como punto de partida para crear el instrumento de entrevista [69] para las
entrevistas, que tuvo lugar en la segunda fase del estudio. En la tercera
fase, los resultados de la entrevista fueron presentados a (otros) seis
profesionales de la misma empresa y validados mediante un cuestionario
(ver seccin 6 para ms detalles y [69] para el cuestionario de validacin).
Esto se hizo para reducir el riesgo de falsa certidumbre (inadecuada) de la
correccin de los resultados [60].
4.1. Fase uno: pre-estudio y generacin de hiptesis

El propsito de la primera fase del estudio fue formular una hiptesis sobre
el overscoping y prepararse para las entrevistas. Se utiliz la experiencia de
uno de los autores (que ha trabajado en la empresa caso, con experiencia
en varias reas, incluyendo la codificacin, el diseo, la ingeniera de
requisitos y el desarrollo de procesos) para identificar las causas posibles
(posibles) y el efecto del overscoping. Adems de estas suposiciones para el
modo de trabajo basado en la fase, este autor tambin identific las
prcticas giles de RE que se estn introduciendo en la compaa de casos.
Se asumi que estas prcticas tenan un impacto en uno o ms de los temas
que se crea que causaban overscoping en el proceso basado en la fase. Si
estas suposiciones fueran correctas, la aplicacin de las nuevas prcticas

debera resultar en reducir (o eliminar) los efectos relacionados con esas

causas, y as reducir (o eliminar) el exceso de tamao. Con el fin de evitar la
seleccin de un conjunto de suposiciones sesgadas por una sola persona,
una serie de sesiones de lluvia de ideas alrededor de la hiptesis se llevaron
a cabo dentro del grupo de investigadores involucrados en este estudio (es
decir, los autores). La hiptesis resultante (actualizada) se utiliz entonces
como el principal insumo en la creacin de un instrumento de estudio
entrevista (accesible en lnea [69]).

4.1.1. Hiptesis formulada

La hiptesis formulada para este estudio es que el overscoping es causado
por una serie de factores, y que al abordar uno o ms de estos factores, p. A
travs de prcticas giles de ER, el fenmeno de overscoping puede ser
aliviado, o incluso eliminado. Se identificaron los cinco factores siguientes
como causas supuestas para el overscoping en la fase uno:

Se supona que los requerimientos continuos en el flujo a travs de

mltiples canales (C1) causaban overscoping por los muchos flujos,
aumentando la di fi cultad de definir un alcance realista para mltiples
proyectos paralelos. Los requerimientos llegan continuamente desde el
mercado, as como, de las partes interesadas internas. Este flujo fue
gestionado por

Agrupando esas solicitudes en uno o dos proyectos por ao. Fue un reto
gestionar la ejecucin de mltiples proyectos paralelos, al mismo tiempo
que se gestionaban solicitudes de nuevas caractersticas y requisitos, as
como solicitudes de modificacin del alcance del proyecto acordado.
No se presumi que una visin general de la disponibilidad de recursos de
software (C2) causara overscoping debido al reto de equilibrar el tamao del
alcance total de varios proyectos de desarrollo (paralelos) con el mismo
conjunto de recursos de desarrollo. La asignacin de recursos para la unidad
de desarrollo de software se manej a nivel de DT, es decir, no hubo un
resumen total de la carga y la capacidad disponible de todos los recursos de
desarrollo de la unidad de software.
Se supona que la baja participacin de DT en fases tempranas (C3)
contribua a definir requisitos poco realistas y poco claros en las primeras
fases, que se consideran ms tarde costosas o incluso imposibles de
implementar, provocando as una superposicin. Los equipos de desarrollo
no estuvieron muy involucrados en las primeras fases del proyecto (MS1MS4) con la provisin de estimaciones de costos y retroalimentacin
durante la escritura de los requisitos.
Se supuso que los requisitos no acordados con la DT (C4) causaban un
exceso de tamao debido a que no se aseguraba de que el alcance sugerido
fuera factible y comprensible. La especificacin de los requisitos no siempre
fue acordada con los equipos de desarrollo en el punto de entrega (MS2).

Incluso si hubo una revisin formal por los DT, supusimos que haba un bajo
nivel de compromiso de DTs. Adems, se supona que este bajo nivel de
acuerdo conducira a una baja motivacin de la DT para cumplir los
requisitos definidos por las RT.
Los equipos de requisitos de MS2 prepararon detalladamente los
requisitos antes de que se iniciara el diseo, lo que supuso un exceso de
capacidad al limitar el margen para negociar los requisitos que podran
permitir un diseo ms eficiente y un plan de desarrollo realista. Adems, se
supone que el tiempo y los gastos generales para gestionar dichos cambios
contribuyen a la superposicin.
4.2. Fase dos: un estudio de entrevista en la empresa de caso

En la segunda fase, se realizaron entrevistas semiestructuradas con un alto

grado de discusin abierta entre el entrevistador y el entrevistado. La
hiptesis proporcion un marco que ayud a discutir, explorar y enriquecer
la comprensin de este complejo fenmeno. Para evitar imponer esta
hiptesis a los entrevistados, la discusin tanto sobre overscoping en
general y sobre las causas detalladas y el efecto siempre se inici con una
pregunta abierta. Adems, se pidi a los entrevistados que hablaran
libremente acerca de los papeles y las fases de su experiencia al comienzo
de las entrevistas. Para separar la situacin con el proceso basado en la fase
y con las nuevas prcticas giles de RE, el impacto de las nuevas prcticas
fue discutido especficamente en una seccin (separada) al final de las
entrevistas.
Nuestro objetivo era cubrir todo el proceso, desde la definicin de requisitos
hasta el desarrollo (diseo, implementacin y pruebas) hasta el producto
final resultante (aseguramiento de la calidad, proyectos de producto),
principalmente para el proceso basado en la fase. Esto se logr mediante la
seleccin de personas con experiencia de todas las unidades organizativas
relevantes (ver Seccin 3) para entrevistarse y as captar una gama de
diferentes perspectivas sobre el fenmeno del overscoping. Se
seleccionaron nueve personas en total para ser entrevistadas. Dos de los
entrevistados con papeles idnticos solicitaron que sus entrevistas se
unieran. Los roles, las pertenencias organizativas y la experiencia relevante
de las personas entrevistadas dentro de la empresa de casos para el
proceso basado en la fase se pueden encontrar en la Tabla 1. Usamos una
codificacin para los entrevistados que tambin incluye su pertenencia a la
organizacin. Por ejemplo, los entrevistados pertenecientes a la unidad de
requisitos estn etiquetados con una letra R, perteneciente a una unidad de
producto con una letra P y perteneciente a una unidad de software con una
letra S.
Las entrevistas se programaron durante 90 minutos cada una con la
posibilidad de reducir el tiempo o prolongarlo. Todas las entrevistas fueron
grabadas y transcritas, y las transcripciones enviadas a los entrevistados
para su validacin. Para cada entrevista, la transcripcin tena 7-10 pginas
y contena un promedio de 3900 palabras. La velocidad de transcripcin
vari de 3 a 7 veces del tiempo de entrevista registrado. La codificacin y el

anlisis se realiz en MS Excel. La estructura de la seccin subyacente del

instrumento de la entrevista, es decir, las causas, los efectos y las prcticas
giles de RE, fueron numeradas y utilizadas para clasificar las opiniones de
los entrevistados. Para cada entrevista, los trozos de texto transcritos se
colocaron dentro de las secciones correspondientes y, si era necesario, se
copiaron en varias secciones. Las relaciones entre las diferentes categoras,
as como el nivel de acuerdo sobre las causas, los efectos y las prcticas
giles de ER se anotaron en columnas especficas. Los puntos de vista de los
dos practicantes entrevistados juntos (entrevistados Ra y Rb) fueron
separados en diferentes columnas para permitir reportar sus respuestas
individuales.
4.3. Fase 3: validacin de los resultados mediante cuestionario

Para fortalecer an ms la validez de los resultados de las entrevistas, se

seleccion un grupo de seis (adicionales) profesionales en la compaa de
casos en la tercera fase, vase el Cuadro 2. Para asegurar que estos seis
profesionales comprendieran los resultados correctamente y de manera
uniforme , Se les presentaron los resultados de la entrevista. Durante la
reunin, los participantes pudieron solicitar clari fi caciones y comentar los
resultados, especialmente cuando no estaban de acuerdo o tenan otros
puntos de vista diferentes o adicionales. A fin de reunir sus puntos de vista
sobre los resultados de manera uniforme y no pblica, se pidi a los
participantes que llenaran un cuestionario (disponible en lnea en [69]), en
el que se indicaba en qu grado estaban de acuerdo con los resultados y,
Los artculos haban sido perdidos. Debido a la limitada disponibilidad de los
participantes, se realizaron un total de tres sesiones de este tipo. Cada
sesin fue programada para 90 minutos con la posibilidad de ampliar o
disminuir el tiempo segn sea necesario. Los resultados del cuestionario se
pueden encontrar en la Seccin 6.

5. Resultados de la entrevista
Las causas y los efectos de la sobreexplotacin derivada de las entrevistas
realizadas en la fase dos del estudio (vase la figura 1) se describen en la
Fig. 2 y se describe en las siguientes secciones. La Seccin 5.1 cubre las
principales causas de overscoping, mientras que las causas fundamentales
se reportan en la Seccin 5.2 y los efectos en la Seccin 5.3. Los hallazgos
de las entrevistas acerca de cmo las prcticas giles de RE pueden abordar
la superposicin se describen en la Seccin 5.4. El resultado del cuestionario
de validacin (fase 3) sobre estos resultados se presenta en la seccin 6.
5.1. Causas del overscoping (RQ1)
El punto de vista de cada entrevistado acerca de las causas de la
superposicin se clasific y se compar con la hiptesis con respecto a las
causas asumidas de la sobreescote (C1-C5, vase la Seccin 4.1.1).
Adems, se encontr que cinco de los ocho entrevistados describan una

sexta causa principal de overscoping, a saber, la visin poco clara de C6 de

la meta general. La falta de una estrategia (claramente comunicada) y los
objetivos globales y las direcciones comerciales para el desarrollo de
software condujeron a la falta de claridad en cuanto a la direccin prevista
tanto de las hojas de ruta de software como de las estrategias de producto,
as como una prioridad empresarial poco clara del alcance del proyecto. Los
entrevistados describieron cmo esta causa (C6) condujo a que el alcance
se propusiera principalmente desde un aspecto tecnolgico, y no desde una
perspectiva empresarial, y sin una prioridad unificada (acordada). En su
lugar, la mayor parte del alcance de un proyecto se declar crtico y no
negociable.
Todos los entrevistados haban Experimentado o Acordado a overscoping
como un reto, y la mayora haba Experimentado o Acordado a causas 13. Ningn entrevistado no estuvo de acuerdo con ninguna de las causas,
4 y 5 tenan menos de una mayora de Experimentado o Acordado
Entrevistados. Causas 4-5 no fueron mencionadas por todos, mientras que
la causa
6, derivado de 5 de los entrevistados, no fue mencionado por los otros.
Las entradas marcadas con NA (No Aplicable) indican que no se esperaba
que el entrevistado en su papel tuviera experiencia de esa causa. El gestor
de pruebas de sistemas (Pd) y el gestor de garanta de calidad (Sg) se
clasificaron como NA para C2, C3 y C4, ya que simplemente observaban que
los requerimientos fluan desde sus posiciones gerenciales y no estaban
directamente involucrados en las primeras fases de los proyectos . Adems,
Sg tambin se clasific como NA para C5 debido a la falta de contacto con el
SRS. Adems, el probador de software (Se), que no tena idea de la
planificacin del proyecto, fue categorizado como NA para las causas C1 y
C2.
Para todas las causas asumidas hubo algunas cuentas de Parcialmente
acordado,
a saber:
Flujos continuos en flujo a travs de mltiples canales (C1). El gerente de
calidad (Sg) mencion el flujo continuo de cambios de requisitos despus de
establecer el alcance como causante.
Pero no hay causas de raz antes de este hito, y por lo tanto se clasifica
como "parcialmente acordado".
Sin visin general de la disponibilidad de recursos de software (C2). Uno
de los DT
Coordinadores de necesidades (Si) se indica como "parcialmente causa,
debido a la creencia de que una mejor visin de los recursos disponibles no
aliviara el exceso de grado. En contraste, otro entrevistado (Sf) vio esto
como una causa fuerte para overscoping; "No haba control sobre lo que la

gente estaba trabajando. Haba diferentes lderes de DT que acababan de

enviar [tareas] '.
Baja incidencia de DT en fases tempranas (C3). Ambos coordinadores de
requisitos de DT (Sh, Si) fueron categorizados como 'Parcialmente de
acuerdo' ya que la participacin del resto de la DT, incluyendo la produccin
de estimaciones de costos, era baja, aunque personalmente haban
experimentado buena cooperacin con los lderes de RT durante MS1-MS2 .
Esta falta de participacin fue vista por el probador de DT (Se) como un
campo de aplicacin poco realista que se especifica: "La visin completa de
los requisitos se mejorara mediante la inclusin de la contribucin de ms
funciones, y un alcance ms realista podra ser identificado antes en.'
Requisitos no acordados con DT (C4). Los coordinadores de requisitos de
DT (Sh, Si) crean que los requisitos se entendan y estaban de acuerdo con
el DT en MS2, aunque el DT no se comprometi a implementarlos en ese
momento. Uno de ellos (Sh) mencion que la especi fi cacin de los
requisitos del sistema se acord principalmente con los coordinadores de los
requisitos de DT y no con los desarrolladores y probadores en el DT.
Especificacin detallada de requisitos producida por adelantado (C5). Uno
de los lderes de RT (Rb) tena una manera gil de trabajar y no produjo una
especificacin detallada de requisitos por adelantado, sino que en vez de
regular e interactu directamente con el DT. Esta mayor comprensin de la
DT permiti una discusin ms flexible sobre el alcance y los requisitos
detallados, lo que llev a que el overscoping fuera experimentado como un
desafo ms manejable por Rb. El otro lder de RT (Ra, entrevistado junto
con Rb) no mencion C5 como causante de overscoping, pero estuvo de
acuerdo con las conclusiones de Rb y fue sealado como 'Parcialmente de
acuerdo'. Ra tuvo la experiencia opuesta, es decir, de producir y confiar en
una especificacin de requisitos, y luego no permanecer en contacto con el
DT durante las fases posteriores de desarrollo (despus de MS2), que luego
desarroll un software que usualmente era diferente de lo que se especific
en El SRS. Uno de los entrevistados de la DT (Sf) crea que el esfuerzo
(desperdiciado) de producir y aceptar los requisitos detallados por
adelantado (para los rasgos que se descodieron ms tarde) aument el
exceso debido a que impeda que esos recursos funcionaran con
caractersticas viables. Otro entrevistado (Sh) dijo: 'En este momento [MS2]
aprobamos muchas cosas, porque nos gustaba lo que escriban [RT] y
realmente queramos esa funcionalidad, entonces [DT] empezamos a
cometer. '

5.2. Anlisis de causa raz (RQ1)

Para proporcionar una comprensin ms profunda a los entrevistados se les

pidi que describan lo que puede estar provocando overscoping, es decir,
las causas fundamentales de overscoping. Estas causas se han agrupado de
acuerdo con la causa principal (C1-C6, descrita en las secciones 4.1 y 5.1)
que afectan. Un cuadro completo de las relaciones causa-efecto para

overscoping identificado a travs de este estudio se muestra en la Fig. 2.

Los resultados en torno a las causas raz de las entrevistas y del
cuestionario tambin se resumen en la Tabla 4.

Causas raz de C1 (necesidades continuas en flujo a travs de mltiples

canales). Se mencion una serie de fuentes de requerimientos adems del
flujo de requerimientos regulares (definido por las RT) como contribucin al
flujo continuo. Estos incluyen: requisitos producidos por la definicin de
muchas variantes de productos diferentes en la lnea de productos (RC1a); Y
muchos nuevos requisitos del mercado y los cambios en los plazos largos de
los proyectos (RC1b) en comparacin con la tasa de cambio de los
requisitos. Adems, las brechas de comunicacin (RC1c) se mencionaron
como causantes de requerimientos adicionales en el flujo durante todo el
ciclo de vida del proyecto. stos consisten en lagunas de comunicacin
entre la unidad de requisitos y la unidad de software (RC1ci), lo que dio
como resultado que la unidad de software prefiriera trabajar de acuerdo con
su propia hoja de ruta interna de software que contena una gran cantidad
de requisitos no acordados con la unidad de requisitos. Las diferencias de
comunicacin entre las reas tcnicas, tanto para RT como para DT (RC1cii),
condujeron a requisitos indirectos entre los DT que se estaban descubriendo
despus de la seleccin inicial del alcance en MS2, lo que aument
considerablemente la cantidad de implementacin requerida. El impacto de
estos requisitos indirectos fue especialmente grande para los DT
responsables de la funcionalidad de la capa de servicio, como los marcos de
visualizacin y los protocolos de comunicacin. Adems, las brechas de
comunicacin entre el diseo de usabilidad y las RT (RC1ciii) dieron lugar a
requisitos funcionales adicionales que aparecen en la especificacin del
diseo de usabilidad, a veces en conflicto con los requisitos de RT.
Finalmente, debido a la falta de comunicacin entre los gestores de calidad
de los programas y la unidad de requisitos (RC1civ), no se definieron y se
priorizaron los requisitos sobre aspectos de calidad junto con los requisitos
de RT, sino que se gestionaron por separado en una fase posterior .
Causas raz de C2 (sin visin general de la disponibilidad de recursos de
software). Se crea que la falta de visin general de los recursos de
desarrollo de software disponibles era una consecuencia de los vacos de
comunicacin dentro de la unidad de software y entre los DT (RC2a). Se
observ que las estructuras organizativas y la presin de gran alcance
daban lugar a que cada DT se concentrara en sus propias reas en lugar de
buscar la cooperacin y una buena comunicacin con otros DT. Un
entrevistado describi que la habilitacin de los DT para coordinar sus
planes tena el efecto de mejorar la situacin del alcance aumentando la
tasa de entrega y la eficiencia: "Intentamos Resolver el overscoping
permitiendo a los DTs co-planear y distribuir de forma incremental. Esto dio
como resultado ms entregas y aumento de la eficiencia. "(Sf)
Causas bsicas de C3 (baja incidencia de DT en fases tempranas). Varios
entrevistados describieron que los recursos de software rara vez estaban
disponibles en las primeras fases del proyecto (RC3a) debido al trabajo de
desarrollo y mantenimiento de proyectos anteriores. Rc dijo: 'por MS2, pero

era difcil obtener [DT] recursos. Ese fue probablemente el problema.

"Adems, las estimaciones de costos dbiles e incorrectas (RC3b) fueron
mencionadas como conducentes a incluir demasiado en el alcance del
proyecto. Por el contrario, la baja capacidad de desarrollo de la unidad de
software (RC3c) causada por la mala arquitectura fue creda por los dos
lderes de RT como la razn principal para el exceso de alcance. Adems, se
mencionaron vacos en la comunicacin (RC3d) entre la unidad de requisitos
y la unidad de software como causantes de una baja implicacin de DT. Por
ejemplo, los entrevistados mencionaron que la implicacin temprana de DT
a menudo fue pospuesta debido a una falta de comprensin dentro de la
unidad de software por la importancia de este trabajo. Sin embargo,
tambin se mencion lo contrario, a saber, que los DT recibieron
informacin de requisitos demasiado tarde (RC3di), lo que result en ampliar
el alcance del proyecto sin planes realistas. Del mismo modo, no siempre se
respetaron las estimaciones de costos tanto para el desarrollo como para las
pruebas (RC3dii). Por el contrario, se experiment una estrecha cooperacin
entre las RT y los DT (por Rc) para conducir a un descubrimiento temprano
de los problemas, permitiendo as la de fi nicin de requisitos ms estables
que luego se implementaron con xito.
Races de C4 (requisitos no acordados con DTs). Se consider que la
participacin de DT bajo en las primeras fases (C3, RC4a) condujo a un dbil
acuerdo y compromiso con los requisitos, por los tres entrevistados con
experiencia de planificar el trabajo de DT (Se, Sh, Si). Los entrevistados
conectaron el nivel de acuerdo de requerimientos con el nivel de
comunicacin en torno a los requerimientos (RC4b), es decir, RTs y DTs que
comunicaron bien tambin tendan a tener un entendimiento mutuo y un
acuerdo de los requisitos. Debido a las variaciones en la comunicacin entre
los equipos, la opinin sobre C4 vari entre los entrevistados (ver seccin
5.1). An as, un entrevistado (Sh) que haba experimentado una buena
cooperacin con la RT mencion que las diferentes pertenencias
organizacionales (RC4bi) causaron problemas de tiempo debido a diferentes
prioridades para las diferentes unidades. Adems, las distancias de
comunicacin entre RT y DT (RC4bii), incluyendo ningn contacto entre los
probadores y los lderes de RT, fueron causadas por distancias fsicas y
organizacionales y resultaron en un dbil acuerdo de DT sobre los requisitos.
La dbil comunicacin sobre requisitos y diseo entre desarrolladores y
probadores (RC4biii) tambin fue mencionada (por Se) como la causa de un
bajo acuerdo de requisitos.
Causas raz de C5 (especificacin detallada de los requisitos producida por
adelantado). El proceso basado en la fase decidi que MS2 debera producir
una especificacin de requisitos, por lo que no se han identificado otras
causas profundas para esta causa.
Causas de C6 (visin poco clara de la meta general). Los lderes de RT (Ra
y Rb) describieron que la falta de una clara estrategia de negocio (RC6a) y
una visin que pudiera guiarlos en la definicin de una hoja de ruta, result
en proponer un alcance desde el punto de vista de la tecnologa pura
(RC6b). Una prioridad de negocio dbil y no unificada (RC6c) del alcance
propuesto (casi todo era 'crtico') fue descrita (por Si) como empujando a los
DTs a comprometerse a planes de proyectos irrealistas. Adems, Rc

mencion que la falta de prioridad unificada impeda que la direccin del

proyecto abordara eficazmente el exceso de escala. Adems, se observ
que varias brechas de comunicacin (RC6d) contribuan a esta causa. Rc
describi una comunicacin dbil tanto entre RT (RC6di) como entre DT
(RC6dii) como resultado de una coordinacin de alcance dbil entre reas
funcionales, as como, conflictos y falta de claridad en cuanto al objetivo
general. Finalmente, tanto RT Los lderes describieron que las lagunas en la
comunicacin y el bajo entendimiento entre la unidad de requisitos y la
unidad de software (RC6diii) del objetivo general dieron lugar a que el
alcance del proyecto fuera decidido en gran medida por los DT y no Las RT.

5.3. Efectos de overscoping (RQ2)

Las entrevistas descubrieron los siguientes seis efectos principales del

exceso de alcance (marcados como E1 a E6, ver Fig. 2):

Muchos cambios de requisitos despus de que el alcance del proyecto se

establece (E1). Todos los entrevistados haban experimentado que el exceso
de espacio caus que los cambios de requisitos tuvieran lugar despus de
que se estableciera el alcance del proyecto (en MS2). A medida que los
proyectos avanzaban y la sobrecarga se descubra, grandes cantidades de
caractersticas fueron eliminadas del alcance (desprotegido). El fenmeno
era tan comn que las frases
'Overscoping' y 'decoping' se han convertido en parte del vocabulario de la
empresa. Esta descodificacin de las caractersticas ya iniciadas fue un
desperdicio (E1a) del esfuerzo de RT y DT y condujo a la frustracin ya una
menor motivacin (E1b) para trabajar con nuevos requerimientos. Como dijo
el entrevistado Sh dijo: "Hay muchas cosas que usted como un probador o
desarrollador han pasado tiempo en que nunca dio lugar a nada. Y eso no es
muy divertido. Hay muchas horas extraordinarias que se han desperdiciado
". Sin embargo, el Pd tuvo muchos cambios en el requisito de tener un
impacto menor en las pruebas del sistema. Se limitaron a ajustar los planes
de prueba, y raramente desperdici ningn esfuerzo debido a este efecto.
Calidad (E2). Todos los practicantes entrevistados despus de MS4
(cuando comenz el desarrollo, Rc, Pd, Se, Sf, Sg, Sh) mencionaron que la
calidad del software se vio negativamente afectada por el exceso de alcance
debido a la alta carga de trabajo y debido a los muchos cambios en los
requerimientos. El gerente de calidad de software Sg expres: "Si obtienes
demasiado alcance, obtienes problemas de calidad ms tarde y no tienes la
energa para tratar con ellos". Simultneamente, el entrevistado Pd dijo:
'Cuando tienes mucho que hacer Al mismo tiempo, todo no est acabado al
mismo tiempo y se obtiene un producto de menor calidad ". Adems, la falta
de respeto por los costes de desarrollo (C3dii) en las fases anteriores fue
mencionada por el probador de software (Se) Para contribuir a pruebas
insuficientes y problemas posteriores de calidad.

Retrasos (E3). La sobrecarga excesiva y la subsiguiente sobrecarga de los

DT fue descrita por varios practicantes como resultando en entregas
retardadas siendo la norma y no la excepcin. Adems, a menudo los DT
superpopulados se vieron obligados a comprometerse con peticiones y
cambios crticos para el cliente, lo que a su vez provoc an ms retrasos y
problemas de calidad (E2). Un entrevistado de DT (Sf) declar que "nuestro
equipo siempre estaba cargado al 100% en MS4, lo cual era demasiado ya
que siempre haba peticiones de clientes ms tarde que tenamos que
manejar. Eso signific que nos vimos obligados a ofrecer funcionalidad con
calidad inferior o tarde ". La misma situacin fue descrita por el gerente de
calidad (Sg) Quien dijo: "Incluso si nos decidimos por un alcance para MS4,
hubo muchos cambios en curso, por lo que nunca estuvimos preparados por
MS5, como dijimos, pero se demoraron".
Las expectativas del cliente no siempre se cumplen (E4). Algunos de los
entrevistados mencionaron que el exceso de volumen resultaba a veces
incumplir las expectativas de los clientes. Por ejemplo, los clientes a veces
cambian las peticiones de las caractersticas que haban sido removidas
previamente debido al overscoping. Adems, el exceso de tamao causado
por la necesidad de un gran nmero de productos (RC1a) con diferentes
tamaos de presentacin y formatos fue experimentado por Sf como
resultado de la liberacin de productos con software defectuoso, p. Iconos
extraviados.
Comunicacin (E5). Se describi que la superposicin y sobrecarga de una
organizacin condujo a varias lagunas de comunicacin; Entre los requisitos
y las unidades de software; Dentro de la propia unidad de software, entre
DTs (Sg, Si) y entre DTs y gestores de proyectos de software (Sf); Y entre el
software y la unidad de producto. Por ejemplo, las numerosas caractersticas
de descodificacin (E1) y el esfuerzo desperdiciado (E1a) dieron lugar a una
desconfianza entre la unidad de requisitos y la unidad de software, de tal
manera que la unidad de software defini su propia hoja de ruta interna sin
coordinarla con la unidad de requisitos. Adems, los informes de error no
vlidos presentados por los probadores de sistema basados en un SRS no
confiable (causado por E1-E6) provocaron un aumento tanto en la carga de
trabajo como en la frustracin en la unidad de software y, por consiguiente,
friccin y amplitud de espacios de comunicacin entre estas unidades.
Desafo para mantener el SRS actualizado (E6): La situacin causada por
overscoping, con una carga de trabajo alta y muchos cambios en los
requisitos tardos (E1), aument el reto de mantener el SRS actualizado. Los
practicantes mencionaron que en una situacin excesiva la tarea de
actualizar el SRS recibi poca prioridad (en parte causada por E1b). Adems,
se aument la cantidad de actualizaciones requeridas tanto para los
requerimientos modificados como para los descodificados (Ra, Rb, Pd, Sg,
Si) produciendo los requerimientos upfront (C5) con un bajo nivel de
acuerdo DT (C4). Los lderes de RT (Ra, Rb) tambin haban experimentado
que muchos cambios relacionados con los requerimientos se hicieron
durante el desarrollo sin informar a los RT (o los probadores del sistema),
muchos de los cuales podran haber sido resultado de una insuficiente
implicacin de DT en las primeras fases (C _ {3}).

5.4. Impacto de las prcticas de RE agiles (RQ3)

La opinin general de los entrevistados sobre la situacin tras la
introduccin de las prcticas giles de RE (vase la seccin 3.3) es que,
aunque todava se experimenta alguna sobreexplotacin, es un reto ms
manejable que con el proceso anterior basado en la fase. Por ejemplo, hay
menos decodificacin y la mayora de las funciones trabajadas por la unidad
de software continan hasta su finalizacin (Si). Interviewee Sg dijo: 'Todava
tenemos un exceso de capacidad en todos los proyectos. Pero, ahora es ms
controlado y ms fcil de quitar cosas sin tener Muchos de los entrevistados
afirmaron que en la prctica las prcticas giles de las RE se ocupan de la
superposicin, pero que estas prcticas tambin suponen una serie de
nuevos desafos. Las siguientes prcticas fueron mencionadas por los
entrevistados como impactantes de algunas de las causas y / o causas de
origen de la superposicin:

Un flujo de planificacin de lanzamiento y de alcance continuo (P1). Esta

prctica (que se implement en el momento de las entrevistas) trat la
causa raz de una dbil priorizacin del alcance (RC6c, mencionada por Rc,
Pd, Sg, Sh) y las causas de los requerimientos continuos en flujo a travs de
mltiples canales (C1, Por Se, Sf) y no hay una visin general de la
disponibilidad de recursos de software (C2, mencionada por Sf, Sg),
haciendo que todos los recursos de alcance y desarrollo se gestionen a
travs de una lista uniformemente priorizada.
Equipos de desarrollo multifuncional (P2). Esta prctica (que se
implement en el momento de las entrevistas) se vio para abordar varias
lagunas de comunicacin, y, por lo tanto, las causas de impacto

C1-C4 mediante el cierre de las brechas (identificadas como causas raz)

entre RT y DT y entre diferentes reas funcionales. Tambin se cree que esta
prctica repercute en el C5 (especificacin detallada de los requisitos
producidos por adelantado), ya que el detalle de los requisitos se maneja
ahora dentro de los equipos de desarrollo junto con el representante del
cliente. El entrevistado Sf dijo: 'Es una ventaja que ellos (el equipo) se
sienten juntos y puedan trabajar sin perjuicio, y no hay nosotros y ellos,
pero somos nosotros. Y cuando trabajan con los requisitos, todo el grupo
est involucrado y los estrecha. "
Detalle gradual e iterativo de los requisitos (P3). Esta prctica (que se
implement parcialmente en el momento de las entrevistas) se mencion
como directamente afectando la causa C5 (SRS detallado producido por
adelantado). Adems, esta prctica tambin fue vista por Sf y Sg para
reducir tanto el tiempo de avance para cada requisito de alto nivel (RC1b)
como la cantidad de cambios despus del alcance del proyecto (E1) y as
reducir la cantidad de esfuerzo desperdiciado E1a, tambin mencionada por
Ra, Rb).
6. Cuestionario de validacin de los resultados de las entrevistas

Overscoping fue investigado a travs de los cuestionarios de validacin [69],

vase el Cuadro 4. Cada uno de los seis encuestados seal su nivel de
acuerdo mediante la siguiente notacin:

Experimentado: He experimentado esto (artculo y conexin) para ser

vlido.
De acuerdo: Estoy de acuerdo con esto, pero no lo he experimentado
personalmente.
En parte de acuerdo: acepto participar, pero no todos, de esto.
En desacuerdo: No estoy de acuerdo.
No s: No tengo conocimiento de este tema ni de su impacto.

6.1. Causas y causas raz (RQ1)

La mayora de los encuestados con fi rmaron (es decir, Experimentado o

Acordado) todas las causas principales como contribuyendo a la
sobreescote, excepto la C3 (baja implicacin de DT) para la cual hubo
tambin una respuesta en Desacuerdo. Causas C2, C3, C5 y C6 cada uno
tena una cuenta de En desacuerdo de los encuestados con experiencia de
la unidad de requisitos. Dos de las principales causas fueron dos
encuestados, a saber, la debilidad de los procesos de adherencia (+ C7) y el
dictado del alcance y los plazos de la gestin (+ C9). Adems, se dieron
algunas causas adicionales para C1, C3 y C4. Para C3, se dieron dos causas
raz alternativas, a saber, el retorno de los miembros de DT a medida que el
proyecto progresaba (RC3f) y asignando los mismos recursos a mltiples
proyectos paralelos (RC3g). Para C4 (requisitos no acordados con DT), tres
respondieron que esto fue causado por requisitos claros y ambiguos (RC4c),
mientras que uno de los encuestados sugiri que los DT a menudo carecan
de una idea de por qu ciertas caractersticas y requisitos eran importantes,
(Visin poco clara de la meta general). Todas las respuestas del cuestionario
de validacin sobre causas y causas de raz se pueden encontrar en la Tabla
4.
El impacto de cada causa principal en el overscoping se midi al pedir a los
encuestados que distribuyeran 100 puntos sobre todas las causas segn el
alcance de su impacto (vase Tabla 5) C1 obtuvo la puntuacin ms alta en
total y los seis encuestados, Los requerimientos continuos en el fl ujo fueron
una de las principales causas de la sobreexplotacin. La segunda
puntuacin total ms alta fue dada a C6 (visin poco clara de la meta
general), que todos los participantes de la unidad de software clasificaron
con 30-60, mientras que los otros participantes calificaron esto con 0 o 30.
Causas C4, C5, C6 y + C7 fueron vistos como teniendo un impacto menor o
nulo en la situacin de overscoping.

6.2. Efecto de overscoping (RQ2)

En general, los encuestados del cuestionario haban experimentado o

estaban de acuerdo con todos los efectos de la superposicin identificados
de las entrevistas. El encuestado de la unidad de producto no tena ninguna
opinin sobre E5 o E6, mientras que el arquitecto de requisitos en parte
acord E5. Adems, los encuestados mencionaron los siguientes efectos de

Tiempo adicional (+ E7); Cambiado ya veces cancelado planes de producto

(+ E8); Baja priorizacin de tareas administrativas (+ E9). La respuesta
completa del cuestionario sobre los efectos se muestra en la Tabla 6.
Adems de indicar el nivel de acuerdo con los efectos identi fi cados de la
superposicin, se pidi a los encuestados que evaluaran su impacto. Se
utiliz la siguiente notacin:

Crtico: Empresa o nivel de cliente.

Mayor: Proyecto o nivel de unidad.
Medio: Nivel de equipo. Menor: Nivel individual. Ninguno: Ningn impacto.

Todos los efectos identificados de las entrevistas fueron vistos como

teniendo un impacto. Todos los efectos excepto E5 (lagunas de
comunicacin) fueron vistos como teniendo un impacto mayor o crtico por
la mayora de los participantes. Hubo dos recuentos de menor impacto: uno
para E6 (manteniendo SRS actualizado) y otro para + E7 (horas extras).

6.3. Impacto de las prcticas de RE agiles (RQ3)

Los encuestados del cuestionario acordaron en su mayora que las tres

prcticas giles idnticas de RE afectaban el reto del overscoping, ya sea a
travs de su propia experiencia o creyendo que la prctica debera funcionar
en teora. Adems, algunas prcticas adicionales fueron mencionadas como
impactando el overscoping: (+ P4) una visin ms clara de la empresa (es
decir, dirigindose directamente a C6), (+ P5) desarrollo de cdigo abierto
restringiendo lo que el cliente puede razonablemente esperar cuando
grandes partes de la Software estn fuera del control de la empresa) y (+
P6) entregas incrementales (los ciclos ms cortos facilitan el control del
tamao del alcance para cada ciclo). La Tabla 7 contiene las respuestas de
los cuestionarios sobre el impacto de las prcticas giles de RE sobre el
overscoping.

Por ltimo, los encuestados haban experimentado, acordado o en parte de

acuerdo en que overscoping todava era un desafo para la compaa de
casos. El nuevo proceso y prcticas giles son vistos, al menos en parte,
para abordar la situacin y proporcionan formas de administrar y controlar
mejor el alcance de la superposicin y sus efectos. Las respuestas de los
practicantes sobre la situacin actual se muestran en la Tabla 8.
7. Interpretacin y discusin

Los resultados de este estudio corroboran que overscoping es un riesgo

complejo y grave para la gestin de proyectos de software [13, 20, 43],
tanto para la fase y para los procesos de desarrollo gil. Adems, los
resultados muestran que los problemas de comunicacin tienen un impacto importante en la superposicin. Esto complementa el trabajo de
Sangwan et al. Y Konrad et al. [41] que mencion que la comunicacin dbil
puede causar fallas de proyectos en el desarrollo a gran escala y la
ingeniera de software global [63]. Adems, nuestros resultados amplan las
listas de efectos de coordinacin dbil propuestas por Sangwan et al. [63]
(largos retrasos, dejar a los equipos inactivos y causar problemas de
calidad) aadiendo overscoping. Se necesitan ms investigaciones para
identificar y atender completamente los factores involucrados. Los
resultados se discuten y se relacionan A otra investigacin con ms detalle,
por pregunta de investigacin, en las secciones 7.1 (RQ1), 7.2 (RQ2) y 7.3
(RQ3). Finalmente, las limitaciones de este estudio y las amenazas a la
validez de los resultados se discuten en la Seccin 7.4.

7.1. Causas del overscoping (RQ1)

Nuestros resultados indican que el overscoping es causado por una serie de

causas y causas de raz. Estas causas se derivan principalmente de la
naturaleza del contexto del MDRE en el que opera la empresa, pero tambin
se deben a cuestiones relativas a la cultura y las estructuras
organizacionales ya la comunicacin. Los entrevistados describieron la
causa adicional C6 (visin poco clara del objetivo general) y dos
encuestados que mencionaron causas adicionales relacionadas con la falta
de respeto por el proceso de decisin y desarrollo, es decir, C7 y C8. En
contraste, los practicantes con experiencia de buena cooperacin y equipos
bien comunicados describieron el overscoping como un desafo menos serio
y ms manejable. Esto puede explicar todas las respuestas al cuestionario
en desacuerdo, pero una (es decir, C5).
Interpretamos los resultados alrededor de las seis causas de overscoping
identificadas a travs de las entrevistas (ver Seccin 5.1 y Fig. 2) como
sigue:

Requerimientos continuos en flujo desde mltiples canales (C1).

Interpretamos la homogeneidad de los resultados de la entrevista y del

cuestionario (vanse las Tablas 3 y 5) para indicar que un grupo grande y no

controlado, El in fl ujo de los requisitos tiene el potencial de causar un
exceso de alcance cuando no se gestiona y se equilibra con la cantidad de
capacidad disponible. Esta causa tambin fue identificada por Regnell y
Brinkkemper [59] y Karlsson en el. [38] como uno de los desafos del MDRE.
Adems de corroborar este desafo, nuestro trabajo tambin identifica que
este flujo continuo de requisitos puede causar overscoping. La importancia y
gravedad de este factor estn indicadas por esta causa que anot el factor
de impacto total ms alto en el cuestionario (ver Tabla 5). La medida en que
esta causa afecta a las empresas que operan en el contexto de ingeniera
de requisitos a medida [59] requiere ms investigacin.
Nuestro estudio tambin revela que el flujo de requerimientos puede ser
incrementado an ms por el deslizamiento de alcance en el nivel de
administracin de software a travs de una hoja de ruta interna de software
(RC1ci, vea la Seccin 5.2). En efecto, esto impeda que los recursos
estuvieran disponibles para gestionar las nuevas necesidades de los
clientes. Resultados similares han sido reportados por Konrad et al. Quien
encontr que el alcance fluencia puede dar lugar a problemas con el
cumplimiento de las expectativas del cliente [41], es decir, el efecto E4
(vase la Seccin 5.3). Konrad et al. [41] proponen abordar la expansin del
alcance mediante una mayor comprensin y rastreabilidad de los
requerimientos de los clientes, y mediante la creacin de una estructura
jerrquica eficaz de CCB. El impacto de estos mtodos en el overscoping
sigue siendo evaluado.

Sin visin general de la disponibilidad de recursos de software (C2). La

mayora de nuestros respondedores (seis de nueve entrevistados y cinco de
seis Los encuestados) haban experimentado o estaban de acuerdo en que
la falta de visin general de los recursos disponibles era una causa de
exceso de capacidad. Sin embargo, los resultados del cuestionario sugieren
que el impacto de esta causa no es tan crtico como causa C1. Este
resultado es sorprendente, al considerar la importancia de la gestin de la
carga de trabajo diaria, incluida la coordinacin de tareas y actividades
informadas por, p. Philips et al. [52]. Es interesante la opinin contrastada
de la baja capacidad de desarrollo (RC3c, mantenida por los lderes de RT) y
el bajo respeto por los costos de desarrollo (RCdii, en manos de los roles de
DT). Esta diferencia puede interpretarse como una comprensin baja del
punto de vista del otro en torno al coste y una indicacin de que este punto
de vista depende del papel (relacionado con Jorgensen y Shepperd [33]). Si
la capacidad de desarrollo es realmente baja es un tema diferente.
Finalmente, esta causa incluye especficamente la falta de supervisin, o el
conocimiento de la carga total sobre los recursos. Hasta donde sabemos,
este tema no ha sido investigado empricamente. En lugar de software de
estimacin de costes de investigacin [33] se centra principalmente en la
estimacin del esfuerzo y en la optimizacin de la asignacin de recursos
[45].
Baja participacin del equipo de desarrollo en las primeras fases (C3). Los
resultados indican que la baja participacin en el desarrollo en la fase de

requisitos puede causar overscoping (mencionado por 6 de cada 9

entrevistados y 5 de cada 6 encuestados no discreparon a esto). Esto con fi
rma un trabajo anterior que seala la necesidad de una implicacin
temprana en el desarrollo en ingeniera de requisitos, p. Requerido por las
interdependencias entre la gestin de productos y el desarrollo de software
[51]. Glinz et al. Tambin mencion que la falta de comunicacin entre la
gestin del proyecto y el desarrollo a requerimientos de entrega puede dar
lugar a resultados insatisfactorios [27]. De manera similar, Karlsson et al.
Inform que las brechas de comunicacin entre la comercializacin [38]
(unidad de requisitos para nuestra empresa de casos) y el desarrollo, puede
dar lugar a estimaciones de esfuerzo insuficientes (es decir, RC3b) y al
comprometerse con rasgos grandes irrelevantes sin considerar las
implicaciones tcnicas y de programacin. ]. Nuestros resultados corroboran
estos resultados en que la participacin baja y la comunicacin dbil en
fases tempranas pueden conducir a problemas ms adelante, incluyendo el
overscoping. Estos problemas de comunicacin tambin pueden exacerbar
el problema de obtener estimaciones de esfuerzo precisas y confiables
(RC3b). Adems, el hecho de que un encuestado haya expresado que
experimenta una buena comunicacin y cooperacin entre los requisitos y
los equipos de desarrollo tambin puede explicar la respuesta en
Desacuerdo por esta causa. Por otro lado, un resultado sorprendente del
cuestionario de validacin es que se cree que esta causa (C3) in fl uye en el
overscoping menos que causa C6 (visin poco clara del objetivo general)
tanto en total (entre todos los encuestados) como en 2 de los 3 programas
Encuestados. Estos resultados indican que puede haber factores adicionales
(no cubiertos) que influyen en el impacto que esta causa tiene en el exceso
de tamao.

Finalmente, se han propuesto varios mtodos para tratar la causa C3, p.

Negociacin de propuestas de implantacin [25], modelos de conectores
para la transformacin de requerimientos arquitectnicos [47], captura de
requisitos cooperativos [46] e implicacin de los clientes en el proceso de
gestin de requisitos [35]. El razonamiento orientado a objetivos tambin
puede proporcionar directrices constructivas para los arquitectos en sus
tareas de diseo [42]. Si ya qu grado los mtodos mencionados pueden
aliviar el exceso de tamao al afectar esta causa sigue siendo un tema de
investigacin adicional.

Requisitos no acordados con el equipo de desarrollo (C4). Los resultados

proporcionan evidencia emprica de que el dbil acuerdo sobre
requerimientos entre requerimientos y unidades de software puede causar
overscoping (los 6 respondedores del cuestionario acordaron causar C4 y
cinco entrevistados mencionaron C4 como una causa de overscop-

En g). Se encontr que una causa raz significativa de esta causa era las
brechas de comunicacin, principalmente entre las funciones relacionadas
con los requisitos y las funciones de desarrollo y prueba. Esto con fi rma el

punto de vista de Hall et al. [29] que la mayora de los problemas de los
requisitos son en realidad cuestiones de organizacin. Adems, esto con fi
rma la importancia de la integracin sin fisuras de los diferentes procesos en
el trabajo colaborativo [22]. El impacto de la comunicacin insuficiente en la
ingeniera de software ha sido reportado como una cuestin general dentro
de la ingeniera de requisitos y la gestin de productos [12,25,29,35,38].
Sorprendentemente, C4 obtuvo el menor impacto entre todas las causas y
slo dos respondedores del cuestionario (ambos de la unidad de software)
calificaron esta causa como teniendo cualquier factor (bajo) de impacto en
overscoping. En contraste, la causa C6 (visin dbil de la meta general) fue
clasificada como teniendo el mayor impacto en overscoping. Especificacin
detallada de requisitos producida por adelantado (C5). Nuestros resultados
indican que demasiada documentacin detallada producida de antemano
puede causar un exceso de capacidad (mencionado por cinco entrevistados
y experimentado, acordado o parcialmente aceptado por cinco encuestados,
ver seccin 5.1). Esto complementa otros estudios de documentacin en
proyectos de ingeniera de software. Por ejemplo, Emam y Madhavji
mencionaron que en las organizaciones que requieren ms control la presin
para producir muchos detalles es tambin mayor [23]. Lethbridge inform
que, para los ingenieros de software, a menudo hay demasiada
documentacin para sistemas de software, frecuentemente mal escrita y
desactualizada [44]. Adems, Sawyer et al. [65] mencionan que el
congelamiento prematuro de los requisitos puede causar problemas de
fluencia del alcance y de comunicacin (ambos de los cuales se identifican
como causas de la sobrecaptacin en nuestro estudio) y sugieren prototipos
evolutivos como remedio. Otros remedios sugeridos para abordar la
documentacin excesiva incluyen la reutilizacin de las especificaciones de
requisitos [24], as como, simplemente la creacin de menos documentacin
[3]. La eficacia de estos mtodos para el riesgo de overscoping sigue siendo
investigada. Las opiniones divergentes sobre esta causa entre los
encuestados pueden explicarse por su papel y relacin con el RE. Todos los
encuestados en desacuerdo para esta causa trabajaron con roles
relacionados con los requisitos. Es ms probable que estos papeles
consideren que las especificaciones detalladas de los requisitos son
positivas y buenas, en lugar de un problema. Sin embargo, estos roles
tienen menos visin de las fases posteriores cuando el desarrollo tiene lugar
y los efectos de overscoping son experimentados. Tres de los encuestados
con experiencia en fases posteriores de desarrollo haban experimentado
que C5 causara un exceso de tamao. Adems, Berry et al. Mencion que
cuando el tiempo para la elicitacin es corto, es decir, hay una falta de
documentacin inicial (o falta de C5), los requisitos usualmente terminan
como una mejora o se descodifican ya que todas las solicitudes del cliente
no pueden ser entregadas [9]. ]. Teniendo en cuenta esto, concluimos que
tanto en la especificacin (como en [9]) y sobre la especificacin (como en
nuestro estudio) puede causar overscoping y ms tarde la descodificacin, y
que queda por investigar cmo lograr un buen equilibrio.
Visin poco clara de la meta general (C6). Nuestro estudio identifica que la
falta de metas y estrategias claramente comunicadas para el desarrollo de
software puede hacer que se defina el alcance del proyecto principalmente
desde una perspectiva tecnolgica, en lugar de centrarse en el negocio,

contribuyendo as a la superposicin. En general, esta causa se calific de

tener el segundo mayor impacto en el exceso de tamao, a pesar de que un
encuestado (un lder de RT) estaba en desacuerdo con esta causa. Nuestros
resultados respaldan los hallazgos de los documentos relacionados [4, 18,
20, 40, 49, 61] que subrayan la importancia de seleccionar los requisitos
alineados con los objetivos globales del negocio y despedir a otros lo antes
posible. Adems, el fracaso de las partes interesadas en coincidir con los
objetivos del proyecto fue encontrado por DeMarco y Lister como el mayor
riesgo para un proyecto [20]. Un mtodo para el triaje de requisitos
tempranos basado en estrategias de manejo Fue propuesta por Khurum et
al. [40]. Aurum y Wohlin han propuesto un marco para alinear los requisitos
con los objetivos de negocio [4]. Rosca et al. Mencionan que la caracterstica
ms exigente del negocio es la probabilidad de un cambio que no puede ser
totalmente controlado [61]. Esto puede ser manejado cuando los objetivos
de negocio son claros para los desarrolladores de software, permitindoles
as manejar un sistema que requiere modi fi caciones mientras se cumplen
los objetivos de negocio [18]. Finalmente, Karlsson et al. [38] mencionaron
la falta de metas y visiones comunes como un desafo para lograr una
buena cooperacin, citando a sus respondedores: "Si todos tienen el mismo
objetivo y la misma visin, entonces todos trabajan en la direccin
correcta".
Debilidad de la adherencia al proceso (+ C7) y alcance y plazo dictado por
la gerencia (+ C8). Estas dos causas se mencionaron en los cuestionarios,
aunque ninguno de ellos se consider que tuviera un impacto importante en
el overscoping. Karlsson et al. [38] encontraron que la dbil adherencia al
proceso puede ser causada tanto por la alta complejidad del proceso, como
por la falta de tiempo para la implementacin del proceso. Esto ltimo
podra ser una consecuencia de la sobreexplotacin. La direccin de la
relacin causal entre la superposicin y la adhesin al proceso an debe ser
investigada.

7.2. Los efectos del overscoping (RQ2)

Los resultados indican que la superposicin puede dar lugar a una serie de
efectos (o consecuencias), muchos de los cuales se consideran serios y
potencialmente muy costosos para la empresa. Varios de los efectos identi fi
cados pueden estar en consonancia con las creencias sostenidas sobre lo
que podra conducir a sobrecargar un proyecto con demasiado trabajo. El
objetivo de este estudio es investigar si tales creencias pueden ser
apoyadas por evidencia emprica o no, y si surgen fenmenos ms
sorprendentes en relacin con una situacin especfica de overscoping en el
mundo real.

Muchos cambios despus del alcance del proyecto (E1). Los resultados
muestran que el exceso de tamao conduce a un gran nmero de cambios
en el alcance (experimentado por todos los respondedores y el impacto se

califica como crtico o mayor por los seis respondedores del cuestionario).
Esto confirma la evidencia proporcionada por Harker y Eason [30] que los
requisitos no son estticos y, por lo tanto, son difciles de capturar o
clasificar. Adems, la volatilidad de los requisitos se menciona como uno de
los desafos en MDRE por Karlsson et al. [38] e identificados por Ramesh et
al. Como uno de los 14 supuestos que subyacen en el desarrollo de software
gil [57]. Adems, se han enumerado los orgenes de la volatilidad de los
requisitos [30]. A pesar de este conocimiento, las causas de la volatilidad de
los requisitos no han sido exploradas empricamente. Nuestros resultados
destacan la superposicin como una posible causa de cambios tardos en los
requisitos. Adems, nuestros resultados confirman que es un desafo
administrar los cambios en los requisitos.
Calidad (E2). Los resultados indican que esto es un efecto importante de
la superposicin (experimentado y acordado para entrevistas y
cuestionarios, y clasificado como de impacto crtico o mayor). Esto confirma
que la calidad de la ingeniera de requisitos determina la calidad del
software, segn se informa, p. Por Aurum y Wohlin [6]. Adems, nuestros
resultados destacan la superposicin como una posible razn para
problemas de calidad.
Retrasos (E3). Este estudio muestra (con un alto grado de alineamiento
entre los entrevistados y las respuestas al cuestionario) que los retrasos
pueden ser un efecto de exceso de tamao. Dentro del MDRE, los retrasos
en el lanzamiento de los productos pueden ser muy costosos y provocar la
prdida de cuotas de mercado [38,59,64,65]. Por lo tanto, la idea de que el
exceso de espacio puede tener este efecto es una evidencia importante que
indica que el sobreescapamiento es un riesgo (potencialmente) serio.
Las expectativas del cliente no siempre se cumplen (E4). Nuestros
resultados indican que la superposicin puede tener el efecto de no
satisfacer las expectativas del cliente. Esto podra explicarse por un
proyecto sobrecargado que no tiene ni tiempo ni capacidad para analizar o
Ni a validar si las necesidades del mercado o del cliente podran haber
cambiado. Adems, Karlsson et al. Inform el fracaso para satisfacer las
necesidades de los clientes como uno de los riesgos de desarrollar
productos basados en un enfoque tecnolgico (causa raz RC6b) [38]. Otra
parte crucial de la produccin de productos de software que satisfagan a los
clientes, como sealan Aurum y Wohlin, est trabajando con RE a lo largo de
todo el ciclo de vida del proyecto (en contraposicin a los requisitos iniciales
que detallan, C5). Los resultados de este estudio ponen de relieve la
importancia de seleccionar un mbito factible como un factor a considerar
cuando se trata de comprender mejor y captar las necesidades de los
clientes.
Comunicacin (E5). Nuestros resultados indican que el overscoping puede
causar mayores brechas de comunicacin. (Aproximadamente la mitad de
nuestros entrevistados y los que respondieron al cuestionario mencionaron y
aceptaron este efecto). Esto puede explicarse por la ten- dencia de de fi nir
culpando a otros cuando estn bajo presin, en lugar de cooperar para
resolver problemas juntos. Adems, los entrevistados describieron que los
muchos cambios resultantes de la superposicin (E1) fueron mal

comunicados a la unidad del producto y dieron lugar a falsos informes de

error que se presentaron en los requisitos cambiados, pero no actualizados.
Esto, a su vez, caus irritacin entre los equipos de desarrollo y aument
an ms las brechas de comunicacin. De manera similar, Karlsson et al.
Inform que el flujo constante de requisitos (causa C1) caus conflictos de
decisin entre las funciones de comercializacin y desarrollo [38].
Desafo para mantener SRS actualizado (E6). La mayora de los
encuestados con fi rmaron que la superposicin aumenta el reto de
mantener actualizada la SRS. Cuando el SRS es detallado por adelantado
(C5), la combinacin de los dos efectos (overscoping) E1 (muchos cambios
de alcance) y E1b (disminucin de la motivacin) conducen a una mayor
necesidad, pero una menor motivacin para actualizar el SRS. Esto
complementa trabajo previo, que reporta la volatilidad de requisitos como
un desafo comn para los proyectos de software [30, 32, 34, 70] y que la
opinin de RE como un conjunto esttico de requisitos es inapropiada [29,
30]. Adems, Berry et al. Reportan que el tiempo y los recursos nunca son
suficientes para mantener la documentacin actualizada y que el alcance se
produce cuando los programadores codifican mientras la documentacin
sigue cambiando. Adems, nuestro estudio destaca que el reto de mantener
el SRS actualizado se incrementa como un efecto de overscoping. Harker y
Eason propusieron abordar este desafo definiendo una especificacin crtica
mnima combinada con entregas incrementales (es decir, + P6) y
proporcionando gradualmente ms valor [30]. Se necesitan ms
investigaciones para investigar si los mtodos propuestos para abordar el
desafo de actualizar la documentacin de los requisitos tambin podran
minimizar este efecto para la superposicin.
Horas extras (+ E7), planes de productos modificados / cancelados (+ E8),
baja prioridad para tareas administrativas (+ E9). Estos efectos se
mencionaron en los cuestionarios de validacin y cada uno recibi un
recuento de impacto crtico. Se necesitan ms investigaciones para validar
su relacin con la superposicin.

7.3. Cmo agilidad RE prcticas pueden afectar overscoping (RQ3)

Nuestro estudio identifica que tres de las prcticas giles de ER que se

estn introduciendo en la compaa de casos pueden afectar a varias de las
causas y causas races de overscoping. Adems, los encuestados sugirieron
que tres prcticas ms trataban de superponerse. Los detalles de cmo las
prcticas de RE agilizadas identificadas pueden tener un impacto excesivo
(las causas raz mencionadas pueden verse en la Fig. 2) se discuten a
continuacin. Interpretamos los resultados como una indicacin de que
overscoping sigue siendo un desafo para la compaa de caso, aunque ms
manejable con las prcticas giles (parcialmente implementadas) de RE. Se
necesitan ms investigaciones para comprender plenamente la situacin en
el contexto gil.

Los actuadores responden directamente a la causa C2 (no hay supervisin

de la disponibilidad de recursos de software) al permitir la transparencia y el
conocimiento del alcance total del proyecto y de la carga de trabajo actual
del software unidad. La mayor visibilidad de la carga y de la capacidad de
los recursos disponibles tanto para la unidad de negocio como para la de
software puede superar varias brechas de comunicacin identificadas como
la causa raz del overscoping, es decir, RC1c, RC3d y RC4b. Esta prctica
abarca las prcticas giles de las RE de priorizacin de los requisitos y la
constante reorientacin de los requisitos de alto nivel [57]. Nuestros
resultados confirman los hallazgos de Dyb y Dingsyr de que los directivos
de las empresas giles estn ms satisfechos con la forma en que planifican
sus proyectos que las empresas con planes [21]. Por otra parte, nuestro
estudio tambin corrobora las conclusiones de que la priorizacin gil del
alcance en combinacin con un modelo de etapa-puerta en el nivel de
caracterstica puede evitar el retraso de caractersticas crticas y tambin
proporciona retroalimentacin temprana en las caractersticas [36]. Sin
embargo, el logro de una estimacin correcta de costos y horarios de alto
nivel se ha identificado como un reto tambin para el proyecto gil [57], lo
cual puede ser una de las razones por las que el overscoping sigue siendo
un problema para la compaa de casos.
Los equipos de desarrollo multifuncional (P2) son indicados por nuestros
resultados como la mejora de varias de las brechas de comunicacin
identificadas por nuestro estudio como causas fundamentales importantes
para overscoping (es decir, RC1c, RC2a, RC3d, RC4b, RC6d). Esta prctica de
la empresa de casos es equivalente a la prctica gil de la RE de preferir la
comunicacin presencial cara a cara sobre la documentacin escrita [8] en
combinacin con la priorizacin gil y la constante reestructuracin en el
nivel detallado de requisitos [57]. A este nivel detallado de requisitos, se ha
demostrado que las estimaciones de costes y de calendario de manera gil
(al permitir slo adiciones al eliminar simultneamente algo menos
priorizado) son eficaces [36, 57] y eliminan el problema de " Es equivalente
a overscoping. Otros estudios han encontrado que la comunicacin dentro
de los equipos de desarrollo se mejora mediante prcticas giles, pero que
la comunicacin hacia otros equipos (dependientes) sigue siendo un desafo
[36, 53]. Este desafo se aborda con P2 incluyendo la competencia que
abarca todas las reas funcionales involucradas dentro del mismo equipo
(por lo tanto, impactando las causas raz RCicii, RC2a, RC4b y RC6dii).
Adems, la prctica gil de RE de incluir un representante del cliente en los
equipos de desarrollo est resumida por Dyb et al. [21] como mejorar la
comunicacin ha sido cliente e ingenieros, mientras que llenar este papel
puede ser estresante y desafiante [36, 57].
El detalle gradual de los requisitos (P3) se observa para disminuir el
tiempo total de desarrollo de una caracterstica (causa raz RC1b)
retrasando el detallado de los requisitos hasta que sean realmente
necesarios para el diseo y desarrollo. Esto a su vez reduce la cantidad de
cambios de requerimientos dentro del (ms corto) plazo para el desarrollo
de la caracterstica, lo que en un mercado con alta volatilidad de
requerimientos es una mejora signi fi cativa. Tambin puede reducir las
brechas de comunicacin que se producen debido al aspecto temporal de

los requisitos de detalle antes de que comience el diseo y la

implementacin, es decir, las causas raz RC3d, RC4a, RC4b. La prctica de
la empresa de casos P3 es equivalente a la prctica gil de RE iterativa [57].

7.4. Amenazas a la validez y limitaciones

Como para cada estudio hay limitaciones que deben ser discutidas y
tratadas. Estas amenazas a la validez y las medidas adoptadas para
mitigarlas se informan aqu sobre la base de directrices proporcionadas por
Robson para los estudios de diseo flexible [60]. Otro aspecto importante
para la calidad de una investigacin de diseo flexible es el investigador
[60], y para ello

Todos los investigadores involucrados tienen experiencia previa en la

realizacin de investigaciones empricas, tanto en estudios de entrevistas
como en encuestas. 7.4.1. Validez de las descripciones
La mala interpretacin [60] de los entrevistados plantea la principal
amenaza a la validez de la descripcin. Esta amenaza se abord de varias
maneras. Las entrevistas fueron grabadas y transcritas. Para aumentar la
fiabilidad de las transcripciones, la persona que toma notas durante las
entrevistas tambin las transcribi. Adems, esta persona ha trabajado para
la compaa de casos durante varios aos y est bien versado en la cultura
de la empresa y el idioma. Adems, la triangulacin de datos se aplic a las
transcripciones por otro investigador realizando una transcripcin
independiente y la codificacin de dos entrevistas seleccionadas al azar.
Adems, los entrevistados revisaron las transcripciones y los resultados del
estudio por errores e interpretaciones errneas. Finalmente, se aplic la
triangulacin de los datos a los resultados de las entrevistas mediante la
recoleccin de puntos de vista adicionales de seis (otros) practicantes a
travs de un cuestionario [60].

7.4.2. Validez de la interpretacin

Para este estudio, la principal amenaza a la interpretacin vlida ha sido el
riesgo de imponer la hiptesis (formulada en la primera fase) a los
entrevistados. Para abordar esta amenaza, las preguntas de la entrevista
abierta siempre se planteaban antes de hacer preguntas especficas
basadas en la hiptesis. Adems, se han descrito descripciones espontneas
de las causas (sin indicacin) (como Experimentado) separadamente de las
respuestas a las preguntas de seguimiento sobre causas especficas (segn
lo acordado), ver Seccin 5.1 y Tabla 3.
Para la tercera fase, la amenaza a la descripcin vlida fue abordada por los
investigadores diseando conjuntamente el cuestionario y la sesin

celebrada en relacin con l. Para asegurar que todos los respondedores del
cuestionario entendieran correcta y uniformemente los resultados de la
entrevista, los resultados fueron presentados a los participantes. Podran
entonces solicitar clari fi caciones antes de llenar el cuestionario. El hecho
de que los encuestados respondieran a un marco de resultados sigue siendo
una amenaza abierta a la validez de la interpretacin. Por otro lado, tanto
los entrevistados como los encuestados fueron explcitamente alentados a
discrepar y mencionar otras causas, efectos y prcticas, lo que tambin
hicieron. Una de las principales limitaciones del estudio es el nmero
limitado de encuestados. Aunque los representantes de cada una de las
unidades cubiertas de la compaa de casos estuvieron involucrados tanto
en las entrevistas como en el cuestionario de validacin, el nmero de
personas es relativamente pequeo y se pueden identificar ms factores
incluyendo puntos de vista adicionales.

7.4.3. Validez de la teora

La principal amenaza a la validez de la teora para este estudio es el riesgo
de faltar factores adicionales o alternativos. Una fuente de esta amenaza es
el grupo limitado de practicantes de los cuales se han reunido datos. Otra
fuente potencial es el riesgo de sesgos del observador que limitan el estudio
al conocimiento previo del investigador de la empresa. Este fue un riesgo
principalmente en la primera fase y fue abordado mediante la participacin
de los otros investigadores en la discusin y revisin del diseo del estudio y
la hiptesis que dio forma al instrumento de la entrevista. El hecho de que
una causa principal adicional (es decir, C6) se identific como resultado de
las entrevistas muestra que este sesgo se trat con xito. Sin embargo, la
identi fi cacin de resultados adicionales en la fase 3 puede indicar que
todava no se ha alcanzado la saturacin y la exploracin completa del
problema investigado. Como el objetivo de este trabajo es exploratorio
nuestro objetivo no es presentar o lograr una cobertura completa del
problema bajo investigacin.
La participacin del investigador con la experiencia laboral de la compaa
de casos ha desempeado un papel vital en el estudio. Esto ha asegurado
que el problema investigado es autntico y que los resultados se derivan de
una interpretacin de los datos basada en una comprensin profunda del
caso y su contexto. Sin embargo, Los resultados se limitan a la compaa de
casos y existe el riesgo de que no se identifiquen otras posibles causas de la
sobreexplotacin experimentada en otras empresas. Esto tambin se aplica
al conjunto de prcticas RE agiles, que se limitan a las que se conocan
actualmente y en parte se implementaron en la empresa caso en el
momento del estudio.
La generalisabilidad interna se abord mediante muestreo de entrevistados
y encuestados de diferentes partes de la empresa, seleccionando as los
roles y las responsabilidades involucradas a lo largo del ciclo de vida del
desarrollo. Aun as, no fue posible incluir representantes de ventas y
marketing (no estaban disponibles en el momento del estudio). Sin
embargo, los lderes de los equipos de los requisitos proporcionaron una

cierta penetracin en estos aspectos basados en su experiencia de

contactos con los clientes y con los papeles de las ventas y de la
comercializacin.
Teniendo en cuenta la generalizacin externa, los resultados deben ser
interpretados teniendo en cuenta el contexto de la empresa caso. La validez
externa se aborda mediante la generalizacin analtica que permite extraer
conclusiones sin anlisis estadstico y, bajo ciertas condiciones, relacionarlas
tambin con otros casos [60,62]. En el mbito de este trabajo, se argumenta
la generalizacin analtica aplicando la estrategia de caso ([60], p.107)
analizando el trabajo relacionado y reportando similitudes, diferencias y
desacuerdos con nuestros resultados (ver Seccin 7). Este anlisis construye
un argumento de apoyo a la validez externa de nuestro estudio buscando
datos que no con fi rman una teora pre-asumida. Adems, se pueden llevar
a cabo estudios de seguimiento en otros mbitos para utilizar la estrategia
de demostracin directa ([60]) para abordar la amenaza a la validez
externa.

8. Conclusiones y trabajos futuros

La toma de decisiones est en el centro de la ingeniera de requisitos (ER)

[5] y dentro de la planificacin de la liberacin de los requisitos de mercado
(MDRE) es una de las tareas ms importantes y difciles [38,39,59,65]. Las
decisiones sobre lo que se debe desarrollar y cundo, estn inherentemente
relacionadas con la satisfaccin del cliente. Aunque la planificacin de la
liberacin [37, 39, 59] est bien investigado, la toma de decisiones RE es
reconocido como un reto [2, 5, 50] y el alcance fluencia se clasifica como un
riesgo grave proyecto [16, 17, 31] Los aspectos de la gestin del mbito han
sido menos explorados [72]. Adems, las tcnicas para priorizar los
requisitos [37, 39] a menudo se centran en la planificacin del alcance de
un proyecto como una actividad discreta, o una de una serie de liberaciones
[50]. Nuestro trabajo anterior inform de que el alcance en un contexto
MDRE es una actividad continua que puede durar a lo largo de todo el ciclo
de vida del proyecto [71]. Si no se gestiona con xito y se incluyen ms
requisitos en el alcance del proyecto que los que se pueden manejar con los
recursos disponibles, el resultado es excesivo, es decir, el proyecto
"morder ms de lo que puede masticar".
Nuestro estudio ofrece un cuadro detallado de los factores que intervienen
en overscoping y confirma que el alcance es una parte difcil de la ingeniera
de requisitos y uno de los riesgos en la gestin de proyectos [13, 20, 43].
Nuestros resultados indican que el exceso de capacidad es causado
principalmente por el rpido movimiento del dominio impulsado por el
mercado en el que opera la compaa de casos y cmo se maneja este flujo
de requisitos. En las primeras fases del proyecto, la baja implicacin de los
roles de desarrollo cerca de los objetivos en combinacin con una conciencia
dbil de los objetivos generales puede resultar en un alcance poco realista
del proyecto. Nuestro estudio indica que el exceso de capacidad puede
conducir a una serie de efectos negativos, incluyendo problemas de calidad,

retrasos e incumplimiento de las expectativas del cliente. Los retrasos y los

problemas de calidad son caros, no slo teniendo en cuenta el costo de fijar
los problemas de calidad, sino tambin la prdida de cuotas de mercado y el
valor de la marca [59]. Por otra parte, encontramos indicios de que una
situacin de overscoping puede causar an ms overscoping, es decir, una
organizacin puede terminar en un crculo vicioso cuando overscoping
vincula recursos de desarrollo que no estn disponibles para participar en
las primeras fases del proyecto. Adems, Overscoping conduce a un
aumento de las lagunas de comunicacin, que a su vez son las causas
fundamentales de overscoping.
Las compaas, como nuestra compaa de casos, que desarrollan software
incorporado para un dominio de negocios con una alta presin del mercado
necesitan una estructura organizativa y un proceso adecuado para manejar
eficientemente cambios frecuentes de una manera rentable. Los proyectos
de desarrollo deben responder rpidamente a los cambios, mientras que al
mismo tiempo manejan la complejidad del desarrollo de software en un
entorno de gran escala. Se afirma que los procesos giles estn mejor
adaptados a la gestin del cambio que los basados en la fase. Como dijo un
entrevistado: "El enfoque de la cascada es bueno desde la perspectiva de la
preparacin, si se puede seguir con lo planeado. Pero, dado que vivimos en
un mundo que cambia mucho, no funciona despus de todo. "Nuestro
estudio indica que, a pesar de la introduccin de prcticas de RE agiles,
overscoping sigue siendo un problema para la compaa de casos, aunque
ms manejable. Llegamos a la conclusin de que las mejoras pueden ser
explicadas por las prcticas giles RE de priorizacin continua del alcance
del proyecto, en combinacin con el costo de ejecucin y la estimacin del
cronograma, y requisitos graduales detallando, en estrecha colaboracin
dentro de equipos interfuncionales, - lagunas de formacin. Sin embargo, las
prcticas giles RE plantean tambin desafos [57], p. Comunicacin entre
equipos [36, 53], dificultad en la estimacin de costos [57]. Esto, en
combinacin con un dominio en rpido movimiento y dominado por el
mercado, puede explicar por qu el overscoping sigue siendo un desafo
tambin con el gil proceso de desarrollo.
Las causas y los efectos revelados a travs de este estudio (resumidos en la
Fig. 2) pueden utilizarse como base para identificar problemas potenciales a
tratar para evitar o aliviar una situacin excesiva. Por ejemplo, la causa
bsica de la baja competencia en las estimaciones de costos puede
abordarse mediante la introduccin de tcnicas para mejorar la estimacin
de costos, lo que debera conducir a planes ms realistas. Por ltimo,
apoyados por nuestros hallazgos de efectos potencialmente graves de la
sobreescote, concluimos que este fenmeno puede ser un riesgo mayor de
requerimientos de ingeniera y gestin de proyectos, complementarios al
riesgo de deslizamiento de alcance mencionado por De Marco y Lister [20] .
El trabajo futuro incluye la evaluacin de las prcticas giles de ER cuando
estn completamente implementadas; Cmo afectan el overscoping y qu
desafos adicionales plantean con el tiempo? Adems, sera interesante
investigar cmo aspectos tales como la organizacin organizacional, el
modelo de desarrollo de software (gil o cascada) y la aplicacin de
diferentes mtodos de ingeniera de software afectan la toma de decisiones.

Adems, extender los resultados de este estudio para incluir otras empresas
y tambin otras perspectivas, como la comercializacin y las ventas, puede
fortalecer la generalizabilidad de nuestros hallazgos.
Expresiones de gratitud
Queremos agradecer a todos los entrevistados annimos ya los encuestados
por su inestimable contribucin a este proyecto. Tambin queremos
agradecer al Dr. Dietmar Pfahl por revisar una versin temprana de este
documento. El proyecto est parcialmente financiado por la Fundacin
Sueca para la Investigacin Estratgica y VINNOVA (la Agencia
Gubernamental Sueca para Sistemas de Innovacin) en los Proyectos EASE y
UPITER.