plan de administración del proyecto de software unidad...

Plan de administración del proyecto de software

Unidad Administrativa Especial de Parques Naturale s de Colombia

José David Yances Rojas

Samuel Murillo Ariza

Pontificia Universidad Javeriana Facultad de Ingeniería Ingeniería de Sistemas

Octubre de 2008 Bogotá

SIPREDIAL Versión: 1.0 Aplicación Practica Fecha: 12/02/2009 Unidad Administrativa Especial de Parques Naturales de Colombia

Aplicación Práctica UEAPNNC

1

HISTORIA DE REVISIÓN

Versión Fecha Descripción Responsable

1.0 7/10/2008

Revisión del alcance y propósito del proyecto, asignación de

responsabilidades, revisión de las actividades de trabajo.

José David Yances-Samuel

Murillo

1.1 13/10/2008 Revisión final del documento del SPMP y los casos de uso

José David Yances-Samuel

Murillo



2

PREFACIO

El propósito de este documento es mostrar la manera como el equipo de trabajo integrado por los

estudiantes se organizó, para realizar el proyecto practico en la Unidad Administrativa Especial de

Parques Naturales de Colombia (UEAPNNC).

Describe como se abordo el proyecto, que consideraciones se tuvieron en cuenta, y la manera como

el producto final se integrara en el entorno de la entidad.



3

TABLA DE CONTENIDO Historial de Cambios………………………. ......................................................................................................1 Prefacio ............................................................................................................................................................2 Tabla de Contenido ..........................................................................................................................................3

1.1. Sumario del Proyecto ............................................................................................................................4 1.1.1. Propósito, Alcance y Objetivos.................................................................................................4 1.1.2. Asunciones y Restricciones .....................................................................................................5 1.1.3. Entregables del Proyecto .........................................................................................................5 1.1.4 Resumen de calendario y presupuesto ……………………………………….………………………7

1.2. Evolución del Plan ................................................................................................................................7 2.0. Referencias ..........................................................................................................................................8 3.0. Definiciones y acrónimos .....................................................................................................................8 4.0. Organización del Proyecto ........................................................................................................................9

4.1 Interfaces Externas ..........................................................................................................................9 4.2 Estructura Interna.............................................................................................................................9

5.0. Planeación de Procesos Gerenciales ................................................................................................ 11 5.1 Plan de Arranque ........................................................................................................................... 11 5.1.1 Plan de estimación…………………………………………………………..………………………….. 11 5.1.2 Plan de manejo de personal ……………………………………………………………..……………..12 5.1.3 Plan de adquisición de recursos…………………………………………………………..……….…...12 5.1.4 Plan de entrenamiento para el personal del proyecto…………………………………………..……12 5.2 Plan de Trabajo .............................................................................................................................. 13

5.2.1 Actividades de Trabajo ........................................................................................................... 13 5.2.2 Asignación de agenda ............................................................................................................ 15 5.2.3 Asignación de Recursos ............................................................................................................ 16 5.2.4 Asignación de Presupuesto ................................................................................................... 16

5.3 Plan de Control .............................................................................................................................. 16 5.3.1 Plan de Control de Requerimientos ....................................................................................... 16 5.3.2 Plan de Control de Cronograma............................................................................................ 16 5.3.3 Plan de Control de Presupuesto ............................................................................................ 17 5.3.4 Plan de Control de Calidad .................................................................................................... 17

5.4 Plan de administración de riesgos ................................................................................................ 19 5.5 Plan de Clausura............................................................................................................................ 20

6.0. Plan de Procesos Técnicos ................................................................................................................ 21 6.1 Modelo de procesos ………………………………………………………………………………………….. 21 6.1.1 Actividades de iniciación del proyecto…………………………………………………………………..21 6.1.2 Actividades de terminación del proyecto ……………………………………………………………….21 6.1.3 Puntos de control……………….………………………………………………………………………......21 6.2 Métodos, herramientas y técnica.…………………………………..………………………………………..21 6.2.1 Metodología de desarrollo…………………………………………………………………………...…….21 6.2.2 Plan de herramientas a utilizar………………………………………………………….……….………..22 6.3 Plan de infraestructura…………………………………………………………………………………….…....22 6.4 Plan de aceptación del producto……………………………………….………………………………….......23 Anexos…………………………………………………………………………………………………………………...24



4

