2013 PONTIFICIA

UNIVERSIDAD

JAVERIANA

Daniel Warner White

[SPMP (SOFTWARE

PROJECT MANAGEMENT

PLAN)] Proyecto de Trabajo de Grado para la aplicación SmartGauge

HISTORIAL DE CAMBIOS

Versión Fecha Descripción de cambios

(corta)

0.1 18/02/2013

Se definió la visión general del proyecto, delimitando el prefacio, propósitos, objetivos y alcance.

0.2 20/02/2013

Modificaciones en la visión general del proyecto. Se añaden algunas referencias y se comienza con el punto 4, organización del proyecto.

0.4 24/02/2013

Se añade el punto 6 plan de procesos técnicos y parte del 7 plan de procesos de soporte.

0.6 27/02/2013 Se integra al punto 4 el punto 4.3 y al punto 7 el 7.3.

0.8 01/03/2013

Se hace corrección de ortografía y de redacción del documento.

1.0 06/03/2013

Se modifican los puntos 4 y 5. Y se hace revisión de ortografía, redacción y orden del documento.

Tabla 1: Historial de cambios

PREFACIO

Para el buen desarrollo de un proyecto de construcción de software, es necesaria una excelente planeación. El SPMP (Plan de Administración de Proyectos de Software) es un documento en el cuál se describe cuidadosamente cada detalle de la elaboración del producto de software con el fin de especificar cada una de sus etapas de elaboración y así evitar al máximo el riesgo de errores o despropósitos del proyecto. El presente proyecto será elaborado por un estudiante de Ingeniería de Sistemas de la Universidad Javeriana que tiene como objetivo el levantamiento de requerimientos, el diseño y desarrollo de una aplicación móvil para la toma de medidas volumétricas de objetos tridimensionales. Para ello se utiliza como primera instancia este documento en donde se presenta el SPMP al que se hizo referencia anteriormente.

TABLA DE CONTENIDO

LISTA DE FIGURAS .................................................................................................. 6

LISTA DE TABLAS..................................................................................................... 7 1. VISION GENERAL DEL PROYECTO .................................................................... 8

1.1 RESUMEN DEL PROYECTO ....................................................................... 8 1.1.1 Propósito, Alcance y Objetivos ............................................................... 8 1.1.2 Suposiciones y Restricciones ................................................................. 9

1.2 ENTREGABLES DEL PROYECTO .............................................................. 9 1. REFERENCIAS ................................................................................................. 10 2. DEFINICIONES Y ACRÓNIMOS ...................................................................... 11

3. ORGANIZACIÓN DEL PROYECTO ................................................................. 11 4.1 Interfaces Externas ..................................................................................... 11 4.2 Estructura Interna ........................................................................................ 11 4.3 Roles y Responsabilidades ......................................................................... 12

5 PLAN DE PROCESOS DE GESTIÓN .............................................................. 12

5.1 PLAN DE ARRANQUE ............................................................................... 12 5.1.1 Plan de Estimación ............................................................................... 12

5.2 PLAN DE TRABAJO ................................................................................... 15 5.2.1 Actividades de Trabajo ......................................................................... 15

5.2.2 Cronograma .......................................................................................... 16 5.3 PLAN DE CONTROL DE CALIDAD ............................................................ 16

5.3.1 Plan de Control de Calidad ................................................................... 16 5.4 PLAN DE ADMINISTRACIÓN DE RIEGOS ................................................ 17

5.4.1 Introducción .......................................................................................... 17 5.4.2 Objetivos ............................................................................................... 17 5.4.3 Detalle del plan ..................................................................................... 17

5.4.4 Responsable ......................................................................................... 18 5.5 PLAN DE CIERRE ...................................................................................... 18

5.5.1 Actividades ........................................................................................... 18 5.5.2 Aceptación por parte del cliente ........................................................... 18

6 PLAN DE PROCESOS TÉCNICOS .................................................................. 19 6.1 MODELO DE CICLO DE VIDA DEL PROCESO ......................................... 19

6.1.1 Objetivos específicos: ........................................................................... 19

6.1.2 Desarrollo del plan ................................................................................ 19

6.2 MÉTODOS, HERRAMIENTAS Y TÉCNICAS ............................................. 19 6.2.1 Objetivo ................................................................................................ 19 6.2.2 Metodología del desarrollo del proyecto ............................................... 20 6.2.3 Lenguaje de programación ................................................................... 20 6.2.4 Herramientas de software ..................................................................... 20

6.3 PLAN DE INFRAESTRUCTURA ................................................................. 20 6.3.1 Introducción .......................................................................................... 20 6.3.2 Objetivo ................................................................................................ 20 6.3.3 Características de equipos ................................................................... 21

6.4 PLAN DE ACEPTACIÓN DEL PRODUCTO ............................................... 21

7 PLAN DE PROCESOS DE SOPORTE ............................................................. 22 7.1 PLAN DE ADMINISTRACIÓN DE LA CONFIGURACIÓN .......................... 22

7.1.1 INTRODUCCIÓN .................................................................................. 22 7.1.2 OBJETIVOS ......................................................................................... 22

7.1.3 PLAN DE DESARROLLO ..................................................................... 22 7.1.4 RIESGOS ............................................................................................. 23 7.1.5 HERRAMIENTAS ................................................................................. 23 7.1.6 MONITOREO Y CONTROL .................................................................. 24

7.2 PLAN DE VERIFICACIÓN Y VALIDACIÓN ................................................ 24 7.2.1 INTRODUCCIÓN .................................................................................. 24 7.2.2 OBJETIVOS ......................................................................................... 25 7.2.3 FUNCIONAMIENTO DEL SOFTWARE ................................................ 25 7.2.4 EXPECTATIVAS DEL USUARIO ......................................................... 25

7.2.5 VALIDACIÓN Y VERIFICACIÓN .......................................................... 25 7.3 PLAN DE DOCUMENTACIÓN .................................................................... 26

7.3.1 INTRODUCCIÓN .................................................................................. 26

