Ingenier

1
Ingeniería de Software

• Unidad 2
• Administración de Proyectos de Software

2
Contenido
Unidad 2

• Esquema del plan de administración del proyecto
• Técnicas de planificación
• Diagramas de GANTT
• Redes de precedencia (PERT)
• Métricas del proyecto
• Mediciones del software
• Métricas orientadas al tamaño (LDC)
• Métricas orientadas a la función
• Modelo de estimación de costos (COCOMO)
• Seguimiento y supervisión del proyecto
• Gestión de riesgos.

3
Esquema del plan de administración del proyecto
Unidad 2

• Existen varias maneras de elaborar un plan de
  administración, sin embargo una de las mejores es
  el estándar IEEE 1058 Schach, 2004.
• El estándar refleja la experiencia de la
  industria y las universidades.
• Se diseño como marco de trabajo para usarlo con
  todo tipo de sistemas de información, sin
  importar el ciclo de vida o metodología.
• En el caso de sistemas pequeños algunas secciones
  no son relevantes.

1. Descripción general 1.1 Resumen del
proyecto 1.1.1 Propósito, alcance y
objetivos 1.1.2 Suposiciones y
Restricciones 1.1.3 Elementos del
proyecto sujetos a entrega 1.1.4
Calendario y resumen del presupuesto 1.2
Evolución del plan de administración del
proyecto 2. Materiales de consulta 3.
Definiciones y acrónimos 4. Organización del
proyecto 4.1 Interfaces externas 4.2
Estructura interna 4.3 Funciones y
responsabilidades 5. Planes del proceso
administrativo 5.1 Plan inicial 5.1.1
Plan de estimación 5.1.2 Plan de
contratación de personal 5.1.3 Plan de
adquisición de recursos 5.1.4 Plan de
capacitación para el personal del proyecto
5.2 Plan de trabajo 5.2.1 Actividades de
trabajo 5.2.2 Asignación del calendario
5.2.3 Asignación de recursos 5.2.4
Asignación del presupuesto 5.3 Plan de
control 5.3.1 Plan de control de
requisitos 5.3.2 Plan de control del
calendario 5.3.3 Plan de control del
presupuesto 5.3.4 Plan de control de la
calidad 5.3.5 Plan de generación de
informes 5.3.6 Plan de recolección de
mediciones 5.4 Plan de manejo de riesgos
5.5 Plan de cierre del proyecto 6. Planes del
proceso técnico 6.1 Modelo del proceso
6.2 Métodos, herramientas y técnicas 6.3 Plan
de infraestructura 6.4 Plan de aceptación del
producto
7. Planes de procesos de soporte 7.1 Plan del
control de la configuración 7.2 Plan de
pruebas 7.3 Plan de documentación 7.4
Plan de aseguramiento de la calidad 7.5 Plan
de revisiones y auditorias 7.6 Plan de
resolución de problemas 7.7 Plan de control
de los subcontratistas 7.8 Plan de mejora del
proceso 8. Planes adicionales
4
Esquema del plan de administración del proyecto
(2)
Unidad 2

• 1.- Descripción general
• 1.1 Resumen del proyecto
• 1.1.1 Propósito, alcance y objetivos. Se da una
  breve descripción del propósito y las
  posibilidades del sistema de información que se
  va a entregar, así como de los objetivos del
  proyecto.
• 1.1.2 Suposiciones y restricciones. Cualquier
  suposición subyacente al proyecto se define aquí,
  junto con restricciones como la fecha de entrega,
  el presupuesto, los recursos y artefactos que se
  van a utilizar.
• 1.1.3 Elementos del proyecto sujetos a entrega.
  Todos los elementos que se van a entregar al
  cliente se enlistan aquí, junto con las fechas
  correspondientes.
• 1.1.4 Calendario y resumen del presupuesto. El
  calendario general se presenta aquí, junto con el
  presupuesto.
• 1.2 Evolución del plan de administración del
  proyecto
• En esta sección se describen los procedimientos y
  mecanismos formales para cambiar el plan.
• 2.- Materiales de consulta
• Todos los documentos referidos en el plan de
  administración del proyecto se enlistan aquí.
• 3.- Definiciones y acrónimos
• Esta información asegura que todos comprendan el
  plan de administración del proyecto de la misma
  manera.
• 4.- Organización del proyecto
• 4.1 Interfaces externas
• Se deben establecer los mecanismos (quién,
  cuándo, dónde y propósito) de las reuniones entre
  el cliente y los miembros del proyecto.
