2. ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE

INGENIERÍA DE SOFTWARE UTM 2017 MARZO, 2015

1

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

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

EL PROCESO ADMINISTRATIVO

4

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

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

GRÁFICAS DE PERT

7

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

CONSIDERACIONES DE TIEMPO

• Tiempo Optimista

• Tiempo Probable

• Tiempo Pesimista

Tiempo = ( Optimista + 4 x Probable + Pesimista ) / 6

9

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

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

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

GRÁFICAS DE GANTT

13

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

PLANEACIÓN DE TIEMPOS (GANTT)

15

GRÁFICA GANTT

16

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

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

¿CÓMO MEDIR EL DESARROLLO DE SOFTWARE?

• Diferentes métricas para la administración, el equipo y el cliente

• Tamaño

• Dinero

• Tiempo

• Calidad

¿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

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).

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

¿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

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

ELEMENTOS CONSIDERADOS PARA MEDIR POR TAMAÑO DEL SOFTWARE

• Productividad

• Calidad

• Costo

• Documentación

• Errores

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.

• 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

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.

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.

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).

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)

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.

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.

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.

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

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

¿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

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).

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.

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.