7.3.2 OBJETIVOS ......................................................................................... 26 7.3.3 PLAN DE DESARROLLO ..................................................................... 26 7.3.4 RIESGOS ............................................................................................. 27 7.3.5 HERRAMIENTAS ................................................................................. 27 7.3.6 SUPERVISIÓN Y CONTROL ............................................................... 27

7.4 PLAN DE ASEGURAMIENTO DE LA CALIDAD ......................................... 28 7.4.1 INTRODUCCIÓN .................................................................................. 28 7.4.2 OBJETIVOS ......................................................................................... 28

7.4.3 REVISIÓN DE PLANES ....................................................................... 28 7.4.4 RIESGOS ............................................................................................. 29

7.5 PLAN DE REVISIONES Y AUDITORIAS .................................................... 30

7.5.1 INTRODUCCIÓN .................................................................................. 30

7.5.2 OBJETIVOS ......................................................................................... 30 7.5.3 RIESGOS ............................................................................................. 30

7.6 PLAN DE ADMINISTRACIÓN DE SUBCONTRATOS ................................ 30

7.7 PLAN DE MEJORAS DEL PROCESO ........................................................ 30 7.7.1 INTRODUCCIÓN .................................................................................. 30

7.7.2 OBJETIVOS ......................................................................................... 30 7.7.3 PLAN DE DESARROLLO ..................................................................... 31 7.7.4 RIESGOS ............................................................................................. 31

8 ANEXOS ........................................................................................................... 31

REFERENCIAS DE LA PLANTILLA......................................................................... 32

LISTA DE FIGURAS Ilustración 1: Ciclo de vida del proyecto ................................................................... 19 Ilustración 2: Equipos ............................................................................................... 21

Ilustración 3 Herramientas de Configuración ........................................................... 23

LISTA DE TABLAS Tabla 1: Historial de cambios ..................................................................................... 2 Tabla 2 Herramientas de Versiones ......................................................................... 24

Tabla 3 Control de versiones ................................................................................... 24 Tabla 4 Estándares .................................................................................................. 26 Tabla 5 Control de documentación .......................................................................... 28

1. VISION GENERAL DEL PROYECTO

1.1 RESUMEN DEL PROYECTO

1.1.1 Propósito, Alcance y Objetivos

El propósito general del proyecto es el de diseñar y desarrollar una aplicación móvil que permita la toma de medidas volumétricas de cualquier objeto tridimensional bajo un esquema formal de desarrollo de software. Si bien se busca que el producto final esté sustentado sobre el pilar del rigor de la ingeniería aplicada, se pretende también que sea elaborado teniendo en cuenta factores humanos y productivos que incidirán directamente en el desarrollo del mismo, pues se requerirá del apoyo de una organización especializada en logística de mercados llamada GS1 Colombia [1].

Alcance El alcance de este proyecto consiste en el levantamiento de requerimientos, diseño e implementación de un sistema de información que permita la medir objetos tridimensionales con un alto grado de precisión. La aplicación parte de un trabajo previamente desarrollado (llamado ProMeter) y hará parte del mismo en la medida que integre nuevas funcionalidades y mejore las que éste ya posee. Los alcances del producto estarán también limitados por los conocimientos, capacidades, habilidades y a las limitaciones del estudiante Daniel Warner, que de acuerdo a los propósitos del proyecto serán mínimas gracias a que el proyecto se desarrollará como su trabajo de grado y ya cuenta con suficiente experiencia en desarrollo de aplicaciones cliente-servidor, servicios web, desarrollo de aplicaciones móviles para Android y posee conocimientos básicos en computación gráfica. A su vez, el sistema de información debe adaptarse a las siguientes características:

Estar desarrollado para dispositivos Android.

Implementar una arquitectura cliente-servidor de manera que pueda integrarse con los sistemas existentes actualmente en GS1 Colombia.

Hacer uso de Web Services para permitir la escalabilidad y mantenibilidad del proyecto.

La aplicación móvil debe poder ser descargada de Google Play.

Objetivo General

Desarrollar una aplicación móvil que permita tomar medidas volumétricas de diferentes objetos para poder obtener información logística que sea útil a los procesos de transporte y almacenamiento en bodega asociados a su venta.

Objetivos Específicos

Investigar los cinco métodos de análisis de imágenes que más tengan aplicabilidad dentro de la solución al problema planteado.

Plantear un modelo de toma de datos que permita que se mejore la calidad del contenido dentro del catálogo CABASnet en un 30%.

Construir un prototipo funcional de la aplicación propuesta.

Validar cuantitativamente el aporte que brinda la aplicación al ser implantada en un ambiente productivo real.

1.1.2 Suposiciones y Restricciones

o El cliente será quien defina las fechas de entrega de avances y entrega del producto final, fechas que serán contempladas dentro del cronograma general del proyecto.

o Se asume por parte de los stakeholders (el ingeniero Juan Plablo Garzón y la empresa GS1 Colombia) que los requerimientos del proyecto no cambiarán una vez iniciada la fase de desarrollo del sistema.

o El producto final contemplado en este plan de desarrollo será elaborado por un estudiante de Ingeniería de Sistemas, tomando como base una aplicación que fue desarrollada en el año 2012 en conjunto con dos compañeros más de la maestría en Ingeniería de Sistemas y Computación de la Universidad Javeriana.

o El estudiante no puede destinar grandes sumas de dinero para el proyecto por sus limitaciones económicas.

o El periodo total de desarrollo del proyecto estará comprendido entre las fechas 22 de Enero de 2013, fecha de inicio, y 26 de Mayo del mismo año, fecha de entrega de la totalidad del proyecto al cliente.

o La aplicación móvil debe poder ser descargada desde la tienda de aplicaciones online llamada Google Play

1.2 ENTREGABLES DEL PROYECTO

A medida que se lleve a cabo cada una de las fases metodológicas, se preparará un entregable, de manera que:

Para la primera fase metodológica se llevará a cabo un proceso de investigación enfocado en análisis de imágenes y visión artificial.

Para la segunda fase se planteará un modelo que mejore el proceso actual.

