GESTIN DE PROYECTOS (Introduccin)

El propsito de este tema es conocer las tcnicas de gestin necesarias para planificar, organizar, supervisar y controlar proyectos de software. Estudiaremos los conceptos clave que llevan a una gestin efectiva de proyectos de software que son: Gestin de proyectos de software Mtricas de procesos Bases para una toma de decisiones de gestin efectivas Tcnicas que se emplean para estimar los costos Requisitos de recursos Como establecer un plan efectivo del proyecto

Las actividades de gestin llevan a:

una correcta supervisin, reduccin, y gestin de riesgo actividades necesarias para definir las tareas de un proyecto y establecer una programacin de proyecto realista.
1

TEMA 1
Objetivo de aprendizaje: El alumno conocer la terminologa necesaria para la gestin de proyectos Criterio de aprendizaje:

La gestin de proyectos de software es una actividad protectora dentro de la ingeniera del software. Empieza antes de iniciar cualquier actividad tcnica y contina a lo largo de la definicin, el desarrollo y el mantenimiento del software. El objetivo principal de un sistema de gestin de proyectos es entregar un producto con calidad.
2

Objetivos de un sistema de gestin de proyectos

Entorno necesario para la gestin de proyectos

La gestin eficaz de un proyecto de software se centra en las cuatro pes: El personal Debe organizarse en equipos eficaces, motivados para hacer un software de alta calidad y coordinados para alcanzar una comunicacin efectiva. Se deben cuidar las siguientes reas clave: RECLUTAMIENTO SELECCIN GESTION DE RENDIMIENTO ENTRENAMIENTO RETRIBUCION DESARROLLO DE LA CARRERA DISEO DE LA ORGANIZACIN Y DEL TRABAJO DESARROLLO CULTURAL ESPIRITU DE EQUIPO El elemento fundamental en todos los proyectos de software es el personal.

Entorno necesario para la gestin de proyectos

El proceso del sw lo componen los siguientes participantes : Gestores superiores. Definen aspectos de negocios que tienen una significativa influencia del proyecto. Gestores (tcnicos) del proyecto. Planificar, Motivar, Organizar y controlar a los profesionales que realizan el trabajo del Sw. Profesionales. Proporcionan las capacidades tcnicas necesarias para la ingeniera de un producto o aplicacin Clientes, que especifican los requisitos para la ingeniera de sw. Usuarios finales, que interaccionan con el sw una vez que se ha entregado para la produccin. Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona.

Organigramas de equipo
Descentralizado Democrtico (DD). Comunicacin horizontal Descentralizado controlado (DC). Comunicacin horizontal y vertical Centralizado Controlado (CC). Comunicacin vertical

Factores a considerar cuando se planifica el organigrama de equipos de ingeniera de Sw

La dificultad del problema que hay que resolver El tamao del programa resultante en lneas de cdigo o puntos de funcin El tiempo que el equipo estar junto El grado en que el problema puede ser modularizado. La calidad requerida y fiabilidad del sistema que se va a construir La rigidez de la fecha de entrega El grado de comunicacin requerido para el proyecto.

Tcnicas de coordinacin y comunicacin de proyectos

Formal, enfoque impersonal. Incluye documentos de Ing de Sw yentregas, memorandos tcnicos, entre otros. Formal, procedimientos interpersonales. Actividades de garanta de calidad aplicada a productos de ing de sw. Inspecciones de diseo y de cdigo Informal, procedimientos interpersonales. Reuniones de grupo para la divulgacin de informacin y resolucin de problemas. Comunicacin electrnica. Correo electrnico, boletines de noticias electrnicos, pginas web, sistemas de videoconferencia Red interpersonal. Discusiones informales con personas que no estn en el proyecto pero que pueden tener experiencia o una profunda visin que puede ayudar a los miembros del equipo.

El problema (segunda p)
Antes de planificar un proyecto se deben: ESTABLECER OBJETIVOS AMBITO SOLUCIONES ALTERNATIVAS IDENTIFICAR DIFICULTADES TECNICAS Y DE GESTION
8

El problema (segunda p)
Los objetivos identifican las metas generales del proyecto sin considerar como se conseguirn. El mbito identifica los datos primarios, funciones y comportamientos que caracterizan el problema e intenta abordar estas caractersticas de una manera cuantitativa. Se define respondiendo a las siguientes cuestiones: Contexto. Cmo encaja el sw a construir en un sistema, producto o contexto de negocios mayor y qu limitaciones se imponene como resultado del contexto? Objetivos de informacin. Qu objetos de datos visibles al cliente se obtienen del sw? Qu objetos de datos son requeridos de entrada? Funcin o rendimiento. Qu funcin realiza el sw para convertir los datos de entrada en una salida? Hay caractersticas de rendimiento especiales que abordar?

El problema (segunda p)
El mbito de un proyecto de software: Debe ser unvoco y entendible a niveles de gestin y tcnico. Deben establecerse explcitamente los datos cuantitativos (Ej. Nmero de usuarios simultneos,

tamao de la lista de correo, mximo tiempo de respuesta permitido)

Deben sealarse las restricciones y/o limitaciones (Ej.

el costo del producto limita el tamao de la memoria) Se describen los factores de reduccin de riesgos (Ej. los algoritmos deseados)

10

El proceso (tercera P)
Un proceso de Sw proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del sw. Actividades estructurales (aplicables a todos los proyectos) Diferentes conjuntos de tareas Actividades protectoras (garanta de la calidad de sw)

11

Actividades que debern realizarse al inicio de un proyecto de software

Seleccionar el modelo ms adecuado para el proyecto (secuencial lineal, de prototipo, RAD, incremental, en espiral, etc) Realizar un plan preliminar. (La planificacin de un

proyecto inicia con la maduracin del problema y del proceso. Todas las funciones que se deben tratar dentro de un proceso de ingeniera por el equipo de sw deben pasar por el conjunto de actividades estructurales que se han definido para una organizacin de sw) ver tabla
Iniciar la descomposicin del proceso.

12

Tabla 2. Maduracin del problema y del proceso ACTIVIDADES ESTRUCTURALES DE PROCESO EN COMN Comunicacin con el cliente Planificacin Anlisis de riesgo Ingeniera

Tareas de ingeniera del software

Funciones del producto

Introduccin de texto

Edicin y formateo

Edicin automtica de copia

Capacidad de diseo de pgina

Indexacin automtica

Administracin de archivos

Produccin de documentos

Actividades de gestin de proyectos (cuarta p)

Medicin y mtricas Estimacin Anlisis de riesgos Planificacin del programa Seguimiento y Control

14

1.3 Qu se debe pedir a un gestor de proyectos

Que cumpla con el modelo de gestin MOI, de Jerry Weinberg Motivacin Habilidad para motivar al personal tcnico para que produzca conforme a sus mejores capacidades Organizacin. La habilidad para moldear procesos existentes que permita al concepto inicial transformarse en un proyecto final. Ideas o innovacin. La habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban trabajar dentro de los lmites establecidos para un producto o aplicacin de sw particular.
15