• 4.2 Estructura interna
• En esta sección se describe la estructura de la
  empresa de desarrollo (grupo de desarrollo, de
  soporte, gerencial).
• 4.3 Funciones y responsabilidades.
• Para cada función del proyecto y para cada
  actividad debe identificarse al responsable
  individual.

5
Esquema del plan de administración del proyecto
(3)
Unidad 2

• 5.- Planes del proceso administrativo
• 5.1 Plan inicial
• 5.1.1 Plan de estimación. Las técnicas utilizadas
  para estimar la duración y el costo del proyecto
  se enlistan aquí, así como la manera en que se
  rastrearán y, en caso de ser necesario, se
  modificarán mientras el proyecto está en proceso.
• 5.1.2 Plan de contratación de personal. Se
  enlista la cantidad y el tipo de personal
  requerido, junto con los periodos para los cuales
  se necesita.
• 5.1.3 Plan de capacitación para el personal del
  proyecto. Toda la capacitación necesaria para una
  finalización exitosa del proyecto se enlista en
  esta subsección.
• 5.2 Plan de trabajo
• 5.2.1 Actividades de trabajo. Se especifican
  todas las actividades de trabajo, hasta el nivel
  de tarea en caso de ser necesario.
• 5.2.2 Asignación del calendario. En general,
  existe una relación cercana entre los paquetes de
  trabajo y la dependencia de eventos externos
  (análisis primero, después diseño, ). Aquí se
  especifican las dependencias relevantes.
• 5.2.3 Asignación de recursos. Los diversos
  recursos enlistados antes se asignan a las
  funciones, actividades y tareas propias del
  proyecto.
• 5.2.4 Asignación del presupuesto. Esta subsección
  se divide el presupuesto general en los niveles
  de función, actividad y tarea del proyecto.
• 5.3 Plan de control
• 5.3.1 Plan de control de requisitos. Se describen
  los mecanismos para controlar y vigilar los
  cambios que se dan en los requisitos.
• 5.3.2 Plan de control del calendario. Se enlistan
  los mecanismos para medir el progreso, junto con
  una descripción de las medidas que se deben tomar
  en caso de que el progreso real no corresponda
  con el esperado.
• 5.3.3 Plan de control del presupuesto. Los
  mecanismos para vigilar cuando el costo real
  excede al presupuestado, así como las medidas a
  tomar si esto ocurre.
• 5.3.4 Plan de control de la calidad. Las formas
  en que se medirá y controlará la calidad se
  describen en esta sección.

6
Esquema del plan de administración del proyecto
(4)
Unidad 2

• 5.3.5 Plan de generación de informes. Con el fin
  de vigilar los requisitos, el calendario, el
  presupuesto y la calidad, es necesario establecer
  los mecanismos para la generación de informes.
• 5.3.6 Plan de recolección de mediciones. Se
  enlistan las mediciones que se van a recopilar
  (LDC, PF, )
• 5.4 Plan de manejo de riesgos
• Los riesgos deben identificarse, ponerse en orden
  de prioridad, mitigarse y darles seguimiento. En
  esta sección se deben describir todos los
  aspectos del manejo de riesgos.
• 5.5 Plan de cierre del proyecto
• Las acciones por realizar una vez que el proyecto
  está terminado, incluyendo la reasignación del
  personal y crear el archivo de los artefactos.
• 6.- Planes del soporte técnico
• 6.1 Modelo del proceso
• En esta sección se da una descripción detallada
  del modelo del ciclo de vida que se va a
  utilizar.
• 6.2 Métodos, herramientas y técnicas
• Las metodologías de desarrollo y los lenguajes de
  programación que se van a usar se describen aquí.
• 6.3 Plan de infraestructura
• Los aspectos técnicos de hardware y software se
  describen con detalle en esta subsección (equipo,
  SO, la red, SW, CASE, ), tanto los que se van a
  utilizar para desarrollar el sistema de
  información, así como aquellos en los cuales se
  ejecutará dicho sistema.
• 6.4 Plan de aceptación del producto
• Se deben preparar los criterios de aceptación el
  cliente debe aceptarlos por escrito y los
  desarrolladores deben entonces asegurar que se
  cumplan. La manera en que se realizará lo
  anterior debe quedar por escrito.
• 7.- Planes de procesos de soporte
• 7.1 Plan de control de la configuración
• Se da una descripción detallada de los medios por
  los cuales todos los artefactos se pondrán bajo
  el control de la configuración.

7
Esquema del plan de administración del proyecto
(5)
Unidad 2

