Capítulo 4. Esfuerzo y coste

Tabla de contenidos
4.1. Planificación
4.2. Valoración económica del esfuerzo

En este capítulo se presenta como se ha estructurado el trabajo de creación de pDI-Tools y se estima el coste de éste si se hubiese realizado como un proyecto de "software" real.

El capítulo se divide en dos partes: planificación y coste.

En la primera parte se presenta la planificación de trabajo del proyecto en fases. La finalización de una fase representa una cantidad de trabajo sustancial y un hito en la historia del desarrollo de pDI-Tools. Además nos permite ver a grandes rasgos como se esperaba conducir, y como se condujo, el desarrollo de pDI-Tools: momentos más críticos, cuanto tiempo se dedicó a investigar, cuando pDI-Tools empezó a tener su aspecto definitivo, etc.

En la segunda parte se reune toda la información de distribución de tiempo de la primera parte y en base a ella se decide como se reparten costes: cuanta gente debería trabajar en el proyecto, con que remuneración, etc. Y al final del mismo presentamos el coste económico que hubiese tenido el proyecto.

4.1. Planificación

Inicialmente se quería portar DITools de Irix a GNU/Linux. Este proyecto se empezó sin total seguridad de poder completarse o no. Por un lado no sabíamos si la implementación de ELF de GNU/Linux permitiría realizar las mismas operaciones que la implementación de Irix, y por otro lado no teniamos conocimiento sobre el grado de portabilidad de DITools.

Terminado un proceso de investigación sobre ELF e ingeniería inversa sobre DITools se decidió reescribir la aplicación desde cero. Como se vió que sería un proyecto con un diseño básico que se iría perfeccionando y afinando con el tiempo se optó por un desarrollo basado en prototipos.

Esta metodología de diseño consiste en partir de un análisis de requerimientos y posteriormente se realiza un diseño rápido, una implementación del prototipo, su evaluación y finalmente su refinamiento. Si es necesario se itera sobre estos cuatro pasos hasta llegar al producto final. Sólo en casos extremos, en los cuales se ha partido de una mala base, se debe repetir el análisis de requerimientos.

En este diagrama se explica el modelo en diseño mediante prototipos. La espiral parte de un análisis de requerimientos y finalizará cuando se obtenga un prototipo que se pueda considerar un producto final.

No obstante este modelo en espiral de prototipos no es totalmente fiel a la planificación seguida para desarrollar este proyecto. A pesar de que hubo algunas iteraciones, hubo en realidad muchos procesos independientes en paralelo. En el siguiente gráfico se muestra a grandes rasgos como se planificó y ejecutó el desarrollo del proyecto a lo largo de doce meses:

En este gráfico se muestran las tareas realizadas. Cada división representa un mes de trabajo.

