39861943 Unidad II Planif y Modelado

7/31/2019 39861943 Unidad II Planif y Modelado

1/80

Planificacin y ModeladoPlanificacin del Sistema

UNIDAD 2

Planificacin del Sistema

De acuerdo con Sommerville [SOM00], la gestin de proyectos de software se

hace necesaria ya que todo proyecto esta sujeto a restricciones de

presupuesto y tiempos. La gestin permite asegurar que el software se lleve acabo a tiempo y de acuerdo con los requerimientos especificados.

La gestin del software es particularmente difcil, algunas de las razones son:

o El producto de software es intangible. Esto obliga a los gestores del

proyecto a confiar en los otros miembros del personal para la toma de

decisiones.

o No hay un proceso estndar. Y por lo tanto tampoco se tiene la certeza

de cuando un proceso en particular empieza a tener problemas.

o A menudo los proyectos de software grandes son nicos. Esto se refiere

a que los proyectos se diferencian unos de otros, por lo que hasta los

gestores ms experimentados no siempre podrn anticipar los

problemas.

Las de las actividades comunes de la gestin de proyectos software son:

o Redaccin de la propuesta.

o Planificacin del proyecto

o estimaciones de costo, tiempo y esfuerzo.

o Supervisin y revisin del proyecto.

o Seleccin y evaluacin del personal.

Ingeniera en Sistemas Computacionales

17


2/80


o Redaccin y presentacin de informes.

Las actividades listadas anteriormente son responsabilidad del gestor de

proyectos. A continuacin se considera importante discutir el tema referente a

la seleccin del personal, ya que ste representa una pieza clave para una

buena gestin de proyecto. La cantidad de personas requeridas para el

desarrollo de un proyecto de software solo puede determinarse despus de

hacer una estimacin de esfuerzo de desarrollo, por ejemplo, personas mes o

personas aos. An as empezando un proyecto se tendr que dar un

aproximado del personal necesitado y asignarlas a las diferentes tareas o

actividades, para as poder realizar estimaciones de costo y tiempo.

Seleccin del personal

Todo proyecto requiere personal que interacte con los clientes par determinar

los requerimientos, otro grupo de personas diferentes para disear el sistema,

otros para escribirlo, otros que los prueben etc. [PFL02]. El gestor del proyecto

se encarga de seleccionar al personal que constituir su equipo de trabajo.

Debe establecer un equipo ideal mnimo de acuerdo a las restricciones del

presupuesto, y a la disponibilidad del personal con o sin experiencia, esto por

que algunas veces se desea capacitar al personal dentro de la misma empresa

[SOM00]. Al momento de seleccionar el personal de trabajo el gestor debe

[PFL02]:

o Asignar tareas que desempearn

o Designar a los jefes de equipo.

o La estructura organizacional de los diferentes equipos.

La asignacin de tareas al personal depende de la dimensin del proyecto, de

la destreza y experiencia de stos. Una vez que se decide el rol de los

miembros de cada grupo que conformarn el equipo del proyecto, el gestor

debe decidir el tipo de personas que necesita para cada rol. Ya que el personal

difiere en muchas maneras, no basta decir que un proyecto necesita de una


18


3/80


analista, dos diseadores y cinco programadores, por poner un ejemplo. De

acuerdo con Sommerville [SOM00], la seleccin del personal se realiza de

acuerdo a los siguientes factores:

o Experiencia en el dominio de la aplicacin.

o Experiencia en la plataforma.

o Experiencia en el lenguaje de programacin.

o Capacidad de aprender.

o Habilidades de comunicacin.

o Adaptabilidad.

o Actitud.

o Personalidad.

Cada una de estas caractersticas, puede afectar la capacidad del individuo

para desempearse en forma productiva. La forma en que se desempea un

trabajador es muy importante para el xito de un proyecto, se debe tener en

cuenta que algunas personas son buenas cuando se trata de captar lo global

en un proyecto y a otras se le facilita el trabajar en una pequea parte de ste.

Ambos tipos de personas podran sentirse incomodas realizando trabajos

opuestos. Por lo anterior se deduce que un trabajador se desempear mejor si

est cmodo con el trabajo que realiza, y es ms productivo cuando tiene

confianza en su capacidad para desempearse. El estimular al personal para

que desempee bien su trabajo es tambin tarea del gestor. El estimulo puede

ser invitndolo a crear algo diferente a lo que siempre hace, o a mejorarlo; con

esto mantendr el inters del personal en su trabajo [PFL02].

El personal debe ser flexible. La capacidad de compartir responsabilidades o

carga de trabajo, es muy importante, ya que a una tarea se le puede asignar

ms de una persona que trabajen en un mismo equipo. Entonces entre el

personal tambin deben tener confianza en que cada uno realizar su parte del

trabajo, y aceptar los resultados del otro sin querer cambiar o repetir su

trabajo.


19


4/80


La interaccin personal tambin est relacionada con la comodidad y confianza

entre los miembros del equipo, algunas personas son buenas dirigiendo el

trabajo de otras, a las cuales sera bueno asignarles el control de x equipo, este

tipo de personas son buenas alentando a su equipo para cumplir con un

calendario y lograr las metas, o para reunirse con el cliente. Resulta

beneficioso el que el personal se sienta motivado por el exitoso cumplimiento

de las metas personales y del equipo.

La comunicacin verbal y escrita tanto de ideas como resultados es crucial, ya

que ayuda al avance del proyecto, como la comunicacin con el cliente, cuando

se est investigando sobre los requisitos bsicos del proyecto; cuando se debe

comunicar al jefe del equipo y este al gestor del proyecto de los avances o

fallas durante el desarrollo. En un proyecto, el nmero de personas que

necesitan comunicarse entre s y la buena o mala comunicacin, pueden

afectar la calidad del producto final. La tabla 2.1 muestra como se incrementan

las lneas de comunicacin. En general si un proyecto tiene n trabajadores, hay

n ( n-1 ) /2 pares de personas que probablemente necesitarn comunicarse

y 2n 1 grupos posibles que pueden crearse para trabajar en secciones ms

pequeas del proyecto.

Nmero de

personas

Lneas de comunicacin

13 34 65 10N n (n-1 ) /2

Tabla 2.1 Caminos de comunicacin en un proyecto

La comunicacin puede ser uni/ bidireccional, segn el nivel asignado a cada

persona.

Otro factor importante en la seleccin del personal es el estilo de trabajo. La

compresin de estos estilos fomenta la flexibilidad que se hace necesaria para

un buen trabajo en equipo, as como permite tener una mejor decisin de


20


5/80


quien se comunicar con el cliente y/o usuario. Personas diferentes tienen

diferentes estilos para interactuar con otras personas y para entender los

problemas que surgen en el curso de trabajo. Por ejemplo un hay personas que

gustan de hacer un anlisis detallado de toda la informacin antes de tomar

una decisin, contrariamente habr personas que solo necesiten confiar en su

intuicin para tomar alguna decisin importante.

Los estilos de trabajo afectan las interacciones de un proyecto entre clientes,

desarrolladores y usuarios. A continuacin se muestran en la figura 2.2 una

variedad de stos, la comunicacin la constituye el eje horizontal y los estilos

de decisin el vertical. Se debe sealar que no todas las personas encajan en

estos cuatro estilos. Por ejemplo la siguiente lista de caractersticas

corresponde al estilo de trabajo de los extrovertidos intuitivos:

o rara vez piden opiniones,

o prefieren comunicar sus propias ideas y

o basan la mayora de sus decisiones en intuiciones.

Fig. 2.2 Estilos de trabajo

La organizacin de un proyecto.(aqu me Qede)

El conjunto de personas que conforman el gran equipo de un proyecto deben

trabajar de manera conjunta y coordinada, lo que asegura la obtencin de


21


6/80


productos de calidad. La eleccin de una estructura apropiada depende del

nmero de personas en el equipo, de las caractersticas de personal y los

estilos de trabajo, entre otras cosas. Existen muchas formas de para la

organizacin de proyectos, a continuacin se describirn dos tipos de

organizacin, los cuales son los extremos.

Una muy popular es el equipo de jefe de programadores (chief programmer

team). En este tipo de organizacin, una persona (el jefe de programadores) es

responsable por el diseo del sistema y su desarrollo; tiene un sustituto para

cuando sea necesario reemplazarlo. El jefe de programadores tiene los

siguientes privilegios y responsabilidades:

o Recibe reportes del resto del de los miembros del equipo

o Tiene la ltima palabra en la toma de decisiones (por lo que debe ser

una persona que tome buenas decisiones rpidamente)

o Disea todos los programas

o Asigna el desarrollo de codificacin a otros miembros

o Supervisa al resto del equipo

Este tipo de organizacin cuenta con un bibliotecario asiste al equipo y es

responsable de:

o Darle mantenimiento a la documentacin

o Compilar y hacer enlace (link edition ) de cdigo

o Ejecutar pruebas preeliminares

La responsabilidad recae sobre una sola persona, lo que hace que la estructura

minimice la comunicacin necesaria durante el proyecto. Cada miembro delequipo a menudo tiene que comunicarse con el jefe, pero no necesariamente

