Embed Size (px)
Citation preview
Ingeniería de Software
Unidad I
Gestión de Proyectos de Software
Proyectos de software
Tema
Semana 3
Objetivos Generales:
Comprender correcta y eficientemente los conceptos y principios del espectro de técnicas de Ingeniería de Software que puedan ser aplicadas en proyectos de software.
Desarrollar una cultura de ingeniería de software.
Objetivos Específicos:
Aplicar correctamente los conceptos y principios relacionados a la Ingeniería de Software en la resolución de casos prácticos para la gestión de proyectos de software de calidad.
Utilizar herramientas para el modelado y gestión de proyectos de software.
Utilizar metodologías agiles en el desarrollo de software.
Objetivos Instruccionales:
Discutir los conceptos relacionados a la gestión del software.
Analizar la influencia de las 4Ps en la gestión del software.
• Planteo del problema de la gestión
La gestión de proyectos de software persigue la misma finalidad que todas las gestiones de proyectos de ingeniería:
Estimar que sucederá con un proyecto nuevo Analizar qué sucedió con un proyecto ya finalizado
En todos los casos se tratará de dar respuestas cuantitativas a preguntas precisas tales como:
¿Cuál será el plazo de entrega? ¿Cuántas personas necesito? ¿Cuánto costará el proyecto?
Co
nce
pto
s so
bre
ge
stió
n d
e
pro
yect
os
• Diferentes tipos de proyectos
Debemos diferenciar tres tipos de proyectos desde el punto de vista de su gestión:
Proyectos nuevos: se busca analizar costos, tiempos y cantidad de personas. Es el caso más difícil de todos.
Replanteo de proyectos viejos: se busca afinar la metodologías de estimación. Es la principal fuente de información
Extensiones: o ampliaciones de un proyecto existente: Es un caso intermedio donde se desea tener buena precisión en plazos y costos.
Co
nce
pto
s so
bre
ge
stió
n d
e
pro
yect
os
La gestión eficaz de un proyecto se centra en las cuatro P’s.
Personal – Producto – Proceso – Proyecto
El orden no es arbitrario.
El gestor debe tener en cuenta que:
El trabajo de IS, es un esfuerzo humano intenso que lo llevara al éxito.
Debe fomentar una minuciosa comunicación con el cliente al principio de la evolución del proyecto.
Un proyecto emprendido sin un plan sólido arriesga el éxito del producto.
El e
spe
ctro
de
la g
est
ión
Una mala gestión produce:
Proyectos mal organizados Fechas limites imposibles de cumplir. Sistemas que no cumplen con lo que esperaban los clientes. Sistemas imposibles de mantener.
¡Cual es la SOLUCION!
Una buena gestión de los proyectos de software
El e
spe
ctro
de
la g
est
ión
Necesitamos personal preparado y motivado
El factor humano es tan importante, tal que se han desarrollado “modelos de madurez de la capacidad de gestión”, para permitir aumentar la preparación de organizaciones del software y llevar a cabo cada vez más complicadas aplicaciones.
El modelo de madurez de gestión de personal define áreas claves prácticas para el personal que desarrolla software:
Reclutamiento, Selección, Gestión del rendimiento, Entrenamiento, Retribución, Desarrollo de la carrera, Diseño de la organización y del trabajo, Desarrollo cultural y de espíritu.
Las compañías que gestionan sensiblemente su inversión en personal a la larga prosperarán.
Hay 5 tipos de participantes: Gestores Superiores.- Definen los aspectos del
negocio.Gestores (técnicos) del proyecto.- Planifican,
motivan, organizan y controlan a quienes realizan el trabajo de software.
Profesionales.- Proporcionan la capacidad técnica.Clientes.- Especificando los requisitos para la
ingeniería del software.Usuarios finales.- Interactúan con el software una
vez que se ha entregado para la producción.
Los Jefes de Equipo
Es la persona que lidera a un equipo.
En función de la organización y el proyecto puede ser un gestor técnico o un profesional.
Un buen profesional informático competente, no quiere decir buen jefe de equipo: Generalmente, no tienen la mezcla adecuada de
capacidades para guiar al personal.
El e
spe
ctro
de
la g
est
ión
-
PE
RS
ON
AL
Características de un buen jefe de equipo
Modelo de Gestión según Jerry Weinberg
•MotivaciónHabilidad para motivar al personal técnico para
que produzca conforme a sus mejores capacidades.
•OrganizaciónHabilidad para amoldar procesos existentes.
•IdeasHabilidad para motivar al personal para crear y
sentirse creativo.
Características que definen a un Gestor de Proyectos…
Resolución del problema: Pueden diagnosticar los aspectos técnicos y de organización
mas relevantes. Estructuran una solución sistemáticamente. Son flexibles para cambiar la gestión si los intentos iniciales de
resolver el problema no dan resultado.
Dotes de gestión: Capacidad para manejar el problema y el personal. Debe tener confianza para asumir el control de ser necesario.
Incentivos por logros: Debe recompensar la iniciativa y logros. Demostrar que no habrá penalizaciones si se corren riesgos
controlados.
Competencia tecnológica: Grado de conocimiento de las ultimas tecnologías.
Influencia y construcción de espíritu de equipo: Debe ser capaz de “leer” a la gente. Entender señales verbales y no verbales. Mantener el control en situaciones de gran estrés. Capacidad para cohesionar al grupo y entender los problemas
personales.
…Características que definen a un Gestor de Proyectos
El equipo de desarrollo de softwareEl jefe de equipo elige el personal para cada
proyecto.
Existen tantas estructuras de organización de personal para el desarrollo de software como organizaciones que se dedican a ello.
Opciones de aplicación a los recursos de un proyecto que requiere n personas trabajando durante k años. n individuos son asignados a m diferentes tareas funcionales
(m>n). n individuos son asignados a m diferentes tareas funcionales
de manera que se establezcan equipos de trabajo (m<n). n individuos se organizan en t equipos, a cada equipo se le
asigna una o mas tareas formales.
Valores del equipo de desarrollo…Experiencia en el dominio de la aplicación.
Para desarrollar un proyecto con éxito, debemos entender el dominio.
Experiencia con la plataforma. Solo es importante si hay programación de bajo nivel.
Experiencia con el lenguaje de programación. Sobretodo en proyectos cortos.
Capacidad de comunicación. Comunicarse con los otros miembros del equipo, con los gestores y con los clientes.
Adaptabilidad. Capacidad de aprender.
Actitud. Ante el trabajo y las dificultades.
Personalidad. Capacidad de trabajo en equipo.
…Valores del equipo de desarrollo
Factores a considerar cuando se planifica el organigrama de equipos de IS
La dificultad del problema que hay que resolver.El tamaño del programa resultante en líneas de
código.El tiempo que el equipo estará juntoEl grado en que el problema puede ser
modularizado.La calidad requerida y fiabilidad del sistema que se
va a a construir.La rigidez de la fecha de entrega.El grado de sociabilidad requerido para el proyecto.
Organización del PersonalIndividuos trabajando de forma independiente en
distintas tareas, con poco trabajo conjunto y coordinados por el gestor del proyecto.
Formación de equipos informales que acometen distintas tareas, donde se puede elegir un jefe, y los equipos los coordina el gestor.
Organización de equipos bien determinados, donde a cada equipo se le asigna un conjunto de tareas bien definido. Cada equipo tiene una estructura especifica y bien definida. La coordinación se divide entre el equipo y el gestor del proyecto.
Organigramas de Equipos GenéricosDescentralizado Democrático (DD).
No tiene un jefe permanente Se nombran coordinadores de tareas a corto plazo para tareas
especificas. Las decisiones sobre problemas se toman en consenso en
grupo. La comunicación entre los miembros del equipo es horizontal.
Descentralizado Controlado (DC). Tiene un jefe de equipo para las tareas Tiene jefes secundarios para las subtareas. La resolución de problemas sigue siendo una actividad de
grupo. El jefe de grupo distribuye la implementación de tareas entre
los subgrupos La comunicación es tanto vertical (entre jefes) como horizontal
(entre subgrupos).
Centralizado Controlado (CC). Hay un único jefe de equipo Este resuelve los problemas a alto nivel y la
coordinación del equipo. La comunicación entre el jefe y los miembros del
equipo es vertical.
Organigramas de Equipos Genéricos
Estructuras de equipo según MANTEI
DD DC CC
Organigramas de Equipos Genéricos
Que organigrama de equipos elegir
Mantei, identifica siete factores de un proyecto para determinar la estructura a elegir.
Dificultad del problema Tamaño en líneas de código (LDC) o de puntos de
función (PF). Duración del equipo. Modularidad del problema. Calidad y fiabilidad del sistema a construir. Fecha de entrega. Comunicación requerida en el proyecto.
TamañoModularidad FiabilidadFecha de entrega.
• Dificultad• Duración• Comunicación
CC DC DD
Que organigrama de equipos elegir
Considerando los factores según Mantei…
Uso de las Organigramas de Equipos Genéricos
Centralizado Controlado (CC).Manejan problemas sencillos.
Descentralizado Controlado (DC).Tienen mas probabilidad de éxito en la resolución
de problemas complejos.
Descentralizado Democrático (DD).Manejan mejor los problemas difíciles.
Equipos cohesionados
Con independencia de la estructura, la cohesión del equipo es fundamental:
Ventajas:Desarrollo estándar de calidad de grupoLos miembros del grupo trabajan mejor juntos.Se conoce el trabajo de los otros miembros del
grupoSe practica la programación sin ego.
Desventajas:Resistencia al cambio en el liderazgoPensamiento de grupo.
Según Jackman hay 5 toxinas que afectan a la cohesión del equipo:
Atmósfera de trabajo frenética.Frustración causada por factores tecnológicos
del negocio o personales.Falta de un modelo de proceso adecuado.Definición confusa de los papeles.Continua y repetida exposición al fallo.
Equipos no cohesionados
Paradigmas de Organización para equipos de Ingeniería de Software…
Paradigma cerrado: Tiene una jerarquía tradicional de autoridad. Trabajan bien cuando producen software similar a
otros anteriores.
Paradigma aleatorio: Tiene una jerarquía libre. Depende de la iniciativa individual de los miembros
del equipo. Son eficaces cuando se requiere innovación o
avances.
Paradigma abierto: Estructura a un equipo con controles asociados con el
paradigma cerrado. También tienen mucha innovación. El trabajo se desarrolla en colaboración con mucha
comunicación Son adecuados para la resolución de problemas
complejos.Paradigma sincronizado:
Se basa en el comportamiento natural de un problema. Organiza a los miembros del equipo para trabajar en
partes del problema con poca comunicación activa entre ellos.
…Paradigmas de Organización para equipos de Ingeniería de Software
Algunos Aspectos sobre la Coordinación y Comunicación
La escala:El esfuerzo de desarrollo es grande, conduciendo a complejidades, confusión y dificultades significativas para coordinar a los miembros del equipo.
La incertidumbre:Da como resultado un continuo flujo de cambios que impactan al equipo de proyecto.
La Interoperatividad:El software nuevo debe comunicarse con el anterior y ajustarse a restricciones predefinidas impuestas por el sistema o el producto.
Motivos por los que los proyectos de software pueden tener problemas
Dilema del gestor de proyectos al inicio de un proyecto
Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida.
Un análisis detallado de los requisitos del software proporcionaría la información necesaria para las estimaciones, pero esto llevaría semanas o meses.
O en su defecto los requisitos pueden ser fluidos, cambiando regularmente a medida que avanza el proyecto, pero el plan de proyecto se necesita ya.
SOLUCION: Determinar el ámbito del software
Antes de planificar un proyecto se debe:
Establecer los objetivos y el ámbito del producto. Considerar soluciones alternativas e identificar las
dificultades técnicas y de gestión.
Los objetivos identifican las metas generales del proyecto sin considerar como se conseguirán.
El ámbito identifica: Los datos primarios. Funciones y comportamientos que caracterizan al
producto
El e
spe
ctro
de
la g
est
ión
-
PR
OD
UC
TO
El ámbito del Software…La primera actividad de gestión de un proyecto de software es determinar el ámbito del software.
El ámbito se define en función a: Contexto. Como encaja el software a construir en un sistema, producto o
contexto de negocio mayor, limitaciones. Objetivos de Información.
Que objetos de datos visibles al cliente se obtiene del software (resultados o salidas).
Que objetos de datos son requeridos de entrada Función y rendimiento.
Que función realiza el software para transformar la información de entrada en una salida, características especiales de rendimiento.
El e
spe
ctro
de
la g
est
ión
-
PR
OD
UC
TO
El ámbito de un proyecto de software debe ser univoco y entendible a niveles de gestión y técnico.
Los enunciados del ámbito del software deben estar limitados.
En esta fase se lleva a cabo la partición horizontal Se descompone el sistema en módulos Un modulo es una agrupación de funciones que
llevan a cabo tareas de naturaleza similar.
…El ámbito del Software…E
l esp
ect
ro d
e la
ge
stió
n -
P
RO
DU
CT
O
Por ejemplo un sistema CAD.
Modulo de dibujo. Modulo de transformaciones. Modulo de archivo. Modulo de impresión.
…El ámbito del SoftwareE
l esp
ect
ro d
e la
ge
stió
n -
P
RO
DU
CT
O
Descomposición del Problema…Es una actividad que se asienta en el núcleo
del análisis de requisitos del software.
Durante la actividad de exposición del ámbito no se intenta descomponer el problema totalmente.
La descomposición se aplica en dos áreas principales: La funcionalidad que deba entregarse El proceso que se emplea para entregarlo
Esta es la estrategia que se aplica al inicio de la planificación del proyecto.
El e
spe
ctro
de
la g
est
ión
-
PR
OD
UC
TO
Es esta fase se lleva a cabo la partición vertical
Durante la exposición del ámbito se produce una descomposición de primer nivel.
Ahora se refina dicha descomposición hasta el nivel de funciones.
Una función representa un procesamiento directamente invocable por el usuario que transforma información de entrada en información de salida.
En el proceso de descomposición pueden definirse nuevos submódulos.
…Descomposición del Problema…E
l esp
ect
ro d
e la
ge
stió
n -
P
RO
DU
CT
O
En el ejemplo del sistema CAD.
Modulo de dibujo.Dibujo 2D
Lineas Cuadrados Circunferencias
o Por centro y radioo Por tres puntos
SplinesDibujo 3D
…Descomposición del ProblemaE
l esp
ect
ro d
e la
ge
stió
n -
P
RO
DU
CT
O
El Proceso…Las fases genéricas que caracterizan el
proceso de software, definición, desarrollo y mantenimiento se encuentran y son aplicables a todo los modelos de proceso de software.
El problema esta en elegir el modelo de proceso apropiado.
El gestor del proyecto debe decidir que modelo de proceso es el mas adecuado para: Los clientes que han solicitado el producto y la gente que
realizara el trabajo. Las características del producto en si. El entorno del proyecto en el que trabaja el equipo de software.
Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo de software.
Los proyectos de software incorporan: Un pequeño numero de actividades estructurales, sin tener en
cuenta su tamaño o complejidad (Tareas, Hitos, Productos de trabajo, Puntos de Garantía de Calidad).
Actividades Protectoras. Garantía de Calidad del Software, Gestión de la configuración de Software y Medición.
Las actividades Protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.
…El Proceso
Maduración del Producto y el Proceso…Actividades estructurales:
Comunicación con el cliente.- Obtención de requerimientos.
Planificación.- Define los recursos. Análisis de riesgos.- Valora los riesgos técnicos y de
gestión. Ingeniería.- Tareas requeridas para construir una o
mas representaciones de la aplicación. Construcción y entrega.- Tarea requerida para
construir, probar, instalar y proporcionar asistencia al usuario.
Evaluación del cliente.- Tarea para obtener información de la opinión del cliente basada en la evaluación de la representación de software creado.
…Maduración del Producto y el ProcesoActividades Estructurales de Proceso Comunes
Comunicación con el cliente
Planificación Análisis de riesgo
Ingeniería
Tareas de Ingeniería de software
Funciones del producto
Introducción de texto 10.10.12
25.10.12
Tarea de trabajo
Edición y formato
Edición automática de copia
Capacidad de diseño de pagina
Indexación automática
Administración de archivos
Producción de documentos
Análisis Diseño
Estructura descomposición
La misión del gestor es rellenar todas las celdas de la tabla para obtener una planificación temporal.
La tabla es orientativa.
Los niveles de descomposición pueden ser varios
Descomposición del Proceso…
Elección del paradigma de ingeniería de software que resulta mejor para el proyecto.
Enfoque secuencial.- un proyecto relativamente pequeño similar a otros.
Desarrollo rápido de aplicaciones.- si hay limites de tiempo muy severos.
Estrategia incremental.- cuando la fecha limite esta tan próxima que no va a ser posible entregar toda la funcionalidad.
Una vez elegida el modelo de proceso, la Estructura Común de Proceso (ECP) se adapta a el.
El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.
Las Actividades Estructurales (AE) del proceso deben descomponerse en un conjunto de tareas de IS.
Dicha descomposición depende básicamente del tipo de proyecto
…Descomposición del Proceso…
Por ejemplo, para un proyecto de desarrollo de un producto nuevo, la AE ingeniería puede descomponerse en las tareas de IS : Análisis y diseño.
Para un proyecto de Reingeniería, la AE ingeniería puede descomponerse en las tareas de IS: Análisis, Revisar diseño, Diseño.
…Descomposición del Proceso
Es la única manera conocida de gestionar la complejidad.
Para evitar el fracaso de un proyecto; un gestor de proyectos de software y los ingenieros de software deben:
Eludir un conjunto de señales de peligro comunes. Comprender los factores de éxito que conducen a
las gestión correcta del proyecto. Desarrollar un enfoque de sentido común para:
Planificar, supervisar y Controlar el proyecto.
La Regla 90 – 90(Se toma como cierto para proyectos mal
gestionados)
El 90% de un sistema absorbe el 10% del tiempo y el esfuerzo asignado.
El ultimo 10% se lleva el otro 90% del esfuerzo y del tiempo asignado.
El e
spe
ctro
de
la g
est
ión
-
PR
OY
EC
TO
1. La gente del software no comprende las necesidades del cliente.
2. El ámbito del producto esta definido pobremente.
3. Los cambios están mal realizados.
4. La tecnología elegida cambia.
5. Las necesidades del negocio cambian (o están mal definidas).
6. Las fechas de entrega no son realistas.
7. Los usuarios se resisten.
8. Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente).
9. El equipo del proyecto carece del personal con las habilidades apropiadas.
10. Los gestores (y los desarrolladores) evitan buenas practicas y sabias lecciones.
10 señales que indican que un proyecto de sistemas de información esta en peligro.
El e
spe
ctro
de
la g
est
ión
-
PR
OY
EC
TO
• Empezar con el pie derecho (trabajar duro)
• Mantenerse (proporcionar incentivos)
• Seguimiento del progreso (seguimiento-aprueban)
• Tomar decisiones inteligentes (usar estándares
para eliminar riesgos, asignar mas tiempo a tareas arriesgadas)
• Realizar un análisis “postmortem” (después de finalizar el proyecto, evaluar la planificación real y la estimada)
Como debe actuar el gestor para evitar los problemas señalados:
El e
spe
ctro
de
la g
est
ión
-
PR
OY
EC
TO
El principio W5HH… Why is the System being Developed?
What will be done?
When will it be done?
Who is responsible for a function?
Where are they organizationally located?
How will the job be done technically and Managerially?
How much of each resource is needed?
El principio W5HH…
Boehm, sugiere un enfoque que trate los objetivos, hitos, planificación, responsabilidades enfoque técnico y de gestión y los recursos requeridos del proyecto a través de 7 cuestiones.Se plantean las siguientes:
(Why) Porque se desarrolla el sistema.- Justifica el propósito del negocio, el gasto del personal, tiempo y dinero.
(What)(When) Que se realizara y Cuando.- Identifica las tareas claves del proyecto y los hitos requeridos por el cliente.
(Who)Quien es el responsable de una función.- La responsabilidad de cada miembro del equipo de software debe estar definida.
(Where)Donde están situados organizacionalmente.- El cliente, usuarios y otros directivos también tienen responsabilidades.
(How)Como estará realizado el trabajo desde el punto de vista técnico y de gestión.- Se debe definir una estrategia
técnica y de gestión para el proyecto.
(How)Que cantidad de cada recurso se necesita.- Esta en función de las estimaciones realizadas.
El principio W5HH es aplicable sin tener en cuenta el tamaño o la complejidad del proyecto de software
…El principio W5HH
Las Prácticas Críticas
La Gestión formal del riesgo El costo empírico y estimación de la planificación La gestión del proyecto basada en métricas Seguimiento del valor ganado Seguimiento de defectos frente a objetivos de
calidad Gestión del programa de personal
Relación entre error, defecto y falloD
efe
cto
s y
err
ore
s e
n s
oftw
are
• La dirección del proyecto involucra la planificación, supervisión y mando de las personas, proceso, y eventos que ocurren durante el desarrollo del software.
• Todos administramos, pero el alcance de las actividades de dirección de cada persona varía conforme a su rol o papel en el proyecto.
• El software necesita ser administrado porque es una tarea compleja con un tiempo de duración largo.
Apreciación Global…R
esu
me
n
• Un plan de proyecto es un documento acerca de lo que define las cuatro P's de tal manera que asegure un producto de software de calidad y eficaz.
• La única manera de estar seguro que un plan del proyecto trabajó correctamente es estar observando que un producto de calidad alto fue entregado a tiempo y bajo el presupuesto.
…Apreciación GlobalR
esu
me
n
Ingeniería de Software
Unidad I
Gestión de Proyectos de Software
Proyectos de software
Tema
Semana 3
