Planeación de Proyectos Hipermedia. Estimación de costos

2. Técnicas de
   estimación
3. Métricas de
   estimación para software hipermedia
4. Conclusión
5. Bibliografía
6. Anexo

Introducción

La administración efectiva de un proyecto de
software depende
de planear completamente el progreso del proyecto. El
administrador
del proyecto debe anticiparse a los problemas que
podrían surgir, así como preparar soluciones
tentativas a esos problemas.

La planeación
es un proceso
iterativo que solamente se completa cuando el proyecto mismo se
termina. Conforme la información se hace disponible, el plan debe
revisarse regularmente. Las metas globales del negocio son un
factor importante que debe considerarse cuando se formula el
plan del
proyecto. Conforme esto cambie, los cambios en el proyecto
serán necesarios.

El proceso de
planeación del proyecto inicia con una
valoración de las restricciones que afectan el proyecto
(fecha de entrega requerida, personal
disponible, presupuesto
global, etc.). Ésta se lleva a cabo con una
estimación de los parámetros del proyecto como su
estructura,
tamaño y distribución de funciones.
Entonces se definen los hitos de progreso y productos a
entregar. En ese momento, el proceso entra en un ciclo. Se
prepara un calendario para el proyecto y las actividades
definidas en el calendario inician o continúan.
Después de algún tiempo (por lo
general 2 o 3 semanas), se revisa el proyecto y señalan
las discrepancias. Debido a que las estimaciones iniciales de los
parámetros del proyecto son tentativas, el plan siempre
deberá actualizarse.

Las estimaciones están asociadas con el esfuerzo
y el tiempo con las
actividades identificadas del proyecto. Los administradores del
proyecto deben estimar las respuestas a las siguientes
preguntas:

1. ¿Cuánto esfuerzo (personal
   necesario) se requiere para completar una
   actividad?
2. ¿Cuánto tiempo se necesita para
   completar una actividad?
3. ¿Cuál es el costo total
   de una actividad?

La estimación y la realización del
cronograma del proyecto se llevan a cabo de forma conjunta. Sin
embargo, en las primeras etapas del proyecto se requieren algunas
estimaciones de costos, antes que
se tenga el cronograma detallado. Estas estimaciones son
necesarias para establecer un presupuesto para
el proyecto o para asignar un precio para el
software de un
cliente.

Una vez que el proyecto se comienza a ejecutar, las
estimaciones se actualizan de forma regular. Esto ayuda al
proceso de planeación y permite la utilización
efectiva de los recursos. Si el
gasto real es significativamente más grande que las
estimaciones, entonces el administrador del
proyecto debe tomar algunas acciones.
Éstas pueden ser: solicitar recursos
adicionales para el proyecto o modificar el trabajo a
realizar.

Existen tres parámetros involucrados en el
cálculo
del costo total de un
proyecto de desarrollo de
software:

• los costos de
  hardware y
  software, incluyendo el mantenimiento;
• los costos de viajes y
  capacitación;
• los costos de esfuerzo (los costos de pago a los
  ingenieros de software).

Para muchos proyectos, el
costo dominante es el costo del esfuerzo. Las computadoras
que son suficientemente poderosas como para desarrollar el
software son relativamente baratas. Aunque los costos de viajes pueden
ser importantes si un proyecto se desarrolla en sitios distintos,
son relativamente bajos para muchos proyectos. Además, el
uso de correo
electrónico, los chat, fax y
teleconferencias reduce los viajes requeridos.

Los costos del esfuerzo no son simplemente los
relacionados a los salarios de los
ingenieros de software involucrados en el proyecto. Las organizaciones
calculan los costos de esfuerzo en función de
los costos de sobrecarga donde se toma en cuenta el costo total
de hacer funcionar la
organización y dividen éste entre el
número de personas productivas. Por lo tanto, los
siguientes costos son parte de los costos de esfuerzo
totales:

1. los costos de proveer, calentar e iluminar las
   oficinas;
2. los costos del personal de apoyo como los contadores,
   secretarias, limpiadores y técnicos;
3. los costos de las redes y comunicaciones;
4. los costos de los recursos centralizados como las
   bibliotecas,
   los recursos recreativos, etc.;
