GESTIÓN DEL PROYECTO DEL SOFTWARE.pdf

8/19/2019 GESTIÓN DEL PROYECTO DEL SOFTWARE.pdf

1/40


2/40

• La gestión de proyectos busca las técnicasnecesarias para planificar, organizar,supervisar y controlar proyectos de software.

El objetivo de gestionar proyectos es tener unproducto de alta calidad.

- Personal

- Problema- Proceso


3/40

• Personal: atraer, motivar y retener el talentonecesario para mejorar su capacidad de

desarrollo de software.

• Toda organización que alcanza la madurez.

• Tengan un proceso de software maduro.


4/40

• El proceso de software lo componen participantes que puedenclasificarse en cinco categorías:

- Gestores superiores: definen los aspectos de negocios que amenudo tienen una significativa influencia en el proyecto(jefe delequipo humano tenga motivación, organización, ideas o innovación. )

- Gestores técnicos del proyecto: deben planificar, organizar ycontrolar a los profesionales que realizan el trabajo del

software.(entender el problema a resolver, gestionando el flujo deideas. Existen otras características como dotes de gestión, incentivode los logros, espíritu de equipo.)

- Profesionales: proporcionan las capacidades técnicas para laingeniería de un producto

- Clientes: especifica los requisitos para la ingeniería de software.

- Usuarios finales: interaccionan con el software una vez que se haentregado para la producción.


5/40

• El problema: Se establecen los objetivos y se deben considerar solucionesalternativas e identificar las dificultades técnicas y de gestión. Definir unasestimaciones razonables del costo, una valoración efectiva del riesgo, unasubdivisión realista de las tareas del proyecto o una planificación delproyecto asequible que proporcione una indicación fiable del progreso.

• El desarrollador de software y el cliente deben reunirse para definir losobjetivos del proyecto. Los objetivos identifican las metas generales delproyecto sin considerar cómo se conseguirán.

• Se identifican los datos primarios, funciones y comportamientos quecaracterizan el problema. – Busca un análisis detallado de los requisitos del software

– proporcionaría la información necesaria para las estimaciones

– examinar el problema al inicio de proyecto, establecer el problema y delimitándolo.

–

determinar el ámbito del software – determinar el ámbito del software

– define el contexto

– Limitaciones

– objetivo de la información

– datos se obtienen del software

–

función, que realiza el software para transformar la información.


6/40

• Proceso: proporciona la estructura desde laque se puede establecer un detallado planpara el desarrollo del software.

Definición

Desarrollo

Mantenimiento.

El gestor del proyecto decide: El Modelo

Define un plan preliminar Descomposición del proceso.

Maduración del problema

Llevar el control de calidad de dicho proyecto.


7/40

Madurez de una Organización en lagestión de proyectos

• La organización, el control de los recursoshumanos, la comunicación y las relaciones conlos clientes son vitales en la planificación de un

proyecto.

• El crecimiento y éxito de una organizacióndepende del grado de madurez en la gestión de

sus proyectos: – Planes de mejora, procesos de certificación, conocer

sus fortalezas y debilidades, así como realizarbenchmarking en un mercado tan competitivo.


8/40


9/40

– ¿En cuántos proyectos está involucrada suempresa?

– ¿En qué etapa está cada uno de sus proyectos? – ¿Cuántos recursos humanos y equipos tienen

asignados a cada uno de sus proyectos?

• El análisis de la madurez en la gestión deproyectos de una compañía pasa

necesariamente por el tema de los modelosque la miden, muchos de los cuales se derivandel CMI (Capacity Maturity Model).


10/40

Que es el CMMI?

• El Modelo de Capacidad y MadurezIntegrado CMMI (Capability MaturityModel® Integration) es un modelo dereferencia de prácticas maduras usadaspara evaluar y mejorar la capacidad de losprocesos. Es una ruta evolutiva de

implementación de las mejores prácticas enlos procesos organizacionales.


11/40

MADUREZ VS INMADUREZ


12/40

• NIVELES

•

1- Ejecutado- Inicial• 2 - Administrado - Gestionado

• 3 - Definido

• 4 - Administrado - GestionadoCuantitativamente