con otros miembros del equipo. Por lo tanto si el equipo consiste de n-1

programadores ms el jefe, el equipo solamente puede establecer n-1 caminos

de comunicacin ms all de un potencial de n (n-1) / 2 caminos.


22


7/80


Aunque esta estructura sea jerrquica, se pueden formar grupos de trabajotes

para llevar a cabo una tarea especializada que requiera ms de una persona

para su elaboracin.

Fig. 2.3 organizacin del jefe de programadores.

El otro extremo se basa en la idea de una programacin sin egosmo como lo

describe Weinberg (1971). En vez de un nico punto de responsabilidad, otorga

a todos los miembros responsabilidades equivalentes.

La estructura de un equipo sin egosmo se diferencia de jefe de

programadores, en lo siguiente:

Es una estructura democrtica

Todos los miembros del equipo participan en la toma de decisiones

mediante votos.

Cul de las estructuras anteriores es preferible utilizar? Si el proyecto que se

pretende llevar a cabo cuenta con las siguientes caractersticas entonces

necesitar de una estructura formal jerrquica y tambin de una organizacin

bien definida. Este tipo de proyectos tiene:

o Un gran nmero de personal involucrado

o Un alto grado de certeza


23


8/80


o Estabilidad

o Uniformidad

o repeticin

Este tipo de proyectos requieren menos comunicacin entre los miembros del

equipo, una comunicacin vertical, y se adaptan mejor a este tipo de

estructura organizacional ya que imponen reglas, especializacin, formalidad y

una clara definicin de la jerarqua organizacional.

Por otro lado, un proyecto necesitar una estructura aproximada a la

democrtica si tiene las siguientes caractersticas:

o Un pequeo nmero de personal involucrado

o Existe cierto nivel de incertidumbre

o Realizan pruebas con tcnicas o tecnologa nuevas

Comnmente en este tipo de proyectos los requerimientos probablemente

cambien durante su desarrollo, por esto necesitan una estructura ms flexible

con

amplia comunicacin abierta y por lo tanto la participacin de todos los

miembros del equipo.

Teniendo el conocimiento de cmo seleccionar al personal para el equipo del

proyecto y la manera de organizarlo para su ptimo desempeo, se puede

profundizar en el tema de la planificacin del proyecto que abarca el resto de

la unidad. A continuacin se da una breve introduccin de ste antes de

describirlo de manera ms detallada.

De acuerdo con George Steiner [STE89], planear significa disear un futuro

deseado e identificar las formas para lograrlo.

Qu es la planificacin:


24


9/80


o Es una gua de desarrollo para cumplir las metas del proyecto.

o Es un proceso iterativo el cual termina hasta que el proyecto mismo

haya terminado. Esto quiere decir que su revisin es continua, ya que

tanto requerimientos como restricciones pueden cambiar a lo largo del

desarrollo [SOM00].

El xito o fracaso de un proyecto de software depende en gran parte de la

planificacin, ya que con ayuda de sta se pueden evitar problemas a los que

un proyecto est sujeto, tales como:

o Retraso de tiempo de entrega

o Sobrepasar el presupuesto

o Baja calidad del producto

o Alto costo de mantenimiento, etc.

El gestor de proyecto es responsable de planear y supervisar el proyecto para

que este se lleve a cabo:

o dentro de los tiempos establecidos

o conforme a los estndares requeridos

o acorde al presupuesto

Durante la planificacin, el gestor del proyecto debe tener un plan para

enfrentarse a los problemas que puedan surgir durante el desarrollo del

proyecto y poder solucionarlos. Al ir desarrollndose el proyecto se obtiene

mayor y mejor informacin, esto modificar el plan inicial, lo que conduce a

replanear el calendario de actividades necesarias para desarrollar el proyecto.

Los pasos de la planificacin de un proyecto comprende las siguientes

ilustradas en la figura 2.4:

o Delimitar el mbito del software

o Realizar estimaciones de tiempo, costo y esfuerzo

o Calendarizar el trabajo


25


10/80


o Gestionar riesgos

o Controlar la calidad y los cambios

o Gestin de configuracin de software

Fig. 2.4 actividades de la gestin y planificacin

La planificacin inicia con la valoracin de las restricciones impuestas por el

cliente. Es importante que antes de realizar la estimacin, se delimite el

mbito del software. En esta etapa se evalan las funciones, y desempeo del

software. Se describen los datos que se procesarn, funciones, desempeo,

restricciones, interfaces y viabilidad [PRE02]. Las actividades de planificacin

del tiempo, estimacin de costo y recursos para acometer el esfuerzo de

desarrollo, se describen posteriormente los puntos 2.1 y 2.2 respectivamente.

Dentro del Proceso Unificado (PU) [JBR00], la planificacin del proyecto es

similar a la planificacin estndar para cualquier proyecto de software. La

planificacin del sistema se ve presente en cada una de las fases del proceso

unificado.

En cada una de estas y en cada iteracin se realiza lo siguiente:

o se toman las decisiones de continuar o no con el proyecto

o se determina

o el calendario

o el presupuesto


26


11/80


o se gestionan los

o requerimientos

o y riesgos

Los cinco flujos de trabajo fundamentales (requerimiento, anlisis, diseo,

implementacin y prueba), mas la planificacin y evaluacin de la iteracin,

constituyen lo que se llama la iteracin genrica. El nmero de iteraciones

depender bsicamente de la complejidad del sistema propuesto. A mayor

complejidad mayor nmero de iteraciones en cada fase. La planeacin de la

iteracin incluye los siguientes pasos:

1. Primeramente se identifican los recursos humanos, es decir, los

individuos disponibles para actuar como trabajadores.

2. Teniendo conocimiento de los recursos, se calendarizan las iteraciones.

Aqu se decide cunto tiempo puede tomar cada iteracin y as asignarle

una fecha de terminacin. Esta calendarizacin se refina en cada fase, a

principio grosso modo y posteriormente con mayor precisin.

3. Conociendo el tiempo aproximado para cada iteracin, enseguida se

realiza una estimacin de costos en esfuerzo y dinero de cada fase.

4. Luego se planea detalladamente las actividades de cada iteracin.

Cada iteracin debe ser evaluada para entre otras cosas, conocer los

beneficios y la parte del trabajo que se ha completado por sta. Tambin

ayuda en lo siguiente:

o Reconsiderar el plan de la siguiente iteracin para realizar los cambios

necesarios a ste.

o

Modificar el proceso, adaptar las herramientas, prolongar la preparaciny realizar otras acciones sugeridas por la iteracin evaluada.

Por medio de la evaluacin el gestor de proyecto se da cuenta si el proyecto va

progresando, en otras palabras necesita saber si el proyecto est:


27


12/80


o avanzando de acuerdo al presupuesto y calendarizacin.

o cumpliendo con los criterios de calidad.

Si no se cumplen con lo criterios de evaluacin entonces se tendr que

prolongar el trabajo en la siguiente iteracin.

Una vez evaluada la iteracin, el gestor del proyecto realiza lo siguiente:

1. Determina que el trabajo est listo para la siguiente iteracin.

2. Asigna el trabajo incompleto a las siguientes iteraciones.

3. Planea en detalle la siguiente iteracin.

4. Actualizar la lista de riesgos y el plan del proyecto.

5. Compara el costo y la planificacin de la iteracin con los planeados.

2.1 Planificacin del tiempo

El factor tiempo es muy importante en el desarrollo de software ya que

ganaremos o perderemos a un cliente si este no es entregado en los tiempos

establecido o ya negociados.

La planificacin de tiempo se puede definir como una actividad en la cual se

debe estimar el tiempo que requerir para llevar a cabo una tarea y los

recursos necesarios para su realizacin.

Durante la recoleccin de requerimientos, se listan todos los elementos que se

deben entregar del proyecto, que son los tems que los clientes esperan ver

durante el desarrollo del proyecto, tales como:

o La documentacin, que describir el estado del software en desarrollo.

o Demostraciones de funciones, precisin, confiabilidad, seguridad, y

desempeo.


28


13/80


A continuacin se muestran los hitos y actividades que se deben llevar a cabo

para lograr dichos elementos. Se debe distinguir claramente entres una

actividad y un hito.

Una actividad:

o Es un evento medible.

o Es una parte del proyecto que tiene lugar durante un periodo de tiempo.

o Tiene un principio y un fin.

Se puede describir con cuatro parmetros:

o Precursor: evento o conjunto de stos, que deben ocurrir antes que la

actividad pueda comenzar. Son las condiciones que permiten que una

actividad comience.

o Duracin: tiempo necesario para completar una actividad.

o Fecha de entrega: la fecha para cual la actividad debe ser completada.

o Punto final: entendiendo que una actividad ha terminado es un hito o un

componente para entregar.

Un hito:

o Es un evento que indican el alcance de un nivel mensurable en el

proyecto.

o Es la completitud y final de una actividad y sucede en un determinado

momento.

o Debe representar el fin de una etapa lgica del proyecto.