PLAN DE MANEJO DEL PROYECTO DE SOFTWARE

1.1 Sumario del Proyecto

1.1.1. Propósito alcance y objetivos del proyecto

El propósito de este documento es analizar los aspectos relevantes, que se tendrán en cuenta durante

las etapas de diseño, implementación e instalación del producto, teniendo en cuenta las necesidades

mencionadas por los funcionarios de la entidad. Se pretende diseñar, implementar, probar e instalar

un producto que permita agilizar el saneamiento de los predios que se encuentran dentro de los

Parques Naturales de Colombia.

Describe el alcance que tendrá el proyecto, y las responsabilidades tanto de los estudiantes como de

los funcionarios en cada una de las etapas.

Se espera entregar un producto en una versión estable, que satisfaga los requerimientos acordados,

para ser puesto en producción lo antes posible debido a la necesidad actual, después de haber

pasado por una etapa de pruebas tanto del equipo de trabajo como de los funcionarios y usuarios del

sistema.

Describe todas las consideraciones que se han tenido en cuenta para el cumplimiento satisfactorio

de los siguientes objetivos trazados para el proyecto:

• Realizar un análisis del sistema actual de manejo de la información predial, junto con el

modelo lógico y físico de la base de datos.

• Diseñar un modelo de datos normalizado que facilite la integración de la información

predial (alfanumérica como cartográfica).

• Diseñar, desarrollar e implementar el sistema propuesto que integre el componente

geográfico con los datos alfanuméricos de la base de datos.

• Validar el sistema propuesto, a través de un caso de estudio, con información suministrada

por la Unidad Administrativa Especial de Parques Nacionales Naturales de Colombia



5

1.1.2. Asunciones y Restricciones

Se ha establecido que el principal canal de comunicación entre la entidad y los estudiantes, son el

Ingeniero encargado de la plataforma tecnológica y el Ingeniero encargado del componente predial.

Para todas las fases en la cuales se necesite información y datos, se asume que la información

suministrada por los dos funcionarios es completa, y va orientada a las necesidades de la entidad.

Se parte teniendo en cuenta algunas restricciones tecnológicas de hardware, restricciones de

software, y la manera en cómo debe operar el aplicativo deseado.

Software

La entidad cuenta con un software licenciado a nivel de base de datos y manejo de información

cartográfica, por consiguiente el uso de este software es fundamental.

Hardware

La entidad cuenta con recursos de hardware, los cuales hacen parte de su estructura tecnológica,

integrar el producto final teniendo en cuenta estos lineamientos es fundamental.

Las pruebas se harán con base en la información suministrada por los funcionarios, de dos Parques

Naturales. Esa información será migrada por los estudiantes con ayuda de los funcionarios, una vez

sea aprobado el producto, y la entidad será la encargada de su puesta en producción, migrando la

información necesaria, y administrando el sistema.

1.1.3. Entregables del Proyecto

Los siguientes serán los entregables durante todas las etapas del proyecto.

Documento diagnostico: este documento presenta un análisis de cómo está funcionando el sistema

actual para el manejo de la información predial de los Parques Naturales, identificando las

debilidades y fortalezas. También se espera detallar la estructura tecnológica que se tiene en las

diferentes sedes.



6

Fecha de entrega: Septiembre 12 de 2009, Universidad Pontificia Javeriana.

SPMP: descripción de los lineamientos de proyecto acordados por las partes involucradas.

Fecha de entrega: Octubre 2 de 2008, Universidad Pontificia Javeriana

Octubre 6 de 2008, UEAPNNC

SRS: documento que resume los requerimientos que debe satisfacer el producto final.

Fecha de entrega: Octubre 16 de 2008, Universidad Pontificia Javeriana

Octubre 20 de 2008, UEAPNNC

SDD: diseño del producto, con el cual se van a satisfacer los requerimientos encontrados y

acordados con la UEAPNNC.

Fecha de entrega: Noviembre 20 de 2008, Universidad Pontificia Javeriana

Noviembre 24 de 2008, UEAPNNC

Plan de pruebas: documento que contiene las pruebas que se harán en cada uno de los

componentes, con el objetivo de identificar fallas, minimizando los riesgos y posibles impactos

negativos que tenga el producto cuando este en producción.

Fecha de entrega: Abril 23 de 2009, Universidad Pontificia Javeriana

Abril 27 de 2009, UEAPNNC

