Estás Mordiendo Más de Lo Que Puedes Hacer

ests mordiendo ms de lo que puedes hacer?
Un estudio de caso sobre las

causas y los efectos de overscoping en ingeniera de
software a gran escala

.
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 impulsado

por el mercado, cuando slo unos pocos requieren
declaraciones son conocidos a priori el riesgo de overscoping puede aumentar.
Objetivo: en este documento se informa sobre los resultados de un estudio

encaminado a comprender overscoping impulsado por el
mercado, los proyectos de desarrollo de software, y cmo las prcticas de

ingeniera de requerimientos gil podra afectar a
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 profesionales en una gran empresa

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 overscoping

como un fenmeno que incluye una serie de causas,
causas y efectos, e indican que el overscoping es causado principalmente por

operar en un dominio de movimiento rpido y
dirigido por el mercado y cmo este cambio constante de los requisitos es

Gestionado Una dbil conciencia de los objetivos
generales, en combinacin con una baja participacin en el desarrollo en las

primeras fases, puede contribuir
A "morder" ms que un proyecto puede "masticar". Adems, el exceso de
capacidad puede dar lugar a una serie de consecuencias
potencialmente graves y costosas, incluidas las cuestiones de calidad, los

retrasos y el incumplimiento de las expectativas de
los clientes. Finalmente, el estudio indica que el overscoping ocurre tambin

cuando se aplican prcticas de ingeniera de
requisitos giles, 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 los requisitos

graduales detallados y una estrecha
cooperacin dentro de los equipos interfuncionales.
Conclusin: Los resultados proporcionan una mayor comprensin del alcance

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 requisitos
giles a la cuestin de 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 para 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 el mercado impulsado por la
ingeniera de requisitos (MDRE) [38, 59] los gerentes de productos de software

se enfrentan al reto de la gestin de cambio
continuo de las necesidades del mercado [1] con un gran nmero de nuevos y
cambiantes requisitos [28] causada por una
caprichosa situacin del mercado [19] y por 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 de
la lnea de productos de alcance [66], que deriva 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 respuesta impredecible del mercado a
los nuevos productos, obligan a los encargados de tomar decisiones a

enfrentarse continuamente a la tarea de tomar 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 que los disponibles. Varios investigadores se han centrado en el
alcance de fluencia donde el mbito 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.
Sin embargo, ningn estudio ha intentado
investigar la
Causas y efectos de overscoping aunque la ingeniera de requisitos
(RE) es un desafo reconocido
[2,5,50]. En este estudio, hemos investigado este fenmeno de
Overscoping un proyecto, o morder ms que usted puede masticar, en
particular
En un contexto RE (VLSRE) basado en el mercado y en una escala muy
grande.
Los procesos de desarrollo giles pretenden abordar algunos de los problemas

involucrados en la especificacin requisitos que
cambian con frecuencia.

Por ejemplo, en eXtreme Programming (XP) [7] y [67] de Scrum el equilibrio
entre el mbito y los
recursos disponibles es administrado por la priorizacin extrema y constante

(re)Planificacin del alcance en combinacin con
el tiempo boxeo de iteraciones del desarrollo individual. Sin embargo, la

ingeniera de requerimientos gil (RE) tambin se
han encontrado prcticas que plantean nuevos desafos, por ejemplo, en el

logro de un consenso sobre las prioridades entre las
mltiples partes interesadas y en la creacin de planes de proyecto precisa

(costo y tiempo) para un proyecto completo [57].
El
objetivo principal del estudio de caso reportados en este trabajo fue aumentar
el entendimiento de los factores que
intervienen en la overscoping y destacar as este riesgo y tomar un paso hacia

el tratamiento y evitando overscoping de
proyectos. Para lograr esto, el estudio se de- firmado para responder a las
siguientes preguntas: (RQ1) lo que causa ms-
mbito? (RQ2) Cules son los efectos resultantes de overscoping? Y (RQ3)

cmo puede volver prcticas giles las causas y los
efectos de impacto de overscoping? El estudio se ha realizado en un gran

mercado impulsado por la empresa de desarrollo de
software que ha comenzado a cambiar a- bajo la tutela de una manera ms gil

de trabajar. El estudio incluye entrevistas con
nueve profesionales que trabajan con la ingeniera de requisitos, desarrollo de

software y pruebas de productos. Los
resultados de la entrevista luego fueron validados a travs de un cuestionario

con otros seis practitio- ners desde el caso de
empresa. La contribucin del trabajo presentado incluye ocho causas

principales de overscoping complementado por una serie de
causas y efectos de las nueve principales overscoping.

Adems, los resultados indican que tres de los giles RE prcticas
adoptadas por la empresa caso puede afectar algunas de estas causas y

causas y, por lo tanto, tambin puede reducir los
efectos de overscoping.
Los resultados parciales de este estudio se han publicado anteriormente como
Taller publicaciones en
[11] donde prelimi- narily overscoping fue investigado y en [10] donde los
resultados preliminares sobre los beneficios y
efectos secundarios de Agile RE prcticas fueron publicadas. Para este

artculo, los resultados se extendi con (1) causas
adicionales, las causas y los efectos de overscoping; (2) resultados empricos

adicionales sobre overscoping desde 6 (Otros)
profesionales; y (3) los detalles sobre el impacto de las prcticas giles de re

especficamente en overscoping. Dichas
prrrogas fueron alcanzados por un anlisis ulterior de la entrevista completa

material y validacin de los resultados a
travs de un cuestionario.
El resto de este documento est estructurado de la siguiente manera: La
seccin 2 describe el
trabajo relacionado. La seccin 3 describe el caso compaa, mientras que el

mtodo de investigacin se describen en la
seccin 4. Los resultados se presentan en la seccin 5 de las entrevistas y en

la seccin 6 para el cuestionario de
validacin. En la seccin 7, los resultados estn inter- preted y relacionado a

otros trabajos, y las limitaciones y amenazas
de validez son discutidos. Por ltimo, la Seccin 8 contiene las conclusiones y

trabajos adicionales.
2. Trabajos relacionados
con
los plazos poco realistas y los presupuestos estn entre los diez principales
riesgos en ingeniera del software [13] y
algunas de las razones de la sobrecarga de proyectos con alcance han sido

sugeridas. Por ejemplo, DeMarco y Lister mencion
que una falta de acuerdo entre las partes interesadas en el cumplimiento de los
objetivos del proyecto [20] (tambin uno de
los desafos de Agile RE [57]) puede resultar en una extensin excesiva carga
sobre un proyecto.
Sobrecarga de proyectos puede
deberse tambin al personal de ventas acordando entregar unre- alistically

grandes caractersticas sin considerar la
programacin implicaciones [29]. Adems, el alcance que se extiende ms

all de los requisitos formales por parte de los
desarrolladores, es decir, alcance creep, es afirmado por Iaconou y Dexter [31]

como factores que llevan a los fracasos del
proyecto.
Alcance creep es mencionado tambin como teniendo un gran impacto en el
riesgo y la gestin del riesgo en proyectos
de enterprise data warehouse [43]. Adems, es catalogado como uno de los

cinco principales riesgos durante la fase de
requerimientos, y es una consecuencia directa de cmo estn reunidos los

requisitos [20]. Por otro lado, Gemmer argumenta que
la percepcin que tienen las personas de riesgo y su comportamiento posterior

se daba dentro de la gestin de riesgos y una
mayor conciencia de las causas y los efectos de los riesgos puede conducir a
una mejor discusin y gestin de estos riesgos
[26]. Algunos mtodos y herramientas para mitigar y gestionar los riesgos

relacionados con la especificacin se han presentado
[17].
Por ejemplo, Carter et al. [16] sugieren combinar el prototipado evolutivo y

estrategia de reduccin del riesgo para
mitigar los efectos negativos del mbito creep. Sin embargo, toda la cuestin
de overscoping no es nombrado explcitamente
como un riesgo en el trabajo, ni empricamente investigados por sus causas y

consecuencias.
Ingeniera de Requisitos (RE) es
una decisin intensa parte del proceso de ingeniera de software [5], que
pueden apoyar y aumentar la probabilidad de xito en
el proceso de desarrollo [4]. De cualquier modo, la eficiencia y la eficacia de la

toma de decisiones tiene limitaciones
cognitivas [5], debido a ser un conocimiento intensivo- activ idad. Adems, la

investigacin en el mbito de toma de
decisiones est todava en su infancia [2,50]. Un reto importante en esta

investigacin (accord- dades y Alenljung Persson)
reside en la comprensin de la naturaleza de la toma de decisiones y la

identificacin de los obstculos [2] y varios autores
[2,4,5,50] se menciona la necesidad de: (1) identificar la decisin problemas

en el nuevo proceso; (2) realizar estudios
empricos de volver la toma de decisiones; y (3) examinar cmo afectan

cuestiones no tcnicas o influencia en la toma de
decisiones. Lagunas de comunicacin son un ejemplo de tales cuestiones no

tcnicas que han sido comunicadas a afectar
negativamente la toma de decisiones y contribuir a la definicin de un mbito

realista [12].
Hay dos caractersticas de la mdre
[59], que adems vates aggra- re la toma de decisiones, a saber, la falta de

clientes reales con el cual negociar
disposiciones [37,55] y un flujo continuo de los requisitos de mltiples canales

[28,38]. Como resultado, en lugar de negociar
con clientes especficos, las demandas y requerimientos de un mercado de

consumidores annimos que se han "inventado" [55], a
travs de investigacin de mercado. Adems, el xito del producto final es

principalmente validada por el mercado con la
incertidumbre [59] de cmo el "inventado" requisitos comparar al mar- ket

necesidades. Comnmente, la investigacin de mercado
continuamente cuestiones ms requisitos [59] que pueden ser manejadas con

los recursos disponibles.
Un estado de congestin se
produce en el proceso MDRE [38] y el conjunto de requisitos para implementar

en el prximo proyecto tiene que ser seleccionado
mediante tcnicas de priorizacin se basa en el mercado de pre- dictions y

estimaciones de esfuerzo [15,33,37].
mbito gestin
es considerada como una de las funciones bsicas de la versin de software de

planificacin y una actividad clave para lograr
beneficios econmicos en el desarrollo de la lnea de productos [66].

Planeamiento de la versin exacta es vital para el
lanzamiento de productos dentro de la ventana de mercado ptimo. Y este es

un factor crtico en el xito de los productos de
la mdre dominio [64]. Falta esta ventana podra provocar prdidas en las
ventas, y un costo adicional para el desarrollo
prolongado y de retras las campaas de promocin. No obstante, la

elaboracin de los planes de liberacin fiables basados en
estimaciones incierto [38] y frecuentemente con fea- tures con dependencias

de otras caractersticas [14] es un desafo en l
mismo. Adems, en un mercado rpidamente cambiante situacin puede forzar

un proyecto para estudiar los nuevos requisitos del
mercado en una etapa tarda. Planificacin del Release es un compromiso

donde ya comprometidas caractersticas pueden
necesitar ser sacrificada a expensas del esfuerzo desperdiciado [71] del trabajo
ya realizado. El rea de planeamiento de la
versin
E. Bjarnason et al. / Informacin y Software de Tecnologa 54 (2012) 1107-1124

est bien documentado y Svahnberg et al.
informaron de 24 re- planificacin estratgica de arrendamiento modelos

presentados en documentos acadmicos destinados al
mercado impulsadas por el desarrollo de software [68]. Adems, Wohlin y

Aurum investig qu es importante a la hora de decidir
en un requisito de software- clude en un proyecto o release [73]. A pesar de

ello, la comprensin de los desafos relacionados
con el mbito de administracin y sus causas y efectos, todava es baja.

En el mbito de los proyectos de desarrollo gil,
consiste principalmente en tres de los giles RE prcticas identificadas por

Ramesh et al., a saber, la priorizacin extrema,
constante e iterativo de planificacin Volver [57]. Requisitos de alto nivel son

priorizados y las caractersticas con el
valor de mercado ms alto se desarrollan primero. Este enfoque asegura que si

el proyecto se ha retrasado el lanzamiento an
puede ser posible desde los requisitos empresariales ms crticas ya se habr

desarrollado. Ramesh et al. identificaron una
serie de ventajas para las empresas que apliquen estas prcticas giles de RE,
pero tambin desafos y efectos variables sobre
el proyecto de riesgos. Los beneficios identificados incluyen la capacidad para

adaptarse a las cambiantes necesidades de
priorizacin, as como una mejor comprensin de lo que quieren los clientes,
reduciendo as la necesidad de realizar grandes
cambios [57]. Por otro lado, prcticas giles se encontraron nuevamente para
incluir desafos en (1) estimar correctamente y
sched- uling para todo el mbito del proyecto (que cambia continuamente), (2)
una tendencia a omitir los requisitos de calidad
y problemas de arquitectura (con el riesgo de graves y costosos problemas a lo

largo del tiempo), y (3) una reordenacin de
las prioridades de las necesidades constantes (con la consiguiente

inestabilidad y residuos) [57].
3. El caso
el caso de la
empresa empresa tiene alrededor de 5000 empleados y desarrolla sistemas

integrados para un mercado global con una lnea de
productos ap- cercano [54]. Los proyectos de inters de este estudio de caso
son las inversiones en tecnologa en la evolucin
de la base de cdigo comn de una lnea de productos (alias) de la plataforma

en la que se basan los productos mltiples. Hay
varios lanzamientos consecutivos de esta plataforma donde cada versin es la

base de uno o ms productos. Los productos
principalmente reutilizar la funcionalidad de la plataforma y cualidades, y

contienen muy poco producto de software
especfico. Una gran versin de plataforma tiene un plazo de entrega de

aproximadamente 2 aos desde el inicio de lanzamiento,
y se centra en la funcionalidad de crecimiento y calidad de mejoras para un

producto port- folio. Para tales proyectos
tpicamente alrededor de 60-80 que se aadan nuevas caractersticas, por lo

que aproximadamente 700-1000 requisitos del
sistema son producidos. Estos requisitos se aplican por 20- 25 a los equipos de
desarrollo diferentes, en total, alrededor de
40-80 desarrolladores por equipo asignados a diferentes proyectos. Los

requerimientos de la base de datos heredada asciende a
un muy complejo y amplio conjunto de requisitos, a diversos niveles de

abstraccin, en el orden de la mag- nitude de 20.000
entidades. Esto hace que sea un ejemplo de la VLSRE escala muy grande (RE)
contexto [58]. Tanto el flujo de nuevas exigen-
cias (agregar y quitar del mbito de proyectos de plataforma) y el alcance de

las decisiones asociadas con este flujo puede
cambiar con frecuencia y rapidez. Esto expone la gestin del proyecto a una
serie de imprevistos, y a menudo difciles
decisiones, donde los anteriores compromisos tienen que ser modificadas o

anuladas.
3.1. Organizacin
varias unidades
organizativas dentro de la empresa estn implicados en el desarrollo. Para este

estudio de caso, las dependencias pertinentes
son: los requisitos unidad que administra 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 re- arrendamientos. Adems, existe
una unidad de diseo usabilidad responsable de disear la interfaz de usuario.

Dentro de cada unidad, hay varios grupos de
especialistas dividido por el rea tcnica. Estos especialistas

1109
son responsables de los trabajos en las distintas etapas
del proceso de desarrollo. Para este estudio, la mayora de grupos esenciales

son las exigencias de equipos (RTs) (parte de
la unidad de necesidades), que por un rea tcnica especfica, definir el

alcance, y recabar y especificar los requisitos del
sistema, y los equipos de desarrollo (DTS) (parte del software unidad) que
disear, desarrollar y mantener el software para
la (pre- viously) los requisitos definidos. Cada RT tiene un jefe de equipo que
dirige el equipo. Otro papel pertenecientes a
los requisitos requisitos de dependencia es el arquitecto que se encarga de

gestionar el alcance global, que incluye la
coordinacin de los RTS. En DTs existen varios roles, es decir,

lder de equipo de desarrollo y los planes que lidera el equipo
de trabajo para las fases de implementacin y mantenimiento; equipos de

desarrollo que lleva el coordinador del equipo de
trabajo durante la fase de diseo y gestin de requisitos, y coordina los

requisitos con el RTs; Programador que disea,
desarrolla y mantiene el software; probador verifica que el software.

El software de la unidad tambin dispone de un equipo de
gestin del proyecto consisten- ing de (entre otros): directores de calidad que
establezca el destino los niveles de calidad y
el seguimiento de estos proyectos de software y responsables de supervisar y

coordinar la DTs e interactuar con las exigen-
cias de los arquitectos. Para la unidad de desarrollo de producto en este

estudio, nos centramos en la tarea de probar el
sistema desde el punto de vista de la funcionalidad y la calidad de la

plataforma de software producidos por la unidad.
3.2.
Proceso basado en fase