o Son productos a entregar para el cliente o resultados de una actividadpara el gestor de proyectos.

Cuando se trata de un resultado de una actividad los informes de estos

logros deben ser cortos.


29


14/80


Ejemplos de hitos son los siguientes:

o la especificacin de requerimientos.

o la terminacin de un manual de usuario

o realizacin de un conjunto de clculos

o demostracin de la capacidad de comunicacin en el sistema.

Si el cliente quiere que el sistema se entregue acompaado de un tutorial

asistido por un operador en lnea, el desarrollo de dicho tutorial y sus

programas asociados son ejemplo de una actividad, que culmina en la

demostracin de las funciones requeridas por el cliente, este es otro ejemplo

de hito[PFL02].

De acuerdo con Sommerville [SOM00], para determinar los hitos en un proceso

de desarrollo de software, es necesario dividirlo en actividades bsicas junto

con sus salidas asociadas, como se muestra en la figura 2.1.1:

Fig. 2.1.1 Actividades y hitos en el desarrollo de software

La descomposicin en hitos y actividades beneficia:

Tanto a clientes como desarrolladores para entender el desarrollo y

mantenimiento del sistema.

Al gestor para juzgar el progreso del software y puede entonces

actualizar costos y el calendario.

Dentro del PU, los desarrolladores dividen el trabajo en partes ms pequeas y

compresibles, equivale a dividirlo en fases y cada una de stas en iteraciones.


30


15/80


Dentro de cada iteracin se debera trabajar en las cosas apropiadas,

permitiendo alcanzar un equilibrio entre las secuencias de actividades

ejecutadas en la misma iteracin. De esto se deduce que dos taras muy

importantes de un proyecto son:

1. seleccionar las cosas correctas en las que trabajar dependiendo del

punto del ciclo de vida en que se encuentre el proyecto.

2. determinar el equilibrio de las secuencias de las actividades, es decir

asignarles prioridades para sincronizarlas con facilidad.

Las fases son la primera divisin del trabajo. En cada fase las primeras

iteraciones se centran en los flujos de requerimientos, anlisis y diseo, como

sera el trabajar con riesgos, casos de uso fundamentales, cuestiones

arquitectnicas, etc. Y en las ltimas iteraciones se trabaja con actividades

orientadas al desarrollo, como la implementacin y prueba, evaluacin de

desempeo [JBR00].

Durante la fase de elaboracin el objetivo principal es crear una lnea base

para la arquitectura y la estimacin de costos con gran precisin, as como la

planificacin de la fase de construccin, siendo sta muy precisa, que

abarcara la planificacin de tiempo y costos que se ver en la seccin 2.2

(anlisis costo-beneficio).

Una vez definidas las actividades y hitos lo siguiente es calendarizar el

proyecto, esto es, dividir el trabajo en actividades o tareas complementarias y

considerar el tiempo que requiere cada una para completarse. Generalmente

se representa con grficos de barras y grafos o redes de actividades que

muestran las actividades, los responsables, la dependencia entere actividades

y la asignacin de recursos, entre otras cosas.

El gestor debe coordinar las tareas del trabajo, asignarles a stas el personal y

otros recursos de tal manera que se aprovechen de manera ptima. Las

actividades por lo general duran al menos una semana, la cantidad de tiempo

mxima sugerida es de 8 a 10 semanas.


31


16/80


El calendario debe actualizarse continuamente a medida de que progrese el

proyecto y se obtenga mejor informacin. Tambin es necesario hacer uso de

documentos que describan el estado del software durante su desarrollo, para

as facilitar los cambios.

Los siguientes son problemas a los cuales un gestor de proyectos se puede

enfrentar, lo que representa retrasos en algunas actividades:

Personal faltante.

Hardware o software defectuosos o que no estn disponibles a tiempo.

Proyectos con mtodos de diseos y lenguajes diferentes.

Proyectos nuevos que utilizan tcnicas complejas.

Una regla prctica, es hacer la estimacin como si nada fuera a salir mal, e

incrementar la estimacin entre un 20% y 30% para cubrir los imprevistos.

2.1.1 Mtodos de Planificacin temporal

Existen varios mtodos para la planificacin aqu se describirn:

La tcnica de revisin y evaluacin del programa(PERT)

y CPM la ruta crtica

Tambin existen varias representaciones grficas como los son:

redes de actividades

Grficos de barras

Por medio de una red de actividades se muestra la dependencia entre las

diferentes actividades y se estima el tiempo en que tardar cada tarea,debemos considerar que algunas de estas se podrn realizar en paralelo. Ya

que pueden surgir problemas las suposiciones iniciales del calendario deben

ser pesimistas para tener holgura y poder llevar a cabo el plan dentro de los

tiempos establecidos [SOM00].


32


17/80


Ejemplo: Supongamos las actividades mostradas en la tabla 2.1.2, se muestra

su duracin e interdependencia. La M representa un hito.

Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12

Duracin(das)

8 15 15 10 10 5 20 25 15 15 7 10

Dependencias

T1

(M1

)

T2,T

4

(M2

)

T1,T

2

(M3

)

T1

(M1

)

T4

(M5

)

T3,

T6

(M4

)

T5,

T7

(M7

)

T9

(M6

)

T11

(M8

)

Tabla 2.1.2 duracin y dependencias de las actividades

Teniendo la dependencia y duracin estimada de las actividades, un diagrama

de actividades muestra la sucesin de actividades que deben generarse, las

que se llevan en paralelo y las que deben ejecutarse en secuencia, debido a la

dependencia con una actividad previa.

El diagrama que se muestra en la figura 2.1.3, se produce con ayuda de una

herramienta de gestin de proyecto, y se requiere que todas las actividades

terminen en hitos. El diagrama se debe leer de izquierda a derecha y de arriba

hacia abajo. Las actividades se representan con rectngulos, los hitos y

productos con esquinas redondeadas.

Una actividad comienza cuando su hito precedente se ha alcanzado. Y antes

de poder pasar de un hito a otro, todas las trayectorias deben completarse. Por

ejemplo T9 no puede iniciar hasta completarse T3 y T6, cuando se llega a M4

entonces estas tareas ya se habrn completado.


33


18/80


Fig. 2.1.3 Diagrama de actividades

Para estimar el tiempo mnimo requerido para finalizar el proyecto, se toma en

cuenta la trayectoria ms larga en el diagrama de actividades, la trayectoria

crtica. En este ejemplo es de 11 semanas o 55 das laborales, y est resaltada

en la figura anterior.

El calendario realizado depende de esta trayectoria crtica, si se presentaralgn problema para completar una actividad dentro de la trayectoria crtica,

provocara demora en el proyecto. Hay que sealar que si hay algn retraso en

actividades que no se encuentren dentro de la trayectoria crtica no provocan

necesariamente demora en todo el calendario.

Una alternativa es utilizar los grficos de barras (tambin llamados grficos de

Grantt) muestran quien hace qu, cuando inicia y cuando termina. Se pueden

generar automticamente a partir de una base de datos utilizando

herramientas de gestin.

Ejemplo: considerando las actividades anteriormente listadas. El siguiente

diagrama de la figura 2.1.4 muestra las actividades, hitos y tiempo estimado.


34


19/80


Fig. 2.1.4 grfico de barras de actividades de un proyecto de software

Las actividades son seguidas por una barra sombreada (en este caso se resalta

de color azul) y cuya longitud es calculada por una herramienta de

calendarizacin. La barra azul indica que hay flexibilidad en las fecha de

terminacin para dichas actividades. Entonces, la trayectoria crtica se ve

afectada solamente si:

las actividades que no tiene la barra azul no se completan a tiempo.

las actividades con barra azul pasa del lmite de tiempo marcado por

sta.

Tambin se puede hacer uso de los grficos de barras para mostrar las

personas asignadas a las diferentes actividades y tambin el tiempo en que se

ocupar a las personas. La tabla 2.1.5 muestra la asignacin de personas a las

actividades y la figura 2.1.6 lo muestra junto con el tiempo asignado.


35


20/80


TareaIngenier

o

T1 Jane

T2 Anne

T3 Jane

T4 FredT5 Mary

T6 Anne

T7 Jim

T8 Fred

T9 Jane

T10 Anne

T11 Fred

T12 Fred

Tabla 2.1.5 asignacin de personal a actividades

Fig. 2.1.6 grfico de barras de actividades de un proyecto de software


36


21/80


PERT Y CPM

A continuacin se describirn el mtodo PERT (Program Evaluation and Review

Technique) y el mtodo CPM (Crtical Path Method), que fueron desarrollados

en Estados Unidos en 1957 [4 y 5].

Ambos mtodos aportaron los elementos administrativos necesarios para

formar el mtodo del camino crtico actual, utilizando el control de los tiempos

de ejecucin y los costos de operacin, para buscar que el proyecto total sea

ejecutado en el menor tiempo y al menor costo posible. Tanto PERT como CPM

hacen uso de diagramas o redes de actividades.

El PERT se desarroll para proyectos en donde hubiera incertidumbre en el

