Unidad II Planif y Modelado

Planificacin y Modelado Planificacin 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 a cabo 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.
No hay un proceso estndar. Y por lo tanto tampoco se tiene la certeza de cuando un proceso en particular empieza a tener problemas. 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

o
Redaccin de la propuesta. Planificacin del proyecto o estimaciones de costo, tiempo y esfuerzo. Supervisin y revisin del proyecto. Seleccin y evaluacin del personal.
o o
Ingeniera en Sistemas Computacionales
17
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
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 o o o o o o o Experiencia en el dominio de la aplicacin. Experiencia en la plataforma. Experiencia en el lenguaje de programacin. Capacidad de aprender. Habilidades de comunicacin. Adaptabilidad. Actitud. 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
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 3 4 5 N
Lneas de comunicacin 1 3 6 10 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
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
productos de calidad. La eleccin de una estructura apropiada depende del nmero de personas en el equipo, de las caractersticas de personal y los dos tipos de estilos de trabajo, entre otras cosas. Existen muchas formas de para la organizacin de proyectos, a continuacin se describirn 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 del equipo 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
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 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: se diferencia de jefe de
o Un gran nmero de personal involucrado

o Un alto grado de certeza
23
o o o
Estabilidad Uniformidad 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 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: proyectos los requerimientos probablemente
cambien durante su desarrollo, por esto necesitan una estructura ms flexible
24
o
o
Es una gua de desarrollo para cumplir las metas del proyecto. 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 o o o Retraso de tiempo de entrega Sobrepasar el presupuesto Baja calidad del producto 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 o o dentro de los tiempos establecidos conforme a los estndares requeridos 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 ilustradas en la figura 2.4: o
o
las siguientes
Delimitar el mbito del software Realizar estimaciones de tiempo, costo y esfuerzo Calendarizar el trabajo
25
Planificacin y Modelado Planificacin del Sistema o
Gestionar riesgos Controlar la calidad y los cambios Gestin de configuracin de software
o o
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 o se toman las decisiones de continuar o no con el proyecto se determina o o el calendario el presupuesto
26
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 o Reconsiderar el plan de la siguiente iteracin para realizar los cambios necesarios a ste. Modificar el proceso, adaptar las herramientas, prolongar la preparacin y 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
o o
avanzando de acuerdo al presupuesto y calendarizacin. 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
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

