Escuela de Informática y Telecomunicaciones. Sede Antonio Varas. Marco Metodológico para el desarrollo de Proyecto de Titulo Alumnos: Echeverria Olivo, Nicolas Fuentes Roberts, Rodrigo Santiago, Junio 24 de 2010 Índice Índice ................................................................................................................................................... 2 Introducción ........................................................................................................................................ 6 Definición del Modelo de Procesos .................................................................................................... 7 Metodología de desarrollo escogida ................................................................................................ 7 Gestión de Riesgo ............................................................................................................................. 11 Identificación de definición de riesgo ........................................................................................... 11 Tabla de cálculo de exposición de riesgo .................................................................................. 12 Planillas de riesgo...................................................................................................................... 14 Gestión de la configuración de software (SCM) ............................................................................... 16 Procesos Asociados ...................................................................................................................... 16 Subversion ..................................................................................................................................... 17 Ventajas .................................................................................................................................... 18 Desventajas ............................................................................................................................... 18 Gestión de aseguramiento de la calidad de software (SQA) ............................................................. 19 Función del Aseguramiento de la Calidad de Software ................................................................ 19 Modelo SQA ................................................................................................................................. 20 Revisión del Software ............................................................................................................... 21 Actividades de Verificación ...................................................................................................... 21 Objetivo de las Pruebas mencionadas ....................................................................................... 22 Estándares de desarrollo de software ................................................................................................ 24 Funcionalidad ...................................................................................................................... 24 Fiabilidad ............................................................................................................................. 24 Usabilidad ............................................................................................................................ 24 Eficiencia .............................................................................................................................. 24 Mantenibilidad .................................................................................................................... 24 Portabilidad ......................................................................................................................... 25 Estándares de generación de bases de datos...................................................................................... 26 1. Modelo y Diseño .................................................................................................................. 26 2. Programación ...................................................................................................................... 27 Estándares de generación de interfaces ............................................................................................. 29 1. HTML & CSS ...................................................................................................................... 29 2. Scripting y Ajax ................................................................................................................... 29 Estándares de generación de programación ...................................................................................... 31 1. Porque tener convenciones de programación ........................................................................ 31 2. Nombre de Archivos ............................................................................................................. 31 3. 2.1. JavaSoft utiliza los siguientes sufijos. ........................................................................... 31 2.2. Nombre de archivos comunes ....................................................................................... 31 Organización de Archivos ..................................................................................................... 31 3.1. 4. 5. 6. Archivos Fuentes Java ................................................................................................... 31 Indentación ............................................................................................................................ 32 4.1. Largo de Línea .............................................................................................................. 32 4.2. Envase de Líneas (Wrapping) ....................................................................................... 32 Declaraciones ........................................................................................................................ 33 5.1. Numero por Línea ......................................................................................................... 33 5.2. Colocación..................................................................................................................... 33 5.3. Inicialización ................................................................................................................. 33 5.4. Declaraciones de Interfaces y Clases ............................................................................ 33 Sentencias .............................................................................................................................. 34 6.1. Sentencias simples......................................................................................................... 34 7. 8. 6.2. Sentencias compuestos .................................................................................................. 34 6.3. Sentencias de retorno .................................................................................................... 34 6.4. Sentencias if, if-else, if-else-if-else ............................................................................... 34 6.5. Sentencias for ................................................................................................................ 35 6.6. Sentencias while ............................................................................................................ 35 6.7. Sentencias do-while....................................................................................................... 35 6.8. Sentencias switch .......................................................................................................... 35 6.9. Sentencias try-catch....................................................................................................... 36 Espacios en blanco ................................................................................................................ 36 7.1. Líneas en Blanco ........................................................................................................... 36 7.2. Espacios en Blanco........................................................................................................ 36 Convenciones de Nombres .................................................................................................... 37 8.1. 9. Estilos de capitalización ................................................................................................ 37 Prácticas de Programación .................................................................................................... 38 9.1. Proporcionando acceso a instancias y variables de clase .............................................. 38 9.2. Referencias a variables de clase y métodos................................................................... 38 9.3. Constantes ..................................................................................................................... 38 9.4. Asignación de variables ................................................................................................ 38 9.5. Practicas Diversas ......................................................................................................... 39 Elección de la herramienta de desarrollo .......................................................................................... 40 1. Lenguaje ............................................................................................................................... 40 2. Herramienta: NetBeans ...................................................................................................... 40 3. Herramienta: IReport ......................................................................................................... 40 4. Base de Datos: PostgreSQL ................................................................................................ 41 Planificación...................................................................................................................................... 42 Estimación ......................................................................................................................................... 44 Carta Gantt .................................................................................................................................... 44 Introducción El presente documento tiene como finalidad presentar las metodologías selecionadas para llevar a cabo el desarrollo del proyecto SICA. Donde se define la metodología de desarrollo. Riesgos encontrados que puedan incidir ya sea de manera directa o indirecta a la evolución del proyecto. También se establecen los estándares que se utilizaran a nivel de desarrollo de software, bases de datos, interfaces y desarrollo como tal. Para hacer efectivos el uso de los estándares antes descritos también se hace referencia a las herramientas para programar, trabajar con las bases de datos y otros. Todos los elementos de proyecto son planificados y evaluados. Definición del Modelo de Procesos Metodología de desarrollo escogida Una metodología es una guía que se sigue con el fin de lograr el objetivo para la cual fue diseñada de manera sistemática y disciplinada. La elección en particular de una metodología de desarrollo se basa en las necesidades específicas del cliente, el tiempo disponible y el personal, por lo que estas son las necesidades básicas que debe contemplar la elección. A la actualidad existen muchas metodologías para el desarrollo de software y cada una se orienta hacia un concepto específico o varios, dando como resultado una amplia gama a la hora de decidir e implementar. La elección de la metodología de trabajo se baso en las restricciones del poco tiempo disponible y el personal designado al proyecto. Bajo estas directrices, el uso de RUP es el que presenta mejores prácticas y adaptabilidad. Esta herramienta, llamada Proceso Unificado Rational para Desarrollo de Software, se describe como un proceso de Ingeniería de Software, en donde se asignan tareas y responsabilidades dentro de una organización de desarrollo tecnológico. Algunas de las ventajas del RUP, incluyen: 1. Procesos iterativos e incrementales. a. Una de las mayores ventajas es que implementa el desarrollo de maneja iterativa incremental, lo cual permite realizar entregas funcionales que el cliente puede ir probando y corrigendo, la siguiente imagen ilustra el proceso iterativo incremental. Componentes de una iteración 2. Están basados en casos de uso. a. El hecho de trabajar con casos de uso evita generar mayores dudas al desarrollador al contener toda la información necesaria para la programación de un modulo en un documento además de permitir la validación de que lo se que implementó, realmente cumpla con lo estipulado en el caso de uso. Trabajos integrados al caso de uso 3. Se centra en la Arquitectura. a. Este atributo permite tomar mejores decisiones sobre cómo tiene que ser construido un sistema además de elementos de calidad como el rendimiento, capacidad de reutilización y capacidad de evolución o escalabilidad. Evolución de la arquitectura del sistema Sin embargo, aunque RUP cumple con los requisitos, era necesario ir más allá y adelantarnos a los hechos, para ello la única forma de poder hacerlo es ganar tiempo, es por esto que se utilizan métodos de agilización del proceso de desarrollo haciendo convivir RUP con las mejores prácticas de la metodología ágil, lo anterior bajo las siguientes premisas: 1. Individuos e interacciones por sobre los procesos y herramientas. 2. Aplicaciones operativas por sobre la documentación exhaustiva. 3. Colaboración con el cliente por sobre la negociación contractual. 4. Respuesta al cambio por sobre el seguimiento a un plan. El resultado del uso de RUP, junto con el uso de métodos de agilidad nos permite tener claro que debemos enfocarnos en las siguientes características para el desarrollo: 1. Guiado por Casos de Uso. 2. Centrado en la Arquitectura de Software. 3. Iterativo e incremental, en los diferentes ciclos, fases y disciplinas. 4. Prioriza el trabajo en equipo. 5. Enfatiza el aseguramiento de calidad. 6. Proceso Integrado. 7. Mejorar la comprensión del problema del cliente, e incluir soluciones que consideran la estrategia de planificación y la respuesta rápida a sus necesidades. 8. Contar con alternativas a los cambios solicitados por el Cliente. Lo anterior nos permite tener planificaciones acotadas a desarrollos que son diariamente integrados lo cual indica que se pueden medir los avances y realizar correcciones o planificaciones antes de llegar a algún punto crítico de retraso que impacte las entregas y/o el negocio del cliente. Gestión de Riesgo Identificación de definición de riesgo La identificación del riesgo consta de un proceso que incluye la identificación de peligros, evaluación, el manejo y la comunicación del riesgo para controlar su ocurrencia y minimizar su impacto. Riesgo en un Proyecto: La probabilidad de que una amenaza se materialice, utilizando una vulnerabilidad existente de un activo o grupo de activos, generándole pérdidas o daños. Con esto podemos decir que un riesgo se compone de estos elementos: probabilidad, amenazas, vulnerabilidades, activos e impactos. Riesgos Conocidos: Corresponden a aquellos riesgo inherentes al proyecto que han sido encontrados durante el análisis del proyecto. Una de las formas más rápidas de identificar riesgos asociados a un proyecto, es mediante una base de conocimientos que refleje riesgos enfrentados anteriormente y ver si estos pueden estar presentes en el proyecto a elaborar. La gestión de esta base de conocimientos debe tener un responsable de nutrirla constantemente con nuevos riesgos identificados y eliminando aquellos que sea necesario. Con el objetivo de crear una tabla de cálculo de exposición al riesgo, los riesgos identificados que puedan afectar al proyecto, serán clasificados de acuerdo a los tópicos señalados a continuación: Ambiente e Infraestructura de Desarrollo. Cliente. Diseño e Implementación. Elaboración de la Planificación. Personal. Proceso. Producto. Requisitos. Usuarios Finales. Para la ponderación de los riesgos mencionados se manejará la siguiente escala: Ocurre la mayor parte de las veces: Ocurre regularmente: Puede ocurrir alguna vez: Casi improbable que ocurra: Valor 4 Valor 3 Valor 2 Valor 1 Tabla de cálculo de exposición de riesgo Categoría Cliente Diseño e Implementación Elaboración de la Planificación Personal Proceso Descripción Específica del Riesgo Valor Los componentes suministrados por el cliente no son adecuados para el producto que se está desarrollando, por lo que se tiene que hacer un trabajo extra de diseño e integración. 3 Los componentes suministrados por el cliente tienen poca calidad, por lo que tienen que hacerse trabajos extra de comprobación, diseño e integración. 3 El tiempo de comunicación del cliente (por ejemplo, tiempo para responder a las preguntas para aclarar los requisitos) es más lento del esperado. 2 El cliente piensa en una velocidad de desarrollo que el personal de desarrollo no puede alcanzar. 1 Un mal diseño implica volver a diseñar e implementar. 1 Se ha sobreestimado el ahorro en la planificación derivado del uso de herramientas para mejorar la productividad. 2 Un diseño demasiado complejo exige tener en cuenta complicaciones innecesarias e improductivas en la implementación. 4 La fecha final ha cambiado sin ajustarse al ámbito del producto o a los recursos disponibles. 4 Las definiciones de la planificación, de los recursos y del producto han sido impuestas por el cliente o un directivo superior, y no están equilibradas. 2 No hay suficiente personal disponible para el proyecto. 4 Se necesitan personas para el proyecto con habilidades muy específicas y no se encuentran. 4 Las tareas asignadas al personal no se ajustan a sus posibilidades. 4 La burocracia produce un progreso más lento del esperado. 2 La falta de rigor (ignorar los fundamentos y estándares del desarrollo de software) conduce a fallos de comunicación, problemas de calidad y repetición del trabajo. Un consumo de tiempo innecesario. 2 Producto Requisitos Usuarios Finales Los módulos propensos a tener errores necesitan más trabajo de comprobación, diseño e implementación. 2 El desarrollo de una interfaz de usuario inadecuada requiere volver a diseñarla y a implementarla. 1 El desarrollo de funciones software que no son necesarias alarga la planificación. 1 Los requisitos no se han definido correctamente y su redefinición aumenta el ámbito del proyecto 3 Las partes del proyecto que se no se han especificado claramente consumen más tiempo del esperado. 3 En último momento al usuario final no le agrada el producto y debe ser rediseñado y recreado. 1 Planillas de riesgo Categoría Descripción Específica del Riesgo Acción de mitigación Los componentes suministrados por el cliente no son adecuados para el producto que se está desarrollando, por lo que se tiene que hacer un trabajo extra de diseño e integración. Dedicar más tiempo al análisis y levantamiento de la información además del seguimiento a esta. Los componentes suministrados por el cliente tienen poca calidad, por lo que tienen que hacerse trabajos extra de comprobación, diseño e integración. Agendar reuniones con el cliente para revisión y mejor entendimiento de los componentes entregados Cliente El tiempo de comunicación del cliente (por Acudir a otras instancias de ejemplo, tiempo para responder a las preguntas comunicación para acelerar y dar para aclarar los requisitos) es más lento del seguimiento exhaustivo esperado. Abultar tiempos para así poder El cliente piensa en una velocidad de desarrollo mostrar al cliente que los tiempos que el personal de desarrollo no puede alcanzar. originales se rebajan. Diseño e Implementación Un mal diseño implica volver a diseñar e implementar. Revisar las principales aristas del proyecto y sus requerimientos generando maquetas funcionales para obtener la aprobación del cliente. Valor 3 3 2 1 1 2 4 4 Se ha sobreestimado el ahorro en la Evitar el uso de herramientas planificación derivado del uso de herramientas nuevas y solo enfocarse en las para mejorar la productividad. que ya se tenga experiencia Diseño e Implementación 2 Revisar puntos en los que se pueda requerir uso de herramientas o soluciones complejas y documentar fuertemente estos puntos 4 La fecha final ha cambiado sin ajustarse al Elaboración de Re planificar e incluir horas de ámbito del producto o a los recursos la Planificación trabajo extra. disponibles. 4 Realizar distribución de carga No hay suficiente personal disponible para el acorde a los niveles técnicos y de proyecto. compromiso 2 Capacitar a las personas más Se necesitan personas para el proyecto con idóneas para involucrarlas al habilidades muy específicas y no se encuentran. proyecto 2 Un diseño demasiado complejo exige tener en cuenta complicaciones innecesarias e improductivas en la implementación. Personal 4 Potenciar a las personas mediante Las tareas asignadas al personal no se ajustan a capacitaciones para elevar su sus posibilidades. nivel Avanzar con punto futuros del proyecto para que al momento de La burocracia produce un progreso más lento llegar a ellos no se encuentren sin del esperado. avance de forma de minimizar el impacto por demoras. Proceso Requisitos 1 1 La falta de rigor (ignorar los fundamentos y estándares del desarrollo de software) conduce a fallos de comunicación, problemas de calidad y repetición del trabajo. Un consumo de tiempo innecesario. Producto 2 Se verificará que todos los desarrollos se encuentren bajo los estándares y además se debe probar la integración continua de los modúlos. 3 Se analizar más a fondo los Los módulos propensos a tener errores necesitan puntos que puedan resultar más trabajo de comprobación, diseño e complejos para diseñar una implementación. solución más flexible 3 El desarrollo de una interfaz de usuario Verificar con el usuario que la inadecuada requiere volver a diseñarla y a interfaz diseñada se encuentra implementarla. dentro de lo requerido. 1 La planificación debe apegarse a El desarrollo de funciones software que no son los requerimientos y a los casos necesarias alarga la planificación. de uso para evitar trabajo innecesario. 3 Revisar junto con el cliente los Los requisitos no se han definido correctamente nuevos requisitos y definir y su redefinición aumenta el ámbito del nuevas iteraciones que incluyan proyecto el control de cambios 3 Revision de etapas del desarrollo Las partes del proyecto que se no se han que no hayan sido analizadas en especificado claramente consumen más tiempo su totalidad y solicitar el del esperado. compromiso del cliente frente a situaciones de duda. Continuamente se harán entregas En último momento al usuario final no le agrada Usuarios Finales al cliente de módulos funcionales el producto y debe ser rediseñado y recreado. para rediseñas etapas futuras. 2 1 Gestión de la configuración de software (SCM) La configuración del Software necesario para el proyecto de sistema de indexado y gestión de archivos (SICA), corresponde a la lista presentada a continuación: Plan de Gestión de la configuración. Documento de definición de requerimientos. Estándares de diseño, programación, pruebas. Especificaciones de prueba del sistema. Plan de pruebas del sistema. Código fuente del programa. Código objeto y ejecutable. Especificaciones de pruebas de unidad. Planes de pruebas de unidad. Documentos de diseño de base de datos. Datos de prueba. Procesos Asociados Con el objetivo de certificar el correcto cumplimiento del proyecto y proveer una alta calidad del producto a desarrollar, se realizaran procesos anexos al Proceso de Gestión de Configuración. El proceso se compone de los siguientes elementos: 1. Implementación del Proceso: La implementación del proceso incluye la generación de un plan que describa los pasos de la gestión de configuración, los procedimientos y la planificación para su realización, y los responsables de dichas actividades. Todo esto debe se encontrará documentado. 2. Identificación de la Configuración: Se establecerá un esquema de identificación de los elementos de software y las versiones a ser controlados dentro del proyecto. 3. Control de la Configuración: Se llevará registro de las solicitudes de cambio, se analizarán y evaluación los cambios, se aprobará o rechazará, se implementará, verificará y distribuirá el elemento de software modificado. Se generará documento en donde se centralizaran todas las solicitudes y su estado final. 4. Contabilidad de Estado de la Configuración: Se prepararán archivos de registros históricos que incluyan toda la información necesaria para administrar la configuración de manera efectiva, estados de la implementación y cambios propuestos. 5. Evaluación de la Configuración: Se revisará los tipos de elementos de configuración, relaciones, atributos y valores asociados, estructura de la base de datos, derechos de acceso. Se determinará y asegurará que los elementos de software sean funcionales de acuerdo al requerimiento aceptado. 6. Gestión de actualización y distribución: Se asegurará que los responsables de los elementos de configuración actualicen los históricos de estos elementos con los cambios implementados. 7. Gestión de Auditoria y revisión: Se deberá validar que se haya ejecutado solamente lo solicitado y aprobado a fin de asegurar que los componentes estén en un estado apropiado a través de todo el ciclo de vida del producto y que el mismo sea una colección bien definida de componentes. Subversion Para el manejo de versiones se utilizará “Subversion”. Una de las ventajas de “Subversión” es que cada uno de los archivos versionados cuenta con un número de revisión independiente (a diferencia de CVS). Todo el repositorio tiene un único número de versión que identifica un estado común de todos los archivos del repositorio en un instante determinado. “Subversion” puede acceder al repositorio a través de redes locales o bien a través de internet, lo que le permite ser usado por personas que se encuentran en distintos ordenadores y ubicaciones físicas. Una de las ventajas de esta herramienta es que permite que varias personas puedan acceder y modificar al mismo tiempo un grupo de archivos y al momento de terminar sus modificaciones, puedan integrarlas sin problemas con los desarrollos de otras personas. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razón para temer por que la calidad del mismo vaya a verse afectada, sí se ha hecho un cambio incorrecto a los datos, simplemente el cambio puede ser deshecho volviendo a una versión anterior o estable. La estructura habitual de un repositorio de Subversion es: Trunk: código fuente completo del proyecto. Tags: ubicación de las versiones congeladas. Branches: ubicación con versiones de desarrollo paralelas al trunk. Ventajas Se sigue la historia de los archivos y directorios a través de copias y renombrados. Las modificaciones (incluyendo cambios a varios archivos) son atómicas (Se dice que una operación es atómica cuando es imposible para otra parte de un sistema encontrar pasos intermedios. Si esta operación consiste en una serie de pasos, todos ellos ocurren o ninguno). La creación de ramas y etiquetas es una operación más eficiente; Tiene costo de complejidad constante (O(1)) y no lineal (O(n)) como en CVS. Se envían sólo las diferencias en ambas direcciones (en CVS siempre se envían al servidor archivos completos). Puede accesado mediante Apache, sobre WebDAV/DeltaV. Esto permite que clientes WebDAV utilicen Subversion en forma transparente. Maneja eficientemente archivos binarios (a diferencia de CVS que los trata internamente como si fueran de texto). Permite selectivamente el bloqueo de archivos. Se usa en archivos binarios que, al no poder fusionarse fácilmente, conviene que no sean editados por más de una persona a la vez. Cuando se usa integrado a Apache permite utilizar todas las opciones que este servidor provee a la hora de autentificar archivos (SQL, LDAP, PAM, etc.). Desventajas El manejo de cambio de nombres de archivos no es completo. Lo maneja como la suma de una operación de copia y una de borrado. No resuelve el problema de aplicar repetidamente parches entre ramas, no facilita llevar la cuenta de qué cambios se han realizado. Esto se resuelve siendo cuidadoso con los mensajes de commit. Para el manejo de SVN bajo consolas UNIX, no está soportada la posibilidad de auto completar la URL empleando el tabulador (posibilidad que sí soportan todas las shell de UNIX para los comandos estándar y los ejecutables añadidos al path o residentes en el directorio local). Existen varias interfaces a Subversion, ya sea programas individuales como interfaces que lo integran en entornos de desarrollo. TortoiseSVN. Provee integración con el explorador de Windows. Subclipse. "Plugin" que integra Subversion al entorno Eclipse. Subversive. "Plugin" alternativo para Eclipse. ViewVC. Interfaz Web, que también trabaja delante de CVS. Para mac, pueden emplearse los interfaces SvnX, RapidSVN y Zigversion RapidSVN también corre en Linux. RabbitVCS Para el administrador de archivos Nautilus del escritorio GNOME, inspirado por TortoiseSVN. KDESvn. Provee integración con el escritorio KDE, muy parecido en apariencia/funcionamiento/características a TortoiseSVN Easyeclipse, es un paquete basado en eclipse es una plataforma de desarrollo, con algunos plugins de código abierto. sventon Interfaz Web Versions Interfaz de escritorio para Mac OS X AnkhSVN "Plugin" para Visual Studio para versiones 2002, 2003, 2005, 2008 y 2010, esta última en modo experimental. Gestión de aseguramiento de la calidad de software (SQA) El propósito del aseguramiento de la calidad de software es entregar a la administración una visibilidad adecuada del proceso utilizado y los productos construidos mediante acciones planificadas y sistemáticas que aseguren la calidad de dichos procesos y productos. Este control debe poder permitir la retroalimentación del sistema desarrollado. Los objetivos principales se SQA son: Planificar las actividades de SQA. Verificar el cumplimiento de los productos de trabajo y de las actividades a los estándares, procedimientos y requerimientos establecidos. Informar a los individuos o grupos sobre las actividades de SQA y sus resultados. Comunicar a la administración superior sobre desviaciones no resueltas dentro del proyecto. Para cumplir con estos objetivos, se deberán realizar las siguientes tareas: Se generarán conjuntos de funciones de auditoría e información con el propósito de evaluar la efectividad respecto de que tan completas serán las actividades de control de calidad. Se tendrá como meta brindar al encargado del Proyecto (Jefe de Proyecto) los datos necesarios para que esté informado acerca de la calidad del producto que se generará. En caso de identificar problemas durante el proceso de aseguramiento de la calidad, se deberá realizar seguimiento de estos durante el proceso de resolución. Función del Aseguramiento de la Calidad de Software Se realizará revisiones y reportes del proceso de SQA. Se proporcionará información acerca de la Calidad del producto al Jefe de Proyecto con el propósito de asegurar que los estándares de calidad que están especificados se están cumpliendo. Lo anterior es con el objeto de Evaluar críticamente el software que se ha desarrollado, comprobar que los estándares de calidad se cumplen, identificar las debilidades que posee el producto antes de que sea entregado al cliente, determinando si el producto que fue desarrollado cumple las necesidades del cliente. Modelo SQA Modelo a Aplicar para el Aseguramiento de la Calidad (SQA) Figura 1. Esquema del modelo para implementar SQA en el Proyecto Detalle de las actividades de la Figura Nro. 1 Preparación del Plan SQA: Se elaborará un plan de pruebas en donde se incluyan los casos de prueba y el resultado que debe ser obtenido. Revisión del Software Control estático del código: Se validará el código contra el conjunto de reglas, mejores prácticas y estándares predefinidos que han sido incorporados dentro del Marco Metodológico. Control dinámico del código: Se enfocará en el uso de los recursos de la aplicación y la cobertura del código dentro de las pruebas unitarias. Actividades de Verificación Verificación de requerimientos: Actividad a realizar con el propósito de validar la claridad, información completa y correcto de los requerimientos asociado al sistema que se probará. Validación y Verificación de Documentación: Actividad a realizar con el objetivo de controlar que la información esté correcta, completa y no exista ambigüedad. Validación de arquitectura: Actividad que será realizada para evaluar la factibilidad de cumplir con los requerimientos del proyectos. Se utilizará además para identificar otros riesgos asociados al proyecto, los cuales no hayan sido identificados al comienzo. Pruebas de Caja Negra: Se realizarán estas pruebas con objeto de validar que efectivamente el sistema realice y cumpla las especificaciones que deba realizar. Pruebas de Caja Blanca: Se realizarán estas pruebas para determinar las partes del código de no hayan sido ejecutadas e identificar y eliminar aquellas sentencias innecesarias dentro del código. Prueba de Sentencias: Se realizarán estas pruebas para evaluar y validar que la totalidad de las condiciones de los programas sean ejecutadas. Objetivo de las Pruebas mencionadas Certificar que las pruebas de caja negra muestren que el software posee una cobertura funcionalmente elevada, idealmente 100%. Observar el código ejecutado buscando que la cobertura de las sentencias sea del 100%. Observar las condiciones “difíciles” del código, a fin de forzar toda la variedad de condiciones que el programa analiza en su ejecución. Documentación: Se realizará documentación de las pruebas realizadas (evidencias) con el propósito de evidenciar que las pruebas de los módulos que conforman el software cumplen con los requerimientos del proyecto. Reporte de Iteraciones: Reporte de todos los errores encontrados a los módulos probados, para su posterior evaluación y corrección por parte de los desarrolladores. El proceso de aseguramiento de la calidad considerará además: Revisar la calidad de los entregables asociados al Proyecto. Revisión del nivel de apego del modelo de proceso de desarrollo de software en conjunto a los planes de verificación. Las responsabilidades que tendrán asignado el grupo de SQA serán las siguientes: Asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el proyecto así como también disminuir la calidad del mismo. Realizar mediciones para comprobar la calidad del proyecto Asegurarse de que se realice la actividad de implementación y se haga según los estándares de calidad propuestos Evitar el desperdicio de esfuerzo dentro del proceso de pruebas. Estándares de desarrollo de software El proyecto tiene como objetivo cumplir con el estándar internacional de evaluación de Software (ISO 9126). El modelo de calidad clasifica la calidad del software en un conjunto estructurado de características y sub características de la siguiente manera: Funcionalidad Conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades especificas. Las funciones son aquellas que satisfacen las necesidades implícitas o explicitas 1. 2. 3. 4. 5. Idoneidad Exactitud Interoperabilidad Seguridad Cumplimiento de normas Fiabilidad Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de presentación bajo condiciones establecidas durante un periodo establecido. 1. Madurez 2. Recuperabilidad 3. Tolerancia a fallos Usabilidad Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la valoración individual de tal uso, por un establecido o implicado conjunto de usuarios. 1. 2. 3. 4. Aprendizaje Comprensión Operatividad Atractividad Eficiencia Conjunto de atributos relacionados con la relación entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas. 1. Comportamiento en el tiempo 2. Comportamiento de recursos Mantenibilidad Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema. 1. 2. 3. 4. Estabilidad Facilidad de análisis Facilidad de cambio Facilidad de pruebas Portabilidad Conjunto de atributos relacionados con la capacidad de un sistema para ser trasferido desde una plataforma a otra. 1. 2. 3. 4. Capacidad de instalación Capacidad de reemplazo Adaptabilidad Co-Existencia Este estándar provee un entorno para que las organizaciones definan un modelo de calidad para el producto (software), llevando a cada organización la tarea de especificar precisamente su propio modelo. Por ende el proyecto debe cumplir con los estándares de calidad establecidos por el Banco Santander. Estándares de generación de bases de datos 1. Modelo y Diseño 1.1. Estandarización de términos Establecer convenciones en el nombrado de las bases de datos y sus objetos, estandarizarlo y apegarse a él. Reduciendo confusiones y perdidas de semántica de los objetos a crear. 1.1.1. Convenciones de Modelo y Base de Datos Los nombres de las dentro del modelo de clases deben estar en singular y con capitalización Pascal. (Ej.: Persona, PersonaGrande). Los nombres de las tablas del modelo deben estar en plural y usando guion bajo. Las tablas subyacentes para los modelos arriba mencionados serian persona y persona_grande respectivamente. 1.1.2. Nombre de Campos Los nombres de los campos con dos o más palabras se definen con guiones bajos y en minúscula: nombre_y_apellidos. 1.1.3. Llaves primarias Todas las tablas del modelo deben tener una clave primaria simple que identifique inequívocamente cada fila. 1.1.4. Llaves foráneas El nombre por defecto de las claves foráneas en relaciones hasMany, belongsTo o hasOne, es el nombre de la tabla relacionada (en singular) seguido de _id. Así si Panadero hasMany Tarta referenciara la tabla panaderos mediante la clave foránea de panadero_id. Para una tabla compuesta por varias palabras como tipo_categorias, la clave foránea seria tipo_categoria_id. 1.2. Normalización y Rendimiento Asegurarse de normalizar los datos cuando menos hasta la tercera forma normal, sin comprometer el rendimiento. Esto otorgara mejores tiempos de respuesta y congruencia del modelo físico. 1.3. Manejo de Textos y BLOB Evitar el guardar este tipo de datos en la base de datos y guardar en su lugar la ruta en donde se encuentra el fichero a fin de que el software correspondiente lo manipule correctamente reduciendo así los tiempos de respuesta. 1.4. Manejo de Valores Nulos Minimizar el uso de valores nulos para efectuar una captura más completa de la información. Evitando la malinterpretación de los datos ausentes y tiempo de acceso al convertir un campo inexistente a nulo al desplegarse. 1.5. Uso de diccionario de datos Optimizar y estandarizar el dominio de datos a utilizarse en los atributos minimizando el riesgo de capturar valores incongruentes. Estos tipos de datos deben estar definidos por usuario, si una columna en particular se repite en varias tablas de tal forma que el dominio será consiste en todas las tablas. 1.6. Análisis de requerimientos y utilización de índices Es de vital importancia que mediante análisis se obtengan cuales serán las consultas más populares, de tal forma que la información pueda indexarse y aprovechar el acceso prácticamente directo que nos permiten los arboles al generar los índices correspondientes y actualizar el plan de acceso. Lo que conlleva a diseñar las entidades identificando cuáles serán sus consultas, llaves primarias, foráneas e índices. 1.7. Generación y Ejecución de SQL dinámico El uso de SQL dinámico da la posibilidad de que un usuario inyecte código y elimine o corrompa información. A su vez cada ejecución de este tipo de código requiere compilación y la generación de su respectivo plan de ejecución, afectando así el rendimiento. 2. Programación 2.1. Convenciones a la hora de programar Las palabras reservadas a sintaxis SQL utilizarán capitalización Versal (palabras en mayúsculas), todo lo demás debe estar en minúscula. En cuanto a la indentación se espera alcanzar un desarrollo similar al obtenido en el punto 2 de indentación de los estándares de programación. 2.2. Documentación de objetos SQL Documentar los procedimientos almacenados, triggers y demás programas, reduciendo los tiempos de mantenimiento. 2.3. Detalle de atributos en la inserción, consulta o actualización Evitar SELECT * en consultas. Al mencionar los campos que se requieren el acceso a disco es más rápido. 2.4. Uso de cursores como simulación de programación estructurada Omitir el uso de cursores en el servidor, ya que estos simulan la programación procedural sino se hacen con cuidado y se comienzan a anidar formando exponencialmente arboles, gastando recursos y por tanto tiempo de ejecución. 2.5. Uso de comodines Evitar el uso de comodines al inicio de la palabra, LIKE ‘%pples’. Ya que el optimizador realiza búsquedas secuenciales, provocando problemas de concurrencia y tiempos de respuesta inaceptables. 2.6. Uso de Operadores No realizar búsquedas por operadores de desigualdad (<>,not). Dado que el optimizador no tiene una constante a buscar en el árbol, realizando un barrido de todo el árbol de índices. 2.7. Uso de constraints para chequeo de integridad referencial El uso de constraints es una forma de reducir el dominio de los datos. Chequeando integridad referencial vía constraints, si la complejidad es mayor se recomienda la utilización de triggers. 2.8. Manejo de transacciones Cuando se modifica/inserta/borra registros en tablas. El manejador aloja candados para ese recurso a nivel de registro/pagina/tabla. Si existe otro proceso que desea acceso a dicha pagina, no necesariamente al mismo recurso y dicho recurso está bloqueado, el proceso no puede ejecutarse. Por lo tanto es recomendable que las transacciones sean lo más cortas posibles y incorporar un commit cada cierto número de registros. Directrices generales para nombres Todos los objetos de la base de deben seguir el próximo listado de convenciones generales de nombramiento. Los nombres de los objetos solo pueden contener letras [a-z][0-9] y guion bajo. Los nombres deben empezar con un carácter. Los nombres no pueden ser palabras reservadas de sintaxis SQL. Convenciones Las convenciones de nombres son presentadas como patrones compuestos por uno o más de los próximos elementos: Guion bajo: Las palabras que conformen el nombre de algún objeto están separadas por guion bajo para mejorar legibilidad. Sustituciones: Indica que el elemento está compuesto por caracteres entregados por el usuario y representados por caracteres en cursiva. Constantes: Representados por caracteres que no se encuentren en cursiva. Corchetes: indican que los caracteres contenidos son solo incluidos bajo condiciones específicamente definidas. Estándares de generación de interfaces El diseño web y aplicaciones involucran un estándar para construir y representar las páginas web, cabe mencionar tecnologías tales como HTML, CSS, SVG y AJAX. 1. HTML & CSS HTML y CSS son las tecnologías fundamentales para construir páginas web. HTML(html y xhtml) es utilizado para estructurar una página, mientras que CSS define los estilos y disposición de elementos. 2. Scripting y Ajax Un script es código de programa que no requiere de pre-procesamiento (ej: compilación) antes de ejecutarse. Dentro del contexto de un explorador web el scripting usualmente es código JavaScript que es ejecutado por el explorador al momento de cargar una página o producto de una acción realizada por el usuario cuando este gatilla algún evento. 2.1. DOM (Document Object Model) DOM es una interfaz base de programación de aplicaciones que proporciona un conjunto estándar de objetos para representar documentos HTML y XML. Estas representaciones le permiten a los programas y scripts ingresar de manera dinámica actualizado el contenido, estructura y estilos de los documentos a los cuales ingresan. El responsable del desarrollo y mantenimiento de DOM es la W3C (World Wide Consortium). 3. Arquitectura de la información La arquitectura de la información es la ciencia detrás de averiguar cuál es el objetivo de un sitio o aplicación web. Para después construir un prototipo de este antes de armar cualquier aplicación. Primero se definen los fines del sitio, destacando aquellos de mayor relevancia producto de opiniones emitidas por los clientes, ensamblándolos de manera coherente y priorizada. 3.1. Secciones y Distribución de Formularios Los elementos enumerados a continuación están ordenados según importancia visual de mayor a menor. Head de página (Contenedor de Logos Clientes ) Menú Principal Aplicación Formulario de búsqueda Formularios dependientes del menú Botonera Pie de Pagina 3.2. Layout y prototipo (Layout definido) Una vez aprobado por layout (blueprint) por el cliente se generó un prototipo funcional desplegado a continuación. (Prototipo Funcional) Estándares de generación de programación 1. Porque tener convenciones de programación Las convenciones de código son importantes para los programadores por una serie de razones: 80% del costo en el ciclo de vida de un software se consume en mantenimiento. Es difícil que durante la vida de un software este sea mantenido por el autor original. Las convenciones de código mejoran la legibilidad de un software, facilitándole a los ingenieros la lectura de código. 2. Nombre de Archivos Esta sección enumera los sufijos y nombres más comunes en Java. 2.1. JavaSoft utiliza los siguientes sufijos. Tipo de Archivo Fuentes Java Bytecode Java Sufijo .java .class 2.2. Nombre de archivos comunes Nombre Archivo README Uso El nombre preferido para el archivo que resumirá el contenido de un directorio en particular 3. Organización de Archivos Un archivo consiste en secciones que debería estar separadas por líneas en blanco y con un comentario opcional describiendo cada sección. Los archivos que superan las 2000 líneas de código son incomodos y deberían evitarse. 3.1. Archivos Fuentes Java Cada archivo fuente contiene una clase publica o interface. Cuando existan clases y/o interfaces asociadas a una clase publica, es posible incluirlas en el mismo archivo. Donde la clase o interface publica debería estar al inicio de este. Los archivos obedecen el siguiente orden: Comentarios de Inicio Package y sentencias de importación; por ejemplo: import java.applet.Applet; import java.awt.*; import java.net.*; Declaración de clases e interfaces 3.1.1. Comentarios de Inicio Todos los archivos fuente deberían iniciar con un comentario que le describa al programador el propósito del programa. Por Ejemplo: /* * NombreClase * * Información de la Versión * */ 3.1.2. Package y sentencias de importación La primera línea no comentada de la mayoría de los archivos java debe ser la declaración package. Después de esto vienen las sentencias import. Por Ejemplo: package java.awt; import java.awt.peer.CanvasPeer; 3.1.3. Declaración de clases e interfaces La siguiente tabla describe las partes de una declaración de clase o interface, en el orden que deberían aparecer. Nº 1 2 3 4 5 6 7 Estructura de Clase o Interface Documentación de clase o interface Declaración de clase o interface Comentario de implementación de clase o interface en caso de ser necesario Variables estáticas de clase Variables de instancia Constructores Métodos 4. Indentación Cuatro espacios deberían ser utilizados como unidad de indentación. La constitución exacta de la indentación (espacios vs tabulación) no está especificada. La tabulación debe estar configurada cada 8 espacios (no 4). 4.1. Largo de Línea Evitar líneas de largo mayor a 80 caracteres. En caso de ser un comentario se recomienda que este no supere los 70 caracteres. 4.2. Envase de Líneas (Wrapping) Cuando el largo de una expresión no se ajuste a una línea, cortar está acorde a reglas generales: Partir después de una coma. Partir antes de un operador. Alinear la nueva línea con el inicio de la expresión en el mismo nivel que la línea anterior. Si las reglas anteriores llevan a un código confuso, solo aplicar indentación de 8 espacios. 5. Declaraciones 5.1. Numero por Línea Se recomienda una declaración por línea. int nivel; int fuente; En absolutamente en ningún caso se debería declarar variables y métodos en la misma línea de código. long numeroLargo, getNumeroLargo(); 5.2. Colocación Situar las declaraciones solo al inicio de un bloque (Un bloque es cualquier código encapsulado dentro de corchetes {}). void miMetodo() { Int int1; if (condicion) { int int2; … } } 5.3. Inicialización Tratar de inicializar las variables locales en la misma línea donde son declarados. La única razón para no inicializarlas en el mismo lugar es porque estas dependen de algún evento. 5.4. Declaraciones de Interfaces y Clases Cuando se programan clases o interfaces en Java se recomienda seguir las siguientes reglas: No deben existir espacios entre el nombre de un método y el paréntesis Los métodos deben estar separados por una línea en blanco 6. Sentencias 6.1. Sentencias simples Cada línea del archivo debería contener al menos una sentencia. Exemplo: arg++; argc--; //EVITAR; 6.2. Sentencias compuestos Las sentencias compuestas contienen una serie de expresiones encapsuladas en corchetes. Las sentencias encapsuladas están pensadas para estar a un nivel más que la sentencia compuesta. La apertura del corchete debería ser al final de la sentencia en donde se declara aquella que es compuesta. Y el corchete de cierre debería estar en una línea aparte de las demás sentencias, una vez finalizado el bloque. 6.3. Sentencias de retorno Una sentencia de retorno con un valor no debería usar paréntesis a menos que haga el valor a retornar más obvio. Ejemplo: return; return miDisco.memoriaLibre(); retrun (peso ? peso : pesoDefecto); 6.4. Sentencias if, if-else, if-else-if-else Una sentencia if debería tener el siguiente formato: if (condicion) { Sentencias; } if (condicion) { Sentencias; } else { Sentencias; } if (condicion) { Sentencias; } else if (condicion) { Sentencias; } else { Sentencias; } Observación: las sentencias if siempre deben usar corchetes {}. Evitar la próxima sentencia propensa a error: if (condicion) Sentencias; 6.5. Sentencias for Una sentencia for debería tener el siguiente formato: for (inicialización; condición; actualización){ … } 6.6. Sentencias while Una sentencia do-while debería tener el siguiente formato: while (condicion){ … } Una sentencia do-while debería tener el siguiente formato: while (condicion); 6.7. Sentencias do-while Una sentencia do-while debería tener el siguiente formato: do { … } while (condicion); 6.8. Sentencias switch Una sentencia do-while debería tener el siguiente formato: switch (condicion) { case ABC; sentencias; case DEF; sentencias; default: sentencias; break; } 6.9. Sentencias try-catch Una sentencia try-catch debería tener el siguiente formato: try{ … } catch (Exception e){ … } 7. Espacios en blanco 7.1. Líneas en Blanco Las líneas en blanco mejoran la legibilidad por generar secciones de código que están lógicamente relacionados. Dos líneas en blanco deberían ser usados en las próximas circunstancias: Entre secciones de un archivo fuente. Entre las definiciones de clases e interfaces Una línea en blanco debería ser usado siempre en las próximas situaciones: Entre métodos Entre las variables locales en un método y su primera sentencia. Antes de un bloque o comentario de línea simple. Entre secciones lógicas dentro de un método para mejorar legibilidad. 7.2. Espacios en Blanco Los espacios en blanco deberían ser utilizados en las próximas circunstancias: Una palabra clave seguido de un paréntesis while (true) { … } Un espacio debería aparecer después de una coma en la lista de argumentos En todas las operaciones binarias, exceptuando aquellas que correspondan a operaciones unarias. Ejemplo: c += c + d; c = (a + b) / (c * d); Las expresiones contenidas en un bucle for. Ejemplo: for (exp1; exp2; exp3) En cualquier tipo de casteo. Ejemplo: miMetodo((byte) unNumero, (Objeto) x); 8. Convenciones de Nombres Las convenciones de nombres hacen que los programas sean comprensibles por hacerlos más fáciles de leer. Estos también pueden entregar información sobre la función del identificador. 8.1. Estilos de capitalización Se contemplara tres estilos de capitalización distintos, que se utilizarán en determinados casos. 8.1.1. Capitalización Pascal En este estilo se capitaliza la primera letra de cada palabra: TestYou, ValorNulo. 8.1.2. Capitalización Camel En este caso otro estilo se capitaliza la primera letra de casa palabra excepto la primera: testYou, valorNulo. 8.1.3. Capitalización Versal Es aquella en la que se escribe en mayúsculas. En nuestro proyecto utilizaremos la capitalización versal para las constantes que se pudieran definir. Tipo identificador Clases Interfaces Métodos Variables Reglas para nombrar Los nombre de las clases deben ser sustantivos con capitalización Pascal. Evitar el uso de acrónimos y abreviaciones. Los nombres de interfaces deberían tener la misma capitalización que las clases (Pascal) Los métodos deberían ser verbos, capitalización Pascal Ejemplos class Raster; class ImageSprite; interface RasterDelegate; interface Storing; run(); runFast(); getBackground(); A diferencia de las clases, int i; interfaces y métodos las char *cp; variables utilizaran float myWidth; capitalización Camel. Los nombres deben ser cortos pero significativos. Deberían ser mnemotécnicos. Los nombres de las variables int MIN_WIDTH = 4; declaradas contantes de clase int MAX_WIDTH = 999; deberían estar con capitalización Versal separando las palabras con guion bajo. Constantes 9. Prácticas de Programación 9.1. Proporcionando acceso a instancias y variables de clase No generar ninguna instancia o variable de clase publica sin una buena razón aparente. 9.2. Referencias a variables de clase y métodos Evitar el uso de un objeto para ingresar a una variable o método de una clase (estática). Utilizar el nombre de una clase en su lugar. Por ejemplo: classMethod(); AClass.classMethod(); //OK //OK anObject.classMethod(); //EVITAR 9.3. Constantes Constantes numéricas (literales) no deberían codificarse directamente, exceptuando -1,0 y 1 los cuales pueden aparecer en bucles for como contadores. 9.4. Asignación de variables Evitar asignar varias variables al mismo valor en una sola declaración. Es difícil de leer. Ejemplo: fooBar.fChar = fooBar.lChar = ‘c’ //EVITAR No utilizar operadores de asignación en un lugar donde fácilmente puede ser confundido por un operador de igualdad. Ejemplo: if (c++ = d++) { … } Representar de la siguiente forma if ((c++ = d++) != 0) { //EVITAR … } No utilizar asignaciones incrustadas en un intento de mejorar el rendimiento en tiempo de ejecución. Esto es trabajo del compilador. Ejemplo: d = (a = b + c) + r; //EVITAR Representar de la siguiente forma a = b + c; d = a + r; 9.5. Practicas Diversas 9.5.1. Paréntesis Generalmente es una buena idea utilizar paréntesis deliberadamente en expresiones involucrando operadores mixtos. if (a == b && c == d) //EVITAR if ((a == b) && (c == d)) //OK 9.5.2. Retorno de Valores Tratar de hacer que la estructura del programa coincidir la intención. Ejemplo: if (expresionBooleana){ retrun TRUE; } else { return FALSE; } Debería ser escrito retrun expresionBooleana; 9.5.3. Expresiones antes de ‘?’ en el operador condicional Si una expresión contiene un operador binarios antes de ?, este debería estar en paréntesis. Ejemplo: (x >= 0) ? x : -x; 9.5.4. Comentarios Especiales Usar XXX en un comentario para marcar algo que es falso pero funciona. Usar FIXME para marcar algo que es falso y interrumpido. Elección de la herramienta de desarrollo 1. Lenguaje Para efectos de desarrollo, el lenguaje de programación seleccionado fue Java. Lo que llevo a esta determinación fue una sumatoria de razones, de las cuales cabe mencionar: -El que no existe ningún tipo de limitante por parte del cliente en cuanto a las tecnologías a utilizar. -Extenso conocimiento y experiencia por parte del equipo de desarrollo en el uso de estas tecnologías. -Plasmar parte de la filosofía de Java en el ciclo de vida del proyecto (permitir la ejecución de la aplicación en múltiples sistemas operativos y tomar lo mejor de otros lenguajes como C++). -Trabajar y promover el uso de tecnologías open-source. -Las herramientas que serán utilizadas en el desarrollo están desarrolladas en el mismo lenguaje Java. 2. Herramienta: NetBeans Seleccionado el lenguaje el paso lógico sería determinar la herramienta de desarrollo a utilizar. Siguiendo la filosofía open-source quien cumplía con las expectativas era Netbeans 6.9, por ser un entrono de desarrollo integrado para desarrolladores. Del cual se pueden obtener todas las herramientas necesarias para crear aplicaciones destinadas a equipos de escritorio, empresariales, web y dispositivos moviles. Esto también permite trabajar con otros lenguajes como lo son C/C++, PHP, JavaScript, Groovy y Ruby. Netbeans es la primera herramienta de desarrollo en proveer soporte completo para trabajar con Java EE 6, aparte de contar con los controladores listos para trabajar inmediatamente con MySQL y PostgreSQL. Esto último no quiere decir que no se trabajen con otros motores pero es necesario instalar y configurar los controladores necesarios. 3. Herramienta: IReport Existe muchas formas de agregar reporteria a una aplicación, para muchos desarrolladores web, crear un reporte significa crear una nueva página web, lo que visualmente se ve bastante bien en un monitor pero el resultado es bastante pobre al minuto de imprimirlo en papel. Generar reportes en formato PDF le significa a los desarrolladores escribir bastante código, haciendo los reportes difíciles de mantener y largos de codificar. El problema no varía mucho trabajando con otras tecnologías. La respuesta a estos problemas es IReport es un diseñador visual de reportes open-source, donde es posible llevar a cabo despliegues sofisticados con gráficos, imágenes, sub reportes y tablas cruzadas. También es posible exportar estos reportes generados a múltiples formatos como lo son PDF, open office, DOCX, HTML y muchos otros. 4. Base de Datos: PostgreSQL PostgreSQL es un sistema bastante potente de base de datos objeto-relacional open-source. Tiene más de 15 años de desarrollo activo con una arquitectura probada que lo ha hecho merecedor de una irrefutable reputación por confiabilidad, integridad de datos y exactitud. Es posible instalarlo en la mayoría de los sistema operativos, incluyendo Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows. Las características mencionadas y otras más llevaron a seleccionar a PostgreSQL en su versión 8.3.x como motor por excelencia del proyecto. Planificación El equipo de desarrollo está compuesto por dos desarrolladores, de los cuales uno de ellos asumirá un rol dual, tanto para el desarrollo como para gestión del proyecto. Se dará inicio al proceso de desarrollo el 9 de Agosto del año en curso. Considerando como feriados el 18 y 19 de Septiembre, 11 y 31 de Octubre. Los módulos contemplados para el desarrollo del proyecto son: 1. Ciclo Uno (Interfaz) o Interfaz y prototipos funcionales o Autenticación o Mantenedor de Usuarios 2. Ciclo Dos (Verificación) o Modulo de Verificación o Carga de imágenes o Iteraciones ciclo uno 3. Ciclo Tres (Indexación) o Modulo de Indexación o Distribuidor de Imágenes o Convertidor de formatos o Iteraciones ciclo dos 4. Ciclo Cuatro (Arqueo) o Modulo de arqueo y digitalización de garantías o Mantenedor de bienes o Iteraciones ciclo tres 5. Ciclo Cinco (Reportes) o Motor de reportes web o Tareas programadas (cron y batch) o Iteraciones ciclo cuatro o Instalación en producción Esquema Funcional Estimación Estimación en días y horas hombre involucradas en el desarrollo del proyecto donde se desina un 30% de horas de desarrollo a Pruebas (QA). Carta Gantt