Marco Metodologico Version Final
Anuncio
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