• 7.2 Plan de pruebas
• Se necesita de una planeación cuidadosa que
  incluya los recursos para su aplicación y el
  calendario específico de que prueba ha de
  realizarse.
• 7.3 Plan de documentación
• Una descripción de toda la documentación ya sea
  que se entreguen o no al cliente.
• 7.4 Plan de aseguramiento de la calidad
• Todos los aspectos del aseguramiento de la
  calidad, incluidas las pruebas, los estándares y
  las revisiones se engloban en esta sección.
• 7.5 Plan de revisiones y auditorias
• Se presentan detalles relacionados con la manera
  como se realizan las revisiones.
• 7.6 Plan de resolución de problemas
• Se describe la forma y mecanismos de resolver
  problemas en cualquiera de las fases del
  desarrollo del sistema.
• 7.7 Plan de control de los subcontratistas
• Se aplica cuando se requiere y el método para
  seleccionar y manejar a los subcontratistas debe
  aparecer aquí.
• 7.8 Plan de mejora del proceso
• Las estrategias para la mejora del proceso se
  incluyen aquí.
• 8. Planes adicionales
• Para ciertos proyectos, los componentes
  adicionales tal vez necesiten aparecer en el
  plan. En términos del marco de trabajo del IEEE,
  aparecen al final. Los componentes adicionales
  pueden incluir planes de seguridad, de
  prevención, de conversión de datos, de
  instalación y el plan de mantenimiento del
  sistema de información.

8
Técnicas de planificación
Unidad 2

• Las técnicas contribuyen en la realización del
  calendario.
• Diagramas de GANTT
• Es la técnica más utilizada cuando se pretende
  mostrar el tiempo previsto para diferentes tareas
  o actividades
• Se utiliza en proyectos pequeños (aproximadamente
  25 actividades)
• Permite visualizar los solapamientos de tareas,
  pero no la dependencia entre ellas
• Redes de precedencia
• La planificación se realiza en base a grafos.
• Las dos técnicas principales son
• PERT (Program Evaluation and Review Technique) y
• CPM (Crítical Path Method)
• Son convenientes cuando
• Todas las actividades están bien definidas
• Las actividades se pueden comenzar, interrumpir y
  realizar de forma separada dentro de una
  secuencia dada.
• Las actividades se pueden relacionar con otras
• Las actividades están organizadas de forma que se
  pueda seguir una secuencia.
• Una vez comenzada una actividad, debe continuar
  sin interrupción hasta su finalización.

9
Diagramas de GANTT
Unidad 2

• Es un diagrama de barras en forma de tabla donde
  se hace una referencia cruzada entre las tareas
  (filas) y los tiempos de duración de las mismas
  (columnas).
• Dentro del diagrama se pueden incluir fases que
  engloben diferentes tareas su duración es la
  necesaria para terminar dichas tareas.

10
Redes de precedencia
Unidad 2

• Se trata de un modelo gráfico que señala las
  relaciones secuenciales entre sucesos clave en un
  proyecto.
• Esta técnica permite visualizar el camino crítico
  que es la base para la planificación.
• Las reglas a considerar al desarrollar una red
  son
• Mínimo unos 20 eventos.
• Si se gestiona manualmente no mas de 300 eventos,
  de lo contrario utilizar algún software de
  gestión.
• Útil para proyectos con alto riesgo o
  incertidumbre, que involucren muchas personas u
  organizaciones, los técnicamente complejos o con
  tareas a realizar en distintas localizaciones
  geográficas.

11
Técnica PERT
Unidad 2

• Parte de la descomposición del proyecto en
  actividades.
• Las actividades ocurren entre dos sucesos
  (inicial y final), entendiendo como suceso un
  acontecimiento o punto temporal.
• La representación se realiza por medio de un
  grafo en donde las actividades se reflejan
  mediante arcos y los sucesos mediante vértices.
• El siguiente paso es la determinación de las
  relaciones entre las actividades.

A
1
2
Representación de actividad y suceso en PERT
12
Técnica PERT (2)
Unidad 2

• Tipos de relaciones de precedencia

Relaciones de precedencia lineales Para iniciar la actividad B es necesario haber finalizado la actividad A. El suceso 2 es suceso final de A y suceso inicio de B.
Relaciones de precedencia convergentes Para iniciar la actividad D es necesario haber finalizado las actividades A, B, y C.
Relaciones de precedencia divergentes Para poder iniciar cualquiera de las actividades B, C, o D, es necesario que haya finalizado la actividad A.
A
B
A
B
1
2
3
3
3
3
A
A
1
1
1
1
B
D
B
B
2
4
5
2
2
2
2
2
C
C
C
C
C
3
3
3
3
3
3
3
3
B
3
3
3
A
A
A
C
4
1
2
1
4
4
D
5
5
13
Técnica PERT (3)
Unidad 2

