Generador de Escenarios de Planeación para la Gestión de ...

Pontificia Universidad Javeriana Memoria de Trabajo de Grado - Profundización

Página 1

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

PA163-3-SIGPLAN

Generador de Escenarios de Planeación para la Gestión de un Proyecto

informático- SIGPLAN.

Paulo Alexander Chirán Portillo

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

MAESTRÍA EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

BOGOTÁ, D.C.

2016


Página 2

PA163-3-SIGPLAN

Generador de Escenarios de Planeación para la Gestión de un Proyecto

informático- SIGPLAN.

Autor:

Paulo Alexander Chirán Portillo

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO

DE LOS REQUISITOS PARA OPTAR AL TITULO DE

MAGÍSTER EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

Directora

María Mercedes Corral Strassmann, MsC

Comité de Evaluación del Trabajo de Grado

Rafael Andrés Gonzales Rivera, PhD

Luz Marina Sánchez Ayala, PhD

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

MAESTRÍA EN INGENIERIA DE SISTEMAS Y COMPUTACIÓN

BOGOTÁ, D.C.

11, 2016

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/


Página 3


PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA

MAESTRÍA EN INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

Rector Magnífico

Jorge Humberto Peláez, S.J.

Decano Facultad de Ingeniería

Ingeniero Jorge Luis Sánchez Téllez

Director Maestría en Ingeniería de Sistemas y Computación

Ingeniera Ángela Carrillo Ramos

Director Departamento de Ingeniería de Sistemas

Ingeniero Efraín Ortíz Pabón


Página 4

Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus

proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral

católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que

se vean en ellos el anhelo de buscar la verdad y la Justicia”


Página 5


AGRADECIMIENTOS

Agradezco a en primer lugar a Dios, mis padres mi novia y todas las personas que ayudaron de

una u otra forma a alcanzar esta meta, pongo todos los conocimientos adquiridos al servicio de

la sociedad para ayudar a construir un mundo mejor.

Agradezco a la Ingeniera María Mercedes Corral por apoyarme durante todo el proceso y brin-

darme sus grandes aportes al proyecto, estaré infinitamente agradecido por todo lo que he

aprendido de ella.

Agradezco a la empresa ITAC quien acompaño el proceso de desarrollo del proyecto y que

gracias a sus aportes se estructuró por buen camino el desarrollo del mismo siempre en el sen-

tido de mejorar la planeación de proyectos.


Página 6

Contenido

1 INTRODUCCIÓN ......................................................................................................15

2 DESCRIPCIÓN GENERAL .........................................................................................17

2.1 PROBLEMÁTICA ................................................................................................17

2.2 OPORTUNIDAD ..................................................................................................18

3 DESCRIPCIÓN DEL PROYECTO ...............................................................................21

3.1 OBJETIVO GENERAL ..........................................................................................21

3.2 OBJETIVOS ESPECÍFICOS ....................................................................................21

3.3 METODOLOGÍA .................................................................................................21 3.3.1 Fase 1: Identificar el problema y establecer una motivación .............................. 23 3.3.2 Fase 2: Proponer los Objetivos ........................................................................... 23 3.3.3 Fase 3: Diseñar y desarrollar .............................................................................. 24 3.3.4 Fase 4: Demostrar ............................................................................................... 25 3.3.5 Fase 5: Evaluar .................................................................................................... 26 3.3.6 Fase 6: Comunicar .............................................................................................. 26

4 ESTADO DEL ARTE ..................................................................................................27

5 TRABAJOS RELACIONADOS ....................................................................................32

6 FASE 1 - IDENTIFICAR EL PROBLEMA Y ESTABLECER UNA MOTIVACIÓN ............34

6.1 COMPONENTES DEL PROYECTO SIGPLAN .......................................................34 6.1.1 Plan marco de trabajo ......................................................................................... 35 6.1.2 Metodología de desarrollo ................................................................................... 35

7 FASE 2 PROPONER LOS OBJETIVOS ......................................................................37

7.1 ALCANCE DEL PROYECTO..................................................................................37

7.2 DESCOMPOSICIÓN DEL TRABAJO EDT ...............................................................37

7.3 PLAN DE GESTIÓN DEL TIEMPO ..........................................................................41 7.3.1 Resultados Esperados .......................................................................................... 41 7.3.2 Cronograma ......................................................................................................... 41

7.4 PROSPECTIVA DE INNOVACIÓN ..........................................................................42

7.5 IMPACTOS POTENCIALES ...................................................................................43

7.6 PLAN DE GESTIÓN DE RECURSOS HUMANOS ......................................................44


Página 7


7.6.1 Organigrama ........................................................................................................ 44 7.6.2 Roles y responsables ............................................................................................ 45

7.7 VINCULACIÓN DEL PROYECTO CON ITAC .........................................................45

7.8 PLAN DE GESTIÓN DEL RIESGO ..........................................................................47

7.9 GESTIÓN DE LA CALIDAD DEL PROYECTO ..........................................................50

7.10 ESTRATEGIA DE COMUNICACIONES ...................................................................51

7.11 COMPONENTES ..................................................................................................51 7.11.1 Métodos de estimación ..................................................................................... 51 7.11.2 Información base de ITAC ............................................................................... 51 7.11.3 Clasificación de proyectos ............................................................................... 52 7.11.4 Descomposición de proyectos .......................................................................... 54 7.11.5 Herramientas de desarrollo ............................................................................. 55 7.11.6 Requerimientos ................................................................................................ 55

7.12 BASES DE CONOCIMIENTO .................................................................................55

7.13 INFORMACIÓN DE PROYECTOS DE ITAC ...........................................................56

7.14 INFORME DE RETROSPECTIVA ............................................................................62

8 FASE 3 DISEÑAR Y DESARROLLAR .........................................................................63

8.1 ARQUITECTURA ................................................................................................63 8.1.1 Alcance ................................................................................................................. 63 8.1.2 Audiencia ............................................................................................................. 63 8.1.3 Motivaciones de negocio ...................................................................................... 63 8.1.4 Decisiones de arquitectura .................................................................................. 63

8.2 RECOMENDACIONES PARA EL USO DE TECNOLOGÍA JEE ...................................63

8.3 ENTIDADES .......................................................................................................64

8.4 CLIENTES WEB .................................................................................................64

8.5 COMUNICACIÓN DEL SERVIDOR ........................................................................64

8.6 COMPONENTES DE LA APLICACIÓN SIGPLAN ..................................................65 8.6.2 Vista Funcional .................................................................................................... 66 8.6.3 Vista de alto nivel ................................................................................................. 66 8.6.4 Vista Detallada .................................................................................................... 67 8.6.5 Despliegue físico .................................................................................................. 68 8.6.6 Capas del Sistema ................................................................................................ 68

8.7 MODELO DE DOMINIO .......................................................................................69 8.7.1 Modelo entidad relación ...................................................................................... 69

8.8 DOCUMENTO DE CASOS DE USO ........................................................................71 8.8.1 Proceso de administración y configuración ........................................................ 72


Página 8

8.8.2 Proceso de Proyectos ........................................................................................... 72 8.8.3 Proceso de generación de escenarios .................................................................. 73

8.9 PROTOTIPO ........................................................................................................73

8.10 DESARROLLO ....................................................................................................74 8.10.1 Módulo de Administración ............................................................................... 74 8.10.2 Módulo de costos ............................................................................................. 75 8.10.3 Módulo de proyectos ........................................................................................ 76 8.10.4 Motor generador de escenarios ....................................................................... 76 8.10.5 Calculador de factores ..................................................................................... 76 8.10.6 Módulo de escenarios ...................................................................................... 76 8.10.7 Base de datos ................................................................................................... 76

8.11 PRUEBAS Y CORRECCIÓN DE ERRORES ..............................................................76

9 FASE 4 DEMOSTRAR ...............................................................................................78

9.1 PLAN DE PRUEBAS Y RUBRICA DE EVALUACIÓN ...............................................78

10 FASE 5 EVALUAR ..............................................................................................79

10.1 RESULTADO DE PRUEBAS ..................................................................................79 10.1.1 Observaciones generales ................................................................................. 80

10.2 CONTROL AL ALCANCE .....................................................................................82

11 FASE 6 COMUNICAR .........................................................................................82

11.1 MEMORIAS DE TRABAJO DE GRADO ...................................................................82

11.2 MANUAL TÉCNICO ............................................................................................82

11.3 SOLUCIÓN SIGPLAN .......................................................................................83

11.4 CONCLUSIONES .................................................................................................83 11.4.1 Conclusiones generales.................................................................................... 83 11.4.2 Frente a las pruebas con gerentes ................................................................... 84 11.4.3 Frente a los escenarios .................................................................................... 84

11.5 TRABAJOS FUTUROS .........................................................................................85

12 ANEXOS ............................................................................................................86

13 REFERENCIAS ..................................................................................................92


Página 9


Tabla de figuras FIGURA 1:GRAFICA DE PLANTEAMIENTO DE UN PROYECTO INFORMÁTICO .............................................................. 19 FIGURA 2: CICLOS DE LA METODOLOGÍA LLAMADA CIENCIA BASADA EN EL DISEÑO ................................................... 22 FIGURA 3: SECTOR SOFTWARE Y TECNOLOGÍAS DE LA INFORMACIÓN COLOMBIA ..................................................... 29 FIGURA 4: COMPONENTES DE LA SOLUCIÓN PLANTEADA .................................................................................... 34 FIGURA 5: CATEGORIZACIÓN DE LOS PROCESOS DE UN PROYECTO ........................................................................ 35 FIGURA 6: ESTRUCTURA DE DESCOMPOSICIÓN DEL TRABAJO ............................................................................... 37 FIGURA 7: ORGANIGRAMA DEL PROYECTO ....................................................................................................... 44 FIGURA 8: NIVELES DE MADUREZ CMMI ........................................................................................................ 45 FIGURA 9: CATEGORÍAS DE CMMI DEV ......................................................................................................... 46 FIGURA 10: ESTRUCTURA DE DESCOMPOSICIÓN DEL RIESGO ............................................................................... 47 FIGURA 11: COMPONENTES DE UN PROYECTO DE DESARROLLO DE SOFTWARE ........................................................ 52 FIGURA 12: MÓDULOS GENERALES DEL SISTEMA SIGPLAN................................................................................ 58 FIGURA 13: MÓDULOS DE PROYECTO SIGPLAN .............................................................................................. 58 FIGURA 14: MÓDULO DE COSTOS .................................................................................................................. 59 FIGURA 15: MÓDULO DE GESTIÓN DE PROYECTOS ............................................................................................ 61 FIGURA 16: MÓDULO DE GENERACIÓN DE ESCENARIOS...................................................................................... 61 FIGURA 17: COMUNICACIÓN DEL SERVIDOR ..................................................................................................... 64 FIGURA 19: COMPONENTES DE DESPLIEGUE .................................................................................................... 65 FIGURA 20: VISTA DE ALTO NIVEL DE SIGPLAN ............................................................................................... 67 FIGURA 21: VISTA DETALLADA DE SIGPLAN ................................................................................................... 67 FIGURA 22: DESPLIEGUE FÍSICO DE SIGPLAN .................................................................................................. 68 FIGURA 23: MODELO DE DOMINIO................................................................................................................ 69 FIGURA 24: MODELO ENTIDAD RELACIÓN ....................................................................................................... 69 FIGURA 25:MODELO EVOLUTIVO, ................................................................................................................. 73 FIGURA 26: COMPONENTES DE LA SOLUCIÓN SIGPLAN .................................................................................... 74 FIGURA 27: CONSOLIDADO DE PREGUNTAS ..................................................................................................... 79


Página 10

Tabla de tablas TABLA 1: CODIFICACIÓN DE LAS ACTIVIDADES ................................................................................................... 30 TABLA 2: CARACTERÍSTICAS DE EVALUACIÓN .................................................................................................... 32 TABLA 3: CRUCE DE LAS CARACTERÍSTICAS DE EVALUACIÓN Y LOS PROYECTOS ENCONTRADOS .................................... 33 TABLA 4: TABLA QUE DESCRIBE LOS COMPONENTES DE LA EDT ........................................................................... 38 TABLA 5: TABLA DE LOS RESULTADOS ESPERADOS ............................................................................................. 41 TABLA 6: CRONOGRAMA DEL PROYECTO.......................................................................................................... 41 TABLA 7: PROSPECTIVA DE INNOVACIÓN ......................................................................................................... 42 TABLA 8: IMPACTOS POTENCIALES ................................................................................................................. 43 TABLA 9: DEFINICIÓN DE LAS ESCALAS DE IMPACTO DEL RIESGO ........................................................................... 48 TABLA 10: PLAN DE MITIGACIÓN DEL RIESGO ................................................................................................... 49 TABLA 11: HERRAMIENTAS DE DESARROLLO ..................................................................................................... 55 TABLA 12: CUADRO DE RELACIÓN DE INFORMACIÓN ANALIZADA PARA LA GENERACIÓN DE ESCENARIOS ....................... 55 TABLA 14: CUADRO DE ANÁLISIS DE INFORMACIÓN SUMINISTRADA POR ITAC ........................................................ 57 TABLA 15: RESULTADO DE PRUEBAS Y CORRECCIÓN DE ERRORES .......................................................................... 76 TABLA 16:CONTROL AL ALCANCE ................................................................................................................... 82


Página 11


ABSTRACT

The Present final project for graduation contains the whole process in which SIGPLAN solu-

tion has been developed, this is a managemet solution that allows the organizations to generate

different planning scenarios of information technology projects order to help the project man-

agement. Design research project [1]: 1. Identify the problem and establish a motivationed. 2.

Propose the objectives of the project. 3. Design and develop the purposes. 4. To prove by proof

of concept. 5. Evaluate the results 6. Communicate the results of the whole project. The project

was accompanied by the thesis director and ITAC - IT Applications Consulting

RESUMEN

El presente trabajo de grado contiene todo el proceso en el cual se desarrolló la solución

SIGPLAN, este proyecto es una solución gerencial que le permite a las organizaciones generar

escenarios de proyectos informáticos para la planeación de la gestión de proyectos. Este pro-

yecto se dividió en seis fases, según lo plantea la metodología Design Science Research [1] las

cuales son: 1. Identificar el problema y establecer una motivación. 2. Proponer los objetivos

del proyecto. 3. Diseñar y desarrollar los objetivos planteados. 4. Demostrar mediante una

prueba de concepto. 5. Evaluar los resultados 6. Comunicar los resultados de todo el proyecto.

El proyecto estuvo acompañado por la directora de tesis y la empresa ITAC – IT Applications

Consulting.


Página 12

RESUMEN EJECUTIVO

El presente documento contiene el proceso que se desarrolló para lograr los objetivos plantea-

dos en la solución SIGPLAN, esta solución es un generador de escenarios de planeación de

proyectos para la gestión de un proyecto informático.

Inicialmente se realizó un análisis de las diferentes problemáticas a las que se enfrenta la in-

dustria del desarrollo de software y se identificó que existen problemáticas a la hora de generar

planeaciones precisas, generalmente cuando se habla de problemas en los proyectos informáti-

cos, se habla de que la planificación no fue precisa [2], esta falla en la planeación comienza a

generar sobre carga en el equipo de trabajo, reflejadas en jornadas extensas. El exceso de pre-

sión en la planificación de los recursos, está presente en el 75 % de los proyectos grandes y en

el 100 % de los proyectos informáticos muy grandes. Respecto al equipo de trabajo práctica-

mente el 60 % de los colaboradores en este tipo de proyectos manifiestan que su nivel de estrés

aumenta progresivamente a medida que el proyecto avanza y no alcanzan los objetivos plan-

teados [3].

Dentro de la gran variedad de proyectos informáticos están proyectos de desarrollo software

que son sobre los cuales se centra esta propuesta, el problema al que se enfrenta los proyectos

de desarrollo software desde el año 1968 donde se introdujo el término “Crisis del software”

por F. L. Bauer [4] muestra que este tipo de proyectos por su propia naturaleza no son fáciles

de resolver. Según el reporte del CAOS de The Standish group [5] en su estudio anual 2015

realizado a 50 mil empresas alrededor del mundo, da como resultado que solo el 29 % de los

proyectos se cumplieron dentro del presupuesto y tiempo con todas las características y fun-

ciones, por otro lado el 52% de los proyectos se completaron y son operacionales, pero más

allá del presupuesto, más allá del tiempo estimado y con pocas de las características y funciones

que fueron especificadas inicialmente y el 19% de los proyectos fueron cancelados antes de

completarse.

Al identificar éstas y otras problemáticas se exploraron alternativas de solución que le aportaran

a mejorar las situaciones complejas a las que se enfrentan los gerentes de proyectos al hacer

planes de proyectos. Para dar un aporte a estas problemáticas se planteó la construcción un

generador de escenarios de planeación para la gestión de un proyecto informático (SIGPLAN).

Para cumplir con este propósito se utilizó la metodología Design Science Research [1]. Esta

metodología propone tres ciclos: Ciclo de Diseño, Ciclo de Relevancia, Ciclo de Rigor.

Por el lado de la relevancia se contó con la participación de ITAC - IT Applications Consulting

[6] la cual es una empresa de base tecnológica 100% colombiana fundada en el año 2004. Por

el lado del rigor se exploraron diferentes estándares, autores, artículos y estudios que aportan

ideas desde diferentes perspectivas al tema de planeación de proyectos.

El proyecto estuvo dividido en seis fases que son las que propone la metodología de investiga-

ción científica basada en el diseño.

Fase 1: identificar el problema y establecer una motivación, dentro de esta fase se realizó más

ampliamente el análisis del contexto del problema y se estableció un plan marco de trabajo con


Página 13


la empresa participante ITAC. Dentro de la motivación del proyecto se establecieron compo-

nentes que debía contener SIGPLAN, estos componentes son, métodos de estimación, infor-

mación histórica de las organizaciones, clasificación de proyectos, descomposición de proyec-

tos, una metodología de implantación que permita que todo el proyecto fluya con eficiencia y

eficacia junto con un plan de proyecto.

Fase 2: en esta fase se definieron los objetivos del proyecto, el alcance del proyecto junto la

estructura de descomposición de trabajo EDT que tendría durante los dos semestres de dura-

ción, se definió el cronograma y los entregables a través del tiempo que tendría el proyecto. La

descomposición de trabajo estuvo dividida en grupos de inicio, planificación, ejecución, moni-

toreo, control y cierre del proyecto.

Fase 3: esta fase incluía las actividades de diseño y de desarrollo de la solución SIGPLAN,

dentro de esta fase de definió todos los elementos que componen la solución final como son

método de estimación, plan de proyecto, metodología de implementación, descomposición de

proyectos, clasificación de proyectos, información histórica, arquitectura del sistema, diagra-

mas, definición de requerimientos, como parte del diseño se realizó la arquitectura de la solu-

ción SIGPLAN, se creó la vista funcional, vista de alto nivel, vista detallada, despliegue físico,

diseño de las capas del sistema, modelo de dominio, modelo entidad relación, definición de

casos de uso que se dividieron en los módulos de administración y configuración, módulo de

proyectos, proceso de generación de escenarios.

En la fase de desarrollo se muestra los componentes software desarrollados y cómo estos in-

teractúan para generar los escenarios para la planeación de la gestión de un proyecto informá-

tico. La solución SIGPLAN cuenta con los siguientes componentes que interactúan estrecha-

mente entre sí para lograr el objetivo del proyecto.

Módulo de administración

Módulo de costos

Módulo de proyectos

Motor generador de escenarios

Calculador de factores

Módulo de escenarios

Base de datos

se realizaron todas las posibles actividades de relevancia con la empresa participante ITAC.

Mas delante se realizó un proceso de retroalimentación por medio de prototipos iterativos y

evolutivos, esto permitió el desarrollo de modelos que se fueron mejorados a través del tiempo,

hasta llegar a un nivel en donde se cumplen los objetivos propuestos.

Fase 4: en esta fase se realizaron los procesos de demostración de los resultados del proyecto,

para esto se definieron los elementos necesarios para realizar las pruebas de concepto de la

solución SIGPLAN, se definieron los escenarios de pruebas. Como parte de los resultados se

obtuvieron los siguientes comentarios de los gerentes que participaron en esta fase.


Página 14

Fase 5: en esta fase se definió la rúbrica de evaluación de la solución, se recolectaron los resul-

tados y se hizo el respectivo análisis de las pruebas, como resultado de las sesiones de pruebas

se obtuvieron buenos comentarios de cómo este tipo de soluciones son necesarias en las orga-