En la tercera fase se diseñará y desarrollará una aplicación software que permita tomar las medidas volumétricas de un objeto mediante el análisis de una fotografía del mismo. Para esto, se elaborará un documento SPMP que plantee el proceso de desarrollo de software que se llevará a cabo, un documento SRS que especifique los requerimientos del software a ser desarrollado y por último se hará entrega del prototipo funcional de la aplicación móvil que cumpla con el objetivo central de este proyecto, junto con sus respectivos manuales de usuario.

En la cuarta fase, se desarrollará un proceso de validación utilizando las métricas planteadas para evaluar la calidad de la solución generada. Finalmente se hará la entrega de la memoria del trabajo de grado.

En el siguiente gráfico se muestran a grandes rasgos las actividades a resolver durante la duración del proyecto, los entregables al cliente y las fases que agrupan cada conjunto de actividades dentro de una fecha.

1. REFERENCIAS

[1] Definición IDE. Mini diccionario informático de Carlos Pes.

http://www.carlospes.com/minidiccionario/entorno_integrado_de_desarrollo.ph

p

[2] Sección quiénes somos GS1 Colombia, <<GS1 Colombia – GS1>>, [Online].

Available: http://www.gs1co.org/en-us/nosotros/gs1colombia.aspx [Accessed:

23-mar-2013].

[3] Definición de software libre <<¿Qué es software libre? -Proyecto GNU->>,

[Online]. Available: http://www.gnu.org/philosophy/free-sw.es.html [Accessed:

13-mar-2013].

FASE I - 22/01/2013

•Investigar técnicas de visión artificial.

•Plantear una técnica que solucione el problema planteado.

•Informe con los resultados del proceso de investigación.

FASE II - 04/02/2013

• Reuniones con asesores externos pertenecientes a GS1 Colombia.

• Medir el tiempo y esfuerzo .requeridos para realizar el proceso.

• Disenar y validar un modelo que mejore el proceso actual.

FASE III -18/02/2013

• Elaborar documento SPMP.

• Documento SRS que sea acorde a los modelos planteados.

• Desarrollar los componentes de la aplicación que den solución al problema planteado.

•Manuales de usuario.

FASE IV -23/05/2013

• Realizar pruebas en campo, de la solución generada.

• Analizar la retroalimentación

•Entregar memorias de trabajo de grado

•Presentación del producto final

2. DEFINICIONES Y ACRÓNIMOS

SPMP: Software Project Management Plan.

SRS: Software Requirements Specifications.

IDE: Entorno Integrado de Desarrollo. Herramientas que ayudan a la programación de software en todas sus etapas (Edición, compilación y ejecución) sobre diversos lenguajes [1].

UML: Del inglés Unified Modeling Languaje o Lenguaje Unificado de Modelamiento.

La Nube: Conjunto de servidores remotos de propiedad de una empresa prestadora de servicios informáticos.

V & V: Verificación y validación.

3. ORGANIZACIÓN DEL PROYECTO

4.1 Interfaces Externas

Para el desarrollo óptimo del proyecto, el estudiante requerirá trabajar con entidades externas a la Universidad Javeriana, buscando que estas sean un apoyo vital a la hora de auditar el trabajo, darle soporte o brindar herramientas que faciliten su elaboración. Principalmente se requerirá trabajar de la mano con algunos representantes y empleados del área de sistemas de GS1 Colombia, quienes brindarán su apoyo para entender la problemática, el modelo actualmente utilizado en los procesos de toma de datos para actualizar el sistema de productos de la canasta familiar que se comercializan en los principales almacenes de cadena del país, llamado CABASnet [2]. Dichos representantes serán quienes validen los requerimientos, diseños arquitecturales y diseños de interfaces gráficas de la aplicación móvil. Por último, se contará con el apoyo y supervisión del profesor Juan Pablo Garzón, quien será el mentor y director para que el presente trabajo de grado se lleve a cabo bajo los suficientes parámetros investigativos y formales requeridos por la Pontificia Universidad Javeriana.

4.2 Estructura Interna

La persona encargada del presente proyecto es un estudiante de último semestre de la carrera de Ingeniería de Sistemas de la Pontificia Universidad Javeriana, que busca elaborar su trabajo de grado en la modalidad de aplicación práctica. El estudiante será quien planee y lleve a cabo todas las actividades relacionadas con la planeación y el desarrollo de la aplicación móvil anteriormente mencionada, de manera que asumirá varios roles dentro de su propio proyecto, los cuales se enuncian a continuación.

4.3 Roles y Responsabilidades

Debido a que dentro del proceso de ejecución del proyecto actual solo hay un integrante, todos los roles que deben tomarse dentro del proyecto, como un proyecto formal de desarrollo de software, serán asumidos por el mismo, a saber:

Cada uno de los roles a desempeñar dentro del proyecto requiere de ciertas habilidades y responsabilidades características que se verán reflejadas tanto en la planeación, como en la documentación, los planes de contingencia, de levantamiento de requerimientos, diseño de software y programación. Así que al ser asumidos todos los roles por un mismo personaje, se debe trabajar en el fortalecimiento de las habilidades en las que se tenga menos experiencia y experticia para llevar a cabo un proceso juicioso y bien gestionado en todos los aspectos.

5 PLAN DE PROCESOS DE GESTIÓN

5.1 PLAN DE ARRANQUE

5.1.1 Plan de Estimación

El plan de estimación es aquel por medio del cual se realiza una aproximación al costo que puede tomar el proyecto en total. Por eso es imperante un análisis suficientemente serio para evitar desfases de cobro o sobrecostos para el cliente, ya que el factor de cotización de un proyecto de diseño software en el mercado, como con cualquier otra actividad económica, es decisivo a la hora de contratar con un potencial vendedor o de mantener por más etapas un proyecto.

5.1.1.1 Responsables

La estimación de costos del proyecto está a cargo del Gerente de proyecto, ya que es él quien conoce el panorama general del mismo, sus fases, sus necesidades de recursos, el costo de tiempo y de personal para su desarrollo al igual que los requerimientos del cliente, que en la mayoría de los casos también competen a los costos.

•Daniel Warner DIRECTOR DE PROYECTO

•Daniel Warner ARQUITECTO

•Daniel Warner DIRECTOR DE DESARROLLO