tiempo de las actividades (usualmente debido a que el proyecto nunca se

haba intentado antes y por tanto no haba bases de datos, para los tiempos de

las actividades). Esto condujo al enfoque probabilstico que se tom. Mientras

que en PERT los estimados de tiempo y sus distribuciones han sido de

controversia, el PERT ha constituido una herramienta til para la

administracin de proyectos. La principal desventaja es que no es funcional

para grandes proyectos, debido a los tres estimados de tiempo que serequieren en cada actividad y a la capacidad limitada de los computadores

actuales, para almacenar esta vasta cantidad de datos. Adems, el costo de

actualizar y mantener la informacin del proyecto con el tiempo en ambientes

tan dinmicos, puede ser excesivamente prohibitivo.

Por otra parte, el CPM se desarroll para manejar proyectos repetitivos o

similares (ej., mantenimiento de plantas qumicas). Obviamente, se gana gran

cantidad de experiencia con el tiempo en tales circunstancias, aun cuando dos

proyectos puede que no sean iguales. Esta experiencia llev al anlisis de

tcnicas de colisin utilizadas en las redes CPM.

A pesar de que PERT y CPM difieren un poco en terminologa y en la forma de

construir el diagrama de red, sus objetivos son los mismos. El anlisis usado

por ambas tcnicas es muy similar.


37
http://www.monografias.com/trabajos11/metods/metods.shtmlhttp://www.monografias.com/trabajos11/basda/basda.shtmlhttp://www.monografias.com/trabajos12/pmbok/pmbok.shtmlhttp://www.monografias.com/trabajos11/basda/basda.shtmlhttp://www.monografias.com/trabajos12/pmbok/pmbok.shtmlhttp://www.monografias.com/trabajos11/metods/metods.shtml


22/80


Las diferencias entre PERT y CPM son las siguientes listadas en la tabla 2.1.7:

PERT es un mtodo Probabilstico. CPM es un mtodo Determinstico.Considera que la variable de tiempo

es una variable desconocida de la

cual solo se tienen datos

estimativos.

Considera que los tiempos de las

actividades se conocen y se pueden

variar cambiando el nivel de recursos

utilizados.

El tiempo esperado de

finalizacin de un proyecto es la

suma de todos los tiempos

esperados de las actividades

sobre la ruta crtica.

A medida que el proyecto avanza, estos

estimados se utilizan para controlar y

monitorear el progreso. Si ocurre algn

retraso en el proyecto, se hacen

esfuerzos por lograr que el proyectoquede de nuevo dentro de los tiempos

programados cambiando la asignacin

de recursos.Suponiendo que las

distribuciones de los tiempos de

las actividades son

independientes, la varianza del

proyecto es la suma de lasvarianzas de las actividades en

la ruta crtica.

Considera que las actividades son

continuas e interdependientes,

siguen un orden cronolgico y ofrece

parmetros del momento oportuno

del inicio de la actividad.

Considera tres estimativos de

tiempos:

o el ms probable

o optimista,

o pesimista.

Considera tiempos normales y

acelerados de una determinada

actividad, segn la cantidad de

recursos aplicados en la misma.

Tabla 2.1.7 diferencias entre PERT y CPM

Mtodo CPM


38
http://www.monografias.com/trabajos11/basda/basda.shtmlhttp://www.monografias.com/trabajos11/basda/basda.shtml


23/80


Los siguientes son los pasos en el planeamiento del proyecto con CPM y son

descritos brevemente a continuacin:

1. Especificar las actividades individuales.

2. Determinar la secuencia de esas actividades.

3. Dibujar el diagrama de la red.

4. Estimar el tiempo de terminacin para cada actividad.

5. Identificar la trayectoria crtica (la trayectoria ms larga a travs de la

red)

6. Actualizar el diagrama del CPM

1. Especificar las actividades individuales.

Se hace un listado de todas las actividades del proyecto. Una actividad se

considera como una serie de operaciones realizadas por una persona o grupo

de personas en forma continua, sin interrupciones, con tiempos determinables

de inicio y trmino.

2. Determinar la secuencia de esas actividades.

Algunas actividades son dependientes en la terminacin de otras. Un listado de

los precursores inmediatos de cada actividad es til para construir el diagrama

de la red del CPM. Existen dos procedimientos para conocer la secuencia de las

actividades: Por medio de los precursores y por secuencias.

Por medio de los precursores se les preguntar a los responsables de los

procesos cuales actividades deben quedar terminadas para ejecutar cada una

de las que aparecen en la lista.

En el segundo procedimiento se preguntara a los responsables de la ejecucin,

cuales actividades deben hacerse al terminar cada una de las que aparecen en

la lista.


39
http://www.monografias.com/trabajos7/plane/plane.shtmlhttp://www.monografias.com/trabajos7/plane/plane.shtml


24/80


3. Dibujar el diagrama de red.

Se llama red a la representacin grfica de las actividades que muestran sus

eventos, secuencias, interrelaciones y el camino critico. Una vez que se hayan

definido las actividades y su secuencia, el diagrama del CPM puede ser

dibujado. El CPM fue desarrollado originalmente como actividad en red del

nodo (AON), pero algunos planificadores del proyecto prefieren especificar las

actividades en los arcos como se ilustra en la figura 2.1.8. No interesa la forma

de las flechas, ya que se dibujarn de acuerdo con las necesidades y

comodidad de presentacin de la red. Pueden ser horizontales, verticales,

ascendentes, descendentes curvas, rectas, quebradas, etc.

Se llama evento al momento de iniciacin o terminacin de una actividad. Se

determina en un tiempo variable entre el ms temprano y el ms tardo

posible, de iniciacin o de terminacin. A los eventos se les conoce tambin

con los nombres de nodos

Fig. 2.1.8 diagrama de red

4. Estimar el tiempo de terminacin para cada actividad.

El tiempo requerido para terminar cada actividad se puede estimar usando

experiencia previa o las estimaciones de personas bien informadas. El CPM es

un modelo determinista que no considera la variacin en el tiempo de la

terminacin, tan solamente un nmero se utiliza para la estimacin del tiempo

de una actividad.


40


25/80


5. Identificar la trayectoria crtica (la trayectoria ms larga a travs de la

red).

No solamente se llama camino crtico al mtodo sino tambin a la serie de

actividades contadas desde la iniciacin del proyecto hasta su terminacin, queno tienen flexibilidad en su tiempo de ejecucin, por lo que cualquier retraso

que sufriera alguna de las actividades de la serie provocara un retraso en todo

el proyecto. Desde otro punto de vista, camino crtico es la trayectoria crtica

de mayor duracin a travs de la red. Debido a su impacto en el proyecto

entero, el anlisis de trayectoria crtica es un aspecto Importante del

planeamiento del proyecto.

La trayectoria crtica puede ser identificada determinando los cuatro

parmetros siguientes para cada actividad:

o ES, Inicio ms temprano.

o EF, Inicio ms tardo.

o LS, terminacin ms temprana.

o LF, terminacin ms tarda.

El tiempo real (TR) para una actividad es la cantidad estimada en tiempo

que requiere la actividad para ser completada y el tiempo disponible (TD) es

la cantidad disponible de tiempo en el cronograma para completar la actividad.

La holgura de tiempo (HT) o margen de tiempo para una actividad es la

diferencia entre el tiempo disponible y el tiempo real para una actividad:

HT = TD TR

Otra forma de ver la holgura de tiempo, es comparar el tiempo ms temprano

en el que una actividad puede comenzar con el tiempo ms tardo en el que

dicha actividad puede comenzar, sin retrasar el proyecto.

HT = EF ES


41
http://www.monografias.com/trabajos11/metods/metods.shtml#ANALIThttp://www.monografias.com/trabajos11/metods/metods.shtml#ANALIT


26/80


La trayectoria crtica es la trayectoria a travs de la red del proyecto en la

cual ninguna de las actividades tienen holgura, es decir, la trayectoria para la

cual ES=LS y EF=LF para todas las actividades en la trayectoria.

6. Actualizar el diagrama del CPM

A medida que el proyecto progresa, los tiempos reales de la terminacin de las

tareas se conocern y el diagrama de red se tiene que actualizar para incluir la

nueva informacin. Una trayectoria crtica nueva puede emerger, y los cambios

estructurales se pueden realizar en la red si los requisitos del proyecto

cambian.

Mtodo PERT

En CPM se asume que la duracin de cada actividad es conocida con certeza.

Claramente, en muchas ocasiones este supuesto no es valido. PERT intenta

corregir este error suponiendo que la duracin de cada actividad es una

variable aleatoria. Para cada activad, se requiere estimar las siguientes

cantidades:

a = Tiempo Optimista. Duracin de la actividad bajo las condiciones ms

favorables.

b = Tiempo Pesimista. Duracin de la actividad bajo las condiciones ms

desfavorables.

m = Tiempo Normal. El valor ms probable de la duracin de la actividad.

La forma de la distribucin se muestra en la figura 2.1.7 . El tiempo ms

probable es el tiempo requerido para completar la actividad bajo condiciones

normales. Los tiempos optimistas y pesimistas proporcionan una medida de la