• Algunas combinaciones de precedencia pueden
  generar conflictos. Por ejemplo
• Las actividades A y B preceden a la actividad D.
• Las actividades A, B, y C preceden a la actividad
  E.
• Para resolver el problema se añade una actividad
  ficticia F, de duración cero.

A
D
D
A
B
B
F
E
C
E
C
Ejemplo de resolución del conflicto PERT
Ejemplo de conflicto PERT
14
Técnica PERT (4)
Unidad 2

• Ejemplo
• Supongamos que se tiene que realizar un proyecto
  que tiene las siguientes actividades A, B, C, D,
  E, F y G. Las relaciones entre las actividades
  son las siguientes
• A precede a B, C y D
• B precede a E
• C precede a F
• D precede a G
• E, F preceden a H
• Existen dos formas de manipular las relaciones de
  precedencia
• Matriz de encadenamientos
• Matriz de precedencia

Matriz de encadenamientos
Cuadro de relaciones de precedencia
15
Técnica PERT (5)
Unidad 2

• Ejemplo (continuación)
• La red resultante del ejemplo es la siguiente

3
E
B
6
F
C
H
1
2
4
A
D
7
G
5
16
Técnica PERT (6)
Unidad 2

• Asignación de los tiempos de cada actividad
• Estimación de tiempo pesimista (tp)
• Representa el tiempo máximo en que podría
  finalizarse la actividad si aparecen todas las
  circunstancias negativas que pueden darse durante
  su ejecución.
• Estimación de tiempo más probable (tn)
• Representa el tiempo normal de duración de la
  actividad considerando que hay problemas durante
  las actividades, pero no aparecen en su
  totalidad.
• Estimación de tiempo optimista (to)
• Representa el tiempo mínimo si no aparece ningún
  problema durante la ejecución de la actividad.
• Basándose en las estimaciones anteriores se puede
  trabajar con un tiempo simplificado PERT (T?) que
  se calcula como

17
Técnica PERT (7)
Unidad 2

• Cálculo de los tiempos más temprano posible
  (early) y más tardíos (late).
• El tiempo early del suceso j (TEj) será igual a
• TEj máx TEi Tij, ?j
• El Tiempo late (TLi) del último suceso coincide
  con su tiempo early y el resto de los tiempos
  late se calculan como
• TLi min TLj - Tij, ?j

Tiempo más temprano para comenzar la actividad A
(Tiempo early)
Tiempo más temprano para finalizar actividad A
Tiempo más tardío para comenzar la actividad A
(Tiempo late)
Tiempo más tardío para finalizar actividad A
TEi
TLi
TEj
TLj
A
Suceso i
Suceso j
Tij duración de la actividad que comienza en el
suceso i y finaliza en el suceso j
18
Técnica PERT (8)
Unidad 2

• Ejemplo
• Tomando la red del ejemplo anterior y suponiendo
  que se tienen calculados los tiempos PERT para
  cada actividad, el cálculo de los tiempos early
  es

3
13
19
6
6
E
5
21
B
1
2
4
8
7
3
6
0
8
14
H
22
F
C
A
7
5
24
D
9
5
13
G
TEj máx TEi Tij, ?j
19
Técnica PERT (9)
Unidad 2

• Ejemplo (continuación)
• El cálculo de los tiempos late es
• TLi min TLj - Tij, ?j
• La holgura total de una actividad está dada por
• HT TLj TEi - Tij
• Representa el número de unidades de tiempo que
  puede retrasarse la actividad sin que aumente la
  duración del proyecto.
• Las actividades que tienen un holgura total igual
  a cero se denominan actividades críticas.
• La unión de todas las actividades críticas forman
  el camino crítico.

3
13
15
6
6
E
5
21
21
B
10
10
1
2
4
8
7
3
6
0
8
14
14
8
0
H
F
C
A
7
5
24
24
D
9
5
13
15
G
20
Métricas del proyecto
Unidad 2

• Las métricas de software se refieren a un amplio
  elenco de mediciones para el software de
  computadora.
• Hay cuatro razones para medir los procesos del
  software, los productos y los recursos