•Daniel Warner DIRECTOR DE CALIDAD Y MANEJO DE RIESGOS

•Daniel Warner DOCUMENTADOR

•Daniel Warner TESTER

5.1.1.2 Plan de desarrollo del proyecto

Para el desarrollo del presente proyecto, el gerente del equipo, Daniel Warner hace un análisis de estimación de la siguiente manera: El proyecto se desarrollará del 22 de Enero del año 2013 al 26 de Mayo del mismo año para un total de cuatro meses de ejecución. La siguiente tabla detalla los costos asociados directamente con el desarrollo del proyecto a manera global.

RECURSOS FÍSICOS Y SERVICIOS

Ítem Cantidad Valor Total

Computador 1 $ 1.500.000

$ 1.500.000

Visitas técnicas a GS1 Colombia 5 $ 20.000 $ 100.000

Asesorías técnicas 4 $ 30.000 $ 120.000

Papelería 1 $ 40.000 $ 40.000

Recursos bibliográficos 2 $ 80.000 $ 160.000

Total $ 1.920.000

RECURSOS HUMANOS

Persona Horas de trabajo por semana

Semanas Precio por hora

Total

Daniel Warner White

12 18 $ 20.000 $ 4.320.000

Ing. Juan Pablo Garzón

2 18 $ 65.000 $ 2.340.000

Total 14 36 $ 85.000 $ 6.660.000

TOTALES

Ítem Valor

Recursos Humanos $ 6.660.000

Recursos Físicos y Servicios

$ 1.920.000

Total $ 8.580.000

5.1.1.3 Plan de adquisición de recursos

Para el desarrollo del proyecto y su viabilidad económica, el estudiante ha procurado utilizar la mayor cantidad de herramientas de licencia libre [3], o en su defecto versiones de prueba de herramientas que requieran de un licenciamiento pago. Así como se asumirá uno o varios roles de trabajo para cada una de las etapas, cada rol necesitará del uso de herramientas software y hardware diferentes para la

integración de documentos, de productos de software y de entregables. Dichas herramientas son:

Especializadas

1. Subclipse SVN: Herramienta que permite almacenar proyectos de software en repositorios de Google Code.

2. Netbeans: Herramienta IDE para el desarrollo de aplicaciones de tipo

empresarial con el lenguaje Java en su versión Enterprise Edition.

3. Visual Paradigm: Herramienta de pago para el diseño de software y

documentación asociada que utiliza el Lenguaje de Unificado de Modelamiento UML.

4. Eclipse: Herramienta IDE que permite el desarrollo de aplicaciones

para dispositivos Android mediante el plugin ADT.

Generales

1. Herramientas de ofimática: Suite Microsoft Office 2007, utilizada para elaborar los documentos, cronogramas y tablas adscritas a los entregables del proyecto.

2. DropBox: Herramienta que permite el almacenamiento y acceso de archivos en la nube.

3. Herramientas de Google: Herramientas desarrolladas por Google

para el acceso a documentos ofimáticos, correo electrónico y repositorios de proyectos de desarrollo de software.

5.2 PLAN DE TRABAJO

5.2.1 Actividades de Trabajo

Las actividades generales definidas para la realización del proyecto dentro del marco de cada fase, o corte de entrega se encuentran nombradas en el gráfico de entregables (ver sección 1.2) A continuación encontramos la muestra detallada de cada una de las actividades específicas descritas para cada una de las entregas al cliente durante el desarrollo del proyecto.

5.2.1.1 ACTIVIDADES FASE I

Tabla actividades de la Fase I

5.2.1.2 ACTIVIDADES FASE II

Tabla actividades de la Fase II

5.2.1.3 ACTIVIDADES FASE III

Tabla actividades de la Fase III

5.2.1.4 ACTIVIDADES FASE IV

5.2.2 Cronograma

Para el desarrollo del proyecto se definieron tres etapas de desarrollo denominadas Fase I, Fase II, Fase III y Fase IV. Cada fase será una iteración dentro del ciclo de vida del proyecto donde se desarrollarán unas actividades y se harán las correcciones pertinentes estimadas por el cliente para cada entrega. En términos generales, la Fase I comprende el proceso de investigación enfocado en análisis de imágenes y visión artificial, la Fase II comprende el planteamiento de un modelo de toma de datos que mejore el proceso actual. La Fase III por su lado, consiste en diseño y desarrollo de una aplicación software que permita tomar las medidas volumétricas de un objeto mediante el análisis de una fotografía del mismo. Finalmente la fase IV que es la validación cuantitativa del aporte generado por el sistema de información desarrollado. Un esquema un poco más detallado del desarrollo de estas actividades y sus fechas puede verse en el diagrama GANTT (ver Diagrama Gannt) del proyecto, y la especificación de cada una de las actividades generales dentro del diagrama se encuentra en la tabla de actividades por Fase (ver Sección 1.2) La responsabilidad del desarrollo de este cronograma será labor del rol de Gerente del proyecto, cuya principal responsabilidad debe ser organizar las actividades y velar por su cumplimiento bajo los parámetros de calidad establecidos.

5.3 PLAN DE CONTROL DE CALIDAD

5.3.1 Plan de Control de Calidad

Poder medir la calidad del software es un trabajo difícil de asegurar dada la naturaleza del producto, es por esto que la medición de la calidad de un producto de software se hace a través de la observación del proceso de desarrollo o de creación de éste [3]. La utilización de los procesos y métodos definidos por estándares aseguran que se cumpla con un mínimo de calidad de software, pues ayudan a cuantificar el aseguramiento de la calidad del mismo, a pesar de que no garanticen un producto perfecto y libre de fallas, lo cual le brinda al cliente los elementos necesarios para asegurar un poco más la confiabilidad en el producto final. Se buscará asegurar la calidad del software desarrollado teniendo en cuenta los siguientes principios definidos según la norma ISO 9126:

Funcionalidad: El grado en que el software satisface las necesidades

indicadas según:

o Idoneidad

o Corrección

o Conformidad

Confiabilidad: Cantidad de tiempo que el software está disponible para su

uso. Se indicará el grado de confiabilidad según:

o Tolerancia a fallos

o Facilidad de recuperación

