12

Mircoles 30 de mayo

Unidad 5: Evaluacin general

de Organizaciones de Archivos
Jess Oscar Molina Alvarado

No. Ctrl: 10550372

I n s t i t u t o Te c n o l g i c o d e C h i h u a h u a I I

Estimacin del uso del sistema

Modelos de Estimacin
Lneas de cdigo
La mtrica de tamao tradicional para estimar el esfuerzo de desarrollo y
productividad ha sido LOC (Lines Of Code) o SLOC (Source Lines Of Code). Se
han propuesto varios modelos de estimacin, la mayora de ellos son funciones de
las lneas de cdigo o de las miles de lneas de cdigo que tendr el software a
desarrollar. Generalmente, el modelo de estimacin de esfuerzo consiste de dos
partes. La primera provee una base de estimacin como una funcin del tamao
del software, y es de la siguiente forma:

donde E es el esfuerzo estimado en meses hombre, A, B y C son constantes y

KLOC es el tamao estimado del sistema final en miles de lneas de cdigo. La
segunda parte del modelo modifica esta estimacin en base a cuantificar la
influencia de factores de ambiente, por ejemplo la utilizacin de diferentes
metodologas, habilidad del equipo de desarrollo y restricciones de hardware.
La definicin de KLOC es importante si se quiere comparar los distintos modelos
que se han propuesto en la literatura. Algunos de ellos incluyen lneas de
comentarios, y otros no. Del mismo modo, la definicin del esfuerzo estimado E es
tambin importante., ya que E puede representar slo el esfuerzo de codificacin,
o en el otro extremo, el esfuerzo total del anlisis, diseo, codificacin, test y
mantencin. Por estas razones, comparar estos modelos se torna complejo.
Los principales problemas de utilizar lneas de cdigo como mtrica para
estimacin del esfuerzo son la falta de una definicin universal de lnea de cdigo,
su dependencia con el lenguaje de desarrollo y la dificultad de estimar en fases
tempranas del desarrollo la cantidad de lneas que tendr una aplicacin.
Puntos de funcin
El anlisis por puntos de funcin es un mtodo para cuantificar el tamao y la
complejidad de un sistema software en trminos de las funciones de usuario que
este desarrolla (o desarrollar). Esto hace que la medida sea independiente del
lenguaje o herramienta utilizada en el desarrollo del proyecto.
El anlisis por puntos de funcin est diseado para medir aplicaciones de
negocios; no es apropiado para otro tipo de aplicaciones como aplicaciones
tcnicas o cientficas. Esas aplicaciones generalmente median con algoritmos
complejos que el mtodo de puntos de funcin no est diseado para manejar.
El enfoque de puntos de funcin tiene caractersticas que permiten superar los
principales problemas de utilizar lneas de cdigo como mtrica del tamao del
software. Primero, los puntos de funcin son independientes del lenguaje,
herramientas o metodologas utilizadas en la implementacin; por ejemplo, no
tienen que considerar lenguajes de programacin, sistemas de administracin de
bases de datos, hardware, o cualquier otra tecnologa de procesamiento de datos.

Segundo, los puntos de funcin pueden ser estimados a partir de la especificacin

de requisitos o especificaciones de diseo, haciendo posible de este modo la
estimacin del esfuerzo de desarrollo en etapas tempranas del mismo. Como los
puntos de funcin estn ntimamente relacionados con la declaracin de
requisitos, cualquier modificacin a sta, puede ser reflejada sin mayor dificultad
en una re estimacin.
Tercero, como los puntos de funcin estn basados en una visin externa del
usuario del sistema, los usuarios no tcnicos del software poseen un mejor
entendimiento de lo que los puntos de funcin estn midiendo. El mtodo resuelve
muchas de las inconsistencias que aparecen cuando se utiliza lneas de cdigo
como mtrica del tamao del software.
En resumen, los puntos de funcin aparecen con ventajas substanciales por sobre
las lneas de cdigo, para fines de estimacin temprana del tamao del software, y
por ende, del esfuerzo de desarrollo. Adems es una medida ampliamente
utilizada, y con xito, en muchas organizaciones que desarrollan software en
forma masiva.
Puntos de Caracterstica.
Debido a que el anlisis por Puntos de Funcin fue diseado para software de
negocios y no es fcil de generalizar a aplicaciones cientficas, de tiempo real y
otras, Caper Jones propuso ampliaciones a este mtodo, generando una mtrica
que denomin Puntos de Caracterstica. sta da cabida a aplicaciones cuya
complejidad algortmica es alta.
Este mtodo considera los mismos elementos que considera Albrecht en su
anlisis por puntos de funcin, slo que aade la variable "nmero de algoritmos"
y elimina los niveles de complejidad, as, cada cuenta es pesada por un valor
nico para ese componente (es decir, se le asigna complejidad media).
3. Estimacin Temprana del Tamao del Software.
Para realizar la planificacin de un proyecto software, es necesario poseer una
estimacin certera del esfuerzo necesario para el desarrollo lo ms temprano
posible, idealmente, con slo la etapa de especificacin de requisitos cubierta.
Se tiene que a esta altura del desarrollo del software, difcilmente se puede
realizar una estimacin certera de la cantidad de lneas de cdigo que tendr la
aplicacin, ya que en este nivel no tiene por qu estar decidida la herramienta de
desarrollo. Slo se podra entrar a realizar una estimacin certera en los
comienzos de la etapa de construccin, con un diseo acabado. Por otro lado, la
determinacin de los Puntos de Funcin podra realizarse a partir de la
especificacin de requisitos, pero los factores correctores segn la complejidad de
la aplicacin pueden estimarse con certeza una vez que se ha entrado de lleno a
la etapa de diseo. Si bien es posible realizar la estimacin de puntos de funcin
en fases anteriores que la estimacin de LDC, se deseara poder realizar una
estimacin certera en base nicamente a la especificacin de requisitos.
De una "buena" especificacin de requisitos se pueden obtener las caractersticas
de la aplicacin a desarrollar, antes de que comience el desarrollo del software. Si
a partir de estas caractersticas se puede obtener una estimacin del tamao del
software, se tendra una estimacin temprana del tamao del mismo.