Manual de usuario: contiene paso a paso la explicación de las diferentes funcionalidades que tiene

el producto, para los diferentes usuarios, con gráficos describiendo paso a paso el procedimiento.

Fecha de entrega: Abril 9 de 2009, Universidad Pontificia Javeriana

Abril 13 de 2009, UEAPNNC

Manual de instalación: describe la manera como se debe instalar el producto de principio a fin,

mostrando gráficamente los diferentes pasos, probados previamente, asegurando una correcta

instalación.



7

Fecha de entrega: Marzo 16 de 2009, Universidad Pontificia Javeriana

Marzo 20 de 2009, UEAPNNC

1.1.4. Resumen de presupuesto

Presupuesto

Se elaboro una estimación de los gastos necesarios para la realización del proyecto.

Concepto Valor (pesos)

Concepto de papelería

• Impresión

• Papel

• Anillado

240.000

Alimentación y transporte 450.000

Conexión a Internet 480.000

Libros 260.000

Total Gastos 1’430.000

Tabla 1. Gastos del proyecto

1.2. Evolución del plan

Este documento presentará cambios cuando suceda alguna de las siguientes situaciones:

• La UEAPNNC presente algún cambio que no implique modificar los recursos de

software planteados desde el comienzo.

• El cronograma de actividades planteado cambie por petición de alguna de las dos

partes.

• Se genere algún cambio con el ánimo de satisfacer un requerimiento.



8

Para controlar la evolución del proyecto, se llevaran a cabo reuniones semanales entre los miembros

del grupo de trabajo, reuniones semanales con el director de los estudiantes, y reuniones

programadas con la entidad, para mostrar los avances.

2. Referencias

[SOM02] I. Sommerville. Introducción .En: Ingeniería de Software. 6a ed. México: Addison

Wesley; 2002.

[BRU02] B. Bruegge and A. Dutoit. Introducción a la Ingeniería de Software. En: Ingeniería de

Software Orientado a Objetos. 1a ed. México: Prentice Hall; 2002.

[LAR01] C. LARMAN. UML y Patrones: Una Introducción al Análisis y Diseño Orientado a

Objetos. 2a ed. España: Prentice Hall, 2001.

[IEEEQA] IEEE Std. 730-1995, IEEE Standard for Software Quality Assurance Planning

[IEEESA] IEEE-SA Standards Board, Diciembre de 1998.

[IEEESCM] IEEE Std. 828-1998, IEEE Standard for Software ConÞguration Management Plans

[IEEESPMP] IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans

[IEEESRS] IEEE Recommended Practice for Software Requirements Specifications. Estándar

IEEE 830-1998.

[IEEERM] IEEE Std. 1540-2001, IEEE Standard for Software Life Cycle Processes—Risk

Management

3. Definiciones y acrónimos

ArcGis: software orientado a la visualización y manejo de datos geográficos.

Base de datos Oracle 10g: motor de base de datos proporcionada por Oracle Corp.

Borland Together: Software utilizado para la realización de diagramas en la construcción de

software.

Hibérnate: herramienta orientada a la persistencia con bases de datos orientada a objetos y

relacionales.

JAVA: Lenguaje de programación orientado a objetos.

Patrón: solución genérica para un problema recurrente en el desarrollo de software.

SDD: Descripción del Diseño de Software (Software Design Description)

SPMP: Plan de Manejo del Proyecto de Software (Software Project Management Plan).



9

SRS: Especificación de los Requerimientos de Software (Software Requirements Specifications)

4. Organización del proyecto

4.1. Interfaces externas

En la evolución del proyecto, el grupo de trabajo integrado por los estudiantes se relaciona con una

interfaz externa.

La UEAPNNC: es el cliente, donde va a quedar operando el producto final. El equipo de trabajo

interactúa principalmente con dos miembros de la UEAPNNC, ingenieros encargados del manejo

de la plataforma tecnológica, y el componente predial. Ellos son los encargados de suministrar la

información necesaria para las diferentes fases del proyecto. Igualmente, son los encargados de

aprobar los avances realizados, y dar sugerencias correctivas en caso necesario.

Figura 1. Canales de comunicación

4.2. Estructura interna

El equipo de trabajo está conformado por dos integrantes, los cuales tienen una comunicación

constante en reuniones semanales, reuniones semanales con el asesor del proyecto, y reuniones