5. los costos de seguridad
   social y de beneficio de empleados como las pensiones y los
   seguros de
   salud.

Debido a las consideraciones organizacionales
involucradas, asignar precio del
proyecto por lo general le concierne al administrador principal
de la organización, así como a los
administradores del proyecto de software.

El proceso de desarrollo de
aplicaciones hipermedia al igual que el de cualquier producto de
software, requiere la aplicación de métricas de
estimación para garantizar resultados más precisos
en su ciclo de
vida.

El objetivo de
este trabajo es investigar acerca de las técnicas
de estimación que existen para los productos
hipermedia, presentando métricas para estimación de
costos dadas por varios autores de artículos,
especialistas en el asunto de aplicaciones hipermedia y web.

1. Técnicas
de estimación

No existe una forma simple de calcular el esfuerzo
requerido para desarrollar un sistema
informático. Las estimaciones iniciales se hacen bajo la
base de la definición de requisitos de usuario de alto
nivel.

Pero en una primera etapa del proyecto es difícil
producir una estimación precisa de los costos de
desarrollo del sistema.

Por ese motivo la estimación se utiliza para
definir si el presupuesto del proyecto y el producto se
ajusta para que las cifras del presupuesto se cumplan. No se
conocen informes de
experimentos
controlados sobre los costos de los proyectos donde los costos
estimados no se utilicen para ajustar el experimento. Un
experimento controlado no revelaría la estimación
del costo al administrador del proyecto. Los costos reales
tendrían que compararse con los estimados del
proyecto.

A pesar de esto, las organizaciones
necesitan calcular esfuerzos de software y estimaciones de los
costos. Para hacerlo, se utilizan una o más de las
técnicas descritas en la tabla 1 (Boehm, 1981).

Estos enfoques para la estimación del costo se
pueden abordar utilizando enfoque descendente o ascendente. Un
enfoque descendente inicia en el nivel de sistema. La
estimación comienza examinando la funcionalidad total del
producto y cómo es que esa funcionalidad se propaga al
interactuar con las subfunciones. Se toman en cuenta los costos
de las actividades del nivel del sistema tales como la integración, la
administración de la configuración y la
documentación.

El enfoque ascendente, en contraste, inicia en el nivel
de componente. El sistema se divide en componentes y se calcula
el esfuerzo requerido para desarrollar cada uno de éstos.
Estos costos se suman para dar el esfuerzo requerido del
desarrollo del sistema completo.

Las desventajas del enfoque descendente son las ventajas
del ascendente y viceversa. La estimación descendente
subestima los costos de resolver problemas técnicos
difíciles asociados con componentes específicos
como las interfaces para hardware no estándar.
No existe justificación detallada de la estimación
que se produce. En contraste, la estimación ascendente
produce tal justificación y considera cada componente. Sin
embargo, este enfoque tiende a subestimar los costos de las
actividades del sistema como la integración. La estimación
ascendente también es más costosa. Debe haber un
diseño
inicial del sistema para identificar los componentes a
evaluar.

Tabla 1 – Técnicas de estimación de
costos

Cada técnica de estimación tiene sus
propias fortalezas y debilidades. Para proyectos grandes, se
deben utilizar varias técnicas de estimación de
costos y comparar sus resultados. Si éstos predicen costos
radicalmente diferentes, esto indica que no se tiene suficiente
información para generar los costos. Se debe buscar
más informaciones y repetir el proceso hasta que la
estimación converja.

Estas dos técnicas de estimación son
aplicables cuando existe un documento de requisitos para el
sistema. Éste define a todos los usuarios y los requisitos
del sistema. Por lo tanto, se puede generar una estimación
razonable de la amplitud de la funcionalidad del sistema a
desarrollar. En general, los proyectos grandes de ingeniería
de sistemas normalmente tendrán tal documento de
requisitos.

Sin embargo, en muchos casos, los costos de muchos
proyectos se tienen que estimar utilizando solamente un borrador
de solicitudes del usuario del sistema. El análisis y la especificación de
requisitos son costosos y los administradores de la
compañía necesitan de una estimación inicial
del costo del sistema antes de que puedan generar un presupuesto
aprobado para este proceso.