De este modo, al contar con una estimacin temprana del tamao de lo que se
desea desarrollar, se puede realizar una estimacin del esfuerzo en etapas
tempranas del desarrollo. Esto es debido a que el tamao del software es la
variable manejadora de costo principal del desarrollo.
Una estimacin temprana sera til para generar la planificacin del proyecto, la
cual podra corregirse con el apoyo de las tcnicas basadas en los puntos de
funcin o lneas de cdigo en etapas ms avanzadas del desarrollo.
4. Mtrica para Estimacin Temprana del Tamao del Software.
Para poder realizar una estimacin temprana, se propone la utilizacin de la
mtrica de puntos de funcin modificada.
Este mtodo consiste en clasificar, listar y contar a partir de la especificacin de
requisitos todos los componentes, desagregados en:
a. Entradas Externas.
b. Salidas Externas
c. Archivos Lgicos
d. Consultas.
En el mtodo original adems se consideraba la clasificacin Archivos de
Interfaces externos, los cuales son utilizados para la comunicacin entre
aplicaciones. Debido a que a esta altura del desarrollo difcilmente se puede
contar con esta informacin, se ha eliminado. En caso de ser obvia la necesidad
de contar con un archivo de interface, ste debe cuantificarse como un archivo
lgico ms.
Para resolver el problema de determinar la complejidad asociada a cada
componente de la aplicacin (difcil de conocer en esta etapa), se ha optado por
asignar a todos los componentes una complejidad promedio. Esta es una
aproximacin vlida, debido a que normalmente "en media" las aplicaciones son
de complejidad promedio, teniendo slo unos pocos componentes de complejidad
simple y otros complejos.
De este modo, la frmula para obtener los puntos de funcin para estimacin
temprana (PFET) es la siguiente:

Donde
PFET : Puntos de funcin para estimacin temprana.
IN : Nmero de Entradas Externas
OUT : Nmero de Salidas Externas
INQ : Nmero de Consultas
FILE : Nmero de Archivos Lgicos
ACP : Factor de Ajuste de Complejidad de Proceso
5. Obtencin de un Modelo Emprico
Para obtener un modelo emprico de estimacin del esfuerzo, es necesario contar
con registros de proyectos concluidos, con sus tamaos estimados en puntos de
funcin para estimacin temprana y el esfuerzo de desarrollo (sin incluir puesta en
marcha ni mantenimiento) medido en horas hombre.

En este proyecto, se utiliza el modelo propuesto en [1], ya que se cuenta con los
datos de los proyectos desde los cuales se obtuvo el modelo, sus tamaos estn
medido en la medida de Puntos de Funcin para estimacin temprana y la medida
del esfuerzo corresponde a la que se utilizar en este proyecto. Con estos
antecedentes, se le puede adaptar a la organizacin una vez que se cuente con
informacin acerca de proyectos terminados.
Con respecto a la obtencin del modelo, se utilizarn herramientas de la inferencia
estadstica, que se especifican en [11].
Mtodo de Regresin Lineal.
Se han de registrar datos de Esfuerzo y Tamao de proyectos concluidos. En base
a estos registros se obtendr un modelo de la forma
Esfuerzo = f (tamao del software)
donde el esfuerzo es medido en horas hombre, y el tamao del software est
medido en puntos de funcin para estimacin temprana.
Para fines estadsticos, hay que notar que la variable predictora o independiente
es el tamao del software, y la variable respuesta o dependiente es el esfuerzo de
desarrollo.
As, el esfuerzo E es funcin del tamao T, de la forma
Esta ecuacin corresponde a un modelo de regresin lineal simple, donde los
parmetros a y b quedan determinados por:

donde n es el nmero de registros, Ti es el registro i-simo del tamao y Ei es el

registro i-simo del esfuerzo.

Anlisis de los beneficios del sistema

Los beneficios tangibles son las ventajas econmicas cuantificables que obtiene la
organizacin a travs del uso del sistema de informacin. Ejemplo de beneficios
tangibles seran:
1. El incremento en la velocidad de proceso
2. Contar con cierta informacin que de otra manera seria inaccesible

3. La obtencin de informacin con mayor puntualidad que en el pasado

4. Aprovechar el mayor poder de clculo de las computadoras
5. Reducir el tiempo requerido por los empleados para concluir una tarea
especifica
Aunque la medicin no siempre es fcil los beneficios tangibles pueden estimarse
en trminos de pesos, recursos o tiempo ahorrados.
Algunos de los beneficios que la organizacin obtiene a travs de un sistema de
informacin son difciles de cuantificar, pero no por ello dejan de ser importantes. A
stos se les conoce como beneficios intangibles. Los beneficios intangibles
incluyen:
1.
2.
3.
4.
5.

La mejora del proceso de toma de decisiones

El incremento de precisin
El llegar a ser ms competitivo en los servicios al cliente
El mejoramiento de la imagen del negocio
El incremento de la satisfaccin de los empleados al eliminar tareas de
naturaleza tediosa.
Los beneficios intangibles son extremadamente importantes y pueden tener
implicaciones de relevancia para el negocio, en su relacin con personas tanto
ajenas como propias de la organizacin. Aunque los beneficios intangibles del
sistema de informacin son elementos importantes para decidir si se procede o no
con su implantacin, un sistema soportado exclusivamente por beneficios
intangibles no tendr xito.

Comparacin entre costo y beneficio

Los costos y los beneficios del sistema propuesto de cmputo siempre deben
considerarse en conjunto, ya que se interrelacionan y con frecuencia dependen
entre s. Aunque los analistas de sistemas proponen un sistema que satisfaga los
requerimientos de manejo de la informacin, la decisin para continuar con la
propuesta del sistema se basar en el anlisis de los costos y los beneficios y no
en los requerimientos de informacin. Muchas veces los beneficios se miden por
su costo.
Los analistas de sistemas deben predecir ciertas variables fundamentales. En
cierta forma, un analista de sistemas har uso de una simulacin, pero no puede
confiar en el anlisis de simulacin para todo, si desea que su propuesta sea
creble, significativa y trascendente. El analista de sistemas cuenta con numerosos
modelos de pronsticos. La condicin principal es la disponibilidad de datos
histricos. Si no se dispone de ellos, el analista debe seleccionar alguno de los
mtodos de criterio como la estimacin de la fuerza de ventas, encuestas que
estimen la demanda del cliente, estudios Delphi (un pronstico de consenso que
se desarrolla de manera independiente por un grupo de expertos a travs de una
serie de iteraciones), la creacin de escenarios o la elaboracin de analogas
histricas. Si se cuenta con datos histricos, la siguiente diferenciacin entre las

diversas tcnicas implicar definir si el pronstico es condicional o no condicional.

Un pronstico condicional implica que hay una asociacin entre variables en el
modelo o que existe una relacin causal. El pronstico no condicional implica que
el analista no requiere encontrar o identificar una relacin causal.
Cuando se cuenta con datos histricos cuantitativos, el analista de sistemas puede
estimar tendencias futuras. El analista debe considerar datos relevantes y grficos
para determinar si existe cierta tendencia. Hay tres tendencias comunes como
son: lineal, estacional y cclica. Los comportamientos fluctuantes tambin se
identifican como tendencias estacinales si se repiten anualmente. Si el patrn se
repite regularmente, pero no anualmente, constituye una tendencia cclica. El
analista deber identificar el tipo de tendencia cuando estime la demanda, la carga
de trabajo y los factores econmicos.
Las tendencias pueden estimarse de diferentes maneras. Las tcnicas de mayor
uso son:
Evaluacin grfica
Mtodo de mnimos cuadrados
Mtodo de promedios mviles.
Los costos y los beneficios pueden ser tanto de naturaleza tangible como
intangible. Ambos deben tomarse en cuenta en las propuestas de los sistemas.