Usabilidad: Grado en que el software es fácil de usar, se indica según:

o Facilidad de comprensión

o Facilidad de aprendizaje

o Operatividad.

Eficiencia: Grado en que el software hace óptimo el uso de los recursos del

sistema, se indica según:

o Tiempo de uso

o Recursos utilizados

Facilidad de Mantenimiento: La facilidad con que una modificación puede ser

realizada, se indica según:

o Facilidad de análisis

o Facilidad de cambio

o Estabilidad

o Facilidad de prueba

5.4 PLAN DE ADMINISTRACIÓN DE RIEGOS

5.4.1 Introducción

Una tarea muy importante en un proyecto es poder identificar los riesgos, desde el de impacto más pequeño o insignificante, hasta los que podrían hacer de un proyecto un fracaso total. Estos deben ser diferenciados, medidos y tomados en cuenta para la toma de decisiones.

5.4.2 Objetivos

La administración de riesgos busca:

Prever situaciones problemáticas y catastróficas que puedan afectar el

proyecto, mediante la supervisión y control de los riesgos.

Calcular el índice de ocurrencia y el impacto que cualquier riesgo pueda

presentar y pueda afectar el normal desarrollo del proyecto.

Crear planes que permitan controlar los efectos de los riesgos y reduzcan el

índice de aparición de estos.

5.4.3 Detalle del plan

Para lograr mitigar todos los riesgos de la mejor manera posible, se evaluará

semanalmente la siguiente tabla [tabla] que detalla cada uno de los riesgos

identificados y contiene acciones estratégicas para su supervisión y reducción, al

igual que para su control en caso tal de que se materialicen.

5.4.4 Responsable

Director de calidad y manejo de riesgos.

5.5 PLAN DE CIERRE

El plan de cierre contempla la revisión sistemática de todas las partes concernientes al proyecto, tanto de producto final, como de su respectiva documentación. Los objetivos de este plan son realizar el cierre de todos los planes y garantizar el orden y la coherencia del proyecto.

5.5.1 Actividades

Se realizarán las siguientes actividades:

Se revisarán todas las plantillas y/o documentos mayores de los cuales se encuentra conformada la documentación asociada al diseño de la aplicación.

Se revisarán todas las auditorías y correcciones que sean realizadas durante el proceso de análisis y diseño.

Si es necesario, se harán “cambios de última hora” pertinentes a errores encontrados en este plan, ya sea por ausencia de correcciones, descubrimiento de nuevos errores, partes del documento inconclusas, se necesiten mejoras al documento o se añadan nuevos puntos a considerar dentro del documento.

Se realizará una última reunión con el cliente para la consolidación del proyecto con las necesidades reales del cliente, buscando una mejor aceptación y conformidad con el producto por parte del mismo.

5.5.2 Aceptación por parte del cliente

Se dirá que el cliente acepta el producto cuando:

Este acepta los diseños: el cliente acepta los diagramas de diseño del producto.

Verifica que el producto sea eficaz: el cliente verifica que el producto cumpla con los requerimientos funcionales.

Entiende el funcionamiento del producto y cómo operarlo.

No presente quejas y/o mejoras relacionadas con los documentos SRS y SDD.

Una vez se cumpla con todo lo anterior, se hará entrega del producto final al cliente y a sus respectivos evaluadores.

6 PLAN DE PROCESOS TÉCNICOS

6.1 MODELO DE CICLO DE VIDA DEL PROCESO

6.1.1 Objetivos específicos:

Especificar las etapas de desarrollo del presente proyecto.

Determinar qué modelo de ciclo de vida encaja con el desarrollo del proyecto

Planificar las distintas etapas involucradas en el proyecto.

6.1.2 Desarrollo del plan

El modelo de ciclo de vida de software fue la espiral de Boehm [3], pues tiene las siguientes características convenientes:

Proceso orientado por el manejo de riesgos.

Orientado a constantes iteraciones.

Involucra al cliente en fases específicas del desarrollo (al final de cada iteración).

En la siguiente ilustración se muestra un diagrama del mismo:

Ilustración 1: Ciclo de vida del proyecto

6.2 MÉTODOS, HERRAMIENTAS Y TÉCNICAS

6.2.1 Objetivo

El objetivo de este plan es tener claro los ambientes que permitirán el buen desarrollo en el ciclo de vida del proyecto, disminuyendo la posibilidad de que en algún instante del progreso del mismo, cambie de ambiente de implementación y esto cause problemas en la finalización del proyecto.

6.2.2 Metodología del desarrollo del proyecto

Este proyecto se desarrollará con la metodología de programación orientada a objetos, que nos facilitará el modelado de los componentes de tal manera que se distingan por sus características, para que se relacionen entre sí con los distintos objetos existentes. ¡Error! No se encuentra el origen de la referencia.

6.2.3 Lenguaje de programación

Los lenguajes de programación que se utilizarán serán Java para Android, Java EE 6 y C++. La plataforma Java EE 6 se usara para la implementación del modelo de negocio y la capa de persistencia de datos de la aplicación. La plataforma Java para Android será utilizada principalmente para desarrollar la aplicación móvil. El lenguaje C++ será utilizado para el manejo de componentes que requieran de análisis de imágenes y visión artificial, debido a que la principal librería a utilizar para dichos propósitos (OpenCV) está desarrollada en dicho lenguaje. Es importante resaltar que estos tipos de lenguajes contienen APIs que nos brindan una gran variedad de herramientas útiles para el desarrollo de este proyecto.

6.2.4 Herramientas de software

Las herramientas que como grupo tendremos disponibles, serán una gran variedad de programas que darán apoyo a la realización de documentos, imágenes, tablas, modelado, entre otros y que permitirán un mejor desarrollo en el ciclo de vida del proyecto.

6.3 PLAN DE INFRAESTRUCTURA

6.3.1 Introducción

A continuación se describirá de forma detallada los aspectos físicos y digitales con los que contará el estudiante para el desarrollo del software definiendo características de procesador, memorias, capacidad de almacenamiento, sistema operativo que está corriendo la máquina del integrante, características de la tarjeta de video ya sea integrada o compartida y programas que éste pueda utilizar.

