MÉTODO PARA EL DESARROLLO DE HERRAMIENTAS … · zacatecas, zac. 12 dic 2017 mÉtodo para el...

Zacatecas, Zac. 12 Dic 2017

MÉTODO PARA EL DESARROLLO DE

HERRAMIENTAS ENFOCADAS EN FACILITAR LA

IMPLEMENTACIÓN DE BUENAS PRÁCTICAS DE

DESARROLLO DE SOFTWARE EN PYMES

T E S I S Que para obtener el grado de

Maestro en Ciencias con Orientación en

Ingeniería de Software

Presenta

Yolanda Meredith García Molina

Director de Tesis:

Dra. Mirna Ariadna Muñoz Mata

II

Agradecimientos

Me gustaría expresar el más profundo y sincero agradecimiento a todas las personas que

fueron de gran apoyo para realizar mis estudios de maestría así como el desarrollo de mi tesis.

A Dios, infinitas gracias porque sin él nada sería posible.

A mis padres por su valioso apoyo al cuidar de mis hijas así como estar conmigo en los

momentos más hermosos al igual que en los más difíciles.

A mi esposo Juan Manuel por estar a mi lado y apoyarme y acompañarme en los momentos

más difíciles y no dejarme renunciar a mis sueños.

A mis hijas Paola y Arantza, por ser el motor que me impulsa a salir adelante día a día.

Al Consejo Nacional de Ciencia y Tecnología (CONACYT) por su apoyo a través de la beca

para realizar los estudios de maestría.

A la Dra. Mirna Muñoz, mi tutora y directora de tesis, le hago un reconocimiento especial por

su gran ayuda y colaboración a lo largo de la maestría así como por darme consejos y guía

para el desarrollo de la tesis.

Al Dr. Jezreel Mejía, por su apoyo y colaboración invaluables recibidos a lo largo de la

maestría.

Al Centro de Investigación en Matemáticas Unidad Zacatecas por permitir a una servidora

ingresar a la maestría y siempre tener disposición para apoyar en lo que se necesitara, en

especial al Mtro. José Guadalupe Hernández.

Al Instituto Tecnológico Superior Zacatecas Norte por su invaluable apoyo al permitir a una

servidora estudiar la maestría para superarse profesionalmente y ser una mejor persona cada

día.

A todos ellos, infinitas gracias.

III

Abstract

Nowaday, SMEs face difficulties implementing best practices contained in standards

and models internationally accepted, because they lack of economic resources, human

resources, skills, tools and techniques focused on the application of best practices. Besides, to

apply the best practices provided by these models and estandards, the SMEs require adapt

those practices according to their size and type of business.

This thesis aims to provide a method for the development of tools focused on making

easily the implementation of best practices, so that it supports the SMEs in the selection of

techniques and tools that best tie to their enviroment and that encourage them to the use of

best practices contained in the existing models and standards.

It is important to highlighth that the application of best practices will be through a set

of agile and traditional techniques in the project management of software development,

considering the areas of risk management, project planning, as well project monitoring and

control.

Keywords: techniques and tools, project management, risk management, project

planning, project monitoring and control, catalog of best practices, SMEs.

IV

Resumen

Hoy en día, las pymes enfrentan dificultades para implementar buenas prácticas

contenidas en los estándares y modelos internacionalmente aceptados, debido a que carecen

de recursos económicos, de personal, capacidades, técnicas y herramientas enfocadas en la

aplicación de buenas prácticas. Además, para aplicar las buenas prácticas contenidas en

dichos modelos o estándares, las pymes requieren adaptarlos según su tamaño y tipo de

negocio.

El objetivo de esta tesis es proponer un método para el desarrollo de herramientas

enfocadas en facilitar la implementación de buenas prácticas que apoyen a las pymes en la

selección de técnicas y herramientas adecuadas a su entorno y que impulsen el uso de buenas

prácticas contenidos en los modelos y estándares existentes.

Cabe resaltar que la aplicación de buenas prácticas será a través de un conjunto de

técnicas ágiles y tradicionales en la gestión de proyectos de desarrollo de software,

considerando las áreas de gestión de riesgos, planificación del proyecto, así como

monitorización y control del proyecto.

Palabras clave: técnicas y herramientas, gestión de proyectos, gestión de riesgos,

planificación del proyecto, monitorización y control del proyecto, catálogo de buenas

prácticas, pymes.

V

Índice

Abstract .............................................................................................................................................. iii

Resumen ..............................................................................................................................................iv

Introducción ......................................................................................................................................... 1

Capítulo 1. Antecedentes ................................................................................................................. 4

1.1. Marco teórico ......................................................................................................................... 4

1.1.1. Gestión de proyectos ...................................................................................................... 4

1.1.1.1. Planificación del Proyecto ...................................................................................... 5

1.1.1.2. Monitorización y Control del Proyecto................................................................... 5

1.1.2. Gestión de riesgos .......................................................................................................... 6

1.2. Planteamiento del problema ................................................................................................... 7

1.3. Objetivos ................................................................................................................................ 8

1.3.1. Objetivo General ............................................................................................................ 8

1.3.2. Objetivos específicos...................................................................................................... 8

1.4. Hipótesis ................................................................................................................................ 8

1.5. Justificación ........................................................................................................................... 8

Capítulo 2. Estado del arte ............................................................................................................ 10

2.1. Revisión sistemática en la planificación y monitorización y control de proyectos ............... 10

2.1.1. Diagrama del método de revisión sistemática .............................................................. 10

2.1.2. Planificación de la revisión sistemática ........................................................................ 11

2.1.2.1. Identificación de la necesidad de la revisión ........................................................ 11

2.1.2.2. Formulación de la pregunta .................................................................................. 11

2.1.2.3. Cadenas de búsqueda ............................................................................................ 12

2.1.2.4. Selección de Fuentes de datos .............................................................................. 12

2.1.3. Ejecución de la revisión sistemática ............................................................................. 13

2.1.3.1. Selección de estudios primarios............................................................................ 13

2.3.1.1. Los criterios de inclusión para la selección de estudios son: ................................ 13

2.3.1.2. Los criterios para excluir los estudios son: ........................................................... 13

2.3.1.3. Procedimiento de selección de estudios primarios ............................................... 13

Evaluación de calidad de Estudios........................................................................ 14 2.3.1.3.1.

2.1.3.2. Extracción de información.................................................................................... 14

2.1.4. Reporte de resultados ................................................................................................... 16

VI

2.1.5. Hallazgos de la revisión sistemática ............................................................................. 17

2.1.5.1. Técnicas de planificación más utilizadas .............................................................. 17

2.1.5.2. Técnicas de monitorización y control de proyectos más utilizadas ....................... 18

2.1.5.3. Técnicas ágiles de planificación y monitorización y control de proyectos ........... 19

2.1.5.4. Herramientas de gestión, monitorización y control de proyectos ........................ 20

2.2. Búsqueda de técnicas y herramientas en el área de Gestión de Riesgos ............................... 21

2.3. Trabajos relacionados........................................................................................................... 23

2.3.1. Gestión de riesgos ........................................................................................................ 23

2.3.2. Gestión de proyectos .................................................................................................... 25

2.3.3. Clasificación de trabajos relacionados .......................................................................... 28

2.5. Modelos de ciclo de vida del software ................................................................................. 31

2.5.1. Construcción de prototipos ........................................................................................... 31

2.5.1.1. Descripción .......................................................................................................... 31

2.5.1.2. Características ...................................................................................................... 31

2.5.1.3. Descripción de etapas ........................................................................................... 32

2.5.1.4. Esquema de etapas................................................................................................ 32

2.5.3. El modelo espiral.......................................................................................................... 33

2.5.3.1. Descripción .......................................................................................................... 33


2.5.3.3. Descripción de etapas ........................................................................................... 33

2.5.3.1. Esquema de etapas................................................................................................ 34

2.5.4. Análisis del modelo de construcción de prototipos y modelo espiral ........................... 34

2.6. Selección de Tecnología ...................................................................................................... 36

2.6.1. Frameworks de desarrollo Web .................................................................................... 36

2.6.2. Análisis de frameworks de desarrollo web ................................................................... 36

2.6.3. Framework Django ....................................................................................................... 37


2.6.3.2. Funcionamiento .................................................................................................... 37

Capítulo 3. Metodología para el desarrollo de la tesis................................................................. 40

Capítulo 4. Propuesta del Método para el desarrollo de herramientas enfocadas en facilitar la

implementación de buenas prácticas de desarrollo de software en pymes .................................... 42

4.1. Desarrollo del método .......................................................................................................... 42

Capítulo 5. Validación del método ............................................................................................... 46

VII

5.1. Implementación del método en tres áreas ............................................................................. 46

5.1.1. Gestión de Riesgos ....................................................................................................... 46

5.1.1.1. Hallazgos de la trazabilidad de Gestión de Riesgos .............................................. 51

5.1.2. Planificación del Proyecto, Monitorización y Control del Proyecto ............................. 55

5.1.2.1. Hallazgos de la trazabilidad de las áreas de Planificación del Proyecto y

Monitorización y Control del Proyecto .................................................................................... 68

5.2. Desarrollo de una herramienta que facilita la implementación del método propuesto para el

área de Gestión de Riesgos .............................................................................................................. 75

5.2.1. Elementos que contiene la herramienta de gestión de Riesgos RiskSys que facilita la

implementación de buenas prácticas de ingeniería de software.................................................... 75

5.2.2. Análisis ........................................................................................................................ 76

5.2.2.1. Comunicación con el cliente................................................................................. 76

5.2.2.2. Planificación ......................................................................................................... 76

5.2.3. Diseño .......................................................................................................................... 81

5.2.3.1. Ingeniería ............................................................................................................. 81

5.2.3.2. Estructuración general de la herramienta .............................................................. 81

5.2.4. Desarrollo ..................................................................................................................... 88

5.2.4.1. Construcción ........................................................................................................ 88

5.2.5. Implementación ............................................................................................................ 89

5.2.5.1. Evaluación del cliente .......................................................................................... 89

Capítulo 6. Resultados ................................................................................................................... 96

6.1. Caso de estudio para validación de herramienta de gestión de riesgos RiskSys ................... 96

6.1.1. Diseño y planificación del caso de estudio ................................................................... 98

6.1.1.1. Objetivo del caso de estudio ................................................................................. 98

6.1.1.2. Objeto de estudio .................................................................................................. 98

6.1.1.3. Marco de referencia .............................................................................................. 98

6.1.1.4. Preguntas de investigación ................................................................................... 99

6.1.1.5. Métodos para la recogida de datos ........................................................................ 99

6.1.2. Preparación de la recogida de datos............................................................................ 100

6.1.2.1. Diseño del cuestionario ...................................................................................... 100

6.1.3. Recogida de datos ...................................................................................................... 101

6.1.4. Análisis de los datos recogidos ................................................................................... 103

6.1.4.1. Caso de estudio de la Empresa A ...................................................................... 103

VIII

6.1.4.2. Caso de estudio de la Empresa B ....................................................................... 111

6.1.5. Informe de resultados ................................................................................................. 118

Capítulo 7. Conclusiones ............................................................................................................. 120

7.1. Conclusiones ...................................................................................................................... 120

7.2. Trabajo futuro .................................................................................................................... 120

7.3. Logros académicos ............................................................................................................. 122

7.3.1. Productos académicos ................................................................................................ 122

7.3.2. Ponencias en congresos .............................................................................................. 123

Referencias ....................................................................................................................................... 124

Anexo I Información de EP sobre Planificación y Monitorización y Control de Proyectos ....... 128

Anexo II Diseño de la herramienta RiskSys ........................................................................................i

Anexo III Funcionalidad principal de la herramienta RiskSys .......................................................vi

1) Iniciar sesión .........................................................................................................................vi

2) Página Principal RiskSys .................................................................................................... vii

3) Cerrar sesión ....................................................................................................................... vii

5) Editar cuenta ...................................................................................................................... viii

6) Modificar contraseña .............................................................................................................ix

7) Catálogo de Riesgos ..............................................................................................................xi

8) Gestión de Catálogo de Riesgos .......................................................................................... xiv

10) Gestión de riesgos de manera individual ......................................................................... xvi

12) Gestion de Riesgos en equipo ...................................................................................... xviii

13) Tratamiento de riesgos por proyecto ............................................................................... xix

14) Mostrar gráfica ................................................................................................................ xix

16) Establecer estrategia ........................................................................................................ xxi

18) Empresa ........................................................................................................................ xxii

19) Proyectos ....................................................................................................................... xxiv

20) Categorías de Probabilidad ............................................................................................ xxvi

21) Categorías de Impacto ................................................................................................ xxviii

22) Última evaluación de riesgos ........................................................................................ xxxi

23) Acerca de .....................................................................................................................xxxii

IX

Índice de Figuras

Figura 1. Método de Revisión Sistemática ........................................................................................... 10

Figura 2. Procedimiento de selección de estudios ................................................................................ 13

Figura 3. Técnicas de planificación...................................................................................................... 17

Figura 4. Técnicas de monitorización y control del proyecto ............................................................... 18

Figura 5. Técnicas ágiles de planificación y monitorización y control de proyectos ............................ 19

Figura 6. Herramientas de gestión, monitorización y control de proyectos .......................................... 20

Figura 7. Diagrama del modelo de construcción de prototipos (Pressman, 2010) ................................ 32

Figura 8. Diagrama del modelo espiral (Pressman, 2010) .................................................................... 34

Figura 9. Funcionamiento del Framework Django ............................................................................... 37

Figura 10. Metodología de desarrollo de la tesis .................................................................................. 40

Figura 11. Diagrama del método .......................................................................................................... 42

Figura 12. Vista lógica de RiskSys ...................................................................................................... 82

Figura 13. Diagrama de despliegue de RiskSys ................................................................................... 83

Figura 14. Diagrama de clases de RiskSys ........................................................................................... 84

Figura 15. Modelo de BD de RiskSys .................................................................................................. 85

Figura 16. Diagrama de secuencia identificar riesgos .......................................................................... 86

Figura 17. Diagrama de secuencia evaluar riesgos ............................................................................... 86

Figura 18. Diagrama de secuencia de realizar gestión de riesgos ......................................................... 87

Figura 19. Manual de Usuario Colaborador ......................................................................................... 88

Figura 20. Manual de Líder de Proceso ............................................................................................... 88

Figura 21. Manual de Administrador ................................................................................................... 88

Figura 22. Video demostrativo de herramienta .................................................................................... 88

Figura 23. Diagrama de Tipos de usuarios de RiskSys ........................................................................ 89

Figura 24. Selección de proyecto para conformar catálogo de riesgos ................................................. 90

Figura 25. Gestión de Catálogo de Riesgos para el proyecto seleccionado .......................................... 90

Figura 26. Selección de proyecto para iniciar evaluación de riesgos individual................................... 91

Figura 27. Selección de riesgos individual ........................................................................................... 91

Figura 28. Identificación, establecimiento de parámetros y evaluación de riesgos individual ............. 92

Figura 29. Pantalla de Gestión de Riesgos en Equipo .......................................................................... 93

Figura 30. Mensaje de nueva iteración ................................................................................................. 93

Figura 31. Selección de proyecto para ver gráfico ............................................................................... 93

Figura 32. Gráfica de riesgos por proyecto .......................................................................................... 94

Figura 33. Selección de proyecto para tratamiento de riesgos .............................................................. 95

Figura 34. Reporte de Tratamiento de riesgos por proyecto ................................................................. 95

Figura 35. Pasos para implementar un caso de estudio. ....................................................................... 97

Figura 36. Diagrama de descripción de pasos para recogida de datos ................................................ 102

Figura 37. Respuestas de pregunta 1 de Empresa A ........................................................................... 104

Figura 38. Respuestas de importancia de pregunta 1 de Empresa A .................................................. 104


X










Figura 49. Respuestas de pregunta 1 de Empresa B ........................................................................... 111

Figura 50. Respuestas de importancia de pregunta 1 de Empresa B .................................................. 112











Figura 61. Diagrama de implementación del catálogo ....................................................................... 122

XI

Índice de Tablas

Tabla 1. Palabras clave y sinónimos .................................................................................................... 11

Tabla 2. Cadenas de búsqueda ............................................................................................................. 12

Tabla 3. Resultados de búsquedas lanzadas ......................................................................................... 14

Tabla 4. Listado de estudios primarios ................................................................................................. 14

Tabla 5. Información de EP sobre Planificación y Monitorización y Control de Proyectos ................. 16

Tabla 6. Listado de técnicas/herramientas del área de Gestión de Riesgos .......................................... 21

Tabla 7. Trabajos relacionados de la Gestión de riesgos y características que cubren ......................... 28

Tabla 8. Trabajos relacionados de Planificación, Monitorización y Control del Proyecto ................... 29

Tabla 9. Descripción de etapas del modelo de construcción de prototipos ........................................... 32

Tabla 10. Descripción de etapas del modelo espiral............................................................................. 33

Tabla 11. Análisis de características de los modelos de construcción de prototipos y espiral .............. 34

Tabla 12. Comparativa entre Django y Ruby On Rails ........................................................................ 36

Tabla 13. Listado de técnicas/herramientas del área de Gestión de Riesgos ........................................ 47

Tabla 14. Clasificación por enfoque de técnicas/herramientas del área de Gestión de Riesgos ........... 48

Tabla 15. Clasificación por nivel de dificultad de técnicas/herramientas del área de Gestión de Riesgos

............................................................................................................................................................. 49

Tabla 16. Trazabilidad entre prácticas específicas de CMMI y técnicas y herramientas del área Gestión

de Riesgos ............................................................................................................................................ 54

Tabla 17. Listado de técnicas y herramientas del área de Planificación del Proyecto .......................... 55

Tabla 18. Listado de técnicas y herramientas del área de Monitorización y Control del Proyecto ....... 58

Tabla 19. Clasificación de técnicas y herramientas del área de Planificación del Proyecto por enfoque

............................................................................................................................................................. 59

Tabla 20. Clasificación de técnicas y herramientas del área de Monitorización y Control del Proyecto

por enfoque .......................................................................................................................................... 61

Tabla 21. Clasificación de técnicas y herramientas del área de Planificación del Proyecto por nivel de

dificultad .............................................................................................................................................. 63

Tabla 22. Clasificación de técnicas y herramientas del área de Monitorización y Control del Proyecto

por nivel de dificultad .......................................................................................................................... 65

Tabla 23. Trazabilidad entre prácticas específicas de CMMI y técnicas y herramientas del área de

Planificación del Proyecto (parte 1 de 3) ............................................................................................. 71






Monitorización y Control del Proyecto ................................................................................................ 74

Tabla 27. Restricciones ........................................................................................................................ 77

Tabla 28. Listado de Requisitos funcionales para herramienta de gestión de riesgos RiskSys ............. 78

Tabla 29. Riesgos de negocio del proyecto .......................................................................................... 79

Tabla 30. Conceptos de diseño elegidos .............................................................................................. 81

XII

Tabla 31. Elementos de perspectiva lógica de RiskSys ........................................................................ 82

Tabla 32. Elementos de vista física de RiskSys ................................................................................... 83

Tabla 33. Objeto de estudio ................................................................................................................. 98

Tabla 34. Cuestionario para evaluar la herramienta RiskSys ............................................................. 100

Tabla 35. Descripción de la Empresa A ............................................................................................. 103

Tabla 36. Descripción de la Empresa B ............................................................................................. 111

1

Introducción

En una economía global con una creciente demanda de información y conocimiento, el

software se ha convertido en una herramienta decisiva para aumentar la productividad. La

producción de software es por lo tanto, una actividad económica cada vez más importante.

Tan solo en América Latina este sector está compuesto por el 99% de pymes (Navarro &

Garzás, 2010). Esto destaca la importancia de implementar buenas prácticas de ingeniería de

software en las pymes para mejorar su productividad y asegurar la mejora continua.

Por lo anterior, la implementación de buenas prácticas de Ingeniería de Software es una

actividad que las pymes deben realizar con el fin de mejorar la calidad de sus productos y/o

servicios(Durón, Muñoz, & Mejía, 2013; Navarro & Garzás, 2010). Para ello se utilizan

modelos como CMMI-DEV v1.3(Chrissis, Konrad, & Shrum, 2010), ISO 12207(Rajchel et

al., 2011), ISO 15504(ISO, 2012), entre otros. Sin embargo, los modelos sólo explican ¿Qué

hacer? y no ¿Cómo hacerlo?.

Como una solución este trabajo de investigación presenta un método que permite la

creación de herramientas de buenas prácticas como apoyo a las pymes en la selección de

técnicas y herramientas adecuadas a su entorno y que impulsen el uso de buenas prácticas

contenidos en los modelos y estándares existentes, así como el desarrollo de una herramienta

que facilite la implementación de buenas prácticas. En específico se enfoca en las buenas

prácticas relacionadas con la gestión de proyectos. Debido a su importancia e impacto en el

desarrollo de software, para la validación del método en las pymes, se muestran los resultados

para la gestión de riesgos, la planificación del proyecto y monitorización y control del

proyecto.

La estructura de la tesis está compuesta por 7 capítulos, los cuales se detallan a

continuación:

Capítulo 1. Antecedentes. Se aborda la problemática sobre la Gestión de proyectos,

además de presentar el objetivo general y los objetivos específicos de la investigación así

como la justificación.

Capítulo 2. Estado del arte. Resume la situación actual de las empresas en cuanto a la

Gestión de Proyectos y Gestión de Riesgos, así como de técnicas y/o herramientas

utilizadas en las áreas de Gestión de Proyectos.

2

Capítulo 3. Metodología para el desarrollo de la tesis. Presenta los pasos

establecidos para el desarrollo de la tesis.

Capítulo 4. Propuesta. Describe el método para el desarrollo de herramientas

enfocadas en facilitar la implementación de buenas prácticas de desarrollo de software

en pymes.

Capítulo 5. Validación. Presenta la aplicación del método para las áreas de Gestión

de Riesgos, Planificación de Proyectos, Monitorización y Control de Proyectos, así

como de la herramienta para facilitar la implementación del método, finalmente

muestra el análisis, diseño y funcionalidad de la herramienta.

Capítulo 6. Resultados. Muestra la realización del caso de estudio para validar la

herramienta y presenta los resultados obtenidos.

Capítulo 7. Conclusiones. Presenta las conclusiones, recomendaciones y trabajo

futuro.

4

Capítulo 1. Antecedentes

En este capítulo se presentan los antecedentes de este trabajo de investigación, comenzando

con el marco teórico que contiene la definición de los conceptos a partir de los cuales se

fundamenta, posteriormente se presenta: el planteamiento del problema, los objetivos

generales y específicos así como la justificación.

1.1. Marco teórico

El objetivo del marco teórico es brindar un marco de referencia conceptual necesaria

para comprender la investigación. A continuación se presentan los conceptos fundamentales

directamente involucrados con el desarrollo de la presente investigación.

1.1.1. Gestión de proyectos

La gestión de proyectos es la aplicación de conocimiento, habilidades, herramientas y

técnicas en actividades del proyecto para cumplir con los requisitos del proyecto

(Wangenheim, Carlo, Hauck, & Wangenheim, 2009).

En este contexto, los principales problemas encontrados en la gestión de proyectos se

listan a continuación:

(1) Los ingenieros carecen de conocimiento en gestión de proyectos, y por lo tanto

presentan problemas para cumplir con el presupuesto y calendario, evaluación de riesgos y

mantenimiento de comunicación efectiva en los equipos (Tomer, 2015).

(2) La falta de conocimiento en la elección de herramientas adecuadas a su entorno para

automatizar las actividades de gestión de proyectos (Rivas, Perez, Mendoza, & Grimán,

2010).

(3) Dificultad en la implementación de modelos y estándares orientados a grandes

empresas (Mas & Amengual, 2005; Pino, García, & Piattini, 2006; Richardson, 2001).

5

Dentro de la gestión de proyectos se consideran básicas las áreas de Planificación del

Proyecto y Monitorización y Control del Proyecto, a continuación se describen.

1.1.1.1. Planificación del Proyecto

Consiste en aquellas actividades que se realizan para desarrollar el plan del proyecto y la

documentación del proyecto que serán utilizados para llevar a cabo el proyecto (Project

Management Institute, 2000).

Su propósito (Chrissis et al., 2010) es crear y mantener planes que definan las

actividades del proyecto. Implica las siguientes actividades:

» Desarrollar el plan de proyecto.

» Interactuar de forma apropiada con las partes interesadas relevantes.

» Obtener el compromiso con el plan.

» Mantener el plan.

La planificación incluye la estimación de los atributos de los productos de trabajo y de

las tareas, la determinación de los recursos necesarios, la negociación de los compromisos, la

elaboración de un calendario, y la identificación y el análisis de los riesgos del proyecto. El

plan de proyecto proporciona la base para realizar y controlar las actividades del proyecto. Un

plan de proyecto es un plan global para controlar el proyecto (Chrissis et al., 2010) .

1.1.1.2. Monitorización y Control del Proyecto

Consiste en aquellas actividades requeridas para rastrear, revisar y coordinar el progreso

y desempeño del proyecto, así como identificar áreas en las que se requieran cambios al plan

e iniciar los cambios correspondientes (Project Management Institute, 2000).

Su propósito (Chrissis et al., 2010) es proporcionar una comprensión del progreso del