proyecto.
un nivel mensurable en el
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 actividad
para el gestor de proyectos. Cuando se trata de un resultado de una actividad los informes de estos logros deben ser cortos.
29
Ejemplos de hitos son los siguientes:
o la especificacin de requerimientos.
o o o la terminacin de un manual de usuario realizacin de un conjunto de clculos 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
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 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. mxima sugerida es de 8 a 10 semanas. Las actividades por lo general duran al menos una semana, la cantidad de tiempo que muestran las actividades, los responsables, la dependencia entere actividades
31
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
Ejemplo: Supongamos las actividades mostradas en la tabla 2.1.2, se muestra su duracin e interdependencia. La M representa un hito.
Tarea Duracin (das) T1 (M1
Dependencias
T1
T2
T3
15 15
T4 T5 10 10
T2,T 4 (M2 )
T6 5
T1,T 2 (M3 )
T7 20
T1 (M1 )
T8 25
T4 (M5 )
T9 15
T3, T6 (M4 )
T10 15
T5, T7 (M7 )
T11 7
T9 (M6 )
T12 10
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
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 presentar algn 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
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 sta. pasa del lmite de tiempo marcado por
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
Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
Ingenier o Jane Anne Jane Fred Mary Anne Jim Fred Jane Anne Fred 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
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 se requieren 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
Las diferencias entre PERT y CPM son las siguientes listadas en la tabla 2.1.7: PERT es un mtodo Probabilstico. Considera que la variable de tiempo es una variable desconocida de la cual solo se tienen datos estimativos. CPM es un mtodo Determinstico. Considera que los tiempos de las actividades se conocen y se pueden variar cambiando el nivel de recursos utilizados.
El suma
tiempo de
esperado los
de A medida que el proyecto avanza, estos
finalizacin de un proyecto es la estimados se utilizan para controlar y todos de las tiempos monitorear el progreso. Si ocurre algn en el proyecto, se hacen esfuerzos por lograr que el proyecto quede de nuevo dentro de los tiempos programados cambiando la asignacin Suponiendo las que las son de recursos. Considera que las actividades son continuas e interdependientes, siguen un orden cronolgico y ofrece parmetros del momento oportuno del inicio de la actividad. esperados actividades retraso
sobre la ruta crtica.
distribuciones de los tiempos de actividades independientes, la varianza del proyecto es la suma de las varianzas de las actividades en la ruta crtica.
Considera tres estimativos de tiempos:
Considera acelerados actividad,
tiempos de segn una la
normales cantidad
y de
determinada
o el ms probable o optimista,
o pesimista.
recursos aplicados en la misma.
Tabla 2.1.7 diferencias entre PERT y CPM
Mtodo CPM
38
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 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.
se les preguntar a los responsables de los
procesos cuales actividades deben quedar terminadas para ejecutar cada una
39
Planificacin y Modelado Planificacin del Sistema 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
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, que no 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 o o o
ES, Inicio ms temprano. EF, Inicio ms tardo. LS, terminacin ms temprana. 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
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
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. 2. 3. 4. 5. Identificar las actividades y su interdependencia Determinar la secuencia de actividades Construir el diagrama de red Tiempos estimados de actividades Determinar la trayectoria crtica Actualizar segn el progreso del proyecto
6. 43
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. Otras tareas 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
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
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 cada actividad 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
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 o Los costos excedidos pueden causar que los clientes cancelen el proyecto. 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
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
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
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 de proceso 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 de proceso.
o o o brindan una visin profunda sobre la eficacia de un proceso ya existente. permiten evaluar lo que est y no funcionando. 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
o o
Evaluar el estado del proyecto 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 o medidas directas como lo es el largo de un tornillo 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 de

partes que representen al sistema como lo es el producidas. diseo, cdigo, documentos. Como lo es el medir las lneas de cdigo
51
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 calidad y/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 Costo $ N de errores N de pginas de Esfuerzo empleado Lneas de cdigo (LDC)
Personas
documentacin (das/hombre)
Proy1 Proy2
15 10
20Mil 17Mil
520 380
320 450
tabla 2.2.1
1200 1000
3220 2800
Productividad =LDC / persona mes Costo = $ / LDC Grado de errores = N de errores / LDC Grado de documentacin = N de pginas documentadas / LDC Ventajas:
52
o o
Que son fciles de calcular en cualquier proyecto Existen varias herramientas de estimacin basadas en las lneas de cdigo
Desventajas: o o o la falta de una definicin universal de lnea de cdigo las lneas de cdigo dependen de los lenguajes de programacin y por lo tanto perjudica a los programas ms cortos pero bien diseados. 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 o El decidir que lneas de cdigo se contabilizaran ya sean nuevas, lneas modificadas, reutilizadas ms definiciones de datos y comentarios. 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
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 N entradas N salidas N peticiones N archivos N interfaces Cuenta
Cuenta simple
Cuenta media * 3 + *4
Cuenta compleja + *6
total
54
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
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 o o son independientes del lenguaje de programacin y desde este punto de vista lo hace ms atractivo como enfoque de estimacin. pueden ser estimados a partir de la especificacin de requisitos o especificaciones de diseo, lo que permite una estimacin temprana. 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
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 no son clases de objetos [SOM00]. El nmero de puntos de objeto en un programa es una estimacin ponderada de: o o o El nmero de pantallas que son visualizadas por separado El nmero de informes que se producen por el sistema 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
o o
corregir defectos encontrados, 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
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 o Complejidad del proyecto: es una medida relativa que se ve afectada por la familiaridad que se tenga con esfuerzos anteriores. 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
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 software
es 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
De cada recurso se debe especificar las siguientes caractersticas, que son las que se toman en cuanta a la hora de la estimacin. o o o o Descripcin del recurso Informes de disponibilidad Fecha en la que se requiere el recurso, inicio y fin 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 o o o Componentes ya desarrollados. Componentes ya experimentados. Componentes con experiencia Parcial. Componentes nuevos.
61
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
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
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
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
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 o Tiene en cuenta costos tales como integracin, gestin de configuraciones y documentacin. 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
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
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 o Utilizan frmulas derivadas empricamente para predecir el esfuerzo como una funcin de LDC o PF. Utilizan datos empricos obtenidos de una muestra de proyectos: o o Son difciles de usar para todas las clases de software y todos los entornos de desarrollo Se deben calibrar para las condiciones especficas de una organizacin La siguiente es la frmula para obtener la estimacin del esfuerzo en personasmes.
E = A + B X (ev)
Donde A y B: son constantes obtenidas empricamente E: esfuerzo en meses/persona ev: variable de estimacin (LDC o PF)
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 un conjunto de hardware, software y restricciones operativas muy restringidas.
68
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
db
C= cb E
= meses
En la tabla se muestran los valores para cada tipo de proyecto que toma cada constante de la frmula del esfuerzo. Proyecto Simple Moderado Embebido ab 2,4 3,0 3,6 Bb 1,05 1,12 1,20 cb 2,5 2,5 2,5 db 0,38 0,35 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
o o
La experiencia y capacidad del desarrollador Las capacidades de la herramienta CASE utilizada
Y toma los valores presentados en la tabla 2.2.2.3. Muy baja 4 Baja 7 Nominal 13
Tabla 2.2.2.3
Alta 25
Muy alta 50
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 etc. o o o o o o RCPX - fiabilidad de producto y complejidad RUSE - reutilizacin requerida PDIF - dificultad de la plataforma PREX - experiencia del personal PERS - capacidad del personal SCED - agenda requerida multiplicadores (M ) reflejan la capacidad de los desarrolladores,
requerimientos no funcionales, la familiaridad con la plataforma de desarrollo,
70
FCIL - facilidades de soporte de grupo
PM refleja la cantidad de cdigo generada automticamente. Nivel Post arquitectura: es cuando el desarrollo ha comenzado y se tiene mucha ms informacin. Para la estimacin de costos se utiliza entonces puntos de funcin o lneas de cdigo. Usa la misma frmula que la estimacin inicial de diseo: PM = A x TamaoB x M + PMm Se ajusta la estimacin de tamao para que tenga en cuenta: o o La volatilidad de los requerimientos Grado de posible reutilizacin
ESLOC = ASLOC x (AA + SU +0.4DM + 0.3CM +0.3IM)/100 ESLOC es el nmero de lneas de cdigo nuevo. ASLOC es el nmero de lneas de cdigo reusable que debe modificarse. DM es el porcentaje de diseo modificado. CM es el porcentaje de cdigo que se modifica IM es el porcentaje del esfuerzo original de integracin del software reusado. SU es un factor basado en la interpretacin del coste del software AA es un factor que refleja los costes de evaluacin iniciales para decidir si el software puede reutilizarse. El trmino exponente (B) depende de 5 factores de escala. La suma de dichos factores se divide por 100 y se aade a 1.01 Ejemplo: Antecedentes proyecto nuevo 4 Flexibilidad desarrollo no implicacin cliente Muy alto 1 Arquitectura/resolucin riesgos No. anlisis de riesgos Muy bajo 5 Cohesin del grupo nuevo grupo nominal 3
71
Madurez proceso algn control nominal 3 Por lo tanto El factor de escala es 1.17 Multiplicadores (M) o o o o Atributos del producto Atributos del ordenador Atributos del personal Atributos del proyecto El modelo COCOMO avanzado
Modelo III.
o o
incorpora todas las caractersticas del modelo intermedio evala el impacto de los conductores de costos en cada fase del proceso (anlisis, diseo, etc.).
2.2.2.3 La decisin desarrollar o comprar En muchas ocasiones es ms aconsejable adquirir un producto de software que desarrollarlo. Los gestores son los que tienen que tomar esta decisin y deben tener en cuenta lo siguiente [PRE02]:
1. Comprar/alquilar el software ya desarrollado con licencia y que se ajuste a las especificaciones. 2. Comprar componentes de software parcial o totalmente experimentados y luego modificarlos para ajustarse con las especificaciones. 3. Encargar la construccin del software a una empresa externa. Si se piensa en comprar software hay que tener en cuenta su costo. Si el costo es muy elevado entonces se debe tener en cuenta las siguientes directrices:
1. Desarrollo de una especificacin de la funcin y rendimiento del software
deseado.
2. Evaluar costo desarrollo interno y fecha de entrega.
72
Planificacin y Modelado Planificacin del Sistema 3. Seleccionar
tres o cuatro aplicaciones candidatos que se ajusten a la
especificacin o seleccionar componentes reutilizables.

4. Desarrollar una matriz de comparacin de funciones clave 5. Evaluacin de cada paquete de software seleccionad basndose en:
o o o o
Calidad de productos anteriores Soporte Post venta Reputacin organizacin Etc.
6. Recabar informacin de opiniones de otros usuarios de dicho software.
La decisin final de desarrollar - comprar se basar en las siguientes condiciones:

o o
La fecha de entrega externa es menor a la fecha final de desarrollo? El costo de compra externa es menor al costo de desarrollo interno? El costo soporte externo (mantenimiento) es menor al costo soporte interno?
En cualquiera de las tres alternativas, un factor importantsimo es la disponibilidad de recursos humanos, Tcnicos/hardware/ software.
2.2.2.4 Herramientas Automticas De Estimacin Implementan tcnicas de descomposicin y modelos empricos. 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.
73
Dependiendo
los
datos
el
modelo
implementado
por
la
herramienta
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. Qu datos necesitan:
o Datos cuantitativos sobre el tamao del proyecto (LDC, PF)

o o Caractersticas cualitativas del proyecto. Datos relacionados con el entorno y personal de desarrollo.
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 necesitar para su realizacin. La estimacin del proyecto de software nunca ser una ciencia precisa, pero la combinacin de buenos datos histricos y tcnicas puede mejorar la precisin de la estimacin. 2.2.3 Evaluacin del costo - beneficio El anlisis econmico incluye lo que se llama, el anlisis o evaluacin de costo beneficio, significa una valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o sistema. El anlisis econmico sirve para [6]:
o Valorar la necesidad de la realizacin de un proyecto. o Seleccionar la alternativa ms beneficiosa para la realizacin del
proyecto.
o Estimar adecuadamente los recursos econmicos necesarios en el plazo

de realizacin del proyecto. Muchas veces en el desarrollo de Sistemas, los beneficios son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la caractersticas del Sistema. El anlisis de costo beneficio es una fase muy importante de ella depende la posibilidad de desarrollar o no el proyecto.
74
Algunos costos y beneficios pueden cuantificarse fcilmente. Los beneficios que pueden cuantificarse con facilidad son de dos tipos generales: Ahorros en costos, tales como una disminucin en costos de operacin y aumentos en las utilidades directas. Otros ejemplos de beneficios tangibles son [7]: o o o Disminucin de errores Incremento de rentabilidad Reduccin de costos anteriores (fijos o variables)
Beneficios intangibles aquellos que en el momento del anlisis, no se pueden cuantificar y con frecuencia estn relacionados a la calidad de la informacin que proporciona el sistema, tales como los listados a continuacin:
o Satisfaccin en el servicio al cliente o En las actividades administrativas, mejora en la toma de decisiones

Segn la Sociedad Latinoamericana para la Calidad [8], el anlisis costo beneficio es el proceso de colocar cifras en dlares en los diferentes costos y beneficios de una actividad. Al utilizarlo, se puede estimar el impacto financiero acumulado de lo que se pretende lograr.
Cundo utilizarlo Al comparar costos y beneficios de las diferentes decisiones. Un anlisis de costo beneficio por si solo puede no ser una gua clara para tomar una buena decisin. Existen otros puntos que deben ser tomados en cuenta, por ejemplo la moral de los empleados, la seguridad, las obligaciones legales y la satisfaccin del cliente [6]. Cmo se utiliza Involucra los siguientes pasos:
75
1. Llevar a cabo una lluvia de ideas o reunir datos provenientes de factores importantes relacionados con cada una de sus decisiones. 2. Determinar los costos relacionados con cada factor. Algunos costos, como la mano de obra, sern exactos mientras que otros debern ser estimados. 3. Sumar los costos totales para cada decisin propuesta. 4. Determinar los beneficios en dlares para cada decisin.
5. Poner las cifras de los costos y beneficios totales en la forma de una

relacin donde los beneficios son el numerador y los costos son el denominador. BENEFICIOS / COSTOS
6. Comparar las relaciones Beneficios a Costos para las diferentes

decisiones propuestas. La mejor solucin, en trminos financieros es aquella con la relacin ms alta beneficios a costos. 2.2.3.1 Mtodos para el anlisis Costo / Beneficio Diferentes mtodos pueden ser utilizados para calcular la relacin costo beneficio. Los mtodos ms sofisticados consideran el tiempo valor del dinero como parte del anlisis costo beneficio. El tiempo valor del dinero, tambin conocido como el factor de descuento, es simplemente un mtodo utilizado para convertir el valor futuro del dinero en valor presente (dlares futuros a dlares presentes). Se basa sobre la premisa de que el dlar de hoy tiene ms valor que un dlar en unos aos en el futuro debido a los intereses o a la ganancia que se puede obtener. Incluir el tiempo valor del dinero puede ser crucial para la salud financiera de una organizacin ya que los esfuerzos por mejorar pueden requerir de compromisos de capital por un periodo de tiempo prolongado. Los mtodos comunes para el anlisis de costo beneficio incluyen:
76
o o o o
Punto de equilibrio Periodo de devolucin Valor presente neto Tasa interna de retorno
Punto de equilibrio (Breakeeven point (BP)) Observa el punto de equilibrio para realizar un esfuerzo por mejorar es una de las formas ms sencillas de hacer el anlisis de costo beneficio. El punto de equilibrio es el tiempo que tomara para que el total de los ingresos incrementados y/o la reduccin de gastos sea igual al costo total. Sin embargo, no toman en cuenta el valor del dinero en el tiempo. Frmula PE = (Costo / Total de ingresos incrementados y/o reduccin de gastos) x 12 (meses) Periodo de devolucin (payback period exercise) El periodo de Devolucin es el tiempo requerido para recuperar el monto inicial de una inversin de capital. Este mtodo calcula la cantidad de tiempo que se tomara para lograr un flujo de caja positivo igual a la inversin total. Toma en cuenta beneficios, tales como el valor asegurado. Este mtodo indica esencialmente la liquidez del esfuerzo por mejorar un proceso en vez de su rentabilidad. Al igual que el anlisis del punto de equilibrio, el anlisis del periodo de devolucin no tiene en cuenta el valor del dinero en el tiempo. Frmula PD = [(Costo Valor Asegurado) / Total de ingresos incrementados y/o reduccin de gastos] x 12 (meses) Valor presente neto (net present value (NPV))
77
El NVP representa el Valor Presente (PV) de los flujos salientes de caja menos la cantidad de la inversin inicial (I). Simplemente NPV = PV I El valor presente del flujo de caja futuro es calculado utilizando el costo del capital como un factor de descuento. El propsito del factor de descuento es contar el Valor Futuro del dinero en Valor Presente (dlares futuros a dlares presentes) y se expresa como 1 + la tasa de inters (i). Frmula PV = ((ingresos + Valor Asegurado) / Factor de descuento) NPV = PV inversin (I) Tasa interna de retorno (internal rate of return (IRR)) La tasa interna de retorno es la tasa de inters que hace la ecuacin de la inversin inicial (I) con el Valor presente (PV) de los futuros flujos de caja entrantes [6]. Esto es, a la Tasa Interna de Retorno, I = PV o NPV = 0. El resultado anlisis del punto de equilibrio, del periodo de devolucin y del clculo del valor presente neto indicara que este esfuerzo por mejorar es aceptable desde un punto de vista financiero. Cuando se calcula la IRR, el NPV se fija en cero y se resuelve para un inters (i). en este caso, el factor de descuento es (1 + i) ya que no conocemos el inters verdadero, solamente conocemos el inters deseado. Frmula PV = ((ingresos + Valor Asegurado) / Factor de descuento) NPV = PV inversin (I)
2.3
Estudio de viabilidad
78
El proceso de ingeniera de requerimientos comienza con un estudio de viabilidad. Este es un estudio corto que ayuda a resolver si un nuevo sistema de software es o no candidato para desarrollarse de acuerdo a los recursos y restricciones impuestas por al organizacin. Dentro del PU, durante la fase de inicio uno de sus objetivos es la decisin de proceder o no con el proyecto, es decir, se establece el anlisis de negocio, o dicho en otras palabras establecer la viabilidad del proyecto [JBR00]. De acuerdo con Sommerville [SOM00], el estudio de viabilidad est orientado a resolver las siguientes preguntas: o o o El sistema contribuye a los objetivos generales de la organizacin? El sistema puede implementarse utilizando la tecnologa actual y con El sistema puede integrarse a otros que existen en la organizacin?
las restricciones establecidas?
Llevar a cabo un estudio de factibilidad comprende la evaluacin y recoleccin de informacin y la redaccin de informes. A continuacin se describen brevemente los tipos de viabilidad desde el punto de vista, econmico, tcnico y operativo. 2.3.1 Viabilidad econmica Es una evaluacin de costo beneficio del sistema que se quiere desarrollar, para saber que tan efectivo resultar su desarrollo, si contribuye o no a los objetivos del negocio, lo que determinar si vale la pena o no la inversin econmica. 2.3.2 Viabilidad Tcnica Es un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. Las restricciones adems de presupuesto
79
tiempo incluyen los recursos
humanos, hardware y software. Con este
estudio se determina si con la tecnologa existente se puede implementar el nuevo sistema, o si hay que adquirir nueva tecnologa.
2.3.3 Viabilidad operativa Se trata de averiguar si el nuevo sistema es el adecuado para la organizacin. Se necesita saber si el nuevo sistema es flexible y puede integrarse a otros ya existentes en la organizacin. Dentro del PU el objetivo principal de la fase de inicio es establecer la viabilidad del proyecto, dicho en otras palabras establecer el anlisis del negocio. Esto con el objetivo de decidir si se sigue o no adelante con el proyecto. Se debe sealar que este anlisis se sigue desarrollando en la fase de elaboracin conforme se va recopilando ms informacin [JBR00].
2.4
Planificacin de la documentacin
Para mantener informado al cliente acerca de los riesgos, de la planificacin de tiempo y de la organizacin usualmente se hace por medio de un documento llamado plan de proyecto. El plan del proyecto de software se produce como culminacin de la etapa de planificacin. El plan del proyecto de software es un documento breve, esta dirigido a una diversa audiencia y debe :
1.
Comunicar el alcance y recursos a los gestores del Software, personal tcnico y clientes.
2. Definir los riesgos y sugerir planes de contingencia 3. Definir el costo y el plan temporal para la revisin de la gestin. 4.
Proporcionar una aproximacin global del desarrollo del software para toda la gente involucrada en el proyecto.
5. Describir cmo se garantizar la calidad y la gestin de cambios.

80
De acuerdo a Pfleeger [PFL02], un buen plan de proyecto incluye lo siguiente:

1. alcance del proyecto (lo que si y no incluir, como objetivos, funciones,
etc. )
2. planificacin temporal (se puede utilizar un diagrama de Gantt)
3. organizacin del equipo del proyecto 4. descripcin tcnica del sistema propuesto 5. estndares, procedimientos, tcnicas y herramientas propuestas 6. plan de calidad 7. plan de gestin de configuracin de software 8. plan de documentacin
9. plan de gestin de datos (recursos humanos, de hardware y software)
10.plan de gestin de recursos 11.plan de prueba 12.plan de entrenamiento 13.plan de seguridad 14.plan de gestin de riesgo 15.plan de mantenimiento
2.5 Gestin de la configuracin del software (GCS) Los cambios durante el proceso de construccin de un software: o o o Son inevitables Provocan confusin e incertidumbre Pueden ocurrir en cualquier momento
Estos cambios aumentan conforme avanza el tiempo. La primera ley de ingeniera de sistemas [BER80] dice: sin importar en qu momento del ciclo de vida del sistema nos encontremos, el cambio se producir, y el deseo de cambiarlo persistir a lo largo de todo el ciclo de vida del sistema. De ah surge la necesidad de la gestin de configuracin del software.
81
El arte de coordinar el desarrollo de software para minimizarla confusin, se denomina gestin de la configuracin. La gestin es el arte de identificar, organizar y controlar las modificaciones que sufre el softwarela meta es maximizar la productividad minimizando errores. Babich [BAB86]. De acuerdo con Pressman [PRE02], las actividades de GCS sirven para: o o o o Identificar el cambio de nuestro software. Controlar ese cambio. Garantizar que el cambio quede bien implantado. Informar el cambio.
La GCS no es un mantenimiento del software, el mantenimiento es la etapa final de la ingeniera hasta que se retire el producto del equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina slo una vez que el software queda fuera de circulacin. Por qu cambiar el sistema? Que produce los cambios en el sistema? La respuesta a estas interrogantes se puede encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del desarrollo del software: o o o Nuevos requisitos del negocio o condiciones que dictan los cambios en las condiciones del producto o en las normas comerciales. Nuevas necesidades del los clientes que demandan la modificacin de los datos producidos por un sistema basado en computadora. Reorganizacin y/o reduccin del volumen comercial que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniera del software. o Restricciones presupuestarias o de planificaciones que provocan una redefinicin del sistema o del producto.
82
La GCS realiza un conjunto de actividades desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del software [PRE02]. De acuerdo con Sommerville [SOM00], la GCS Implica el desarrollo y uso de procedimientos y estndares evolutivo. Lnea base Una lnea base es un concepto de gestin de configuracin del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define una lnea base como: Una especificacin o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, es decir que se ha sido aprobad, y que de ah en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a travs de procedimientos formales de control de cambios. Una forma de describir la lnea base es mediante una analoga. Considere las puertas de la cocina de un gran restaurante. Para evitar colisiones una puerta esta marcada como SALIDA y la otra como ENTRADA las puertas tienen topes que hacen que solo se puedan abrir en la direccin apropiada. Si un camarero recoge un pedido en la cocina lo coloca en una bandeja y luego se da cuenta de que ha cogido un plato equivocado, puede cambiar el plato correcto rpidamente informalmente antes de salir de la cocina. Sin embargo, si abandona la cocina le da el plato al cliente y luego se le informa de su error, debe seguir el siguiente proceso: 1) Mirar en la orden de pedido si ha cometido algn error. 2) Disculparse insistentemente. 3) Volver a la cocina por la puerta de entrada. 4) Explicar el problema etc. Una lnea base es anloga a un plato mientras pasa por las puertas de la cocina de un restaurante antes de que un elemento de configuracin del software se convierta en lnea base, el cambio se puede llevar a cabo rpida e
para administrar un producto de software
83
informalmente. Sin embargo, una vez que se establece una lnea base, pasamos, de forma figurada, por una puerta de un solo sentido. S pueden llevar a cabo los cambios, pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio. En el contexto de la ingeniera del software se define una lnea base como un punto de referencia en el desarrollo del software y que queda marcado por el envo de uno o ms elementos de configuracin del software (ECS) y la aprobacin de ECS obtenido mediante una revisin tcnica formal. Por ejemplo, los elementos de una especificacin de diseo se documentan y se revisan. Se encuentran errores y se corrigen. Cuando todas las partes de las especificaciones se han revisado corregido y aprobado, la especificacin de diseo se convierte en lnea base. Solo se pueden realizar cambios futuros en la arquitectura del software (contenidos en la especificacin del diseo) tras haber sido evaluados y aprobados. Aunque se puedan definir las lneas base con cualquier nivel de detalle las lneas base ms comunes son las que se muestran en figura 2.5.1
Fig. 2.5.1 Lnea Base
Elemento de configuracin de software Los elementos de configuracin del software ECS son cualquier documento, especificacin, conjunto completo de casos de prueba etc. que se crea durante
84
el desarrollo del software. Un elemento de configuracin del software seguir el ciclo mostrado en la figura 2.5.1. Es importante considerar poner las herramientas de desarrollo de software bajo control de configuracin. Es decir congelar la versiones de editores, compiladores y otras herramientas CASE utilizadas durantes el desarrollo, un cambio en las versiones utilizadas puede que produzca resultados diferentes que la versin original. Los ECS se organizan como objetos de configuracin que deben ser catalogados por la base de datos del proyecto con un nombre nico. Un ECS tiene un nombre y atributos, y est conectado a otros objetos mediante relaciones. La figura 2.5.2 muestra el modelo de datos de los elementos de la configuracin, cada objeto esta relacionado con otro, si se lleva a cabo un cambio sobre un objeto la interrelaciones sealan a que otros objetos afectar.
Fig. 2.5.2 modelo de datos de la GCS
2.5.1 Planificacin de la GCS
85
De acuerdo con Sommerville [SOM00], la planificacin de la GCS empieza durante las primeras fases del proyecto y debe definir el o los documentos que se controlarn. Aquellos documentos documentos de control. El plan de la GCS incluye: que puedan requerirse para el futuro mantenimiento del software, debern ser identificados y especificados como
1. La identificacin de los ECS, donde se controlan los cambios y se decide