programadas con el cliente. Debido a que el equipo está conformado por dos integrantes, se tuvo

que realizar una clasificación en cada rol, con el fin de tener una optima sincronización.



10

Arquitecto: José David Yances y Samuel Murillo, tendrán la tarea de diseñar la aplicación,

separando responsabilidades en el diseño del modelo de datos, y el diseño de la aplicación que

interactúa con este modelo.

Desarrollo: José David Yances tendrá a su cargo el desarrollo del producto teniendo en cuenta los

lineamientos del SDD.

Auxiliar de desarrollo: Samuel Murillo contribuirá al desarrollado, esto incluye la aplicación y

construcción del modelo de datos requerido.

Documentación: José David Yances y Samuel Murillo tendrán a su cargo la documentación de cada

uno de los componentes resultantes del producto.

Calidad: José David Yances y Samuel Murillo Ariza serán los encargados de la calidad de los

diferentes componentes, y del producto final que será entregado.

Asesor: el Ingeniero Javier López brindara asesoría durante la elaboración del producto. Su

aprobación al producto final será de carácter obligatorio.

Figura 2. Comunicación entre los roles



11

5. PLAN DE ARRANQUE

5.1 Plan de Arranque

5.1.1. Plan de estimación

Para estimar los costos de realización de nuestro proyecto, tendremos en cuenta los costos directos e

indirectos, así como el presupuesto realizado anteriormente [Numeral 1.2.4.Presupuesto]

COSTOS DIRECTOS

ACTIVIDAD Unidad Cantidad Valor unitario Total Costo

Valor total

RECOLECCION DE INFORMACION Días/hombre 9 20000 180000

ANÁLISIS DE REQUERIMIENTOS Días/hombre 13 20000 260000

DISEÑO DE SISTEMA Días/hombre 39 20000 780000

IMPLEMENTACION Días/hombre 110 20000 2200000

PRUEBAS Días/hombre 30 20000 600000

ENTREGA Días/hombre 4 20000 80000

INSTALACION Días/hombre 2 20000 40000

TOTAL COSTOS DIRECTOS 4.140.000 Tabla 2. Costos directos del proyecto

COSTOS INDIRECTOS

Costos directos 4.140.000 IU (imprevistos y utilidad) 18% Imprevistos= Costo Directo * 5 % $ 207.000 Utilidad= Costo Directo * 13% $ 538.200 Garantía = Costo Directo * 10% $ 414.000 Costo indirecto = Costo directo * IU + Garantía $ 1.159.200

Tabla 3. Costos indirectos



12

COSTO TOTAL

TOTAL COSTOS INDIRECTOS $ 1.159.000

TOTAL COSTOS DIRECTOS $ 4.140.000

TOTAL $ 5.299.000 Tabla 4. Costo total

5.1.2. Plan de manejo de personal

Los integrantes del proyecto tendrán asignados los roles descritos en la sección 4.2, teniendo en

cuenta las habilidades de cada uno. Debido a que el proyecto es una aplicación práctica con fines

educativos, no se va a requerir personal externo.

5.1.3. Plan de adquisición de recursos

En cuanto a los recursos humanos, se cuenta con la participación activa de todos los miembros del

equipo. El proyecto se desarrollará en el lenguaje de programación Visual Estudio .Net versión 6.0,

las licencias de instalación del producto las provee la Universidad, además, en cuanto a los recursos

físicos, todos los miembros del equipo cuentan con al menos un computador personal además de los

disponibles en los laboratorios de la Universidad.

5.1.4. Plan de entrenamiento para el personal del proyecto

El conocimiento previo en el lenguaje de programación Java y base de datos Oracle de los

estudiantes, es fundamental en el desarrollo del proyecto. Los componentes geográficos que

requiere el producto, demandan un estudio por parte de los estudiantes, es por esto que los foros

alimentados por las comunidades de desarrollo en la Web, y los libros son fundamentales. La

investigación en el uso de tecnologías como ArcGis, y su integración con el lenguaje Java estará a

cargo de la totalidad de los integrantes. La tabla resume las principales tecnologías necesarias para

el proyecto.

Componente Producto Nivel de conocimiento Base de datos Oracle Medio Lenguaje de programación Java Medio/Avanzado Componente geográfico ArcGis Bajo/Medio

Tabla 5. Componentes tecnológicos



13

5.2 Plan de trabajo

5.2.1. Actividades de trabajo

A continuación se describen las principales actividades que se realizaran para asegurar la

conclusión del proyecto.

Actividad Involucrados Riesgos

Asignación de roles del equipo Equipo de trabajo No se llega a un acuerdo en la

asignación de responsabilidades

Organización del proyecto Equipo de trabajo/Director No se llega a un acuerdo con el

plan de trabajo a seguir

Reunión inicial de trabajo Equipo de trabajo

Los integrantes del equipo de

trabajo no logran acordar una

fecha teniendo en cuenta sus

actividades laborales

Reunión y acuerdo con el cliente Equipo de trabajo/Cliente

No hay claridad en cuanto al

alcance del proyecto y las

especificaciones que el cliente

quiere del producto

Planificación de duración y costos

del proyecto Equipo de trabajo/Director

No se tienen definidos los costos,

entregables y duración del

proyecto.

Entrega documento diagnostico Equipo de trabajo/Director No se cumple con el cronograma

Construcción de los casos de usos Equipo de trabajo No se cumple con las

especificaciones

Entrega formal del SPMP Equipo de

trabajo/Director/Cliente

No se cumple con las

especificaciones

Entrega formal del SRS Equipo de

trabajo/Director/Cliente

No se cumple con las

especificaciones

Prototipo inicial Equipo de trabajo/Director No se cumple con el cronograma.

Entrega del primer prototipo Equipo de trabajo/Cliente No se cumple con el cronograma.

Diseño de la Arquitectura Equipo de trabajo Los requerimientos no es lo que el

cliente requiere



14

Diseño de Alto y Bajo nivel Equipo de trabajo No es claro el alcance del proyecto

Elaboración SDD Equipo de trabajo No cumpla con las

especificaciones necesarias.

Entrega del segundo prototipo Equipo de trabajo/Director El prototipo no satisface el director

del proyecto

Entrega del segundo prototipo Equipo de trabajo/Cliente El prototipo no satisface el cliente

Integración componentes Equipo de trabajo No hay interoperabilidad entre los

componentes del proyecto

Pruebas Equipo de trabajo Fallo en el resultado de las pruebas

Pruebas Equipo de trabajo/Cliente Fallo en el resultado de las pruebas

Manual de usuario Equipo de trabajo

No se tengan en cuenta las

especificaciones finales del

sistema.

Ajustes Equipo de trabajo/Cliente No se logra realizar los ajustes

necesarios.

Entrega final Equipo de trabajo/Director No se cumple con el cronograma.

Entrega final Equipo de trabajo/Cliente No es posible la instalación en el

cliente

Tabla 6. Actividades y riesgos



15

Figura 2. Actividades del proyecto

5.2.2. Asignación de agenda

El siguiente diagrama muestra las actividades por meses.

Figura 3. Grafico de duración del las actividades.

ESPECIFICACIÓN DE SOFTWARE Versión: 1.0 Aplicación Practica Fecha: 25/08/2006 Unidad Administrativa Especial de Parques Naturales de Colombia

Aplicación Práctica UEAPNNC 16

5.2.3. Asignación de recursos

Remitirse al numeral 5.2.1 el cual especifica las actividades de trabajo.

5.2.4. Asignación de presupuesto

Se cuenta con los recursos necesarios para la elaboración del presupuesto. Las licencias del

motor de base de datos Oracle, y el software para la visualización de la información geográfica

ArcGis, son productos adquiridos por la entidad.

El software necesario para la elaboración de documentos es proporcionado por la Pontificia

Universidad Javeriana.

El lenguaje de programación Java es software libre, por lo tanto no causa ningún gasto.

5.3 Plan de control

5.3.1. Plan de control de requerimientos

Se tendrá constante comunicación con el cliente, esto permitirá manejar de una mejor forma

cualquier posible cambio en los requerimientos.

Se entregaran prototipos, con lo que se espera satisfacer las necesidades de la entidad, y mantener

informados a los funcionarios de la evolución y presentación del producto. La entrega de

prototipos les brindará una participación activa a los funcionarios, y encaminará el producto

debido al amplio conocimiento que tienen de los procesos que manejará el aplicativo.

Todos los cambios solicitados por el cliente, se registraran por medio de actas, producto de las

reuniones.

5.3.2. Plan de control de cronograma

Por medio de reuniones semanales, se tendrá un control del avance del proyecto entre los

integrantes del equipo de trabajo, teniendo en cuenta el calendario propuesto.



5.3.3. Plan de control de presupuesto

Debido a que es un proyecto de trabajo de grado, no requiere un control de presupuesto.

5.3.4. Plan de control de calidad

Se llevaran a cabo las siguientes actividades, para mantener la calidad del proyecto a través de

todas sus fases:

Aseguramiento de la calidad en los procesos del desarrollo del producto:

En cada etapa del proyecto el administrador de calidad y manejo de riesgos tendrá en cuenta los

posibles riesgos asociados y analizará su impacto en caso de que ocurran.

Corrección y validación de los cambios hechos por parte del equipo de trabajo y registro de estos.

Aseguramiento de la calidad en la documentación

En las reuniones semanales del equipo de trabajo, se discutirá la documentación de cada uno de

los entregables, asegurando la claridad y calidad de los mismos. El director del trabajo de grado

revisará y aprobara la documentación generada.

Aseguramiento de la calidad en el desarrollo

Cada semana se revisará la adecuada documentación de la codificación del producto,

especificando el funcionamiento y avance.

El desarrollador será el encargado de realizar esta documentación, la cual será revisada por el

auxiliar de desarrollo.



5.3.5 Plan de Recolección de Métricas

El equipo de estudiantes ha establecido una serie de formatos, con los que se pretende realizar

autoevaluaciones de los componentes más relevantes del proyecto.

Escritura de código y documentación (Anexo 3).

Nombramiento de clases, funciones, parámetros, atributos etc. (Anexo 4).

Nombramiento de las tablas, atributos y constraints del modelo de datos (Anexo 5).



5.4 Plan de administración de riesgos

Los riesgos principales que encontramos en el desarrollo del proyecto son:

Riesgo Probabilidad Efecto Responsable Estrategia

Incapacidad de cualquier de los integrantes por enfermedad.

Moderada Serio Equipo de trabajo

Revisión de reuniones y contingencias para los avances.

Desconfiguración de ambiente

donde se desarrolla el

software

Baja Serio Desarrollador

Tener un backup de la instalación inicial en un segundo computador.

El cronograma no se alcanza Alta Tolerable Equipo de trabajo

Modificar el cronograma con previa autorización del cliente.

Rotación en el personal de la

entidad baja Serio

Equipo de trabajo y director

Tener registro detallado de los acuerdos alcanzados con los funcionarios actuales.

Cambio en los requerimientos

Moderada Serio Equipo de trabajo

Establecer los requerimientos a través de un documento aprobado por la entidad, para determinar la severidad y viabilidad de cualquier cambio

La tasa de reparación de defectos esta subestimada

Alta Tolerable Desarrollador

Probar el código cada vez que se implemente una nueva funcionalidad

Falta de tiempo en los integrantes

del equipo de trabajo

Alta Seria Equipo de trabajo

Encontrar apoyo entre los integrantes del equipo para la



realización de tareas según la responsabilidad. Mantener al cliente al tanto del estado actual del producto.

Tabla 7. Tabla de riesgos 5.5 Plan de clausura

El producto será entregado tanto al director del proyecto, como a la UEAPNNC, en medio

magnético. Esta entrega estará conformada por los instaladores del producto, y por los siguientes

documentos:

• Documento diagnostico.

• SPMP.

• SRS.

• SDD.

• Plan de Pruebas.

• Actas de reuniones.

• Registros 1 Y 2.

• Manual de instalación.

• Manual de usuario.

• Carta de aprobación de requerimientos.

El producto se entregará instalado en la UEAPNNC. El soporte se dará mientras se realicen las

pruebas por parte de los funcionarios, y quede constancia de su aprobación.

La instalación se hará teniendo en cuenta las especificaciones técnicas (hardware y software)

contempladas en el documento de diagnostico. La entidad garantiza tener las versiones de los

productos, y en caso de cambio en alguna de ellas, garantizará su compatibilidad.



6 Plan de procesos técnicos

6.1 Modelo de procesos

El equipo de trabajo seguirá la metodología RUP para el desarrollo del proyecto, con la cual se

espera cumplir con el calendario y objetivos.

6.1.1. Actividades de iniciación del proyecto

Las actividades que darán inicio al proyecto de implementación del aplicativo predial serán las

siguientes:

Definición de las condiciones iniciales en la entidad.