• 5 - Optimizado


13/40


14/40

Administrado

• Algunas áreas organizacionales y/oproyectos han alcanzado las metasgenéricas y específicas establecidasen sus áreas de proceso, es decir

planean sus procesos, los ejecutan,los miden y los controlan.

• Se han establecido en la organizacióntécnicas básicas de administración de

proyectos y el éxito ya puede serrepetido, dado que los procesos hansido elaborados, establecidos,definidos y documentados.


15/40

Definido

• Tienen los procesos

caracterizados, entendidos porlos ejecutores, descritosmediante estándares,procedimientos, métodos yherramientas.


16/40

Administrado CuantitativamenteNivel de administración o desempeño

estandarizado • La organización selecciona y

administra las actividades quecontribuyen perceptiblemente al

funcionamiento de proceso total.Estas actividades seleccionadas soncontroladas con técnicasestadísticas y otras técnicas

cuantitativas.• La compañía monitorea y controla

sus propios procesos mediante larecolección y análisis de datos.


17/40

Optimizado

• Los procesos de la organización sonmejorados continuamente basadosen una comprensión cuantitativa de

las causas comunes de variacióninherentes a los procesos. El nivel 5está centrado en mejorarcontinuamente el desempeño de los

procesos con mejoras tecnológicasincrementales e innovadoras.


18/40


19/40

Hay que notar que el modelo no establece llegara determinado puntaje para que la compañíasea madura, sino que su madurez óptima laalcanza cuando posee los procesos listos pararecibir la realimentación, al mismo tiempo quese mantiene abierta a las mejoras que promueve

constantemente.


20/40

Componentes del Modelo CMMI

• Áreas de procesos

•

Metas genéricas• Metas específicas

• Prácticas genéricas

• Prácticas específicas y sub prácticas


21/40


22/40

Necesita su Organización CMMI?

• Los planes se hacen, pero no necesariamente se siguen.• No se hace el seguimiento al trabajo real vs el plan. Los planes

no son revisados.• Los requerimientos no son consistentes, los cambios no son

manejados.• Los estimados son muy irreales, su incumplimiento es común.• Cuando no se puede cumplir con los plazos, surge una

atmósfera de crisis.• Los defectos se encuentran en la fase de pruebas, o peor aún

los encuentra el cliente.• El éxito depende de acciones heroicas de individuos

competentes.• La consistencia en la ejecución es cuestionable.


23/40

SITUACION ACTUAL

Una empresa tiene 5 unidades de negocio y cada una cuenta con unaUnidad Desarrolladora de Software (UDS).

Una UDS desarrolla aplicativos corporativos y brinda soporte al 60% de losusuarios de la empresa, y otras 4 desarrolla aplicativos locales y brindaservicio en conjunto al 40% de los usuarios.

• Cada UDS opera independientemente utilizando sus propios estándares, metodologías,practicas, etc.

• Algunos procesos no se realizan o se realizan de diversas maneras aun dentro de cadaUDS.

• No se realizan procesos comunes, menos se realiza una reutilización de procesos dentrode la empresa.

EJEMPLO:


24/40

• Algunas veces se ha hecho el mismo producto bajo variosenfoques y/o plataformas. Debido a los problemas de integración.

• No se predice de antemano el tiempo que demandará la

construcción de un producto.• La documentación de las actividades de desarrollo es muy pobre

lo que origina que el personal desarrollador consuma muchotiempo entendiendo los programas y los procesos.

• La demanda de mantenimiento de aplicativos, así como lasolución de errores grandes toma mucho tiempo por losprogramadores.


25/40

DETERMINACION DEL PROBLEMA

Entre algunos de los que se presentan se encuentran:

•Cada UDS tiene su propia política con relación a los procesosde desarrollo de software.

•El procedimiento de atención de requerimientos no contribuyea una gestión adecuada de los requerimientos.

•

Demasiado esfuerzo en la elaboración de un producto.

•Cada vez que se desarrolla un nuevo producto se tiene querealizar todas las actividades. No hay cultura de re-uso, ni usode experiencias exitosas.


26/40