Caractersticas que definen a un gestor de proyecto eficiente

Resolucin del problema (Diagnosticar aspectos tcnicos y de organizacin) Dotes de gestin (Tomar las riendas) Incentivo de los logros (Recompensar) Influencia y construccin de espritu de equipo. Existe una ley de liderazgo que dice El lider ensea lo que sabe pero reproduce lo que l es.
16

1.4 Software de gestin de proyectos

El software de gestin se refiere a sistemas internos, que se utilizan en una nica empresa. Funciona sobre un hardware limitado, quizs un nico computador. Los ejemplos tpicos son sistemas de control de nminas, contabilidad o control de almacn. El software IS, IT y MIS se tratan como pertenecientes a un grupo ms general, el software de gestin. Se puede usar el Project para administracin de proyectos.
17

TEMA 2
Objetivo de aprendizaje: El alumno conocer y aplicar las etapas de gestin de proyectos para un desarrollo efectivo Criterios de aprendizaje: 2.1 Etapas de la gestin de proyectos.
18

Comienzo del Proyecto de Software

Antes de poder empezar a planificar un proyecto se debe:
Establecerse el mbito y los objetivos Considerarse soluciones alternativas Identificarse las restricciones tcnicas y de gestin. Sin esta informacin, es imposible obtener: Estimaciones de costo razonables y precisas Una identificacin realista de las tareas del proyecto plan de trabajo adecuado que proporcione una indicacin significativa del progreso.
19

Comienzo del Proyecto de Software

El desarrollador del software y el cliente deben ponerse de acuerdo para definir el mbito y los objetivos del proyecto. Los objetivos identifican los fines globales del proyecto sin considerar cmo se llegaran a esos fines. El mbito identifica las funciones primordiales que debe llevar a cabo el software y, lo que es ms importante, intenta limitar esas funciones de manera cuantitativa. Una vez entendidos los objetivos y el mbito del proyecto, se han de considerar soluciones alternativas. Las alternativas han de permitir a los gestores y a los desarrolladores seleccionar el mejor enfoque, dadas las restricciones impuestas por las fechas tope de entrega, los lmites propuestos, la disponibilidad de personal, las interfaces tcnicas y una mirada a otros factores.

20

Medicin y mtricas
La medicin y las mtricas nos ayudan a entender tanto el proceso tcnico que se utiliza para desarrollar un producto, como el propio producto. El proceso se mide para intentar mejorarlo. El producto se mide para intentar aumentar su calidad. La necesidad de medicin nos permite cuantificar y gestionar de forma ms efectiva.
21

Estimacin
Una de las actividades cruciales del proceso de gestin de proyectos de software es la planificacin. Cuando se planifica un proyecto de software se tiene que obtener estimaciones de:
Esfuerzo humano requerido (normalmente en personas-mes) Duracin cronolgica del proyecto (en fechas) Costo (en dlares).
22

Mtodos de estimacin
Experiencia pasada .- Si un nuevo proyecto es bastante similar en tamao y funcin a un proyecto pasado, es probable que el nuevo proyecto requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente el mismo tiempo y que cueste aproximadamente lo mismo que el trabajo anterior.
23

Mtodos de estimacin
Se han desarrollado varias tcnicas de estimacin para el desarrollo de software, todos tienen en comn los siguientes atributos:
Se ha de establecer de antemano el mbito del proyecto como base para la realizacin de estimaciones y sus puntos dbiles El proyecto se desglosa en partes ms pequeas que se estiman individualmente. Muchos gestores aplican varias tcnicas diferentes de estimacin, utilizando unas para verificar los resultados de otras.
24

Anlisis de riesgos
Es algo vital para una buena gestin del proyecto de software Sin embargo, se emprenden muchos proyectos sin que se hayan considerado los riesgos concretos. El anlisis de riesgos consiste en una serie de pasos de control de riesgos que nos permiten combatirlos: Identificacin de riesgos Clculo de riesgos, Priorizacin de riesgos Estrategias de control de riesgos Resolucin de riesgos Supervisin de riesgos. Estos pasos se aplican a lo largo del proceso de ingeniera de software.
25

Planificacin
Cualquier proyecto de software tiene su planificacin. La planificacin de un proyecto de software no difiere de la planificacin de cualquier proyecto de ingeniera.

Se identifica una serie de tareas del proyecto. Se establecen interdependencias entre las tareas. Se estima el esfuerzo asociado con cada tarea. Se hace la asignacin del personal y de otros recursos. Se crea una red de tareas. Se desarrolla la agenda de fechas.
26

La planeacin de un proyecto

Algunas ideas importantes

Los planes son tiles, pero planear no lo es todo Dwight Eisenhower

Si no tenemos un plan, el control es imposible James Lewis No sabemos a donde vamos, pero estamos yendo muy rpido

El crculo vicioso
No hay tiempo para planear Porque estoy apagando fuegos Porque estoy ocupado

Apagafuegos

Fallas mas comunes en la planeacin

No involucrar a las personas que implementarn el plan, en el proceso de planeacin Se considera que las personas dedican el 100% de su tiempo al proyecto

Desarrollo efectivo de actividad 65% Actividad administrativa 25% Otras Actividades 10%

Los efectos de los errores

Falta de compromiso del equipo o persona en particular

Estimaciones Fallidas
Falta detalle en la descripcin de las actividades Crean expectativas inadecuadas

El libro del Proyecto

Es un cuaderno donde se registra la historia del proyecto desde su planeacin hasta su conclusin Se registra el conocimiento y la experiencia Es responsabilidad del AP Es un documento vivo, dinmico, se actualiza diariamente

Contenido del Libro del Proyecto

- Descripcin del problema: "La solucin correcta pero el problema equivocado"

- La misin del proyecto: Quien es el cliente y cual es el objetivo global

- Alcance: Que se har y que no se har - Objetivos: Tcnicos, econmicos y de desempeo

Contenido del Libro del Proyecto

- Enfoque a aplicar: Subcontratacin, metodologas, prcticas, hacer contra comprar, etc. - Requisitos contractuales: Los entregables: documentacin, prototipos, cotizaciones, reportes de avance, etc.

- Especificaciones tcnicas de los entregables

Contenido del Libro del Proyecto

- Estructura de actividades WBS (WorkBreakdownSchedule) es el corazn del plan - Fechas meta: Con la liga entre compromisos vs. entregables - Recursos necesarios: Diagrama de carga de trabajo, recursos tecnolgicos, recursos financieros

Contenido del Libro del Proyecto

- Sistema de control: Como se controlar el avance y cumplimiento de las actividades - Areas de riesgo: La identificacin de los obstculos y amenazas - Contribuyentes: Las personas que aportarn ideas, conocimiento, especificaciones, decisiones, en general valor agregado.

