Post on 24-Jun-2015
Planificación y Modelado Planificación del Sistema
UNIDAD 2
Planificación del Sistema
De acuerdo con Sommerville [SOM00], la gestión de proyectos de software se
hace necesaria ya que todo proyecto esta sujeto a restricciones de
presupuesto y tiempos. La gestión permite asegurar que el software se lleve a
cabo a tiempo y de acuerdo con los requerimientos especificados.
La gestión del software es particularmente difícil, algunas de las razones son:
o El producto de software es intangible. Esto obliga a los gestores del
proyecto a confiar en los otros miembros del personal para la toma de
decisiones.
o No hay un proceso estándar. Y por lo tanto tampoco se tiene la certeza
de cuando un proceso en particular empieza a tener problemas.
o A menudo los proyectos de software grandes son únicos. Esto se refiere
a que los proyectos se diferencian unos de otros, por lo que hasta los
gestores más experimentados no siempre podrán anticipar los
problemas.
Las de las actividades comunes de la gestión de proyectos software son:
o Redacción de la propuesta.
o Planificación del proyecto
o estimaciones de costo, tiempo y esfuerzo.
o Supervisión y revisión del proyecto.
o Selección y evaluación del personal.
Ingeniería en Sistemas Computacionales 17
Planificación y Modelado Planificación del Sistema
o Redacción y presentación de informes.
Las actividades listadas anteriormente son responsabilidad del gestor de
proyectos. A continuación se considera importante discutir el tema referente a
la selección del personal, ya que éste representa una pieza clave para una
buena gestión de proyecto. La cantidad de personas requeridas para el
desarrollo de un proyecto de software solo puede determinarse después de
hacer una estimación de esfuerzo de desarrollo, por ejemplo, personas mes o
personas años. Aún 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.
Selección del personal
Todo proyecto requiere personal que interactúe con los clientes par determinar
los requerimientos, otro grupo de personas diferentes para diseñar 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 mínimo 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 desempeñarán
o Designar a los jefes de equipo.
o La estructura organizacional de los diferentes equipos.
La asignación de tareas al personal depende de la dimensión del proyecto, de
la destreza y experiencia de éstos. Una vez que se decide el rol de los
miembros de cada grupo que conformarán 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
Ingeniería en Sistemas Computacionales 18
Planificación y Modelado Planificación del Sistema
analista, dos diseñadores y cinco programadores, por poner un ejemplo. De
acuerdo con Sommerville [SOM00], la selección del personal se realiza de
acuerdo a los siguientes factores:
o Experiencia en el dominio de la aplicación.
o Experiencia en la plataforma.
o Experiencia en el lenguaje de programación.
o Capacidad de aprender.
o Habilidades de comunicación.
o Adaptabilidad.
o Actitud.
o Personalidad.
Cada una de estas características, puede afectar la capacidad del individuo
para desempeñarse en forma productiva. La forma en que se desempeña 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 pequeña parte de éste.
Ambos tipos de personas podrían sentirse incomodas realizando trabajos
opuestos. Por lo anterior se deduce que un trabajador se desempeñará mejor si
está cómodo con el trabajo que realiza, y es más productivo cuando tiene
confianza en su capacidad para desempeñarse. El estimular al personal para
que desempeñe bien su trabajo es también tarea del gestor. El estimulo puede
ser invitándolo a crear algo diferente a lo que siempre hace, o a mejorarlo; con
esto mantendrá el interés 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
más de una persona que trabajen en un mismo equipo. Entonces entre el
personal también 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.
Ingeniería en Sistemas Computacionales 19
Planificación y Modelado Planificación del Sistema
La interacción personal también está relacionada con la comodidad y confianza
entre los miembros del equipo, algunas personas son buenas dirigiendo el
trabajo de otras, a las cuales sería 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 comunicación verbal y escrita tanto de ideas como resultados es crucial, ya
que ayuda al avance del proyecto, como la comunicación con el cliente, cuando
se está investigando sobre los requisitos básicos 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 número de personas que
necesitan comunicarse entre sí y la buena o mala comunicación, pueden
afectar la calidad del producto final. La tabla 2.1 muestra como se incrementan
las líneas de comunicación. En general si un proyecto tiene n trabajadores, hay
“n ( n-1 ) /2” pares de personas que probablemente necesitarán comunicarse
y 2n – 1 grupos posibles que pueden crearse para trabajar en secciones más
pequeñas del proyecto.
Número de
personas
Líneas de comunicación
1
3 3
4 6
5 10
N n (n-1 ) /2
Tabla 2.1 Caminos de comunicación en un proyecto
La comunicación puede ser uni/ bidireccional, según el nivel asignado a cada
persona.
Ingeniería en Sistemas Computacionales 20
Planificación y Modelado Planificación del Sistema
Otro factor importante en la selección del personal es el estilo de trabajo. La
compresión de estos estilos fomenta la flexibilidad que se hace necesaria para
un buen trabajo en equipo, así como permite tener una mejor decisión de
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 análisis detallado de toda la información antes de tomar
una decisión, contrariamente habrá personas que solo necesiten confiar en su
intuición para tomar alguna decisión importante.
Los estilos de trabajo afectan las interacciones de un proyecto entre clientes,
desarrolladores y usuarios. A continuación se muestran en la figura 2.2 una
variedad de éstos, la comunicación la constituye el eje horizontal y los estilos
de decisión el vertical. Se debe señalar que no todas las personas encajan en
estos cuatro estilos. Por ejemplo la siguiente lista de características
corresponde al estilo de trabajo de los extrovertidos intuitivos:
o rara vez piden opiniones,
o prefieren comunicar sus propias ideas y
o basan la mayoría de sus decisiones en intuiciones.
Fig. 2.2 Estilos de trabajo
La organización de un proyecto.(aquí me Qede)
Ingeniería en Sistemas Computacionales 21
Planificación y Modelado Planificación del Sistema
El conjunto de personas que conforman el gran equipo de un proyecto deben
trabajar de manera conjunta y coordinada, lo que asegura la obtención de
productos de calidad. La elección de una estructura apropiada depende del
número de personas en el equipo, de las características de personal y los
estilos de trabajo, entre otras cosas. Existen muchas formas de para la
organización de proyectos, a continuación se describirán dos tipos de
organización, los cuales son los extremos.
Una muy popular es “el equipo de jefe de programadores” (chief programmer
team). En este tipo de organización, una persona (el jefe de programadores) es
responsable por el diseño 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 rápidamente)
o Diseña todos los programas
o Asigna el desarrollo de codificación a otros miembros
o Supervisa al resto del equipo
Este tipo de organización cuenta con un bibliotecario asiste al equipo y es
responsable de:
o Darle mantenimiento a la documentación
o Compilar y hacer enlace (link edition ) de código
o Ejecutar pruebas preeliminares
La responsabilidad recae sobre una sola persona, lo que hace que la estructura
minimice la comunicación 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
Ingeniería en Sistemas Computacionales 22
Planificación y Modelado Planificación del Sistema
programadores más el jefe, el equipo solamente puede establecer n-1 caminos
de comunicación más allá de un potencial de n (n-1) / 2 caminos.
Aunque esta estructura sea jerárquica, se pueden formar grupos de trabajotes
para llevar a cabo una tarea especializada que requiera más de una persona
para su elaboración.
Fig. 2.3 organización del jefe de programadores.
El otro extremo se basa en la idea de una programación “sin egoísmo” 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 egoísmo se diferencia de jefe de
programadores, en lo siguiente:
Es una estructura democrática
Todos los miembros del equipo participan en la toma de decisiones
mediante votos.
¿Cuál de las estructuras anteriores es preferible utilizar? Si el proyecto que se
pretende llevar a cabo cuenta con las siguientes características entonces
necesitará de una estructura formal jerárquica y también de una organización
bien definida. Este tipo de proyectos tiene:
o Un gran número de personal involucrado
Ingeniería en Sistemas Computacionales 23
Planificación y Modelado Planificación del Sistema
o Un alto grado de certeza
o Estabilidad
o Uniformidad
o repetición
Este tipo de proyectos requieren menos comunicación entre los miembros del
equipo, una comunicación vertical, y se adaptan mejor a este tipo de
estructura organizacional ya que imponen reglas, especialización, formalidad y
una clara definición de la jerarquía organizacional.
Por otro lado, un proyecto necesitará una estructura aproximada a la
democrática si tiene las siguientes características:
o Un pequeño número de personal involucrado
o Existe cierto nivel de incertidumbre
o Realizan pruebas con técnicas o tecnología nuevas
Comúnmente en este tipo de proyectos los requerimientos probablemente
cambien durante su desarrollo, por esto necesitan una estructura más flexible
con
amplia comunicación abierta y por lo tanto la participación de todos los
miembros del equipo.
Teniendo el conocimiento de cómo seleccionar al personal para el equipo del
proyecto y la manera de organizarlo para su óptimo desempeño, se puede
profundizar en el tema de la planificación del proyecto que abarca el resto de
la unidad. A continuación se da una breve introducción de éste antes de
describirlo de manera más detallada.
De acuerdo con George Steiner [STE89], “planear” significa diseñar un futuro
deseado e identificar las formas para lograrlo.
Qué es la planificación:
Ingeniería en Sistemas Computacionales 24
Planificación y Modelado Planificación del Sistema
o Es una guía de desarrollo para cumplir las metas del proyecto.
o Es un proceso iterativo el cual termina hasta que el proyecto mismo
haya terminado. Esto quiere decir que su revisión 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
planificación, ya que con ayuda de ésta se pueden evitar problemas a los que
un proyecto está sujeto, tales como:
o Retraso de tiempo de entrega
o Sobrepasar el presupuesto
o Baja calidad del producto
o Alto costo de mantenimiento, etc.
El gestor de proyecto es responsable de planear y supervisar el proyecto para
que este se lleve a cabo:
o dentro de los tiempos establecidos
o conforme a los estándares requeridos
o acorde al presupuesto
Durante la planificación, 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 desarrollándose el proyecto se obtiene
mayor y mejor información, esto modificará el plan inicial, lo que conduce a
replanear el calendario de actividades necesarias para desarrollar el proyecto.
Los pasos de la planificación de un proyecto comprende las siguientes
ilustradas en la figura 2.4:
o Delimitar el ámbito del software
o Realizar estimaciones de tiempo, costo y esfuerzo
Ingeniería en Sistemas Computacionales 25
Planificación y Modelado Planificación del Sistema
o Calendarizar el trabajo
o Gestionar riesgos
o Controlar la calidad y los cambios
o Gestión de configuración de software
Fig. 2.4 actividades de la gestión y planificación
La planificación inicia con la valoración de las restricciones impuestas por el
cliente. Es importante que antes de realizar la estimación, se delimite el ámbito
del software. En esta etapa se evalúan las funciones, y desempeño del
software. Se describen los datos que se procesarán, funciones, desempeño,
restricciones, interfaces y viabilidad [PRE02]. Las actividades de planificación
del tiempo, estimación 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 planificación del proyecto es
similar a la planificación estándar para cualquier proyecto de software. La
planificación del sistema se ve presente en cada una de las fases del proceso
unificado.
En cada una de estas y en cada iteración se realiza lo siguiente:
o se toman las decisiones de continuar o no con el proyecto
o se determina
o el calendario
Ingeniería en Sistemas Computacionales 26
Planificación y Modelado Planificación del Sistema
o el presupuesto
o se gestionan los
o requerimientos
o y riesgos
Los cinco flujos de trabajo fundamentales (requerimiento, análisis, diseño,
implementación y prueba), mas la planificación y evaluación de la iteración,
constituyen lo que se llama “la iteración genérica”. El número de iteraciones
dependerá básicamente de la complejidad del sistema propuesto. A mayor
complejidad mayor número de iteraciones en cada fase. La planeación de la
iteración 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 cuánto tiempo puede tomar cada iteración y así asignarle
una fecha de terminación. Esta calendarización se refina en cada fase, a
principio grosso modo y posteriormente con mayor precisión.
3. Conociendo el tiempo aproximado para cada iteración, enseguida se
realiza una estimación de costos en esfuerzo y dinero de cada fase.
4. Luego se planea detalladamente las actividades de cada iteración.
Cada iteración debe ser evaluada para entre otras cosas, conocer los
beneficios y la parte del trabajo que se ha completado por ésta. También
ayuda en lo siguiente:
o Reconsiderar el plan de la siguiente iteración para realizar los cambios
necesarios a éste.
o Modificar el proceso, adaptar las herramientas, prolongar la preparación
y realizar otras acciones sugeridas por la iteración evaluada.
Por medio de la evaluación el gestor de proyecto se da cuenta si el proyecto va
progresando, en otras palabras necesita saber si el proyecto está:
Ingeniería en Sistemas Computacionales 27
Planificación y Modelado Planificación del Sistema
o avanzando de acuerdo al presupuesto y calendarización.
o cumpliendo con los criterios de calidad.
Si no se cumplen con lo criterios de evaluación entonces se tendrá que
prolongar el trabajo en la siguiente iteración.
Una vez evaluada la iteración, el gestor del proyecto realiza lo siguiente:
1. Determina que el trabajo esté listo para la siguiente iteración.
2. Asigna el trabajo incompleto a las siguientes iteraciones.
3. Planea en detalle la siguiente iteración.
4. Actualizar la lista de riesgos y el plan del proyecto.
5. Compara el costo y la planificación de la iteración con los planeados.
2.1 Planificación 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 planificación 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 realización.
Durante la recolección 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 documentación, que describirá el estado del software en desarrollo.
o Demostraciones de funciones, precisión, confiabilidad, seguridad, y
desempeño.
Ingeniería en Sistemas Computacionales 28
Planificación y Modelado Planificación del Sistema
A continuación 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 parámetros:
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 Duración: tiempo necesario para completar una actividad.
o Fecha de entrega: la fecha para cual la actividad debe ser completada.
o Punto final: entendiendo que una actividad ha terminado es un hito o un
componente para entregar.
Un hito:
o Es un evento que indican el alcance de un nivel mensurable en el
proyecto.
o Es la completitud y final de una actividad y sucede en un determinado
momento.
o Debe representar el fin de una etapa lógica 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.
Ingeniería en Sistemas Computacionales 29
Planificación y Modelado Planificación del Sistema
Ejemplos de hitos son los siguientes:
o la especificación de requerimientos.
o la terminación de un manual de usuario
o realización de un conjunto de cálculos
o demostración de la capacidad de comunicación en el sistema.
Si el cliente quiere que el sistema se entregue acompañado de un tutorial
asistido por un operador en línea, el desarrollo de dicho tutorial y sus
programas asociados son ejemplo de una actividad, que culmina en la
demostración 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 básicas 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 descomposición 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 más pequeñas y
compresibles, equivale a dividirlo en fases y cada una de éstas en iteraciones.
Ingeniería en Sistemas Computacionales 30
Planificación y Modelado Planificación del Sistema
Dentro de cada iteración se debería trabajar en las cosas apropiadas,
permitiendo alcanzar un equilibrio entre las secuencias de actividades
ejecutadas en la misma iteración. 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 división del trabajo. En cada fase las primeras
iteraciones se centran en los flujos de requerimientos, análisis y diseño, como
sería el trabajar con riesgos, casos de uso fundamentales, cuestiones
arquitectónicas, etc. Y en las últimas iteraciones se trabaja con actividades
orientadas al desarrollo, como la implementación y prueba, evaluación de
desempeño [JBR00].
Durante la fase de elaboración el objetivo principal es crear una línea base
para la arquitectura y la estimación de costos con gran precisión, así como la
planificación de la fase de construcción, siendo ésta muy precisa, que
abarcaría la planificación de tiempo y costos que se verá en la sección 2.2
(análisis 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 gráficos de barras y grafos o redes de actividades que
muestran las actividades, los responsables, la dependencia entere actividades
y la asignación de recursos, entre otras cosas.
El gestor debe coordinar las tareas del trabajo, asignarles a éstas el personal y
otros recursos de tal manera que se aprovechen de manera óptima. Las
actividades por lo general duran al menos una semana, la cantidad de tiempo
máxima sugerida es de 8 a 10 semanas.
Ingeniería en Sistemas Computacionales 31
Planificación y Modelado Planificación del Sistema
El calendario debe actualizarse continuamente a medida de que progrese el
proyecto y se obtenga mejor información. También 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 estén disponibles a tiempo.
Proyectos con métodos de diseños y lenguajes diferentes.
Proyectos nuevos que utilizan técnicas complejas.
Una regla práctica, es hacer la estimación como si nada fuera a salir mal, e
incrementar la estimación entre un 20% y 30% para cubrir los imprevistos.
2.1.1 Métodos de Planificación temporal
Existen varios métodos para la planificación aquí se describirán:
La técnica de revisión y evaluación del programa(PERT)
y CPM la ruta crítica
También existen varias representaciones gráficas como los son:
redes de actividades
Gráficos 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 podrán 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].
Ingeniería en Sistemas Computacionales 32
Planificación y Modelado Planificación del Sistema
Ejemplo: Supongamos las actividades mostradas en la tabla 2.1.2, se muestra
su duración e interdependencia. La ”M” representa un hito.
Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
Duración
(días)
8 15 15 10 10 5 20 25 15 15 7 10
Dependencias
T1
(M1
)
T2,T
4
(M2
)
T1,T
2
(M3
)
T1
(M1
)
T4
(M5
)
T3,
T6
(M4
)
T5,
T7
(M7
)
T9
(M6
)
T11
(M8
)
Tabla 2.1.2 duración y dependencias de las actividades
Teniendo la dependencia y duración estimada de las actividades, un diagrama
de actividades muestra la sucesión 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 gestión 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 rectángulos, 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 habrán completado.
Ingeniería en Sistemas Computacionales 33
Planificación y Modelado Planificación del Sistema
Fig. 2.1.3 Diagrama de actividades
Para estimar el tiempo mínimo requerido para finalizar el proyecto, se toma en
cuenta la trayectoria más larga en el diagrama de actividades, la trayectoria
crítica. En este ejemplo es de 11 semanas o 55 días laborales, y está resaltada
en la figura anterior.
El calendario realizado depende de esta trayectoria crítica, si se presentará
algún problema para completar una actividad dentro de la trayectoria crítica,
provocaría demora en el proyecto. Hay que señalar que si hay algún retraso en
actividades que no se encuentren dentro de la trayectoria crítica no provocan
necesariamente demora en todo el calendario.
Una alternativa es utilizar los gráficos de barras (también llamados gráficos de
Grantt) muestran quien hace qué, cuando inicia y cuando termina. Se pueden
generar automáticamente a partir de una base de datos utilizando
herramientas de gestión.
Ejemplo: considerando las actividades anteriormente listadas. El siguiente
diagrama de la figura 2.1.4 muestra las actividades, hitos y tiempo estimado.
Ingeniería en Sistemas Computacionales 34
Planificación y Modelado Planificación del Sistema
Fig. 2.1.4 gráfico 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
calendarización. La barra azul indica que hay flexibilidad en las fecha de
terminación para dichas actividades. Entonces, la trayectoria crítica se ve
afectada solamente si:
las actividades que no tiene la barra azul no se completan a tiempo.
las actividades con barra azul pasa del límite de tiempo marcado por
ésta.
También se puede hacer uso de los gráficos de barras para mostrar las
personas asignadas a las diferentes actividades y también el tiempo en que se
ocupará a las personas. La tabla 2.1.5 muestra la asignación de personas a las
actividades y la figura 2.1.6 lo muestra junto con el tiempo asignado.
Ingeniería en Sistemas Computacionales 35
Planificación y Modelado Planificación del Sistema
TareaIngenier
o
T1 Jane
T2 Anne
T3 Jane
T4 Fred
T5 Mary
T6 Anne
T7 Jim
T8 Fred
T9 Jane
T10 Anne
T11 Fred
T12 Fred
Tabla 2.1.5 asignación de personal a actividades
Ingeniería en Sistemas Computacionales 36
Planificación y Modelado Planificación del Sistema
Fig. 2.1.6 gráfico de barras de actividades de un proyecto de software
PERT Y CPM
A continuación se describirán el método PERT (Program Evaluation and Review
Technique) y el método CPM (Crítical Path Method), que fueron desarrollados
en Estados Unidos en 1957 [4 y 5].
Ambos métodos aportaron los elementos administrativos necesarios para
formar el método del camino crítico actual, utilizando el control de los tiempos
de ejecución y los costos de operación, 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
había intentado antes y por tanto no había bases de datos, para los tiempos de
las actividades). Esto condujo al enfoque probabilístico 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
administración de proyectos. La principal desventaja es que no es funcional
Ingeniería en Sistemas Computacionales 37
Planificación y Modelado Planificación del Sistema
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. Además, el costo de
actualizar y mantener la información del proyecto con el tiempo en ambientes
tan dinámicos, puede ser excesivamente prohibitivo.
Por otra parte, el CPM se desarrolló para manejar proyectos repetitivos o
similares (ej., mantenimiento de plantas químicas). 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 análisis de
técnicas de colisión utilizadas en las redes CPM.
A pesar de que PERT y CPM difieren un poco en terminología y en la forma de
construir el diagrama de red, sus objetivos son los mismos. El análisis usado
por ambas técnicas es muy similar.
Las diferencias entre PERT y CPM son las siguientes listadas en la tabla 2.1.7:
PERT es un método Probabilístico. CPM es un método Determinístico.
Considera que la variable de tiempo
es una variable desconocida de la
cual solo se tienen datos
estimativos.
Considera que los tiempos de las
actividades se conocen y se pueden
variar cambiando el nivel de recursos
utilizados.
El tiempo esperado de
finalización de un proyecto es la
suma de todos los tiempos
esperados de las actividades
sobre la ruta crítica.
A medida que el proyecto avanza, estos
estimados se utilizan para controlar y
monitorear el progreso. Si ocurre algún
retraso en el proyecto, se hacen
esfuerzos por lograr que el proyecto
quede de nuevo dentro de los tiempos
programados cambiando la asignación
de recursos.
Suponiendo que las
distribuciones de los tiempos de
las actividades son
Considera que las actividades son
continuas e interdependientes,
siguen un orden cronológico y ofrece
Ingeniería en Sistemas Computacionales 38
Planificación y Modelado Planificación del Sistema
independientes, la varianza del
proyecto es la suma de las
varianzas de las actividades en
la ruta crítica.
parámetros del momento oportuno
del inicio de la actividad.
Considera tres estimativos de
tiempos:
o el más probable
o optimista,
o pesimista.
Considera tiempos normales y
acelerados de una determinada
actividad, según la cantidad de
recursos aplicados en la misma.
Tabla 2.1.7 diferencias entre PERT y CPM
Método CPM
Los siguientes son los pasos en el planeamiento del proyecto con CPM y son
descritos brevemente a continuación:
1. Especificar las actividades individuales.
2. Determinar la secuencia de esas actividades.
3. Dibujar el diagrama de la red.
4. Estimar el tiempo de terminación para cada actividad.
5. Identificar la trayectoria crítica (la trayectoria más larga a través 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
Ingeniería en Sistemas Computacionales 39
Planificación y Modelado Planificación del Sistema
de personas en forma continua, sin interrupciones, con tiempos determinables
de inicio y término.
2. Determinar la secuencia de esas actividades.
Algunas actividades son dependientes en la terminación de otras. Un listado de
los precursores inmediatos de cada actividad es útil para construir el diagrama
de la red del CPM. Existen dos procedimientos para conocer la secuencia de las
actividades: Por medio de los precursores y por secuencias.
Por medio de los precursores se les preguntará a los responsables de los
procesos cuales actividades deben quedar terminadas para ejecutar cada una
de las que aparecen en la lista.
En el segundo procedimiento se preguntara a los responsables de la ejecución,
cuales actividades deben hacerse al terminar cada una de las que aparecen en
la lista.
3. Dibujar el diagrama de red.
Se llama red a la representación gráfica 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 dibujarán de acuerdo con las necesidades y
comodidad de presentación de la red. Pueden ser horizontales, verticales,
ascendentes, descendentes curvas, rectas, quebradas, etc.
Se llama evento al momento de iniciación o terminación de una actividad. Se
determina en un tiempo variable entre el más temprano y el más tardío
posible, de iniciación o de terminación. A los eventos se les conoce también
con los nombres de nodos
Ingeniería en Sistemas Computacionales 40
Planificación y Modelado Planificación del Sistema
Fig. 2.1.8 diagrama de red4. Estimar el tiempo de terminación 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 variación en el tiempo de la
terminación, tan solamente un número se utiliza para la estimación del tiempo
de una actividad.
5. Identificar la trayectoria crítica (la trayectoria más larga a través de la
red).
No solamente se llama camino crítico al método sino también a la serie de
actividades contadas desde la iniciación del proyecto hasta su terminación, que
no tienen flexibilidad en su tiempo de ejecución, por lo que cualquier retraso
que sufriera alguna de las actividades de la serie provocaría un retraso en todo
el proyecto. Desde otro punto de vista, camino crítico es la trayectoria crítica
de mayor duración a través de la red. Debido a su impacto en el proyecto
entero, el análisis de trayectoria crítica es un aspecto Importante del
planeamiento del proyecto.
La trayectoria crítica puede ser identificada determinando los cuatro
parámetros siguientes para cada actividad:
o ES, Inicio más temprano.
o EF, Inicio más tardío.
Ingeniería en Sistemas Computacionales 41
Planificación y Modelado Planificación del Sistema
o LS, terminación más temprana.
o LF, terminación más tardía.
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 más temprano
en el que una actividad puede comenzar con el tiempo más tardío en el que
dicha actividad puede comenzar, sin retrasar el proyecto.
HT = EF – ES
La trayectoria crítica es la trayectoria a través 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 terminación de las
tareas se conocerán y el diagrama de red se tiene que actualizar para incluir la
nueva información. Una trayectoria crítica nueva puede emerger, y los cambios
estructurales se pueden realizar en la red si los requisitos del proyecto
cambian.
Método PERT
En CPM se asume que la duración de cada actividad es conocida con certeza.
Claramente, en muchas ocasiones este supuesto no es valido. PERT intenta
corregir este error suponiendo que la duración de cada actividad es una
Ingeniería en Sistemas Computacionales 42
Planificación y Modelado Planificación del Sistema
variable aleatoria. Para cada activad, se requiere estimar las siguientes
cantidades:
a = Tiempo Optimista. Duración de la actividad bajo las condiciones más
favorables.
b = Tiempo Pesimista. Duración de la actividad bajo las condiciones más
desfavorables.
m = Tiempo Normal. El valor más probable de la duración de la actividad.
La forma de la distribución se muestra en la figura 2.1.7 . El tiempo más
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.
Fig. 2.1.7 distribución de los tiempos
Con la distribución definida, la media (esperada) y la desviación estándar,
respectivamente, del tiempo de la actividad para la actividad Z puede
calcularse por medio de las fórmulas de aproximación.
Ingeniería en Sistemas Computacionales 43
Planificación y Modelado Planificación del Sistema
El tiempo esperado de finalización de un proyecto es la suma de todos los
tiempos esperados de las actividades sobre la ruta crítica. 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 crítica.
Pasos en el proceso de planeamiento del PERT
1. Identificar las actividades y su interdependencia
2. Determinar la secuencia de actividades
3. Construir el diagrama de red
4. Tiempos estimados de actividades
5. Determinar la trayectoria crítica
6. Actualizar según el progreso del proyecto
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
más actividades.
2. Determinar la secuencia de actividades
Este paso se puede combinar con el paso de la identificación de la actividad
puesto que la secuencia de la actividad es evidente para algunas tareas. Otras
tareas pueden requerir más análisis para determinar el orden exacto en la cual
deben ser realizadas
Ingeniería en Sistemas Computacionales 44
Planificación y Modelado Planificación del Sistema
3. Construir el diagrama de red
Usando la información 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 estimación Optimista. El que representa el tiempo mínimo
posible sin importar el costo o cantidad de recursos materiales y humanos que
se requieran; es simplemente la posibilidad física 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 más probable de la duración de la actividad,
basado en la experiencia personal de un experto.
Si Tij es la variable aleatoria asociada a la duración de la actividad (i; j), PERT
asume que Tij sigue una distribución Beta. Sin entrar en mayores detalles de
esta distribución, se puede demostrar que el valor esperado y la varianza de la
variable aleatoria Tij quedan definidas por:
En PERT se asume además que la duración de las actividades es
independiente. Por lo tanto, el valor esperado y la varianza de una ruta pueden
ser estimadas según:
= Duración esperada de la ruta
Ingeniería en Sistemas Computacionales 45
Planificación y Modelado Planificación del Sistema
= Variación de la duración de la ruta
5. Determinar la trayectoria crítica
La trayectoria crítica es determinada agregando los tiempos para las
actividades en cada secuencia y determinando la trayectoria mas larga del
proyecto.
La trayectoria crítica determina el tiempo total del calendario requerido para el
proyecto. Si las actividades fuera de la trayectoria cítrica aceleran o retrasaron
el tiempo (dentro de los límites), entonces el tiempo total de proyecto no varia;
la cantidad del tiempo en que una actividad de la trayectoria crítica no altera la
duración del proyecto se denomina holgura.
Si la trayectoria crítica del proyecto no resulta obvia, entonces puede ser
provechoso determinar las cuatro cantidades siguientes para cada actividad:
ES, Inicio más temprano.
EF, Inicio más tardío.
LS, terminación más temprana.
LF, terminación más tardía.
Se calculan estos tiempos usando el tiempo previsto para las actividades
relevantes. Los tiempos de inicio y terminación más tempranos de cada
actividad son determinados trabajando desde el inicio al final a través de la red
y determinando el tiempo más temprano en el cual una actividad puede
comenzar y acabar considerando las actividades del precursor.
Los tiempos de inicio y terminación más tardíos son el tiempo más 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 atrás a través de la red.
La diferencia entre la terminación más tardía y la terminación más temprana
da como resultado la holgura de una actividad. La trayectoria crítica entonces
Ingeniería en Sistemas Computacionales 46
Planificación y Modelado Planificación del Sistema
es la trayectoria a través de la red en la cual ningunas de las actividades
tienen holgura.
La variación en el tiempo de la terminación del proyecto puede ser calculada
sumando las variaciones en los tiempos de la terminación de las actividades en
la trayectoria crítica. Dado esta variación, una puede calcular la probabilidad
que el proyecto será terminado por cierta fecha si se asume una distribución
normal de la probabilidad para la trayectoria crítica.
Sea CP la variable aleatoria asociada a la duración total de las actividades de la
ruta crítica determinadas mediante CPM. PERT asume que la ruta crítica
encontrada a través de CPM contiene suficientes actividades para emplear el
Teorema Central del Límite y concluir que CP se distribuye normalmente.
Puesto que la trayectoria crítica determina la fecha de la terminación del
proyecto, el proyecto puede ser acelerado agregando los recursos requeridos
para disminuir el tiempo para las actividades en la trayectoria crítica.
6. Actualizar según 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 Evaluación del costo – beneficio
Hoy en día el Software es el elemento más caro en la mayoría de los sistemas
de información, por lo que la estimación debe realizarse cuidadosamente ya
Ingeniería en Sistemas Computacionales 47
Planificación y Modelado Planificación del Sistema
que un gran error en la estimación del costo puede ser lo que marque la
diferencia entre beneficios y pérdidas tanto para clientes y la empresa
desarrolladora de software.
De acuerdo con Pfleeger [PFL02], dentro de la planificación es crucial
comprender cuál será el costo aproximado de éste. Unas de las razones son
porque:
o Los costos excedidos pueden causar que los clientes cancelen el
proyecto.
o Los costos subestimados lo que puede no compensar el tiempo invertido
por el equipo del proyecto.
No se debe olvidar que la estimación es una actividad compleja que se vale de
modelos y de técnicas y estos a su vez se basan en métricas, por lo que es
necesario profundizar sobre éstas.
2.2.1 Métricas de Software
Dentro de la Ingeniería de Software existe controversia con las métricas, como
lo son las siguientes:
o Algunos desarrolladores piensan que el recolectar métricas es difícil y
consume mucho tiempo.
o Otros que es difícil ponerse de acuerdo de lo que se tiene que medir, las
métricas que se utilizarán para hacerlo y posteriormente como utilizar
los resultados obtenidos.
Pressman [PRE02], comenta que aún cuando muchos desarrolladores de
software se resisten al uso de las métricas como una guía 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 tendría la certeza de
una mejora tanto en el desarrollo del producto como en la calidad del producto
en si.
Ingeniería en Sistemas Computacionales 48
Planificación y Modelado Planificación del Sistema
De acuerdo a Lord Kelvin “Cuando se puede medir lo que se esta diciendo y
expresarlo con números, significa que tenemos conocimientos sobre ese tema, cuando esto
no ocurre significa que nuestro conocimiento es precario y deficiente”.
La medición es muy común en el mundo de la ingeniería en general. Aún así,
con respecto a la ingeniería de software no lo es tanto por las cuestiones
descritas anteriormente. Sin embargo hay razones que justifican la medición
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 métodos y herramientas de
ingeniería de software justificando el uso de éstos.
o Esta evaluación permite una mejora continua al proceso de
desarrollo de software.
o Nos ayuda a establecer una línea base para la estimación
Qué es una medida:
Ingeniería en Sistemas Computacionales 49
Planificación y Modelado Planificación del Sistema
Cuando se recopila un solo aspecto de los datos se está hablando de medidas.
Ejemplo: número de líneas de código o número de errores.
La medición es el acto de determinar una medida. Y es el resultado de la
recopilación de uno o varios aspectos de los datos. Ejemplo: se investiga un
número de revisiones de módulos para recuperar las medidas de errores
encontrados durante cada revisión.
Qué es una métrica
Es una medida cuantitativa del grado en que un sistema, componente o
proceso posee un atributo dado (IEEE Standard Glossary of Software
Engineering, 1993).
Describe en cierta forma las medidas individuales sobre algún aspecto.
Ejemplo: el número de errores encontrados por revisión o por persona.
Fiabilidad, facilidad de uso, facilidad de cambio, etc.
Un ingeniero de software recopila medidas y desarrolla métricas para obtener
indicadores. Un indicador: es una métrica o una combinación de métricas que
proporcionan un visión 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
Ingeniería en Sistemas Computacionales 50
Planificación y Modelado Planificación del Sistema
dos tipos de indicadores o métricas: Indicadores de proceso e indicadores del
proyecto. Muchas de las métricas se pueden utilizar tanto en el dominio del
proceso cono en el del proyecto [PRE04].
1. Indicadores de proceso.
o brindan una visión profunda sobre la eficacia de un proceso ya
existente.
o permiten evaluar lo que está y no funcionando.
o Su propósito 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, además se utilizan para realizar las
estimaciones de tiempo y esfuerzo. Permiten al gestor de proyecto:
o Evaluar el estado del proyecto
o Seguir las pistas de los riesgos potenciales
o Detectar las áreas de problemas para evitar áreas críticas
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 físico pueden englobarse en dos categorías, directas
e indirectas:
o medidas directas como lo es el largo de un tornillo
o y medidas indirectas como lo es la calidad de un tornillo.
Las métricas del software pueden ser catalogadas en forma análoga, directas e
indirectas y se aplican al proceso, proyecto y producto de software.
Medidas directas:
Ingeniería en Sistemas Computacionales 51
Planificación y Modelado Planificación del Sistema
o del proceso, donde se miden los datos cuantitativos del software, como
costo y esfuerzo aplicado, número de ocurrencias de un evento .
o del producto, donde se miden las características del software y se
dividen a su vez en dinámicas y estáticas:
o dinámicas: aquellas que se relacionan directamente con los
atributos de calidad del software y que se miden al momento
en que un programa está en ejecución. Un ejemplo es obtener
el tiempo de ejecución, defectos, etc.
o estáticas: los resultados de estas mediciones se obtienen de
partes que representen al sistema como lo es el diseño,
código, documentos. Como lo es el medir las líneas de código
producidas.
Ejemplo: métricas orientadas al tamaño. 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: métricas orientadas a la función. Son medidas indirectas del proceso
de software.
Métricas orientadas al tamaño
Las métricas del software orientadas al tamaño son medidas directas del
proceso de software, provienen de la normalización de las medidas de calidad
y/o productividad considerando el tamaño de software que se ha producido
[PRE02]. La métrica orientada al tamaño más utilizada es LOC (Lines Of Code)
o SLOC (Source Lines Of Code) en español líneas de código LDC. Calcula el
tamaño de un producto en LDC y con esto el grado de errores y productividad
entre otros.
Ingeniería en Sistemas Computacionales 52
Planificación y Modelado Planificación del Sistema
Teniendo la tabla 2.2.1 como ejemplo podrían calcularse los valores a
continuación
Nombre
del
proyecto
Nº de
Personas
Costo $ Nº de
errores
Nº de páginas
de
documentación
Esfuerzo
empleado
(días/hombre)
Líneas de
código
(LDC)
Proy1 15 20Mil 520 320 1200 3220
Proy2 10 17Mil 380 450 1000 2800
tabla 2.2.1
Productividad =LDC / persona mes
Costo = $ / LDC
Grado de errores = Nº de errores / LDC
Grado de documentación = Nº de páginas documentadas / LDC
Ventajas:
o Que son fáciles de calcular en cualquier proyecto
o Existen varias herramientas de estimación basadas en las líneas de
código
Desventajas:
o la falta de una definición universal de línea de código
o las líneas de código dependen de los lenguajes de programación y por lo
tanto perjudica a los programas más cortos pero bien diseñados.
o El estilo de programación dependerá de cada persona. Comparar la
productividad utilizando lenguajes diferentes de programación puede
llevar a conclusiones erróneas respecto a la productividad de los
programadores.
o El decidir que líneas de código se contabilizaran ya sean nuevas, líneas
modificadas, reutilizadas más definiciones de datos y comentarios.
Ingeniería en Sistemas Computacionales 53
Planificación y Modelado Planificación del Sistema
o dificultad de estimar en fases tempranas del desarrollo la cantidad de
líneas que tendrá una aplicación.
Métricas orientadas a la función
Es un método para cuantificar el tamaño y la complejidad de un sistema
software en términos de las funciones que el usuario desarrolla o desarrollará.
Utilizan una media de la funcionalidad de software como valor de
normalización. Puesto que la funcionalidad no puede medirse directamente se
debe obtenerla indirectamente a través de otras medidas directas.
Se entiende por funciones a las entradas, salidas, archivos, etc.
La primera propuesta de los puntos de función fue realizada por Albrecht,
métrica que hasta hoy es muy utilizada. De ésta se derivan otras como los
puntos de característica y los puntos de función para estimación temprana.
Para calcular los puntos de función es necesario conocerlo siguiente y se
muestra en la tabla 2.2.2:
1. Número de entradas de usuario: aquellas que permiten añadir, 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. Número de salidas de usuario: aquellas que proporciona información al
usuario. Ejemplos: Pantallas, informes, gráficos o mensajes.
3. Número 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. Número de archivos lógicos internos, se cuenta cada archivo de forma
individual. Son los principales grupos lógicos de datos de usuarios finales
Ingeniería en Sistemas Computacionales 54
Planificación y Modelado Planificación del Sistema
o información de control que es manejada absolutamente por el
programa. Un archivo lógico podría constar de un único archivo plano o
de una sola tabla en una base de datos relacional.
5. Número 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 lógicos o
información de control que entre o salga en el programa.
Parámetros de medición Cuenta
simple
Cuenta
media
Cuenta
compleja
total
Nº entradas
Nº salidas
Nº peticiones
Nº archivos
Nº interfaces
* 3 + * 4 + *6
Cuenta
total
Tabla 2.2.2 tabla de parámetros de medición
PF (Puntos de función) = 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 recuperación fiables?
Ingeniería en Sistemas Computacionales 55
Planificación y Modelado Planificación del Sistema
2. ¿Se necesita comunicación datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico 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 múltiples
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 diseñado el código para ser reutilizable?
12.¿Están incluidas en el proyecto la conversión e instalación?
13.Se ha diseñado el software para instalarlo en diferentes empresas?
14.¿Se ha diseñado el software para facilitar los cambios y ser fácilmente
usado por el usuario?
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 función por el
multiplicador de la complejidad, para conseguir un valor de puntos de
función ajustado.
Productividad= PF/persona mes
Costo= pesos/PF
Ventajas:
Ingeniería en Sistemas Computacionales 56
Planificación y Modelado Planificación del Sistema
o son independientes del lenguaje de programación y desde este punto de
vista lo hace más atractivo como enfoque de estimación.
o pueden ser estimados a partir de la especificación de requisitos o
especificaciones de diseño, lo que permite una estimación temprana.
o Como se basan en una visión externa del usuario, los usuarios no
técnicos entienden mejor lo que los puntos de función están midiendo.
Desventaja: Como aspecto negativo tienen el que se basan en unas
valoraciones subjetivas y además que el PF no tienen un significado físico
directo. (e)
Puntos de Característica
Debido a que el análisis por Puntos de Función fue diseñado para software de
gestión y no es fácil de generalizar a aplicaciones científicas, de tiempo real y
otras, Caper Jones propuso ampliaciones al método que denominó Puntos de
Característica, que da cabida a aplicaciones cuya complejidad algorítmica es
alta.
Este método considera los mismos elementos que considera Albrecht en su
método de análisis por puntos de función, sólo que añade la variable número
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 generación o similares
para el desarrollo. Los puntos de objeto no son clases de objetos [SOM00].
El número de puntos de objeto en un programa es una estimación ponderada
de:
o El número de pantallas que son visualizadas por separado
o El número de informes que se producen por el sistema
Ingeniería en Sistemas Computacionales 57
Planificación y Modelado Planificación del Sistema
o El número de módulos lenguajes de tercera generación que deben
desarrollarse para complementar el código 4G.
Métricas para la calidad del software
Cualquier proyecto de ingeniería del software tiene como objetivo principal
obtener sistemas y productos de alta calidad [PRE02]. La calidad es difícil
medirla directamente, no obstante hay indicadores que nos pueden dar una
idea sobre la misma. Gilb basa estos indicadores en los siguientes aspectos:
o Corrección.- Es el grado en el que el software lleva a cabo su función.
Se mide en “defectos por KLDC” (miles de líneas de código),
entendiéndose por “defecto” cualquier falta de concordancia con los
requisitos.
o Facilidad de mantenimiento.- Se mide por la facilidad de:
o corregir defectos encontrados,
o adaptar ese programa a nuevos entornos
o mejorar el programa si el cliente desea cambios.
La facilidad de mantenimiento se mide indirectamente por medio de una
métrica orientada al tiempo: “tiempo medio del cambio (TMC)”, es decir,
por el tiempo que se tarda en analizar la petición del cambio, diseñar la
modificación, implementarla, probarla y distribuir la notificación 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
documentación 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.
Ingeniería en Sistemas Computacionales 58
Planificación y Modelado Planificación del Sistema
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.- Entendiéndose 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 características:
1- Habilidad intelectual o física 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- Valoración subjetiva de la disposición de los usuarios hacia el
sistema.
Se concluye con lo que respecta a las métricas, que definen que es lo que se
va a predecir y los métodos o técnicas definen como una métrica es predicha.
Se recomienda hacer la estimación utilizando más de un modelo o técnica para
que una respalde o refute a la otra.
Con el conocimiento sobre las métricas del software se puede proseguir con el
tema de la estimación.
2.2.2 Estimación del proyecto de software
De acuerdo con Pressman [PRE02], con frecuencia una estimación más que
una ciencia es un arte pero no por ello debe descuidarse, sino más bien se
debe realizarla de manera estricta. Cualquier estimación lleva consigo un
riesgo o incertidumbre viéndose esta afecta por: (observaciones de la
estimación)
Ingeniería en Sistemas Computacionales 59
Planificación y Modelado Planificación del Sistema
o Complejidad del proyecto: es una medida relativa que se ve afectada
por la familiaridad que se tenga con esfuerzos anteriores.
o Tamaño del proyecto: afecta a la precisión y eficiencia de las
estimaciones. Cuanto mayor sea el proyecto, mayor será el riesgo de la
estimación.
o Disponibilidad de información histórica: Si no se dispone de información
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 planificación 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 también afectar a la competitividad de la compañía así como
provocar perdida de beneficios, por ejemplo podría contratarse personal en
exceso para la realización del proyecto.
Lo que la estimación busca determinar es:
Una buena estimación de costo al comienzo del proyecto nos ayuda a conocer
cuantos desarrolladores se requerirán y así preparar el equipo apropiado para
que esté disponible cuando se lo necesite [SOM00].
Los recursos.
Una de las tareas importantes de la planificación del desarrollo de software
es la estimación de los recursos requeridos para acometer el esfuerzo.
De acuerdo con Pressman [PRE02], se considera una pirámide de recursos
ilustrada en la figura 2.2.2.1:
Ingeniería en Sistemas Computacionales 60
Planificación y Modelado Planificación del Sistema
1. En la base se encuentran los recursos técnicos, 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 servirán para el nuevo desarrollo.
3. Y en la punta los recursos primarios, los recursos humanos.
Fig. 2.2.2.1 recursos del proyecto
De cada recurso se debe especificar las siguientes características, que son las
que se toman en cuanta a la hora de la estimación.
o Descripción del recurso
o Informes de disponibilidad
o Fecha en la que se requiere el recurso, inicio y fin
o Tiempo durante el que será aplicado el recurso
Las dos últimas características, se denominan “ventana temporal” que
representa la disponibilidad de un recurso para un proyecto específico, y debe
ser fijado lo antes posible para una buena planificación de recursos.
Recursos Humanos.- La Cantidad de personas requeridas para el desarrollo de
un proyecto de software sólo puede ser determinado después de hacer una
estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas
años), y seleccionar la posición dentro de la organización y la especialidad que
desempeñara cada profesional.
Ingeniería en Sistemas Computacionales 61
Planificación y Modelado Planificación del Sistema
Recursos o componentes de software reutilizables.- Cualquier estudio sobre
recursos de software estaría incompleto sin estudiar la reutilización, esto es la
creación y la reutilización de bloques de construcción de Software. Tales
bloques se deben establecer en catálogos para una consulta más fácil,
estandarizarse para una fácil aplicación y también validarse para una fácil
integración.
Bennatan sugiere cuatro categorías de recursos de software que se deberían
tener en cuenta a medida que se avanza con la planificación:
o Componentes ya desarrollados.
o Componentes ya experimentados.
o Componentes con experiencia Parcial.
o Componentes nuevos.
Recursos de entorno.- El entorno es donde se apoya el proyecto de Software,
llamado a menudo entorno de Ingeniería 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 Ingeniería del Software, un planificador de proyectos debe
determinar la ventana temporal requerida para el Hardware y el Software, y
verificar que estos recursos estén disponibles. Muchas veces el desarrollo de
las pruebas de validación de un proyecto de software para la composición
automatizada puede necesitar un compositor de fotografías en algún punto
durante el desarrollo. Cada elemento de hardware debe ser especificado por el
planificador del proyecto de software.
2.2.2.1 Técnicas para la estimación del software
Ingeniería en Sistemas Computacionales 62
Planificación y Modelado Planificación del Sistema
Para realizar estimaciones seguras de costos y esfuerzos tienen varias
opciones posibles:
1. Dejar la estimación para más adelante (obviamente se puede realizar
una estimación 100% fiable después de haber terminado el proyecto).
2. Basar las estimaciones en proyectos similares ya terminados.
3. Utilizar técnicas de estimación relativamente sencilla para generar las
estimaciones de costos y esfuerzo del proyecto.
4. Utilizar un modelo empírico para él cálculo de costos y esfuerzos del
Software.
Desdichadamente la primera opción, aunque atractiva no es práctica. La
Segunda opción 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 métodos viables para la estimación del
proyecto de software. Desde el punto de vista ideal, se deben aplicar
conjuntamente las técnicas indicadas usando cada una de ellas como
comprobación de las otras.
Técnicas de descomposición.
Antes de hacer una estimación, el planificador del proyecto debe comprender
el ámbito del software a construir y generar una estimación de su tamaño.
La estimación de un proyecto de software se predice basándose en lo
siguiente:
1. Por el grado en el que el planificador ha estimado adecuadamente el
tamaño del proyecto.
2. Por la habilidad en traducir el tamaño 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.
Ingeniería en Sistemas Computacionales 63
Planificación y Modelado Planificación del Sistema
4. Por la estabilidad de los requerimientos y del entorno de desarrollo.
La estimación del tamaño es el reto del planificador, ya que en el contexto de
la planificación de proyectos, el tamaño se refiere a una producción
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.
Estimación basada en el problema.- los datos de LDC y PF se utilizan de dos
formas: 1) como una variable de estimación que se utiliza para cada elemento
del software y 2) como métricas de línea de base recopiladas de proyectos
anteriores y utilizadas junto con variables de estimación para desarrollar
proyecciones de costo y esfuerzo.
Estimación basada en el proceso.- Es una de las técnicas más comunes para
estimar un proyecto. Lo que se hace es descomponer el proceso en un
conjunto relativamente pequeño de actividades y en el esfuerzo requerido para
llevar a cabo cada actividad. Al igual que las técnicas basadas en problemas, la
estimación basada en el proceso comienza en una delineación 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 función y la actividad del proceso de
software.
Otras técnicas de estimación.
Juicio Experto
Es la técnica más utilizada para realizar estimaciones de costos y tiempos. Son
técnicas informales basadas en la experiencia de los gestores de proyecto o de
otras personas que hayan desarrollado aplicaciones similares.
Ingeniería en Sistemas Computacionales 64
Planificación y Modelado Planificación del Sistema
De acuerdo con Sommerville [SOM00] las ventajas están en que es una técnica
estimación económica 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.
Estimación por analogía
También se hace uso de analogías, al tener un sistema parecido entonces
pueden basar la estimación 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 debería ser similar
[PFL02].
De acuerdo a [SOM00] la ventaja de esta técnica está en que es precisa si está
disponible la información del proyecto con el cuál 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 estimación más formal, se les
pide a varios expertos que hagan tres predicciones:
Pesimista (EP)
Optimista (EO)
Ingeniería en Sistemas Computacionales 65
Planificación y Modelado Planificación del Sistema
La conjetura más probable (EMP)
Asignándole una probabilidad a cada una, se obtiene la estimación mediante:
E=EO *Po + EMP*Pmp + EP*Pp
Donde Po es la probabilidad asignada a la estimación optimista, Pmp la
asignada a la más probable y Pp la asignada a la pesimista.
Ley de Parkinson
Los costos del proyecto están en función de los recursos disponibles, utilizando
todo el tiempo permitido [SOM00].
Ventaja: No se sobrepasa el presupuesto.
Desventaja: El sistema normalmente no se termina.
Pricing to win
El costo del proyecto está en función 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
mínima, y los costos no reflejan realmente el trabajo requerido.
Esta es algunas veces la única técnica aplicable, aunque es poco profesional.
La estimación completa puede estimarse mediante dos tipos de análisis
[SOM00]:
o Top-down (descendente): Comienza a nivel de sistema y evalúa la
totalidad de funcionalidades y cómo é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 añaden
a la estimación final
Ingeniería en Sistemas Computacionales 66
Planificación y Modelado Planificación del Sistema
Estimación descendente
o Se puede usar sin conocer la arquitectura ni los componentes que
formarán parte del sistema.
o Tiene en cuenta costos tales como integración, gestión de
configuraciones y documentación.
o Puede sub-estimar costos relacionados con la resolución de problemas
técnicos de bajo nivel difíciles de resolver.
Estimación 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 diseñado
con detalle.
o Puede subestimar costos a nivel de sistema, tales como integración y
documentación.
Aún cuando en la práctica, la mayoría de las estimaciones se basan en el juicio
experto y en la información histórica, es importante conocer algunos modelos y
técnicas de estimación que de manera conjuntan con el uso de métricas
devuelven una estimación. De acuerdo con Sommerville [SOM00], la
estimación se debe basa en varias técnicas que devuelvan datos aproximados.
2.2.2.2 Modelos de estimación
Modelos algorítmicos
Son modelos que expresan la relación entre el esfuerzo y los factores que lo
influencian. Utilizan ecuaciones donde el esfuerzo es la variable dependiente y
varios factores como la experiencia, tamaño (que es el de mayor influencia) y
tipo de sistema, son las variables independientes.
Ingeniería en Sistemas Computacionales 67
Planificación y Modelado Planificación del Sistema
Estos modelos suelen basarse en el tamaño del software y tienen un
componente exponencial (los costos no crecen normalmente de forma lineal
con el tamaño del proyecto).
Esfuerzo = A x TamañoB x M
Uno de los problemas con este tipo de modelo es que el tamaño es una
variable clave, y al momento de hacer la estimación la información sobre el
tamaño es incierta [PFL02].
Modelos empíricos
Los Modelos empíricos se dividen en:
o paramétricos. Los cuales tiene una formula funcional explícita,
relacionando una variable dependiente con una o más variables
o no paramétricos. no tiene una formula funcional explícita, por ejemplo,
un modelo desarrollado usando la técnica de aprendizaje máquina como
una red neuronal.
Los modelos de estimación más comunes son los Modelos paramétricos
empíricos de estimación:
o Utilizan fórmulas derivadas empíricamente para predecir el esfuerzo
como una función de LDC o PF.
o Utilizan datos empíricos obtenidos de una muestra de proyectos:
o Son difíciles de usar para todas las clases de software y todos los
entornos de desarrollo
o Se deben calibrar para las condiciones específicas de una
organización
La siguiente es la fórmula para obtener la estimación del esfuerzo en personas-
mes.
Ingeniería en Sistemas Computacionales 68
E = A + B X (ev) c
Donde A y B: son constantes obtenidas empíricamenteE: esfuerzo en meses/personaev: variable de estimación (LDC o PF)
Planificación y Modelado Planificación del Sistema
El Modelo COCOMO.
De estos modelos lo más 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 pequeños
Moderado: intermedios en cuanto al tamaño y complejidad
Embebido (empotrado): proyectos que deben ser desarrollados en un
conjunto de hardware, software y restricciones operativas muy
restringidas.
El modelo constructivo de costos de Boehm es una jerarquía de modelos de
estimación constituida por los siguientes:
Modelo I. El Modelo COCOMO básico utilizaba las líneas de código como factor
clave. Calcula el esfuerzo y el costo del desarrollo de Software en función del
tamaño del programa, expresado en líneas de código (LDC) estimadas.
E = ab LDC bb = personas / mes
C= cb E db = meses
En la tabla se muestran los valores para cada tipo de proyecto que toma cada
constante de la fórmula del esfuerzo.
Proyecto ab Bb cb db
Simple 2,4 1,05 2,5 0,38
Moderado 3,0 1,12 2,5 0,35
Embebido 3,6 1,20 2,5 0,32
Tabla 2.2.2.2 valores para fórmula del esfuerzo.
Ingeniería en Sistemas Computacionales 69
Planificación y Modelado Planificación del Sistema
Modelo II. Como es imposible conocer al inicio del ciclo de desarrollo las líneas
de código 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 tamaño del producto final,
entonces se estima la dimensión sobre la base de lo que sus creadores
denominan puntos de objeto y una fórmula simple para el cálculo del esfuerzo.
En otras palabras, captura las dimensiones en términos de generadores de
esfuerzo, tales como el número 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 número de puntos de objeto, y
PROD es la productividad que depende de:
o La experiencia y capacidad del desarrollador
o Las capacidades de la herramienta CASE utilizada
Y toma los valores presentados en la tabla 2.2.2.3.
Muy baja Baja Nominal Alta Muy alta
4 7 13 25 50
Tabla 2.2.2.3
Nivel inicial de diseño: cuando se decide por una arquitectura para el diseño,
nuevamente no hay suficiente información para una estimación precisa de
esfuerzo y duración, pero se conoce más que en el nivel 1. Entonces se emplea
puntos de función convertidas en LDC.
Las estimaciones pueden hacerse después de que los requerimientos hayan
sido establecidos.
Se basa en las fórmulas estándar para métodos algorítmicos:
PM = A x TamañoB x M + PMm
en donde
M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED
Ingeniería en Sistemas Computacionales 70
Planificación y Modelado Planificación del Sistema
PMm = (ASLOC x (AT/100)) / ATPROD
A = 2.5 según la calibración inicial, Tamaño se da en LDC, B varía desde 1.1
hasta 1.24 dependiendo de la novedad del proyecto, la flexibilidad del
desarrollo, la gestión de riesgos, y la madurez del proceso
Los multiplicadores (M) reflejan la capacidad de los desarrolladores,
requerimientos no funcionales, la familiaridad con la plataforma de desarrollo,
etc.
o RCPX - fiabilidad de producto y complejidad
o RUSE - reutilización requerida
o PDIF - dificultad de la plataforma
o PREX - experiencia del personal
o PERS - capacidad del personal
o SCED - agenda requerida
o FCIL - facilidades de soporte de grupo
PM refleja la cantidad de código generada automáticamente.
Nivel Post arquitectura: es cuando el desarrollo ha comenzado y se tiene
mucha más información. Para la estimación de costos se utiliza entonces
puntos de función o líneas de código.
Usa la misma fórmula que la estimación inicial de diseño:
PM = A x TamañoB x M + PMm
Se ajusta la estimación de tamaño para que tenga en cuenta:
o La volatilidad de los requerimientos
o Grado de posible reutilización
ESLOC = ASLOC x (AA + SU +0.4DM + 0.3CM +0.3IM)/100
ESLOC es el número de líneas de código nuevo.
Ingeniería en Sistemas Computacionales 71
Planificación y Modelado Planificación del Sistema
ASLOC es el número de líneas de código reusable que debe modificarse.
DM es el porcentaje de diseño modificado.
CM es el porcentaje de código que se modifica
IM es el porcentaje del esfuerzo original de integración del software reusado.
SU es un factor basado en la interpretación del coste del software
AA es un factor que refleja los costes de evaluación iniciales para decidir si el
software puede reutilizarse.
El término exponente (B) depende de 5 factores de escala. La suma de dichos
factores se divide por 100 y se añade a 1.01
Ejemplo:
Antecedentes proyecto nuevo 4
Flexibilidad desarrollo no implicación cliente Muy alto 1
Arquitectura/resolución riesgos No. análisis de riesgos Muy bajo 5
Cohesión del grupo nuevo grupo nominal 3
Madurez proceso algún control nominal 3
Por lo tanto El factor de escala es 1.17
Multiplicadores (M)
o Atributos del producto
o Atributos del ordenador
o Atributos del personal
o Atributos del proyecto
Modelo III. El modelo COCOMO avanzado
o incorpora todas las características del modelo intermedio
o evalúa el impacto de los conductores de costos en cada fase del
proceso (análisis, diseño, etc.).
2.2.2.3 La decisión desarrollar o comprar
Ingeniería en Sistemas Computacionales 72
Planificación y Modelado Planificación del Sistema
En muchas ocasiones es más aconsejable adquirir un producto de software que
desarrollarlo. Los gestores son los que tienen que tomar esta decisión 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 construcción 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 especificación de la función y rendimiento del software
deseado.
2. Evaluar costo desarrollo interno y fecha de entrega.
3. Seleccionar tres o cuatro aplicaciones candidatos que se ajusten a la
especificación o seleccionar componentes reutilizables.
4. Desarrollar una matriz de comparación de funciones clave
5. Evaluación de cada paquete de software seleccionad basándose en:
o Calidad de productos anteriores
o Soporte Post venta
o Reputación organización
o Etc.
6. Recabar información de opiniones de otros usuarios de dicho software.
La decisión final de desarrollar - comprar se basará en las siguientes
condiciones:
o ¿La fecha de entrega externa es menor a la fecha final de desarrollo?
o ¿El costo de compra externa es menor al costo de desarrollo interno?
o ¿El costo soporte externo (mantenimiento) es menor al costo soporte
interno?
Ingeniería en Sistemas Computacionales 73
Planificación y Modelado Planificación del Sistema
En cualquiera de las tres alternativas, un factor importantísimo es la
disponibilidad de recursos humanos, Técnicos/hardware/ software.
2.2.2.4 Herramientas Automáticas De Estimación
Implementan técnicas de descomposición y modelos empíricos. Permiten al
planificador estimar costos y esfuerzos, así como llevar a cabo análisis del tipo,
“que pasa si”, con importantes variables del proyecto, tales como la fecha de
entrega o la selección del personal. Aunque existen muchas herramientas
automáticas de estimación, todas exhiben las mismas características generales
y todas requieren de una o más clases de datos.
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 duración, y en algunos casos la planificación
temporal de desarrollo y riesgos asociados. Qué datos necesitan:
o Datos cuantitativos sobre el tamaño del proyecto (LDC, PF)
o Características cualitativas del proyecto.
o 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 realización. La estimación del
proyecto de software nunca será una ciencia precisa, pero la combinación de
buenos datos históricos y técnicas puede mejorar la precisión de la estimación.
2.2.3 Evaluación del costo - beneficio
El análisis económico incluye lo que se llama, el análisis o evaluación de costo
– beneficio, significa una valoración de la inversión económica comparado con
Ingeniería en Sistemas Computacionales 74
Planificación y Modelado Planificación del Sistema
los beneficios que se obtendrán en la comercialización y utilidad del producto o
sistema. El análisis económico sirve para [6]:
o Valorar la necesidad de la realización de un proyecto.
o Seleccionar la alternativa más beneficiosa para la realización del
proyecto.
o Estimar adecuadamente los recursos económicos necesarios en el plazo
de realización 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 características
del Sistema. El análisis de costo – beneficio es una fase muy importante de ella
depende la posibilidad de desarrollar o no el proyecto.
Algunos costos y beneficios pueden cuantificarse fácilmente. Los beneficios
que pueden cuantificarse con facilidad son de dos tipos generales: Ahorros en
costos, tales como una disminución en costos de operación y aumentos en las
utilidades directas. Otros ejemplos de beneficios tangibles son [7]:
o Disminución de errores
o Incremento de rentabilidad
o Reducción de costos anteriores (fijos o variables)
Beneficios intangibles aquellos que en el momento del análisis, no se pueden
cuantificar y con frecuencia están relacionados a la calidad de la información
que proporciona el sistema, tales como los listados a continuación:
o Satisfacción en el servicio al cliente
o En las actividades administrativas, mejora en la toma de decisiones
Según la Sociedad Latinoamericana para la Calidad [8], el análisis costo –
beneficio es el proceso de colocar cifras en dólares en los diferentes costos y
Ingeniería en Sistemas Computacionales 75
Planificación y Modelado Planificación del Sistema
beneficios de una actividad. Al utilizarlo, se puede estimar el impacto
financiero acumulado de lo que se pretende lograr.
Cuándo utilizarlo
Al comparar costos y beneficios de las diferentes decisiones. Un análisis de
costo beneficio por si solo puede no ser una guía clara para tomar una buena
decisión. Existen otros puntos que deben ser tomados en cuenta, por ejemplo
la moral de los empleados, la seguridad, las obligaciones legales y la
satisfacción del cliente [6].
Cómo se utiliza
Involucra los siguientes pasos:
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, serán exactos mientras que otros deberán ser
estimados.
3. Sumar los costos totales para cada decisión propuesta.
4. Determinar los beneficios en dólares para cada decisión.
5. Poner las cifras de los costos y beneficios totales en la forma de una
relación 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 solución, en términos financieros es
aquella con la relación más alta beneficios a costos.
2.2.3.1 Métodos para el análisis Costo / Beneficio
Ingeniería en Sistemas Computacionales 76
Planificación y Modelado Planificación del Sistema
Diferentes métodos pueden ser utilizados para calcular la relación costo –
beneficio. Los métodos más sofisticados consideran el tiempo – valor del dinero
como parte del análisis costo beneficio. El tiempo – valor del dinero, también
conocido como el factor de descuento, es simplemente un método utilizado
para convertir el valor futuro del dinero en valor presente (dólares futuros a
dólares presentes). Se basa sobre la premisa de que el dólar de hoy tiene más
valor que un dólar en unos años 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 organización ya que los esfuerzos por
mejorar pueden requerir de compromisos de capital por un periodo de tiempo
prolongado.
Los métodos comunes para el análisis de costo beneficio incluyen:
o Punto de equilibrio
o Periodo de devolución
o Valor presente neto
o 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 más sencillas de hacer el análisis de costo beneficio. El punto de
equilibrio es el tiempo que tomaría para que el total de los ingresos
incrementados y/o la reducción de gastos sea igual al costo total. Sin embargo,
no toman en cuenta el valor del dinero en el tiempo.
Fórmula
PE = (Costo / Total de ingresos incrementados y/o reducción de gastos) x 12
(meses)
Periodo de devolución (payback period exercise)
Ingeniería en Sistemas Computacionales 77
Planificación y Modelado Planificación del Sistema
El periodo de Devolución es el tiempo requerido para recuperar el monto inicial
de una inversión de capital. Este método calcula la cantidad de tiempo que se
tomaría para lograr un flujo de caja positivo igual a la inversión total. Toma en
cuenta beneficios, tales como el valor asegurado. Este método indica
esencialmente la liquidez del esfuerzo por mejorar un proceso en vez de su
rentabilidad. Al igual que el análisis del punto de equilibrio, el análisis del
periodo de devolución no tiene en cuenta el valor del dinero en el tiempo.
Fórmula
PD = [(Costo – Valor Asegurado) / Total de ingresos incrementados y/o
reducción de gastos] x 12 (meses)
Valor presente neto (net present value (NPV))
El NVP representa el Valor Presente (PV) de los flujos salientes de caja menos
la cantidad de la inversión 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 propósito del factor de descuento es
contar el Valor Futuro del dinero en Valor Presente (dólares futuros a dólares
presentes) y se expresa como 1 + la tasa de interés (i).
Fórmula
PV = ((ingresos + Valor Asegurado) / Factor de descuento)
NPV = PV – inversión (I)
Tasa interna de retorno (internal rate of return (IRR))
La tasa interna de retorno es la tasa de interés que hace la ecuación de la
inversión 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.
Ingeniería en Sistemas Computacionales 78
Planificación y Modelado Planificación del Sistema
El resultado análisis del punto de equilibrio, del periodo de devolución y del
cálculo del valor presente neto indicaría 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 interés
(i). en este caso, el factor de descuento es (1 + i) ya que no conocemos el
interés verdadero, solamente conocemos el interés deseado.
Fórmula
PV = ((ingresos + Valor Asegurado) / Factor de descuento)
NPV = PV – inversión (I)
2.3 Estudio de viabilidad
El proceso de ingeniería 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 organización.
Dentro del PU, durante la fase de inicio uno de sus objetivos es la decisión de
proceder o no con el proyecto, es decir, se establece el análisis 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 ¿El sistema contribuye a los objetivos generales de la organización?
o ¿El sistema puede implementarse utilizando la tecnología actual y con
las restricciones establecidas?
o ¿El sistema puede integrarse a otros que existen en la organización?
Llevar a cabo un estudio de factibilidad comprende la evaluación y recolección
de información y la redacción de informes.
Ingeniería en Sistemas Computacionales 79
Planificación y Modelado Planificación del Sistema
A continuación se describen brevemente los tipos de viabilidad desde el punto
de vista, económico, técnico y operativo.
2.3.1 Viabilidad económica
Es una evaluación 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 inversión
económica.
2.3.2 Viabilidad Técnica
Es un estudio de funciones, rendimiento y restricciones que puedan afectar la
realización de un sistema aceptable. Las restricciones además de presupuesto
y tiempo incluyen los recursos humanos, hardware y software. Con este
estudio se determina si con la tecnología existente se puede implementar el
nuevo sistema, o si hay que adquirir nueva tecnología.
2.3.3 Viabilidad operativa
Se trata de averiguar si el nuevo sistema es el adecuado para la organización.
Se necesita saber si el nuevo sistema es flexible y puede integrarse a otros ya
existentes en la organización.
Dentro del PU el objetivo principal de la fase de inicio es establecer la
viabilidad del proyecto, dicho en otras palabras establecer el análisis del
negocio. Esto con el objetivo de decidir si se sigue o no adelante con el
proyecto. Se debe señalar que este análisis se sigue desarrollando en la fase
de elaboración conforme se va recopilando más información [JBR00].
2.4 Planificación de la documentación
Ingeniería en Sistemas Computacionales 80
Planificación y Modelado Planificación del Sistema
Para mantener informado al cliente acerca de los riesgos, de la planificación de
tiempo y de la organización usualmente se hace por medio de un documento
llamado “plan de proyecto”.
El plan del proyecto de software se produce como culminación de la etapa de
planificación. 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
técnico y clientes.
2. Definir los riesgos y sugerir planes de contingencia
3. Definir el costo y el plan temporal para la revisión de la gestión.
4. Proporcionar una aproximación global del desarrollo del software para
toda la gente involucrada en el proyecto.
5. Describir cómo se garantizará la calidad y la gestión de cambios.
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. planificación temporal (se puede utilizar un diagrama de Gantt)
3. organización del equipo del proyecto
4. descripción técnica del sistema propuesto
5. estándares, procedimientos, técnicas y herramientas propuestas
6. plan de calidad
7. plan de gestión de configuración de software
8. plan de documentación
9. plan de gestión de datos (recursos humanos, de hardware y software)
10.plan de gestión de recursos
11.plan de prueba
12.plan de entrenamiento
13.plan de seguridad
14.plan de gestión de riesgo
15.plan de mantenimiento
Ingeniería en Sistemas Computacionales 81
Planificación y Modelado Planificación del Sistema
2.5 Gestión de la configuración del software (GCS)
Los cambios durante el proceso de construcción de un software:
o Son inevitables
o Provocan confusión e incertidumbre
o Pueden ocurrir en cualquier momento
Estos cambios aumentan conforme avanza el tiempo. La primera ley de
ingeniería 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 gestión de configuración del software.
“El arte de coordinar el desarrollo de software para minimizar…la confusión, se
denomina gestión de la configuración. La gestión es el arte de identificar,
organizar y controlar las modificaciones que sufre el software…la meta es
maximizar la productividad minimizando errores.” Babich [BAB86].
De acuerdo con Pressman [PRE02], las actividades de GCS sirven para:
o Identificar el cambio de nuestro software.
o Controlar ese cambio.
o Garantizar que el cambio quede bien implantado.
o Informar el cambio.
La GCS no es un mantenimiento del software, el mantenimiento es la etapa
final de la ingeniería 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 sólo una vez que el
software queda fuera de circulación.
Ingeniería en Sistemas Computacionales 82
Planificación y Modelado Planificación del Sistema
¿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 Nuevos requisitos del negocio o condiciones que dictan los cambios en
las condiciones del producto o en las normas comerciales.
o Nuevas necesidades del los clientes que demandan la modificación de
los datos producidos por un sistema basado en computadora.
o Reorganización y/o reducción del volumen comercial que provoca
cambios en las prioridades del proyecto o en la estructura del equipo de
ingeniería del software.
o Restricciones presupuestarias o de planificaciones que provocan una
redefinición del sistema o del producto.
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 estándares para administrar un producto de software
evolutivo.
Línea base
Una línea base es un concepto de gestión de configuración del software que
nos ayuda a controlar los cambios sin impedir seriamente los cambios
justificados.
La IEEE define una línea base como: Una especificación 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 través de
procedimientos formales de control de cambios.
Una forma de describir la línea base es mediante una analogía. 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
Ingeniería en Sistemas Computacionales 83
Planificación y Modelado Planificación del Sistema
que hacen que solo se puedan abrir en la dirección 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
rápidamente 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 algún error.
2) Disculparse insistentemente.
3) Volver a la cocina por la puerta de entrada.
4) Explicar el problema etc.
Una línea base es análoga a un plato mientras pasa por las puertas de la
cocina de un restaurante antes de que un elemento de configuración del
software se convierta en línea base, el cambio se puede llevar a cabo rápida e
informalmente. Sin embargo, una vez que se establece una línea 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 ingeniería del software se define una línea base como un
punto de referencia en el desarrollo del software y que queda marcado por el
envío de uno o más elementos de configuración del software (ECS) y la
aprobación de ECS obtenido mediante una revisión técnica formal. Por ejemplo,
los elementos de una especificación de diseño 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 especificación de
diseño se convierte en línea base. Solo se pueden realizar cambios futuros en
la arquitectura del software (contenidos en la especificación del diseño) tras
haber sido evaluados y aprobados. Aunque se puedan definir las líneas base
con cualquier nivel de detalle las líneas base más comunes son las que se
muestran en figura 2.5.1
Ingeniería en Sistemas Computacionales 84
Planificación y Modelado Planificación del Sistema
Fig. 2.5.1 Línea Base
Elemento de configuración de software
Los elementos de configuración del software ECS son cualquier documento,
especificación, conjunto completo de casos de prueba etc. que se crea durante
el desarrollo del software. Un elemento de configuración 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 configuración. 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 versión original.
Los ECS se organizan como objetos de configuración 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
configuración, cada objeto esta relacionado con otro, si se lleva a cabo un
cambio sobre un objeto la interrelaciones señalan a que otros objetos afectará.
Ingeniería en Sistemas Computacionales 85
Planificación y Modelado Planificación del Sistema
Fig. 2.5.2 modelo de datos de la GCS
2.5.1 Planificación de la GCS
De acuerdo con Sommerville [SOM00], la planificación de la GCS empieza
durante las primeras fases del proyecto y debe definir el o los documentos que
se controlarán. Aquellos documentos que puedan requerirse para el futuro
mantenimiento del software, deberán ser identificados y especificados como
documentos de control.
El plan de la GCS incluye:
1. La identificación de los ECS, donde se controlan los cambios y se decide
qué documentos (o tipo de documentos) se van a controlar, tales como:
o planes del proyecto
o especificaciones
o diseños
o programas
Ingeniería en Sistemas Computacionales 86
Planificación y Modelado Planificación del Sistema
o resultados de las pruebas, etc.
Por lo general no se controlarán documentos de trabajo, informes internos,
propuestas, etc.
2. La asignación de responsabilidades. Después de identificar los ECS se
decide quién se encarga de los procedimientos de la GCS y quién se
encarga de la creación de las líneas base.
3. Las políticas de la GCS dadas dentro de una organización son para
controlar los cambios y versiones apoyando por herramientas CASE.
4. La definición de archivos de la GCS que deben ser controladas.
5. La definición de la base de datos, que registra toda la información
relevante relacionada con las configuraciones, ayuda a la evaluación del
impacto de los cambios en el sistema y proveer información sobre el
proceso de la GCS. Esta información debe permitir hacer las siguientes
consultas:
o Los clientes a los que se ha entregado una versión en particular
o Las configuraciones de hardware y sistema operativo necesarias para
cada versión
o El número de versiones se han creado y fechas de creación
o El número de peticiones de cambio pendientes de una versión concreta
o El número de fallos reportados existentes para una versión en particular,
etc.
6. Puede incluir información de software externo, proceso de auditoría, etc.
2.5.2 El proceso de gestión de la configuración del software
Ingeniería en Sistemas Computacionales 87
Planificación y Modelado Planificación del Sistema
De acuerdo con Pressman [PRE02], la GCS es un elemento importante de
garantía de calidad es responsable de controlar los cambios. Sin embargo
también se debe identificar los ECS individuales. El proceso se puede definir en
cinco tareas de GCS:
1. Identificación
2. Control de versiones
3. Control de cambios
4. Auditorias de configuración
5. Generación de informes
2.5.3.1 Identificación de objetos en la GCS
Se pueden identificar dos tipos de objetos los objetos básicos y los objetos
compuestos. Un objeto básico es una unidad de texto creada durante el
análisis, diseño, codificación o prueba. Un objeto compuesto es una colección
de objetos básicos u objetos compuestos. Cada objeto tiene un conjunto de
características que los identifican como únicos:
o El nombre del objeto es una cadena de caracteres que identifica al
objeto sin ambigüedad.
o La descripción 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 Un identificador del proyecto
o La información de la versión y/o el cambio.
El esquema de identificación de los objetos de software debe tener en cuenta
que los objetos evolucionan a lo largo del proceso de ingeniería, por lo que se
Ingeniería en Sistemas Computacionales 88
Planificación y Modelado Planificación del Sistema
puede crear un grafo de evolución ejemplificado en la figura 2.5.3.1.
Fig. 2.5.3.1 grafo de evolución
En el grafo de evolución se describe la historia del objeto y sus cambios, las
grandes modificaciones hacen que un objeto cambie, por lo que cambia el
número de versión principal.
2.5.3.2 Control de versiones
El control de versiones combina procedimientos y herramientas para gestionar
las versiones de los objetos de configuración creadas durante el proceso de
ingeniería del software. Clemm describe el control de versiones en el contexto
de la GCS.
"La gestión de configuración permite a un usuario especificar configuraciones
alternativas del sistema de software mediante la selección de las versiones
adecuadas. Esto se puede gestionar asociando atributos a cada versión del
software y permitiendo luego especificar y construir una configuración
describiendo el conjunto de atributos deseado."
Los atributos pueden ser tan sencillos como un número específico de versión
asociado a cada objeto o tan complejos como una cadena de variables lógicas
que especifiquen tipos de cambios funcionales aplicados al sistema.
Ingeniería en Sistemas Computacionales 89
Planificación y Modelado Planificación del Sistema
Ejemplo: En la figura 2.5.4.2 ilustra una versión de un sencillo programa que
está formada por los componentes 1, 2, 3, 4 y 5. El componente 4 sólo se usa
cuando el software se implementa para monitores de color, y el 5 cuando se
dispone de un monitor monocromático, por lo tanto se pueden definir dos
variantes de la versión:
o Componentes 1, 2, 3 y 4
o componentes 1, 2, 3 y 5
Fig. 2.5.4 .2 grafo de versiones y variantes
Para construir la variante adecuada de una determinada versión de un
programa, a cada componente se le asigna una tupla de atributos (lista de
características que definen si se utilizará un componente, par determinada
versión del software). A cada variante se le asigna uno o más atributos. Otra
forma de establecer los conceptos de la relación entre componentes, variantes
y versiones es representarlas como un fondo de objetos
Otra forma de establecer los conceptos de relación entre componentes
variantes y versiones es como un fondo de objetos [REI89]. La figura 2.5.4.3
Ingeniería en Sistemas Computacionales 90
Planificación y Modelado Planificación del Sistema
representa de los objetos, sus componentes, variantes y versiones. La principal
diferencia entre los distintos enfoques está en la sofisticación de los atributos
que se usan para construir versiones y variantes específicas de un sistema y en
la mecánica del proceso de construcción.
Fig. 2.5.4.3 representación 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
rápidamente al caos. El control de cambios combina los procedimientos
humanos y las herramientas automáticas para proporcionar un mecanismo
para el control de cambio mostrado en la figura 2.5.5.1.
Ingeniería en Sistemas Computacionales 91
Planificación y Modelado Planificación del Sistema
Fig. 2.5.5.1 Proceso de control de cambios
Los resultados de la evaluación 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
ingeniería (OCI) La OCI describe el cambio a realizar, las restricciones
que se deben respetar y los criterios de revisión 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.
Ingeniería en Sistemas Computacionales 92
Planificación y Modelado Planificación del Sistema
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 versión del software.
Los procedimientos de "alta" y "baja" implementan dos elementos
importantes del control de cambios: control de acceso y control de
sincronización.
o El control de acceso gobierna los derechos de los ingenieros de
software a acceder y modificar objetos de configuración
concretos.
o El control de sincronización 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 sincronización
Antes de que un ECS se convierta en una línea base, sólo es necesario aplicar
un control de cambios informal. El que haya desarrollado el ECS en cuestión
podrá hacer cualquier cambio justificado por el proyecto y por los requisitos
Ingeniería en Sistemas Computacionales 93
Planificación y Modelado Planificación del Sistema
técnicos. Una vez que el objeto ha pasado la revisión técnica formal y ha sido
aprobada, se crea la línea base.
Una vez que el ECS se convierte en una línea base, aparece el control de
cambios a nivel de proyecto. Para hacer un cambio, el encargado del desarrollo
debe recibir la aprobación 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 evaluación de cada cambio así como un
seguimiento y revisión 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) desempeña un papel activo en el
segundo y tercer nivel de control. El papel de la ACC es el de tener una visión
general, o sea, evaluar el impacto del cambio fuera del ECS en cuestión y de
plantear las siguientes cuestiones y muchas otras más:
o ¿Cómo impactará el cambio en el hardware?
o ¿Cómo impactará en el desempeño?
o ¿Cómo alterará el cambio la percepción del cliente sobre el producto?
2.5.3.4 Auditoria de la configuración
¿Cómo podemos asegurar que el cambio se ha implementado correctamente?
La respuesta es doble:
1) revisiones técnicas formales y
2) auditorias de configuración del software.
Las revisiones técnicas formales se centran en la corrección técnica del
elemento de configuración que ha sido modificado. Los revisores evalúan el
ECS para determinar la consistencia con otros ECS, las omisiones o los posibles
efectos secundarios.
Ingeniería en Sistemas Computacionales 94
Planificación y Modelado Planificación del Sistema
Una auditoria de configuración del software complementa la revisión técnica
formal al comprobar características que generalmente no tiene en cuenta la
revisión. 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 revisión técnica formal para evaluar la
corrección técnica?
3. ¿Se han seguido adecuadamente los estándares de ingeniería 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
configuración?
5. ¿Se han seguido procedimientos del GCS para señalar el cambio,
registrarlo y divulgarlo?
6. ¿Se han actualizado adecuadamente todos los ECS relacionados?
En algunos casos las preguntas anteriores se incluyen en la revisión técnica
formal, pero cuando la GCS es formal la auditoría se lleva a cabo de manera
independiente por el grupo encargado de garantizar la calidad.
2.5.3.5 Informes de estado
La generación de informes de estado de la configuración es una tarea de GCS
que responde a las siguientes preguntas:
1) ¿Qué pasó?
2) ¿Quién lo hizo?
3) ¿Cuándo pasó?
4) ¿Que más se vio afectado?
La generación de informes de estado de la configuración desempeña un papel
vital en el éxito del proyecto de desarrollo de software. Cuando aparece
involucrada mucha gente es muy fácil que no exista una buena comunicación.
Ingeniería en Sistemas Computacionales 95
Planificación y Modelado Planificación del Sistema
Pueden darse errores entre las personas desarrolladoras del software. El IEC
ayuda a eliminar esos problemas, mejorando la comunicación entre todas las
personas involucradas [PRE02].
Para trabajo de la Unidad II, deberán 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.planificación temporal (se puede utilizar un diagrama de Gantt)
18.organización del equipo del proyecto
19.descripción técnica del sistema propuesto
20.estándares, procedimientos, técnicas y herramientas propuestas
21.plan de calidad
22.plan de gestión de configuración de software
23.plan de documentación
24.plan de gestión de datos (recursos humanos, de hardware y software)
25.plan de gestión de recursos
26.plan de prueba
27.plan de entrenamiento
28.plan de seguridad
29.plan de gestión de riesgo
30.plan de mantenimiento
Ingeniería en Sistemas Computacionales 96