Proyecto Parroquial: octubre 2015

Proyecto Parroquial

Integrantes del grupo:
Jackson Hernandez leon
Carlos Andrés Calderón López
Pablo Cortes
Miguel Angel Pachón

Se realiza la descripción del proyecto Parroquial con el cual se especifica cada una de las actividades a nivel detallado y global de cada requerimiento, no solo de la aplicación si no del proceso adquisitivo del proyecto, descripción, compra, desarrollo y puesta en marcha.

La descripción inicial del proyecto hace referencia a la necesidad de elaborar un software o solución la cual esté en capacidad de almacenar los datos que a diario se manejan en una iglesia, parroquia o catedral, debido a que en la actualidad se realiza este proceso por medio de ingreso manual en libros los cuales por tiempo se convierten en un proceso dispendioso al momento de consultar por un registro ya que cada libro contiene mil páginas y de estos ya existen mas de cincuenta libros, los promedios de entregas de certificaciones se hacen en tiempos de 15 a 20 días para su elaboración y entrega, haciendo de esta actividad un cuello de botella, al momento que se requieren por demanda muchos certificados, estos se encolan y el promedio de satisfacción de los feligreses baja por la tardanza y demora en entrega de los mismos.

La aplicación deberá manejar estándares integrales para que su uso sea amigable con cualquier sistema y proceso en cada lugar de instalación.

ALCANCE DEL PROYECTO

El alcance del proyecto va a tener un ámbito local, radicado en la localidad séptima de Bosa y junto a Soacha, específicamente León XIII, y toda la infraestructura junto con el programa se instalaran con equipo especializado de la empresa en los lugares que requiera esta jurisdicción, se debe contar con un límite de licencias las cuales se desplegaran en con cada instalación, lo que indica que por cada parroquia se entregará una licencia.

Los requerimientos iniciales serán los siguientes:

Se requiere ingresar la información de los feligreses al momento de presentarse en cada uno de los templos, los requerimientos de cada uno varían de acuerdo a la necesidad en particular de las cuales se tiene las siguientes:

1. Bautismo.

2. Comunión.

3. Confirmación.

4. Matrimonio.

5. Unción.

6. Misas especiales.

7. Emisión de certificados.

De acuerdo a cada una de las necesidades en la actualidad se lleva un libro en físico con dicha información por lo que se requiere almacenar esta información en medios magnéticos y protegida con copias de respaldo.

El ingreso de esta información se debe manejar por medio de un ambiente WEB el cual permita por medio de un menú y mediante un formulario ingresar a cada una de las especialidades; se requiere que una vez este almacenada la información y un feligrés requiera una copia o una impresión de un certificado, se pueda generar un informe.

Para detallar este alcance se han detallado 4 tareas principales las cuales son:

1. Entregables

2. Especificaciones

3. Responsabilidades

4. Actividades fuera del alcance

Entregables:

Se debe realizar la entrega de los formularios de ingreso a la aplicación, ingreso de información y consulta de a misma, detallados de la siguiente forma:

1. Login aplicación: Formulario con los datos de solicitud de credenciales de los empleados de cada parroquia.
2. Bautismo: Formulario de ingreso de la información referente a Bautismo.

3. Comunión: Formulario de ingreso de la información referente a Comunión.

4. Confirmación: Formulario de ingreso de la información referente a Confirmación.

5. Matrimonio: Formulario de ingreso de la información referente a Matrimonio.

6. Unción: Formulario de ingreso de la información referente a Unción.

7. Misas especiales: Formulario de ingreso de la información referente a Misas especiales.

8. Emisión de certificados: Formulario de ingreso de la información referente a Emisión de certificados.
9. Logout de la aplicación: Pantalla de finalización de la sesión de cada usuario.
10. Pantalla de time out de sesión: Presenta el cierre de la sesión, bien sea por inactividad o por cierre directo del usuario.
Se entregará un instalador de Xampp para realizar el despliegue de la aplicación, esta estará contenida en un paquete war, se entregarán los scripts de base de datos para la creación y ambientación de la aplicación, tablas y registros iniciales que se requieren para dar inicio con la aplicación.

La aplicación se encontrará desarrollada en java, jsf2 y con complementos en prime faces, con conexión a una base de datos Mysql.

Detalle entregables:

* Fecha de inicio del proyecto (Implementación del software): 17 de noviembre de 2015
* Fecha fin del proyecto (Construcción software y puesta en pruebas): 27 Diciembre y entrega a pruebas el 1 de diciembre.

Criterios de aceptación (proceso y criterios de aceptación parte cliente)

RESPONSABILIDADES

- Formas de comunicación (Suplidor de información – Adquiriente de información)
El principal canal de comunicación será el cara a cara en donde el feligrés acudirá a la parroquia y personalmente hablara con la persona encargada de generar los documentos para realizar los trámites que requiera el feligrés y validar la información que requiera el mismo y garantizar la confidencialidad de la información contenida en las bases de datos.
- Riesgos (Suplidor de información)
El potencial riesgo por parte del suplidor de información, es sufrir una pérdida de datos ya sea por daño en los servidores de información o por algún riesgo de desastre natural en que se dañen los servidores que contienen las bases de datos. Para garantizar la seguridad de la información, a dicha información se le estarán haciendo múltiples copias de seguridad en diferentes servidores para evitar pérdidas de información.
- Frecuencia de informes
Semanalmente se realizara un informe del estado de los servidores de las bases de datos para garantizar la seguridad de la información y así corregir a tiempo cualquier posible falla.
- Penalidades (Suplidor de información – Adquiriente de información)
Quien viole la confidencialidad de la información ya sea el Suplidor de información o el Adquiriente de información, será demandado antes las autoridades competentes y así evitar que se generen falsos documentos que no concuerden en lo contenido en las bases de datos.

Fuera del alcance

1. No se tendrán manejos de ingreso de pagos y certificaciones de pago que sean manejados por concepto de cada una de las actividades realizadas internamente.
2. Toda funcionalidad externa al requerimiento inicial, se manejará como control de cambios.
3. Toda funcionalidad que no se encuentre definida y sea requerida fuera del alcance una vez implementado el software se tomará como control de cambios y se debe gestionar para medir el impacto en la funcionalidad.

Restricciones del proyecto

Todo manejo del lenguaje de programación diferente al solicitado no se contemplará y por ende se tendrá solo el propuesto en el inicio de los requerimientos.

La instalación de toda aplicación se encuentra con restricción por uso de licencia, cada licencia esta definida por equipo.

FUNCIONES Y CARACTERÍSTICAS
PROPÓSITO FUNCIONAL

1. Requerimiento funcional General
Descripción

Hacer un software en ambiente WEB que admita la entrada y la salida de los diferentes datos de los feligreses como son:

1. Bautismo=Entrada.

2. Comunión=Entrada.

3. Confirmación=Entrada.

4. Matrimonio=Entrada.

5. Unción=Entrada.

6. Misas especiales=Entrada.

7. Emisión de certificados=Salida.

1. Requerimiento no Funcional pre requisitos Autenticación
Descripción
Se deben cumplir con pre requisitos para el momento de cada una de las actividades a realizar en la aplicación, se tiene :
1.1 Para el proceso de login el usuario debe estar previamente creado en BD y con una contraseña activa.
1.2 El usuario debe tener un rol asignado con los permisos a cada funcionalidad, estos permisos serán otorgados por el sacerdote quien estará en cabeza del proceso de administración de usuarios.
1.3 Solo el usuario administrador podrá desbloquear usuarios que se encuentren con estados de bloqueo por contraseña o acceso.

2. Requerimiento Funcional Autenticación
Descripción
Se requiere tener un formulario de autenticación al momento de realizar el consumo de la página en el cual se soliciten las credenciales de ingreso del funcionario que va a realizar el proceso de ingreso, consulta o generación del informe de la aplicación, todo funcionario debe tener un usuario de ingreso a la aplicación con ciertos permisos autorizados, las definiciones de los roles se establecen en las pre condiciones del ingreso requerimiento no Funcional pre requisitos Autenticación 1.

A continuación se definen los campos, labels o etiquetas y botones que se presentarán en el formulario:
Ingresar su Nombre de Usuario y Clave (labels)
Campo Clave (campo).
Campo Usuario (campo Enmascarado).
Ingresar (Botón).
3. Requerimiento funcional Bautismo
Descripción
Por medio de este formulario el usuario tendrá la opción de realizar el proceso de ingreso de las partidas de bautizo, de la misma forma podrá realizar el proceso de consulta e impresión del comprobante si se es necesario.