la empresa utiliz un stage-gate modelo. Hubo hitos (MS) para controlar y
monitorear el progreso del
proyecto. En particular, hubo cuatro hitos de la administracin de requisitos y

diseo (MS1-MS4) y tres hitos para la apli-
cacin y Mantenimiento (MS5-MS7). Para cada uno de estos hitos, el alcance

del proyecto fue actualizado y baselined. El hito
crite- ria fueron como sigue:

MS1: al principio de cada proyecto, RT se extrajeron documentos gua para
formular un conjunto de
caractersticas para un prximo proyecto de plataforma. Una caracterstica, en

este caso, se trata de un concepto de
agrupacin requisitos que constituyan una nueva mejora funcional a la

plataforma. En esta etapa, las funciones que contenan
una descripcin suficiente para permitir la estimacin de su valor de mercado y

aplicacin de esfuerzo, ambos de los cuales
fueron obtenidos mediante la aplicacin de un enfoque de costo-valor [37].

Estos valores fueron la base para la inclusin
inicial de alcance para cada rea tcnica cuando las caractersticas fueron
revisados, aprobados y priorizados. El mbito
inicial fue decidido y baselined por RT, guiados por un proyecto de directiva y
sobre la base de las estimaciones de recursos
inicial dada por la recepcin principal (main) DT. El alcance fue mantenida en
un documento llamado lista de caractersticas
que se actualizan cada semana despus de una reunin de la junta de control

de cambios (CCB). El papel de la CCB fue decidir
agregar- ing o quitando caractersticas segn los cambios que se produzcan.

MS2: Las caractersticas eran refinados y a los
requisitos especificados por la RTs y asignados a sus DTs, principal

responsable del diseo y la implementacin de la funcin.
Los requisitos fueron examinadas con los principales DTs y fueron luego
aprobadas.
Otros DTs (secundario) que tambin se vieron
afectados por las caractersticas fueron identificadas. La ede hacer una

estimacin de esfuerzo por caracterstica para DT
principal y secundaria.
MS3: DTs ha perfeccionado los requisitos del sistema y comenz a disear el
sistema. El conjunto de DTs
secundario fueron refinados, junto con las estimaciones de esfuerzo y el

alcance fue actualizado y baselined.
1110 E. Bjarnason
et al. / Informacin y Software de Tecnologa 54 (2012) 1107-1124

MS4: El refinamiento de los requisitos de trabajo y el diseo
del sistema estaban terminados, y los planes de ejecucin fueron producidas.

El alcance final fue decidido y acordado con los
recursos de desarrollo, es decir, la unidad de software.

MS5: todos los requisitos que se haban elaborado y entregado a la
plataforma.
MS6: el software en la plataforma se haba estabilizado y preparado para
pruebas de clientes.
MS7: El cliente
inform de cuestiones haban sido manipulados y el software actualizado. El

software estaba listo para ser lanzado.
Segn las
directrices del proceso de la empresa, la mayora del mbito de trabajo debera

haberse realizado por MS2. Las exigencias se
expresaron mediante un dominio especfico, el lenguaje natural, y contena

muchos trminos especiales que requiere conoci-
mientos contextuales para ser entendido. En las primeras fases, requisitos

contena una descripcin orientada al cliente
posteriormente al ser refinado para de- requisitos de aplicacin de la cola.

3.3. Proceso de desarrollo gil
a fin de hacer
frente a los retos de la gestin de requisitos de alta volatilidad, el caso empresa

fue la introduccin de un nuevo proceso de
desarrollo en el momento de este estudio. El tamao y la complejidad del

desarrollo de software, incluyendo el uso de las
lneas de producto, sigue siendo la misma, independientemente del proceso

utilizado. El nuevo proceso se ha visto influido por
las ideas y principios del desarrollo gil pro- cesses eXtreme Programming (XP)
[7] y [67] de Scrum. Proceso basado en la
fase- fue sustituido por un modelo de desarrollo continuo con un peaje de

entrada de estructura para las versiones de software
de la lnea de productos de software (para permitir la coordinacin con

hardware y proyectos de producto, consultar P1 infra).
La responsabilidad de la administracin de requisitos fue trasladado desde el

(anterior) requisitos unidad, parcialmente en la
unidad de negocio y parcialmente en el software de la unidad.

Las siguientes prcticas giles se estaban introduciendo RE:
una
liberacin continua de alcance y planificacin de flujo (P1). El alcance para

todas las versiones de software est
continuamente planificados y administrados a travs de una lista basada en

prioridades (comparable a una cartera de
productos).
La unidad de negocio recoge y prioriza las funciones desde una perspectiva
busi- ness. Todos los nuevos requisitos
de alto nivel se continua- amente colocado en esta lista y priorizados por la

unidad de negocio. El software calcula la unidad
de esfuerzo y potencial- ery fecha de entrega para cada caracterstica en

funcin de la prioridad y la capacidad de recursos
de software disponibles. El desarrollo es planeada y ejecutada segn un orden

de prioridad. La planificacin y la asignacin
de recursos se realiza a travs de un plan global que contiene todos los

recursos de la unidad de software. El mbito de
aplicacin de la plataforma de lanzamientos estn sincronizados con los

lanzamientos de productos por compromiso gradual a
diferentes partes del mbito. mbito crtico es solicitado para ser

comprometidos para lanzamientos de producto especfico,
mientras que los no-caractersticas crticas son asignados a las versiones de

los productos cuando son implementados y listos
para ser integrados en la plataforma.
Los equipos de desarrollo de funciones cruzadas (P2) que incluya un

representante de
atencin al cliente asignado por la unidad de negocios (comparable a la gil

prctica de cliente proxy) tiene la plena
responsabilidad de la definicin de los requisitos detallados, implementar y

probar una caracterstica (de la lista basada en
prioridades comunes). Cada nueva caracterstica es desarrollado por un equipo

multidisciplinar compuesta especficamente para
esa funcin. Las diferentes disciplinas de ingeniera de software y fases (por

ejemplo, requisitos, diseo y prueba) se
realizan en forma integrada y en el mismo equipo.

El equipo tiene el mandato de decidir sobre los cambios en el valor, el
esfuerzo y los marcos de tiempo asignado para la funcin.

E iterativo gradual detallando los requisitos (P3). Las exigencias
se definen primero en el nivel alto (como caractersticas en el pri-ority basado lista) y luego iterativamente refinado en
los equipos de desarrollo en requisitos ms detallados, como el diseo y la

ejecucin de los trabajos.
Ingeniera de
Requerimientos integrados (P4). Los requisitos engi- neering tareas estn

integradas con otras actividades de desarrollo
activ- dades. Los requisitos son detallados, acordado y documentado durante el

diseo y desarrollo dentro de la misma cruz-
funcional del equipo de desarrollo a travs de una estrecha interaccin entre
el representante de atencin al cliente y
otros miembros del equipo, por ejemplo,

diseadores, desarrolladores y probadores.
Las historias de usuario y criterios de
aceptacin (P5) se usan para doc- ument formalmente los requisitos acordados
para el desarrollo. Las historias de usuario
usuario definir metas y definir los criterios de aceptacin para cumplir requisitos
detallados para una historia de usuario
para ser aceptada como totalmente implementado. Los criterios de aceptacin

sern cubiertos por los casos de prueba.
Este
estudio se centra principalmente en la situacin previa a la introduccin de la

nueva forma de trabajo gil, es decir, para
los proyectos de trabajo como se describe en la seccin 3.2. La gil RE las

prcticas comprendidas en este trabajo fueron de-
multado en el proceso de desarrollo interno de la empresa en el momento del

estudio. Prcticas P1 y P2 estn siendo utilizados
en los proyectos, mientras que P3 se ha aplicado parcialmente, y P4 y P5 en el

proceso de ser implementado. Por lo tanto, no
fue posible investigar el impacto total de la nueva RE prcticas giles en el

momento de este estudio. No obstante, el estudio
investiga cmo estas (nuevas) prcticas se cree para afectar la situacin
overscoping, es decir, qu causas y causas pueden
ser afectados por la gil RE prcticas y, por lo tanto, permitan reducir

overscoping y sus efectos.
4. Mtodo de investigacin
El estudio se inici debido a un nmero mayor de transicin que tiene lugar en
el caso de la empresa y con el objetivo de
entender las diferencias entre el mbito de los procesos basados en la fase

proceso y el nuevo proceso de desarrollo gil.
Investigaciones anteriores en nuestro mbito [71] sirvi como base para la

identificacin de la investigacin preguntas,
tendientes a buscar una comprensin ms profunda de overscoping como

fenmeno. A fin de obtener una visin detallada, un
enfoque explicativo [60] fue tomada y el diseo del estudio se bas en el

contexto especfico de la empresa y los autores de
pre-comprensin.
(Estas investigaciones pueden luego ampliarse en futuros estudios.) el
conocimiento existente de la literatura
fue tomada en cuenta en la interpretacin y validacin de los resultados.

Una sola empresa Estudio de caso explicativo [60]
se realiz utilizando principalmente un enfoque de investigacin cualitativa

complementado por un mtodo cuantitativo para
algunos de la recopilacin de datos. Re- bsqueda cualitativa es adecuado

para investigar un fenmeno complejo (como
overscoping) en un contexto real donde existe [48] (como nuestro caso) de la

empresa. En este estudio, los practicantes las
percepciones del overscoping fueron estudiados mediante entrevistas donde el

verbalizado pensamientos de individuos con una
amplia gama de papeles diferentes en el caso de compaa fueron capturados

[48,60]. Una descripcin general de los mtodos de
investigacin se muestra en la Fig. 1.

El estudio de caso se realiza en tres fases, vase la Fig. 1. En la primera fase,
la
experiencia industrial de uno de los autores fue utilizado para formular una
hiptesis acerca de las posibles causas de la
(supuesta) y overscoping (supuesta) efectos que pueden derivarse de

overscoping. Esta hiptesis fue utilizado como punto de
partida para crear el instrumento de entrevista [69] para la entrevista, que tuvo
lugar en la segunda fase del estudio. En la
tercera etapa, se presentaron los resultados de la entrevista (otro) de seis

profesionales de la misma empresa y validado
mediante un cuestionario (vase la seccin 6 para obtener ms detalles y [69]

para el cuestionario de validacin). Esto se
hizo para reducir el riesgo de inadecuado (false) cer- tainty de la exactitud de

los resultados [60].
E. Bjarnason et al. /
Informacin y Software de Tecnologa 54 (2012) 1107-1124 1111

investigaciones anteriores preguntas de investigacin sobre
OVERSCOPING
para fase-fase basada en procesos basados en contexto
RQ1 overscoping: Cules son las causas? Contexto gil para el
proceso de desarrollo gil provoca efectos RQ2: Cules son las

consecuencias? RQ3: Cmo puede volver prcticas giles
provoca efectos'' impacto de las causas y efectos?

Caso
estudio de caso de contexto de la empresa
Fase 1 Fase 2 Fase 3
experiencia
de trabajo en el caso de la empresa con funciones profesionales 9 y 6 (Otros)

experiencias profesionales en todo el ciclo de
vida de
pre-estudio de entrada y validacin de la formulacin de hiptesis de estudio

entrevista cuestionario
5 asumi las
causas (Seccin 4.1.1) 6 causas principales (Seccin 5.1, [11]) + 2 principales

causas, raz 5 RE prcticas giles
(Seccin 3.3, [10]) causas (Seccin 5.2, [11]) causas (Seccin 6.1)
Entrevista instrumento ([69]) 6 efectos (Seccin
5.3, [11]) + 3 efectos (Seccin 6.2)

3 RE prcticas giles (Seccin 5.4) + 3 prcticas (Seccin 6.3)
Salida
Fig. 1. Descripcin
de mtodo de investigacin para el estudio de caso.

4.1. Fase uno: estudio previo y generacin de hiptesis lotes de esas
peticiones en uno o dos proyectos por ao. Fue un desafo para gestionar la
ejecucin de varios proyectos paralelos, el
propsito de la primera fase del estudio fue elaborar un, mientras que la
tramitacin de las solicitudes de nuevas
caractersticas y requisitos, como hiptesis sobre overscoping y prepararse

para las entrevistas. Al igual que, las
solicitudes de cambios en el mbito de proyectos convenidos. La

experiencia de uno de los autores (que ha trabajado en el caso
com- ninguna visin general de la disponibilidad de recursos de software (C2)

fue asumida como pany, con experiencia en varias
reas, incluyendo la codificacin, diseo, causa overscoping debido al reto de

equilibrar el tamao de ingeniera de
requisitos y desarrollo de procesos) fue utilizada para el alcance total para

varios proyectos de desarrollo (paralela)
identificar posibles (supuesta) causa y efecto de overscoping. En contra de la

(misma) conjunto de recursos para el
desarrollo. Adems el recurso a estos supuestos para la fase-basado de la

manera de trabajar, la asignacin de la unidad de
desarrollo de software se manejan en este autor tambin identific el gil RE

prcticas que presenta el nivel de DT, es decir,
no hubo visin total de la carga y en el caso de empresa. Estas prcticas se

afectarn a la capacidad disponible de todos los
recursos para el desarrollo de uno o ms de los temas que aparentemente

causan overscoping en la unidad de software
basado en
fase de proceso. Si estas suposiciones son correctas, aplicando DT baja

participacin en fases tempranas (C3) fue asumida para
contrib- las nuevas prcticas debe entonces como resultado reducir (o eliminar)
a ute definicin realista y requisitos poco
claros en las primeras los efectos conectado a esas causas, y por lo tanto
reducir (o elimi- fases, que posteriormente se
consider demasiado costoso o imposible de Nate) overscoping. A fin de evitar

la seleccin de un conjunto de suposiciones,
causando as overscoping implemento. Los equipos de desarrollo sesgado por

una sola persona, una serie de reuniones de
intercambio de ideas no estaban muy involucrados en las primeras fases del

proyecto (MS1-MS4) alrededor de la hiptesis se
realizan dentro del grupo de de proporcionar estimaciones de costos y

retroalimentacin durante la exigen- investigadores
implicados en este estudio (es decir, los autores). El resultado de declaraciones

por escrito.
(actualizado) hiptesis fue
utilizado como el principal insumo en la creacin de requisitos no est de

acuerdo con el DT (C4) fue asumida para causar una
entrevista instrumento de estudio (accesible en lnea [69]). overscoping debido

al no garantizar que el alcance sugerido era
factible y comprensible. La especificacin de los requisitos 4.1.1. Formulan

hiptesis no siempre estaba de acuerdo con los
equipos de desarrollo a la hiptesis formulada por este estudio es que

overscoping es punto de transferencia (MS2). Incluso si
existiera una revisin formal por parte causada por un nmero de factores, y
que haciendo frente a uno o ms de DTs, se supone
que existe un bajo nivel de compromiso de estos factores, por ejemplo, a travs
de prcticas giles de RE, el fenmeno de DTs.
Adems, este bajo nivel de acuerdo fue overscoping pueden aliviarse, o incluso
eliminado. El siguiente supone llevar a DT baja
motivacin para cumplir los requisitos de cinco factores fueron identificados

como causas de overscoping asumidas en definido
por la RTs.
Fase uno: especificacin de requisitos detallados es producida por adelantado
(C5) por los requisitos equipos por
MS2 comienza antes de que el diseo es la continua afluencia de requisitos a

travs de mltiples canales (C1) fue asumida para
causar overscoping limitando el margen de negoti- supone para causar

overscoping por la creciente afluencia de muchos
requisitos de explotacin que podra permitir a un diseo ms eficiente la

dificultad de definir un mbito realista para
varios pro- paralelo y plan de desarrollo realistas. Adems, el tiempo y el coste

de la rechaza. Llegan continuamente los
requisitos del mercado, as como los gastos generales de administracin tales

cambios tambin se supone que pro- como, desde
interlocutores internos. Esta entrada fue gestionada por el homenaje a

overscoping.
1112 E. Bjarnason et al. / Informacin y
Software de Tecnologa 54 (2012) 1107-1124

4.2. Fase dos: una entrevista en el estudio de caso
en la fase dos de la empresa,
entrevistas semi-estructuradas con un alto grado de debate abierto entre el

entrevistador y el entrevistado se celebraron. La
hiptesis proporcion un marco que ayudaron a debatir, explorar y enriquecer

la comprensin de este complejo fenmeno non.
Para evitar la imposicin de esta hiptesis sobre los entrevistados, el debate

sobre la overscoping en general y detallado
sobre las causas y efectos siempre comenz con una pregunta abierta.
Adems, los entrevistados se les pregunt a hablar
libremente acerca de los roles y las fases tena experiencia de al comienzo de

las entrevistas. A fin de separar entre la
situacin con el proceso basado en fase y con las nuevas prcticas giles de
RE, el impacto de las nuevas prcticas se
discuti especficamente en una seccin (separados) al final de la entrevista.