Entrando en detalle describimos las actividades de esta planificación:

  1. Estudio de DITools. En esta fase se estudió DITools con el objetivo de decidir si era viable portarlo a GNU/Linux. Al final resulto que el coste de portarlo era casi mayor que el coste de comenzarlo desde cero, así que se realizo un estudio para exprimir toda la experiencia que esta herramienta contiene. Además se depuró y se reprogramarón algunas partes para hacer el código más legible. El estudió tuvo como objetivo reunir experiencia para escribir una nueva aplicación.

  2. Estudio ELF y suplementos INTEL® 386 y MIPS®. En esta fase se recogió información de cualquier tipo sobre ELF, arquitecturas, sistemas operativos, técnicas de reenlace, etc.

    Se hizo una comparativa, almenos superficial, entre formatos específicos de enlace dinámico para tener una visión global de como se implementan estos en diferentes plataformas.

    Se investigó también que técnicas de infección e interposición de código se han desarrollado o ensayado en ELF.

    También se profundizó en el conocimiento de las arquitecturas INTEL® 386 y MIPS®, tanto para poder entender DITools como para poder diseñar el nuevo pDI-Tools.

  3. Estudio SPARC. En el quinto mes, ya con un conocimiento avanzado sobre ELF, se estudió una plataforma totalmente distinta tanto en arquitectura como en implementación. La plataforma escogida fue Solaris/SPARC debido a que parece de todas la más sencilla.

    Este estudio va tanto orientado a la implementación del "driver" para Solaris sobre SPARC como para poder extrapolar luego una interfaz portable para los "drivers".

  4. Estudio PowerPC™. Se investigó como funciona esta plataforma, la cual no está totalmente estandarizada a nivel ELF. Este estudio es el doble de costoso de lo habitual porque la especificación de 32 bits no se asemeja en nada a las recomendaciones para 64 bits.

  5. Análisis de requerimientos. En el tercer mes, con la experiencia obtenida hasta ese momento, se empezó el análisis de requerimientos y a establecer el diseño inicial de pDI-Tools.

    Para poder empezar a programar lo antes posible se dividió pDI-Tools en grandes partes y se fijaron, sólo comenzar, a grandes rasgos las estructuras de datos principales. Estas se pudieron fijar rápidamente ya que ya se venían madurando durante el estudio de DITools.

    Este proceso duró tres meses aunque la mayor parte del trabajo está contenido principalmente en el primer mes.

  6. Implementación de pDI-Tools. Esta fase contiene todo el desarrollo de la parte no dependiente de la arquitectura de pDI-Tools. El código desarrollado procura reciclar el máximo código posible sin mermar para nada la portabilidad.

    Se escribió todo el código encargado de configurar pDI-Tools, de procesar los ficheros de comandos, de realizar comprobaciones, gestionar "backends", etc. Es decir, el código encargado de realizar la mayor parte de gestiones de pDI-Tools.

  7. "Elf Backend" Linux™/INTEL® 386. En esta fase se implementó el código específico para realizar reenlaces, redefiniciones e interposiciones mediante el mecanismo de "callback" en GNU/Linux sobre INTEL® 386.

    Esta fase se dividió en pruebas de concepto, implementación y adaptaciones. Las pruebas de concepto sirvieron tanto para garantizar la viabilidad de las interposiciones como para ensayar su posterior implementación. Estas pruebas son pequeños programas con "hacks" que simulan la creación de las distintas interposiciones.

    Sigue la implementación del "driver". A la vez se escribe, en la parte independiente el API, el protocolo a seguir para interaccionar con este "driver".

    Este código fué readaptado en dos ocasiones para poder dar soporte a la arquitectura Solaris/SPARC. Esto fue debido a nuestro desarrollo por prototipos: el primer prototipo era demasiado específico para INTEL® 386, así que se empezo un nuevo prototipo también apto para SPARC 32 bits. Luego se hizo otro prototipo (adaptación) para poder funcionar en entornos de 64 bits (SPARC 64).

  8. "Elf Backend" Solaris/SPARC. Se crea un "driver" para un nuevo sistema operativo y una nueva arquitectura. El objetivo es desarrollar ambos "drivers" (GNU/Linux y Solaris) a la vez para poder definir la interfaz que compartiran para comunicarse con pDI-Tools.

    Esta fase tuvo repercusión sobre el resto del código ya que se portó la aplicación a un entorno de 64 bits. Esto sumado a que se cambió tanto de "hardware" como de sistema operativo expuso muchos problemas de portabilidad en el primer prototipo de pDI-Tools.

  9. "Elf Backend" Linux™/PowerPC™. Consiste en ampliar el "driver" para GNU/Linux para que soporte las arquitecturas PowerPC™ de 32 y 64 bits.

    Como a estas alturas la interfaz entre la parte no dependiente y el "driver" estaba prácticamente congelada, el desarrollo de este "driver" apenas implicó cambios.

    No obstante sirvió para plantear como un "driver" puede soportar varias arquitecturas. Así se desarrolló una segunda capa de abstracción, totalmente interna al "driver" de GNU/Linux, que permite reciclar mucho código relacionado con el sistema operativo y no con la CPU.

    Además se sabía de antemano que es una de las plataformas más duras de trabajar ya que PowerPC™ 64 bits es una plataforma todavía a medio desarrollar, desde el punto de vista de ELF.

  10. "Elf Backend" Irix/MIPS®. El último "driver" que se escribió fue para Irix sobre máquinas MIPS®.

    Este "driver" se implemento en un tiempo record. Se escribió con objetivo de medir la facilidad de portar de golpe pDI-Tools a una nueva plataforma y arquitectura.

  11. Optimizaciones, pruebas y corrección. La mayor parte de pruebas y optimizaciones se han realizado a lo largo del desarrollo, especialmente en el tema de la corrección del programa. No obstante una vez acabado el "software" se siguió sometiendo a varias revisiones y evaluaciones con objetivo de detectar donde se debía mejorar y, si era posible, se realizaban las mejoras.

  12. Creación del entorno DocBook/XSL. Esta tarea consistió en construir un entorno de proceso de documentos XML en formato DocBook. Con este entorno de trabajo se simplificó la construcción y escritura de los documentos relacionados con esta aplicación.

    Esta fase incluye la creación de los ficheros makefile (responsables de construir la documentación), las hojas de transformación y estilo (que transforman un conjunto de ficheros XML en un fichero, y algunos "scripts" en Perl encargados de automatizar algunas tareas (por ejemplo la creación de las marcas de índice para poder indexar el texto DocBook/XSL), etc.

    Este desarrollo se dividió en dos partes: creación de lo más básico del entorno para poder escribir el documento "pDI-Tools: Descripción del proyecto" y después se añadió, según se iba necesitando, soporte a características más complejas como índices o imágenes.

  13. Documentación del proyecto. Esta etapa se corresponde con la escritura del documento "pDI-Tools: Descripción del proyecto" y de la presente memoria.

    Para este proceso, gracias a la tecnología usada, sólo se necesitó un editor de textos (en concreto Vi IMproved) y editores de imágenes (Inkscape y GIMP principalmente, aunque no se estaba ligado a ninguno en especial).

Inicialmente se estimo que el proyecto tendría un coste total de 960 horas de trabajo. Esto correspondería a 12 meses de trabajo a 4 horas por día asumiendo que hay 20 días laborables cada mes.

Como suele suceder, se fue demasiado optimista y se subestimo la cantidad de trabajo, especialmente en cuanto a la documentación se refiere. En cambio casi se acerto el tiempo estimado para ingeniería inversa, el cual fue ligeramente superior debido al estado del código fuente DITools y la ausencia de documentación. Pero sin duda se acerto con el tiempo requerido para la programación de la parte no dependiente de pDI-Tools:

Tabla 4-1. Comparación del tiempo estimado y empleado realmente

 Tiempo planificadoTiempo real
Formación e investigación200 h.293 h.
Diseño60 h.78 h.
Ingeniería inversa100 h.125 h.
Programación400 h.399 h.
Documentación200 h.305 h.
total960 h.1.200 h.

Para poder terminar el proyecto se tuvo que trabajar todos los días, excepto 5 de cada mes (asumimos un mes de 30 días). La cantidad de horas por día se mantuvo a 4 ya que más era imposible debido a que este proyecto se compagino con un trabajo de 5 horas diarias. Esto sumo un trabajo total de 1.200 horas de trabajo, superando en 240 horas las estimaciones iniciales.

Seguidamente, y con el fin de hacer una valoración del coste del proyecto, desglosamos todas estas horas de trabajo en tareas, y cada tarea la desglosamos en diferentes categorías. De esta forma podremos evaluar mejor la complejidad del proyecto y así calibrar el coste que hubiese tenido.

Tabla 4-2. Tiempo empleado en cada tarea

etapaformación e investigacióndiseñoing. inversaprogra-macióndocumen-taciónhoras por etapa
A90 h.-70 h.20 h.-180 h.
B140 h.----140 h.
C20 h.----20 h.
D35 h.----35 h.
E-70 h.---70 h.
F---150 h.-150 h.
G--30 h.85 h.-115 h.
H--10 h.40 h.-50 h.
I--10 h.20 h.-30 h.
J--5 h.10 h.-15 h.
K---30 h.-30 h.
L8 h.8 h.-44 h.-60 h.
M----305 h.305 h.
total293 h.78 h.125 h.399 h.305 h.1.200 h.