incertidumbre inherente en la actividad, incluyendo desperfectos en el equipo,

disponibilidad de mano de obra, retardo en los materiales y otros factores.


42
http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtmlhttp://www.monografias.com/trabajos14/propiedadmateriales/propiedadmateriales.shtmlhttp://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtmlhttp://www.monografias.com/trabajos14/propiedadmateriales/propiedadmateriales.shtml


27/80


Fig. 2.1.7 distribucin de los tiempos

Con la distribucin definida, la media (esperada) y la desviacin estndar,

respectivamente, del tiempo de la actividad para la actividad Z puede

calcularse por medio de las frmulas de aproximacin.

El tiempo esperado de finalizacin de un proyecto es la suma de todos los

tiempos esperados de las actividades sobre la ruta crtica. De modo similar,

suponiendo que las distribuciones de los tiempos de las actividades son

independientes, la varianza del proyecto es la suma de las varianzas de las

actividades en la ruta crtica.

Pasos en el proceso de planeamiento del PERT

1. Identificar las actividades y su interdependencia

2. Determinar la secuencia de actividades

3. Construir el diagrama de red

4. Tiempos estimados de actividades

5. Determinar la trayectoria crtica

6. Actualizar segn el progreso del proyecto


43
http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCEhttp://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE


28/80


1. Identificar las actividades y su interdependencia

Las actividades son las tareas requeridas para terminar el proyecto. Las

precedencias son los acontecimientos que marcan el principio y fin de una o

ms actividades.

2. Determinar la secuencia de actividades

Este paso se puede combinar con el paso de la identificacin de la actividad

puesto que la secuencia de la actividad es evidente para algunas tareas. Otrastareas pueden requerir ms anlisis para determinar el orden exacto en la cual

deben ser realizadas

3. Construir el diagrama de red

Usando la informacin de la secuencia de actividades, un diagrama de la red se

puede dibujar demostrando la secuencia de actividades seriales y paralelas.

4. Tiempos estimados de actividades

Para cada activad, se requiere estimar las siguientes cantidades:

a = Tiempo o estimacin Optimista. El que representa el tiempo mnimo

posible sin importar el costo o cantidad de recursos materiales y humanos que

se requieran; es simplemente la posibilidad fsica de realizar la actividad en el

menor tiempo

b = Tiempo Pesimista. Es un tiempo excepcionalmente grande que pudiera

presentarse ocasionalmente como consecuencia de accidentes, falta de

suministros, retrasos involuntarios, causas no previstas, etc.

m = Tiempo Normal. El valor ms probable de la duracin de la actividad,

basado en la experiencia personal de un experto.


44
http://www.monografias.com/Fisica/index.shtmlhttp://www.monografias.com/trabajos12/higie/higie.shtml#tipohttp://www.monografias.com/Fisica/index.shtmlhttp://www.monografias.com/trabajos12/higie/higie.shtml#tipo


29/80


Si Tij es la variable aleatoria asociada a la duracin de la actividad (i; j), PERT

asume que Tij sigue una distribucin Beta. Sin entrar en mayores detalles de

esta distribucin, se puede demostrar que el valor esperado y la varianza de la

variable aleatoria Tij quedan definidas por:

En PERT se asume adems que la duracin de las actividades es

independiente. Por lo tanto, el valor esperado y la varianza de una ruta pueden

ser estimadas segn:

= Duracin esperada de la ruta

= Variacin de la duracin de la ruta

5. Determinar la trayectoria crtica

La trayectoria crtica es determinada agregando los tiempos para las

actividades en cada secuencia y determinando la trayectoria mas larga del

proyecto.

La trayectoria crtica determina el tiempo total del calendario requerido para el

proyecto. Si las actividades fuera de la trayectoria ctrica aceleran o retrasaron

el tiempo (dentro de los lmites), entonces el tiempo total de proyecto no varia;

la cantidad del tiempo en que una actividad de la trayectoria crtica no altera la

duracin del proyecto se denomina holgura.

Si la trayectoria crtica del proyecto no resulta obvia, entonces puede ser

provechoso determinar las cuatro cantidades siguientes para cada actividad:

ES, Inicio ms temprano.

EF, Inicio ms tardo.


45


30/80


LS, terminacin ms temprana.

LF, terminacin ms tarda.

Se calculan estos tiempos usando el tiempo previsto para las actividades

relevantes. Los tiempos de inicio y terminacin ms tempranos de cadaactividad son determinados trabajando desde el inicio al final a travs de la red

y determinando el tiempo ms temprano en el cual una actividad puede

comenzar y acabar considerando las actividades del precursor.

Los tiempos de inicio y terminacin ms tardos son el tiempo ms tarde en

que una actividad puede comenzar o acabar sin variar el proyecto. El LS y el LF

son encontrados trabajando desde el final hacia atrs a travs de la red.

La diferencia entre la terminacin ms tarda y la terminacin ms temprana

da como resultado la holgura de una actividad. La trayectoria crtica entonces

es la trayectoria a travs de la red en la cual ningunas de las actividades

tienen holgura.

La variacin en el tiempo de la terminacin del proyecto puede ser calculada

sumando las variaciones en los tiempos de la terminacin de las actividades en

la trayectoria crtica. Dado esta variacin, una puede calcular la probabilidad

que el proyecto ser terminado por cierta fecha si se asume una distribucin

normal de la probabilidad para la trayectoria crtica.

Sea CP la variable aleatoria asociada a la duracin total de las actividades de la

ruta crtica determinadas mediante CPM. PERT asume que la ruta crtica

encontrada a travs de CPM contiene suficientes actividades para emplear el

Teorema Central del Lmite y concluir que CP se distribuye normalmente.

Puesto que la trayectoria crtica determina la fecha de la terminacin del

proyecto, el proyecto puede ser acelerado agregando los recursos requeridos

para disminuir el tiempo para las actividades en la trayectoria crtica.


46


31/80


6. Actualizar segn el progreso del proyecto

Mientras que el proyecto se desarrolla, los tiempos estimados se pueden

sustituir por tiempos reales. En casos donde haya retrasos, los recursos

adicionales pueden necesitarse de manera permanentemente.

2.2 Evaluacin del costo beneficio

Hoy en da el Software es el elemento ms caro en la mayora de los sistemas

de informacin, por lo que la estimacin debe realizarse cuidadosamente ya

que un gran error en la estimacin del costo puede ser lo que marque la

diferencia entre beneficios y prdidas tanto para clientes y la empresa

desarrolladora de software.

De acuerdo con Pfleeger [PFL02], dentro de la planificacin es crucial

comprender cul ser el costo aproximado de ste. Unas de las razones son

porque:

o Los costos excedidos pueden causar que los clientes cancelen el

proyecto.

o Los costos subestimados lo que puede no compensar el tiempo invertido

por el equipo del proyecto.

No se debe olvidar que la estimacin es una actividad compleja que se vale de

modelos y de tcnicas y estos a su vez se basan en mtricas, por lo que es

necesario profundizar sobre stas.

2.2.1 Mtricas de Software


47


32/80


Dentro de la Ingeniera de Software existe controversia con las mtricas, como

lo son las siguientes:

o Algunos desarrolladores piensan que el recolectar mtricas es difcil y

consume mucho tiempo.o Otros que es difcil ponerse de acuerdo de lo que se tiene que medir, las

mtricas que se utilizarn para hacerlo y posteriormente como utilizar

los resultados obtenidos.

Pressman [PRE02], comenta que an cuando muchos desarrolladores de

software se resisten al uso de las mtricas como una gua en su trabajo, no

dejan de ser muy importante su estudio, ya que ayudan a entender y mejorar

el proceso de desarrollo de un producto. Sin ellas no se tendra la certeza de

una mejora tanto en el desarrollo del producto como en la calidad del producto

en si.

De acuerdo a Lord Kelvin Cuando se puede medir lo que se esta diciendo y

expresarlo con nmeros, significa que tenemos conocimientos sobre ese tema, cuando esto

no ocurre significa que nuestro conocimiento es precario y deficiente.

La medicin es muy comn en el mundo de la ingeniera en general. An as,con respecto a la ingeniera de software no lo es tanto por las cuestiones

descritas anteriormente. Sin embargo hay razones que justifican la medicin

del software:

o Nos indica la calidad del producto referencia

o Nos ayudan a evaluar

o la productividad de la gente que desarrolla el producto

o los beneficios de utilizar nuevos mtodos y herramientas de

ingeniera de software justificando el uso de stos.

o Esta evaluacin permite una mejora continua al proceso de

desarrollo de software.


48


33/80


o Nos ayuda a establecer una lnea base para la estimacin

Qu es una medida:

Cuando se recopila un solo aspecto de los datos se est hablando de medidas.

Ejemplo: nmero de lneas de cdigo o nmero de errores.

La medicin es el acto de determinar una medida. Y es el resultado de la

recopilacin de uno o varios aspectos de los datos. Ejemplo: se investiga un

nmero de revisiones de mdulos para recuperar las medidas de errores

encontrados durante cada revisin.

Qu es una mtrica

