Admon requerimientos

ADMINISTRACIÓN DE ADMINISTRACIÓN DE REQUERIMIENTOSREQUERIMIENTOS

Hernán Jiménez & AsociadosDivisió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

CLIENTE

SATISFACCION

REQUISITOS

GESTIÓN POR PROCESOS

INGENIERÍA

GESTIÓN DE PROYECTOS

SOPORTE

CLIENTE

Establecer un entendimiento común entre el cliente y el equipo del proyecto de software acerca de los requerimientos.

PROPÓSITO PROPÓSITO (1)(1)PROPÓSITO PROPÓ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)PROPÓSITOPROPÓSITO (2)(2)

COMPROMISOS COMPROMISOS (1)(1)COMPROMISOS COMPROMISOS (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.

HABILIDADES HABILIDADES (1)(1)HABILIDADES HABILIDADES (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 manejar 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

GERENTEPROYECTO

INTERVENTOR JEFE DLLO

ANALISTA DISEÑADOR DESARROLLAD

1. REQUERIMIENTOS NO TÉCNICOS: Acuerdos, condiciones, y/o términos contractuales

queafectan y determinan las actividades del proyecto

desoftware.

- productos para ser entregados- fechas de entrega

1. REQUERIMIENTOS NO TÉCNICOS: Acuerdos, condiciones, y/o términos contractuales

queafectan y determinan las actividades del proyecto

desoftware.

- productos para ser entregados- fechas de entrega

AsdaxxxxxxxxxxxxxxxxxxXxxxxxxxxxxxxxxxxxxxxxXxxxxdsdsdfdfsdfsfsfsfdsfsFsdgdgjghdfjkghdghduighi

XxxxxxxxxxxxxxxxxxxxxxXxxxxxxxxxxxxxxxxxxxxxXxxxxxxxxxxxxxxxxxxxxxXxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxdfsdfxxxxxxxxxxxxFsfsfsdfsFxxxxxxxxxxxxxxxxsf

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.

3. CRITERIOS DE ACEPTACIÓN:

Que serán usados para validar que los productos satisfacen los requerimientos.

CICLO DEL REQUERIMIENTOCICLO DEL REQUERIMIENTO

LEVANTAMIENTO

REPOSITORIO

CONGELAR

CONTABILIDAD ESTADO

LIBERACION

CAMBIO

ACTIVIDADES ACTIVIDADES (1)(1)ACTIVIDADES ACTIVIDADES (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 Administración de

requerimientosrequerimientos

4.4. RevisiónRevisión

5.5. LiberaciónLiberación

6.6. AuditoriaAuditoria

7.7. Control de cambios Control de cambios

requerimientosrequerimientos

ACTIVIDADESACTIVIDADESACTIVIDADESACTIVIDADES

1. RECOLECCIÓN DE 1. RECOLECCIÓN DE REQUERIMIENTOS REQUERIMIENTOS (1)(1)1. RECOLECCIÓN DE 1. RECOLECCIÓN DE REQUERIMIENTOS REQUERIMIENTOS (1)(1)

EXPECTATIVACASO DE

ACEPTADO?

ANÁLISIS DE FALLAS

VALIDACION

REQUERIMIENTOS

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

ContabilidadAnaliza riesgo

Comerciante

Negocia precio

Captura negocio

Valuación

Agente de

Ventas

<<usa>>

EJEMPLO – Diagrama de Caso de UsoEJEMPLO – 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: ______________________________

ACTIVIDADESACTIVIDADESACTIVIDADESACTIVIDADES1. RECOLECCIÓN DE REQUERIMIENTOS (4)1. RECOLECCIÓN DE REQUERIMIENTOS (4)1. RECOLECCIÓN DE REQUERIMIENTOS (4)1. RECOLECCIÓN DE REQUERIMIENTOS (4)

CRITERIOS ACEPTACION:

PROYECTO: NOMBRE:NUMERO:

ESTACIONES CLIENTE

PRE: ______________________________

OPERACIÓN: ______________________________

POST: ______________________________

SERVER

PRE: ______________________________

OPERACIÓN: ______________________________

POST: ______________________________

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 REQUERIMIENTOVALORES DE INICIO OPERACIÓNVALIDACIONES

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 Y 2. APROBACIÓN Y CONGELAMIENTO CONGELAMIENTO (1)(1)

Los requerimientos deben ser revisados antes de que sean incorporados en el proyecto.

PROPÓSITO:

Identificar requerimientosincompletos y erróneos

LOS REQUERIMIENTOS SON REVISADOS PARADETERMINAR 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 DE 3. ADMINISTRACIÓN DE REQUERIMIENTOS REQUERIMIENTOS (1)(1)

REQUERIMIENTREQUERIMIENTOO

ESTADOESTADO RESPONSABLRESPONSABLEE

FECHAFECHA

PENDIENTEASIGNADOEJECUTADORECHAZADOAPROBADOEN 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ÓN 4. REVISIÓN (1)(1)4. REVISIÓN 4. REVISIÓN (1)(1)

REQUERIMIENTO Y ARQUITECTURAREQUERIMIENTO Y ARQUITECTURAREQUERIMIENTO Y ARQUITECTURAREQUERIMIENTO Y ARQUITECTURA

REQUERIMIENTREQUERIMIENTOO

DESCRIPCIÓNDESCRIPCIÓN

ITEMITEM.EXE.EXE

.DBF.DBF

MANUAL MANUAL USUARIOUSUARIO

4. REVISIÓN 4. REVISIÓN (2)(2)4. REVISIÓN 4. REVISIÓN (2)(2)

REVISIÓNREVISIÓN

VERIFICACIÓNVERIFICACIÓN

VALIDACIÓNVALIDACIÓN

LIQUIDACIÓN FINALLIQUIDACIÓN FINAL

5. LIBERACIÓN 5. LIBERACIÓN (1)(1)5. LIBERACIÓN 5. LIBERACIÓN (1)(1)

El grupo auditor revisa y

audita el ciclo de los requerimientos yasegura suimplementación

6. AUDITORIA 6. AUDITORIA (1)(1)6. AUDITORIA 6. 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 DE 7. CONTROL DE CAMBIOS CAMBIOS (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 delos 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.

MEDIDASMEDIDASMEDIDASMEDIDAS

VERIFICACIONES VERIFICACIONES (1)(1)VERIFICACIONES VERIFICACIONES (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.

VERIFICACIONES VERIFICACIONES (2)(2)VERIFICACIONES VERIFICACIONES (2)(2)

HJ & ASOCHJ & ASOC 3838

TALLER APLICATIVOTALLER APLICATIVO

ESCRIBA LA POLITICA DE GESTION DE ESCRIBA LA POLITICA DE GESTION DE REQUERIMIENTOSREQUERIMIENTOS

DEFINA LAS AUTORIDADES DE GESTION DE DEFINA LAS AUTORIDADES DE GESTION DE REQUERIMIENTOSREQUERIMIENTOS

PREPARE UN EQUIPO PARA ESCRIBIR LOS PREPARE UN EQUIPO PARA ESCRIBIR LOS DOCUMENTOS RELACIONADOSDOCUMENTOS RELACIONADOS

HJ & ASOC 39

DOCUMENTACIÓNDOCUMENTACIÓN

►CARACTERIZACIÓN DE PROCESO CARACTERIZACIÓN DE PROCESO GESTIÓN DE REQUERIMIENTOSGESTIÓN DE REQUERIMIENTOS

►PROCEDIMIENTO DE GESTIÓN DE PROCEDIMIENTO DE GESTIÓN DE REQUERIMIENTOSREQUERIMIENTOS

►FORMATOS RELACIONADOSFORMATOS RELACIONADOS►DOCUMENTACIÓN TEÓRICA DOCUMENTACIÓN TEÓRICA

RELACIONADARELACIONADA

PP = PROCESOS Y PP = PROCESOS Y PROCEDIMIENTOSPROCEDIMIENTOSPP = PROCESOS Y PP = 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 REQUERIMIENTOSPOLÍ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 HUMANOSINGENIEROS SISTEMAS

USUARIOSGERENTE PRODUCTO

SEGUIMIENTOComité de control de cambios hace

seguimiento a diario

DOCUMENTOS-Procedimiento de administración

de la configuración

PARTES INTERESADASCLIENTE

USUARIOSDESARROLLADORES

RECURSOS FÍSICOSESTACIÓN PC

REDUTILITARIOS

REQUERIMIENTOSA TIEMPO

CARACTERIZACIÓN DEL PROCESO

CRITERIOS SALIDA

- REQUERIMIENTO CERTIFICADO

HJ & ASOC 42

INICIO

AMONESTACIÓN

VALIDA

CONSULTA

HJ & ASOC 43

NUMERO DE NUMERO DE REQUERIMIENTOSREQUERIMIENTOS

REQUERIMIENTOS REQUERIDOS:REQUERIMIENTOS REQUERIDOS:

►CADA ACTIVIDAD CRITICA REQUIERE CADA ACTIVIDAD CRITICA REQUIERE UN REQUERIMIENTO FUNCIONALUN REQUERIMIENTO FUNCIONAL

►CADA MOMENTO DE VERDAD EN CADA MOMENTO DE VERDAD EN PROCESOS DE SERVICIOS REQUIERE PROCESOS 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 AH 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

PROBLEMAS FRECUENTESPROBLEMAS FRECUENTES

UNA DE LAS PRINCIPALES CAUSAS

PARA EL FRACASO DE UN

PROYECTO DE SOFTWARE ES LA

MALA (O AUSENCIA DE)

ADMINISTRACIÓN DE

REQUERIMIENTOS.

HJ & ASOC 50

PROBLEMAS FRECUENTES

NO SON CLARAS LAS REGLAS DEL NEGOCIOLAS REGLAS CON CAMBIANTESNO HAY ESTABILIDAD EN EL NEGOCIOLOS USUARIOS SON CAMBIADOS RÁPIDAMENTE, INCLUSIVE NO SON DE LA EMPRESA CLIENTE, SON PERSONAL EN MISIÓN.

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 & ASOCIADOSMail: hernan.jimenez.barrero@gmail.comTELÉFONO: 313-3210580BOGOTA - COLOMBIA

Admon requerimientos

Documents

Transcript of Admon requerimientos

ADMON. FAMILIAR.pptx

UNIDAD4 ADMON

Gestion admon

Teorías admon.

Admon bas1

ADMON ECLESIAL

admon. publica

Admon Merca

Coaching admon

Proyecto Admon

Presentación de PowerPoint - ESAPconcurso2.esap.edu.co/personeros2020/admon/uploads/...señaladas por el equipo de la ESAP. Requerimientos del Sistema Es responsabilidad exclusiva

Admon RRHH.

EXPOSICION ADMON.

admon tiemp

Fund Admon

Admon categorias

ADMON DESCENTRALIZADA

Admon Produccion

Expo admon

ENFOQUES ADMON