4. Requerimiento funcional Comunión
Descripción
Por medio de este formulario el usuario tendrá la opción de realizar el proceso de ingreso de las partidas de Comunión, de la misma forma podrá realizar el proceso de consulta e impresión del comprobante si se es necesario.

5. Requerimiento funcional Confirmación
Descripción
Por medio de este formulario el usuario tendrá la opción de realizar el proceso de ingreso de las partidas de Confirmación, de la misma forma podrá realizar el proceso de consulta e impresión del comprobante si se es necesario.

6. Requerimiento funcional Matrimonio
Descripción
Por medio de este formulario el usuario tendrá la opción de realizar el proceso de ingreso de las partidas de Matrimonio, de la misma forma podrá realizar el proceso de consulta e impresión del comprobante si se es necesario.

7. Requerimiento funcional Unción
Descripción
Por medio de este formulario el usuario tendrá la opción de realizar el proceso de ingreso de las partidas de Unción, de la misma forma podrá realizar el proceso de consulta e impresión del comprobante si se es necesario.

8. Requerimiento funcional Misas especiales
Descripción
Por medio de este formulario el usuario tendrá la opción de realizar el proceso de ingreso de las Misas especiales, de la misma forma podrá realizar el proceso de consulta e impresión del comprobante si se es necesario.

9. Requerimiento funcional Emisión de certificados

Descripción
Por medio de este formulario el usuario tendrá la opción de realizar el proceso Emisión de certificados para así poder tener en una sola pantalla consolidados los datos, por medio de esta funcionalidad logrará encontrar cualquier partida o información requerida por cada feligrés.

Supuestos
Incendios:
inundaciones:
Hurtos:
Cortocircuitos:
Daños estructurales:
Daños Hardware:
Llenado de bases de datos:
Apagones:

Riesgos Generales

Fallas en los ambientes de contingencia.
Llenado de colas al momento del ingreso de la información.
Llenado de información impacto en Base de datos.
Tiempo de duración de la aplicación.
Cambios sujetos a disponibilidad.
Cambios de fechas en las entregas.

CALIDAD

LEYES QUE AMPARAN EL PROYECTO
- Ley 133 de 1994 (Reglamentada parcialmente por el Decreto Nacional 1396 de 1997, por la cual se desarrolla el Decreto de Libertad Religiosa y de Cultos, reconocido en el artículo 19 de la Constitución Política).
- Ley 23 de 1982 (Ley sobre los derechos de autor).
- Ley 23 de 1982 Art. 30 (Derechos morales).
- Ley 23 de 1983 Art. 72 (Derechos patrimoniales).
- Ley 170 de 1994
- Ley 599 de 2000 (Código Penal), que presenta un capítulo único y exclusivo a los delitos contra los derechos de autor, mediante tres artículos específicos: uno dirigido a sancionar la violación de los derechos morales, un segundo artículo para castigar la violación de los derechos patrimoniales, y un último que castiga la violación a los mecanismos de protección de los derechos de autor.
- Decreto 1360 de 1989, declara el software como un bien protegido por los derechos de autor.
- Ley 33 de 1987. Aprobatoria del Convenio de Berna (Derecho de Autor).
- Ley 44 de 1993. Por la cual se modifica y adiciona la Ley 23 de 1982.
- Ley 565 de 2000. Aprobatoria del tratado OMPIWCT, sobre derechos de autor.
- Tratado OMPI sobre Derecho de Autor, suscrito en Ginebra en 1996, al cual adhirió Colombia mediante la Ley 565 de 2000.

- Tratado de la OMPI –Organización Mundial de la Propiedad Intelectual– sobre Derechos de Autor (WCT), adoptado en Ginebra el veinte (20) de diciembre de mil novecientos noventa y seis (1996).

CRONOGRAMA DE ACTIVIDADES INICIALES

RECURSOS:

Para el desarrollo del proyecto se debe contar con los siguientes recursos
1. Un gerente de proyecto que será el encargado de velar porque se lleven a cabo todas las labores necesarias para culminar con el objetivo del proyecto, para esta labor se tiene un presupuesto de $4.000.000 por mes
2. Un desarrollador que debe velar por la programación de la aplicación y la documentación, se tiene asignado un presupuesto de $2.500.000
3. Una oficina que cuente con los implementos necesarios como escritorios, papelería, sillas. Para esto se destinará un presupuesto mensual de $ 2.000.000
4. Equipos de cómputo, aplicaciones, licencias, por el tiempo destinado para el proyecto se alquilarán los equipos y las licencias, con un presupuesto mensual para 5 equipos portátiles y una impresora láser de $ 3.000.000.
5. Comercial: se encargará de los acuerdos con el cliente y se asignará un salario básico de $ 1.000.000 más una comisión del 5 % del valor de la contratación
EQUIPOS: A continuación se definen los roles que desempeñará cada integrante del grupo de operación.
Gerente de proyecto: tiene la responsabilidad total del planeamiento y la ejecución acertados de cualquier proyecto. El gerente de proyecto debe poseer una combinación de habilidades incluyendo una gran capacidad inquisitiva, de detectar asunciones sin especificar y de resolver conflictos interpersonales. Una de sus tareas más importantes es el reconocimiento de los riesgos que afectan directamente las probabilidades de éxito del proyecto, y la constante medición, formal e informalmente de dicho riesgo a lo largo del ciclo de vida del proyecto. El riesgo se presenta mayormente como incertidumbre. El gerente de proyecto acertado es aquel que enfoca esto como preocupación principal. La mayor parte de los problemas que afectan un proyecto se relacionan de un modo u otro a un riesgo. Un buen gerente de proyecto puede reducir los riesgos significativamente, a menudo adhiriéndose a una política de comunicación abierta, asegurándose de que cada participante significativo tenga una oportunidad de expresar sus opiniones y preocupaciones. Un gerente de proyecto es el responsable de tomar las decisiones necesarias de manera tal que el riesgo sea controlado y la incertidumbre reducida al mínimo. Cada decisión tomada por el encargado de proyecto debe involucrar un beneficio directo hacia el proyecto.
Desarrollador: Se dedica a uno o más aspectos del proceso de desarrollo de software. El ámbito más amplio de la programación. Debe contribuir a la visión general del proyecto más a nivel de aplicación que a nivel de componentes o en las tareas de programación individuales. Incluso de ser necesario el desarrollador se convierte en arquitecto de sistemas informáticos, incluye: trabajo en equipo: el proyecto es en general una colaboración, y también de otros colaboradores como los comerciales, que definen con el cliente la finalidad del producto pruebas: que sirven para detectar las disconformidades y los errores, en el proceso se incluirá mantenimiento, la corrección de los errores después de la salida del programa informático, y la mejora para hacer evolucionar el producto.

Comercial: se encargará del acuerdo comercial con el cliente y de definir los requisitos previos necesarios para llevar a cabo la negociación y la implementación del desarrollo ofrecido.

Adquisiciones:

La empresa inicialmente para el tipo de proyecto realiza ciertas compras de acuerdo a la demanda de los productos adquiridos por el cliente, toda dependencia requiere de las aprobaciones de compra para la instalación, todos los insumos necesarios para la adquisición al momento del despliegue serán dados por los detalles de cada factura, por lo general cada proyecto para instalación consta del aplicativo en la parte de software y para la parte de hardware en infraestructura se contará con la instalación de los equipos de computo con las especificaciones requeridas para el soporte de la aplicación como lo son los discos, memoria, procesadores y red disponible.

Las adquisiciones se realizarán un día después de la compra del producto, según lo pactado con el comprador, el proveedor se encargará de realizar el proceso de instalación y puesta en marcha de la aplicación, en caso de solo realizar el proceso de compra del software, de igual forma el compromiso con el comprador es realizar la instalación por parte del proveedor en las instalaciones contempladas de acuerdo a los términos de las licencias adquiridas, todo despliegue de la solución se realizará acompañada de una licencia, en dado caso que se compren paquetes de licencias se procederá a instalar cada una con el software y en caso de aún no disponer del ambiente se dejará pendiente por instalación sin ningún costo, cada licencia tendrá una jurisdicción de acuerdo a lugar de instalación.

Cada compra quedará registrada con fecha y hora para temas de garantías y mantenimientos sugeridos dentro del proceso de compra, también para saber al momento de una mejora, actualización, control de cambio o parche a la aplicación.

Los requerimientos necesarios para la puesta en marcha de la aplicación en un ambiente productivo son:

* Red de internet (suministrada por el comprador).
* Servidor de base de datos.
* Servidor de despliegue de la solución.
* Servidor de aplicaciones.
* Ears o jars de la aplicación
* Mano de obra con Ingenieros lideres, desarrolladores, equipo de pruebas y gerencia del proyecto.
* Infraestructura de desarrollo e inmuebles para el proceso de ejecución, estos integran el sitio físico de elaboración del proyecto y sus procesos alternos como servicios y demás, también se tienen en cuenta los accesorios como equipos para el desarrollo, muebles para el proceso y lugares donde reposarán las aplicaciones generadas.

Costos:

Adecuaciones

ESTUDIO FINANCIERO
CONSTRUCCION 1
Descripción	Cantidad	Valor Unitario	Valor total
Pintura	5	45,000	225,000
Instalacion de equipos	1	400,000	400,000
Adecuacion de instalaciones	1	400,000	400,000
			-
			-
			-
			-
			-
			-
			1,025,000
Mano de obra
Descripción	Cantidad	Valor Unitario	Valor total
Ingeniero de sistemas	1	1,000,000	1,000,000
Tecnico de sistemas	2	700,000	1,400,000
Sub Total			2,400,000
Total			3,425,000

TOTAL CONSTRUCCIONES Y ADECUACIONES

4,450,000

Equipos

MAQUINARIA Y EQUIPOS
Descripción	Cantidad	Valor Unitario	Valor total
Computador	2	1,100,000	2,200,000
Impresora	2	600,000	1,200,000
Telefonos fijos	2	150,000	300,000
Servidores	2	3,500,000	7,000,000



		VALOR TOTAL	10,700,000

HERRAMIENTAS
Descripción	Cantidad	Valor Unitario	Valor total
Esferos	100	900	90,000
Resmas de papel	25	25,000	625,000
			-
			-


		VALOR TOTAL	715,000

TOTAL MAQUINARIA Y EQUIPOS Y HERRAMIENTAS

11415000

Gastos

GASTOS ANUALES DEL PROYECTO

OTROS COSTOS DE PRODUCCION
Descripción	Cantidad/ Año	Valor Unitario	Valor total
Agua	12	50,000	600,000
Energía Electrica	12	35,000	420,000
Total			1,020,000

GASTOS DE VENTAS
Descripción	Cantidad/ Año	Valor Unitario	Valor total
Publicidad del Software	4	40,000	160,000
Total			160,000

GASTOS DE ADMINISTRACION
Descripción	Cantidad/ Año	Valor Unitario	Valor total
Implementos de papeleria	12	50,000	600,000
Implementos de aseo	4	30,000	120,000
Servicio de internet	12	60,000	720,000
			1,440,000

Comunicaciones:

Desde el inicio del proyecto se deberá mantener una comunicación constante con el cliente de esta forma se llevará una trazabilidad de cambios, sugerencias y desarrollo del software como tal.
Luego de realizar este proceso inicial se procederá a generar los requerimientos de la aplicación, de forma alguna que todo lo que se requiere por parte del cliente quede por escrito, se conocen los alcances, se definen los límites y se definen los casos de uso de la aplicación para así determinar posibles excepciones o vacíos funcionales que no son tenidos en cuenta al momento de la creación de los requerimientos.

Se procede a realizar reuniones de seguimiento con el comprador al momento del inicio del desarrollo, sí se acuerdan entregas parciales, se procederá a programar con antelación cada entrega, generando procesos de aceptación de cada componente a entregar, paulatinamente se instalará con el aval del comprador y se realizará un acta de entrega al momento de cada entrega, de acuerdo con las definiciones del plan de pruebas y plan de desarrollo.
Los criterios de aceptación serán definidos con los requerimientos de tal forma que se proceda a certificar cada entrega con dichos criterios.

De acuerdo a la metodología de Scrum, se determina que cada reunión el cliente podrá estar al tanto con el desarrollo de su aplicación por medio de un informe gerencial el cual mostrará a grandes rasgos el estado y posibles bloqueos, también proyecciones de cumplimiento y factores de retraso.

El control del proyecto se realizará por medio de reuniones en modo webex, skype, minutograma y de acuerdo a la necesidad se realizará en físico, cada reunión se dejará con acta y compromisos, los cuales se deberán retomar al momento de cada nueva reunión, para mantener el control de pendientes y estado del proyecto.

Procesos: