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.