SPMP

SIPREDIAL Versión: 1.
0
Aplicación Practica Fecha: 12/02/2009
Unidad Administrativa Especial de Parques Naturales de Colombia
Plan de administración del proyecto de software

José David Yances Rojas

Samuel Murillo Ariza
Pontificia Universidad Javeriana

Facultad de Ingeniería
Ingeniería de Sistemas
Octubre de 2008
Bogotá
Aplicación Práctica UEAPNNC 0

SIPREDIAL Versión: 1.0
HISTORIA DE REVISIÓN
Versión Fecha Descripción Responsable

Revisión del alcance y propósito
José David
del proyecto, asignación de
1.0 7/10/2008 Yances-Samuel
responsabilidades, revisión de las
Murillo
actividades de trabajo.
José David
Revisión final del documento del
1.1 13/10/2008 Yances-Samuel
SPMP y los casos de uso
Murillo

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.

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
PLAN DE MANEJO DEL PROYECTO DE SOFTWARE

1.1 Sumario del Proyecto
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
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.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.
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.
Fecha de entrega: Marzo 16 de 2009, Universidad Pontificia Javeriana
Marzo 20 de 2009, UEAPNNC

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
240.000
 Papel
 Anillado
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
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.
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.

Referencias
[SOM02] I. Sommerville. Introducción .En: Ingeniería de Software. 6 a 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
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).
SRS: Especificación de los Requerimientos de Software (Software Requirements Specifications)

Organización del proyecto
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
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.

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

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
Total Valor
ACTIVIDAD Unidad Cantidad Valor unitario
Costo 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
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

3. 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

No se llega a un acuerdo en la
Asignación de roles del equipo Equipo de trabajo
asignación de responsabilidades
No se llega a un acuerdo con el
Organización del proyecto Equipo de trabajo/Director
plan de trabajo a seguir
Los integrantes del equipo de
trabajo no logran acordar una fecha
Reunión inicial de trabajo Equipo de trabajo
teniendo en cuenta sus actividades
laborales
No hay claridad en cuanto al
alcance del proyecto y las
Reunión y acuerdo con el cliente Equipo de trabajo/Cliente
especificaciones que el cliente
quiere del producto
No se tienen definidos los costos,
Planificación de duración y costos
Equipo de trabajo/Director entregables y duración del
del proyecto
proyecto.
Entrega documento diagnostico Equipo de trabajo/Director No se cumple con el cronograma
No se cumple con las

Construcción de los casos de usos Equipo de trabajo
especificaciones
Equipo de No se cumple con las
Entrega formal del SPMP
trabajo/Director/Cliente especificaciones
Equipo de No se cumple con las
Entrega formal del SRS
trabajo/Director/Cliente 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.
Los requerimientos no es lo que el
Diseño de la Arquitectura Equipo de trabajo
cliente requiere
Diseño de Alto y Bajo nivel Equipo de trabajo No es claro el alcance del proyecto
No cumpla con las
Elaboración SDD Equipo de trabajo
especificaciones necesarias.

El prototipo no satisface el director

Entrega del segundo prototipo Equipo de trabajo/Director
del proyecto
Entrega del segundo prototipo Equipo de trabajo/Cliente El prototipo no satisface el cliente
No hay interoperabilidad entre los
Integración componentes Equipo de trabajo
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
No se tengan en cuenta las
Manual de usuario Equipo de trabajo especificaciones finales del
sistema.
No se logra realizar los ajustes
Ajustes Equipo de trabajo/Cliente
necesarios.
Entrega final Equipo de trabajo/Director No se cumple con el cronograma.
No es posible la instalación en el
Entrega final Equipo de trabajo/Cliente
cliente
Tabla 6. Actividades y riesgos

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
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.
4. 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. Plan de administración de riesgos
Los riesgos principales que encontramos en el desarrollo del proyecto son:
Riesgo Probabilidad Efecto Responsable Estrategia

Revisión de
Incapacidad de
reuniones y
cualquier de los
Moderada Serio Equipo de trabajo contingencias
integrantes por
para los
enfermedad.
avances.
Tener un
Desconfiguració
backup de la
n de ambiente
instalación
donde se Baja Serio Desarrollador
inicial en un
desarrolla el
segundo
software
computador.
Modificar el
cronograma con
El cronograma
Alta Tolerable Equipo de trabajo previa
no se alcanza
autorización del
cliente.
Tener registro
detallado de los
Rotación en el
Equipo de trabajo acuerdos
personal de la baja Serio
y director alcanzados con
entidad
los funcionarios
actuales.
Establecer los
requerimientos
a través de un
documento
aprobado por la
Cambio en los
Moderada Serio Equipo de trabajo entidad, para
requerimientos
determinar la
severidad y
viabilidad de
cualquier
cambio
Probar el
La tasa de código cada vez
reparación de que se
Alta Tolerable Desarrollador
defectos esta implemente una
subestimada nueva
funcionalidad
Falta de tiempo Alta Seria Equipo de trabajo Encontrar
en los integrantes apoyo entre los
del equipo de integrantes del
trabajo 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
6. 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.

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.
1. 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.
2. 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.

3. 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
NO INFORMACION
Elemento a Revisar SI NO APLICA 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

SPMP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SPMP

Cargado por

Copyright:

Formatos disponibles

SIPREDIAL Versión: 1.

Plan de administración del proyecto de software

José David Yances Rojas

Pontificia Universidad Javeriana

Aplicación Práctica UEAPNNC 0

Versión Fecha Descripción Responsable

Aplicación Práctica UEAPNNC 1

Aplicación Práctica UEAPNNC 2

PLAN DE MANEJO DEL PROYECTO DE SOFTWARE

Aplicación Práctica UEAPNNC 3

1.1 Sumario del Proyecto

1.1. Propósito alcance y objetivos del proyecto

1.2. Asunciones y Restricciones

Aplicación Práctica UEAPNNC 4

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

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

1.3. Entregables del Proyecto

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

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

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

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

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

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

Aplicación Práctica UEAPNNC 6

1.4. Resumen de presupuesto

Concepto Valor (pesos)

2. Evolución del plan

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

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

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

Aplicación Práctica UEAPNNC 7

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

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

Aplicación Práctica UEAPNNC 8

Organización del proyecto

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

Figura 1. Canales de comunicación

Aplicación Práctica UEAPNNC 9

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

Figura 2. Comunicación entre los roles

Aplicación Práctica UEAPNNC 10

5.1 Plan de Arranque

5.1.1. Plan de estimación

Aplicación Práctica UEAPNNC 11

TOTAL COSTOS INDIRECTOS $ 1.159.000

5.1.2. Plan de manejo de personal

5.1.3. Plan de adquisición de recursos

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

Componente Producto Nivel de conocimiento

Aplicación Práctica UEAPNNC 12

5.2.1. Actividades de trabajo

Actividad Involucrados Riesgos

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

No se cumple con las

Aplicación Práctica UEAPNNC 13

El prototipo no satisface el director

Tabla 6. Actividades y riesgos

Aplicación Práctica UEAPNNC 14

Figura 2. Actividades del proyecto

5.2.2. Asignación de agenda

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

Aplicación Práctica UEAPNNC 15