proyecto para que se puedan tomar las acciones correctivas apropiadas, cuando el rendimiento

del proyecto se desvíe significativamente del plan.

Las actividades que involucra la monitorización y control del proyecto son (Project

Management Institute, 2000):

» Controlar los cambios y recomendar acciones preventivas o correctivas en

previsión de posibles problemas.

» Realizar un seguimiento de actividades en curso del proyecto en relación con el

plan del proyecto y la línea base de medición del desempeño del proyecto

» Influir en los factores que podrían eludir el control de cambios o la gestión de la

configuración para que sólo aquellos cambios aprobados sean implementados.

6

Cuando el estado real del proyecto se desvíe de manera significativa del plan del

proyecto, se llevarán a cabo las acciones correctivas necesarias, dichas acciones pueden

requerir una re-planificación, que pueden incluir la modificación del plan original, es

establecimiento de nuevos acuerdos o la inclusión de actividades adicionales de mitigación en

el plan actual (Chrissis et al., 2010).

1.1.2. Gestión de riesgos

Todo proyecto de desarrollo de software tiene riesgos, por lo tanto, como parte de la

gestión de proyectos se debe desarrollar la gestión de riesgos, que es un área importante cuyo

objetivo se centra en la identificación de problemas potenciales antes de que éstos ocurran

(Chrissis et al., 2010).

La gestión de riesgos se encarga de realizar la detección temprana y dinámica de riesgos

ya que es más fácil, menos costosa y menos perjudicial hacer los cambios y corregir los

esfuerzos de trabajo durante las fases iniciales del proyecto, en lugar de en fases

posteriores(Chrissis et al., 2010) .

.

(Pressman, 2010) y otros autores (Carr, Konda, Monarch, Ulrich, & Walker, 1993; ISO,

2013) mencionan que la definición de un riesgo implica dos características: la incertidumbre

y la pérdida:

1) Incertidumbre: es el acontecimiento de que el riesgo pueda o no ocurrir.

2) Pérdida: son las consecuencias no deseadas que ocurren cuando el riesgo se convierte

en realidad.

Por lo tanto, un riesgo se puede definir como la combinación de la posibilidad de la

ocurrencia de un evento no deseado (probabilidad) y sus consecuencias (impacto) (Pressman,

2010).

La gestión de riesgos comprende tanto las actividades de identificación cómo las de

tratamiento durante todo el ciclo de vida del desarrollo del software. Sin embargo, muchas

organizaciones continúan sin una cultura ni la habilidad para realizar y gestionar sus riesgos

de manera adecuada.

7

1.2. Planteamiento del problema

Para las empresas desarrolladoras de software es importante crear estrategias para ser

competitivas, como incrementar la calidad de sus productos, reduciendo tiempos de entrega y

costos de producción.

Como una respuesta a esta necesidad, organizaciones como el Software Engineering

Institute (SEI), Institute of Electrical and Electronics Engineers (IEEE) e International

Organization for Standardization (ISO) entre otras, en los últimos años han desarrollado

modelos y estándares de calidad como el modelo CMMI (Chrissis et al., 2010), o la norma

ISO/IEC 15504 (ISO, 2012), PMBOK (Project Management Institute, 2000) etc., para ayudar

a las organizaciones en la implementación de mejores prácticas. Sin embargo estos modelos y

estándares solo dicen qué actividades implementar y no dicen el cómo implementarlas.

Lo anterior resalta que el problema actual con el uso de buenas prácticas en las pymes no

es la falta de modelos o estándares de referencia, si no la falta de estrategias efectivas de

implementación de prácticas contenidas en estas (Durón et al., 2013; Niazi, Wilson, &

Zowghi, 2005), y más en entornos de pymes que son disparadores en la resistencia para la

implementación de buenas prácticas donde se tienen que tener en cuenta aspectos tales como:

» Desconocimiento de la importancia que tienen las prácticas de ingeniería de

software para el desarrollo de la calidad del producto o (Muñoz, Gasca, &

Valtierra, 2014).

» Falta de conocimientos y experiencia por parte de los empleados para la adopción

de modelos y estándares que proporcionen buenas prácticas para el desarrollo de

software o (Muñoz et al., 2014).

» Falta de tiempo y recursos, así como desconocimiento de buenas prácticas (Rivas

et al., 2010).

» Falta de experiencia de los desarrolladores en las organizaciones y más

específicamente las pymes en la selección de las buenas prácticas más óptimas

(Tomer, 2015).

Como una solución a esta problemática, este trabajo busca desarrollar un método que

permita desarrollar herramientas que habiliten a las organizaciones y en específico a las

pymes en la selección de las técnicas y herramientas más adecuadas según sus necesidades, su

forma de trabajo y su entorno.

8

1.3. Objetivos

El objetivo general y los objetivos específicos para el desarrollo del presente trabajo de

investigación se muestran a continuación:

1.3.1. Objetivo General

Desarrollar un método para la creación de herramientas de buenas prácticas que apoyen a las

pymes en la selección de técnicas y herramientas adecuadas a su entorno y que impulsen el

uso de buenas prácticas contenidos en los modelos y estándares existentes.

1.3.2. Objetivos específicos

I. Obtener el estado del arte en la gestión de proyectos.

II. Identificar y revisar los trabajos relacionados.

III. Realizar la propuesta del método para el desarrollo de herramientas enfocadas en

facilitar la implementación de buenas prácticas de desarrollo de software en pymes.

IV. Creación de una herramienta basada en el análisis del área de gestión de riesgos.

V. Validación de la propuesta y de la herramienta mediante un caso de estudio.

1.4. Hipótesis

Al proporcionar herramientas basadas en mejores prácticas se facilita el uso de buenas

prácticas en las pymes.

1.5. Justificación

Hoy en día, el software juega un papel clave en la economía, siendo un factor de éxito en

todos los sectores económicos (Bastos & Silveira, 2009; Rivas et al., 2010), por lo que es

importante garantizar la calidad de sus productos y/o servicios (Contact, 2014; Durón et al.,

2013; Gómez, Aguileta, Ancona, & Gómez, 2014).

En este contexto, las pymes se consideran una pieza clave ya que el 99% de la industria

del software está conformado por pymes (Navarro & Garzás, 2010). Por lo tanto, se debe

impulsar en ellas la implementación de buenas prácticas de Ingeniería de Software contenidas

9

en modelos como CMMI-DEV v1.3 (Chrissis et al., 2010), ISO 15504 (ISO, 2012), entre

otros. Sin embargo, estos modelos no son fácilmente implementados.

El objetivo de este trabajo es mostrar un análisis de técnicas y herramientas de gestión de

proyectos (planificación de proyectos, monitorización y control de proyectos, así como la

gestión de riesgos) como apoyo a las pymes para la selección de técnicas y herramientas

adecuadas a su entorno, impulsando así el uso de buenas prácticas de ingeniería de software.

10

Capítulo 2. Estado del arte

En este capítulo se presenta el estado del arte respecto a las técnicas y herramientas que

ayudan a cumplir con las prácticas de la gestión de proyectos. Se analizan los trabajos

relacionados con la presente investigación y finalmente se presentan conceptos sobre modelos

de ciclo de vida de software y selección de tecnología.

2.1. Revisión sistemática en la planificación y

monitorización y control de proyectos

Para la búsqueda de técnicas y herramientas se realizó una revisión sistemática de literatura;

método propuesto por Barbara Kitchenham (Kitchenham, 2004) que permite identificar,

evaluar, interpretar y sintetizar todas las investigaciones existentes y relevantes en un tema de

interés particular.

Las revisiones sistemáticas se ejecutan de forma rigurosa e imparcial para que tengan un

alto valor científico y su principal motivación es que se realizan para aumentar la posibilidad

de detectar más resultados reales en el tema de interés que los que puedan ser detectados con

revisiones de menor dimensión (Kitchenham, 2004).

2.1.1. Diagrama del método de revisión sistemática

A continuación, la Fig. 1 muestra las fases que integran el método de la revisión sistemática.

1.

Figura 1. Método de Revisión Sistemática

11

2.1.2. Planificación de la revisión sistemática

Es la primer fase de la revisión donde se desarrolla el protocolo para guiar la revisión, a

continuación se describen las actividades.

2.1.2.1. Identificación de la necesidad de la revisión

Las pymes desarrolladoras de software representan una actividad económica importante en

los países del mundo.

De acuerdo a (Pino, García, & Piattini, 2006) hay una tendencia enfocada a resaltar

que la implementación de buenas prácticas de ingeniería de software sólo se aplican en las

grandes empresas, debido a la gran cantidad de recursos y altos costos que implican. De tal

manera que en las pymes se trata de implementar buenas prácticas que las apoyen a ser más

eficientes, independientemente si utilizan metodologías ágiles o tradicionales.

2.1.2.2. Formulación de la pregunta

1 ¿Cuáles son los métodos, técnicas o herramientas que existen en la

planificación del proyecto en pymes_ds (pymes desarrolladoras de software)?

2 ¿Cuáles son los métodos, técnicas o herramientas que existen en la

monitorización y control del proyecto en pymes_ds?

La lista de los términos usados para resolver las pregunta de investigación son:

Methods, Techniques, Tools, Project Planning, Project Monitoring and Control, SME,

Software, CMMI, CMMI-DEV, Scrum. La lista de términos se muestra en la Tabla 1 a

continuación.

Tabla 1. Palabras clave y sinónimos

Met

ho

ds

Tec

hn

iqu

es

To

ols

Pro

ject

Pla

nn

ing

Pro

ject

Mo

nit

ori

ng

a

nd

Co

ntr

ol

SM

E

So

ftw

are

Scr

um

CM

MI

Small Enterprises

CM

MI-

DE

V

Small Organization

Firms

12

2.1.2.3. Cadenas de búsqueda

En la construcción de las cadenas, se utilizaron las palabras clave, haciendo uso de los

conectores lógicos AND y OR así como los paréntesis para especificar niveles de detalle.

Se decidió utilizar términos en inglés para abarcar un mayor número de literatura. La

Tabla 2 muestra las cadenas de búsqueda utilizadas para realizar la revisión sistemática.

Tabla 2. Cadenas de búsqueda

La cadena C1 y la cadena la cadena C2 se refinaron en la cadena C1.2, se quitaron las

palabras CMMI CMMI-DEV SCRUM, ya que sesgaban la búsqueda y daban resultados que

hablaban específicamente de esos temas y no se relacionaba con técnicas de monitorización y

control de proyectos.

2.1.2.4. Selección de Fuentes de datos

Los criterios de selección se basan en que son las fuentes más reconocidas en el campo de la

Ingeniería de Software, así como por recomendación del asesor basado en su experiencia

profesional.

La lista de fuentes para ejecutar la revisión sistemática son:

» Science Direct

» IEEE Xplore

» Springer

» SEIR (Software Engineering Information Repository)

» SEI

Además de fuentes de literatura base como:

» PMBOK

» CMMI

C1 Software AND project planning OR PP AND ((methods) OR (techniques) OR

(TOOLS)) AND (CMMI OR CMMI-DEV OR SCRUM) AND (SME OR

(small AND (enterprises OR organizations OR firms)))

C2 Software AND project monitoring control OR PMC AND ((methods) OR

(techniques) OR (TOOLS)) AND (CMMI OR CMMI-DEV OR SCRUM) AND

(SME OR (small AND (enterprises OR organizations OR firms)))

C1.2 Software AND project planning OR PP AND project monitoring control OR

PMC AND ((methods) OR (techniques) OR (TOOLS)) AND (SME)

13

Al ejecutar las búsquedas, las cadenas se tienen que adaptar a los motores de búsqueda de las

fuentes seleccionadas.

2.1.3. Ejecución de la revisión sistemática

Es la segunda fase de la revisión, en donde se define la selección de los estudios primarios y

se extrae la información. A continuación se describen las actividades.

2.1.3.1. Selección de estudios primarios

2.3.1.1. Los criterios de inclusión para la selección de estudios son:

[1]. Fecha: Que estén dentro del rango 2009 a la fecha.

[2]. Idioma: Inglés y español.

[3]. Disciplina: Ciencias de la Computación e Ingeniería de Software.

[4]. Técnicas implementadas.

[5]. Herramientas que tengan un caso de estudio.

[6]. Métodos que estén probados.

2.3.1.2. Los criterios para excluir los estudios son:

[1]. Que no estén dentro del rango del 2009 a la fecha.

[2]. Que el idioma no sea inglés y español.

[3]. Que la disciplina no sea Ciencias de la Computación e Ingeniería de Software.

[4]. Que la técnica no esté implementada.

[5]. Que la herramienta no tenga un caso de estudio.

[6]. Que el método no esté probado.

[7]. Aunque tenga una o más palabras clave no se relacione con el tema.

[8]. Que no sea referente a la gestión de proyectos de software.

2.3.1.3. Procedimiento de selección de estudios primarios

A continuación se muestra un diagrama de flujo que ilustra el procedimiento utilizado para la

selección y depuración de estudios en la Fig. 2.

Figura 2. Procedimiento de selección de estudios

1. Adaptar las cadenas de búsqueda al motor de la fuente seleccionada

2. Ejecutar la búsqueda con la cadena en la fuente seleccionada

3. Seleccionar el estudio encontrado

4. Aplicar los criterios de inclusión

5. Leer resumen, introducción y conclusiones y aplicar los criterios de exclusión

14

Evaluación de calidad de Estudios 2.3.1.3.1.

La forma en que se validó la calidad de los estudios se describe a continuación:

» Revisión constante del documento con el Asesor para correcciones.

2.1.3.2. Extracción de información

Al lanzar la búsqueda, los resultados se resumen en la Tabla 3.

Tabla 3. Resultados de búsquedas lanzadas

Fuente Formal

SCIENCE

DIRECT

IEEE

XPLORE

SEIR SPRINGER

C1.2 C1.2 C1.2 C1.2

Paso 1 y 2 474 12 91 186

Paso 3 y 4 63 5 58 91

Paso 5 5 3 10 3

Resultado 5 3 5 1

Total 14 EP (Estudios Primarios)

En la Tabla 4 se muestra el listado de los estudios primarios seleccionados. Para la

extracción de la información, se recopilaron los datos de los artículos seleccionados en una

Tabla con los siguientes datos de cada estudio primario: Título, Revista, Fecha, Autores,

Metodología y Contenido (Técnica/Herramienta/Método), esta información se muestra en la

Tabla 5.

Tabla 4. Listado de estudios primarios

Título Año ID

Mejora de software de código abierto en alineación con CMMI-DEV 2009 EP1

SOFTWARE MANGINEERINGMENT: Enseñanza de manejo de

Proyectos de Software desde una perspectiva de Ingeniería

2014 EP2

Modelo de Selección para Herramientas de Gestión de Proyectos

Software en Pymes

2010 EP3

15

Un modelo basado en DSS para integración del impacto del

aprendizaje en el control del proyecto

2009 EP4

Gestión de Proyectos en Proyectos Multimedia: resultados

preliminares de comunicación, interacción y dinámicas de trabajo en

equipo

2015 EP5

Estimando, planificando y gestionando desarrollo de proyectos Web

Ágiles bajo una perspectiva basada-en valor.

2015 EP6

Monitoreo Ágil usando la línea de balance 2010 EP7

Modelo de Estimación Temprana de Software (SEEM) 2014 EP8

Alternativas para definir procedimientos de estimación de software

compatibles con CMMI

2010 EP9

Mejorando el seguimiento en los proyectos de desarrollo de software 2011 EP10

El compendio de medición IT: Estimando y evaluando

satisfactoriamente con medidas de tamaño funcional

2008 EP11

Gestión de proyectos por capacidad funcional 2008 EP12

Recursión en las áreas de proceso de Gestión de Proyectos CMMII 2009 EP13

Gestión de Proyectos de Software 1989 EP14

16

Tabla 5. Información de EP sobre Planificación y Monitorización y Control de Proyectos

2.1.4. Reporte de resultados

En la Tabla 5, se muestra la información analizada de los primeros 3artículos seleccionados, la información del resto de los

artículos se encuentra en el Anexo I Información de EP sobre Planificación y Monitorización y Control de Proyectos.

17

2.1.5. Hallazgos de la revisión sistemática

A continuación se presentan los hallazgos derivados del análisis de los 14 estudios

primarios.

2.1.5.1. Técnicas de planificación más utilizadas

En la Fig.3 se muestra que las técnicas más utilizadas para la planificación son: WBS, Puntos

de función y COCOMO II.

Figura 3. Técnicas de planificación

3 3 3

2 2 2 2 2

1 1 1

0

0.5

1

1.5

2

2.5

3

3.5

Nú

mer

o d

e ve

ces

men

cio

nad

a

18

2.1.5.2. Técnicas de monitorización y control de proyectos más

utilizadas

En la Fig. 4 se muestra que las técnicas más utilizadas para monitorización y control son: en

primer lugar el Valor ganado, enseguida PERT, CPM (Método del camino crítico) y Gantt.

Figura 4. Técnicas de monitorización y control del proyecto

5

1 1 1

0

1

2

3

4

5

6

EVM (Valor ganado) PERT CPM (método del

camino crítico)

Gantt

Núm

ero

de

vec

es m

enci

ionad

a

19

2.1.5.3. Técnicas ágiles de planificación y monitorización y

control de proyectos

En la Fig. 5 se muestra que la técnica ágil más utilizada es Burn down chart, enseguida están

Burn up chart e Historias de usuario, Planning game, Planning poker, Blitz planning y LOB

(Línea de balance).

Figura 5. Técnicas ágiles de planificación y monitorización y control de proyectos

2

1 1 1 1 1 1

0

0.5

1

1.5

2

2.5

Burn down

chart

Burn up chart Historias de

usuario

Planning

game

Planning

póker

Blitz

Planning

LOB (Línea

de balance)

Núm

ero

de

vec

es m

enci

onad

a

20

2.1.5.4. Herramientas de gestión, monitorización y control de

proyectos

En la Fig. 6, se muestra el total de herramientas encontradas agrupadas por área. Las

herramientas de monitorización y control de proyectos no ágiles son las más utilizadas,

enseguida están las herramientas de gestión de proyectos no ágiles y finalmente están las

herramientas de monitorización y control de proyectos ágiles. Algunas de las herramientas de

la Fig. 6 en la gestión de proyectos son: dotProject; en la monitorización y control de

proyectos ágiles: Open Project y Jira Agile; en la monitorización y control de proyectos no

ágiles: Crowdbase, Function Fox, Gantt Project, Liquid Planner, Wrike, Nozbe, Team Gantt,

Smartsheet, Wiggio, Paymo, Podio.

Figura 6. Herramientas de gestión, monitorización y control de proyectos

6

11

2

0

2

4

6

8

10

12

Herramientas de planificación

de proyectos ágiles

Herramientas de

monitorización y control no

ágiles

Herramientas de

monitorización y control

ágiles

Núm

ero

de

vec

es m

enci

onad

a

21

2.2. Búsqueda de técnicas y herramientas en el área de

Gestión de Riesgos

Después de la revisión sistemática, para el área de Gestión de Riesgos se realizó una

búsqueda de técnicas y herramientas, se tomó como fuente la documentación de modelos

como CMMI-DEV v1.3(Chrissis et al., 2010), PMBOK (Project Management Institute,

2013), la metodología MAGERIT(Ministerio de Hacienda y Administraciones Públicas,

2012b)(Ministerio de Hacienda y Administraciiones Públicas, 2012a)(Ministerio de Hacienda

y Administraciones Públicas, 2012c), el modelo eSourcing Capability Model for Client

Organizations – eSCM-CL (Hefley & Loesche, 2006), el estándar de la taxonomía de riesgos

de IEEE(Engineering & Committee, 2001). Se obtuvo un listado de 28 técnicas y

herramientas, que se muestran en la Tabla 6 a continuación.

Tabla 6. Listado de técnicas/herramientas del área de Gestión de Riesgos

No. Técnica/Herramienta No. Técnica/Herramienta

1 Enfoque informal (McManus,

2012)

15 Tormenta de ideas (Harris &

Arbeitstechniken, 2015)

2 Enfoque periódico (McManus,

2012)

16 Taxonomía (Carr et al., 1993;

Chrissis et al., 2010; Engineering

& Committee, 2001)

3 Enfoque formal (McManus, 2012) 17 Lecciones aprendidas (Engineering

& Committee, 2001)

4 Lista de riesgos (McManus, 2012) 18 Análisis de escenarios

(Engineering & Committee, 2001;

Fischer, 2011)

5 Análisis de estrategia de riesgos

(McManus, 2012)

19 Hoja de cálculo (Chrissis et al.,

2010)

6 Diagrama de dependencia entre

activos (Públicas, 2012b, 2012c)

20 Relación de activos a considerar

(Chrissis et al., 2010; Públicas,

2012b, 2012c)

7 Enfoque ad-hoc (McManus, 2012) 21 Lista de acción de riesgos

(McManus, 2012)

8 Catálogos de amenazas (Chrissis et

al., 2010; Públicas, 2012a)

22 Análisis mediante tablas (Chrissis

et al., 2010; Públicas, 2012b,

2012c)

9 Árboles de ataque (Públicas,

2012a)

23 Análisis algorítmico (Públicas,

2012b, 2012c)

22

10 Entrevistas (Públicas, 2012a) 24 Técnicas gráficas (Públicas, 2012b,

2012c)

11 Reuniones (Públicas, 2012a) 25 Modelo de estrategia de riesgos

(McManus, 2012)

12 Valoración Delphi (Públicas,

2012a)

26 Matriz de priorización de historias

de riesgo (Arora & Naresh, 2014)

13 Documentar la política de gestión

del riesgo (Hefley & Loesche,

2006)

27 Técnica de burn-down de riesgos

(Singh & Saxena, 2014)

14 Cuestionarios (Accountants, 2007;

Engineering & Committee, 2001)

(Accountants, 2007)

28 Tablero de riesgos con dos tipos de

notas (Ylimannela, 2012)

23

2.3. Trabajos relacionados

En esta sección se presentan los trabajos relacionados con la presente investigación, los

cuales se tomarán como referencia para realizar la propuesta. Se presentan dos análisis, el

primero es sobre la Gestión de Riesgos y el segundo es acerca de la Gestión de Proyectos.

2.3.1. Gestión de riesgos

Debido a la importancia de este tema para las organizaciones, se pueden encontrar varias

propuestas relacionadas con la gestión de riesgos bajo diferentes enfoques.

Los autores (Krishna Mohan, Srividya & Verma, 2010) en su trabajo ANP-based

software reliability prediction using PoCs and subsequent employment of orthogonal defect

classification measurements for risk mitigation during prototype studies proponen el uso de

un procedimiento para identificar las fases críticas potenciales de un proceso de desarrollo de

software utilizando ANP (Analytic Network Process) Procesos Analíticos en Red, antes de la

implementación del prototipo. Los resultados se comparan con los obtenidos en la realización

del prototipo y se analiza la información, se explican las medidas para fortalecer la

efectividad del conjunto con la intención de mitigar los riesgos.

El autor (Bannerman, 2008) en su trabajo Risk and risk management in software

projects: A reassessment presenta un análisis del estado del riesgo y la gestión del riesgo en la

literatura y la práctica. Realiza un estudio de las prácticas del riesgo en empresas

gubernamentales de un estado australiano.

Se encontró que la noción de riesgo como una amenaza de impacto negativo es relevante

para los proyectos de software y que existe la necesidad de manejar tales amenazas para

lograr resultados benéficos para el proyecto. Dado el costo y las pérdidas potenciales de los

proyectos de software fallidos, los investigadores y los profesionales deben seguir

aprendiendo unos de otros para reducir los fracasos del proyecto y desarrollar prácticas que

consistentemente generan consistentemente mejores resultados del proyecto. Una mejor

gestión del riesgo, como proyecto y capacidad organizativa, es fundamental para lograr estos

objetivos.

Los autores (Costa, Barros & Travassos, 2007) en su trabajo Evaluating software project

portfolio risks presentan una técnica para evaluar un nivel de riesgo de proyecto de software

por medio de analogías con conceptos económicos, dicha técnica permite a un administrador

estimar la distribución de probabilidad de ganancias y pérdidas incurridas por una

organización de acuerdo a su cartera de proyectos de software. Presentan además una

herramienta construida para apoyar la aplicación de las técnicas propuestas. La herramienta

RISICARE realiza una evaluación del nivel de riesgo, aplica un cuestionario y las diferentes

24

ponderaciones que pueden atribuirse a cada proyecto (según sus características específicas),

el cálculo del nivel de riesgo del proyecto y las simulaciones necesarias para crear las

pérdidas y la distribución de la probabilidad de ingresos para una cartera de proyectos no se

pueden realizar manualmente.

Los autores (Nakatsu, Charalambos & Iacovou, 2007) en el trabajo A comparative study

of important risk factors involved in offshore and domestic outsourcing of software

development projects: A two-panel Delphi study se orientan a estrategias para la

identificación de factores de riesgo importantes en los proyectos de software. Investigaron los

factores de riesgo de desarrollo de software en el outsorcing. Utilizaron técnicas Delphi para

identificar los factores de riesgo importantes desde la perspectiva del cliente en outsorcing y

en offshore. Compararon cualitativamente los resultados de las encuestas para identificar

similitudes y diferencias a través de sus perfiles de riesgos. Los hallazgos sugieren que los

riesgos tradicionales de gestión de proyectos son importantes en contextos outsorcing y

offshore, sin embargo el segundo parece ser más vulnerable a algunos riesgos tradicionales.

El estudio trató de determinar los factores de riesgo de outsorcing más importantes..

Concluyen que es más difícil mantener el control sobre largas distancias y con destinos que

tienen diferentes culturas, leyes y lenguas.

Los autores (Dey, Kinch & Ogunlana, 2007) en su trabajo Managing risk in software

development projects: a case study estructuran frameworks para la gestión de riesgos,

buscando determinar condiciones específicas que impactan la percepción del riesgo y la

decisión de continuar o no con un proyecto. La gestión eficaz del riesgo en el desarrollo de

software asegura la realización exitosa de los proyectos con la satisfacción del cliente, el

logro funcional y en general un mejor rendimiento financiero de las organizaciones. Por lo

tanto un plan de gestión de riesgos junto con el plan de trabajo es necesario para lograr que el

proyecto termine en tiempo y con calidad y costos justos. La gestión del riesgo requiere la

participación de las partes interesadas de manera interactiva, ya que la experiencia es el mejor

medio para gestionar el riesgo junto con un framework cuantitativo.

En el desarrollo ágil también se pueden encontrar propuestas enfocadas a la gestión de

riesgos. Tal es el caso del trabajo de (Arora & Naresh, 2014) en su trabajo A Risk Based

Story Prioritization Technique In An Agile Environment, se propone un enfoque basado en

una matriz completa de historias de usuarios que ayuda a evaluar la medida de diseño general

de la historia del usuario. Además de añadir, esta medida predice el factor de riesgo de

cualquier historia de usuario y puede tener un efecto sustancial en las historias existentes.

Esta priorización sobre la base de los factores de riesgo asegura la utilización óptima de los

recursos como el coste, el tiempo y el esfuerzo. La matriz de historias de usuario ayuda en la

evaluación del diseño y en la predicción del factor de riesgo de cualquier historia de usuario.

25

2.3.2. Gestión de proyectos

En el área de planificación y monitorización y control de proyectos, se pueden encontrar

varias propuestas las cuales se presentan a continuación.

Los autores (Wangenheim et al., 2009) en su trabajo Enhancing Open Source Software

in Alignment with CMMI-DEV examinan y comparan algunas herramientas Web Open

Source de gestión, monitoreo y control de proyectos para determinar que tan bien cumplen

con CMMI-DEV. Usan los resultados del análisis para implementar mejoras en una

herramienta en particular, dotProject, para mejorar el soporte para PMC, incluyendo gestión

del Valor Ganado (EVM), en alineación con las prácticas requeridas por CMMI-DEV.

Presenta una tabla comparativa entre las herramientas dotProject, phpCollab, ]Project-

open[ y Track+ las características que compara son número de descargas, soporte para PP,

soporte para PMC, capacidad de personalización, capacidad de integración, soporte de

lenguaje, distribución, últimas actualizaciones.

El autor (Tomer, 2015) en su trabajo Software Mangineeringment: Teaching Project

Management from Software Engineering Perspective describe un curso de Gestión de

Proyectos Software el cual únicamente combina la teoría general y práctica de Gestión de

Proyectos con prácticas específicas de Ingeniería de Software. Esta integración resulta en un

conjunto aplicable de prácticas el cual ha sido validado para beneficiar a los estudiantes de

ISW e ingenieros de software industrial y administradores, menciona algunas técnicas de

estimación como COCOMO II, Puntos de Función, Gestión del Valor Ganado, Burn Down

Chart, entre otras.

Los autores (Rivas et al., 2010) en su trabajo Selection Model for Software Project

Management Tools in SMEs menciona que las Pymes están aumentado su presencia a nivel

mundial en la industria software y utilizan herramientas para automatizar actividades en las

distintas disciplinas de ISW, entre las que Gestión de Proyectos (PM) es de especial

importancia. Sin embargo, las Pymes con experiencia tienen restricciones que les obligan a

seleccionar de manera efectiva sus tecnologías. Tomar una decisión en la que la herramienta

debe ser adquirida puede ser una tarea compleja para las Pymes. Por lo tanto, hay que

analizar la empresa y sus necesidades. Existen procesos definidos en términos de estándares

para llevar a cabo esta selección, pero identificaron dificultades para su aplicación en Pymes.

Su principal objetivo fue proponer un modelo que apoye la selección de herramientas de

Gestión de Proyectos en las Pymes. Además evaluaron el modelo y 8 expertos evaluaron los

criterios y demostraron su relación directa con áreas de Gestión de Proyectos relevantes de

tales compañías. Los resultados de la evaluación mostraron que estos criterios pueden ser

analizados y mejorados para aplicar un enfoque más cercano a las necesidades de las Pymes.

26

Los autores (Plaza & Turetken, 2009) en su trabajo A model-based DSS for integrating

the impact of learning in project control presentan un caso de estudio donde discuten la

versión extendida del método de Valor Ganado (EVM), que es una popular técnica de control

de proyectos. Sitúa el efecto del aprendizaje sobre el rendimiento de los equipos de proyectos.

Estos efectos tienden a ser ignorados en las aplicaciones EVM. Se presenta una hoja de

cálculo basado en una herramienta de soporte a la decisión que automatiza los cálculos y

análisis en EVM/LC. Usando esta herramienta se ahorra al líder del proyecto realizar cálculos

complejos mientras toma ventaja de hacer estimaciones relativamente exactas generadas por

EVM/LC. El modelo resultante, EVM / LC, es un modelo más realista de lo que sucede

durante los proyectos donde el aprendizaje y la formación de equipos se lleva a cabo en las

primeras etapas; Sin embargo este modelo no proporcionó cálculos sencillos para las

estimaciones de duración del proyecto, por lo tanto, sería un desafío a adoptar por la práctica

de los administradores de proyectos.

Los autores (Seabra & Margarida, 2015) en su trabajo Project management on

Multimedia Projects: preliminary results on communication, interaction and team work

dynamics presentan los resultados preliminares de una investigación en curso que tiene como

objetivo analizar la «comunicación», "interacción" y la dinámica de 'trabajo en equipo' de un

proyecto multimedia, que está siendo desarrollado en el Departamento de Comunicación y

Arte de la Universidad de Aveiro, Portugal. Esta investigación pretende contribuir con

soluciones capaces de mejorar el trabajo en equipo, el logro de metas, la finalización de tareas

y el cumplimiento de los plazos, con el fin de mejorar la productividad de los equipos de

desarrollo multimedia. Instrumentos y herramientas para monitorización y control: Además

presentan un estudio de herramientas existentes que apoyan la gestión de proyectos. Hay

varias herramientas gratuitas y de pago disponibles online, basadas en navegador o basadas

en escritorio y multiplataforma, que permite al acceso a la información sobre las tabletas o

teléfonos inteligentes.

Los autores (Torrecilla-Salinas et al., 2015) en su trabajo Estimating, planning and

managing Agile Web development projects under a value-based perspective presentan una

propuesta para estimar, planificar y gestionar proyectos Web, combinando algunos técnicas

Ágiles existentes con principios de Ingeniería Web, presentándolos como un framework

unificado el cual utiliza el valor del negocio para guiar la entrega de características. El

propósito es analizado por significados de un caso de estudio, incluyendo un proyecto de la

vida real, en orden para obtener conclusiones relevantes. Los resultados logrados después de

utilizar el framework en un proyecto de desarrollo son presentados, incluyendo interesantes

resultados de planificación de proyectos y estimación, tal como productividad del equipo en

el desarrollo del proyecto. Se concluyó que el marco de trabajo puede ser útil en orden para

gestionar mejor los proyectos basados en Web, mediante una continua estimación basada en

valor y proceso gestionado.

27

Los autores (Miranda & Bourque, 2010) en su trabajo Agile monitoring using the line

of balance los autores muestran como la línea de balance, se puede utilizar para obtener

información sobre el avance de los proyectos no previstos por la gráfica burn down o

diagramas de flujo acumulativos, dos de los indicadores más comunes usados para medir el

progreso reportado en proyectos Ágiles. Los autores también proponen reemplazar el punto

de control de cálculos de tiempo basados en el plan original con información dinámica

extraída de un sistema de control de versión e introducir el concepto del plan ideal para medir

el progreso en relación con ambos, el final de los hitos de iteración y la fecha de finalización

del proyecto. Se propone el uso de la línea de balance (LOB) que es un método como

alternativa para superar las deficiencias señaladas anteriormente. De acuerdo con la idea de

utilizar el rendimiento actual del equipo, también propondremos para derivar los plazos de

entrega para los llamados puntos de control, no desde una red de actividad como en la

formulación de LOB original, sino a partir de la velocidad del equipo.

28

2.3.3. Clasificación de trabajos relacionados

A continuación, la Tabla 7 presenta información acerca de los trabajos relacionados de la

Gestión de Riesgos así como las características que cubren. La Tabla 8 presenta información

referente a la Planificación de Proyectos y Monitorización y Control de Proyectos así como

las características que cubren.

Tabla 7. Trabajos relacionados de la Gestión de riesgos y características que cubren

Núm.

Ayuda a

implementar bp

de ingeniería de

software

Hay una

clasificación

de técnicas

Incluye

técnicas/herra

mientas

tradicionales

y ágiles

Actividades de gestión

de riesgos que realiza

la propuesta

Realiza una

gestión de riesgos

completa

Requiere

conocimiento

especializado

en el área

1 Sí No

Tra

dic

ional

es

Identifica las fases

críticas potenciales de

un proceso de

desarrollo de software

utilizando ANP

Procesos Analíticos en

Red

No, sólo

identificación de

riesgos

Sí

2 Sí No

Tra

dic

ional

es Realiza un estudio de

las prácticas del riesgo

en empresas

gubernamentales de un

estado australiano

Prácticas para

mejorar resultados

del proyecto

No

3 Sí No

Tra

dic

ional

es

Técnica para evaluar

un nivel de riesgo de

proyecto de software

por medio de

analogías con

conceptos económicos

Evaluación de

nivel de riesgo,

herramienta

RISICARE que

aplica un

cuestionario y

realiza el cálculo

de nivel de riesgo

del proyecto para

simular pérdidas y

distribución de

probabilidad de

ingresos

Sí

4 Sí No

Sí

Estrategias para la

identificación de

factores de riesgo

importantes en los

proyectos de software

outsorcing y offshore

No, sólo la

identificación de

factores de riesgo.

Sí

5 Sí No

Tra

dic

ional

es

Presentan un

framework para la

gestión de riesgos

Sí Sí

29

6 Si No

Ágil

es

Matriz completa de

historias de usuario

para evaluar el diseño

y predicción del factor

de riesgo de cualquier

historia de usuario

No, sólo

identificación del

factor de riesgo de

la historia de

usuario

Sí

Como resultado del análisis de los trabajos relacionados para el área de gestión de

riesgos, puede observarse que proponen una gran variedad de técnicas y herramientas sin

tomar en cuenta el nivel de conocimiento de la organización, algunas son muy complejas ya

que requieren conocimiento especializado del área, y se centran sólo en actividades

específicas sin realizar todo el proceso de la gestión de riesgos.

A continuación, la Tabla 8 muestra la clasificación de los trabajos relacionados en el

área de Planificación y Monitorización y Control de Proyectos.

Tabla 8. Trabajos relacionados de Planificación, Monitorización y Control del Proyecto

Núm.

Ayuda a

implementar bp

de ingeniería de

software

Hay una

clasificación

de técnicas

Incluye

técnicas/herra

mientas

tradicionales

y ágiles

Actividades de gestión

de riesgos que realiza

la propuesta

Realiza una

planificación/mon

itorización de

poryectos

completa

Requiere

conocimiento

especializado

en el área

1 Sí No

Tra

dic

ional

es

Examinan algunas

herramientas Web

Open Source de

gestión, monitoreo y

control de proyectos y

sugieren el uso de

dotProject

Sï, pero

Monitorización y

Control de

Proyecto requiere

mejoras

Sí

2 Sí No

Tra

dic

ional

es y

ágil

es

Integración de un

conjunto aplicable de

prácticas específicas

de ingeniería de

software

Sólo planificación Sí

3 No No

Tra

dic

ional

es Modelo que apoye a

las pymes en la

selecciones de

herramientas de

gestión de proyectos

Sólo presentan

una clasificación

de herramientas

de la Gestión de

Proyectos

Sí

4 Sí No

Tra

dic

ional

es Caso de estudio de la

versión extendida del

EVM (Método del

Valor Ganado)


30

5 Sí No

Sí

Clasificación de

herramientas de

monitorización y

control de proyectos

Sólo

monitorización y

control

No

6 Sí No

Sí

Framework unificado

que combina técnicas

ágiles para estimar,

planificar y gestionar

proyectos Web


7 Sí No

Ágil

es

Monitoreo Ágil

utilizando el método

de LOB (Línea de

Balance)

Solo

monitorización

Sí

Como resultado del análisis de los trabajos relacionados para las áreas de Planificación y

Monitorización y Control de Proyectos, puede observarse que proponen una gran variedad de

técnicas y herramientas sin tomar en cuenta el nivel de conocimiento de la organización,

algunas son muy complejas ya que requieren conocimiento especializado del área, y se

centran sólo en actividades específicas al realizar la planificación o la monitorización y

control pero no ambas.

31

2.5. Modelos de ciclo de vida del software

En esta sección se presenta el concepto de modelo de ciclo de vida del software o paradigma

de ingeniería del software, así como la descripción de los modelos elegidos para realizar la

herramienta.

De acuerdo a (Pressman, 2010) se define modelo de ciclo de vida del software o

paradigma de ingeniería del software como “una estrategia de desarrollo que ayuda al control

y a la coordinación de un proyecto de software”.

2.5.1. Construcción de prototipos

2.5.1.1. Descripción

El modelo de construcción de prototipos (Pressman, 2010) inicia con la recolección de

requisitos. El desarrollador y el cliente encuentran, definen e identifican los requisitos.

Después, se realiza un diseño rápido que se centra en la representación de aspectos del

software que serán visibles para el usuario/cliente. Este diseño es un prototipo el cual se le

muestra al cliente, lo utiliza y lo evalúa para refinar los requisitos del software a desarrollar.

La primera iteración ocurre cuando el prototipo satisface las necesidades del cliente a

su vez que el desarrollador comprende mejor lo que necesita saber. La idea es que el prototipo

sirva como un mecanismo para identificar o refinar los requisitos del software y a medida de

que este vaya creciendo se realicen los ajustes necesarios en el software o se agreguen

nuevas funciones.

2.5.1.2. Características

» Son iterativos: En este tipo de modelo se crean iteraciones, de tal forma que permite

que se desarrollen versiones más completas del software en cada iteración.

» Se ejecuta el sistema Prueba-Error, a través del cual el software se va adaptando a las

necesidades del cliente con mayor exactitud.

» Tiene una función lógica: Presenta las funciones que han de realizarse con la

información.

» Tiene una visión física: Contiene información de los requisitos físicos de la

computadora.

32

2.5.1.3. Descripción de etapas

A continuación, la Tabla 9 muestra el conjunto de etapas y las actividades que se realizan en

el modelo.

Tabla 9. Descripción de etapas del modelo de construcción de prototipos

No. Etapa Actividades

1 Escuchar al cliente » Evaluar la petición del software y determinar si el

software es un candidato a desarrollar prototipo.

» El desarrollador define los objetivos globales e identifica

requisitos.

2 Construcción del

prototipo

» Crea un conjunto de especificaciones de diseño.

» Se comienza a desarrollar el software, a modificar

errores o agregar nuevas herramientas o módulos.

3 Prueba del prototipo » El cliente hace las pruebas al prototipo del software de

tal forma que permita encontrar errores o necesite

nuevas funciones o herramientas en el sistema.

2.5.1.4. Esquema de etapas

La Fig. 7 muestra el diagrama del modelo.

Figura 7. Diagrama del modelo de construcción de prototipos (Pressman, 2010)

33

2.5.3. El modelo espiral

2.5.3.1. Descripción

Es un modelo de proceso de software evolutivo (Pressman, 2010) donde se combinan

características del modelo de construcción de prototipos con los aspectos controlados y

sistemáticos del modelo en cascada. En este modelo, el software se desarrolla en un conjunto

de versiones incrementales. En las primeras iteraciones la versión incremental podría ser un

prototipo (modelo en papel o pantallas), mientras que en las últimas iteraciones se realizan

versiones cada vez más completas del sistema diseñado hasta llegar a la versión final.


» En cada giro se construye un nuevo modelo del sistema completo.

» Es un enfoque realista del desarrollo de software a gran escala.

» El análisis de riesgo requiere la participación de personal experto.

» Utiliza la construcción de prototipos.

2.5.3.3. Descripción de etapas

A continuación la Tabla 10 muestra las etapas y las actividades del modelo.

Tabla 10. Descripción de etapas del modelo espiral

# Etapa Actividades

1 Comunicación

con el Cliente

Las tareas necesarias para establecer comunicación entre el

desarrollador y el cliente.

2 Planificación Las tareas necesarias para definir recursos, el tiempo, los

objetivos, alternativas y restricciones y otra información

relacionada con el proyecto a desarrollar.

3 Análisis de

Riesgos

Las tareas requeridas para evaluar riesgos técnicos y de gestión,

análisis de alternativas e identificación/resolución de riesgos

4 Ingeniería Las tareas requeridas para construir una o más representaciones de

la aplicación, desarrollo del producto hasta "el siguiente nivel".

5 Construcción y

Acción

Las tareas requeridas para construir, probar, instalar y

proporcionar soporte al usuario (por ejemplo manuales de usuario).

6 Evaluación del

cliente

Tareas requeridas para obtener la valoración por parte del cliente

de los resultados obtenidos.

34

2.5.3.1. Esquema de etapas

La Fig. 8 ilustra las etapas del modelo.

Figura 8. Diagrama del modelo espiral (Pressman, 2010)

2.5.4. Análisis del modelo de construcción de prototipos

y modelo espiral

A continuación en la Tabla 11 se muestran las características tomadas en cuenta para elegir el

modelo de construcción de prototipos así como el modelo evolutivo.

Tabla 11. Análisis de características de los modelos de construcción de prototipos y espiral

Característica Modelo de

Construcción de

Prototipos

Modelo Espiral

Iterativos Sí Sí

Versiones incrementales Sí Sí

Comunicación constante con el

cliente

Sí Sí

Retroalimentación del cliente Sí Sí

Demostración Sí Sí

Prototipado Sí No

Planificación Escasa Sí

Evidencia de documentación No Sí

Evaluación del cliente Sí Sí

35

Uno de los factores para elegir el modelo espiral principalmente fue el poder documentar

el análisis y diseño, así como poder mostrar al cliente las pantallas de los módulos de la

herramienta así como funcionalidad esperada, en la versión inicial para visualizar el diseño y

así obtener retroalimentación, en las iteraciones siguientes ir mejorando hasta llegar a la

versión final y completa. La constante comunicación con el cliente es importante para ir

tomando en cuenta sus observaciones.

36

2.6. Selección de Tecnología

2.6.1. Frameworks de desarrollo Web

Un framework de desarrollo web es un software que está diseñado para soportar el desarrollo

de aplicaciones web incluyendo web services, recursos web y API’s web. Permiten aliviar la

sobrecarga asociada con las actividades comunes de desarrollo web. (Wikipedia, 2017)

2.6.2. Análisis de frameworks de desarrollo web

La Tabla 12 muestra una comparación entre Django y Ruby On Rails.

Tabla 12. Comparativa entre Django y Ruby On Rails

Framework Django Ruby On Rails

Lenguaje Python Ruby

MVC Sí Sí

ORM Sí Sí

Testing Sí Sí

Migración de

BD Sí Sí

Seguridad Sí Plugin

Administración

de datos

Genera interfaz para

crear/modificar/borrar/listar ítems de una clase de objetos del modelo de

dominio a través de la clase

A través de plugins

Capacidad de

aprendizaje

Simple Sencillo de aprender

Lenguaje de alto nivel

Portable

Es mejor para alguien que ya sabe uno o dos

lenguajes de

programación

Experiencia Sí

No

De acuerdo a la experiencia que se tiene en el lenguaje Python, se eligió Django como la

mejor opción para desarrollar la herramienta.

37

2.6.3. Framework Django

Django es un framework para desarrollo de aplicaciones web gratuito y open source, escrito

en Python. Proporciona un conjunto de componentes que ayudan a desarrollar sitios web de

manera rápida y fácil. (DjangoGirls, 2017)


» Django se basa en el patrón de diseño MVC (Modelo-Vista-Controlador).

» Se enfoca en el re-uso, la conectividad y extensibilidad de componentes.

» Utiliza el desarrollo rápido y está basado en el principio DRY (“Don’t

RepeatYourself”) (“No lo repitas”).

2.6.3.2. Funcionamiento

En la Fig. 9 se ilustra el funcionamiento de Django (Infante Moreno, 2017), que utiliza

lenguaje HTML y Python; para manejo de BD utiliza SQLite, Mysql, PostgreSQL y Oracle.

(García M., 2015) En la Fig. 8 se ilustra el funcionamiento de Django.

Figura 9. Funcionamiento del Framework Django

38

» El modelo es donde se definen los datos almacenados, en forma de clases de Python.

» El controlador en Django se llama Vista (View), se presenta en forma de funciones de Python, su objetivo es el manejo de los datos que serán visualizados.

» A la vista en Django se le conoce como Plantilla (Template), es la forma de presentar los datos en lenguaje html, la plantilla recibe los datos de la vista y los organiza para

la presentación en el navegador web.

40

Capítulo 3. Metodología para el

desarrollo de la tesis

En este capítulo se describe el conjunto de pasos definidos para llevar a cabo el desarrollo de

la tesis. La Fig. 10 muestra el diagrama de la metodología para el desarrollo de la tesis.

1. Obtención del estado del arte sobre las técnicas y herramientas del área de

Gestión de Proyectos. Para lo que se realizó una búsqueda de las técnicas y

herramientas a través de una Revisión Sistemática para las áreas de Planificación

del Proyecto y Monitorización y Control del Proyecto, así como una búsqueda en

diversas fuentes a partir de un listado base para el área de Gestión de Riesgos, a

partir del cual se obtiene un listado de técnicas y herramientas. El detalle de este

paso se encuentra en el capítulo 2, sección 2.1 y 2.2.

2. Identificación y revisión de trabajos relacionados. A partir de la revisión

sistemática y la búsqueda en diversas fuentes, se eligieron un conjunto de trabajos

que muestran propuestas de técnicas y herramientas de planificación del proyecto,

monitorización y control de proyectos, así como gestión de riesgos. Se realiza un

análisis de dicho trabajos, y así mismo se examinan las características cubiertas

por los trabajos. El desarrollo de esta actividad se encuentra en el capítulo 2,

sección 2.3.

1. Obtención del estado del arte en la gestión de

proyectos

2. Identificación y Revisión de Trabajos

relacionados

3. Propuesta del Método para el desarrollo de herramientas

enfocadas en facilitar la implementación de buenas prácticas de desarrollo de

software en pymes

4. Creación de herramienta para facilitar el uso de buenas

prácticas

5.Validación de la propuesta y de la

herramienta mediante un caso de estudio

Figura 10. Metodología de desarrollo de la tesis

41

3. Propuesta del Método para el desarrollo de herramientas enfocadas en

facilitar la implementación de buenas prácticas de desarrollo de software en

pymes.

En este paso se presenta el método definido para realizar una herramienta de

buenas prácticas. El método está compuesto por seis pasos, los cuales son: 1)

Realizar una búsqueda de las técnicas y herramientas a clasificar; 2) Analizar y

clasificar las técnicas por enfoque; 3) Analizar y clasificar las técnicas por nivel de

dificultad; 4) Identificar el área de proceso en el modelo de capacidad y madurez

integrado; 5) Trazar técnicas y herramientas encontradas con las prácticas

propuestas en el modelo de capacidad y madurez integrado y 6) Creación de

herramienta. El desarrollo del método se encuentra en el capítulo 4, sección 4.1.

4. Creación de herramienta para facilitar el uso de buenas prácticas. Se

desarrolló una herramienta que facilite la implementación de buenas prácticas. La

herramienta realiza una gestión de riesgos básica, basada en el análisis hecho para

el área de gestión de riesgos. El diseño y funcionalidad de la herramienta se

describen en el capítulo 5, sección 5.2.

5. Validación de la propuesta y de la herramienta mediante un caso de estudio.

Se realizó la implementación del método tanto en el área de gestión de riesgos

como en las áreas de Planificación del Proyecto y Monitorización y Control del

Proyecto. La validación se encuentra en el Capítulo 5, secciones 5.1. También se

llevó a cabo un caso de estudio en al menos 2 empresas, la descripción de los

casos de estudio y resultados se encuentran en el Capítulo 6, sección 6.1.

42

Capítulo 4. Propuesta del Método para

el desarrollo de herramientas enfocadas

en facilitar la implementación de buenas

prácticas de desarrollo de software en

pymes

En este capítulo se describe a detalle la propuesta del método para el desarrollo de

herramientas enfocadas en facilitar la implementación de buenas prácticas de desarrollo de

software en pymes. Enseguida se muestra el análisis, diseño y desarrollo de la herramienta

que facilita la implementación de buenas prácticas.

4.1. Desarrollo del método

El método para el desarrollo de catálogos consta de 6 pasos como lo muestra la Fig. 11.

Figura 11. Diagrama del método

A continuación se describe brevemente cada uno de los pasos.

1. Realizar una búsqueda de las técnicas y herramientas a clasificar. En este

paso se realiza una búsqueda de técnicas y herramientas. Una vez encontradas las

técnicas y herramientas, se realiza una descripción de cada una de ellas.

1. Realizar una búsqueda de las T&H a

clasificar

2. Analizar y clasificar las T&H por enfoque

3. Analizar y clasificar las T&H por nivel de

dificultad

4. Identificar el área de proceso en el modelo de

capacidad y madurez integrado

5. Trazar T&H encontradas con las

prácticas propuestas en el modelo de capacidad

y madurez integrado

6. Creación de la herramienta que facilita

la implementación de buenas prácticas

43

2. Análisis y clasificación de técnicas y herramientas por enfoque. En este paso

las técnicas y herramientas se analizan a detalle, se describen y se clasifican por

enfoque. Para este trabajo enfoque es una forma de valoración o consideración de

algún aspecto. Los enfoques considerados son: personas/matemático/visual.

1) Enfoque a personas (P): aquellas técnicas o herramientas que se centran en la

participación directa o indirecta de las personas.

a) Participación directa (D), se refiere a la participación presencial de las

personas para la realización de alguna actividad.

b) Participación indirecta (I), se refiere a la participación del personal a través

del uso de una aplicación software.

2) Enfoque matemático (M): aquellas técnicas o herramientas que se centran en el

uso de fórmulas matemáticas para la gestión de riesgos.

3) Enfoque visual (V): aquellas técnicas o herramientas que se centran en la

presentación gráfica del análisis de riesgos para la gestión de riesgos.

El procedimiento para realizar la clasificación de las técnicas y herramientas

consiste en revisar el objetivo, los componentes y el formato que la técnica o

herramienta utiliza para mostrar resultados. Así como los requisitos de

conocimiento para su uso. Este procedimiento se siguió para cada técnica y

herramienta.

3. Análisis y clasificación de técnicas y herramientas por nivel de dificultad. En

este paso las técnicas y herramientas se analizan, se describen y se clasifican por

nivel de dificultad. Para este trabajo dificultad se refiere al conocimiento requerido

en el área enfocada para ejecutar la técnica y herramienta. Los niveles de

dificultad considerados son: complejas/intermedias/sencillas.

1) Complejas (C): aquellas técnicas o herramientas que requieren conocimiento

especializado de implementar en las áreas de gestión de riesgos, planificación

del proyecto y monitorización y control del proyecto, por lo tanto, se considera

difícil o compleja.

2) Intermedias (I): aquellas técnicas o herramientas que requieren de

conocimiento básico en las áreas de planificación del proyecto y

monitorización y control del proyecto, para su realización, por lo tanto, se

considera que tienen un nivel de dificultad intermedio.

3) Sencillas (S): aquellas técnicas o herramientas que no requieren conocimiento

previo especializado en las áreas de planificación del proyecto y

monitorización y control del proyecto, por lo tanto tienden a ser fáciles de

implementar.

El procedimiento para realizar la clasificación de las técnicas y herramientas

consiste en revisar las instrucciones para ejecutar la técnica o el manual de

usuario de la herramienta. Así como los requisitos de conocimiento para su

uso. Este procedimiento se siguió por cada técnica y herramienta.

44

4. Identificación de las áreas de proceso de Gestión de Proyectos en el modelo de

capacidad y madurez integrado. Se analiza el modelo CMMI (Chrissis et al.,

2010) para identificar las áreas de proceso relacionadas con el proceso enfocado.

Es importante mencionar que se eligió el modelo CMMI al ser un modelo

ampliamente aceptado a nivel mundial, además de contener un conjunto de buenas

prácticas que han demostrado un rendimiento efectivo y probado en otras

organizaciones permitiendo abarcar un mayor número de prácticas de ingeniería

de software.

Se identifican las metas específicas (SG) del área de proceso, así como el

propósito y las prácticas específicas (SP) del área.

5. Trazabilidad de los métodos, técnicas y herramientas encontradas con las

buenas prácticas del área de conocimiento del modelo de capacidad y

madurez integrado. Se realiza una trazabilidad de las técnicas y herramientas con

las prácticas específicas del área de proceso enfocado, para identificar su cobertura

y cumplimiento. Para realizar este análisis se toman como base las metas y

prácticas específicas de CMMI-Dev v.1.3 (Chrissis et al., 2010) del área de

proceso enfocada.

6. Creación de herramienta que facilita la implementación de buenas prácticas.

Se desarrollará una herramienta que facilite la implementación de buenas prácticas

de ingeniería de software basada en el análisis realizado para el área enfocada.

46

Capítulo 5. Validación del método

Este capítulo muestra los resultados de las dos validaciones realizadas al método:

1) Implementación del método (Capítulo 4, sección 4.1, Fig. 12) en las áreas de:

» Gestión de riesgos

» Planificación del proyecto, así como monitorización y control del proyecto.

2) Validación de la herramienta que facilita la implementación de buenas prácticas en el

área de gestión de riesgos a través de un caso de estudio.

5.1. Implementación del método en tres áreas

5.1.1. Gestión de Riesgos

A continuación se presenta la implementación del método propuesto para el área de

gestión de riesgos.

Paso 1. Realizar una búsqueda de las técnicas y herramientas a clasificar. En este paso se

realizó una búsqueda de técnicas y herramientas de la gestión de riesgos, se tomó como

fuente la documentación de modelos como CMMI-DEV v1.3(Chrissis et al., 2010), PMBOK

(Project Management Institute, 2013), la metodología MAGERIT(Ministerio de Hacienda y

Administraciones Públicas, 2012b)(Ministerio de Hacienda y Administraciiones Públicas,

2012a)(Ministerio de Hacienda y Administraciones Públicas, 2012c), el modelo eSourcing

Capability Model for Client Organizations – eSCM-CL (Hefley & Loesche, 2006), el

estándar de la taxonomía de riesgos de IEEE(Engineering & Committee, 2001). Una vez

encontradas las técnicas y herramientas, se realiza una descripción de cada una de ellas,

obteniendo una selección de 28 técnicas y herramientas.

En la Tabla 13 se presenta el listado de 28 técnicas/herramientas encontradas para el

área de gestión de riesgos.

47

Tabla 13. Listado de técnicas/herramientas del área de Gestión de riesgos

No. Técnica/Herramienta No. Técnica/Herramienta

1 Enfoque informal (McManus,

2012)

15 Tormenta de ideas (Harris &

Arbeitstechniken, 2015)

2 Enfoque periódico (McManus,

2012)

16 Taxonomía (Carr et al., 1993;

Chrissis et al., 2010; Engineering

& Committee, 2001)

3 Enfoque formal (McManus, 2012) 17 Lecciones aprendidas (Engineering

& Committee, 2001)

4 Lista de riesgos (McManus, 2012) 18 Análisis de escenarios

(Engineering & Committee, 2001;

Fischer, 2011)

5 Análisis de estrategia de riesgos

(McManus, 2012)

19 Hoja de cálculo (Chrissis et al.,

2010)

6 Diagrama de dependencia entre

activos (Públicas, 2012b, 2012c)

20 Relación de activos a considerar

(Chrissis et al., 2010; Públicas,

2012b, 2012c)

7 Enfoque ad-hoc (McManus, 2012) 21 Lista de acción de riesgos

(McManus, 2012)

8 Catálogos de amenazas (Chrissis

et al., 2010; Públicas, 2012a)

22 Análisis mediante tablas (Chrissis

et al., 2010; Públicas, 2012b,

2012c)

9 Árboles de ataque (Públicas,

2012a)

23 Análisis algorítmico (Públicas,

2012b, 2012c)

10 Entrevistas (Públicas, 2012a) 24 Técnicas gráficas (Públicas, 2012b,

2012c)

11 Reuniones (Públicas, 2012a) 25 Modelo de estrategia de riesgos

(McManus, 2012)

12 Valoración Delphi (Públicas,

2012a)

26 Matriz de priorización de historias

de riesgo (Arora & Naresh, 2014)

13 Documentar la política de gestión

del riesgo (Hefley & Loesche,

2006)

27 Técnica de burn-down de riesgos

(Singh & Saxena, 2014)

14 Cuestionarios (Accountants, 2007;

Engineering & Committee, 2001)

28 Tablero de riesgos con dos tipos de

notas (Ylimannela, 2012)

48

Paso 2. Análisis y clasificación de técnicas y herramientas por Enfoque. En este paso las

técnicas y herramientas se analizaron a detalle, se describieron y se clasificaron de acuerdo a

tres enfoques: personas, matemático y visual.

El procedimiento para realizar la clasificación de las técnicas y herramientas consistió

en revisar el objetivo, los componentes y el formato que la técnica o herramienta utiliza para

mostrar resultados. Este procedimiento se siguió para cada técnica y herramienta

seleccionada.

A continuación en la Tabla 14 se muestran los resultados de análisis y clasificación de

técnicas/herramientas por enfoque.

Tabla 14. Clasificación por enfoque de técnicas/herramientas del área de Gestión de riesgos

Id Técnica/Herramienta

Enfoque

P V M

D I

1 Enfoque informal X

2 Enfoque periódico X

3 Enfoque formal X

4 Lista de riesgos X

5 Análisis de estrategia de riesgos X

6 Diagrama de dependencia entre activos X

7 Enfoque ad-hoc X

8 Catálogo de amenazas X

9 Árboles de ataque X

10 Entrevistas X

11 Reuniones X

12 Valoración Delphi X

13 Documentar la política de gestión del riesgo X

14 Cuestionarios X

15 Tormenta de ideas X

16 Taxonomía X

17 Lecciones aprendidas X

18 Análisis de escenarios X

19 Hoja de cálculo X

20 Relación de activos a considerar X

21 Lista de acción de riesgos

22 Análisis mediante tablas X

23 Análisis algorítmico X

24 Técnicas gráficas X

25 Modelo de estrategia de riesgos X

26 Matriz de priorización de historias de riesgo X

27 Técnica de burn-down de riesgos X

28 Tablero de riesgos con dos tipos de notas X

49

Paso 3. Análisis y clasificación de técnicas y herramientas por nivel de dificultad. En este

paso las técnicas y herramientas se analizaron, se describieron y se clasificaron por nivel de

dificultad, considerando tres niveles: complejas, intermedias y sencillas.

El procedimiento para realizar la clasificación de las técnicas y herramientas consiste en

revisar las instrucciones para ejecutar la técnica o el manual de usuario de la herramienta. Así

como los requisitos de conocimiento para su uso. Este procedimiento se siguió por cada

técnica y herramienta seleccionada. A continuación se muestra el análisis y clasificación en la

Tabla 15.

Tabla 15. Clasificación por nivel de dificultad de técnicas/herramientas del área de Gestión de

Riesgos


Dificultad

S I C

1 Enfoque informal X

2 Enfoque periódico X

3 Enfoque formal X

4 Lista de riesgos X

5 Análisis de estrategia de riesgos X

6 Diagrama de dependencia entre activos X

7 Enfoque ad-hoc X

8 Catálogo de amenazas X

9 Árboles de ataque X

10 Entrevistas X

11 Reuniones X

12 Valoración Delphi X

13 Documentar la política de gestión del riesgo X

14 Cuestionarios X


16 Taxonomía X

17 Lecciones aprendidas X

18 Análisis de escenarios X

19 Hoja de cálculo X

20 Relación de activos a considerar X

21 Lista de acción de riesgos X

22 Análisis mediante tablas X

23 Análisis algorítmico X

24 Técnicas gráficas X

25 Modelo de estrategia de riesgos X

26 Matriz de priorización de historias de riesgo X

27 Técnica de burn-down de riesgos X

28 Tablero de riesgos con dos tipos de notas X

50

Paso 4. Identificación de las áreas de proceso de Gestión de Proyectos del modelo de

capacidad y madurez integrado. Se analiza el modelo CMMI (Chrissis et al., 2010) para

identificar las áreas de proceso relacionadas con el proceso enfocado. Es importante

mencionar que se eligió el modelo CMMI al ser un modelo ampliamente aceptado en el

mundo, además de contener un conjunto de buenas prácticas que han demostrado un

rendimiento efectivo y probado en otras organizaciones permitiendo abarcar un mayor

número de prácticas de ingeniería de software.

Se identificaron las metas específicas (SG) del área de proceso, así como el propósito y las

prácticas específicas (SP) del área de Gestión de Riesgos. Esta área de proceso está formada

por 3 metas específicas (SG) y 7 prácticas específicas como a continuación se detalla:

1) SG 1. Preparar la gestión de riesgos: Se establece y mantiene una estrategia para

identificar, analizar y mitigar los riesgos, dicha estrategia se documenta en un plan

de gestión de riesgos.

Incluye las siguientes prácticas específicas:

1.1) Determinar las fuentes y las categorías de riesgos,

1.2) Definir los parámetros de riesgos y

1.3) Establecer una estrategia de gestión de riesgos.

2) SG 2. Identificar y analizar los riesgos: Se identifican los riesgos de las fuentes

internas y externas, se evalúan para determinar su probabilidad y consecuencias y se

clasifican para permitir su tratamiento.


2.1) Identificar los riesgos y

2.2) Evaluar, clasificar y priorizar los riesgos.

3) SG 3. Mitigar los riesgos: Se desarrollan e implementan planes de mitigación para

reducir el impacto de ocurrencia del riesgo y planes de contingencia para tratar con

el impacto de los riesgos que pueden ocurrir aun cuando se intentaron mitigarlos.


3.1) Desarrollar los planes de mitigación de riesgos y

3.2) Implementar los planes de mitigación de riesgos.

Paso 5. Trazabilidad de los métodos, técnicas y herramientas encontradas con las

buenas prácticas del área de conocimiento del modelo de capacidad y madurez

integrado. Se realizó una trazabilidad de las técnicas y herramientas encontradas con las

prácticas específicas del área de gestión de riesgos de CMMI-Dev v.1.3 (Chrissis et al., 2010)

identificadas en el paso anterior, para identificar su cobertura y cumplimiento. La trazabilidad

entre prácticas y técnicas y herramientas se muestra en la Tabla 16.

51

La trazabilidad ha sido validada por un grupo de cuatro investigadores, dos investigadores

del grupo de mejora de procesos de la Unidad de Zacatecas del Centro de Investigación en

Matemáticas (CIMAT) y dos investigadores de la Universidad de Medellín (UdeM).

El proceso de validación consiste en dos pasos: el envío de la trazabilidad a cada

investigador para su revisión previa y la realización de reuniones. Resultado de la validación,

la trazabilidad se ha refinado con los comentarios de los 4 investigadores.

5.1.1.1. Hallazgos de la trazabilidad de Gestión de Riesgos

La trazabilidad mostrada en la Tabla 16, muestra las técnicas y herramientas para la gestión

de riesgos y su relación (cobertura o cumplimiento) con las prácticas específicas (SP) de

CMMI-DEV v1.3 (Chrissis et al., 2010).

A continuación se mencionan los principales hallazgos logrados mediante el uso del

método:

5.1.1.1.1 Técnicas y herramientas con mayor cobertura de SP

A partir de la trazabilidad realizada, se identificó que las técnicas documentar la política de

gestión de riesgo y lecciones aprendidas son las que cubren el 100% de las prácticas

específicas de la gestión de riesgos. Enseguida se encuentran las técnicas de tormenta de

ideas y enfoque formal con un porcentaje de cobertura de prácticas específicas de 57% y por

último se encuentran las técnicas de valoración Delphi, análisis de escenarios y tablero de

riesgos con dos tipos de notas con un porcentaje de cobertura de prácticas específicas de

43%.

Para determinar la cobertura de SP por técnica, se realizó una fórmula en donde la cobertura

(C) es igual a la sumatoria del número de SP que la técnica cubre por 100 entre el número

total de SP, a continuación se muestra la fórmula en (1):

(1)

Dónde: C= cobertura en %,

Ʃ= sumatoria,

n= número de SP,

i= técnica,

N= número total de SP.

52

5.1.1.1.2 La práctica específica con mayor cobertura por las técnicas y

herramientas

A partir de la trazabilidad realizada, se identificó que la práctica específica que cuenta con la

mayor cantidad de técnicas y herramientas es la SP 2.2 evaluar, clasificar y priorizar los

riesgos con un porcentaje de 53% de cobertura de técnicas y herramientas, enseguida se ubica

la SP 2.1 identificar los riesgos con un porcentaje de 46% de cobertura de técnicas y

herramientas y finalmente se encuentra la SP 1.1 determinar las fuentes y categorías de

riesgos con un porcentaje de cobertura de técnicas y herramientas de 43%.

Para determinar la cobertura de técnicas por SP se realizó una fórmula en donde la

cobertura (C) es igual a la sumatoria del número de técnicas que la SP cubre por 100 entre el

número total de técnicas, a continuación se muestra la fórmula en (2):

(2)

Dónde: C= cobertura en %,

Ʃ= sumatoria,

n= número de técnicas,

i= SP,

N= número total de técnicas.

Paso 6. Creación de herramienta. Como alternativa a la selección de técnicas y

herramientas específicas, se desarrolló una herramienta que facilita la implementación de

buenas prácticas de ingeniería de software basada en el análisis de cobertura de prácticas y de

elementos realizado en esta sección. En este punto se describen los elementos requeridos de

la técnica o herramienta para realizar una gestión de riesgos básica.

Se identificaron técnicas y herramientas que son de especial importancia para cumplir

algunas SP específicas de la gestión de riesgos, las cuales se mencionan a continuación:

1) Técnica de taxonomía de riesgos: A través de la taxonomía se puede establecer un

listado de fuentes y categorías de riesgos, así como establecer un listado de riesgos.

2) Técnica de entrevistas: Permite reunir información de todas las partes interesadas en

el proyecto para determinar las fuentes y categorías de riesgos, así como reunir

información para identificar los riesgos.

53

3) Técnica de cuestionarios: Permiten obtener información de la empresa y del

proyecto.

4) Técnicas de análisis mediante Tablas: Permiten evaluar y priorizar los riesgos.

5) Técnica de tormenta de ideas: Esta técnica consiste en la aportación de ideas, lo que

puede contribuir a: establecer los parámetros de impacto y probabilidad, valorar los

riesgos, así como agregar acciones de mitigación y la identificación del responsable

del riesgo.

6) Técnica de Valoración Delphi: Permite analizar los riesgos y agregar acciones de

mitigación/contención así como la identificación del responsable del riesgo.

7) Técnica de planning poker: Permite realizar una votación de los valores de riesgos

gestionados de forma colaborativa y ágil.

El diseño y la funcionalidad de la herramienta se describen a detalle en el presente

capítulo, sección 5.2.

54

Tabla 16. Trazabilidad entre prácticas específicas de CMMI y técnicas y

herramientas del área Gestión de Riesgos

55

5.1.2. Planificación del Proyecto, Monitorización y

Control del Proyecto

A continuación se presenta la implementación del método propuesto para las áreas de

planificación del proyecto, así como monitorización y control del proyecto.

Paso 1. Realizar una búsqueda de las técnicas y herramientas a clasificar. En este paso se

realizó una búsqueda de técnicas y herramientas, mediante una revisión sistemática así como

búsqueda en diversas fuentes. Una vez encontradas las técnicas y herramientas, se realiza una

descripción de cada una de ellas. En total se encontraron 102 T&H. En la Tabla 17 se

muestran 83 técnicas/herramientas del área de planificación del proyecto y en la Tabla 18 se

muestran 35 técnicas/herramientas del área de monitorización y control del proyecto.

Tabla 17. Listado de técnicas y herramientas del área de Planificación del Proyecto

Id Técnica/Herramienta Id Técnica/Herramienta Id Técnica/Herramienta

1 Descomposición (WBS)

(PBS) (Chrissis et al.,

2010; Jacobs & Schenker,

2008; Project

Management Institute,

2000; Schenker, 2008;

Tomayko & Hallman,

1989)

29 Taxonomías de riesgos

(Chrissis et al., 2010;

Project Management

Institute, 2000)

57 Negociación (Chrissis et

al., 2010; Project


2000)

2 Juicio experto (Chrissis et

al., 2010; Dagnino, 2010;

Project Management

Institute, 2000; Torrecilla-

Salinas, Sedeño, Escalona,

& Mejías, 2015)

30 Evaluaciones de riesgos


Project Management

Institute, 2000)

58 Adquisición (Chrissis et

al., 2010; Project


2000)

3 Planificación gradual

(Chrissis et al., 2010)

31 Listas de comprobación


Project Management

Institute, 2000)

59 Equipos virtuales


Project Management

Institute, 2000)

4 Reuniones (Chrissis et al.,

2010; Project


2000; Schenker, 2008)

32 Entrevistas estructuradas


Project Management

Institute, 2000)

60 Análisis de decisión

multi-criterios (Chrissis

et al., 2010; Project


2000)

5 PROBE (Chrissis et al.,

2010) 33 Tormenta de ideas

(Chrissis et al., 2010) 61 Formación interna


Project Management

Institute, 2000)

6 Puntos de función

(Bundschuh & Carol,

2008; Chrissis et al., 2010;

Tomer, 2015; Torrecilla-

Salinas et al., 2015)

34 Análisis del factor de

calidad (Chrissis et al.,

2010; Project


2000)

62 Formación externa


Project Management

Institute, 2000)

7 Técnica Delphi (Chrissis 35 Revisión estructurada de 63 Contratación de personal

56

et al., 2010; Dagnino,

2010; Torrecilla-Salinas et

al., 2015)

documentación (Chrissis



2000)


Project Management

Institute, 2000)

8 Proxy (Bundschuh &

Carol, 2008; Chrissis et

al., 2010; Dagnino, 2010)

36 Técnicas de recolección

de información (Chrissis



2000)

64 Habilidades

interpersonales (Chrissis



2000)

9 COCOMO II (Chrissis et

al., 2010; Tomayko &

Hallman, 1989; Tomer,


al., 2015)

37 Análisis de supuestos


Project Management

Institute, 2000)

65 Entrenamiento

(capacitación) (Chrissis



2000)

10 SEER-SEM (Self Service

Estimation Model)

(Clifford, 2014)

38 Técnicas de

diagramación (Chrissis et

al., 2010; Project


2000)

66 Actividades de

construcción de equipos


Project Management

Institute, 2000)

11 Estimación por analogía

(Dagnino, 2010; Project



al., 2015)

39 Análisis de fortalezas,

oportunidades,

debilidades y amenazas

FODA (SWOT) (Chrissis



2000)

67 Reglas del juego (Project


2000)

12 Estimaciones paramétricas

(Project Management

Institute, 2000)

40 Evaluación de

probabilidad e impacto

de riesgos (Chrissis et al.,

2010; Project


2000)

68 Colocación (Project


2000)

13 Técnicas de toma de

decisiones grupal (Project


2000)

41 Matriz de probabilidad e

impacto de riesgos


Project Management

Institute, 2000)

69 Reconocimiento y

recompensas (Project


2000)

14 Análisis de reserva

(Project Management

Institute, 2000)

42 Evaluación de calidad de

datos de riesgos (Chrissis



2000)

70 Herramientas de

evaluación de personal


Project Management

Institute, 2000)

15 Estimación de abajo hacia

arriba (Bottom-Up)

(Dagnino, 2010; Project


2000)

43 Categorización de riesgos


Project Management

Institute, 2000)

71 Análisis de Hacer o

Comprar (Chrissis et al.,

2010; Project


2000)

16 Planning Poker

(Torrecilla-Salinas et al.,

2015)

44 Evaluación de urgencia

de riesgos (Chrissis et al.,

2010; Project


2000)

72 Investigación de Mercado


Project Management

Institute, 2000)

17 Planning Game

(Torrecilla-Salinas et al.,

2015)

45 BD electrónicas (Chrissis

et al., 2010) 73 Conferencias ofrecidas


Project Management

Institute, 2000)

57

18 Blitz Planning (Torrecilla-

Salinas et al., 2015) 46 Repositorios (Chrissis et

al., 2010) 74 Técnicas de evaluación

propuestas (Chrissis et

al., 2010; Project


2000)

19 Método del camino crítico

(CPM) (Chrissis et al.,

2010; Project


2000; Tomayko &

Hallman, 1989)

47 Análisis de

requerimientos de

comunicación (Chrissis



2000)

75 Publicidad (Chrissis et

al., 2010; Project


2000)

20 Técnica de evaluación y

revisión del programa

(PERT) (Chrissis et al.,

2010; Project


2000; Rivas et al., 2010;

Tomayko & Hallman,

1989)

48 Tecnología de




2000)

76 Negociaciones de

adquisiciones (Chrissis et

al., 2010; Project


2000)

21 Técnicas analíticas


Project Management

Institute, 2000)

49 Modelos de




2000)

77 Análisis de las partes

interesadas relevantes


Jacobs & Schenker,

2008; Project


2000)

22 Método de diagramación

de precedencia (PDM)


Project Management

Institute, 2000)