• Caracterizar
• Para comprender mejor los procesos, los
  productos, los recursos y los entornos y para
  establecer la líneas base para las comparaciones
  con evaluaciones futuras.
• Evaluar
• Para determinar el estado con respecto al diseño.
  Las medidas dicen cuando el proyecto y los
  procesos están perdiendo la pista. También se
  evalúa para valorar el logro de los objetivos de
  calidad, el impacto de la tecnología y las
  mejoras en los productos y procesos.
• Predecir
• Para poder planificar. Medir para predecir
  implica aumentar la comprensión de las relaciones
  entre los procesos y los productos y la
  construcción de modelos de estas relaciones,
  logrando así establecer objetivos alcanzables
  para el coste, planificación y calidad. Además
  las predicciones y estimaciones basadas en datos
  históricos ayudan a analizar riesgos.
• Mejorar
• Cuando se recaba información cuantitativa es
  posible identificar obstáculos, problemas de
  raíz, ineficiencias y otras oportunidades para
  mejorar la calidad del producto y el rendimiento
  del proceso

21
Métricas del proyecto (2)
Unidad 2

• Una métrica es una medida cuantitativa del grado
  en que un sistema, componente o proceso posee un
  atributo dado IEEE93.
• Una métrica de software relata de alguna forma
  las medidas individuales sobre algún aspecto
  (número promedio de errores encontrados por
  revisión).
• La recopilación de medidas y desarrollo de
  métricas se utilizan para obtener indicadores.
• Un indicador proporciona una visión profunda que
  permite al gestor del proyecto o a los ingenieros
  de software ajustar el producto, el proyecto o el
  proceso para que las cosas salgan mejor
  Pressman, 2002.

Las métricas del software le permiten conocer
cuándo reír y cuándo llorar Tom Glib
No todo lo que se puede contar cuenta, y no todo
lo que cuenta se puede contar
22
Métricas del proyecto (3)
Unidad 2

• Las métricas del proyecto y los indicadores
  derivados de ellos son utilizados por un equipo
  de software y el gestor del proyecto para adaptar
  el flujo de trabajo del proyecto y las
  actividades técnicas.
• Regularmente las métricas de proyectos tienen su
  primera aplicación durante la estimación. Aquí se
  compara respecto a proyectos anteriores (esfuerzo
  y tiempo).
• Conforme avanza el proyecto se compara el tiempo
  y esfuerzo estimado con el tiempo y esfuerzo real
  para hacer los ajustes pertinentes.
• Durante el transcurso del trabajo técnico se
  miden índices de producción representados
  mediante páginas de documentación, horas de
  revisión, puntos de función, líneas fuente
  entregadas. Además se sigue la pista de los
  errores detectados durante todas las tareas.
• La recopilación de métricas técnicas durante la
  evolución de la especificación al diseño permite
  evaluar la calidad y proporciona indicadores para
  la generación y prueba del código.
• La utilización de métricas para el proyecto tiene
  dos aspectos
• Minimizar la planificación del desarrollo
  haciendo ajustes necesarios para evitar retrasos
  y reducir problemas y riesgos potenciales.
• Evaluar la calidad de los productos en el momento
  actual y cuando sea necesario, modificando el
  enfoque técnico que mejore la calidad.

23
Mediciones del software
Unidad 2

• Al igual que en el mundo físico, en el software
  se pueden categorizar dos formas de medir
• Medidas directas
• En el proceso coste y esfuerzo aplicado.
• En el producto líneas de código producidas,
  velocidad de ejecución, tamaño de memoria y los
  defectos detectados durante un periodo de tiempo
  establecido.
• Medidas indirectas
• Funcionalidad, calidad, complejidad, eficiencia,
  fiabilidad, facilidad de mantenimiento y muchas
  otras capacidades

24
Métricas orientadas al tamaño (LDC)
Unidad 2

• Provienen de la normalización de las medidas de
  calidad y/o productividad considerando el tamaño
  del software producido.
• Se pueden mantener registros históricos sencillos
  y crear una tabla de datos orientados al tamaño.
  El coste y esfuerzo reflejados en la tabla
  involucran todas las actividades de la ingeniería
  de software (no solo la codificación).
• Para desarrollar métricas que se puedan comparar
  entre distintos proyectos, se seleccionan las
  líneas de código (LDC) como valor de
  normalización.
• A partir de los datos de la tabla se pueden
  obtener métricas simples orientadas al tamaño.
• Errores por KLDC
• Defectos por KLDC
• páginas documentación x KLDC
• Errores persona-mes
• LDC por persona-mes
• por página de documentación