qu documentos (o tipo de documentos) se van a controlar, tales como: o o o o o planes del proyecto especificaciones diseos programas resultados de las pruebas, etc.
Por lo general no se controlarn documentos de trabajo, informes internos, propuestas, etc.
2. La asignacin de responsabilidades. Despus de identificar los ECS se

decide quin se encarga de los procedimientos de la GCS y quin se encarga de la creacin de las lneas base.
3. Las polticas de la GCS dadas dentro de una organizacin son para

controlar los cambios y versiones apoyando por herramientas CASE. 4. La definicin de archivos de la GCS que deben ser controladas.
5. La definicin de la base de datos, que registra toda la informacin

relevante relacionada con las configuraciones, ayuda a la evaluacin del impacto de los cambios en el sistema y proveer informacin sobre el
86
proceso de la GCS. Esta informacin debe permitir hacer las siguientes consultas:
o Los clientes a los que se ha entregado una versin en particular o Las configuraciones de hardware y sistema operativo necesarias para
cada versin
o El nmero de versiones se han creado y fechas de creacin o El nmero de peticiones de cambio pendientes de una versin concreta o El nmero de fallos reportados existentes para una versin en particular,
etc.
6. Puede incluir informacin de software externo, proceso de auditora, etc.

2.5.2 El proceso de gestin de la configuracin del software De acuerdo con Pressman [PRE02], la GCS es un elemento importante de garanta de calidad es responsable de controlar los cambios. Sin embargo tambin se debe identificar los ECS individuales. El proceso se puede definir en cinco tareas de GCS: 1. Identificacin 2. Control de versiones 3. Control de cambios 4. Auditorias de configuracin 5. Generacin de informes 2.5.3.1 Identificacin de objetos en la GCS Se pueden identificar dos tipos de objetos los objetos bsicos y los objetos compuestos. Un objeto bsico es una unidad de texto creada durante el anlisis, diseo, codificacin o prueba. Un objeto compuesto es una coleccin de objetos bsicos u objetos compuestos. Cada objeto tiene un conjunto de caractersticas que los identifican como nicos:
87
o o
El nombre del objeto es una cadena de caracteres que identifica al objeto sin ambigedad. La descripcin del objeto es una lista de elementos de datos que identifica el tipo de ECS (documento, programa, datos) que est representado por el objeto.
o o
Un identificador del proyecto La informacin de la versin y/o el cambio.
El esquema de identificacin de los objetos de software debe tener en cuenta que los objetos evolucionan a lo largo del proceso de ingeniera, por lo que se puede crear un grafo de evolucin ejemplificado en la figura 2.5.3.1.
Fig. 2.5.3.1 grafo de evolucin
En el grafo de evolucin se describe la historia del objeto y sus cambios, las grandes modificaciones hacen que un objeto cambie, por lo que cambia el nmero de versin principal.
88
2.5.3.2 Control de versiones El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuracin creadas durante el proceso de ingeniera del software. Clemm describe el control de versiones en el contexto de la GCS. "La gestin de configuracin permite a un usuario especificar configuraciones alternativas del sistema de software mediante la seleccin de las versiones adecuadas. Esto se puede gestionar asociando atributos a cada versin del software y permitiendo luego especificar y construir una configuracin describiendo el conjunto de atributos deseado." Los atributos pueden ser tan sencillos como un nmero especfico de versin asociado a cada objeto o tan complejos como una cadena de variables lgicas que especifiquen tipos de cambios funcionales aplicados al sistema. Ejemplo: En la figura 2.5.4.2 ilustra una versin de un sencillo programa que est formada por los componentes 1, 2, 3, 4 y 5. El componente 4 slo se usa cuando el software se implementa para monitores de color, y el 5 cuando se dispone de un monitor monocromtico, por lo tanto se pueden definir dos variantes de la versin:
o Componentes 1, 2, 3 y 4
o componentes 1, 2, 3 y 5
89
Fig. 2.5.4 .2 grafo de versiones y variantes
Para construir la variante adecuada de una determinada versin de un programa, a cada componente se le asigna una tupla de atributos (lista de caractersticas que definen si se utilizar un componente, par determinada versin del software). A cada variante se le asigna uno o ms atributos. Otra forma de establecer los conceptos de la relacin entre componentes, variantes y versiones es representarlas como un fondo de objetos Otra forma de establecer los conceptos de relacin entre componentes
variantes y versiones es como un fondo de objetos [REI89]. La figura 2.5.4.3 representa de los objetos, sus componentes, variantes y versiones. La principal diferencia entre los distintos enfoques est en la sofisticacin de los atributos que se usan para construir versiones y variantes especficas de un sistema y en la mecnica del proceso de construccin.
90
Fig. 2.5.4.3 representacin en fondo de objetos componentes, versiones y variantes
2.5.3.3 Control de cambios En un gran proyecto de desarrollo de software, el cambio incontrolado lleva rpidamente al caos. El control de cambios combina los procedimientos humanos y las herramientas automticas para proporcionar un mecanismo para el control de cambio mostrado en la figura 2.5.5.1.
91
Fig. 2.5.5.1 Proceso de control de cambios
Los resultados de la evaluacin se presentan como un informe de cambios a la autoridad de control de cambios (ACC). Para cada cambio aprobado se genera una orden de cambio de ingeniera (OCI) La OCI describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisin y de auditoria. El objeto a cambiar es "dado de baja" de la base de datos del proyecto; se realiza el cambio y se aplican las adecuadas actividades de SQA.
92
Luego, el objeto es "dado de alta" en la base de datos y se usan los mecanismos de de control de versiones apropiadas para crear la siguiente versin del software.
Los procedimientos de "alta" y "baja" implementan dos elementos importantes del control de cambios: control de acceso y control de sincronizacin. o El control de acceso gobierna los derechos de los ingenieros de software concretos. a acceder y modificar objetos de configuracin
o El control de sincronizacin asegura que los cambios en paralelo,