Nuestro objetivo era cubrir los requisitos de
todo el proceso, desde la definicin a travs de desarrollo (diseo,

implementacin y pruebas) al producto final resultante
(aseguramiento de la calidad, proyectos de producto), principalmente para el

proceso basado en fase. Esto se logr mediante la
seleccin de personas con experiencia de todas las unidades organizativas

pertinentes (vase la seccin 3) para ser
entrevistados y, por lo tanto, coger un rango de dif erentes- perspectivas sobre

el fenmeno de la overscoping. Nueve perso-
nas en total fueron seleccionados para ser entrevistados. Dos de los

entrevistados con idnticas funciones pidi tener su
inter- vistas juntos. Las funciones organizacionales, pertenencias y experiencia

pertinente de las personas entrevistadas en
el caso de la empresa basada en la fase de proceso pueden encontrarse en la

Tabla 1. Hemos utilizado una codificacin para los
entrevistados que incluye tambin sus organizacio- nal perteneciente. Por

ejemplo, los entrevistados pertenecientes a los
requisitos unidad estn marcados con una letra R, perteneciente a la unidad de

producto con una letra P y pertenecientes a la
unidad de software con una letra S.

Las entrevistas fueron programados para cada 90 minutos con la posibilidad
para reducir
el tiempo o prolongarlo. Las entrevistas fueron grabadas y transcritas, las

transcripciones y enviado de vuelta a los
entrevistados para su validacin. Para cada entrevista, la transcripcin fue de 7

a 10 pginas y contenidos en promedio 3900
palabras. Velocidad de transcripcin variaba de 3 a 7 veces de entrevistas

grabadas. La codificacin y el anlisis fue
realizado en MS Excel. La seccin subyacente estructura de la entrevista

instrumento, es decir, causas, efectos y gil RE
prcticas, fueron numeradas y utilizado para categorizar las opiniones de los
entrevistados. Para cada entrevista, la
transcripcin de fragmentos de texto fueron colocados dentro de las secciones

pertinentes y, en caso necesario, se copia en
varias secciones. Las relaciones entre las diferentes categoras, as como, el

nivel de acuerdo sobre las causas, los efectos
y la gil RE prcticas se observaron en columnas especficas. Dos de los

puntos de vista de los profesionales entrevistados
juntos (entrevistados Ra y Rb) fueron separados en columnas diferentes a fin

de permitir la generacin de informes de sus
respuestas individuales.
Tabla 1 entrevistados roles (para procesos basados en la fase de
organizacin), pertenencia y longitud
de la experiencia para cada funcin dentro de la empresa (vase la seccin

3.1).
Cdigo funcin organizativa dentro de la
empresa (s) aos en funcin de la dependencia de

requisitos de Ra lder RT 5 Rb requisitos lder RT 2 Rc Requisitos arquitecto
Pd 3 Sistema producto test manager 7 Se Software Tester 3 Sf Software project

manager 2 DT 2 Desarrollador lder de software
de 2 SG Quality Manager 3 Sh Software requisitos DT coordinador 1

Desarrollador lder 2 DT 1 Requisitos del software Si DT
coordinador 7
4.3. Fase 3: validacin de los resultados a travs de cuestionario
para fortalecer an ms la validez de los
resultados de la inter- opiniones un conjunto de seis profesionales (adicionales)

en el caso de empresa fue seleccionada en la
fase tres, ver Tabla 2. Para garantizar que estos seis profesionales entiende los
resultados correctamente y de manera
uniforme, los resultados de la entrevista se presentaron a ellos. Durante la

reunin, los participantes podrn pedir
aclaraciones y comentarios sobre los resultados, especialmente cuando

discrepaban o tenan otras diferentes o puntos de
vista adicionales. A fin de recabar sus opiniones sobre los resultados en forma
uniforme y no de manera pblica, se pidi a
los participantes que rellenen un cuestionario (disponible en lnea en [69])

indicando en qu grado aceptaron los resultados y
si hay otros elementos pertinentes haban sido perdidas. Debido a la limitada

disponibilidad de los participantes un total de
tres de esos perodos de sesiones se celebraron. Cada sesin fue programada

para 90 minutos, con la posibilidad de ampliar o
disminuir el tiempo que sea necesario. Los resultados del cuestionario puede
ser encontrada en la seccin6.
5. Los resultados
de la entrevista
las causas y los efectos de overscoping derivado del entrevistas realizadas en
la segunda fase del estudio
(vase Fig. 1) se detallan en la Fig. 2 y se describen en las secciones

siguientes. Seccin 5.1 abarca las principales causas
de overscoping, mientras que las causas son reportados en la seccin 5.2 y los
efectos en la seccin 5.3. Los resultados de
las entrevistas acerca de cmo las prcticas giles pueden abordar

overscoping RE se describen en la seccin 5.4. Los
resultados de la validacin cuestionario (fase 3) en estos resultados se

analiza en la seccin 6.
5.1. Causas de overscoping
(RQ1)
El punto de vista de cada entrevistado sobre las causas de overscoping fue
categorizada y compara con la hiptesis sobre
las supuestas causas de overscoping (C1-C5, vase seccin 4.1.1). Adems,
cinco de los ocho entrevistados fueron encontrados
para describir la sexta causa principal de overscoping, es decir, C6 clara visin

del objetivo general. Una falta de
(claramente comunicado) estrategia y objetivos generales y direcciones

empresariales para el desarrollo de software dirigido a
unclarities sobre el sentido tanto de software guas y estrategias de productos,

as como, claro empresas pri- ority de
alcance del proyecto. Los entrevistados describieron cmo esta causa (C6)
provoc el alcance propuesto principalmente de una
tecnologa como- pect, en lugar de desde una perspectiva empresarial, y sin

una prioridad unificada (acordado). En su lugar,
la mayora de los alcances de un proyecto que pretenda ser crtico y no

negociables.
El entrevistado resultados alrededor de
las principales causas de overscoping se muestran en la Tabla 3. Las opiniones

de los entrevistados han sido clasificadas de
la siguiente manera:
Experiencia: la causa (tanto su ocurrencia y sus efectos sobre overscoping) es
experimentado y fue
mencionada sin preguntar.

De acuerdo: la causa (ocurrencia e impacto) fue no se menciona directamente,
sino que provienen o
acordado tras la pregunta directa, o cuando el entrevistado no tiene experiencia

directa, pero haba observado o escuchado
acerca de los dems.

En parte de acuerdo: parcialmente experimentado o en parte de acuerdo.
Discreparon: no est de acuerdo con
la causa, ya sea su aparicin, o que caus overscoping.

No mencionados: aunque en espera experiencia para papel.
NA: no dentro
de la experiencia esperada para el papel (segn el proceso).
E. Bjarnason et al. / Informacin y Software de Tecnologa 54
(2012), 1107-1124
Cuadro 2 respuestas al cuestionario: funciones y organizacin (para la etapa

pertenecen el proceso basado), y
la longitud de la experiencia dentro de la empresa (vase la seccin 3.1 para

obtener descripciones de las unidades
organizativas y roles).
Funcin organizativa(s) aos dentro de la unidad de
Software de la empresa project manager, lder DT 4
Probador de software 7 Software requisitos DT coordinador, lder DT 5

Requisitos arquitecto 5 Requisitos del sistema del
producto lder RT 13 test manager 15

Todos los entrevistados haban experimentado o acordaron overscoping como
un desafo, y la
mayora haban experimentado o acordado a causas 1- 3. No entrevistados

manifest su desacuerdo a cualquiera de las causas,
aunque las causas 4 y 5 tenan menos de una mayora de experimentados o

acordado a los entrevistados. Causa 4-5 no fueron
mencionados por todos, mientras que la causa 6, el cual se deriv de 5 de los

entrevistados, no era hombre- cionado por los
dems.
Las entradas marcadas NA (no aplicable) indican que la inter- viewee en su
papel no se esperaba tener experiencia de esa
causa. El director de pruebas de sistemas (Pd) y el gerente de aseguramiento

de la calidad (SG) fueron clasificados como NA
para C2, C3 y C4, ya que se limit a observar los requisitos fluya desde sus
posiciones a nivel de gestin y no estaban
directamente implicados en las primeras fases de los proyectos. Adems, la SG

fue clasificada tambin como NA C5 debido a la
falta de contacto con los Srs. Adems, el software tester (Se), que no tenan
conocimientos en la planificacin del
proyecto, se clasific como na de las causas C1 y C2.

Para todos supone causas hubo algunos recuentos de en parte de acuerdo, a
saber: la
continua afluencia de requisitos a travs de mltiples canales (C1). El gerente
de calidad (SG) menciona el flujo
continuo de cambios de requisitos despus de establecer el alcance como el

causante de la
Fig. 2. Descripcin general de todos
los encontr causas (C), causas y efectos (RC) (E) de overscoping. Productos
derivados del cuestionario observ con + y lneas
discontinuas. Entrevistado Cdigo (vase

1113
overscoping, pero no las causas antes de este hito y, por tanto, est clasificado
como "parcialmente acordado".

No hay ningn resumen de la disponibilidad de recursos de software (C2). Uno
de los requisitos DT
coordinadores (IS) es sealado como "parcialmente" acordadas a esta causa,

debido a la creencia de que una mejor visin de
conjunto de los recursos disponibles no aliviara la overscoping a cualquier en

mayor medida. En contraste, otro entrevistado
(Sf) vio esto como una fuerte causa de overscoping; 'No hay control de lo que
la gente estaba trabajando. Hubo diferentes DT
lderes que slo envi [tareas]'.

DT baja participacin en fases tempranas (C3). Ambos requisitos DT
coordinadores (sh, Si)
fueron clasificados como "parcialmente de acuerdo" desde la participacin del

resto de los DT, incluso para producir
estimaciones de costos fue escasa, a pesar de que personalmente antes

experimen- t una buena cooperacin con el RT lderes
durante MS1-MS2.
Esta falta de participacin fue visto por el DT tester (Se) como principalmente
a un alcance excesivamente
elevada especificada, 'La vista completa de requisitos podra mejorarse

incluyendo la entrada de ms funciones y un alcance
ms realista podra ser identificado anteriormente." requisitos no acordadas con

DT (C4). Requisitos de la DT-coor- dinators
(sh, IS) estima que los requisitos eran entendido y acordado con el DT en MS2,
aunque el DT no se comprometen a aplicar en ese
momento. Uno de ellos (Sh) mencion que la especificacin de requisitos del

sistema fue fundamentalmente de acuerdo con el DT
requisitos coordinadores y no con los desarrolladores y probadores en la DT.
especificacin de requisitos detallados producidos
por adelantado (C5). Uno de los lderes de la RT (Rb) tena una forma de
trabajo gil y no se produce una especificacin de
requisitos detallados de antemano, sino que regularmente e interactuaban

directamente con el DT. Este aumento de la
penetracin en el DT permiti una discusin ms flexible alrededor de alcance

y requisitos detallados, llevado a overscoping
ser experimentado como un desafo ms manejables por RB. El otro lder RT

(Ra, entrevistado junto con Rb) no menciona la
seccin 4.2) seal dentro de los corchetes.
1114 E. Bjarnason et al. / Informacin y Software de Tecnologa 54 (2012) 1107-
1124
C5 como causando overscoping, pero acordaron Rb las conclusiones y se
seal como "parcialmente acordado". Ra tena la
experiencia opuesta, es decir, de producir y apoyarse en una especificacin de

requisitos, y luego no estar en contacto con el
DT durante las posteriores fases de desarrollo (despus de MS2) que luego

desarroll software que normalmente era diferente
de lo que se especific en el SRS. Uno de los entrevistados (DT) crea que la

Sf (perdido) el esfuerzo de elaborar y acordar
los requisitos detallados (iniciales de las caractersticas que ms tarde fueron

descoped) aument la overscoping que
obstaculizaba los recursos trabajando en caractersticas viables. Otro

entrevistado (Sh) dice: "En este momento [MS2] nos [DT]
aprobado un montn de cosas, porque nos gust lo que [RT] escribi aqu y
realmente queramos que la funcionalidad entonces
nosotros [DT] comenz a sobrecompromiso."

5.2. Anlisis de causa raz (RQ1)
para proporcionar una mayor comprensin de los
entrevistados se les pregunt para describir lo que se puede desencadenar

overscoping, es decir, las causas de overscoping.
Estas causas han sido agrupados en funcin de la causa principal (C1-C6,

descritos en las secciones 4.1 y 5.1) que les
afectan. Un panorama completo de las relaciones causa-efecto para overscoping identificados a travs de este estudio est
representada en la Fig. 2. Los resultados alrededor de causas tanto de las

entrevistas y el cuestionario tambin estn
resumidos en la Tabla 4.
causas de C1 (requisitos continua afluencia a travs de varios canales). Un
gran nmero de fuentes,
adems de la exigencia del requisito de regular el caudal (definido por la RTs)

fueron mencionados como pro- tributacin para
el flujo continuo. Estos incluyen: requisitos producida por definir diferentes

variantes del producto en la lnea de productos
(RC1a); y, la mayora de finales de los nuevos requisitos del mercado y los

cambios efectuados por los largos plazos de
entrega de proyectos (RC1b) en comparacin con la tasa de requerimientos de

cambio. Adems, comunicacin lagunas (RC1c) fueron
mencionados como causa de ingreso requisitos adicionales a travs del ciclo

de vida del proyecto. Estas consisten de brechas
de comunicacin entre la unidad y el software requisitos de unidad (RC1ci) que

result en la unidad de software prefieren
trabajar segn su propio software-inter- nal roadmap que contienen una gran
cantidad de requisitos no est de acuerdo con los
requisitos unidad. Brechas de comunicacin entre reas tcnicas, tanto para la

RTs y para DTs (RC1Cii) condujo a requisitos
indirecta entre DTs se descubri despus del alcance inicial seleccin en MS2,
lo que increment enormemente la cantidad de
aplicacin requerida. El impacto de estos indi- rect requisitos era especialmente

grande para DTs responsable de la
funcionalidad de la capa de servicio como mostrar marcos y protocolos de

comunicacin. Adems, las interrupciones de la
comunicacin entre la usabilidad y el diseo RC1RTs (CIII) result en operacionales requisitos funcionales que aparecen en
la especificacin de diseo de usabilidad, a veces en conflicto con los

requisitos de la RT.
Y, finalmente, debido a la falta
de comunicacin entre el software gestores de calidad y los requisitos unidad

(RC1civ), requisitos de calidad aspectos no
fueron definidas y priori- tized junto con los requisitos de RT, pero logr separado en una fase posterior.
Causas de C2 (sin
visin general de la disponibilidad de recursos de software).

La falta de una visin general de los recursos disponibles para
el desarrollo de software fue credo para ser consecuencia de lagunas de

comunicacin dentro de la unidad de software y entre
el DTs (RC2a). Las estructuras organizativas y el alcance de alta presin fueron

vistos al resultado en cada DT centrndose en
sus propias esferas ms que luchar por la cooperacin y la buena

comunicacin con otros DTs. Una de las entrevistadas
describi que la habilitacin de DTs para coor- dinate sus planes tena el efecto
de mejorar el alcance situ- cin mediante el
aumento de la tasa de entrega y la eficiencia, "hemos intentado

resolver la overscoping habilitando la DTs para co-plan y deli-
ver incrementalmente. Esto result en ms entregas y el aumento de la

eficiencia." (Sf) causas de C3 (DT baja participacin en
fases tempranas). Varios entrevistados describen que recursos de software

eran raramente disponibles en fases iniciales del
proyecto (RC3a) debido a que el desarrollo y mantenimiento de proyectos

anteriores. Rc dijo: 'Por MS2, pero era difcil
conseguir [DT] recursos. Ese fue probablemente el problema." Adems, dbil y

estimaciones de costos incorrecto (RC3b) fueron
mencionados como conducente a incluida demasiado en el alcance del

proyecto. En contraste, la baja capacidad de desarrollo de
software de la unidad (RC3c) causados por la mala arquitectura fue credo por
los dos dirigentes RT que la principal razn de
ms alcance-. Adems, las lagunas en la comunicacin (RC3D) entre la unidad

y el software requisitos unidad fueron mencionados
como causantes de baja participacin de DT. Por ejemplo, inter- viewees

mencion que DT temprana participacin era a menudo
post- poned debido a una falta de entendimiento dentro de la unidad de

software para la importancia de este trabajo. Sin
embargo, lo opuesto tambin fue mencionado, a saber, que el DTs requisitos

recibido informacin demasiado tarde (RC3DI), que
luego se tradujo en extender el alcance del proyecto sin planes realistas.

Asimismo, las estimaciones de costo, tanto para el
desarrollo y las pruebas no siempre fueron respetados (RC3DII). En contraste,

la estrecha cooperacin entre la RTs y el DTs
eran experimentados (Rc) para conducir a la pronta deteccin de problemas,

