GESTION DE REQUERIMIENTOS

ADMINISTRACIÓN DEADMINISTRACIÓN DE
REQUERIMIENTOSREQUERIMIENTOS
Hernán Jiménez & Asociados
División de Desarrollo Profesional
VERSIÓN 1.29 de Diciembre de 2010

HJ & ASOC 2
TEMARIOTEMARIO
► TEORÍA DEL CMMITEORÍA DEL CMMI
► DOCUMENTACIÓN REQUERIDADOCUMENTACIÓN REQUERIDA

HJ & ASOC 3
CMMI CATEGORIAS DE PROCESOSCMMI CATEGORÍAS DE PROCESOS
D
E
L
C
L
I
E
N
T
E
S
A
T
I
S
F
A
C
C
I
O
N
R
E
Q
U
I
S
I
T
O
S
GESTIÓN POR PROCESOS
INGENIERÍA
GESTIÓN DE PROYECTOS
SOPORTE
D
E
L
C
L
I
E
N
T
E

Establecer un entendimiento
común entre el cliente y el
equipo del proyecto de
software acerca de los
requerimientos.
PROPÓSITOPROPÓSITO (1)(1)

Implica el establecimiento y el mantenimiento de un
acuerdo con el cliente sobre los requerimientos para el
proyecto de software.
El acuerdo forma la base para la estimación, la
planificación, la realización, y el rastreo las actividades
del proyecto de software en todas partes del ciclo de
vida de software.
PROPÓSITOPROPÓSITO (2)(2)

COMPROMISOSCOMPROMISOS (1)(1)
Definir política para llevar a cabo la Administración
de Requerimientos del Software, que incluya:
 Documentar los requerimientos.
 Revisiones a los requerimientos.

HABILIDADESHABILIDADES (1)(1)
Se debe establecer la responsabilidad para:
Analizar y documentar los requerimientos del
sistema.
Asignación en todas partes de la vida del proyecto.
Realización y control de cambios a los
requerimientos.

Se deben asignar los recursos adecuados para
anejar los requerimientos.
Individuos que tengan experiencia
en el dominio de aplicación y en
ingeniería de software.
Herramientas de apoyo.
- programas de hoja de cálculo
- herramientas para admón. config.
- herramientas para trazabilidad
- herramientas para admón. pruebas
GERENTE
PROYECTO
INTERVENTOR JEFE DLLO
ANALISTA DISEÑADOR DESARROLLAD

1. REQUERIMIENTOS NO TÉCNICOS:
Acuerdos, condiciones, y/o términos contractuales que
afectan y determinan las actividades del proyecto de
software.
- productos para ser entregados
- fechas de entrega
Asdaxxxxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxxxxxxxx
Xxxxxdsdsdfdfsdfsfsfsfdsfs
Fsdgdgjghdfjkghdghduighi
Xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxdfsdf
xxxxxxxxxxxxFsfsfsdfs
Fxxxxxxxxxxxxxxxxsf
Pedro perex
Se deben documentar todos los requerimientos.

2. REQUERIMIENTOS TÉCNICOS:
 Hardware
 Software
 Requerimientos de rendimiento
 Transacción requerida
 Funciones de integración
 Lenguaje de programación
 Requerimientos de interfaz

3. CRITERIOS DE
ACEPTACIÓN:
Que serán usados para validar
que los productos satisfacen
los requerimientos.

CICLO DEL REQUERIMIENTO
LEVANTAMIENTO
REPOSITORIO
CONGELAR
CONTABILIDAD
ESTADO
LIBERACION
CAMBIO

ACTIVIDADESACTIVIDADES (1)(1)
1.1. Recolección de requerimientosRecolección de requerimientos
2.2. Aprobación y congelamientoAprobación y congelamiento
3.3. Administración de requerimientosAdministración de requerimientos
4.4. RevisiónRevisión
5.5. LiberaciónLiberación
6.6. AuditoriaAuditoria
7.7. Control de cambios requerimientosControl de cambios requerimientos

ACTIVIDADESACTIVIDADES
1. RECOLECCIÓN DE1. RECOLECCIÓN DE
REQUERIMIENTOSREQUERIMIENTOS (1)(1)
EXPECTATIVA CASO DE
USO
ACEPTADO
?
ANÁLISIS
DE FALLAS
VALIDACION
REQUERIMIENTOS
NO
SI