6.3.2 Objetivo

El objetivo de este plan, es detallar todos los componentes inherentes al desarrollo del software que como grupo estamos desarrollando y que utilizará a lo largo del mismo.

6.3.3 Características de equipos

ENUMERACIÓN DE EQUIPOS

ID

Propietario

Marca-Modelo

Procesador

Memoria

RAM

Capacidad

D.D

Sistema

Operativo

PC1 Daniel Warner

SONY VAIO Intel Core i7 Q740 @1.73 GHz

4GB

455 GB

Windows 7 Home Premium

Tablet 1

Daniel Warner

Samsung Nexus 10

ARM Cortex A-15 Dual Core @ 1700MHz

2GB

16 GB

Android 4.2.2

PC2

Daniel Warner

Macbook Pro 15”

Intel Core 2 Duo 2.4 GHz

8GB

250GB

OS X Mountain Lion

Ilustración 2: Equipos

6.4 PLAN DE ACEPTACIÓN DEL PRODUCTO

Para lograr la aceptación del producto se harán pruebas formales de software, buscando que lo entregado funcione de manera correcta y teniendo en cuenta los requerimientos asociados. ¡Error! No se encuentra el origen de la referencia. Anteriormente se especificó un plan de calidad que busca, de igual forma, que el producto entregado sea correcto. El entorno de pruebas que dispondremos para llevar a cabo cada una de las pruebas de software será la herramienta JUnit, con éste software se llevarán a cabo todas las pruebas que se tengan que realizar según los criterios de revisión de software que se hayan implementado.

7 PLAN DE PROCESOS DE SOPORTE

7.1 PLAN DE ADMINISTRACIÓN DE LA CONFIGURACIÓN

7.1.1 INTRODUCCIÓN

El objetivo general del plan de administración de la configuración es el de evaluar y controlar los cambios que se presenten en los ítems de configuración, a su vez evaluar y mantener la integridad de estos ítems.

7.1.2 OBJETIVOS

Monitorear los cambios que presenten los ítems de configuración durante la

elaboración del software.

Definir el formato en el cuál se llevará un registro de los cambios realizados.

Mantener un repositorio donde se encuentren los ítems de configuración para

un fácil monitoreo de éstos.

7.1.3 PLAN DE DESARROLLO

Se manejarán dos tipos de versiones, una para documentos y la otra para software y código fuente.

7.1.3.1 Versión de Documentos

Para manejar cualquier tipo de documento, se utilizarán las herramientas ofimáticas de Microsoft Office y para mantener aseguradas las copias de seguridad, se utilizará la herramienta DropBox, de manera que cada documento quede almacenado en La Nube. Respecto al versionamiento de los documentos, la numeración de las versiones se lleva de tal manera que:

El primer documento realizado será la versión 0.0.0.

Cada vez que se modifique el documento con cambios importantes, como

incluir nuevas secciones, cambiará la segunda cifra aumentando de a uno en

uno. Por ejemplo, si al primer documento se le agrega una nueva sección, se

crearía una nueva versión, pasando de 0.0.0 a 0.1.0.

Cada vez que se modifiquen asuntos que no cambien la estructura del

documento, como redacción o ampliación de algún párrafo, cambiará la

tercera cifra aumentando de uno a uno, es decir, si al documento inicial se le

realiza este tipo de cambios, se crearía una nueva versión, pasando de 0.0.0.

a 0.0.1.

7.1.3.2 Versión de Software y código fuente

Para llevar un monitoreo del avance que se tenga con el software y más específicamente con el código fuente, se trabajará con la aplicación SVN (Subversion). Con ella se tiene la posibilidad de mantener un repositorio de software el cual puede ser actualizado constantemente. Esto se hará de tal manera al conectarse al repositorio, éste tendrá almacenadas todas las versiones del código de manera que se pueda retroceder en el eventual caso de que se cometa un error de difícil reparación o un error fatal.

7.1.4 RIESGOS

Se puede presentar incoherencias en la estructura del proyecto.

Fallo en el funcionamiento de las herramientas usadas para esta labor, por

ejemplo repositorios.

7.1.5 HERRAMIENTAS

Las herramientas que serán utilizadas para llevar el control y registro de las versiones y cambios realizados a lo largo del proyecto son las siguientes:

Ilustración 3 Herramientas de Configuración

En la siguiente tabla se especifica para qué situaciones se hará uso de cada una de las herramientas de configuración. (Ver ilustración 21)

HERRAMIENTAS DE VERSIONES

SubClipse SVN- Permite crear, alojar, modificar y monitorear los cambios

de codigo fuente.

DropBox - Permite subir archivos, documentos, fotos y videos en la web

para compartirlos facilmente.

DESCRIPCIÓN DE LA SITUACIÓN HERRAMIENTA

Después de cada modificación a cualquier documento, se procederá a almacenar su correspondiente versión en DropBox. DropBox

Se hacen cambios en el código fuente.

Subclipse SVN

Tabla 2 Herramientas de Versiones

7.1.6 MONITOREO Y CONTROL

Para efectos de llevar una buena tarea en el control de cambios tanto en documentación como en el desarrollo, se hará uso de la siguiente plantilla:

CONTROL DE VERSIONES

Nombre o explicación de la tarea que se realizó

Nombre de Entregable o documento que afectó.

Versión actual después de la modificación.

Autor de la modificación.

Tabla 3 Control de versiones

7.2 PLAN DE VERIFICACIÓN Y VALIDACIÓN

7.2.1 INTRODUCCIÓN

Una tarea muy importante en el desarrollo de software, es la de validar y verificar que el producto final cumpla con las especificaciones dadas por el cliente. Mediante un buen proceso de V & V se pueden garantizar índices altos de calidad. Esto dado que en un proceso de V & V bien realizado, se encuentran los errores más insignificantes que pueden causar, en pluralidad, errores mayores afectando la calidad de la entrega final. Este proceso también busca garantizar, al igual que los planes de control, garantía y cierre, que el producto se encuentre en conformidad de las necesidades del cliente. Para la realización de este plan se entiende la diferencia entre verificación y validación como lo explica Sommerville [19]:

Validación: Se está construyendo el producto correcto.

Verificación: Se está construyendo el producto correctamente.

Dada esta diferenciación se entiende que al hablar de validación hablamos de la coherencia entre las necesidades del cliente y las funcionalidades reales del producto. Y de verificación como la calidad intrínseca del producto, es decir la calidad de los procesos de desarrollo.

7.2.2 OBJETIVOS

Verificar que el producto final cumpla con el alcance establecido por el cliente

y por el estudiante.

Llevar un control de errores e implementar mecanismos para la detección de

los mismos.

Entregar un producto de calidad que se rija por unos estándares establecidos

internacionalmente (ver sección 5.3).

7.2.3 FUNCIONAMIENTO DEL SOFTWARE

Se revisará el funcionamiento del software dados los aspectos de calidad definidos en el Plan de Control de Calidad (ver sección 5.3) y se realizará simultáneamente con toda la sección 5 de este documento. Además se realizarán ejecuciones del programa en uso continuo y prolongado para generar posibles situaciones donde frecuentemente fallan los programas dada la utilización de los recursos del computador y su continuo uso de red. En caso de falla se probará su tolerancia a éstas y su capacidad de recuperación.

7.2.4 EXPECTATIVAS DEL USUARIO

En este punto se busca entregar un sistema fiable al usuario, al mismo tiempo que cumpla con las expectativas del cliente. La entrega al cliente se realizará en conjunto con las pruebas del software buscando la integridad de éste, asegurando los mayores índices de calidad.

7.2.5 VALIDACIÓN Y VERIFICACIÓN

Establecidos los parámetros de calidad de procesos, software, documentación y en general del proyecto, la validación y la verificación se encuentran en permanente observación, ya que se encuentran incluidas en todas las planeaciones concernientes a la búsqueda sistemática de calidad, coherencia y total satisfacción.

7.3 PLAN DE DOCUMENTACIÓN

7.3.1 INTRODUCCIÓN

En Ingeniería de Software es de gran importancia que todas las tareas referentes al proyecto que se está desarrollando estén debidamente documentadas, ya que será de gran ayuda tanto quien desarrolla el producto, como para el cliente, para un mejor entendimiento del proceso llevado a cabo.

7.3.2 OBJETIVOS

Definir los estándares con los cuales se regirán los documentos entregables.

Establecer de qué forma se supervisará que las tareas de documentación se

lleven de la mejor forma posible.

Establecer las herramientas con las cuáles se va a llevar a cabo esta tarea.

7.3.3 PLAN DE DESARROLLO

A continuación se presenta cada uno de los documentos entregables y su respectivo estándar bajo el cual se regirá su elaboración.

Tabla 4 Estándares

SPMP

-1058-1998 - IEEE Standard for Software Project Management Plan. [26] - Plantilla SPMP. IronWorks. (Plantilla base) [25]

SRS - 830-1998 - IEEE Recommended Practice for Software Requirements Specifications. [27] -Plantilla SRS. IronWorks. (Plantilla base)[26]

0 SDD -1016-2009 - IEEE Recommended Practice for Software Design Descriptions Specifications Plans [28] -Plantilla SDD. IronWorks. (Plantilla

base)[25] Manual de Usuario

-Plantilla de Manual de Usuario.

IronWorks (Plantilla base)[25]

Por otro lado, el documento debe poseer buena redacción y ortografía, deben estar adecuadamente referenciadas las fuentes y debe estar organizado siguiendo un índice. Cada uno de estos documentos se entregará al cliente en las fechas establecidas.

7.3.4 RIESGOS

Mala redacción.

Omitir referencias.

Plagio de información

7.3.5 HERRAMIENTAS

Para tener como resultado una documentación sobresaliente, se tomará los documentos subidos a DropBox y se les agregará detalles de presentación, para esto utilizará la siguiente herramienta:

Microsoft Office 2010

7.3.6 SUPERVISIÓN Y CONTROL

Previamente a la entrega de cualquier documento al cliente, se realizará un checklist para así determinar si el documento cumple con los estándares y requisitos expuestos en la sección 7.3.3. Se ha establecido que la plantilla base para la elaboración de los documentos es la plantilla de IronWorks, aunque se tomará también elementos existentes los estándares de la IEEE.

CUMPLE

REQUISITO SI NO

¿Cumple el documento con la plantilla de IronWorks definida en el plan de documentación?

¿El documento cuenta con una buena ortografía?

¿Es claro el documento en cuanto a redacción?

¿El documento se encuentra debidamente referenciado?

OBSERVACIONES

Tabla 5 Control de documentación

7.4 PLAN DE ASEGURAMIENTO DE LA CALIDAD

7.4.1 INTRODUCCIÓN

El Plan de Aseguramiento de Calidad contempla todos los aspectos de calidad del proyecto al igual que evalúa todos los riesgos contemplados a lo largo del proceso de desarrollo.

7.4.2 OBJETIVOS

Asegurar la coherencia de la documentación con el software.

Asegurar que el software construido es el software anhelado.

Asegurar que el desarrollo del software sea congruente a los procesos

debidos según la metodología implementada.

Asegurar un mejoramiento en los procesos.

Asegurar la satisfacción del cliente

7.4.3 REVISIÓN DE PLANES

El plan de aseguramiento es el plan macro dentro del cual se gestionarán todos los controles del proyecto. Estas revisiones incluyen:

Revisión de la situación actual del componente del proyecto, su visión

general y partes subyacentes del mismo su como resumen y evolución.

Revisión de referencias y bibliografía.

Revisión del plan de procesos de gestión.

o Revisión del plan de arranque.

o Revisión del plan de trabajo.

o Revisión del plan de control.

o Revisión del plan de gestión de riesgos.

o Revisión del plan de cierre.

Revisión del plan de procesos técnicos.

Para el plan de procesos de soporte, la revisión será cómo se describe a continuación:

La revisión estándar se realizará sobre:

o Plan de administración de configuraciones.

o Plan de verificaciones y validación.

o Plan de la documentación.

o Plan de resolución de problemas.

o Plan de administración de subcontratos.

o Plan de mejoras del proceso.

