Sei sulla pagina 1di 105

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 implica- ciones [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 ges- tin 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 pro- blemas


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 administra- cin 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 pro- yecto de riesgos. Los beneficios identificados incluyen la capacidad para


adaptarse a las cambiantes necesidades de

priorizacin, as como una mejor com- prensin 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 exigen- cias 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 soft- ware 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 fun- cionalidad 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 partic- ular, 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


apli- cacin 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 soft- ware 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 exigen- cias 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 soft- ware, 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 exigen- cias

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-

fun- cional 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


pro- ceso 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) prc- ticas 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


pro- ceso y el nuevo proceso de desarrollo gil.

Investigaciones anteriores en nuestro mbito [71] sirvi como base para la


identificacin de la investigacin pre- guntas,

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 inter- pretacin 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 im- pacto 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 posi- bilidad
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 estruc- tura de la entrevista


instrumento, es decir, causas, efectos y gil RE

prc- ticas, 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 prc- ticas 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 dife- rentes 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 entre- vistas 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 vali- dacin 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 sec- cin 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 tes- ter (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 principal- mente
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 pro- duce 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 soft- ware 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 soft- ware 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 infor- macin 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
sec- cin 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 (des- de 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 prc- ticas 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 im- pacto 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 desa- rrollo (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

empre- sa) 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 comuni- cacin 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 pro- ducido 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 comuni- cacin 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 re- lacin 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 especifi- caciones como buena


y positiva, en lugar de un problema. Sin

embargo, estas funciones tienen menos penetracin en las fases posteriores al


de- sarrollo 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 desa- rrollo 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 intere- sadas 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 adher- encia

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

evi- dencia 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 exigen- cias 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 indi- can 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 vola- tilidad 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 exigen- cias 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-planifica- cin 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


desa- rrollo, 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 cali- dad 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) sepa- rado 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 operacio- nales 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 empre- sa

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 aspec- tos 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 ad- ministracin [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 perspec- tiva, 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

exigen- cias 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&amp;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.