realizados por personas diferentes, no se sobrescriben mutuamente [HAR89].
Fig. 2.5.5.2 controles de acceso y de sincronizacin
Antes de que un ECS se convierta en una lnea base, slo es necesario aplicar un control de cambios informal. El que haya desarrollado el ECS en cuestin podr hacer cualquier cambio justificado por el proyecto y por los requisitos
93
tcnicos. Una vez que el objeto ha pasado la revisin tcnica formal y ha sido aprobada, se crea la lnea base. Una vez que el ECS se convierte en una lnea base, aparece el control de cambios a nivel de proyecto. Para hacer un cambio, el encargado del desarrollo debe recibir la aprobacin del gestor del proyecto (si el cambio es local), o de la ACC si el cambio impacta en otros ECS. En algunos casos, se dispensa de generar formalmente las peticiones de cambio, los informes de cambio y las OCI. Sin embargo, hay que hacer una evaluacin de cada cambio as como un seguimiento y revisin de los mismos. Cuando se distribuye el producto de software a los clientes, se instituye el control de cambios formal. La autoridad de control de cambios (ACC) desempea un papel activo en el segundo y tercer nivel de control. El papel de la ACC es el de tener una visin general, o sea, evaluar el impacto del cambio fuera del ECS en cuestin y de plantear las siguientes cuestiones y muchas otras ms: o Cmo impactar el cambio en el hardware?
o Cmo impactar en el desempeo?