50 Métodos de




2000)

78 Habilidades de gestión


Project Management

Institute, 2000)

23 Determinación de

dependencias (Chrissis et

al., 2010; Project


2000)

51 Sistemas de Gestión de

Información (Chrissis et

al., 2010; Project


2000)

79 Software para

administración de

proyectos, dotProject,

Basecamp, MS Project


Project Management

Institute, 2000; Rivas et

al., 2010; Tomayko &

Hallman, 1989;

Wangenheim et al., 2009)

24 Análisis de red del

calendario (Chrissis et al.,

2010; Project


2000)

52 Análisis de alternativas


Project Management

Institute, 2000)

80 Técnicas de facilitación


Project Management

Institute, 2000)

25 Método de cadena

crítica(Chrissis et al.,

2010; Jacobs & Schenker,

2008; Project


2000)

53 Gráficas de organización

y descripciones de

posición (Gantt) (Chrissis

et al., 2010; Jacobs &

Schenker, 2008; Project


2000)

81 Checklist de revisión


Project Management

Institute, 2000;

Torrecilla-Salinas,

Sedeño, Escalona, &

Mejías, 2015)

26 Técnicas de optimización

de recursos (Chrissis et

al., 2010; Project

54 Networking (Chrissis et

al., 2010; Project


82 Prácticas de recursos

humanos (Chrissis et al.,

2010; Project

58


2000)

2000) Management Institute,

2000)

27 Técnicas de modelado


Project Management

Institute, 2000)

55 Teoría organizacional


Project Management

Institute, 2000)

83 Identificación de

alternativas (Chrissis et

al., 2010; Project


2000)

28 Herramienta de

calendarización (Chrissis



2000)

56 Pre-asignaciones


Project Management

Institute, 2000)

Tabla 18. Listado de técnicas y herramientas del área de Monitorización y Control del Proyecto

Id Técnica/Herramienta Id Técnica/Herramienta Id Técnica/Herramienta

1 Juicio experto


Dagnino, 2010; Project


2000; Torrecilla-

Salinas et al., 2015)

13

Habilidades interpersonales

(Chrissis et al., 2010; Project

Management Institute, 2000) 25

Observación y

conversación (Chrissis



2000)

2 Reuniones (Chrissis et

al., 2010; Project


2000; Schenker, 2008)

14 Negociaciones de adquisiciones


Management Institute, 2000)

26

Evaluaciones de

rendimiento del

proyecto (Chrissis et

al., 2010; Project


2000)

3 Análisis de reserva

(Project Management

Institute, 2000)

15 Habilidades de gestión (Chrissis

et al., 2010; Project Management

Institute, 2000) 27

Gestión del conflicto


Project Management

Institute, 2000)

4 Técnicas analíticas


Project Management

Institute, 2000)

16 Software para administración de

proyectos, dotProject, Basecamp,

MS Project (Chrissis et al.,

2010; Project Management

Institute, 2000; Rivas et al.,

2010; Tomayko & Hallman,

1989; Wangenheim et al., 2009)

28

Reporte de

rendimiento (Chrissis



2000)

5 Técnicas de

optimización de

recursos (Chrissis et

al., 2010; Project


2000)

17

Gestión del valor ganado

(Chrissis et al., 2010; Cuadrado-

García, Cuadrado-Gallego,

Herranz-Martínez, & Rodríguez-

Soria, 2011; Dagnino, 2010;

Plaza & Turetken, 2009; Project

Management Institute, 2000;

Schenker, 2008; Tomer, 2015)

29

Sistemas de pago


Project Management

Institute, 2000)

6 Técnicas de modelado


Project Management

Institute, 2000)

18

Análisis de varianza (Chrissis et

al., 2010; Project Management

Institute, 2000) 30

Administración de

compromisos (Chrissis



2000)

7 Herramienta de 19 Revisiones del desempeño 31 Auditorías de riesgos

59

calendarización


Project Management

Institute, 2000)




Project Management

Institute, 2000)

8 Revisión estructurada

de documentación


Project Management

Institute, 2000)

20

Inspecciones y auditorías



32

Medida de rendimiento

técnico (Chrissis et al.,

2010; Project


2000)

9 Evaluación de calidad

de datos de riesgos


Project Management

Institute, 2000)

21

Análisis de tendencias (Chrissis

et al., 2010; Project Management

Institute, 2000)

33

Revisiones periódicas

de riesgos del proyecto


Project Management

Institute, 2000)

10 Evaluación de

urgencia de riesgos


Project Management

Institute, 2000)

22

Herramientas de control de

cambios (Chrissis et al., 2010;

Project Management Institute,

2000)

34

Revisiones periódicas

de gestión de los datos

del proyecto (Chrissis



2000)

11 Métodos de

comunicación


Project Management

Institute, 2000)

23

Muestreo estadístico (Chrissis et

al., 2010; Project Management

Institute, 2000) 35

Revisiones formales


Project Management

Institute, 2000)

12 Sistemas de Gestión de

Información (Chrissis



2000)

24

Revisión de solicitudes de

cambio aprobadas (Chrissis et al.,

2010; Project Management

Institute, 2000)

Paso 2. Análisis y clasificación de técnicas y herramientas por enfoque. En este paso las

técnicas y herramientas se analizaron a detalle y se clasificaron de acuerdo a tres criterios:

personas (P), matemático (M) y visual (V).

El procedimiento para realizar la clasificación de las técnicas y herramientas consiste

en revisar el objetivo, los componentes y el formato que la técnica o herramienta utiliza para

mostrar resultados. Este procedimiento se siguió para cada técnica y herramienta

seleccionada.

Los resultados del análisis y clasificación de técnicas y herramientas por enfoque del

área de Planificación del Proyecto se muestran en la Tabla 19 del área de Monitorización y

Control del Proyecto se muestran en la Tabla 20.

Tabla 19. Clasificación de técnicas y herramientas del área de Planificación del Proyecto por

enfoque


Enfoque

P V M

D I

60

1 Descomposición (WBS) (PBS) X

2 Juicio experto X

3 Planificación gradual X

4 Reuniones X

5 PROBE X

6 Puntos de función X

7 Técnica Delphi X

8 Proxy X

9 COCOMO II X

10 SEER-SEM (Self Service Estimation Model) X

11 Estimación por analogía X

12 Estimaciones paramétricas X

13 Técnicas de toma de decisiones grupal X

14 Análisis de reserva X

15 Estimación de abajo hacia arriba (Bottom-Up) X

16 Planning Poker X

17 Planning Game X

18 Blitz Planning X

19 Método del camino crítico (CPM) X

20 Técnica de evaluación y revisión del programa

(PERT)

X

21 Técnicas analíticas X

22 Método de diagramación de precedencia

(PDM)

X

23 Determinación de dependencias X

24 Análisis de red del calendario X

25 Método de cadena crítica X

26 Técnicas de optimización de recursos X

27 Técnicas de modelado X

28 Herramienta de calendarización X

29 Taxonomías de riesgos X

30 Evaluaciones de riesgos X

31 Listas de comprobación X

32 Entrevistas estructuradas X


34 Análisis del factor de calidad X

35 Revisión estructurada de documentación X

36 Técnicas de recolección de información X

37 Análisis de supuestos X

38 Técnicas de diagramación X

39 Análisis de fortalezas, oportunidades,

debilidades y amenazas FODA (SWOT)

X

40 Evaluación de probabilidad e impacto de

riesgos

X

41 Matriz de probabilidad e impacto de riesgos X

42 Evaluación de calidad de datos de riesgos X

43 Categorización de riesgos X

44 Evaluación de urgencia de riesgos X

61

45 BD electrónicas X

46 Repositorios X

47 Análisis de requerimientos de comunicación X

48 Tecnología de comunicación X

49 Modelos de comunicación X

50 Métodos de comunicación X

51 Sistemas de Gestión de Información X

52 Análisis de alternativas X

53 Gráficas de organización y descripciones de

posición (Gantt)

X

54 Networking X

55 Teoría organizacional X

56 Pre-asignaciones X

57 Negociación X

58 Adquisición X

59 Equipos virtuales X

60 Análisis de decisión multi-criterios

61 Formación interna X

62 Formación externa X

63 Contratación de personal X

64 Habilidades interpersonales X

65 Entrenamiento (capacitación) X

66 Actividades de construcción de equipos X

67 Reglas del juego X

68 Colocación X

69 Reconocimiento y recompensas X

70 Herramientas de evaluación de personal X

71 Análisis de Hacer o Comprar X

72 Investigación de Mercado X

73 Conferencias ofrecidas X

74 Técnicas de evaluación propuestas X

75 Publicidad X

76 Negociaciones de adquisiciones X

77 Análisis de las partes interesadas relevantes X

78 Habilidades de gestión X

79 Software para administración de proyectos,

dotProject, Basecamp, MS Project

X

80 Técnicas de facilitación X

81 Checklist de revisión X

82 Prácticas de recursos humanos X

83 Identificación de alternativas X

Tabla 20. Clasificación de técnicas y herramientas del área de Monitorización y Control del

Proyecto por enfoque

Id Técnica/Herramienta Enfoque

P V M

62

D I

1 Juicio experto X

2 Reuniones X















dotProject, Basecamp, MS Project

X

17 Gestión del valor ganado X

18 Análisis de varianza X

19 Revisiones del desempeño X

20 Inspecciones y auditorías X

21 Análisis de tendencias X

22 Herramientas de control de cambios X

23 Muestreo estadístico X

24 Revisión de solicitudes de cambio aprobadas X

25 Observación y conversación X

26 Evaluaciones de rendimiento del proyecto X

27 Gestión del conflicto X

28 Reporte de rendimiento X

29 Sistemas de pago X

30 Administración de compromisos X

31 Auditorías de riesgos X

32 Medida de rendimiento técnico X

33 Revisiones periódicas de riesgos del

proyecto

X

34 Revisiones periódicas de gestión de los

datos del proyecto

X

35 Revisiones formales X

63

Paso 3. Análisis y clasificación de técnicas y herramientas por nivel de dificultad. En este

paso las técnicas y herramientas se analizaron, se describieron y se clasificaron por nivel de

dificultad, considerando tres niveles: complejas (C), intermedias (I) y sencillas (S).

El procedimiento para realizar la clasificación de las técnicas y herramientas consiste

en revisar las instrucciones para ejecutar la técnica o el manual de usuario de la herramienta.

Así como los requisitos de conocimiento para su uso. Este procedimiento se siguió por cada

técnica y herramienta.

Los resultados del análisis y clasificación de técnicas y herramientas por nivel de

dificultad para el área de Planificación del Proyecto se muestran en la Tabla 21, así como el

análisis y clasificación de técnicas y herramientas por nivel de dificultad para el área de

Monitorización y Control del Proyecto se muestran en la Tabla 22.

Tabla 21. Clasificación de técnicas y herramientas del área de Planificación del Proyecto por

nivel de dificultad


Dificultad

S I C

1 Descomposición (WBS) (PBS)

2 Juicio experto X

3 Planificación gradual X

4 Reuniones X

5 PROBE X

6 Puntos de función X

7 Técnica Delphi X

8 Proxy X

9 COCOMO II X

10 SEER-SEM (Self Service Estimation Model) X

11 Estimación por analogía X

12 Estimaciones paramétricas X

13 Técnicas de toma de decisiones grupal X


15 Estimación de abajo hacia arriba (Bottom-Up) X

16 Planning Poker X

17 Planning Game X

18 Blitz Planning X

19 Método del camino crítico (CPM) X

20 Técnica de evaluación y revisión del programa

(PERT) X


22 Método de diagramación de precedencia

(PDM) X

23 Determinación de dependencias X

24 Análisis de red del calendario X

25 Método de cadena crítica X

64




29 Taxonomías de riesgos X

30 Evaluaciones de riesgos X

31 Listas de comprobación X

32 Entrevistas estructuradas X


34 Análisis del factor de calidad X


36 Técnicas de recolección de información X

37 Análisis de supuestos X

38 Técnicas de diagramación X

39 Análisis de fortalezas, oportunidades,

debilidades y amenazas FODA (SWOT) X

40 Evaluación de probabilidad e impacto de

riesgos X

41 Matriz de probabilidad e impacto de riesgos X


43 Categorización de riesgos X


45 BD electrónicas X

46 Repositorios X

47 Análisis de requerimientos de comunicación X

48 Tecnología de comunicación X

49 Modelos de comunicación X



52 Análisis de alternativas X

53 Gráficas de organización y descripciones de

posición (Gantt) X

54 Networking X

55 Teoría organizacional X

56 Pre-asignaciones X

57 Negociación X

58 Adquisición X

59 Equipos virtuales X

60 Análisis de decisión multi-criterios X

61 Formación interna

62 Formación externa X

63 Contratación de personal X


65 Entrenamiento (capacitación) X

66 Actividades de construcción de equipos X

67 Reglas del juego X

68 Colocación X

69 Reconocimiento y recompensas X

70 Herramientas de evaluación de personal X

65

71 Análisis de Hacer o Comprar X

72 Investigación de Mercado X

73 Conferencias ofrecidas X

74 Técnicas de evaluación propuestas X

75 Publicidad X


77 Análisis de las partes interesadas relevantes X



dotProject, Basecamp, MS Project X

80 Técnicas de facilitación X

81 Checklist de revisión X

82 Prácticas de recursos humanos X

83 Identificación de alternativas X

Tabla 22. Clasificación de técnicas y herramientas del área de Monitorización y Control del

Proyecto por nivel de dificultad


Dificultad

S I C

1 Juicio experto X

2 Reuniones X















dotProject, Basecamp, MS Project X

17 Gestión del valor ganado X 18 Análisis de varianza X

19 Revisiones del desempeño X

20 Inspecciones y auditorías X

21 Análisis de tendencias X

22 Herramientas de control de cambios X

23 Muestreo estadístico X

24 Revisión de solicitudes de cambio aprobadas X

66

25 Observación y conversación X

26 Evaluaciones de rendimiento del proyecto X 27 Gestión del conflicto X

28 Reporte de rendimiento X

29 Sistemas de pago X

30 Administración de compromisos X

31 Auditorías de riesgos X

32 Medida de rendimiento técnico X

33 Revisiones periódicas de riesgos del

proyecto X

34 Revisiones periódicas de gestión de los

datos del proyecto X

35 Revisiones formales X

Paso 4. Identificación de las áreas de proceso de Gestión de Proyectos del modelo de

capacidad y madurez integrado. Se analiza el modelo CMMI (Chrissis et al., 2010) para

identificar las áreas de proceso relacionadas con el proceso enfocado. Es importante

mencionar que se eligió el modelo CMMI al ser un modelo ampliamente aceptado en el

mundo, además de contener un conjunto de buenas prácticas que han demostrado un

rendimiento efectivo y probado en otras organizaciones permitiendo abarcar un mayor

número de prácticas de ingeniería de software. A continuación, se describen las áreas de

proceso.

1) Planificación del proyecto

El propósito de esta área de proceso de acuerdo a CMMI-DEV v1.3(Chrissis et al., 2010) es

establecer y mantener planes que definan las actividades del proyecto. Esta área de proceso

está formada por 3 metas específicas (SG) y 14 prácticas específicas como a continuación se

detalla:

SG 1. Establecer las estimaciones: Se definen y mantienen las estimaciones de los parámetros

de planificación del proyecto. Algunos parámetros son: tamaño, esfuerzo y coste.

Consta de las siguientes prácticas específicas:

1.1) Estimar el alcance del proyecto.

1.2) Establecer las estimaciones de los atributos de los productos de trabajo y de las tareas.

1.3) Definir las fases del ciclo de vida del proyecto.

1.4) Estimar el esfuerzo y el coste.

SG 2. Desarrollar un plan de proyecto: Se define y mantiene un plan de proyecto que será la

base para administrar el proyecto, el plan de proyecto está basado en los requisitos del

proyecto y en las estimaciones establecidas.

67


2.1) Establecer el presupuesto y el calendario.

2.2) Identificar los riesgos del proyecto.

2.3) Planificar la gestión de los datos.

2.4) Planificar los recursos del proyecto.

2.5) Planificar el conocimiento y las habilidades necesarias.

2.6) Planificar la involucración de las partes interesadas.

2.7) Establecer el plan de proyecto.

SG 3. Obtener el compromiso con el plan: Se establecen y mantienen los compromisos con el

plan de proyecto.


3.1) Revisar los planes que afectan al proyecto.

3.2) Conciliar los niveles de trabajo y de recursos.

3.3) Obtener el compromiso con el plan.

2) Monitorización y control del proyecto

De acuerdo CMMI-DEV v1.3 (Chrissis et al., 2010) su propósito es realizar el seguimiento

del avance del proyecto para que se puedan tomar las acciones correctivas necesarias cuando

el rendimiento del proyecto se desvíe significativamente del plan. Esta área de proceso está

formada por 2 metas específicas (SG) y 10 prácticas específicas como a continuación se

detalla:

SG 1. Monitorizar el proyecto frente al plan: Se monitorizan el progreso y el rendimiento

reales del proyecto frente al plan del proyecto.


1.1) Monitorizar los parámetros de planificación del proyecto.

1.2) Monitorizar los compromisos.

1.3) Monitorizar los riesgos del proyecto.

1.4) Monitorizar la gestión de los datos.

1.5) Monitorizar la involucración de las partes interesadas.

1.6) Llevar a cabo las revisiones del progreso.

1.7) Llevar a cabo las revisiones de hitos.

SG 2. Gestionar las acciones correctivas hasta su cierre: Se gestionan las acciones

correctivas hasta su finalización cuando el rendimiento o los resultados del proyecto se

desvían significativamente del plan.

68


2.1) Analizar las cuestiones.

2.2) Llevar a cabo las acciones correctivas.

2.3) Gestionar las acciones correctivas.

Paso 5. Trazabilidad de los métodos, técnicas y herramientas encontradas con las

buenas prácticas del área de conocimiento del modelo de capacidad y madurez

integrado. Se realizó una trazabilidad de las técnicas y herramientas encontradas con las

prácticas específicas del área de gestión de riesgos de CMMI-Dev v.1.3 (Chrissis et al., 2010)

identificadas en el paso anterior, para identificar su cobertura y cumplimiento. La trazabilidad

entre prácticas y técnicas y herramientas del área de planificación del proyecto se muestra en

la Tabla 23, Tabla 24 y Tabla 25, así como la trazabilidad entre prácticas y herramientas del

área de monitorización y control del proyecto se muestra en la Tabla 26.

La trazabilidad ha sido validada por un grupo de cuatro investigadores, dos investigadores

del grupo de procesos de la Unidad de Zacatecas del Centro de Investigación en Matemáticas

(CIMAT) y dos investigadores de la Universidad de Medellín (UdeM).

El proceso de validación consistió en dos pasos: el envío de la trazabilidad a cada

investigador para su revisión previa y la realización de reuniones para revisión del catálogo.

Resultado de la validación, la trazabilidad se ha refinado con los comentarios de los 4

investigadores.

5.1.2.1. Hallazgos de la trazabilidad de las áreas de Planificación

del Proyecto y Monitorización y Control del Proyecto

A continuación se mencionan los principales hallazgos de la trazabilidad realizada de las

prácticas de CMMI con las técnicas y herramientas encontradas.

5.1.2.1.1 Técnicas y herramientas con mayor cobertura de SP

Para determinar la cobertura de SP por técnica, se realizó una fórmula en donde la cobertura

(C) es igual a la sumatoria del número de SP que la técnica cubre por 100 entre el número

total de SP, a continuación se muestra la fórmula en (1):

(1)

Donde C= cobertura en %

Ʃ= sumatoria

69

n= número de SP

i= técnica

N= número total de SP

Se identificó en el área de planificación del proyecto que la técnica de juicio experto

tiene un 71% de cobertura de SP, reuniones un 50% y software para administración de

proyectos un 43%.

En el área de monitorización y control del proyecto se encuentran las técnicas de

reuniones con un 100% de cobertura de SP, juicio experto con un 60% de cobertura de SP, y

software para administración de proyectos con un 50%.

5.1.2.1.2 La práctica específica con mayor cobertura por las técnicas y

herramientas

Para determinar la cobertura de técnicas por SP se realizó una fórmula en donde la cobertura

(C) es igual a la sumatoria del número de técnicas que la SP cubre por 100 entre el número

total de técnicas, a continuación se muestra la fórmula en (2):

(2)

Donde C= cobertura en %

Ʃ= sumatoria

n= número de técnicas

i= SP

N= número total de técnicas

Se identificó en el área de planificación la SP 2.5 Planificar el conocimiento y las

habilidades necesarias con un 23% de cobertura de técnicas y herramientas, seguida de la SP

2.1 Establecer el presupuesto y el calendario y la SP 2.2 Identificar los riesgos del proyecto

con un 20% de cobertura de técnicas y herramientas y finalmente la SP 2.4 Planificar los

recursos del proyecto con un 17%.

En el área de monitorización y control la SP 1.1 Monitorizar los parámetros de

planificación del proyecto con un 51%, enseguida la SP 1.3 Monitorizar los riesgos del

proyecto con un 29% y finalmente la SP 1.2 Monitorizar los compromisos con un 23%.

70

Aunque existen muchos trabajos referentes a la gestión de proyectos, todavía se continúa

con los problemas de falta de conocimiento por parte de los ingenieros hacia la realización de

prácticas de la gestión de proyectos, así como de la elección de herramientas adecuadas a su

entorno que permitan la implementación y fomenten el uso de buenas prácticas de ingeniería

de software, por lo tanto el aporte de este trabajo es que el análisis realizado proporciona a los

ingenieros:

» Conocimiento sobre las técnicas y herramientas utilizadas en la planificación del

proyecto y monitorización y control de proyecto.

» Los resultados de un análisis de un conjunto de técnicas y herramientas clasificadas

por nivel de dificultad y enfoque, que de acuerdo a la valoración de criterios

especificados en cada técnica ayudarán a la pyme en la elección de la más adecuada

a sus necesidades.

» Y un análisis de cobertura de prácticas específicas y técnicas y herramientas que

puede reforzar el uso e implementación de buenas prácticas en las pymes.

Finalmente mencionar que la técnica más utilizada en la planificación del proyecto es la

WBS, así como en la monitorización y control del proyecto es la Gestión del Valor Ganado.

Paso 6. Creación de herramienta. Como alternativa a la selección de técnicas y

herramientas específicas, se desarrolló una herramienta que facilite la implementación de

buenas prácticas de ingeniería de software basada en el análisis de cobertura de prácticas y de

elementos realizado para la sección de riesgos. El diseño y la funcionalidad de la herramienta

se describen a detalle en el presente capítulo, sección 5.3.

71

Tabla 23. Trazabilidad entre prácticas específicas de CMMI y técnicas y herramientas del área

de Planificación del Proyecto (parte 1 de 3)

72



73



74


de Monitorización y Control del Proyecto

75

5.2. Desarrollo de una herramienta que facilita la

implementación del método propuesto para el área de

Gestión de Riesgos

En este apartado se describen los elementos que contiene la herramienta que facilita la

implementación de buenas prácticas de ingeniería de software, así como el análisis, diseño,

desarrollo e implementación de la herramienta. Es una herramienta de gestión de riesgos,

finalmente se describe la funcionalidad a través de pantallas principales.

La razón para desarrollar la herramienta es la validación del método propuesto. La

herramienta está basada en el análisis realizado para la gestión de riesgos. Su finalidad es

ayudar a las pymes a realizar una gestión de riesgos básica.

La herramienta de gestión de riesgo fue llamada RiskSys por sus abreviaturas en inglés de

riesgo (risk) y sistema (system). La herramienta de gestión de riesgos RiskSys permite:

determinar las fuentes y categorías de riesgos; identificar los riesgos; definir los parámetros

de riesgos, evaluar, clasificar y priorizar los riesgos; así como establecer una estrategia de

gestión de riesgos, a través de una aplicación web.

5.2.1. Elementos que contiene la herramienta de gestión

de Riesgos RiskSys que facilita la implementación de

buenas prácticas de ingeniería de software

A continuación se mencionan las técnicas que se tomaron como base para realizar la

herramienta y la descripción de cómo ayudan a realizar buenas prácticas en la gestión de

riesgos.

Cada una de las técnicas listadas se tomó como base por ciertos aspectos clave, cada una

de ellas aporta algo importante para ayudar a realizar una gestión de riesgos básica,

destacando la ejecución del Planning Póker, que permite realizar una votación de valores de

riesgos gestionados de forma colaborativa y ágil.

La herramienta de gestión de riesgos RiskSys contiene técnicas formales a través de la

implementación de una técnica ágil (Planning poker).

» Técnica de taxonomía de riesgos: A través de la taxonomía se puede establecer un listado

de fuentes y categorías de riesgos, así como establecer un listado de riesgos.

76

» Técnica de entrevistas: Permite reunir información de todas las partes interesadas en el

proyecto para determinar las fuentes y categorías de riesgos, así como reunir información

para identificar los riesgos.

» Técnica de cuestionarios: Permiten obtener información de la empresa y del proyecto.

» Técnicas de análisis mediante Tablas: Permiten evaluar y priorizar los riesgos.

» Técnica de tormenta de ideas: Esta técnica consiste en la aportación de ideas, lo que

puede contribuir a: establecer los parámetros de impacto y probabilidad, valorar los