nizaciones para ser una herramienta de apoyo a la toma de decisiones.

Fase 6: esta fase contiene la generación de todas las memorias de este trabajo, documento téc-

nico de la herramienta, conclusiones y trabajos futuros.

Como parte de las conclusiones principales que se obtuvieron se encuentra que este

trabajo se desarrolló con el fin brindar un aporte a las diferentes problemáticas que se enfrentan

las empresas que se dedican al desarrollo de proyectos informáticos, el principal beneficio de

este proyecto se centra en la fase inicial de los proyectos, donde los gerentes deben generan

proyecciones, analizar la viabilidad de iniciativas e incluso presentar propuestas de proyectos

en marcos globales de trabajo, la solución SIGPLAN brinda una visión global de los proyectos

haciendo combinaciones de recursos humanos, financieros, tiempo y alcance en diferentes es-

cenarios donde el proyecto informático lograría los objetivos planteados, con estos elementos

los gerentes de proyectos pueden tomar decisiones respecto a las necesidades de la organiza-

ción.

Además, la solución SIGPLAN es muy útil no sólo en la fase previa a la planeación, sino que

también puede apoyar la toma de decisiones una vez el proyecto ha iniciado, cuando a medida

que se tienen más detalles las condiciones pueden cambiar, es allí cuando la herramienta puede

apoyar al gerente de proyecto en la toma de decisiones para solventar las nuevas situaciones y

conseguir los objetivos del proyecto.

Con la generación de escenarios la herramienta puede ayudar a determinar la viabilidad inicial

del proyecto. La información suministrada por los escenarios puede ser la entrada para presen-

tar una propuesta formal al cliente, junto con los tiempos, costos y alcance del proyecto.


Página 15


1 INTRODUCCIÓN

Actualmente las organizaciones de base tecnológica participan en convocatorias de licitaciones

de proyectos, reciben iniciativas de sus clientes para que se hagan las propuestas de proyectos,

o en su defecto la misma empresa puede ser un generador de necesidades que pueden surgir

desde diferentes dependencias, todas estas necesidades de negocio por lo general tienen como

solución final la puesta en marcha de sistemas de información que ayuden a mejorar las opera-

ciones o que soporten las necesidades empresariales para ofrecer servicios o productos al pú-

blico en general. Por lo general la incertidumbre es muy alta cuando se desea iniciar con un

proyecto, entonces es aquí donde entran a combinar diferentes factores humanos y técnicos que

les permiten a las organizaciones realizar planes de gestión más efectivos [7], entre de los mé-

todos más usados en las organizaciones se encuentra los métodos de estimación , herramientas

de cálculo de costos, el juicio de expertos, en donde se reúnen un grupo de personas con alto

grado de experiencia y a criterio de cada uno generan planes para abordar los proyectos, prin-

cipalmente estos planes tienen consigo costos, responsables, cronograma de entrega, alcance

del proyecto, pero existen diversas problemáticas en las planeaciones iniciales que no permiten

que los proyectos terminen exitosamente, a continuación se nombran algunas de las problemá-

ticas encontradas:

La falta de estimaciones realistas basadas en datos objetivos [8] [9]

Cambio de requisitos sin ajustar el plan de gestión [10].

Cronogramas poco realistas impuestos a los proyectos por fuerzas externas [11]

Pobre inspección del plan de gestión de proyecto [11]

Plan de gestión de proyecto no realista o incompleto [10]

Falta de recursos asignados desde el plan de gestión [8]

Falta de un plan de gestión del riesgo [12].

Este proyecto pretende aportar mejoras a algunas de las problemáticas descritas, se propone

desarrollar una solución que cuente con características concretas que permitan generar escena-

rios de planeación para la gestión de proyectos informáticos, esta solución debe ser capaz de

combinar los recursos disponibles como tiempo, recurso humano, alcance y costo, ya que estos

elementos están asociados a la triple restricción en la gestión de proyectos.

La triple restricción es un concepto de gestión de proyectos, que se origina en la base para la

realización de un proyecto y proporciona orientación para enmarcar el plan de gestión [13]. La

triple restricción constituye uno de los pilares principales del plan de proyecto y es de suma

importancia para la gerencia del proyecto. Con esta solución se pretende dar a los gerentes de

proyectos una visión global del proyecto antes de que este inicie, con esto se busca que sea una

herramienta de apoyo a la toma de decisiones donde la información suministrada sea de utilidad

y refleje escenarios en los cuales el proyecto planteado pueda cumplir con los objetivos pro-

puestos.

La siguiente propuesta se estructura de la siguiente manera, inicialmente se hace una descrip-

ción general de la problemática y oportunidad de mejora, después se realiza la descripción del

proyecto, un estado del arte, trabajos relacionados, este proyecto de desarrolló bajo la metodo-

logía de investigación científica basada en el diseño [1] y sus 6 fases son: identificación del


Página 16

problema y establecer una motivación, proponer los objetivos, diseñar y desarrollar, demostrar,

evaluar y comunicar.


Página 17


2 DESCRIPCIÓN GENERAL

Esta sección está dedicada a explicar a nivel general la problemática del proyecto y como esta

se convirtió en una oportunidad de proyecto de grado dentro de un contexto empresarial de

compañías que se dedican al desarrollo de proyectos informáticos.

2.1 Problemática

Un plan de gestión es un instrumento elaborado a partir de un diagnóstico, que da una visión

de conjunto para el futuro desarrollo de un proyecto. En este sentido un plan de gestión se

convierte en una guía para la acción que señala metas viables y deseables, líneas de adminis-

tración, así como los medios y recursos humanos, técnicos y financieros para alcanzar los ob-

jetivos en periodos finitos de tiempo [14] [15]. Por otro lado, los proyectos son un esfuerzo

temporal finito que se lleva a cabo para crear un producto, servicio o resultado único [16]. En

ese orden de ideas un proyecto informático se materializa o ejecuta mediante un plan o diversos

planes de gestión, orientados en obtener resultados deseables sobre un sistema de información.

Se podría comparar la planeación de la gestión de proyectos informáticos como un barco que

está zarpando. Si no se han planificado bien previamente los recursos, será muy difícil que

pueda llegar a su destino [17]. Generalmente cuando se habla de problemas en los proyectos

informáticos, se habla de que la planificación no fue precisa [2], esta falla en la planeación

comienza a generar sobre carga en el equipo de trabajo, reflejadas en jornadas extensas. El

exceso de presión en la planificación de los recursos, está presente en el 75 % de los proyectos

grandes y en el 100 % de los proyectos informáticos muy grandes. Respecto al equipo de tra-

bajo prácticamente el 60 % de los colaboradores en este tipo de proyectos manifiestan que su

nivel de estrés aumenta progresivamente a medida que el proyecto avanza y no alcanzan los

objetivos planteados [3].

Dentro de la gran variedad de proyectos informáticos están proyectos de desarrollo software

que son sobre los cuales se centra esta propuesta, el problema al que se enfrenta los proyectos

de desarrollo software desde el año 1968 donde se introdujo el término “Crisis del software”

por F. L. Bauer [4] muestra que este tipo de proyectos por su propia naturaleza no son fáciles

de resolver. Según el reporte del CAOS de The Standish group [5] en su estudio anual 2015

realizado a 50 mil empresas alrededor del mundo, da como resultado que solo el 29 % de los

proyectos se cumplieron dentro del presupuesto y tiempo con todas las características y fun-

ciones, por otro lado el 52% de los proyectos se completaron y son operacionales, pero más

allá del presupuesto, más allá del tiempo estimado y con pocas de las características y funciones

que fueron especificadas inicialmente y el 19% de los proyectos fueron cancelados antes de

completarse.

Para el caso de Colombia cabe resaltar que la industria de las tecnologías de la información ha

tenido un crecimiento de cinco veces su tamaño y las exportaciones han crecido 29% entre

2003 y 2014 [18] y sigue en aumento, pero es bueno preguntarse si las organizaciones están

preparadas para esta demanda, aquí se muestran algunas limitaciones representadas en proble-

mas como: calidad del producto, tiempos de entrega, recursos especializados, inversión en la

innovación [19]. En la actualidad en Colombia existe un porcentaje de proyectos en tecnologías


Página 18

de la información y comunicación que tiene un “fracaso financiero” [20], en la industria a

pesar de que muchas empresas conocen de los modelos de planeación para la gestión, estos no

son utilizados [21].

Los estándares de gestión de proyectos están cobrando cada vez más fuerza en las organizacio-

nes mundiales, ya que los principales beneficios es la armonización entre la terminología de

gestión, los procesos y métodos para tener una gestión más precisa en los proyectos. Entre los

principales estándares de gestión de proyectos se encuentran The PMBOK (Project Manage-

ment Body of Knowledge), APM BoK (Association of Project Management Body of

Knowledge), BS 6079 (British Standard Guide to Project Management), IPMA Competence

Baseline (ICB), ISO 10006, P2M (Project & Program Management for Enterprise Innovation)

[22]. En Colombia los proyectos informáticos y en especial el desarrollo de software inició de

forma artesanal [23] pero ha crecido de forma moderada en los últimos años, con niveles de

madurez cada vez mayores en procesos de desarrollo de software, mostrando que para 2008

solo 18 empresas reportaban una madurez CMMI DEV [24] seis de ellas nivel 3, mientras en

india ascendían 323, para el año 2010 hubo un crecimiento importante, ya que para la fecha

existían 40 firmas que contaban con madurez CMMI DEV [24], y esta tendencia por seguir en

desarrollo no ha parado ya que para el año 2015 el SEI (Software Engineering Institute) señala

que Colombia ocupa el primer lugar en américa latina en calificación de número de empresas

valoradas en CMMI DEV [24], por encima de países como Brasil, Chile, Perú, Ecuador [25].

Sin embargo, estos esfuerzos no han sido suficientes para tener una planeación precisa de los

proyectos. Cabe aclarar que son varias las razones por las cuales un porcentaje de proyectos

informáticos no han sido exitosos [10], pero los problemas (entre otros) en los que esta pro-

puesta de solución se centra están relacionados con el plan de gestión del proyecto y se nombran

a continuación:

La falta de estimaciones realistas basadas en datos objetivos [8] [9]

Cambio de requisitos sin ajustar el plan de gestión [10].

Cronogramas poco realistas impuestos a los proyectos por fuerzas externas [11]

Pobre inspección del plan de gestión de proyecto [11]

Plan de gestión de proyecto no realista o incompleto [10]

Falta de recursos asignados desde el plan de gestión [8]

Falta de un plan de gestión del riesgo [12].

2.2 Oportunidad

Este proyecto pretende aportar o apoyar la parte inicial de todo proyecto informático, que com-

prende la construcción de un plan de gestión inicial. Dadas las anteriores problemáticas se pro-

pone desarrollar una solución que cuente con características concretas que permitan generar

escenarios de planeación para la gestión de proyectos informáticos, esta solución debe ser ca-

paz de combinar los recursos disponibles como tiempo, recurso humano, alcance y costo, estos

elementos están asociados a la triple restricción en la gestión de proyectos.

La triple restricción es un concepto de gestión de proyectos, que se origina en la base para la

realización de un proyecto y proporciona orientación para enmarcar el plan de gestión [13]. La


Página 19


triple restricción constituye uno de los pilares principales del plan de proyecto y es de suma

importancia para la gerencia del proyecto.

Aunque el tema triple restricción tiene varias interpretaciones, la literatura muestra un acuerdo

general en que el alcance del proyecto, el tiempo y el costo comprenden las tres variables de

restricción triples clave [26], aunque el Project Management Institute en su guía PMBOK [16]

propone 5 restricciones que son el alcance, calidad, cronograma, presupuesto, recursos y ries-

gos, en este proyecto se dejan por fuera los temas de calidad y riesgos que pueden ser tratados

en una siguiente fase, a continuación, se hace una breve descripción de las restricciones.

Tiempo del proyecto se refiere a la programación y la duración del proyecto, el costo aborda el

presupuesto y los recursos humanos del proyecto, y el alcance aborda los requisitos y el trabajo

del proyecto. Un proyecto con limitaciones de tiempo está limitado a un cronograma general-

mente impuesto por los clientes, mientras que un proyecto de costo limitado es el que tiene un

presupuesto asignado y no puede variar, los proyectos llamados de costo fijo. Restricción en el

alcance de proyectos están limitadas por los criterios de funcionamiento de los entregables, por

otro lado, la calidad del proyecto constituye un elemento integrante de la gestión de proyectos

y es apoyado por la triple restricción.

La solución debe ser capaz de mostrar varios escenarios donde se combinación de recursos

humanos, tiempo, alcance y costo de un proyecto que puedan ser usados como elementos ge-

nerales en un plan de proyecto informático, cabe resaltar, que esta solución apoyaría la toma

de decisiones en una etapa temprana en la que aún no se ha hecho un análisis exhaustivo de los

recursos que va a necesitar el proyecto, la propuesta se explica de forma gráfica a continuación.

Figura 1:Grafica de planteamiento de un proyecto informático

Fuente: Elaboración propia

Nivel 1: Proyecto Informático, en este nivel se tiene conocimiento de la iniciativa general del

proyecto que se quiere iniciar y se cuenta con alternativas de solución a un requerimiento de

negocio, en este nivel se ha identificado la necesidad de plantear una solución haciendo uso de

herramientas tecnológicas, es posible que se desee plantear una propuesta a un cliente, o se

desea analizar la viabilidad del proyecto frente a unos recursos disponibles.

Nivel 2: En este nivel al Proyecto informático se le identifica las fases que debe tener, la com-

plejidad de cada fase y su tamaño, calidad, riesgos, adquisiciones, interesados, alcance y puede

o no tener recursos asignados como presupuesto, recursos humanos, tiempo [15].

Nivel 1: Proyecto Informático o propuesta de solución

Nivel 2: Fases, Tamaño, complejidad, Presupuesto, Personas, Tiempo, alcance

Nivel 3: Requisitos, elementos de diseño, análisis detallado, arquitectura, modelos


Página 20

Nivel 3: en este nivel se pueden conocer elementos más detallados del proyecto informático

como requisitos, elementos de diseño, análisis detallado, arquitectura, entre otros.

La solución propuesta en este proyecto debe permitir generar escenarios de planeación donde

se realice la combinación de recursos humanos, tiempo, alcance y costo en los cuales en con-

diciones normales de una compañía pueda desarrollar el proyecto. Estos escenarios están vin-

culados al conocimiento que se pueda tener del proyecto desde un nivel 1 y nivel 2, en donde

un gerente de proyectos pueda tener elementos de toma de decisión para analizar si una inicia-

tiva es viable frente a un contexto actual del proyecto, con la disponibilidad de los recursos

asignados.


Página 21


3 DESCRIPCIÓN DEL PROYECTO

A continuación, se presentan los objetivos generales y específicos del proyecto, así

como la metodología de investigación que se aplicó y sus respectivas fases.

3.1 Objetivo general

Construir una solución que permita generar escenarios de planeación para la gestión de un

proyecto informático (SIGPLAN).

3.2 Objetivos específicos

1. Especificar los componentes de planeación para la gestión de un proyecto informático

2. Diseñar un modelo para generar escenarios de planeación para la gestión de un pro-

yecto informático.

3. Desarrollar el modelo de generación de escenarios de planeación para la gestión de un

proyecto informático

4. Validar la solución desarrollada a través de una prueba de concepto.

3.3 Metodología

La solución del proyecto que se plantea es construir un generador de escenarios de planeación

para la gestión de un proyecto informático (SIGPLAN). Se utilizará la metodología Design

Science Research [1]. Esta metodología propone tres ciclos: Ciclo de Diseño, Ciclo de Rele-

vancia, Ciclo de Rigor.

El ciclo de diseño consiste en el diseño, construcción y evaluación de la solución, En este ciclo

se desarrolla todo el modelo de generación de escenarios de planeación para gestión alimentado

constantemente por la relevancia y rigor de forma iterativa.

El ciclo de relevancia se relaciona con una constante retroalimentación entre el entorno de

aplicación y la solución propuesta:

El proyecto SIGPLAN propuesto tendrá la participación de la empresa ITAC - IT Applications

Consulting [6] la cual es una empresa pequeña [27], 100% colombiana fundada en el año 2004,

dedicada a proveer servicios de desarrollo de software a la medida y desarrollo de productos

propios como software seguro, esta empresa cuenta con una madurez CMMI [24] nivel 3. Se

decidió trabajar con esta empresa porque tiene características propias de empresas en el sector

de la tecnología y ve que esta iniciativa que puede generar valor para el beneficio de sus pro-

cesos y sus clientes.

Esta empresa tendrá una participación con los siguientes roles:

Proveedor de Información (PI): debido al recorrido de que esta empresa tiene, cuenta con

información importante en temas relacionados con estructura, planeación, ejecución y segui-

miento de proyectos, la cual será analizada y tenida en cuenta para el diseño del modelo. Esta


Página 22

información también será un elemento importante para tener una base comparativa con los

resultados que arroje la solución SIGPLAN.

Retroalimentador (RE): las fases de diseño y desarrollo de la aplicación se construirán de

forma iterativa y se presentarán a la empresa ITAC para que esta haga aportes en cada una de

las fases desde su experiencia.

Verificador (VE): al final del diseño y desarrollo, la empresa ITAC debe hacer una prueba de

concepto de la solución SIGPLAN y con una rúbrica de verificación se podrá constatar que tan

cerca del objetivo propuesto se encuentra el trabajo realizado. En este rol de verificador tam-

bién pretende buscar otra organización o un grupo de expertos gerentes de proyectos para que

hagan parte de la prueba y den su concepto del proyecto SIGPLAN.

El ciclo de rigor consiste en una búsqueda constante en las bases del conocimiento que contri-

buya en la solución del proyecto: se pretende implementar en la solución SIGPLAN las mejores

prácticas que ofrece la comunidad y los estándares mundiales en el tema referente a los com-

ponentes involucrados, este ciclo debe garantizar que el proyecto SIGPLAN esté construido

con estándares generales y así otras organizaciones puedan hacer uso de la solución.

Se selecciona esta metodología porque se ajusta al marco de trabajo planteado para ejecutar

este proyecto, En la Figura 3 se ilustran los ciclos expuestos:

Figura 2: Ciclos de la metodología llamada ciencia basada en el diseño

Fuente: Tomada de la presentación Estrategia y método de la investigación científica ba-

sada en el diseño y la cual fue adaptada de [28]

Un proceso de la investigación científica basada en el diseño, propone un método para instan-

ciar la metodología Design Science Research. Las fases propuestas por Peffers [1] son:

Fase 1: Identificar el problema y establecer una motivación

Fase 2: Definir los objetivos

Fase 3: Diseñar y desarrollar

Fase 4: Demostrar

Fase 5: Evaluar


Página 23


Fase 6: Comunicar

3.3.1 Fase 1: Identificar el problema y establecer una motivación

En esta fase se identifica el problema de un contexto, haciendo un análisis específico de estu-

dios que reflejan las problemáticas en la planeación de proyectos informáticos, sobre estas pro-

blemáticas se plantean posibles soluciones a través de la identificación de oportunidades de

mejora.

Las actividades planteadas a continuación serán desarrolladas bajo el ciclo de relevancia con

aportes de la empresa ITAC. El Ciclo de rigor se llevará a cabo investigando en las bases de

conocimiento sobre las mejores y más usadas prácticas de los componentes que integran la

solución SIGPLAN.

Para el desarrollo de esta fase se realizarán las siguientes actividades:

A. Selección de un marco de trabajo para un Plan de Proyecto: en este proyecto se van a

seguir los lineamientos de gestión de proyectos planteados en el PMBOK [16] el cual

nos plantea un conjunto de procesos que se deben seguir para alcanzar un objetivo

determinado, dentro de este proceso de planeación se recogen los elementos que debe

incluir la planeación de todo el proyecto SIGPLAN. Este plan debe definir un conjunto

de tareas coordinadas en el tiempo, así como los recursos necesarios para cumplir los

objetivos [29] [30]. ITAC participará en su rol de RE.

B. Selección de una metodología de desarrollo, debido a que uno de los productos finales

del trabajo de grado es un sistema de información, se hace necesario plantear una me-

todología de desarrollo de software.

3.3.2 Fase 2: Proponer los Objetivos

En esta fase se definen los objetivos de la solución, se crea el plan del proyecto SIGPLAN,

según lineamientos PMI [16], el cual contempla alcance, tiempo, calidad, recursos, riesgos,

comunicaciones e integración, este plan permite visualizar cómo se desarrollará en un plan de