Requerimientos recolectados en la entidad.

Arquitectura diseñada para suplir los requerimientos recolectados.

Revisión del calendario.

6.1.2. Entregables del proyecto

El proyecto se considerará entregado, una vez se cumplan las siguientes situaciones:

• Entrega del código fuente y los documentos descriptivos de la aplicación.

• Validación de la funcionalidad del producto, por parte de los funcionarios de la entidad.

• Aceptación expresa del cliente del producto de software entregado.

• Entrega en la universidad del producto y su documentación.

• Aceptación del producto y sus documentos, por parte del director del proyecto.

6.2 Métodos, herramientas y técnicas

6.2.1. Metodología de desarrollo

Lenguaje de implementación: el lenguaje en el que se implementará el producto será Java, y

se utilizará el jdk 1.5.



Metodología empleada: la metodología que se utilizará en el desarrollo del proyecto, es

RUP.

Motor de base de datos: el motor de base de datos que se utilizará, es Oracle 10g, versión

10.2.0.4

Software cartográfico: el software para desplegar la información cartográfica será ArcGis

9.3

El motor de base de datos, lenguaje de programación y software geográfico, fue elección de

los funcionarios de la entidad desde el comienzo del proyecto.

6.2.2. Herramientas a utilizar

Herramientas para la construcción del software: para la implementación del producto, se

utilizará Eclipse como IDE.

Herramienta de documentación: la documentación del producto se hará a través de la

herramienta JavaDoc. La documentación del modelo de datos, y los diagramas que se construyan

se harán con la herramienta Borland Together.

6.3 Plan de infraestructura

La infraestructura que se utilizará será proporcionada principalmente por los estudiantes, y en

algunos casos se utilizarán los equipos proporcionados por la universidad en los laboratorios.

Se tendrán dos ambientes configurados, en dos computadores portátiles, propiedad de los

estudiantes de los estudiantes.

Las licencias de software serán proporcionadas por la universidad, y por la UEAPNNC.



6.4 Plan de aceptación del producto

El producto debe satisfacer la totalidad de los requerimientos acordados con la Unidad Especial

Administrativa de Parques Nacionales Naturales de Colombia, especificados en el documento

SRS.

El producto debe satisfacer las pruebas establecidas tanto por los estudiantes, como por los

funcionarios de la entidad.

El producto debe estar construido y corriendo bajo el software especificado por la entidad.

El código del producto debe tener una correcta identación, de tal forma que facilite su

visualización.

El modelo de datos debe estar correctamente documentado, y el nombre de sus tablas, atributos y

constraints debe ser de fácilmente relacionados en el contexto del negocio, para facilitar su

mantenimiento a futuro.



Anexo 1. Formato de chequeo para las diferentes pantallas del aplicativo.

Estándar de Lista de chequeo para la presentación

Pantalla

Fecha de Revisión Aprobado SI NO

Revisado

Elemento a Revisar SI NO

NO

APLICA

INFORMACION

ADICIONAL

Nombres de los Objetos

Canvas

Funciones y/o procedimientos

Gráficos

Librerías

Radio Group

Parámetros

Push Button

Ventanas

Relación

Variables



Anexo 2. Formato para la elaboración de pruebas a los diferentes módulos del producto.

Formato de resultados, ejecución de pruebas

Firma:

Fecha:

Aprobado: Si No

Ejecutor:

Casos: 1 2 3 4 5 6

Errores

Caso: 1

Problemas encontrados

Solución

Observaciones

Entradas

Salidas

Errores



Anexo 3. Formato de evaluación de la documentación de las clases.

Evaluación de clases

Nombre de la clase


Revisado

Elemento a Revisar SI NO NO APLICA INFORMACION ADICIONAL

Nombres de los Objetos

Código identado

Nombramiento adecuado de clases

Nombramiento adecuado de funciones Nombramiento adecuado de parámetros Nombramiento adecuado de atributos Clasificación y agrupamiento de código

Anexo 4. Formato de evaluación de la documentación del modelo de datos

Evaluación de la documentación del modelo de datos


Revisado

Elemento a Revisar SI NO NO APLICA INFORMACION ADICIONAL

Criterio

Nombre adecuado de las tablas

Ordenamiento de los constraints

Nombre adecuado de los atributos

Nombre de relaciones entre tablas adecuado

plan de administración del proyecto de software unidad...

Documents