permitiendo as la definicin de requisitos ms
estable que luego fueron exitosamente implementadas.
Causas de C4 (requisitos no est de acuerdo con DTs). DT baja
participacin en las primeras etapas (C3, RC4a) fue visto como conducente a la
dbil acuerdo y compromiso con los requisitos,
por los tres entrevistados con experiencia en planificacin de trabajo DT (Se,

Sh, Si). Los entrevistados conectado al nivel
de los requisitos de acuerdo con el nivel de comunicacin alrededor de exigencias (RC4b), es decir, RTs y DTs que comunican
bien tambin tendan a tener un entendimiento mutuo y el acuerdo de los

requisitos. Debido a variaciones en la comunicacin
entre los equipos, la opinin sobre C4 variaron entre los entrevistados (vase
seccin 5.1). Aun as, uno de los
entrevistados (sh) que haban experimentado una buena cooperacin con el RT

mencion que las diferentes pertenencias
organizacionales (RC4bi) caus problemas de sincronizacin debido a las

diferentes prioridades para las diferentes unidades.
Adems, la comunicacin brechas entre RTs y DTs (RC4bii) incluyendo ningn

contacto entre los evaluadores y RT dirigentes
fueron causados por las distancias fsicas y organizativas y result en DT dbil

acuerdo sobre los requisitos. La debilidad de
la comunicacin sobre los requisitos y el diseo entre desarrolladores y

probadores (RC4Biii) tambin fue mencionado (Se) como
causa de requisitos dbil acuerdo.
Causas de C5 (especificacin de requisitos detallados producidos por

adelantado). La fase de
proceso basado en una especificacin de requisitos definidos que deben ser

producidos por MS2, por tanto, no habra nuevas
causas se han identificado para esta causa.

Causas de C6 (clara visin del objetivo general). El RT lderes (Ra y Rb)
describi
que la ausencia de una clara estrategia de negocio (RC6a) y la visin de futuro

que podran servir de gua en la definicin de
un roadmap result en proponer un mbito de proyecto desde un punto de vista

puramente tecnolgico (RC6b). Una dbil y ONU-
prioridad empresarial unificada (RC6c) del alcance propuesto (casi todo era
'crticos') se describen (por Si) como empujando
el DTs para comprometer a unreal- istic planes de proyecto. Adems, Rc

mencion que la falta de prioridad unificada
obstaculizaron el project management de abordar eficazmente el overscoping.

Adems, varias lagunas de comunicacin (RC6d) se
considera que contribuyen a esta causa.

La debilidad de la comunicacin tanto entre RTs (RC6DI) y entre DTs (RC6DII)
fueron
descritos por rc como resultado de dbil alcance la coordinacin entre reas

funcionales, as como, los conflictos y la falta
de claridad respecto al objetivo general. Por ltimo, ambos RT
E. Bjarnason et al. / Informacin y Software de Tecnologa 54
(2012) 1107-1124 1115

Tabla 3 para cada una de las principales causas de overscoping identificados,
el nmero de entrevistados
por cada categora de respuesta (vase la seccin 5.1) y unidad organizativa

(Reqs, etc, vase la seccin 3.1).
Overscoping
continuo C1 C2 C3 bajo ninguna descripcin DT no Reqs C4 C5 C6 reqs

detallada claro como un desafo req afluencia de softw
involvm especificacin acordada visin de recursos en las fases tempranas con

DTs producido upfront objetivo general
Reqs Softw
Producto Reqs Softw Producto Reqs Softw Producto Reqs Softw Producto
Reqs Softw Producto Reqs Softw Producto Reqs Softw
experimentado Producto 2 5 1 1 3 1 1 2 3 1 1 1 2 3 2 acordado 1 2 2 1 1 1 1 1 1
2 en parte de acuerdo En desacuerdo no
menciona 21 2 12 31 NA 1 21 11 11 1
lderes describen que brechas de comunicacin y baja comn que deca:
"Incluso si nos
decidimos por un mbito para MS4, hubo acuerdo entre la unidad y el software
requisitos extremadamente muchos cambios en
marcha, as que nunca estuvimos listos unidad (RC6diii) del objetivo general se
tradujo en el mbito del proyecto por MS5,
como habamos dicho, pero se retrasaron." se decidi en gran medida por el

DTs, y no (como el pro- las expectativas de los
clientes no siempre se cumplen (E4). Fue declarado Overscoping cess) por la

RTs. mencionada por algunos entrevistados como
resultado de falla a veces- ing para satisfacer las expectativas de los clientes.
Por ejemplo, clientes 5.3. Efectos de
overscoping (RQ2) a veces las solicitudes de cambio de archivo caractersticas

que anteriormente haban sido eliminadas debido
a overscoping. Adems, las entrevistas overscoping descubri los siguientes

seis principales efectos de excesiva causada por
exigir un gran nmero de productos (RC1a) con dif- (marcado como mbito de
E1 a E6, vase la Fig. 2): los tamaos de pantalla
y formatos de tores fue experimentado por intervie- wee Sf como resultado de

lanzar productos con software defectuoso, muchos
cambios de requisitos despus de que el proyecto alcance est establecido

(E1). Por ejemplo todos los iconos extraviado.
entrevistados haban experimentado que overscoping causados exigenbrechas de comunicacin (E5). Overscoping y sobrecargar
una orga- bles cambios tienen lugar despus de que el alcance del proyecto
fue establecido (izacin fue descrito como lder en
comunicacin a varios MS2). Como los proyectos continuaron y la sobrecarga

fue uncov- lagunas; entre los requisitos y las
unidades de software; dentro de ered grandes cantidades de caractersticas

fueron retirados del mbito (desde la propia
unidad de software, entre DTs (SG, IS) y entre DTs arregl). El fenmeno es tan
comn que las frases y los gerentes de
proyecto de software (Sf); y entre el software 'overscoping' y 'descoping' se han

convertido en parte de la empresa y de la
unidad de producto. Por ejemplo, muchas caractersticas descoped

vocabulario. Este descoping de caractersticas ya iniciado
era un (E1) y el esfuerzo intil (E1a) se tradujo en desconfianza entre los

desechos (E1a) tanto de RT y DT esfuerzo y llevado
a la frustracin y el software de la unidad de los requisitos de dependencia,

tanto as que el y disminucin de la motivacin
(E1b) para trabajar con nuevos requieren- software unidad definida su propia
gua interna sin coor- ciones. Como Sh
entrevistado dijo: "Hay muchas cosas que dinating esta unidad con los
requisitos. Adems, usted no vlido como un probador o
desarrollador han pasado un tiempo en que nunca presentaron informes de

error por los probadores del sistema basado en un mal
resultado en nada. Y eso no es muy divertido. Hay un montn de SRS

(causada por E1-E6) caus un aumento tanto en la carga de
trabajo y las horas extraordinarias que se ha desperdiciado." Sin embargo, los

muchos requieren- en frustracin por la unidad
de software y, por consiguiente friccin ment cambios fueron experimentados

por el Pd como con menor y ampliaron brechas de
comunicacin entre estas unidades. Impacto en la prueba del sistema.

Simplemente ajusta la prueba desafo para mantener
actualizado el SRS (E6): La situacin provocada por los planes, y rara vez se
desperdicia ningn esfuerzo debido a este
efecto. overscoping, con un alto volumen de trabajo y muchos problemas de

calidad requisito tarda (E2). Todos los
entrevistados profesionales involucrados despus de cambios (E1), el aumento

de la dificultad de mantener el SRS MS4 (cuando
se inicie el desarrollo, RC, Pd, Se, Sf, SG, SH) hombres- actualizado. Los
practicantes mencion que en un overscoping cionado
que la calidad del software se ha visto negativamente afectada por la sobreSituacin la tarea de actualizacin del SRS fue
dado de baja prioridad, tanto de alcance debido a la elevada carga de trabajo y

debido a los muchos (parcialmente causada por
E1B). Adems, la cantidad de cambios de requisitos. El software quality

manager Sg actualizaciones tanto para cambiar y
requisitos descoped se expres, "Si usted consigue demasiado alcance,

obtendr mayores problemas de calidad (ra, rb, PD, SG,
Si) produciendo los requisitos ms adelante y que no tienes la energa para

lidiar con ellos'. Sim- upfront (C5) con un bajo
nivel de acuerdo DT (C4). El RT plomo- ilarly, entrevistado Pd dijo: "Cuando

tienes un montn en el ERS (ra, rb) han
experimentado tambin que muchos requisito- mismo tiempo, todo no est

terminado al mismo tiempo y se relacionaron los cambios
fueron realizados durante el desarrollo sin obtener un producto de calidad

inferior". Adems, la falta de informacin la RTs
(o el sistema probadores), muchas de las cuales podran respetar los costes de

desarrollo (C3DII) en las fases anteriores han
sido el resultado de la insuficiente participacin de DT en las primeras fue

mencionado por el comprobador de software (Se)
para contribuir a las fases (C3). Las pruebas insuficientes y posteriores

problemas de calidad.
retrasos (E3). La overscoping y
la consecuente sobrecarga del DTs fue descrito por varios profesionales como
resultado de 5.4. Impacto de las prcticas giles
de RE (RQ3) retrasos en las entregas son la norma y no la excepcin.

Adems, DTs overscoped se vean a menudo obligados a
comprometerse a cus- La opinin general de los entrevistados sobre la

situacin despus de tomer crticas y peticiones de
cambios que, a su vez, dio lugar a la introduccin de las prcticas giles de RE

(vase la seccin 3.3) es que incluso an ms
retrasos y problemas de calidad (E2). Uno DT entrevistado aunque algunos

overscoping todava est experimentado, es una ms de
administra- (Sf) declar que "nuestro equipo ha sido siempre cargada al 100%
en MS4, reto que con el anterior proceso basado
en fase. Por lo que fue demasiado ya que no siempre eran ejemplo de cliente,
hay menos descoping y la mayora de las
caractersticas trabajadas pide luego que hemos tenido que manejar. Esto
significa que estamos por la unidad de software ahora
contine hasta su finalizacin (IS). Inter- fueron obligados a entregar la

funcionalidad de calidad inferior o tarde.' viewee
Sg dijo: "Todava tenemos overscoping en todos los proyectos. Pero, es la

misma situacin fue descrita por el gerente de
calidad (SG) ahora ms controlado y ms fcil sacar cosas sin tener
1116 E. Bjarnason et al. / Informacin y Software de
Tecnologa 54 (2012), 1107-1124

Cuadro 4 Resumen de todas las causas y causas de overscoping: Nmero de
respuestas de los
entrevistados (vase la seccin 5 para ms detalles) y de las respuestas al

cuestionario por nivel de acuerdo (vase la
seccin 6 para ms detalles). Elementos adicionales de las respuestas al

cuestionario son marcadas con +.
Mencion como causas
raz/Nmero de respuestas al cuestionario (6 en total) causas por # de

experimentados de acuerdo parcialmente en desacuerdo no
entrevistados convienen saber (9 en total)

Overscoping (como un reto) 9 6
C1: Continua reqs. Entrada a travs de mltiples
canales 8 42 (a) gran nmero de variantes de producto 2 3 1 2 b) plazos largos

1 4 2 (c) brechas de comunicacin 6 3 1 1 1 (i)
Entre reqs & software unidad 3 3 2 1 (ii) entre RT-RT y DT-DT 2 3 2 1 (iii)
entre RT y Usabilidad Diseo 1 2 1 1 2 (iv)
entre el RT y los gestores de la calidad del software 1 2 4 (+d) los requisitos del
cliente (muchos cambios y tarde) 3 (+e)
portafolio de productos re-planificacin 1

C2: No hay descripcin de la disponibilidad de recursos de software 6 231 (a)
brechas de comunicacin dentro de la unidad de software 2 1 2 1 1 1

C3: equipo de desarrollo de baja participacin en fases
tempranas 7 1221 (DT) la falta de recursos para el trabajo de pre-desarrollo 1 2

2 2 b) la poca competencia en la estimacin
del costo 2 2 1 3 (c) de baja capacidad de desarrollo 2 1 1 2 1 1 (d) brechas de

comunicacin 3 (i). Requerimientos de
informacin tarda a DT 1 2 2 1 1 (II). Falta de respeto y comprensin de los

costes de desarrollo 2 2 3 1 (+e) dbil
liderazgo incluyendo la comunicacin ineficaz 1 (+f) el cambio de las personas

durante el proyecto 1 (+g) la multitarea 1
C4:
Requisitos no acordadas con los equipos de desarrollo 5 222 (a) baja

participacin de DT en fases tempranas (C3), 3 2 2 1 1 b)
Lagunas de comunicacin 3 1 2 2 1 (i) Entre los requisitos y las unidades de

software 2 1 2 1 2 (ii) entre el RT y DT 2 1 1 2
1 1 (iii) entre los desarrolladores y probadores 1 1 1 1 2 1 (+c) ambiguo e

impreciso requisitos 3 (+d) baja comprensin de
por qu mbito concreto es seleccionado 1

C5: Especificacin detallada de reqs producidos por adelantado 5 1311
C6: clara visin
general Objetivo 5 411 (a) claro la estrategia empresarial para el desarrollo de

software 2 3 2 1 b) tecnologa centrada al
mbito establecido 3 3 2 1 (c) la escasa prioridad de alcance 2 3 2 1 (d)

brechas de comunicacin 2 3 1 (i) entre RTs 1 1 3 2
(ii) entre DTs 1 2 2 2 (iii) Entre los requisitos y las unidades de software 3 1 3 1
1
+C7 proceso dbil adherencia 1
+C8
alcance global y plazo dictada desde 1 gestin

hecho demasiado trabajo." Muchos de los entrevistados afirm que en el C1C4,
cerrando las brechas (identificado como causas) entre ory el gil RE

overscoping direccin prcticas, pero que estas prcticas
RTs y DTs y entre las distintas reas funcionales. Esta prcticas tambin
incurren en una serie de nuevos desafos. Los
siguientes tice se cree tambin que el impacto C5 (requisitos detallados

prcticas fueron mencionados por los entrevistados
que impactan en algunas especificaciones producidas por adelantado) desde

detalles de requisitos de las causas y/o causas de
overscoping: ahora se manejan dentro de los equipos de desarrollo, junto con

el representante de atencin al cliente.
Entrevistado Sf dijo: "Es un advan- alcance un continuo flujo de planificacin

& Release (P1). Esta prctica tage que
ellos [el equipo] sentarse juntos y pueden trabajar undis- (que fue aplicada en
el momento de la entrevista) fue turbed, y no
hay ninguna nosotros y ellos, pero es a nosotros. Y cuando visto para abordar
la causa raz dbil priorizacin de mbito
trabajan con requisitos todo el grupo est involucrado y (RC6c, mencionado por
RC, PD, SG, SH) y las causas apretones de
manos." continua afluencia requisitos a travs de mltiples canales (C1,

mencionado por e iterativo gradual detallando los
requisitos (P3). Esta prctica se, Sf) y ninguna visin general de la

disponibilidad de recursos de software (C2, (que fue
ejecutado parcialmente al momento de la entrevista) mencionada por sf, SG),

haciendo valer que todo el mbito y desarrollar-
se menciona como impactando directamente en la causa C5 (detallada ment

recursos son administrados a travs de una prioridad
uniformemente SRS producidos por adelantado). Adems, esta prctica

tambin fue visto lista. Por Sf y SG para reducir tanto el
tiempo de entrega para cada cruz de alto nivel funcional de los equipos de
desarrollo (P2). Esta prctica (cuyo requisito
(RC1b) y la cantidad de cambios despus del proyecto se llev a cabo en el

momento de las entrevistas) fue visto alcance est
establecido (E1) y, por tanto, tambin reducir la cantidad de desperdicio de

abordar varias lagunas de comunicacin y, por
tanto, impacto provoca esfuerzo (E1a, tambin mencionado por ra, rb).
E. Bjarnason et al. / Informacin y Software de
Tecnologa 54 (2012) 1107-1124 1117

ing: horas extraordinarias (+E7); ha cambiado y a veces cancelado el producto
6.
Cuestionario sobre la validacin de los resultados de la entrevista los planes

(+E8); bajo la priorizacin de tareas
administrativas (+E9). La respuesta completa al cuestionario sobre los efectos

se muestran en la Tabla 6. Overscoping se
investig ms a travs de la validacin adems de expresar el grado de

acuerdo a las identificadas ef- cuestionarios [69], ver
Tabla 4. Cada uno de los seis encuestados seal fects de overscoping, se

pidi a los encuestados que grado sus im- su nivel
de acuerdo con la siguiente notacin: pacto. Se utiliza la siguiente notacin:

experimentado: lo he experimentado (Tema y
conexin) a ser crtico: nivel de la empresa o del cliente. vlida. Importante: el

proyecto o el nivel de la unidad. De
acuerdo: Estoy de acuerdo con esto, pero no han experimentado

personalmente. Medio: nivel de equipo. Parcialmente de acuerdo:
Estoy de acuerdo en parte, pero no todas, de esto. Menor: de nivel individual.