gestión para solución propuesta.


A. Definición de los objetivos.

B. Definición del alcance y tiempo para esta actividad se realiza una estructura de des-

composición del trabajo (WBS) y cronograma del proyecto, en esta tarea se define

como va a ser el desarrollo del proyecto en función del tiempo y cuáles son los entre-

gables que se deben completar a través del tiempo, se contemplan entregables como

(según la WBS):

- Documento de análisis de los componentes

- Documento de Diseño del SIGPLAN, que contenga diagramas de dominio, dia-

grama de componentes, diagrama de despliegue, diagramas de secuencia.


Página 24

- Aplicación software SIGPLAN,

- Documento técnico,

- Actas de reunión

- Documento de prueba de concepto

- Documento de resultado de prueba de concepto

- Memorias de trabajo de grado.

C. Selección de método de estimación de esfuerzos: se deben seleccionar el o los métodos

más recomendados o usados por la comunidad que permiten calcular el valor del es-

fuerzo en un proyecto por medio de algoritmos o fórmulas matemáticas. ITAC partici-

pará en su rol de RE

D. Definir la Información Histórica: se debe analizar qué información de las empresas

relacionadas con ejecución de proyectos informáticos es útil para generar nuevos es-

cenarios de planeación para la gestión de proyectos, ITAC participará en su rol de PI

y RE.

E. Definir la clasificación de proyectos: para este proyecto solo se contempla proyectos

de desarrollo de software e infraestructura, se debe plantear una estructura de clasifi-

cación de proyectos que sirve para evaluar que tan grande es un proyecto según recur-

sos humanos y financieros, tiempo, número de usuarios atendidos, complejidad, tec-

nología involucrada entre otros. ITAC participará en su rol de PI y RE.

F. Definir la descomposición de proyectos: aquí de debe definir una clasificación de los

entregables que al final de los ciclos de vida del proyecto quedan como resultado, entre

estos pueden estar módulos, componentes, funcionalidad, manuales, código fuente,

framework, infraestructura. ITAC participará en su rol de PI y RE.

G. Elección de herramientas para el desarrollo del proyecto, se deben elegir las herramien-

tas y tecnologías sobre las cuales se va a desarrollar la solución final, estas aportan al

ítem de calidad. Para esta actividad se contempla las siguientes tareas:

- Diseño de formatos para hacer el seguimiento del proyecto SIGPLAN

- Elección de herramientas tecnológicas como lenguajes de programación, motor de

base de datos, repositorio de documentos, elección de un lenguaje de modelado.

H. Creación de un plan de gestión de recursos y riesgos: este plan contempla cómo se

administra los recursos y los posibles riesgos que el proyecto puede tener, junto con

los planes de mitigación de riesgos.

I. Definición de la estrategia de interacción y comunicación con la empresa ITAC parti-

cipante en el proyecto, esta interacción se planea realizar dos veces cada mes para que

la empresa participe en su rol de PI, RE y VE del proyecto SIGPLAN. Como resultado

de estas interacciones se pretende obtener.

- información de los procesos de planeación, ejecución y seguimiento de proyectos

- Actas de reunión

- Formatos de retroalimentación y observaciones generales

3.3.3 Fase 3: Diseñar y desarrollar

En la fase de diseño (ciclo diseño) se pretende plantear un modelo de interacción entre los

componentes encontrados en la Fase 1 y cómo estos interactúan entre sí para generar escenarios

de planeación para la gestión de proyectos, para esta fase se propone unos ciclos iterativos para


Página 25


la generación del modelo, este va a ser mejorado en cada iteración hasta llegar al resultado

esperado. Para esta fase se pretende validar el modelo con la empresa participante ITAC en su

rol de RE (ciclo de relevancia) y mediante la implementación algoritmos de cálculo de costos

y alcance (ciclo de rigor).

En la fase de desarrollo se pretende implementar el diseño planteado en un lenguaje programa-

ción orientado a objetos que resulte en una herramienta web que implemente el modelo de

interacción.


A. Definición del modelo de interacción de la estructura de los componentes que rodean

la solución SIGPLAN (ciclo relevancia y rigor):

Método de estimación

Plan de proyecto

Metodología de implementación

Descomposición de proyectos

Clasificación de proyectos

Información histórica

B. Retroalimentar el modelo con la empresa participante ITAC (ciclo relevancia)

C. Desarrollo de una herramienta web que implemente el diseño.

Pruebas y Corrección de errores de la herramienta SIGPLAN, se pretende hacer pruebas fun-

cionales para garantizar el correcto funcionamiento de la herramienta.

3.3.4 Fase 4: Demostrar

En la fase de demostración se pretende verificar SIGPLAN con una prueba de concepto, en

este caso se realizará esta prueba con la empresa participante ITAC y con otros expertos en

Gerencia de Proyectos (ciclo relevancia). El alcance de esta prueba se realizará en dos escena-

rios los cuales se explican en la actividad A. para el desarrollo de esta fase se realizarán las

siguientes actividades:

A. Definir el objetivo de la prueba de concepto, en esta actividad se plantea cual va a ser

el objetivo de la prueba y como se va a evaluar la prueba en los dos escenarios con-

templados:

- Escenario 1: Realizar una prueba con datos históricos de proyectos que ya fueron

ejecutados en la empresa ITAC, con estos datos se pretende comparar la planeación

para la gestión generada con la solución SIGPLAN frente a los datos reales de la

planeación para gestión de los proyectos que ya fueron ejecutados. ITAC participa

en su rol de PI y VE

- Escenario 2: Realizar una segunda prueba mediante la generación de un proyecto

ficticio, en esta prueba se creará una planeación para la gestión en la solución

SIGPLAN y sus resultados se evaluarán según juicios de expertos.


Página 26

3.3.5 Fase 5: Evaluar

A. Definición de la rúbrica de evaluación: en este punto se pretende diseñar un artefacto

que permita capturar la evaluación cuantitativa y cualitativa de la solución SIGPLAN

desde diferentes aspectos.

B. Definición de escenarios de prueba: en esta actividad se debe generar un documento

que contenga el flujo de los escenarios que los expertos van probar.

C. Ejecución de la prueba: en esta actividad los expertos hacen uso de la solución y regis-

tran su evaluación en la rúbrica. ITAC participa en su rol de VE

Recolección de resultados: en esta actividad se recolectan los resultados obtenidos de la prueba

para su análisis. ITAC participa en su rol de VE.

3.3.6 Fase 6: Comunicar

En la fase comunicar se tiene como fin entregar un compendio de todos los artefactos producto

de la solución, entre ellos están memorias del trabajo de grado (ciclo diseño, relevancia y rigor),

documento técnico, herramienta software, instalador de software, análisis de resultados de

pruebas de concepto, conclusiones.


A. Consolidar las memorias del trabajo de grado.

B. Redacción del manual técnico, especificación de instalación de software.

C. Entrega de la solución SIGPLAN a la empresa participante del proyecto.

D. Conclusiones

E. Trabajos futuros

F. Anexos

G. Bibliografía

Entrega de los resultados de los análisis a los participantes.


Página 27


4 ESTADO DEL ARTE

El proceso de desarrollo de proyectos informáticos ha sido fuente de investigación y durante

muchos años se ha querido hacer de este un proceso estandarizado, eficiente y preciso en cada

una de sus fases de planificación, inicio, ejecución e implantación [31], pero debido a la natu-

raleza compleja del proceso de desarrollo han sido muchos los problemas que las empresas de

tecnología y las de base no tecnológica han tenido que cargar por décadas [5]. Una de las fases

en las cuales se desea realizar con una mayor certeza es la planeación del proyecto, siendo esta

fase una de las principales en todo proyecto ya que aquí se distribuyen los recursos necesarios

para lograr los objetivos en unos intervalos de tiempo definidos. Los proyectos de desarrollo

de software se caracterizan por factores difíciles de cuantificar como por ejemplo el tamaño y

la complejidad y en segundo lugar la calidad [32], ya que estas características no son tangibles

en un producto o servicio se hace muy difícil su medición en una escala estandarizada, incluso

estos pueden variar de un entorno a otro.

Generalmente la planeación de proyectos se descompone en una serie de pasos como los si-

guientes [16]:

Cronograma

Listado de actividades

Red de dependencias

Asignación de recursos requeridos

Estimación de duración de las actividades

Estructura de desglose

para realizar la planeación de proyectos existen dos frentes importantes en la forma en la que

se aborda la planeación: uno, la utilización de métodos de estimación de costo, alcance, es-

fuerzo y tiempo que permite tener una idea global del tamaño del proyecto y por otro lado toda

la implementación de lineamientos o estrategias de planes de gestión que permiten de una

forma efectiva y rigurosa hacer la estructuración del proyecto, a continuación se revisan algu-

nos trabajos relacionados que le aportan a la planeación.

Ya se han realizado esfuerzos en involucrar el razonamiento semicuantitativo como paradigma

para el modelado de procesos de software [33]. Seguido a este trabajo se propone una mejora

al enfoque para la planificación de proyectos de software la cual permita adaptarse a la evolu-

ción de la definición de éxito del proyecto, e introducir el razonamiento semicuantitativo como

la técnica central para lograr los objetivos del proyecto [34]. Otro método muy aplicado en las

organizaciones es el de puntos de función para tener estimaciones más exactas en un temprano

ciclo de vida de desarrollo de software, este método de puntos de función se ha combinado con

modelos de regresión lineal, redes neuronales artificiales [35] [36]. También se ha utilizado

utilizando el método de puntos de caso de uso, para optimizar el cálculo del esfuerzo utilizando

conjuntamente técnicas de machine learning de para obtener una mayor precisión en la predic-

ción [37]. Aun se siguen desarrollando propuestas para mejorar estos modelos aplicando mo-

delos de priorización de casos de uso [38]. Entre otros métodos propuestos, los modelos de

redes radiales de función básica neural (RBFN) han presentado resultados prometedores en la


Página 28

estimación de esfuerzo de software. Este método va de la mano de algoritmos de clustering

como el C-means duros y difusos [39].

En los anteriores estudios se puede visualizar como la estimación del esfuerzo de software es

muy decisiva y siempre hay una necesidad de mejorar su exactitud como sea posible, para

lograr este objetivo se han desarrollado varias técnicas de estimación de las cuales es difícil

determinar qué modelo da una estimación más precisa o aproximada, lo que sí es importante

es que estas técnicas se deben involucrar con planes de gestión que permitan estructurar una

visión global macro de los proyectos informáticos antes de que estos inicien su fase de ejecu-

ción.

Junto con las estimaciones se trabajan de la mano los marcos de gestión los cuales indican los

lineamientos claros que se deben seguir con el fin de tener un impacto positivo en el éxito de

un proyecto, haciendo uso de la aplicación de conocimientos, procesos, habilidades, herramien-

tas y técnicas [16]. La guía de PMBOK [16] propone cinco grupos principales de proceso que

son

Inicio

Planificación

Ejecución

Monitoreo y control

Cierre

Para ejecutar la gestión de proyectos se deben tener en cuenta las restricciones como alcance,

calidad, cronograma, presupuesto, recursos y riesgos, por lo general en las empresas que no

tienen una alta madurez en sus procesos, esta planificación en muchos caso se realiza por juicio

de gerente o un experto en el área, lo cual al inicio crea un grado de incertidumbre mayor, por

otro lado, las empresas con alta madurez como por ejemplo CMMI DEV para su nivel 4 se

desarrollan procesos de gestión cuantitativa para medir la calidad y el rendimiento de los pro-

cesos, y para el nivel 5 se desarrollan actividades de mejora continua de procesos basados en

la interpretación cuantitativa de los objetivos de negocio y necesidades de rendimiento [24].

Para apuntalar con mayor efectividad los procesos de alta madurez se hace uso de estándares

como las normas ISO / IEC 25000, conocida como SQuaRE (System and Software Quality

Requirements and Evaluation), es una familia de normas que tiene por objetivo la creación de

un marco de trabajo común para evaluar la calidad del producto software. La familia ISO / IEC

25000 es el resultado del avance de otras normas anteriores como ISO/IEC 9126, que describe

las características de un modelo de calidad del producto software, e ISO/IEC 14598, que abor-

daba el proceso de evaluación de productos software. Esta familia de normas ISO/IEC 25000

se encuentra compuesta por cinco divisiones [40].

ISO/IEC 2500n – División de Gestión de Calidad

ISO/IEC 2501n – División de Modelo de Calidad

ISO/IEC 2502n – División de Medición de Calidad

ISO/IEC 2503n – División de Requisitos de Calidad

ISO/IEC 2504n – División de Evaluación de Calidad


Página 29


Como vemos son muchos los elementos que las organizaciones pueden usar e implementar

para hacer sus planeaciones más precisas.

A continuación, se aborda una visión general de cómo está compuesta el sector software y

tecnologías de la información en Colombia.

de la Industria del Software y Servicios Asociados con TI de Colombia realizado por MinTIC,

que registró que en el 2014 había 4016 empresas activas de las cuales el 80% se encuentran en

la Región Centro, el 4% en la Región Norte, 6% en la Región Occidente, 4% en la Región

Oriente, y el 6% distribuidas en el resto del país [41]. A continuación, se visualiza la distribu-

ción de empresas en diferentes sectores dentro del territorio colombiano.

Figura 3: Sector software y tecnologías de la información Colombia

Fuente: adaptado de [41]

851

772

477

330

300

143

143

116

115

90

27

6

0 100 200 300 400 500 600 700 800 900

Manejo de centros de datos (data center)

Desarrollo / fábrica de software

Mesas de ayuda (Otras)

Testing de software

Infraestructura como servicio

Consultoría e implementación

Mantenimiento o soporte de aplicaciones

Software como servicio

Otro

Plataformas tecnológicas como servicio

Cloud computing

Gerencia

Sector Software y tecnologías de la información

Número de Empresas


Página 30

Las ventas totales del sector Software y tecnologías de la información en el 2014, de acuerdo

con los códigos, 5820, 6201, 6202, 6209, 6311, 6312 y 6399; fueron $6.241.658.881.000, el

64% de las ventas se concentran en las actividades: 31,9% en la 6201, Actividades de desarrollo

de sistemas informáticos (planificación, análisis, diseño, programación, pruebas) y 32,7% en

la 6202, Actividades de consultoría informática y actividades de administración de instalacio-

nes informáticas.

El tercer CIU más representativo de las ventas es el 6311, Procesamiento de datos, alojamiento

(hosting) y actividades relacionadas, con el 19,5% de las ventas.

Le sigue con el 9% el código CIU 6209, Otras actividades de tecnologías de información y

actividades de servicios informáticos.

Otras actividades relacionadas con tecnologías de la información y las actividades relacionadas

con informática no clasificadas en otras partes, tales como: La recuperación de la información

de los ordenadores en casos de desastre informático, los servicios de instalación y configura-

ción de los computadores personales y los servicios de instalación de software o programas

informáticos.

Tabla 1: Codificación de las actividades

Código de activi-

dad económica

Descripción Ventas Nacionales Por-

centaje

5820 Edición de programas de informática (soft-

ware). La edición de programas informáticos

comerciales: Sistemas operativos, aplicacio-

nes comerciales y otras aplicaciones y

juegos informáticos para todas las platafor-

mas.

63,263,529,000 1 %

6201 Actividades de desarrollo de sistemas infor-

máticos (planificación, análisis, diseño,

programación, pruebas)

1,988,512,423,000 31.9 %

6202 Actividades de consultoría informática y ac-

tividades de administración de instalaciones

informáticas

2,040,882,379,000 32.7 %

6209 Otras actividades de tecnologías de informa-

ción y actividades de servicios informáticos.

Otras actividades relacionadas con tecnolo-

gías de la información y las actividades

relacionadas con informática no clasificadas

en otras partes, tales como: La

recuperación de la información de los orde-

nadores en casos de desastre informático,

los servicios de instalación (configuración)

de los computadores personales y los

servicios de instalación de software o progra-

mas informáticos

575,567,303,000 9.2 %

6311 Procesamiento de datos, alojamiento (hos-

ting) y actividades relacionadas

1,217,188,495,000.00 19.5 %

6312 Portales web 71,525,907,000.00 1.1 %


Página 31


6399 Otras actividades de servicio de información

n.c.p. Otras actividades de servicio de

información no clasificada en otra parte, ta-

les como: servicios de información

telefónica y servicios de búsqueda de infor-

mación a cambio de una retribución o por

contrata.

284,718,145,000.00 4.6%

Fuente: adaptado de [41]

A nivel general se puede deducir que Colombia es un país donde el sector de las tecnologías

tiene un crecimiento importante frente a sus vecinos y que esto implica una mayor responsabi-

lidad frente a la calidad de los productos que se están ofreciendo. Por ende es necesario imple-

mentar estrategias que permitan a las organizaciones tener modelos más acertados de planea-

ción y ejecución de proyectos.


Página 32

5 TRABAJOS RELACIONADOS

1. Structured planning – Project views [32], Structured planning – projects views [42], project

planning using an interactive, structured modeling environment [43]: estos proyectos traba-

jan en la descomposición de los ciclos de vida del proyecto, solo cuenta con algunos ele-

mentos de planeación de proyectos, pero no genera escenarios donde se combinen los re-

cursos.

2. Planning Software Project Success with Semi-Quantitative Reasoning [44]: ofrece un en-

foque de planeación de proyectos con razonamiento semicuantitativo, el cual plantea una

serie de procesos para lograr el éxito del proyecto, tiene elementos de planeación de pro-

yectos, pero no genera escenarios donde se combinen los recursos.

3. COCOMO Constructive Cost Model [45] [46]: es utilizado para estimar costos de proyectos

utilizando tres submodelos: básico, intermedio, detallado, solo contempla la estimación de

costos, pero deja por fuera la gestión de la planeación y la información histórica de la orga-

nización.

4. CESIM [47]: esta es una herramienta de entrenamiento de equipos de trabajo con un enfo-

que de gestión de proyecto, trabajo en equipo, liderazgo, comunicación efectiva, sirve para

visualizar los elementos de la planeación sin generar escenarios.

5. DoProject [48], Microsoft Project: la primera es la versión open source de Microsoft Pro-

ject, estas herramientas ayudan a realizar toda la gestión del proyecto durante su ejecución.

No generan escenarios de planeación debido a que toda la información debe ser suminis-

trada por el usuario.

A continuación, se presenta un cuadro comparativo entre los trabajos relacionados y la solución

propuesta.

X: abarca los elementos planteados en la solución propuesta.

AE: contiene algunos elementos relacionados con la solución propuesta.

Tabla 2: Características de evaluación

Nro. Ítem a evaluar

A Método de estimación de proyectos

B Usabilidad y portabilidad

C Plan de Proyecto

D Metodologías de implementación

E Descomposición de proyectos

F Clasificación de proyectos

G Información Histórica cómo aprendizaje

H Generación de escenarios de planeación para la gestión temprana


A continuación, se hace el cruce entre los proyectos encontrados y las características que se

espera que tenga la solución final SIGPLAN.


Página 33


Tabla 3: Cruce de las características de evaluación y los proyectos encontrados

trabajos a b c d e f g h

solución propuesta X X X X X X X X

1 AE AE AE

2 AE AE AE

3 AE AE AE

4 AE AE

5 AE AE AE AE

Fuente: elaboración propia

En el cuadro anterior se puede observar propuestas que aportan elementos a solucionar proble-

mas con la planeación de la gestión de problemas informáticos. Lo que se pretende en este

proyecto es tomar algunos elementos e integrarlos a la solución SIGPLAN con el fin de generar

un modelo más completo que aporte a cada uno de los objetivos propuestos en este trabajo de

grado.


Página 34

6 FASE 1 - IDENTIFICAR EL PROBLEMA Y ESTABLECER UNA

MOTIVACIÓN

Dentro de esta fase se desarrolló la propuesta inicial del proyecto la cual fue probada en el

primer semestre del año 2016, esta propuesta contiene los objetivos planteados, la problemá-

tica, los entregables e impactos ver Anexo 1.

6.1 Componentes del proyecto SIGPLAN

Para llegar al objetivo principal se pretende desarrollar una solución (SIGPLAN) que cuente

con un conjunto de elementos que aporten características para desarrollar mejor la tarea de

planeación de la gestión proyectos informáticos, para lograr este objetivo se plantea la integra-

ción de los siguientes componentes:

Figura 4: Componentes de la solución planteada

Fuente: Elaboración Propia

La identificación de los componentes planteados en la Figura 3 se obtuvieron gracias a un