o Cmo alterar el cambio la percepcin del cliente sobre el producto?
2.5.3.4 Auditoria de la configuracin Cmo podemos asegurar que el cambio se ha implementado correctamente? La respuesta es doble: 1) revisiones tcnicas formales y 2) auditorias de configuracin del software. Las revisiones tcnicas formales se centran en la correccin tcnica del elemento de configuracin que ha sido modificado. Los revisores evalan el ECS para determinar la consistencia con otros ECS, las omisiones o los posibles efectos secundarios.
94
Una auditoria de configuracin del software complementa la revisin tcnica formal al comprobar caractersticas que generalmente no tiene en cuenta la revisin. La auditoria se plantea y responde con las siguientes preguntas: 1. Se ha hecho el cambio especificado en la OCI? Se han incorporado modificaciones adicionales? 2. Se ha llevado a cabo una revisin tcnica formal para evaluar la correccin tcnica? 3. Se han seguido adecuadamente los estndares de ingeniera de software? 4. Se han "recalcado" los cambios en el ECS?Se han especificado la fecha del cambio y el autor?Reflejan los cambios los atributos del objeto de configuracin? 5. Se han seguido procedimientos del GCS para sealar el cambio, registrarlo y divulgarlo? 6. Se han actualizado adecuadamente todos los ECS relacionados? En algunos casos las preguntas anteriores se incluyen en la revisin tcnica formal, pero cuando la GCS es formal la auditora se lleva a cabo de manera independiente por el grupo encargado de garantizar la calidad. 2.5.3.5 Informes de estado La generacin de informes de estado de la configuracin es una tarea de GCS que responde a las siguientes preguntas: 1) Qu pas? 2) Quin lo hizo? 3) Cundo pas? 4) Que ms se vio afectado? La generacin de informes de estado de la configuracin desempea un papel vital en el xito del proyecto de desarrollo de software. Cuando aparece involucrada mucha gente es muy fcil que no exista una buena comunicacin.
95
Pueden darse errores entre las personas desarrolladoras del software. El IEC ayuda a eliminar esos problemas, mejorando la comunicacin entre todas las personas involucradas [PRE02].
Para trabajo de la Unidad II, debern entregar el plan de su proyecto, el cual incluye lo siguiente:
16.alcance del proyecto (lo que si y no incluir, como objetivos, funciones, etc. ) 17.planificacin temporal (se puede utilizar un diagrama de Gantt) 18.organizacin del equipo del proyecto 19.descripcin tcnica del sistema propuesto 20.estndares, procedimientos, tcnicas y herramientas propuestas 21.plan de calidad 22.plan de gestin de configuracin de software 23.plan de documentacin 24.plan de gestin de datos (recursos humanos, de hardware y software) 25.plan de gestin de recursos 26.plan de prueba 27.plan de entrenamiento 28.plan de seguridad 29.plan de gestin de riesgo 30.plan de mantenimiento
96