riesgos, así como agregar acciones de mitigación y la identificación del responsable del

riesgo.

» Técnica de valoración delphi: Permite analizar los riesgos y agregar acciones de

mitigación/contención así como la identificación del responsable del riesgo.

» Técnica de planning póker: Permite realizar una votación de los valores de riesgos

gestionados de forma colaborativa y ágil.

» Técnicas gráficas: Permiten visualizar los resultados de riesgos gestionados clasificados y

priorizados para enfocarse en los de probabilidad e impacto críticos y así poder establecer

un plan.

5.2.2. Análisis

Como se mencionó anteriormente, el modelo que se utilizó como referencia fueron algunas

prácticas del modelo espiral, por lo que en las siguientes secciones se especificará cada etapa

y la descripción en cada una.

5.2.2.1. Comunicación con el cliente

Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. En este

caso las reuniones entre el desarrollador y el cliente.

5.2.2.2. Planificación

Las tareas requeridas para definir recursos, el tiempo, la determinación de los objetivos,

alternativas y restricciones y otra información relacionada con el proyecto.

5.2.2.2.1 Objetivo

Desarrollar una herramienta de gestión de riesgos, que sea eficiente y flexible.

La herramienta de gestión de riesgos RiskSys permitirá:

» Determinar las fuentes y categorías de riesgos

» Identificar los riesgos

77

» Definir los parámetros de riesgos

» Evaluar, clasificar y priorizar los riesgos

» Establecer una estrategia de gestión de riesgos

A través de una aplicación Web que gestione todo lo anterior de una forma eficiente.

5.2.2.2.2 Características importantes

La herramienta permitirá:

» Registrar usuarios de tipo Colaborador.

» Registrar los datos del proyecto.

» Registrar los datos de empresa

» Seleccionar proyectos.

» CRUD de usuarios/proyectos/empresas/catálogo de riesgos

» Identificar los riesgos y seleccionar los que puedan afectar al proyecto.

» Obtener una lista de riesgos categorizados.

» Establecer parámetros y evaluar los riesgos.

» Clasificar los riesgos priorizados por nivel de criticidad.

» Mostrar gráfico de priorización de riesgos.

» Establecer una estrategia de gestión de riesgos.

5.2.2.2.3 Alcance de lanzamiento inicial (Versión 1.0)

» Realizar la gestión de riesgos permitiendo establecer n (1-10) iteraciones en el

proyecto.

» Poder exportar la gráfica a un archivo de imagen, así como generar el reporte de

tratamiento de riesgos y exportarlo en archivo con formato pdf.

5.2.2.2.4 Restricciones

La Tabla 27 muestra las restricciones del proyecto.

Tabla 27. Restricciones

ID Descripción

Res-01

La aplicación realizará el proceso de gestión de riesgos basada en n iteraciones definidas en el

proyecto. (n=1-10)

Res-02 Para poder utilizar la aplicación es necesario contar con conexión a Internet.

Res-03 El usuario que ingrese a RiskSys debe contar con una cuenta de correo electrónico.

78

5.2.2.2.5 Requisitos funcionales

La Tabla 28 muestra el listado de los requisitos funcionales.

Tabla 28. Listado de Requisitos funcionales para herramienta de gestión de riesgos RiskSys

Número Nombre del Requisito

RF-01

Registrar usuarios de Tipo

Administrador/Colaborador.

RF-02 Registrar los datos del proyecto.

RF-03 Seleccionar proyectos.

RF-04 CRUD de usuarios.

RF-05 Identificar los riesgos

RF-06

Seleccionar los riesgos que pueden afectar al

proyecto.

RF-07 Obtener una lista de riesgos categorizados.

RF-08 Establecer parámetros de evaluación

RF-09 Evaluar los riesgos

RF-10 Priorizar los riesgos

RF-11

Clasificar los riegos priorizados por nivel de

criticidad.

RF-12 Mostrar gráfico de priorización de riesgos.

RF-13 Establecer una estrategia de gestión de riesgos.

RF-14 Autentificar usuarios

RF-15 Registrar Empresa

5.2.2.2.6 Requisitos de calidad

En este apartado se describen los requisitos de calidad especificados en la norma ISO/IEC

9126-3 (ISO, 2003) con los que cumple la herramienta de gestión de riesgos RiskSys.

Seguridad

79

Una característica que permitirá a la aplicación estar protegida contra accesos no autorizados.

Para garantizar la seguridad se cuenta con el acceso al sistema mediante usuario y contraseña,

la cual se encuentra encriptada.

Usabilidad Este requisito define como la herramienta RiskSys cumple los requisitos de usuario y

consumidor, que la aplicación sea intuitiva y fácil de utilizar, y con esto realice la gestión de

riesgos de manera fácil, nada compleja. Para garantizar la usabilidad se cuenta con manuales

de usuario, tutoriales, así como etiquetas de descripción en cada campo de la herramienta.

Mantenibilidad Es la habilidad del sistema para someterse a los cambios con un grado de facilidad. Estos

cambios pueden impactar en los componentes, servicios, características e interfaces cuando se

agrega o cambia funcionalidad, corrección de errores, y cumplir con nuevos requisitos del

negocio. La modularidad de la aplicación permite el fácil mantenimiento.

Reutilización Define la capacidad de los componentes y subsistemas de ajustarse para usarlos en otras

aplicaciones y en otros escenarios. La Reutilización reduce la duplicación de componentes y

también tiempo de implementación. Esto se garantiza con la utilización del framework

Django, ya que permite que se reutilicen componentes y evitar duplicidad de código.

Portabilidad Especifica los atributos de software que se relacionan con la facilidad de portar el software a

otras máquinas y/o sistemas operativos. La aplicación tendrá la capacidad de poder ejecutarse

en PC, Mac, etc. Esto se garantiza al utilizar el Framework Django.

5.2.2.2.7 Análisis de riesgos

Las tareas requeridas para evaluar riesgos técnicos y de gestión, análisis de alternativas e

identificación/resolución de riesgos. En esta fase se realizó una tabla en donde se contemplan

algunos riesgos, así como su estrategia de mitigación.

En la Tabla 29 se muestran algunos riesgos de negocio que podrían afectar al proyecto.

Tabla 29. Riesgos de negocio del proyecto

ID Descripción Probabilidad Descripción de

impacto

Estrategia de

Mitigación

RN-01 Avería de origen físico o

lógico

Medio Una falla en el

hardware o software

provocaría la pérdida

de la información, daño

del equipo físico.

Realizar respaldos de la

información

periódicamente

Contar con un equipo

adicional

RN-02 Pérdida accidental de

información

Medio El no contar con un

respaldo provocaría

pérdidas.

Realizar respaldos

periódicos de la

información.

80

RN-03 Indisponibilidad del

personal

Bajo No hay una correcta

gestión de las

actividades y tiempos

de los integrantes, por

lo que se enferman.

Revisión frecuente de

la salud de cada

integrante.

Correcta gestión de

actividades y tiempo.

RN-04 Agilizar y reducir el

tiempo invertido por

clientes al momento de

establecer una reunión.

Bajo Pérdida de la confianza

del cliente

Se notificará al cliente

cuando la aplicación

presenta conflictos de

tiempo.

RN-05 La información del

usuario no es

confidencial.

Medio Pérdida de la confianza

del cliente al usar la

aplicación.

Se notificará al cliente

la información que está

visible para el resto de

los usuarios.

81

5.2.3. Diseño

5.2.3.1. Ingeniería

Las tareas requeridas para construir una o más representaciones de la herramienta, desarrollo

del producto hasta el siguiente nivel.

5.2.3.1.1 Consideraciones de desarrollo

» La interfaz cliente de la herramienta de gestión de riesgos RiskSys se implementará utilizando el framework web Django.

» Correrá en navegador web, Mac OS o iOS.

» El modelo a utilizar es: Construcción de Prototipos con algunas prácticas del

Modelo Espiral.

5.2.3.2. Estructuración general de la herramienta

5.2.3.2.1 Conceptos de diseño elegidos

La Tabla 30 muestra los conceptos de diseño elegidos y la justificación de la decisión.

Tabla 30. Conceptos de diseño elegidos

Concepto de diseño

(nombre de patrón,

táctica o tecnología)

Justificación de la decisión

Estilo arquitectónico

de capas (Layers)

Las capas permiten aislar de forma lógica las distintas responsabilidades

del sistema: los aspectos relacionados con el usuario (Capa de

presentación), el manejo de la lógica del negocio (Capa de negocio) y la

persistencia de datos (Capa de datos).

Patrón arquitectónico

MVC

Al existir la separación de vistas, controladores y modelos es más factible

realizar el mantenimiento, realizar la modificación de componentes sin

afectar la lógica del negocio, permite la escalabilidad del sistema, permite

cambios sin que sea afectado todo el sistema, permite cambiar de

tecnología sin afectar la lógica del sistema con el objetivo de mejorar el

rendimiento.

Selección de

Tecnologías:

Framework Django

Moderno Framework de Desarrollo Web, utiliza Python, HTML, Apache,

está basado en el patrón MTV (Model, Template, View).

Analogía con MVC

» El modelo en Django sigue siendo modelo (Model)

» La vista en Django se llama Plantilla (Template)

82

» El controlador en Django se llama Vista (View)

5.2.3.2.1.1 Vista Lógica

El siguiente diagrama de la Fig. 12 muestra la perspectiva lógica de la herramienta RiskSys.

Figura 12. Vista lógica de RiskSys

A continuación se describe cada componente de la vista lógica en la Tabla 31.

Tabla 31. Elementos de perspectiva lógica de RiskSys

Elemento Responsabilidad Propiedades

Capa de

presentación

Son todos los componentes encargados de interactuar con el

usuario y de mostrarle resultados.

Lenguaje:

HTML

Framework:

Django

Capa de negocio Engloba todos los componentes de administración que se

encargan de llevar a cabo la ejecución de los requisitos

funcionales de la herramienta

Lenguaje:

Python

Framework

Django

Capa de datos Son todos los componentes encargados de almacenar la

información en una Base de Datos.

PostgreSQL

83

5.2.3.2.1.2 Vista Física

El siguiente diagrama de la Fig.13 muestra la perspectiva física de la herramienta RiskSys.

Figura 13. Diagrama de despliegue de RiskSys

A continuación, en la Tabla 32 se describen los elementos de la vista física en la siguiente

Tabla.

Tabla 32. Elementos de vista física de RiskSys

Elemento Responsabilidad Propiedades

Cliente Es el equipo mediante el cual el usuario

accede a RiskSys. Puede ser un dispositivo

móvil o una pc.

Navegador = Safari 7+, Google

chrome 10+, Internet Explorer 10+,

Firefox 30+

Servidor

Web

El servidor Web contiene las capas de

presentación, negocio, datos e integración.

Tipo = Apache

Servidor

BD

El servidor de Base de Datos alberga la Base

de Datos.

Tipo= PostgreSQL

84

5.2.3.2.3 Diagrama de clases

A continuación se muestra el diagrama de clases para la herramienta RiskSys en la Fig. 14.

Figura 14. Diagrama de clases de RiskSys

85

5.2.3.2.4 Modelo de la BD de RiskSys

Figura 15. Modelo de BD de RiskSys

86

5.2.3.2.5 Diagramas de secuencia de la herramienta RiskSys

A continuación se presentan los principales diagramas de secuencia de la herramienta RiskSys, si desea ver

los diagramas secundarios, consulte el Anexo II Diseño de la herramienta RiskSys.

5.2.3.2.5.1 DS-01 Identificar riesgos

Figura 16. Diagrama de secuencia identificar riesgos

5.2.3.2.5.2 DS-02 Evaluar riesgos

Figura 17. Diagrama de secuencia evaluar riesgos

87

5.2.3.2.5.3 DS-03 Realizar gestión de riesgos

Figura 18. Diagrama de secuencia de realizar gestión de riesgos

88

5.2.4. Desarrollo

5.2.4.1. Construcción

Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario

(documentación, prácticas, etc).

Una vez que se finalizó la codificación, se realizaron 3 manuales de usuario de la

herramienta de gestión de riesgos RiskSys.

Líder de Proceso Usuario Colaborador Administrador

Así como videos demostrativos donde se explican los procesos principales de cada tipo de

usuario.

Figura 22. Video demostrativo de herramienta

Figura 21. Manual de

Administrador Figura 19. Manual de

Usuario Colaborador Figura 20. Manual de Líder

de Proceso

89

5.2.5. Implementación

5.2.5.1. Evaluación del cliente

Tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones

del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

Valoración por parte del cliente de los resultados obtenidos. Para lograr la valoración del cliente se

realizó el diseño del caso de estudio, donde 2 empresas probaron la herramienta de gestión de

riesgos RiskSys y al finalizar respondieron una encuesta para obtener su opinión. El caso de estudio

y los resultados se describen a detalle en el Capítulo 7 Resultados, secciones 7.1.4.1 y 7.1.4.2.

5.2.5.1.1 Funcionalidad de la herramienta de gestión de Riesgos RiskSys

En esta sección se describe la funcionalidad principal de la herramienta, primero se describen

los tipos de usuario que hay para ingresar a la herramienta y finalmente se muestran las pantallas

principales de la herramienta con una breve descripción.

5.2.5.1.1.1 Tipos de usuario

La Fig. 23 muestra los tipos de usuario que hay para ingresar a la herramienta.

Figura 23. Diagrama de Tipos de usuarios de RiskSys

•Tiene permiso para realizar cambios en el sitio de Administración. Es el usuario AdministradorRS2.

Administrador técnico

•Es el líder del proyecto, tendrá acceso a todas las funcionalidades de la herramienta RiskSys. Predefinido. Es el usuario LíderP1, LíderP2, LíderP3...

Líder de Proceso

•Es un miembro del equipo asignado a un proyecto, puede realizar la identificación, selección y evaluación de riesgos individual, así como consultar el reporte del gráfico de riesgos por proyecto, consultar la última evaluación de riesgos realizada por proyecto asignado, así como consultar el tratamiento de riesgos por proyecto. Se tiene que registrar por su cuenta.

Usuario colaborador

90

5.2.5.1.1.2 Funcionalidad principal de la herramienta de gestión de riesgos RiskSys

A continuación se muestran las pantallas principales de la herramienta RiskSys, si desea consultar

las pantallas secundarias de la herramienta, consulte el Anexo III Funcionalidad principal de la

herramienta.

5.2.5.1.1.2.1 Selección de riesgos que pueden afectar al proyecto

En este módulo el Líder de Proceso primero debe seleccionar el proyecto, después de acuerdo a su

juicio experto, seleccionará aquellos riesgos que considere pueden afectar al proyecto y conformará

el catálogo de riesgos para el proyecto seleccionado.

Figura 24. Selección de proyecto para conformar catálogo de riesgos

Figura 25. Gestión de Catálogo de Riesgos para el proyecto seleccionado

91

5.2.5.1.1.2.2 Obtener una lista de riesgos categorizados, identificar los riesgos,

establecer parámetros de evaluación y evaluar los riesgos

» En este módulo el usuario colaborador debe seleccionar el proyecto con el que se desea

gestionar riesgos, previamente el Líder de Proceso tuvo que asignarle proyectos al usuario.

Figura 26. Selección de proyecto para iniciar evaluación de riesgos individual

» Selección de riesgos de manera individual.- En esta pantalla (Fig. 27) se muestra el

Catálogo de Riesgos que el Líder de Proceso seleccionó para el proyecto, el usuario de

manera individual y de acuerdo a su juicio experto marcará aquellos que considere pueden

afectar al proyecto y oprimirá el botón Seleccionar.

Figura 27. Selección de riesgos individual

92

» Identificación y evaluación de riesgos.- En la Fig. 28 se muestra la pantalla en la que el

usuario una vez que seleccionó los riesgos, los evaluará con parámetros de probabilidad e

impacto y dará click en el botón Guardar.

Figura 28. Identificación, establecimiento de parámetros y evaluación de riesgos individual

5.2.5.1.1.2.3 Evaluar, priorizar y clasificar los riesgos, establecer estrategia

En este módulo el Líder de Proceso debe ingresar al módulo de Gestión de Riesgos, es un proceso

que se realiza de forma ágil (a través de la ejecución de la técnica Planning Póker) a través de una

reunión del Líder de Proceso con los miembros del equipo. Todos los miembros del equipo

asignados al proyecto debieron haber realizado la gestión de riesgos de manera individual. En esta

sección se evalúan, priorizan y clasifican los riesgos, así como también se establecen estrategias.

» Módulo de Gestión de Riesgos

El Líder de Proceso y los miembros del equipo se reúnen, el Líder de Proceso deberá entrar al

módulo de Gestión de Riesgos, primero deberá seleccionar el proyecto, posteriormente entrará a la

pantalla de Gestión de Riesgos. La pantalla del módulo se muestra en la Fig. 29.

93

Figura 29. Pantalla de Gestión de Riesgos en Equipo

» Mensaje de nueva iteración.- La Fig. 30 muestra el mensaje del comienzo de una nueva

iteración.

Figura 30. Mensaje de nueva iteración

5.2.5.1.1.2.4 Mostrar gráfica de riesgos del proyecto

En esta sección se muestra una gráfica de riesgos gestionados por proyecto.

» Selección de proyecto para ver gráfico. - La Fig. 31 muestra la pantalla de selección de

proyecto, en la cual el usuario debe seleccionar el proyecto para el cual desea ver la gráfica.

Figura 31. Selección de proyecto para ver gráfico

94

» Gráfica de riesgos del proyecto. En la Fig. 32 se muestra una gráfica de burbuja de los

riesgos gestionados del proyecto. La información que muestra es el número de iteración

actual así como los valores de probabilidad e impacto de los riesgos gestionados.

La escala de valores es por colores y expresada en porcentaje.

» Verde: Riesgos con baja probabilidad e impacto

» Amarillo: Riesgos con media probabilidad e impacto.

» Rojo: Riesgos con alta probabilidad e impacto. (Son los que tienen que gestionarse).

Figura 32. Gráfica de riesgos por proyecto

5.2.5.1.1.2.5 Establecer estrategia (Reporte de tratamiento de riesgos)

Esta sección se refiere al listado de riesgos gestionados con responsable y tipo de acción

(contención/ mitigación) filtrados por proyecto.

» Selección de proyecto para reporte de Tratamiento de Riesgos.- Como se observa en la Fig.

33 se debe seleccionar el proyecto para el cual se desea ver el reporte de Tratamiento de

Riesgos.

95

Figura 33. Selección de proyecto para tratamiento de riesgos

» Tratamiento de riesgos por proyecto.- La Fig. 34 muestra el reporte de Tratamiento de

Riesgos por proyecto, así como la opción de guardar el reporte en formato pdf.

Figura 34. Reporte de Tratamiento de riesgos por proyecto

96

Capítulo 6. Resultados

6.1. Caso de estudio para validación de la herramienta de

gestión de riesgos RiskSys

A continuación se describirán algunos métodos empíricos de investigación en ingeniería de

software, los autores (Wohlin, Höst, & Henningsson, 2003) mencionan que hay dos tipos de

paradigmas de investigación: cualitativa y cuantitativa.

» Investigación Cualitativa (Wohlin et al., 2003): Se ocupa de estudiar objetos en su

entorno natural, un investigador cualitativo tiende a interpretar un fenómeno basado en

las explicaciones que la gente aporta; este tipo de investigación se ocupa de descubrir

las causas notadas por los sujetos en el estudio y de entender su opinión en el problema

en cuestión.

» Investigación Cuantitativa (Wohlin et al., 2003): Se ocupa de cuantificar la relación o

comparar dos o más grupos, el objetivo es identificar la relación causa-efecto; este tipo

de investigación frecuentemente se lleva a cabo a través de la creación de experimentos

o recopilación de datos a través de casos de estudio, así como permiten comparaciones

y análisis estadísticos.

Dependiendo del propósito de la evaluación y condiciones para la investigación empírica, hay

cuatro tipos principales de investigación (Wohlin et al., 2003), los cuales se mencionan a

continuación.

1 Experimento. Este tipo de investigación tiene un alcance limitado y la mayoría de las veces se

ejecutan en un entorno de laboratorio; frecuentemente son altamente controlados y denominados

experimentos controlados. Cuando se experimenta, los sujetos son asignados a diferentes

tratamientos de manera aleatoria. El objetivo es manipular una o más variables y controlar las

demás variables a niveles fijos. El efecto de la manipulación es medido y basado en eso puede

realizarse un análisis estadístico.

2 Encuesta. En este tipo de investigación es posible enviar un cuestionario o entrevistar a un gran

número de personas cubriendo cualquier población objetivo que se tenga. Una encuesta es

frecuentemente una investigación realizada en retrospectiva, cuando por ejemplo, una técnica o

herramienta ha estado en uso por cierto tiempo. Los medios primarios de recolección de datos

cualitativos o cuantitativos son las entrevistas o cuestionarios, a través de una muestra que

represente a la población a estudiar. Los resultados de la encuesta son analizados para derivar

97

conclusiones descriptivas y explicativas. Las encuestas son muy comunes en las ciencias sociales y

no es posible manipular variables.

3 Análisis Post-Mortem. Este tipo de análisis al igual que la encuesta, se realiza sobre el pasado

como lo indica su nombre. Por ejemplo; un proyecto no tiene que estar finalizado para lanzar un

análisis post-mortem. Debería ser posible estudiar cualquier parte del proyecto retrospectivamente

utilizando este tipo de análisis. Este tipo de investigación se relaciona con la encuesta y el caso de

estudio. Puede realizarse examinando la documentación del proyecto (análisis de archivos o

entrevistando a personas, de manera individual o en grupo, quiénes han participado en el objeto que

está siendo analizado en el análisis post-mortem). La idea básica es capturar los conocimientos y la

experiencia de un caso específico o actividad después de que haya sido finalizada.

4 Caso de estudio. Un caso de estudio según (Stake, 1999) “es el estudio de la particularidad y de la

complejidad de un caso singular, para llegar a comprender su actividad en circunstancias

importantes”. Para el presente trabajo, se tomará en cuenta la investigación cuantitativa ya que se

realizaran análisis estadísticos con base en datos recopilados a través de casos de estudio aplicados

en al menos 2 empresas.

Pérez Serrano (Pérez Serrano, 2014) afirma que el objetivo de los casos de estudio es

“comprender el significado de una experiencia”, el conocimiento de lo particular sin olvidar su

contexto.

Yin (Yin, 2002) enfatiza la contextualización del objeto de investigación, al entender que un

caso de estudio es una investigación empírica dirigida a investigar un fenómeno contemporáneo

dentro de su contexto real. El caso de estudio se conforma de cinco pasos (Runeson & Höst, 2009),

los cuales se mencionan a continuación en la Fig. 35:

Figura 35. Pasos para implementar un caso de estudio.

1. Diseño y planificación del caso de estudio

2. Preparación de la recogida de datos

3. Recogida de datos

4. Análisis de los datos recogidos

5. Informe de los resultados

98

En las siguientes secciones se describen los pasos para la implementación de un caso de

estudio.

6.1.1. Diseño y planificación del caso de estudio

El diseño y planificación de un caso de estudio debe contener los siguientes elementos:

» Objetivo - ¿Qué se quiere lograr?

» El objeto de estudio - ¿Qué es lo que se estudia?

» Teoría - Marco de referencia.

» Preguntas de investigación - ¿Qué se quiere conocer?

» Métodos – ¿Cómo recoger los datos?

A continuación se muestra el diseño y planificación para el caso de estudio.

6.1.1.1. Objetivo del caso de estudio

Evaluar la viabilidad de la herramienta de gestión de riesgos que facilita la implementación de

buenas prácticas de ingeniería de software en gestión de riesgos.

6.1.1.2. Objeto de estudio

El caso de estudio se centra en la implementación del método en al menos dos empresas que

utilicen la herramienta de gestión de riesgos. La Tabla 33 muestra las características de las

empresas que participaron en el caso de estudio.

Tabla 33. Objeto de estudio

Nombre Número de

empleados

Muestra de

empleados

Característica

Empresa A 15 8 Con experiencia en gestión de riesgos

Empresa B 10 5 Con experiencia en gestión de riesgos

6.1.1.3. Marco de referencia

La implementación de buenas prácticas de Ingeniería de Software es una actividad que las pymes

deben realizar con el fin de mejorar la calidad de sus productos y/o servicios. Sin embargo, los

ingenieros de software carecen de conocimiento de gestión de proyectos, ya que no reciben la

formación suficiente. Aunado a lo anterior, este tipo de organizaciones no utilizan las técnicas

adecuadas a su forma de trabajo ya que tienen restricciones que les obligan a seleccionar sus

99

tecnologías de acuerdo a recursos de tiempo y dinero limitados, dando como resutlad que desde

etapas tempranas se enfrenten a problemas para cumplir con el presupuesto y calendario, evaluar

riesgos potenciales, mantener una comunicación efectiva en los equipos, entre otros. En este contexto, la aplicación de buenas prácticas contenidos en los modelos y estándares

de calidad en las pymes es difícil, porque están orientados a grandes empresas y, por lo tanto,

representan una gran inversión de recursos económicos, de tiempo, entre otros.

Como una solución a esta situación, se propone una herramienta cuya finalidad es facilitar la