análisis detallado de planteamientos y estudios independientes que aportan la identificación de

factores críticos al problema de planeación para la gestión de proyectos informáticos en [48]

[49] [43] [16] [46] [50] [21] [51] [44], estos elementos se consideran factores necesarios para

cumplir con el objetivo principal de este proyecto SIGPLAN. Los componentes que rodean la

solución deben interactuar entre sí para generar escenarios de planeación para la gestión de

proyectos, la relación entre estos factores es tal que, si alguno de ellos cambia, es probable que

al menos otro de ellos se vea afectado [16]. Por ejemplo, si el cronograma es acortado, a me-

nudo el presupuesto necesita ser incrementado a fin de añadir recursos humanos adicionales

para completar la misma cantidad de trabajo en menos tiempo. Si no fuera posible aumentar el

SIGPLAN

Método de Estimación

Información Histórica

Clasificación de proyectos

Descompocisión de

proyectos

Metodología de

implementación

Plan de Proyecto


Página 35


presupuesto, se podría reducir el alcance o los objetivos de calidad para entregar el resultado

final del proyecto en menos tiempo y por el mismo presupuesto. Los interesados en el proyecto

pueden tener opiniones diferentes sobre cuáles son las mejores metodologías de implementa-

ción, esto puede afectar directamente las fases de ciclo de vida del proyecto. La modificación

de los requisitos o de los objetivos del proyecto también puede generar riesgos adicionales.

SIGPLAN necesita ser capaz de evaluar la situación de los recursos disponibles, equilibrar las

demandas y mantener un plan de gestión con el fin de plantear escenarios en los que se lograría

un proyecto exitoso.

6.1.1 Plan marco de trabajo

El objetivo de este documento es identificar los lineamientos que propone PMI en relación a la

gestión de proyectos, para luego ver como estos se pueden implementar en el proyecto

SIGPLAN. Estos lineamientos son obtenidos del documento GUÍA DE LOS

FUNDAMENTOS PARA LA DIRECCIÓN DE PROYECTOS, (Guía del PMBOK®) —

Quinta edición [16]. Para más información consulte el Anexo 2.

Se tratará de mantener los nombres propios de la guía y sus numerales para no afectar la inter-

pretación de los mismos.

La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y téc-

nicas a las actividades del proyecto para cumplir con los requisitos del mismo. Están categori-

zados en cinco grupos de procesos los cuales son:

Figura 5: Categorización de los procesos de un proyecto

Fuente: Elaboración propia basado en la guía PMBOK [16]

El proyecto se va a guiar por los procesos de gestión de proyectos planteados en la guía PMBOK [16].

6.1.2 Metodología de desarrollo

Para este proyecto se decidió utilizar Scrum como metodología de desarrollo, ya que es un

proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar

colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prác-

ticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar

de equipos altamente productivos.

Proyecto

Inicio Planificación Ejecución Monitoreo y

ControlCierre


Página 36

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el bene-

ficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para

proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requi-

sitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad

y la productividad son fundamentales [52].

Para el desarrollo del proyecto SIGPLAN se escogió la metodología Scrum, esta metodología

toma como base 6 principios, los cuales responden a las necesidades del proyecto SIGPLAN

estos principios son los siguientes [52]:

Empirical Process Control: Este principio pone de relieve la filosofía central de Scrum

en base a las tres ideas principales de transparencia, inspección y adaptación.

Self-organization: Este principio se centra en los trabajadores de hoy, que entregan un

valor significativamente mayor cuando son auto-organizados lo cual resulta en equipos

con un gran sentimiento de compromiso y responsabilidad; a su vez, esto produce un

entorno innovador y creativo que es más propicio para el crecimiento.

Collaboration: Este principio se centra en las tres dimensiones básicas relacionadas con

el trabajo colaborativo: conciencia, articulación y apropiación. También aboga por la

gestión de proyectos como un proceso de creación de valor compartido con los equipos

de trabajo e interactuar conjuntamente para ofrecer el mayor valor.

Value-based Prioritization: Este principio pone de relieve el enfoque de Scrum para

ofrecer el máximo valor de negocio, desde el principio del proyecto hasta su conclu-

sión.

Time-boxing: Este principio describe cómo el tiempo se considera una restricción li-

mitante en Scrum, y cómo se utiliza para ayudar a manejar eficazmente la planificación

y ejecución del proyecto. Los elementos de time-box en Scrum son Sprints, Daily

Standup Meetings, Sprint Planning Meetings, y Sprint Review Meetings.

Desarrollo Iterativo: Este principio define el desarrollo iterativo y enfatiza cómo ma-

nejar mejor los cambios y crear productos que satisfagan las necesidades del customer.

También delinea las responsabilidades del Product Owner y las de la organización,

relacionadas con el desarrollo iterativo.

Existe una terminología asociada a esta metodología Scrum [52] la cual se puede encontrar en

el Anexo 3.


Página 37


7 FASE 2 PROPONER LOS OBJETIVOS

En esta fase se definen los objetivos de la solución, se crea el plan del proyecto SIGPLAN,

según lineamientos PMI [16], el cual contempla alcance, estructura de descomposición de tra-

bajo EDT, tiempo, calidad, recursos, riesgos, comunicaciones e integración, este plan permite

visualizar cómo se desarrollará en un plan de gestión para solución propuesta. Ver documento

completo en Anexo 4

Los objetivos de este trabajo de grado se encuentran en el numeral 3 de este documento.

7.1 Alcance del proyecto

En este proyecto se va a construir una solución que permita generar escenarios de planeación

para la gestión de un proyecto informático (SIGPLAN), para este fin se va a realizar el análisis,

diseño y desarrollo de una aplicación web la cual permita interactuar a los usuarios gerentes de

proyectos. Esta interacción se realiza mediante interfaces gráficas y realizando una serie de

procesos para que los usuarios puedan visualizar la generación de escenarios de planeación

para la gestión, estos escenarios que generan con base en información registrada en el sistema

e información que el usuario provee. Como resultado de este proceso de desarrollo se entrega-

rán los siguientes componentes:

Aplicación web: es el software que contiene toda la lógica de negocio para la genera-

ción de escenarios de planeación para la gestión de un proyecto informático.

Modelo relacional de base de datos: este modelo físico contiene toda la estructura re-

lacional donde se va almacenar la información necesaria para la que el software fun-

cione.

Manual técnico: este documento contiene las especificaciones de hardware y software

que la aplicación necesita para funcionar.

Memorias de trabajo de grado compiladas durante todo el proyecto

7.2 Descomposición del trabajo EDT

Figura 6: Estructura de descomposición del trabajo


Página 38


Tabla 4: Tabla que describe los componentes de la EDT

Nro. Nombre Entrega-

ble

Descripción

1. Plan Este entregable es la recopilación de varios documentos que

contiene todo el plan de proyecto de SIGPLAN desde los ob-

jetivos hasta su plan de gestión

1.1 Propuesta Sección que contiene la identificación del problema, objeti-

vos, impactos esperados.

1.2 Visión del Proyecto Sección que contiene el alcance del proyecto y su plan de ges-

tión.

1.3 Cronograma Estructura de entregables en una línea de tiempo que estará

dividida en TG1 semestre 1 y TG2 semestre 3 del 2016.

1.4 Formatos Son documentos que tienen formatos de acta de reunión,

plantilla de observaciones en las que se registrará las iteracio-

nes con ITAC. Ver Anexo 5,6 y 7

1.5 Plan de Gestión

marco

Selección de lineamientos de planeación de la gestión según

estándar PMI para la gestión del proyecto. Ver Anexo 2


Página 39


1.6 Documento de me-

todología de desa-

rrollo

Selección de una metodología de desarrollo de software para

implementar la solución SIGPLAN. Ver Anexo 3

2 Documento de Aná-

lisis

Este entregable es la recopilación de varios documentos que

contiene el levantamiento de información y el procesamiento

de la misma que va a generar la entrada para el diseño del

sistema SIGPLAN

2.1 Informe de métodos

de estimación

Análisis de los métodos de estimación y selección de 3 para

su posible implementación en la solución SIGPLAN

2.2 Documento Infor-

mación Base de

ITAC

Contiene la información histórica representativa de la planea-

ción para la gestión de proyectos informáticos de la empresa

ITAC

2.3 Informe de Clasifi-

cación de Proyectos

Definición de la clasificación de proyectos informáticos se-

gún su tamaño

2.4 Informe Descompo-

sición de proyectos

Definición de la clasificación de descomposición de proyec-

tos informáticos y sus interrelaciones

2.5 Informe de Metodo-

logías de implemen-

tación

Definición metodologías de desarrollo de software, una me-

todología tradicional y una metodología ágil para analizar

cómo estas impactan en el ciclo de vida del proyecto para ha-

cer las proyecciones

2.6 Documento de se-

lección de herra-

mientas para desa-

rrollo

Definición de un estándar para el desarrollo de la aplicación

web, que debe contener tecnologías aplicadas, lenguajes de

programación, Arquitectura, servidor de aplicación, motor de

base de datos.

2.7 Documento de Re-

querimientos

Definición de una lista de requerimientos para ser tenidos en

el diseño

2.8 Informe de Retros-

pectiva

Es la documentación de las reuniones y retroalimentaciones

obtenidas de las interacciones con la empresa ITAC hasta el

primer momento de análisis

3 Diseño Este entregable en la recopilación de documentos contiene

todo el proceso de análisis de la solución SIGPLAN

3.1 Arquitectura Definición de la arquitectura del proyecto

3.2 Modelo de dominio -

Entidad relación

Definición del modelo de dominio - entidad relación

3.3 Documento de Espe-

cificación de CU

(User Stories)

Definición de los casos de uso a desarrollar en la implemen-

tación del sistema.

3.3.1 Documento de Ta-

reas

Definición de las tareas a realizar las cuales se despliegan de

la especificación de casos de uso

3.3.2 Documento de Itera-

ciones (Sprint)

Contiene el conjunto de tareas a realizar dentro del Sprint


Página 40

3.2 Modelo de Dominio Contiene los diagramas del modelo de dominio de la aplica-

ción los cuales se convertirán en los diagramas de dominio -

entidad relación

3.4 Prototipo Contiene las interfaces y funcionamiento inicial del sistema

SIGPLAN

3.5 Informe de Retros-

pectiva

Es la documentación de las reuniones y retroalimentaciones

obtenidas de las interacciones con la empresa ITAC hasta el

segundo momento de diseño

4 Desarrollo Contiene el consolidado de código fuente, estructura de da-

tos, scripts y documentación relacionada al desarrollo

4.1 Código Fuente Aplicación web funcional

4.2 Informe pruebas Documento resultado de las pruebas en el desarrollo de la so-

lución SIGPLAN

4.3 Informe corrección

de errores

Documento resultado de la corrección de errores

5 Demostrar y evaluar Documento consolidado de aplicación de pruebas por parte

de los expertos gerentes, los resultados y análisis de las mis-

mas

5.1 Documento Plan de

pruebas

Documento del plan de pruebas que va a ejecutar el grupo de

expertos gerentes de proyectos

5.2 Formato Rúbrica de

evaluación

Definición de los ítems que se van a evaluar en las pruebas

5.3 Informe de ejecu-

ción

Documento que contiene el consolidado de las pruebas eje-

cutadas

5.4 Informe de resulta-

dos

Documento que contiene el análisis de los resultados de las

pruebas con los expertos gerentes de proyectos

5.5 Informe de control

alcance proyecto

Informe de revisión periódica con la directora de proyecto

para verificar el avance en la ejecución y si esto sea línea al

alcance del proyecto

5.6 Informe control cro-

nograma

Informe en donde se verifica el avance del proyecto frente a

las fechas de entrega propuestas en el cronograma

6 Comunicar Documento informe de todo el proceso del proyecto

6.1 Memorias de trabajo

de grado

Documento de trabajo de grado resultado del proyecto

6.2 Manual técnico Manual técnico de instalación de la aplicación

6.3 Herramienta Funcio-

nal

Código fuente de la aplicación web

6.4 Informe Entrega de

resultados

Informe de entrega de los resultados a la empresa participante

ITAC



Página 41


7.3 Plan de gestión del tiempo

El tiempo estimado para la ejecución del proyecto se divide en dos ítems

Trabajo de Grado 1: en este semestre se empieza a ejecutar desde la semana 9 hasta la semana

18.

Trabajo de Grado 2. En este semestre se a ejecutar desde la semana 1 hasta la semana 16

7.3.1 Resultados Esperados

En esta tabla se discriminan los entregables del proyecto en función del tiempo, diferenciados

por Trabajo de grado 1 y Trabajo de grado 2

Tabla 5: Tabla de los resultados esperados

RESULTADOS ESPERADOS

ASIGNATURA

MISyC

PROYECTO 1

1a Documento de Propuesta

1b Documento de Visión del proyecto, cronograma

1c Documentos de Formatos, Documento de la metodología de desa-

rrollo

1d Documento con el análisis de los componentes: método de estima-

ción, información base de ITAC, clasificación de proyectos, des-

composición de proyectos, metodologías de implementación, selec-

ción de herramientas de desarrollo, información histórica.

1e Documento de Requerimientos (Product backlog)

1f Informe de Retrospectiva (Restrospect Sprint)

ASIGNATURA

MISyC

PROYECTO 2

2a Arquitectura, modelo de dominio - entidad relación, Documento Es-

pecificación de CU (User Stories), Prototipo, Informe Retrospectiva

2b Software de la solución que permita generar escenarios de planea-

ción de la gestión de un proyecto informático. Código fuente, in-

forme de pruebas, informe de corrección de errores.

2c Documentación plan de pruebas, Formato rubrica de evaluación, in-

forme ejecución, informe de resultados

2d Documento con consolidación de las memorias de trabajo de grado

2e Documento manual técnico

2f Documento entrega de resultados


7.3.2 Cronograma

Tabla 6: cronograma del proyecto


Página 42

CRONOGRAMA

ASIGNATU

RA MISyC

PROYECTO

1

Se-

ma

nas

1 2 3 4 5 6 7 8 9 1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

18

1-

a x x x x x x x x x x x

1-

b x x

1-c x

1-

d x x x x x x x

1-e x x x x

1-f x

En

tre

gas 1

a

1

b

1

c

1d,1e,

1f

ASIGNATU

RA MISyC

PROYECTO

2

Se-

ma

nas

1 2 3 4 5 6 7 8 9 1

0

1

1

1

2

1

3

1

4

1

5

1

6

1

7

18

2-

a X

2-

b X X X X X X X X X

2-c X X X X

2-

d X X X X X X X X

2-e X X

2-f X X

En

tre

gas

2

a

2

e

2

b

2

c

2

c

2f 2

d


7.4 Prospectiva de innovación

Tabla 7: prospectiva de innovación

PROSPECTIVA DE INNOVACIÓN

POTENCIAL

DE

INNOVACIÓN

Desde el punto de vista de innovación se pretende que esta solución sea

de gran utilidad para los gerentes de proyectos (nuevos o experimenta-

dos) en apoyo a la toma de decisiones, ya que la solución va a permitirle


Página 43


visualizar posibles escenarios donde se combinen los recursos disponi-

bles de un proyecto sin necesidad de que le gerente realice un análisis

riguroso de la planeación del proyecto, esta solución le permitirá combi-

nar con los recursos disponibles y visualizar como estos afectan todo el

ciclo de vida del proyecto, estos elementos pueden llegar a ser de gran

utilidad cuando se desee analizar la viabilidad de un proyecto o presentar

propuestas a clientes.

PROPIEDAD

INTELECTUAL Este trabajo de grado se realizará dentro del marco de investigación del

grupo de investigación ISTAR de la Pontificia Universidad Javeriana de

Bogotá. El resultado documental del proyecto aportará al marco global

del desarrollo del grupo ISTAR y servirá como base para futuros trabajos

y proyectos del grupo, y estará a disposición del grupo ISTAR, sin nin-

guna restricción de uso académico. El software producto de este trabajo

de grado se licenciará bajo Freeware.


7.5 Impactos Potenciales

Tabla 8: Impactos potenciales

IMPACTOS POTENCIALES

DESARROLLO

CIENTÍFICO Y

TECNOLÓGICO

Este proyecto propone una solución que será de gran utilidad para los

gerentes de proyectos ya que por medio de la solución propuesta se per-

mitirá de una forma anticipada contar una visión global del proyecto. Lo

cual es la base para apoyar la toma de decisiones a nivel gerencial.

Esta solución permitirá a las empresas hacer un uso eficiente y prove-

choso de sus datos históricos en la ejecución de proyectos informáticos,

estos datos servirán como base del modelo y refinación de generación

de escenarios de planificación.

La solución propuesta pretende integrar componentes críticos en la pla-

neación de la gestión de proyectos, para que a partir del modelo de in-

teracción entre ellos se pueda obtener na visión general del proyecto que

muestre los costos, tiempo, recursos humanos, alcance, que le permitirá

al gerente tener elementos para realizar un plan de proyecto más asertivo

y eficiente.

Esta solución pretende causar un impacto competitivo para las organi-

zaciones, generando un valor agregado a la hora de tomar decisiones


Página 44

frente a iniciativas de proyectos, cerrando la brecha entre la incertidum-

bre del plan de gestión de proyectos y convirtiéndose en la solución de

apoyo para los gerentes de proyectos.

IMPACTO Y

PROYECCIÓN

EN LA

SOCIEDAD

Lo que se pretende con la solución es que aumente el número proyectos

exitosos en la industria Colombiana en el campo de las tecnologías de la

información, esto se puede lograr desde el momento es que nace una

iniciativa de proyecto generando planes de proyecto más precisos y efec-

tivos, con esta propuesta se hace un aporte a uno de los problemas que

se enfrenta la industria del software y así el país se podrá trasformar en

un motor competitivo a los mercados globales que demandan soluciones

de alta complejidad y calidad.

ASPECTOS

ÉTICOS Y

AMBIENTALES

Por el lado ético la solución propuesta utilizará software libre en sus he-

rramientas de implementación, con esto se evita utilizar software priva-

tivo de forma no autorizada.


7.6 Plan de gestión de recursos humanos

Este proyecto contará con la participación de un grupo de trabajo dividida en tres partes las

Directora de proyecto: Ing. María Mercedes Corral

Ejecutor: Paulo Alexander Chirán

Empresa Participante: ITAC

7.6.1 Organigrama

Este organigrama representa una estructura horizontal no jerárquica donde cada rol cumple con

funciones específicas dentro del proyecto y todos aportan un factor importante para el éxito del

mismo.

Figura 7: Organigrama del proyecto

Directora

deproyecto

Ejecutor

Empresa Participant

e


Página 45



7.6.2 Roles y responsables

A continuación, se presenta una descripción de cada uno de los cargos involucrados en la eje-

cución del proyecto.

Directora de Proyecto: es la persona responsable de hacer seguimiento al proyecto, brindar

asesoría hacia el Ejecutor con el fin de resolver dudas o dar lineamientos sobre el estado del

proyecto, además de recibir y avalar los entregables que se tienen propuestos en toda la ejecu-

ción.

Ejecutor: es la persona responsable de ejecutar todo el plan de proyecto, es responsable de

culminar los entregables del proyecto y entregarlos a la directora de proyecto, el ejecutor debe

estar en constante comunicación con la directora y la empresa participante para recibir retro-

alimentación y asesorías.

Empresa Participante ITAC: esta empresa tiene los siguientes roles

Proveedor de Información (PI): debido al recorrido de que esta empresa tiene, cuenta con

información importante en temas relacionados con estructura, planeación, ejecución y segui-

miento de proyectos, la cual será analizada y tenida en cuenta para el diseño del modelo. Esta

información también será un elemento importante para tener una base comparativa con los

resultados que arroje la solución SIGPLAN.

Retroalimentador (RE): las fases de diseño y desarrollo de la aplicación se construirán de

forma iterativa y se presentarán a la empresa ITAC para que esta haga aportes en cada una de

las fases desde su experiencia.

Verificador (VE): al final del diseño y desarrollo, la empresa ITAC debe hacer una prueba de

concepto de la solución SIGPLAN y con una rúbrica de verificación se podrá constatar que tan

cerca del objetivo propuesto se encuentra el trabajo realizado. En este rol de verificador tam-

bién pretende buscar otra organización o un grupo de expertos gerentes de proyectos para que

hagan parte de la prueba y den su concepto del proyecto SIGPLAN.

7.7 Vinculación del proyecto con ITAC

Como se explicó en un capitulo anterior el proyecto SIGPLAN propuesto tendrá la participa-