• Los productos elaborados por una UDS no pueden serutilizados por otra UDS por cuanto los estándares,procedimientos, procesos, hardware y software sondiferentes.

• Las unidades de negocio no tienen una sola visión compartidasobre el desarrollo de software.

• Los tiempos para la construcción de software frecuentementeson mayores que los planeados.


27/40

Justificación

• Es necesaria la implantación del modelo CMMIpara dar solución a los problemas planteados ycomo herramienta que permite disminuir costos

a las Unidades de Negocio y a la organizaciónen general por economías de escala, uniformidadde procesos, facilitar la comunicación yentendimiento entre el personal de las UDS,

reducción del tiempo de desarrollo, reducción deriesgos, ayuda en la estimación del software ysobre todo para aumentar la calidad del software.


28/40

• Ayudará a establecer objetivos y prioridades en mejoras de procesos.

• Ayudará a asegurar procesos estables maduros y con la capacidad requerida.

•

Como guía para mejorar de procesos a nivel de proyecto y de organización.

• Como una metodología de evaluación para diagnosticar el estado de los esfuerzosde mejora.

• Se usará la metodología Identificación, Transformación e Implantación - ITIpara transformar la UDS "1" a los estándares requeridos por el modelo CMMI deuna manera simple y sencilla.

Se utilizará CMMI para:


29/40

IMPLEMENTACION DEL MODELO CMMI

La implementación del modelo de CMMI, consta de dos partes:

*Consultaría Especializada: consiste en realizar el acompañamiento dirigidopor un consultor Senior, durante un tiempo estimado de un año por nivel

de madurez.

*Valoración SCAMPI: consiste en un proceso mediante el cual durante utiempo estimado de tres meses se recoge evidencias para comprobar si laorganización ha alcanzado el nivel de madurez deseado. La valoración es

realizada por una empresa autorizada por el SEI (Software EngineeringInstitute).


30/40

• Se definió el proyecto "CMMI" el cual tuvo como misiónimplantar el CMMI en la organización y en la UDS "1" en elmás breve plazo. El equipo del proyecto estuvoconformado por personal experto en procesos de CMMI ypersonal de la UDS "1", con roles y responsabilidades

claramente definidos:

• 1 Ejecutivo de Proyecto• 1 Administrador del proyecto• 1 líder del proyecto por el lado de la UDS "1"• Equipo Implementador


31/40

Se definió una estrategia de implementación rápida, para lo cual se tomó encuenta lo siguiente:

• Incluir dentro del Equipo de implementación a personal experto en CMMI.• Capacitar al Equipo de implementación de la UDS "1" en CMMI.• Obtener el compromiso del personal de la UDS "1" para apoyar en las

actividades de CMMI.• Explicar a todo el personal de la UDS "1" las razones de la implementación y

cómo ayudará en los objetivos de calidad.•

Involucrar a un grupo de la UDS "1" en el Proyecto de Implementación.• Usar como base los procedimientos, formatos y herramientas que estánsiendo utilizados por la UDS "1" y que cumplen con los requerimientos delCMMI y solicitar aprobaciones a los expertos.

• Uso de herramientas que permitan desarrollar rápidamente el trabajo yque ayuden a generar métricas.

• No duplicar esfuerzos registrando bases de datos adicionales. Se usa las

bases de datos existentes, para lo cual es posible que se requieramodificaciones al SW para generar métricas• Reducir el impacto en la atención a usuarios.• La implantación de los procesos organizacionales se debería hacer a nivel

Empresa.


32/40


33/40

Al inicio del Proyecto se identificaron un conjunto de actividades y se asignaronresponsables, los cuales tuvieron como responsabilidad de elaborar el plan deimplementación:

Descripción detallada


34/40

Identificación: Levantamiento de Requerimientos

La UDS "1" tiene un conjunto de estándares, procesos, procedimientos yformatos definidos con los cuales ha venido operando. Algunos de losdocumentos son compartidos con los Usuarios. El Equipo de Implantaciónentrevistó al personal de la USD "1" y revisó los siguientes documentos quedeben ser generados por la UDS "1":