La administracin de Cambios
- Los cambios deben ejecutarse con la aprobacin de los clientes principales - El AP debe identificar cuales son los cambios "significativos" - Cuidado con el fenmeno de la "Amnesia"

La planeacin contesta a:
- Que debe hacerse: objetivos, alcance y magnitud - Cmo debe hacerse: estrategia del proyecto - Quien debe hacerlo: roles y responsabilidades

- Cundo debe hacerse: Programacin de actividades

La planeacin contesta a:
- Cunto costar: el presupuesto

- Que tan bueno debe ser: el nivel de calidad - Que nivel de desempeo: las especificaciones del "performance" - Que fuerzas: para sacarles provecho

La planeacin contesta a:
- Que debilidades: riesgos, obstculos, para minimizarlos - Que oportunidades: para capitalizarlas

Puntos Crticos
- Desarrollo de la descripcin del problema

- Proceso de fragmentacin de la idea general a una proposicin mas particular

- Los problemas abiertos: no tienen una nica respuesta correcta

Los medios para definir un problema

- Escriba una descripcin del problema - Complete las siguientes frases: - Hay mas maneras de ver el problema, tambin se puede definir como . . . - . . . Pero el punto principal del problema es . .. - Lo que pudiramos hacer . . . - El problema es parecido a. . . Vuelva a iniciar el proceso

Proceso de Identificacin de Problemas

Existe un problema

Restricciones estticas y claras

si

Problema cerrado algo est roto

no
Problema abierto

entender necesidades del cliente inventar un producto

Pasos bsicos del proceso de planeacin

- Definicin del problema
- Estime: duracin, costos, recursos

- Preparacin del plan maestro

- Definir la organizacin del equipo - Prepare el libro del proyecto - Obtenga la aprobacin

Lecciones aprendidas
- Si no se tiene un plan, el control no es posible
- Las personas que ejecutarn el plan, deben participar en su preparacin - Utilice un libro de proyectos para documentarlas actividades - El plan debe ser aprobado por aquellos que tiene inters en su ejecucin

Lecciones aprendidas
- Cuando haya cambios significativos, deben ajustarse las variables y comunicar los efectos a los clientes

- Realice un anlisis de fuerzas, debilidades, riesgos y oportunidades

- Defina claramente el problema antes de iniciar la planeacin

Seguimiento y Control
El seguimiento se puede hacer de diferentes maneras: Realizando reuniones peridicas del estado del proyecto en la que todos los miembros del equipo informan del progreso y de los problemas Evaluando los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniera de software. Determinando si se han conseguido los hitos formales del proyecto en la fecha programada Comparando la fecha real de inicio con las previstas para cada tarea del proyecto listada en la tabla del proyecto Reunindose informalmente con los profesionales del software para obtener sus valoraciones subjetivas del progreso hasta la fecha y los problemas que se avecinan

47

Seguimiento y Control
El control lo usa el gestor para administrar los recursos del proyecto, enfrentarse a los problemas y dirigir al personal del proyecto. Si las cosas van bien el control es liviano. Pero cuando aparecen los problemas, el gestor debe ejercer el control para solucionarlos tan pronto como sea posible.
48

2.2 Medidas de fiabilidad del software y mtricas

2.2.1 Conceptos bsicos

Medida: Proporciona una indicacin cuantitativa de extensin, cantidad, dimensiones, capacidad y tamao de algunos atributos de un proceso o producto. Medicin: Es el acto de determinar una medida, aparece como resultado de la recopilacin de uno o varios aspectos de los datos. Mtrica: Medida cuantitativa del grado en que un sistema, componente o proceso, posee un atributo dado. Mtrica del software: Relata de alguna forma las medidas individuales sobre algn aspecto. Indicador: Es una mtrica o una combinacin de mtricas que proporcionan una visin profunda del proceso de software, del proyecto de software o del producto en si, permite hacer ajustes al proceso, proyecto o producto para que las cosas salgan mejor.
Nota: La mtrica proporciona al gestor una visin ms profunda y adems le llevar a una toma de decisiones ms fundamentada.
49

Medidas de fiabilidad del software y mtricas

Los indicadores de proyecto permiten al gestor de proyectos:
Evaluar el estado del proyecto en curso Seguir la pista de los riesgos potenciales Detectar las reas de problemas antes de que se conviertan en crticas Ajustar el flujo y las tareas del trabajo Evaluar la habilidad del equipo del proyecto Controlar la calidad de los productos de trabajo de la ingeniera de software.

50

2.2.2 Mtricas del proceso

El proceso es el nico factor de los controlables al mejorar la calidad del software y su rendimiento como organizacin.

51

Fig. 2.1 Determinantes de la calidad del software y de la efectividad de organizacin

Producto

Caractersticas del cliente

Proceso

Condiciones del negocio

Personas

Entorno de desarrollo

Tecnologa

52

Mtricas del proceso

La destreza y la motivacin han mostrado ser el nico factor realmente influyente en calidad y en rendimiento. La complejidad del producto puede tener un impacto sustancial sobre la calidad y el rendimiento del equipo. La tecnologa que puebla el proceso tambin tiene su impacto. La eficacia de un proceso de software se mide indirectamente. Mtricas segn los resultados que provienen del proceso: Errores detectados antes de la entrega del software Defectos detectados e informados por los usuarios finales Productos de trabajo entregado Esfuerzo humano Tiempo consumido

53

Mtricas del proceso

Las mtricas de proceso tambin se extraen midiendo las caractersticas de tareas especficas de la ingeniera del software Medir tiempo y esfuerzo de llevar a cabo las actividades de proteccin y las actividades genricas de ingeniera del software Existen diferentes tipos de mtricas privadas y publicas Ejemplo de mtricas privadas: ndices de defectos (general o por modulo) Errores encontrados durante el desarrollo
54

Proceso Personal del Software (PSP)

El proceso personal del software (PSP) es un conjunto estructurado de descripciones de proceso, mediciones y mtodos que pueden ayudar a que los ingenieros mejoren su rendimiento personal Algunas mtricas de proceso son privadas para el equipo del proyecto de software, pero publicas para todos los miembros del equipo. Las mtricas pblicas asimilan informacin que originalmente era privada. Los ndices de defectos a nivel de proyecto, el esfuerzo, el tiempo y los datos afines se recopilan y se evalan en un intento de detectar indicadores que puedan mejorar el rendimiento del proceso organizativo.
55

Beneficios de las mtricas

Las mtricas del proceso del software pueden proporcionar beneficios significativos a medida que una organizacin trabaja por mejorar su nivel global de madurez del proceso, para lograr este beneficio es necesario que el gestor: Utilice el sentido comn y una sensibilidad organizativa al interpretar datos de mtricas Proporcione una retroalimentacin regular a particulares y equipos que hayan trabajado en la recopilacin de medidas y mtricas. No utilice mtricas para evaluar a particulares Trabaje con profesionales y equipos para establecer objetivos claros y mtricas que se vayan a utilizar para alcanzarlos No utilice nunca mtricas que amenacen a particulares o equipos Los datos de mtricas que indican un rea de problemas no se deberan considerar negativas sino como un indicador de mejora del proceso No se obsesione con una sola mtrica y excluya otras mtricas importantes
56

Mejora Estadstica del Proceso de Software (MEPS)

A medida que una organizacin esta ms a gusto con la recopilacin y utiliza mtricas de proceso, la derivacin de indicadores simples abre el camino hacia un enfoque llamado mejora estadstica del proceso de software (MEPS) el cual utiliza el anlisis de fallos del software para recopilar informacin de errores y defectos encontrados al desarrollar y utilizar una aplicacin de sistema o producto.
57

Anlisis de fallo
El anlisis de fallo funciona de la siguiente manera: Todos los errores y defectos se categorizan por origen Se registra tanto el costo de corregir cada error como el del defecto El numero de errores y defectos de cada categora se cuentan y se ordenan en orden descendente Se computa el costo global de errores y defectos de cada categora Los datos resultantes se analizan para detectar las categoras que producen el costo ms alto para la organizacin Se desarrollan planes para modificar el proceso con el intento de eliminar ( o reducir la frecuencia de apariciones) la clase de errores y defectos que sean ms costosas

58

Causas de defectos y su origen para cuatro proyectos de software

I nt er f az sof t war e 6% I nt er f az har wdwar e 8% Logi ca 20%

Origen de errores / defectos Especificacin / requisitos Diseo

Compr obaci n de er r or es 11%

Cdigo

M anej o de dat os 11%

I nt er f az de usuar i o 1 2% E st ndar es 7%

E speci f i caci ones 25%

59

Un diagrama en espina que muestra las causas de una clase de efectos

Perdido Ambiguo

Defectos de especificacin Cliente equivocado consultado El cliente dio informacin equivocada

Peticiones inadecuadas
Informacin anticuada utilizada

Incorrecto

Cambios

60

Utilizacin de las mtricas

Las mtricas del proceso de software se utilizan para propsitos estratgicos. Las mtricas del proyecto de software son tcticas, es decir, las mtricas de proyectos y los indicadores derivados de ellos los utilizan un gestor de proyectos y un equipo de software para adaptar el flujo de trabajo del proyecto y las actividades tcnicas. Las mtricas recopiladas de proyectos anteriores se utilizan como una base desde la que se realizan estimaciones del esfuerzo y del tiempo para el actual trabajo de software. El gestor de proyectos utiliza estos datos para supervisar y controlar el avance. Cuando va evolucionando el software desde la especificacin al diseo se recopilan las mtricas tcnicas.

La utilizacin de mtricas para el proyecto tiene dos aspectos fundamentales:

Minimizar la planificacin de desarrollo guiando los ajustes necesarios que eviten retrasos y mitiguen problemas y riesgos potenciales Para evaluar la calidad de los productos en el momento actual y cuando sea necesario, modificando el enfoque tcnico que mejore la calidad
61

Reduccin del costo del proyecto

Conforme mejora la calidad, se reducen los errores y la cantidad de trabajo. Esto lleva a una reduccin del costo global del proyecto. Otro modelo sugiere que todos los proyectos deban medir Entradas: La dimensin de los recursos que se requieren para realizar el trabajo (ejemplo: personas, entorno) Salidas: medidas de las entregas o productos creados durante el proceso de ingeniera de software Resultados: medidas que indican la efectividad de las entregas.

62

2.2.3 Mediciones del software

Las mediciones del mundo fsico se clasifican en: Medidas directas: Por ejemplo la longitud de un tornillo. En el software se incluyen el costo y el esfuerzo aplicados (la inversin y mano de obra) Medidas indirectas: Por ejemplo la calidad de los tornillos producidos, medidos contando los artculos defectuosos. En el software se incluyen las lneas de cdigo (LDC) producidos, velocidad de ejecucin, tamao de memoria y los defectos informados durante un tiempo establecido. Eficiencia Fiabilidad Factibilidad de mantenimiento, etc. <<capacidades>>
63

Mtricas orientadas al tamao.

Las mtricas de software conectadas al tamao provienen de la normalizacin de las medidas de calidad y/o productividad considerando el tamao del software que se haya producido. Para desarrollar mtricas que se puedan comparar entre distintos trayectos, se selecciona las lneas de cdigo como valor de normalizacin...
Un conjunto de mtricas simples orientadas al tamao: Errores por KLDC ( miles de lneas de cdigo , KiloLDC) Defectos por KLDC $ por LDC Paginas de documentacin por KLDC.
64

Mtricas orientadas al tamao.

Las mtricas orientadas por tamaos no estn aceptadas universalmente como el mejor modo de medir el proceso de desarrollo del software debido a que mucho modelos de estimacin de software existentes utilizan LDC o KLDC como clave de entrada, y que ya existe un amplio conjunto de datos y de literatura basados en LDC. En el lado opuesto las medidas de LDC son dependientes del lenguaje de programacin que perjudican a los ms cortos, pero bien diseados. Los lenguajes orientados objetos estn orientados a reutilizar cdigo reduciendo con esto las LDC por lo que estn en desventaja para este criterio
65

Mtricas orientadas a la funcin

Utilizan una medida de la funcionalidad entregada por la aplicacin como valor de normalizacin ya que la funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante otra medida directa. Los puntos de funcin se derivan con una relacin emprica segn las medidas contables (directas) del dominio de informacin del software y las evaluaciones de la complejidad del software.
66

Mtricas orientadas a la funcin

Se determina 5 caractersticas de dominios de informacin. Numero de entradas de usuario. Se cuenta cada entrada de usuario que propicia diferentes datos orientados al a aplicacin. Las entradas se deberan diferenciar de las peticiones, las cuales se cuentan de forma separada. Numero de salida de usuario se cuenta cada salida que proporciona al usuario informacin orientada a la aplicacin, salida se refiere a informes, pantallas, mensajes de error etc. Numero de peticiones de usuario se define como una entrada interactiva que produce la generacin de alguna respuesta del software inmediata en forma de salida interactiva. Se cuenta cada peticin por separado. Numero de archivos se cuenta cada archivo maestro lgico (esto es un grupo lgico de datos que pueden ser una parte de una gran base de datos o un archivo independiente). Numero de interfaces externas se cuenta todas las interfaces legibles por la maquina por (ejemplo archivo de datos de datos de cinta o disco.) Que se utiliza para trasmitir informacin a otro sistema.

Una vez que se hayan recopilado los datos anteriores se calcula el punto de funcin : PF = cuenta-total * [ 0,65 + 0,01 * Fi] Donde Fi ( i = 1 a 14 ) son valores de ajuste de la complejidad .
67

Mtricas ampliadas de punto de funcin

Se dise originalmente para aplicase a aplicaciones de sistemas de informacin de gestin. Inadecuada para muchos sistemas de ingeniera y sistemas empotrados porque se enfatizo en la dimensin de los datos para la exclusin de dimensiones funcionales y de comportamiento.

Se ha propuesto un nmero de extensiones a la mtrica del punto de funcin bsica algunas son:
punto de caractersticas la cual se puede aplicar a sistemas y aplicaciones de sistemas de software, se acomoda a las aplicaciones en donde la complejidad del algoritmo es alta ( aplicaciones de tiempo real, de control de procesos, y empotradas), cuenta con una caracterstica nueva del software , los algoritmos. Un algoritmo se define como un problema de clculo limitado (invertir una matriz, decodificar una cadena de bits, o manejar una interrupcin). Boeing desarrollo otra extensin al punto de funcin para sistemas en tiempo real y productos de ingeniera, el nombre que se le ha dado es de punto de funcin 3D enfatizan capacidades de funcin y control.
68

Punto de funcin 3D
Las caractersticas de las tres dimensiones del software se cuentan, cuantifican y transforman La dimensin de los datos. La cuenta de los datos internos ( por ejemplo archivos) y los datos externos ( entradas , salidas peticiones y referencias externas). La dimensin funcional se mide considerando el numero de operaciones requeridas para transformar datos de entrada en datos de salida La dimensin de control se mide contando el numero de transiciones entre estados. Un estado representa algn modo de comportamiento externamente observable, y una transicin ocurre con el resultado de algn suceso que cambia el modo de comportamiento del sistema o del software. Por ejemplo un telfono mvil contiene software que soporta funciones de marcado automtico.

69

Factores importantes que inciden en la productividad del software

Factores humanos. El tamao y la experiencia de la organizacin de desarrollo Factores del problema. La complejidad del problema que se debe resolver y el nmero de cambios en las restricciones o los requisitos del diseo Factores del proceso. Tcnicas del anlisis y diseo que se utilizan, lenguajes y herramientas CASE y tcnicas de revisin Factores del producto. Fiabilidad y rendimiento del sistema basado en computadora Factores del recurso. Disponibilidad de herramientas CASE y recursos de hardware y software. Si uno de los factores de productividad esta por encima de la media (altamente favorable) para un proyecto dado, la productividad de desarrollo del software ser significativamente ms alta que el mismo factor por debajo de la media (desfavorable)

70

2.2.4 Mtricas para la calidad del software

El objetivo primordial de la Ingeniera de Software es Producir un

sistema, aplicacin o producto de alta calidad

Para ello es necesario aplicar: Mtodos efectivos para la elaboracin del software y Herramientas modernas que faciliten la elaboracin del mismo. Como se mide la calidad de un sistema? A travs de la descripcin del problema. El modelo de solucin. El cdigo del programa y Por la pruebas que se realicen. Los errores se pueden medir: Por hora de revisin y Por hora de prueba Lo que nos da la llamada: Eficiencia de la eliminacin de defectos (EED)

71

2.2.4.1 Visin general de los factores que afectan a la calidad

Para realizar la evaluacin del software, es necesario tener en cuenta: La operacin del producto: Esto se logra utilizndolo. La revisin del producto: Hay que cambiarlo para saber si no es necesaria una modificacin o adecuacin. La transicin del producto: Que se puedan hacer modificaciones para adecuarlo en cualquier momento. A estos tres elementos se les conoce como Marco de Trabajo. El marco de trabajo proporciona: Los mecanismos de identificacin de lo importante como es:

El medio para evaluar cuantitativamente. La interaccin del personal. La identificacin de estndares.

La facilidad de mantenimiento (preventivo y correctivo) y La facilidad de transportabilidad (la aplicacin en diferentes plataformas).

72

2.2.4.2

Medida de la calidad

La correccin, facilidad de mantenimiento, integridad y facilidad de uso proporcionan indicadores tiles para el quipo que en su proyecto trata de tomar medidas de calidad del software. Correccin Es el grado en el que el software lleva a cabo su funcin requerida. La medida ms comn de correccin son los defectos por KLDC (miles de lneas de cdigo), en donde un defecto se define como una falta verificada conforme los requisitos.

73

Medida de la calidad
Facilidad de mantenimiento Es la facilidad con la que se puede corregir errores en un programa Se puede adaptar si su entorno cambia o mejora si el cliente desea un cambio de requisitos. Como no existe forma de medir directamente la facilidad del mantenimiento, se deben utilizar medidas indirectas. Ejemplo una mtrica orientada al tiempo TMC (tiempo medido de cambio).- Tiempo que se tarda en hacer la peticin de cambio, en disear una modificacin adecuada, en implementar el cambio, en probarlo y en distribuir el cambio a todos los usuarios. Los programas que son ms fciles de mantener tendrn un TMC mas bajo que aquellos que son ms difciles de mantener.

HITACHI ha utilizado una mtrica orientada al coste para la capacidad de mantenimiento llamada DESPERDICIOS el coste en corregir defectos encontrados despus de haber distribuido el software a los usuarios finales. Cuando la proporcin de desperdicios en el coste global del proyecto se representa como una funcin del tiempo, el gestor puede determinar si la facilidad de mantenimiento total del software producido por una organizacin en desarrollo esta mejorando.

74

1 amenaza* (1 seguridad)

Medida de la calidad
Integridad Mide la habilidad de un sistema para resistir ataques (tanto accidentales como intencionados) contra su seguridad, el ataque se puede realizar en cualquiera de los tres componentes del software: programas datos y documentos. Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad. Amenaza es la probabilidad (que se puede estimar o deducir de la evidencia emprica) de que un ataque de un tipo determinado. La seguridad de la probabilidad de que pueda repeler el ataque de un ataque de un tipo determinado. La integridad del sistema se puede definir como: Integridad =

1 amenaza* (1 seguridad)

Donde se suma la amenaza y la seguridad para cada tipo de ataque.

75

Medida de la calidad
Facilidad de uso Sigue la filosofa del trmino amigable con el usuario. La facilidad de uso es un intento de cuantificar lo amigable que puede ser con el usuario y se puede medir en funcin de cuatro caractersticas: Habilidad intelectual y/o fsica requerida para aprender el sistema. El tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema. Aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida cuando alguien utiliza el sistema moderada y eficientemente. Valoracin subjetiva (a veces obtenida de cuestionarios) de la disposicin de los usuarios hacia el sistema.

76

2.2.4.3 Eficacia de la Eliminacin de Defectos (EED)

Es la habilidad de filtrar las actividades de la garanta de la calidad y control Al aplicarse todas las actividades. De forma global en un proyecto: EED = E/(E + D) E = numero de errores encontrados antes de entregare al Usuario Final D = defectos entregados despus de la entrega EED = 1 D puede tender a 1 Si E aumenta D disminuye EED se utiliza tambin para evaluar al equipo que tan eficientes son encontrando errores antes de pasar a otra parte de la ingeniera de software Anlisis de los requisitos produce un modelo de anlisis que se puede revisar para encontrar y corregir errores, si no se encuentran aqu se pasa a la tarea de diseo. EED, = E, (E,+ E, + 1) E, = n errores encontrados durante la actividad i de ingeniera de software Ei + 1 = n errores durante la ingeniera de software El objetivo de la ingeniera de software es ver que EED se aproxime o llegue a 1
77

2.2.5 Integracin de las mtricas dentro del proceso del software

La mayora de los desarrolladores de software todava no miden, y por desgracia la mayora no desean ni comenzar. Por qu necesitamos hacer esto? No entiendo por qu, se queja un profesional saturado de trabajo. Por qu es tan importante medir el proceso de ingeniera de software y el producto (software) que produce? La respuesta es relativamente obvia. Si no se mide, no hay forma real de determinar si se est mejorando. Y no se est mejorando, se est perdido
78

Integracin de las mtricas dentro del proceso del software

La medicin es una de las medicaciones que pueden ayudar a curar el mal del software. La gestin de alto nivel puede establecer objetivos significativos de mejora del proceso de ingeniera del software pidiendo y evaluando las medidas de productividad y de calidad. Si el proceso por el que se desarrolla puede ser mejorado, puede producirse un impacto directo en lo sustancial. Pero para establecer objetivos de mejora, se debe comprender el estado actual de desarrollo del software. Los riesgos del trabajo diario de un proyecto del software no dejan mucho tiempo para pensar en estrategias. Mediante el uso de la medicin para establecer una lnea base del proyecto, cada uno de estos asuntos se hace ms fcil de manejar. La recopilacin de mtricas de calidad permite a una organizacin sintonizar su proceso de ingeniera del software para eliminar las causas poco vitales de los defectos que tienen el mayor impacto en el desarrollo del software.
79

Integracin de las mtricas dentro del proceso del software

Las mtricas del software, cuando se aplican al producto, proporcionan beneficios inmediatos. Cuando se ha terminado el diseo del software, la mayora de los que desarrollan pueden estar ansiosos por obtener respuesta a preguntas como: Qu requisitos del usuario son ms susceptibles al cambio? Qu mdulos del sistema son ms propensos a error? Cmo se debe planificar la prueba para cada mdulo? Cuntos errores puede esperar cuando comience la prueba?

80

Proceso que establece una lnea base.

Proceso de ingeniera del software

Proyecto del software

Producto del software

Recuperacin de datos

Medidas

Clculos de mtricas

Mtricas

Evaluacin de mtricas
Proceso de recopilacin de mtrica de software

Indicadores 81

Proceso que establece una lnea base.

Los datos necesarios para establecer una lnea de ase se han ido recopilando a medida que se ha ido progresando. La recopilacin de datos requiere una investigacin histrica de los proyectos anteriores para reconstruir los datos requeridos. Una vez que se han recopilado medidas, el clculo de mtricas es posible. Dependiendo de la amplitud de las medidas recopiladas, las mtricas pueden abarcar una gran gama de mtricas LDS y PF, as como mtricas de la calidad y orientadas a objetos. Las mtricas se deben evaluar y aplicar durante la estimacin, el trabajo tcnico, el control del proyecto y la mejora de proyectos.

82

2.3 Estudio de recursos y estimacin de costos para el desarrollo de software

El Proceso de gestin para la creacin de un Sistema o software, encierra un conjunto de actividades, una de las cuales es la estimacin, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimacin, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costes de tiempo. Y dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena Ingeniera de Sistemas y Software.
83

2.3.2 Objetivos de la Planificacin del Proyecto.

El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse. El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables.
84

2.3.3 Actividades asociadas al proyecto de software.

mbito del Software. Es la primera actividad llevada a cabo durante la planificacin del proyecto de Software. En esta etapa se deben evaluar la funcin y el rendimiento que se asignaron al Software durante la Ingeniera del Sistema de Computadora para establecer un mbito de proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos Describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes. El mbito se define como un pre-requisito para la estimacin y existen algunos elementos que se debe tomar en cuenta como es: La Obtencin de la Informacin necesaria para el software. Para esto el analista y el cliente se renen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo.
85

2.3.4. Recursos.
La Segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirmide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirmide se encuentran los Componentes reutilizables. Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el recurso humano). Cada recurso queda especificado mediante cuatro caractersticas: Descripcin del Recurso. Informes de disponibilidad. Fecha cronolgica en la que se requiere el recurso. Tiempo durante el que ser aplicado el recurso.

86

Recursos.
Personas Componentes de software reutilizables Herramientas Hardware/software
87

2.3.4.1 Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y seleccionar la posicin dentro de la organizacin y la especialidad que desempeara cada profesional.
88

2.3.4.2 Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin, esto es la creacin y la reutilizacin de bloques de construccin de Software. Tales bloques se deben establecer en catlogos para una consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para la tambin fcil integracin. El Autor Bennatan sugiere cuatro categoras de recursos de software que se deberan tener en cuenta a medida que se avanza con la planificacin: Componentes Componentes Componentes Componentes ya desarrollados. ya experimentados. con experiencia Parcial. nuevos.

89

2.3.4.3 Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniera de Software, incorpora Hardware y Software. El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniera del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estn disponibles. Muchas veces el desarrollo de las pruebas de validacin de un proyecto de software para la composicin automatizada puede necesitar un compositor de fotografas en algn punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software.

90

2.3.5. Estimacin del proyecto de Software.

