Propuesta para trabajo de grado - aplicaciónpegasus.javeriana.edu.co/~CIS1130IS10/data/propuesta.pdf · asociados a un proyecto de ingeniería mecánica, con el fin de ... Propuesta

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

mailto:[email protected]

mailto:[email protected]

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


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


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?


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


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.


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


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.


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


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.


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.



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.



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.



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.


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



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


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.


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


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.


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.


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.


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.

Documents

Propuesta para trabajo de grado - aplicaciónpegasus.javeriana.edu.co/~CIS1130IS10/data/propuesta.pdf · asociados a un proyecto de ingeniería mecánica, con el fin de ... Propuesta