Los requerimientos son el vínculo coherente y
rastreable que une a todo el ciclo de desarrollo.
Los "casos de uso" son una excelente
forma para capturar los
requerimientos funcionales y asegurar
que éstos sean el punto único de
partida.
Establece límites Actualiza cuentas
Gerente
de
Comercio
Sistema
de
Contabilid
adAnaliza riesgo
Comercia
nte
Negocia precio
Captura negocio
Valuación
Agente de
Ventas
<<usa>>

EJEMPLO – Diagrama de Caso de Uso
Establece límites Actualiza cuentas
Gerente de
Comercio
Sistema de
Contabilidad
Analiza riesgo
Comerciante
Negocia precio
Captura negocio
Valuación
Agente de
Ventas
<<usa>>

Œ
PRE:______________________________
OPERACIÓN: ______________________________
POST:______________________________
1. RECOLECCIÓN DE REQUERIMIENTOS (4)1. RECOLECCIÓN DE REQUERIMIENTOS (4)
CRITERIOS ACEPTACION:
PROYECTO:
NOMBRE:
NUMERO:
ESTACIONES CLIENTE

PRE:______________________________
OPERACIÓN: ______________________________
POST:______________________________
PROYECTO:
NOMBRE:
NUMERO:
SERVER

Los requerimientos deben ser
documentados.
La documentación puede ser tan
simple como un memo o tan elaborado
como un formato elaborado para tal fin.
Los requerimientos ambiguos deben aclararse
completamente antes de continuar el proyecto.

SOFTWARE
PROYECTO: PROGRAMA: NUMERO:
USO POR: NIVEL AUTORIDAD: NIVEL AUTONOMIA:
OBJETIVO DEL REQUERIMIENTO
VALORES DE INICIO OPERACIÓN
VALIDACIONES
ALMACENAMIENTO
BASE DE DATOS: MOTOR: MALLA:
ARCHIVOS PLANOS CD VIDEO:
HARDWARE
SERVIDOR: ESTACION TRABAJO: GETWAY:
RED LOCAL: INTRANET: OTRAS CONEXIONES:

Los requerimientos deben ser revisados
por:
REPRESENTANTES DEL
CLIENTE
GERENTES DE SOFTWARE
OTROS GRUPOS
AFECTADOS.
2. APROBACIÓN Y2. APROBACIÓN Y
CONGELAMIENTOCONGELAMIENTO (1)(1)

Los requerimientos deben ser revisados antes de que
sean incorporados en el proyecto.
PROPÓSITO:
Identificar requerimientos
incompletos y erróneos

LOS REQUERIMIENTOS SON REVISADOS PARA
DETERMINAR SI ELLOS SON:
Factibles y apropiados poner en práctica en el
software
Claros y correctamente indicados (stated)
Compatible con el uno al otro
Que pueden ser probados.

LOS REQUERIMIENTOS DEBEN SER
“MANEJADOS
Y CONTROLADOS”:
 Son identificados, evaluados, medido su riesgo y
documentado, planeados, comunicados y se sigue
semanalmente su estado.
 Que se conoce la versión del producto (control de versión)
 Los cambios son incorporados a una manera controlada
(control de cambio).
3. ADMINISTRACIÓN DE3. ADMINISTRACIÓN DE

REQUERIMIENTREQUERIMIENT
OO
ESTADOESTADO RESPONSABLRESPONSABL
EE
FECHAFECHA
PENDIENTE
ASIGNADO
EJECUTADO
RECHAZADO
APROBADO
EN
DESARROLLO

LEVANTADO ANALIZADO APROBADO CAMBIADO
PROYECTO: FECHA:

SE REVISA LA IMPLEMENTACIÓN DE CADA
REQUERIMIENTO EN LA ARQUITECTURA DEL
PROGRAMA.
Se deja constancia de ello
a cargo del Director del
Proyecto.
4. REVISIÓN4. REVISIÓN (1)(1)

REQUERIMIENTO Y ARQUITECTURAREQUERIMIENTO Y ARQUITECTURA
REQUERIMIENTREQUERIMIENT
OO
DESCRIPCIÓNDESCRIPCIÓN
ITEMITEM
.EXE.EXE
.DBF.DBF
MANUALMANUAL
USUARIOUSUARIO
4. REVISIÓN4. REVISIÓN (2)(2)

 REVISIÓNREVISIÓN
 VERIFICACIÓNVERIFICACIÓN
 VALIDACIÓNVALIDACIÓN
 LIQUIDACIÓN FINALLIQUIDACIÓN FINAL
5. LIBERACIÓN5. LIBERACIÓN (1)(1)

El grupo auditor revisa y
audita el ciclo de los
requerimientos y
asegura su
implementación
6. AUDITORIA6. AUDITORIA (1)(1)

 Los cambios a los requerimientos deben ser revisados
e
incorporados en el proyecto de software.
 El impacto a compromisos existentes es evaluado,
y los cambios son negociados como sea apropiado.
 Cambios a compromisos dentro de la organización
son negociados con los grupos afectados.
7. CONTROL DE7. CONTROL DE
CAMBIOSCAMBIOS (1)(1)

LOS PLANES, PRODUCTOS Y ACTIVIDADES DEBEN
SER CAMBIADOS PARA SER COMPATIBLES CON
CAMBIOS A LOS REQUERIMIENTOS.
Si los requerimientos cambian: Los cambios deben
ser documentados y todos los cambios necesarios
que resulten en otros documentos se les deben hacer
seguimiento y ser verificados.

Los cambios a los planes, productos y actividades
deben ser:
 Identificados,
 Evaluados,
 Evaluado el riesgo,
 Documentados,
 Planificados,
 Comunicados a los grupos afectados,
 Rastreados a la terminación.

Se deben realizar mediciones para determinar el
estado de las actividades de administración de
los requerimientos:
 Estado de cada requerimiento;
 Cambios en la actividad para los requerimientos;
 Número acumulativo de cambios a los requerimientos,
incluyendo número total de cambios propuestos, abierto,
aprobado, e incorporado en la línea base del sistema.
MEDIDASMEDIDAS

VERIFICACIONESVERIFICACIONES (1)(1)
Las actividades de
Administración de
Requerimientos son revisadas
periódicamente y cuando se
presente un evento con:
 El Gerente del Proyecto
 Gerentes Senior
 Grupo SQA

 El propósito de las revisiones periódicas es
proporcionar el conocimiento y la visión en las
actividades de proceso de software a un nivel
apropiado de abstracción y de una manera oportuna.
 El tiempo entre las revisiones debe satisfacer las
necesidades de la organización.
VERIFICACIONESVERIFICACIONES (2)(2)

HJ & ASOCHJ & ASOC 3838
TALLER APLICATIVOTALLER APLICATIVO
 ESCRIBA LA POLITICA DE GESTION DEESCRIBA LA POLITICA DE GESTION DE
 DEFINA LAS AUTORIDADES DE GESTION DEDEFINA LAS AUTORIDADES DE GESTION DE
 PREPARE UN EQUIPO PARA ESCRIBIR LOSPREPARE UN EQUIPO PARA ESCRIBIR LOS
DOCUMENTOS RELACIONADOSDOCUMENTOS RELACIONADOS

HJ & ASOC 39
DOCUMENTACIÓNDOCUMENTACIÓN
►CARACTERIZACIÓN DE PROCESOCARACTERIZACIÓN DE PROCESO
GESTIÓN DE REQUERIMIENTOSGESTIÓN DE REQUERIMIENTOS
►PROCEDIMIENTO DE GESTIÓN DEPROCEDIMIENTO DE GESTIÓN DE
►FORMATOS RELACIONADOSFORMATOS RELACIONADOS
►DOCUMENTACIÓN TEÓRICADOCUMENTACIÓN TEÓRICA
RELACIONADARELACIONADA

PP = PROCESOS YPP = PROCESOS Y
PROCEDIMIENTOSPROCEDIMIENTOS
PP - ADMINISTRACIÓN DE REQUERIMIENTOS
- DIAGRAMA DE PROCESO
- PROCEDIMIENTO DE RECOLECCIÓN DE
REQUERIMIENTOS
- PROCEDIMIENTO DE APROBACIÓN Y
CONGELAMIENTO DE REQUERIMIENTOS
- PROCEDIMIENTO DE CAMBIO DE
REQUERIMIENTOS.
- PROCEDIMIENTO DE DOCUMENTACION DE
REQUERIMIENTOS.

NOMBRE: GESTIÓN REQUERIMIENTOS
POLÍTICA: Todos los requerimientos y los ítems de software deben ser controlados .
FORMACIÓN: Curso de 8 horas, examen calificación y competencia a cargo del Director Técnico.
ENTRADAS
-REQUERIMIENTOS
-CAMBIOS REQUERIMIENTOS
PROCESO
-Recibo requerimientos
-Check out desarrollo
-Codificación
-Pruebas
-Check in
-CHECK OUT CLIENTES
SALIDAS
- REQUERIMIENTOS CONTROLADOS
- ÍTEMS CONTROLADOS
CRITERIOS ENTRADA
- Requerimiento firmado
RECURSOS HUMANOS
INGENIEROS SISTEMAS
USUARIOS
GERENTE PRODUCTO
SEGUIMIENTO
Comité de control de cambios hace
seguimiento a diario
DOCUMENTOS
-Procedimiento de administración
de la configuración
PARTES INTERESADAS
CLIENTE
USUARIOS
DESARROLLADORES
RECURSOS FÍSICOS
ESTACIÓN PC
RED
UTILITARIOS
REQUERIMIENTOS
A TIEMPO
CARACTERIZACIÓN DEL PROCESO
CRITERIOS SALIDA
- REQUERIMIENTO CERTIFICADO

HJ & ASOC 42
OPERA
INICIO
AMONESTACIÓN
FIN
VALIDA
CONSULTA

HJ & ASOC 43
NUMERO DENUMERO DE
REQUERIMIENTOS REQUERIDOS:REQUERIMIENTOS REQUERIDOS:
►CADA ACTIVIDAD CRITICA REQUIERECADA ACTIVIDAD CRITICA REQUIERE
UN REQUERIMIENTO FUNCIONALUN REQUERIMIENTO FUNCIONAL
►CADA MOMENTO DE VERDAD ENCADA MOMENTO DE VERDAD EN
PROCESOS DE SERVICIOS REQUIEREPROCESOS DE SERVICIOS REQUIERE
UN REQUERIMIENTO FUNCIONALUN REQUERIMIENTO FUNCIONAL

PROCESO DOCUMENTADO
SÍMBOLO DE INICIO Y FIN
FORMATO IMPRESO O ELECTRÓNICO
FORMATO MULTIFORMA

ALISTAMIENTO Y PREPARACIÓN
ALMACENAMIENTO EN DISCO DURO
ESPERA
ALMACENAMIENTO SECUENCIAL

DIAGRAMA DE
REQUERIMIENTOS
P H V A
H S E Q

TALLER APLICATIVOTALLER APLICATIVO
 ELABORE LA CARACTERIZACIÓN DEL PROCESOELABORE LA CARACTERIZACIÓN DEL PROCESO
 DEFINA LOS PROCEDIMIENTOS RELACIONADOSDEFINA LOS PROCEDIMIENTOS RELACIONADOS
 DEFINA LOS FORMATOS RELACIONADOSDEFINA LOS FORMATOS RELACIONADOS

UNA DE LAS PRINCIPALES CAUSAS
PARA EL FRACASO DE UN
PROYECTO DE SOFTWARE ES LA
MALA (O AUSENCIA DE)
ADMINISTRACIÓN DE
REQUERIMIENTOS.
PROBLEMAS
FRECUENTES

HJ & ASOC 50
PROBLEMAS FRECUENTES
 NO SON CLARAS LAS
REGLAS DEL NEGOCIO
LAS REGLAS CON
CAMBIANTES
NO HAY ESTABILIDAD EN
EL NEGOCIO
LOS USUARIOS SON
CAMBIADOS
RÁPIDAMENTE, INCLUSIVE
NO SON DE LA EMPRESA
CLIENTE, SON PERSONAL
EN MISIÓN.

PROBLEMAS
FRECUENTES
LOS PRINCIPALES PROBLEMAS DE UN MAL
MANEJO DE REQUERIMIENTOS SON:
 Incapacidad para manejar los cambios en los
requerimientos durante el desarrollo.
 Falta de especificación detallada de los
requerimientos.
 Mala organización y control de requerimientos.
 Requerimientos mal entendidos.

HJ & ASOCIADOS
Mail: hernan.jimenez.barrero@gmail.com
TELÉFONO: 313-3210580
BOGOTA - COLOMBIA

GESTION DE REQUERIMIENTOS

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a GESTION DE REQUERIMIENTOS

Semelhante a GESTION DE REQUERIMIENTOS (20)

Mais de HERNAN JIMENEZ

Mais de HERNAN JIMENEZ (13)

Último

Último (20)

GESTION DE REQUERIMIENTOS