25
Métricas orientadas a la función
Unidad 2

• Se mide la funcionalidad a partir de mediciones
  directas.
• Se utiliza una medida llamada punto de función
  Albretch, derivado con una relación empírica
  según las medidas contables (directas) del
  dominio de la información y las evaluaciones de
  la complejidad del software.
• Se determinan cinco características de dominios
  de información
• Número de entradas de usuario
• Se cuenta cada entrada de usuario que proporciona
  diferentes datos orientados a la aplicación. Las
  entradas se deberían diferenciar de las
  peticiones, las cuales se cuentan de forma
  separada.
• Número de salidas de usuario.
• Se cuenta cada salida que proporciona al usuario
  información orientada a la aplicación. En este
  contexto la salida se refiere a informes,
  pantallas, mensajes de error, etc. Los elementos
  de datos particulares dentro de un informe no se
  cuentan de forma separada.
• Número de peticiones de usuario
• Una petición (consulta) de usuario se define como
  una entrada interactiva que produce la generación
  de alguna respuesta del software inmediata en
  forma de salida interactiva. Se cuenta cada
  petición por separado.
• Número de archivos
• Se cuenta cada archivo maestro lógico (esto es,
  un grupo lógico de datos que puede ser una parte
  de una gran pase de datos o un archivo
  independiente)
• Número de interfaces externas
• Se cuentan todas las interfaces legibles por la
  máquina (por ejemplo archivos de datos de cinta
  o disco) que se utilizan para transmitir
  información a otro sistema.

26
Métricas orientadas a la función (2)
Unidad 2

• Cuantificadas la cinco características del
  dominio de la información se debe determinar si
  una entrada en particular es simple, mediana o
  compleja. Sin embargo esta determinación suele
  ser subjetiva.
• Para calcular puntos de función (PF) también se
  debe calcular un factor de complejidad (Fi) según
  las respuestas (en un rango de 0 a 5) a una serie
  de preguntas.
• Así se tiene que

27
Métricas orientadas a la función (3)
Unidad 2

• Ejemplo
• Sistema hogar seguro
• La función gestiona la interacción con el
  usuario, aceptando una contraseña de usuario para
  activar/desactivar el sistema y permitiendo
  consultas sobre el estado de las zonas de
  seguridad y varios sensores de seguridad.
• Se identifican
• Tres entradas de usuario contraseña, interruptor
  de emergencia y activar/desactivar
• Dos consultas consulta de zona y consulta de
  sensor
• Un archivo datos de configuración del sistema
• Dos salidas de usuario mensajes y estados del
  sensor
• Cuatro interfaces externas sensor de prueba,
  configuración de zona, activar/desactivar y
  alerta de alarma.

Sensores
Sensor de prueba
Configuración de zona
Contraseña
Funciones de interacción del usuario con Hogar
Seguro
Usuario
Suponiendo
(moderadamente complejo)
Mensajes
Consulta de zona
Usuario
Consulta de sensor
Estado del sensor
Se tiene
Interruptor de emergencia
Activar/Desactivar
En base al valor calculado y los datos históricos
de que se dispongan, se pueden estimar LCD,
esfuerzo, etc. Por ejemplo un PF supone 60
líneas de código y un mes- persona produce 12 PF.
Cuál es tamaño y esfuerzo?.
Activar/desactivar
Subsistema de monitorización
Alerta de alarma
Contraseñas, sensores,
Datos de configuración del sistema
28
Modelo de estimación de costos (COCOMO)
Unidad 2

• COCOMO
• COnstructive COst MOdel
• Uno de los modelos más completos y detalladamente
  documentados para la estimación de costos por lo
  que también es el más conocido.
• Se trata de un modelado algorítmico de costos
• Se construye analizando los costos y atributos de
  los proyectos realizados.
• Se utiliza una fórmula matemática para predecir
  los costos basados en estimaciones de tamaño del
  proyecto (LDC), número de programadores y otros
  factores de los procesos y productos.
• La fórmula tiene un componente exponencial, lo
  que refleja el hecho de que los costos
  normalmente no se incrementan de forma lineal con
  el tamaño del proyecto.

29
Modelo de estimación de costos (COCOMO) (2)
Unidad 2
Ecuaciones de esfuerzo y tiempo de COCOMO BOEHM,
1981

• En su forma más general, la ecuación del esfuerzo
  se expresa como
• Esfuerzo A ? TamañoB
• Donde
• A es un factor constante que depende de las
  prácticas organizacionales locales y del tipo de
  software que se desarrolla.