En desacuerdo: no estoy de acuerdo. Ninguno: No
hay impacto. No s: no tengo conocimiento de este tema o su impacto.

Todos los efectos identificados en las entrevistas fueron
vistos como hav- 6.1. Causas y causas (RQ1) ing un impacto. Todos los
efectos, excepto el E5 (lagunas de comunicacin) eran
vistos como teniendo importantes o impacto crtico por la mayora de los particuna mayora de los encuestados confirmaron
(es decir ipants. Hubo dos cargos de menor impacto: uno para E6 (mantengaexperimentado o acordado) todas las principales
causas que contribuyen a ing SRS actualizado) y uno para +E7 (horas
extraordinarias).
overscoping, excepto C3 (baja
participacin DT) para que tambin hubo un desacuerdo respuesta. Causas

C2, C3, C5 y C6 cada 6.3. Impacto de las prcticas
giles de RE (RQ3) tenan un recuento de desacuerdo por parte de los

encuestados con experiencia de los requisitos unidad.
Otras dos causas principales fueron dadas por los encuestados la mayora
estuvo de acuerdo con los tres iden- dos de los
encuestados, es decir, procesos de dbil adherencia (+C7) y gil tified RE

prcticas que impactan en el reto de overscoping,
dictado de alcance y plazos de gestin (+C9). Adems, ya sea por experiencia

propia o por creer que la prctica ms, algunas
otras causas fueron dadas para C1, C3 y debera funcionar en teora. Adems,
algunas prcticas adicionales C4. Para C3, otras
dos causas fueron dados, es decir, fueron mencionados como impactando

overscoping: (+P4) la empresa ms clara de DT miembros a
medida que el proyecto avanzaba (RC3F) y visin (es decir, abordar

directamente C6), (+P5) open source development asignar los
mismos recursos para varios proyectos paralelos (limitando el C1 por restringir

lo que el cliente puede razonablemente ex-
(RC3g). Para C4 (requisitos no est de acuerdo con el DT) tres respon- pect
cuando grandes partes del software estn fuera de
la empresa con- abolladuras declar que esto era causado por el ambiguo e
impreciso trbol) y (+P6) las entregas incrementales
(ciclos ms cortos facilitar requisitos (RC4c), mientras que uno de los

encuestados sugirieron que DTs alcance el control del
tamao de cada ciclo). La tabla 7 contiene la pregunta- a menudo carecan de

una idea de por qu ciertas caractersticas y
requisitos naire respuestas sobre el impacto de las prcticas giles de RE en

eran importantes, que est relacionado con C6
(claro visin general de overscoping.

Objetivo). Todas las respuestas del cuestionario de validacin sobre causas Por
ltimo,
los encuestados haba experimentado, acordados o parcialmente y las causas

pueden encontrarse en la Tabla 4. acord que
overscoping segua siendo un reto para el caso de empresa.

El impacto de cada una de las principales causas de overscoping se
midi por el nuevo proceso gil y prcticas son vistos, por lo menos
parcialmente, ad- pidiendo a los encuestados para
distribuir 100 puntos visten la situacin y proporciona los medios para gestionar
mejor los pros y los contra- sobre todas las
causas segn el alcance de su impacto (vase el alcance de overscoping trol y

sus efectos. Los practicantes' Tabla 5) C1
consigui la mxima puntuacin en total y todos los seis encuestados, las

respuestas relativas a la situacin actual se
muestran en la Tabla 8.
lo que indica que los requisitos de continuo flujo fue una causa principal de
overscoping. La segunda
mxima puntuacin total fue de 7. Interpretacin y discusin dado a C6 (clara

visin del objetivo general), en el que todos
los participantes de la unidad de software clasificado con 30-60, mientras que

el resto de los resultados de este estudio
corroboran que overscoping es una com- participantes clasificados con 0 o 30.

Causas C4, C5+C6 y C7 + plex y grave riesgo para
la gestin de proyectos de software [13,20,43] se han visto como un poco o

ningn impacto en el overscoping tanto para la fase
de base y para los procesos de desarrollo gil. En operacio- situacin. cin, los
resultados muestran que los problemas de
comunicacin tienen una gran impacto sobre overscoping. Esto complementa
la labor por Sangwan et al.
6.2. Efecto de
overscoping (RQ2) y Konrad et al. [41] quien mencion que la debilidad de la

comunicacin puede provocar fallos en los
proyectos de desarrollo en gran escala global y en grande, los encuestados

haban experimentado o ingeniera de software [63].
Adems, nuestros resultados ampliar las listas acordadas para todos los
efectos de overscoping identificados a partir de la
inter- de los efectos de la deficiente coordinacin propuesto por Sangwan et al.

[63] opiniones. El demandado desde la unidad
de producto no tena vista en E5 (largas demoras, deje los equipos inactivos y

causar problemas de calidad) agregando o E6,
mientras que el arquitecto requisitos acordados parcialmente E5. En operaciooverscoping. Se necesitan ms investigaciones
para identificar plenamente y ad- cin, los encuestados mencionaron los

siguientes efectos de overscop- visten los factores
involucrados. Se discuten los resultados y

tabla relacionada 5 El nmero total de puntos que reflejan el impacto de cada
causa
de overscoping. Cada cuestionario demandado distribuy 100 puntos. Efectos

de overscoping (RQ2). Las columnas muestran el
nmero de puntos por cada interviniente (organizativas pertenecientes en

cabecera, vase la seccin 3.1).
Impacto total de
softw Softw Softw Reqs Reqs producto

C1: reqs continua afluencia a travs de mltiples canales 275 20 20 15 50 100
70 C2: No
hay descripcin de la disponibilidad de recursos de software 60 10 20 20 10

C3: baja participacin de DT en fases tempranas 80
10 50 20 C4: Requisitos no acordadas con DTs 10 5 5 C5: Especificacin

detallada de reqs producidos por adelantado 15 5 5 5
C6: clara visin del objetivo general 140 60 40 30 10 +C7: proceso de dbil
adherencia 0 +C8: alcance global y la fecha lmite
impuesta desde arriba 20 20
1118 E. Bjarnason et al. / Informacin y Software de Tecnologa 54 (2012),

1107-1124
Cuadro 6 Nmero
de respuestas al cuestionario sobre los efectos de overscoping por nivel de

acuerdo (notacin descrita en la seccin 6) y por
categora de impacto (notacin descrita en la seccin 6.2). Elementos

adicionales derivados del cuestionario marcados con +.
Mencionado por las respuestas al cuestionario (6 en total) # de acuerdo
impacto entrevistados (9 en total) experimentaron de
acuerdo parcialmente en desacuerdo crtica principal medio menor ninguno

acepta no saber
E1: Muchos req cambios despus de
mbito se establece 9 5 1 4 2 (un) esfuerzo desperdiciado 7 5 1 3 3 b)

disminucin de la motivacin 5 4 2 3 2 1 E2: Problemas
de calidad 6 6 5 1 E3: Retrasos 4 6 5 1 E4: no siempre cumplen las

expectativas del cliente 1 4 2 5 1 E5: Lagunas de
comunicacin 4 2 1 1 1 2 1 3 E6: Mantener actualizado el SRS 5 1 4 1 5 1 +E7:

Horas extraordinarias 3 1 1 1 +E8: Cambiado
& cancelado planes de producto 1 1 +E9: tareas administrativas No

Siempre 1 1 realiza el
Cuadro 7 Nmero de respuestas al
cuestionario sobre el impacto de las prcticas giles en overscoping RE por

nivel de acuerdo (notacin descrita en la seccin
6).
Prcticas adicionales identificadas a travs de las respuestas al cuestionario

son marcadas con +.
Experimentado de acuerdo
(en teora) parcialmente de acuerdo En desacuerdo no sabe

P1: alcance y liberacin-continuo flujo de planificacin 2 4 P2:
equipos de desarrollo funcional cruzada 3 2 1 P3: gradual e iterativa de detallar

requisitos 2 2 2 +P4: Empresa Visin 1 +P5:
Open Source Development 1 +P6: Entregas incrementales 1

Tabla 8 Nmero de respuestas al cuestionario por acuerdo categora
(descrita en la seccin 6) sobre la situacin actual en el caso de empresa con

prcticas giles de RE, en comparacin a cuando
se utilizan procesos basados en la fase.

Experimentado de acuerdo parcialmente de acuerdo En desacuerdo no sabe
Overscoping
sigue siendo un reto 3 1 2 Hay menos overscoping ahora 1 1 3 1 Overscoping

es ms manejable ahora 1 3 1 1
para otras
investigaciones en ms detalle, por cada pregunta de investigacin, en secdere afluencia de requisitos tiene el potencial de
causar ms- ciones 7.1 (RQ1), 7.2 (RQ2) y 7.3 (RQ3). Por ltimo, el alcance de
las limitaciones si no se administran y
equilibrado contra el importe de este estudio y las amenazas a la validez de los

resultados son discutidos de la capacidad
disponible. Esta causa tambin se ha identificado en la seccin 7.4. Regnell y

Brinkkemper [59] y Karlsson en el. [38] como
uno de los desafos de la mdre. Adems de corroborar esta 7.1. Causas de

overscoping (RQ1) Desafo, nuestro trabajo tambin
identifica que este flujo continuo de los requisitos puede causar overscoping. La
importancia y nuestros resultados indican
que overscoping es causada por un nmero de gravedad de este factor son

indicados por esta causa anotando causas y causas.
Estas causas se originan principalmente en el mayor factor de impacto total en

el cuestionario (vase el Cuadro 5). La
naturaleza de la mdre el contexto en que opera la empresa, pero la medida en
que esta causa afecta a las empresas que operan
en son tambin debido a las cuestiones relativas a la cultura organizativa y

estruc- la ingeniera de requisitos a medida
contexto [59] requiere tures y comunicacin. Esto fue resaltado por internuevas investigaciones.
viewees describiendo la
causa adicional C6 (clara visin de nuestro estudio revela tambin que la

afluencia de los requisitos puede ser objetivo
general) y dos encuestados mencionar las operacio- aumentaron ms del

mbito creep en el software de gestin internacional de
causas relacionadas a la falta de respeto a la decisin- y mediante un software

interno de roadmap (RC1ci, vase sec- proceso
de desarrollo, es decir, C7 y C8. En contraste, los practicantes con tion 5.2). En

efecto, esto obstaculiza la experiencia
disponible de recursos de buena cooperacin y comunicacin para gestionar

equipos nuevos requisitos de los clientes.
Resultados similares se han descrito overscoping como menos graves y ms

manejables ha informado por Konrad et al. quien
descubri que alcance creep puede impugnar. Esto puede explicar todos los
desacuerdo cuestionario re- producir problemas de
satisfacer las expectativas del cliente [41], es decir,

sponses pero uno (p. ej. C5). efecto E4 (ver seccin 5.3). Konrad et
al. [41] se proponen abordar interpretamos los resultados alrededor de las seis
causas de alcance overscoping creep por una
mayor comprensin y trazabilidad de cus- identificados a travs de las

entrevistas (vase la seccin 5.1 y Fig. 2) como tomer
requisitos, y mediante la creacin de un eficaz: estructura jerrquica de CCB. El

impacto de estos mtodos en overscoping re-
red elctrica para ser evaluados.

Requisitos continua afluencia de mltiples canales (C1). Interpretamos la
homogeneidad de las
entrevistas y los cuestionarios ninguna visin general de la disponibilidad de

recursos de software (C2). La mayora de los
resultados (vanse los cuadros 3 y 5) para significar que un gran y uncontrolnuestros respondedores (seis de nueve
entrevistados y cinco de seis cues-
E. Bjarnason et al. / Informacin y Software de Tecnologa 54 (2012) 1107-1124

tionnaire
encuestados) haban experimentado o de acuerdo a la falta de una visin

general de los recursos disponibles sea una causa de
overscoping.
Sin embargo, los resultados del cuestionario sugieren que el impacto de esta
causa no es tan crtica como la causa
C1. Este resultado es sorprendente, teniendo en cuenta la importancia de la

gestin de la carga de trabajo diaria incluida la
coordinacin de las tareas y actividades reportadas por, por ejemplo, Philips et

al. [52]. El contraste de opiniones de baja
capacidad de desarrollo (RC3c, celebrado por RT dirigentes) y escaso respeto

por los costes de desarrollo (RCdii, celebrada
por DT roles) es interesante. Esta diferencia puede ser interpretado como una
baja comprensin de cada uno de los otros
alrededor del punto de vista del coste y una indicacin de que este punto de
vista- es dependiente de la funcin (relacionados
con Jorgensen y Shepperd [33]). Si la capacidad de desarrollo es realmente

baja es una cuestin diferente. Por ltimo, esta
causa incluye especficamente la falta de visin, o la conciencia de la carga

total de los recursos. Al mejor de nuestro
conocimiento, esta cuestin no ha sido investigado empricamente. Ms bien la

estimacin de costes de software de
investigacin [33] se centra principalmente en la estimacin de esfuerzo y en la

optimizacin de la asignacin de recursos
[45].
El equipo de desarrollo de baja participacin en fases tempranas (C3). Los
resultados indican que la baja participacin
de desarrollo en la fase de requisitos puede causar overscoping (mencionado

por 6 de cada 9 entrevistados y 5 de cada 6
encuestados no est en desacuerdo con esto). Esto confirma la labor anterior

que seala la necesidad de la participacin
temprana de desarrollo en la ingeniera de requisitos, por ejemplo, requeridos

por las interdependencias entre la gestin de
productos y desarrollo de software [51]. Glinz et al. tambin mencion que la

falta de comunicacin entre la gerencia del
proyecto y desarrollo en requerimientos de mano-off pueden conducir a

resultados insatisfactorios [27].
Asimismo, Karlsson y
cols. informaron de que las interrupciones de la comunicacin entre el

marketing [38] (requisitos unidad para nuestro caso
empresa) y desarrollo, puede resultar en un insuficiente esfuerzo esti- mates

(i.e. RC3b) y para comprometerse a irrealmente
grandes caractersticas sin considerar las implicaciones tcnicas y de

programacin [38]. Nuestros resultados corroboran estos
resultados en esa baja participacin y dbil en las primeras fases de

comunicacin puede llevar a problemas posteriores,
incluyendo overscoping. Estos problemas de comunicacin pueden tambin

exacerbar el problema de conseguir estimaciones de
esfuerzo precisos y fiables (RC3b). Adems, el hecho de que un cuestionario

encuestados manifestaron su experiencia- encing
buena comunicacin y cooperacin entre los requerimientos y los equipos de

desarrollo pueden tambin explicar el desacuerdo
respuesta para esta causa. Por otro lado, un resultado sorprendente desde el
cuestionario de validacin es que esta causa (C3)
fue visto influencia overscoping inferior a causa C6 (clara visin del objetivo
general) tanto en total (entre todos los
entrevistados) y en 2 de los 3 software encuestados. Estos resultados indican

que puede haber otros (descubierto) Factores que
influyen en el impacto que esto tiene sobre la causa overscoping.

Por ltimo, se han propuesto varios mtodos para abordar la
causa C3, por ejemplo la negociacin de propuestas de aplicacin [25], el

modelo conectores para transformar los requisitos
para architec- ture [47], la captura de requisitos de cooperacin [46] y involvcin de los clientes en el proceso de gestin
de requerimientos [35].
Razonamiento orientada al objetivo tambin puede proporcionar orientaciones

constructivas para
arquitectos en sus tareas de diseo [42]. Si, y a la que de- cordar los
mencionados mtodos pueden aliviar overscoping
afectando esta causa sigue siendo un tema que requiere ms investigacin.

requisitos no acord con el equipo de desarrollo
(C4). Los resultados proporcionan evidencia emprica de que la dbil acuerdo

sobre requieren- ciones entre los requisitos y
las unidades de software puede causar overscoping (los 6 cuestionario

contest afirmativamente a causa C4 y C4 de cinco
entrevistados mencion como causa de overscop1119

ing). Una importante causa de esta causa fue encontrado para ser com-
comunicacin lagunas, principalmente entre los requisitos, las funciones y las

funciones de desarrollo y pruebas. Esto
confirma el punto de vista de Hall et al. [29] el requisito de que la mayora de

los problemas son en realidad cuestiones
organizativas. Adems, esto confirma la importancia de la integracin de los

diferentes procesos de trabajo colaborativo [22].
El impacto de la insuficiencia de comunicacin de ingeniera del software ha

sido reportado como una cuestin general en
ingeniera de requerimientos y gestin de producto [12,25,29,35,38].

Sorprendentemente, C4 marc el menor impacto entre todas
las causas y slo dos cuestionarios de respondedores (tanto desde la unidad

de software) calific esta causa como con
cualquier factor de impacto (baja) en overscoping. En contraste, causa C6

(dbil visin de propsito general) fue calificada
como tener el mayor impacto en overscoping.