Bajo estas circunstancias, "asignar costos para ganar"
es una estrategia
utilizada comúnmente. La noción de "asignar
precios para
ganar" parece no ser ética y
poco apropiada para los negocios. Sin
embargo, tiene algunas ventajas. Un costo del proyecto se acuerda
en base a un borrador de la propuesta. Entonces, las
negociaciones se llevan a cabo con el cliente para determinar una
especificación detallada del proyecto. Esta
especificación se restringe por el costo acordado. El
comprador y el vendedor deben acordar la funcionalidad aceptable
del sistema. El factor clave en muchos proyectos no son los
requisitos del proyecto, sino el costo. Los requisitos se cambian
de tal forma que no se exceda el costo.

Cuando se estiman los costos de software, los
administradores deben tomar en cuenta que existen diferencias
importantes entre los proyectos anteriores y los futuros. Una
gran variedad de nuevos métodos y
técnicas de desarrollo han aparecido en los últimos
diez años. Muchos administradores tienen poca experiencia
en estas técnicas o poco conocimiento
de cómo éstas afectan los costos de los proyectos.
Algunos ejemplos de los cambios que afectan las estimaciones de
acuerdo con la experiencia son:

• Desarrollo orientado a objetos en lugar de desarrollo
  orientado a funciones;
• Sistemas cliente-servidor en
  lugar de sistemas
  basados en "mainframes";
• Utilización de componentes de software
  comerciales en lugar de desarrollo de componentes;
• Desarrollar y reutilizar en lugar de desarrollar
  todas las partes del sistema;
• La utilización de herramientas
  CASE (Ingeniería
  de Software Asistida por Computadora)
  y generadores de programas en
  lugar de desarrollar software sin ayuda.

Todos estos factores hacen más difícil que
los administradores produzcan estimaciones precisas de los
costos de
producción del software. Su experiencia previa no es
relevante para ayudarles a estimar los costos del proyecto de
software.

2. Métricas de estimación para
software hipermedia

Un proyecto hipermedia reúne diversos
profesionales con distinta formación, interés y
visión, tales como ingenieros, diseñadores,
publicistas, fotógrafos,
escritores, locutores, productores, artistas, programadores,
psicólogos, etc. Todos tienen su propio lenguaje
técnico, sus propias prioridades y cada uno debe usar
herramientas
ad hoc a sus funciones dentro del proyecto
[Solar2000].

Las aplicaciones hipermedia son centradas en tres
pilares: datos,
funcionalidad y navegación en perspectivas diferentes de
acuerdo con la aplicación que está siendo
desarrollada [Mendes2002].

Las empresas
desarrolladoras de softwares reconocen la importancia de la
utilización de métricas de estimación para
el desarrollo de los proyectos. Para los productos hipermedia no
se tiene excepciones. Una estimación realista en las
etapas tempranas del ciclo de vida
de un proyecto hipermedia garantiza a gerentes y desarrolladores
en una organización manejar la información
de manera efectiva.

Este trabajo reúne una revisión
bibliográfica en materiales
publicados en la internet acerca de las
estimaciones y métricas que existen para los productos
hipermedia, como los libros
electrónicos, sitios web para cursos, softwares
educativos, etc. Para la comprensión de algunos trabajos
se hizo necesaria una explicación de modelos e
investigaciones previas a la utilización de
las métricas.

2.1 – Guión
(Storyboard)

Solar en su artículo "Un Modelo Para
Diseñar Storyboard en Proyectos Multimedia"
propone un modelo para apoyar el diseño
de guiones basado en métodos
generados a partir de modelos de
proceso de Ingeniería de Software, utilizando grafos
dirigidos y describe sus componentes genéricos a
través de un modelo de objetos. Aprovechando la
información contenida en el grafo diseñado, es
presentado un modelo para obtener reportes sobre los medios
descritos en cada nodo, resumen sobre la totalidad de la
aplicación, así como también el cálculo de
una aproximación del tiempo de desarrollo de una
aplicación, el costo de desarrollo del proyecto, y el
espacio de almacenamiento
requerido para el producto final, información de gran
utilidad en la
toma de
decisiones en la fase de diseño de un producto con
tecnología
Multimedia.