• Tamaño es una valoración del tamaño del código o
  una estimación de la funcionalidad.
• B por lo general se encuentra entre 1 y 1.5
  refleja el esfuerzo requerido para proyectos
  grandes.
• Los tipos de proyectos pueden ser
• Orgánico.
• Desarrollo en un entorno estable, con poca
  innovación técnica, con pocas presiones de tiempo
  y tamaño relativamente pequeño
• Empotrado
• Desarrollo de software con requisitos muy
  restrictivos, con gran volatilidad de requisitos,
  complejo, en un entorno con gran innovación
  técnica.
• Semi-libre
• Situaciones entre el modo orgánico y el empotrado

La precisión de las estimaciones depende de la
Información disponible del sistema.
Conforme avanza el proceso, se dispone de más
información y por tanto las estimaciones son más
precisas.
4x 2x x 0.5x 0.25x
Factibilidad Requerimientos Diseño Código
Entrega
30
Modelo de estimación de costos (COCOMO) (3)
Unidad 2

• Se distinguen tres modelos distintos que se
  corresponden con diferentes cantidades de
  información disponible en las etapas del ciclo de
  vida
• COCOMO básico
• Para estimaciones iniciales moderadamente
  precisas al inicio del proyecto cuando no se
  dispone de detalles (por ejemplo, para empezar a
  negociar el contrato). Consiste en aplicar
  básicamente la ecuación del esfuerzo.
• COCOMO intermedio
• Cuando tenemos identificados los principales
  componentes del sistema (especificación de
  requisitos terminada). Se emplea para estimar
  el coste de los componentes y consiste en aplicar
  la ecuación del esfuerzo y hacer un ajuste
  incorporando 15 factores de coste.
• COCOMO detallado
• Cuando están identificados los componentes
  individuales del sistema (especificación de
  requisitos completa o diseño general bien
  definido). En este caso, el modelo COCOMMO
  proporciona tablas para poder distribuir las
  cantidades, ajustadas a los entorno, del esfuerzo
  y el tiempo de desarrollo del proyecto a lo largo
  de las distintas fases del mismo. Incluso permite
  refinar el ajuste de los factores para adaptarlo
  a las peculiaridades de cada etapa del proyecto

31
Modelo de estimación de costos (COCOMO) (4)
Unidad 2

• Ejemplo
• Se trata de estimar el esfuerzo de desarrollo de
  un sistema de comunicaciones de 30 KLDC, de alta
  complejidad. Afortunadamente se puede emplear
  personal de muy alta calificación con una gran
  experiencia específica en ese tipo de software.
  El coste del salario mensual de cada persona es
  de 1350 euros al mes.
• Aplicando COCOMO, se puede observar que el
  esfuerzo estimado será
• Esfuerzo 3.2 ? (30)1.05 113.79 PM
• Se aplicó el modo orgánico porque la aplicación
  no supera las 50 KLDC y no hay datos que señalen
  alguna complejidad especial.
• El ajuste del esfuerzo sería
• Esfuerzoa 113.79 PM ? 1.15 (complejidad) ?
  0.70 (personal) ? 0.91 (experiencia)
• Esfuerzoa 83.35 PM
• Coste 83.35 ? 1350 112522.5 euros
• Tiempo 2.5 ? 83.350.38 13.42 meses
• No Promedio de personas 83.35 / 13.42 6.2
  personas
• Sería más rentable emplear a personas de nivel
  medio cuyo salario es 1275 euros?
• Haciendo cálculos

32
Seguimiento y supervisión del proyecto
Unidad 2

• El seguimiento y supervisión del proyecto implica
  seguir, revisar y comparar los logros y los
  resultados obtenidos, frente a las estimaciones,
  los compromisos y los planes del proyecto,
  actualizándolos en función de estos resultados.
• Se puede decir que los objetivos que se pretenden
  con el seguimiento y supervisión del proyecto del
  software son
• Comparar los resultados actuales con los
  previstos
• Tomar acciones correctivas cuando existan
  desviaciones significativas de los planes
  previstos
• Acordar compromisos con el personal afectado por
  las acciones correctivas.

Si no sabes dónde estas, un mapa no te ayudará
Humphery, 1989
33
Seguimiento y supervisión del proyecto (2)
Unidad 2

• En la supervisión de los resultados actuales con
  los planes previstos se han de desarrollar
• Estándares que establezcan las condiciones o
  medidas que deben cumplirse cuando se realicen
  las diferentes tareas del proyecto.