especificacin de requisitos detallados producidos por adelantado (C5).
Nuestros
resultados indican que demasiada documentacin detallada producido por

adelantado puede causar overscoping (citado por cinco
inter- viewees y experimentados, convenido o parcialmente aceptado por cinco

encuestados, vase la seccin 5.1). Esto
complementa otros estudios en la documentacin de proyectos de ingeniera

de software. Por ejemplo, Emam y Madhavji mencion
que en organi- zaciones que requieren un mayor control de la presin para

producir mucho detalle es tambin mayor [23].
Lethbridge inform de que, para los ingenieros de software, a menudo hay

demasiada documentacin para sistemas informticos,
frecuentemente mal escrito y fuera de fecha [44]. Adems, Sawyer et al. [65]
mencionan que la congelacin prematura de los
requisitos puede causar el alcance de arrastre y comunicacin problemas

(ambos de los cuales se identifican como causas de
overscoping en nuestro estudio) y sugerir prototipos evolutivos como un

remedio. Otros recursos sugeridos para tratar el
exceso de documentacin incluyen la reutilizacin de las especificaciones de

los requisitos [24], as como creando simplemente
menos documentacin [3]. La eficacia de estos mtodos para el riesgo de

overscoping permanece para ser investigados. Las
opiniones divergentes sobre esta causa entre los encuestados pueden

explicarse por sus funciones y relacin para volver.
Todos los encuestados para discrepar de esta causa trabaj con requisitos
funciones relacionadas. Estos roles son ms
propensos a considerar los requisitos detallados especificaciones como buena

y positiva, en lugar de un problema. Sin
embargo, estas funciones tienen menos penetracin en las fases posteriores al

desarrollo se lleva a cabo y los efectos de
overscoping son experimentados.

Tres de los encuestados con experiencia en posteriores fases de desarrollo
haban experimentado
como causar overscoping C5. Fur- thermore, Berry et al. mencion que cuando
el tiempo para la obtencin es corto, es decir,
existe una falta de documentacin por adelantado (o la falta de C5), los

requisitos suelen terminar como mejorar- ment o
volverse descoped desde todas las peticiones del cliente no puede ser
entregado [9]. Considerando esto, podemos concluir que
tanto en la especificacin (como en [9]) y por encima de la especificacin

(como en nuestro estudio) puede causar descoping
overscoping y posteriormente, y que queda por ser investigado cmo lograr un

buen equilibrio.
clara visin del objetivo general
(C6). Nuestro estudio indica que una falta de comunicar claramente los
objetivos y estrategia para el desarrollo de software
puede causar definir el alcance del proyecto, principalmente desde la

perspectiva de la tecnologa, en lugar de con un enfoque
empresarial, contribuyendo as a overscoping. En general esta causa fue

clasificado como el segundo mayor impacto en
overscoping, a pesar de un cuestionario nico demandado (RT) lder en

desacuerdo- ing a esta causa. Nuestros resultados apoyan
las conclusiones de documentos relacionados [4,18,20,40,49,61] que subrayan

la importancia de los requisitos de seleccin
alineadas con los objetivos generales del negocio y dis- cardado otros tan
pronto como sea posible. Adems, el fracaso de las
partes interesadas que concurren en el cumplimiento de los objetivos del

proyecto fue encontrado por DeMarco y Lister
constituyendo el mayor riesgo para un proyecto [20]. Un mtodo de triage

primeros requisitos basados en las estrategias de
gestin
1120 E. Bjarnason et al. / Informacin y Software de Tecnologa 54 (2012)

1107-1124
fue propuesto por Khurum et al.
[40]. Wohlin Aurum y han propuesto un marco de requisitos de alineacin con

los objetivos de negocio [4]. Rosca et al.
mencionan que la caracterstica ms exigentes de negocios es la probabilidad

de cambio que no pueden ser totalmente
controlados [61]. Esto puede ser administrado cuando los objetivos

empresariales son claros para los desarrolladores de
software, lo que les permite gestionar un sistema que requiera modificaciones

mientras se cumplen- cin de los objetivos de
negocio [18]. Por ltimo, Karlsson et al. [38] mencionaron la falta de objetivos y
visiones comunes como un desafo para
lograr una buena cooperacin, citando su respuesta: "Si todo el mundo tiene la
misma meta y visin, entonces todo el mundo
trabaja en la direccin correcta." proceso de dbil adherencia (+C7) y el

alcance y la fecha lmite impuesta por la
administracin (+C8). Estas dos causas se mencionan en los cuestionarios,

aunque ninguno de ellos era visto como teniendo una
repercusin importante en overscoping. Karlsson et al. [38] Se encontr que el

escaso cumplimiento de proceso puede ser
causado tanto por el proceso de alta complejidad, as como, la falta de tiempo

para la ejecucin del proceso.
Este ltimo
podra ser una consecuencia de overscoping. La direccin de la relacin causal

entre el proceso y overscoping adherencia
permanece para ser investigados.

7.2. Los efectos de overscoping (RQ2)
Los resultados indican que overscoping puede conducir a
una serie de efectos (o consecuencias), muchos de los cuales se consideran

graves y potencialmente muy costoso para la
empresa. Varias de las identi- zos efectos pueden estar en lnea con creencias
acerca de lo que la sobrecarga de un proyecto
con demasiado trabajo puede provocar. El objetivo de este estudio es investigar

si esas creencias pueden ser apoyadas por la
evidencia emprica o no, y si ms sorprendentes fenmenos surgen en

relacin a un determinado del mundo real situacin
overscoping.
muchos cambios despus de que el proyecto alcance est establecido (E1).
Los resultados muestran que overscoping
conduce a un gran nmero de los cambios de alcance (experimentado por

todos los intervinientes y el impacto clasificados como
crticos o importantes por los seis cuestionario respondedores). Esto confirma

la evidencia proporcionada por Harker y Eason
[30] que las necesidades no son estticas y, por tanto, son difciles de capturar
o clasificar. Adems, la volatilidad de los
requisitos es mencionado como uno de los desafos en la mdre de Karlsson et

al. [38] e identificados por Ramesh et al. como
uno de los 14 supuestos subyacentes de Agile Software Development [57].

Adems, orgenes de exigencias volatilidad han sido
enumeradas [30]. A pesar de esta conciencia, causas de la volatilidad de los

requisitos no han sido explorados empricamente.
Nuestros resultados destacan overscoping como una posible causa de finales

de requerimientos de cambios. Adems, nuestros
resultados confirman que es difcil de gestionar cambios de requisitos.

cuestiones de calidad (E2). Los resultados indican que
se trata de un importante efecto de overscoping (experimentado y acord por

tanto inter- opiniones y cuestionarios, y
clasificado como crtico o de gran impacto). Esto confirma que la calidad de los
requisitos engi- neering determina la calidad
del software, segn se inform, por ejemplo, por Aurum y Wohlin [6]. Adems,
nuestros resultados resaltan ms alcance- como
una posible razn de los problemas de calidad.

retrasos (E3). Este estudio muestra (con un alto grado de paralelismo entre los
entrevistados y las respuestas al cuestionario) que el retraso puede ser un

efecto de overscoping. Dentro MDRE, retrasos en el
lanzamiento de productos- cin puede ser muy costoso y provocar la prdida

de cuotas de mercado [38,59,64,65]. Por lo tanto,
la visin que puede tener este efecto overscoping es importante evidencia que
indica que overscoping (potencialmente) es un
grave riesgo.
Las expectativas de los clientes no siempre se cumplen (E4). Nuestros
resultados indican que overscoping pueden
tener el efecto de no cumplir con cus- tomer expectativas. Esto podra

explicarse por una sobrecarga en el proyecto no tener
tiempo o capacidad ni para analizar o implantar

nuevos requisitos ni para validar si el mercado o las necesidades del cliente
podra haber cambiado. Adems, Karlsson y cols. informaron de 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 esencial de
producir productos de software que satisfar a los clientes, como se ha

sealado por Aurum y Wohlin, est trabajando con RE a
lo largo de todo el ciclo de vida del proyecto (en contraposicin a detallar los
requisitos iniciales, C5) [6]. Los resultados
de este estudio ponen de relieve la importancia de seleccionar un mbito viable

como un factor a tener en cuenta a la hora de
intentar entender y captar las necesidades de los clientes.

lagunas de comunicacin (E5). Nuestros resultados indican que
pueden causar aumento overscoping brechas de comunicacin.

(Aproximadamente la mitad de nuestros entrevistados y encuestados
mencionaron y accedi a este efecto.) Esto puede ser explicado por los diezrevisin de tancia para desviar por culpar a
otros cuando estn bajo presin, en lugar de cooperar para resolver problemas
juntos. Adems, inter- viewees descrito en que
muchos de los cambios resultantes de la sobre-especificacin (E1) fueron mal

comunicadas a la unidad de producto y se tradujo
en informes de error falso se archiven en cambiar, pero no se han actualizado

los requisitos. Esto, a su vez, provoc
irritacin entre los equipos de desarrollo y aument ms la comunicacin

lagunas. Asimismo, Karlsson y cols. informaron de que
la constante afluencia de requisitos (causa C1) decisin provoc conflictos

entre las funciones de marketing y desarrollo
[38]. El
desafo para mantener actualizado el SRS (E6). La mayora de las responsabilites confirm que overscoping aumenta el
desafo de mantener actualizado el SRS. Cuando el SRS es detallada por

adelantado (C5), la combinacin de las dos
(overscoping) efectos E1 (muchos cambios de alcance) y E1b (disminucin de

la motivacin) conducen a un aumento de la
necesidad, pero una menor motivacin para actualizar los Srs. Esto
complementa el trabajo anterior, que los requisitos de
informes volatilidad como un desafo comn para proyectos de software

[30,32,34,70] y que el punto de vista de RE como sobre
un conjunto esttico de exigencias es inapropiado [29,30]. Adems, Berry et

al. informan que el tiempo y los recursos nunca
son suficientes para mantener la documentacin actualizada y que scope creep

ocurre cuando el programa- mers cdigo mientras
la documentacin sigue cambiando [9].

Adems, nuestro estudio pone de relieve que el reto de mantener actualizado
el SRS es
aumentado por un efecto de overscoping. Harker y Eason propuestas para

abordar este reto mediante la definicin de un mnimo
min- Especificacin crtica junto con entregar incremental- ies (p. ej. +P6) y, por
lo tanto, gradualmente, proporcionando ms
valor [30].
Se necesita ms investigacin para investigar si los mtodos pro- plantean para
afrontar el reto de la
actualizacin de los requisitos de documentacin tambin puede minimizar este

efecto para overscoping.
Horas extraordinarias
(+E7), modificado o cancelado planes de productos (+E8), la baja prioridad

para las tareas administrativas (+E9). Estos
efectos fueron mencionados en la validacin de cuestionarios y cada uno tiene

un recuento de impacto crtico. Se necesitan ms
investigaciones para validar su relacin con overscoping.

7.3. Cmo volver prcticas giles pueden afectar overscoping (RQ3)
Nuestro estudio indica que tres de las prcticas giles de RE est introduciendo
en el caso de empresa pueden afectar varias
de las causas y races de overscoping. Adems, tres ms prcticas fueron

sugeridas por los encuestados como abordar sobre la
especificacin. Los detalles de cmo identificar prcticas giles pueden afectar

overscoping RE (mencionadas causas puede
verse en la Fig. 2) se examinan a continuacin. Interpretamos los resultados

como una indicacin de que overscoping sigue
siendo un reto para el caso de empresa, aunque ms manejable con el

(parcialmente) RE prcticas giles. De- sarrollo
investigaciones son necesarias para entender completamente la situacin en el

contexto gil.
E. Bjarnason et al. / Informacin
y Software de Tecnologa 54 (2012) 1107-1124

un continuo alcance y planificacin del release de flujo (P1) es experiencia-
sufrido por los encuestados para impactar directamente la causa C2 (no a

travs de la disponibilidad de recursos de software)
al permitir la transparencia y perspectiva en todo el mbito del proyecto y en la

carga de trabajo actual de la unidad de
software. La mayor visibil- lidad de la carga y la capacidad disponible de

recursos tanto de la empresa como unidad de
software puede salvar varias lagunas de comunicacin identificado como causa

de overscoping, es decir, RC1c, RC3d y RC4b. Esta
prctica abarca las prcticas giles de re- cos requieren de priorizacin y

constante re-planificacin para los requisitos de
alto nivel [57]. Nuestros resultados confirman los hallazgos de Dingsyr Dyb y
que los gerentes de las empresas giles estn
ms satisfechos con la forma en que planean sus proyectos que estn basados
en el plan com- empresas [21]. Adems, nuestro
estudio tambin corrobora el hallazgo- turas que gil del alcance de priorizacin
en combinacin con un stage-gate modelo en
el nivel de funcin puede evitar retrasar las caractersticas crticas y tambin

proporciona una informacin temprana sobre
caractersticas [36]. Sin embargo, lograr corregir alto nivel de estimacin de

costos y cronograma ha sido identificado como
un reto tambin para el proyecto Agile [57], que puede ser una razn por la cual
overscoping sigue siendo un problema para el
caso de empresa.
Los equipos de desarrollo de funciones cruzadas (P2) estn indicados por
nuestros resultados como mejorar
varias de las brechas de comunicacin identi- zos por nuestro estudio como
causas importantes de overscoping (p. ej.
RC1c,
RC2a, RC3D, RC4b, RC6d). Este caso la prctica de la compaa equivale a la

gil re la prctica de preferir cara a cara, la
comunicacin a travs de los requisitos de documentacin escrita [8] en

combinacin con la priorizacin de gil y constante
re-planificacin en los requisitos detallados nivel [57]. En este nivel de

requisitos detallados, estimaciones de costos y
de programacin en una manera gil (permitiendo slo adiciones al eliminar

simultneamente algo menos prioridad) se ha
encontrado para ser eficaz [36,57] y eliminar el problema de los "requisitos

cramming" [36], lo que equivale a overscoping.
Otros estudios han encontrado que la comunicacin dentro de los equipos de

desarrollo se mejora mediante prcticas giles,
pero que la comunicacin con otros equipos (dependientes) sigue siendo un

reto [un 36,53]. Este desafo se dirige con P2
mediante la inclusin de competencia abarca todas las reas funcionales

dentro del mismo equipo (por lo tanto, afectar causas
RCicii, RC2a, RC4b y RC6DII). Adems, el gil RE prctica de incluir un

representante del cliente en los equipos de desarrollo
se resume por Dyb et al.

[21] como mejorar la comunicacin sido cliente y engi- neers, mientras rellena
este papel puede ser
estresante y desafiante [36,57].
Requisitos e iterativo gradual detallando (P3) es visto (Por nuestros

entrevistados) para
reducir el plazo de entrega total para el desarrollo de una caracterstica (causa

raz RC1b), retrasando el detalle de los
requisitos hasta que son realmente necesarios para el diseo y desarrollo. Esto
a su vez reduce la cantidad de cambios de
requisitos dentro del marco de tiempo (ms corto) para la caracterstica el

desarrollo, que en un mercado con requisitos de
alta volatilidad es una mejora significativa. Tambin puede reducir la comunicacin lagunas que ocurren debido al aspecto de
la distribucin se detallan los requisitos antes de que se inicia el diseo y la

implementacin, es decir, causas RC3D, RC4a,
RC4b. El caso de la prctica de la compaa P3 es equivalente a la gil

prctica de re iterativa [57].
7.4. Las amenazas a la
validez y limitaciones
de cada estudio hay limitaciones que deben ser examinados y abordados.
Estas amenazas a la validez y las
medidas adoptadas para mitigarlos se inform aqu sobre la base de las

directrices proporcionadas por Robson para estudios de
diseo flexible [60]. Otro aspecto importante de la calidad de un diseo de

investigacin flexible es el investigador [60],
y para este
1121
estudio todos los investigadores implicados tienen experiencia previa en

conductos con- la investigacin
emprica, tanto entrevista estudios y encuestas.

7.4.1. Descripcin validez interpretaciones [60] de los entrevistados plantea
la amenaza principal a la descripcin validez. Esta amenaza fue dirigida en

varias maneras. Las entrevistas fueron grabadas y
transcritas. Para mejorar la confiabilidad de las transcripciones, la persona que

toma notas durante las entrevistas tambin
transcritas. Adems, esta persona ha trabajado para el caso de empresa por

varios aos y est bien versado en la lengua y la
cultura de la empresa. Adems, la triangulacin de datos fue ap- ganaban a las

transcripciones por otro investigador
independiente realice una transcripcin y codificacin de dos entrevistas

seleccionadas aleatoriamente. Adems, los
entrevistados verificaron tanto la tran- scriptions y los resultados del estudio

para detectar errores y misinterpreta-
ciones. Por ltimo, la triangulacin de datos se aplica a los resultados de la