• Contratos, Acuerdos de niveles de servicio.• Plan de trabajo de la UDS y de los proyectos.• Productos de trabajo con actividades de Administración de la calidad• Registro (Log) de Problemas, de Dependencias, requerimientos de cambio y de

riesgos

• Minutas de reunión con clientes y miembros del equipo.• Documentos firmados por clientes• Plan de pruebas• Resultado de revisiones previas de Aseguramiento de la calidad• Procesos, procedimientos, metodologías, estándares, guías, formatos.


35/40

• Se asignó las áreas de proceso a los miembros delequipo. Cada uno de ellos tuvo el encargo de identificar lasbrechas (gaps) de una o más áreas de proceso.

• Se corroboró la brecha total mediante la revisión de

Aseguramiento de Calidad PPQA), para conocer el gradode cumplimiento de la USD "1" respecto del modeloCMMI definido para la Empresa, usando un formato paraaseguramiento de procesos (checklist) que tiene una lista

de chequeo de todos los puntos relacionados con elcumplimiento de las prácticas genéricas y específicas del

CMMI de todas las áreas de procesos


36/40

• Se analizó el Reporte de Aseguramiento de calidad. Elresultado del análisis arrojó como resultado que la USD "1" tuvo 30 % de adherencia al CMMI. Con este resultado se determinó elalcance, el esfuerzo y el costo del Proyecto y se elaboró el

Plan del Proyecto.

• La estimación del alcance fue dada por las tareas a realizarseen cada una de las PAs para completar en conjunto el 70% de

cumplimiento faltante.


37/40

• El esfuerzo estimado para la Transformación e Implantaciónfue de 24 meses - persona, en base a la situación actual,complejidad y número de pendientes por implementar en

cada PA. Se asignó 3 personas a tiempo completo para lograrel objetivo de implantarlo en 10 meses

• El costo del Proyecto fue calculado en base de los recursos

requeridos (personal, infraestructura, HW, SW) y al tiempo dededicación del personal


38/40

Barreras para una implantación exitosa

• Cultura del Usuario

• A los Desarrolladores no les gusta documentar nialimentar las bases de datos, por lo cualgeneralmente inician la atención de un siguienterequerimiento antes de haber culminado ladocumentación del anterior.

El modelo CMMI no establece llegar a determinado puntaje para que la


39/40

El modelo CMMI no establece llegar a determinado puntaje para que lacompañía sea madura, sino que su madurez óptima la alcanza cuando poseelos procesos listos para recibir la realimentación, al mismo tiempo que semantiene abierta a las mejoras que promueve constantemente.

Lenguaje común: Buen entendimiento del conocimiento básico en estadisciplina, el cual debe estar respaldado por un lenguaje o terminologíaestándar.

Procesos comunes: Definir y desarrollar procesos estándar como medio parael éxito de los proyectos, los que podrán ser repetidos en otros.

Metodología única: Es cuando la organización percibe y valora el efectosinérgico que tiene la combinación de todas las metodologías de laorganización dentro de una metodología única, de la cual el foco de irradiaciónes la administración de proyectos.

Benchamarking: Identifica que la mejora de los procesos es una acciónfundamental para lograr y/o mantener una ventaja competitiva. La compañíaestablece con quién efectúa esta comparación y los hallazgos que utilizará.

Mejoramiento continuo: Evalúa la información obtenida mediante el procesode benchmarking y establece si esta información se convertirá en unametodología única para la organización.


40/40

Actividades

1. Por equipos de trabajo usar un caso de estudio y aplicarCMM.

2. En que consiste el principio W5HH?2. Consultar y analizar las siguientes lecturas:

–

Harold Kerzner. En su libro Strategic planning for projectmanagement. – Organizational Project Management Maturity Model (OPM3®). – Project Management Institute (PMI®).

–

Work Organization: Paradigms for Project Management andOrganization; Larry L. Constantine; Communications of the ACMOctober 1993 Vol. 36 No. 10.http://ftp.math.utah.edu/pub/tex/bib/toc/cacm1990.html

GESTIÓN DEL PROYECTO DEL SOFTWARE.pdf

Documents

Transcript of GESTIÓN DEL PROYECTO DEL SOFTWARE.pdf