implementación de buenas prácticas de gestión de riesgos, permitiendo a las pymes realizar una

gestión de riesgos básica.

La herramienta de gestión de riesgos permite determinar las fuentes y categorías de riesgos,

identificar los riesgos, definir los parámetros de riesgos, evaluar, clasificar y priorizar los riesgos,

así como establecer una estrategia de gestión de riesgos, a través de una aplicación web.

6.1.1.4. Preguntas de investigación

P1. ¿Las técnicas que utiliza la herramienta (tradicionales/ágiles) son las adecuadas para realizar

una gestión de riesgos básica?

Con esta pregunta se pretende validar si el conjunto de técnicas en las que se fundamenta la

herramienta son las adecuadas para realizar una gestión de riesgos básica.

P2. ¿La forma en que se realiza la gestión de riesgos es adecuada?

Con esta pregunta se pretende validar si la manera en la que se realiza la gestión de riesgos

en la herramienta es adecuada o suficiente.

P3. ¿La herramienta de gestión de riesgos es eficiente, intuitiva y amigable al usuario?

Con esta pregunta se pretende validar la usabilidad de la herramienta.

P4. ¿La herramienta de gestión de riesgos facilita la implementación de buenas prácticas?

Con esta pregunta se pretende validar si la herramienta realmente ayuda a las empresas a

implementar buenas prácticas de ingeniería de software.

6.1.1.5. Métodos para la recogida de datos

El método para la recogida de datos será la Encuesta, a través del diseño de un cuestionario

que consta en su mayoría de preguntas cerradas y una pregunta abierta, el cual será elaborado en la

aplicación Formularios de Google.

100

6.1.2. Preparación de la recogida de datos

1) Primero, una muestra de empleados de la empresa A y de la empresa B utilizará la

herramienta de gestión de riesgos y observará los resultados obtenidos en forma de gráfica y

reporte de tratamiento de riesgos.

2) Enseguida, la muestra de empleados responderá una encuesta para evaluar la viabilidad de

la herramienta de gestión de riesgos.

6.1.2.1. Diseño del cuestionario

A continuación, se presenta el conjunto de preguntas del cuestionario en la Tabla 34, así como su

escala de valoración para las respuestas, para lo cual se utilizó la escala de matriz de lado a lado de

análisis de datos, la cual evalúa la importancia y satisfacción de los atributos deseados (Muguira,

2017).

Tabla 34. Cuestionario para evaluar la herramienta RiskSys

Núm.

Pregunta de

investigación

asociada

Pregunta Satisfacción

Importancia

Nada

importante

Muy

importante

1 P3. ¿Considera que la herramienta RiskSys es

intuitiva y fácil de utilizar? Sí No

¿Por

qué? 1 2 3 4 5

2 P3. ¿Considera que la herramienta RiskSys es

adecuada para una gestión de riesgos básica? Sí No

¿Por

qué? 1 2 3 4 5

3 P4.

¿Considera que al utilizar RiskSys está

implementando buenas prácticas de ingeniería

de software?

Sí No ¿Por

qué? 1 2 3 4 5

4 P2. ¿Considera que la forma en que se realiza la

gestión de riesgos es adecuada? Sí No

¿Por

qué? 1 2 3 4 5

5 P1.

¿Considera adecuada que para la ejecución de

la herramienta se implemente la técnica de

Planning Póker?

Sí No ¿Por

qué? 1 2 3 4 5

6 P1.

¿Considera que las técnicas en las que se

fundamenta la herramienta (Delphi,

cuestionarios, gráficas, taxonomía, análisis de

datos mediante Tablas) son adecuadas para la

gestión de riesgos?

Sí No ¿Por

qué? 1 2 3 4 5

7 P3. Qué considera que se debería mejorar en

RiskSys

101

6.1.3. Recogida de datos

Para la recogida de datos en el caso de estudio se siguen los pasos descritos en la Fig. 36.

1. Reunión de presentación de herramienta, presentación

electrónica y video demostrativo.

2. El Líder de Proceso ingresa a la herramienta, se identifica, registra los datos de su empresa y proyecto, conforma el catálogo de riesgos para el proyecto, establece los valores de parámetros de categorías de probabilidad e impacto para el proyecto.

3. Los empleados ingresan a la herramienta y se registran.

4. El Líder de Proceso actualiza sus datos de perfil y modifica su contraseña.

5.El Líder de Proceso asigna los empleados al proyecto.

No

¿Todos los empleados fueron

asignados al proyecto?

Sí

No

6 . Los empleados ingresan a la página principal de la herramienta y seleccionan el proyecto al que estén asignados y empiezan a realizar la gestión de riesgos de manera individual.

Continúa en la página siguiente

¿Todos los empleados están

registrados?

Sí

102

Sí

No

7. El Líder de Proceso ingresa al módulo de Gestión de Riesgos del proyecto y guarda los valores que se muestran de la gestión de riesgos,

¿Todos los empleados realizaron la gestión de riesgos

individual?

8. Se despliega el reporte de tratamiento de riesgos, el Líder de Proceso regresa al módulo de Gestión de Riesgos del proyecto.

9. Reunidos el Líder de Proceso y los empleados,, hacen un análisis de los valores mostrados en la Gestión de Riesgos y votan por su aceptación o rechazo.

¿Todos aceptaron los valores de cada riesgo gestionado?

10. El Líder de Proceso selecciona al responsable del riesgo, selecciona la acción de tratamiento (mitigación/contención) e ingresa la descripción de la acción.

11. El Líder de Proceso marca el riesgo rechazado y oprime el botón Nueva iteración para comenzar una nueva iteración.

12. El Líder de Proceso y los miembros del equipo revisan la gráfica y el reporte de tratamiento de riesgos.

13. Finalizar sesión.

14. Empleados y Líder de Proceso contestan la encuesta de validación de la herramienta.

15. A partir de las encuestas contestadas, se realiza el análisis de la información recopilada.

Sí No

Figura 36. Diagrama de descripción de pasos para recogida de datos

11.1 Regresar al paso 6.

No Sí ¿Comenzó una nueva iteración?

103

6.1.4. Análisis de los datos recogidos

En esta sección se realiza un análisis de los datos recopilados de las empresas que participaron en el

caso de estudio.

6.1.4.1. Caso de estudio de la Empresa A

En la Tabla 35 se muestran los datos generales de la Empresa A.

Tabla 35. Descripción de la Empresa A

Nombre Empresa A

Descripción

Empresa dedicada a ofrecer servicios de venta y

mantenimiento de equipo de cómputo, así como

desarrollo de software a la medida.

Número de empleados 15

Muestra de empleados que

participó en el caso 8

Experiencia en gestión de riesgos Sí

6.1.4.1.1 Resultados de la Encuesta

A continuación se presentan los datos obtenidos al aplicar la encuesta a la muestra de

empleados de la empresa A, en forma de gráficas.

P1. ¿Considera que la herramienta RiskSys es intuitiva y fácil de utilizar?

En la Fig. 37 se observa que el 100% de los empleados (8) considera que la herramienta es intuitiva

y fácil de utilizar, reafirmando así la usabilidad de la herramienta.

104

Figura 37. Respuestas de pregunta 1 de Empresa A

Importancia de que la herramienta RiskSys sea intuitiva y fácil de utilizar.

En la Fig. 38 se observa que referente a la importancia de la pregunta 1, el 87%(7) de los

empleados afirmó que es muy importante, mientras que el 13%(1) le dio un valor de medianamente

importante.

Figura 38. Respuestas de importancia de pregunta 1 de Empresa A

100%

1.- ¿Considera que la herramienta RiskSys es intuitiva y fácil de utilizar?

Sí No

87%

0% 13%

0% 0%


Muy importante

Importante

Medianamenteimportante

Algo importante

Nada importante

105

P3. ¿Considera que la herramienta RiskSys es adecuada para una gestión de riesgos

básica?

Como se puede observar en la Fig. 39, el 100% (8) de los empleados respondió que la herramienta

sí es adecuada para realizar una gestión de riesgos básica.


Importancia de que la herramienta RiskSys sea adecuada para realizar una gestión de riesgos

básica.

En la Fig. 40 puede observarse que referente a la importancia de la pregunta 2, el 62%(5) de los

empleados afirmó que es muy importante, mientras que el 38%(3) le dio un valor de importante.


100%

0%

2.- ¿Considera que la herramienta RiskSys es adecuada para una gestión de riesgos

básica?

Sí

No

62%

38%

0% 0%

0%

Importancia de que la herramienta RiskSys sea adecuada para una gestión de riesgos

básica.

Muy importante

Importante


Algo importante

Nada importante

106

P4. ¿Considera que al utilizar RiskSys está implementando buenas prácticas de

ingeniería de software?

Como se puede observar en la Fig. 41, el 87% (7) de los empleados respondió que sí consideran que

al utilizar la herramienta se implementan buenas practicas de ingeniería de software, y solo un

13%(1) respondió que no, argumentando que la cultura de la empresa influye en que no se

implementen las buenas prácticas.


Importancia de que al utilizar RiskSys se implementen buenas prácticas de ingeniería de

software.




87%

13%

3.- ¿Considera que al utilizar RiskSys está implementando buenas prácticas de


Sí

No

75%

25%

0% 0%

0%

Importancia de que al utilizar RiskSys se implementen buenas prácticas de

ingeniería de software.

Muy importante

Importante


Algo importante

Nada importante

107

P5. ¿Considera que la forma en que se realiza la gestión de riesgos es adecuada?

Como se muestra en la Fig. 43, el 87%(7) de los empleados respondió que sí considera que

la forma en que se realiza la gestión de riesgos es adecuada y sólo el 13%(1) respondió que

no, sugiriendo que se deberían considerar los dos tipos de acciones, tanto de mitigación

como de contingencia y no sólo una de ellas.


Importancia de que la forma en que se realiza la gestión de riesgos sea la adecuada.

En la Fig. 44 puede observarse que referente a la importancia de la pregunta 4, el 62%(5) de

los empleados afirmó que es muy importante, mientras que el 25%(2) le dio un valor de

importante y sólo el 13%(1) le dio un valor de medianamente importante.


87%

13%

4.- ¿Considera que la forma en que se realiza la gestión de riesgos es adecuada?

Sí

No

62%

25%

13%

0% 0%

Importancia de que la forma en que se realiza la gestión de riesgos sea la

adecuada.

Muy importante

Importante


Algo importante

Nada importante

108

P6. ¿Considera adecuada que para la ejecución de la herramienta se implemente la

técnica de Planning Póker?

Como se observa en la Fig. 45, el 100%(8) de los empleados respondió que sí considera

adecuada para ejecución de la herramienta la técnica de Planning Póker.


Importancia de que para la ejecución de la herramienta se implemente la técnica de Planning

Póker.


empleados afirmó que es muy importante, mientras que el 13%(1) le dio un valor de importante y

sólo el 25%(2) le dio un valor de medianamente importante.


100%

0%

5.- ¿Considera adecuada que para la ejecución de la herramienta se implemente

la técnica de Planning Póker?

Sí

No

62% 13%

25%

0% 0%

Importancia de que para la ejecución de la herramienta se implemente la técnica de

Planning Póker.

Muy importante

Importante


Algo importante

Nada importante

109

P7. ¿Considera que las técnicas en las que se fundamenta la herramienta (Delphi,

cuestionarios, gráficas, taxonomía, análisis de datos mediante Tablas) son adecuadas

para la gestión de riesgos?

Como puede observarse en la Fig.47, el 100%(8) de los empleados sí considera que las técnicas en

las que se fundamenta la herramienta son adecuadas para la gestión de riesgos.


Importancia de que las técnicas en las que se fundamenta la herramienta (Delphi, cuestionarios,

gráficas, taxonomía, análisis de datos mediante Tablas) sean adecuadas para la gestión de

riesgos.




100%

0%

6.- ¿Considera que las técnicas en las que se fundamenta la herramienta (Delphi,

cuestionarios, gráficas, taxonomía, análisis de datos mediante tablas) son adecuadas para la


Sí

No

75%

25%

0% 0% 0%

Importancia de que las técnicas en las que se fundamenta la herramienta (Delphi,

cuestionarios, gráficas, taxonomía, análisis de datos mediante tablas) sean adecuadas para la


Muy importante

Importante


Algo importante

110

P8. ¿Qué considera que se debería mejorar en RiskSys?

La pregunta 7 es una pregunta abierta en donde se desea obtener la opinión del usuario para mejorar

la herramienta, por lo que las observaciones se mencionan a continuación.

» Distribuir la información de manera equilibrada para no dejar tantos espacios en blanco.

» Mejorar los márgenes de los reportes en pdf.

» Poner los recuadros de campos de texto más largos.

» Reducir la duración de los videos demostrativos.

» Representar los riesgos a través de valores cualitativos (Alto/Medio/Bajo)

» Que se tomen en cuenta los promedios de todos los colaboradores del proyecto.

111

6.1.4.2. Caso de estudio de la Empresa B

En la Tabla 36 se muestran los datos generales de la Empresa B.

Tabla 36. Descripción de la Empresa B

Nombre Empresa B

Descripción Organización dedicada a proyectos de

investigación y de desarrollo de software.

Número de empleados 10

Muestra de empleados que

participó en el caso 5

Experiencia en gestión de

riesgos Sí

6.1.4.2.1 Resultados de la Encuesta

A continuación se presentan los datos obtenidos al aplicar la Encuesta a la muestra de

empleados de la empresa B, en forma de gráficos.

P1. ¿Considera que la herramienta RiskSys es intuitiva y fácil de utilizar?

En la Fig. 49 se observa que el 100% de los empleados (5) considera que la herramienta es

intuitiva y fácil de utilizar, reafirmando así la usabilidad de la herramienta.

Figura 49. Respuestas de pregunta 1 de Empresa B

100%

0%

1.- ¿Considera que la herramienta RiskSys es intuitiva y fácil de utilizar?

Sí

No

112




Figura 50. Respuestas de importancia de pregunta 1 de Empresa B

P2. ¿Considera que la herramienta RiskSys es adecuada para una gestión de riesgos

básica?

Como se puede observar en la Fig. 51, el 100% (5) de los empleados respondió que la herramienta

es adecuada para realizar una gestión de riesgos básica.


80%

20%

0% 0%

0%


Muy importante

Importante


Algo importante

Nada importante

100%

0%

2.- ¿Considera que la herramienta RiskSys es adecuada para una gestión de riesgos

básica?

Sí

No

113

Importancia de que la herramienta RiskSys sea adecuada para realizar una gestión de riesgos

básica.




P3. ¿Considera que al utilizar RiskSys está implementando buenas prácticas de


Como se puede observar en la Fig. 53, el 80% (4) de los empleados respondió que sí consideran que

al utilizar la herramienta se implementan buenas prácticas de ingeniería de software, y solo un

20%(1) respondió que no, argumentando que la herramienta solo ayuda a realizar buenas prácticas

de ingeniería de software más no asegura que esas prácticas sean buenas.


80%

20%

0% 0% 0%

Importancia de que la herramienta RiskSys sea adecuada para una gestión de riesgos

básica.

Muy importante

Importante


Algo importante

80%

20%

3.- ¿Considera que al utilizar RiskSys está implementando buenas prácticas de


Sí

No

114

Importancia de que al utilizar RiskSys se implementen buenas prácticas de ingeniería de

software.




P4. ¿Considera que la forma en que se realiza la gestión de riesgos es adecuada?

Como se muestra en la Fig. 55, el 60%(3) de los empleados respondió que sí considera que

la forma en que se realiza la gestión de riesgos es adecuada y el 40%(2) respondió que no,

sugiriendo que la herramienta al momento de la selección de los riesgos debería considerar

el total de riesgos seleccionados por el líder de proceso.


80%

20%

Importancia de que al utilizar RiskSys se implementen buenas prácticas de

ingeniería de software.

Muy importante

Importante


Algo importante

Nada importante

60%

40%

4.- ¿Considera que la forma en que se realiza la gestión de riesgos es adecuada?

Sí

No

115

Importancia de que la forma en que se realiza la gestión de riesgos sea la adecuada.



importante.


P5. ¿Considera adecuada que para la ejecución de la herramienta se implemente la

técnica de Planning Póker?

Como se observa en la Fig. 57, el 80%(4) de los empleados respondió que sí considera

adecuada para ejecución de la herramienta la técnica de Planning Póker, mientras que un

20%(1) respondió que no, argumentando que la herramienta no considera todos los riesgos

seleccionados por el líder para todos los colaboradores, de manera que un riesgo elegido por

un solo miembro, tiene un alto valor en impacto y probabilidad siendo que solo una persona

lo consideró.


80%

0% 20%

0% 0%

Importancia de que la forma en que se realiza la gestión de riesgos sea la

adecuada.

Muy importante

Importante


Algo importante

80%

20%

5.- ¿Considera adecuada que para la ejecución de la herramienta se implemente

la técnica de Planning Póker?

Sí

No

116

Importancia de que para la ejecución de la herramienta se implemente la técnica de Planning

Póker.



importante.


P6. ¿Considera que las técnicas en las que se fundamenta la herramienta (Delphi,

cuestionarios, gráficas, taxonomía, análisis de datos mediante Tablas) son adecuadas

para la gestión de riesgos?

Como puede observarse en la Fig. 59, el 100%(5) de los empleados sí considera que las técnicas en

las que se fundamenta la herramienta son adecuadas para la gestión de riesgos.


60%

0%

40%

0% 0%

Importancia de que para la ejecución de la herramienta se implemente la técnica de

Planning Póker.

Muy importante

Importante


Algo importante

Nada importante

100%

0%

6.- ¿Considera que las técnicas en las que se fundamenta la herramienta (Delphi,

cuestionarios, gráficas, taxonomía, análisis de datos mediante tablas) son adecuadas para la


Sí

No

117

Importancia de que las técnicas en las que se fundamenta la herramienta (Delphi, cuestionarios,

gráficas, taxonomía, análisis de datos mediante Tablas) sean adecuadas para la gestión de

riesgos.



importante.


P7. ¿Qué considera que se debería mejorar en RiskSys?

La pregunta 7 es una pregunta abierta en donde se desea obtener la opinión del usuario para mejorar

la herramienta, por lo que en las observaciones se mencionan a continuación.

» Complementar la tabla de gestión de riesgos con una columna que contenga los nombres de

los colaboradores que evaluaron el riesgo.

» Mostrar una rúbrica que diga lo que significa Alto, Medio y Bajo.

» La estimación de cada riesgo debería ser estimada por todos los miembros para tener un

promedio más acertado.

» Emplear rangos cualitativos (alto, medio, bajo) para medir los riesgos en lugar de

cuantitativos.

80%

0% 20%

0% 0%

Importancia de que las técnicas en las que se fundamenta la herramienta (Delphi,

cuestionarios, gráficas, taxonomía, análisis de datos mediante tablas) sean adecuadas para la


Muy importante

Importante


Algo importante

118

6.1.5. Informe de resultados

Derivado de los casos de estudio aplicados a la Empresa A y empresa B, que tienen experiencia en

la gestión de riesgos, la empresa A se dedica al desarrollo de software a la medida así como

instalación y venta de equipo de cómputo, la empresa B se dedica a desarrollo de proyectos de

investigación y de software, al utilizar la herramienta pudieron realizar una gestión de riesgos de

manera consensuada, algunos de los empleados enfatizaron que la herramienta es colaborativa y eso

les agradó, de igual manera, hicieron algunas sugerencias de mejora que serán tomadas en cuenta

en el trabajo futuro.

A continuación, se presentan los resultados a partir de los datos obtenidos en la encuesta.

» Las técnicas (tradicionales/ágiles) son adecuadas para realizar una gestión de riesgos

básica. Todos los empleados estuvieron de acuerdo en que las técnicas en las que se

fundamenta la herramienta son adecuadas para realizar una gestión de riesgos básica,

destacando la ejecución del Planning Póker.

» La forma en la que se realiza la gestión de riesgos en la herramienta es adecuada o

suficiente. Al 90% de los empleados sí les pareció que la herramienta realiza una gestión

de riesgos básica, y un 10% sugirió que en la gestión de riesgos en equipo se consideren

los dos tipos de acciones (contención y mitigación) para un mejor tratamiento, así como

que en el proceso de gestión de riesgos individual, los usuarios evalúen todos los riesgos

que el líder de proceso seleccionó para el proyecto.

» La herramienta es usable (eficiente, intuitiva y amigable al usuario). Todos los

empleados estuvieron de acuerdo en que la herramienta es fácil de utilizar.

» La herramienta facilita la implementación de buenas prácticas de ingeniería de software

en las pymes. El 95% de los empleados respondió que la herramienta sí facilita la

implementación de buenas prácticas, aunque un 5% presenta cierta resistencia al cambio

argumentando que la herramienta no asegura que sean buenas prácticas, así como que la

cultura de la empresa influye en que no se implementen.

De acuerdo a los resultados de la pregunta 3 (P3) en los dos casos de estudio la hipótesis se

acepta, ya que los usuarios están de acuerdo en que las herramientas basadas en mejores prácticas

facilitan el uso de buenas prácticas en las pymes.

120

Capítulo 7. Conclusiones

En este capítulo se presentan las conclusiones obtenidas. Además, se presenta el trabajo

futuro derivado de este tema de investigación, y por último, se abordan los productos

académicos de esta investigación.

7.1. Conclusiones

Aunque existen muchos trabajos referentes a la gestión de proyectos, todavía se continúa

con los problemas de falta de conocimiento por parte de los ingenieros hacia la realización de

prácticas de la gestión de proyectos, así como de la elección de herramientas adecuadas a su

entorno que permitan la implementación y fomenten el uso de buenas prácticas de ingeniería

de software, por lo tanto, el aporte que este trabajo proporciona a los ingenieros es:

» El conocimiento sobre las técnicas y herramientas utilizadas en las áreas de gestión

de riesgos, planificación del proyecto y, monitorización y control del proyecto.

» Un conjunto de técnicas y herramientas clasificadas por enfoque y nivel de

dificultad, que de acuerdo a la valoración de criterios especificados en cada técnica,

ayudarán a la pyme en la elección de la más adecuada a sus necesidades.

» Un análisis de cobertura de prácticas específicas, técnicas y herramientas que puede

reforzar el uso e implementación de buenas prácticas en las pymes.

» Estado del arte de técnicas y herramientas en la gestión de proyectos en específico en

las áreas de gestión de riesgos, planificación del proyecto y monitorización y control

del proyecto.

» Método para la generación de herramientas de buenas prácticas.

» Herramienta para la Gestión de Riesgos básica.

» Resultados de 2 casos de estudio de aplicación del método.

» 4 artículos publicados y uno enviado.

Finalmente, cabe resaltar que la herramienta de gestión de permite llevar a cabo una

gestión de riesgos básica, con lo cual se está impulsando la implementación de buenas

prácticas de ingeniería de software enfocadas en la gestión de riesgos.

7.2. Trabajo futuro

Es importante mencionar que como trabajo futuro se espera lograr la caracterización de la

organización para que en conjunto con el método propuesto, se obtenga un Catálogo de

121

técnicas y herramientas que ayude a las pymes a implementar buenas prácticas de ingeniería

de software.

Para realizar la caracterización de la organización, se obtendrán datos de la organización

para conocer su entorno. La información requerida de la organización está basada en el

“Cuestionario para establecer la situación actual de las empresas”.

La información a obtener para la caracterización de la pyme se enfoca en las

características de la organización a través de la recopilación y análisis de datos generales de la

empresa y su experiencia en el uso de modelos y estándares de calidad, así como

metodologías que utilice la empresa para el desarrollo de sus productos.

A continuación se describe la información requerida de la empresa:

» Información general: (1) Nombre de la empresa;

(2) Tipo de empresa;

(3) Perfil de la organización;

(4) Número de empleados;

(5) Forma de trabajo mediante equipos y

(6) Número de integrantes de equipo.

» Información relacionada con el uso de modelos y estándares de calidad:

(1) Certificaciones obtenidas por la empresa;

(2) Metodología de desarrollo utilizada (Ágil/Tradicional/Híbrida);

(3) Técnicas utilizadas actualmente y

(4) Herramientas utilizadas actualmente.

El proceso para el análisis de la información obtenida de la organización se muestra en la

Fig. 61. Como puede observarse en la Figura, una vez recabada la información, se analiza

internamente por el catálogo, de tal forma que de acuerdo a las características de la empresa,

el catálogo le proporcionará la lista de aquellas técnicas y herramientas que mejor se ajusten a

su forma de trabajo y contexto. Además, el catálogo podrá desglosar la técnica o

herramienta a detalle para facilitar la implementación de la misma.

122

Figura 61. Diagrama de implementación del catálogo

7.3. Logros académicos

A continuación se muestran los logros académicos obtenidos a partir de la presente

investigación.

7.3.1. Productos académicos

Artículos publicados

» García, Y.M, Muñoz, M., Mejía, J.,Gasca, G.P., Mireles, A. (2017). Application of a

Risk Management Tool Focused on Helping to SME’s Implementing the Best

Practices in Software Development Projects. 6th World Conference on Information

Systems and Technologies 2018(WORLDCIST 18). Estatus: Enviado.

» García, Y.M., Muñoz, M., Mejía, J.,Gasca-Hurtado, G.P. (2017). Analysis of Projects

Planning and Monitorization and Control Techniques and Tools for their use in