entrevista por recoger ms de seis puntos de
vista (otros) tioners practi- mediante un cuestionario [60].

7.4.2. Interpretacin la validez de este estudio, la principal
amenaza a la interpretacin vlida ha sido el riesgo de imponer la hiptesis

(formulada en la fase uno) a los entrevistados.
Para hacer frente a esta amenaza, abra las preguntas de la entrevista siempre
fueron planteados antes de plantear preguntas
especficas sobre la base de la hiptesis. Adems, descripciones espontneas

de causas (sin preguntar) han sido reportados
(como los experimentados) separado a partir de las respuestas a las

preguntas complementarias sobre causas especficas
(segn lo acordado), consulte la seccin 5.1 y en la Tabla 3.

Para la fase tres, la amenaza a la descripcin vlida fue
dirigida por los investigadores conjuntamente disear el cuestionario y la

reunin celebrada en conexin con l. Para
garantizar que todos los intervinientes cuestionario correctamente y de manera

uniforme entiende la entrevista resultados, los
resultados fueron presentados a los participantes. Luego podran pedir

aclaraciones antes de rellenar el cuestionario. El
hecho de que el cuestionario respondedores fueron confrontados con un marco

de resultados sigue siendo una amenaza abierta a
la interpretacin de validez.
Por otro lado, ambos entrevistados y cuestionario respon- abolladuras fueron
explcitamente
alent a discrepar y mencionar las operacionales causas, efectos y prcticas,

que tambin lo hizo. Una de las principales
limitaciones del estudio es el nmero limitado de respon- abolladuras. Aunque

los representantes de cada una de las cubiertas
de las unidades de la empresa caso participaron en las entrevistas y el

cuestionario de validacin, el nmero de personas es
relativamente pequea y ms factores pueden ser identificados mediante la

inclusin de nuevos puntos de vista.
7.4.3. Teora
validez la amenaza principal a la teora la validez de este estudio es el riesgo

de la falta de factores adicionales o
alternativos. Una fuente de esta amenaza es el conjunto limitado de

practicantes de cuyos datos han sido gath- bles. Otra
fuente potencial es el riesgo de sesgos de observacin limitar el estudio a los

investigadores pre-conocimiento de la
compaa. Este fue un riesgo principalmente en la primera fase y fue dirigida

por involucrar a los otros investigadores en
debatir y examinar el diseo del estudio y la hiptesis de que la entrevista con

forma de instrumento. El hecho de que una
causa principal adicional (p. ej. C6) fue identificado como resultado de las
entrevistas muestra que este sesgo se ha abordado
con xito.
Sin embargo, la identificacin de los resultados adicionales en la fase 3 de
mayo indicara que la saturacin y la
exploracin completa del problema bajo investigacin an no se ha alcanzado.

Como el objetivo de este trabajo es explor- atory
nuestro objetivo no es presentar o lograr una cobertura completa del problema

bajo investigacin.
La participacin de los
investigadores con experiencia de trabajo en el caso de empresa ha

desempeado un papel vital en el estudio. Esto ha en- sured
que el problema investigado es autntico y que los resultados son derivados

aunque una interpretacin de los datos sobre la
base de un profundo conocimiento del caso y su contexto. Sin embargo, la re-
1122 E. Bjarnason et al. / Informacin y Software
de Tecnologa 54 (2012) 1107-1124

Resultados se limitan al caso de empresa y existe el riesgo de que otras
posibles causas de
overscoping experimentado en otras compaas no fueron identificados. Esto

tambin se aplica al conjunto de prcticas giles
de RE, que se limitan a las que se conoce actualmente y parcialmente en el

caso de la empresa en el momento del estudio.
Generalizabilidad interna fue dirigida por muestreo de los entrevistados y
encuestados desde distintas partes de la empresa
lo Seleccin de roles y responsabilidades inherentes a travs del ciclo de vida

de desarrollo. Aun as, no fue posible incluir
a representantes de ventas y marketing (que no estaban disponibles en el

momento del estudio). No obstante, los requisitos los
lderes del equipo suministr alguna informacin sobre estos aspectos, sobre la
base de su experiencia de los contactos con
los clientes y con el departamento de ventas y marketing.

Considerando generalizabilidad externo, los resultados deberan ser
inter- preted con el caso de la empresa en el contexto de la mente. La validez

externa se aborda mediante la generalizacin
analtica que permite extraer conclusiones sin anlisis estadstico y, bajo ciertas
condi- ciones, relativas tambin a otros
casos [60,62]. Dentro del alcance de este papel, se argumenta la

generalizacin analtica mediante la aplicacin de la
formulacin de una estrategia de caso ([60], pg. 107) por trabajos

relacionados con el anlisis y la presentacin de informes
las similitudes, diferencias y desacuerdos con nuestros resultados (vase la

seccin 7). Este anlisis genera un argumento de
apoyo hacia la validez externa de nuestro estudio buscando datos que no se

confirma una pre-asumi la teora. Adems, los
estudios de seguimiento realizados en otros dominios pueden llevarse a cabo

para utilizar la estrategia de demostracin
directa ([60]) para seguir haciendo frente a la amenaza a la validez externa.

8. Conclusiones y trabajar ms la
toma de
decisiones est en el centro de ingeniera de requisitos (RE) [5] y en el marco

de mercado impulsadas por ingeniera de
requisitos (MDRE) soltar la planificacin es uno de los ms importantes retos y

tareas lenging [38,39,59,65]. Las decisiones
sobre cmo desarrollar y cuando, estn intrnsecamente relacionadas con la

consecucin de satisfac- cin del cliente. Aunque
la planificacin del release [37,39,59] est bien investigado, vuelva la toma de

decisiones es reconocido como desafiante
[2,5,50] y alcance creep es clasificado como un proyecto serio riesgo