En el principio el costo del Software constitua un pequeo porcentaje del costo total de los sistemas basados en Computadoras. Hoy en da el Software es el elemento ms caro de la mayora de los sistemas informticos. Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimacin del costo y del esfuerzo del software nunca ser una ciencia exacta, son demasiadas las variables: humanas, tcnicas, de entorno, polticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo. Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles: Deje la estimacin para mas adelante (obviamente podemos realizar una estimacin al cien por cien fiable despus de haber terminado el proyecto. Base las estimaciones en proyectos similares ya terminados. Utilice tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto. Desarrolle un modelo emprico para l clculo de costos y esfuerzos del Software.
91

2.3.5. Estimacin del proyecto de Software.

Desdichadamente la primera opcin, aunque atractiva no es practica. La Segunda opcin puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son mtodos viables para la estimacin del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas usando cada una de ellas como comprobacin de las otras. Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito del software a construir y generar una estimacin de su tamao.
92

2.3.5.1 Estimacin basada en el Proceso.

Es la tcnica ms comn para estimar un proyecto es basar la estimacin en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeo de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de cada tarea. Al igual que las tcnicas basadas en problemas, la estimacin basada en el proceso comienza en una delineacin de las funciones del software obtenidas a partir del mbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de software.
93

2.3.6. Diferentes modelos de estimacin.

Existen diferentes modelos de estimacin como son: 2.3.6.1 Los Modelos Empricos: Donde los datos que soportan la mayora de los modelos de estimacin obtienen una muestra limitada de proyectos. Por esta razn, el modelo de estimacin no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia.
94

2.3.6.2 El Modelo COCOMO.

Barry Boehm, en su libro clsico sobre economa de la Ingeniera del Software, introduce una jerarqua de modelos de estimacin de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarqua de modelos de Boehm esta constituida por los siguientes: Modelo I. El Modelo COCOMO bsico calcula el esfuerzo y el costo del desarrollo de Software en funcin del tamao del programa, expresado en las lneas estimadas. Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en funcin del tamao del programa y de un conjunto de conductores de costos que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto. Modelo III. El modelo COCOMO avanzado incorpora todas las caractersticas de la versin intermedia y lleva a cabo una evaluacin del impacto de los conductores de costos en cada caso (anlisis, diseo, etc.) del proceso de ingeniera de Software

95

2.3.6.3 Herramientas Automticas De Estimacin.

Las herramientas automticas de estimacin permiten al planificador estimar costos y esfuerzos, as como llevar a cabo anlisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la seleccin del personal. Aunque existen muchas herramientas automticas de estimacin, todas exhiben las mismas caractersticas generales y todas requieren de una o ms clases de datos.
96

Herramientas Automticas De Estimacin.

A partir de estos datos, el modelo implementado por la herramienta automtica de estimacin proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duracin, y en algunos casos la planificacin temporal de desarrollo y riesgos asociados. En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerir y cuanta gente estar implicada. Adems el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado.
97

Herramientas Automticas De Estimacin.

Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres tcnicas referidas anteriormente. Mediante la comparacin y la conciliacin de las estimaciones obtenidas con las diferentes tcnicas, el planificador puede obtener una estimacin ms exacta. La estimacin del proyecto de software nunca ser una ciencia exacta, pero la combinacin de buenos datos histricos y tcnicas puede mejorar la precisin de la estimacin.

98

2.4 Anlisis de riesgos

El manejo de riesgos El manejo de riesgos involucra identificar los riesgos y crear planes para minimizar su efecto en un proyecto Un riesgo es una probabilidad de que alguna circunstancia adversa pueda ocurrir

Los riesgos de un proyecto afectan el calendario o recursos Los riesgos de un producto afectan la calidad o el rendimiento del producto Los riesgos de negocio afectan la organizacin que desarrolla o compra el software

99

Los riesgos de software

Riesgo Movimiento de personal Tipo de riesgo Proyecto Descripcin El personal con experiencia saldr el proyecto antes de que el proyecto sea completado Habr un cambio en administracin organizacional con diferentes prioridades Hardware que es imprescindible para el proyecto no ser entregado a tiempo Habrn un nmero ms grande de cambio a los requerimientos que esperaba Las especificaciones de interfaces imprescindibles no estarn disponibles a tiempo

Cambio en administracin
Hardware no disponible Requerimientos cambian Retrasos en especificacin

Proyecto
Proyecto Proyecto y producto Proyecto y producto Producto y proyecto Producto Negocio Negocio

Subestimacin de tamao
Subrendimiento de herramientas CASE Cambio en tecnologa Competencia del producto

El tamao del sistema ha sido subestimado

Herramientas CASE que soportan el proyecto no funcionan como esperada La tecnologa en que el sistema es construido es suplantada por nueva tecnologa Un producto competitivo est publicitado antes de que el sistema est completo

100

El proceso de manejar riesgos

Identificar riesgos

Identificar los riesgos de proyecto, producto y negocio Valorar la probabilidad y las consecuencias de estos riesgos Crear planes para evitar o minimizar los efectos del riesgo

Analizar riesgos

Planificar riesgos

Monitorear riesgos Monitorear los riesgos durante todo el proyecto

101

El proceso de manejar riesgos

Identificar riesgos Lista de riesgos potenciales Analizar riesgos Lista priorizada de riesgos Planificar riesgos Planes para evitar riesgos y de contingencia Monitorear riesgos Valoracin de riesgos

102

Identificacin de riesgos
Riesgos Riesgos Riesgos Riesgos Riesgos de de de de de tecnologas personas la organizacin los requerimientos estimacin

103

Riesgos y tipos de riesgo

Tipo de riesgo Riesgos Posibles La base de datos usada en el sistema no puede procesar tantas transacciones por segundo como esperaba. Componentes de software que deben ser reutilizados tienen defectos que limitan su funcionalidad. Es imposible contratar personal con las habilidades requeridas. Personal clave est enfermo y no disponible a horas criticas. Entrenamiento requerido para el personal no est disponible. La organizacin es reestructurada en una manera en que una administracin diferente es responsable del proyecto. Problemas financieros de la organizacin causan reducciones en el presupuesto del proyecto. El cdigo generado por herramientas CASE es ineficiente. Las herramientas CASE no pueden ser integradas. Cambios a los requerimientos que requieren grandes reajustes del diseo son propuestos. Los clientes no entienden el impacto de los cambios a los requerimientos. El tiempo requerido para desarrollar el software es subestimado. La velocidad de reparar defectos es subestimada. El tamao del software es subestimado. Tecnologa

Personas

Organizacional

Herramientas Requerimientos

Estimacin

104

Analizar riesgos
Valorar la probabilidad y seriedad de cada riesgo La probabilidad puede ser muy baja, baja, moderada, alta o muy alta Los efectos del riesgo pueden ser catastrficos, serios, soportables o insignificantes
105

Anlisis de riesgos
Riesgo Problemas financieros de la organizacin hacen que se reduzca el presupuesto del proyecto. Es imposible reclutar personal con las habilidades requeridas para el proyecto. El personal clave est enfermo en un momento crtico para el proyecto. Componentes de software que se deberan reusar tienen defectos que limitan su funcionalidad. Cambios en requerimientos que requieren trabajo de rediseo significante son propuestos. La organizacin es reorganizada de tal manera que una administracin diferente es ahora responsable del proyecto. La base de datos usada en el sistema no puede procesar la cantidad de transacciones por segundo como se esperaba. El tiempo requerido para desarrollar el software es subestimado. Las herramientas CASE no pueden ser integradas. Los clientes no logran entender el impacto de los cambios de requerimientos. Entrenamiento requerido para el personal no esta disponible. La velocidad de reparacin de defectos es subestimada. El tamao del software es subestimado. El cdigo generado por las herramientas CASE es ineficiente. Probabilidad Baja Alta Moderada Moderada Moderada Alta Moderada Alta Alta Moderada Moderada Moderada Alta Moderada Efectos Catastrficos Catastrficos Serios Serios Serios Serios Serios Serios Tolerables Tolerables Tolerables Tolerables Tolerables Insignificantes

106

Planificar riesgos
Tomar en cuenta cada riesgo y desarrolle una estrategia para manejar ese riesgo Estrategias evasivas

Estrategias de minimizacin

La probabilidad de que el riesgo surja es reducida El impacto que el riesgo tendr sobre el proyecto o el producto es reducida

Planes de contingencia Si el riesgo surge, los planes de contingencia son planes para manejar ese riesgo
107

Estrategias para manejar riesgos

RIESGO Problemas financieros de la organizacin Problemas con reclutamiento ESTRATEGIA Preparar un informe para la administracin superior que muestre como el proyecto hace una contribucin muy importante a las metas del negocio Alertar el cliente sobre dificultades potenciales y la posibilidad de retrasos, investigar comprar componentes pre-construidos Reorganizar el equipo para hacer ms superposicin de trabajo para que las personas comprendan el trabajo de las otras Reemplazar componentes defectuosos en potencia con componentes pre-hechos de reliabilidad conocida Derivar informacin para valorar el impacto del cambio de requerimientos, maximizar ocultar la informacin en el diseo Preparar un informe para la administracin superior que muestre como el proyecto hace una contribucin muy importante a las metas del negocio Investigar la posibilidad de comprar una base de datos de ms alto rendimiento

Enfermedad de personal

Componentes defectuosos

Cambios en requerimientos Reestructuracin de la organizacin Rendimiento de la base de datos Tiempo subestimado para desarrollar

Investigar comprar componentes pre-hechos

108

Monitorear riesgos
Valorar cada riesgo identificado con regularidad para determinar si est volvindose ms o menos probable Tambin valorar si los efectos del riesgo han cambiados Cada riesgo clave se debe discutir con la administracin durante reuniones de progreso
109

Factores de riesgo
Tipo de riesgo Indicadores potenciales Tecnologa Entrega tarde de hardware o software de soporte, muchos problemas reportados de tecnologa

Personal

Baja moral del personal, malas relaciones entre miembros del equipo, disponibilidad de trabajo

Organizacin

Cotilleo sobre la organizacin, una falta de accin por la administracin superior

Herramientas

Desgana por los miembros del equipo por usar herramientas, quejas sobre las herramientas CASE, exigencias para computadoras con ms poder

Requerimientos

Muchas solicitudes para cambios de requerimientos, quejas por el cliente

Estimacin

Fracaso a alcanzar el calendario convenido, fracaso al arreglar defectos reportados

110

Puntos claves
Buena administracin del proyecto es necesaria para el xito del proyecto El carcter intangible del software causa problemas para administracin Los administradores tienen roles diversos pero sus actividades ms significantes son planificar, estimar y calendarizar. Planificar y estimar son procesos iterativos que continan durante todo el proyecto Un hito de un proyecto es un estado previsible donde un reporte formal es presentado a la administracin Los riesgos pueden ser riesgos de proyecto, producto o negocio Manejar riesgos involucra identificar los riesgos que pueden afectar el proyecto y planificar para asegurar que estos riesgos no se conviertan en amenazas significativas

111

2.5 Planificacin temporal y seguimiento de proyectos

Planeacin del Proyecto Conjunto de actividades necesarias para desarrollar el proyecto. Probablemente es la actividad que ms consume tiempo. Existe una actividad continua desde el concepto inicial del proyecto hasta que este es liberado. Los planes deben de ser revisados regularmente a medida que est disponible nueva informacin.

112

Estructura del plan del proyecto

Introduccin. Organizacin del proyecto. Anlisis de riesgos. Requerimientos de software y hardware. Reparticin del trabajo. Planificacin del trabajo. Monitorizacin y mecanismos de reporte.

113

Tipos de planes del proyecto

Plan Descripcin Describe la metodologa a utilizar en el desarrollo del proyecto.

Plan de Desarrollo

Plan de Calidad

Describe los procedimientos de calidad, y los estndares a utilizar en el proyecto.

Plan de Validacin

Describe el enfoque los recursos y la planificacin utilizada por la validacin.

Plan de Mantenimiento

Predice los requerimientos de mantenimiento del sistema, los costes de mantenimiento y el esfuerzo.

Plan de Desarrollo Personal

Describe como se adquirirn y desarrollarn los conocimientos y habilidades del personal.

114

Proceso de planeacin del proyecto

Establecer las restricciones del proyecto Hacer las suposiciones iniciales de los parmetros del proyecto while el proyecto no termina o ha sido cancelado loop Describe la planificacin de tiempos del proyecto Inicia las actividades de acuerdo a la planificacin Espera (a que se lleve a cabo el desarrollo) Revisa el progreso del proyecto Revisa los parmetros estimados del proyecto Actualiza la planificacin del proyecto Renegoca las restricciones del proyecto y los tiempos de entrega if (aparecen problemas) then inicia una revision tcnica y sus posibles soluciones end if end loop

115

Organizacin de actividades
Las actividades en un proyecto deben ser organizadas para producir resultados tangibles para que la administracin pueda juzgar el progreso. Los Milestones son los puntos finales de alguna actividad. Los deliverables son los resultados del proyecto que sern entregados a los clientes. El proceso de cascada permite una definicin precisa de los milestones.

116

Milestones y Deliverables
ACTIVIDADES Estudio de Factibilidad Anlisis de Requerimientos Desarrollo del Prototipo Estudio del Diseo Especificacin de Requerimientos

Reporte de Factibilidad

Definicin de Requerimientos

Reporte de Evaluacin

Diseo de la Arquitectura

Especificacin de Requerimientos

MILESTONES

117

Planificacin del Proyecto

Distribuye el proyecto en tareas y estima el tiempo y los recursos requeridos para completar cada tarea. Organiza las tareas de forma concurrente para hacer mejor uso de la fuerza laboral. Minimiza dependencias entre tareas para evitar retrasos debidos a que una tarea espere a la terminacin de otra. Depende de la intuicin y experiencia de los administradores.

118

Problemas en la Planificacin
Es difcil estimar la longitud y dificultad de las tareas, por lo que la estimacin del coste es mas difcil. La productividad no es proporcional al nmero de personas trabajando en una tarea. Incluir personal en un proyecto en avance, retrasa el proyecto por overheads en la comunicacin. Lo inesperado siempre sucede. Es necesario considerar siempre contingencias.
119

Grficas de barras y redes de actividades.

Se utilizan notaciones grficas para ilustrar la planificacin del proyecto. Muestra la particin del proyecto en tareas. Las tareas no deben ser muy pequeas. Estas deben de tener una duracin de una semana o dos. Las grficas de actividades muestran las dependencias entre tareas y la ruta crtica. Las grficas de barras muestran la planificacin contra el tiempo del calendario de actividades.
120

Duracin de las tareas y dependencias.

Tareas
T1 T2

Duracin (das)
8 15 15 10 10 5 20 25 15 15 7 10

Dependencias

T3 T4

T1

T5 T6 T7 T8 T9 T10 T11 T12

T2,T4 T1,T2 T1 T4 T3,T6 T5,T7 T9 T11

121