PROPUESTA PARA TRABAJO DE GRADO
TÍTULO
Sistematización de la generación de presupuestos para proyectos de obras industriales.
MODALIDAD
Aplicación - Caso de Estudio: Inargos Ltda. - Empresa de consultoría (ingeniería mecánica, civil y eléctrica).
OBJETIVO GENERAL
Definir la arquitectura de software e implementar el prototipo funcional de un sistema que administre los materiales de tubería
asociados a un proyecto de ingeniería mecánica, con el fin de reducir los tiempos, en empresas pequeñas, relacionados con la
generación de presupuestos de obra.
ESTUDIANTE(S)
Camilo González González __________________________________________
Documento Celular Teléfono fijo Correo Javeriano
CC. 80'197'724 316-3011628 2569729 [email protected]
DIRECTOR
Ing. César Julio Bustacara Medina Ms.E _______________________________________________
Documento Celular Teléfono fijo Correo Javeriano Empresa donde trabaja y cargo
CC. 1234678 320-xxx-xxx 3208320 [email protected]; Pontificia Universidad Javeriana;
Director Departamento Ing. Sistemas
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
2
CONTENIDO
1 Problemática ......................................................................................................................................................... 4
1.1 Descripción de la problemática ........................................................................................................... 4
1.2 Formulación ................................................................................................................................................. 4
1.3 Justificación .................................................................................................................................................. 5
1.4 Impacto Esperado del proyecto ........................................................................................................... 6
1.4.1 Impacto a corto plazo ..................................................................................................................... 6
1.4.2 Impacto a largo plazo ..................................................................................................................... 6
2 Descripción del proyecto ................................................................................................................................. 7
2.1 Objetivo General ........................................................................................................................................ 7
2.2 Fases Metodológicas y objetivos específicos.................................................................................. 7
2.2.1 Fase Metodológica N°1: Inicio .................................................................................................... 7
2.2.2 Fase Metodológica N°2: Elaboración y Construcción ....................................................... 8
2.2.3 Fase Metodológica N° 3: Finalización ...................................................................................... 8
2.3 Entregables o resultados esperados .................................................................................................. 9
3 Proceso ................................................................................................................................................................. 10
3.1 Fase Metodológica N°1: Inicio ........................................................................................................... 10
3.1.1 Objetivo Específico: Detallar el contexto de negocio y comprender e identificar
los requerimientos asociados al sistema. ............................................................................................... 10
3.1.2 Objetivo Específico: Identificar los tiempos asociados a la generación de
presupuestos de tubería dentro del caso de estudio. ........................................................................ 11
3.2 Fase Metodológica N°2: Elaboración y construcción ............................................................... 11
3.2.1 Objetivo Específico: Diseñar la arquitectura de software de un sistema que
administre los materiales de tubería asociados a un proyecto de ingeniería mecánica. ... 11
3.2.2 Objetivo Específico: Implementar el prototipo funcional del sistema que
automatiza el conteo de materiales de tubería asociados a un proyecto de ingeniería
mecánica, con base en la arquitectura definida. .................................................................................. 11
3.3 Fase Metodológica N° 3: Finalización............................................................................................. 12
3.3.1 Objetivo Específico: Evaluar y medir los beneficios de tiempo asociados al
prototipo desarrollado ................................................................................................................................... 12
4 Gestión del proyecto ....................................................................................................................................... 13
4.1 Estimación Duración de las actividades del proyecto ............................................................. 13
4.2 Relación entre las actividades del proyecto ................................................................................ 13
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
3
4.3 Estimación del Costo del proyecto .................................................................................................. 14
4.4 Estimación de los riesgos del proyecto ......................................................................................... 15
5 Marco Teórico .................................................................................................................................................... 16
6 Referencias ......................................................................................................................................................... 18
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
4
1 PROBLEMÁTICA
1.1 DESCRIPCIÓN DE LA PROBLEMÁTICA
Es una realidad que la generación de presupuestos es una actividad que demanda mucho
tiempo y costos de diferentes tipos, pues estos son documentos de gran importancia que
afectan a todos los participantes de algún proyecto cualquiera. Existe gran dificultad en
empresas pequeñas para elaborar estos documentos de forma eficiente, por lo general este
trabajo toma más tiempo de lo necesario y además no concuerda ni es preciso con los costos
reales, lo cual conlleva a problemas de varios tipos. Ya sea por falta de interés, de conciencia o
de conocimiento, falta que las empresas pequeñas, apoyen todos los procesos de generación
de presupuestos con herramientas de software, que agilicen las tareas y ayuden a arrojar
resultados más precisos [50][51].
El caso de estudio, Inargos Ltda. es una empresa de consultoría que trabaja el área de
ingeniería mecánica, eléctrica y civil. Sus áreas de trabajo más importantes son el diseño y la
interventoría. Es una empresa que lleva más de 30 años participando de forma activa dentro
de la industria, y se han actualizado en conocimiento y temas técnicos propios de su área, pero
han dejado de lado temas administrativos y de sistematización. La actividad principal de
Inargos Ltda. es el diseño, y uno de los entregables de esa actividad es un documento robusto
que especifica el presupuesto del proyecto. Ese presupuesto indica de forma aproximada lo
que costaría en total algún proyecto específico a un cliente cualquiera. Estos documentos son
muy delicados, pues tratan temas de grandes cifras de dinero, los cuales afectan de forma
significativa las políticas y futuros empresariales de sus clientes. Desafortunadamente esta
actividad no está estandarizada ni sistematizada dentro de la compañía, al igual que en
muchas empresas similares. Inargos Ltda. tiene cierto software que apoya la generación de
estos presupuestos (como lo es Microsoft Excel), pero el proceso cuenta con varias
actividades manuales que entorpecen la generación de dicho entregable y lo convierte en una
actividad dispendiosa y vulnerable a errores. La intención es atacar esta problemática para
que la compañía transforme parcialmente sus costumbres de trabajo, mejore sus procesos de
negocio y se vuelva un poco más competitiva dentro de la industria.
1.2 FORMULACIÓN
¿Cómo se puede apoyar el proceso de generación de presupuestos dentro de proyectos de
ingeniería mecánica, mediante herramientas de software, de forma que se acople a los
proceso de negocio, políticas de alguna compañía y mejore los tiempos y costos asociados a
dicha actividad?
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
5
1.3 JUSTIFICACIÓN
Las empresas de diseño de ingeniería como Inargos Ltda. generan documentos de
presupuestos muy robustos y complejos. Dependiendo del tipo de proyecto, el presupuesto
asociado puede tener secciones de muchos tipos, como por ejemplo toda una sección de temas
mecánicos, civiles, eléctricos, de tubería, de tanques, de estructuras, y cada una de estas
puede tener sub-secciones. Ahora bien, generar estos presupuestos de forma exacta y precisa
puede llegar a ser todo un arte, pues depende de muchos factores como son la experiencia de
los ingenieros, el nivel de detalle, la calidad de los diseños de ingeniería, las herramientas
tecnológicas y el tiempo invertido para generar el presupuesto, entre otros. A muchas
empresas les puede interesar software que apoye la generación de presupuestos, software
que permita sistematizar ciertas actividades, las actividades que la empresa desee, y que
dependiendo del futuro y necesidades de la compañía, puedan agregarle funcionalidad y casos
de uso cuando sea prudente.
La sección de presupuestos que vale la pena apoyar en primera medida es la que está
relacionada con tuberías. El manejo de éstas y sus componentes requiere cuidado especial a la
hora de generar presupuestos, pues esta área involucra muchas referencias, características y
propiedades. Por ejemplo, las tuberías difieren según sus tipos de materiales, códigos y
estándares, componentes adicionales, y/o la manufactura e instalación. Por otro lado, existen
muchos tipos de sistemas en los que las tuberías pueden ser aplicadas, como lo son sistemas
de agua, de protección contra incendios, de petróleo, de gas, sistemas químicos o refinerías, de
refrigeración, de manejo de tóxicos, de lodos y residuos, de aguas lluvias, de plomería, etc. Es
un tema tan desarrollado que cuenta hasta con una carrera de Ingeniería de Tuberías. Ahora
bien, por su complejidad e importancia, es fundamental contar con software que apoye la
administración de toda esta sección, para facilitar el desarrollo de presupuestos que
involucren cifras, cantidades y propiedades de los mismos sistemas de tubería.
También es necesario que las compañías mejoren sus procesos de trabajo, todo con el fin que
se transformen en un grupo más eficiente y competitivo. Automatizando y sistematizando la
generación de presupuestos, estos documentos van a ser mucho más confiables, detallados y
precisos, lo cual es muy importante tanto para el cliente como para Inargos Ltda. como tal. Por
otro lado, actualmente la generación de presupuestos no es una actividad estándar y bien
definida en la compañía, depende mucho de las costumbres y prácticas personales de los
empleados, la generación de un sistema para colaborar en este campo ayuda a estandarizar
esta actividad y darle más rigor y disciplina, después de todo es una tarea bastante mecánica
pero que se ha vuelto muy complicada. Se espera que de esta forma los empleados de Inargos
Ltda. lleguen a ser más eficientes y productivos. Otra motivación es que alrededor del tema de
presupuestos hay más procesos de negocio relacionados y necesidades que el sistema podría
integrar o apoyarlos de una u otra forma.
Finalmente es importante mencionar que existen varias herramientas, dentro de toda la rama
de software enfocado a la administración de proyectos, que apoyan, entre otras actividades, la
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
6
generación de presupuestos; pero las empresas pequeñas no han adquirido dichos productos
porque tienen exceso de funcionalidad, que en gran medida no sería usado y tienen grandes
costos (justamente por todas sus características funcionales) los cuales la compañía no puede
darse el lujo de afrontar. Además como se mencionó en el punto anterior, se desea que la
tecnología se adapte a los procesos de negocio, y no al contrario, donde la compañía se ve
forzada por algún producto de software a modificar sustancialmente sus costumbres de
trabajo.
1.4 IMPACTO ESPERADO DEL PROYECTO
1.4.1 IMPACTO A CORTO PLAZO
Se espera que el caso de estudio, Inargos Ltda., integre dentro de sus actividades de trabajo el
software desarrollado al darse cuenta que en efecto el producto reduce de una forma u otra
los costos y tiempos asociados a la generación de presupuestos. Por otro lado se pretende que
el sistema sirva como una base para que en el futuro se le puedan agregar más módulos que
apoyen las actividades de empresa pequeña de ingeniería mecánica, civil y/o eléctrica.
1.4.2 IMPACTO A LARGO PLAZO
Finalmente todo el trabajo puede servir como base para iniciar una propuesta de trabajo más
formal y es probable que el producto le interese a muchas compañías, relacionadas con el
tema, que tengan escasos recursos para invertir en soluciones de software mucho más
complejas y con exceso de funcionalidad.
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
7
2 DESCRIPCIÓN DEL PROYECTO
2.1 OBJETIVO GENERAL
Definir la arquitectura de software e implementar el prototipo funcional de un sistema que
administre los materiales de tubería asociados a un proyecto de ingeniería mecánica, con el
fin de reducir los tiempos, en empresas pequeñas, relacionados con la generación de
presupuestos de obra.
2.2 FASES METODOLÓGICAS Y OBJETIVOS ESPECÍFICOS
A continuación se listan las fases metodológicas propuestas y se describen los objetivos
específicos ligados a cada una de ellas. El desglose de cada fase y la descripción de sus
actividades se detallarán en la siguiente sección.
2.2.1 FASE METODOLÓGICA N°1: INICIO
2.2.1.1 OBJETIVO ESPECÍFICO: DETALLAR EL CONTEXTO DE NEGOCIO Y COMPRENDER E IDENTIFICAR
LOS REQUERIMIENTOS ASOCIADOS AL SISTEMA.
En esta etapa se busca analizar y comprender a fondo el caso de estudio. El trabajo consiste en
realizar entrevistas con los diferentes empleados y auxiliares de Inargos Ltda. para
comprender de forma detallada y específica todas las actividades asociadas a la generación de
presupuestos. Se pretende modelar los procesos de negocio (asociados a la realización de
presupuestos) usando BPMN (Business Process Modeling Notation), pues es una notación
estándar que ayuda a administrar los procesos tanto para usuarios técnicos como para la alta
gerencia. Realizando esta actividad de forma rigurosa el trabajo futuro va a ser mucho más fiel
a la organización y se puede entregar un producto de mayor calidad [49]. Por último, se
levantarán los requerimientos, se estimarán los recursos necesarios y se definirá el alcance
del proyecto.
2.2.1.2 OBJETIVO ESPECÍFICO: IDENTIFICAR LOS TIEMPOS ASOCIADOS A LA GENERACIÓN DE
PRESUPUESTOS DE TUBERÍA DENTRO DEL CASO DE ESTUDIO.
En este objetivo se busca cuantificar realmente la problemática asociada a la generación de
presupuestos (sección tuberías) y todas sus actividades relacionadas. El objetivo es medir el
tiempo invertido de cada uno de los participantes dentro de la generación del presupuesto.
Este tiempo debe ser medido para diferentes tipos de proyectos: pequeños, medianos y
grandes. Se determinará un conjunto de pruebas y se definirá un plan de trabajo para llevar a
cabo éste estudio. Si no hay oportunidad de realizar las medidas sobre un proyecto real o un
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
8
proyecto que este en curso, se podrá hacer la simulación de las diferentes actividades para
obtener tiempos aproximados de trabajo.
2.2.2 FASE METODOLÓGICA N°2: ELABORACIÓN Y CONSTRUCCIÓN
2.2.2.1 OBJETIVO ESPECÍFICO: DISEÑAR LA ARQUITECTURA DE SOFTWARE DE UN SISTEMA QUE
ADMINISTRE LOS MATERIALES DE TUBERÍA ASOCIADOS A UN PROYECTO DE INGENIERÍA
MECÁNICA.
Después de una etapa de análisis el objetivo es realizar todo el diseño arquitectónico. Para ser
más claros, la administración de materiales de tubería se refiere al conteo de elementos por
tipos específicos, a conteos generales por subsistemas de algún proyecto, búsquedas de
materiales por criterios definidos, a la edición, agregación y eliminación de materiales y
subsistemas, etc. Por lo tanto se debe diseñar un sistema que permita cumplir con estos
requisitos. El objetivo principal del producto, es que automatice el conteo de todos estos
materiales, pues todos estos van a arrojar una cantidad total que más adelante se va a ver
reflejada en un documento de presupuestos.
2.2.2.2 OBJETIVO ESPECÍFICO: IMPLEMENTAR EL PROTOTIPO FUNCIONAL DEL SISTEMA QUE
AUTOMATIZA EL CONTEO DE MATERIALES DE TUBERÍA ASOCIADOS A UN PROYECTO DE
INGENIERÍA MECÁNICA, CON BASE EN LA ARQUITECTURA DEFINIDA.
Para lograr tener un prototipo de calidad se va a usar un modelo de desarrollo basado en
prototipos, que se va ir trabajando en paralelo, junto al diseño de la arquitectura de software.
Básicamente las actividades involucradas son: la identificación de requisitos que debe cumplir
el prototipo, diseñar e implementar dicho prototipo, utilizar el prototipo con el fin de realizar
pruebas de funcionamiento y aportar nuevas mejoras, para tener en cuenta en iteraciones
posteriores del desarrollo y el diseño.
2.2.3 FASE METODOLÓGICA N° 3: FINALIZACIÓN
2.2.3.1 OBJETIVO ESPECÍFICO: EVALUAR Y MEDIR LOS BENEFICIOS DE TIEMPO ASOCIADOS AL
PROTOTIPO DESARROLLADO
Se deben analizar las ventajas y desventajas del prototipo implementado, comparando las
actividades de Inargos Ltda., asociadas a la generación de presupuestos, con y sin el uso del
prototipo implementado. Para tal fin se definirá un nuevo plan de trabajo, que utilice los
mismos conjuntos de pruebas usados anteriormente, para obtener nuevos tiempos usando el
prototipo, y contrastarlos con los tiempos anteriores. Con estos nuevos resultados se podrán
comparar las dos actividades, documentar los beneficios y resumir las conclusiones del
trabajo de grado.
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
9
2.3 ENTREGABLES O RESULTADOS ESPERADOS
Memoria
Documentación de los procesos de negocio asociados a la
generación de presupuestos.
Documento de especificación de requerimientos de software.
Documento de visión
Documento de arquitectura
Prototipo implementado
Documento de diseño detallado
Documento de pruebas y beneficios
Documentación del software
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
10
3 PROCESO
Dado que es un proyecto de aplicación, se ha escogido "Rational Unified Process (RUP)" como
proceso de ingeniería de software, para tener tareas disciplinadas y entregables claros,
además esta metodología es ampliamente conocida en la industria y ya demostró ser exitosa
en muchos casos. Realmente RUP asigna responsabilidades dentro de una organización y
valora el trabajo en equipo, pero gracias a que el proceso es altamente configurable [48] y
tiene como objetivos acomodarse a diferentes organizaciones, solo se tomarán los elementos
de RUP que tengan sentido cuando el proyecto es desarrollado por una sola persona.
3.1 FASE METODOLÓGICA N°1: INICIO
3.1.1 OBJETIVO ESPECÍFICO: DETALLAR EL CONTEXTO DE NEGOCIO Y COMPRENDER E IDENTIFICAR
LOS REQUERIMIENTOS ASOCIADOS AL SISTEMA.
Las actividades de esta fase que ayudan a cumplir éste objetivo se detallan a continuación:
Actividad Descripción Resultado
Análisis del contexto de negocio El objetivo es comprender el negocio en el que se desenvuelve el caso de estudio y documentar las razones de su interés por mejorar las actividades asociadas a la generación de presupuestos.
Documento de análisis
Modelar los procesos de negocio asociados a actividades de generación de presupuestos.
Se desea comprender y modelar los procesos de negocio asociados a las actividades de generación de presupuestos usando BPMN.
Documentación de los procesos de negocio.
Generar documento de visión Aquí se especifican las características principales del sistema, el alcance del proyecto, los actores participantes, las restricciones, la terminología que se va a manejar y los atributos de calidad que debe tener el sistema.
Documento de visión y diagrama de casos de uso de contexto.
Levantamiento de los requerimientos
Es necesario describir los comportamientos deseados del prototipo a desarrollar. Aquí quedaran formalmente especificados tanto los requerimientos funcionales como los no-funcionales.
Documento de especificación de requerimientos de software.
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
11
3.1.2 OBJETIVO ESPECÍFICO: IDENTIFICAR LOS TIEMPOS ASOCIADOS A LA GENERACIÓN DE
PRESUPUESTOS DE TUBERÍA DENTRO DEL CASO DE ESTUDIO.
Las actividades de esta fase que ayudan a cumplir éste objetivo se detallan a continuación:
Actividad Descripción Resultado
Elaboración de plan de pruebas N°1 Se debe investigar y definir un plan de pruebas para calcular los tiempos que el caso de estudio está invirtiendo en la generación de presupuestos asociados a materiales de tubería.
Plan de pruebas N°1
Realización del plan de pruebas N°1 Al tener claro el plan de pruebas se debe recolectar un conjunto de datos y llevar a cabo las pruebas específicas.
Documento que resume los tiempos invertidos, del caso de estudio, en la generación de presupuestos de tubería .
3.2 FASE METODOLÓGICA N°2: ELABORACIÓN Y CONSTRUCCIÓN
3.2.1 OBJETIVO ESPECÍFICO: DISEÑAR LA ARQUITECTURA DE SOFTWARE DE UN SISTEMA QUE
ADMINISTRE LOS MATERIALES DE TUBERÍA ASOCIADOS A UN PROYECTO DE INGENIERÍA
MECÁNICA.
Las actividades de esta fase que ayudan a cumplir éste objetivo se detallan a continuación:
Actividad Descripción Resultado
Elaboración casos de uso Definir los casos de uso y refinar las características de los actores que participan en el sistema.
Diagrama de casos de uso
Realizar documento de arquitectura de software
Se debe diseñar la arquitectura de software usando una metodología basada en patrones. Posteriormente debe quedar claro el diseño detallado del prototipo funcional.
Documento de arquitectura de software.
Revisión incremental de los requerimientos
A medida que se desarrolla el diseño se debe hacer la trazabilidad de los requerimientos para asegurar que el diseño cumpla con los requisitos del sistema.
Requerimientos revisados
3.2.2 OBJETIVO ESPECÍFICO: IMPLEMENTAR EL PROTOTIPO FUNCIONAL DEL SISTEMA QUE
AUTOMATIZA EL CONTEO DE MATERIALES DE TUBERÍA ASOCIADOS A UN PROYECTO DE
INGENIERÍA MECÁNICA, CON BASE EN LA ARQUITECTURA DEFINIDA.
Las actividades de esta fase que ayudan a cumplir éste objetivo se detallan a continuación:
Actividad Descripción Resultado
Análisis incremental de prototipos Se deben definir, con base en la etapa formal de levantamiento de requerimientos, los requisitos que
Requisitos a cumplir en cada prototipo parcial.
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
12
debe cumplir cada prototipo. Se debe tener en cuenta la priorización de los requerimientos definida en el documento de especificación de requerimientos.
Diseño incremental prototipos Diseñar detalladamente cada prototipo parcial e ir refinando el diseño en cada iteración. Esta actividad también ayuda a reestructurar todo el diseño y arquitectura del sistema. Por otro lado se debe ir realizando el documento de diseño detallado hasta lograr un documento final.
Diseño prototipo parcial y documento diseño parcial.
Implementación incremental de prototipos
Implementar el diseño del prototipo parcial.
Prototipo parcial
Prueba de validación del prototipo parcial
Al tener claros los requisitos de cada prototipo y tener lista su implementación se deben realizar pruebas de su funcionamiento, documentarlas y tener en cuenta los resultados para futuras iteraciones del desarrollo basado en prototipos.
Resultados de la prueba del prototipo
3.3 FASE METODOLÓGICA N° 3: FINALIZACIÓN
3.3.1 OBJETIVO ESPECÍFICO: EVALUAR Y MEDIR LOS BENEFICIOS DE TIEMPO ASOCIADOS AL
PROTOTIPO DESARROLLADO
Las actividades de esta fase que ayudan a cumplir éste objetivo se detallan a continuación:
Actividad Descripción Resultado
Elaboración de plan de pruebas N°2 Se definirá un nuevo plan de trabajo, que utilice los mismos conjuntos de pruebas usados anteriormente en el plan N°1, para obtener nuevos tiempos de generación de presupuestos de tubería, usando el prototipo, y contrastarlos con los tiempos anteriores.
Plan de pruebas N°2.
Realización del plan de pruebas N°2 Se deben realizar las pruebas usando el prototipo y documentar los resultados y nuevos tiempos obtenidos.
Documento que resume los tiempos invertidos, del caso de estudio, en la generación de presupuestos de tubería al usar el prototipo desarrollado
Comparación resultados obtenidos. Al tener los resultados de los dos tipos de pruebas, se deben comparar y documentar las ventajas y desventajas de cada uno.
Documento que compara las dos aproximaciones para realizar presupuestos de tubería: Sin la ayuda del prototipo y con la ayuda del prototipo.
Conclusiones del proyecto Es necesario recolectar y detallar las conclusiones que se obtuvieron a lo largo de todo el trabajo y ciclo de vida del proyecto.
Conclusiones del proyecto
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
13
4 GESTIÓN DEL PROYECTO
4.1 ESTIMACIÓN DURACIÓN DE LAS ACTIVIDADES DEL PROYECTO
4.2 RELACIÓN ENTRE LAS ACTIVIDADES DEL PROYECTO
A continuación se muestra una gráfica que indica las relaciones entres las actividades del
proyecto. Cada fase está representada con un color específico, sus actividades tienen los
identificadores definidos en el punto anterior y la ruta crítica se señala con las banderas rojas.
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
14
Al tener clara la ruta crítica, se le debe prestar principal importancia a las actividades que la
componen. Cada tarea tiene un inicio y un fin programado, pero a lo largo del desarrollo de la
propuesta, existe la posibilidad que los tiempos se modifiquen, produciendo unos inicios y
fines de trabajo reales. La idea es que esta relación de actividades ayude a gestionar el
proyecto y cumplir con todos objetivos. (La actividad de conclusiones del proyecto no se
muestra en el gráfico).
Ya entrando en detalle, se trabajaran los días hábiles de la semana, cada día alrededor de 6 a 8
horas (repartiendo ese tiempo entre las actividades asociadas a cada día, dependiendo de sus
prioridades y esfuerzo que involucran). Finalmente, se programaran reuniones semanales con
el Director para revisar los trabajos
4.3 ESTIMACIÓN DEL COSTO DEL PROYECTO
A continuación se muestran costos aproximados por tema. Hay que tener el cuenta que el
tiempo aproximado de trabajo total de todo el proyecto suma 17 semanas (en cada una se
trabajará los cinco días hábiles, alrededor de 5 horas cada día).
Tabla Presupuesto (miles de pesos)
Rubros PUJ Camilo González González Inargos
Ltda Total
Personal 2700 8500 10000 21200
Equipo 0,0 0.0 3000 3000
Equipo propio uso 0,0 1000 0.0 1000
Software 0,0 180 500 680
Impresión 500 300 300 1100
Transporte 0,0 600 0.0 600
Material bibliográfico 500 300 0.0 800
Publicaciones y Patentes 0,0 0,0 0.0 0,0
Servicios técnicos 0,0 0,0 0.0 0,0
Seguros 0,0 0,0 0.0 0,0
Administración 0,0 500 0.0 500
Evaluación y seguimiento 0,0 0,0 0.0 0,0
Total $3,700 $11,380 $13,800 $28,880
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
15
4.4 ESTIMACIÓN DE LOS RIESGOS DEL PROYECTO
Al igual que todos los proyectos, este también tiene riesgos involucrados, que pueden afectar
y comprometer los objetivos. Es necesario estar consciente que estos riesgos existen, y que se
debe estar preparado para mitigarlos. A continuación se listan los riegos de acuerdo a su
prioridad:
Tabla posibles riesgos del proyecto
Nombre riesgo
Problemas con la planeación, las actividades y el tiempo asociado a cada una
Falta de cooperación del caso de estudio
Incumplir el cronograma por problemas técnicos
Falta de tiempo por motivos personales
Rechazo de la propuesta
Para mitigar los riesgos (solo los cuales podemos controlar de una u otra forma) se debe
seguir un plan de control riguroso del cronograma. A continuación se describe brevemente:
Plan de mitigación de riesgos
Objetivos Monitorear y controlar el desarrollo y cumplimiento de las actividades.
Responsables Director de tesis y estudiante.
¿Cómo?
Realizando reuniones para revisar el porcentaje de desarrollo de cada actividad y compararlo con lo propuesto en el cronograma y en la gestión del proyecto.
¿Cuándo? Reunión semanal del director de tesis y el estudiante.
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
16
5 MARCO TEÓRICO
[0] Mohinder L. Nayyar, "Piping Handbook", Sixth Edition, McGraw Hill, 1992. [1] S. S. Adel Torkaman Rahmani, Vahid Rafe and A. Abbaspour, “An mda-based modeling and design of service oriented architecture,”Iran University of Science and Technology, p. 8, 2006. [2] G. D. Alexander Grosskopf, The Process: Business Process Modeling using BPMN. Meghan Kiffer Press, 2009. [3] T. Allweyer, BPMN 2.0. BoD, 2010. [4] Y. H. Amnon H. Eden and R. Kazman, “Abstraction classes is software design,” Department of Computer Science, University of Essex, vol. 3, p. 53, 2006. [5] M. Barbacci, Quality Attributes. Software Engineering Institute Carnegie Mellon University, 1995. [6] H. Benbya, “Toward a complexity theory of information systems development,” UCLA Anderson School of Management, p. 23. [7] S. Brookson, Essential Managers: Managing Budgets. Dk Adult, 2000. [8] D. S. Buschmann, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Volume 2. Wiley, 2000. [9] F. Buschmann, Pattern-Oriented Software Architecture: A System of Patterns. Wiley, 2001. [10] F. Buschmann, “Building software with patterns,” Siemens AG, vol. 1, p. 58, 1999. [11] P. C. Clements, “A survey of architecture description languages,”Eighth International Workshop on Software Specification and Design, Germany., vol. 1, p. 10, 1996.1 [12] P. C. C. D. L. Parnas and D. M. Weiss, “The modular structure of complex systems,” [13] S. K. . E. Dunbar, Budgeting for Managers. McGraw-Hill, 2003. [14] S. Elliot and P. Melhuish, “A methodology for the evaluation of it strategic implementation,” Journal of Information Technology, p. selliot, 1995. [15] M. Fowler, Analysis Patterns: Reusable Object Models. [16] D. C. S. Frank Buschmann, Kevlin Henney, Pattern-Oriented Software Architecture: On Patterns and Pattern Languages. Wiley, 2007. [17] D. S. Frank Buschmann, Kevlin Henney, Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing. Wiley, 2007. [18] D. Garlan, “Software architecture,” School of Computer Science, Carnegie Mellon University. [19] D. Garlan and M. Shaw, “An introduction to software architecture, ”School of Computer Science - Carnegie Mellon University, vol. 1, p. 42, 1994. [20] I. Graham, Business Rules Management and Service Oriented Architecture: A Pattern Language. Wiley, 2006. [21] M. Grand, Patterns in Java. Wiley Computer Publishing, 1999. [22] R. A. Gregory Abowd and D. Garlan, “Using style to understand descriptions of software architecture,” Computer Science Department Carnegie Mellon University. [23] R. A. Gregory Abowd and D. Garlan, “Formalizing style to understand descriptions of software architecture,” Carnegie Mellon University, vol. 1, p. 29, 1994. 2 [24] R. A. Gregory Abowd and D. Garlan, “Using style to understand descriptions of software architecture,” Carnegie Mellon University, vol. 1, p. 12, 1993. [25] I. S. Group, “Introduction to bpmn,” tech. rep., IBM, 2006. [26] P. Hruby, Model-Driven Design Using Business Patterns. Springer, 2006. [27] L. B.-D. Ian Alexander, Discovering Requirements: How to Specify Products and Services. Wiley, 2009. [28] J. N. John Jeston, Business Process Management. Butterworth- Heinemann, 2008. [29] R. M. N. P. . L. C. Jon Pyke, Keith D. Swenson, 2010 BPM and Workflow Handbook, Spotlight on Business Intelligence. Layna Fisher, 2010.
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
17
[30] R. Kazman, “Software architecture,” Software Engineering Institute,Carnegie Mellon University. [31] M. Kircher and P. Jain, Pattern-Oriented Software Architecture: Patterns for Resource Management, Volume 3. Wiley, 2004. [32] P. Kuchana, Software Architecture Design Patterns in Java. Auerbach Publications, 2004. [33] V. Lakshminarayanan, “Software architects in practice,” [34] A. van Lamsweerde, Requirements Engineering. Wiley, 2009. [35] J. Lee, “Software architecture evaluation methods based on cost benefit analysis and quantitative decision making,” p. 23, 2008. [36] F. Losavio, L. Chirinos, N. Lévy, and A. Ramdane-Cherif, “Quality characteristics for software architecture,” JOURNAL OF OBJECT TECHNOLOGY, vol. 2, p. 18, 2003. 3 [37] B. B. Marie desJardins, “Integrating top-down planning with a bottom-up approach that learns to locally combine actions,” University of Maryland Baltimore County, p. 2. [38] L. B. J. C. M. B. Mark H. Klein, Rick Kazman and H. Lipson, “Attribute-based architecture styles,” Software Engineering Institute - Carnegie Mellon University, vol. 1, p. 20. [39] R. C. Martin, “Design principles and design patterns,” Robert C. Martin, vol. 1, p. 34, 2000. [40] F. L. N. Lévy, “Pattern-based architectural design process model,” International Conference on Computer Systems and Technologies, 2004. [41] R. Rachlin, Total Business Budgeting: A Step-by-Step Guide with Forms. Wiley, 1999 [42] M. Scheldbaur, The Art of Business Process Modeling: The Business Analyst’s Guide to Process Modeling with UML & BPMN. CreateSpace, 2010. [43] H. B. School, Preparing a Budget: Expert Solutions to Everyday Challenges. Harvard Business School Press, 2009. [44] B. Silver, BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0. Cody-Cassidy Press, 2009. [45] D. M. Stephen White, BPMN Modeling and Reference Guide. Future Strategies Inc, 2008. [46] R. G. Tom Debevoise, The Microguide to Process Modeling in BPMN. BookSurge Publishing, 2008. [47] K. E. Wiegers, Software Requirements. Microsoft Press, 2003.
Pontificia Universidad Javeriana - Ingeniería de Sistemas Propuesta para trabajo de grado - Aplicación
18
6 REFERENCIAS
[48] R. S. D. Company, “Rational unified process: Best process for software development,”
Rational Software White Paper, vol. 1, p. 21, 2001.
[49] M. Havey, Essential Business Process Modeling. O’Reilly, 2005.
[50] R. C. y Nápoles, Presupuestos: Teoría y práctica. McGraw Hill, 2008.
[51] M. W. Turban, Leidner, Information Technology for Management. John Wiley & Sons Inc.,
2007.