ción de la empresa ITAC - IT Applications Consulting [6] la cual es una empresa pequeña [27],

100% colombiana fundada en el año 2004, dedicada a proveer servicios de desarrollo de soft-

ware a la medida y desarrollo de productos propios como software seguro, esta empresa cuenta

con una madurez CMMI DEV [24] nivel 3. En el año 2016 esta empresa empieza su proceso

de madurez CMMI DEV nivel 5, este proceso cuenta con 32 áreas de proceso las cuales se van

implantando según el nivel de madurez de la organización. En la siguiente imagen se pueden

apreciar los niveles CMMI DEV.

Figura 8: Niveles de madurez CMMI


Página 46

Fuente: tomada de [53]

Los niveles se componen de categorías y las categorías cuentan con áreas de proceso como se

ve en la siguiente imagen.

Figura 9: Categorías de CMMI DEV


Página 47


Fuente: tomada de reingeniería de procesos [54]

El proyecto SIGPLAN se encuentra ubicado dentro de la categoría Gestión de proyectos y el

área de proceso PP – Planificación del proyecto.

Propósito de la Planificación del proyecto según CMMI DEV [24]:

“El propósito de la Planificación del Proyecto (PP) es establecer y mantener planes que definan las actividades del proyecto. La planificación incluye la estimación de los atribu-tos de los productos de trabajo y de las tareas, la determinación de los recursos necesa-rios, la negociación de los compromisos, la elaboración de un calendario, y la identifica-ción y el análisis de los riesgos del proyecto. Para establecer el plan de proyecto, puede ser necesario realizar iteraciones de estas actividades. El plan de proyecto proporciona la base para realizar y controlar las actividades del proyecto que abordan los compromi-sos con el cliente del proyecto”.

7.8 Plan de gestión del riesgo

La gestión de riesgos se realizará durante toda la ejecución y cierre del proyecto, esta sección

se presentan los aspectos considerados para la definición de la matriz de riesgos en donde para

cada riesgo potencial se establece su descripción, probabilidad de ocurrencia, impacto, plan de

mitigación, plan de contingencia y el responsable de su gestión.

A continuación, se muestra la estructura de descomposición del riesgo (EDR)

Figura 10: Estructura de descomposición del riesgo

De la EDR se describen posibles riesgos que pueden llegar a materializarse durante la ejecución

del proyecto, junto con un plan de mitigación para evitar que lleguen a materializarse y en caso

que sea inevitable su eventual aparición se presenta un plan de contingencia.

Probabilidad de Ocurrencia [Alta; Media; Baja]: Probabilidad de materialización de un

riesgo.


Página 48

Muy Alta: tiene una alta probabilidad de ocurrir durante la ejecución del proyecto en

un porcentaje superior o igual al 80%

Alto: tiene una alta probabilidad de ocurrir durante la ejecución del proyecto en un

porcentaje igual o superior al 70 % y menor al 80%

Medio: tiene una probabilidad media de ocurrir durante la ejecución del proyecto en-

tre un 40 % y 69 %

Baja: tiene una probabilidad media de ocurrir durante la ejecución del proyecto entre

un 11 % y 39 %

Muy baja: tiene una alta probabilidad de ocurrir durante la ejecución del proyecto en

un porcentaje mayor que 1 y menor o igual al 10%

Tabla 9: Definición de las escalas de impacto del riesgo

Condiciones definidas para las escalas de impacto de un Riesgo sobre los principales

objetivos del proyecto

Objetivo

del pro-

yecto

Muy Bajo Bajo Medio Alto Muy Alto

Tiempo Aumento en

tiempo ente

uno 1 y 2

días

Aumento en

tiempo ente

uno 3 y 4

días

Aumento en

tiempo ente

uno 5 y 7

días

Aumento en

tiempo ente

uno 8 y 15 días

Aumento en

tiempo ente uno

16 y más días

Alcance Disminu-

ción del al-

cance en 1%

en términos

no funciona-

les

Disminución

del alcance

en un 2 % en

términos no

funcionales

Disminución

del alcance

en un 5 % en

términos no

funcionales

Disminución

del alcance en

un 10 % en

términos no

funcionales y

funcionales

Disminución

del alcance

igual o superior

15 % en térmi-

nos no funcio-

nales y funcio-

nales

Calidad Disminu-

ción de la

calidad en

1% en térmi-

nos no fun-

cionales

Disminución

de la calidad

en 2% en tér-

minos no

funcionales

Disminución

de la calidad

requiere

aprobación

de los aseso-

res

Disminución

de la calidad

requiere res-

tringir el al-

cance de fun-

cionalidades

Disminución de

la calidad re-

quiere eliminar

funcionalidades



Página 49


A continuación, se explica los planes para mitigar el riesgo en el proyecto SIGPLAN

Plan de Mitigación: Acciones preventivas a tomar para disminuir la probabilidad de

ocurrencia de un riesgo.

Plan de Contingencia: Acciones correctivas dada la materialización de un riesgo.

Tabla 10: Plan de mitigación del riesgo

Plan del riesgo

ID Riesgo Pro-

babi-

lidad

Im-

pacto

Plan Mitigación Plan Contingencia

1. Técnico

1.1 Tecnolo-

gía ade-

cuada

Baja Me-

dio

La selección de tecnología

se estableció como una ta-

rea primordial para que el

desarrollo del proyecto se

lleve a cabo con éxito

En caso de que un compo-

nente no funcione bien se

pretende buscar en la bi-

bliografía otro sustituto

que pueda cumplir las mis-

mas funciones sin afectar la

calidad del producto final

1.2 Calidad Baja Me-

dio

Para asegurar la calidad del

proyecto, se realizarán eva-

luaciones y retroalimenta-

ciones periódicas con el fin

de corregir errores antes de

que estos lleguen a un es-

tado avanzado

Si en una etapa avanzada se

descubre algún elemento

con baja calidad se debe re-

visar y corregir, revisando

que su impacto sea menor

en su entorno.

2. Externo

2.1 Renuncia

de ITAC

Baja Me-

dio

Constante verificación so-

bre el compromiso de su

permanencia en el proyecto

Buscar una empresa que

pueda participar en el pro-

yecto, en caso que no exista

otra empresa se debe bus-

car uno o más expertos ge-

rentes de proyectos para

que suman el rol de ITAC

2.2 Demora

en tiem-

Alta Baja Se plantea hacer reuniones

cortas sólo con los interesa-

dos en la fase que se esté

Hacer sesiones cortas con

la parte interesada de

ITAC, esta sesión consiste


Página 50

pos de res-

puesta de

ITAC

llevando en curso, se solici-

tará apoyo a la gerencia de

ITAC para gestionar los

tiempos de respuesta

en responder algunas pre-

guntas

3. Gestión del Proyecto

3.1 Renuncia

Directora

de Pro-

yecto

Baja Me-

dio

Constante comunicación

para conocer el estado de su

permanencia en el proyecto

Solicitar a la dirección de

la maestría un director que

pueda seguir con la Direc-

ción del proyecto

3.3 Tiempos

no se

cumplan

Baja Me-

dio

Constante seguimiento al

resultado de los entregables

comprometidos

Sacar actividades extras

que no le aporten dema-

siado al proyecto pero que

no afecten su calidad final

3.2 Enferme-

dad del

ejecutor

Baja Me-

dio

Cuidado personal en temas

relacionados con salud

Ajustar el cronograma para

ver que las actividades

planteadas se cumplan


7.9 Gestión de la calidad del proyecto

En este proyecto se pretende establecer políticas de calidad para asegurar que cada uno de los

entregables que tiene el proyecto SIGPLAN satisfaga las necesidades por las cuales fue creado.

Para hacer este seguimiento de la calidad se va a usar un artefacto llamado “hojas de verifica-

ción” esta herramienta se va a usar como una comprobación de que tan aceptable es un entre-

gable en términos de calidad.

Para evaluar esta calidad se tendrá esta métrica de evaluación:

Aceptable: se refiere a que el entregable se ajusta a los requerimientos planteados y con una

alta calidad

Bueno: se refiere a que el entregable se ajusta a los requerimientos planteados, pero puede ser

susceptible de mejora en algunos aspectos, no se rechaza el entregable, pero se deja la obser-

vación para su posterior revisión.

Mejora Necesaria: el entregable no se ajusta a los requerimientos planteados, por lo tanto, es

necesario ajustarlo para que suba al nivel de bueno o aceptable.


Página 51


7.10 Estrategia de comunicaciones

Para este proyecto se definieron dos estrategias de comunicación

A. Comunicación con la directora de proyecto: se definieron reuniones semanales en las

cuales se debe presentar el respectivo avance del proyecto, estas reuniones se llevaron

a cabo en las instalaciones de la universidad o sitios alternos acordados por las partes,

también se hizo uso de los canales electrónicos como correo.

B. Comunicación con la empresa participante: esta comunicación se realizó mediante

reuniones programadas dentro de la organización, el objetivo de estas reuniones fue

mostrar los avances y recibir las observaciones a los avances, los resultados de estas

reuniones se ponen en actas de reunión.

7.11 Componentes

En este capítulo se realizó un análisis amplio de los componentes utilizados para la solución

SGIPLAN, estos componentes se describen en una serie de entregables los cuales hacen parte

de los anexos de este proyecto, para facilitar al lector el recorrido de este análisis cada compo-

nente analizado tiene un breve resumen.

7.11.1 Métodos de estimación

Este análisis pretende identificar los métodos más apropiados para estimación de software, es-

tas es una parte fundamental para una gestión efectiva del proceso de desarrollo de proyectos

informáticos. La medición del tamaño de un software es comúnmente, uno de los principales

obstáculos para la estimación de los tiempos y el costo de un proyecto. Este trabajo busca

revisar los principales métodos para calcular el tamaño y estimar los esfuerzos y costos del

proceso de desarrollo.

Para este proyecto se decidió utilizar el método de estimación de esfuerzo por puntos de caso

de uso [55], este método define una medida de la cantidad de esfuerzo que se requiere para

desarrollar software frente a la cantidad de trabajo que el software está destinado a hacer. El

método de punto de caso de uso fue creado por Gustav Karner de Rational Software Corpora-

tion en los mediados de los años 1990 [56]. Este método se basa en un estudio de cerca de 200

proyectos con un tamaño medio de 5 años-hombre de esfuerzo.

Para ver el análisis completo ver Anexo 9

7.11.2 Información base de ITAC

Este capítulo pretende describir la dinámica de trabajo de la empresa ITAC IT Application

Consulting en el entorno de sus procesos para el desarrollo de proyectos informáticos.

Para realizar el proceso de validación de la solución se decidió recolectar a la información de

4 proyectos que la empresa ya desarrolló en los años 2016, 2015 y 2012, esta información

corresponde a los siguientes datos:


Página 52

Número de horas hombre del proyecto

Costos de los recursos humanos involucrados

Costos de impuestos de los proyectos

Gastos administrativos del proyecto

Tecnologías de desarrollo del proyecto

Arquitectura del proyecto

La información suministrada por ITAC sirvió para diseñar los modelos de entre la generación

de escenarios y los componentes de los proyectos, por otro lado, la parte relacionada con los

costos sirvió para calcular los gastos generales de los escenarios, estos costos son específicos

a cada organización así que quedaron parametrizables en base de datos, más adelante en el

capítulo de diseño se amplía el tema de costos.

Por razones de privacidad con ITAC esta información no es pública por lo tanto no hace parte

de los entregables del proyecto, solo se utilizó con fines académicos dentro del proyecto.

7.11.3 Clasificación de proyectos

Este capítulo hace referencia a la clasificación de proyectos informáticos los cuales tienen un

amplio espectro según su enfoque y entorno en el que se desea aplicar, el objetivo de este

numeral es hacer un breve recorrido sobre los proyectos informáticos y definir cuáles son los

proyectos en los que se va a profundizar en la solución propuesta SIGPLAN.

7.11.3.1 Proyecto informático

Cómo ya se ha descrito un proyecto es un esfuerzo temporal que se lleva a cabo para crear un

producto, servicio o resultado único, por naturaleza un proyecto tiene un objetivo claro, es

temporal, tiene recursos e implica que tiene un inicio y un final definidos [16]. Entonces, un

proyecto informático es la ejecución de actividades simultáneas, secuenciales o iterativas que

incluyen personas, infraestructura, hardware, software y diversos planes, enfocados en obtener

uno o más resultados deseables sobre un sistema de información [57]. En la siguiente figura se

observan los componentes de un sistema informático.

Figura 11: componentes de un proyecto de desarrollo de software

Proyecto Infromatico

Objetivo

Recursos humanos

financieros

Tenologia

Principio y final

Procesos

Personas


Página 53



En el análisis realizado se identificaron diferentes tipos de proyectos informáticos los cuales se

numeran a continuación:

Desarrollo de software

Planeación de recursos empresariales ERP

Gestión de relación con los clientes CRM

Gestión de la cadena de suministro SCM

Proyectos de hardware

Comunicación y redes

Instalación de hardware para seguridad

Sistemas de información de misión crítica SIMC

Auditorias

Sistemas operativos

Inteligencia de negocios

Mantenimiento de aplicaciones

El proyecto SIGPLAN se centra en proyectos informáticos de tipo “Desarrollo de software”

este tipo de proyectos cuenta con características específicas que se nombran a continuación y

serán tenidas en cuenta para el desarrollo del modelo de la aplicación SIGPLAN.

Características de proyectos informáticos de desarrollo de software

Estas características están basadas en los aportes de [58], [59], para tener más información

remitirse al documento Anexo 11

Datos persistentes: La información persistida generalmente es el núcleo del sistema y su ciclo

de vida es más amplio que el del resto de los componentes.

Estructura de datos: están organizados en decenas de millones de registros, siendo esta infor-

mación la mayor parte del sistema, por lo general se utilizan motores de base de datos relacio-

nales en los cuales se hace más fácil el acceso a la información.

Acceso concurrente a datos: Generalmente muchas personas acceden a los datos concurren-

temente. Debido a esto, hay problemas bien determinados que deben abordarse para asegurar

que los distintos usuarios pueden acceder a la información de manera confiable.

Interfaces gráficas: Para manejar tanta información es necesario disponer de cientos de pan-

tallas que permitan presentar los datos de distinta forma y, eventualmente, para distintos usua-

rios.

Integrado con otras aplicaciones empresariales: Las aplicaciones empresariales raramente

viven de manera aislada; generalmente requieren integrarse con otras aplicaciones de la em-

presa o fuera de la misma.


Página 54

Lógica de Negocio Compleja: Las reglas de negocio son parte integral del sistema ya que

permite mejorar procesos, tareas, además de interconectar diferentes áreas de la organización.

Lenguajes de Programación: existe diferentes lenguajes en los cuales puede ser implemen-

tado como por ejemplo lenguajes imperativos, declarativos, orientados a objetos, orientados al

problema y de programación natural. Este proyecto se centra en los lenguajes orientados a ob-

jetos de tercera generación, junto con lenguajes imperativos como SQL y lenguajes declarati-

vos como HTML.

Arquitectura: puede ser arquitectura multicapa, arquitectura orientada a servicios SOA, web,

cliente servidor, entre otras.

Para ver el informe completo ver Anexo 10

7.11.4 Descomposición de proyectos

El objetivo de este capítulo es presentar una estructura de descomposición de proyectos infor-

máticos, esto quiere decir llevar al nivel de clasificación de los proyectos teniendo en cuenta

lenguajes de desarrollo, framework de presentación, tipo de aplicaciones web, móvil o escrito-

rio, bases de datos, entre otras características. Esto con el fin de centrar la propuesta hacia un

tipo de proyectos específicos para acotar el alcance y hacer que SIGPLAN sea más efectivo

centrándose en los tipos de aplicaciones empresariales transaccionales.

Como insumo a este documento se tomará el entregable Anexo 10, desarrollado en el marco de

este proyecto, el cual nos brinda una visión global de la clasificación de proyectos informáticos,

por consiguiente, se pretende profundizar más en esta materia para ampliar el suministro a una

posterior etapa que es el diseño del sistema SIGPLAN.

En el análisis realizado en el documento Anexo 11 se identificaron las diferentes aplicaciones

de software:

Web Estática

Web dinámica

Aplicaciones web gestoras de contenidos

Web animada

Web de tienda virtual

Portal web

Aplicación web empresarial

Este proyecto se enfoca en las Aplicaciones web empresariales ya que son aplicaciones de

software desarrolladas para administrar las operaciones, activos y recursos de una empresa

[60], Este tipo de aplicaciones es la de mayor dificultad, fácilmente este tipo de aplicaciones