Para el plan de revisiones y auditorias, se contempla lo siguiente:

o Exigencias

o Análisis

o Enfoque

o Metodología

7.4.3.1 PÁRAMETROS

Las revisiones seguirán las siguientes condiciones:

Gramática

Ortografía

Necesidades.

Aporte al desarrollo del proyecto.

Coherencia con la finalidad u objetivo deseado.

Estructuración

Encargado(s) o responsable(s) de la(s) tarea(s).

Distribución equitativa de cargas.

Actualización con la realidad del proyecto.

Cronograma

Uso de herramientas.

Proceso o metodología usada.

Identificación de riesgos.

Problemas presentados.

Resolución de problemas.

Conflictos presentados (personales).

Mejoras

Observaciones

7.4.4 RIESGOS

El manejo o gestión de riesgos, según el Plan de Gestión de Riesgos (ver sección 5.4), será llevado en paralelo con el proceso general de avance del proyecto. En la ejecución de este plan, también se encuentra la autorización para realizar modificaciones en las tablas de planificación de los riesgos. Así mismo, dado que en revisiones se encuentran riesgos nuevos, se establece la autoridad para identificar y generar planes de mitigación de nuevos riesgos.

7.5 PLAN DE REVISIONES Y AUDITORIAS

7.5.1 INTRODUCCIÓN

El fin de este plan es el de controlar y verificar la calidad de cada una de las actividades realizadas dentro del plan de trabajo.

7.5.2 OBJETIVOS

Asegurar una revisión de calidad a cada una de las actividades del proyecto.

Garantizar que los entregables sigan los estándares de calidad establecidos.

7.5.3 RIESGOS

Revisión pobre de los documentos.

Revisión pobre del código.

7.6 PLAN DE ADMINISTRACIÓN DE SUBCONTRATOS De acuerdo a las reglas del proyecto no es posible contar con la ayuda de terceros para el desarrollo del mismo.

7.7 PLAN DE MEJORAS DEL PROCESO

7.7.1 INTRODUCCIÓN

Es importante que cada vez se vaya evaluando el desempeño de cada uno de los procesos, esto ayuda a que el proyecto cada vez esté más completo y libre de errores que puedan afectar su operación.

7.7.2 OBJETIVOS

Eficiencia en el desarrollo de cada uno de los entregables.

Satisfacer al cliente de manera que cada vez los proyectos realizados se

parezcan más a lo que se desea.

7.7.3 PLAN DE DESARROLLO

Para realizar mejoras a procesos los pasos a seguir son los siguientes:

1. Se evaluará cada una de las actividades que se llevan a cabo durante el

desarrollo de un proyecto.

2. Se generará un reporte de las observaciones relevantes de cada proceso

evaluado.

3. Contando con los comentarios del cliente después de entregado un proyecto,

se llevaran a cabo las correcciones y aclaraciones pertinentes.

4. Se definirá de qué manera se llevarán a cabo de ahora en adelante los

procesos que presentaron falencias.

5. La modificación o inclusión de procesos debe ser debidamente documentada.

7.7.4 RIESGOS

La sobrecarga de trabajo entorpece el avance del proyecto.

Después de terminadas las tareas no se observa una mejora.

8 ANEXOS

REFERENCIAS DE LA PLANTILLA [1] Construx Software, Configuration Management CXOne Standard, Construx Software Builder, Inc, Noviembre 2002. [2] NASA (National Aeronautics and Space Administration) SEI (Software Engineering Laboratory), Recommended Approach to Software Development, Revisión 3, Junio 1992. [3] IEEE (Institute of Electrical and Electronics Engineers), IEEE Standard for Software Project Management Plans, IEEE-SA Standards Board, Diciembre 1998. [4] ESA (European Space Agency) Board for Software Standarisation and Control (BSSC), Guide to Software Project Management, Revisión 1, Marzo 1995. [5] Construx Software, Project Management CXOne Standard, Construx Software Builder, Inc, Noviembre 2002. [6] Diccionario de la Real Academia Española. Disponible en: http://www.rae.es/ [7] Sommerville I. Ingeniería de Software. 7th ed. Romo MM. Madrid: Pearson Educación. S.A.; 2005. [8] Larman C. UML Y PATRONES. Una introducción al análisis y diseño orientado a objetos y al proceso unificado. 2nd ed. Aragón DF. Madrid: Pearson Educación. S.A.; 2003. [9] Bruegge B, Dutoit AH. Ingeniería de Software orientada a objetos. 1st ed. Trujano G. México: Pearson Educación; 2002. [10] Página de Miguel Torres [homepage de Internet]. Bogotá. Ing. Miguel Eduardo Torres Moreno MSc. Copyright - Miguel Torres 2007. [Actualizado el 26 Feb. 2007; citado 11 Feb. 2007]. Materias - Ingeniera de Software – Plantilla SRS [aprox. 3era pantalla].Disponible en: http://sophia.javeriana.edu.co/~metorres/ [11] JabRef Reference Manager. Disponible en: http://jabref.sourceforge.net/ [12] Objetivos SMART. Disponible en: http://changingminds.org/disciplines/hr/performance_management/smart_objectives.htm [13] Tortoise CVS, Repositorio de Archivos. Disponible en: http://www.tortoisecvs.org/ [14] Eclipse Herramienta IDE. Disponible en: http://www.eclipse.org/ [15] Construx, Software Development Best Practices. Disponible en: http://www.construx.com/ [16] Construx Software, Qualilty Plan CXOne CheckList, Construx Software Builder, Inc, 2002. [17] JAVADOC Documentation Tool. Disponible en: http://java.sun.com/j2se/javadoc/ [18] Kendall KE, Kendall JE. Análisis y diseño de sistemas. 6th ed. Horan B. México: Pearson Educación. S.A.; 2005. [19] IEEE Computer Society Style Guide – References, 2006, disponible en: http://www.computer.org/portal/site/ieeecs/menuitem.c5efb9b8ade9096b8a9ca0108bcd45f3/index.jsp?&pName=ieeecs_level1&path=ieeecs/publications/author/style&file=refer.xml&xsl=generic.xsl&