Segundos apuntes del curso de Ingeniería de Software de la UTM (2071)

1. 2. ADMINISTRACIÓN DE PROYECTOS DE
SOFTWARE
INGENIERÍA DE SOFTWARE
UTM 2017
MARZO, 2015
1

2. TEORÍA GENERAL ADMINISTRATIVA
• La TGA es el campo del conocimiento humano que se ocupa del
estudio de la administración en general, independientemente si ésta
se aplica en organizaciones sin fines o con fines de lucro.
• Por lo tanto la TGA estudia la administración de las organizaciones.
2

3. DEFINICIÓN DE ADMINISTRACIÓN
• La palabra administración proviene del latín:
ad que significa dirección, tendencia.
minister que significa subordinación, obediencia.
• En ese sentido significa cumplimiento de una función bajo el mando de otro.
Por lo tanto, la administración, es el proceso cuyo objetivo es la coordinación
eficaz de los recursos de un grupo social para lograr sus objetivos con la
máxima productividad.
3

4. EL PROCESO ADMINISTRATIVO
4

5. CARACTERÍSTICAS DE LA ADMINISTRACIÓN
• La administración existe y puede ser aplicada dentro de cualquier colectivo o grupo social.
• La administración constituye un medio para lograr un fin y no un fin en sí mismo.
• La administración es un proceso dinámico en el que todas sus fases o etapas existen en
forma simultánea.
• La administración puede ser aplicada a todos los sistemas o subsistemas de la organización.
• Los principios administrativos deben adaptarse a las condiciones propias del grupo social
donde se apliquen.
• La rigidez en la administración es inoperante.
5

6. 2.1 GRÁFICAS PERT, GANNT
• Gráficas de actividades PERT (Program Evaluation and Review Technique)
• Gráficas utilizadas por los gestores de proyectos para mostrar las dependencias
entre las tareas que se tienen que completar. La gráfica muestra las tareas, el
tiempo esperado para completarlas y las dependencias entre ellas.
• La ruta crítica define el tiempo máximo requerido para completar el proyecto.
Es el camino más largo (en función del tiempo requerido para completar las
tareas) a lo largo del gráfico de actividades.
Ingeniería de Software, Sommerville, 7a Ed.
6

7. GRÁFICAS DE PERT
7

8. PASOS PARA ELABORAR UNA GRÁFICA PERT
1.Identifique las actividades específicas y las metas
2.Determine la secuencia correcta de las actividades
3.Construya el diagrama de la red
4.Estime el tiempo requerido para cada actividad
5.Determine la ruta crítica
6.Actualice la gráfica PERT mientras el proyecto se desarrolla
8

9. CONSIDERACIONES DE TIEMPO
• Tiempo Optimista
• Tiempo Probable
• Tiempo Pesimista
Tiempo = ( Optimista + 4 x Probable + Pesimista ) / 6
9

10. PARA CALCULAR LA RUTA CRÍTICA
• Fecha de Inicio Temprano
• Fecha de Finalización Temprana
• Fecha de Inicio Tardío
• Fecha de Finalización Tardía
• En términos prácticos, la ruta crítica se interpreta como la dimensión
máxima que puede durar el proyecto y las diferencias con las otras rutas
que no sean la crítica, se denominan tiempos de holgura.
10

11. BENEFICIOS DE LAS GRÁFICAS PERT
• Nos da una fecha de término esperada
• La probabilidad de término del proyecto antes de una fecha específica
• La ruta crítica que afectará la fecha de término
• El tiempo de holgura y la utilización de los recursos necesarios
• Fechas de inicio y término de cada actividad
NetMBA - PERT
http://www.netmba.com/operations/project/pert/
11

12. GRÁFICAS DE GANTT
• Gráficas de barras (Gantt)
• Gráfico utilizado por los gestores de proyectos para mostrar las
tareas del proyecto, la agenda asociada con estas tareas y las
personas que trabajarán en ellas.
• Muestra las fechas de comienzo y finalización de las tareas y la
asignación de personal contra una línea de tiempo.
Ingeniería de Software, Sommerville, 7a Ed.
12

13. GRÁFICAS DE GANTT
13

14. UNA GRÁFICA DE GANTT MUESTRA
• Cuáles son las actividades a realizar
• Cuándo empieza y cuándo termina cada actividad
• Cuánto debe de durar cada actividad
• Dónde se translapan las actividades y por cuánto tiempo
• El inicio y el final del proyecto
14

15. PLANEACIÓN DE TIEMPOS (GANTT)
15

16. GRÁFICA GANTT
16

17. VENTAJAS DE LAS GRÁFICAS GANTT
• Imagen sencilla de un proyecto complejo
• Ayuda a organizar ideas
• Mantiene un proyecto bajo control y administración
• Herramientas gráficas nos permite mantener una comunicación para
en equipo de trabajo de diferentes áreas de conocimiento
17

18. 2.2 MÉTRICAS DEL PROYECTO
La industria de software no cuenta con métricas y mediciones
estándares. Casi todas las métricas cuentan con múltiples definiciones
y reglas ambiguas … El resultado de estos problemas con las métricas
de software es la falta de datos sólidos empíricos sobre el costo del
software, el esfuerzo, los calendarios, la calidad y otras mediciones
tangibles. Strengths and Weaknesses of Software Metrics, 2006
http://swreflections.blogspot.mx/2012/05/software-development-
metrics-that.html

20. ¿CÓMO MEDIR EL DESARROLLO DE
SOFTWARE?
• Diferentes métricas para la
administración, el equipo y el
cliente
• Tamaño
• Dinero
• Tiempo
• Calidad

21. ¿CÓMO MEDIR?
el proceso - utilizado durante el desarrollo de software
el proyecto - específico a este desarrollo de software
el producto - el software producido

22. El proceso de software y las métricas del proyecto son mediciones
cuantitativas que permiten a los ingenieros de software tener una
idea clara sobre la eficiencia en el proceso de desarrollo de software.
En la administración del proyecto de desarrollo de software, estamos
enfocados en la productividad y las métricas de calidad. Existen
cuatro razones para medir el proceso de desarrollo de software (para
conocer, evaluar, predecir y mejorar).

23. 2.3 MEDICIONES DE SOFTWARE
¿Por qué medir el software?
Para indicar la calidad del producto
Para evaluar la productividad del equipo de trabajo
Para evaluar los beneficios derivados de métodos y herramientas
Como base para estimación de costo/ganancia

24. ¿QUÉ PUEDE SER MEDIDO?
• Mediciones directas
Líneas de Código (LOC), tiempo, costo, tamaño, errores, etc.
• Mediciones indirectas
Calidad, funcionalidad, complejidad, fiabilidad, eficiencia, etc

25. MÉTRICAS ORIENTADAS AL TAMAÑO (LOC)
• Basado en el tamaño del software desarrollado
• Normalmente utiliza LOC como valor de normalización
• Ventajas: se pueden contar, mucha documentación existente
• Desventajas: depende del lenguaje, depende el desarrollador
• Depende del proyecto, por lo que no es la mejor medida de medir
un software

26. ELEMENTOS CONSIDERADOS PARA MEDIR
POR TAMAÑO DEL SOFTWARE
• Productividad
• Calidad
• Costo
• Documentación
• Errores

27. MEDICIONES BASADAS EN FUNCIÓN
• Basada en la funcionalidad entregada como valor de normalización
del software
• La funcionalidad es una medida indirecta (subjetiva?)
• Los Puntos de Función (PF) es la medida que expresa la
funcionalidad de negocio de un sistema de información (como
producto) que se entrega al usuario. El costo de ese PF se calcula
basado en experiencia pasada en otros proyectos.

28. • Número de inputs de usuario
• Número de outputs de usuario: reportes, pantallas, mensajes de error, etc
• Número de peticiones de usuario: inputs de usuario que generan
respuestas inmediata del sistema
• Número de archivos
• Número de interfaces externas: todos los dispositivos periféricos que
pueda ser utilizado por el sistema

31. 2.5 MODELO DE ESTIMACIÓN DE COSTOS
COCOMO
El Modelo Constructivo de Costos (o COCOMO, por su acrónimo del
inglés COnstructive COst MOdel) es un modelo matemático de base
empírica utilizado para estimación de costos de software.
El primer modelo, COCOMO, incluye tres submodelos, cada uno
ofrece un nivel de detalle y aproximación, cada vez mayor, a medida
que avanza el proceso de desarrollo del software: básico, intermedio
y detallado.

32. MODELO COCOMO
El modelo COCOMO es un modelo empírico que se obtuvo
recopilando datos de varios proyectos grandes. Estos datos fueron
analizados para descubrir las fórmulas que mejor se ajustaban a las
observaciones. Estas fórmulas vinculan el tamaño del sistema y del
producto, factores del proyecto y del equipo con el esfuerzo
necesario para desarrollar el sistema.

33. RAZONES PARA EMPLEAR COCOMO
• Está bien documentado, es de dominio público y lo apoyan el
dominio público y las herramientas comerciales.
• Se ha utilizado y evaluado ampliamente.
• Tiene una gran tradición desde su primera versión en 1981 (Boehm,
1981), pasando por un refinamiento para el desarrollo de software en
ADA (Boehm y Royce, 1989), hasta su versión más reciente,
COCOMO 11. publicada en 2000 (Boehm el al., 2(00).

34. COCOMO BÁSICO
• Calcula el esfuerzo de desarrollo de software y su costo como una función del
tamaño del sistema expresado en DSIs (Delivered Source Instruction).
Normalmente se expresa en miles de líneas de código (eg. 2000 DSI o 2KDSI).
• Tres modos:
• Modo Orgánico (<50,000 DSIs)
• Modo Semi Desprendido (<300,000 DSIs)
• Modo Embebido (embebido dentro de hardware)

35. COCOMO INTERMEDIO
• Es una extensión del COCOMO Básico que calcula el costo del
desarrollo de software pero agrega una serie de factores que
determinará el esfuerzo y la duración del proyecto, tales como la
evaluación del personal y el hardware.

36. COCOMO DETALLADO
• Es una extensión del COCOMO Intermedio que agrega una serie de
multiplicadores para cada fase del proyecto para determinar los
costos de los factores para cada paso.
• COCOMO fue desarrollado por Barry Boehm en su libro de 1981
Software Engineering Economics.

37. PRESENTACIONES COCOMO EXPLICADO
• Tarea 2: Presentación de COCOMO funcional
• Fecha de Presentación: A partir del día viernes 24 de Abril, 2015
• Valor: 50% del 2nd Examen Parcial
• ¿En qué consiste? Hacer una presentación de 20 minutos sobre la
definición, las variables que involucra, su utilización y una
herramienta para el desarrollo del COCOMO que les corresponda.

38. 2.6 MÉTRICAS ORIENTADAS A LOS PUNTOS
DE FUNCIÓN
• Los Puntos de Función (FP) son medidas estándares que representan
el tamaño funcional de un software. De tal manera, un software
puede ser medido por medio de los puntos de función que el
software contenga en la aplicación.
• ¿Cuánto cuesta un FP? $250 USD por FP

39. PUNTOS IMPORTANTES A CONSIDERAR
• Se mide en base a la perspectiva del usuario (en base de lo que el
cliente solicitó)
• Independiente de la tecnología (se obtienen de pantallas, no del
código a desarrollar)
• Bajo costo (aproximadamente un 1% del costo total del software)
• Confiable en la industria

40. ¿QUÉ NOS PUEDE DETERMINAR LOS
PUNTOS DE FUNCIÓN?
Poder determinar:
• El costo del proyecto
• La duración del proyecto
• El tamaño del equipo de trabajo
Y entender las siguientes
métricas:
• La taza de errores del proyecto
• Costo de FP
• FP desarrollados por hora
• Los beneficios y productividad
de utilizar herramientas

41. 2.7 ANÁLISIS DE RIESGO
Una tarea importante del gestor de proyectos es anticipar los riesgos
que podrían afectar a la programación del proyecto o a la calidad del
software a desarrollar y emprender acciones para evitar esos riesgos.
Los resultados de este análisis de riesgos se deben documentar a lo
largo del plan del proyecto junto con el análisis de consecuencias
cuando el riesgo ocurra.
Identificar éstos y crear planes para minimizar sus efectos en el
proyecto se llama gestión de riesgos (Hall, 1998; Quid, 1999).

42. PROCESO DEL ANÁLISIS DE RIESGOS
1. Identificación de riesgos. Identificar los posibles riesgos para el proyecto, el
producto y los negocios.
2. Análisis de riesgos. Valorar las probabilidades y consecuencias de estos riesgos.
3. Planificación de riesgos. Crear planes para abordar los riesgos. ya sea para
evitarlos o minimizar sus efectos en el proyecto.
4. Supervisión de riesgos. Valorar los riesgos de forma constante y revisar los
planes para la mitigación de riesgos tan pronto como la infoonación de los
riesgos esté disponible.

43. PORCENTAJE DE RIESGOS
• La probabilidad del riesgo se puede valorar como muy bajo « 10%),
bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto
(>75%).
• Los efectos del riesgo pueden ser valorados como catastrófico, serio,
tolerable o insignificante.