tiene millones de líneas de código (java, C#, Vb, Php, sql), este tipo de aplicaciones soportan

modelos de negocio como por ejemplo en el sector financiero, salud, educación, seguridad,

administrativos, transaccional, entre muchos más, las aplicaciones web empresariales por lo


Página 55


general son multicapa, con motores de base de datos y comunicación entre sistemas de infor-

mación externos. Por lo general estos sistemas empresariales están en la intranet de las empre-

sas, donde se potencia el acceso a la información de la organización, contacto con clientes y

proveedores, material de trabajo para sus trabajadores, cuidando mucho el tipo de información

a presentar en función del tipo de usuario que la solicita por ser muchas veces confidencial

[61].

Ver informe completo Anexo 11.

7.11.5 Herramientas de desarrollo

El propósito de este capítulo es establecer las herramientas de desarrollo que se van a usar para

implementar SIGPLAN, estas herramientas comprenden el entorno de desarrollo, lenguaje de

programación, base de datos, generador de reportes, JDK, entre otras.

A continuación, se presenta una tabla con los ítems seleccionados

Tabla 11: herramientas de desarrollo

Descripción Ítem Seleccionado

Entorno integrado de desarrollo NetBeans 8.1

Lenguaje de Programación Java

Edición empresarial JEE 7

Java Developer Kit JDK 8

Framework de presentación PrimeFaces 6.0

Gestor de bibliotecas Maven

Servidor de aplicaciones Glassfish 4.1

Motor de Base de datos Postgres 9.5

Para ver el informe completo ver Anexo 12

7.11.6 Requerimientos

Para el levantamiento de requerimientos de la solución SIGPLAN se tuvieron en cuenta el

análisis que se realizó a los métodos de investigación, la clasificación de proyectos, descom-

posición de proyectos, y cruzados con la información y necesidades expresadas por la empresa

ITAC, a continuación, se presenta un breve resumen de los elementos tenidos en cuenta para

tomar los requerimientos iniciales

7.12 Bases de conocimiento

Tabla 12: Cuadro de relación de información analizada para la generación de escenarios

Investigación Objetivo Resultado


Página 56

Métodos de estimación Realizar un análisis e identi-

ficar los diferentes métodos

de estimación que las organi-

zaciones utilizan para reali-

zar planeaciones de proyec-

tos y calcular los esfuerzos

requeridos

Se seleccionó un método de

estimación el cual será usado

y aplicado en la solución

SIGPLAN, este método de

estimación también fue iden-

tificado como un elemento de

apoyo que usa la empresa

ITAC para realizar sus esti-

maciones y posterior planea-

ción de proyectos informáti-

cos

Clasificación de proyectos Realizar un análisis de los di-

ferentes proyectos informáti-

cos que desarrollan las em-

presas de base tecnológica,

con este análisis se pretende

analizar el foco en el que se

encuentra la industria co-

lombiana y en especial la

empresa participante ITAC

Se identificó la caracteriza-

ción de proyectos informáti-

cos y se seleccionó junto con

la empresa ITAC cuales de

estos proyectos por su natu-

raleza son los que mayor de-

manda se requieren en el

mercado. Esta caracteriza-

ción permitió identificar para

que tipo de proyectos se iba a

realizar los escenarios de pla-

neación

Descomposición de proyec-

tos

Realizar un análisis de los di-

ferentes componentes que

encierran el desarrollo de un

proyecto informático, estos

componentes se desglosaron

en tecnologías, arquitectu-

ras, lenguajes, entre otros

elementos

Se identificó los componen-

tes que encierran los proyec-

tos informáticos y en especial

los de desarrollo de software

a la medida, estos elementos

fueron la base para identifi-

car las variables que deben

ser expuestas en la genera-

ción de los escenarios


7.13 Información de proyectos de ITAC

ITAC suministró información que ha recopilado a través de los años en documentos y herra-

mientas de seguimiento y control, esta información se depuró ordenó y clasificó para obtener

el mejor provecho de ella, a continuación, se explica que tipo de información que se obtuvo, el

objetivo de procesar esta información y los resultados obtenidos del análisis.


Página 57


Tabla 13: Cuadro de análisis de información suministrada por ITAC

Información suministrada Análisis Resultado

Documentos de arquitectura

de diferentes proyectos desa-

rrollados

Identificar la caracterización

de los proyectos desarrolla-

dos, junto con los compo-

nentes que involucraron la

solución final

Se realizó el cruce de infor-

mación con la clasificación

de proyectos y los proyectos

ejecutados en la empresa

ITAC, con esto se logró

identificar con cuales pro-

yectos se puede trabajar para

la generación de escenarios

de planeación

Información de esfuerzos en

ejecución de proyectos, cla-

sificada por roles personas y

roles que participaron en las

diferentes etapas de los pro-

yectos

Identificar el esfuerzo invo-

lucrado en cada fase del pro-

yecto y que la sumatorio de

estos esfuerzos lleven a cum-

plir los objetivos del pro-

yecto

Se estableció los elementos

como costos, fases y esfuer-

zos asociados a la ejecución

de los proyectos, esto permi-

tió tener un entendimiento

claro de las fases en los que

los proyectos demandan más

recursos financieros y es-

fuerzo.

Información de costos fijos,

costos variables y deducibles

de los proyectos

Identificar los costos indirec-

tos y directos asociados a la

ejecución de proyectos

Este análisis permitió identi-

ficar todos los costos que se

encuentran alrededor de un

proyecto y analizar el im-

pacto que estos costos tienen

sobre el funcionamiento de

la organización y la ejecu-

ción de proyectos


Como resultado de esta primera fase se presentó a ITAC una lista de requerimientos a tener en

cuenta para la generación de escenarios, junto con ITAC se priorizaron los requerimientos y se

eliminaron algunos elementos que identificó que no le aportaban valor significativo al proyecto

SIGPLAN.

Del análisis de esta segunda fase se generan los requerimientos del proyecto SIGPLAN, este

análisis dio como resultado la definición de 44 requerimientos funcionales y 1º requerimientos

no funcionales. A continuación, se hace una breve descripción de los requerimientos, se iden-

tificaron 4 módulos principales del proyecto:


Página 58

Módulo de administración: aunque este módulo no hace parte del alcance de este proyecto, se

identificó la necesidad de modelar los roles y usuarios de la aplicación, para que en trabajos

futuros se pueda completar esta funcionalidad.

Módulo de costos: dentro de este módulo se encuentran funcionalidades que permites registrar

los costos asociados a la operación de la organización estos costos se dividen en los siguientes

ítems.

Módulo de gestión de proyectos: este módulo permite administrar todo el ciclo de vida de las

aplicaciones desarrolladas en por la organización esta funcionalidad se divide en parametriza-

ción de los componentes y administración de proyectos históricos de la organización.

Módulo de escenarios: este es el módulo principal del sistema SIGPLAN, en el cual debe tomar

como parámetros de entrada el alcance, inversión, recursos, tiempo y como resultado se debe

mostrar la combinación de todos estos recursos para obtener el mejor escenario que llevaría a

un proyecto satisfactorio para la empresa. Este módulo hace uso del módulo de costos y gestión

de proyectos para ser más preciso al generar la estimación.

Se requiere que ingrese los parámetros antes nombrados y seleccione cuál de estos tiene mayor

prioridad y cuál de estos no es variable, a partir de estos datos el sistema debe generar escena-

rios combinando los recursos disponibles. En caso que con los recursos disponibles no sea

posible un escenario válido el sistema debe generar otros escenarios en los cuales se cumpla en

alcance del proyecto.

Figura 12: Módulos generales del sistema SIGPLAN


En la siguiente figura se muestra un desglose general de cada módulo del sistema.

Figura 13: Módulos de proyecto SIGPLAN


Página 59



A continuación, se muestra en detalle el módulo de costos del proyecto SIGPLAN.

Costos fijos: son los relacionados a los costos administrativos de la empresa dentro de

estos se encuentran servicios públicos, arriendo, alquiler de servidores, servicios gene-

rales entre otros.

Costos variables: los costos variables están directamente asociados a los proyectos

como, por ejemplo, viáticos, costo de licencias, bonificaciones por objetivos, entre

otros.

Impuestos: estos impuestos están relacionados con los descuentos de ley que debe in-

currir la empresa por ejecutar proyectos informáticos sea en el sector público o en el

sector privado. Estos impuestos están relacionados con entes como Dian, cámara de

comercio, IVA, retención en la fuente.

Recurso Humano: Los recursos humanos son los componentes más importantes en el

desarrollo de los proyectos informáticos, es por ello que el sistema SIGPLAN debe

permitir ingresar los diferentes perfiles que pueden participar en el proyecto y los cos-

tos por hora, día o mes que están asociados a estos roles.

Ganancia: SIGPLAN debe permitir que la empresa ingrese su porcentaje de ganancia

por proyecto, esto permite visualizar los márgenes libres que deben quedar de un pro-

yecto cuando se restan los costos fijos más los costos variables.

Figura 14: Módulo de costos


Página 60


A continuación, se muestra en detalle el módulo de Gestión de proyectos del proyecto

SIGPLAN

Ciclo de vida del proyecto: Este módulo representa los ciclos de vida del proyecto y los tiempos

que se dedican a cada fase del desarrollo. Estas fases de ciclo de vida tienen relación directa

con los proyectos.

Componentes del proyecto: Los componentes son parte integral de los proyectos, entre estos

componentes se tienen en cuenta los módulos funcionales, las tecnologías involucradas, las

operaciones de negocio que soportan, también como la complejidad que involucró su desarro-

llo.

Histórico de proyectos: este corresponde a un resumen de los proyectos ejecutados en los que

se tendrá en cuenta tiempos, costos, alcance, recursos humanos.

Plan de gestión: se debe capturar un resumen de los esfuerzos involucrados en cada fase de la

gestión del proyecto, contando desde el inicio, planeación, ejecución, monitoreo y control. Es-

tos esfuerzos están medidos por tiempo, número de recursos asignados, también los costos aso-

ciados a cada fase.

Tipo de Proyectos: los tipos de proyectos comprenden la clasificación de los proyectos infor-

máticos y se trata de capturar los proyectos a los que se dedica la empresa para mejorar la

estimación.


Página 61


Figura 15: Módulo de gestión de proyectos


A continuación, se muestra en detalle el módulo de escenarios del proyecto SIGPLAN

Módulo de escenarios: este es el módulo principal del sistema SIGPLAN, en el cual debe

tomar como parámetros de entrada el alcance, inversión, recursos, tiempo y como resultado se

debe mostrar la combinación de todos estos recursos para obtener el mejor escenario que lle-

varía a un proyecto satisfactorio para la empresa. Este módulo hace uso del módulo de costos

y gestión de proyectos para ser más preciso al generar la estimación.

Se requiere que ingrese los parámetros antes nombrados y seleccione cuál de estos tiene mayor

prioridad y cuál de estos no es variable, a partir de estos datos el sistema debe generar escena-

rios cambiando los recursos disponibles. En caso se lo solicitado con los recursos disponibles

no sea posible el sistema debe generar otros escenarios en los cuales se cumpla en alcance del

proyecto.

Tener en cuenta documento:

2.1 Informe de métodos de estimación. Ver Anexo 9

2.2 Documento de información base de Itac.docx

Figura 16: Módulo de generación de escenarios


Página 62

Fuente: Elaboración Propia

para ver el informe completo de requerimientos ver Anexo 13

7.14 Informe de retrospectiva

Esta fase termina con la presentación en ITAC del documento de requerimientos de la cual

surgen comentarios y aportes de mejora, los cuales quedan consignados en el acta de la reunión

ver Anexo 14.

Como conclusiones generales de la reunión, se visualiza una buena acogida del proyecto por

parte de ITAC, y se queda que para tener más claro el objetivo del proyecto se debe presentar

un prototipo funcional e incremental de la herramienta.

custom Módulo de E...

REQ-041 Generar

Escenario de

Costos

REQ-042 Generar

Escenario de

Recursos

Humanos

REQ-043 Generar

Escenario de

Alcance

REQ-044 Generar

Escenario de

Tiempo


Página 63


8 FASE 3 DISEÑAR Y DESARROLLAR

En esta fase se presenta de forma concisa la arquitectura propuesta y el diseño detallado del

proyecto SIGPLAN. Este documento evolutivo reúne los elementos de arquitectura necesarios

para proporcionar a los usuarios técnicos una herramienta que le permita la validación de la

propuesta por el desarrollador y además que sea una guía fundamental para la construcción

total del sistema y su posterior mantenimiento.

8.1 Arquitectura

8.1.1 Alcance

En este documento se encuentra la arquitectura de la solución con la vista de alto nivel, vista

detallada, despliegue físico, despliegue lógico y diagrama de paquetes.

8.1.2 Audiencia

La audiencia de este documento incluye analistas expertos del negocio, técnicos, desarrollado-

res, arquitectos, diseñadores y analistas funcionales que de una u otra forma tengan relación

con el sistema.

8.1.3 Motivaciones de negocio

Contar con un sistema que le brinde soporte al proceso de planeación de la gestión de proyectos

informáticos, brindando escenarios que ayuden al gerente de proyectos a proyectar las iniciati-

vas con recursos disponibles y bajo restricciones de la organización o impuestas por el cliente.

8.1.4 Decisiones de arquitectura

A continuación, se relacionan las diferentes decisiones de arquitectura generales, en donde se

contemplan las configuraciones del servidor de aplicaciones y base de datos de la aplicación.

La arquitectura definida para la solución SIGPLAN está basada en los lineamientos de la Pla-

taforma JAVA edición empresarial [62], a continuación, se explican algunos lineamientos

clave en el diseño del proyecto.

8.2 Recomendaciones para el uso de tecnología JEE

Cuando se implementan aplicaciones empresariales usando tecnología JEE, se recomienda que se haga uso de Frameworks existentes en el mercado. Para la capa de presentación se recomienda que se haga uso del framework estándar de industria Java Server Faces. Los Entity Beans, Message-Driven Beans y Session Beans tienen diferentes usos en una aplica-ción JEE. Es importante comprender dónde encaja cada uno de los tipos de componentes EJB cuando se está diseñando una aplicación.


Página 64

8.3 Entidades

Los entity beans son clases POJO serializables que son utilizados para representar el modelo

de negocio, uno de los mayores cambios de la versión 2.1 a la versión 3.0 de los entity beans

es que estos no son tratados como componentes EJB, ni tienen un ciclo de vida especifico que

administre el contenedor, simplemente son clases POJO con anotaciones para realizar el mapeo

del objeto a la tabla. Se recomienda usar entity beans cuando se requiere almacenamiento per-

sistente para un objeto de negocio utilizando JPA.

8.4 Clientes Web

Un cliente web consta de dos partes, páginas web dinámicas que contienen varios tipos de

lenguaje de marcado (HTML, XML, entro otros) generados por componentes web que se eje-

cutan en el nivel web. Un navegador web que procesa las páginas recibidas en el servidor, Un

cliente web a veces se llama un cliente ligero. Los clientes ligeros normalmente no consultan

bases de datos, no ejecutan reglas de negocio complejas o no se conectan a aplicaciones here-

dadas. Cuando se utiliza un cliente ligero, estas operaciones pesadas se descargan a los beans

empresariales que se ejecutan en el servidor Java EE, donde pueden aprovechar la seguridad,

la velocidad, los servicios y la fiabilidad de las tecnologías de servidor Java EE.

8.5 Comunicación del servidor

La Figura 1 muestra los diversos elementos que pueden formar el nivel de cliente web de la

solución SIGPLAN. El cliente se comunica con el nivel de negocio que se ejecuta en el servidor

Java EE directamente o, como en el caso de un cliente que se ejecuta en un navegador, pasando

por páginas web o servlets que se ejecutan en el nivel web.

Figura 17: Comunicación del servidor

Fuente: Java Platform, Enterprise Edition [62]


Página 65


8.6 Componentes de la aplicación SIGPLAN

Los componentes web de Java EE usados en la solución SIGPLAN son páginas web creadas

utilizando la tecnología Java Server Faces, estas clases de lenguaje de programación Java que

procesan dinámicamente peticiones y construyen respuestas. La tecnología Java Server Faces

se basa en servlets y tecnología JSP y proporciona un marco de componentes de interfaz de

usuario para aplicaciones web.

Las páginas y los applets estáticos del HTML se empaquetan con los componentes del Web

durante el ensamblaje de la aplicación, pero no se consideran componentes por la especifica-

ción de Java EE.

Las clases de utilidad del servidor también se pueden incluir con componentes web y, al igual

que las páginas HTML, no se consideran componentes web. A continuación, se especifican los

componentes involucrados en el despliegue de la aplicación SIPLAN.

Figura 18: Componentes de despliegue

Fuente: Java Platform, Enterprise Edition [62]

8.6.1.1 Decisiones comunes

Se elige como herramientas y tecnologías de desarrollo las expresadas en el numeral 7.11.5

Para mayor información de las herramientas de desarrollo remitirse al documento Anexo 12

desarrollado en el marco del proyecto SIGPLAN.


Página 66

Se va a entregar un módulo desplegable que va a representar la aplicación SIGPLAN, la cual

se encargará de implementar los casos de uso de generación de escenarios de

La aplicación va a ser desarrollada bajo una arquitectura N-Tier (N-Capas), la cual permite que

se pueda manejar componentes distribuidos, así como la asignación de responsabilidades espe-

cíficas a cada una de las capas.

Para el modelo de datos se definen los siguientes prefijos para el nombramiento de las tablas de la base de datos:

SP_*: Representa el prefijo de las tablas que van a ser modeladas como parte del dominio de

SIGPLAN.

8.6.2 Vista Funcional

Se describen los elementos funcionales del sistema, así como sus principales responsabilidades.

Es un punto de referencia para el entendimiento del desarrollo de la arquitectura.

La solución SIPLAN permitirán ser una herramienta de apoyo en la planeación de la gestión

de proyectos informáticos, la herramienta permitirá generar escenarios de la planeación de un

proyecto, contemplando elementos como recursos financieros, tiempo, recurso humano, al-

cance del proyecto. Un escenario se compone de la distribución de recursos con lo cual se

pretende llegar al objetivo del proyecto, en el caso que los recursos disponibles no sean sufi-

cientes la solución SIGPLAN debe brindar un escenario alternativo.

Se pretende que SIPLAN sea una herramienta de fácil uso intuitiva para que sea usada por

líderes, gerentes de proyectos, gerentes generales. Esta herramienta necesitará de una configu-

ración inicial para su correcto funcionamiento y constante actualización para que la generación

de escenarios sea más precisa.

8.6.3 Vista de alto nivel

En esta vista se muestra los componentes en conjunto, para mostrar sus relaciones y la forma

en que están organizados. Actualmente se cuenta con una infraestructura organizada en domi-

nios y capas, las cuales definen los diferentes componentes y las relaciones de interacción per-

mitidas. Cada domino está constituido por diferentes capas, las cuales separan las aplicaciones

dependiendo de su responsabilidad.

A continuación, se muestra los dominios identificados y su responsabilidad:

SIGPLAN: En este dominio se encuentran las aplicaciones, servicios y datos desplegados ne-

cesarios para la aplicación SIGPLAN.


Página 67


Figura 19: Vista de alto nivel de SIGPLAN


8.6.4 Vista Detallada

Es esta vista se realiza un acercamiento al entorno de la aplicación, en el cual se realizará el

despliegue de los diferentes módulos de la aplicación y las plataformas que lo soportaran.

Figura 20: Vista detallada de SIGPLAN

deployment Vista física detallada

Entorno de alto niv el

Capa de aplicación

«executionEnvironment»

Serv idor linux


Serv idor Glassfish 4.1


Capa de datos


Serv idor Linux


Postgres 9.5

deployment Vista alto niv el

SIGPLAN


Entorno de aplicación


Capa de acceso


Capa de aplicaciones


Capa de datos


Página 68


8.6.5 Despliegue físico

Este diagrama presenta los diferentes dispositivos y entornos de ejecución que se encuentran

alrededor del despliegue de las aplicaciones. El diagrama muestra, basado en las decisiones de

arquitectura, cómo la aplicación se encuentra desplegada en el servidor de aplicaciones y el

esquema de base de datos se encuentra en un entorno diferente.

Figura 21: Despliegue físico de SIGPLAN


8.6.6 Capas del Sistema

La arquitectura general de la aplicación SIPLAN esta basadas en el estilo N-Tiers, en donde se

hace una clara separación de las responsabilidades además de modularizar la aplicación. Las

capas utilizadas por ambos aplicativos son las siguientes:

Capa de cliente: Representa los usuarios que van a realizar peticiones al sistema a

través de un navegador web.

Capa Web: Representa todos los componentes que van a realizar el procesamiento de

las páginas, redirecciones y parte visual con la cual van a interactuar los clientes de las

aplicaciones.

Capa de Negocio: Representa todos los componentes que realizan procesamiento de

flujos y reglas de negocio, procesamientos transaccionales de datos. Le presta servicios

de procesamiento a la capa web.

deployment Despliegue físico

SGIPLAN

Cliente SIGPLAN


Serv idor Linux


Glassfish 4.1


Instancia SIGPLAN

SIGPLAN-ear-1.0.ear


Serv idor Linux


Postgres 9.5

Esquema Domiciliación

HTTP JDBC


Página 69


Capa de Persistencia y Datos: Representa los componentes que realizan las atraccio-

nes del modelo de dominio y modelos de datos que serán utilizados por las diferentes

aplicaciones. Se encapsula en su propio módulo con el fin de que pueda ser reutilizable

ente los módulos.

Para ver el documento de arquitectura completo ver Anexo 15

8.7 Modelo de Dominio

El modelo de dominio explica las entidades existentes en la solución SIGPLAN y a su vez

representa las relaciones entre estas entidades.

Figura 22: Modelo de Dominio


8.7.1 Modelo entidad relación

Figura 23: Modelo entidad relación


Página 70


A continuación, se describen algunas entidades principales

SP_PROYECTO: Esta entidad representa un proyecto informático donde lo integran otras en-

tidades y todas las características de un proyecto informático, esta entidad es una de las princi-

pales ya que a esta se le asocian atributos de otras entidades y se crean estructuras intermedias

a las cuales se les asignan los valores correspondientes de cada proyecto. Las entidades que

tiene asociación directa con SP_PROYECTO son:

sp_proyecto_arquitectura

sp_proyecto_ciclo

sp_proyecto_componente

sp_proyecto_costo_fijo

sp_proyecto_costo_variable

sp_proyecto_factor

sp_proyecto_framework

sp_proyecto_gestion

sp_proyecto_impuesto

sp_proyecto_lenguaje

sp_proyecto_rr_hh

SP_ARQUITECTURA: Esta entidad representa la categorización de arquitecturas de software,

entre las que se pueden encontrar arquitecturas SOA, multicapa, microservicios, cliente servi-

dor.


Página 71


SP_CICLO DE VIDA: Esta entidad describe si un proyecto informático se desarrolló con todas

las fases de desarrollo como lo son el análisis, diseño, implementación, pruebas, puesta en

marcha, garantía. Pueda darse el caso que un proyecto solo cuente con algunas fases o también

que cuente con todas las fases.

SP_COSTOS_FIJOS: Esta entidad representa los costos fijos asociados a un proyecto infor-

mático dentro de estos costos se puede incluir gastos administrativos, de infraestructura, servi-

cios públicos, arriendos.

SP_COSTO_VARIABLE: Esta entidad representa los costos del recurso humano, infraestruc-

tura, viáticos que estén asociados directamente al proyecto.

SP_FACTOR: Esta entidad representa los factores de estimación de los componentes del pro-

yecto, estos son los que se usa en el método de puntos de casos de uso: factor técnico, factor

ambiental, casos de uso, factor actor.

SP_FRAMEWORK: Esta entidad representa todos los framework de desarrollo presentes en

un proyecto informático, junto a estos están asociados grados de complejidad en la utilización

de este respecto a productos similares.

SP_IMPUESTO: Esta entidad representa los impuestos asociados a un proyecto informático,

todo proyecto es deducible de impuestos y la ganancia se calcula a partir de la base libre.

SP_LENGUAJE: Esta entidad representa los lenguajes de desarrollo en los que puede ser im-

plementado un proyecto informático, junto a estos están asociados grados de complejidad en

la utilización de este respecto a productos similares.

SP_RECURSO_HUMANO: Esta entidad representa el recurso profesional y humano que in-

terviene en el desarrollo de un proyecto informático, algunos ejemplos de estos recursos son

ingenieros, arquitectos, gerente, entre otros profesionales. Esta entidad también representa el

costo de cada recurso dentro del proyecto.

SP_TIPO_DE PROYECTO: Esta entidad representa la categorización de proyectos informáti-

cos que desarrolla la organización ITAC, estos tipos de proyectos pueden variar según el enfo-

que de desarrollo o nichos de negocio.

Documento completo Ver Anexo 16

8.8 Documento de Casos de uso

En esta fase se definieron los comportamientos de las entidades descritas en el modelo entidad

relación, con los procesos que desarrolla el sistema SIGPLAN y se dividieron en tres grandes

grupos, proceso de administración y configuración, proceso de proyectos y procesos de gene-

ración de escenarios. A continuación, se explica cada uno de estos.


Página 72

8.8.1 Proceso de administración y configuración

Dentro de este módulo del sistema se encuentran todas las entidades que requieren y pueden

contar con tareas de administración (insertar, actualizar, borrar, leer) dentro de este grupo se

encuentran las siguientes entidades:

sp_arquitectura

sp_ciclo_vida

sp_complejidad

sp_componente

sp_costo_fijo

sp_costo_variable

sp_empresa

sp_factor

sp_framework

sp_gestion

sp_impuesto

sp_lenguaje

sp_parametro

sp_periodo

sp_recurso_humano

sp_rol

sp_seguridad

sp_tipo_factor

sp_tipo_proyecto

sp_usuario

sp_usuario_rol

para las entidades anteriormente nombradas se realizó un caso de uso estándar en el cual el

usuario pueda realizar la consulta, inserción, edición y eliminación.

Documento de caso de uso ver Anexo 17

8.8.2 Proceso de Proyectos

Esta funcionalidad corresponde a la caracterización de los proyectos que desarrolla la organi-

zación, esta caracterización consiste en registrar todos los componentes del proyecto, como por

ejemplo tiempo del proyecto, fases del proyecto y los recursos involucrados en cada fase, la

descripción de los factores que aplicaron al proyecto, así como los elementos técnicos (lengua-

jes de desarrollo, arquitectura, frameworks). Esta funcionalidad hace uso de las siguientes en-

tidades.

sp_proyecto

sp_proyecto_arquitectura

sp_proyecto_ciclo

sp_proyecto_componente

sp_proyecto_costo_fijo

sp_proyecto_costo_variable

sp_proyecto_factor

sp_proyecto_framework

sp_proyecto_gestion

sp_proyecto_impuesto

sp_proyecto_lenguaje

sp_proyecto_rr_hh

Documento de caso de uso Ver Anexo 18


Página 73


8.8.3 Proceso de generación de escenarios

La funcionalidad de generación de escenarios es la funcionalidad principal del sistema

SIGPLAN, la cual permite al usuario seleccionar unas variables básicas a partir de estas varia-

bles el sistema debe hacer una combinación de tiempo, recursos humanos, alcance y dinero

para alcanzar el objetivo de generar un escenario general que le permita al gerente de proyectos

tener una vista de cómo sería su proyecto con los recursos disponibles y las capacidades de la

organización.

Documento de caso de Uso ver Anexo 19

8.9 Prototipo

Para esta fase se utilizó prototipos evolutivos, que permitió crear versiones cada vez más com-

pletas del sistema SIGPLAN. Este modelo empezó con la creación de unas interfaces primarias

para luego ir aumentando la funcionalidad de generación de escenarios. Las iteraciones se rea-

lizaron continuamente hasta tener más claros los objetivos generales del software, identificando

las funcionalidades principales. Estas iteraciones de prototipos se realizaron una vez al mes con

la empresa participante ITAC durante la ejecución del proyecto y el modelado con un diseño

iterativo. Los diseños se encaminaron en una representación de aquellos aspectos del software

que serán visibles para los usuarios finales, el diseño iterativo condujo a la construcción de un

prototipo cada vez más cercano a lo esperado. El prototipo fue evaluado por las partes intere-

sadas en este caso son ITAC y la directora del trabajo de grado, de estas presentaciones se

obtuvo una retroalimentación que se utiliza para refinar aún más los requisitos. A continuación,

se presenta de forma gráfica el paradigma de prototipos [63].

Figura 24:Modelo evolutivo,

Fuente: tomado de Software Engineering a Practitioner’s Approach, Séptima Edición

[63]


Página 74

8.10 Desarrollo

En esta fase se muestra los componentes software desarrollados y cómo estos interactúan para

generar los escenarios para la planeación de la gestión de un proyecto informático. La solución

SIGPLAN cuenta con los siguientes componentes.

Módulo de administración

Módulo de costos

Módulo de proyectos

Motor generador de escenarios

Calculador de factores

Módulo de escenarios

Base de datos

Figura 25: Componentes de la solución SIGPLAN


8.10.1 Módulo de Administración

Este módulo contiene la parametrización inicial del sistema dentro de esta parametrización se

puede encontrar

Empresa: se usa para asociar posteriormente los proyectos a una empresa registrada en el sis-

tema, además de contener unos parámetros como número de horas laborales y número de em-

pleados de apoyo y operativos.


Página 75


Tipo de proyecto: comprende la lista de los tipos de los tipos de proyectos que desarrolla la

organización ITAC, estos tipos son parametrizables para cada organización donde se desee por

en funcionamiento la solución SIGPLAN.

Arquitectura: comprende las arquitecturas de proyectos informáticos que son más usadas en

el medio de las empresas tecnológicas.

Ciclo de Vida: comprende las fases o ciclos de proyectos, desde la fase de análisis hasta la fase

de puesta en marcha.

Componentes: son características contables dentro de un sistema de información las cuales

son número de campos, tablas de referencia, tablas de domino, casos de negocio, numero de

roles, número de reportes, interfaces externas (consumo de servicios externos como por ejem-

plo servicios web).

Framework: comprende los paquetes de tecnologías que son utilizadas en los proyectos infor-

máticos.

Lenguajes: comprende los diferentes lenguajes de programación desde orientados a objetos

hasta los leguajes SQL.

Tiempo: es un conjunto de rangos de tiempo que son aplicables a los costos del proyecto

Seguridad: es la lista del rango niveles de seguridad de la aplicación

Tipo factor: son los factores que contemplan la estimación basada en puntos de caso de uso

Factores: es el conjunto de variables que clasifican en cada tipo de factor

Parámetros: son un conjunto de variables parametrizables para que la aplicación configure un

entorno inicial de la aplicación.

8.10.2 Módulo de costos

Este módulo encierra la parametrización de costos organizacionales dentro de los cuales se

encuentran

Costos fijos: comprende los costos organizacionales que se cobran con o sin la existencia de

proyectos. Como por ejemplo los servicios públicos, los gastos administrativos, entre otros

Costos variables: comprende los costos organizacionales que están directamente asociados

con el proyecto que se esté llevando a cabo en el momento de ejecutar el proyecto, o también

son los costos variables que demande el volumen de producción de la organización.

Impuestos: es el conjunto de valores deducibles a los proyectos.

Recurso humano: son los costos discriminados por roles dentro de la organización.


Página 76

8.10.3 Módulo de proyectos

Este módulo integra el módulo de administración y el módulo de costos, los proyectos son el

conjunto de elementos tecnológicos y de recursos humanos y financieros que se emplearon

para lograr un objetivo, este módulo cumple la función de caracterizar los proyecto que desa-

rrolla la organización y a partir de esta caracterización se hace una regresión que permite cal-

cular el factor de esfuerzo que está empleando en los proyectos.

8.10.4 Motor generador de escenarios

Este componente cumple una función muy importante que es hacer la transformación de los

elementos que ha seleccionado el usuario y convertirlos en escenarios de la planeación para la

gestión. Este motor cuenta con factores de conversión y un conjunto de reglas que permiten

combinar los recursos disponibles en un solo proyecto.

8.10.5 Calculador de factores

Este componente permite calcular de forma regresiva cual es el factor de tiempo empleado para

resolver los puntos de caso de uso, posteriormente este factor se usa para recalcular los nuevos

escenarios de planeación. Este componente es usado tanto por el módulo de proyectos como

por el motor generador de escenarios. Ver Anexo 26

8.10.6 Módulo de escenarios

Este módulo comprende tanto la presentación grafica de esta funcionalidad de escenarios, su

interacción con el módulo de administración, módulo de proyectos y el motor generador de

escenarios. Este módulo integra todos los recursos del sistema para generar escenarios de pla-

neación para la gestión de un proyecto informático. Ver Anexo 27

8.10.7 Base de datos

Este es el componente de persistencia de la solución SIGPLAN, cabe resaltar que es un motor

de base de datos relacional y todas sus entidades están relacionadas entre sí para lograr una

consistencia en la información registrada.

8.11 Pruebas y Corrección de errores

Para esta fase se desarrollaron un conjunto de pruebas unitarias y funcionales, las cuales per-

mitieron identificar errores dentro de la aplicación y posteriormente en un plan de corrección

de errores se arreglaron los defectos encontrados. A continuación, en una tabla se muestran los

consolidados de las pruebas realizadas y la corrección de errores.

Tabla 14: Resultado de pruebas y corrección de errores

Módulo Número de pruebas Errores encontrados Errores Resueltos

Administración 3 35 35

Costos 3 15 15


Página 77


Proyectos 30 45 45

Escenarios 100 150 150

Fuente: elaboración propia


Página 78

9 FASE 4 DEMOSTRAR

En esta fase se pretende hacer una prueba de concepto de la solución SIGPLAN, esta prueba

consiste en evaluar de forma cualitativa y cuantitativa la solución planteada, para luego hacer

un análisis de los resultados y obtener las conclusiones del proyecto.

9.1 Plan de Pruebas y Rubrica de evaluación

En esta fase se desarrollaron un conjunto de pruebas de la solución SIGPLAN, estas pruebas

se realizaron con diferentes gerentes de proyecto de la empresa ITAC y de otras empresas. El

objetivo de estas pruebas de concepto es validar y verificar el funcionamiento de la solución

desde una vista de utilidad para los gerentes y como esta le puede apoyar a las tareas de pla-

neación de proyectos.

Los formatos se encuentran en el Anexo 20 y Anexo 21


Página 79


10 FASE 5 EVALUAR

10.1 Resultado de pruebas

El objetivo de esta fase es consolidar los resultados de las pruebas realizadas a la solución

SIGPLAN, estas pruebas fueron realizadas a 3 gerentes de proyectos de entidades activas en el

sector de las tecnologías de la información, incluidos los aportes de la empresa ITAC.

En el consolidado de preguntas gráficamente se puede observar que frente a usabilidad y es-

tructura visual del software el resultado es satisfactorio, mientras que en preguntas como:

Si la información que muestran los escenarios de planeación para la gestión el 66 % respondió

que es excelente mientras que el 33% opina que es regular.

Es una herramienta que puede llegar a ser de utilidad para los gerentes de proyectos en su

organización, el 66% respondió que sería altamente útil y el 33 % respondió que en algunos

casos sería de utilidad.

Presenta apoyo a los objetivos planteados del proyecto, el 66% opina que si presenta apoyo

para los objetivos y el 33% opina que establece algunos criterios de apoyo.

Figura 26: Consolidado de preguntas


0 0,5 1 1,5 2 2,5 3 3,5

Presentación y estructura visual del software

Usabilidad

Presenta apoyo a los objetivos planteados en elproyecto

Es una herramienta que puede llegar a ser deutilidad para los gerentes de proyecto en su

organización

La información que muestran los escenarios deplaneación para la gestión es

consolidado de preguntas

No aceptable Regular Satisfactorio Excelente


Página 80

10.1.1 Observaciones generales

¿Cuáles son los aspectos positivos de la herramienta que puedan apoyar a un gerente en

una fase previa de la planeación del proyecto y su organización?

La herramienta es muy útil no sólo en la fase previa a la planeación, sino que también

puede apoyar la toma de decisiones una vez el proyecto ha iniciado, cuando a medida

que se tienen más detalles las condiciones pueden cambiar. Es allí cuando la herra-

mienta puede apoyar al Gerente de Proyecto en la toma de decisiones para solventar

las nuevas situaciones y conseguir los objetivos.

Con la generación de escenarios la herramienta puede ayudar a determinar la viabilidad

inicial del proyecto.

La información suministrada por los escenarios puede ser la entrada para presentar una

propuesta formal al cliente, junto con los tiempos, costos y alcance del proyecto.

La parte de los proyectos en importante ya que para generar los escenarios toma la

información de la organización, esto permite identificar el comportamiento de los pro-

yectos que se han desarrollado en la organización.

La herramienta apoya en la estimación y/o validación de costos planeados para un pro-

yecto, siendo particularmente útil cuando se alimenta con la historia de la empresa,

ayudando así a tener mayor precisión. Sin embargo, se considera que la herramienta

por sí misma no debería ser la única herramienta o artefacto usado para la toma de

decisiones de estimación de tamaño, esfuerzo, costo de un proyecto. Es decir, usar la

herramienta puede apoyar de forma relevante a validar las estimaciones que se han

hecho usando otras herramientas o técnicas para poder establecer tamaño, esfuerzo,

costo de un proyecto nuevo.

Con una base de datos significativa de información histórica de proyectos, que haya

sido recogida de manera sistemática y formal, la organización podría tener una fuente

de información importante en la cual apoyar su toma de decisiones.

¿Cuáles aspectos por mejorar considera que tiene la herramienta SIGPLAN?

Se pueden manejar nuevos tamaños de proyecto, tal vez caracterizados por sector (ej.

financiero, salud, minero, entre otros)

En cuanto a usabilidad los escenarios podrían describir mejor lo que representa cada

uno.

Sería una mejora adicionarle modelos predictivos para poder llegar a un control esta-

dístico de procesos

Tener él cuenta el tema de calidad en el sistema


Página 81


Tener en cuenta el tema de defectos para realizar escenarios más realistas

Tener en cuenta el tema de riesgos y como estos pueden afectar la planeación

Que otras variables son necesarias para llegar a tener escenarios más precisos

Sería muy interesante que se le pudiera agregar un módulo o funcionalidades orienta-

das a proyectos de mantenimiento de software y no solo para proyectos nuevos.

Por otro lado, que el porcentaje de ganancia se debería definir como una variable defi-

nida por la empresa para cada tipo de proyecto y no a partir de la historia, dado que

esto no refleja necesariamente la realidad (podrían existir proyectos históricos en los

cuales la rentabilidad no fue la que la empresa requería).

Finalmente, contar con tablas comparativas de las diferentes opciones o simulaciones

realizadas, que permitan al gerente del proyecto o a la fuerza comercial contrastar los

datos calculados y las diferentes opciones planteadas por la herramienta de una forma

más fácil.

Proveer una base más grande de información a partir de la cual la organización pueda

empezar a tomar decisiones, así como apoyar el análisis de estimaciones en distintas

fuentes y autores.

¿Cuáles aspectos no le aportan valor a la herramienta SIGPLAN?

El manejo de roles en la aplicación no es claro ni tampoco su diferenciación.

En general, en general se considera que la herramienta está bien conceptualizada. Qui-

zás se hace necesario organizar un poco mejor la forma como se presenta la informa-

ción.

No se le quitaría nada a la herramienta, tal y como se ha tenido la oportunidad de ana-

lizarla.

Comentarios adicionales

Aunque la herramienta está planteada para Organizaciones cuyo Core de negocio son los pro-

yectos informáticos, la herramienta puede llegar a ser útil para todo tipo de organizaciones en

las cuales se involucren proyectos de naturaleza tecnológica. La caracterización y parametriza-

ciones iniciales junto con el cargue de la información propia de la organización hacen que los

escenarios planteados se ajusten a la cultura organizacional y por ende sean de mucha utilidad.

Trabajos como los del ISBSG, que es una entidad que lleva muchos años recopilando y entre-

gando herramientas para realizar estimaciones del esfuerzo requerido para los proyectos de

SW, o las investigaciones de Caper Jones, quien lleva más de 20 años haciendo investigaciones

en el mismo sentido. Como consecuencia de lo anterior, el trabajo observado consiste en una

herramienta de software que las organizaciones pueden utilizar para alimentar su propia infor-

mación y con base en ello empezar a hacer algunos análisis, con los escenarios limitados que

brinda la herramienta.

Para ver el análisis completo de las pruebas ver Anexo 23


Página 82

10.2 Control al alcance

El control al alcance se realizó durante la ejecución del proyecto, haciendo un seguimiento

continuo a los entregables de la estructura de descomposición de trabajo (EDT) y seguimiento

a los objetivos planteados en el proyecto. A continuación, se analiza el porcentaje de cumpli-

miento de los objetivos específicos

Tabla 15:Control al alcance


11 FASE 6 COMUNICAR

En esta fase se realizan actividades de cierre del proyecto, en las cuales se dan a conocer los

resultados y conclusiones del proyecto.

11.1 Memorias de trabajo de grado

Este documento hace parte del proceso de trabajo de grado para obtener el título de Magister

en Ingeniería de Sistemas y Computación de la Universidad Javeriana.

Junto con las memorias de trabajo de grado se desarrolló un poster del proyecto, ver Anexo22

11.2 Manual técnico

El manual técnico de la aplicación se encuentra en el Anexo 25

Objetivo específico Porcentaje de

avance

estado

Especificar los componentes de planeación para la gestión de un

proyecto informático

100 % Finali-

zado

Diseñar un modelo para generar escenarios de planeación para

la gestión de un proyecto informático.

100 % Finali-

zado

Desarrollar el modelo de generación de escenarios de planeación

para la gestión de un proyecto informático

100 % Finali-

zado

Validar la solución desarrollada a través de una prueba de con-

cepto.

100 % Finali-

zado


Página 83


11.3 Solución SIGPLAN

Los resultados software de este proyecto quedan a disposición de ITAC quien licenciará bajo

Freeware.

11.4 Conclusiones

11.4.1 Conclusiones generales

Este proyecto se abordó con un método de investigación científica basada en el diseño [1], esto

permitió conocer de forma rigurosa la problemática a abordar, ya que se analizaron amplia-

mente las áreas de conocimiento relacionadas tanto con la planeación de proyectos, como las

características especiales de los proyectos informáticos, esto contrastado con una realidad de

la empresa ITAC que fue un actor crítico e imparcial de los componentes que se proponían en

la solución a medida que el proyecto avanzaba, ITAC siempre aportó información, análisis y

criterios con el fin de generar soluciones reales a problemas reales de la industria, como con-

secuencia de esta interacción entre el entorno y la literatura relacionada se produjo un entendi-

miento claro de problema y abrió el camino para plantear una solución paso a paso con meto-

dologías evolutivas que cada vez se acercaban a cumplir los objetivos planteados, el desglose

de trabajo y gestión de proyectos que se propuso al inicio de esta iniciativa bajo la metodología

del PMBOK [16] lo que permitió abordar la problemática de una forma práctica, estructurada

y eficiente, resolviendo a la vez una parte del problema y que esta parte interactuaba con su

parte anterior, esta serie de pasos condujo a que al finalizar el proyecto la suma de todas sus

partes completaban el objetivos general y los objetivos específicos planteado en la propuesta.

Este trabajo se desarrolló con el fin brindar un aporte a las diferentes problemáticas que en-

frentan las empresas que se dedican al desarrollo de proyectos informáticos, el principal bene-

ficio de esta iniciativa se centra en la fase inicial de los proyectos, donde los gerentes deben

generan proyecciones, analizar la viabilidad de iniciativas e incluso presentar propuestas de

proyectos en marcos globales de trabajo, la solución SIGPLAN brinda una visión global de los

proyectos haciendo combinaciones de recursos humanos, financieros, tiempo y alcance en di-

ferentes escenarios donde el proyecto informático lograría los objetivos planteados, con estos

elementos los gerentes de proyectos pueden tomar decisiones respecto a las necesidades de la

organización.

Adicionalmente, la solución SIGPLAN se diseñó con elementos estandarizados que permiten

a las organizaciones realizar su caracterización en proyectos y le permite registrar su base his-

tórica con el fin de que ésta pueda ser de utilidad en la generación de escenarios, estos elemen-

tos permiten a través del tiempo ajustar los modelos con el fin de que siempre representen el

actual funcionamiento de la organización y reflejar su comportamiento según sus capacidades.

Una parte importante que contribuyo al éxito del proyecto SIGPLAN fue la vinculación de

ITAC, esta una organización cuyo foco principal es el desarrollo de proyectos informáticos

para diferentes organizaciones a nivel nacional, expresó desde una visión crítica y con base en

la experiencia en ejecución de proyectos, las necesidades a las que se enfrenta la industria día

a día, esta visión ayudo a focalizar con mayor esfuerzo en los puntos críticos de la gestión

previa de la planeación en los proyectos informáticos.


Página 84

Se puede concluir que la solución SIGPLAN tiene un gran potencial para las organizaciones

desde el punto de vista que esta solución puede llegar a conocer las capacidades de la organi-

zación, los recursos, costos y esfuerzo aplicado a los proyectos, con estos elementos y am-

pliando las capacidades del SIGPLAN se puede llegar a generar escenarios más precisos de tal

forma que le aporte de manera significativa a realizar planeaciones más acertadas a los gerentes

de proyectos.

11.4.2 Frente a las pruebas con gerentes

Las pruebas realizadas con los gerentes de proyecto dieron una visión más amplia de lo que

podría llegar a ser la propuesta SIGPLAN ampliando su enfoque y madurez de la solución, los

aportes y observaciones realizadas a la solución SIGPLAN se hicieron con gran optimismo

sobre las utilidades que puede llegar a tener en las organizaciones de base tecnológica, incluso

se propone dar un enfoque más amplio a otro tipo de proyectos. La utilidad se puede manifestar

en diferentes etapas en una organización, el primero objetivo es que sea una solución para

gerentes de proyectos que apoye en una epata temprana la iniciativa de proyectos, brindando

una visión global con los escenarios planteados.

La generación de escenarios de la herramienta puede ayudar a determinar la viabilidad inicial

del proyecto, ya que esta le muestra una combinación de recursos y con estos elementos en

donde el gerente puede analizar si cumple el alcance de proyecto.

La información suministrada por los escenarios puede ser la entrada para presentar una pro-

puesta formal al cliente, junto con los tiempos, costos y alcance del proyecto.

Esta es una primera versión de la solución SIGPLAN, por lo tanto, se puede visualizar aportes

de mejora para siguientes versiones como por ejemplo incluir otras variables de proyecto como

temas relacionados con la calidad, riesgos, defectos e incluir nuevos parámetros que aporten a

generar escenarios más precisos y de mayor alcance para los gerentes de proyectos.

11.4.3 Frente a los escenarios

Las variaciones en los recursos humanos, tiempo, recursos financieros depende de la combina-

ción de los elementos y componentes del proyecto, al realizarla prueba de concepto a nivel

general se puede observar la variación en los recursos humanos se ve reflejado directamente en

los tiempos y costos, cuando se involucra más gente en el proyecto la tendencia es a reducir los

tiempos y los costos del proyecto, esto se debe a que la empresa tiene que acarrear con menos

gastos administrativos cuando el proyecto dura menos tiempo.

Por otro lado, cuando se involucra personal menos capacitado en un proyecto esto tiende a

aumentar el tiempo que va a durar el proyecto, esto se debe a que personal sin experiencia no

puede responder con la misma efectividad a las necesidades del proyecto.

Los escenarios son un primer acercamiento al proyecto, depende del análisis que el gerente

realice a la combinación de los recursos y a las necesidades actuales de la organización, a partir

de este análisis pueda tomar decisiones si desea o no tomar la iniciativa como viable.


Página 85


11.5 Trabajos Futuros

SIGPLAN podrá ser una solución más robusta si se desea involucrar técnicas de control esta-

dístico de procesos y modelos predictivos, en donde se utilicen varias técnicas de modelamiento

estadístico, aprendizaje autónomo y minería de datos, para conocer más de cerca las capacida-

des de los procesos y realizar escenarios predictivos.

Existen variables y recursos de los proyectos que no se tuvieron en cuenta para esta primera

fase de la solución, para una siguiente versión se podría analizar factores como riesgos, calidad,

defectos y estructurar el modelo de tal forma que se analice cuáles otras variables que no se

tuvieron en cuenta pueden a llegar a tener un impacto en la generación de escenarios para que

estos seas más precisos.

Se puede ampliar la funcionalidad de SIGPLAN, generando funcionalidades como generación

de cronogramas, generación de planes en project u otras herramientas, generación de informes

que puedan ser utilizados para propuestas formales a clientes o para realizar análisis estadísti-

cos de los proyectos, o sea la entrada a otra herramienta de gestión de proyectos.

Se propone ampliar la funcionalidad de SIGPLAN no solo de proyectos informáticos de desa-

rrollo a la medida, sino también que se pueda generar escenarios de proyectos de tipo mante-

nimiento o mejoras a sistema de información existentes.


Página 86

12 ANEXOS

1. Resumen de la propuesta - Enlace Web

2. Plan de Gestión Marco según la Guía PMBOK – Enlace Web

3. Informe de metodología de implementación – Enlace Web

4. Documento de visión del proyecto – Enlace Web

5. Formato de entregable del proyecto – Enlace Web

6. Formato de Acta de Reunión – Enlace Web

7. Formato de Asistencia a reunión

8. Cronograma del proyecto – Enlace Web

9. Informe de métodos de estimación -Enlace Web

10. Informe de clasificación de proyectos – Enlace Web

11. Informe de descomposición de proyectos -Enlace WEB

12. Informe de selección de herramientas - Enlace Web

13. Documento de requerimientos – Enlace Web

14. Acta de retrospectiva 1- Enlace Web

15. Arquitectura del proyecto SIGPLAN – Enlace Web

16. Documento de dominio -Enlace Web

17. Caso de Uso de Administración y Configuración – Enlace Web

18. Caso de Uso de proyectos – Enlace Web

19. Caso de uso de Generación de Escenarios – Enlace Web

20. Plan de Pruebas – Enlace Web

21. Rubrica de Evaluación -Enlace Web

22. Poster del proyecto - Enlace Web

23. Informe de resultados de pruebas – Enlace Web

24. Informe de resultados de pruebas Excel – Enlace Web

25. Manual técnico de la aplicación – Enlace Web

26. Calculo de factores – Enlace Web

27. Motor generador de escenarios - Enlace Web

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/MISyC_TG-ResumenPropuesta-PauloChiran-2016-04-12.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/2.6_Plan_de_Gestion_Marco.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/2.5_Informe_de_metodologias_de_implementacion.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/1.2_Documento_de_vision_del_proyecto.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Formato_Entregable.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Formato_TG_ACTA.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Formato_TG_ASISTENCIA.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Cronograma_SIGPLAN.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/2.1_Informe_de_metodos_de_estimacion.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/2.3_Informe_de_clasificacion_de_proyectos.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/2.4_Informe_de_descomposicion_de_proyectos.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/2.6_Documento_seleccion_de_herramientas.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/2.7_Documento_de_requerimientosV2.0.0.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/TG_Acta_010.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/3.1Arquitectura.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Modelo_de_Dominio.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Especificacion_de_Casos_de_Uso-Administracion_y_configuracion.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Especificacion_de_Casos_de_Uso-Proyectos.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Especificacion_de_Casos_de_Uso-Escenarios.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/5.1_Plan_de_pruebas.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/5.2_Rubrica_de_Evaluacion.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/poster.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/5.4_Informe_de_Resultados.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Resultados.xlsx

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Manual_Tecnico.pdf

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/UseCasePoints.xls

http://pegasus.javeriana.edu.co/~PA163-3-SIGPLAN/Docs/Motor_generador_de_escenarios.pdf


Página 92

13 REFERENCIAS

[1] K. Peffers, T. Tuure, M. Rothenberger y S. Chatterjee, «A Design Science Research Methodology

for Information Systems Research,» Journal of Management Information Systems, vol. 24 Issue 3,

nº 3, pp. 45-77, 2007-2008.

[2] L. Wallace y M. Keil, «Software project risks and their effect on outcomessoftware project risks

and their effect on outcomes,» Communicaions of the ACM, vol. 47, nº 4, p. 6, 2004.

[3] S. MaConnell, Desarrollo y Gestión de Proyectos Informáticos., McGraw-Hill, 1997.

[4] F. A. Amo, L. Martínez Normand y F. J. Segovia Pérez, Introducción A La Ingeniería Del

Software: Modelo De Desarrollo De Programas, Delta, 2005.

[5] S. Hastie y S. Wojewoda, «Info Q,» 04 10 2015. [En línea]. Available:

http://www.infoq.com/articles/standish-chaos-2015. [Último acceso: 25 01 2016].

[6] ITAC- IT Applications Consulting, «ITAC,» ITAC, [En línea]. Available:

http://www.itac.co/es/web/guest/quienes-somos. [Último acceso: 01 03 2016].

[7] M. M. Guerra, F. G. Ramos y M. D. Silva, «Methods and standars: Essentials tools in the

application of proyect managment,» Journal Technology, vol. 12, nº 2, pp. 11-23, 2013.

[8] B. Boehm, «Project Termination Doesn’t Equal Project Failure,» University of Southern

California, p. 3, 2000.

[9] D. C. Nimo Parra y J. E. Amaya Salaza, «Metaheuristics to solve the software project scheduling

problem,» IEEE, p. 10, 2012.

[10] R. E. Fairley, «Why the Vasa Sank: 10 Problems and Some Antidotes for Software Projects,»

IEEE Software, p. 8, 2003.

[11] J. J. Ahonen y T. Junttila, «A Case Study on Quality-Affecting Problems in Software Engineering

Projects,» IEEE International Conference on Software—Science, Technology & Engineering, p.

9, 2003.

[12] K. Hashim, «An Approach to Sharing Solutions to Software Project Management Problems,»

IEEE, p. 4, 2009.

[13] T. S. Mokoena y J. H. C. P. , «Triple constraint considerations in the management of construction

projects,» IEEE International Conference on Industrial Engineering and Engineering

Management, Bangkok, pp. pp. 813-817., 2013.

[14] R. Méndez Lozano, Formulación y evaluación de proyectos. Enfoque para emprendedores. 4a Ed.,

Bogotá D.C.: D´vinni Ltda, 2006.

[15] P. Lledó, Director de Proyectos, Victoria, BC, Canadá, 2013.

[16] Project Management Institute, Fundamentos para la dirección de proyectos- Guía del PMBOK,

Pensilvania: Project Management Institute, Inc, 2013.

[17] G. Maigua y E. López, Buenas Prácticas en la Dirección y Gestión de Proyectos Informáticos,

Argentina: Universidad Tecnológica Nacional – edUTecNe, 2012.

[18] F. REYES VILLAMIZAR, J. A. DUQUE DUQUE, N. P. CÁCERES VARGAS y N. C. SOTO

ECHEVERRY, «DESEMPEÑO DEL SECTOR SOFTWARE años 2012 - 2014,» Super

intedencia de Sociedades, Bogotá, 2015.

[19] S. J. Martínez Marín, S. Arango Aramburo y J. Robledo Velásquez, «THE GROWTH OF THE

COLOMBIAN SOFTWARE INDUSTRY: A SYSTEMIC ANALYSIS,» EIA.Esc.Ing.Antioq, vol.

12, nº 23, p. 12, 2015.


Página 93


[20] A. E. Salinas Duarte, «OBSTACULOS EN LA GESTIÓN DE PROYECTOS EN

TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN - TICs Y POSIBLES

SOLUCIONES,» Universidad Pontificia Bolivariana, Bucaramanga, 2007.

[21] I. D. Páez Anaya, «Estudio Empírico del Estado Actual de la Estimación de Software en Pymes

de Colombia,» Universidad EAFIT, 2012.

[22] E. N. Zabaleta, J. I. Igartua Lopez y N. Errasti Lozares, «Análisis de la Relación Existente entre

los Estándares de Gestión de Proyectos y los Factores Críticos para su Éxito,» Mechanical and

Manufacturing Department, Mondragon University, p. 8, 2012.

[23] K. C. Palomino Zuluaga, «ESTUDIO DEL COMPORTAMIENTO DE LA INDUSTRIA DEL

SOFTWARE EN COLOMBIA ANTE ESCENARIOS DE CAPACIDADES DE INNOVACION

Y VENTAJAS COMPARATIVAS POR MEDIO DE DINAMICA DE SISTEMAS,» Universidad

Nacional de Colombia, Bogotá D.C, 2011.

[24] S. E. Institute, CMMI® for Development, Version 1.3, Carnegie Mellon University, 2010.

[25] D. M. Vega, «MINTIC,» 25 03 2015. [En línea]. Available:

http://www.mintic.gov.co/portal/604/w3-article-8571.html. [Último acceso: 01 10 2016].

[26] C. J. V. Wyngaard, J.-H. P. y L. P. , «Theory of the triple constraint — A conceptual,» IEEE

International Conference on Industrial Engineering and Engineering Management (IEEM), p. 8,

2012.

[27] EL CONGRESO DE COLOMBIA, LEY 905 DE 2004, 2004.

[28] A. Hevner y S. Chatterjee, «Design Science Research in Information Systems,» C Springer

Science+Business Media, p. 15, 2010.

[29] G. Sánchez y J. Salvador, Ingeniería de proyectos informáticos: actividades y procedimientos.,

UNIVERSIDAD JAUME I. SERVICIO DE COMUNICACIÓN Y PUBLICACIONES, 2003.

[30] Departamento de Informática, «Plan de proyecto - Desarrollo de Sistemas de Información

Corporativos,» Universidad Carlos III de Madrid, [En línea]. Available:

http://ocw.uc3m.es/ingenieria-informatica/desarrollo-de-sistemas-de-informacion-corporativos-

1/documentos/plan-de-proyecto. [Último acceso: 28 02 2016].

[31] J.-g. Li y G.-y. T. , «Research on software development process evaluation method,» Software

Intelligence Technologies and Applications & International Conference on Frontiers of Internet

of Things, International Conference on, 2014.

[32] D. N. Wilson y M. J. Sifer, «Structured planning - project views,» Software Engineering Journal,

p. 7, 1988.

[33] H. Zang y B. K. , «Semi-Quantitative Simulation Modeling of Software Engineering Process,»

Springer, vol. 3966, pp. 242 - 2453, 2006.

[34] H. Z. B. K. y R. J. , «Planning Software Project Success with Semi-Quantitative Reasoning,»

Australian Software Engineering Conference IEEE, 2007.

[35] F. Bootsma, «How to Obtain Accurate Estimates in a Real-Time Environment,» Application-

Specific Systems and Software Engineering Technology, Proceedings. 3rd IEEE Symposium, pp.

105-112., 2000.

[36] S. A. A. F. S. y N. C. D. , «Estimating software effort and function point using regression, Support

Vector Machine and Artificial Neural Networks models,» Computer Systems and Applications

(AICCSA), IEEE/ACS 12th International Conference, pp. 1-8., 2015.

[37] S. M. Satapathy y B. P. Acharya, «Early stage software effort estimation using random forest

technique based on use case points,» IET Software IEEE, vol. 10, nº 1, pp. 10-17, 2016.


Página 94

[38] B. K. Park y S. Y. Moon, «Improving Use Case Point (UCP) Based on Function Point (FP)

Mechanism,» Platform Technology and Service (PlatCon), 2016 International Conference. IEEE,

pp. 1-5, 2016.

[39] A. Idri, A. H. y A. A. , «RBFN Networks-based Models for Estimating Software Development

Effort: A Cross-validation Study,» Computational Intelligence, IEEE Symposium Series, 2015.

[40] Normas ISO, «ISO/IEC 2503n – División de Requisitos de Calidad,» ISO - International

Organization for Standardization, 2015. [En línea]. Available:

http://iso25000.com/index.php/normas-iso-25000?limit=4&limitstart=0. [Último acceso: 11 10

2016].