Unidad II Planif y Modelado

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad II Planif y Modelado

Cargado por

Copyright:

Formatos disponibles

Planificacin y Modelado Planificacin del Sistema

Planificacin del Sistema

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

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Redaccin y presentacin de informes.

o Asignar tareas que desempearn o Designar a los jefes de equipo.

La estructura organizacional de los diferentes equipos.

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Lneas de comunicacin 1 3 6 10 n (n-1 ) /2

Tabla 2.1 Caminos de comunicacin en un proyecto

Planificacin y Modelado Planificacin del Sistema

Fig. 2.2 Estilos de trabajo

Planificacin y Modelado Planificacin del Sistema

o Disea todos los programas o Asigna el desarrollo de codificacin a otros miembros

o Compilar y hacer enlace (link edition ) de cdigo

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Fig. 2.3 organizacin del jefe de programadores.

o Un gran nmero de personal involucrado

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Estabilidad Uniformidad repeticin

o Un pequeo nmero de personal involucrado

o Realizan pruebas con tcnicas o tecnologa nuevas

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

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema o

Gestionar riesgos Controlar la calidad y los cambios Gestin de configuracin de software

Fig. 2.4 actividades de la gestin y planificacin

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

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

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

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

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

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

avanzando de acuerdo al presupuesto y calendarizacin. cumpliendo con los criterios de calidad.

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

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

o Es un evento que indican el alcance de

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

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Ejemplos de hitos son los siguientes:

Fig. 2.1.1 Actividades y hitos en el desarrollo de software

Planificacin y Modelado Planificacin del Sistema

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

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Tambin existen varias representaciones grficas como los son:

redes de actividades Grficos de barras

Ingeniera en Sistemas Computacionales

Planificacin y Modelado Planificacin del Sistema

Tabla 2.1.2 duracin y dependencias de las actividades

Ingeniera en Sistemas Computacionales