• Establecer sistemas de supervisión y de informes,
  para lo cual hay que determinar los datos
  necesarios, quién los recibe y cuándo se reciben.
• Medir los resultados, lo que permite determinar
  la consecución o la desviación de los objetivos y
  estándares.
• Otros aspectos importantes a considerar son
• Seguimiento de costes y calendario
• Seguimiento de aspectos técnicos
• Generación de datos históricos
• Seguimiento de hitos

No tratare de estar bien hoy a expensas de mañana
34
Seguimiento y supervisión del proyecto (3)
Unidad 2

• Acciones correctivas
• Cuando no se cumplen los planes, se ejecutan
  diversas acciones correctivas que pueden incluir
  desde la revisión del plan de administración del
  proyecto hasta la replanificación del mismo.
• La razón principal para el seguimiento y el
  estado del progreso es detectar problemas y
  resolverlos lo más rápido posible.
• Los dos objetivos esenciales del seguimiento y la
  supervisión son
• Las acciones correctivas se realizan y gestionan
  cuando los resultados reales se desvían
  significativamente de los planes
• Los grupos y los individuos afectados llegan al
  acuerdo de los cambios en los compromisos.
• En general las acciones correctivas pueden ser
• Ajustar/añadir personal o número de hora extra
• Reasignar a los empleados para mejorar la
  eficiencia
• Reducir el alcance o contenido de una entrega
• Alargar o retrasar el calendario, negociando con
  el cliente.

35
Gestión de riesgos
Unidad 2

• Riesgo
• Se puede definir como cualquier elemento
  potencial que provoca resultados insatisfactorios
  en un proyecto.
• Es la forma de expresar la incertidumbre a lo
  largo del ciclo de vida la probabilidad de que
  en un punto del ciclo de vida no se alcancen los
  objetivos propuestos con los recursos disponibles
  AFSC, 1988.
• Estrategias de riesgo
• Reactivas
• Escuela de gestión del riesgo de Indiana Jones
  (no te preocupes, pensaré en algo).
• En el mejor de los casos, supervisa el proyecto
  en previsión de posibles riesgos y no se hace
  nada hasta que algo sale mal.
• Proactivas
• Inicia mucho antes de que inicie el trabajo
  técnico.
• Se identifican los riesgos potenciales, se valúa
  su probabilidad e impacto y se establece un orden
  de prioridad.
• Una vez hecho el paso anterior se establece un
  plan para controlar el riesgo.
• El objetivo principal es evitar el riesgo, sin
  embargo no se pueden evitar todos ellos, por lo
  que también es necesario un plan de contingencia.

Si usted no ataca los riesgos activamente, ellos
le atacarán activamente a usted. Tom Glib
36
Gestión de riesgos (2)
Unidad 2

• Categorías de riesgos
• Riesgos del proyecto
• Amenazan al plan del proyecto
• Si ocurren es probable que la planificación
  temporal del proyecto se retrace o que los costos
  aumenten.
• Identifican problemas potenciales de presupuesto,
  planificación temporal, personal, recursos,
  cliente y requisitos.
• Riesgos técnicos
• Amenazan la calidad y la planificación temporal
  del software.
• Si ocurre la implementación puede llegar a ser
  difícil o imposible.
• Identifican problemas potenciales de diseño,
  implementación, de interfaz, verificación y de
  mantenimiento.
• Riesgos del negocio
• Amenazan la viabilidad del software a construir.
• Los principales riesgos de negocios son
• Construir un producto o sistema excelente que
  nadie quiere en realidad (riesgo de mercado).
• Construir un producto que no encaja en la
  estrategia comercial general de la compañía
  (riesgo estratégico).
• Construir un producto que el departamento de
  ventas no sabe cómo vender.
• Perder el apoyo de una gestión experta debido a
  cambios en el personal o de enfoque (riesgo de
  dirección).
• Perder presupuesto o personal asignado (riesgos
  de presupuesto).

37
Gestión de riesgos (3)
Unidad 2

• Plan RSGR
• Es el Plan de Reducción, Supervisión y Gestión
  del Riesgo.
• La reducción del riesgo evita problemas
• La supervisión da seguimiento al proyecto con
  tres objetivos
• Evaluar cuando un riesgo previsto ocurre
• Asegurarse de que los procedimientos para reducir
  los riesgos se apliquen apropiadamente
• Recopilar datos históricos
• Puede llevarse a la práctica documentando cada
  riesgo en una hoja de información de riesgo.