El modelo denominado Generación Gráfica de
Guiones (GGG o G3) se basa en la propuesta de Verdugo (1997),
basado en los métodos desarrollados por Jadue (1993) y
Montilva (1996), define formalmente una aplicación
multimedia (MM) utilizando grafos dirigidos y describe sus
componentes genéricos a través de un modelo de
objetos (figura 1), independiente de las herramientas
de autoría existentes para implementar y desarrollar
aplicaciones MM [Nemetz, 1995]. Emplea técnicas de
análisis y diseño orientado a
objetos, que permiten el modelado de estructura y
contenido más natural, elegante y de fácil
comprensión que aquel alcanzado con métodos
imperativos convencionales [Nielsen, 1990].

 Para ver el gráfico
seleccione la opción "Descargar" del menú
superior

Figura 1: Descripción de una aplicación MM
empleando grafos dirigidos

Se define formalmente un grafo dirigido G(N, E), donde N
es el conjunto de nodos de descripción de
información y E es el conjunto de arcos (llamados
enlaces), donde cada uno conecta dos nodos {n1,
n2}Î
N. Los nodos de información describen o se refieren
a un objeto del dominio de la aplicación.

Estructuralmente, un nodo es un objeto compuesto por un
conjunto de ítems de descripción de
información MM (i.e. texto,
gráfico, imagen, pistas de
audio, clips de videos, etc.).

Un enlace conecta un nodo inicio a otro de destino. Este
enlace es un objeto que describe el tipo de interacción
que debe existir para pasar del nodo inicio al de destino.
Interacciones posibles son click sobre un botón, presionar
una tecla, una variable, un tiempo transcurrido, etc. Al ocurrir
la interacción se indica que debe activarse el objeto o
unidad de destino, produciendo la presentación o
despliegue visual, según los medios que lo
compongan.

2.1.1. Estimación de
Costos, Tiempo de Desarrollo y Almacenamiento

Tal vez, ésta es una de las estimaciones
más difíciles en la definición de un
proyecto MM y en Ingeniería de
Software en general. Se aprecia que las tareas no son pocas
ni triviales, y la cantidad y perfil profesional de los
integrantes del equipo de producción son multidisciplinarios, por lo
que es necesario coordinar las tareas y el personal de producción en forma
óptima.

Para estas estimaciones se emplea como base la
información contenida en el grafo G(N, E) generado por el
storyboard del modelo Generación Gráfica de Guiones
(GGG). Cada nodo nÎ G(N, E) define una cantidad de medios y
tiene asociado valores de
tiempo de desarrollo y espacio de almacenamiento
según naturaleza y
complejidad.

Al recorrer el grafo en su totalidad, se puede obtener
el total de los medios contenidos en la aplicación
diseñada, y se puede deducir a partir de esto, el tiempo
de desarrollo del proyecto, su costo asociado, como
también el almacenamiento total requerido por el producto
final. A continuación, se presenta la obtención de
esta información, añadida a la información
contenida en el grafo G(N, E) generado en el diseño con
las tablas de costos asociadas a cada uno de los
medios.

2.1.2. Pesos Asociados a los
Medios

Cada medio tiene asociado tareas y un profesional que
las realiza, para lo cual se define una tabla que contiene los
tiempos de producción de cada medio (tabla 2), junto con
el valor hora del
tipo de profesional asociado. También, se define una tabla
para almacenar ponderadores que afectan el tiempo de desarrollo
de cada medio de acuerdo a la pericia o experiencia del
profesional a cargo (tabla 3). Ambas tablas poseen valores
expresados en unidades numéricas.

Con la tabla 3 se puede asignar a cada medio,
profesionales con mayor o menor pericia en el tema. A nivel de
software, es un módulo complementario al de diseño,
donde se puede agrupar los medios, y a su vez, dividir estos
grupos por
capítulos o subtemas. Así, el coordinador del
proyecto puede asignar a cada medio, uno o varios profesionales
(uno por capítulo) con distintos niveles, definidos por su
pericia o por el hardware utilizado. Por ejemplo, si el grafo
diseñado indica un total de diez ambientaciones(secuencias
de medios) por desarrollar, el tiempo total de producción
dependerá de la capacidad del profesional a cargo, que
puede ser de nivel medio, que según la tabla 3, aplica un
ponderador p6 al tiempo definido en tabla 2.
Así, el tiempo total de desarrollo del medio
"ambientación" será de
t6×
k6× p6 horas/hombre. Este
nivel medio puede definirse a un profesional altamente
capacitado, pero con hardware no apropiado que le produce
retrasos, por ejemplo, un "scanner" de tres
pasadas y baja resolución.

