Unidad II Planif y Modelado

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


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



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.



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.



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)



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



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



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:



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



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



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á:



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.



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.



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.



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.



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



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.



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.



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.



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



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


http://www.monografias.com/trabajos11/metods/metods.shtml

http://www.monografias.com/trabajos12/pmbok/pmbok.shtml

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


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


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


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


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


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



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.


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


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



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.


http://www.monografias.com/trabajos14/propiedadmateriales/propiedadmateriales.shtml

http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml


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


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


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


http://www.monografias.com/trabajos12/higie/higie.shtml#tipo

http://www.monografias.com/Fisica/index.shtml


= 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



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



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.



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:



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



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:



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.



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.



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



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?



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:



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



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.



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)



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:



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.



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



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.



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.



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)



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



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.



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.


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)


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.



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



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.



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



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?



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



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



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



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)



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.



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.



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



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



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.



¿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



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



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



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



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



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



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.



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



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.



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.



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



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.



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.



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


Unidad II Planif y Modelado

Documents

Transcript of Unidad II Planif y Modelado