[41] Ministerio de las Tecnologías de la Información y Comunicaciones de Colombia, «INFORME DE

CARACTERIZACIÓN DEL SECTOR DE SOFTWARE Y TECNOLOGÍAS DE LA

INFORMACIÓN EN COLOMBIA,» 2015.

[42] D. N. Wilson y M. J. Sifer, «Structured planning - deriving project views,» Software Engineering

Journal, p. 7, 1988.

[43] I. Flood, «project planning using an interactive, structured modeling environment,» Proceedings

of the 2007 Winter Simulation Conference, p. 9, 2007.

[44] H. Zhang, B. Kitchenham y R. Jeffery, «Planning Software Project Success with Semi-

Quantitative Reasoning,» Australian Software Engineering Conference (ASWEC'07) IEEE, p. 10,

2007.

[45] B. W. Boehm, «Software Engineering Economics,» IEEE, Vols. %1 de %2SE-10, nº 1, pp. 4-21,

1984.

[46] N. Merlo, «COCOMO - Constructive Cost Model,» Department of Computer Science - University

of Zurich, Zurich, 2003.

[47] Cesim, «Simulación para la Gestión de Proyectos,» [En línea]. Available:

http://www.cesim.com/es/simulaciones/cesim-project. [Último acceso: 20 01 2016].

[48] Community, «dotporject,» dotporject, [En línea]. Available: http://www.dotproject.net/index.php.

[Último acceso: 20 02 2016].

[49] D. A. Godoy, C. H. Kotyñski, E. A. Belloni, H. D. Santos y E. O. Sosa, «Modelo de Simulación

Dinámico de Proyectos de Desarrollo de Software con Scrum,» Centro de Investigación en

Tecnologías de la Información y Comunicaciones.

[50] L. B. Velasco, «Clasificación de los proyectos informáticos y establecimiento de sus EDT's,»

Universidad Abierta de Cataluña, Cataluña, 2004.

[51] T. G. Kasiak y D. A. Godoy, «Modelo Dinámico de Simulación para la Gestión de Proyectos de

Software Desarrollados con XP,» Centro de Investigación en Tecnología de la Información y

Comunicaciones.

[52] SCRUMstudy, Una guía para el conocimiento de Scrum (Guía SBOK™), Phoenix, Arizona 85008

USA: SCRUMstudy™, una marca de VMEdu, Inc., 2013.

[53] S. D. O. Vargas, «DIAGNÓSTICO PARA LA IMPLEMENTACIÓN DE HOJAS DE RUTA EN

LA CERTIFICACIÓN DE LA INDUSTRIA DESARROLLADORA DE SOFTWARE EN

CARTAGENA DE INDIAS,» UNIVERSIDAD DE CARTAGENA, Cartagena, 2013.

[54] F. Villareal, «Reingenieria de Procesos,» Universidad Nacional, 2011.

[55] C. B. d. S. Monteiro , D. S. Loubach y A. M. da Cunha, «Applying the Use Case Points effort

estimation technique to Avionics Systems,» IEEE/AIAA 27th Digital Avionics Systems

Conference, St. Paul, , pp. pp. 5.B.4-1-5.B.4-10, 2008.


Página 95


[56] T. B. «Software Cost Estimation With Use Case Points – Introduction,» tynerblain, 12 02 2007.

[En línea]. Available: http://tynerblain.com/blog/2007/02/12/software-cost-estimation-ucp-1/.

[Último acceso: 25 09 2016].

[57] Departamento de lenguajes y sistemas informáticos, «Planificación y Gestión de Proyectos

Informáticos,» Universidad de Sevilla, 2009. [En línea]. Available:

http://www.lsi.us.es/docencia/get.php?id=7191. [Último acceso: 01 02 2016].

[58] F. Bellas Permuy, «Introducción al Desarrollo de Aplicaciones Empresariales,» Departamento de

Tecnologías de la Información y las Comunicaciones (TIC), Coruña, 2005.

[59] A. Trellini, «Universidad Nacional del Sur,» Departamento de Ciencias e Ingeniería de la

Computación, 28 03 2014. [En línea]. Available:

http://www.cs.uns.edu.ar/~mfalappa/dae/downloads/Clases/Clase-01.pdf. [Último acceso: 25 04

2016].

[60] B. Rienzi, S. Grattarola y R. Sosa, «Sistemas de Información Geográficos Empresariales

(TSIGE),» Laboratorio de Integración de Sistemas, 2012.

[61] BUYTO, «Páginas web,» PAVI S.L., CIF B-84127109, [En línea]. Available:

http://www.buyto.es/general-diseno-web. [Último acceso: 05 06 2016].

[62] The Java EE Tutorial, Java Platform, Enterprise Edition, ORACLE, 2014.

[63] R. s. Pressman, Software Engineering A Practitioner's Approach Seven Edition, Mc Graw Hill,

2010.

[64] M. Carvajal y J. Saab, «Fundamentos conceptuales de las Directrices de Usabilidad de Gobierno

en línea,» Ministerio de las tecnologías de la información y las comunicaciones Colombia, 2010.

Generador de Escenarios de Planeación para la Gestión de ...

Documents

Transcript of Generador de Escenarios de Planeación para la Gestión de ...