Procesos de Ingeniería de Software

Gestión de Proyectos de Software

2019

@aaacabrera
 Preliminares
• Procesos de Ingeniería de Software
• Armando Cabrera Silva – Master en Ingeniería de Software
• Clases,
– Paralelo A, Lunes 09:00 – 12:00, aula 715
– Paralelo B, Miércoles 09:00 – 12:00, aula 433
• Tutoría,
– Paralelo A, Lunes 16:00-17:00
– Paralelo B, Lunes 17:00-18:00
• Requisitos
– Programación Avanzada
– Fundamentos de Ingeniería de Software
– Gestión de Proyectos
– Ingeniería de Requisitos
– Arquitectura de Aplicaciones
 Definición

“La aplicación de un enfoque sistemático,

disciplinado y cuantificable para el desarrollo,
operación y mantenimiento del software, esto
es la aplicación de la ingeniería al software”
IEEE Computer Society
Semana 1
 Objetivos
• Conocer las principales tareas de los administradores de proyectos
de software
• Introducir la noción de gestión del riesgo y a algunos de los riesgos
que pueden surgir en los proyectos de software.
• Comprender los factores que influyen en la motivación personal y
que significan para los administradores de proyectos de software
• Entender los conflictos clave que influyen en el trabajo en equipo,
tales como la composición del equipo, la organización y la
comunicación.
 Agenda
1. SWEBOK
2. PMBOK
3. Gestión de Proyectos
4. Gestión del riesgo
5. Gestión del personal
6. Trabajo en equipo
Cuerpo de Conocimiento de la Ingeniería de Software

SWEBOK
 SWEBOK
