Gestion de proyectos
Páginas: 4 (951 palabras)
Publicado: 30 de octubre de 2010
Captura de Requisitos
La difícil tarea de capturar los requisitos
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
El proceso de averiguar lo que se necesita, “las condiciones/capacidades que el sistemadebería cumplir/satisfacer) Las funcionalidades que debe proporcionar, y los requisitos no funcionales que debería cumplir Todavía en algunos casos se comienza a escribir código, cuando todavía no se haacordado qué debe hacer!!! Los desarrolladores crean código para otros, no serán los usuarios Los usuarios no saben del todo lo que el sistema debería hacer, hasta que está casi hecho Lamentablemente, losusuarios no saben los requisitos al principio, aunque siempre hemos creído que sí. Suele haber demasiados cambios durante el proceso de desarrollo Conforme se avanza se va comprendiendo realmente lasverdaderas necesidades El sistema debe proporcionar valor al negocio, y a los clientes que lo utilizan, por eso es tan difícil, y se producen cambios
(C) Carlos Rossi & Eduardo Medina
2 Cada proyecto es diferente
1. 2.
El sistema a desarrollar, el cliente, la tecnología, los plazos, etc, todo es diferente. Respecto a capturar los requisitos, las situaciones son diferentes:
1.
2.3. 4. 5.
6.
Por ejemplo, comenzamos desarrollando el “modelo de negocio” (esencialmente un diagrama de casos de uso que describe los procesos de la organización) En otros, el modelo de negociopuede ya estar iniciado En otros, el cliente ha elaborado ya una especificación de requisitos O por el contrario, el cliente sólo tiene una idea imprecisa de lo que el sistema debería hacer. Puede queel sistema no dé soporte a un negocio (un videojuegos, un software para un coche, etc), entonces empezamos con un modelo de objetos, como “modelo de dominio” Es una buena idea mantener un glosariopara la compresión del contexto
(C) Carlos Rossi & Eduardo Medina
3
Captura en el Proceso Unificado
1.
Los trabajos y artefactos en el Proceso Unificado, del conjunto de todos los...
La difícil tarea de capturar los requisitos
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
El proceso de averiguar lo que se necesita, “las condiciones/capacidades que el sistemadebería cumplir/satisfacer) Las funcionalidades que debe proporcionar, y los requisitos no funcionales que debería cumplir Todavía en algunos casos se comienza a escribir código, cuando todavía no se haacordado qué debe hacer!!! Los desarrolladores crean código para otros, no serán los usuarios Los usuarios no saben del todo lo que el sistema debería hacer, hasta que está casi hecho Lamentablemente, losusuarios no saben los requisitos al principio, aunque siempre hemos creído que sí. Suele haber demasiados cambios durante el proceso de desarrollo Conforme se avanza se va comprendiendo realmente lasverdaderas necesidades El sistema debe proporcionar valor al negocio, y a los clientes que lo utilizan, por eso es tan difícil, y se producen cambios
(C) Carlos Rossi & Eduardo Medina
2 Cada proyecto es diferente
1. 2.
El sistema a desarrollar, el cliente, la tecnología, los plazos, etc, todo es diferente. Respecto a capturar los requisitos, las situaciones son diferentes:
1.
2.3. 4. 5.
6.
Por ejemplo, comenzamos desarrollando el “modelo de negocio” (esencialmente un diagrama de casos de uso que describe los procesos de la organización) En otros, el modelo de negociopuede ya estar iniciado En otros, el cliente ha elaborado ya una especificación de requisitos O por el contrario, el cliente sólo tiene una idea imprecisa de lo que el sistema debería hacer. Puede queel sistema no dé soporte a un negocio (un videojuegos, un software para un coche, etc), entonces empezamos con un modelo de objetos, como “modelo de dominio” Es una buena idea mantener un glosariopara la compresión del contexto
(C) Carlos Rossi & Eduardo Medina
3
Captura en el Proceso Unificado
1.
Los trabajos y artefactos en el Proceso Unificado, del conjunto de todos los...
Leer documento completo
Regístrate para leer el documento completo.