[16,17,31], otros aspectos de la negociacin gestin
han sido menos explorada [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 diferenciada, o uno

de una serie de lanzamientos [50]. Nuestro
trabajo anterior inform que en un contexto MDRE de alcance es una actividad

continua que puede durar durante todo el ciclo de
vida del proyecto [71]. Si no se gestiona correctamente, y ms requisitos estn

incluidos en el alcance del proyecto que
pueden ser manejadas con los recursos disponibles, el resultado es

overscoping, es decir,
el proyecto "muerde ms de lo que
puede masticar".
Nuestro estudio proporciona una imagen detallada de los factores que
intervienen en la overscoping y confirma
que la especificacin es un reto de ingeniera de requisitos y uno de los riesgos

en el proyecto administracin [13,20,43].
Nuestros resultados indican que overscoping es causada principalmente por el

rpido movimiento de dominio impulsado por el
mercado en el que la compaa opera, caso y cmo esta afluencia de requisitos

es administrado. En las primeras fases del
proyecto, la escasa participacin en el desarrollo de cerca de papeles en

combinacin con dbil conciencia de objetivos
globales pueden resultar en un proyecto de gran alcance poco realista.

Nuestro estudio indica que overscoping puede conducir a
una serie de efectos neg- adores, incluidas las cuestiones de calidad, las
demoras y la falta de cumplimiento de las
expectativas del cliente. Los retrasos y problemas de calidad son caros, no slo
considerando el costo de arreglar los
problemas de calidad, sino tambin en la prdida de cuotas de mercado y el

valor de la marca [59]. Adems, hemos encontrado
indicios de que una situacin de overscoping puede incluso causar ms

overscoping, es decir, una organizacin puede acabar en
un crculo vicioso cuando overscoping une los recursos de desarrollo que luego
no estn disponibles para participar en fases
iniciales del proyecto. Adems,

overscoping conduce a un aumento de las interrupciones de la comunicacin,
que a su vez son
causas de overscoping.
Empresas, como nuestro caso, empresa que desarrolla el software integrado
para un dominio empresarial
con una alta presin de mercado necesita una estructura organizativa y el

proceso adecuado para la gestin eficaz de los
cambios frecuentes de una forma rentable. Los proyectos de desarrollo deben

responder rpidamente a los cambios, mientras que
al mismo tiempo han- dling la complejidad del desarrollo de software en un

conjunto de gran escala- ting. Los procesos giles
se aleg estar mejor adaptado para gestionar el cambio de fase. Como un

entrevistado sta- ted: "El mtodo en cascada es buena
preparacin desde una perspectiva, si usted puede pegarse a lo planeado.

Pero, puesto que vivimos en un mundo que cambia
mucho no funciona despus de todo." Nuestro estudio indica que, a pesar de

introducir prcticas giles overscoping RE, es
todava un problema para el caso, aunque la empresa sea ms manejable.

Concluimos que las mejoras pueden explicarse por la gil
RE prcticas continuas de la priorizacin de los objetivos del proyecto, en

combinacin con la realizacin de la estimacin de
costos y cronograma, detallando los requisitos y gradual, en estrecha

colaboracin dentro de los equipos interfuncionales,
cerrando una serie de lagunas de la comunicacin. Sin embargo, prcticas

giles de RE tambin plantean retos [57], por
ejemplo, comunicacin entre equipos [un 36,53], dificultad en el costo estimacin [57]. Esto, en combinacin con un rpido
movimiento de mercado, dri- ven el dominio puede explicar porqu overscoping

sigue siendo un reto tambin con el proceso de
desarrollo gil.
Las causas y efectos dio a conocer a travs de este estudio (que se resume en
la Fig. 2) puede ser utilizada
como base para la identificacin de posibles temas a tratar a fin de evitar o

paliar una situacin overscoping.
Por ejemplo, la
causa de la baja competencia en estimaciones de costos puede ser abordado

por la introduccin de tcnicas para mejorar la
estimacin de costos, que debera conducir a ms planes realistas. Por ltimo,

el sup- portado por nuestros hallazgos
potencialmente graves efectos de overscoping, llegamos a la conclusin de que

este fenmeno puede ser un riesgo importante de
exigencias de ingeniera y gestin de proyectos, complementarios al riesgo de

mbito mencionado por arrastre de marco y
Lister [20].
Labor futura incluye la evaluacin de las prcticas giles de nuevo cuando se
hayan aplicado plenamente; cmo
influyen overscoping y qu otros retos que plantean a lo largo del tiempo?

Adems, sera interesante investigar cmo aspectos
tales como las cuestiones de organizacin, desarrollo de software gil (modelo

o una cascada) y la aplicacin de diferentes
mtodos de ingeniera de software afectan a la toma de decisiones. Adems,

extender los resultados de este estudio para
incluir a otras empresas y tambin otras perspectivas, tales como ventas y

marketing, pueden fortalecer la generalizabilidad
de los hallazgos.
Agradecimientos
Queremos agradecer a todos los entrevistados annimos y cuestionario
encuestados por su
inestimable contribucin a este proyecto. Tambin quisiramos agradecer al Dr.

Dietmar Pfahl para revisin- ing una primera
versin de este documento. El proyecto est financiado parcialmente por la

Fundacin Sueca para la Investigacin Estratgica y
VINNOVA (La Agencia Gubernamental Sueca para Sistemas de Innovacin)

con- en la facilidad y UPITER Proyectos.
Referencias
[1] M.
Abramovici, O.C. Sieg, el Estado y las tendencias de desarrollo de sistemas de

gestin del ciclo de vida del producto, la
Ruhr-Universitt Bochum (Alemania), 2002.

[2] B. Alenljung, A. Persson, describiendo la prctica de toma de decisiones en
ingeniera de requisitos: un caso de desarrollo a medida, de gran escala Req.

Eng. 13 (2008) 257-279.
[3] A. Aurum, E. Martin,
gestionando la participacin individual y colectiva en el proceso de obtencin

de requisitos de software, en: 14 Simposio
Internacional sobre Ciencias de la Computacin e Informacin (ISCIS'99),

Kusadasi, Turqua, 1999, pp.
124-131.
E. Bjarnason et
al. / Informacin y Software de Tecnologa 54 (2012) 1107-1124

[4] A. Aurum, C. Wohlin, Requisitos de alineacin con los
objetivos de negocio: un marco para las decisiones de ingeniera de

requerimientos, Taller sobre ingeniera de requerimientos
de apoyo a la toma de decisiones, REDECS'05, 29 de agosto - 2 de septiembre

de 2005, Pars, Francia.
[5] A. Aurum, C. Wohlin,
la naturaleza fundamental de las actividades de ingeniera de requisitos como

un proceso de toma de decisiones, Inf. Softw.
Technol. 45 (2003) 945-954.

[6] A. Aurum, C. Wohlin, Ingeniera de Requisitos: establecer el contexto, en: A.
C. Wohlin Aurum,
(Eds.), la gestin y la Ingeniera de Software Requisitos, Springer-Verlag,

Alemania, 2005, pgs. 1-15.
[7] K. Beck, Extreme
Programming explic, Addison-Wesley, 1999.

[8] K. Beck et al., el Agile manifesto. <http://agilemanifesto.org/>Accede (junio
de
2011).
[9] D.M. Berry, K. Czarnecki, M. Antkiewicz, M. AbdElRazik, determinacin de
requisitos es imparable: un relato de
experiencia, en: Actas de la 18 Conferencia Internacional de Ingeniera de

Requisitos de IEEE, el IEEE Computer Society,
2010, pg. 311.

[10] E. Bjarnason, K. Wnuk, B. Regnell, un estudio de caso sobre los beneficios
y efectos secundarios de
prcticas giles en gran escala de ingeniera de requerimientos, en: Actas del

1er Taller sobre Ingeniera de Requerimientos
gil (AREW '11), ACM, Nueva York, NY, EE.UU., 2011.

[11] E. Bjarnason, K. Wnuk, B. Regnell. Overscoping: causas y
consecuencias: un estudio de caso en la toma de decisiones en la

administracin de productos de software, en:
Actas del 4
Seminario Internacional sobre Administracin de Productos de Software, IEEE

Computer Society, en septiembre de 2010, pgs. 30
-39.
[12] E. Bjarnason, K. Wnuk, B. Regnell, requisitos se desliza a travs de las

brechas - un caso de estudio sobre las
causas y efectos de las interrupciones de la comunicacin en el desarrollo de

software a gran escala, en: 19 Conferencia
internacional IEEE de Ingeniera de Requisitos, IEEE Computer Society, 2011,

pgs. 37-46.
[13] B. Boehm, Tutorial: Software de
gestin de riesgos, IEEE Computer Society Press, 1989.

[14] P. Carlshamre, K. Sandahl, M. Lindvall, B. Regnell, J. Dag Och
Natt, un estudio de las necesidades industriales interdependencias en el

planeamiento de la versin del producto de software,
en: Actas del Quinto Simposio Internacional del IEEE sobre Ingeniera de
Requisitos, IEEE Computer Society, de agosto de 2001,
en Toronto, Canad, pgs. 84-91.

[15] P. Carlshamre, una perspectiva de uso en Ingeniera de Requerimientos Desde la
metodologa para el desarrollo de productos, la Tesis Doctoral, La Universidad

de Linkping, Suecia, 2002.
[16] de la R.A.
Carter, A.I. ANTON, A. Dagnino, L. Williams, evolucionando ms all de los

requisitos fluencia: una basada en el riesgo, en el
modelo de prototipos evolutivos:

Actas del Quinto Simposio Internacional del IEEE sobre Ingeniera de
Requisitos, de Toronto,
Canad, en agosto de 2001, la IEEE Computer Society Press, pgs.

84-101.
[17] N. Crockford, una introduccin a la gestin del
riesgo, segunda ed., Woodhead- Faulkner, Cambridge, Reino Unido, 1980, pg.
18.
[18] A. A. Cusumano, R.W. Selby, Microsoft
secretos, Simon and Schuster, Nueva York, 1995.

[19] J.M. DeBaud, K. Schmid, un enfoque sistemtico para derivar el alcance
de
lneas de producto de software, en: Actas de la 21 Conferencia Internacional

sobre Ingeniera de Software, ACM, Los Angeles,
USA, 1999, pgs. 34-43.

[20] T. DeMarco, T. Lister, manejo del riesgo en los requisitos, IEEE Software 20
(2003) 99-101.
[21] T.
Dyb, T. Dingsyr, estudios empricos del desarrollo gil de software: una

revisin sistemtica, Inf. Softw. Technol. 50
(2008) 833-859.
[22] C. Ebert, J. De hombre, E-R&D - proceso de gestin eficaz de la
diversidad, Ann. Softw.
Eng. 14 (2002)
73-91.
[23] K. El Emam, N.H. Madhavji, un estudio de campo de las necesidades
prcticas de ingeniera en el desarrollo de
sistemas de informacin, en: Actas del Segundo Simposio Internacional del

IEEE sobre Ingeniera de Requisitos, IEEE Computer
Society, en Washington, DC, USA, 1995, pgs. 68-80.

[24] S.R. Faulk, especificacin de requisitos de lnea de producto (PRS):
un planteamiento y un caso de estudio, en: Actas del Quinto Simposio

Internacional del IEEE sobre Ingeniera de Requisitos,
IEEE Computer Society, en Washington, DC, USA, 2001, pgs. 48-55.

[25] S. Fricker, T. Gorschek, P. Myllyperki, intercambio
entre proyectos de software y partes interesadas mediante propuestas de

aplicacin, en: Actas de la Conferencia Internacional
de Trabajo en Ingeniera de Requisitos: la Fundacin para la Calidad del

Software, Trondheim, Noruega, 2007, vol. 4542 de
apuntes en Ciencias de la Computacin, Springer Berlin / Heidelberg, 2007, pp.

144-159.
[26] A. Gemmer, gestin de riesgos ms
all de proceso, Equipo 30 (1997), 33-43.

doi:http://dx.doi.org/10.1109/2.589908 Http://dx.doi.org/10.1109/ 2.589908.
[27] M.
Glinz, S. Berner, S. Joos, Modelado orientado a objetos con adora, informar.

Syst. 27 (2002) 425-444.
[28] T. Gorschek, C.
Wohlin, requisitos modelo de abstraccin, Req. Eng. 11 (2005) 79-101.

[29] T. Hall, S. A. Beecham, Rainer, requisitos problemas
en doce empresas de software: un anlisis emprico, Software IEEE 149 (2002)

153-160.
[30] S.D.P. Harker, K.D. Eason, el cambio
y la evolucin de los requisitos como desafo a la prctica de la ingeniera de

software, en: Actas del Simposio Internacional
del IEEE sobre Ingeniera de Requisitos, San Diego, CA, USA, 1993, pp. 266292.
[31] C.L. Iacovou, A.S. Dexter Runaway,
revirtiendo los proyectos de tecnologa de la informacin, IEEE Eng.

Administrar. Rev. 3 (2004) 97-112.
[32] C. el cap, S.
Wiedemann, S. Fichtinger, U. Pautz, Change Management Interface, en: Gestin de los requisitos de la interfaz entre las
necesidades de
desarrollo de 1123 y todos los dems sistemas de ingeniera de procesos,

Springer-Verlag, Berln, Heidelberg,
2008, pp. 175-191.

[33] M. Jorgensen, M. Shepperd, una revisin sistemtica de estudios de
estimacin de coste de desarrollo de
software, IEEE Trans. Softw. Eng. 33 (2007) 33-53.

[34] P. Jnsson, M. Lindvall, anlisis de impacto, en: A. C. Wohlin Aurum,
(Eds.), la gestin y la Ingeniera de Software Requisitos, Springer-Verlag,

Alemania, 2005, pp. 117-142.
[35] J. Kabbedijk, S.
Brinkkemper, S. Jansen, S.B. van der Veldt, la participacin del cliente en la

administracin de requisitos: lecciones de
mercado masivo, desarrollo de software en: Actas de la 17 Conferencia

internacional IEEE de Ingeniera de Requisitos,
Atlanta, GA, EE.UU., septiembre 2009, pp. 281-286.

[36] D. Karlstrm, P. Runeson, combinando mtodos giles con stage-gate
project management, IEEE suave. 22 (2005) 43-49.

[37] J. KARLSSON, K. Ryan, un enfoque costo-valor para priorizar los
requisitos Software IEEE, 14 (1997) 67-74.

[38] L. Karlsson, .G. Dahlstedt, J. Dag Och Natt, B. Regnell, A. Persson,
Ingeniera de Requisitos desafos en mercado impulsadas por el desarrollo de

software - estudio de una entrevista con los
practicantes, Inf. Softw. Technol. 49 (2007) 588-604.

[39] L. Karlsson, T. Thelin, B. Regnell, P. Berander, C. Wohlin,
comparaciones de pares versus Juego de planificacin particionarexperimentos sobre las necesidades tcnicas de priorizacin,
emprico de softw. Eng. 12 (2007) 3-33.

[40] M. Khurum, K. Aslam, T. Gorschek, un mtodo de primeros requisitos de
clasificacin y seleccin utilizando las estrategias de producto, en: Actas de la

14 Asia-Pacfico Conferencia de Ingeniera
de Software, IEEE Computer Society, en Washington, DC, EE.UU., 2007, pp.

97-104.
[41] S. Konrad, M. Gall, ingeniera de
requerimientos en el desarrollo de sistemas de gran escala, en: Actas de la 16

Conferencia internacional IEEE de Ingeniera
de Requisitos, IEEE Computer Society, en Washington, DC, EE.UU., 2008, pp.

217-222.
[42] A. van Lamsweerde, desde los objetivos
del sistema a la arquitectura de software, en: M.

Bernardo, P. Inverardi (Eds.), Mtodos Formales de arquitecturas de software,
Springer, 2003.
[43] I. Legodi, M.L. Barry, los desafos actuales y el estado de la gestin del
riesgo en proyectos de
Enterprise Data Warehouse en Sudfrica, en: Actas de PICMET '10, 18-22 de

julio de 2010, pgs. 1-5.
[44] T.C. Lethbridge, J. A.
Singer, Adelante, cmo los ingenieros de software utilizan documentacin: el

estado de la prctica, IEEE Software (2003) 20 35
39.
[45] Z. Lixin, un mtodo de asignacin de los recursos humanos del proyecto
basado en arquitectura de software y red
social, en: Actas de la 4 Conferencia Internacional sobre comunicaciones

inalmbricas, redes y computacin mvil, de octubre
de 2008, pgs. 1-6.

[46] L. Macaulay, captura de requisitos como una actividad cooperativa, en:
Actas de la primera IEEE
Simposio sobre Ingeniera de Requisitos, USA, 1993, pgs. 174- 181.

[47] N. Medvidovic, P. Grnbacher, A. Egyed, B. Boehm,
modelos de puente a travs del ciclo de vida del software, J. Syst. Softw. 68
(2003) 199-215.
[48] M.D. Myers, D. Avison,
investigacin cualitativa en el campo de los sistemas de informacin, Sage

Publications, USA, 2002.
[49] L. Neumann-Alkier,
pensar globalmente, actuar localmente, no siga la regla en las empresas

multinacionales? En: Actas de la Quinta Conferencia
europea sobre Sistemas de Informacin, 1997, pgs. 541 a 552).

[50] A. Ngo-The, G. Ruhe, apoyo a la toma de decisiones en
ingeniera de requisitos, en: A.

Aurum, C. Wohlin (Eds.), la gestin y la Ingeniera de Software Requisitos,
Springer-Verlag,
Alemania, 2005, pp. 267-286.

[51] B. Nuseibeh, entretejiendo requisitos y arquitecturas, Equipo 34 (2001)
115-117.
[52] J.J.
Phillips, T.W. Bothell, G.L. Snead, el cuadro de mandos de gestin del proyecto:
medicin del xito de las soluciones de
gestin de proyectos, Elsevier, USA, 2002.

[53] M. Pikkarainen, J. Haikara, O. Salo, P. J. Abrahamsson, an as, el impacto
de
prcticas giles sobre la comunicacin en el desarrollo de software, emprico

de softw. Eng.
13 (2008) 303-337.
[54] C. Pohl, G.
Bckle, F.J. van der Linden, la lnea de productos de software de ingeniera:

Fundamentos, principios y tcnicas, Springer-
Verlag, Nueva York, Estados Unidos, 2005.

[55] C. Potts, invent requisitos y imaginado clientes: ingeniera de
requerimientos
de software "off-the-shelf", en: Actas del Segundo Simposio Internacional del

IEEE sobre Ingeniera de Requisitos, IEEE
Computer Society Press, marzo de 1995, pgs. 128-131, doi:

Http://dx.doi.org/10.1109/ ISRE.1995.512553.
[56] Project Management
Institute, una gua al cuerpo de conocimientos de gestin de proyectos

(PMBOK Guide), 2000, Ed., Gestin del alcance del
proyecto. Project Management Institute, cuatro Campus Plaza Boulevard,

Newtown, PA 19073- 3299, EE.UU., 2000 (Captulo 5).
[57]
B. Ramesh, L. Cao, R. Baskerville, prcticas giles de ingeniera de

requerimientos y desafos: un estudio emprico, informar.
Syst. J. 20 (2007) 449-480.

[58] B. Regnell, R. Berntsson-Svensson, K. Wnuk, podemos batir la
complejidad de muy gran escala?,
en ingeniera de requisitos: B. Paech, C. Rolland (Eds.), Actas de la 14

Conferencia Internacional sobre Ingeniera de
Requisitos: la Fundacin para la Calidad del Software (REFSQ '08), vol. 5025
de apuntes en Ciencias de la Computacin,
Springer-Verlag, Berln, Heidelberg, 2008, pp. 123-128.

[59] B. S. Brinkkemper Regnell, impulsada por el mercado, ingeniera de
requisitos para los productos de software, en: A. C. Wohlin Aurum, (Eds.), la

gestin y la Ingeniera de Software Requisitos,
Springer-Verlag, Alemania, 2005, pp. 287-308.
1124 E. Bjarnason et al. / Informacin y Software de Tecnologa 54 (2012)

1107-
1124
[60] C. Robson, investigacin del mundo real, Blackwell Publishing, 2002.
[61] D. Rosca, S. GreenSpan, M. Feblowitz, C.
Wild, una metodologa de toma de decisiones en apoyo de las reglas de

negocio, ciclo de vida en: Actas del Tercer Simposio
Internacional del IEEE sobre ingeniera de requerimientos, en Annapolis, MD,

EE.UU., enero de 1997, pgs. 236-246.
[62] P.
Runeson, A. Rainer, M. Hst, B. Regnell, Estudio de caso la investigacin en

Ingeniera del Software: directrices y ejemplos,
Wiley, 2012.
[63] R. Sangwan, M. Bass, N. Mullick, D.J. Kazmeier Paulish, J., Manual de
Desarrollo de Software Global,
Publicaciones Auerbacj, Boston, MA, USA, 2006.

[64] P. Sawyer, software empaquetado: desafos para volver, en: Actas del 6
Seminario Internacional sobre Ingeniera de Requisitos: la Fundacin para la

Calidad del Software (REFSQ'2000), Estocolmo,
junio de 2000.
[65] P. Sawyer, I. G. Kotonya Sommerville, impulsada por el mercado, la mejora
de los procesos, en re: Actas de
la Conferencia Internacional sobre la mejora de procesos software ProductFocused, Oulu, Finlandia, en junio de 1999, pgs.
222-236.
[66] K. Schmid, una completa lnea de productos enfoque de alcance y su
validacin, en: Actas de la 24 Conferencia
Internacional sobre Ingeniera de Software, IEEE Computer Society, Orlando,

Estados Unidos, del 19 al 25 de mayo de 2002,
pgs. 593-603.
[67] K. Schwaber, M. Beedle, Desarrollo gil de Software con SCRUM, Prentice
Hall, 2002.
[68] M. Svahnberg, T.
Gorschek, R. Feldt, R. Torkar, S. Bin Saleem, M.U. Shafique, una revisin

sistemtica sobre la liberacin de modelos de
planificacin estratgica, Inf. Softw. Technol. 52 (2010) 237-248.

[69] El Material de Estudio de Casos (instrumento de
entrevista, cuestionario, etc.) para el antes y el despus (BNA) estudio.

<http://serg.cs.lth.se/research/experiment_packages/
bna/>.
[70] K.E. Wiegers, requisitos de software, segunda edicin, Microsoft Press,
Redmond, 2003.
[71] K. Wnuk, B. Regnell, L.
Karlsson, lo sucedido a nuestras caractersticas? Visualizacin y cambio en el

alcance de la comprensin de la dinmica en un
entorno industrial en gran escala, en: Actas de la 17 Conferencia internacional

IEEE de Ingeniera de Requisitos, IEEE
Computer Society Press, en septiembre de 2009, Atlanta, GA, EE.UU., pp. 8998, doi: http://dx.doi.org/10.1109/RE.2009.32.
[72]
I. van de Weerd, S. R. Brinkkemper Versendaal Nieuwenhuis, J., L. Bijlsma,

hacia un marco de referencia para la administracin
de productos de software, ingeniera de requisitos, en: 14 Conferencia Interna

del IEEE, Septiembre 2006, pp. 319-322.
[73] C.
Wohlin, A. Aurum. Lo que es importante a la hora de decidir incluir un requisito

de software en un proyecto o liberacin?, en:
4 Simposio sobre emprico, Ingeniera de Software, 17-18 de noviembre de

2005, doi: Http://dx.doi.org/10.1109/
ISESE.2005.1541833.

Estás Mordiendo Más de Lo Que Puedes Hacer

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estás Mordiendo Más de Lo Que Puedes Hacer

Cargado por

Copyright:

Formatos disponibles

ests mordiendo ms de lo que puedes hacer?

Un estudio de caso sobre las

software a gran escala

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

para liberar productos de software exitosos al mercado. En un caso impulsado

declaraciones son conocidos a priori el riesgo de overscoping puede aumentar.

Objetivo: en este documento se informa sobre los resultados de un estudio

mercado, los proyectos de desarrollo de software, y cmo las prcticas de

entrevistas semiestructuradas con nueve profesionales en una gran empresa

Resultados: Los resultados proporcionan un cuadro detallado de overscoping

causas y efectos, e indican que el overscoping es causado principalmente por

dirigido por el mercado y cmo este cambio constante de los requisitos es

generales, en combinacin con una baja participacin en el desarrollo en las

potencialmente graves y costosas, incluidas las cuestiones de calidad, los

los clientes. Finalmente, el estudio indica que el overscoping ocurre tambin

requisitos giles, aunque la sobrecarga es ms manejable y se percibe como

aplicar una priorizacin de alcance continuo, en combinacin con los requisitos

cooperacin dentro de los equipos interfuncionales.

Conclusin: Los resultados proporcionan una mayor comprensin del alcance

un anlisis de las causas, efectos y una discusin sobre el posible impacto de

giles a la cuestin de overscoping. Los resultados presentados en este

potenciales a abordar con el fin de lograr un alcance de proyecto ms realista.

Maximizar el valor de negocio para un producto y un conjunto de recursos

seleccionar caractersticas de acuerdo con el mayor retorno de la inversin. Sin

ingeniera de requisitos (MDRE) [38, 59] los gerentes de productos de software

caprichosa situacin del mercado [19] y por la evolucin de las tecnologas. En

que deben incluirse en la siguiente versin de un producto de software

[56]) es una tarea compleja y continua de evaluar y reevaluar cmo afectan

lnea de productos de software [54] en la que se construyen esos productos

la lnea de productos de alcance [66], que deriva el valor de las oportunidades

productos. Estos factores, combinados con el aumento de la competencia en el

los nuevos productos, obligan a los encargados de tomar decisiones a

las decisiones en un mundo en constante evolucin [5].

significativamente durante todo el ciclo de vida del proyecto. Estos cambios se

decir, establecer un mbito que requiere

Los procesos de desarrollo giles pretenden abordar algunos de los problemas

cambian con frecuencia.

recursos disponibles es administrado por la priorizacin extrema y constante

el tiempo boxeo de iteraciones del desarrollo individual. Sin embargo, la

han encontrado prcticas que plantean nuevos desafos, por ejemplo, en el

mltiples partes interesadas y en la creacin de planes de proyecto precisa

intervienen en la overscoping y destacar as este riesgo y tomar un paso hacia

mbito? (RQ2) Cules son los efectos resultantes de overscoping? Y (RQ3)

efectos de impacto de overscoping? El estudio se ha realizado en un gran

software que ha comenzado a cambiar a- bajo la tutela de una manera ms gil

nueve profesionales que trabajan con la ingeniera de requisitos, desarrollo de

resultados de la entrevista luego fueron validados a travs de un cuestionario

empresa. La contribucin del trabajo presentado incluye ocho causas

causas y efectos de las nueve principales overscoping.

adoptadas por la empresa caso puede afectar algunas de estas causas y

efectos secundarios de Agile RE prcticas fueron publicadas. Para este

adicionales, las causas y los efectos de overscoping; (2) resultados empricos

profesionales; y (3) los detalles sobre el impacto de las prcticas giles de re

prrrogas fueron alcanzados por un anlisis ulterior de la entrevista completa

trabajo relacionado. La seccin 3 describe el caso compaa, mientras que el

seccin 4. Los resultados se presentan en la seccin 5 de las entrevistas y en

validacin. En la seccin 7, los resultados estn inter- preted y relacionado a

de validez son discutidos. Por ltimo, la Seccin 8 contiene las conclusiones y

algunas de las razones de la sobrecarga de proyectos con alcance han sido

deberse tambin al personal de ventas acordando entregar unre- alistically

programacin implica- ciones [29]. Adems, el alcance que se extiende ms

desarrolladores, es decir, alcance creep, es afirmado por Iaconou y Dexter [31]

de enterprise data warehouse [43]. Adems, es catalogado como uno de los

requerimientos, y es una consecuencia directa de cmo estn reunidos los