• Cuerpo de Conocimiento de la Ingenieria de Software
(Software Enginnering Body of Knowledge.

“Software Engineering Body of Knowledge, es un documento creado

por la Software Engineering Coordinating Committee, promovido por la
IEEE Computer Society, que se define como una guía al conocimiento
presente en el área de la Ingeniería del Software”
SWEBOK
 Áreas de Conocimiento
• Requerimientos de software
• Diseño de software
• Pruebas de Software
• Mantenimiento de Software
• Gestión de la Configuración del Software
• Gestión de la ingeniería del software
• Procesos de Ingeniería de software
• Métodos y herramientas de la ingeniería de software
• Calidad del Software
DevOps ?
Cuerpo de Conocimiento de la Gestión de Proyectos

PMBOK
 Qué es?
• Aplicación de conocimientos, habilidades, herramientas y
técnicas a las actividades de un proyecto
• Aplicación e integración de 42 procesos de la dirección de
proyectos agrupados lógicamente en 5 grupos de procesos.
 Grupos de Proceso
• Iniciación
• Planificación
• Ejecución
• Seguimiento y Control
• Cierre
GESTIÓN DE PROYECTOS DE SOFTWARE
 Introducción
• La gestión de proyectos de software es parte esencial de la
ingeniería de software.
• Los proyectos necesitan administrarse.
• Ingeniería de software profesional
• Restricciones organizacionales de presupuesto y fecha.
• Software de alta calidad
• Tarea del administrador del proyecto
Introducción
Introducción
Introducción
 Introducción
• La buena gestión no puede garantizar el éxito del proyecto.
• Mala gestión – falla en el proyecto:
– El software puede entregarse tarde
– Costar más de lo estimado
– No cumplir con la expectativas de los clientes
 Introducción
• Criterios de éxito varían de un proyecto a otro:

– Entregar el software al cliente en el tiempo apropiado.

– Mantener los costos dentro del presupuesto general
– Mantener un equipo de desarrollo óptimo y con buen
funcionamiento.

• Estas metas no son exclusivas de la ingeniería de software

 Introducción
• La ingeniería de software es diferente a otros tipos de
ingeniería debido a:

– El producto es intangible
– Los grandes proyectos de software con frecuencia son proyectos
excepcionales
– Los procesos de software son variables y específicos de la
organización
 Introducción
• Debido a conflictos, no es sorpresivo que los proyectos de
software se retrasen y excedan de presupuesto.
• A menudo los proyectos de software son nuevos o
técnicamente innovadores.
• Los proyectos reformadores(refactory), tienen también
problemas de calendario.
• Asombroso que los proyectos de software: ¡se entreguen a
tiempo y dentro del presupuesto!
 Introducción
• Las actividades de un proyecto de software son imposibles de
estandarizar, la mayoría de gerentes de proyectos suelen realizar
las siguientes actividades:

• Planeación del Proyecto

• Gestión del Riesgo
• Gestión del Personal
• Redactar Propuestas
• Informes
GESTIÓN DEL RIESGO
 Riesgo
• Un evento que puede o no ocurrir, pero si ocurre,
tendrá consecuencias no deseadas.
• Evento ó condición que si ocurre tiene un efecto
positivo o negativo sobre al menos un objetivo del
proyecto.
Fuente, PMBOK Guide
 Riesgos
• Tarea sustancial del administrador del proyecto
• Implica anticipar riesgos que:
– Pudieran alterar el calendario del proyecto o la calidad del software
a entregar.
– Permitan tomar acciones para evitar dichos riesgos
• Algo preferible que no ocurra
 Categorías

• Riesgos del proyecto

– Alteran el calendario o los recursos del proyecto
• Riesgos del producto
– Afectan la calidad o el rendimiento del software a desarrollar
• Riesgos empresariales.
– Afectan a la organización que desarrolla o adquiere el software
 Gestión del Riesgo
• Registrar los resultados del análisis en el plan del proyecto
junto con un análisis de consecuencias.
 Ejemplos
Riesgo Repercute en Descripción
Rotación de personal Proyecto Personal experimentado
abandonará el proyecto antes de
que éste termine
Cambio Administrativo Proyecto Habrá un cambio de gestión en la
organización con diferentes
prioridades
Indisponibilidad de Proyecto Hardware, que es esencial para el
hardware proyecto, no se entrega a tiempo.
Cambio de requerimientos Proyecto y Habrá mayor cantidad de cambios
producto a los requerimientos que los
anticipados.
Demoras en la Proyecto y Especificaciones de interfaces
especificación producto esenciales no están disponibles a
tiempo.
 Gestión del Riesgo

Riesgo Repercute en Descripción

Subestimación del tamaño Proyecto y Se subestimo el tamaño del
producto producto
Bajo rendimiento de las Proyecto y Las herramientas CASE, que
herramientas CASE producto apoyan el proyecto, no se
desempeñan como se anticipaba
Cambio tecnológico Empresa La tecnología subyacente sobre la
cual se construye el sistema se
sustituye con una nueva
Competencia de productos Empresa Un producto competitivo se
comercializa antes de que el
sistema esté completo.
 Etapas
• Identificación del riesgo
– Identificar posibles riesgos (proyecto-producto-empresa)
• Análisis de riesgos
– Valorar probabilidad y consecuencias
• Planeación del riesgo
– Elaborar planes para enfrentar el riesgo
• Monitorización del riesgo
– Valorar regularmente el riesgo y los planes para atenuarlo
Proceso de gestión del riesgo
 Identificación del riesgo
• Primera etapa del proceso
• Identificar riesgos de mayor amenaza
• Puede ser un proceso de equipo
• El administrador del proyecto en base a su experiencia
identifica los riesgos más probables y críticos.
• Se recomienda utilizar listas de verificación.
 Tipos de riesgos
• Riesgos tecnológicos
• Riesgos personales
• Riesgos organizacionales
• Riegos de herramientas
• Riesgos de requerimientos
• Riesgos de estimación
 Ejemplos

Tipo de riesgo Riesgos posibles

Tecnológico La B.D no puede procesar tantas transacciones por segundo
como se esperaba.
Los componentes de software de reutilización contienen
defectos que hacen que no puedan reutilizarse como se
planteo
Personal Es imposible reclutar personal con las habilidades requeridas
El personal clave enfermo e indispuesto en momentos críticos.
No. esta disponible la capacitación requerida para el personal
De organización La organización se restructura de modo que diferentes
administraciones son responsables del proyecto.
Problemas financieros de la organización fuerzan reducciones
en el presupuesto del proyecto.
 Ejemplos

Tipo de riesgo Riesgos posibles

Herramientas El código elaborado por las herramientas de generación de
código de software es insuficiente.
Las herramientas de software no pueden trabajar en forma
integrada.
Requerimientos Se proponen cambios a los requerimientos que demandan
mayor trabajo de rediseño
Los clientes no entienden las repercusiones de los cambios a
los requerimientos.
Estimación Se subestima el tiempo requerido para desarrollar el software
Se subestima la tasa de reparación de defectos
Se subestima el tamaño del software
 Ejemplos
• Para la mayoría de los proyectos de desarrollo de software,
podemos definir cinco áreas principales de impacto de riesgo:

• Nuevas tecnologías no probadas.

• Usuario y requisitos funcionales.
• Arquitectura de aplicaciones y sistemas
• Actuación
• Organizativo
 Ejemplo
• Nuevas tecnologías no probadas.
– La mayoría de los proyectos de software implican el uso de nuevas
tecnologías.
– Las herramientas, técnicas, protocolos, estándares y sistemas de
desarrollo que cambian constantemente aumentan la probabilidad
de que surjan riesgos tecnológicos en prácticamente cualquier
esfuerzo sustancial de ingeniería de software.
– La capacitación y el conocimiento son de importancia crítica, y el uso
inadecuado de la nueva tecnología a menudo conduce directamente
al fracaso del proyecto.
 Ejemplo
• Usuario y requisitos funcionales.
– Los requisitos de software capturan todas las necesidades del usuario con
respecto a las características, funciones y calidad del servicio del sistema
de software. Con demasiada frecuencia, el proceso de definición de
requisitos es largo, tedioso y complejo.
– Además, los requisitos generalmente cambian con las actividades de
descubrimiento, creación de prototipos e integración.
– Es probable que el cambio en los requisitos elementales se propague a lo
largo de todo el proyecto y que las modificaciones a los requisitos del
usuario no se traduzcan en requisitos funcionales.
– Estas interrupciones a menudo conducen a una o más fallas críticas de un
proyecto de desarrollo de software mal planificado.
• Aplicación y arquitectura del sistema.
– Tomar la dirección equivocada con una plataforma, componente o
arquitectura puede tener consecuencias desastrosas.
– Al igual que con los riesgos tecnológicos, es vital que el equipo
incluya expertos que entiendan la arquitectura y tengan la capacidad
de tomar decisiones de diseño de sonido.
 Ejemplos

• Actuación.
– Es importante asegurarse de que cualquier plan de gestión de riesgos
incluya las expectativas de rendimiento de los socios y los usuarios.
– Se debe tener en cuenta los puntos de referencia y las pruebas de
umbral en todo el proyecto para garantizar que los productos de
trabajo se mueven en la dirección correcta.
 Ejemplo
• Organizativo.
– Los problemas organizacionales pueden tener efectos adversos en los
resultados del proyecto.
– La gerencia del proyecto debe planificar la ejecución eficiente del
proyecto y encontrar un equilibrio entre las necesidades del equipo
de desarrollo y las expectativas de los clientes.
– Por supuesto, la dotación de personal adecuada incluye la elección
de los miembros del equipo con conjuntos de habilidades que
combinen bien con el proyecto.
 Análisis de riesgos
• Considerar cada riesgo identificado y:
– Realizar un juicio acerca de la probabilidad y gravedad de dicho
riesgo.
– Apoyarse en su propio juicio y experiencia obtenida en proyectos
anteriores.
• No es posible hacer valoraciones precisas y numéricas de la
probabilidad y gravedad de cada riesgo.
 Análisis de riesgos
• La probabilidad del riesgo puede valorarse como:
– Muy baja (<10%)
– Baja (del 10 al 25%)
– Moderada (del 25 al 50%)
– Alta (del 50 al 75%)
– Muy alta (>75%)
 Análisis de riesgos
• Los efectos de un riesgo pueden estimarse como:
– Catastróficos (amenazan la supervivencia del proyecto)
– Graves (causarían grandes demoras)
– Tolerables (demoras dentro de la contingencia permitida)
– Insignificantes.
 Ejemplos
Riesgo Probabilidad Efectos
Problemas financieros de la organización fuerzan Baja Catastrófico
reducciones en el presupuesto del proyecto
Es imposible reclutar personal con las habilidades Alta Catastrófico
requeridas.
El personal clave enfermo e indispuesto en momentos Moderada Grave
críticos.
Los componentes de software de reutilización Moderada Grave
contienen defectos que hacen que no puedan
reutilizarse como se planteo
Se proponen cambios a los requerimientos que Moderada Grave
demandan mayor trabajo de rediseño
La organización se restructura de modo que Alta Grave
diferentes administraciones son responsables del
proyecto.
 Tipos de riesgos
Riesgo Probabilidad Efectos
La B.D no puede procesar tantas transacciones por Moderada Grave
segundo como se esperaba.
Se subestima el tiempo requerido para desarrollar el Alta Grave
software.
Las herramientas de software no pueden trabajar en Alta Tolerable
forma integrada.
Los clientes no entienden las repercusiones de los Moderada Tolerable
cambios a los requerimientos.
No esta disponible la capacitación requerida para el Moderada Tolerable
personal.
Se subestima la tasa de reparación de defectos Moderada Tolerable
Se subestima el tamaño del software Alta Tolerable
El código elaborado por las herramientas de Moderada Insignificante
generación de código de software es insuficiente.
 Análisis de riesgos
• Boehm recomienda identificar y monitorizar 10 riesgos.
• El número correcto de riesgos a monitorizar depende del
proyecto.
Lista de los 10 riesgos principales según Boehm y cómo
gestionarlos

Riesgo Técnica de gestión del

riesgo
Deficiencias del Contratar gente con
personal talento, reasignación
de trabajos,
construcción equipos,
acuerdos entre
personal clave,
formación cruzada
Lista de los 10 riesgos principales según Boehm y cómo
gestionarlos

Riesgo Técnica de gestión del

riesgo
Planificaciones y Estimación de varias
presupuestos poco fuentes detallada de
realistas costos y planificación,
diseñar en función del
costo, desarrollo
incremental,
reutilización
Lista de los 10 riesgos principales según Boehm y cómo
gestionarlos

Riesgo Técnica de gestión del

riesgo
Desarrollo de las Análisis de
funciones erróneas organización,
revisiones y
participación del
usuario, prototipos,
manuales preliminares
Lista de los 10 riesgos principales según Boehm y cómo
gestionarlos

Riesgo Técnica de gestión del

riesgo
Desarrollo erróneo de la Prototipos, escenarios,
interfaz análisis de tareas

Deficiencia en Benchmarking,
componentes inspecciones, análisis de
proporcionados compatibilidad
Lista de los 10 riesgos principales según Boehm y cómo
gestionarlos

Riesgo Técnica de gestión del

riesgo
Deficiencias en Simulación, Prototipos,
rendimiento en tiempo Benchmarking
real
Deficiencia en Benchmarking,
componentes inspecciones, análisis
proporcionados de compatibilidad
 Planeación del riesgo
• Considere cada uno de los riesgos clave identificados y
desarrolle estrategias para manejarlos.
• Considere acciones a tomar para minimizar los efectos al
proyecto si se produce el problema identificando el riesgo
• Recopile información mientras observa el proyecto para que
anticipe problemas.
 Planeación del riesgo

Riesgo Estrategia
Problemas Prepare un documento informativo para altos ejecutivos en el que
financieros de la muestre cómo el proyecto realiza una aportación muy importante
organización a las metas de la empresa y presente rezones por las que los
recortes al presupuesto del proyecto no serian efectivos en costo.
Problemas de Alerte al cliente de dificultades potenciales y de la posibilidad de
reclutamiento demoras; investigue la compra de componentes.
Enfermedad del Reorganice los equipo de manera que haya más traslape de
personal trabajo y, así, las personas comprendan las labores de los demás.
Componentes Sustituya los componentes potencialmente defectuosos con la
defectuosos compra de componentes de conocida fiabilidad.
Cambios en los Obtenga información de seguimiento para valorar el efecto de
requerimientos cambiar los requerimientos; maximice la información que se
oculta en el diseño.
 Planeación del riesgo
• Estrategias:
– Estrategias de evitación: reducir la posibilidad de ocurrencia de del
riesgo.
– Estrategias de minimización: Reducir el efecto del riesgo
– Planes de contingencia: Contar con una estrategia para hacer frente a
los problemas ante al ocurrencia de un riesgo.
 Planeación del Riesgo

Tipo de riesgo Indicadores potenciales

Tecnológico Entrega tardía de hardware o software de soporte; muchos
problemas tecnológicos reportados
Personal Baja moral del personal; malas relaciones entre miembros del
equipo; alta rotación del personal
De organización Cometarios de pasillo en la organización; falta de acción de
altos ejecutivos
Herramientas Renuencia de los miembros del equipo para usar herramientas;
quejas acerca de las herramientas CASE; demandas por
estaciones de trabajo mejor equipadas
Requerimientos Muchas peticiones de cambio de requerimientos; quejas de los
clientes.
Estimación Fallas en cumplimiento del calendario acordado, fallas en la
corrección de defectos reportados.
GESTIÓN DEL PERSONAL
 Introducción
• Personal – activo más importante de la empresas de software
• Cuesta mucho dinero reclutar y retener al buen personal
• Los administradores deben garantizar a la organización el
aprovechamiento por su inversión.
• Respeto a las personas
• Asignar responsabilidades que reflejen sus habilidades y
experiencia.
 Introducción
• Los ingenieros de software no necesariamente son buenos
administradores de personal.
• Habilidades técnicas - V.S – Habilidades para motivar y dirigir al
equipo de desarrollo.
• Como administrador del proyecto debe:
– Estar al tanto de los problemas potenciales de administrar personal
– Desarrollar habilidades de gestión de recursos humanos
 Introducción
• Factores críticos de la gestión del personal:
– Consistencia: recibir trato similar
– Respeto: Las personas tienen distintas habilidades y los
administradores deben respetar esas diferencias
– Inclusión: Las personas contribuyen efectivamente cuando sienten
que otros las escuchan y que sus propuestas se toman en cuenta
– Honestidad: Como administrador debe ser honesto con lo que está
bien y lo que está mal.
Motivación del Personal
 Motivación personal
• El tipo de personalidad también influye en la motivación:
– Personas orientadas a las tareas: quienes están motivadas por el
trabajo que realizan
– Personas orientadas hacia sí mismas: motivadas por el éxito y
reconocimiento personal
– Personas orientadas a la interacción: motivadas por la presencia y las
acciones de los compañeros de trabajo. Disfrutan de trabajar como
parte de un grupo
 Trabajo en equipo
• El software profesional se desarrolla mediante equipos de
trabajo.
• Cada equipo es responsable de desarrollar parte del sistema
global.
• Regla, grupos de trabajo no deben tener mas de 10 miembros.
• Grupos pequeños reducen problemas de comunicación.
 Trabajo en equipo
• Conformar un equipo equilibrado de habilidades técnicas,
experiencia y personalidades es una tarea administrativa
fundamental.
• Cohesión – espíritu de grupo
• Personas motivadas – éxito individual y de grupo.
 Trabajo en equipo
• Beneficios:
– Establecer sus propios estándares de calidad.
– Aprender de los demás y apoyarse mutuamente.
– Compartir el conocimiento
– Alentar la refactorización y el mejoramiento
continuo.
 Trabajo en equipo
• Factores que afectan el trabajo en equipo
– La personas en el grupo
– La organización grupal
– Comunicaciones técnicas y administrativas
PSP (Personal Software Process)
 PSP-TSP-CMMI

CMM - Improves
organization’s
capability,
management focus.

TSP - Improves team

performance, team
and product focus.

PSP - Improves
individual skills and
discipline, personal
focus.
 PSP TSP TSP
Skill-building Team-building Team-working

Personal measures Project goals Risk analysis

Process discipline Team roles Team communication
Estimating & planning Team process Team coordination
Quality management Project plan Status tracking
Balanced plan Project reporting

Team Team Team

Members Disciplines Management

Integrated
Product Teams
 Selección de los miembros del grupo
• Funciones del administrador del proyecto:
– Crear un grupo cohesivo y organizar a los miembros del grupo para
que puedan trabajar de forma efectiva
– Crear un grupo con el equilibrio correcto de habilidades técnicas y
personales.
– Empleados actuales que tiene experiencia en otros proyectos.
– Los administradores pocas veces tienen absoluta libertad en la
selección del equipo.
 Organización del grupo
• La forma en la que se organiza el grupo influye en:

– Las maneras como se intercambia la información y

– La interacciones entre el grupo de desarrollo y los participantes
externos del proyecto.
 Organización del Grupo
• Preguntas organizacionales importantes para los administradores
de proyecto:

– El administrador del proyecto debe ser el líder técnico del proyecto?

– Quién se encargará de tomar las decisiones técnicas criticas y como se
tomarán?
– Cómo se manejaran las interacciones con los participantes externos y los
altos directivos de la compañía?
– Como es posible que los grupos logren integrar a personas que no se
localizan en el mismo lugar?
– Como puede compartirse el conocimiento a través del grupo?
 Comunicaciones grupales
• Esencial que los miembros del grupo se comuniquen efectiva y
eficientemente entre sí y con otras partes interesadas en el
proyecto.
• Deben intercambiar información acerca del estatus de su
trabajo.
• La buena comunicación ayuda a fortalecer la cohesión del
equipo.
• Comprensión de las motivaciones, fortalezas y debilidades de
otras personas en el equipo.
 Comunicaciones grupales
• La efectividad y la eficiencia esta influida por:
– Tamaño del grupo
– Estructura del grupo
– Composición del grupo
– Al ambiente laborar físico
– Los canales de comunicación disponibles
 Puntos clave
• La buena gestión de proyectos de software es esencial si los
proyectos de ingeniería de software deben desarrollarse
dentro del plazo y el presupuesto establecidos.

• La gestión del software es distinta de otras administraciones de

ingeniería. El software es intangible. Los proyectos pueden ser
novedosos o innovadores, así que cuenta con un conjunto de
experiencias para orientar su gestión. Los procesos de software
son tan maduros como los proceso de ingeniería tradicionales.
 Puntos clave
• La gestión del riesgo se reconoce ahora como una de las tareas
más importantes de la gestión de un proyecto.

• La gestión del riesgo implica la identificación y valoración de

los grandes riesgos del proyecto para establecer la
probabilidad de que ocurran; también supone identificar y
valorar las consecuencias para el proyecto si dicho riesgo
surge. Debe hacer planes para evitar gestionar o enfrentar los
posibles riesgos.
 Puntos clave
• Las personas se sienten motivadas por la interacción con otros
individuos, el reconocimiento de la gestión y sus pares y al
recibir oportunidades de desarrollo personal.

• Los grupos de desarrollo de software deben ser bastante

pequeños y cohesivos. Los factores clave que influyen en la
efectividad de un grupo son sus integrantes, la forma en que
esta organizado y la comunicación entre los miembros.
 Puntos clave
• Las comunicaciones en un grupo están influidas por factores
como el estatus de los miembros del grupos, el tamaño del
grupo, la composición por género del grupo, las personalidades
y los canales de comunicación disponibles.
@aacabrera