Es una medida cuantitativa del grado en que un sistema, componente o

proceso posee un atributo dado (IEEE Standard Glossary of Software

Engineering, 1993).


49


34/80


Describe en cierta forma las medidas individuales sobre algn aspecto.

Ejemplo: el nmero de errores encontrados por revisin o por persona.

Fiabilidad, facilidad de uso, facilidad de cambio, etc.

Un ingeniero de software recopila medidas y desarrolla mtricas para obtener

indicadores. Un indicador: es una mtrica o una combinacin de mtricas que

proporcionan un visin profunda del proceso y proyecto del software o del

producto en si mismo.

Por medio de los indicadores, el gestor de proyecto o ingeniero de software

pueden ajustar el producto, proyecto o proceso para mejorar las cosas. Hay

dos tipos de indicadores o mtricas: Indicadores deproceso e indicadores del

proyecto. Muchas de las mtricas se pueden utilizar tanto en el dominio del

proceso cono en el del proyecto [PRE04].

1. Indicadores deproceso.

o brindan una visin profunda sobre la eficacia de un proceso ya

existente.

o permiten evaluar lo que est y no funcionando.

o Su propsito es mejorar los procesos de software a largo plazo y

conducir a estrategias que permitan mejorar la calidad del proceso.

2. indicadores del proyecto.

Son utilizadas para supervisar el progreso durante el desarrollo de software

y controlar la calidad del producto, adems se utilizan para realizar las

estimaciones de tiempo y esfuerzo. Permiten al gestor de proyecto:


50


35/80


o Evaluar el estado del proyecto

o Seguir las pistas de los riesgos potenciales

o Detectar las reas de problemas para evitar reas crticas

o Ajustar el flujo y las tareas del trabajo

o Evaluar la habilidad del equipo del proyecto para controlar la calidad

del producto de software.

Las mediciones del mundo fsico pueden englobarse en dos categoras, directas

e indirectas:

o medidas directas como lo es el largo de un tornillo

o y medidas indirectas como lo es la calidad de un tornillo.

Las mtricas del software pueden ser catalogadas en forma anloga, directas e

indirectas y se aplican al proceso, proyecto y producto de software.

Medidas directas:

o del proceso, donde se miden los datos cuantitativos del software, como

costo y esfuerzo aplicado, nmero de ocurrencias de un evento .

o del producto, donde se miden las caractersticas del software y se

dividen a su vez en dinmicas y estticas:

o dinmicas: aquellas que se relacionan directamente con los

atributos de calidad del software y que se miden al momento

en que un programa est en ejecucin. Un ejemplo es obtener

el tiempo de ejecucin, defectos, etc.

o estticas: los resultados de estas mediciones se obtienen departes que representen al sistema como lo es el diseo,

cdigo, documentos. Como lo es el medir las lneas de cdigo

producidas.


51


36/80


Ejemplo: mtricas orientadas al tamao. Que son medidas directas del

software y el proceso de software. Para estimar el esfuerzo.

Medidas indirectas:

o calidad, funcionalidad, eficiencia, facilidad de mantenimiento, etc.

Ejemplo: mtricas orientadas a la funcin. Son medidas indirectas del proceso

de software.

Mtricas orientadas al tamao

Las mtricas del software orientadas al tamao son medidas directas del

proceso de software, provienen de la normalizacin de las medidas de calidady/o productividad considerando el tamao de software que se ha producido

[PRE02]. La mtrica orientada al tamao ms utilizada es LOC (Lines Of Code)

o SLOC (Source Lines Of Code) en espaol lneas de cdigo LDC. Calcula el

tamao de un producto en LDC y con esto el grado de errores y productividad

entre otros.

Teniendo la tabla 2.2.1 como ejemplo podran calcularse los valores a

continuacin

Nombre

del

proyecto

N de

Personas

Costo $ N de

errores

N de pginas

de

documentacin

Esfuerzo

empleado

(das/hombre)

Lneas de

cdigo

(LDC)

Proy1 15 20Mil 520 320 1200 3220

Proy2 10 17Mil 380 450 1000 2800tabla 2.2.1

Productividad =LDC / persona mes

Costo = $ / LDC

Grado de errores = N de errores / LDC

Grado de documentacin = N de pginas documentadas / LDC

Ventajas:


52


37/80


o Que son fciles de calcular en cualquier proyecto

o Existen varias herramientas de estimacin basadas en las lneas de

cdigo

Desventajas:

o la falta de una definicin universal de lnea de cdigo

o las lneas de cdigo dependen de los lenguajes de programacin y por lo

tanto perjudica a los programas ms cortos pero bien diseados.

o El estilo de programacin depender de cada persona. Comparar la

productividad utilizando lenguajes diferentes de programacin puede

llevar a conclusiones errneas respecto a la productividad de los

programadores.

o El decidir que lneas de cdigo se contabilizaran ya sean nuevas, lneas

modificadas, reutilizadas ms definiciones de datos y comentarios.

o dificultad de estimar en fases tempranas del desarrollo la cantidad de

lneas que tendr una aplicacin.

Mtricas orientadas a la funcin

Es un mtodo para cuantificar el tamao y la complejidad de un sistema

software en trminos de las funciones que el usuario desarrolla o desarrollar.

Utilizan una media de la funcionalidad de software como valor de

normalizacin. Puesto que la funcionalidad no puede medirse directamente se

debe obtenerla indirectamente a travs de otras medidas directas.

Se entiende por funciones a las entradas, salidas, archivos, etc.

La primera propuesta de los puntos de funcin fue realizada por Albrecht,

mtrica que hasta hoy es muy utilizada. De sta se derivan otras como los

puntos de caracterstica y los puntos de funcin para estimacin temprana.


53


38/80


Para calcular los puntos de funcin es necesario conocerlo siguiente y se

muestra en la tabla 2.2.2:

1. Nmero de entradas de usuario: aquellas que permiten aadir, borrar o

cambiar datos de un programa. (flujos de datos de entrada en el

diagrama de contexto), ejemplos: Pantallas, formularios, cuadros de

dialogo, controles o mensajes.

2. Nmero de salidas de usuario: aquellas que proporciona informacin al

usuario. Ejemplos: Pantallas, informes, grficos o mensajes.

3. Nmero de consultas de usuario. Es una entrada interactiva que es el

resultado de una respuesta en forma de salida interactiva, en otras

palabras, es una entrada que produce una respuesta (consulta).

4. Nmero de archivos lgicos internos, se cuenta cada archivo de forma

individual. Son los principales grupos lgicos de datos de usuarios finales

o informacin de control que es manejada absolutamente por el

programa. Un archivo lgico podra constar de un nico archivo plano o

de una sola tabla en una base de datos relacional.

5. Nmero de interfaces externos con otros sistemas Archivos controlados

por otros programas, con los que el programa va a interactuar. Esto

incluye cada uno de los principales grupos de datos lgicos o

informacin de control que entre o salga en el programa.

Parmetros de medicin Cuenta

simple

Cuenta

media

Cuenta

compleja

total

N entradas

N salidas

N peticiones

N archivos

N interfaces

* 3 + * 4 + *6

Cuenta


54


39/80


total

Tabla 2.2.2 tabla de parmetros de medicin

PF (Puntos de funcin) = Cuenta total * [0,65+0,01 fi]

Fi son unos valores de ajuste de la complejidad, en total son 14 y se

consiguen evaluando las siguientes 14 preguntas de 0 a 5 donde:

0: No tiene influencia

1: Tiene influencia muy baja

2: Influencia moderada

3: Influencia media

4: Influencia significativa

5: Son esenciales

1. Requiere el sistema copias de seguridad y de recuperacin fiables?

2. Se necesita comunicacin datos?

3. Existen funciones de procesamiento distribuido?

4. Es crtico el rendimiento?

5. Se ejecutar el sistema en un entorno operativo existente y altamente

utilizado?

6. Se requiere entrada de datos interactiva?

7. La entrada de datos interactiva debe hacerse desde mltiples

pantallas?

8. Se actualizan los datos maestros de forma continua?

9. Son complejas las entradas, salidas, los archivos o las peticiones?

10.Es complejo el procesamiento interno?

11.Se ha diseado el cdigo para ser reutilizable?

12.Estn incluidas en el proyecto la conversin e instalacin?

13.Se ha diseado el software para instalarlo en diferentes empresas?

14.Se ha diseado el software para facilitar los cambios y ser fcilmente

usado por el usuario?


55


40/80


Cuando se han considerado los 14 factores de influencia, y se les han asignado

puntuaciones individualmente, la suma de estos factores es convertida en un

ajuste de la complejidad final siguiendo el procedimiento siguiente:

1. Multiplicar la suma de los factores por 0,01, para convertir la suma en un

valor decimal.

2. Sumar la constante 0,65 al valor decimal para crear un factor multiplicador

de la complejidad.

3. Multiplicar el valor no ajustado del total de los puntos de funcin por el

multiplicador de la complejidad, para conseguir un valor de puntos de

funcin ajustado.

Productividad= PF/persona mes

Costo= pesos/PF

Ventajas:

o son independientes del lenguaje de programacin y desde este punto de

vista lo hace ms atractivo como enfoque de estimacin.

o pueden ser estimados a partir de la especificacin de requisitos o

especificaciones de diseo, lo que permite una estimacin temprana.

o Como se basan en una visin externa del usuario, los usuarios no

tcnicos entienden mejor lo que los puntos de funcin estn midiendo.

Desventaja: Como aspecto negativo tienen el que se basan en unas

valoraciones subjetivas y adems que el PF no tienen un significado fsico

directo. (e)

Puntos de Caracterstica

Debido a que el anlisis por Puntos de Funcin fue diseado para software de

gestin y no es fcil de generalizar a aplicaciones cientficas, de tiempo real y

otras, Caper Jones propuso ampliaciones al mtodo que denomin Puntos de


56


41/80


Caracterstica, que da cabida a aplicaciones cuya complejidad algortmica es

alta.

Este mtodo considera los mismos elementos que considera Albrecht en su

mtodo de anlisis por puntos de funcin, slo que aade la variable nmero

de algoritmos y elimina los niveles de complejidad [PRE02].

Puntos de objeto

Los puntos de objeto son una medida alternativa relacionada con la

funcionalidad cuando se utilizan lenguajes de cuarta generacin o similares

para el desarrollo. Los puntos de objeto noson clases de objetos [SOM00].

El nmero de puntos de objeto en un programa es una estimacin ponderada

de:

o El nmero de pantallas que son visualizadas por separado

o El nmero de informes que se producen por el sistema

o El nmero de mdulos lenguajes de tercera generacin que deben

desarrollarse para complementar el cdigo 4G.

Mtricas para la calidad del software

Cualquier proyecto de ingeniera del software tiene como objetivo principal

obtener sistemas y productos de alta calidad [PRE02]. La calidad es difcil

medirla directamente, no obstante hay indicadores que nos pueden dar una

idea sobre la misma. Gilb basa estos indicadores en los siguientes aspectos:

o Correccin.- Es el grado en el que el software lleva a cabo su funcin.

Se mide en defectos por KLDC (miles de lneas de cdigo),

entendindose por defecto cualquier falta de concordancia con los

requisitos.

o Facilidad de mantenimiento.- Se mide por la facilidad de:


57


42/80


o corregir defectos encontrados,

o adaptar ese programa a nuevos entornos

o mejorar el programa si el cliente desea cambios.

La facilidad de mantenimiento se mide indirectamente por medio de una

mtrica orientada al tiempo: tiempo medio del cambio (TMC), es decir,

por el tiempo que se tarda en analizar la peticin del cambio, disear la

modificacin, implementarla, probarla y distribuir la notificacin del

cambio a los usuarios.

o Integridad.- Mide la habilidad de un sistema para resistir ataques

contra su seguridad. El proteger los datos, programas y

documentacin debe ser una prioridad. Para medirla se consideran

dos atributos adicionales:

o Amenaza, que es la probabilidad estimada o deducida de que se

produzca un ataque de un tipo determinado.

o Seguridad: Probabilidad estimada o deducida de el nuestro

sistema pueda repeler dichos ataques.

La Integridad del sistema se define como:

integridad= (1- amenaza(1-seguridad))

o Facilidad de uso.- Entendindose como tal lo amigable que resulta

al usuario el sistema. Es un intento de cuantificar los amigable que

es el sistema. Se puede deducir a partir de cuatro caractersticas:

1- Habilidad intelectual o fsica requerida para aprender el

sistema.2- El tiempo requerido para llegar a ser moderadamente eficiente

en el uso del sistema.

3- El aumento de productividad de alguien que usa el sistema.

4- Valoracin subjetiva de la disposicin de los usuarios hacia el

sistema.


58


43/80


Se concluye con lo que respecta a las mtricas, que definen que es lo que se

va a predecir y los mtodos o tcnicas definen como una mtrica es predicha.

Se recomienda hacer la estimacin utilizando ms de un modelo o tcnica para

que una respalde o refute a la otra.

Con el conocimiento sobre las mtricas del software se puede proseguir con el

tema de la estimacin.

2.2.2 Estimacin del proyecto de software

De acuerdo con Pressman [PRE02], con frecuencia una estimacin ms que

una ciencia es un arte pero no por ello debe descuidarse, sino ms bien se

debe realizarla de manera estricta. Cualquier estimacin lleva consigo un

riesgo o incertidumbre vindose esta afecta por: (observaciones de la

estimacin)

o Complejidad del proyecto: es una medida relativa que se ve afectada

por la familiaridad que se tenga con esfuerzos anteriores.

o Tamao del proyecto: afecta a la precisin y eficiencia de las

estimaciones. Cuanto mayor sea el proyecto, mayor ser el riesgo de la

estimacin.

o Disponibilidad de informacin histrica: Si no se dispone de informacin

de proyectos anteriores similares la incertidumbre ser mayor.

El riesgo o incertidumbre sobre las estimaciones afectan al costo, a los

recursos necesarios y a la planificacin temporal.

Suponiendo que se subestima el esfuerzo, un costo superior al previsto puede

hacer que los beneficios obtenidos sean nulos o negativos. Sobrestimar el

esfuerzo puede tambin afectar a la competitividad de la compaa as como

provocar perdida de beneficios, por ejemplo podra contratarse personal en

exceso para la realizacin del proyecto.

Lo que la estimacin busca determinar es:


59


44/80


Una buena estimacin de costo al comienzo del proyecto nos ayuda a conocer

cuantos desarrolladores se requerirn y as preparar el equipo apropiado para

que est disponible cuando se lo necesite [SOM00].

Los recursos.

Una de las tareas importantes de la planificacin del desarrollo de softwarees la estimacin de los recursos requeridos para acometer el esfuerzo.

De acuerdo con Pressman [PRE02], se considera una pirmide de recursos

ilustrada en la figura 2.2.2.1:

1. En la base se encuentran los recursos tcnicos, hardware y software,

que proporcionan la infraestructura de soporte de desarrollo de

software.

2. En el segundo nivel se encuentran los componentes reutilizables,

bloques de software que servirn para el nuevo desarrollo.

3. Y en la punta los recursos primarios, los recursos humanos.

Fig. 2.2.2.1 recursos del proyecto


60


45/80


De cada recurso se debe especificar las siguientes caractersticas, que son las

que se toman en cuanta a la hora de la estimacin.

o Descripcin del recurso

o Informes de disponibilidad

o Fecha en la que se requiere el recurso, inicio y fin

o Tiempo durante el que ser aplicado el recurso

Las dos ltimas caractersticas, se denominan ventana temporal que

representa la disponibilidad de un recurso para un proyecto especfico, y debe

ser fijado lo antes posible para una buena planificacin de recursos.

Recursos Humanos.- La Cantidad de personas requeridas para el desarrollo de

un proyecto de software slo 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.

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 tambin validarse para una fcil

integracin.

Bennatan sugiere cuatro categoras de recursos de software que se deberan

tener en cuenta a medida que se avanza con la planificacin:

o Componentes ya desarrollados.

o Componentes ya experimentados.

o Componentes con experiencia Parcial.

o Componentes nuevos.


61


46/80


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.

2.2.2.1 Tcnicas para la estimacin del software

Para realizar estimaciones seguras de costos y esfuerzos tienen varias

opciones posibles:

1. Dejar la estimacin para ms adelante (obviamente se puede realizar

una estimacin 100% fiable despus de haber terminado el proyecto).

2. Basar las estimaciones en proyectos similares ya terminados.

3. Utilizar tcnicas de estimacin relativamente sencilla para generar las

estimaciones de costos y esfuerzo del proyecto.

4. Utilizar un modelo emprico para l clculo de costos y esfuerzos del

Software.

Desdichadamente la primera opcin, aunque atractiva no es prctica. 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


62


47/80


conjuntamente las tcnicas indicadas usando cada una de ellas como

comprobacin de las otras.

Tcnicas de descomposicin.

Antes de hacer una estimacin, el planificador del proyecto debe comprender

el mbito del software a construir y generar una estimacin de su tamao.

La estimacin de un proyecto de software se predice basndose en lo

siguiente:

1. Por el grado en el que el planificador ha estimado adecuadamente el

tamao del proyecto.

2. Por la habilidad en traducir el tamao en:

a. Esfuerzo humano

b. Tiempo y

c. Dinero

3. Por el grado en el que el plan del proyecto refleja las habilidades del

equipo.

4. Por la estabilidad de los requerimientos y del entorno de desarrollo.

La estimacin del tamao es el reto del planificador, ya que en el contexto de

la planificacin de proyectos, el tamao se refiere a una produccin

cuantificable del proyecto de software. Se puede realizar de forma directa

utilizando LDC o de manera indirecta utilizando PF. As mismo se puede basar

en el problema o en el proceso.

Estimacin basada en el problema.- los datos de LDC y PF se utilizan de dos

formas: 1) como una variable de estimacin que se utiliza para cada elemento

del software y 2) como mtricas de lnea de base recopiladas de proyectos

anteriores y utilizadas junto con variables de estimacin para desarrollar