Tabla 2: Medios y valores
asociados

Tabla 3: Ponderadores
según conjunto Profesional/Hardware

Es posible asignar más de un profesional por
medio, pero se debe considerar que la mínima
división es por capítulos o temas, fundamentalmente
porque las labores son usualmente artísticas, las que son
altamente sensibles al cambio de
creador. Así, es recomendable contar con un experto
encargado de la producción de uno o varios medios, pero no
varios expertos para un solo medio.

2.1.3. Recorrido del Grafo

Para calcular los costos nodo por nodo se debe recorrer
el grafo en profundidad. A medida que se avanza se calculan
los valores de
acuerdo al reporte deseado, el que tiene las modalidades (que se
aprecian en la tabla 4. Se puede obtener reportes sobre tiempos
de desarrollo y costos por temas o por medios. Para reportes por
temas se definen los nodos niÎ G(N, E), que
representan el punto de partida de cada tema para iniciar la
búsqueda y cálculos. Para reportes por medios, el
cálculo comienza desde la raíz del grafo,
recorriéndolo en forma exhaustiva.

Tabla 4: Tabulación de tiempos

2.1.4. Formalización del Cálculo de
Tiempo y Costos

El cálculo de horas-hombre
Ti para el medio i (Mi) en una
aplicación es el producto entre cantidad de elementos
Mi y tiempo ti para realizarlo, aplicando
el ponderador pi dependiente del conjunto
profesional/hardware (ec. 1).

(1)

Para el cálculo por capítulos se divide la
cantidad Mi en tantos grupos como temas
hayan. El término Mi (total de medios i) se
convierte en Mij, que representa cantidad de medios i
en capítulo j. En el cálculo de tiempo de
desarrollo Tij del capítulo j para el medio i
(ec. 2) aparece el término pij (ponderador de
Mi en capítulo j) posibilitando asignar
distintos profesionales a diferentes temas.

(2)

De ecuación 2 se deduce la ecuación
general para calcular el tiempo total Tim
para el medio i, reflejada en ecuación 3, donde C es el
número de capítulos en la
aplicación.

(3)

Al organizar el proyecto por capítulos, el
análisis de tiempo y costo de capítulos se enfoca
desde otro punto de vista. El punto de partida es el mismo, dado
que a contar de la ecuación 1 y 2, se desarrolla de manera
horizontal los medios, que serán barridos en el
término i, que corresponde al medio, manteniendo constante
el término j que es el capítulo (ec. 4). El tiempo
total TjC del capítulo j es el
producto entre cantidad Mi en capítulo j y
tiempo ti asociado a Mi, por el ponderador
pij de tiempo de Mi en el capítulo
j. La ec. 4 recorre todos los medios del capítulo j, donde
M es el número total de medios definidos en el
modelo.

(4)

Para el cálculo de
horas TP totales para desarrollar el proyecto (no
implica tiempo lineal) se suma totales obtenidos por
capítulos o por medios (ec. 5), deduciéndose la
ecuación 6.

(5)

(6)

Al contar con las horas-hombre para realizar las tareas
del proyecto, el cálculo de costo de éste no es
complejo, dado que puede traducirse éstas horas-hombre en
costo. No toda la mano de obra tiene el mismo costo
(diseñador, cineasta e ingenieros son distintos), por lo
tanto para obtener costo del proyecto se calcula las horas-hombre
por medio (igual valor), luego
se suman los medios del proyecto. En ecuación 7 se observa
incorporación de costo de hora-hombre ki para
obtener el costo de producir Mi en el
proyecto.

(7)

Análogamente para obtener costo por
capítulos (costo de capítulo j) en ecuación
8 se incorpora el valor hora-hombre ki según
Mi. El costo total del proyecto queda definido por la
ecuación 9.

(8)

(9)

2.1.5. Cálculo del
Almacenamiento

El cálculo del espacio de almacenamiento es
también una medida estimativa, dado que no es posible
conocer a priori el tamaño de medios que tienen asociado
los métodos de compresión. Por ejemplo, un
tamaño y cantidad de "frames" dada en un video posee un
tamaño fijo, pero comprimido, su tamaño final
depende del método de
compresión y las características del video.

Considerando lo anterior, el espacio de almacenamiento
requerido por el producto final de la aplicación, se
obtiene en forma similar a los tiempos. Se requiere la tabla 2,
que contiene el tamaño promedio de cada medio. Así,
al recorrer el grafo se obtiene el tamaño (ec. 10), donde
el espacio de almacenamiento Ap del producto final se
define como la suma de los medios de todos los capítulos
multiplicados por cada espacio según
Mi.

2.2 – Estimación de
métricas para Hipermedia Web y Esfuerzo de
autoría

Mendes en su artículo "Measurement, prediction
and risk analysis for web applications" presenta un modelo de
predicción para aplicaciones hipermedia de autoría
y web durante un estudio de casos realizado con un proyecto
asignado a los estudiantes en el curso de hipermedia y multimedia
de la Universidad de
Auckland. Reúne una serie de métricas de la
literatura de
ingeniería de software y multimedia con
adaptaciones.

Fueron aplicados dos cuestionarios (ver Anexo) para
recolectar los datos. El primero
cualifica la experiencia de los diseñadores en cinco
escalas que va de ninguna experiencia (1) hasta muy buena
experiencia (5). El segundo cuestionario
mide las características de las aplicaciones
desarrolladas y el esfuerzo involucrado en el diseño y
autoría de estas aplicaciones.

El proceso utilizado sigue los pasos del diagrama 1. El
análisis de los requisitos no fue considerada en este
modelo.

Para ver el gráfico seleccione la
opción "Descargar" del menú superior

Fijaremos nuestra atención en el conjunto de métricas
utilizadas para el trabajo que reúne bibliografías de diversos
autores sobre aplicación de métricas a los
productos hipermedia.

Las métricas colectadas durante el estudio de
caso representan atributos de 4 tipos de Entidades:

1. Aplicaciones Web
2. Procesos de diseño Web y
   autoría
3. Desarrollador
4. Herramientas de autoría.

Cada tipo de entidad tiene un conjunto de
métricas organizadas en 5 categorías de acuerdo con
las tablas que siguen: métricas de tamaño,
reusabilidad, complejidad, esfuerzo y factores de
confusión, siendo que esta última consiste en
verificar los factores que, si no son controlados, pueden influir
en la validez de la evaluación.

2.2.1. Métricas de
tamaño (Size Metrics)

Tabla 5 Metric
Description

2.2.2. Métricas de
reusabilidad (Reusability Metrics)

Tabla 6ption

2.2.3. Métricas de
Complejidad (Complexity Metrics)

Tabla 7pe

2.2.4. Métricas de
Esfuerzo (Effort Metrics)

Tabla 8

E2.2.5. Factores de confusion
(Confounding Factors)

Tabla 9

Conclusión

Las empresas de
informática de todo el mundo desarrollan
aplicaciones comerciales y educativas con características
que las clasifican en productos hipermedia o aplicaciones Web.
Pero, desarrollar estos tipos de productos es caro, exige mucho
tiempo y personal calificado.

Analizando la literatura existente sobre
el asunto se concluye no existir un estándar para la
planificación de costos de los productos
hipermedia. Pero los especialistas ya se dieron cuenta de la
extrema necesidad de una investigación más profunda en este
tema bien como una adecuada utilización de las
métricas para las características especiales que
poseen los softwares hipermedia y las aplicaciones
Web.

Bibliografía

[Verdugo, 1997] P. Verdugo, "Definición de un
Modelo para el Desarrollo de Proyectos de Tecnología
Multimedia." Tesis de
Magister, DPTO. Ing. Informática, de Chile,
Universidad de
Santiago, 1997.

[Jadue, 1993] J. Jadue, "Implementación de
Laboratorio de
Multimedios orientado a mejorar calidad de
docencia en Universidad de Santiago de Chile."
Trabajo de Título, Ing. de Ejecución en Computación e Informática, DPTO.
Ing. Informática, Universidad de Santiago de Chile,
1993.

[Montilva, 1996] J. Montilva, "Aplicando Modelos de
procesos de
software al desarrollo de aplicaciones hipermedia." XXII
CLEI-Panel 96, Santafé de Bogotá, Colombia,
1996.

[Solar, 2000] Solar, M., Verdugo, P., Parada, P., "Un
Modelo para Diseñar Storyboard en Proyectos Multimedia" –
International Journal on Computer Applications in Engineering
Education, Vol. 8, num. 3 and 4, pp. 221-228, 2000.

[Mendes, 2001] Mendes, E., Fewster, R., "Web
Metrics-Estimating Design and Authoring Effort", IEEE MultiMedia,
special issue on Web Engineering, January-March 2001, pp. 50-57,
2001.

[Mendes, 2001] Mendes, E., Fewster, R., "Measurement,
prediction and risk analysis for web applications", Proceedings
of IEEE Metrics Symposium -7th International Software metrics
Symposium, IEEE CS Press, 2001.

[Mendes, 2002] Mendes, E., Mosley, N., Counsell, S.,
"The Application of Case-Based Reasoning to Early Web Project
Cost Estimation", IEEE 26th Annual International
Computer Software and Applications Conference – COMPSAC,
2002.

[Mendes, 2002] Mendes, E., Mosley, N., Counsell, S., "A
Comparison of Size Measures for Predicting Web Design and
Authoring Effort", Jornal Paper IEE Proc. Software,
2002.

[Hihn, 1991] Hihn, J., Habid-agahi, H., "Cost Estimation
of software intensive projects: a survey of current practices",
Proc. 13th Int. Conf. On Software Engineering. Austin
TX, ACM Press. (cap. 23), 1991.

[Boehm, 1981] Boehm, B., "Software Engineering
Economics", Englewood Cliffs, NJ: Prentice Hall. (cap.23),
1981.

Anexo

Cuestionario
1

http://www.cs.auckland.ac.nz/~emilia/Assignments/exp-questionnaire.html

415.708 – Hypermedia
and Multimedia Systems

Experience
Questionnaire used for Assignment 2

The objective of this questionnaire is
to gather information about your Web authoring experience
before developing the Web application in assignment
2.

Accuracy is a key
component to completing this form correctly.

Top of Form 1

Id: spacee-mail:

Name: spaceSurname:

Rate your authoring experience
before developing the Web application given in assignment
2:

spaceNone

spaceLittle

spaceAverage

spaceGood

spaceVery
good

Bottom of Form
1

GLOSSARY

No experience – group
zero

This level of experience means that you
have not had any previous contact with using or authoring on the
Web.

back

Little experience – group
one

This level of experience means that you
have used the Web for browsing and have authored a Web page using
basic HTML: images, links, paragraphs, lists

back

Average experience – group
two

This level of experience means that you
have used everything described for group one plus: use of frames,
tables, colors, background, bookmarks, animated gifs, and
knowledge of difference between jpg, gif98a.

back

Very Good experience – group
three

This level of experience means that you
have used everything described for group two plus: use of image
maps (client/server), meta tags, knowledge of HTTP, HTTPS,
FTP, etc,
basic java Applets and
Javascript.

back

Very good experience – group
four

This level of experience means that you
have use everything described for group three plus: use of
complex meta-tags, special characters (e.g., ), cgi scripts, java
Applets, Javascript, DHTML and XML.

Cuestionario
2

http://www.cs.auckland.ac.nz/~emilia/Assignments/questionnaire.html.

415.708 – Hypermedia
and Multimedia Systems

Questionnaire used for
Assignment 2

The objective of this questionnaire is
to gather information about your Web authoring experience and
also information about the Web application that you have
developed as part of assignment 2.

Accuracy is a key
component to completing this form correctly.

Note: All the
time-related questions should be answered using
number of hours.

Please use decimals
for fractions (e.g. 1.5 hours).

Top of Form 1

IDENTIFICATION

Id: spacee-mail:

Name: spaceSurname:

EXPERIENCE

Rate your perceived
authoring experience (refer to
Glossary) after
developing the Web application given in
assignment 2:

spaceNone

spaceLittle

spaceAverage

spaceGood

spaceVery
good

AUTHORING THE
APPLICATION

Structuring the
Application:

How long did it take you to plan
the Structure?

hours

How long did it take you to inter-link
(link) the pages in order to build the structure? hours

Designing the
interface:

How long did it take you to
plan the
interface? hours

How long did it take you to
implement the
interface? hours

Testing the
application:

How long did it take you to
test the
links? hours

How long did it take you to
test the media?
hours

AUTHORING
TOOLS

What authoring
tools did you use?

spaceWord for Windows

spaceNotepad
or a similar text editor

spaceFirstPage

spaceArachnophilia

Graphics editor:

Audio editor:

Video editor:

Animation editor

STRUCTURE OF THE
APPLICATION

Would you classify
the structure
of your application as mainly:

spaceSequential

spaceHierarchical

spaceNetwork

FILES TO
DOWNLOAD

Download the file
media-file.xls
(Microsoft
excel) and fill in the information about each media type,
other than text, created or reused

Download the file page-file.xls
(Microsoft
excel) and
fill in the information about each html page you created or
reused

Download the file language-file.xls
(Microsoft
excel) and fill in the information about each programming
language (other than html) used

Finally, draw on an A3 sheet a graph
representing the structure of your application and hand it in to
Emilia with your name and id-number.

Bottom of Form
1

GLOSSARY

Authoring
Experience

No experience – group
zero

This level of experience means that you
have not had any previous contact with using or authoring on the
Web.

back

Little experience – group
one

This level of experience means that you
have used the Web for browsing and have authored a Web page using
basic HTML: images, links, paragraphs, lists

back

Average experience – group
two

This level of experience means that you
have used everything described for group one plus: use of frames,
tables, colors, background, bookmarks, animated gifs, and
knowledge of difference between jpg, gif98a.

back

Very Good experience – group
three

This level of experience means that you
have used everything described for group two plus: use of image
maps (client/server), meta tags, knowledge of HTTP, HTTPS,
FTP, etc,
basic java Applets and Javascript.

back

Very good experience – group
four

This level of experience means that you
have use everything described for group three plus: use of
complex meta-tags, special characters (e.g., ), cgi scripts, java
Applets, Javascript, DHTML and XML.

back

Structuring the
application

Structuring the application represents
organising the information collected into nodes (what content to
include on each Web page) and identifying the appropriate links
and where to create them.

back

• Structure

The structure represents the way in
which the nodes are linked when considering the backbone (core)
of the application. The structure can be sequential, hierarchical
or in a network shape, corresponding respectively to nodes
linearly (sequentially) linked, nodes linked in a tree shape and
nodes linked in a net shape.

back

Design the
Interface

Deciding what sort of layout the Web
pages should have, where information should be included, what
html templates to use, what colors to use, what types of media to
include and how to organise it without cluttering the page.
Involves planning the interface and implementing it.

back

• Plan the Interface

Organise the interface of each page in
order to keep the "look and feel" as similar as possible
throughout the application (use of templates). Where to include
different types of media, which colors to use, font size, any
appearance considerations would also be part of
planning.

back

• Implement the
  Interface

Adds the content to the templates
developed. The decision regarding what content to include on
each Web page is accomplished at the phase entitled
"Structuring the Application"

back

Test the
application

Checks if links and different types os
media work. Testing occurs after the application has been
developed.

back

• Test Links

Test whether the links are dangling or
if they are still valid

back

• Test Media

Test whether the different types of
media work

back

Lic. Vanessa Teixeira de Oliveira
Sandi

Aspirante al título de Máster
por el Instituto Superior Politécnico José Antonio
Echeverría –

Havana – Cuba

Prof: Dra. Sofia Alvarez
Cárdenas

Categoria: Ingeniería de
Software

CIUDAD UNIVERSITARIA

"JOSÉ ANTONIO ECHEVERRÍA"

CUJAE

CEIS – Centro de Estudios de Ingeniería de
Sistemas

Ciudad de La Habana. Cuba.