Administracion de requerimientos
Páginas: 7 (1603 palabras)
Publicado: 27 de septiembre de 2010
Levantamiento de Requerimientos
Estrategias para la creación de Software de Calidad Norberto Ortigoza Gerente de la Disciplina de Ingeniería de Software Crosshorizons
Contenido I. Objetivo
II. El problema III. La Solución IV. Puntos por recordar
Objetivo
Comprender la necesidad de definir y administrar requerimientos. Analizar los riesgos que se pueden presentar si no se realiza unlevantamiento de requerimientos y conocer buenas prácticas para su administración.
Contenido
I. Objetivo
II. El problema
III. La Solución IV. Puntos por recordar
Una sabia reflexión...
“Un viaje de mil kilómetros comienza con un solo paso.”
Lao Tzu Filósofo Chino (Siglo VI A.C.)
El detalle...
• Si doy el primer paso en la dirección incorrecta... Termino mil kilómetros peorde lo que empecé.
Algunas estadísticas
• 31% de los proyectos son cancelados • 53% de los proyectos se terminan con un costo del 189% de lo presupuestado • 9% son terminados en costo y tiempo (compañías grandes) • 16% son terminados en costo y tiempo (compañías pequeñas)
“Project Impairment Factors” Standish Group
Las 3 primeras razones
Factor Falta de indicaciones por parte del usuarioEspecificaciones de requerimientos incompleta Cambios en especificaciones de requerimientos
“Project
% de Respuestas 12.8% 12.3% 11.8%
Impairment Factors” Standish Group
Contexto
“Existe evidencia contundente de que el reducir errores en los requerimientos es la forma más efectiva para incrementar las posibilidades de terminar un proyecto con calidad dentro del tiempo y costopresupuestados.”
Calculating Your Return on Investment from More Effective Requirements Management Rational Software Corporation 1997
Otros Estudios
“Un ahorro de hasta 100:1 puede ser obtenido de detectar y corregir errores en la fase de análisis de requerimientos”
“Software Requirements– Objects, Functions and States“ Davis, A.
Costo de detectar y corregir un error
Requerimientos, 0.2 Diseño,0.5 Codificación, 1 Pruebas Unitarias, 2 Pruebas Aceptación, 5 Mantenimiento, 20
Fase
0
5
10
15
20
Costo relativo de reparación
"Understanding and Controlling Software Costs“ IEEE Transactions of Software Engineering 1998
Origen de los errores
“Source of errors in an US Air Force project“ IEEE Transactions of Software Engineering 1998
Errores en requerimientos
•Son los tipos de error más comunes • Son los más caros de corregir • Pueden consumir entre el 25% y el 40% del presupuesto del proyecto
Origen de los errores
• Poca o nula participación de los clientes o usuarios antes y durante el proyecto • Como consecuencia se malentienden los requerimientos • No se validan los requerimientos • No se obtiene retroalimentación
Origen de los errores
• Losproyectos por lo regular están muy limitados en tiempo • Esto provoca que la fase para la obtención de requerimientos se omita o sea acortada • Se empieza a codificar el sistema sin tener claro lo que se necesita
Origen de los errores
• Muchos proyectos carecen de un proceso de administración de cambios • Durante el desarrollo se aceptan una gran cantidad de cambios a los requerimientos sinevaluar su impacto o su prioridad
¿Requerimientos completos?
• No es posible obtener requerimientos 100% estables o completamente definidos al inicio del proyecto
Razones
• Cambios en las prioridades del cliente
Las prioridades del cliente cambian durante el desarrollo del sistema como resultado de un cambio en el ambiente de negocio, el surgimiento de nuevos competidores,presentación en un evento, etc.
Razones
• Cambios en la percepción del cliente
Conforme se desarrolla el producto el cliente comprende mejor lo que solicitó.
• Cambios Organizacionales
La organización que pretende emplear el sistema sufre de cambios estructurales o procesos.
Razones
• Cambios en operación el ambiente de
El ambiente donde se instala el producto sufre cambios y por lo tanto...
Estrategias para la creación de Software de Calidad Norberto Ortigoza Gerente de la Disciplina de Ingeniería de Software Crosshorizons
Contenido I. Objetivo
II. El problema III. La Solución IV. Puntos por recordar
Objetivo
Comprender la necesidad de definir y administrar requerimientos. Analizar los riesgos que se pueden presentar si no se realiza unlevantamiento de requerimientos y conocer buenas prácticas para su administración.
Contenido
I. Objetivo
II. El problema
III. La Solución IV. Puntos por recordar
Una sabia reflexión...
“Un viaje de mil kilómetros comienza con un solo paso.”
Lao Tzu Filósofo Chino (Siglo VI A.C.)
El detalle...
• Si doy el primer paso en la dirección incorrecta... Termino mil kilómetros peorde lo que empecé.
Algunas estadísticas
• 31% de los proyectos son cancelados • 53% de los proyectos se terminan con un costo del 189% de lo presupuestado • 9% son terminados en costo y tiempo (compañías grandes) • 16% son terminados en costo y tiempo (compañías pequeñas)
“Project Impairment Factors” Standish Group
Las 3 primeras razones
Factor Falta de indicaciones por parte del usuarioEspecificaciones de requerimientos incompleta Cambios en especificaciones de requerimientos
“Project
% de Respuestas 12.8% 12.3% 11.8%
Impairment Factors” Standish Group
Contexto
“Existe evidencia contundente de que el reducir errores en los requerimientos es la forma más efectiva para incrementar las posibilidades de terminar un proyecto con calidad dentro del tiempo y costopresupuestados.”
Calculating Your Return on Investment from More Effective Requirements Management Rational Software Corporation 1997
Otros Estudios
“Un ahorro de hasta 100:1 puede ser obtenido de detectar y corregir errores en la fase de análisis de requerimientos”
“Software Requirements– Objects, Functions and States“ Davis, A.
Costo de detectar y corregir un error
Requerimientos, 0.2 Diseño,0.5 Codificación, 1 Pruebas Unitarias, 2 Pruebas Aceptación, 5 Mantenimiento, 20
Fase
0
5
10
15
20
Costo relativo de reparación
"Understanding and Controlling Software Costs“ IEEE Transactions of Software Engineering 1998
Origen de los errores
“Source of errors in an US Air Force project“ IEEE Transactions of Software Engineering 1998
Errores en requerimientos
•Son los tipos de error más comunes • Son los más caros de corregir • Pueden consumir entre el 25% y el 40% del presupuesto del proyecto
Origen de los errores
• Poca o nula participación de los clientes o usuarios antes y durante el proyecto • Como consecuencia se malentienden los requerimientos • No se validan los requerimientos • No se obtiene retroalimentación
Origen de los errores
• Losproyectos por lo regular están muy limitados en tiempo • Esto provoca que la fase para la obtención de requerimientos se omita o sea acortada • Se empieza a codificar el sistema sin tener claro lo que se necesita
Origen de los errores
• Muchos proyectos carecen de un proceso de administración de cambios • Durante el desarrollo se aceptan una gran cantidad de cambios a los requerimientos sinevaluar su impacto o su prioridad
¿Requerimientos completos?
• No es posible obtener requerimientos 100% estables o completamente definidos al inicio del proyecto
Razones
• Cambios en las prioridades del cliente
Las prioridades del cliente cambian durante el desarrollo del sistema como resultado de un cambio en el ambiente de negocio, el surgimiento de nuevos competidores,presentación en un evento, etc.
Razones
• Cambios en la percepción del cliente
Conforme se desarrolla el producto el cliente comprende mejor lo que solicitó.
• Cambios Organizacionales
La organización que pretende emplear el sistema sufre de cambios estructurales o procesos.
Razones
• Cambios en operación el ambiente de
El ambiente donde se instala el producto sufre cambios y por lo tanto...
Leer documento completo
Regístrate para leer el documento completo.