proyecciones de costo y esfuerzo.


63


48/80


Estimacin basada en el proceso.- Es una de las tcnicas ms comunes para

estimar un proyecto. Lo que se hace es descomponer el proceso en un

conjunto relativamente pequeo de actividades y en el esfuerzo requerido para

llevar a cabo cada actividad. 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.

Otras tcnicas de estimacin.

Juicio Experto

Es la tcnica ms utilizada para realizar estimaciones de costos y tiempos. Son

tcnicas informales basadas en la experiencia de los gestores de proyecto o de

otras personas que hayan desarrollado aplicaciones similares.

De acuerdo con Sommerville [SOM00] las ventajas estn en que es una tcnica

estimacin econmica y puede ser precisa si los expertos tienen una

experiencia directa con sistemas similares.

La desventaja es que puede ser inexacto si no existen tales expertos.


64


49/80


Estimacin por analoga

Tambin se hace uso de analogas, al tener un sistema parecido entonces

pueden basar la estimacin en la similitud. Si el proyecto actual es bastante

similar a los esfuerzos de uno anterior y si otras influencias del proyecto son

similares, entonces el costo y esfuerzo para producirlo debera ser similar

[PFL02].

De acuerdo a [SOM00] la ventaja de esta tcnica est en que es precisa si est

disponible la informacin del proyecto con el cul se va a comparar.

La desventaja es que es imposible de comparar si el proyecto ha sido

abordado. Trae consigo costos de mantenimiento de la base de datos.

De acuerdo con Pfleeger [PFL02], para hacer una estimacin ms formal, se les

pide a varios expertos que hagan tres predicciones:

Pesimista (EP)

Optimista (EO)

La conjetura ms probable (EMP)

Asignndole una probabilidad a cada una, se obtiene la estimacin mediante:

E=EO *Po + EMP*Pmp + EP*Pp

Donde Po es la probabilidad asignada a la estimacin optimista, Pmp la

asignada a la ms probable y Pp la asignada a la pesimista.

Ley de Parkinson

Los costos del proyecto estn en funcin de los recursos disponibles, utilizando

todo el tiempo permitido [SOM00].

Ventaja: No se sobrepasa el presupuesto.

Desventaja: El sistema normalmente no se termina.


65


50/80


Pricing to win

El costo del proyecto est en funcin de lo que el cliente est dispuesto a

pagar [SOM00].

Ventaja: La empresa desarrolladora consigue el contrato

Desventaja: La probabilidad de que el cliente obtenga el sistema que quiere es

mnima, y los costos no reflejan realmente el trabajo requerido.

Esta es algunas veces la nica tcnica aplicable, aunque es poco profesional.

La estimacin completa puede estimarse mediante dos tipos de anlisis

[SOM00]:

o Top-down (descendente): Comienza a nivel de sistema y evala la

totalidad de funcionalidades y cmo stas se subdividen en subsistemas

o Bottom-up (ascendente): Comienza a nivel de componentes y estima el

esfuerzo requerido para cada componente. Dichos esfuerzos se aaden

a la estimacin final

Estimacin descendente

o Se puede usar sin conocer la arquitectura ni los componentes que

formarn parte del sistema.

o Tiene en cuenta costos tales como integracin, gestin de

configuraciones y documentacin.

o Puede sub-estimar costos relacionados con la resolucin de problemas

tcnicos de bajo nivel difciles de resolver.

Estimacin ascendente

o Se puede usar cuando la arquitectura del sistema es conocida y los

componentes han sido identificados.

o Proporciona estimaciones bastante precisas si el sistema se ha diseado

con detalle.


66


51/80


o Puede subestimar costos a nivel de sistema, tales como integracin y

documentacin.

An cuando en la prctica, la mayora de las estimaciones se basan en el juicio

experto y en la informacin histrica, es importante conocer algunos modelos y

tcnicas de estimacin que de manera conjuntan con el uso de mtricas

devuelven una estimacin. De acuerdo con Sommerville [SOM00], la

estimacin se debe basa en varias tcnicas que devuelvan datos aproximados.

2.2.2.2 Modelos de estimacin

Modelos algortmicos

Son modelos que expresan la relacin entre el esfuerzo y los factores que lo

influencian. Utilizan ecuaciones donde el esfuerzo es la variable dependiente y

varios factores como la experiencia, tamao (que es el de mayor influencia) y

tipo de sistema, son las variables independientes.

Estos modelos suelen basarse en el tamao del software y tienen un

componente exponencial (los costos no crecen normalmente de forma lineal

con el tamao del proyecto).

Esfuerzo = A x TamaoB x M

Uno de los problemas con este tipo de modelo es que el tamao es una

variable clave, y al momento de hacer la estimacin la informacin sobre el

tamao es incierta [PFL02].

Modelos empricos

Los Modelos empricos se dividen en:

o paramtricos. Los cuales tiene una formula funcional explcita,

relacionando una variable dependiente con una o ms variables


67


52/80


o no paramtricos. no tiene una formula funcional explcita, por ejemplo,

un modelo desarrollado usando la tcnica de aprendizaje mquina como

una red neuronal.

Los modelos de estimacin ms comunes son los Modelos paramtricos

empricos de estimacin:

o Utilizan frmulas derivadas empricamente para predecir el esfuerzo

como una funcin de LDC o PF.

o Utilizan datos empricos obtenidos de una muestra de proyectos:

o Son difciles de usar para todas las clases de software y todos los

entornos de desarrollo

o Se deben calibrar para las condiciones especficas de una

organizacin

La siguiente es la frmula para obtener la estimacin del esfuerzo en personas-

mes.

El Modelo COCOMO.

De estos modelos lo ms conocidos son los COCOMO (Constructive cost

model). El modelo de COCOMO est definidos para tres tipos de proyectos de

software [SOM00]:

Simple: relativamente sencillos y pequeos

Moderado: intermedios en cuanto al tamao y complejidad

Embebido (empotrado):proyectos que deben ser desarrollados en unconjunto de hardware, software y restricciones operativas muy

restringidas.


68

E = A + B X (ev) c

DondeA y B: son constantes obtenidas empricamenteE: esfuerzo en meses/personaev: variable de estimacin (LDC o PF)


53/80


El modelo constructivo de costos de Boehm es una jerarqua de modelos de

estimacin constituida por los siguientes:

Modelo I. El Modelo COCOMO bsico utilizaba las lneas de cdigo como factor

clave. Calcula el esfuerzo y el costo del desarrollo de Software en funcin del

tamao del programa, expresado en lneas de cdigo (LDC) estimadas.

E = ab LDC bb = personas / mes

C= cb E db = meses

En la tabla se muestran los valores para cada tipo de proyecto que toma cada

constante de la frmula del esfuerzo.

Proyecto ab Bb cb dbSimple 2,4 1,05 2,5 0,38Moderado 3,0 1,12 2,5 0,35Embebido 3,6 1,20 2,5 0,32

Tabla 2.2.2.2 valores para frmula del esfuerzo.

Modelo II.Como es imposible conocer al inicio del ciclo de desarrollo las lneas

de cdigo el COCOMO II refleja tres niveles principales de cualquier proyecto.

los siguientes niveles son de acuerdo a [SOM00] y [PFL02].

Nivel inicial de prototipado: poco se conoce sobre el tamao del producto final,

entonces se estima la dimensin sobre la base de lo que sus creadores

denominan puntos de objeto y una frmula simple para el clculo del esfuerzo.

En otras palabras, captura las dimensiones en trminos de generadores de

esfuerzo, tales como el nmero de pantallas, de informes, de componentes de

lenguajes, etc.

PM = ( NOP x (1 - %reuso/100 ) ) / PROD

PM es el esfuerzo en personas-mes, NOP es el nmero de puntos de objeto, y

PROD es la productividad que depende de:


69


54/80


o La experiencia y capacidad del desarrollador

o Las capacidades de la herramienta CASE utilizada

Y toma los valores presentados en la tabla 2.2.2.3.

Muy baja Baja Nominal Alta Muy alta4 7 13 25 50

Tabla 2.2.2.3

Nivel inicial de diseo: cuando se decide por una arquitectura para el diseo,

nuevamente no hay suficiente informacin para una estimacin precisa de

esfuerzo y duracin, pero se conoce ms que en el nivel 1. Entonces se emplea

puntos de funcin convertidas en LDC.

Las estimaciones pueden hacerse despus de que los requerimientos hayan

sido establecidos.

Se basa en las frmulas estndar para mtodos algortmicos:

PM = A x TamaoB x M + PMm

en donde

M= PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED

PMm= (ASLOC x (AT/100)) / ATPROD

A = 2.5 segn la calibracin inicial, Tamao se da en LDC, B vara desde 1.1

hasta 1.24 dependiendo de la novedad del proyecto, la flexibilidad del

desarrollo, la gestin de riesgos, y la madurez del proceso

Los multiplicadores (M) reflejan la capacidad de los desarrolladores,requerimientos no funcionales, la familiaridad con la platafo

Documents

39861943 Unidad II Planif y Modelado