SMEs. 12ª Conferencia Ibérica de Sistemas y Tecnologías de Información 2017

(CISTI 2017). Estatus: Publicado.

» García, Y.-M., Muñoz, M., Mejía, J., Martínez, J., Gasca-Hurtado, G. P., & Hincapié, J.-A. (2016). Method for Developing Catalogs focused on Facilitating the

Implementation of Best Practices for SMEs. 2016 International Conference on

123

Software Process Improvement (CIMPS), 1–8.

http://doi.org/10.1109/CIMPS.2016.7802805. Estatus: Publicado.

» García, Y.-M., Muñoz, M., Mejía, J., Martínez, J., Gasca-Hurtado, G. P., & Hincapié,

J.-A Revista electrónica ReCIBE. Extensión de artículo “Desarrollo de

Herramientas Enfocadas en Ayudar a las Pymes de Desarrollo de Software en la

Implementación de Buenas Prácticas de Gestión de Proyectos”. Mayo 2017, Vol.

6, Núm.1. Estatus: Publicado.

Enlace http://recibe.cucei.udg.mx/Recibe/index.php/Recibe/article/view/68

» Martínez, J., Mejía, J., Muñoz M., García, Y.-M . Revista electrónica ReCIBE.

Extensión de artículo “La Seguridad en Internet de las Cosas: Analizando el

Tráfico de Información en Aplicaciones para iOS- Security in the Internet of

Things: Information Traffic Analysis for iOS Apps”. Mayo 2017, Vol. 6, Núm..1.

Estatus: Publicado

Enlace http://recibe.cucei.udg.mx/Recibe/index.php/Recibe/article/view/70

Desarrollo de la herramienta de gestión de riesgos RiskSys.

Participación en proyectos reales (Universidad de Medellín, Chiva Sentada, Cimat

Guanajuato).

Desarrollador de un oda en Unity3d aplicando TSP. (Cimat-Chiva Sentada).

7.3.2. Ponencias en congresos

Ponencia en el Congreso Internacional en Mejora de Procesos de Software (CIMPS 2016),

presentando el artículo Método para el Desarrollo de Catálogos enfocados en Facilitar la

Implementación de Buenas Prácticas en Pymes.

http://recibe.cucei.udg.mx/Recibe/index.php/Recibe/article/view/68

http://recibe.cucei.udg.mx/Recibe/index.php/Recibe/article/view/70

124

Referencias

Accountants, I. of M. (2007). Enterprise Risk Management: Tools and Techniques for effective

implementation, 34.

Arora, A., & Naresh, C. (2014). A Risk Based Story Prioritization Technique In An Agile

Environment. International Journal of Advance Foundation and Research in Computer, 1(7),

16–25.

Barbacci, M., Klein, M. H., Longstaff, T. A., & Weinstock, C. B. (1995). Quality Attributes Technical

Report CMU/SEI-95-TR-021. Pittsburgh, Pennsylvania, E.U.

Bastos, P., & Silveira, F. (2009). Desafíos y oportunidades de la industria del software en América

Latina. (Cepal, Ed.). Colombia: Cepal en coedición con Mayol Ediciones.

Bundschuh, M., & Carol, D. (2008). The IT Measurement Compendium: Estimating and

Benchmarking Success with Functional Size Measurement. Springer-Verlag Berlin Heidelberg.

Carr, M., Konda, S., Monarch, I., Ulrich, F., & Walker, C. (1993). Taxonomy-based risk

identification. Software Engineering Institute, (June), 1–24. http://doi.org/CMU/SEI-93-TR-006

Chrissis, M., Konrad, M., & Shrum, S. (2010). CMMI para Desarrollo: Guía para la integración de

procesos y la mejora de productos, Versión 1.3. Retrieved from

http://www.sei.cmu.edu/library/assets/whitepapers/Spanish Technical Report CMMI V 1 3.pdf

Clifford, A. (2014). Software Early Estimation Model ( SEEM ). SEIR.

Contact, M. (2014). Tendencias de crecimiento y adopción de TI en México para 2015. Retrieved

from http://mundocontact.com/tendencias-de-crecimiento-y-adopcion-de-ti-en-mexico-para-

2015/

Cuadrado-García, J. L., Cuadrado-Gallego, J. J., Herranz-Martínez, M. a., & Rodríguez-Soria, P.

(2011). Improve tracking in the software development projects. Proceedings - Joint Conference

of the 21st International Workshop on Software Measurement, IWSM 2011 and the 6th

International Conference on Software Process and Product Measurement, MENSURA 2011,

(table I), 215–220. http://doi.org/10.1109/IWSM-MENSURA.2011.10

Dagnino, A. (2010). Alternatives to Define Simple CMMI-compliant Software Estimation Procedures,

1–58.

Durón, B., Muñoz, M., & Mejía, J. (2013). Actual state of implementing software process

improvements in software organizations. Information Systems and Technologies (CISTI),

2013 8th Iberian Conference on, 1–7.

Engineering, S., & Committee, S. (2001). IEEE Standard for Software Life Cycle Processes — Risk

Management.

Fischer, U. (2011). Feature IT Scenario Analysis in Enterprise Risk Management, 1–4.

García M., S. (Django S. C. (2015). Django, la guía definitiva. Desarrolla aplicaciones Web de forma

rápida y sencilla usando Django, Versión 1., 567.

125

Gómez, G. E., Aguileta, A. A., Ancona, G. B., & Gómez, O. S. (2014). Avances en las Mejoras de

Procesos Software en las MiPyMEs Desarrolladoras de Software: Una Revisión Sistemática,

2(4), 262–268.

Hefley, B., & Loesche, E. A. (2006). eSourcing Capability Model for Client Organizations – eSCM-

CL, 450. http://doi.org/CMU-ITSQC-006-02

ISO. (2012). INTERNATIONAL STANDARD ISO / IEC ISO/IEC 15504-5 Information technology —

Security.

ISO. (2013). ISO/IEC 27001:2013 - Information technology -- Security techniques -- Information

security management systems -- Requirements. Retrieved from

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=54534&goback

=.gde_4016468_member_276597883#

ISO. (2003). ISO/IEC TR 9126-3 -Software Engineering -- Product quality -Part 3: Internal metrics.

Jacobs, B., & Schenker, F. (2008). Project Management by Functional Capability. Software

Engineering Institute.

Kitchenham, B. (2004). Procedures for performing systematic reviews. Keele, UK, Keele University,

33(TR/SE-0401), 28. http://doi.org/10.1.1.122.3308

Mas, A., & Amengual, E. (2005). La mejora de los procesos de software en las pequeñas y medianas

empresas (pyme). Un nuevo modelo y su aplicación a un caso real. REICIS. Revista Española de

Innovación, Calidad E Ingeniería Del Software, 1(2), 7–29. Retrieved from

http://www.redalyc.org/articulo.oa?id=92210203%0ACómo

McManus, J. (2012). Software Engineering Risk Management. (Routledge, Ed.).

Muñoz, M., Gasca, G., & Valtierra, C. (2014). Caracterizando las necesidades de las pymes para

implementar mejoras de procesos software: Una comparativa entre la teor??a y la realidad. RISTI

- Revista Iberica de Sistemas E Tecnologias de Informacao, 1(E1), 1–15.

http://doi.org/10.4304/risti.e1.1-15

Navarro, J. M., & Garzás, J. (2010). Experiencia en la implantación de CMMI-DEV v1.2 en una

micropyme con metodologías ágiles y software libre. Revista Española de Innovación, Calidad

E Ingeniería Del Software, 6(1), 6–15.

Niazi, M., Wilson, D., & Zowghi, D. (2005). A maturity model for the implementation of software

process improvement : an empirical study. The Journal of Systems and Software, 74(2), 155–

172. http://doi.org/10.1016/j.jss.2003.10.017

Perez Serrano, G. (2014). Investigación cualitativa (La Muralla, Ed.) (6th ed.). Madrid, España.

Pino, F., García, F., & Piattini, M. (2006). Revisión sistemática de mejora de procesos software en

micro , pequeñas y medianas empresas. Revista Espa Nola de Innovación Calidad E Ingeniería

Del Software REICIS, 2(1), 6–23. Retrieved from

http://redalyc.uaemex.mx/pdf/922/92220103.pdf

Plaza, M., & Turetken, O. (2009). A model-based DSS for integrating the impact of learning in project

control. Decision Support Systems, 47(4), 488–499. http://doi.org/10.1016/j.dss.2009.04.010

Pressman, R. (2010). Ingeniería Del Software Un enfoque práctica. (McGraw-Hill Interamericana,

126

Ed.) (7th ed.). México.

Project Management Institute. (2000). Project Management Body of Knowledge A Guide to the

Project Management Body of Knowledge. http://doi.org/10.1002/pmj.20125

Públicas, M. de H. y A. (2012a). MAGERIT- versión 3.0 Metodología de Análisis y Gestión de

Riesgos de los Sistemas de Información Libro II - Catálogo de Elementos, 75. Retrieved from

http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Ma

gerit.html

Públicas, M. de H. y A. (2012b). MAGERIT - versión 3.0 Metodología de Análisis y Gestión de

Riesgos de los Sistemas de Información Libro I - Método, 127. Retrieved from

http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Ma

gerit.html

Públicas, M. de H. y A. (2012c). MAGERIT - versión 3.0 Metodología de Análisis y Gestión de

Riesgos de los Sistemas de Información Libro III - Guía de Técnicas, 42. Retrieved from

http://administracionelectronica.gob.es/ctt/resources/Soluciones/184/Area descargas/Libro-III-

Guia-de-Tecnicas.pdf?idIniciativa=184&idElemento=87&idioma=en

Rajchel, L., Takahashi, M., Fumy, W., Soete, M. De, Humphreys, E. J., Chikazawa, T., … Min, J.

(2011). International Standard Iso / Iec (Vol. 1).

Rivas, L., Perez, M., Mendoza, L. E., & Grimán, A. (2010). Selection model for Software Project

Management tools in SMEs. 2010 2nd International Conference on Software Technology and

Engineering, ICSTE 2010, 1, V192–V196. http://doi.org/10.1109/ICSTE.2010.5608904

Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in

software engineering. Empirical Software Engineering, 14(2), 131–164.

http://doi.org/10.1007/s10664-008-9102-8

Schenker, F. (2008). Recursion in the CMMI Project Management Process Areas.

Singh, M., & Saxena, R. (2014). Risk Management in Agile Model, 16(5), 43–46.

Stake, R. E. (1999). Investigación con caso de estudios (Segunda). Madrid, España: Ediciones Morata,

S.L.

Tomayko, J. E., & Hallman, H. K. (1989). Software Project Management SEI Curriculum Module

SEI-CM-21-1.0.

Tomer, A. (2015). Software Mangineeringment :, (March), 5–11.

Torrecilla-Salinas, C. J., Sedeño, J., Escalona, M. J., & Mejías, M. (2015). Estimating, planning and

managing Agile Web development projects under a value-based perspective. Information and

Software Technology, 61, 124–144. http://doi.org/10.1016/j.infsof.2015.01.006

Wangenheim, C. G. Von, Carlo, J., Hauck, R., & Wangenheim, A. Von. (2009). Enhancing Open

Source Software in Alignment with CMMI-DEV, (April), 59–67.

Wohlin, C., Höst, M., & Henningsson, K. (2003). Empirical Research Methods in Software

Engineering. Springer-Verlag Berlin Heidelberg 2003, 7–23.

Yin, R. K. (2002). Case study research: design and methods. Applied social research method series

127

(tercera ed, Vol. 5). http://doi.org/10.1097/FCH.0b013e31822dda9e

Ylimannela, V. (2012). A Model for Risk Management in Agile Software Development.

Communications of Cloud Software.

128

Anexo I Información de EP sobre

Planificación y Monitorización y

Control de Proyectos

i

Anexo II Diseño de la herramienta

RiskSys

DS-01 Autentificar usuario

DS-02 Registrar usuario

ii

DS-03 Registrar empresa

DS-04 Registrar proyecto

iii

DS-05 Seleccionar proyecto

DS-06 CRUD de usuarios

iv

DS-07 Establecer parámetros de categorías de probabilidad

DS-08 Establecer parámetros de categorías de impacto

v

DS-09 Consultar tratamiento de riesgos

DS-09 Mostrar gráfica de riesgos

vi

Anexo III Funcionalidad principal de la

herramienta RiskSys

1) Iniciar sesión

A continuación se muestra la pantalla de inicio de sesión, una vez que la cuenta fue creada,

ahora el usuario puede ingresar su nombre de usuario, su contraseña y Entrar.

vii

2) Página Principal RiskSys La pantalla de la página principal , en la parte superior se muestra un menu de opciones así

como la sesión activa, la parte central contiene información de RiskSys y finalmente la parte

inferior contiene la selección del Proyecto para iniciar la gestión de riesgos individual.

3) Cerrar sesión La pantalla de enlace muestra el enlace para cerrar la sesión activa, así como la pantalla

siguiente muestra el mensaje de sesión finalizada.

viii

5) Editar cuenta La pantalla de Página Principal, donde se encuentra el enlace editar su perfil que se utiliza

para actualizar los datos de la cuenta del usuario activo.

» Formulario Editar cuenta: La Fig. 82 muestra el formulario de Editar cuenta, que

contiene los campos con los datos personales del usuario activo, el usuario

podrá modificar los campos que deseé y guardará los cambios.

ix

» Mensaje de éxito de cuenta editada: Cuando se actualizaron los datos personales

del usuario, se muestra un mensaje de éxito como se muestra en la siguiente

pantalla.

6) Modificar contraseña La siguiente pantalla de Página Principal, donde se encuentra el enlace cambiar su contraseña

que se utiliza para modificar la contraseña del usuario activo.

» Formulario Cambiar contraseña: En la siguiente pantalla se muestra el formulario

Cambiar contraseña, contiene los campos que el usuario activo tendrá que llenar para

que pueda cambiar su contraseña.

x

Formulario Cambiar contraseña

» Mensaje de éxito de contraseña modificada: Cuando se modificó la contraseña

correctamente, se muestra un mensaje de éxito como se muestra en la pantalla

siguiente.

xi

7) Catálogo de Riesgos La siguiente pantalla muestra el listado de riesgos, contiene el nombre del riesgo, su descripción y la

categoría a la que pertenecen, el Catálogo de Riesgos está basado en la Taxonomía de Riesgos del

SEI.

» Agregar riesgos. - En esta opción, el Líder de Proceso puede agregar un nuevo riesgo

presionando el boton Agregar.

xii

» Formulario Riesgos.- En la siguiente pantalla se muestra el formulario de Riesgos, en

donde el usuario tendrá que llenar los campos como nombre del riesgo, descripción,

seleccionar la categoría a la que pertenece y dar click en Guardar.

» Actualizar riesgos. - Si el Líder de Proceso desea modificar algún campo del riesgo,

debe ubicar el registro y presionar el botón Actualizar.

» Formulario actualizar riesgos.- En este formulario se cargan los datos del riesgo

seleccionado, por lo que el usuario puede modificar los campos que deseé y para

finalizar dar click en el botón Actualizar.

xiii

» Borrar riesgos. - Si el Líder de Proceso desea borrar un riesgo, debe ubicar el registro

y dar click en el botón Borrar.

xiv

8) Gestión de Catálogo de Riesgos » Selección del Proyecto.- En la siguiente pantalla de selección, se muestra el Proyecto

para el cual se desea conformar el Catálogo de Riesgos.

» Selección de riesgos que pueden afectar al proyecto.- En la siguiente pantalla se

muestra el Catálogo de Riesgos general, el Líder de Proceso de acuerdo a su juicio

experto seleccionará los que considere que podrían afectar el desarrollo del proyecto.

La siguiente pantalla muestra los riesgos marcados que el Líder de Proceso marcó para

conformar el catálogo de riesgos del proyecto, para finalizar presionó el botón Seleccionar.

xv

» Mensaje de éxito de Catálogo de Riesgos del proyecto conformado.- Cuando

seleccionó previamente los riesgos para el proyecto aparece un mensaje de éxito

indicando que se conformó el catálogo de riesgos para el proyecto, tal como se

muestra en la siguiente pantalla.

xvi

10) Gestión de riesgos de manera individual En esta sección se podrá obtener una lista de riesgos categorizados, identificar los riesgos,

establecer parámetros de evaluación así como evaluar los riesgos.

» Selección del proyecto para iniciar a gestionar riesgos de manera individual.- En esta

pantalla se debe seleccionar el proyecto con el que se desea gestionar riesgos,

previamente el Líder de Proceso tuvo que asignarle proyectos al usuario.

» Selección de riesgos de manera individual.- En esta pantalla se muestra el Catálogo de

Riesgos que el Líder de Proceso seleccionó para el proyecto, el usuario de manera

individual y de acuerdo a su juicio experto marcará aquellos que considere pueden

afectar al proyecto y oprimirá el botón Seleccionar.

» Identificación y evaluación de riesgos.- En esta pantalla en la que el usuario una vez

que seleccionó los riesgos, los evaluará con parámetros de probabilidad e impacto y

dará click en el botón Guardar.

xvii

» Mensaje de éxito de gestión de riesgos individual.- En la Fig. 100, se muestra el

mensaje de éxito una vez que el usuario terminó de realizar la gestión de riesgos de

manera individual.

xviii

12) Gestion de Riesgos en equipo En esta sección el Líder de Proceso debe ingresar al módulo de Gestión de Riesgos, es un

proceso que se realiza de manera ágil a través de una reunión del Líder de Proceso con los

miembros del equipo, algo similar a las reuniones que se tienen en Scrum así como la técnica

de Planning Poker. Todos los miembros del equipo asignados al proyecto deben haber

realizado la gestión de riesgos de manera individual. En esta sección se evalúan, priorizan y

clasifican los riesgos, así como también se establecen estrategias.

» Módulo de Gestión de Riesgos

El Líder de Proceso y los miembros del equipo se reúnen, el Líder de Proceso deberá entrar al

módulo de Gestión de Riesgos, primero deberá seleccionar el proyecto y enseguida entrará a

la pantalla de Gestión de Riesgos. La pantalla del módulo se muestra en la pantalla siguiente.

» Mensaje de nueva iteración.- Esta pantalla muestra el mensaje de que se comenzó una

nueva iteración.

xix

13) Tratamiento de riesgos por proyecto La pantalla muestra el reporte muestra los datos de los riesgos gestionados así como el

tipo de acción de tratamiento (mitigación/contención) el responsable, la iteración,

entre otros. Este reporte se puede guardar en formato pdf.

14) Mostrar gráfica En esta sección se muestra una gráfica de riesgos gestionados por proyecto.

» Selección de proyecto para ver gráfico.- La pantalla de selección de proyecto, en la

cual el usuario debe seleccionar el proyecto para el cual desea ver la gráfica.

» Gráfica de riesgos del proyecto.- En caso de seleccionar un proyecto que si contenga

riesgos gestionados, se mostrará la gráfica como se puede apreciar en la pantalla.

Contiene el título del proyecto, el número de iteración en la que se encuentre, los

riesgos gestionados en forma de burbuja, así como un botón de Versión Imprimible

para guarder la gráfica si el usuario así lo desea.

La escala de valores es por colores y expresada en porcentaje.

Verde.- Riesgos con baja probabilidad e impacto

Amarillo.- Riesgos con media probabilidad e impacto.

Rojo.- Riesgos con alta probabilidad e impacto. (Son los que tienen que gestionarse).

xxi

16) Establecer estrategia Esta sección se refiere al listado de riesgos gestionados con responsable y tipo de acción

(contención/ mitigación) filtrados por proyecto.

» Selección de proyecto para reporte de Tratamiento de Riesgos.- En la pantalla se debe

seleccionar el proyecto para el cual se desea ver el reporte de Tratamiento de Riesgos.

» Tratamiento de riesgos por proyecto.- La siguiente pantalla muestra el reporte de

Tratamiento de Riesgos por proyecto, así como la opción de guardar el reporte en

formato pdf.

xxii

18) Empresa En la pantalla se muestra el modulo de Empresas, donde el Líder de Proceso puede

agregar/actualizar/borrar los datos de la empresa.

» Agregar Empresa.- Si el Líder de Proceso desea agregar una nueva empresa, debe

presionar el botón Agregar.

» Formulario Agregar Empresa.- La siguiente pantalla muestra el formulario para

agregar una nueva empresa, el Líder de Proceso tendrá que ingresar los campos de

nombre de la empresa, el domicilio y presionar el botón Guardar.

xxiii

» Borrar empresa.- Si el Líder de Proceso desea borrar una empresa, deberá ubicar el

registro y presionar el botón rojo Borrar de la pantalla siguiente.

» Actualizar empresa.- Si el Líder de Proceso desea actualizar los datos de una empresa,

deberá ubicar el registro y presionar el botón azul Actualizar.

» Formulario Actualizar Empresa.- En la siguiente pantalla se muestra el formulario

para actualizar los datos de la empresa, el Líder de Proceso deberá modificar los

campos que deseé y presionar el botón Actualizar.

xxiv

19) Proyectos En este módulo se muestra la información de los proyectos, el Líder de Proceso puede

Agregar/Actualizar/Borrar un Proyecto.

» Agregar Proyecto.- Para que el Líder de Proceso agregue un Nuevo Proyecto, deberá

presionar el botón Azul Agregar.

» Formulario Agregar Proyecto.- Como se muestra en la pantalla siguiente, el Líder de

Proceso deberá llenar los campos del formulario y presionar Guardar.

xxv

» Actualizar Proyecto.- Si el Líder de Proceso desea actualizar los datos de un Proyecto,

deberá ubicar el registro y presionar el botón azul Actualizar de la pantalla siguiente.

» Formulario Actualizar Proyecto.- En la pantalla a continuación se muestra el

formulario con los datos del proyecto que el Líder de Proceso desea actualizar, deberá

modificar los campos que deseé y presionar el botón Actualizar.

Formulario Actualizar Proyecto

xxvi

» Borrar Proyecto.- Si el Líder de Proceso desea borrar el Proyecto, deberá ubicar el

registro y presionar el botón rojo Borrar.

20) Categorías de Probabilidad

En esta sección se muestran los valores de los parámetros de categorías de probabilidad que el

Líder de Proceso establecerá por Proyecto, las categorías son Alta(A)/Media(M)/Baja(B).

» Selección de Proyecto para establecer valores de categoría de probabilidad

» Agregar Categoría de Probabilidad.- El Líder de Proceso deberá dar click en el botón

Agregar para agregar las categorías de probabilidad y sus respectivos valores.

Formulario Agregar Categoría de Probabilidad.- En la pantalla siguiente se muestra el

formulario para agregar las categorías de probabilidad y sus valores para cada una, las

categorías son Alto(A)/Medio(M)/Bajo(B). En la segunda pantalla se muestran las tres

categorías con sus respectivos valores establecidos.

xxvii

» Actualizar Categorías de Probabilidad.- Si el Líder de Proceso desea actualizar el

valor de una categoría, ubica el registro y presiona el botón Actualizar.

» Formulario Actualizar Categoría de Probabilidad.- En siguiente pantalla se muestra

el formulario con los datos del registro que desea modificar, el Líder de Proceso debe

actualizar el valor y oprimir el botón Actualizar.

xxviii

21) Categorías de Impacto En esta sección se muestran los valores de los parámetros de categorías de impacto que el

Líder de Proceso establecerá por Proyecto, las categorías son: Muy Alto(MA)/Alto(A)/

Medio(M)/Bajo(B)/Muy Bajo (MB).

»Selección de Proyecto para establecer valores de categoría de impacto.

» Agregar Categoría de Impacto.- El Líder de Proceso deberá dar click en el botón Agregar

para agregar las categorías de impacto y sus respectivos valores.

» Formulario Agregar Categoría de Probabilidad.- En la pantalla siguiente se muestra

el formulario para agregar las categorías de impacto y sus valores para cada una. En la

segunda pantalla se muestran las cinco categorías con sus respectivos valores

establecidos.

xxix

» Actualizar Categorías de Probabilidad.- Si el Líder de Proceso desea actualizar el

valor de una categoría, ubica el registro y presiona el botón Actualizar.

» Formulario Actualizar Categoría de Impacto- En la pantalla siguiente se muestra el

formulario con los datos del registro que desea modificar, el Líder de Proceso debe

actualizar el valor y oprimir el botón Actualizar.

xxxi

22) Última evaluación de riesgos Esta sección contiene el reporte de la última valoración de riesgos que el usuario activo

realize para cierto Proyecto.

» Selección de Proyecto para ver la última valoración de riesgos

» Reporte de última valoración de riesgos.- Si el usuario activo realizó una gestión de

riesgos de manera individual, se cargarán los registros de la última valoración de

riesgos que realizó, con la opción de guardar en formato pdf dicho reporte.

xxxii

23) Acerca de En la pantalla siguiente se muestra la información referente al sistema, nombre del Proyecto

al que pertenece, así como los colaboradores y desarrolladores.

MÉTODO PARA EL DESARROLLO DE HERRAMIENTAS … · zacatecas, zac. 12 dic 2017 mÉtodo para el...

Documents

Transcript of MÉTODO PARA EL DESARROLLO DE HERRAMIENTAS … · zacatecas, zac. 12 dic 2017 mÉtodo para el...