Hacer frente a «Ámbito de aplicación Creep" en proyectos de desarrollo de software

| by Linda Russell | September 17, 2008
Resumen
=======
Ámbito de aplicación desplazamiento es un riesgo importante en proyectos de desarrollo de software. Se discute por qué esto es así, y la manera de evitar o al menos mitigar el riesgo.

¿Cuál es el alcance fluencia?
================
Nuevo software desarrollado por lo general es como consecuencia de un cliente (que puede ser un interno o una organización externa) la identificación de una necesidad. El siguiente paso es especificar la forma en que el software va a satisfacer esa necesidad; específicamente, ¿qué funcionalidad será desarrollado. Este es el "alcance" del proyecto. El proyecto de los planes, sobre la base de las estimaciones para el desarrollo y distribución de la funcionalidad especificada, y una fecha de finalización está de acuerdo.

Desarrollo y comienza el proyecto parece estar progresando a buen ritmo. Pero entonces el cliente se da cuenta de que hay otros requisitos que olvidó mencionar, o más elementos de funcionalidad que necesitan. Often, adding these extras will cause the project duration to be extended, resulting in missed deadlines and increased costs, leading to erosion of margin on the project and potentially customer dissatisfaction and loss of credibility due to late delivery.

Cómo tratar con alcance fluencia
======================
Es importante que exista una especificación funcional se produce al principio, escrito en términos que el cliente pueda entender. Por ejemplo, una caminata a través del proceso que el software de apoyo, tal vez ilustrado con burlado de capturas de pantalla, ayudarán a aclarar la forma en que el nuevo sistema de trabajo de los punto de vista del usuario.

La especificación funcional debe ser convenido y firmado por el cliente, y debe incluir una declaración Ámbito de aplicación. Esto indica que sólo la funcionalidad que es descrito explícitamente en el pliego de condiciones incluidas en el alcance del proyecto, y que todo lo descrito no es "fuera de alcance".

Cuando el cliente posteriormente identifica elementos adicionales, se hace referencia al pliego de condiciones: es la funcionalidad requerida se describe o se refirieron a? Si no es así, entonces el nuevo desarrollo está fuera de alcance.

El siguiente paso es elaborar el impacto del desarrollo de la nueva funcionalidad: ¿qué esfuerzo adicional se requiere? ¿Qué efecto tendrá esto sobre la duración total del proyecto? ¿Qué costos adicionales se haya incurrido y cómo este proyecto afectará a la margen?

Si el impacto es trivial, puede ser acordado incluir la nueva funcionalidad en el actual proyecto, pero idealmente debe ser una declaración por escrito mediante la emisión de una especificación revisada. El peligro aquí es que el cliente cree un precedente que se ha establecido y que nuevas revisiones se hará de una manera similar: es importante comunicar las razones para permitir la revisión en esta instancia.

Es más probable que el desarrollo adicional provocará retrasos y / o costo adicional. El cliente tiene que ser consciente de las implicaciones de la revisión en términos de su impacto en los plazos y costos, y una especificación de las adiciones y los cambios deben ser por escrito (con su propia Declaración de Alcance). Es entonces hasta el cliente para decidir si están dispuestos a pagar más, y si se puede aceptar la fecha de finalización revisada para el proyecto. Si están de acuerdo, la nueva especificación debe firmarse como antes.

¿Realmente necesitamos una Declaración Ámbito de aplicación?
=============================
Usted puede pensar que la escritura de una forma suficientemente detallada para poder hacer la Declaración Ámbito de aplicación supondría más tiempo (y costo) que se justifica por el valor del proyecto en su conjunto. Por ejemplo, si el proyecto en su conjunto se espera que sólo unas pocas semanas y que serán necesarios de 5 días para escribir una especificación detallada, un análisis coste / beneficio demostraría que no vale la pena hacerlo.

Si este es el caso, evaluar la probabilidad de que el riesgo (sobre la base de su conocimiento del cliente y la forma en que está convencido de que todos los requisitos han sido identificados) y el posible impacto, y construir con la suficiente contingencia en sus estimaciones de tiempo y costo para cubrir todos pero la mayoría de las principales revisiones del pliego de condiciones.

Article Source: http://www.articleset.com



About the Author

Linda has a Master's Degree (with Distinction) in Technical Authorship, and over 25 years' experience in software implementation and consultancy. She was a member of the management buy-out team when 4c Systems Ltd was formed in 2002, having worked on the 4c product for 5 years before that.
For information about the 4c product, visit our website at http://www.4csys.com - http://www.4csys.com
» Read more articles by Linda Russell
You are welcome to publish or reprint this article free of charge, provided: