Control de Requisitos

Share

|

El control de los requisitos puede ser el aspecto más importante para lograr el éxito en un proyecto y garantizar la facilidad de uso completo del sistema desarrollado. El control no significa que nunca hay cualquier cambio en los requisitos de línea de base original. Significa que todas las partes interesadas en el proyecto están informados e involucrados en un proceso de control de los requisitos que elimina la mayor amenaza para cualquier proyecto de desarrollo del sistema - Requisitos de reptiles. Requisitos puede arrastrarse y probablemente debería ser considerado como un saboteador villanos que, como un camaleón, tiene en muchos colores diferentes. Este villano se poncha con un solo propósito: hacer que alguien, cualquier persona en el proyecto, para hacer un cambio en los requisitos de línea de base sin evaluar el impacto y la disposición lógica de los cambios e informar a todas las partes de la necesidad del cambio. Para eliminar los requisitos de reptiles:

- Asegúrese de que hay requisitos básicos.

- Disponer de un método de control de cambios en el lugar para manejar cualquier tipo de modificación a los requisitos de línea de base.

- Asegúrese de que todas las personas involucradas en el proyecto, tanto en la parte editorial y en la parte de desarrollo, entender el proceso y los métodos utilizados para requisitos de referencia y de afectar el cambio a los requisitos de línea de base. La base de referencia lista de necesidades es creado a raíz de la reunión de revisión del cliente y debe disponer de un identificador único en ese momento. Se debe distribuir a todos los participantes en la lista de los únicos requisitos para ser utilizado como inicio del trabajo de diseño. El identificador debe contar con disposiciones para indicar la versión o edición o la liberación. Si un cambio aprobado se hace a la lista de necesidades, el identificador debe ser actualizado y revisado los requisitos de la lista a todos los participantes.

Controlar el cambio de los requisitos

Por ejemplo, decir que como el diseño de la interfaz gráfica de usuario (GUI) se pone en marcha, el diseñador se da cuenta de que no hay ningún requisito para la interfaz gráfica de usuario para proporcionar el transporte para el subsistema de consulta, una función que el diseñador piensa que va a ser esencial para el usuario. Utilizando el proceso de control de los requisitos, el diseñador no agrega la función (que arrastran los requisitos). En cambio, el diseñador prepara un incidente / informe de problemas que señala el hecho de que no es un requisito para la interfaz gráfica de usuario para el transporte de consulta y notifica al poseedor de la lista de requisitos, que puede ser el gerente de aseguramiento de la calidad, el director de ingeniería, el director del proyecto , o alguien en la gestión de configuración. La información proporcionada por el diseñador se determina para el impacto del proyecto y se disponga de una de las siguientes maneras:

1. El cambio está aprobado como un componente necesario del esfuerzo de desarrollo del sistema actual. En este caso, el calendario y el presupuesto será evaluado para el impacto. Si el programa se debe mantener, una decisión de gestión se tienen que hacer en relación con la adición de un recurso para hacer la programación, el aumento de horas para uno o varios programadores existentes, o la contratación de ese pedazo de trabajo. Si el presupuesto está ya en esqueleto y el calendario se deben cumplir, entonces el aumento de horas más probable es que se incluirá en el tiempo extra no pagados categoría exenta de los empleados, pero la gestión debe darse cuenta de que están aumentando el riesgo de pro-yecto.

2. El cambio se aprobó una modificación al actual sistema que se aplicará en la primera versión de software posteriores a la entrega inicial del sistema. Una solución temporal puede o no necesitan ser desarrolladas para la implementación inicial. El punto es asegurarse de que existe un acuerdo con el cliente en cuanto a quién va a desarrollar el trabajo en torno a caso de necesidad. El otro punto crítico que se hace aquí es que los registros de control de cambios y el proceso de utilización de los mismos se efectúen de manera que los artículos de este tipo no entran por las grietas como el desarrollo de la próxima versión se pone en marcha.

3. El cambio se aprobó como una mejora potencial de futuro para el sistema actual sin un horario específico para su aplicación. Al igual que el cambio aprobado como una modificación, los registros de control de cambios debe ser preciso para asegurar que la decisión específica de este cambio no se pierde. Debido a que este cambio no será parte de la próxima versión, que se remontan a mi estado de la lista y se llevará a través del proceso de requisitos de todo. La razón de esto es asegurarse de que el desarrollo de este equipamiento está previsto para el trabajo y la entrega en el contexto de todo el trabajo existente.

4. El cambio es rechazado. Esto cierra el informe del incidente. Ningún trabajo está programado ahora o en el futuro. Puede haber muchas razones para este tipo de respuesta. Cualquiera sea la razón, la acción de rechazo y el motivo del rechazo debe ser registrada en el proceso de control de cambios. Un registro de todos los cambios se mantiene cerrada para garantizar la historia exacta del proyecto y de establecer las razones de por qué el cambio fue rechazado.

Cada vez que el software se libera al cliente, la liberación debe seguir un proceso de liberación de gestión definido, que incluye la identificación específica de todos los componentes que se incluyen en la versión de software, así como los componentes que se supone que estar presente (es decir, el sistema de software). Esta identificación debe incluir también el incidente específico / informes de problemas que fueron corregidos por la liberación y cualquier trabajo-arounds que fueron desarrollados por los problemas conocidos que existen en el software.

---