TESIS de Maestría en
Ingeniería en Sistemas de Información
"METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO
LOGICO"
Tesista: Esp. Ing. Luz Estela Pineda Forero
Director: Doc.(c) Inés Casanovas
Codirector: Doc.(c) Miguel Ángel Cid Correa
Ciudad Autónoma de Buenos Aires, 2013
Dedicatoria
A Dios, por la oportunidad y salud para lograr mis objetivos. A mis padres Luz Marina y José Joaquín por enseñarme el valor del esfuerzo. A mis hermanas Cristina, Sandra, Rocío y Nora (D.E.P.) por su apoyo y motivación en mis emprendimientos. A mi esposo Terry por su ayuda, apoyo, motivación y amor.
Agradecimientos
A la Universidad Tecnológica Nacional por la oportunidad para cumplir mis objetivos académicos y de formación profesional, y por la colaboración que me brindaron tanto en Argentina y desde la distancia con mi país de Colombia A mi directora de Tesis Mg. Inés Casanovas, por sus orientaciones y asesorías en el desarrollo del proyecto. A mi codirector de Tesis Doc. (c) Miguel Ángel Cid, por su iniciativa en el tema del proyecto, sabiduría, y orientaciones como experto en el tema propuesto. A los ingenieros expertos por su tiempo y aportes en la validación de la metodología propuesta. A mis colegas por sus ideas y aportes en el desarrollo del proyecto. A la Mg. Ing. María Florencia Pollo Cattaneo y a Hernán Amatriain por su valiosa colaboración en el proceso de entrega de la tesis en la facultad.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
i
Índice
Pág. Índice de Figuras .......................................................................................................... iii Índice de Tablas ........................................................................................................... v Índice de Esquemas .................................................................................................... ix Nomenclatura ............................................................................................................... x Resumen ..................................................................................................................... xii Abstract ....................................................................................................................... xii CAPITULO 1. INTRODUCCIÓN ................................................................................... 1
1.1. Objetivos ............................................................................................................ 1 1.1.1. Objetivo general. .......................................................................................... 1 1.1.2. Objetivos específicos. .................................................................................. 1
1.2. Alcance .............................................................................................................. 2 1.3. Fundamentos del trabajo .................................................................................... 3 1.4. Metodología empleada ....................................................................................... 4 1.5. Estructura del trabajo ......................................................................................... 6
CAPITULO 2. ESTADO DEL ARTE .............................................................................. 8 2.1. Requerimientos de software ............................................................................... 8
2.1.1. Definición de requerimiento. ........................................................................ 8 2.1.2. Características de los requerimientos. ......................................................... 9 2.1.3. Niveles de descripción de los requerimientos. ........................................... 10 2.1.4. Clasificación de los requerimientos. ........................................................... 11
2.2. Ingeniería de requerimientos ............................................................................ 12 2.2.1. Estructura de la Ingeniería de requerimientos. ........................................... 13 2.2.2. Proceso de ingeniería de requerimientos. .................................................. 14 2.2.3. Documentación de los requerimientos. ...................................................... 21
2.3. Elicitación de requerimientos ............................................................................ 24 2.3.1. El proceso de elicitación. ........................................................................... 25 2.3.2. Fuentes de los requerimientos. .................................................................. 30 2.3.3. Técnicas de elicitación. .............................................................................. 31 2.3.4. Participantes en la elicitación de requerimientos. ....................................... 35
2.4. Enfoques de algunos estándares y modelos en la elicitación de requerimientos de software ............................................................................................................. 39
2.4.1. Estándares IEEE para desarrollo de la ingeniería de sistemas. ................ 39 2.4.2. Modelos para procesos de software. ......................................................... 46
2.5. Metodología de marco lógico ............................................................................ 68 2.5.1. Definición del marco lógico ........................................................................ 68 2.5.2. Fases del marco lógico. ............................................................................. 69
2.6. Resumen .......................................................................................................... 88 CAPITULO 3. PROBLEMA ........................................................................................ 91
3.1. Introducción. ..................................................................................................... 91 3.2. Descripción del problema ................................................................................. 91
3.2.1. Fracasos en proyectos de software. ........................................................... 91 3.2.2. Problemas en el proceso de elicitación de software ................................... 93
3.3. Preguntas de investigación.............................................................................. 97 CAPITULO 4. SOLUCIÓN .......................................................................................... 99
4.1 Análisis en la elicitación de requerimientos de software y el apoyo que aporta la metodología de marco lógico. ................................................................................. 99 4.2. Propuesta ....................................................................................................... 108 4.3. Solución basada en la propuesta ................................................................... 108
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
ii
4.3.1. Metodología para la elicitación de requerimientos de software basada en el marco lógico ...................................................................................................... 109
CAPITULO 5. CASO DE ESTUDIO .......................................................................... 153 CAPITULO 6. VALIDACION DE LA PROPUESTA ................................................... 188
6.1. Modelo de validación seleccionado ................................................................ 188 6.2. Expertos seleccionados .................................................................................. 188 6.3. Resultado de la evaluación de los expertos .................................................... 191
CAPITULO 7. CONCLUSIONES Y APORTACIONES DE ESTA TESIS .................. 197 7.1. Conclusiones .................................................................................................. 197
7.1.1. Valoración sobre la investigación documental .......................................... 197 7.1.2. Valoración del problema .......................................................................... 198 7.1.3. Valoración de la solución ......................................................................... 199 7.1.4. Valoración del caso de estudio ................................................................ 201 7.1.5. Respuesta a los interrogantes de investigación ....................................... 201
7.2. Futuras líneas de investigación ...................................................................... 203 CAPITULO 8. BIBLIOGRAFIA .................................................................................. 204 ANEXOS ................................................................................................................... 209 ANEXO I. Cuestionario modelo ................................................................................. 210
ANEXO II. Evaluación Experto No. 1 ..................................................................... 213 ANEXO III. Evaluación Experto No. 2 .................................................................... 217 ANEXO IV. Evaluación Experto No. 3 ................................................................... 221
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
iii
Índice de Figuras
Pág. Figura 1. Estructura de la ingeniería de requerimientos. Traducción libre. Extraído de (Wiegers, 2003)............................................................................. 13 Figura 2. Proceso de ingeniería de requerimientos. Traducción libre. Extraído de (Loucopoulos & Karakostas, 1995) ............................................................. 15 Figura 3. Modelo espiral del proceso de ingeniería de requerimientos. Traducción libre. Extraído de (Kotonya & Sommerville, 1998) ......................... 16 Figura 4. Proceso de ingeniería de requerimientos. Extraído de (Sommerville, 2011) ................................................................................................................ 18 Figura 5. Vista en espiral del proceso de ingeniería de requerimientos. Extraído de (Sommerville, 2011) .................................................................................... 20 Figura 6. Proceso de elicitación de requerimientos. Traducción libre. Extraído de (Christel y Kang, 1992). .............................................................................. 26 Figura 7. El proceso de adquisición y análisis de requerimientos. Extraído de (Sommerville, 2011) ......................................................................................... 29 Figura 8. Fuentes de posibles requerimientos (Robertson y Robertson 1999). Extraído de (Pfleeger, 2002) ............................................................................ 30 Figura 9. ISO/IEC 26702. Análisis de requerimientos. Traducción libre. Extraído de (ISO/IEC 26702 IEEE, 2007) ........................................................ 41 Figura 10. Estándar IEEE Std 1233 (1998). Proceso de desarrollo de la SyRS. Extraído de (IEEE Std. 1233, 1998) ................................................................. 44 Figura 11. CMMI-DEV V1.3. Relación entre Áreas de Proceso de Ingeniería. Traducción libre. Extraído de (Carnegie Mellon University, 2010) .................... 51 Figura 12. ISO/IEC TR 15504. Estructura de procesos. Traducción libre. Extraído de (SPICE, 2008) ............................................................................... 55 Figura 13. ISO/IEC 15504-5. Categorías de procesos y grupos de procesos. Extraído de (ISO/IEC 15504-5, 2006) .............................................................. 57 Figura 14. RUP. Flujos de trabajo y fases. Extraído de (Rational Software Corporation, 2002) ........................................................................................... 61 Figura 15. RUP. Disciplina de los requerimientos. Traducción libre. Extraído de (Rational Software Corporation, 2002) ........................................................ 65 Figura 16. El modelo de marco lógico. Extraído de (Camacho et. al, 2001. Basado en Gómez y Sainz, 1999) .................................................................... 70 Figura 17. Marco Lógico. Estructura Metodológica del Marco Lógico. Extraído de (Ortegón, Pacheco y Prieto, 2005) .............................................................. 72 Figura 18. Marco Lógico. Identificación de los involucrados. Modelo basado en (Ortegón et. al., 2005. Área de proyectos y programación de inversiones. ILPES) .............................................................................................................. 74 Figura 19. Marco Lógico. Árbol de efectos. Extraído de (Sánchez, 2007. ILPES. Área de proyectos y programación de inversiones) ............................. 77 Figura 20. Marco Lógico. Árbol de causas. Extraído de (Sánchez, 2007. ILPES. Área de proyectos y programación de inversiones) ......................................... 78
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
iv
Figura 21. Marco Lógico. Árbol del problema. Integrado del árbol de efectos y del árbol de causas. Extraído de (Sánchez, 2007. ILPES. Área de proyectos y programación de inversiones) .......................................................................... 78 Figura 22. Marco Lógico. Árbol de objetivos. Basado en el árbol de problemas. Extraído de (Sánchez, 2007. ILPES. Área de proyectos y programación de inversiones) ...................................................................................................... 79 Figura 23. Marco Lógico. Árbol de Acciones. Basado en ejemplo del árbol de acciones de (Sánchez, 2007. ILPES. Área de proyectos y programación de inversiones) ...................................................................................................... 80 Figura 24. Marco Lógico. Coherencia causa, medio y acción. Extraído de (Sánchez (2007) y Ortegón et. al, 2005. ILPES. Área de proyectos y programación de inversiones) .......................................................................... 81 Figura 25. Marco Lógico. Estructura analítica del proyecto. Extraído de (Ortegón et. al., 2005. ILPES. Área de proyectos y programación de inversiones) ...................................................................................................... 85 Figura 26. Marco Lógico. La estructura analítica del proyecto y la columna de objetivos de la matriz de marco lógico. Basado en el ejemplo de (Ortegón et. al., 2005. Área de proyectos y programación de inversiones. ILPES) ............ 86 Figura 27. Proyectos fallidos, problemáticos y exitosos. Extraído de (Standish Group, CHAOS Report, 2009) .......................................................................... 93 Figura 28. Metodología para la elicitación de requerimientos de software basada en el marco lógico: Estructura de la metodología. ............................. 113
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
v
Índice de Tablas
Pág.
Tabla 1. CMMI-DEV V1.3. Áreas de proceso, categorías y niveles de madurez. Traducción libre. Extraído de (Software Engineering Institute, Carnegie Mellon University, 2010) .............................................................................................. 49 Tabla 2. Marco Lógico. Análisis de participación de grupos de involucrados según posición frente al proyecto. Extraído de (Camacho et. al., 2001). ......... 74 Tabla 3. Marco Lógico. Fase 1. Análisis de participación de los implicados según sus intereses. Extraído de (Camacho et. al., 2001). .............................. 75 Tabla 4. Marco Lógico. Fase 2. Análisis de participación de los implicados según sus intereses. Extraído de (Camacho et. al., 2001). .............................. 75 Tabla 5. Marco Lógico. Análisis de participación de grupos de involucrados según expectativa y fuerza con respecto al proyecto. Extraído de (Ortegón et. al., 2005) ......................................................................................................... 75 Tabla 6. Marco Lógico. Grupo de Involucrados y posición frente al proyecto. Extraído de (Montalván. BID) ........................................................................... 76 Tabla 7. Marco Lógico. Análisis cualitativo de alternativas. Extraído de (Camacho et. al., 2001). ................................................................................... 83 Tabla 8. Marco Lógico. Análisis cuantitativo de alternativas. Extraído de (Camacho et. al., 2001). ................................................................................... 83 Tabla 9. Marco lógico. Estructura de la matriz de marco lógico. Extraído de (Ortegón et. al., 2005. Área de proyectos y programación de inversiones. ILPES) .............................................................................................................. 85 Tabla 10. Marco. Lógico. Análisis lógico de los niveles jerárquicos de la columna de resumen narrativo. Extraído de (Ortegón et. al., 2005. Área de proyectos y programación de inversiones. ILPES) ........................................... 86 Tabla 11. Marco Lógico. Revisión de criterios para los indicadores. Extraído de (Ortegón et. al., 2005. Área de proyectos y programación de inversiones. ILPES) .............................................................................................................. 87 Tabla 12. Marco Lógico. Relación entre supuestos y objetivos. Extraído de (Ortegón et. al., 2005. Área de proyectos y programación de inversiones. ILPES) .............................................................................................................. 88 Tabla 13. Porcentajes fracasos de proyectos de software. Extraído de (Standish Group, CHAOS Report, 2004) .......................................................................... 92 Tabla 14. Costos relativos para corregir un error. Extraído de (Whitten y Bentley, 2008). ................................................................................................. 96 Tabla 15. Síntesis de estándares y modelos de ingeniería de requerimientos vs. Metodología de Marco Lógico. ....................................................................... 107 Tabla 16. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Conceptos de la metodología. ......................................... 111 Tabla 17. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Actividades de la metodología ......................................... 112 Tabla 18. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Productos vs. Actividades de la metodología. ................ 124 Tabla 19. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Técnicas vs. Actividades de la metodología. .................. 125
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
vi
Tabla 20. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Herramientas vs. Actividades de la metodología. ........... 134 Tabla 21. Tabla. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PVDP. Vocabulario del dominio del proyecto ......................................................................................................... 135 Tabla 22. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PFDP. Funciones del dominio del proyecto ...... 135 Tabla 23. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PII. Identificación de involucrados en el proyecto ................................................................................................. 136 Tabla 24. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PAIC. Agrupación de Involucrados por características comunes ................................................................................. 136 Tabla 25. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PPGIP. Posición grupos de involucrados con respecto al proyecto ....................................................................................... 137 Tabla 26. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PEFGIP. Expectativa y fuerza del grupo de involucrados en el proyecto ............................................................................ 137 Tabla 27. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PCGIP. Clasificación grupos de involucrados con respecto al proyecto ....................................................................................... 138 Tabla 28. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PAIGIP. Análisis incorporación grupos involucrados al proyecto ................................................................................. 138 Tabla 29. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PLP. Listado de Problemas .............................. 139 Tabla 30. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMP. Matriz de Problemas ............................... 139 Tabla 31. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMP. Matriz de Objetivos ................................. 139 Tabla 32. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMA. Matriz de Acciones. ................................. 140 Tabla 33. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: POS. Objetivos del Sistema. ............................. 140 Tabla 34. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRFS. Requerimientos Funcionales del sistema ....................................................................................................................... 141 Tabla 35. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRNFS. Requerimientos no funcionales del sistema ........................................................................................................... 142 Tabla 36. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMEAP. Matriz Estructura Analítica del proyecto ....................................................................................................................... 143 Tabla 37. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMAEP. Matriz Administración Estructura del proyecto ......................................................................................................... 145
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
vii
Tabla 38. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRMAEP. Revisión Matriz de Administración de la estructura del proyecto. .................................................................................. 146 Tabla 39. Metodología para la elicitación de requerimientos de software basada en el marco lógico: Matriz de Roles y responsabilidades en la metodología. 152 Tabla 40. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PVDP. Vocabulario del dominio del proyecto ...................................................................................... 154 Tabla 41. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PFDP. Funciones del dominio del proyecto .................................................................................................... 155 Tabla 42. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PIIP. Identificación de involucrados en el proyecto ............................................................................ 157 Tabla 43. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PAICP. Agrupación de Involucrados por características comunes en el proyecto .............................. 157 Tabla 44. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PPGIP. Posición grupos de involucrados con respecto al proyecto ........................................................... 159 Tabla 45. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PEFGIP. Expectativa y fuerza del grupo de involucrados en el proyecto ............................................................. 159 Tabla 46. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PCGIP. Clasificación grupos de involucrados con respecto al proyecto ........................................................... 160 Tabla 47. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PAIGIP. Análisis incorporación grupos involucrados al proyecto ..................................................................... 161 Tabla 48. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PLP. Listado de Problemas. .. 162 Tabla 49. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMP. Matriz de Problemas. ... 166 Tabla 50. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMO. Matriz de Objetivos. 168 Tabla 51. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMA. Matriz de Acciones. . 169 Tabla 52. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: POS. Objetivos del sistema ....................................................................................................................... 171 Tabla 53. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRS. Requerimientos del sistema ........................................................................................................... 174 Tabla 54. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRNFS. Requerimientos no funcionales del sistema .................................................................................. 175 Tabla 55. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMEAP. Matriz Estructura Analítica del proyecto. .................................................................................... 180
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
viii
Tabla 56. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMAEP. Matriz Administración Estructura del proyecto .......................................................... 186 Tabla 57. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRMAEP. Revisión Matriz de Administración de la estructura del proyecto. ................................................. 187 Tabla 58. Evaluación de la Metodología para la elicitación de requerimientos de software basada en el marco lógico .......................................................... 193
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
ix
Índice de Esquemas
Pág. Esquema 1. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EIIP. Identificación de Involucrados en el proyecto ......................................................................................................... 147 Esquema 2. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAE. Árbol de efectos ....................... 148 Esquema 3. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAC. Árbol de causas........................ 148 Esquema 4. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAP. Árbol de problemas. ................. 149 Esquema 5. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAO. Árbol de Objetivos .................... 150 Esquema 6. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAA. Árbol de Acciones..................... 150 Esquema 7. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EEAP. Estructura analítica del proyecto ....................................................................................................................... 151 Esquema 8. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EIIP. Identificación de Involucrados en el proyecto ................................................. 156 Esquema 9. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAEP. Árbol de efectos del problema ................................................................................. 163 Esquema 10. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EACP. Árbol de causas del problema. ................................................................................ 164 Esquema 11. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAP. Árbol de problemas. ................................................................................................. 165 Esquema 12. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAO. Árbol de Objetivos. .................................................................................................. 167 Esquema 13. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAA. Árbol de Acciones. ................................................................................................... 169 Esquema 14. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EEAP. Estructura analítica del proyecto. ................................................................... 176
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
x
Nomenclatura
AFDB
BID
CIDA
CMM
CMMI
DES
DRS
DRU
ERS
GTZ
IEEE
ILPES
ISO
MML
MOPROSOFT
NORAD
PAHO
PI
RD
RUP
SPICE
PSP
SEI
Banco Africano de Desarrollo
Banco Interamericano de Desarrollo
Agencia Canadiense de Desarrollo Internacional
Capability Maturity Model . Modelo de madurez de capacidad
Capability Maturity Model Integration. Modelo de madurez de
capacidad integrado.
Documento de Especificación de Software.
Documento de Requisitos de Software.
Documento de Requisitos del Usuario.
Documento de especificación de requerimientos de software
Corporación Alemana para la Cooperación Técnica
Institute of Electrical and Electronics Engineers. Instituto de
ingenieros Eléctricos y Electrónicos
Instituto Latinoamericano y del Caribe de Planificación
Económica y Social
International Organization for Standardization. Organización
internacional para la normalización.
Matriz de Marco Lógico
Modelo de Procesos para la Industria de Software
desarrollado en México.
Agencia Noruega de Cooperación en el Desarrollo
Comisión de las Comunidades Europeas y la Organización
Panamericana de la Salud
Integración de Productos
Desarrollo de Requerimientos
Rational Unified Process. Proceso Unificado de Rational
Software Process Improvement and Capability Determination.
Proceso de Software de Mejoria y Determinación de
Capacidad
Software Engineering Institute. Instituto de Ingeniería del
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
xi
SWEBOK
TS
TSP
UML
UP
USAID
VER
VAL
Software
Personal Software Process. Proceso de Software Personal
Software Engineering Body of Knowledge
Solución Técnica
Team Software Process. Proceso de Software en Equipo.
Unified Modeling Language. Lenguaje de Modelado Unificado.
Unified Process. Proceso Unificado
Agencia para el Desarrollo Internacional de Estados Unidos
Verificación
Validación
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
xii
Resumen
El proyecto consiste en el diseño de una propuesta metodológica basada en
el marco lógico, que apoye el proceso de elicitación de requerimientos de
software en su obtención y negociación con los interesados.
La propuesta parte en que la ingeniería de requerimientos de software es la
actividad más importante y más problemática, con mayores índices de fallas y
fracasos en el proceso de desarrollo de software. Contempla actividades
humanas para el entendimiento y negociación con el cliente en determinada
problemática a resolver, siendo de gran importancia el empleo de metodologías
que apoye este proceso con los involucrados reduciendo los riesgos de
fracasos.
La metodología de desarrollo del trabajo de investigación inicia con el
estudio y análisis del estado del arte en la ingeniería de requerimientos de
software, los estándares y modelos, en las actividades de elicitación,
verificación y validación. Se realiza el estudio de la metodología del marco
lógico y se analizan los aportes como herramienta enfocada al involucramiento
y participación de grupos de beneficiarios, desarrollo por objetivos,
planificación, verificación y negociación. Se desarrolla la metodología
propuesta para la elicitación de requerimientos de software basada en el marco
lógico y se valida a juicio de expertos.
Abstract
The project consists of a design of a methodological proposal based on the
logical framework that supports the software requirements elicitation process in
its obtaining and negotiation with the interested parties.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
xiii
The proposal parts from the fact that the software requirements engineering
is the most important and problematic activity, with high levels of flaws and
failures in the software development process. It contemplates human activities
for the negotiation and understanding with the client in a determined
problematic to be resolved, being of great importance the application of
methodologies that support this process with the involved reducing the risks of
failures.
The development methodology starts with the analysis and study of the
logical framework in the software requirements engineering, the models,
standards and methodologies in the eliciting, verification and validation. A study
is performed on the logical framework methodology and the input as a tool that
focuses on involvement and participation of groups of beneficiaries, objective
development, planning, verification and negotiation. The proposed
methodology is developed and validated by experts’ judgment.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
1
CAPITULO 1. INTRODUCCIÓN
En este capítulo se presenta la introducción al desarrollo del trabajo de tesis
presentado, incluyen los objetivos general y específicos, el alcance de este
trabajo, fundamentos de este trabajo, se describe la metodología empleada
para el desarrollo del trabajo de tesis y finalmente describe la estructura del
mismo.
1.1. Objetivos
1.1.1. Objetivo general.
El objetivo general de este trabajo de tesis es:
Diseñar una propuesta metodológica basada en el marco lógico, que apoye
el proceso de elicitación de requerimientos de software en su obtención y
negociación con los interesados.
1.1.2. Objetivos específicos. Como objetivos específicos se citan los siguientes:
- Identificar y analizar conceptos básicos de los requerimientos de
software, la ingeniería de requerimientos, la elicitación de requerimientos
y los enfoques de algunos modelos en el proceso de elicitación de
requerimientos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
2
- Analizar la metodología de marco lógico, fases, monitoreo y evaluación,
y su relación con el ciclo de vida de proyectos informáticos.
- Realizar un análisis en la elicitación de requerimientos de software en el
contexto de sistemas de información y el apoyo que aporta la
metodología de marco lógico.
- Diseñar una propuesta metodológica que apoye el proceso de elicitación
y administración de requerimientos en software basado en el marco
lógico.
- Evaluar la metodología propuesta para la elicitación y administración de
requerimientos en software basado en el marco lógico, mediante la
técnica de juicio de expertos.
1.2. Alcance
Como alcances de este trabajo de tesis tenemos:
La identificación y el análisis de los conceptos básicos de los requerimientos
de software, la ingeniería de requerimientos y la elicitación de los
requerimientos de software, y el enfoque de algunos estándares y modelos en
el proceso de la elicitación de requerimientos, esto como base de la
comprensión conceptual y de procesos, e identificación de problemas
existentes en la elicitación de los requerimientos en proyectos de desarrollo del
software.
Igualmente se estudia la metodología de marco lógico, para que con base
en este estudio se analice los aportes al proceso de la elicitación de
requerimientos de software. Y también como base guía para el diseño de la
metodología propuesta en este trabajo de tesis.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
3
Finalmente se realiza el diseño de una propuesta metodológica para la
elicitación de requerimientos de software.
1.3. Fundamentos del trabajo
Actualmente existen estándares y modelos de procesos de ingeniería de
sistemas y de software como en los que se puede citar SWEBOK, ISO/IEC
26702, IEEE std. 1233, CMM, CMMI, ISO 9001-20000, ISO/IEC 15504 y
Moprosoft, UP, RUP, PSP y TSP, que contiene actividades de la Ingeniería de
Requerimientos en sus primeras etapas en el desarrollo de software, siendo
una de las actividades más delicadas e importantes la elicitación de
requerimientos, y en las que más dificultades y fallas se presentan, ya que se
enfoca en adquirir todo el conocimiento relevante necesario para poder
producir un modelo del dominio del problema, para esto se vale de técnicas de
educción y modelos de representación como el Modelo Orientado a Objetos y
UML, siendo de gran importancia organizarlas en una metodología o marco
para su correcto entendimiento, verificación y validación.
El marco lógico es una metodología que se está empleando en grandes
proyectos y ha dado excelentes resultados en gestión, siendo una herramienta
para facilitar el proceso de conceptualización, diseño, ejecución y evaluación
de proyectos, centrado en la orientación por objetivos, la orientación hacia
grupos beneficiarios y el facilitar la participación y la comunicación entre las
partes interesadas.
El Marco Lógico, según el BID, ha sido extremadamente valioso para el
diseño, ejecución, monitoria y evaluación de proyectos, y según estudios el
ingeniero Cid, (2006) la metodología del marco lógico ha sido utilizada para la
planeación de proyectos en varios organismos internacionales, entre los que se
incluye la Agencia para el Desarrollo Internacional de Estados Unidos (USAID),
la Agencia Canadiense de Desarrollo Internacional (CIDA), la Corporación
Alemana para la Cooperación Técnica (GTZ), la Agencia Noruega de
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
4
Cooperación en el Desarrollo (NORAD), el Banco Africano de Desarrollo
(AFDB), la Comisión de las Comunidades Europeas y la Organización
Panamericana de la Salud (PAHO). Este método también es empleado en
instituciones privadas y ONG que pretenden tener un mayor control de la
gestión del conocimiento a través del uso de sistemas de administración de
proyectos por resultados.
Por tal razón se propone una metodología que basada en el marco lógico
apoye al proceso de elicitación y administración de requerimientos de
desarrollo de software, como mecanismo de un mejor entendimiento y
negociación con los involucrados y del problema a resolver, siendo ésta la
actividad más problemática y con mayores índices de fallas y fracasos en el
proceso de desarrollo de software.
“La parte más difícil de construir un sistema de software es decidir
precisamente qué construir. Ninguna otra parte del trabajo conceptual es tan
difícil como establecer los requerimientos detallados del sistema.” Fred Brooks
1.4. Metodología empleada
Como proceso de consolidación y desarrollo del proyecto planteado se sigue
los siguientes pasos lógicos como parte de la metodología:
Primero la construcción del marco teórico que se realiza en cinco etapas:
La primera etapa se basa en el estudio y análisis de los requerimientos de
software, enfatizando en definiciones, clasificación, niveles de descripción y
características.
La segunda etapa se basa en el estudio de la ingeniería de requerimientos,
describiendo estructura, procesos y la documentación, según diferentes
autores en el área.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
5
La tercera etapa se basa en el estudio de la elicitación de requerimientos,
según diferentes autores en cuanto al proceso de elicitaciòn, fuentes de los
requerimientos, técnicas de elicitación y los participantes en el proceso.
La cuarta etapa se basa en el enfoque de algunos modelos en la elicitación
de requerimientos de software, con el fin de analizar cómo realizan este
proceso.
La quinta etapa se basa en el estudio y análisis de la metodología de marco
lógico.
La revisión bibliográfica incluye libros, artículos de publicaciones
especializadas y de trabajos presentados en congresos e investigaciones
llevadas a cabo o auspiciadas por organismos técnicos internacionales, con
los últimos desarrollos relacionados en el tema, además de sitios web de
organizaciones e institutos de investigación vinculados con la temática.
Con base en el estudio de lo recopilado en el marco teórico, se consolida el
informe final del estado del arte del proyecto.
Luego se realiza el análisis de la elicitación de requerimientos de software en
el contexto de sistemas de información y se analiza el apoyo que brinda a ésta
la metodología de marco lógico y su producto.
Con el estudio teórico de marco lógico y de las actividades de la elicitación
de requerimientos de software, se elabora la metodología incluyendo las
tareas, herramientas, y técnicas respectivas.
Luego de elaborada la propuesta metodológica, se diseña la aplicación de la
técnica “juicio de expertos” para evaluar la metodología propuesta y se realiza
la selección y contacto del grupo de especialistas en el área de ingeniería del
software, que serán integrantes del grupo.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
6
Ya con el diseño de la evaluación de la metodología y conformado el grupo
de expertos, se aplica la evaluación al grupo, se realiza el análisis de la
evaluación aplicada del juicio de expertos, y luego se realiza, de ser
necesarias, las modificaciones válidas pertinentes a la metodología propuesta
en este proyecto.
Una vez culminado lo anterior, se consolida y realiza el informe final del
proyecto de tesis.
1.5. Estructura del trabajo
El trabajo se estructura en ocho capítulos:
Capítulo 1. Introducción. Contiene los objetivos general y específicos del
trabajo de tesis, el alcance, los fundamentos del trabajo, la metodología
empleada, especificación y la estructura del trabajo.
Capítulo 2. Estado del arte. Describe en forma general los requerimientos
de software, la ingeniería de requerimientos, principales procesos de la
ingeniería de requerimientos y se enfoca en la elicitación de requerimientos,
luego se estudia los enfoques de los principales estándares y modelos en el
desarrollo de la ingeniería y de procesos de software (ISO/IEC 26702, IEEE
std. 1233, CMMI, ISO/IEC 15504 y RUP) enfocándose en el área de elicitación
o descubrimiento de los requerimientos y sus actividades. También se
describe la metodología del marco lógico y un resumen del capítulo.
Capítulo 3. Problema. Contiene una introducción, una descripción del
problema indicando las dificultades en la elicitación de requerimientos y los
problemas causados por requerimientos, y finalmente se formulan las
preguntas de investigación del proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
7
Capítulo 4. Solución. Contiene el análisis de la elicitación de requerimientos
de software y el aporte de la metodología de marco lógico. Se presenta una
síntesis de los modelos y estándares de ingeniería de requerimientos de
software Vs. Modelo de Marco Lógico. De igual forma contiene la propuesta a
realizar y la solución basada en la propuesta que consiste en la metodología
para la elicitación de requerimientos de software basada en el marco lógico.
Describe el desarrollo de la propuesta incluyendo los elementos de conceptos
de la metodología, objetivos, actividades, productos, técnicas, herramientas y
roles y responsabilidades.
Capítulo 5. Caso de estudio. Contiene un ejemplo de aplicación de la
metodología propuesta.
Capítulo 6. Validación de la propuesta. Describe el modelo de validación de
la propuesta, los expertos seleccionados para realizar la evaluación a juicio de
experto y el resultado de la evaluación de los expertos.
Capítulo 7. Conclusiones y aportaciones de esta tesis. Contiene las
conclusiones en cuanto a la valoración sobre la investigación documental,
valoración del problema, valoración de la solución, valoración del caso de
estudio, respuesta de los interrogantes de investigación. Y finalmente contiene
las futuras líneas de investigación.
Capítulo 8. Referencias Bibliografía. Contiene las referencias bibliográficas
utilizadas en el presente trabajo.
Anexos. Contiene los anexos como apoyo al desarrollo del proyecto, como
son el cuestionario utilizado a juicio de expertos y las respuestas de los
expertos como resultado de la evaluación de la metodología.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
8
CAPITULO 2. ESTADO DEL ARTE
2.1. Requerimientos de software
2.1.1. Definición de requerimiento.
Según la definición de la Real Academia Española, podemos encontrar los
siguientes términos relacionados con los requerimientos:
Requerimiento.
1. m. Acción y efecto de requerir. 2. m. Der. Acto judicial por el que se intima que se haga o se deje de ejecutar
algo.
3. m. Der. Aviso, manifestación o pregunta que se hace, generalmente bajo fe
notarial, a alguien exigiendo o interesando de él que exprese y declare su
actitud o su respuesta.
Requerir.
(Del lat. requirĕre).
1. tr. Intimar, avisar o hacer saber algo con autoridad pública.
2. tr. Reconocer o examinar el estado en que se halla algo. 3. tr. necesitar. 4. tr. Dicho de una persona: Solicitar, pretender, explicar su deseo o pasión
amorosa.
5. tr. inducir (‖ instigar).
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
9
Requisito.
(Del lat. requīsitus).
1. m. Circunstancia o condición necesaria para algo.
Según la definición Instituto de Ingeniería Electrónica y Eléctrica (IEEE
610.12-1990):
Requerimiento es:
(1) Una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
(2) Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar, especificación u
otro documento formal.
(3) Una representación documentada de una condición o capacidad
documentada como las descritas en (1) y (2).
2.1.2. Características de los requerimientos.
Según Wiegers (2003) las características de los requerimientos se basan
según sus propiedades principales en estado de madurez, y cita las siguientes
características:
• Completo. Debe describir de forma completa la funcionalidad que debe
cumplir.
• Correcto. Debe describir de manera precisa la funcionalidad que se debe
construir. No debe de estar en conflicto con otro requerimiento.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
10
• Realizable. Ser posible de implementar de acuerdo a las capacidades y
limitaciones del sistema y el medio que lo rodea. Debe estar relacionado
con las limitaciones técnicas y de costos.
• Necesario. Debe documentar lo que los clientes realmente necesiten, de
conformidad a un sistema externo o para satisfacer un estándar.
• Priorizable. Debe indicar que tan esencial es el mismo para la realización
del producto
• No ambiguo. Debe tener consistencia en la interpretación del mismo.
Debe redactarse en un lenguaje que no cause confusiones.
• Verificable. Debe ser cuantificado de manera que se permita hacer uso
de los métodos de verificación como son: inspección, análisis,
demostración o pruebas.
2.1.3. Niveles de descripción de los requerimientos.
Wiegers (2003) indica que los niveles de descripción de requerimientos
permiten hacer una separación entre los diferentes tipos de requerimientos que
se pueden concebir, entre los cuales se encuentran:
• Descripción a nivel de negocio. Se llaman requerimientos del negocio a
aquellos requerimientos que representan objetivos de alto nivel para la
organización o el cliente que requiere el producto. Se caracterizan por ser
descritos de manera generalizada en términos de beneficios o
necesidades de la organización, en ocasiones son llamados objetivos del
software.
• Descripción a nivel de usuario. Los requerimientos que describen tareas
que los usuarios deben estar en capacidad de cumplir con el producto de
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
11
software que se está describiendo, son conocidos como requerimientos
del usuario.
Descripción de las tareas que el sistema debe ejecutar cuando el usuario
opera en él. Describen la funcionalidad necesaria para satisfacer tareas
específicas, necesidades operacionales y grupos de usuarios. INTECO (2008)
Sommerville (2011) indica que estos requerimientos son descritos con frases
usando lenguaje natural, que es expresivo, intuitivo y universal.
• Descripción a nivel del sistema. Hacen referencia a la funcionalidad que
debe ser construida para que el producto pueda realizar las tareas, en
términos de las necesidades del sistema. Estos requerimientos se
enfocan a las funciones del sistema, los servicios y las restricciones de la
operabilidad en detalle. Sirven como base para realizar la arquitectura,
diseño y planes de pruebas del sistema. INTECO (2008).
2.1.4. Clasificación de los requerimientos.
Para la clasificación de los requerimientos hay que ver que provengan de los
requerimientos a nivel del negocio y a nivel del usuario, y se pueden clasificar
de la siguiente forma según Sommerville (2011).
• Requerimientos funcionales. Se relaciona con los servicios que el
sistema debe proveer, como el sistema debe reaccionar a entradas
particulares y como el sistema debe comportarse bajo situaciones
particulares. En algunos casos los requerimientos funcionales deben
describir de manera explícita, lo que el sistema no debe hacer.
• Requerimientos no funcionales. Son limitaciones sobre los servicios y
funcionalidades ofrecidos por el sistema. Estos incluyen restricciones en
el tiempo que se debe demorar un proceso, restricciones sobre el
proceso de desarrollo y estándares. Los requerimientos no funcionales
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
12
aplican usualmente sobre el sistema como un todo. Estos normalmente
no aplican a características o servicios particulares del sistema.
Clasifica los requerimientos no funcionales según su implicancia en:
- Requerimientos del producto. Especifican o restringen el
comportamiento de un software. Entre estos encontramos:
requerimientos de rendimiento, requerimientos de fiabilidad,
requerimientos de seguridad, y requerimientos de usabilidad.
- Requerimientos de la organización. Se derivan de las políticas y
procedimientos existentes en la organización del cliente y el
desarrollador. Entre estos se incluyen los requerimientos de proceso
operacional, requerimientos de proceso de desarrollo, estándares del
entorno o del proceso a utilizar y requerimientos ambientales.
- Requerimientos externos. Incluye los requerimientos que se derivan de
los factores externos del sistema y del proceso de desarrollo. Se
incluyen requerimientos regulatorios, requerimientos legislativos,
requerimientos éticos.
2.2. Ingeniería de requerimientos
Boehm (1981) define la Ingeniería de Requerimientos como la disciplina para
desarrollar una especificación completa, consistente y no ambigua, la cual
servirá como base para acuerdos comunes entre todas las partes involucradas
y en dónde se describen las funciones que realizará el sistema.
La ingeniería de requerimientos recolecta, organiza y documenta los
requerimientos del sistema; establece y mantiene acuerdos sobre los cambios
de requerimientos, entre los clientes y el equipo del proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
13
2.2.1. Estructura de la Ingeniería de requerimientos.
Figura 1. Estructura de la ingeniería de requerimientos. Traducción libre. Extraído de
(Wiegers, 2003)
Wiegers (2003) basado en Abran and Moore (2001), describe que la
estructura de la ingeniería de requerimientos se compone de desarrollo y
administración. En la que el desarrollo de requerimientos se compone de las
actividades de la elicitación, análisis, especificación y validación. Thayer (2000)
define sus componentes en:
• Elicitación: Los clientes y el desarrollador de un sistema de software;
descubren, revisan, articulan, y entienden las necesidades de los
usuarios del sistema y las restricciones pertinentes sobre el software y su
desarrollo.
• Análisis: Se analizan las necesidades de los clientes y los usuarios, como
producto se tiene la definición de los requerimientos de software.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
14
• Especificación: Se elabora el documento que especifica los
requerimientos del sistema.
• Validación: Se asegura que la especificación de requerimientos de
software este acorde con los requerimientos del sistema, con los
estándares de documentación.
Administración: Incluye el conjunto de actividades que ayudan al equipo a
identificar, controlar y dar seguimiento a los requerimientos y a sus cambios en
cualquier momento de desarrollo del proyecto.
2.2.2. Proceso de ingeniería de requerimientos.
Para el proceso de ingeniería de requerimientos podemos citar algunos
autores y sus propuestas como son:
Loucopoulos & Karakostas (1995) describe los procesos de la ingeniería de
requerimientos abarca tres aspectos fundamentales, como se muestra en la
siguiente figura 2:
• Entendimiento del problema (Educción)
• Descripción del problema (Especificación)
• Acuerdo sobre la naturaleza del problema (Validación)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
15
Figura 2. Proceso de ingeniería de requerimientos. Traducción libre. Extraído de (Loucopoulos & Karakostas, 1995)
Kotonya & Sommerville (1998) explican que el proceso de ingeniería de
requerimientos se puede ver como un ciclo repetitivo en espiral, en el que
abarcan las cuatro etapas o pasos del desarrollo de la ingeniería de
requerimientos: Educción (captura, descubrimiento, adquisición), análisis (y
negociación), especificación, y validación de requerimientos. Además citan la
elaboración de diferentes instancias del documento de requerimientos como es:
requerimientos informales, acuerdo acerca de los requerimientos, borrador del
documento de requerimientos y finalmente el documento de requerimientos e
informe de validación. Estos se desarrollan y se revisan en cada punto de
decisión dentro del proceso.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
16
Figura 3. Modelo espiral del proceso de ingeniería de requerimientos. Traducción libre. Extraído de (Kotonya & Sommerville, 1998)
Por otra parte podemos también citar la descripción que hace Pressman
(2010) con respeto a los pasos de la ingeniera de requerimientos de software
en la que describe que la ingeniería de requerimientos comienza con la
concepción, tarea que define el alcance y la naturaleza del problema que se va
a resolver. Luego se realiza la indagación, labor que ayuda a los participantes a
definir lo que se requiere. Sigue la elaboración, donde se de refinan y modifican
los requerimientos básicos. Una vez los participantes definen el problema y lo
que se requiere para solucionarlo, tienen lugar la negociación, identificando las
prioridades, lo esencial y lo que se requiere. Por último se especifica el
problema y luego se revisa y valida, para garantizar que hay coincidencia entre
la concepción del problema entre el grupo desarrollador y la concepción que
tiene los participantes. Y por último se administran los requerimientos en
cuanto al cambio o modificación de los mismos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
17
• Concepción. La mayor parte de los proyectos comienza cuando se
identifican de necesidades del negocio, descubrimiento de un nuevo
mercado o servicio potencial. Se debe establecer en el entendimiento
básico del problema, las personas que quieren una solución, la
naturaleza de la solución que desea, así como la eficacia de la
comunicación y colaboración preliminares entre los participantes y el
equipo de software.
• Indagación. Consiste en preguntar al cliente, a los usuarios y a otras
personas, cuales son los objetivos para el sistema o producto, que es lo
que va a lograrse, como se ajusta el sistema o producto a las
necesidades del negocio, y finalmente como va a usarse el sistema o
producto en las operaciones cotidianas. Esto no es simple y es difícil.
Pressman (2010) cita que Cristel y Kang identifican cierto número de
problemas que se encuentra cuando ocurre la indagación. Problemas de
alcance, problemas de entendimiento, y problemas de volatilidad.
• Elaboración. La elaboración obtenida del cliente durante la concepción e
indagación se expande y refina. Se centra en el desarrollo de un modelo
refinado de requerimientos que identifique aspectos de la función del
software, su comportamiento e información.
• Negociación. Se puede encontrar que los clientes y usuarios pidan más
de lo que puede lograrse, dado lo limitado de los recursos del negocio, o
que propongan requerimientos conflictivos según sus necesidades
especiales. Estos conflictos deben de negociarse según su prioridad,
para esto los requerimientos pueden modificados, combinados o
eliminados, de modo de obtener cierto grado de satisfacción entre las
partes.
• Especificación. Se puede contemplar como producto la elaboración de un
documento escrito, conjunto de modelos gráficos, un modelo matemático
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
18
formal, un conjunto de escenarios de uso, prototipo o cualquier
combinación éstos. Como ejemplo clásico tenemos la elaboración del
documento de especificación de requerimientos de software (ERS) y que
plantea la IEEE en su estándar IEEE-STD-830-1998.
• Validación. se analiza la especificación de los requerimientos a fin de
garantizar que todos se hayan enunciado sin ambigüedades, que se
detectaron y corrigieron las inconsistencias, las omisiones y los errores, y
que los productos del trabajo se presentan conforme a los estándares
establecidos para el proceso, el proyecto y el producto. Se analizan las
especificaciones en busca de errores de contenido o de interpretación,
aspectos de los cuales se necesite hacer aclaraciones, falta de
información, inconsistencias y requerimientos en conflicto o irreales (no
asequibles).
Sommerville (2011) basado en su modelo propuesto en el 2005, propone un
proceso con cuatro subprocesos para la ingeniería de requerimientos:
Figura 4. Proceso de ingeniería de requerimientos. Extraído de (Sommerville, 2011)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
19
• Estudio de factibilidad. En donde se realiza una estimación sobre las
necesidades identificadas del usuario y las tecnologías de hardware y
software actuales, el costo-beneficio desde el punto de vista
empresarial.
• Obtención y análisis de requerimientos. Se derivan los requerimientos
del sistema mediante la observación de los sistemas existentes,
discusiones con los usuarios y proveedores potenciales, analistas de
tareas y otros.
• Especificación de requerimientos. Se transcribe la información
recopilada de la actividad de análisis, en el documento que define el
conjunto de requerimientos que incluye dos clases de requerimientos,
requerimientos de usuario y requerimientos de sistema.
• Validación de requerimientos. Se verifican que los requerimientos sean
realistas, coherentes y completos. Se descubren errores y se corrigen
dichos problemas.
También Sommerville (2011) presenta una alternativa sobre el proceso de
ingeniería de requerimientos, con cuatro actividades de alto nivel en un proceso
iterativo alrededor de un espiral, que se enfocan en valorar la utilidad del
sistema para la empresa (estudio de factibilidad), descubrimiento de
requerimientos (adquisición y análisis), convertir los requerimientos en forma
estándar (especificación), y la comprobación de que los requerimientos definan
lo que quiere el cliente (validación).
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
20
Figura 5. Vista en espiral del proceso de ingeniería de requerimientos. Extraído de (Sommerville, 2011)
Pfleeger (2002) indica que la validación de requerimientos es el proceso por
el que se determina si la especificación es consistente con la definición de los
requerimientos, la validación asegura que los requerimientos satisfarán las
necesidades del cliente.
La validación incluye dos pasos:
Primero asegurar que cada especificación pueda ser rastreada hasta su
requerimiento en el documento de definición.
Y luego se chequea la definición para ver si cada requerimiento es rastreable
hasta la especificación.
Se lista algunas técnicas que se pueden utilizar para realizar la validación:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
21
Técnicas Manuales:
• Lectura
• Cruce de referencias manual
• Entrevistas
• Revisiones
• Listas de comprobación
• Modelos manuales para chequeo de funciones y relaciones
• Escenarios
• Pruebas matemáticas
Técnicas automatizadas:
• Cruce de referencias automatizado
• Modelos automatizados para poner en ejecución funciones
• Prototipos
En la revisión de documentos se:
• Revisan las metas declaradas y los objetivos del sistema
• Comparan los requerimientos con las metas y objetivos, verificando que
todos los requerimientos son necesarios.
• Describe el ambiente en el cual opera el sistema.
• Evalúa y documenta los riesgos en el desarrollo o funcionamiento del
sistema.
• Dialoga sobre las pruebas del sistema.
2.2.3. Documentación de los requerimientos.
Pfleeger (2002) indica que debido a que el foco de atención esta puesto
sobre el problema del cliente, la extracción y el análisis de requerimientos
sirven a dos propósitos diferentes que están relacionados.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
22
La extracción permite la elaboración del documento de definición de
requerimientos, escrito en términos que el cliente pueda entender, comprendido
por un listado completo de las cosas que el cliente espera que haga el sistema
propuesto.
Por otra parte el documento de especificación de requerimientos reitera la
definición en los términos técnicos para el desarrollo del diseño del sistema.
• El documento de definición de requerimientos.
Describe lo que el cliente desea ver y contiene lo siguiente:
- Propósito general del sistema. Incluyen las referencias a otros sistemas
relacionados, se incorpora un diccionario de términos y abreviaturas que
pueden ser útiles.
- Antecedentes y objetivos del desarrollo del sistema. Explica porque el
sistema existente es insatisfactorio.
- Descripción del enfoque. Se debe tener el foco en el como el sistema va
a satisfacer las necesidades del cliente, indicando las restricciones del
cliente sobre el desarrollo, suposiciones a tener en cuenta, indicando
esto en una lista.
- Características del sistema propuesto. Se define el límite del sistema y
las interfaces que lo vinculan con el entorno. Además se incluye una lista
de los elementos de datos, clases y características. Se detallan las
relacione entre los datos, funciones, entradas, salidas de cada proceso o
función. También se incluyen los requerimientos de rendimiento.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
23
- Ambiente de operación del sistema. Incluyen requerimientos para el
soporte, la seguridad y la privacidad, así como las restricciones de
hardware y software.
• El documento de especificación de requerimientos.
Este documento cubre las mismas características que el documento de
definición de requerimientos. El documento de especificación de requerimientos
se escribe desde la perspectiva del desarrollador.
Hadad, G., Doorn, J., Kaplan, G. (2009) indican que existen varios
estándares internacionales que especifican la estructura de un documento de
especificación de requerimientos como son: IEEE Std 830-1998, IEEE Std.
P1233/D3-1995, DOD 5000.2-R, ESA PSS-05-0, NCC 87, entre otros. La
estructura que sugiere la IEEE es una guía de lo que debe contener este
documento, dando pautas generales de contenido para casa sección y que
continuación se describe.
IEEE-STD-830-1998: Especificaciones de los requisitos del software (SRS)1
Según la IEEE-STD-830-1998 en lo relacionado a la especificación de
requisitos del software, este estándar tiene tres temas como referencia a tratar:
definiciones, consideraciones para producir una buena especificación de
requerimientos y partes de una especificación de requerimientos.
Las partes de un SRS. La IEEE std. 830 propone como ejemplo un modelo
para armar una especificación de requerimientos de software.
Tabla de Contenidos
1. Introducción
1.1 Propósito
1 SRS. Software Requirements Specifications.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
24
1.2 Alcance
1.3 Definiciones, siglas, y abreviaciones
1.4 Referencias
1.5 Apreciación global
2. Descripción global
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Restricciones
2.5 Atención y dependencias
3. Los requisitos específicos
Apéndices
Índice
2.3. Elicitación de requerimientos
La elicitación es el primer paso en el proceso de la ingeniería de
requerimientos en la que se relaciona directamente con el dominio del
problema y el usuario, recabando la información del conocimiento del negocio.
“Elicitación de requerimientos es el proceso de adquirir (“eliciting”, sonsacar)
todo el conocimiento relevante necesario para producir un modelo de los
requerimientos de un dominio de problema”. (Loucopoulos & Karakostas
(1995)).
SWEBOK (2004) define la elicitación de requerimientos como la captura de
los requisitos, y se refiere a la fuente de donde vienen los requisitos se
software y cómo recogerlos, siendo la primera etapa en la construcción de la
comprensión del problema que el software requiere solucionar. Es fundamental
la actividad humana, donde se identifican los stakeholders y las relaciones
entre el equipo de desarrollo y el cliente.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
25
También indica que se conoce como “descubrimiento de los requisitos,” y
“adquisición de los requisitos.” Uno de los aspectos fundamentales de la buena
ingeniería de software es que haya buena comunicación entre los usuarios del
software y los ingenieros. Antes de que comience el desarrollo, los
especialistas de requisitos pueden formar el conducto para esta comunicación.
Deben mediar entre el dominio de los usuarios del software (y otros
stakeholders) y el mundo técnico del ingeniero de software.
Pfleeger (2002) indica que la extracción de requerimientos es una parte
especialmente crítica del proceso, en la que a menudo se debe trabajar con los
usuarios y los clientes, para comprender un problema cuando todavía no se ha
encontrado una solución. Se debe analizar el problema antes de considerar
cualquier solución. Una de las formas de realizar el análisis del problema
consiste en identificar las personas, los procesos y los recursos involucrados, y
luego documentar las relaciones que existen entre ellos. Indica que resulta útil
separar los requerimientos en tres categorías:
• Requerimientos que deben ser absolutamente satisfechos
• Requerimientos que son muy deseables pero no indispensables
• Requerimientos que son posibles, pero que podrían eliminarse.
2.3.1. El proceso de elicitación.
Al igual que en el proceso de ingeniería de requerimientos hay diferencias de
enfoques sobre las actividades del proceso de elicitación. Este proceso tiene
como objetivo identificar información que determine las características
deseadas del sistema de software. Por eso es importante tener información del
acerca del dominio de la aplicación y de los usuarios el sistema de software.
Loucopoulos y Karakostas (1995) plantean que para el proceso de educción
de requerimientos se tiene:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
26
Entradas:
• Expertos del dominio.
• Literatura acerca del dominio.
• Aplicaciones software similares en otros dominios.
• Estándares nacionales e internacionales que condicionan el desarrollo
de software en ese dominio.
• Otras directivas de la organización que albergará el sistema software.
Actividades:
• Identificar todas las fuentes de requisitos.
• Adquirir el conocimiento.
• Decidir sobre la relevancia del conocimiento del problema.
• Entender el significado del conocimiento elicitado y su impacto sobre los
requisitos del software.
Entregables (productos):
• Modelos formales del dominio del problema.
Christel y Kang (1992) describen que el proceso de elicitación comprende
cinco pasos en forma de cascada, y se puede volver a etapas anteriores:
Figura 6. Proceso de elicitación de requerimientos. Traducción libre. Extraído de
(Christel y Kang, 1992).
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
27
• Encontrar hechos: Identificación de las partes interesadas en múltiples
niveles, contexto operacional y el contexto del problema.
• Obtención y clasificación de requisitos. Captura de la información por
medio de vistas multidisciplinarias.
• Evaluación y fundamentación. Responde a las preguntas “cómo” y
“qué”. Justifica la determinación de cada requerimiento.
• Priorización. Determina las funciones críticas y su importancia.
• Integración y validación. Resuelve conflictos, validar que los
requerimientos están de acuerdo con los objetivos inicialmente
establecidos. Obtener autorización / verificación para mover al siguiente
paso del desarrollo.
Para Pfleeger (2002) las actividades de desarrollo en el proceso de
elicitación de requerimientos son:
• Identificar fuentes de conocimiento
• Adquirir y decidir sobre la relevancia de un conocimiento
• Comprender el significado e impacto del conocimiento
Bruegge y Dutoit (2002) indican que la obtención de requerimientos se
enfoca solo en la visión del sistema que tiene el usuario, como la funcionalidad
del sistema, la interacción entre el usuario y el sistema, los errores que el
sistema puede detectar y condiciones ambientales, y que son parte de los
requerimientos.
También indican que la obtención de requerimientos incluye las siguientes
actividades:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
28
• Identificación de actores. Se identifican los diferentes tipos de usuarios
que soportará el sistema futuro.
• Identificación de escenarios. Se desarrollan un conjunto de escenarios
detallados para la funcionalidad que proporcionará el sistema. Estos
escenarios se utilizan para la comunicación entre usurarios y
desarrolladores para profundizar la comprensión del dominio de
aplicación.
• Identificación de casos de uso. Se elaboran casos de uso que
representan por completo al sistema futuro, éstos son derivados de los
escenarios.
• Refinamiento de los casos de uso. Se asegura que la especificación del
sistema esté completa, y cada caso de uso este detallado, así como el
comportamiento del sistema en presencia de errores y condiciones
específicas.
• Identificación de las relaciones entre casos de uso. Se consolida el
modelo de caso de uso sin redundancias, asegurando que la
especificación del sistema sea consistente.
• Identificación de requerimientos no funcionales. Se acuerdan con el
cliente las restricciones en el desempeño del sistema, la
documentación, recursos que se consumen, seguridad y calidad.
Sommerville (2011) denomina el proceso como adquisición y análisis de
requerimientos, en la que los ingenieros del software trabajan con los clientes y
usuarios finales del sistema para desarrollar el dominio de la aplicación.
Describe las siguientes actividades:
• Descubrimiento de requerimientos. Proceso de interacción con los
participantes del sistema para descubrir sus requerimientos. Se
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
29
recopila información sobre el sistema requerido y el existente, así como
de separar los requerimientos de usuario y de sistema.
• Clasificación y organización de requerimientos. Se toma la recopilación
no estructurada de requerimientos, se agrupa requerimientos
relacionados y se organizan en grupos coherentes.
• Priorización y negociación de requerimientos. Los requerimientos
entran en conflicto cuando existen muchos participantes, así que se
priorizan los requerimientos y se encuentran y resuelven conflictos de
requerimientos por medio de la negociación.
• Especificación de requerimientos. Se documentan los requerimientos y
se ingresan en la siguiente ronda del espiral, se pueden producir
documentos de requerimientos formales y no formales.
Figura 7. El proceso de adquisición y análisis de requerimientos. Extraído de (Sommerville, 2011)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
30
2.3.2. Fuentes de los requerimientos.
Pfleeger (2002) describe el modelo de proceso de requerimientos según
Volere (Robertson y Robertson (1999)) en el que indica varias fuentes de
requerimientos.
Figura 8. Fuentes de posibles requerimientos (Robertson y Robertson 1999). Extraído de (Pfleeger, 2002)
SWEBOK (2004) describe como fuentes de requerimientos las siguientes:
• Metas: se refiere a los objetivos totales, de alto nivel del software.
• Conocimiento del dominio: Conocimiento sobre el uso del dominio.
• Stakeholders: Identificar, representar, y manejar “puntos de vista” de
todos los interesados.
• El entorno operacional. Ambiente en el cual el software será ejecutado.
• El entorno de la organización. Estructura, cultura, y política interna de la
organización.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
31
Sommerville (2011) describe que las fuentes de información durante la fase
de descubrimiento de requerimientos incluyen documentación, participantes del
sistema y especificaciones de sistemas similares.
2.3.3. Técnicas de elicitación.
Se pueden encontrar las siguientes técnicas de elicitación de requerimientos
descritas por varios autores y algunas planteadas en la IEEE Std. 1233 (1998)
como son:
• Entrevistas. Whitten et al. (2003) describen las entrevistas como
técnicas de investigación de hechos durante las cuales el analista
recoge la información que le suministran las personas cara a cara. Hay
de dos tipos estructurada y no estructurada.
• Cuestionario. Whitten, Bentley y Barlow (2003) describen los
cuestionarios como documentos específicos que permiten al analista
recoger la información y opiniones que manifiestan las personas
encuestadas. Yourdon, (2000) indica que se pueden enviar
cuestionarios a los usuarios de la organización, a las personas u
organizaciones que interactúan con el sistema, a los administradores
que aprobaron el proyecto, y a otros.
• Observación de tareas. Whitten et al. (2003) la describen como una
técnica de investigación de hechos, durante la cual los analistas
participan activamente o actúan como espectadores de las actividades
que se llevan a cabo por la persona usuaria para conocer el sistema.
SWEBOK (2004) la describe como una adaptación de las técnicas de
observación para captura de los requisitos, aprendiendo de las tareas
del usuario cuando obran con el software. Sommerville (2011) la define
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
32
como la etnografía, técnica de observación que se puede utilizar para
entender los procesos operacionales y ayudar a derivar requerimientos
de apoyo para estos procesos.
• Análisis de tareas. Loucopoulos y Karakostas (1995) indica que en esta
técnica describe la tarea de los usuarios en términos de actividades que
ejecutan y cómo están estructuradas, y el conocimiento requerido para
ejecutar esas actividades.
• Tormenta de ideas. Llamada también lluvia de ideas, Whitten y Bentley
(2008) describen que se alientan a los participantes en la generación
de ideas, tantas como sea posible, sin analizar la validez de las mismas.
• Análisis de objetivo y meta. Loucopoulos y Karakostas (1995). El
enfoque del análisis objetivo-meta ve el dominio del problema como
consistente en objetivos, metas, sub-metas (medios), organizados en
una jerarquía de meta-submeta (fin-medio), y restricciones.
• Técnica Nominal de Grupo. Técnica que se puede utilizar para la
investigación de problemas, soluciones o toma participada de
decisiones. CIMAS (2009) describe que consiste en una reunión de
varias personas en las que se combina la reflexión individual y la
interacción grupal. Los participantes son personas con experiencia o
conocimiento del tema a tratar, interesados porque los afecta directa o
indirectamente la situación o usuarios del programa.
• Entrevista de grupo. Consiste en organizar discusiones en áreas
relevantes. Consistente en tres etapas: Establecer la relación con el
grupo, reglas de interacción y objetivos, provocar discusiones del tema,
y sumar las respuestas del grupo como acuerdo.
• Método Delphi. Se selecciona un grupo de expertos en el tema a tratar,
se les envía un cuestionario para ser contestado, resumiendo y
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
33
sintetizando estos resultados, se les envía nuevamente un segundo
cuestionario con elementos más concretos. Se lleva a cabo el proceso
respuesta-análisis-retroalimentación-respuesta.
• Observación participativa. Recoge información acerca de la cultura por
medio de participación en ritos, celebraciones, políticas y actividades
diarias. El ingeniero de requerimientos participa en algunas tareas para
conocer habilidades y conocimientos necesarios para una efectiva
realización de tareas.
• Prototipos. Whitten et al. (2003) indican que el diseño de prototipos
consiste en elaborar modelos de trabajo representativos y a pequeña
escala de las necesidades del usuario con el fin de descubrir o verificar
dichas necesidades del usuario.
• Focus Group. Reuniones grupales donde existe una discusión abierta de
los participantes en presencia del ingeniero de requerimientos, asi
provee conocimiento de lo que piensan y sienten los participantes sobre
los aspectos del sistema.
• Joint/Rapid Application Design (JAD/RAD). Es un método de trabajo
grupal por parte de los interesados en el sistema, en una sesión dirigida
por un facilitador para especificar y realizar un desarrollo preliminar de
un sistema. Participan el líder de la sesión, usuarios representativos,
especialistas, analistas, representante de desarrollo y directivos.
• Planeación conjunta de requerimientos (JRP). Whitten y Bentley (2008)
lo describen como el proceso mediante el cual se conducen reuniones
de grupo altamente estructuradas con el propósito de analizar problemas
y definir requerimientos.
• Escenarios/Casos de Uso. Loucopoulos y Karakostas (1995) describen
los escenarios como la historia que ilustra cómo un sistema puede
satisfacer necesidades del usuario, descripción idealizada pero detallada
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
34
de una instancia específica de interacción hombre-máquina. Utiliza
medios diversos (texto, dibujos, diagramas), estructurados en diálogos o
narrativas, similitud con los prototipos. SWEBOK (2004) indica que los
escenarios proporcionan un marco para preguntas sobre tareas del
usuario. El tipo más común de escenario es el caso del uso.
Sommerville (2005) indica que el caso de uso es la característica
fundamental de UML modelos de sistemas orientado a objetos. El caso
de uso identifica el tipo de interacción y los actores involucrados.
• Revisión de la documentación técnica. Whitten et al. (2003) indican que
se deben de analizar la documentación, los formularios y archivos
existentes, para tener una comprensión del sistema. Loucopoulos y
Karakostas (1995) indican que se analiza las fuentes de colección
estructuradas de variables que está formateada para soportar ingreso de
datos y su recuperación.
• Ingeniería inversa. Whitten y Bentley (2008) describen la ingeniería
inversa como el uso de tecnología que lee el código de programas a
partir de bases de datos, programas de aplicación o interfaces de
usuarios existentes y genera automáticamente el modelo de sistemas
equivalente.
• Investigación y visitas a instalaciones. Whitten et al. (2003) indican que
se lleva una determinada investigación de la aplicación y el problema en
publicaciones informáticas y revistas para aprender el modo en que
actuaron otros para resolver problemas similares. De igual forma se
puede visitar otras empresas o departamentos que hayan vivido
problemas similares.
• Reuso de requerimientos. Loucopoulos y Karakostas (1995). Los
requerimientos capturados para alguna aplicación pueden usarse en otra
similar.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
35
2.3.4. Participantes en la elicitación de requerimientos.
Pressman (2010) define participante como cualquier persona que tenga
interés directo o que se beneficie del sistema que se va a desarrollar.
También Pressman (2010), indica que los candidatos habituales pueden ser:
los gerentes de operaciones del negocio, gerentes de producto, personal de
mercadotecnia, clientes internos y externos, usuarios finales consultores,
ingenieros de producto, ingenieros de software e ingenieros de apoyo y
mantenimiento, entre otros. Cada participante tiene punto de vistas diferentes
frente al sistema, obtiene distintos beneficios cuando el proyecto se desarrolla
con éxito y por ende corre distintos riesgos si fracasa el mismo.
Durante la concepción, debe hacerse la lista de personas que harán aportes
cuando se recaben los requerimientos y esta lista crecerá cuando se haga
contacto con los participantes.
Debido a que existen muchos participantes distintos, los requerimientos del
sistema se explorarán desde puntos de vista diferentes. Cada uno de estos
integrantes aportará información al proceso de ingeniería de requerimientos,
teniendo en cuenta que puede ser inconsistente o que estén en conflicto con
uno o con otro, la cual debe de clasificarse en forma que se permita escoger un
conjunto de requerimientos que tenga coherencia interna.
Whitten y Bentley (2008) indican que los involucrados en los sistemas de
información pueden ser clasificados ampliamente en cinco grupos:
• Propietarios del sistema
• Usuarios del sistema
• Diseñadores del sistema
• Constructores del sistema
• Analistas de sistemas y administradores de proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
36
• Propietarios del sistema. Pagan para que el sistema sea construido y
operado, establecen la visión y las propiedades del sistema. Ven el sistema
de información en términos de costos y beneficios para resolver problemas
y explotar oportunidades.
Whitten et al. (2003), indican que patrocinan y promueven los sistemas de
información, responsables de fijar el presupuesto y plazos para desarrollar y
mantener el sistema de información, y deciden en último término la validez de
dicho sistema de información.
• Los usuarios del sistema. Definen los requerimientos de negocios y las
expectativas del sistema. Ven el sistema de información en términos de
funcionalidad, facilidad de aprendizaje y facilidad de uso.
Yourdon, (2000) define al usuario como aquel o aquellos para quien se
construye el sistema.
Whitten et al. (2003) definen al usuario como una persona o grupos de
personas para las que el analista de sistemas construye y mantiene los
sistemas de información de la empresa. Los usuarios de sistemas son aquellas
personas que utilizan en sistema de información de una forma regular:
capturan, validan, introducen y almacenan datos e información.
Existen dos clases de usuarios de sistemas: Usuarios internos del sistema y
Usuarios externos del sistema.
Los usuarios internos del sistema lo constituyen los empleados del negocio
para el cual se desarrolla el sistema de información, podemos citar como
ejemplo: Trabajadores de oficina y servicios, personal técnico y profesional,
supervisores, administradores medios y administradores ejecutivos.
Los usuarios externos del sistema pueden ser otros negocios o
consumidores directos, también son denominados usuarios remotos y usuarios
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
37
móviles, por ejemplo: Clientes, proveedores, socios, empleados que trabajan
en viajes o desde su casa.
Yourdon (2000) clasifica los usuarios en las siguientes categorías:
Usuarios operacionales. Son usuarios con un panorama local, hacen
funcionar el sistema con una visión física del sistema.
Usuarios supervisores. Están familiarizados con la operación, se rigen con
condiciones presupuestales y actúan como intermediarios entre los usuarios y
los niveles superiores de administración.
Usuarios de nivel ejecutivo. Tienen un panorama global del sistema, proveen
la iniciativa del proyecto, no tienen experiencia operacional directa y sus
preocupaciones son a nivel estratégico.
Pressman (2010) hace una diferencia entre los clientes y usuarios finales
como:
Un cliente es la persona o grupo que solicitó originalmente que se
construyera el software, define los objetivos generales del negocio para el
software, proporciona los requerimientos básicos del producto, coordina la
obtención de fondos para el proyecto.
Usuario final es la persona que usará en realidad el software que se elabore,
definirá los detalles de operación del software de modo que se alcance el
propósito del negocio.
• Diseñadores del sistema. Traducen los requerimientos de negocios en una
solución técnica factible. En esta clasificación encontramos los
administradores de bases de datos, arquitectos de redes, artistas gráficos,
expertos en seguridad, expertos en tecnología.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
38
Yourdon (2000) describe como a quien recibe los resultados del análisis de
sistemas y su labor es transformar la petición de requerimientos de usuario
en un diseño arquitectónico de alto nivel, que servirá de base para el trabajo
de los programadores. Whitten et al. (2003) describen que traducen las
necesidades y restricciones de empresa manifestadas por los usuarios a
soluciones técnicas.
• Constructores del sistema. Construyen, implantan y mantienen el sistema
de información. Ven el sistema en términos de hardware y software para
implementar el sistema. Está conformado por programadores de
aplicaciones, programadores de sistemas, programadores de bases de
datos, administradores de red, administrador de seguridad, webmasters e
integradores de software.
Whitten et al. (2003) relacionan a los programadores como constructores de
sistemas, como las personas que fabrican sistemas de información multiusuario
basados en las especificaciones del diseño obtenidas de los diseñadores del
sistema.
• Analista de sistemas y Administrador de proyectos. El Analista de sistemas
es el especialista que estudia los problemas y necesidades de una
organización. Determina la forma en que las personas, los datos, los
procesos y la tecnología pueden lograr óptimamente mejoras para la
empresa. Podemos citar a analista/programador y analista de negocios.
Yourdon (2000) define al analista de sistemas como a la persona clave en
cualquier proyecto de desarrollo de sistemas, desempeñando funciones de
arqueólogo y escribano, innovador, mediador, jefe de proyecto.
El Administrador de proyectos. Planea, monitorea y controla el proyecto, con
respecto a un calendario, presupuesto, entregables, satisfacción del cliente,
normas técnicas y calidad del sistema.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
39
Puede tener apoyo de auditores, personal de control de calidad, y
verificadores de normas. Yourdon, (2000) indica que su objetivo es asegurar
que un sistema se desarrolle de acuerdo con los diversos estándares o normas
externas al proyecto.
Así mismo SWEBOK (2004) cita como ejemplo de agentes del proceso en la
ingeniería de requerimientos a:
• Usuarios
• Clientes
• Analistas de mercado
• Reguladores
• Ingenieros del Software
2.4. Enfoques de algunos estándares y modelos en la elicitación de requerimientos de software
2.4.1. Estándares IEEE para desarrollo de la ingeniería de sistemas.
Entre las normas IEEE podemos estudiar el estándar ISO/IEC 26702 que es
una guía para la aplicación y gestión de los procesos de la ingeniería de
sistemas, y el estándar IEEE std. 1233 que es una guía para el desarrollo de
especificaciones de requerimientos de sistemas.
2.4.1.1. Estándar ISO/IEC 26702. IEEE Std. 1220-2005
El estándar ISO/IEC 26702 (2007) contempla la aplicación y gestión de los
procesos de la ingeniería de sistemas. Describe las tareas de lo que el
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
40
proyecto llevará a cabo, con el fin de establecer lo que el sistema será capaz
de lograr, teniendo en cuenta los requerimientos, limitaciones y restricciones.
2.4.1.1.1. Análisis de requerimientos en ISO/IEC 26702.
La ISO/IEC 26702. (2007), IEEE Std. 1220-2005 contempla 16 procesos
como se describe en la figura 9.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
41
Figura 9. ISO/IEC 26702. Análisis de requerimientos. Traducción libre. Extraído de (ISO/IEC 26702 IEEE, 2007)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
42
De estos procesos de análisis de requerimientos podemos describir los
siguientes que corresponden con el proceso de elicitación de requerimientos de
software.
• Definir las expectativas de las partes interesadas. Se define y cuantifica
las expectativas de los interesados e incluye lo siguiente:
- Lo que el interesado requiere que el sistema lleve a cabo.
- El desempeño de cada función
- Entornos naturales e inducidos en el que el producto puede ser
utilizado.
- Restricciones
• Definir las restricciones del proyecto y de la empresa. La empresa
identifica y define las limitaciones del proyecto y la empresa.
• Definir las restricciones externas. Se identifica las restricciones de
impacto externo como son: leyes, reglamentos, normas, entre otras.
• Definir los escenarios operacionales. Se identifican y definen los
escenarios operaciones en el que el sistema va a desempeñarse, medio
ambiente, otros sistemas, tareas humanas, plataformas, productos, etc.
• Definir los límites del sistema. Se definen los elementos del sistema que
están bajo el diseño del proyecto y que están fuera de él.
• Definir requerimientos funcionales. Se analiza el contexto funcional para
definir lo que el sistema debe ser capaz de realizar (requerimientos
funcionales).
• Definir los requerimientos de rendimiento. Se definen los
requerimientos de rendimiento basados en los requerimientos
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
43
funcionales. Se asignan a las subfunciones en el análisis de la
descomposición funcional.
2.4.1.2. Estándar IEEE Std 1233.
El estándar IEEE Std 1233 (1998), es la guía para el desarrollo de
especificaciones de requerimientos de sistemas de la IEEE, en el que se da la
pauta para el desarrollo de un conjunto de requerimientos que satisfarán una
necesidad específica. Al conjunto de requerimientos se le llama Especificación
de requerimientos de sistema (System Requirements Specification, SyRS).
2.4.1.2.1. Desarrollo de Especificaciones de Requerimientos de Sistemas (SyRS).
El desarrollo del SyRS es un proceso iterativo e incluye cuatro subprocesos
que son:
• Identificar los requerimientos del usuario, el ambiente y la experiencia de
la comunidad técnica.
• Construir requerimientos bien formados. Requerimientos con declaración
breve y definitiva de una necesidad, condiciones para cada
requerimiento, sin errores de especificación, legibilidad de los
requerimientos.
• Organizar los requerimientos en un SyRS. Se da estructura al conjunto
de los requerimientos relacionándolos entre sí con métodos
comparativos definidos.
• Presentar la SyRS en varias representaciones para diferentes
audiencias. Se Identifica la mejor manera de comunicar los
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
44
requerimientos para entender, revisar, aceptar o usar la SyRS por los
interesados.
Figura 10. Estándar IEEE Std 1233 (1998). Proceso de desarrollo de la SyRS. Extraído de (IEEE Std. 1233, 1998)
2.4.1.2.1.1 Identificar los requerimientos.
La IEEE Std. 1233 (1998) describe que se debe de trabajar con los clientes,
los analistas filtran entradas y extraen el grupo de requerimientos, establecen
requerimientos derivados necesarios y crean los requerimientos. Es un
proceso iterativo con la meta de extraer todos los requerimientos del sistema y
asegurarse que los requerimientos no están repetidos y que no falta ninguno.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
45
Describe el estándar que este proceso puede llevarse a cabo internamente
en la organización por el cliente y en otros casos pueden solicitar la asistencia
del analista de sistemas como consultor o integrador de sistemas.
El proceso de gestión de requerimientos debe asegurar lo siguiente:
• Orientado a los objetivos y producción de un conjunto de requerimientos.
• Definición del alcance del sistema.
• Requerimientos detectados, evaluados y documentados.
• Requerimientos especificados como capacidades y restricciones, y
condiciones calificativas.
• Requerimientos validados.
• Documento de SyRS consistente con participación de varios autores
• Comprensión de los requerimientos por todos los participantes del
proceso.
Como técnicas utilizadas en el proceso de desarrollo de requerimientos cita:
Talleres estructurados, sesiones de tormentas de ideas, entrevistas,
cuestionarios, observación de campo, revisión de la documentación técnica,
análisis de mercado, ingeniería inversa, simulaciones, prototipos.
En este proceso el analista debe de aprender acerca del ambiente del
cliente, del sistema actual y de los requerimientos, y el cliente debe de ser
educado por el analista con respecto a los requerimientos desde su
experiencia.
Se debe desarrollar una definición conjunta de los requerimientos y llegar a
un entendimiento común y representación en un SyRS a satisfacción del
cliente.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
46
2.4.2. Modelos para procesos de software.
Actualmente existen varios modelos para el proceso de desarrollo de
software entre los cuales podemos citar el CMM, CMMI, ISO 9001-20000,
ISO/IEC 15504 y Moprosoft, que abarcan todos los procesos de desarrollo de
software e indican qué se debe hacer, y se pueden utilizar como referencia
para definir procesos de una organización y evaluación. También están los
modelos UP, RUP, PSP y TSP que se utilizan como guía para ejecutar
proyectos enfocados a la ingeniería de productos de software.
Para este proyecto se estudiará el CMMI, como marco que describe
elementos clave de procesos efectivos de software, la ISO/IEC 15504 que es
un estándar internacional que ofrece un marco para la evaluación de procesos
de software, y el RUP que define un proceso enmarcado en mejores prácticas
para el desarrollo del software.
2.4.2.1. Modelo de Madurez de Capacidades Integrado. CMMI
CMMI® Integración de Modelos de Madurez de Capacidades (Capability
Maturity Model Integration, es un modelo de madurez de mejora de procesos
para el desarrollo y mantenimiento de productos y servicios. Consiste en una
serie de mejores prácticas que dirigen las actividades de desarrollo y
mantenimiento que cubren el ciclo de vida del producto. INTECO (2008).
CMMI se está compuesto en constelaciones, que agrupa componentes
CMMI en un modelo, materiales de aprendizaje y documentos de evaluación.
En la actualidad la última versión del 2010, en la versión 1.3, dispone de las
siguientes constelaciones:
CMMI for Acquisition v1.3 (2010). Describe la cadena de suministro,
adquisición y contratación externa.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
47
CMMI for Services v1.3 (2010). Describe la gestión ofrecida por el servicio.
CMMI for Development v1.3 (2010). CMMI-DEV. Describe los procesos de
desarrollo de productos y servicios.
Para esta investigación nos centraremos en el CMMI-DEV, ya que
contempla lo relacionado con el desarrollo de requerimientos de software.
2.4.2.1.1. Elementos del CMMI-DEV V1.3.
Software Engineering Institute, Carnegie Mellon University. CMMI-DEV
(2010) tiene dos representaciones las cuales son la escalonada y la continua.
• Representación contínua. Conocimiento de los procesos y las
dependencias entre procesos. Contiene 4 niveles de capacidad de 0 a 3:
0-Incompleta, 1-realizado, 2-Gestionado, 3-Definido.
0-Incompleta. Proceso imparcialmente implementado o no esta realizado en
su totalidad.
1-Realizado. Procesos que satisface los objetivos específicos, no está
institucionalizado en la organización.
2-Gestionado. Procesos monitorizados, controlados y revisados.
3-Definido. Procesos gestionados en forma proactiva, interrelacionados con
el resto de procesos. Productos medidos y controlados.
• Representación escalonada: Presenta una estructura en 5 niveles de
madurez: 1- Inicial, 2-Gestionados, 3-Definidos, 4-Cuantitativamente
Gestionados, 5- Optimizados.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
48
1- Inicial. Dependencia de los resultados de la capacidad de los
trabajadores. No dispone de procesos.
2- Gestionados. Se tiene procesos establecidos que aseguran una
planificación y ejecución. Procesos monitorizados, controlados y
revisados.
3- Definidos. Procesos bien caracterizados y estandarizados para toda la
organización, con herramientas y métodos.
4- Cuantitativamente Gestionados. Se establecen medidas cuantitativas
para poder medir el proceso y predecir rendimientos en los procesos.
5- Optimizados. Se centran en la mejora continua incrementable e
innovadora de los procesos de la organización.
CMMI-DEV V1.3 (2010) presenta como parte de su marco de trabajo 23
procesos que intervienen en el desarrollo, las cuales están agrupados en 4
categorías: Gestión del proceso, gestión del proyecto, ingeniería y soporte.
Como se indica en la Tabla 1.
• Gestión de procesos: Contiene áreas de proceso relacionadas con
definir, planear, desplegar, implementar, monitorear, controlar, evaluar,
medir y mejorar procesos.
• Gestión de proyectos: Contiene áreas de proceso relacionadas con
planeación, monitoreo y control de proyectos.
• Ingeniería: Cubre actividades relacionadas al desarrollo y mantenimiento
que son compartidas por toda la organización. Cualquier disciplina
técnica involucrada en desarrollo de productos o servicios puede ocupar
esta categoría para enfocar el proceso de mejora.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
49
• Soporte: Contiene áreas de proceso relacionadas con actividades que
apoyan el desarrollo y mantenimiento del producto, y que están dirigidas
a los procesos que son usados en el contexto del desarrollo de procesos
pertenecientes a otras áreas.
Áreas de Proceso Categoría Nivel de Madurez
Análisis causal y resolución (CAR) Soporte 5 Gestión de configuración (CM) Soporte 2 Análisis de decisiones y resolución (DAR) Soporte 3 Gestión integrada del proyecto (IPM) Gestión de proyecto 3 Medición y análisis (MA) Soporte 2 Definición de procesos de la organización (OPD) Gestión de proceso 3 Enfoque en procesos de la organización (OPF) Gestión de proceso 3 Gestión del rendimiento organizacional (OPM) Gestión de proceso 5 Rendimiento del proceso de la organización (OPP) Gestión de proceso 4 Formación organizativa (OT) Gestión de proceso 3 Integración de producto (PI) Ingeniería 3 Monitorización y control del proyecto (PMC) Gestión de proyecto 2 Planificación de proyecto (PP) Gestión de proyecto 2 Aseguramiento de la calidad de proceso y de producto (PPQA)
Soporte 2
Gestión cuantitativa de proyecto (QPM) Gestión de proyecto 4 Desarrollo de requerimientos (RD) Ingeniería 3 Gestión de requerimientos (REQM) Gestión de proyecto 2 Gestión de riesgos (RSKM) Gestión de proyecto 3 Gestión de acuerdos con proveedores (SAM) Gestión de proyecto 2 Solución técnica (TS) Ingeniería 3 Validación (VAL) Ingeniería 3 Verificación (VER) Ingeniería 3
Tabla 1. CMMI-DEV V1.3. Áreas de proceso, categorías y niveles de madurez. Traducción libre. Extraído de (Software Engineering Institute, Carnegie Mellon
University, 2010)
Las áreas de proceso relacionadas con la elicitación de requerimientos de
software están englobadas en la categoría de Ingeniería.
2.4.2.1.2. Áreas de Proceso de Ingeniería CMMI-DEV V1.3.
Las áreas de proceso de Ingeniería pueden integrar los procesos asociados
con diferentes disciplinas de ingeniería cuando el producto final es
consecuencia de ellas, dando así un soporte para estrategias organizacionales
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
50
orientas en el producto. Las áreas de proceso pertenecientes a la categoría de
Ingeniería son:
• Integración de Productos (PI). Ensambla el producto a partir de sus
componentes, asegurar que el producto, una vez integrado, funciona
correctamente, y entregar el producto.
• Desarrollo de Requerimientos (RD). Produce y analiza los
requerimientos de cliente, de producto y de componente del producto.
• Solución Técnica (TS). Diseña, desarrolla e implementa soluciones para
los requerimientos. Engloba productos, componentes de producto y
procesos del ciclo de vida asociados al producto, individualmente o en
combinación, según sea apropiado.
• Validación (VAL). Demuestra que un producto o componente de
producto se ajusta a su uso previsto cuando se sitúa en su entorno
previsto.
• Verificación (VER). Asegura que los productos de trabajo seleccionados
cumplen sus requerimientos especificados.
Las relaciones existentes entre las distintas áreas de proceso de la categoría
se visualizan en la siguiente figura:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
51
Figura 11. CMMI-DEV V1.3. Relación entre Áreas de Proceso de Ingeniería. Traducción libre. Extraído de (Carnegie Mellon University, 2010)
2.4.2.1.3. Desarrollo de Requerimientos (RD) en el CMMI-DEV V1.3.
El propósito del desarrollo de los requerimientos es elicitar, analizar, y
establecer requerimientos del cliente, del producto y componentes del
producto.
El desarrollo de los requerimientos contempla las siguientes actividades:
• Educción, análisis, validación y comunicación de las necesidades, las
expectativas y las restricciones del cliente para obtener los
requerimientos de cliente que constituyen una comprensión de lo que
satisfará a las partes interesadas.
• Recopilación y coordinación de las necesidades de las partes
interesadas.
• Desarrollo de los requerimientos del ciclo de vida del producto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
52
• Establecimiento de los requerimientos de cliente.
• Establecimiento de los requerimientos iniciales de producto y de
componentes del producto consistentes con los requerimientos de
cliente.
El cliente puede proporcionar requerimientos específicos del diseño. Los
requerimientos del cliente se refinan en el en requerimientos del producto y de
sus componentes.
Los elementos más importantes de esta área son:
• Desarrollo de los requerimientos del cliente
• Desarrollo de los requerimientos del producto
• Analizar y validar los requerimientos.
Resumen de Metas y prácticas específicas SG 1 Desarrollar los requerimientos de cliente.
SP 1.1 Elicitar las necesidades.
SP 1.2 Transformar las necesidades de los stakeholders en los
requerimientos del cliente.
SG 2 Desarrollar los requerimientos de producto.
SP 2.1 Establecer los requerimientos de producto y de componentes del
producto.
SP 2.2 Asignar los requerimientos de componentes del producto.
SP 2.3 Identificar los requerimientos de interfaz.
SG 3 Analizar y validar los requerimientos.
SP 3.1 Establecer los conceptos operativos y los escenarios.
SP 3.2 Establecer una definición de la funcionalidad requerida y atributos
de calidad.
SP 3.3 Analizar los requerimientos.
SP 3.4 Analizar los requerimientos para alcanzar el equilibrio.
SP 3.5 Validar los requerimientos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
53
Prácticas específicas por meta.
SG 1 Desarrollar los requerimientos del cliente. Las necesidades,
expectativas, restricciones e interfaces de las partes interesadas son recogidas
y traducidas a requerimientos de cliente.
SP 1.1 Elicitar las necesidades. Obtener las necesidades, las expectativas,
las restricciones, y las interfaces de las partes interesadas para todas las fases
del ciclo de vida del producto.
SP 1.2 Transformar las necesidades de los stakeholders en los
requerimientos del cliente. Transformar las necesidades, las expectativas, las
restricciones y las interfaces de las partes interesadas en requerimientos de
cliente.
SG 2 Desarrollar los requerimientos del producto. Los requerimientos de
cliente son refinados y elaborados para desarrollar los requerimientos del
producto y de componentes del producto. Incluye procesos, objetivos y
personal. Es la base para la solución técnica.
SP 2.1 Establecer los requerimientos del producto y de componentes del
producto. Se expresan los requerimientos en forma técnica desde el punto de
vista del sistema.
SP 2.2 Asignar los requerimientos de componentes del producto. El area de
proceso de solución técnica describe como se realiza la asignación de
componentes al producto.
SP 2.3 Identificar los requerimientos de la interfaz. Se especifican las
interfaces entre la funcionalidad.
SG 3 Analizar y validar los requerimientos. Los requerimientos son
analizados y validados, para tener la garantía que los requerimientos son
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
54
coherentes y no hay conflictos entre ellos. Una definición de la funcionalidad
requerida es desarrollada.
SP 3.1 Establecer los conceptos operativos de los escenarios. Los
escenarios muestran como el sistema se va a comportar y los conceptos
operacionales dependen del diseño y del escenario. Los conceptos se vuelven
soluciones, se toman decisiones y los requerimientos con mayor grado de
detalle son desarrollados.
SP 3.2 Establecer una definición de la funcionalidad requerida. Se realiza el
análisis funcional del sistema.
SP 3.3 Analizar los requerimientos. Se analizan los requerimientos y se
revisa que satisfagan sin conflictos a los objetivos.
SP 3.4 Analizar los requerimientos para alcanzar el equilibrio. Se revisan las
restricciones y las necesidades para ver si llevan a un riesgo, modifican la
planificación, etc.
SP 3.5 Validar los requerimientos. Validar los requerimientos para asegurar
que el producto resultante será el necesario.
2.4.2.2. Norma ISO/IEC TR 15504/SPICE
La norma ISO/IEC TR 15504/SPICE conocida como SPICE (Software
Process Improvement and Capability dEtermination) es un estándar para
procesos de desarrollo de software que provee un marco de trabajo para la
evaluación de procesos que una organización debe ejecutar para adquirir,
proveer, desarrollar, operar, evolucionar y dar soporte al software, y las
prácticas genéricas que caracterizan la capacidad de esos procesos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
55
SPICE está compuesto de la siguiente estructura descrita en la figura 12,
para la evaluación del proceso de software.
Figura 12. ISO/IEC TR 15504. Estructura de procesos. Traducción libre. Extraído de (SPICE, 2008)
ISO / IEC 15504 del 2008 es publicado como un estándar internacional
absoluto con el título de Tecnología de la Información en general - Evaluación
del proceso. Se compone de las siguientes partes.
Parte 1: Conceptos y vocabulario
Parte 2: Realización de una evaluación
Parte 3: Guía para la realización de una evaluación
Parte 4: Orientación sobre el uso de la mejora de procesos y la
determinación de la capacidad del proceso
Parte 5: Un proceso ejemplar de modelo de evaluación
Parte 6: Un proceso ejemplar de modelo de evaluación para los procesos de
los sistemas de ciclo de vida (en la actualidad FDAM en desarrollo)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
56
Parte 7: Evaluación de la madurez de la organización
Y están en desarrollo actualmente:
Parte 8 - Un proceso de evaluación ejemplar modelo para los procesos de
TI de gestión de servicios de ciclo de vida (en la actualidad PDTR)
Parte 9 - Perfil de las capacidades
Parte 10 - extensiones de seguridad (en la actualidad PDTR)
2.4.2.2.1. Estructura del estándar.
Se compone de dos dimensiones: dimensión del proceso y la capacidad de
la dimensión de proceso. INTECO (2008).
ISO/IEC 15504-5. (2006) Describe las dimensiones como sigue:
• Dimensión del proceso. Conjunto estándar de procesos para el ciclo de
vida completo del software. Parte de tres clases básicas de procesos:
Procesos primarios, procesos de soporte y procesos organizacionales,
que a su vez se dividen en nueve categorías de proceso:
Grupo de Procesos de Adquisición (ACQ)
Grupo de Procesos de Suministro (SPL)
Grupo de Procesos de Operación (OPE)
Grupo de Procesos de Ingeniería de Procesos (ENG)
Grupo de Procesos de Soporte (SUP)
Grupo de Procesos de Gestión (MAN)
Grupo de Procesos de Mejora de Procesos (PIM)
Grupo de Procesos de Recursos e Infraestructura (RIN)
Grupo de Procesos de reutilización (REU)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
57
Figura 13. ISO/IEC 15504-5. Categorías de procesos y grupos de procesos. Extraído de (ISO/IEC 15504-5, 2006)
• Capacidad de la dimensión del proceso. Define la escala de medida
para la capacidad del proceso. La norma ISO/IEC 15504-7 2006 (E)
establece 5 niveles de madurez para clasificar a las organizaciones:
Nivel 1. Procesos realizados: La organización implementa y alcanza los
objetivos de los procesos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
58
Nivel 2. Proceso gestionado: La organización gestiona los procesos y los
productos resultantes se establecen, controlan y mantienen.
Nivel 3. Proceso establecido: La organización utiliza procesos definidos
basados en estándares.
Nivel 4. Proceso predecible: La organización gestiona cuantitativamente los
procesos.
Nivel 5. Proceso optimizado: La organización mejora continuamente los
procesos para cumplir los objetivos del negocio.
2.4.2.2.2. Desarrollo de requerimientos en la norma ISO/IEC TR 15504/SPICE.
Los procesos del modelo que contemplan las actividades de desarrollo y
gestión de requisitos pertenecen a la categoría de procesos de Ingeniería, que
comprenden los procesos que directamente elicitan y gestionan los
requerimientos del cliente, especificación, implementación, y/o mantenimiento
del producto del software y su relación con el sistema. El proceso relacionado
con la elicitación de requerimientos es:
ENG.1 Elicitación de requisitos.
El propósito de este proceso es recoger, procesar y registrar las
necesidades y requisitos del cliente a lo largo de la vida del producto y/o
servicio para establecer una línea base de los requerimientos, como base para
definir los productos de trabajo necesarios. La recogida de requisitos puede
llevarse a cabo por el que adquiere o por el que desarrolla el sistema.
Como resultado de la implementación exitosa del proceso de elicitación de
requerimientos se obtiene:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
59
- Una comunicación estable continua con el cliente
- Una vez acordados los requerimientos con el cliente se definen y se crea
una línea base.
- Mecanismos de cambio de requerimientos, para evaluar e incorporar en la
línea base según las necesidades cambiantes de los clientes.
- Mecanismo para el control continuo de las necesidades del cliente.
- Mecanismo para asegurar que los clientes pueden determinar fácilmente el
estado y la disposición de sus peticiones.
- Mejoras derivadas de los cambios tecnológicos y las necesidades que se
identifiquen de los clientes, así como el impacto logrado.
Las prácticas propuestas para este proceso son:
ENG.1.1 Obtener requisitos y peticiones del cliente. Obtener y definir los
requerimientos y peticiones del cliente. Estas se pueden obtener mediante la
revisión de documentos, revisión del negocio, medio ambiente, y otros.
ENG.1.2 Entender expectativas del cliente. Asegurarse de que tanto el
proveedor como el cliente comprendan de la misma manera los requerimientos.
Las limitaciones de medio ambiente y limitaciones legales deben de ser
considerados. Empleo de técnicas para la revisión y elicitación de
requerimientos como son observación de sistemas existentes, prototipos,
simulaciones, extractos de documentos y otros.
ENG.1.3 Llegar a un acuerdo respecto a los requerimientos. Obtener un
acuerdo sobre los requerimientos, entre el equipo de desarrolladores y el
cliente.
ENG.1.4 Establecer una línea base de los requisitos del cliente. Formalizar
los requerimientos del cliente y establecer una línea base para uso del proyecto
y seguimiento del proyecto según las necesidades del cliente.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
60
ENG.1.5 Gestionar los cambios en los requerimientos del cliente.
Administrar todos los cambios realizados según necesidades del cliente,
evaluando el impacto y el riesgo de dichos cambios.
ENG.1.6 Establecer un mecanismo para consulta de requerimientos por
parte del cliente. Proporcionar un medio por el cual el cliente puede estar al
tanto de la situación y disposición de los cambios en los requerimientos.
2.4.2.3. Proceso Racional Unificado. RUP
2.4.2.3.1. Descripción de RUP.
Proceso Racional Unificado (RUP, por las siglas de Rational Unified
Process), es un proceso de ingeniería del software que proporciona un
conjunto de disciplinas para asignar tareas y responsabilidades dentro de un
grupo de desarrollo. Sommerville (2011) indica que este proceso se derivó el
trabajo sobre el UML y el proceso asociado de desarrollo de software unificado.
A continuación Sommerville (2011) describe el proceso de RUP:
RUP contempla tres perspectivas:
• Una perspectiva dinámica que muestra las fases del modelo a través del
tiempo.
• Una perspectiva estática que presenta las actividades del proceso que se
establecen.
• Una perspectiva práctica que sugiera buenas prácticas a usar durante el
proceso.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
61
RUP. FLUJOS DE TRABAJO Y FASES
Figura 14. RUP. Flujos de trabajo y fases. Extraído de (Rational Software
Corporation, 2002)
En la visión dinámica RUP se enfoca en un modelo de cuatro fases en el
proceso de software que se desarrollan en forma iterativa:
• Concepción. En esta fase se establece un caso empresarial para el
sistema, se identifican todas las entidades externas que interactúan con
el sistema y se definen estas interacciones. Se estudia esta información
para valorar la aportación del sistema para la empresa.
• Elaboración. En esta fase se desarrolla la comprensión del problema de
dominio, se establece el marco conceptual arquitectónico para el
sistema, se diseña el plan del proyecto y se identifica los riesgos clave
del proyecto. Se desarrolla un modelo de requerimientos para el
sistema (casos de uso UML), una descripción arquitectónica y un plan
de desarrollo del software.
• Construcción. Esta fase incluye el diseño, programación y pruebas del
sistema, partes del sistema son desarrollados en paralelo integrándose
en esta fase. Como producto de esta fase se tiene un sistema de
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
62
software funcionando y la documentación relacionada para entregar al
usuario.
• Transición. En esta fase se pone a funcionar en un ambiente
operacional el sistema de software.
La visión estática del RUP se enfoca en las actividades o flujos de trabajo
desarrolladas durante el proceso, y se compone de seis flujos de trabajo central
y tres flujos de trabajo de apoyo centrales. El desarrollo de los flujos de trabajo
se orienta sobre modelos UML. Estos flujos de trabajo son:
Flujo de trabajo central:
• Modelado del negocio. Modelado de los procesos de negocio utilizando
casos de uso de la empresa.
• Requerimientos. Identificación de los actores que interactúan con el
sistema y desarrollo de los casos de uso para modelar los
requerimientos del sistema.
• Análisis y diseño. Creación y modelamiento de un documento de diseño
utilizando modelos arquitectónicos, de componentes, de objetos y de
secuencia.
• Implementación. Implementación y estructuración de los componentes
del sistema en subsistemas de implementación. Ayuda a acelerar este
proceso la generación automática de código a partir de modelos de
diseño.
• Pruebas. Proceso iterativo que se realiza en conjunto con la
implementación y se siguen al completar la implementación.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
63
• Despliegue. Liberación de un producto, distribución a los usuarios e
instalación en su lugar de trabajo.
Flujo de trabajo de apoyo centrales o de soporte:
• Administración de la configuración del cambio. Flujo de trabajo de apoyo
que gestiona los cambios del sistema.
• Administración del proyecto. Flujo de trabajo de apoyo que gestiona el
desarrollo del sistema.
• Entorno. Flujo de trabajo de apoyo que pone a disposición del equipo de
desarrollo de software, las herramientas adecuadas de software.
Sommerville (2011) también describe que RUP se basa en seis mejores
prácticas fundamentales de ingeniería del software:
• Desarrollo de software de manera iterativa. Cosiste en incrementar el
plan del sistema según las prioridades del cliente desarrollando
funcionalidades del sistema de mayor prioridad en el proceso de
desarrollo.
• Gestión de requerimientos. Se documenta los requerimientos del cliente
y se gestionan los cambios de estos requerimientos, analizando los
efectos sobre el sistema.
• Usar arquitecturas basadas en componentes. Se estructura la
arquitectura del sistema en componentes.
• Software modelado visualmente. El uso de modelos UML gráficos para
elaborar representaciones de software estáticos y dinámicos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
64
• Verificar la calidad del software. Se garantiza que el software cumpla
con los estándares de calidad de la organización.
• Controlar los cambios de software. Se gestiona los cambios de software
con un sistema propio de administración de cambios.
RUP representa un enfoque que combina tres modelos de procesos como
son modelo en cascada, modelo incremental y el modelo de ingeniería del
software orientado a la reutilización. Lo que se destaca en RUP es la
separación de fases y flujos de trabajo e involucra el despliegue o entrega
como un proceso. Las fases con dinámicas con metas, los flujos de trabajo son
estáticos con actividades técnicas que se asocian a diferentes fases para lograr
las metas de cada fase.
2.4.2.3.2. Los requisitos en el ciclo de vida del software en RUP.
Jacobson, Booch, Rumbaugh (2000) describen que el modelo de casos de
uso se desarrolla incrementalmente a lo largo del desarrollo, en donde cada
iteración añade casos de uso nuevos o detalles a los que ya existen.
Los requisitos adquieren diferentes formas durante las distintas fases y las
iteraciones. En la fase de inicio, se identifican la mayoría de los casos de uso,
se delimita el sistema y el alcance del proyecto. En la fase de elaboración, se
captura la mayoría de los requisitos restantes, con éstos se estiman el tamaño
del esfuerzo de desarrollo requerido para el proyecto. Los requisitos restantes
se capturan e implementan durante la fase de construcción. En la fase de
transición casi no hay captura de requisitos, a no ser que haya requisitos que
cambien.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
65
2.4.2.3.3. Disciplina de Requerimientos en RUP.
Rational Software Corporation (2002) describe un conjunto de actividades o
flujos de trabajo en la disciplina de requerimientos como se describe la figura
15.
Figura 15. RUP. Disciplina de los requerimientos. Traducción libre. Extraído de (Rational Software Corporation, 2002)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
66
• Análisis del problema. Su propósito es obtener un acuerdo sobre el
problema a resolver, identificar las partes interesadas, definir los límites
del sistema e identificar las limitaciones impuestas en el sistema.
• Entender las necesidades de los stakeholders. Su propósito es
recopilar y obtener información de las partes interesadas y entender sus
necesidades reales. Estas solicitudes recopiladas se consideran como
entrada primaria para definir las características de alto nivel.
• Definición del sistema. En esta actividad se alinea al equipo del
proyecto en la comprensión del sistema, se realiza un análisis de alto
nivel sobre los resultados de la recogida de las solicitudes de los
interesados, se refina la visión para incluir las características en el
sistema y sus atributos, se perfecciona los modelos de casos de uso, se
documenta los resultados.
• Administración del alcance del sistema. Se prioriza y refina la
selección de características y requerimientos que se incluyen en la
iteración actual, se define el conjunto de casos de uso que representa
alguna funcionalidad significativa, se define los atributos y
requerimientos que se deben de mantener, se define el alcance con el
conjunto de requerimientos asignados, se realiza la gestión del alcance
del proyecto.
• Perfeccionar la definición del sistema. Se describe el flujo de casos
de uso en detalle, se realiza las especificaciones detalladas de
requerimientos de software, se realiza un modelo y prototipo de la
interfaz usuario, se perfecciona la definición del sistema con los casos
de uso definidos, se describen los actores, se ordena las funciones que
son alcanzables según prioridad.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
67
• Administración de cambios en los requerimientos. Evalúa las
solicitudes de cambio presentadas formalmente y se determina su
impacto, se estructura el modelo de casos de uso, se establece los
atributos de los requerimientos, se verifican los resultados con los
esperados por parte del cliente.
2.4.2.3.4. Captura de requisitos en RUP.
Jacobson, Booch, Rumbaugh (2000) llaman a la captura de requisitos al acto
de descubrimiento, y proceso de averiguar normalmente en circunstancias
difíciles, lo que se debe de construir.
También Jacobson et. al indican que el propósito fundamental del flujo de
trabajo de los requisitos es guiar al desarrollo hacia un sistema correcto,
mediante una descripción de los requisitos del sistema indicando las
condiciones o capacidades que el sistema debe cumplir, y lograr un acuerdo
con el cliente y los desarrolladores sobre qué debe y que no debe hacer el
sistema.
Los resultados del flujo de trabajo de los requisitos ayudarán al jefe de
proyecto a planificar las iteraciones y las versiones del cliente.
Para desarrollar el flujo de trabajo de los requisitos se llevan los siguientes
pasos:
• Enumerar los requisitos candidatos. Lista de ideas como conjunto de
requisitos candidatos provenientes de los clientes, usuarios, analistas, y
desarrolladores.
• Comprender el contexto del sistema. Se desarrolla un modelado del
dominio que describe los conceptos principales del contexto como
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
68
objetos del dominio y modelado del negocio que describe los procesos
con el objeto de comprenderlos.
• Capturar requisitos funcionales. Se basa en una técnica para identificar
requisitos como es los casos de uso, que capturan los casos funcionales
como los no funcionales que son específicos de cada caso de uso.
Cada caso de uso representa una forma de usar el sistema y los
usuarios que interactúan con ellos.
• Capturar requisitos no funcionales. Especifican propiedades del
sistema, como las restricciones del entorno, de la implementación,
rendimiento, dependencias de la plataforma, facilidad de mantenimiento,
extensibilidad y fiabilidad.
Para realizar la captura de requisitos, los analistas se valen de técnicas y
artefactos para obtener la visión suficientemente buena del sistema para
avanzar en los flujos de trabajo siguientes, y se llama a este conjunto de
artefactos conjunto de requisitos. La especificación de requisitos la conforman
el modelo de casos de uso y los requisitos adicionales. El contexto del sistema
lo conforman los modelos del dominio y del negocio.
La forma adecuada de controlar los cambios de los requisitos es por medio
de iteraciones, donde cada iteración refleja algún cambio en el conjunto de
requisitos.
2.5. Metodología de marco lógico
2.5.1. Definición del marco lógico
Rosenberg y Posner (1979) explican que el Marco Lógico fue desarrollado
por la Agencia de los Estados Unidos para el Desarrollo Internacional como
una herramienta para ayudar a conceptualizar un proyecto y analizar sus
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
69
premisas. Y éste ha sido adoptado con varias adaptaciones, por varias
organizaciones bilaterales e internacionales de desarrollo. Siendo valioso para
el diseño, ejecución, monitoria y evaluación de proyectos.
Según Camacho, Cámara, Cascante y Sainz (2001) el marco lógico es un
método de planificación participativa por objetivos, utilizados en proyectos de
cooperación para el desarrollo, y cuenta con una secuencia ordenada de
procesos de participación y técnicas de visualización de los acuerdos
alcanzados.
Y según Ortegón, Pacheco y Prieto (2005) la metodología de marco lógico
es una herramienta que facilita el proceso de conceptualización, diseño,
ejecución y evaluación de proyectos. Su énfasis se centra en la orientación por
objetivos, la orientación hacia grupos de beneficiarios y facilita la comunicación
entre el grupo de usuarios y las partes interesadas.
2.5.2. Fases del marco lógico.
Camacho, et. al (2001) indican que la Metodología de marco lógico se basa
en una lógica circular que subyace al plan propuesto, y se basa en cuatro fases
centrales que incluyen un conjunto de categorías internas o subetapas, estas
fases son: identificación, diseño o formulación, ejecución y seguimiento y
evaluación. Se muestra gráficamente en la figura 16.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
70
Figura 16. El modelo de marco lógico. Extraído de (Camacho et. al, 2001. Basado en Gómez y Sainz, 1999)
• Identificación. Se centra esta fase en determinar cuáles son los
problemas a resolver, se contextualiza y se madura la idea de lo que es
necesario y se desea hacer para resolver el problema de la situación
actual. Esta etapa se basa en la identificación y análisis del grupo de
beneficiarios.
Se realizan las preguntas de: ¿qué sucede?, ¿por qué sucede?, ¿a quiénes
y cómo afecta? ¿Cómo se puede solucionar?
El marco lógico brinda especial importancia sobre esta etapa ya que sobre
ella el modelo construye gran parte de la estructura del proyecto. Esta etapa
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
71
consta de los primeros pasos del marco lógico: Análisis de participación,
análisis de problemas, análisis de objetivos y análisis de alternativas.
• Diseño. Etapa llamada también formulación. Se basa en el análisis de
la fase de identificación, en el que se formalizan y organizan los
resultados obtenidos y se establecen para ello estrategias, plazos,
recursos, costos, etc. Responde a las preguntas de: ¿qué queremos
hacer? ¿Y cómo se puede realizar?, ¿a quién se dirige la acción?, ¿por
qué y para que actuar?, ¿con quién, donde , cuando y con qué
recursos?.
Se elabora el documento de diseño del proyecto, que será la guía de acción
y de comunicación indispensable entre las parte interesadas.
En esta etapa el principal elemento es la Matriz de Planificación de Proyecto,
que presenta en forma lógica y clara los elementos de la propuesta, como
complemento al documento de diseño del proyecto.
• Ejecución y seguimiento. Esta etapa comprende la ejecución de lo
planeado en el diseño. La ejecución y seguimientos se puede realizar
por distintos procedimientos de gestión, planes de trabajo, estrategias de
organización, y contar con un sistema de seguimiento para conocer la
evolución del proyecto.
• Evaluación. En esta fase se valora la acción de cooperación antes,
durante y después de la ejecución del proyecto. Esta evaluación se
apoya en el proceso de seguimiento. El marco lógico contempla un
conjunto de componentes como son: pertinencia, eficiencia, eficacia,
impacto, impacto, y viabilidad.
Ortegón, et al (2005) explican que la Metodología de Marco Lógico propone
una estructura que busca finalmente comunicar e integrar los elementos
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
72
esenciales sobre un proyecto o programa. La figura 17 caracteriza los
componentes principales y su secuencia para alcanzar el resultado de la
metodología.
Figura 17. Marco Lógico. Estructura Metodológica del Marco Lógico. Extraído de (Ortegón, Pacheco y Prieto, 2005)
Con base en este estudio podemos analizar que para el proceso de
elicitación de requerimientos de software podemos basarnos en las fases de
identificación y diseño, en esta última específicamente en la planificación de la
matriz de marco lógico. Fases que se amplía su estudio a continuación.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
73
2.5.2.1. Fase de Identificación.
Ortegón et. al. (2005) explican que en esta fase se analiza la situación
existente para crear una visión de la situación deseada y seleccionar las
estrategias que se aplicarán para lograrla. Esta fase se centra en resolver los
problemas a los que se enfrentan los grupos meta o beneficiarios, y responder
sus necesidades e intereses.
En esta fase es importante llevar a cabo un análisis estructurado de la
situación existente. La Metodología de Marco Lógico incorpora cinco elementos
analíticos importantes los cuales son:
• El análisis de participación (involucrados)
• El análisis de problemas (imagen de la realidad)
• El análisis de objetivos (imagen del futuro y de una situación mejor)
• El análisis de alternativas (comparación de diferentes alternativas en
respuesta a una situación precisa)
• Estructura analítica del proyecto.
Paso 1. Análisis de participación. Según los cursos ofrecidos en marco
lógico por el BID (Montalván), la identificación y participación de los principales
involucrados con el proyecto debe de ser desde el inicio del proceso. Se deben
identificar grupos y organizaciones relacionados directa o indirectamente con el
problema y analizar, sus reacciones frente al avance del proyecto, y conciliar
acuerdos con relación a diferentes puntos de vista y fomentar su pertenencia
con el desarrollo del proyecto. El análisis de involucrados implica:
• Identificar a las personas o grupos, organizaciones, empresas que
tengan relación con el proyecto.
• Clasificar y agrupar a los involucrados según sus características.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
74
Figura 18. Marco Lógico. Identificación de los involucrados. Modelo basado en (Ortegón et. al., 2005. Área de proyectos y programación de inversiones.
ILPES)
• Definir la posición de los involucrados con respecto al proyecto.
Camacho et. al. (2001) describe la siguiente tabla para el análisis de
participación de grupos de involucrados según la posición frente al proyecto.
Beneficiarios
Directos Beneficiarios
indirectos Excluidos/Neutrales Perjudicados/oponentes potenciales
Tabla 2. Marco Lógico. Análisis de participación de grupos de involucrados según posición frente al proyecto. Extraído de (Camacho et. al., 2001).
Camacho et. al. (2001) también describe que el análisis de participación e
implicados puede hacerse en dos fases como se muestra en las tablas
siguientes:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
75
Implicados Principales intereses Posible impacto del proyecto sobre los
intereses (+,-,=,?)
Primarios:
Secundarios:
Tabla 3. Marco Lógico. Fase 1. Análisis de participación de los implicados según sus
intereses. Extraído de (Camacho et. al., 2001).
Potenciales beneficiarios:
(Alta importancia, Baja influencia)
Potenciales contrapartes (Alta importancia, Alta influencia)
Otros colectivos indirectos: beneficiarios indirectos, neutrales, excluidos (Baja importancia, Baja influencia)
Potenciales oponentes (Baja importancia, Alta influencia)
Tabla 4. Marco Lógico. Fase 2. Análisis de participación de los implicados según sus
intereses. Extraído de (Camacho et. al., 2001).
• Definir la fuerza o poder de los involucrados frente al proyecto.
Ortegón et. al. (2005), propone la tabla 5, en donde se incluye el grupo de
involucrados, la posición frente al problema y la evaluación de su fuerza e
intensidad. Se utiliza una escala de 1 a 5, donde 1 indica el menor grado de
importancia del involucrado para el proyecto y el menor grado de
involucramiento, y por otra parte 5, indica el mayor grado de importancia de
involucramiento y el mayor grado de involucramiento. Se puede calificar con
negativo a los involucrados opositores del proyecto y positivo a los que
muestran apoyo. La resultante es el resultado de la multiplicación de la
expectativa por la fuerza.
Grupo de involucrados Expectativa Fuerza Resultante
Tabla 5. Marco Lógico. Análisis de participación de grupos de involucrados según expectativa y fuerza con respecto al proyecto. Extraído de (Ortegón et. al., 2005)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
76
• Definir la intensidad del compromiso de los involucrados con el proyecto.
El BID basado en el curso del modelo de marco lógico (Montalván), propone
la tabla 6 para registrar los intereses, problemas percibidos y recursos y
mandatos por grupos de involucrados con respecto al proyecto.
Grupos de
involucrados Intereses Problemas percibidos Recursos y Mandatos
Tabla 6. Marco Lógico. Grupo de Involucrados y posición frente al proyecto. Extraído de (Montalván. BID)
• Analizar y definir la incorporación de los involucrados al proyecto.
Sánchez (2007) indica que para llevar a cabo el análisis de participación, se
puede pueden aplicar entrevistas, encuestas y actividades de grupo focal, en
las que Ortegón et. al. (2005) citan como ejemplos de actividades de grupo la
Técnica de grupos nominales, técnica Delphi, Método EASW (European
Awareness Sustainability Workshop), núcleos de intervención participativa, etc.
Paso 2. Análisis de problema. En este paso de tratan de identificar los
problemas a intervenir, así como las causas y los efectos o consecuencias.
Enfatizando que un problema es un estado negativo existente y no una
ausencia de solución.
Sánchez (2007) indica que este análisis se puede hacer en forma de taller
en el que participan las partes interesadas con conocimiento de la
problemática, y coordinado por una persona con el dominio del método y
dinámica del grupo.
Sánchez (2007) también sugiere los siguientes pasos para realizar el análisis
del problema:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
77
• Analizar e identificar lo que se considere como problemas principales de
la situación que se analiza.
• Establecer el problema central, según criterios de prioridad y
selectividad, y formular en estado negativo el problema central
identificado.
• Construir el árbol de efectos, según su importancia, y graficar hacia
arriba del problema central. Los efectos pueden estar encadenados y
general a otros efectos siguiendo un orden causal ascendente.
Figura 19. Marco Lógico. Árbol de efectos. Extraído de (Sánchez, 2007. ILPES. Área de proyectos y programación de inversiones)
• Construir el árbol de causas, también pueden ir encadenadas, indicando
las causas primarias e independientes, al mayor número de causas,
permitirá mayor número de soluciones al problema identificado. En la
medida que se resuelvan las últimas causas del encadenamiento, se
podría decir que contribuye a superar positivamente la condición
negativa que se planteó.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
78
Figura 20. Marco Lógico. Árbol de causas. Extraído de (Sánchez, 2007. ILPES. Área de proyectos y programación de inversiones)
• Construir el árbol de problemas, integrando el problema central, el árbol
de efectos y el árbol de causas, representando el resumen de la
situación del problema analizado.
Figura 21. Marco Lógico. Árbol del problema. Integrado del árbol de efectos y del árbol de causas. Extraído de (Sánchez, 2007. ILPES. Área de proyectos y
programación de inversiones)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
79
• Revisar la validez e integridad del árbol, asegurándose que las causas
representan causas y los efectos representan efectos, y que el problema
central está bien definido y las relaciones causales.
Paso 3. Análisis de objetivos. Sánchez (2007) basada en Ortegón et al.
(2005) indican que este análisis permite describir la situación futura deseada
una vez se han resuelto los problemas. En este paso se realiza el árbol de
objetivos y los pasos sugeridos para su construcción son:
• Graficar el árbol de medios y fines, cambiando todas las condiciones
negativas del árbol de problemas a condiciones positivas deseadas y
viables. Por consiguiente las causas del árbol de problemas se
transforman en medios, los efectos se transforman en fines y el
problema central se convierte en el objetivo central o propósito del
proyecto. De este árbol de objetivos se deben deducir las alternativas de
solución para superar el problema.
Figura 22. Marco Lógico. Árbol de objetivos. Basado en el árbol de problemas. Extraído de (Sánchez, 2007. ILPES. Área de proyectos y programación de
inversiones)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
80
• Validar el árbol de medios y fines, examinando las relaciones de medios
y fines del árbol de objetivos. Si se encuentran inconsistencias es
necesario revisar nuevamente el árbol de problemas y de ser necesario
modificar las formulaciones incorrectas. Se pueden agregar nuevos
objetivos relevantes y eliminar aquellos que no.
Paso 4. Análisis de alternativas. Sánchez (2007) describe que basado en
el árbol de objetivos se formulan varias alternativas o acciones para solucionar
el problema planteado. Contiene los siguientes pasos:
• Identificar las acciones, en el que analíticamente se operacionalizan los
medios que están en la parte inferior del árbol de objetivos y que no
tienen otro medio que los genere y que también están en
correspondencia a las causas de la parte más baja del árbol de
problemas, como se muestra en la figura 23. Es recomendable tener un
buen número de acciones por cada medio y eso dependerá de la
experticia de analista del problema.
Figura 23. Marco Lógico. Árbol de Acciones. Basado en ejemplo del árbol de
acciones de (Sánchez, 2007. ILPES. Área de proyectos y programación de inversiones)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
81
Es muy importante verificar, la coherencia entre causa, medio y acción, por
la existencia de una relación lógica entre estos tres aspectos. En este sentido
la relación se puede expresar como sigue: la existencia de un problema se
explica por la existencia de una causa que lo provoca, para solucionarlo es
necesario recurrir a unos medios que eliminen la causa, para hacer efectivos
este medio se debe identificar una acción que lo operacionalice. Si se
esquematiza resulta lo siguiente:
Figura 24. Marco Lógico. Coherencia causa, medio y acción. Extraído de (Sánchez
(2007) y Ortegón et. al, 2005. ILPES. Área de proyectos y programación de inversiones)
• Discriminar entre acciones complementarias y excluyentes.
• Analizar las alternativas, planteándose cual o cuales de las soluciones
pueden ser desarrolladas por el proyecto, se debe ver la capacidad, los
medios disponibles, y los recursos de la organización que va a
desarrollar el proyecto, y ver el entorno que rodea el proyecto.
Existen variados procedimientos para realizar el análisis de alternativas
según las circunstancias particulares de cada proyecto, podemos citar
algunas sugeridas según los siguientes autores:
Camacho et. al. (2001) plantea un análisis cualitativo y cuantitativo para
el análisis de alternativas, indicando que las valoraciones pueden
efectuarse manejando criterios para el análisis cualitativo de: bueno-regular-
malo; alto-medio-bajo, etc., o, bien, en el caso del análisis cuantitativo en
asignar puntuaciones numéricas en una escala predeterminada a cada una
de las alternativas en función de cada criterio. Se multiplican los valores
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
82
absolutos de cada alternativa por el coeficiente de cada criterio, y la suma
total de éstas indica el puntaje de cada alternativa a analizar.
Camacho et. al. (2001), indica que los criterios que pueden manejarse
para la valoración de las diferentes alternativas detectadas son muy
variados pero pueden citarse algunos en forma general como
fundamentales:
• Recursos disponibles. Hace referencia a los recursos materiales,
financieros, humanos, capacidades.
• Tiempo estimado. Tiempo estimado para el logro de los objetivos a
valorar.
• Prioridades. Adecuación a las prioridades según los intereses de las
partes implicadas en el proceso.
• Riesgos. Riesgos identificados en cada una de las
alternativas/Probabilidades de logro de los objetivos.
• Probabilidad de alcanzar el objetivo. Contribución de las diferentes
alternativas al logro de objetivos de carácter más general.
• Impacto. Posibles efectos generados por el logro de los diferentes
objetivos valorados.
• Concentración sobre los beneficiarios. Vinculación entre las distintas
alternativas y los colectivos seleccionados como beneficiarios
prioritarios.
• Viabilidad. Posibilidades de viabilidad de cada una de las alternativas
identificadas.
Con base en los criterios anteriores se pueden citar las siguientes tablas
para el análisis cualitativo y cuantitativo.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
83
Criterios Alternativa 1 Alternativa 2 Alternativa 3
Recursos disponibles Tiempo estimado Prioridades de la política de desarrollo
Riesgos Probabilidad de alcanzar el objetivo
Impacto sobre el entorno Concentración sobre los beneficiarios
Viabilidad
Tabla 7. Marco Lógico. Análisis cualitativo de alternativas. Extraído de (Camacho et. al., 2001).
Criterios Coeficiente
Alternativa 1 Alternativa 2 Alternativa 3 Valor
absoluto Valor
ponderado Valor
absoluto
Valor ponderado
Valor absoluto
Valor ponderado
Recursos disponibles
Tiempo estimado Prioridades de la política de desarrollo
Riesgos Probabilidad de alcanzar el objetivo
Impacto sobre el entorno
Concentración sobre los beneficiarios
Viabilidad Total total total total
Tabla 8. Marco Lógico. Análisis cuantitativo de alternativas. Extraído de (Camacho et.
al., 2001).
Por otra parte, Ortegón et al. (2005), basados en AusGUIDElines, the logical
framework approach, AusAID, propone que las alternativas identificadas
pueden evaluarse por los siguientes aspectos:
• Costos totales en valores presentes y futuros
• Viabilidad financiera y económica
• Viabilidad técnica
• Habilidad para mejorar y mantener recursos
• Sostenibilidad
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
84
• Contribución al fortalecimiento institucional y construcción de capacidad
gerencial
• Impacto ambiental
• Aceptación por parte de los beneficiarios
• Compatibilidad del proyecto con prioridades de un sector o un programa
E indica que de las alternativas viables se escogerá aquella con mayor
pertinencia, eficiencia y eficacia.
Paso 5. Estructura analítica del proyecto. Sánchez (2007) indica que
consiste en la esquematización del proyecto en cuatro niveles jerárquicos: fin,
propósito, componentes y actividades. Y se construye con base en el análisis
de alternativas y el árbol de objetivos. Es la base para la construcción de la
matriz del marco lógico. Y se sugieren los siguientes pasos partiendo de arriba
hacia abajo:
• Identificar los fines del proyecto, que se obtienen del árbol de objetivos.
• Identificar el propósito, que corresponde al objetivo central del proyecto.
• Identificar los productos o componentes (resultados), que corresponde a
las obras, estudios, servicios para lograr el propósito.
• Identificar las actividades que se tendrán que realizar en cada
componente.
Lo anterior se puede ver gráficamente en la figura 25.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
85
Figura 25. Marco Lógico. Estructura analítica del proyecto. Extraído de (Ortegón et. al., 2005. ILPES. Área de proyectos y programación de inversiones)
2.5.2.2. Fase de Diseño (Planificación).
Sánchez (2007) describe que en esta etapa se elabora la Matriz de Marco
Lógico en la que se presenta en forma resumida los aspectos más importantes
del proyecto como se muestra en la tabla 9.
Resumen narrativo de
objetivos Indicadores Medios de verificación Supuestos
Fin Propósito Componentes Actividades
Tabla 9. Marco lógico. Estructura de la matriz de marco lógico. Extraído de (Ortegón
et. al., 2005. Área de proyectos y programación de inversiones. ILPES)
Contiene cuatro columnas que suministran la siguiente información:
• Un resumen narrativo de objetivos. Ortegón et al. (2005), indican que
para la construcción de la matriz de marco lógico se debe de pasar los
elementos de la estructura analítica del proyecto a la columna de
resumen narrativo de objetivos en un orden vertical por elementos: Fin,
Propósito, Componentes y Actividades, como se muestra en la figura 26.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
86
Figura 26. Marco Lógico. La estructura analítica del proyecto y la columna de objetivos de la matriz de marco lógico. Basado en el ejemplo de (Ortegón et. al., 2005.
Área de proyectos y programación de inversiones. ILPES)
El resumen narrativo de objetivos se ubica en la primera columna de la
matriz, y se desarrolla un análisis lógico vertical de abajo hacia arriba, para lo
cual se utiliza la tabla 10, y en dado caso que no se cumpla algunas de las
relaciones se tendrá que revisar y realizar las modificaciones del caso.
Condiciones Si No
Las actividades específicas para cada componente son necesarias para producir el componente Cada componente es necesario para lograr el propósito del proyecto No falta ninguno de los componentes necesarios para lograr el propósito del proyecto Si se logra el propósito del proyecto, contribuirá al logro del Fin Se indican claramente el Fin, el Propósito, los Componentes y las Actividades El Fin es una respuesta al problema más importante en el sector
Tabla 10. Marco. Lógico. Análisis lógico de los niveles jerárquicos de la columna de
resumen narrativo. Extraído de (Ortegón et. al., 2005. Área de proyectos y programación de inversiones. ILPES)
• Indicadores (Resultados específicos a alcanzar). Se realizan
indicadores por cada uno de los niveles del resumen narrativo (fin,
propósito, componentes y actividades), convirtiéndose en el punto de
referencia como guía de las actividades de gestión (monitoreo) y
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
87
evaluación del proyecto. Los indicadores deben de cumplir cinco
característica: especifico, medible, realizable, pertinente y enmarcado en
el tiempo, y pueden ser cuantitativos o cualitativos. La tabla 11 presenta
un modelo para realizar la evaluación de los indicadores.
Nivel Resumen narrativo Indicador
Meta
Cantidad Calidad Tiempo Lugar Grupo social
Fin Propósito Componentes Actividades
Tabla 11. Marco Lógico. Revisión de criterios para los indicadores. Extraído de
(Ortegón et. al., 2005. Área de proyectos y programación de inversiones. ILPES)
• Medios de Verificación. Se debe de indicar los métodos y fuentes de
recolección de información para evaluar y monitorear los indicadores
planteados.
• Supuestos. El BID (1997) indica que se consideran supuestos a los
factores externos que implican riesgos y están fuera de control de la
organización, e inciden en el éxito o fracaso del proyecto. Se consideran
como condiciones, acontecimientos, o decisiones que tienen que ocurrir
para que se logren los niveles de los objetivos planteados. Los riesgos a
los que se puede exponer un proyecto pueden ser ambientales,
financieros, institucionales, sociales, políticos, climatológicos u otros.
Ortegón et al. (2005), indica que para el desarrollo de la matriz de marco
lógico se requiere que se identifiquen los riesgos de cada etapa del proyecto:
actividad, componente, propósito y fin, expresado el riesgo como un supuesto
que se debe cumplir para avanzar al siguiente nivel de la jerarquía de objetivos
como se muestra en la tabla 12. Los supuestos se convierten en un juicio de
probabilidad de éxito del proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
88
Resumen narrativo de
objetivos Indicadores Medios de verificación Supuestos
Fin Propósito Componentes Actividades
Tabla 12. Marco Lógico. Relación entre supuestos y objetivos. Extraído de (Ortegón
et. al., 2005. Área de proyectos y programación de inversiones. ILPES)
Y cuatro filas que presentan información acerca de los objetivos,
indicadores, medios de verificación y supuestos en cuatro momentos diferentes
en la vida del proyecto:
• Fin al cual el proyecto contribuye de manera significativa luego de que el
proyecto ha estado en funcionamiento.
• Propósito logrado cuando el proyecto ha sido ejecutado.
• Componentes/Resultados completados en el transcurso de la ejecución
del proyecto.
• Actividades requeridas para producir los Componentes/Resultados
2.6. Resumen
Los requerimientos de software son una condición o característica necesaria
para desarrollar un sistema de software, también se le puede referir como
requisitos de software. Se les puede clasificar como requerimientos
funcionales y no funcionales (producto, organización, externos) que pueden
venir de los requerimientos a nivel del negocio y de usuario, y que van a
conformar los requerimientos del sistema a desarrollar.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
89
La ingeniería de requerimientos recolecta, organiza y documenta los
requerimientos del sistema; establece y mantiene acuerdos sobre los cambios
de requerimientos, entre los clientes y el equipo del proyecto.
La estructura de la ingeniería de requerimientos puede verse desde varios
puntos de vista según varios autores (Loucopoulos y Karakostas, Kotonya &
Sommerville, Pressman, Sommerville) en la que se destaca don grandes
procesos como son el desarrollo y la gestión o administración de estos
requerimientos, en cuanto al proceso de desarrollo podemos sintetizar cuatro
actividades como son la elicitación, análisis, especificación y validación de
requerimientos de software, con el propósito de entendimiento, descripción y
acuerdos con el cliente sobre la naturaleza del problema. En este proceso de
desarrollan los documentos de definición de requerimientos y el documento de
especificación de requerimientos.
Como objeto de estudio de este proyecto nos centraremos en el proceso de
elicitación de requerimientos de software que es básicamente el proceso de
obtener, adquirir y capturar todo el conocimiento relevante relacionado con el
dominio del problema proveniente de los requerimientos a nivel de negocio y de
usuario.
Al igual que el proceso de la ingeniería de requerimientos, las actividades
de la elicitación de requerimientos son definidas de diferentes formas por
diferentes autores (Loucopoulos y Karakostas, Christel y Kang, Bruegge y
Dutoit, Sommerville), en las que podemos sintetizar las siguientes: Identificar
las fuentes de requerimientos, identificar los involucrados con el sistema,
descubrir u obtener los requerimientos, clasificación de los requerimientos,
evaluación y fundamentación los requerimientos, priorización de los
requerimientos, integración y validación de requerimientos, documento de
requerimientos iniciales. Como producto de este proceso de elicitación se
obtiene una lista de requerimientos iniciales las cuales pasan como entrada al
siguiente proceso del proceso de la ingeniería de requerimientos el cuales es el
análisis y especificación de requerimientos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
90
El proceso de elicitación de requerimientos se lleva a cabo por medio de
diferentes técnicas para la extracción de requerimientos que pueden ir
enfocadas en forma individual o grupal, y que son aplicadas dependiendo de la
metodología de la elicitación aplicada para tal proceso.
Existe actualmente estándares y modelos guía para procesos de ingeniería
de sistemas y de desarrollo de software, las cuales podemos citar ISO/IEC
26702, IEEE std. 1233, CMM, CMMI, ISO 9001-20000, ISO/IEC 15504 y
Moprosoft, UP, RUP, PSP y TSP. En este proyecto se estudian los estándares
IEEE en el desarrollo de la ingeniería de sistemas como son ISO/IEC 26702,
IEEE std. 1233, y los modelos para procesos de software CMMI, ISO/IEC
15504 y RUP, específicamente lo relacionado con el proceso de los
requerimientos y su obtención.
Adicional a lo anterior, también se estudia la Metodología de Marco Lógico
como una herramienta que se orienta a facilitar el proceso de
conceptualización, diseño, ejecución y evaluación de proyectos. Esta
metodología se enfatiza en la orientación por objetivos, en los grupos de
beneficiarios y la facilitación de la participación y comunicación entre las partes
interesadas.
La Metodología de marco lógico comprende de 4 grandes fases cada una
con sus subetapas, y estas fases son: identificación, diseño o formulación,
ejecución y seguimiento y evaluación.
Para este trabajo se hace especial énfasis en las fases de identificación y
diseño, ya que están relacionadas directamente con el diagnóstico, planteo de
los objetivos, definición del alcance, componentes y actividades base para el
desarrollo de requerimientos de software.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
91
CAPITULO 3. PROBLEMA
3.1. Introducción.
La ingeniería de requerimientos posee un alto grado de importancia en el
proceso de desarrollo de software y por ende en la satisfacción de las
necesidades del cliente.
Por otra parte la elicitación de requerimientos de software es uno de los
procesos de la ingeniería de requerimientos con un alto grado de complejidad
en el momento de la extracción de los requerimientos, por la diversidad de
fuentes de información y la concepción del problema a resolver, causando
dificultades y problemas en el entendimiento y la negociación en el alcance del
proyecto con los interesados.
3.2. Descripción del problema
3.2.1. Fracasos en proyectos de software.
Según estudios realizados por el reconocido grupo de investigadores a nivel
mundial Standish Group, en que sus análisis apuntan fundamentalmente a
obtener información de proyectos fallidos de software y poder combatir las
causas de los fracasos, podemos analizar lo siguiente:
Con base en encuestas realizadas a los directores de los proyectos que
participaron en el estudio indicaron, según su opinión, que los tres principales
factores de éxito consistían en:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
92
1. Implicación de los usuarios
2. Apoyo de los directivos
3. Enunciado claro de los requisitos
Y por otra parte los tres principales factores de fracasos son:
1. Falta de información por parte de los usuarios
2. Especificaciones y requisitos incompletos
3. Especificaciones y requisitos cambiantes
Standish Group, en su publicación “CHAOS Report 2004” concluye en sus
estudios una clasificación de las diez principales causas de los fracasos
proyectos de software (por orden de importancia), y se muestran en la tabla 13.
Porcentajes fracasos de proyectos de software
Porcentaje Ítem 13,10% 12,40% 10,60% 9,90% 9,90% 9,30% 8,70% 8,10% 7,50% 6,20% 4,30%
Requisitos Incompletos Falta de involucración de Usuarios Falta de Recursos Expectativas no realistas Otros Falta de Soporte Dirección Requisitos cambiantes Fallos de Planificación El sistema ya no se necesita Carencias de IT Management Desconocimiento Tecnológico
Tabla 13. Porcentajes fracasos de proyectos de software. Extraído de (Standish
Group, CHAOS Report, 2004)
Se observa que el mayor índice de causas en fracasos corresponde a los
procesos de ingeniería de requerimientos en el proceso de elicitación, seguido
de las habilidades de gestión y las relacionales con los interesados.
Igualmente, estudios realizados por el ESI (European Software Institute) a
empresas europeas para el proyecto ESPITI (European Software Process
Improvement Training Initiative), cuyo objetivo era determinar las áreas más
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
93
problemáticas en el desarrollo y la gestión del software, se detectó que los
ingenieros de software encuentran mayores dificultades durante la etapa de
ingeniería de requerimientos, que en el resto de las fases de desarrollo de
software.
Standish Group en su reporte “Chaos Report 2009”, presenta una estadística
en cuanto a los proyectos fallidos, problemáticos y exitosos, indicando un
porcentaje alto entre los dos primeros con respecto al éxito del total de
proyectos desarrollados. Esto se muestra en la figura 27.
PROYECTOS FALLIDOS, PROBLEMATICOS Y EXITOSOS
Standish Group, CHAOS Report, 2009
Figura 27. Proyectos fallidos, problemáticos y exitosos. Extraído de (Standish Group, CHAOS Report, 2009)
3.2.2. Problemas en el proceso de elicitación de software
Los autores Loucopoulos y Karakostas (1995) describen las siguientes
dificultades del proceso de elicitación:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
94
• El conocimiento no siempre está disponible en la forma adecuada o
utilizable para ser usada por el analista.
• Los usuarios no tienen una idea clara de lo que ellos quieren del nuevo
sistema software.
• Los usuarios encuentran dificultad al describir su conocimiento del
dominio.
• Los conocimientos, experiencia y objetivos de los usuarios y analistas
son diferentes. Los usuarios emplean su propia terminología orientada al
dominio y los analistas usan un vocabulario orientado al computador.
• A los usuarios les disgusta la idea de tener que usar un nuevo sistema
software por lo que están poco dispuestos a participar en el proceso de
elicitación.
Christel y Kang (1992) hablan que los problemas que se presentan con los
requerimientos en el proceso de elicitación se pueden agrupar en tres
categorías:
• Problemas de ámbito o de alcance. Relacionados con obtener
información poca o mucha, límites del sistema mal definidos.
• Problemas de comprensión o entendimiento entre los usuarios y
desarrolladores. Usuarios con poca comprensión de sus necesidades y
analistas con poco conocimiento del dominio del sistema.
• Problemas de volatilidad. Evolución y cambios de los requisitos con el
tiempo.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
95
Pressman (2010) adiciona a lo dicho por Christel y Kang (1992) que para
superar estos problemas, debe enfocarse la obtención de requerimientos en
forma organizada.
Browne and Rogich (2001) describen que el proceso de elicitación pasa por
varias dificultades como son:
• Dificultades cognitivas, resultado de restricciones humanas como
procesadores de información.
• Dificultades de estructuración, resultado de la variedad y complejidad de
los requisitos de información.
• Dificultades de comunicación, debido a la complejidad de la interacción
entre usuarios y analistas al definir requerimientos.
Saiedian y Dale (2000) plantean que la obtención de requerimientos es un
proceso difícil y citan los problemas más comunes que dificultan la
identificación / definición de las necesidades del usuario, como son:
• Mala comunicación de la especificación de los requerimientos, causan
malentendidos que pueden llevar al no cumplimiento de las expectativas
del cliente.
• Resistencia al cambio por parte de algunas personas.
• Problemas de articulación y experiencia en relación a la terminología,
muchos profesionales pueden utilizar palabras técnicas que no son
claros para el cliente pudiendo confundir, molestar e intimidar.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
96
• Problemas de perspectiva en cuanto a que muchas empresas no tiene
técnicas integradas centradas al cliente dentro del proceso de desarrollo,
se ofrecen productos que no se basan sobre sus necesidades reales.
Los autores Whitten y Bentley, (2008) describen que las fallas de identificar
correctamente los requerimientos del sistema pueden dar como resultado lo
siguiente:
• El sistema puede costar más de lo proyectado.
• El sistema puede ser entregado después de lo pactado.
• El sistema puede no cumplir con las expectativas de los usuarios, y
puede provocar que no usen el sistema.
• Una vez en producción, los costos de mantenimiento y mejora del
sistema pueden ser altos.
• El sistema puede ser poco confiable, teniendo la tendencia a fallos.
• La reputación del equipo de desarrollo.
Los autores también hacen énfasis en los costos relativos para corregir un
error dependiendo de la etapa, en la cual se detecta el error, según Barry W.
Boehm, y se muestra en la tabla 14.
Costos relativos para corregir un error
Etapa en la cual se detecta el error Relación de costos Requerimientos Diseño Codificación Desarrollo de pruebas Pruebas de aceptación Operación.
1 3-6 10
15-40 30-70
40-1000
Tabla 14. Costos relativos para corregir un error. Extraído de (Whitten y Bentley, 2008).
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
97
Basado en los hallazgos de Boehm, un requerimiento equivocado que no fue
detectado y corregido hasta la fase de operación, costará 1000 veces más de
lo que costaría si fuera detectado y corregido en la fase de requerimientos, por
tanto al definir los requerimientos del sistema es importante que éstos tengan
los lineamientos de: consistentes, completos, factibles, requeridos, exactos,
rastreables, verificables.
Sommerville (2011), indica que la adquisición y la comprensión de los
requerimientos por parte de los participantes del sistema son un poco difíciles
por las siguientes razones:
• Los participantes frecuentemente no saben lo que quieren de un sistema
de cómputo y pueden hacer peticiones inalcanzables.
• Al expresar los participantes los requerimientos en sus términos puede
que los ingenieros de requerimientos sin experiencia en el dominio del
cliente, no entiendan estos requerimientos.
• Diferentes participantes tienen distintos requerimientos y pueden ser
expresados en diferentes formas.
• Los ingenieros de requerimientos deben de descubrir fuentes
potenciales de requerimientos, identificar similitudes y conflictos.
• Factores políticos que pueden influir en los requerimientos del sistema.
• Pueden cambiar los requerimientos, la importancia o el surgimiento de
nuevos requerimientos durante el proceso de análisis.
3.3. Preguntas de investigación
Basados en el problema descrito, se pueden plantear los siguientes
interrogantes, que se intentan responder con este trabajo de tesis y que será
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
98
en busca de algún aporte, mejora o apoyo en el proceso de la elicitación de
requerimientos de software:
• ¿Aporta algún beneficio la aplicación metodológica del marco lógico a
proyectos de desarrollo del software?
• ¿Aporta algún beneficio la aplicación metodológica del marco lógico a la
elicitación de los requerimientos de software?
• ¿Es posible adaptar la metodología de marco lógico a la elicitación de
requerimientos de software?
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
99
CAPITULO 4. SOLUCIÓN
En este capítulo se realiza un análisis de la elicitación de requerimientos de
software y el aporte de la metodología de marco lógico, y se desarrolla la
propuesta de la metodología para la elicitación de requerimientos de software
basada en el modelo de marco lógico, esto como respuesta a las preguntas de
investigación planteadas en el capítulo anterior.
4.1 Análisis en la elicitación de requerimientos de software y el apoyo que aporta la metodología de marco lógico.
El Proceso de ingeniería de requerimientos se define como un conjunto
estructurado de actividades, que incluyen la elicitación, análisis y negociación,
especificación y la validación de requerimientos de software.
La elicitación de requerimientos de software es el proceso de la ingeniería de
requerimientos en el que se realiza la obtención de datos, de diferentes fuentes
de información, utilizando técnicas de recabación y análisis en forma individual
y/o grupal dependiendo de la metodología empleada.
La información recopilada y el análisis realizado de este proceso de
elicitación, son de gran importancia para el sistema de información de la
empresa o negocio, y por consiguiente para la conformación de los
requerimientos de software del sistema a desarrollar en proyectos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
100
La elicitación de requerimientos tiene como principales actividades de
desarrollo: Identificar fuentes de conocimiento, adquirir y decidir sobre la
relevancia de un conocimiento, comprender el significado e impacto del
conocimiento, y presenta como producto la creación de modelos conceptuales.
De igual forma existen varios estándares y modelos guía para procesos de
ingeniería de sistemas y de desarrollo de software, los cuales se estudiaron en
este trabajo los siguientes: ISO/IEC 26702, IEEE std. 1233, CMMI, ISO/IEC
15504 y RUP, cada uno describe el proceso, actividades y algunos las
técnicas de elicitación.
Como problemas en el proceso de elicitación encontramos: La búsqueda del
conocimiento de un dominio y su educción, la distribución en diferentes fuentes,
diversidad conflictiva, identificación y extracción correcta del conocimiento en
expertos humanos.
Por otra parte, la Metodología de Marco Lógico se describe como una
herramienta que facilita el proceso de conceptualización, diseño, ejecución y
evaluación de proyectos, y se compone de una secuencia de 5 pasos
metodológicos principales: Análisis de Involucrados, Análisis de Problemas,
Análisis de Objetivos, Análisis de Alternativas, y La Matriz del Marco Lógico, y
cada una genera productos considerables que se indican en tabla analítica
anterior.
• Análisis de involucrados. Por medio de la tabla de involucrados se
logrará identificar y esclarecer qué grupos y organizaciones están directa
o indirectamente involucrados en el problema de desarrollo específico
que intentamos resolver, para tomar en consideración sus intereses, su
potencial y sus limitaciones, con el fin de gestionar el cómo maximizar el
apoyo y minimizar la resistencia cuando el proyecto se empiece a
ejecutar.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
101
Este análisis ayudará a identificar los actores que van a interactuar con el
sistema a desarrollar, y que van a participar en proceso de la elicitación de los
requerimientos del software a desarrollar.
• Análisis de problemas. Por medio del árbol de problemas se logrará
visualizar relaciones de causalidad y sus interrelaciones en forma de
diagrama, en la que se logra analizar la situación actual relacionada con
el problema de desarrollo seleccionado, se identifica los problemas
principales en torno al problema de desarrollo y las relaciones causa-
efecto entre ellos.
Con este análisis podemos hacer una descripción de la problemática
situación actual y un mejor entendimiento en el momento de identificar
objetivos y alternativas de solución, base para el sistema de software a
desarrollar.
• Análisis de Objetivos. Por medio del árbol de objetivos se logrará
describir la situación que podría existir después de solucionar los
problemas, identificar las relaciones medios-fines entre los objetivos y
visualizar estas relaciones en un diagrama.
Por medio de este árbol podemos identificar el objetivo del proyecto e ir
identificando los requerimientos funcionales.
• Análisis de alternativas. A partir del árbol de objetivos (medios) se
elabora el árbol de acciones, y se logrará identificar estrategias,
evaluarlas y determinar la estrategia a seguir para promover el cambio
de la situación actual a la situación deseada.
• Matriz de Marco Lógico. Por medio de esta herramienta se permitirá la
concepción, el diseño, la ejecución, el seguimiento de desempeño y la
evaluación que debe ser revisada, modificada y mejorada en todo el
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
102
proceso de diseño y ejecución. Se basa en actividades, componentes,
propósito y fin, en la que se siguen indicadores de medición, medios de
verificación, y supuestos. Se observarán logros, éxitos y metas
cumplidas.
Se puede concluir que los productos de la Metodología de Marco Lógico
apoyarán al diagnóstico (tabla de involucrados, árbol de problemas), a la
identificación (árbol de objetivos, árbol de acciones), a la consolidación y
planeación (Matriz de Marco Lógico), seguimiento y control (indicadores de
medición, medios de verificación, y supuestos) a los modelos y estándares
relacionados con la gestión de la ingeniería de requerimientos de software.
Con el estudio de los estándares y modelos para la ingeniería del software y
el marco lógico, la tabla No. 15 presenta una síntesis comparativa de las
actividades planteadas en la elicitación de requerimientos, los productos y las
técnicas a utilizar por cada una, para el desarrollo de éste proceso.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
103
SINTESIS DE ESTANDARES Y MODELOS DE INGENIERIA DEL REQUERIMIENTOS VS METODOLOGIA DE MARCO LOGICO
Estándar/modelo Descripción Elicitación de requerimientos
Procesos, Actividades o prácticas en la Elicitación de
requerimientos Productos Técnicas de
Elicitación
Estándares IEEE en el desarrollo de la ingeniería de sistemas
Estándar ISO/IEC 26702.
Contempla la aplicación y gestión de los procesos de la ingeniería de sistemas.
Tiene el fin de establecer lo que el sistema será capaz de lograr, teniendo en cuenta los requerimientos, limitaciones y restricciones.
- Definir las expectativas de las
partes interesadas. - Definir las restricciones del
proyecto y de la empresa. - Definir las restricciones
externas. - Definir los escenarios
operacionales. - Definir los límites del sistema. - Definir requerimientos
funcionales. - Definir los requerimientos de
rendimiento.
- Expectativas de las partes
interesadas. - Restricciones del proyecto
y de la empresa - Restricciones externas - Escenarios operacionales - Límites del sistema - Requerimientos
funcionales - Requerimientos de
rendimiento.
No describe técnicas para la elicitación de los requerimientos de software
Estándar IEEE Std 1233.
Guía para el desarrollo de especificaciones de requerimientos de sistemas de la IEEE
Se le denomina a este proceso como la identificación de requerimientos, cuya meta es extraer todos los requerimientos del sistema y asegurarse que los requerimientos no están repetidos y que no falta ninguno.
- Identificar objetivos y conjunto de requerimientos
- Definición del alcance - Detectar, evaluar y
documentar los requerimientos.
- Especificar requerimientos, restricciones y condiciones calificativas.
- Validar los requerimientos - Desarrollar el documento
SyRS - Comprender los
requerimientos por parte de los participantes del proceso.
Desarrollo de un documento SyRS a satisfacción del cliente. Que debe contener lo siguiente: (estándar IEEE 830) - Objetivos - Alcance - Conjunto de
Requerimientos, restricciones y condiciones.
Entre otros.
Talleres estructurados, sesiones de tormentas de ideas, entrevistas, cuestionarios, observación de campo, revisión de la documentación técnica, análisis de mercado, ingeniería inversa, simulaciones, prototipos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
104
SINTESIS DE ESTANDARES Y MODELOS DE INGENIERIA DEL REQUERIMIENTOS VS METODOLOGIA DE MARCO LOGICO
Estándar/modelo Descripción Elicitación de requerimientos
Procesos, Actividades o prácticas en la Elicitación de
requerimientos Productos Técnicas de
Elicitación
Modelos para procesos de software.
Modelo de Madurez de Capacidades Integrado. CMMI
Modelo de madurez de mejora o evaluación de procesos para el desarrollo y mantenimiento de productos y servicios. Niveles de madurez: 1.Inicial 2.Repetible/ Gestionado 3.Definido 4.Gestionado cuantitativamente 5. Optimizado
La elicitación de requerimientos está enmarcada en CMMI-DEV V1.3. Área de proceso Desarrollo de Requerimientos (RD). El propósito del desarrollo de los requerimientos es elicitar, analizar, y establecer requerimientos del cliente, del producto y componentes del producto
Metas y prácticas específicas
SG 1 Desarrollar los requerimientos de cliente. - SP 1.1 Elicitar las
necesidades. - SP 1.2 Transformar las
necesidades de los stakeholders en los requerimientos del cliente.
SG 2 Desarrollar los requerimientos de producto. - SP 2.1 Establecer los
requerimientos de producto y de componentes del producto.
- SP 2.2 Asignar los requerimientos de componentes del producto.
- SP 2.3 Identificar los requerimientos de interfaz.
SG 3 Analizar y validar los requerimientos. - SP 3.1 Establecer los
conceptos operativos y los escenarios.
- SP 3.2 Establecer una definición de la funcionalidad requerida y atributos de calidad.
- SP 3.3 Analizar los requerimientos.
- Requerimientos del cliente - Requerimientos del
producto - Requerimientos de los
componentes del producto.
No describe técnicas para la elicitación de los requerimientos de software.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
105
SINTESIS DE ESTANDARES Y MODELOS DE INGENIERIA DEL REQUERIMIENTOS VS METODOLOGIA DE MARCO LOGICO
Estándar/modelo Descripción Elicitación de requerimientos
Procesos, Actividades o prácticas en la Elicitación de
requerimientos Productos Técnicas de
Elicitación
- SP 3.4 Analizar los requerimientos para alcanzar el equilibrio.
- SP 3.5 Validar los requerimientos.
Norma ISO/IEC TR 15504/SPICE
Estándar para procesos de desarrollo de software que provee un marco de trabajo para la evaluación de procesos que una organización debe ejecutar para adquirir, proveer, desarrollar, operar, evolucionar y dar soporte al software, y las prácticas genéricas que caracterizan la capacidad de esos procesos. Dimensiones: 1.Dimensión de proceso. 2. Dimensión de capacidad de proceso.
La elicitación de requerimientos está enmarcada en el Grupo de Procesos de ingeniería de Procesos (ENG). ENG.1 Elicitación de requisitos El propósito de este proceso es recoger, procesar y registrar las necesidades y requisitos del cliente a lo largo de la vida del producto y/o servicio para establecer una línea base de los requerimientos, como base para definir los productos de trabajo necesarios.
ENG.1 Elicitación de requisitos Las prácticas propuestas para este proceso son: ENG.1.1 Obtener requisitos y peticiones del cliente. ENG.1.2 Entender expectativas del cliente ENG.1.3 Llegar a un acuerdo respecto a los requerimientos. ENG.1.4 Establecer una línea base de los requisitos del cliente. ENG.1.5 Gestionar los cambios en los requerimientos del cliente. ENG.1.6 Establecer un mecanismo para consulta de requerimientos por parte del cliente.
- Requisitos del cliente - Línea base de los
requisitos del cliente - Medios de comunicación
de cambios de requerimientos con el cliente.
No describe técnicas para la elicitación de los requerimientos de software.
Proceso Racional Unificado. RUP
Proceso de ingeniería del software que proporciona un conjunto de disciplinas para asignar tareas y
La elicitación de requerimientos se enmarca en el proceso de Captura de requisitos en RUP, y
- Enumerar los requisitos candidatos
- Comprender el contexto del sistema.
- Capturar requisitos
Artefactos resultantes: - Lista de características - Modelos del dominio o del
negocio - Modelos de casos de uso
- Caso de uso - Glosario de
términos.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
106
SINTESIS DE ESTANDARES Y MODELOS DE INGENIERIA DEL REQUERIMIENTOS VS METODOLOGIA DE MARCO LOGICO
Estándar/modelo Descripción Elicitación de requerimientos
Procesos, Actividades o prácticas en la Elicitación de
requerimientos Productos Técnicas de
Elicitación
responsabilidades dentro de un grupo de desarrollo.
lo define como el acto de descubrimiento, y el proceso de averiguar normalmente en circunstancias difíciles, lo que se debe de construir.
funcionales. - Capturar requisitos no
funcionales.
- Requisitos adicionales o casos de uso concretos, según requisitos específicos de un caso de uso.
Metodología de Marco Lógico
Metodología de Marco Lógico.
MML
Herramienta que facilita el proceso de conceptualización, diseño, ejecución y evaluación de proyectos.
Etapa de Identificación. Se analiza la situación existente para crear una visión de la situación deseada y seleccionar las estrategias que se aplicarán para lograrla. Se centra en que los proyectos son diseñados para resolver los problemas a los que se enfrentar los grupos meta o beneficiarios, y responder sus necesidades e intereses. Etapa de Planificación. En esta etapa la idea del
Etapa de Identificación Actividades: - El análisis de involucrados - El análisis de problemas - El análisis de objetivos - El análisis de estrategias o
alternativas - Estructura analítica del
proyecto. Etapa de planificación. Actividades: Elaboración de la matriz de marco lógico: - Resumen narrativo de los
objetivos y las actividades. - Elaboración de Indicadores - Elaboración de Medios de
Verificación. - Elaboración de Supuestos
Herramientas de diagnóstico: - Tabla de involucrados - Árbol de problemas Herramientas de identificación: - Árbol de objetivos - Árbol de acciones Herramienta de planificación: - Matriz de marco lógico
Técnicas de participación individual. - Observación
directa - Entrevistas - Cuestionarios Técnicas de participación grupal - Técnica de
grupos nominales.
- Técnica Delphi. - Método EASW
(European Awareness Sustainability Workshop),
- Núcleos de intervención participativa.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
107
SINTESIS DE ESTANDARES Y MODELOS DE INGENIERIA DEL REQUERIMIENTOS VS METODOLOGIA DE MARCO LOGICO
Estándar/modelo Descripción Elicitación de requerimientos
Procesos, Actividades o prácticas en la Elicitación de
requerimientos Productos Técnicas de
Elicitación
proyecto se convierte en un plan operativo práctico para la ejecución. En esta etapa se elabora la Matriz de Marco Lógico y se definen las actividades y los recursos y son visualizados en cierto tiempo.
Tabla 15. Síntesis de estándares y modelos de ingeniería de requerimientos vs. Metodología de Marco Lógico.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
108
4.2. Propuesta
Como solución al problema planteado se propone desarrollar una
metodología para la elicitación de requerimientos de software basada en el
marco lógico, en la que puede servir de apoyo en los procesos de concepción y
entendimiento del problema del sistema a desarrollar, análisis e identificación
del alcance del proyecto, identificación de los requerimientos iniciales del
sistema y del software, administración de los requerimientos iniciales
identificados y por ende en el proceso de negociación con los interesados en el
proyecto.
Esta propuesta hace especial énfasis en la identificación de los involucrados,
sus intereses y el apoyo e involucramiento de éstos en el desarrollo del
proyecto de software. Así como también el análisis participativo de éstos para
el diagnóstico del problema, determinando el problema central, con las causas
y efectos, la solución del problema como objetivo central y alcance,
identificando los medios y fines, y las acciones a desarrollar para alcanzar los
objetivos o fines, base para la identificación de los requerimientos del sistema
de software a desarrollar, los componentes y actividades.
El análisis final se consolida en una matriz de administración de la estructura
analítica del proyecto, y elementos de control y seguimiento en el cumplimiento
de cada uno de las actividades como son indicadores, fuentes de verificación y
supuestos, para el logro del fin o meta del proyecto.
4.3. Solución basada en la propuesta
A continuación se describe la metodología propuesta y sus componentes.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
109
4.3.1. Metodología para la elicitación de requerimientos de software basada en el marco lógico
La metodología planteada para la elicitación de requerimientos de software
se basa en el modelo del marco lógico, está compuesta de conceptos, objetivo,
actividades, productos elicitados, técnicas, herramientas, y roles y
responsabilidades de los participantes de la metodología. A continuación se
describen estos componentes.
4.3.1.1. Conceptos de la metodología
La tabla 16 contiene los términos y definiciones de la metodología, como
sigue:
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO
Conceptos de la metodología
Término Definición
Actividad Acción tomada o trabajo dentro de un proyecto a fin de transformar los insumos (fondos, equipos) en resultados (organizaciones, edificios). (Haugland et. al.)
Alcance Limites de un proyecto: las áreas de un negocio que el proyecto podría atender (o no). Whitten et.al. (2008).
Ambiente
Las circunstancias, objetos, y condiciones que influenciarán el sistema terminado; éstas incluyen influencias políticas, de mercado, culturales, organizacionales así como estándares y políticas que afectarán lo que el sistema debe hacer y cómo debe hacerlo. (IEEE Std. 1233-1998).
Análisis del sistema
Estudio del dominio de un problema de negocios para recomendar mejoras y especificar los requerimientos del negocio y las prioridades para la solución. (Whitten y Bentley, 2008).
Analista Un miembro de la comunidad técnica (ingenieros en sistemas o analistas de negocios, que desarrollan los requerimientos del sistema) que está capacitado para definir problemas y analizar, desarrollar y expresar algoritmos. (IEEE Std 1233-1998).
Beneficiarios Beneficiarios previstos son los directos (grupo beneficiario) más los indicalistas. (Haugland et. al.))
Cliente
La entidad o entidades para los cuales los requerimientos deben ser satisfechos en el sistema que está siendo definido y desarrollado. Éste puede ser el usuario final de un sistema terminado, una organización dentro de la misma compañía desarrolladora, una compañía o entidad externa a la compañía desarrolladora, o una combinación de las anteriores. Ésta es la entidad para la cual el desarrollador de sistema debe demostrar que el sistema terminado satisface los requerimientos especificados. (IEEE Std 1233-1998).
Definición de problemas
Declaración y categorización de problemas, oportunidades y directrices; también suele incluir las restricciones y una decisión inicial a la solución. (Whitten et. al, 2008).
Enfoque del marco lógico (EML) o modelo de marco lógico
Herramienta de gestión que facilita la planificación, ejecución y evaluación del proyecto. (Haugland et. al.).
Entrevista Técnica de identificación de datos, en la que el analista de sistemas recopila información de individuos mediante interacción cara a cara. (Whitten et. al, 2008)
Factor externo Acontecimiento, condición o decisión necesaria para el éxito de un proyecto pero que
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
110
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL
MARCO LOGICO
Conceptos de la metodología
Término Definición
o supuesto está en gran parte o totalmente fuera del control de la administración del proyecto. (Haugland et. al.).
Fuerza Poder para afectar el proyecto, importancia del involucrado en el proyecto. (Ortegón et al., 2005)
Gerente de proyecto
Profesional experimentado que acepta la responsabilidad de planear, vigilar y controlar proyectos en cuanto al plan, presupuesto, productos, satisfacción del cliente, normas técnicas y calidad del sistema. (Whitten et. al, 2008).
Grupo beneficiario
(Beneficiarios Directos). El grupo específico para beneficio del cual se emprende el proyecto o programa; estrechamente relacionado con el impacto y la pertinencia. (Haugland et. al.).
Identificación de hechos
Proceso formal de usar la investigación, juntas, entrevistas, cuestionarios, muestreo y otras técnicas para recopilar información acerca de los problemas, requerimientos y preferencias concernientes al sistema. (Whitten et. al., 2008).
Identificación de requerimientos
Proceso y técnicas que usan los analistas de sistemas para identificar o extraer problemas de los sistemas y requerimientos de solución de la comunidad de usuarios. (Whitten et. al, 2008).
Impacto Los cambios positivos y negativos producidos directa o indirectamente, como resultado de un programa o proyecto. (Haugland et. al.).
Indicador Resultado específico a alcanzar. (Ortegón et al., 2005). En el contexto del EML un indicador define la norma de realización que hay que alcanzar a fin de lograr un objetivo. (Haugland et. al.)
Insumo Los presupuestos, personal, equipos, etc. de un proyecto necesarios para producir el resultado propuesto. (Haugland et. al.)
Intensidad grado de involucramiento con el proyecto, importancia que le da al proyecto. (Ortegón et al., 2005).
Interesado
Toda persona que tiene interés en un sistema de información existente y propuesto. Los interesados y grupos de interés pueden ser trabajadores técnicos y no técnicos. También pueden tratarse de trabajadores de la misma compañía o de otras. (Whitten, 2008).
Involucrado Toda persona que tiene interés en un sistema de información existente o propuesto. Los involucrados o grupos de interés pueden ser trabajadores técnicos y no técnicos. También puede tratarse de trabajadores internos y externos. (Whitten et. al, 2008)
Meta Objetivo Global.
Objetivo Una medición de éxito. Es algo que se espera lograr si se tienen recursos suficientes. (Whitten et. al, 2008)
Objetivo global El principal objetivo global al que el proyecto tiene que contribuir a largo plazo y que explica la razón por la que se implementa. . (Haugland et. al.).
Objetivo específico
La razón inmediata de un proyecto. El efecto que se espera que el proyecto vaya a lograr si se completa con éxito y a tiempo. (Haugland et. al.)
Posición apoyo y oposición al proyecto. (Ortegón et al., 2005)
Problema Situación indeseable que impide a la organización lograr plenamente su misión, visión, metas y objetivos. (Whitten et. al, 2008).
Propietario del sistema
Patrocinador y proponente ejecutivo de un sistema de información, que generalmente se encarga del financiamiento del proyecto y del desarrollo, operación y mantenimiento del sistema de información. (Whitten et. al, 2008)
Propósito Objetivo específico.
Proyecto Una intervención planificada destinada a lograr ciertos objetivos específicos dentro de un presupuesto dado y dentro de cierto periodo de tiempo. (Haugland et. al.).
Resultado Los resultados que el proyecto puede garantizar como consecuencia de las actividades. (Haugland et. al.).
Representación Una ilustración, dibujo, diagrama de bloques, descripción o símbolo que representa de manera lógica una imagen o situación física, operacional o conceptual. (IEEE Std 1233-1998).
Requerimiento
a) Una condición o capacidad requerida por un usuario para resolver un problema o alcanzar un objetivo. b) Una condición o capacidad que debe ser poseída por un sistema o componente del sistema para satisfacer un contrato, estándar, especificación, u otro documento formalmente impuesto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
111
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL
MARCO LOGICO
Conceptos de la metodología
Término Definición
c) Una representación documentada de una condición o capacidad como las descritas en los incisos a) o b). (IEEE 610.12-1990)
Requerimientos de negocio
Dan una descripción a alto nivel de lo que el sistema debe hacer. Representan: los objetivos, la base del negocio, estrategias, visión, alcance y el valor esperado del desarrollo del software. (INTECO, 2008)
Requerimientos de sistema/software
Definen las funcionalidades y características que debe tener el sistema para satisfacer tanto los requisitos de negocio como los de usuario. Van a servir como base para llevar a cabo la arquitectura, diseño y planes de pruebas del sistema. (INTECO, 2008)
Requerimiento funcional
Descripción de las actividades y los servicios que debe brindar un sistema. (Whitten et. al, 2008)
Requerimiento no funcional
Propiedad o cualidad que debe tener el sistema. Ejemplos: incluye seguridad, facilidad de uso, rendimiento, etc. (Whitten et. al, 2008)
Restricción Un enunciado que expresa límites medibles para un elemento o función del sistema. Esto es, una restricción es un factor impuesto a la solución que puede limitar o modificar el diseño. (IEEE Std 1233-1998).
Supuesto Factor externo que implica riesgos. (Ortegón et al., 2005)
Usuario final La persona o personas quienes al final usarán el sistema para el propósito deseado. (IEEE Std 1233-1998).
Validación El proceso de evaluar un sistema o componente del sistema durante o al final del proceso de desarrollo, para determinar si el sistema o componente satisface los requerimientos especificados. (IEEE Std 1233-1998).
Verificación El proceso de evaluación de un sistema o componente para determinar si el sistema de una fase de desarrollo determinada satisface las condiciones impuestas al principio de esa fase. (IEEE Std 1233-1998).
Tabla 16. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Conceptos de la metodología. 4.3.1.2. Objetivo de la metodología
El objetivo de la metodología es apoyar el proceso de elicitación de
requerimientos de software, en las actividades de identificación de
involucrados y participantes del proyecto, entendimiento y diagnóstico del
problema, análisis de alcance y objetivos, identificación de requerimientos de
software y administración, basándose en el modelo del marco lógico.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
112
4.3.1.3. Actividades de la metodología
La metodología para la elicitación de requerimientos de software basada en
el modelo de marco lógico, se compone de nueve actividades como se listan en
la tabla 17.
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO
Actividades de la metodología
Numero Actividad Actividad 1. Obtención de la información inicial Actividad 2. Análisis de involucrados e identificación de participantes en el proyecto. Actividad 3. Identificación y análisis del problema Actividad 4. Análisis de Objetivos de mejora del sistema Actividad 5. Análisis de Acciones de mejora del sistema. Actividad 6. Identificación/revisión de los objetivos del sistema a desarrollar. Actividad 7. Identificación/revisión de los requerimientos del sistema. Actividad 8. Diseño de la Estructura analítica del proyecto. Actividad 9. Administración de la estructura del proyecto.
Tabla 17. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Actividades de la metodología
Y su estructura se muestra en la figura 28.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
113
Figura 28. Metodología para la elicitación de requerimientos de software basada en el marco lógico: Estructura de la metodología.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
114
A continuación se describen cada una de las actividades de la metodología.
Actividad 1. Obtención de la información inicial. Consiste en obtener información inicial del sistema actual, dominio del
problema en el que existen los problemas a solucionar. Las fuentes de
información para el desarrollo de esta actividad son los propietarios del sistema
y cualquier documentación del sistema actual, que por lo general existe en
algún repositorio o en algunos casos simplemente no existe. En el caso de
existir la documentación hay que tener en cuenta si los documentos son
actuales u obsoletos.
En esta actividad obtenernos una información inicial del dominio del
problema, identificando el vocabulario y las funciones generales. (Ver sección
4.3.1.6. Herramientas de la metodología. Plantilla: PVDP. Vocabulario del
dominio del proyecto y PFDP. Funciones del dominio del proyecto).
Actividad 2. Análisis de involucrados e identificación de participantes en el proyecto.
Se debe tener como principal factor del proyecto a los diferentes
involucrados o interesados (stakeholders) que están relacionados directa o
indirectamente con el proyecto, haciéndose importante identificarlos, agruparlos
según sus características, definir su posición, fuerza y poder con respecto al
proyecto, y analizar y definir la incorporación al proyecto. Esta actividad
contempla las siguientes actividades:
Actividad 2.1. Identificar a las personas o grupos, organizaciones, empresas
que tengan relación con el proyecto, o que se puedan beneficiar directa o
indirectamente con el proyecto en varios niveles.
Actividad 2.2. Agrupar a los involucrados identificados según sus
características comunes.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
115
Actividad 2.3. Definir la posición de los grupos de involucrados con respecto
al proyecto.
Actividad 2.4. Analizar y definir la incorporación de los involucrados al
proyecto.
A continuación se describen estas actividades:
Actividad 2.1. Identificar a las personas o grupos, organizaciones, empresas
que tengan relación con el proyecto, o que se puedan beneficiar directa o
indirectamente con el proyecto en varios niveles. Para esto se puede hacer un
esquema en donde se organizan éstos entorno al proyecto. (Ver sección
4.3.1.6. Herramientas de la metodología. EIIP. Identificación de Involucrados en
el proyecto).
Igualmente se debe de realizar una descripción o algún comentario sobre
cada involucrado identificado. (Ver sección 4.3.1.6. Herramientas de la
metodología. PIIP. Identificación de involucrados en el proyecto).
Actividad 2.2. Agrupar a los involucrados identificados según sus
características comunes. (Ver sección 4.3.1.6. Herramientas de la
metodología. Plantilla: PAICP. Agrupación de Involucrados por características
comunes en el proyecto).
Actividad 2.3. Definir la posición de los grupos de involucrados con respecto
al proyecto. Definir por cada grupo de los involucrados sus problemas
percibidos, intereses, y posible impacto del proyecto sobre los intereses y los
recursos y mandatos sobre el proyecto. (Ver sección 4.3.1.6. Herramientas de
la metodología. Plantilla: PPGIP. Posición grupos de involucrados con respecto
al proyecto).
Luego con base en el análisis anterior se define la fuerza o poder de los
involucrados frente al proyecto. Se analiza por grupos de involucrados la
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
116
expectativa y fuerza, asignando un valor numérico de 1 a 5, siendo 1 la
expectativa y fuerza más baja y 5 la expectativa y fuerza más alta. La
resultante es la multiplicación de estos dos valores. (Ver sección 4.3.1.6.
Herramientas de la metodología. Plantilla: PEFGIP. Expectativa y fuerza del
grupo de involucrados en el proyecto).
Con esta información se analiza y se clasifica en beneficiarios directos,
beneficiarios indirectos, excluidos/neutrales y perjudicados/oponentes
potenciales con respecto al proyecto. (Ver sección 4.3.1.6. Herramientas de la
metodología. Plantilla: PCGIP. Clasificación grupos de involucrados con
respecto al proyecto)
Actividad 2.4. Analizar y definir la incorporación de los involucrados al
proyecto. Se interpretan los resultados de la posición de los grupos de
involucrados, se analiza la importancia y el involucramiento de estos grupos
con el proyecto, asignándoles un valor de 1 a 5, donde 1 es el grado menor y 5
es el grado mayor, y se define qué grupos serán incorporados para participar
en el proceso de elicitación de requerimientos del proyecto. (Ver sección
4.3.1.6. Herramientas de la metodología. Plantilla: PAIGIP. Análisis
incorporación grupos involucrados al proyecto).
Actividad 3. Identificación y análisis del problema. En la sesión con usuarios del sistema, propietario del sistema y analista, se
identifican los problemas existentes, se determina el problema más importante,
se ordena el resto de problemas en causas y efectos en función al problema
central, se elabora los esquemas de causas y efecto, y de objetivos, se revisa
el árbol de objetivos y se hacen los ajustes necesarios. Con este análisis se
responde a la pregunta del por qué ocurre el problema principal. Contempla las
siguientes actividades:
Actividad 3.1. Definir el problema central.
Actividad 3.2. Elaborar el árbol de efectos del problema.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
117
Actividad 3.3. Elaborar el árbol de causas del problema.
Actividad 3.4. Elaborar/revisar el árbol de problemas.
Actividad 3.5. Elaborar la Matriz de problemas.
A continuación se describen estas actividades:
Actividad 3.1. Definir el problema central. Analizar y realizar un listado de lo
que se considere como problemas, seleccionar el problema central y formularlo
como estado negativo, y entorno a éste se analizarán las causas y efectos.
(Ver sección 4.3.1.6. Herramientas de la metodología. Plantilla: PLP. Listado de
Problemas).
Actividad 3.2. Elaborar el árbol de efectos del problema. Definir, analizar y
verificar los efectos más relevantes del problema central. Estos efectos pueden
estar encadenados a otros efectos en un orden causal ascendente. (Ver
sección 4.3.1.6. Herramientas de la metodología. Esquema: EAEP. Árbol de
efectos del problema).
Actividad 3.3. Elaborar de árbol de causas del problema. Identificar las
causas que puedan originar el problema central. Estas causas pueden estar
encadenadas a otras causas en un orden ascendente con respecto al problema
a tratar. (Ver sección 4.3.1.6. Herramientas de la metodología. Esquema:
EACP. Árbol de causas del problema).
Actividad 3.4. Elaborar/revisar el árbol de problemas. Integrar el árbol de
efectos y el árbol de causas en un solo gráfico, como resumen de la situación
del problema analizado. (Ver sección 4.3.1.6. Herramientas de la metodología.
Esquema: EAP. Árbol de problemas).
Se revisar la validez e integridad del árbol dibujado las veces que sea
necesario.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
118
Actividad 3.5. Elaborar la Matriz de problemas. Basado en el árbol de
problemas se elabora la matriz de problemas, que contiene el problema central,
las causas y los efectos identificados. (Ver sección 4.3.1.6. Herramientas de la
metodología. Plantilla: PMP. Matriz de problemas).
Actividad 4. Análisis de objetivos de mejora del sistema. Con base en el árbol de problemas, se elabora el árbol de objetivos y la
matriz de objetivos. Contiene las siguientes actividades:
Actividad 4.1. Elaborar/revisar el árbol de objetivos.
Actividad 4.2. Elaborar la Matriz de objetivos.
A continuación se describen estas actividades:
Actividad 4.1. Elaborar/revisar el árbol de objetivos. Se cambia todas las
condiciones negativas del árbol de problemas a condiciones positivas
deseadas y viables. El problema central se transforma en objetivo central o
propósito del proyecto, las causas se transforman en medios, los efectos se
transforman en fines. (Ver sección 4.3.1.6. Herramientas de la metodología.
Esquema: EAO. Árbol de Objetivos).
Es necesario revisar las relaciones de medios y fines del árbol para
garantizar la validez e integridad del esquema, modificando las formulaciones
incorrectas y agregando o eliminando objetivos si es necesario.
Actividad 4.2. Elaborar la Matriz de objetivos. Basado en el árbol de
objetivos se elabora la matriz de objetivos de mejora del sistema, que contiene
el objetivo central del sistema, los medios y los fines analizados. (Ver sección
4.3.1.6. Herramientas de la metodología. Plantilla: PMO. Matriz de Objetivos).
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
119
Actividad 5. Análisis de Acciones de mejora del sistema.
En esta actividad se identifican y revisan las acciones que son necesarias
para desarrollar los medios identificados en el árbol de objetivos. Contiene las
siguientes actividades:
Actividad 5.1 Identificar/revisar las acciones.
Actividad 5.2. Elaborar la matriz de acciones.
A continuación se describen estas actividades:
Actividad 5.1 Identificar/revisar las acciones. Se definen acciones concretas
por cada medio principal que genera a otros medios del árbol de objetivos
(último nivel del árbol de objetivos). (Ver sección 4.3.1.6. Herramientas de la
metodología. Esquema: EAA. Árbol de Acciones).
Actividad 5.2. Elaborar la matriz de acciones. Con base en el árbol de
acciones, se elabora la matriz de acciones. (Ver sección 4.3.1.6. Herramientas
de la metodología. Plantilla: PMA. Matriz de Acciones).
Actividad 6. Identificación/revisión de los objetivos del sistema a
desarrollar.
Con base en la matriz de objetivos, árbol de acciones y matriz de acciones,
se identifican los objetivos del sistema de software a desarrollar. Se identifican
el objetivo general y los objetivos específicos, señalando ciertos elementos de
cada uno como son: una descripción, objetivos asociados, grupo de
involucrados, stakeholders, restricción, importancia, urgencia y comentarios.
(Ver sección 4.3.1.6. Herramientas de la metodología. Plantilla: POS. Objetivos
del sistema).
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
120
Actividad 7. Identificación/revisión de los requerimientos del sistema.
En esta etapa se identifican los requerimientos del nuevo sistema con base
en la matriz de objetivos del sistema, se identifican y describen los
requerimientos funcionales y no funcionales del sistema de software a
desarrollar. Se realiza una verificación de estos requerimientos.
Se aconseja que la redacción de los requerimientos identificados se haga en
un lenguaje natural, que sea entendido por todas las partes. Y se recomienda
para su redacción lo siguiente:
La forma más usual es utilizar frases cortas, las cuales comienzan por: el
sistema permitirá…., o el sistema deberá…., y sus variantes.
Contiene las siguientes actividades:
Actividad 7.1. Identificar/Revisar los requerimientos funcionales del sistema.
Actividad 7.2. Identificar/Revisar los requerimientos no funcionales del
sistema.
A continuación se describen estas actividades:
Actividad 7.1. Identificar/Revisar los requerimientos funcionales del sistema.
Se identifican los requerimientos funcionales del sistema a desarrollar y se
describen ciertos elementos como: una descripción, objetivos asociados,
requerimientos asociados, grupo de involucrados, stakeholders, restricción,
importancia, urgencia y comentarios. (Ver sección 4.3.1.6. Herramientas de la
metodología. Plantilla: PRFS. Requerimientos Funcionales del sistema).
Actividad 7.2. Identificar/Revisar los requerimientos no funcionales del
sistema. Se identifican los requerimientos no funcionales del sistema a
desarrollar que estén relacionados con seguridad, facilidad de uso,
rendimiento, entorno de explotación técnico, entre otros, y se describen ciertos
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
121
elementos como: una descripción, objetivos asociados, requerimientos
asociados, grupo de involucrados, stakeholders, restricción, importancia,
urgencia y comentarios. (Ver sección 4.3.1.6. Herramientas de la metodología.
Plantilla: PRNFS. Requerimientos no funcionales del sistema).
Actividad 8. Diseño de la Estructura analítica del proyecto. En esta actividad se diagrama el árbol de la estructura analítica del proyecto
y se elabora la matriz de esta estructura, con base en el Árbol de problema,
Objetivos del sistema, y Requerimientos Funcionales del sistema. Contiene las
siguientes actividades:
Actividad 8.1. Diagramar el árbol de la estructura analítica del proyecto
Actividad 8.2. Elaborar la Matriz de la Estructura analítica del proyecto.
A continuación se describen estás actividades:
Actividad 8.1 Diagramar el árbol de la estructura analítica del proyecto. Se
diagrama el árbol de la estructura con seis niveles jerárquicos: fin, objetivo
general o propósito, objetivos específicos, requerimientos funcionales del
sistema, componentes o productos y actividades. El fin se toma del árbol de
objetivos, el objetivo general o propósito y objetivos específicos se toman de la
plantilla de objetivos del sistema, los requerimientos funcionales del sistema se
toman de la plantilla de requerimientos funcionales del sistema, los
componentes o productos se analizan e identifican con base en la descripción
de los requerimientos funcionales del sistema. (Ver sección 4.3.1.6.
Herramientas de la metodología. Esquema: EEAP. Estructura analítica del
proyecto).
Actividad 8.2. Elaborar la Matriz de la Estructura analítica del proyecto. Con
base en el árbol de estructura analítica del proyecto, se elabora la matriz de la
estructura indicando el fin o meta, objetivo general o propósito, objetivos
específicos del sistema, requerimientos funcionales del sistema,
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
122
componente/producto y actividades. (Ver sección 4.3.1.6. Herramientas de la
metodología. Plantilla: PMEAP. Matriz Estructura Analítica del proyecto).
Actividad 9. Administración de la estructura del proyecto.
Es necesario administrar la estructura del proyecto y para esto se elabora la
Matriz de Administración de la estructura del proyecto. Contiene las siguientes
actividades:
Actividad 9.1. Elaborar la Matriz de Administración de la estructura del
proyecto.
Actividad 9.2. Revisar la Matriz de Administración de la estructura del
proyecto.
A continuación se describen estás actividades:
Actividad 9.1. Elaborar la Matriz de Administración de la estructura del
proyecto. Se presenta en forma consolidada en una matriz la estructura de los
elementos relevantes elicitados y analizados para el desarrollo del proyecto.
Estos elementos son: fin, objetivo general o propósito, objetivos específicos,
requerimientos funcionales del sistema, componentes o productos y
actividades, indicadores verificables de la actividad, fuentes de verificación de
la actividad y supuestos de la actividad.
El fin, objetivo general o propósito, objetivos específicos, requerimientos
funcionales del sistema, componentes o productos y actividades, son tomados
de la Matriz de la Estructura analítica del proyecto.
Por cada actividad identificada se plantean indicadores verificables de la
actividad, fuentes de verificación de la actividad y supuestos de la actividad.
(Ver sección 4.3.1.6. Herramientas de la metodología. Plantilla: PMAEP. Matriz
Administración Estructura del proyecto).
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
123
Los indicadores a nivel de actividades, corresponden a los recursos o
insumos y presupuesto o costos necesarios para desarrollar cada actividad.
Las fuentes de Verificación de la actividad, indican los métodos y fuentes de
recolección de información para evaluar y monitorear los indicadores
planteados.
Los supuestos de la actividad, corresponden a factores externos directos
que pueden influir en el cumplimiento de la actividad, estos factores externos
son: acontecimientos, condiciones o decisiones, que tienen que ocurrir para
que se desarrolle la actividad. También pueden ser riesgos a los que se
expone el proyecto y pueden ser ambientales, financieros, institucionales,
sociales, políticos, climatológicos u otros. El supuesto se debe cumplir para
avanzar con el desarrollo de las actividades y cumplimiento de los objetivos. Se
deben de redactar en forma afirmativa positiva.
Para el inicio del desarrollo del proyecto deben de existir unas condiciones
previas, y se catalogan en la parte inferior en la columna de supuestos de la
actividad, dando inicio al desarrollo del proyecto.
Actividad 9.2. Revisar la Matriz de Administración de la estructura del
proyecto. Se debe realizar una revisión de la construcción de la Matriz
Administración Estructura del proyecto a nivel lógico y coherencia entre los
elementos de la matriz. De igual forma se revisa que estén bien planteados los
indicadores, fuentes de verificación y supuestos de las actividades. (Ver
sección 4.3.1.6. Herramientas de la metodología. Plantilla: PRMAEP. Revisión
Matriz de Administración de la estructura del proyecto.).
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
124
4.3.1.4. Productos elicitados con la metodología propuesta.
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN MARCO LOGICO
Productos vs. Actividades de la metodología No. PRODUCTOS DE LA
METODOLOGIA (Conceptos elicitados)
ACTIVIDADES
Act.1 Act.2 Act.3 Act.4 Act.5 Act.6 Act.7 Act.8 Act. 9 1 Información inicial √
2 Involucrados y participantes en el proyecto. √
3 Problema del dominio √ 4 Objetivos de mejora del sistema √ 5 Acciones de mejora del sistema. √ 6 Objetivos del sistema a desarrollar. √ 7 Requerimientos del sistema. √ 8 Estructura analítica del proyecto. √ 9 Administración de la estructura del
proyecto. √
Tabla 18. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Productos vs. Actividades de la metodología.
4.3.1.5. Técnicas de la metodología
4.3.1.5.1. Técnicas de la metodología vs Actividades de la metodología propuesta.
En la siguiente tabla se citan las técnicas de la metodología, y su empleo
según cada una de las actividades de la metodología propuesta.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
125
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN MARCO LOGICO
Técnicas vs. Actividades de la metodología
TECNICAS DE LA METODOLOGIA ACTIVIDADES Act.1 Act.2 Act.3 Act.4 Act.5 Act.6 Act.7 Act.8 Act. 9
Técnicas de elicitación Exploración de documentación existente √ √ √ √ √ Entrevistas √ √ Técnica de grupos nominales. √ √ √ Técnica Delphi. √ √ √ Método EASW (European Awareness Sustainability Workshop) √ √ √
Núcleos de intervención participativa. √ √ √ Lluvia de ideas √ √ √
Tabla 19. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Técnicas vs. Actividades de la metodología.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
126
4.3.1.5.2. Técnicas de elicitación.
Como técnicas de elicitación de requerimientos con los involucrados
tenemos las siguientes, las cuales se aplican como se indica en la tabla
anterior. En cuanto a las técnicas que corresponden a participación grupal se
pueden escoger entre las citadas y aplicar según conveniencia y dominio del
organizador de la actividad.
• Entrevistas.
• Exploración de documentación existente
• Técnica de grupos nominales.
• Técnica Delphi.
• Método EASW (European Awareness Sustainability Workshop).
• Núcleos de intervención participativa.
• Lluvia de ideas.
A continuación se describen las técnicas citadas, cabe a notar que esta
descripción se hace en forma general citando sus actividades principales.
• Entrevistas. Whitten et. al. (2008) explica que consiste en interacciones
cara a cara, y pueden usarse para los objetivos de: indagar hechos,
verificar hechos, aclarar hechos, generar entusiasmo, hacer que se
involucre el usuario final, identificar los requerimientos y solicitar ideas y
opiniones. Existen dos papeles identificados en la entrevista, el analista
de sistemas como el entrevistador responsable de la organización y la
conducción de la entrevista, y el usuario del sistema o el propietario del
sistema es el entrevistado, quien responderán las preguntas. Pueden
uno o más entrevistadores, entrevistados o ambos.
Hay dos tipos de entrevistas, las no estructuradas y las estructuradas. Las
entrevistas no estructuradas se caracterizan por contener preguntas generales
que permiten al entrevistado dirigir la conversación. Las entrevistas
estructuradas consisten en que el entrevistador realiza preguntas específicas
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
127
diseñadas para obtener información específica, se pueden hacer preguntas
adicionales para una aclaración o ampliación del tema.
Para realizar las entrevistas se debe de realizar las siguientes actividades:
• Seleccionar a los entrevistados
• Preparar un guion de entrevista
• Preparar la agenda: fecha, Hora, lugar, tiempo estimado para la
entrevista.
La mayoría de preguntas inician con las preguntas que, cuando, donde,
porque y cuanto. Deben evitarse preguntas cargadas, con intensión, sesgadas,
amenazantes, criticas. Se debe usar un lenguaje claro y conciso, no incluir
una opinión como parte de la pregunta, preguntas largas o complejas.
En una entrevista debe de haber una conducción, seguimiento y tener en
cuenta el lenguaje corporal y la proxemia entre las personas y su espacio
alrededor.
• Exploración de documentación existente. Whitten et. al. (2008),
indican que mediante la consulta de la documentación, formatos y
archivos existentes se desarrolla una buena percepción del sistema.
Con el organigrama se puede identificar a los propietarios y usuarios del
sistema. Igualmente se pueden revisar documentos que describan el
problema que originó el proyecto, y documentos que describan la
función del negocio, como también documentos de estudios de diseño
de sistemas anteriores.
Toda la documentación recolectada se debe de analizar para determinar si
está actualizada, pero tampoco la descartar la documentación obsoleta.
Los elementos que pueden seleccionarse de estos documentos son:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
128
- Síntomas o posibles causas del problema
- Personas de la organización que entienden el problema
- Funciones de negocio que soportan el sistema
- Tipo de datos que el sistema debe recolectar y reportar
- Elementos que no se entienden y que se deben cubrir en entrevistas.
• Técnicas de grupos nominales. Según lo describe Gutiérrez (2001).
Sirven para identificar, cuantificar y resolver temas o problemas,
haciendo posible captar ideas creativas, enfocan la atención hacia los
temas y no hacia las personas, facilitan la comunicación entre personas
con distintas formas de pensar, ayudan en la creación de equipos de
trabajo facilitando la interacción y participación de las personas. Se
compone de seis etapas:
Primera etapa. Clarificación del enunciado de un propósito. El grupo
desarrolla un enunciado y se enfoca a un problema o tema, comprendido por
todos.
Segunda etapa. Generación del mayor número posible de ideas. El grupo
permanece en silencio, para generar ideas con respecto al enunciado.
Tercera etapa. Expresión de ideas. Un facilitador pone por escrito las ideas
expuestas por los participantes.
Cuarta etapa. Reducción de ideas. Eliminación de ideas redundantes o
combinación de ideas, formando enunciados más ricos de contenido.
Quinta etapa. Identificación de enunciados más relacionados al problema.
Mediante el sistema de voto se identifican los enunciados que están más
directamente relacionados con el problema y se ordenan por prioridades.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
129
Sexta etapa. Organización de resultados en un diagrama y elaboración de
un plan de acción. Este debe incluir datos, asignación de responsabilidades, el
tiempo estimado para realizar las tareas encomendadas y la fecha para la
próxima reunión de grupo.
• Técnica Delphi. (Astigarraga) indica que se basa en la utilización
sistemática de un juicio intuitivo emitido por un grupo de expertos. Se
interrogan a expertos por medio de cuestionarios sucesivos, con el
objetivo de obtener convergencia de opiniones y deducir eventuales
consensos.
La encuesta se lleva a cabo de una manera anónima (actualmente es
habitual realizarla haciendo uso del correo electrónico o mediante cuestionarios
web establecidos al efecto) para evitar los efectos de "líderes".
Las preguntas se orientan, por ejemplo, a las probabilidades de realización
de hipótesis o de acontecimientos con relación al tema de estudio. La calidad
de los resultados depende, sobre todo, del cuidado que se ponga en la
elaboración del cuestionario y en la elección de los expertos consultados.
Contiene las siguientes fases:
Fase 1. Formulación del problema. Se define el campo de investigación y se
debe estar seguro que los expertos reclutados y consultados poseen la misma
noción de área de estudio.
Fase 2. Elección de expertos. El experto es elegido por su capacidad de
encarar el futuro y poseer conocimientos sobre el tema consultado. Los
expertos son aislados y sus opiniones son recogidas por vía postal o
electrónica y de forma anónima; así pues se obtiene la opinión real de cada
experto y no la opinión más o menos falseada por un proceso de grupo.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
130
Fase 3: Elaboración y lanzamiento de los cuestionarios (en paralelo con la
fase 2). Los cuestionarios se desarrollan de manera que faciliten respuestas
por parte de las personas consultadas. Las respuestas deben ser cuantificadas
y ponderadas, se formularán preguntas con grados de ocurrencia (probabilidad)
y de importancia (prioridad), fecha de realización de determinados eventos
relacionadas con el objeto de estudio necesidades de información del entorno,
gestión de la información del entorno, evolución de los sistemas, evolución en
los costes, transformaciones en tareas, necesidad de formación, etc.
Fase 4: Desarrollo práctico y explotación de resultados. El cuestionario se
envía a un número de expertos (hay que tener en cuenta las no-respuestas y
abandonos. Se recomienda que el grupo final no sea inferior a 25). El
cuestionario va acompañado por una nota de presentación que precisa las
finalidades, así como las condiciones prácticas del desarrollo del cuestionario.
Los cuestionarios sucesivos disminuyen la dispersión de las opiniones y
precisión de la opinión media consensuada.
Para la segunda consulta, se informa los resultados de la primera consulta a
los expertos solicitando una nueva respuesta o justificarla en el caso que sea
altamente divergente del resto del grupo.
En la tercera consulta, si es necesario se solicita a cada experto argumentar
sus respuestas si divergen de la mayoría.
En la cuarta consulta, se consensua la respuesta definitiva.
• Método EASW (European Awareness Sustainability Workshop). Villasante, Montañés y Martín (2001), indican que el objetivo principal de
este método es el de consensuar entre los participantes las propuestas
del futuro más deseables y sostenibles.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
131
Lo primero es hacer la convocatoria de las personas, entidades o
instituciones que puedan ser pertinentes para participar en las sesiones de
trabajo.
Una vez reunidos los actores convocados, la sesión de trabajo puede
comenzar con algún elemento dinamizador que introduzca al objeto del debate,
por ejemplo un video.
Este método se compone de las siguientes fases:
Fase 1. Reunir los asistentes por grupos homogéneos y plantear que
elaboren dos escenarios futuros posibles para la comunidad en función del
objeto del debate (un escenario positivo y otro negativo). Cada grupo estará
coordinado por un monitor el que se encargará de redactar, las propuestas
respectivas. Cada grupo expone sus conclusiones en una sesión plenaria por
medio de un portavoz.
Fase 2. Agrupar a los asistentes ya no por grupos homogéneos sino por el
interés de las personas por temas concretos dentro del objeto del debate,
formándose grupos heterogéneos donde pueden aparecer políticos, técnicos,
ciudadanos, empresarios, etc. La dinámica para el desarrollo de la sesión de
trabajo es la misma que en la primera fase en la que se debate sobre
escenarios futuros (uno positivo y otro negativo), con un monitor y un portavoz
de cada grupo que expone las conclusiones.
Fase 3. Se realiza la votación de asamblearia se establecen los rangos de
prioridad para las acciones expuestas, en mejora del escenario futuro del
objeto de estudio.
Lo que pretende este método es la captación de propuestas concretas, el
debate, la priorización y la toma de decisiones en orden de importancia para los
asistentes, forzando la motivación de los mismos y obtener resultados
prontamente.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
132
• Núcleos de intervención participativa (NIP). Bustos (2005) describe
que tiene como finalidad estudiar, deliberar y resolver un dictamen sobre
un asunto polémico o difícil que afecta al sistema actual.
Consiste en la convocatoria de unos 25 escogidos al azar, que durante 3-5
días se reúnen en pequeños grupos de forma intensiva para debatir sobre un
tema dado. En esos días, se facilitan los medios (permisos de trabajo,
remuneración, etc.) y las condiciones (visitas sobre el terreno, formación por
parte de técnicos, expertos y grupos de interés, etc.) para que puedan debatir y
conocer con fundamento las distintas opciones que existen para un asunto
determinado. Este grupo que actúa como un "jurado", al finalizar el trabajo
elabora un "dictamen" que acaba siendo público, aunque no vinculante para la
entidad que lo promueve.
• Lluvia de ideas. Whitten et. al. (2008) describe que es una técnica
formal que requiere disciplina y consiste en motivar a los participantes a
generar ideas, sin analizar la validez de las mismas. Y debe seguir los
siguiente lineamientos:
- Aislar a las personas en un lugar libre de interrupciones y distracciones.
- De que todas las personas entiendan el propósito de la reunión
(generación de ideas para resolver el problema y centrarse en los
problemas).
- Asignar a una persona para registrar las ideas.
- Seguir las reglas de la lluvia de ideas: ser espontáneo, no permitir
críticas, análisis o evaluación, mientras que las ideas se están
generando. La meta es la cantidad de ideas, no calidad.
- Dentro de un tiempo específico, expresar las ideas como se piensan.
- Luego de la generación y el registro de ideas, deben ser analizadas y
evaluadas.
- Refinar, combinar y amplificar las ideas generadas.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
133
4.3.1.6. Herramientas de la metodología
A continuación se describen las herramientas de la metodología propuesta
para la elicitación de requerimientos de software basada en el marco lógico.
Estas herramientas están compuestas por plantillas y esquemas.
4.3.1.6.1. Herramientas metodología vs Actividades de la metodología propuesta
En la siguiente tabla se citan las herramientas de la metodología,
clasificadas en plantillas y esquemas, y su empleo según cada una de las
actividades de la metodología propuesta.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
134
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN MARCO LOGICO
Herramientas vs. Actividades de la metodología
HERRAMIENTAS DE LA METODOLOGIA ACTIVIDADES Act.1 Act.2 Act.3 Act.4 Act.5 Act.6 Act.7 Act.8 Act. 9
PLANTILLAS Sigla Nombre
PVDP Vocabulario del dominio del proyecto √ PFDP Funciones del dominio del proyecto √ PIIP Identificación de involucrados en el proyecto √ PAIC Agrupación de Involucrados por características comunes √ PPGIP Posición grupos de involucrados con respecto al proyecto √ PEFGIP Expectativa y fuerza del grupo de involucrados en el proyecto √ PCGIP Clasificación grupos de involucrados con respecto al proyecto √ PAIGIP Análisis incorporación grupos involucrados al proyecto √ PLP Listado de Problemas √ PMP Matriz de Problemas √ PMO Matriz de Objetivos √ PMA Matriz de Acciones √ POS Objetivos del sistema √ PRFS Requerimientos Funcionales del sistema √ PRNFS Requerimientos no funcionales del sistema √ PMEAP Matriz Estructura Analítica del proyecto √ PMAEP Matriz Administración Estructura del proyecto √ PRMAEP Revisión Matriz de Administración de la estructura del proyecto. √
ESQUEMAS EIIP Identificación de Involucrados en el proyecto √ EAE Árbol de Efectos √ EAC Árbol de Causas √ EAP Árbol de problemas √ EAO Árbol de Objetivos √ EAA Árbol de Acciones √ EEAP Estructura analítica del proyecto √
Tabla 20. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Herramientas vs. Actividades de la
metodología.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
135
4.3.1.6.2. Plantillas
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PVDP. Vocabulario del dominio del proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación: No. Término Descripción
Descripción
Plantilla: PVDP. Vocabulario del dominio del proyecto Ítem Descripción No Número Consecutivo Término Nombre del término Descripción Descripción del término
Tabla 21. Tabla. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PVDP. Vocabulario del dominio del proyecto
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PFDP. Funciones del dominio del proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación: No. Funciones Descripción
Descripción
Plantilla: PFDP. Funciones del dominio del proyecto Ítem Descripción No Número Consecutivo Funciones Nombre de la función Descripción Descripción de la función
Tabla 22. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PFDP. Funciones del dominio del proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
136
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PIIP. Identificación de involucrados en el proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
No. Involucrados Descripción Comentarios
Descripción
Plantilla: PIIP. Identificación de involucrados en el proyecto Ítem Descripción No Número Consecutivo Involucrados Nombre de los involucrados identificados, que se relacionan con el proyecto. Descripción Descripción de los involucrados identificados Comentarios Comentarios o aclaraciones con respecto a cada involucrado. (Si los hay).
Tabla 23. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PII. Identificación de involucrados en el
proyecto
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PAIC. Agrupación de Involucrados por características comunes Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
No. Grupo de involucrados Involucrados Características
Descripción
Plantilla: PAIC. Agrupación de Involucrados por características comunes Ítem Descripción No. Número Consecutivo Grupo de involucrados
Nombre del grupo de involucrados
Involucrados Nombre de los involucrados identificados, que se relacionan con el proyecto. Características Características del grupo de involucrados por la cual se realizó la agrupación
Tabla 24. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PAIC. Agrupación de Involucrados por características comunes
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
137
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PPGIP. Posición grupos de involucrados con respecto al proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
No. Grupo de involucrados Problemas percibidos Intereses
Posible impacto del
proyecto sobre los intereses (+,-,=,?)
Recursos y Mandatos
Descripción
Plantilla: PPGIP. Posición grupos de involucrados con respecto al proyecto Ítem Descripción No. Número Consecutivo Grupo de involucrados
Nombre del grupo de involucrados
Problemas percibidos
Condiciones negativas que percibe cada grupo en relación con el problema identificado.
Intereses Deben estar relacionados directamente con el problema de desarrollo identificado, también pueden incluir posibles soluciones sugeridas por el grupo.
Posible impacto del proyecto sobre los intereses (+,-,=,?)
Se indica por medio de símbolos (+,-,=,?) el impacto que tiene el proyecto a desarrollar sobre los intereses del grupo de involucrados. Se puede utilizar más de un símbolo.
Recursos y Mandatos
Recursos (R): Aportes detallados de recursos de cada grupo, pueden ser financieros (presupuesto) y no financieros (recursos humanos, influencias, tecnología, contactos, etc.). Mandatos (M): Autoridad formal en la proporción de un servicio o cumplir una función. Se soporta en documentos como son: estatutos, leyes, normas, etc.
Tabla 25. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Plantilla: PPGIP. Posición grupos de involucrados con respecto al proyecto
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PEFGIP. Expectativa y fuerza del grupo de involucrados en el proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
No. Grupo de involucrados Expectativa Fuerza Resultante
Descripción
Plantilla: PEFGIP. Expectativa y fuerza del grupo de involucrados en el proyecto Ítem Descripción No. Número Consecutivo Grupo de involucrados
Nombre del grupo de involucrados
Expectativa Valor numérico de 1 a 5, dependiendo del grado de expectativa Fuerza Valor numérico de 1 a 5, dependiendo del grado de fuerza Resultante Resultado de la multiplicación de la expectativa por la fuerza.
Tabla 26. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PEFGIP. Expectativa y fuerza del grupo de involucrados en el
proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
138
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PCGIP. Clasificación grupos de involucrados con respecto al proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
No. Grupo de involucrados Beneficiarios directos
Beneficiarios Indirectos
Excluidos/ Neutrales
Perjudicados/ Oponentes potenciales
Descripción
Plantilla: PCGIP. Clasificación grupos de involucrados con respecto al proyecto Ítem Descripción
No. Número Consecutivo. Grupo de involucrados
Nombre del grupo de involucrados.
Beneficiarios Directos
Grupos de involucrados que se beneficiarán directamente de los resultados del proyecto. Se indica con (√) si pertenece a esta clasificación el grupo de involucrados.
Beneficiarios Indirectos
Grupos de involucrados que se beneficiarán indirectamente de los resultados del proyecto. Se indica con (√) si pertenece a esta clasificación el grupo de involucrados.
Excluidos/ Neutrales
Grupos de involucrados en los cuales ajenos del proyecto y/o que tienen una posición neutral. No tiene un gran efecto sobre ellos los resultados del proyecto. Se indica con (√) si pertenece a esta clasificación el grupo de involucrados.
Perjudicados/ Oponentes potenciales
Grupos de involucrados en los que se afecta negativamente los resultados del proyecto, y se oponen al desarrollo de éste. Se indica con (√) si pertenece a esta clasificación el grupo de involucrados
Tabla 27. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PCGIP. Clasificación grupos de involucrados con respecto al
proyecto NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PAIGIP. Análisis incorporación grupos involucrados al proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación: No. Grupo de involucrados Importancia Involucramiento Resultante
Descripción
Plantilla: PAIGIP. Análisis incorporación grupos involucrados al proyecto Ítem Descripción
No. Número Consecutivo. Grupo de involucrados
Nombre del grupo de involucrados.
Importancia Valor numérico de 1 a 5, dependiendo del grado de importancia. Involucramiento Valor numérico de 1 a 5, dependiendo del grado de involucramiento. Resultante Resultado de la multiplicación de la importancia por el involucramiento.
Tabla 28. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Plantilla: PAIGIP. Análisis incorporación grupos involucrados al proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
139
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PLP. Listado de Problemas Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
No. Listado de Problemas
No. Problema central
Descripción
Plantilla: PLP. Listado de Problemas Ítem Descripción
No. Número Consecutivo. Listado de problemas
Contiene el listado de problemas del sistema a resolver
Problema central Contiene el problema central a resolver Tabla 29. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Plantilla: PLP. Listado de Problemas
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PMP. Matriz de Problemas Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
Problema central Causas Efectos
Descripción
Plantilla: PMP. Matriz de Problemas Ítem Descripción
Problema central Problema central del sistema a resolver Causas Listado de causas que originan el problema central Efectos Listado de efectos que origina el problema central
Tabla 30. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Plantilla: PMP. Matriz de Problemas
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PMO. Matriz de Objetivos Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
Objetivo del sistema Medios Fines
Descripción
Plantilla: PMO. Matriz de Objetivos Ítem Descripción
Objetivo del sistema
Objetivo central o propósito del sistema a resolver
Medios Listado de Medios que originan el objetivo del sistema Fines Listado de Fines que origina el objetivo del sistema Tabla 31. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Plantilla: PMP. Matriz de Objetivos
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
140
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PMA. Matriz de Acciones Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación: No. Medios Acciones
Descripción
Plantilla: PMA. Matriz de Acciones Ítem Descripción
No. Número consecutivo Medios Listado de Medios que originan el objetivo del sistema Acciones Listado de Acciones que se proponen para cumplir el medio
Tabla 32. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMA. Matriz de Acciones.
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: POS. Objetivos del sistema Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
OG-<id> OE-<id>
Descripción Objetivos asociados Grupo de involucrados Stakeholders Restricción Importancia Urgencia Comentarios
Descripción
Plantilla: POS. Objetivos del sistema Ítem Descripción
Identificación del objetivo
Numero identificador y Nombre del objetivo y, puede ser objetivo general, u objetivo especifico.
Descripción Descripción del objetivo Objetivos asociados
Objetivos asociados a objetivo
Grupo de involucrados
Grupo de involucrados con el objetivos
Stakeholders Grupo de interesados con el objetivos Restricción Limitaciones del objetivo Importancia Nivel de importancia del objetivo (alta, media, baja) Urgencia Nivel de urgencia del objetivo (alta, media, baja) Comentarios Comentarios relacionados con el objetivo
Tabla 33. Metodología para la elicitación de requerimientos de software basada en el
marco lógico. Plantilla: POS. Objetivos del Sistema.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
141
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PRFS. Requerimientos Funcionales del sistema Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
RFS-<id> Descripción Objetivos asociados Requerimientos asociados
Grupo de involucrados Stakeholders Restricción Importancia Urgencia Comentarios
Descripción
Plantilla: PRFS. Requerimientos Funcionales del sistema Ítem Descripción
Identificación del requerimiento funcional
Numero identificador y Nombre del requerimiento funcional
Descripción Descripción del requerimiento funcional Objetivos asociados
Objetivos asociados a requerimiento funcional
Requerimientos asociados
Requerimientos asociados al requerimiento funcional
Grupo de involucrados
Grupo de involucrados con el requerimiento funcional
Stakeholders Grupo de interesados con el requerimiento funcional Restricción Limitaciones del requerimiento funcional Importancia Nivel de importancia del requerimiento funcional (alta, media, baja) Urgencia Nivel de urgencia del requerimiento funcional (alta, media, baja) Comentarios Comentarios relacionados con el requerimiento funcional
Tabla 34. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRFS. Requerimientos Funcionales del sistema
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
142
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PRNFS. Requerimientos no funcionales del sistema Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
RNF-<id> Descripción Objetivos asociados Requerimientos asociados
Grupo de involucrados Stakeholders Restricción Importancia Urgencia Comentarios
Descripción
Plantilla: PRNFS. Requerimientos no funcionales del sistema Ítem Descripción
Identificación del requerimiento funcional
Numero identificador y Nombre del requerimiento funcional
Descripción Descripción del requerimiento funcional Objetivos asociados
Objetivos asociados a requerimiento funcional
Requerimientos asociados
Requerimientos asociados al requerimiento funcional
Grupo de involucrados
Grupo de involucrados con el requerimiento funcional
Stakeholders Grupo de interesados con el requerimiento funcional Restricción Limitaciones del requerimiento funcional Importancia Nivel de importancia del requerimiento funcional (alta, media, baja) Urgencia Nivel de urgencia del requerimiento funcional (alta, media, baja) Comentarios Comentarios relacionados con el requerimiento funcional
Tabla 35. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRNFS. Requerimientos no funcionales del sistema
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
143
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PMEAP. Matriz Estructura Analítica del proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
FIN O META OBJETIVO GENERAL
O PROPOSITO OBJETIVOS
ESPECIFICOS DEL SISTEMA REQUERIMIENTOS
FUNCIONALES DELSISTEMA COMPONENTE/ PRODUCTO ACTIVIDADES
F-01. OG-01.
OE-01.
RFS-01.
C-01. A-1.1 A-1.n.
C-02. A-2.1 A-2.n.
C-03. A-3.1 A-3.n.
RFS-02. C-04. A-4.1
A-4.n.
C-05. A-5.1 A-5.n.
OE-0n. RFS-03.
C-06. A-6.1 A-6.n.
C-07. A-7.1 A-7.n.
RFS-0n. C-0n. A-N.1 A-N.n.
Descripción
Plantilla: PMEAP. Matriz Estructura Analítica del proyecto Ítem Descripción
Fin Fin al cual el proyecto contribuye de manera significativa luego de que el proyecto ha estado en funcionamiento. Objetivo General Corresponde indicar cuál es el resultado directo del desarrollo del proyecto de software. Es la consecuencia del desarrollo de los resultados o
productos planteados. Propósito a lograr con el desarrollo del proyecto. Objetivos específicos Objetivos específicos a ser cumplidos con el desarrollo de las actividades y componentes específicos, el desarrollo de los objetivos específicos aporta
al cumplimiento del objetivo general del proyecto. Requerimientos funcionales del sistema Características funcionales que el sistema debe de contener para cumplir el objetivo especifico. Producto/ Componente Componentes /resultados completados en el transcurso de la ejecución del proyecto Actividades Corresponde a las actividades requeridas para producir los componentes/productos del proyecto de software. Las actividades deben presentarse
agrupadas por componente. Su planificación se realiza mediante un diagrama de Gantt.
Tabla 36. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMEAP. Matriz Estructura Analítica del proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
144
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PMAEP. Matriz Administración Estructura del proyecto Versión plantilla: 1.0 Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
DECLARACION DEL ALCANCE FIN: <Fin del proyecto> OBJETIVO GENERAL: <Objetivo del proyecto>
No.
OBJETIVOS ESPECIFICOS DEL
SISTEMA REQUERIMIENTOS
FUNCIONALES DELSISTEMA COMPONENTE/ PRODUCTO ACTIVIDADES
INDICADORES VERIFICABLES
DE LA ACTIVIDAD FUENTES DE
VERIFICACION DE LA ACTIVIDAD
SUPUESTOS DE LA
ACTIVIDAD
Recursos Costos
1 OE-01.
RFS-01.
C-01. A-1.1 A-1.2 A-1.n.
C-02. A-2.1 A-2.2 A-2.n.
C-03. A-3.1 A-3.2 A-3.n.
RFS-02.
C-04. A-4.1 A-4.2 A-4.n.
C-05.
A-5.1 A-5.2 A-5.n.
n OE-0n.
RFS-03.
C-06. A-6.1 A-6.2 A-6.n.
C-07. A-7.1 A-7.2 A-7.n.
RFS-0n. C-0n. A-N.1 A-N.2 A-N.n.
Condiciones Previas
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
145
Descripción
Plantilla: PMAEP. Matriz Administración Estructura del proyecto Ítem Descripción
Fin Fin al cual el proyecto contribuye de manera significativa luego de que el proyecto ha estado en funcionamiento. Objetivo General Corresponde indicar cuál es el resultado directo del desarrollo del proyecto de software. Es la consecuencia del desarrollo de los resultados o productos
planteados. Propósito a lograr con el desarrollo del proyecto. No. Número consecutivo Objetivos específicos Objetivos específicos a ser cumplidos con el desarrollo de las actividades y componentes específicos, el desarrollo de los objetivos específicos aporta al
cumplimiento del objetivo general del proyecto. Requerimientos funcionales del sistema
Características funcionales que el sistema debe de contener para cumplir el objetivo especifico.
Producto/ Componente Componentes /resultados completados en el transcurso de la ejecución del proyecto Actividades Corresponde a las actividades requeridas para producir los componentes/productos del proyecto de software. Las actividades deben presentarse agrupadas por
componente. Su planificación se realiza mediante un diagrama de Gantt. Indicadores verificables de la actividad
Corresponde a los recursos y costos necesarios para el desarrollo de la actividad, la componen los recursos y costos.
Fuentes de Verificación de la actividad
Medios de Verificación. Corresponden a las fuentes de información que se utilizarán para obtener los valores de los indicadores. Deben identificarse en la matriz por cada uno de los indicadores presentados a nivel de recursos y costos.
Supuestos de la actividad
O factores críticos. Identifican aquellas situaciones necesarias y suficientes para el desarrollo del proyecto de software, están fuera de control de la administración del mismo. Deben tener una probabilidad intermedia de que ocurran. Debe haber unas condiciones previas para el inicio del proyecto.
Tabla 37. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMAEP. Matriz Administración Estructura del proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
146
NOMBRE DEL PROYECTO: <Nombre del proyecto> Plantilla: PRMAEP. Revisión Matriz de Administración de la estructura del proyecto.
Versión plantilla: 1.0
Analista: <Nombre persona> Fecha:<Fecha elaboración> Versión en desarrollo: <Número versión>
Fuente: <Fuente de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación: No. Condiciones Si No
1 Se indican claramente el Fin(meta), el objetivo general, los objetivos específicos, los requerimientos, los productos/componentes, las Actividades, indicadores, fuentes de verificación y supuestos a nivel de actividad.
2 El fin del proyecto está claramente definido 3 Se tiene un objetivo general o propósito 4 La relación entre el fin y el objetivo general es lógica
5 Los objetivos específicos, y requerimientos y están expuestos claramente y tiene relación con el objetivo general.
6 Cada producto/componente es necesario para lograr cada requerimiento y objetivo específico del proyecto
7 No falta ninguno de los productos/componentes necesarios para lograr cada objetivo del proyecto y requerimiento
8 Las actividades específicas para cada producto/componente son necesarias para producir el componente
9 Los insumos descritos como indicadores a nivel de actividad, definen los recursos y costos requeridos.
10 La relación entre recursos y las actividades es realista
11 La columna de fuentes de verificación a nivel de actividad, señala donde encontrar información para verificar los indicadores
12 Los supuestos planteados producen condiciones necesarias para cumplir las actividades. 13 Existen unas condiciones previas para el desarrollo de proyecto
Descripción
Plantilla: PRMAEP. Revisión Matriz de Administración de la estructura del proyecto. Ítem Descripción
No. Número consecutivo Condiciones Condiciones evaluables en la revisión de la matriz de administración de la estructura del
proyecto Si Se indica con (√) si cumple con la condición de revisión No Se indica con (√) si no cumple con la condición de revisión
Tabla 38. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRMAEP. Revisión Matriz de Administración de la estructura
del proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
147
4.3.1.6.3. Esquemas
NOMBRE DEL PROYECTO: <Nombre del proyecto> Esquema: EIIP. Identificación de Involucrados en el proyecto Versión esquema: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuentes de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
Esquema 1. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EIIP. Identificación de Involucrados en el proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
148
NOMBRE DEL PROYECTO: <Nombre del proyecto> Esquema: EAE. Árbol de Efectos Versión esquema: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuentes de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
PROBLEMA CENTRAL
Efecto 1
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO
EAE. Árbol de Efectos
Efecto 2
Efecto 1.1 Efecto 1.2
Efecto 3
Esquema 2. Metodología para la elicitación de requerimientos de software basada en
el marco lógico. Esquema: EAE. Árbol de efectos NOMBRE DEL PROYECTO: <Nombre del proyecto> Esquema: EAC. Árbol de Causas Versión esquema: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuentes de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
PROBLEMA CENTRAL
Causa 1
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO
EAC. Árbol de Causas
Causa 2
Causa 2.1 Causa 2.2
Causa 3
Causa 3.1
Causa 3.1.1
Esquema 3. Metodología para la elicitación de requerimientos de software basada en
el marco lógico. Esquema: EAC. Árbol de causas
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
149
NOMBRE DEL PROYECTO: <Nombre del proyecto> Esquema: EAP. Árbol de problemas Versión esquema: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuentes de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
PROBLEMA CENTRAL
Causa 1
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO
EAP. Árbol de Problemas
Causa 2
Causa 2.1 Causa 2.2
Causa 3
Causa 3.1
Causa 3.1.1
Efecto 1 Efecto 2
Efecto 1.1 Efecto 1.2
Efecto 3
Esquema 4. Metodología para la elicitación de requerimientos de software basada en
el marco lógico. Esquema: EAP. Árbol de problemas.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
150
NOMBRE DEL PROYECTO: <Nombre del proyecto> Esquema: EAO. Árbol de Objetivos Versión esquema: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuentes de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
OBJETIVO CENTRAL
Medio 1
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO
EAO. Árbol de Objetivos
Medio 2
Medio 2.1 Medio 2.2
Medio 3
Medio 3.1
Medio 3.1.1
Fin 1 Fin 2
Fin 1.1 Fin 1.2
Fin 3
Esquema 5. Metodología para la elicitación de requerimientos de software basada en
el marco lógico. Esquema: EAO. Árbol de Objetivos NOMBRE DEL PROYECTO: <Nombre del proyecto> Esquema: EAA. Árbol de Acciones Versión esquema: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuentes de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
Medio MedioMedio
AcciónAcción Acción
Acción
Medio
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO
EAA. Árbol de Acciones
Esquema 6. Metodología para la elicitación de requerimientos de software basada en
el marco lógico. Esquema: EAA. Árbol de Acciones
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
151
NOMBRE DEL PROYECTO: <Nombre del proyecto> Esquema: EEAP. Estructura analítica del proyecto Versión esquema: 1.0 Analista: <Nombre persona> Fecha: <Fecha elaboración> Versión en desarrollo:
<Número versión> Fuente: <Fuentes de información> Técnica de elicitación: <Técnica de la metodología> Aprobó: Fecha aprobación:
OBJETIVO CENTRAL
Fin
Actividad 3.1
Requerimiento 1
Objetivo Específico 2Objetivo Específico 1
Requerimiento 2
Componente 1 Componente 2 Componente 3 Componente 4
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO.
EEAP. Estructura analítica del proyecto.
Requerimiento 3
Componente 5
Actividad 1.1 Actividad 1.2 Actividad 3.1 Actividad 3.2 Actividad 4.1 Actividad 4.2 Actividad 5.1 Actividad 5.2 Actividad 5.3 Actividad 6.1 Actividad 7.1 Actividad 7.2
Componente 6
Requerimiento 4
Componente 7
Esquema 7. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EEAP. Estructura analítica del proyecto
4.3.1.7. Roles y responsabilidades en la metodología
Los roles y responsabilidades en el proceso del desarrollo de la metodología,
se pueden reflejar en la siguiente matriz RACI.
Roles:
• Propietarios del sistema
• Usuarios del sistema
• Administrador del proyecto
• Analista de sistema
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
152
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DEL SOFTWARE
BASADA EN EL MARCO LOGICO
Roles y responsabilidades en la metodología Actividades Responsabilidad
Encargado Responsable Consultado Informado Aprueba
1. Obtención de la información inicial
Analista de sistemas
Analista de sistemas
Propietarios y usuarios del sistema
Administrador del proyecto
Administrador del proyecto
2.
Análisis de involucrados e identificación de participantes en el proyecto.
Analista de sistemas
Analista de sistemas
Propietarios y usuarios del sistema
Propietarios y Administrador del proyecto
Administrador del proyecto
3. Identificación y análisis del problema
Analista de sistemas
Analista de sistemas
Propietarios y usuarios del sistema
Propietarios y Administrador del proyecto
Administrador del proyecto
4. Análisis de Objetivos de mejora del sistema
Analista de sistemas
Analista de sistemas
Propietarios y usuarios del sistema
Propietarios y Administrador del proyecto
Administrador del proyecto
5. Análisis de Acciones de mejora del sistema.
Analista de sistemas
Analista de sistemas
Propietarios y usuarios del sistema
Propietarios y Administrador del proyecto
Administrador del proyecto
6. Identificación/revisión de los objetivos del sistema a desarrollar.
Analista de sistemas
Analista de sistemas
Propietarios y usuarios del sistema
Propietarios y Administrador del proyecto
Administrador del proyecto
7. Identificación/revisión de los requerimientos del sistema.
Analista de sistemas
Analista de sistemas
Propietarios y usuarios del sistema
Propietarios y Administrador del proyecto
Administrador del proyecto
8. Diseño de la Estructura analítica del proyecto.
Analista de sistemas
Analista de sistemas Administrador
del proyecto Administrador del proyecto
9. Administración de la estructura del proyecto.
Analista de sistemas
Analista de sistemas
Propietarios y Administrador del proyecto
Administrador del proyecto
Tabla 39. Metodología para la elicitación de requerimientos de software basada en el
marco lógico: Matriz de Roles y responsabilidades en la metodología.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
153
CAPITULO 5. CASO DE ESTUDIO
Para realizar un ejemplo de aplicación de la metodología propuesta, se
desarrolla el siguiente caso de estudio:
Caso de estudio: Reservas de habitaciones de un hotel
Un hotel acepta reservas de habitaciones y exige el pago de un adelanto del
50% de la tarifa (precio de la habitación * cantidad de días). En la recepción
del hotel los clientes consultan sobre sus necesidades de alojamiento. El
recepcionista verifica la disponibilidad de habitaciones, y les comunica a los
pasajeros junto con los precios, y si no tiene lo requerido, pide alternativas. En
el momento que los pasajeros confirman la reserva, el empleado toma los
datos personales y les da el número de reserva. Al realizarse el pago de la
reserva, el recepcionista registra los datos de la reserva, la fecha de pago y
genera recibo de pago que le entrega al cliente.
Cuando el pasajero se retire del hotel, se genera y entrega la factura respectiva
del restante de días de estadía en el hotel.
La gerencia semanalmente recibe un informe de la facturación emitida.
Actualmente, el proceso de reservas de habitaciones en el hotel presenta
problemas y fallos en su gestión, y no es confiable.
A partir de esta narrativa se pide realizar la elicitación de los requerimientos de
software, para desarrollar un sistema de información que gestione los procesos
de reserva de habitaciones en el hotel.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
154
A continuación se aplican las etapas de la metodología propuesta al caso de
estudio:
Actividad 1. Obtención de la información inicial. Se realizan entrevistas a los propietarios del hotel caso de estudio, y se
consulta la documentación existente del funcionamiento del hotel y
específicamente de la recepción, y con esta información se obtiene un
conocimiento inicial del sistema caso de estudio.
Se obtiene el vocabulario del negocio: Reservas de habitaciones en un hotel.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PVDP. Vocabulario del dominio del proyecto Versión plantilla:1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012 No. Término Descripción 1 Administrador del hotel Profesional que coordina y gestiona los servicios del hotel
2 Agencias de viajes y turismo Empresa turística dedicada a la intermediación entre el cliente y la entidad hotelera.
3 Asociación Hotelera y turística Gremio en la industria de alojamiento, que regula los servicios turísticos y hoteleros
4 Cliente Personas que acceden al servicio hotelero. 5 Factura Recibo de pago por los servicios 6 Habitación Espacio destinado para el alojamiento 7 Hotel Empresa que presta los servicios de alojamiento 8 Informe facturación Consolidado de las facturaciones en alojamiento
9 Ministerio de desarrollo económico
Ministerio que regula la prestación de servicios turísticos y hoteleros
10 Pago Retribución económica por el servicio de alojamiento 11 Propietario hotel Dueño del hotel 12 Recepción Sección del hotel en donde se realizan las reservas de alojamiento 13 Recepcionista Profesionales en atención a clientes y usuarios del sistema hotelero. 14 Reserva habitación Solicitud del servicio de alojamiento 15 Tarifa Valor del servicio de alojamiento día por el tipo de habitación
Tabla 40. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PVDP. Vocabulario del dominio del
proyecto
Y funciones que se llevan a cabo en la recepción de un hotel:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
155
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PFDP. Funciones del dominio del proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012 No. Funciones Descripción 1 Reservas de habitaciones El recepcionista toma la solicitud de servicio del cliente,
revisa la disponibilidad de habitaciones para las fechas indicadas, e informa el precio al cliente. Si el cliente está de acuerdo paga el 50% del valor del servicio, el recepcionista procede a realizar la reserva y genera y entrega recibo de pago. También el recepcionista puede cancelar reservas realizadas, según solicitud de los clientes.
2 Registro información de clientes El recepcionista registra los datos del cliente que solicita la reserva: Identificación, nombres, dirección y teléfono. y los datos de las personas que lo acompañan si aplica.
3 Tarifas de las reservaciones Las tarifas son asignadas por el administrador del hotel, según la temporada del alojamiento y el tipo de habitación
4 Facturación El recepcionista genera el recibo de pago correspondiente al servicio prestado por el hotel, debe incluir los datos del cliente, tipo de habitación, días de alojamiento, valor del servicio y el IVA correspondiente. Y los datos del hotel.
5 Informe semanal de facturación El administrador genera semanalmente el informe de facturación prestados por alojamiento. Debe indicar el periodo, fecha de informe, habitaciones alquiladas, valor sin IVA y con IVA, y total facturado.
Tabla 41. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PFDP. Funciones del dominio del
proyecto
Actividad 2. Análisis de involucrados e identificación de participantes
en el proyecto.
Para realizar el análisis de los participantes involucrados en la
administración de la recepción del hotel, se realizan las siguientes actividades:
Actividad 2.1. Identificar a las personas o grupos, organizaciones, empresas
que tengan relación con el proyecto, o que se puedan beneficiar directa o
indirectamente con el proyecto en varios niveles.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
156
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Esquema: EIIP. Identificación de Involucrados en el proyecto Versión esquema: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
Esquema 8. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EIIP. Identificación de Involucrados en
el proyecto
Se realiza la descripción y/o algún comentario sobre cada involucrado
identificado con el proyecto, como se ve en la siguiente matriz.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
157
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PIIP. Identificación de involucrados en el proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
No. Involucrados Descripción Comentarios 1 Propietario (s) del hotel Dueño del hotel Ninguno
2 Recepcionistas Profesionales en atención a clientes y usuarios del sistema hotelero.
Ninguno
3 Administrador del hotel Profesional que coordina y gestiona los servicios del hotel
Ninguno
4 Otros empleados del hotel Botones, amas de llaves, etc. Ninguno 5 Clientes Personas que acceden al servicio hotelero. Ninguno
6 Agencias de viajes y turismo Empresa turística dedicada a la intermediación entre el cliente y la entidad hotelera.
Ninguno
7 Población de la región Personas que no acceden directamente al servicio hotelero. No son clientes del servicio.
Ninguno
8 Entidades hoteleras de la región
Hoteles del sector, pueden ser de la misma región o no.
Ninguno
9 Asociación Hotelera y turística Gremio en la industria de alojamiento, que regula los servicios turísticos y hoteleros
Ninguno
10 Ministerio de desarrollo económico
Ministerio que regula la prestación de servicios turísticos y hoteleros
Ninguno
11 Desarrolladores del proyecto Analistas, diseñadores, desarrolladores, integradores, personal de pruebas, personal de despliegue, personal de operaciones, personal de mantenimiento.
Ninguno
12 Proveedores del proyecto Proveedores de los recursos del proyecto Ninguno
Tabla 42. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PIIP. Identificación de involucrados en el
proyecto
Actividad 2.2. Agrupar a los involucrados identificados según sus
características comunes. NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PAICP. Agrupación de Involucrados por características comunes en el proyecto
Versión plantilla: 1.0
Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
No. Grupo de involucrados Involucrados Características 1 Propietarios del sistema • Propietario (s) del hotel Patrocinador del proyecto
2 Usuarios del sistema
• Recepcionistas • Administrador del hotel • Otros empleados del hotel • Clientes del servicio • Agencias de viajes y turismo
Contienen información del funcionamiento y servicios del hotel.
3 Comunidad de la región • Población de la región Afectados por los servicios hoteleros
4 Hoteles de la región • Entidades hoteleras de la región Competencia de el área hotelera
5 Ministerio y gremios reguladores de servicios turísticos y hoteleros
• Asociación Hotelera y turística • Ministerio de desarrollo económico
Regulas los servicios turísticos y hoteleros.
6 Comunidad técnica • Desarrolladores del proyecto • Proveedores del proyecto
Poseen el conocimiento y experiencia técnica para el desarrollo del proyecto
Tabla 43. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PAICP. Agrupación de Involucrados por
características comunes en el proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
158
Actividad 2.3. Definir la posición de los grupos de involucrados con respecto
al proyecto.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PPGIP. Posición grupos de involucrados con respecto al proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema, usuarios del sistema, Comunidad de la región, Hoteles de la región, Ministerio y gremios reguladores de servicios turísticos y hoteleros, Comunidad técnica. Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
No. Grupo de involucrados Problemas percibidos Intereses
Posible impacto del
proyecto sobre los intereses (+,-,=,?)
Recursos y Mandatos
1 Propietarios del sistema
• Disminución de la demanda.
• Muchas quejas de los clientes.
• Las tarifas cobradas cubren solo el 60% los costos operativos en el hotel.
Proveer un servicio hotelero costo-eficiente.
+
R: Contar con Instalaciones del Hotel. R: Presupuesto operativo. M: Proveer un servicio hotelero costo-eficiente. M: Aprobar el desarrollo del proyacto. R: Contar con los recursos presupuestales necesarios para el desarrollo del proyecto.
2 Usuarios del sistema
• El sistema actual de administración no es confiable.
• El sistema actual no lleva un control de reservas, ingresos, salidas, pedidos, pagos y servicios de alojamiento en el hotel.
Contar con un sistema confiable de administración de reservas, ingresos, salidas, pedidos, pagos y otros servicios relacionados con alojamientos solicitados en el hotel.
+
R: Disponibilidad de contar con un sistema de administración de los servicios del hotel. (empleados) R: Disponibilidad de acceder a un servicio hotelero confiable. (clientes) M: Pueden quejarse de los servicios del hotel, ante los entes reguladores y de control
3 Comunidad de la región
Disminución de turistas en la región
El aumento de turistas, ayuda a la economía de la región
+
M: Pueden quejarse de los servicios del hotel, ante los entes reguladores y de control
4 Hoteles de la región
Servicios deficientes a clientes por parte del hotel caso de estudio
Atención de clientes que no pudieron ser hospedados en el hotel caso de estudio
-, +, =
R: Disponibilidad de atender a los clientes que no fueron atendidos.
5
Ministerio y gremios
reguladores de servicios
turísticos y hoteleros
• Disminución de la demanda.
• Disminución de turistas en la región.
• Quejas de clientes por la atención hotelera.
• Atención deficiente en la administración de servicios hoteleros.
• Mejorar los servicios de la atención hotelera en la región.
• Cumplimiento con las normas y estándares de calidad en servicios hoteleros
+
R: Disponibilidad de sistemas hoteleros confiables de los hoteles afiliados. M: Sancionar a los hoteles con servicios deficientes.
6 Comunidad técnica
• Desarrollar con calidad el proyecto de
+ R: Contar con los recursos necesarios para el desarrollo del
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
159
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PPGIP. Posición grupos de involucrados con respecto al proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema, usuarios del sistema, Comunidad de la región, Hoteles de la región, Ministerio y gremios reguladores de servicios turísticos y hoteleros, Comunidad técnica. Técnica de elicitación: Entrevistas, exploración de documentación existente
administración de servicios hoteleros
• Intereses económicos
• Proveer de los elementos para el desarrollo del proyecto.
sistema. M: Desarrollar el sistema. R: Contar con el pago pactado. M: Suministrar los recursos solicitados por el proyecto.
Tabla 44. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: PPGIP. Posición grupos de involucrados con respecto al proyecto
Podemos analizar que habrán hoteles en los que el desarrollo del proyecto
puede afectar positivamente, negativamente e indiferentemente, positivamente
en el caso que haya una buena imagen de atención hotelera en la región y
visiten más turistas, negativamente en el caso que haya mala imagen del
atención en el hotel caso de estudio y se generalice la mala imagen del servicio
hotelero en la región, provocando la disminución de turistas en la región. Y a
otros en que es indiferente el proyecto.
Se define la fuerza o poder de los grupos de involucrados frente al proyecto.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PEFGIP. Expectativa y fuerza del grupo de involucrados en el proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema, usuarios del sistema, Comunidad de la región, Hoteles de la región, Ministerio y gremios reguladores de servicios turísticos y hoteleros, Comunidad técnica. Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
No. Grupo de involucrados Expectativa Fuerza Resultante 1 Propietarios del sistema 5 5 25 2 Usuarios del sistema 5 5 25 3 Comunidad de la región 3 1 3 4 Hoteles de la región 5 1 5
5 Ministerio y gremios reguladores de servicios turísticos y hoteleros 4 2 8
6 Comunidad técnica 5 5 25
Tabla 45. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PEFGIP. Expectativa y fuerza del grupo
de involucrados en el proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
160
Se analiza y se clasifica en beneficiarios directos, beneficiarios indirectos,
excluidos/neutrales y perjudicados/oponentes potenciales con respecto al
proyecto.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PCGIP. Clasificación grupos de involucrados con respecto al proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema, usuarios del sistema, Comunidad de la región, Hoteles de la región, Ministerio y gremios reguladores de servicios turísticos y hoteleros, Comunidad técnica. Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
No. Grupo de involucrados Beneficiarios directos
Beneficiarios Indirectos
Excluidos/ Neutrales
Perjudicados/ Oponentes potenciales
1 Propietarios del sistema √ 2 Usuarios del sistema √ 3 Comunidad de la región √ 4 Hoteles de la región √ √ √
5 Ministerio y gremios reguladores de servicios turísticos y hoteleros
√
6 Comunidad técnica √
Tabla 46. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PCGIP. Clasificación grupos de
involucrados con respecto al proyecto
Podemos concluir que según el análisis de posición de los grupos de
involucrados con respecto al proyecto, resultarían clasificados el grupo de
hoteles de la región, en los tres grupos de beneficiarios indirectos,
excluidos/neutrales y en perjudicados oponentes. Ya que habrán hoteles con
intereses particulares y efectos del proyecto.
Actividad 2.4. Analizar y definir la incorporación de los involucrados al
proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
161
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PAIGIP. Análisis incorporación grupos involucrados al proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema, usuarios del sistema, Comunidad de la región, Hoteles de la región, Ministerio y gremios reguladores de servicios turísticos y hoteleros, Comunidad técnica. Técnica de elicitación: Entrevistas, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012 No. Grupo de involucrados Importancia Involucramiento Resultante 1 Propietarios del sistema 5 5 25 2 Usuarios del sistema 5 5 25 3 Comunidad de la región 1 0 0 4 Hoteles de la región 2 0 0
5 Ministerio y gremios reguladores de servicios turísticos y hoteleros 3 1 4
6 Comunidad técnica 5 5 25
Tabla 47. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: PAIGIP. Análisis incorporación grupos involucrados al proyecto
Podemos concluir que con el grupo de involucrados que se van a trabajar
para el desarrollo del proyecto serán: los propietarios del sistema, usuarios del
sistema, y la comunicad técnica, no dejando de lado los estándares, normas o
regulaciones que pueda brindar los ministerios y gremios reguladores de
servicios turísticos y hoteleros.
Por otro lado la comunidad de la región, y los hoteles de la región deben de
considerarse como factores externos en la gestión del plan del proyecto, ya que
podrían influir positiva o negativamente en el desarrollo del mismo.
Actividad 3. Identificación y análisis del problema. Identificar el problema central a intervenir, las causas y los efectos, en la
gestión de reservas de habitaciones en el hotel. Se realizan las siguientes
actividades:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
162
Actividad 3.1. Definir el problema central.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PLP. Listado de Problemas Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: documentación existente, propietarios del sistema, usuarios del sistema Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
No. Listado de Problemas 1 2 3 4 5 6 7 8 9 10 11 12
13 14 15 16
Fallas en el control de ingreso de datos de los clientes Fallas en el registro de datos del cliente Fallas en el control de actualización de estado de habitaciones Fallas en el reporte de habitaciones libres Fallas en la asignación de habitaciones Registro erróneo de reserva de habitaciones Fallas en el control de actualización de tarifas en el sistema Tarifas de habitaciones no actualizadas Facturación errónea de las reservas de habitaciones Existencia de errores en los Informes semanales de facturación Insatisfacción del cliente Quejas de clientes ante el administrador y propietarios del hotel y el Ministerio y gremios reguladores de servicios turísticos y hoteleros Sanciones por parte del Ministerio y gremios reguladores de servicios turísticos y hoteleros Mala reputación del hotel Reducción de demanda en los servicios del hotel Decisiones incorrectas basadas en el informe no confiable de facturación
No. Problema central 1 Gestión de reservas de habitaciones del hotel inadecuado/no confiable
Tabla 48. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: PLP. Listado de Problemas.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
163
Actividad 3.2. Elaborar el árbol de efectos del problema.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Esquema: EAEP. Árbol de efectos del problema Versión esquema: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: PLP. Listado de Problemas Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
Gestión de reservas de habitaciones del hotel inadecuado/no confiable
Quejas de clientes ante el administrador y propietarios del hotel y el Ministerio y gremios reguladores de servicios turísticos y hoteleros
Reducción de demanda en los servicios de alojamiento
del hotel
Mala reputación del hotel
Sanciones por parte del Ministerio y gremios reguladores de servicios
turísticos y hoteleros
EFECTOS
PROBLEMA CENTRAL
Decisiones incorrectas basadas en el informe no confiable de facturación
Insatisfacción del cliente
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO.
EAEP. Árbol de efectos del problema
CASO DE ESTUDIO
Esquema 9. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAEP. Árbol de efectos del problema
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
164
Actividad 3.3. Elaborar el árbol de causas del problema.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Esquema: EACP. Árbol de causas del problema Versión esquema: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: PLP. Listado de Problemas Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
Gestión de reservas de habitaciones del hotel inadecuado/no confiable
Fallas en el registro de datos del cliente
Facturación errónea de las reservas de
habitaciones
CAUSAS
PROBLEMA CENTRAL
Registro erroneo de reserva de habitaciones
Tarifas de habitaciones no actualizadas
Existencia de errores en los Informes semanales de
facturación
Fallas en la asignación de habitaciones
Fallas en el control de ingreso de datos de los
clientes
Fallas en el reporte de habitaciones libres
Fallas en el control de actualizacion de tarifas de
habitaciones en el sistema
Fallas en el control de actualización de estado
de habitaciones
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO.
EACP. Árbol de causas del problema.
CASO DE ESTUDIO
Esquema 10. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EACP. Árbol de causas del problema.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
165
Actividad 3.4. Elaborar/revisar el árbol de problemas.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Esquema: EAP. Árbol de problemas Versión esquema: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: EAEP. Árbol de efectos del problema, EACP. Árbol de causas del problema Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
Gestión de reservas de habitaciones del hotel inadecuado/no confiable
Quejas de clientes ante el administrador y propietarios del hotel y el Ministerio y gremios reguladores de servicios turísticos y hoteleros
Reducción de demanda en los servicios de alojamiento
del hotel
Mala reputación del hotel
Fallas en el registro de datos del cliente
Facturación errónea de las reservas de
habitaciones
Sanciones por parte del Ministerio y gremios reguladores de servicios
turísticos y hoteleros
EFECTOS
CAUSAS
PROBLEMA CENTRAL
Decisiones incorrectas basadas en el informe no confiable de facturación
Registro erróneo de reserva de habitaciones
Insatisfacción del cliente
Tarifas de habitaciones no actualizadas
Existencia de errores en los Informes semanales de
facturación
Fallas en la asignación de habitaciones
Fallas en el control de ingreso de datos de los
clientes
Fallas en el reporte de habitaciones libres
Fallas en el control de actualizacion de tarifas de
habitaciones en el sistema
Fallas en el control de actualización de estado
de habitaciones
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO.
EAP. Árbol de problemas.
CASO DE ESTUDIO
Esquema 11. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAP. Árbol de problemas.
Se realiza la revisión de validez e integridad del árbol de problemas dibujado
las veces que sea necesario.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
166
Actividad 3.5. Elaborar la Matriz de problemas.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PMP. Matriz de Problemas Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: EAP. Árbol de problemas Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
Problema central Causas Efectos
Gestión de reservas de habitaciones del hotel
inadecuado/no confiable
• Fallas en el control de ingreso de datos de los clientes
• Fallas en el registro de datos del cliente
• Fallas en el control de actualización de estado de habitaciones
• Fallas en el reporte de habitaciones libres
• Fallas en la asignación de habitaciones
• Registro erróneo de reserva de habitaciones
• Fallas en el control de actualización de tarifas en el sistema
• Tarifas de habitaciones no actualizadas
• Facturación errónea de las reservas de habitaciones
• Existencia de errores en los Informes semanales de facturación
• Reducción de demanda en los servicios de alojamiento del hotel
• Insatisfacción del cliente • Quejas de clientes ante el
administrador y propietarios del hotel y el Ministerio y gremios reguladores de servicios turísticos y hoteleros
• Sanciones por parte del Ministerio y gremios reguladores de servicios turísticos y hoteleros
• Mala reputación del hotel • Decisiones incorrectas basadas en
el informe no confiable de facturación
Tabla 49. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: PMP. Matriz de Problemas.
Actividad 4. Análisis de Objetivos de mejora del sistema. En esta actividad se identifican el objetivo central del proyecto que se espera
alcanzar, y los medios y fines. Contiene las siguientes actividades:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
167
Actividad 4.1. Elaborar/verificar el árbol de objetivos.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Esquema: EAO. Árbol de Objetivos Versión esquema: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: EAP. Árbol de problemas Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
Gestión de reservas de habitaciones del hotel adecuado/confiable
Felicitaciones de clientes ante el administrador y propietarios del hotel y el Ministerio y gremios reguladores de servicios turísticos y hoteleros
Aumento de demanda en los servicios de alojamiento
del hotel
Buena reputación del hotel
Premios por parte del Ministerio y gremios reguladores de servicios
turísticos y hoteleros
FINES
OBJETIVO O PROPOSITO
Decisiones correctas basadas en el informe confiable de facturación
Satisfacción del cliente
Registro correcto de datos del cliente
Facturación correcta de las reservas de
habitaciones
MEDIOS
Registro correcto de reserva de habitaciones
Tarifas de habitaciones actualizadas
Informes correctos de facturación semanal
Asignación correcta de habitaciones
Correcto control de ingreso de datos de los
clientes
Correcto reporte de habitaciones libres
Correcto control de actualizacion de tarifas de
habitaciones en el sistema
Correcto control de actualización de estado
de habitaciones
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO.
EAO. Árbol de Objetivos.
CASO DE ESTUDIO
Esquema 12. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAO. Árbol de Objetivos.
Según la revisión de relaciones de medios y fines, se encuentra que son
validas y se encuentran integradas entre si.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
168
Actividad 4.2. Elaborar la Matriz de objetivos.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PMO. Matriz de Objetivos Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: EAO. Árbol de Objetivos Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Fuente: Usuarios del sistema, propietario del sistema Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
Objetivo del sistema Medios Fines
Gestión de reservas de habitaciones del hotel adecuado/confiable
• Correcto control de ingreso de datos de los clientes
• Registro correcto de datos del cliente
• Correcto control de actualización de estado de habitaciones
• Correcto reporte de habitaciones libres
• Asignación correcta de habitaciones
• Registro correcto de reserva de habitaciones
• Correcto control de actualización de tarifas en el sistema
• Tarifas de habitaciones actualizadas
• Facturación correcta de las reservas de habitaciones
• Informes correctos de facturación semanal
• Aumento de demanda en los servicios de alojamiento del hotel
• Satisfacción del cliente • Felicitaciones de clientes ante el
administrador y propietarios del hotel y el Ministerio y gremios reguladores de servicios turísticos y hoteleros
• Premios por parte del Ministerio y gremios reguladores de servicios turísticos y hoteleros
• Buena reputación del hotel • Decisiones correctas basadas en
el informe no confiable de facturación
Tabla 50. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: PMO. Matriz de Objetivos.
Actividad 5. Análisis de Acciones de mejora del sistema.
Actividad 5.1 Identificar/verificar las acciones. Se tomaron los medios del
último nivel del árbol de objetivos y se adicionaron los medios del primer nivel
por ser actividades importantes que contemplan las de último nivel.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
169
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Esquema: EAA. Árbol de Acciones Versión esquema: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: EAO. Árbol de Objetivos, PMO. Matriz de Objetivos. Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
MEDIOS(Nivel inferior del árbol
de objetivos) Correcto control de actualización de estado de
habitaciones
Correcto control de actualización de tarifas de habitaciones en el sistema
Correcto control de ingreso de datos de los clientes
Implantar sistema confiable para el registro y control de
estado de habitaciones
Implantar sistema confiable para el registro y control de
datos de clientes
Implantar sistema confiable para el registro y control de la
actualización de tarifas de habitaciones en el sistema
ACCIONES
Implantar sistema confiable para el registro y control de
reserva de habitaciones
Facturación correcta de las reservas de habitaciones
Registro correcto de reserva de habitaciones Informes correctos de
facturación semanal
Implantar sistema confiable para el registro y control de la facturación de habitaciones
Implantar sistema confiable para la generación del informe de facturación
semanal
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO.
EAA. Árbol de Acciones.
CASO DE ESTUDIO
Esquema 13. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EAA. Árbol de Acciones.
Actividad 5.2. Elaborar la matriz de acciones.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PMA. Matriz de Acciones Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: EAA. Árbol de Acciones Técnica de elicitación: Alguna de las siguientes: Exploración de documentación existente, Técnica de grupos nominales, Técnica Delphi, Método EASW, Núcleos de intervención participativa, lluvia de ideas. Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012 No. Medios Acciones
1 Correcto control de ingreso de datos de los clientes
Implantar sistema confiable para el registro y control de datos de clientes
2 Registro correcto de reserva de habitaciones Implantar sistema confiable para el registro y control de reserva de habitaciones
3 Correcto control de actualización de estado de habitaciones
Implantar sistema confiable para el registro y control de estado de habitaciones
4 Correcto control de actualización de tarifas de habitaciones en el sistema
Implantar sistema confiable para el registro y control de la actualización de tarifas de habitaciones en el sistema
5 Facturación correcta de las reservas de habitaciones
Implantar sistema confiable para el registro y control de la facturación de habitaciones
6 Informes correctos de facturación semanal Implantar sistema confiable para la generación del informe de facturación semanal
Tabla 51. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: PMA. Matriz de Acciones.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
170
Actividad 6. Identificar/revisar los objetivos del sistema a desarrollar.
Con base en la matriz de objetivos, árbol de acciones y matriz de acciones,
se identifican los objetivos del sistema a desarrollar, las cuales se citan en la
siguiente matriz.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: POS. Objetivos del sistema Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: PMO. Matriz de objetivos, EAA. Árbol de Acciones, PMA. Matriz de Acciones Técnica de elicitación: Entrevista, exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
OG-01 Desarrollar un Sistema de información para la gestión de reservas de habitaciones
del hotel adecuado/confiable Descripción Desarrollar un sistema de información para la gestión de reservas de habitaciones de un
hotel que permita realizar la gestión de habitaciones del hotel, gestión de clientes, gestión de reservas de habitaciones, gestión de facturación de servicio de alojamiento, y la gestión del informe de facturación semanal de servicios de alojamiento del hotel, de forma adecuada/confiable.
Objetivos asociados OE-01. Gestionar información de habitaciones del hotel OE-02. Gestionar datos de los clientes del hotel OE-03. Gestionar datos de reservas de habitaciones del hotel OE-04. Gestionar la facturación del servicio de alojamiento OE-05. Gestionar el informe de facturación semanal del hotel por servicios de alojamiento.
Grupo de involucrados Usuarios del sistema Stakeholders Usuarios del sistema, propietarios del sistema, Comunidad técnica Restricción Ninguna Importancia alta Urgencia alta Comentarios Ninguno
OE-01 Gestionar información de habitaciones del hotel Descripción El sistema deberá gestionar la información correspondiente a las habitaciones del hotel
como: ubicación, tipo de habitación, capacidad, disponibilidad, precio. Objetivos asociados OE-03. Gestionar datos de reservas de habitaciones del hotel Grupo de involucrados Usuarios del sistema Stakeholders Usuarios del sistema, propietarios del sistema, Comunidad técnica Restricción Ninguna Importancia alta Urgencia alta Comentarios Con este objetivo se incluye las acciones de : Implantar sistema confiable para el registro
y control de estado de habitaciones, Implantar sistema confiable para el registro y control de la actualización de tarifas de habitaciones en el sistema
OE-02 Gestionar datos de los clientes del hotel Descripción El sistema deberá gestionar la información correspondiente a los clientes como los datos
personales Objetivos asociados OE-03. Gestionar datos de reservas de habitaciones del hotel Grupo de involucrados Usuarios del sistema Stakeholders Usuarios del sistema, propietarios del sistema, Comunidad técnica Restricción Ninguna Importancia alta Urgencia alta Comentarios Ninguno
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
171
OE-03 Gestionar datos de reservas de habitaciones del hotel Descripción El sistema deberá gestionar la información correspondiente a las solicitudes de reserva
de habitaciones del hotel como es: cliente que solicita la reserva, número de personas a alojarse, la habitación para la reserva, fecha de solicitud de reserva, fecha de ocupación de la habitación, fecha de liberación de la habitación, cancelación de reserva.
Objetivos asociados OE-01. Gestionar información de habitaciones del hotel OE-02. Gestionar datos de los clientes del hotel
Grupo de involucrados Usuarios del sistema Stakeholders Usuarios del sistema, propietarios del sistema, Comunidad técnica Restricción Se registra la reserva de habitaciones si se realiza el pago de un adelanto del 50% de la
tarifa (precio de la habitación * cantidad de días). Importancia alta Urgencia alta Comentarios Ninguno
OE-04 Gestionar la facturación del servicio de alojamiento Descripción El sistema deberá gestionar la información correspondiente a la facturación de los
servicios de alojamiento con es: datos cliente, datos habitación reservada, valor habitación reservada, número de días del servicio, IVA del valor factura, pago de la reserva.
Objetivos asociados OE-01. Gestionar información de habitaciones del hotel OE-02. Gestionar datos de los clientes del hotel OE-03. Gestionar datos de reservas de habitaciones del hotel OE-05. Gestionar el informe de facturación semanal del hotel por servicios de alojamiento.
Grupo de involucrados Usuarios del sistema Stakeholders Usuarios del sistema, propietarios del sistema, Comunidad técnica Restricción Ninguna Importancia alta Urgencia alta Comentarios Ninguno
OE-05 Gestionar el informe de facturación semanal del hotel por servicios de alojamiento. Descripción El sistema deberá gestionar la información correspondiente al informe de la facturación
semanal de alojamiento en el hotel como es: fecha del informe, valor unitario facturado por cliente, fecha inicio y fecha final por cliente, total facturado en la semana.
Objetivos asociados OE-04. Gestionar la facturación del servicio de alojamiento Grupo de involucrados Usuarios del sistema, propietarios del sistema Stakeholders Usuarios del sistema, propietarios del sistema Restricción Los informes se realizan semanalmente Importancia alta Urgencia alta Comentarios Ninguno
Tabla 52. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: POS. Objetivos del sistema
Actividad 7. Identificación/revisión de los requerimientos del sistema.
Con base en los objetivos del sistema y acciones se identifican los
requerimientos del sistema a desarrollar para la gestión de reservas de
habitaciones en el hotel.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
172
Se analiza que como requerimiento principal se necesita desarrollar un
sistema de información para la gestión de reservas de habitaciones en un hotel,
que deberá contener los subsistemas de gestión de habitaciones del hotel,
gestión de clientes, gestión de reservas de habitaciones, gestión de facturación
del servicio de alojamiento, y gestión del informe de facturación semanal.
Actividad 7.1. Identificar/Revisar los requerimientos funcionales del sistema.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PRFS. Requerimientos Funcionales del sistema Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: POS. Objetivos del sistema Técnica de elicitación: exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
RFS-01 Registro de información de habitaciones del hotel Descripción El sistema deberá permitir el registro de información de habitaciones del hotel como es:
ubicación, tipo de habitación, capacidad, disponibilidad, precio. El sistema deberá permitir: Adicionar, editar y eliminar los datos relacionados con la información de la habitación
Objetivos asociados OE-01. Gestionar información de habitaciones del hotel. Requerimientos asociados
RFS-02. Consulta de información de habitaciones del hotel
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Solo habitaciones del hotel Importancia alta Urgencia alta Comentarios Ninguno
RFS-02 Consulta de información de habitaciones del hotel Descripción El sistema deberá permitir la consulta de información de habitaciones del hotel por
diferentes criterios como es: numero de habitación, tipo de habitación, precio de habitación, disponibilidad de habitación.
Objetivos asociados OE-01. Gestionar información de habitaciones del hotel Requerimientos asociados
RFS-01. Registro de información de habitaciones del hotel
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Solo habitaciones del hotel Importancia alta Urgencia alta Comentarios Ninguno RFS-03 Registro de información de clientes del hotel Descripción El sistema deberá permitir el registro de información de clientes del hotel como es:
Identificación, nombres, apellidos, dirección, teléfono. El sistema deberá permitir: Adicionar, editar y eliminar los datos relacionados con la información del cliente.
Objetivos asociados OE-02. Gestionar datos de los clientes del hotel Requerimientos asociados
RFS-04. Consulta de información de clientes del hotel
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Se registran clientes mayores de edad. Importancia alta Urgencia alta Comentarios Ninguno
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
173
RFS-04 Consulta de información de clientes del hotel Descripción El sistema deberá permitir la consulta de información de clientes del hotel por diferentes
criterios como es: identificación, nombres, apellidos. Objetivos asociados OE-02. Gestionar datos de los clientes del hotel. Requerimientos asociados
RFS-03. Registro de información de clientes del hotel
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Ninguna Importancia alta Urgencia alta Comentarios Ninguno
RFS-05 Registro de información de reservas de habitaciones Descripción El sistema deberá permitir el registro de información de las reservas de habitaciones del
hotel como es: cliente que solicita la reserva, número de personas a alojarse, la habitación para la reserva, fecha de solicitud de reserva, fecha de ocupación de la habitación, fecha de liberación de la habitación, cancelación de reserva. El sistema deberá permitir: Adicionar, editar y eliminar los datos relacionados con la reserva.
Objetivos asociados OE-03. Gestionar datos de reservas de habitaciones del hotel Requerimientos asociados
RFS-01. Registro de información de habitaciones del hotel RFS-02. Consulta de información de habitaciones del hotel RFS-03. Registro de información de clientes del hotel RFS-04. Consulta de información de clientes del hotel
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Se registra la reserva de habitaciones si se realiza el pago de un adelanto del 50% de la
tarifa (precio de la habitación * cantidad de días). Importancia alta Urgencia alta Comentarios Ninguno
RFS-06 Consulta de información de reservas de habitaciones Descripción El sistema deberá permitir la consulta de información de reservas de habitaciones del
hotel por diferentes criterios como es: Estado de habitaciones (reservadas, libres), fechas de inicio de reservas de habitaciones, fechas de liberación de reservas de la habitaciones, datos del clientes que reservan determinada habitación, pago de la reserva de la habitación.
Objetivos asociados OE-03. Gestionar datos de reservas de habitaciones del hotel Requerimientos asociados
RFS-05. Registro de información de reservas de habitaciones
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Importancia alta Urgencia alta Comentarios Ninguno RFS-07 Registro de información de factura servicio alojamiento Descripción El sistema deberá permitir el registro de información de la facturación de los servicios de
alojamiento con es: datos cliente, datos habitación reservada, valor habitación reservada, número de días del servicio, IVA del valor factura, pago de la reserva. El sistema deberá permitir: Adicionar, editar y eliminar, imprimir los datos relacionados con la facturación del servicio de alojamiento.
Objetivos asociados OE-04. Gestionar la facturación del servicio de alojamiento Requerimientos asociados
RFS-05. Registro de información de reservas de habitaciones RFS-06. Consulta de información de reservas de habitaciones
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Se factura la reserva de habitaciones correspondiente al pago de adelanto de 50% de la
tarifa (precio de la habitación * cantidad de días). Y luego el 50% restante cuando termine el tiempo de reserva.
Importancia alta Urgencia alta Comentarios El número de factura deberá asignarlo el sistema.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
174
RFS-08 Consulta de información de facturas servicio alojamiento Descripción El sistema deberá permitir la consulta de información de reservas de habitaciones del
hotel por diferentes criterios como es: Numero de factura, Datos del cliente, fecha de reserva.
Objetivos asociados OE-04. Gestionar la facturación del servicio de alojamiento Requerimientos asociados
RFS-07. Registro de información de factura servicio alojamiento
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Ninguna Importancia alta Urgencia alta Comentarios Ninguno
RFS-09 Registro de información informe de facturación semanal del hotel por servicios de
alojamiento. Descripción El sistema deberá permitir el registro de información del informe de la facturación semanal
de alojamiento en el hotel como es: Numero de informe, fecha del informe, valor unitario facturado por cliente, fecha inicio y fecha final por cliente, total facturado en la semana.
Objetivos asociados OE-05. Gestionar el informe de facturación semanal del hotel por servicios de alojamiento. Requerimientos asociados
RFS-07. Registro de información de factura servicio alojamiento RFS-08. Consulta de información de facturas servicio alojamiento
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción El informe debe generarse semanalmente. Importancia alta Urgencia alta Comentarios El número de informe deberá asignarlo el sistema.
El valor unitario facturado por cliente, fecha inicio y fecha final por reserva de habitación cliente, deben ser tomados del sistema. El total facturado en la semana debe ser calculado por el sistema.
RFS-10 Consulta de información de informe de facturación semanal del hotel por servicios
de alojamiento. Descripción El sistema deberá permitir la consulta de información de informes históricos de facturación
semanal del hotel por servicios de alojamiento, por diferentes criterios como son: Numero de informe, fecha de informe.
Objetivos asociados OE-05. Gestionar el informe de facturación semanal del hotel por servicios de alojamiento Requerimientos asociados
RFS-09. Registro de información informe de facturación semanal del hotel por servicios de alojamiento.
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción Ninguna Importancia alta Urgencia alta Comentarios Ninguno
Tabla 53. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PRS. Requerimientos del sistema
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
175
Actividad 7.2. Identificar/Revisar los requerimientos no funcionales del
sistema
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PRNFS. Requerimientos no funcionales del sistema Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: POS. Objetivos del sistema Técnica de elicitación: exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
RNF- 01 Copias de seguridad Descripción El sistema deberá tener algún mecanismo que permita realizar copias de seguridad de los
datos almacenados. Objetivos asociados - Requerimientos asociados
-
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción - Importancia alta Urgencia alta Comentarios Ninguno
RNF- 02 Entorno técnico Descripción El sistema deberá funcionar en un entorno de 3 PC’s Pentium con 2 GBytes de RAM y 8
GBytes de disco duro, conectados en red con sistema operativo Microsoft Windows 7. Objetivos asociados - Requerimientos asociados
-
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción - Importancia alta Urgencia alta Comentarios Ninguno
RNF-03 Portabilidad Descripción El sistema deberá poder ser portable al sistema operativo Microsoft Windows 8. Objetivos asociados - Requerimientos asociados
-
Grupo de involucrados Usuarios del sistema, propietarios del sistema, comunidad técnica Stakeholders Usuarios del sistema, propietarios del sistema, comunidad técnica Restricción - Importancia alta Urgencia alta Comentarios Ninguno
Tabla 54. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: PRNFS. Requerimientos no funcionales del sistema
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
176
Actividad 8. Diseño de la Estructura analítica del proyecto.
Actividad 8.1. Diagramar el árbol de la estructura analítica del proyecto
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Esquema: EEAP. Estructura analítica del proyecto Versión esquema: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: POS. Objetivos del sistema, PRFS. Requerimientos Funcionales del sistema Técnica de elicitación: exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
Sistema de información para la Gestión de reservas de habitaciones del hotel adecuado/confiable
Aumento de demanda en los servicios de alojamiento del hotel
FIN
OBJETIVO O PROPOSITO
Análisis detallado de Requerimientos Diseño detallado Desarrollo Pruebas Corrección de fallos Implantación
PRODUCTOS O COMPONENTES
ACTIVIDADES
Registro de información
Gestionar datos de los clientes del hotel
Gestionar información de habitaciones del hotel
Gestionar la facturación del servicio de alojamiento
Gestionar datos de reservas de habitaciones
del hotel
Gestionar el informe de facturación semanal del hotel por
servicios de alojamiento.
OBJETIVOS ESPECIFIGOS
REQUERIMIENTOS DEL SISTEMA Consulta de información
Ingreso Edición Eliminación Consulta
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LOGICO.
EEAP. Estructura analítica del proyecto.
CASO DE ESTUDIO
Esquema 14. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Esquema: EEAP. Estructura analítica del
proyecto.
Actividad 8.2. Elaborar la Matriz de la Estructura analítica del proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
177
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PMEAP. Matriz Estructura Analítica del proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: EEAP. Estructura analítica del proyecto Técnica de elicitación: Exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012
FIN O META OBJETIVO GENERAL
O PROPOSITO OBJETIVOS
ESPECIFICOS DEL SISTEMA REQUERIMIENTOS
FUNCIONALES DELSISTEMA COMPONENTE/ PRODUCTO ACTIVIDADES
F-01. Aumento
de demanda
en los servicios
de alojamiento
del hotel
OG-01. Desarrollar un Sistema de
información para la gestión de reservas de habitaciones del
hotel adecuado/confiable
OE-01. Gestionar información de habitaciones del hotel
RFS-01. Registro de información de habitaciones del hotel
C-01. Ingreso habitación
A-1.1 Análisis detallado de Requerimientos A-1.2 Diseño detallado A-1.3 Desarrollo A-1.4 Pruebas A-1.5. Corrección de fallos A-1.6. Implantación
C-02. Edición habitación
A-2.1 Análisis detallado de Requerimientos A-2.2 Diseño detallado A-2.3 Desarrollo A-2.4 Pruebas A-2.5. Corrección de fallos A-2.6. Implantación
C-03. Eliminación habitación
A-3.1 Análisis detallado de Requerimientos A-3.2 Diseño detallado A-3.3 Desarrollo A-3.4 Pruebas A-3.5. Corrección de fallos A-3.6. Implantación
RFS-02. Consulta de información de habitaciones del hotel
C-04. Consulta habitación
A-4.1 Análisis detallado de Requerimientos A-4.2 Diseño detallado A-4.3 Desarrollo A-4.4 Pruebas A-4.5. Corrección de fallos A-4.6. Implantación
OE-02. Gestionar datos de los clientes del hotel
RFS-03. Registro de información de clientes del hotel
C-05. Ingreso cliente
A-5.1 Análisis detallado de Requerimientos A-5.2 Diseño detallado A-5.3 Desarrollo A-5.4 Pruebas A-5.5. Corrección de fallos A-5.6. Implantación
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
178
FIN O META OBJETIVO GENERAL O PROPOSITO
OBJETIVOS ESPECIFICOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES DELSISTEMA COMPONENTE/ PRODUCTO ACTIVIDADES
C-06. Edición cliente
A-6.1 Análisis detallado de Requerimientos A-6.2 Diseño detallado A-6.3 Desarrollo A-6.4 Pruebas A-6.5. Corrección de fallos A-6.6. Implantación
C-07. Eliminación cliente
A-7.1 Análisis detallado de Requerimientos A-7.2 Diseño detallado A-7.3 Desarrollo A-7.4 Pruebas A-7.5. Corrección de fallos A-7.6. Implantación
RFS-04. Consulta de información de clientes del hotel
C-08. Consulta clientes
A-8.1 Análisis detallado de Requerimientos A-8.2 Diseño detallado A-8.3 Desarrollo A-8.4 Pruebas A-8.5. Corrección de fallos A-8.6. Implantación
OE-03. Gestionar datos de reservas de habitaciones del hotel
RFS-05. Registro de información de reservas de habitaciones
C-09. Ingreso reserva
A-9.1 Análisis detallado de Requerimientos A-9.2 Diseño detallado A-9.3 Desarrollo A-9.4 Pruebas A-9.5. Corrección de fallos A-9.6. Implantación
C-10. Edición reserva
A-10.1 Análisis detallado de Requerimientos A-10.2 Diseño detallado A-10.3 Desarrollo A-10.4 Pruebas A-10.5. Corrección de fallos A-10.6. Implantación
C-11. Eliminación reserva
A-11.1 Análisis detallado de Requerimientos A-11.2 Diseño detallado A-11.3 Desarrollo A-11.4 Pruebas A-11.5. Corrección de fallos A-11.6. Implantación
RFS-06. Consulta de información de reservas de habitaciones
C-12. Consulta Reservas
A-12.1 Análisis detallado de Requerimientos A-12.2 Diseño detallado A-12.3 Desarrollo A-12.4 Pruebas A-12.5. Corrección de fallos A-12.6. Implantación
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
179
FIN O META OBJETIVO GENERAL O PROPOSITO
OBJETIVOS ESPECIFICOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES DELSISTEMA COMPONENTE/ PRODUCTO ACTIVIDADES
OE-04. Gestionar la facturación del servicio de alojamiento
RFS-07. Registro de información de factura servicio alojamiento
C-13. Ingreso factura
A-13.1 Análisis detallado de Requerimientos A-13.2 Diseño detallado A-13.3 Desarrollo A-13.4 Pruebas A-13.5. Corrección de fallos A-13.6. Implantación
C-14. Edición factura
A-14.1 Análisis detallado de Requerimientos A-14.2 Diseño detallado A-14.3 Desarrollo A-14.4 Pruebas A-14.5. Corrección de fallos A-14.6. Implantación
C-15. Eliminación factura
A-15.1 Análisis detallado de Requerimientos A-15.2 Diseño detallado A-15.3 Desarrollo A-15.4 Pruebas A-15.5. Corrección de fallos A-15.6. Implantación
RFS-08. Consulta de información de facturas servicio alojamiento
C-16. Consulta factura
A-16.1 Análisis detallado de Requerimientos A-16.2 Diseño detallado A-16.3 Desarrollo A-16.4 Pruebas A-16.5. Corrección de fallos A-16.6. Implantación
OE-05. Gestionar el informe de facturación semanal del hotel por
servicios de alojamiento.
RFS-09. Registro de información informe de facturación semanal del hotel por servicios de alojamiento.
C-17. Ingreso Informe
A-17.1 Análisis detallado de Requerimientos A-17.2 Diseño detallado A-17.3 Desarrollo A-17.4 Pruebas A-17.5. Corrección de fallos A-17.6. Implantación
C-18. Edición Informe
A-18.1 Análisis detallado de Requerimientos A-18.2 Diseño detallado A-18.3 Desarrollo A-18.4 Pruebas A-18.5. Corrección de fallos A-18.6. Implantación
C-19. Eliminación Informe
A-19.1 Análisis detallado de Requerimientos A-19.2 Diseño detallado A-19.3 Desarrollo A-19.4 Pruebas A-19.5. Corrección de fallos A-19.6. Implantación
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
180
FIN O META OBJETIVO GENERAL O PROPOSITO
OBJETIVOS ESPECIFICOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES DELSISTEMA COMPONENTE/ PRODUCTO ACTIVIDADES
RFS-10. Consulta de información de informe de facturación semanal del hotel por servicios de alojamiento.
C-20. Consulta informe
A-20.1 Análisis detallado de Requerimientos A-20.2 Diseño detallado A-20.3 Desarrollo A-20.4 Pruebas A-20.5. Corrección de fallos A-20.6. Implantación
Tabla 55. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMEAP.
Matriz Estructura Analítica del proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
181
Actividad 9. Administración de la estructura del proyecto.
Actividad 9.1. Elaborar la Matriz de Administración de la estructura del
proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
182
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PMAEP. Matriz Administración Estructura del proyecto Versión plantilla: 1.0 Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: EEAP. Estructura analítica del proyecto Técnica de elicitación: Exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012 DECLARACION DEL ALCANCE FIN: F-01 Aumento de demanda en los servicios de alojamiento del hotel OBJETIVO GENERAL: OG-01 Desarrollar un Sistema de información para la gestión de reservas de habitaciones del hotel adecuado/confiable
No. OBJETIVOS
ESPECIFICOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES DELSISTEMA
COMPONENTE/ PRODUCTO ACTIVIDADES
INDICADORES VERIFICABLES DE LA ACTIVIDAD FUENTES DE
VERIFICACION DE LA ACTIVIDAD
SUPUESTOS DE LA ACTIVIDAD
Recursos Costos
1
OE-01. Gestionar
información de
habitaciones del hotel
RFS-01. Registro de información de habitaciones del hotel
C-01. Ingreso habitación
A-1.1 Análisis detallado de Requerimientos A-1.2 Diseño detallado A-1.3 Desarrollo A-1.4 Pruebas A-1.5. Corrección de fallos A-1.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
C-02. Edición habitación
A-2.1 Análisis detallado de Requerimientos A-2.2 Diseño detallado A-2.3 Desarrollo A-2.4 Pruebas A-2.5. Corrección de fallos A-2.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
C-03. Eliminación habitación
A-3.1 Análisis detallado de Requerimientos A-3.2 Diseño detallado A-3.3 Desarrollo A-3.4 Pruebas A-3.5. Corrección de fallos A-3.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
RFS-02. Consulta de información de habitaciones del hotel
C-04. Consulta habitación
A-4.1 Análisis detallado de Requerimientos A-4.2 Diseño detallado A-4.3 Desarrollo A-4.4 Pruebas A-4.5. Corrección de fallos A-4.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
183
No. OBJETIVOS
ESPECIFICOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES DELSISTEMA
COMPONENTE/ PRODUCTO ACTIVIDADES
INDICADORES VERIFICABLES DE LA ACTIVIDAD FUENTES DE
VERIFICACION DE LA ACTIVIDAD
SUPUESTOS DE LA ACTIVIDAD
Recursos Costos
2
OE-02. Gestionar
datos de los clientes del
hotel
RFS-03. Registro de información de clientes del hotel
C-05. Ingreso cliente
A-5.1 Análisis detallado de Requerimientos A-5.2 Diseño detallado A-5.3 Desarrollo A-5.4 Pruebas A-5.5. Corrección de fallos A-5.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
C-06. Edición cliente
A-6.1 Análisis detallado de Requerimientos A-6.2 Diseño detallado A-6.3 Desarrollo A-6.4 Pruebas A-6.5. Corrección de fallos A-6.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
C-07. Eliminación cliente
A-7.1 Análisis detallado de Requerimientos A-7.2 Diseño detallado A-7.3 Desarrollo A-7.4 Pruebas A-7.5. Corrección de fallos A-7.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
RFS-04. Consulta de información de clientes del hotel
C-08. Consulta clientes
A-8.1 Análisis detallado de Requerimientos A-8.2 Diseño detallado A-8.3 Desarrollo A-8.4 Pruebas A-8.5. Corrección de fallos A-8.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
3
OE-03. Gestionar datos de
reservas de habitaciones
del hotel
RFS-05. Registro de información de reservas de habitaciones
C-09. Ingreso reserva
A-9.1 Análisis detallado de Requerimientos A-9.2 Diseño detallado A-9.3 Desarrollo A-9.4 Pruebas A-9.5. Corrección de fallos A-9.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
184
No. OBJETIVOS
ESPECIFICOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES DELSISTEMA
COMPONENTE/ PRODUCTO ACTIVIDADES
INDICADORES VERIFICABLES DE LA ACTIVIDAD FUENTES DE
VERIFICACION DE LA ACTIVIDAD
SUPUESTOS DE LA ACTIVIDAD
Recursos Costos
C-10. Edición reserva
A-10.1 Análisis detallado de Requerimientos A-10.2 Diseño detallado A-10.3 Desarrollo A-10.4 Pruebas A-10.5. Corrección de fallos A-10.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
C-11. Eliminación reserva
A-11.1 Análisis detallado de Requerimientos A-11.2 Diseño detallado A-11.3 Desarrollo A-11.4 Pruebas A-11.5. Corrección de fallos A-11.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
RFS-06. Consulta de información de reservas de habitaciones
C-12. Consulta Reservas
A-12.1 Análisis detallado de Requerimientos A-12.2 Diseño detallado A-12.3 Desarrollo A-12.4 Pruebas A-12.5. Corrección de fallos A-12.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
4
OE-04. Gestionar la facturación del servicio
de alojamiento
RFS-07. Registro de información de factura servicio alojamiento
C-13. Ingreso factura
A-13.1 Análisis detallado de Requerimientos A-13.2 Diseño detallado A-13.3 Desarrollo A-13.4 Pruebas A-13.5. Corrección de fallos A-13.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
C-14. Edición factura
A-14.1 Análisis detallado de Requerimientos A-14.2 Diseño detallado A-14.3 Desarrollo A-14.4 Pruebas A-14.5. Corrección de fallos A-14.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
185
No. OBJETIVOS
ESPECIFICOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES DELSISTEMA
COMPONENTE/ PRODUCTO ACTIVIDADES
INDICADORES VERIFICABLES DE LA ACTIVIDAD FUENTES DE
VERIFICACION DE LA ACTIVIDAD
SUPUESTOS DE LA ACTIVIDAD
Recursos Costos
C-15. Eliminación factura
A-15.1 Análisis detallado de Requerimientos A-15.2 Diseño detallado A-15.3 Desarrollo A-15.4 Pruebas A-15.5. Corrección de fallos A-15.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
RFS-08. Consulta de información de facturas servicio alojamiento
C-16. Consulta factura
A-16.1 Análisis detallado de Requerimientos A-16.2 Diseño detallado A-16.3 Desarrollo A-16.4 Pruebas A-16.5. Corrección de fallos A-16.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
5
OE-05. Gestionar el informe de facturación semanal del
hotel por servicios de alojamiento.
RFS-09. Registro de información informe de facturación semanal del hotel por servicios de alojamiento.
C-17. Ingreso Informe
A-17.1 Análisis detallado de Requerimientos A-17.2 Diseño detallado A-17.3 Desarrollo A-17.4 Pruebas A-17.5. Corrección de fallos A-17.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
C-18. Edición Informe
A-18.1 Análisis detallado de Requerimientos A-18.2 Diseño detallado A-18.3 Desarrollo A-18.4 Pruebas A-18.5. Corrección de fallos A-18.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
C-19. Eliminación Informe
A-19.1 Análisis detallado de Requerimientos A-19.2 Diseño detallado A-19.3 Desarrollo A-19.4 Pruebas A-19.5. Corrección de fallos A-19.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
186
No. OBJETIVOS
ESPECIFICOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES DELSISTEMA
COMPONENTE/ PRODUCTO ACTIVIDADES
INDICADORES VERIFICABLES DE LA ACTIVIDAD FUENTES DE
VERIFICACION DE LA ACTIVIDAD
SUPUESTOS DE LA ACTIVIDAD
Recursos Costos
RFS-10. Consulta de información de informe de facturación semanal del hotel por servicios de alojamiento.
C-20. Consulta informe
A-20.1 Análisis detallado de Requerimientos A-20.2 Diseño detallado A-20.3 Desarrollo A-20.4 Pruebas A-20.5. Corrección de fallos A-20.6. Implantación
• Técnicos • Humanos
Costos para el desarrollo de la actividad
Registros de seguimiento del proyecto
• Recursos financieros disponibles
• Aceptación a satisfacción del componente/producto por parte del cliente.
6
Condiciones Previas • Aprobación del
proyecto por parte de los propietarios del sistema.
• Recursos financieros, técnicos y humanos disponibles.
Tabla 56. Caso de estudio. Metodología para la elicitación de requerimientos de software basada en el marco lógico. Plantilla: PMAEP. Matriz Administración Estructura del proyecto
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
187
Actividad 9.2. Revisar la Matriz de Administración de la estructura del
proyecto.
NOMBRE DEL PROYECTO: Sistema de información para la gestión de reservas de habitaciones de un Hotel Plantilla: PRMAEP. Revisión Matriz de Administración de la estructura del proyecto.
Versión plantilla: 1.0
Analista: Estela Pineda Fecha: 08/09/2012 Versión en desarrollo: 1.0 Fuente: PMAEP. Matriz Administración Estructura del proyecto Técnica de elicitación: Exploración de documentación existente Aprobó: Pedro Rojas Fecha aprobación: 10/09/2012 No. Condiciones Si No
1 Se indican claramente el Fin(meta), el objetivo general, los objetivos específicos, los requerimientos, los productos/componentes, las Actividades, indicadores, fuentes de verificación y supuestos a nivel de actividad.
√
2 El fin del proyecto está claramente definido √ 3 Se tiene un objetivo general o propósito √ 4 La relación entre el fin y el objetivo general es lógica √
5 Los objetivos específicos, y requerimientos y están expuestos claramente y tiene relación con el objetivo general. √
6 Cada producto/componente es necesario para lograr cada requerimiento y objetivo específico del proyecto √
7 No falta ninguno de los productos/componentes necesarios para lograr cada objetivo del proyecto y requerimiento √
8 Las actividades específicas para cada producto/componente son necesarias para producir el componente √
9 Los insumos descritos como indicadores a nivel de actividad, definen los recursos y costos requeridos. √
10 La relación entre recursos y las actividades es realista √
11 La columna de fuentes de verificación a nivel de actividad, señala donde encontrar información para verificar los indicadores √
12 Los supuestos planteados producen condiciones necesarias para cumplir las actividades. √ 13 Existen unas condiciones previas para el desarrollo de proyecto √
Tabla 57. Caso de estudio. Metodología para la elicitación de requerimientos de
software basada en el marco lógico. Plantilla: PRMAEP. Revisión Matriz de Administración de la estructura del proyecto.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
188
CAPITULO 6. VALIDACION DE LA PROPUESTA
6.1. Modelo de validación seleccionado
Para la validación de la metodología propuesta se diseña un cuestionario
que consta de 33 preguntas agrupadas en 4 áreas y las observaciones y/o
recomendaciones por parte del evaluador (Ver ANEXO I. Modelo de cuestionario).
Las áreas de agrupación son las siguientes:
I. ANALISIS DE LA METODOLOGIA CON RESPECTO A SU
PRESENTACION
II. ANALISIS DE LA METODOLOGIA CON RESPECTO A LA
ELICITACION DE REQUERIMIENTOS DE SOFTWARE
III. ANALISIS DE LA METODOLOGIA CON RESPECTO A LOS USUARIOS
DE LA METODOLOGIA
IV. OBSERVACIONES Y/O RECOMENDACIONES FINALES POR PARTE
DEL EVALUADOR EXPERTO
6.2. Expertos seleccionados
Para llevar la validación de la metodología propuesta, se seleccionaron tres
profesionales cuya formación y experiencia está relacionada con ingeniería de
requerimientos en proyectos de software y en gestión de proyectos de
tecnología de información. A cada uno de los expertos se le hizo entrega de un
extracto de la propuesta de la metodología plateada en este trabajo de tesis,
junto con el ejemplo aplicativo de la misma metodología. Además se les
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
189
entregó el cuestionario evaluativo para obtener un juicio de valor sobre la
utilidad de la metodología.
Los expertos seleccionados son los siguientes:
Experto 1.
Nombre: Ing. Ariel Adolfo Rodríguez Hernández.
- Título de grado: Ingeniero de sistemas.
- Título de posgrado o especialización: Magíster en Software Libre con
énfasis en administración Web y sistemas de comercio electrónico.
Certificado en ITIL V3 Foundation y en proceso de certificación como
evaluador por competencias.
- Experiencia laboral relacionada: Docente investigador, con experiencia
de seis años en áreas de e-learning, ingeniera de sistemas y ciencias de
la computación. Director del grupo de investigación TICA: Tecnología,
Investigación y Ciencia Aplicada; conferencista a nivel regional, nacional
e internacional en temas de tecnología, informática y computación.
Experiencia en administración y dirección de actividades de
investigación y extensión, en dirección de programas académicos y en
diseño curricular de programas de educación superior. Experiencia
profesional y laboral de más de diez años en consultoría relacionada con
desarrollo Web, e-learning, administración y desarrollo sistemas de
información. Par revisor Revista IEEE América Latina y Departamento
Ciencia Tecnología e Innovación COLCIENCIAS.
Experto 2
Nombre: Ing. Francisco Arnaldo Vargas Bermúdez
- Título de grado: Ingeniero de sistemas
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
190
- Título de posgrado o especialización: Especialización en Gerencia de
Sistemas Informáticos, Maestría en Ciencias de la Información y las
Comunicaciones con énfasis en Teleinformática. Y cursando Doctorado
en Ciencia y Tecnología Informática.
- Experiencia laboral relacionada: Docente universitario en el área
ingeniería de sistemas y especialización en gerencia de sistemas
informáticos, con formación en el área de TICS y e-learning; y con
experiencia en educación virtual. Investigador en temas relacionados
con computación grid, redes inalámbricas de geosensores, persistencia
en la grid y Gobierno TI; miembro activo del grupo internacional de
investigación en informática comunicaciones y gestión del conocimiento
– GICOGE: Este grupo basa su trabajo en los temas relacionados con
calidad e innovación en informática, comunicaciones, ingeniería y
gestión del conocimiento para el desarrollo organizacional contribuyendo
activamente al desarrollo y la competitividad del país. Dicho grupo
adelanta un trabajo de investigación conjunto con el grupo OVIEDO3 de
la Universidad de Oviedo, la Facultad de Informática de la Pontificia
Universidad de Salamanca y el Grupo de Inteligencia Artificial de la
Universidad Central de las Villas; en temas relacionados con la
ingeniería web, la gestión del conocimiento e inteligencia computacional
respectivamente.
Experto 3
Nombre: Ing. Mauro Callejas
- Título de grado: Ingeniero de sistemas
- Título de posgrado o especialización: Especialista en Ingeniería de
Software, Magíster en Ciencias Computacionales; actualmente
desarrolla tesis de Doctorado en Ciencia y Tecnología Informática en la
Universidad Carlos III de Madrid España.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
191
- Experiencia laboral relacionada: Profesor Asistente, Universidad
Pedagógica y Tecnológica de Colombia - UPTC, Facultad de Ingeniería,
Escuela de Sistemas y Computación -Tunja, Colombia. Director del
programa de Ingeniería de Sistemas y Computación de la UPTC y
Director del Grupo de Investigación en Software, GIS-UPTC,
COL0037219. Investigador principal proyecto software libre.
6.3. Resultado de la evaluación de los expertos
Tomando como base el cuestionario modelo que se aplicó a los evaluadores
expertos para evaluar la metodología propuesta se puede realizar el siguiente
análisis:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
192
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DEL SOFTWARE BASADA EN EL MARCO LOGICO
Evaluación de la Metodología EVALUADOR
EXPERTO 1 EVALUADOR EXPERTO 2
EVALUADOR EXPERTO 3
No. ASPECTO EVALUADO SI NO SI NO SI NO I. ANALISIS DE LA METODOLOGIA CON RESPECTO A SU PRESENTACION 1 Se describe claramente el objetico de la metodología √ √ √
2 Se describe claramente los conceptos, método, las técnicas y las herramientas que componen la metodología √ √ √
3 Las actividades propuestas son coherentes con el objetivo de la metodología en la elicitación de requerimientos de software. √ √ √
4 Se presenta en forma gráfica la estructura de la metodología √ √ √ 5 Las actividades planteadas tienen un orden lógico e incremental √ √ √ 6 Las actividades planteadas emplean técnicas y herramientas para su desarrollo √ √ √
7 En cada actividad se obtiene un producto que apoye el proceso de la elicitación de requerimientos de software √ √ √
8 Las técnicas planteadas están acordes con el objetivo de la metodología √ √ √ 9 Se indica en qué actividad emplear cada técnica √ √ √
10 Se describen claramente las técnicas planteadas √ √ √ 11 Las herramientas planteadas (esquemas y plantillas) están acordes con el objetivo de la metodología √ √ √ 12 Se indica en que actividad emplear cada herramienta (esquemas y plantillas) √ √ √ 13 Cada esquema y plantilla contiene un nomenclador que lo identifique √ √ √ 14 Los esquemas y plantillas incluyen información de versionado para la gestión del control de cambios √ √ √ 15 Se indican los roles de los miembros de desarrollo del proyecto √ √ √ 16 Los roles están acordes con las actividades planteadas en la metodología √ √ √
II. ANALISIS DE LA METODOLOGIA CON RESPECTO A LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE
17 La metodología ayuda a identificar/validar el problema del sistema actual √ √ √ 18 La metodología ayuda a identificar, analizar, clasificar a los involucrados en el problema √ √ √ 19 La metodología ayuda a identificar, analizar, clasificar a los involucrados en el desarrollo del proyecto √ √ √ 20 La metodología ayuda a identificar los problemas de los involucrados √ √ √
21 La metodología propuesta incluye en el análisis del problema a los involucrados relacionados con éste. √ √ √
22 La metodología ayuda a identificar/validar el fin, objetivo general y específicos del sistema a desarrollar √ √ √
23 La metodología ayuda a identificar los requerimientos funcionales y no funcionales del sistema de software a desarrollar √ √ √
24 Los requerimientos identificados están relacionados con el fin, objetivo general y específicos del sistema a desarrollar √ √ √
25 Los requerimientos identificados son realistas / acordes con las necesidades del problema y con las de los involucrados afectados √ √ √
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
193
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DEL SOFTWARE BASADA EN EL MARCO LOGICO
Evaluación de la Metodología EVALUADOR
EXPERTO 1 EVALUADOR EXPERTO 2
EVALUADOR EXPERTO 3
No. ASPECTO EVALUADO SI NO SI NO SI NO
26 La metodología ayuda a identificar por cada objetivo las actividades a desarrollar para su cumplimiento √ √ √
27 La metodología ayuda a realizar un seguimiento y control de las actividades planteadas para el logro de los objetivos y cumplimiento de los requerimientos √ √ √
28 La metodología ayuda a organizar el proyecto en una estructura analítica viable √ √ √
29 La metodología ayuda a administrar la estructura analítica del proyecto, orientada al cumplimiento de los objetivos y requerimientos del sistema de software a desarrollar √ √ √
30 La metodología propuesta apoya el proceso de elicitación de requerimientos de software √ √ √ III. ANALISIS DE LA METODOLOGIA CON RESPECTO A LOS USUARIOS DE LA METODOLOGIA 31 Los usuarios de la metodología corren riesgos al adoptar la metodología *√ √ **√ 32 Los usuarios de la metodología requieren de algún soporte adicional para el uso de la metodología √ √ √
33 La metodología propuesta demanda algún nivel de conocimiento técnico, habilidades y experiencia del usuario para su uso. √ √ √
IV. OBSERVACIONES Y/O RECOMENDACIONES FINALES POR PARTE DEL EVALUADOR EXPERTO
EXP.1
Experto 1: El trabajo desarrollado es muy interesante y tomar el marco lógico para plantear un modelo de elicitación de requerimientos para el desarrollo de software es interesante, se ve que la autora hizo un muy buen análisis del modelo de marco lógico y logro proponer una metodología ágil y versátil para los fines planteados.
EXP.2 Experto 2: Felicito a la autora del presente trabajo, es muy interesante y útil para el ejercicio de la construcción de sistemas de información; presenta gran organización y facilidad en su aplicación. Existen algunos problemas de redacción, revisar
EXP.3 Experto 3: Se debe presentar como un anexo (en la medida de lo posible) una mini guía de la propuesta metodológica, esto con el fin de hacerla popular y reconocida de manera rápida.
Tabla 58. Evaluación de la Metodología para la elicitación de requerimientos de software basada en el marco lógico
*√ Obviamente toda tarea o conlleva riesgos pero se deben correr y la validación de esta metodología en un caso real ayuda a ajustarla. **√ Los normales en esta clase de propuesta
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
194
Según las sugerencias realizadas por los evaluadores expertos se procede a
hacer las siguientes modificaciones en la metodología propuesta:
Se adiciona una casilla de la versión de la plantilla y esquema según
corresponda, y la aprobación y fecha de la misma, con base a la
recomendación del evaluador experto No.1.
El evaluador Experto No. 2 indica que se debería ampliar la descripción de
las técnicas planteadas en la metodología, se analiza la sugerencia y se
concluye que el documento las describe.
El evaluador experto No. 2 indica que la metodología ayuda a
identificar/validar los requerimientos funcionales, pero las no funcionales no es
muy claro. Cabe anotar que los requerimientos no funcionales son educidos
por el rol del analista experto con base a los requerimientos funcionales.
El evaluador No. 2 también indica que se los usuarios de la metodología
debieran tener un conocimiento mas profundo de las técnicas a emplear en la
metodología y un conocimiento de la ingeniería del software, la cual si se hace
necesario para la implementación de la metodología.
Con base en lo anterior se concluye lo siguiente por cada ítem evaluado:
• Análisis de la metodología con respecto a su presentación.
La metodología propuesta presenta un objetivo claro, describe los
conceptos, métodos y técnicas que componen la metodología, presenta unas
actividades coherentes con el objetivo de la metodología, presenta
gráficamente la estructura de la metodología, con actividades que se
desarrollan el orden lógico e incremental y que presentan un producto que
apoya el proceso para la elicitación de requerimientos de software.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
195
Las técnicas y herramientas están acordes con la metodología y se indica
claramente en qué actividades se emplean.
Igualmente se indican los roles de las personas participantes en cada
actividad en el desarrollo de la metodología.
• Análisis de la metodología con respecto a la elicitación de requerimientos de
software.
La metodología propuesta ayuda a identificar/validar el problema del sistema
actual, a identificar, analizar, clasificar a los involucrados en el problema y con
el desarrollo del proyecto.
Identifica/valida el fin, objetivo general y objetivos específicos del sistema a
desarrollar, junto con los requerimientos funcionales y no funcionales acordes
con las necesidades del problema.
La metodología ayuda a organizar el proyecto en una estructura analítica y
su administración.
La metodología propuesta ayuda en la elicitación de requerimientos de
software.
• Análisis de la metodología con respecto a los usuarios de la metodología.
Los usuarios de la metodología podrían correr los riesgos normales al
adoptarla, y no requieren un soporte adicional para su empleo.
Se requiere un nivel de conocimiento de la ingeniería de software, y
habilidad en el dominio de alguna de las técnicas citada en la metodología.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
196
• Observaciones y/o recomendaciones finales por parte del evaluador
experto.
El evaluador No. 1 cita que es interesante la aplicación del modelo de marco
lógico para el proceso de la elicitación de requerimientos para el desarrollo de
software, y cita que se logró proponer una metodología ágil y versátil para los
fines planteados.
Cabe resaltar la observación del Evaluador No. 2 en la que indica que esta
metodología es interesante y útil para el ejercicio de la construcción de
sistemas de información, es organizada y fácil de aplicar.
En cuanto a la mini guía de la metodología se puede desarrollar a la medida
que se pretenda hacer popular la metodología, como lo sugiere el evaluador
experto No. 3
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
197
CAPITULO 7. CONCLUSIONES Y APORTACIONES DE ESTA TESIS
7.1. Conclusiones
Con la elaboración de este trabajo de investigación se obtuvieron las
siguientes conclusiones.
7.1.1. Valoración sobre la investigación documental
En el estudio documental de este trabajo de investigación se incluyó el tema
de los requerimientos de software, su clasificación y su procedencia. Al igual
se estudió la ingeniería de requerimientos, los procesos, y se centró finalmente
en el subproceso de la elicitación de requerimientos de software. Esto como
base de este proyecto para el entendimiento de los requerimientos a elicitar, y
la relación del subproceso de la elicitación con los demás subprocesos de la
ingeniería de requerimientos. El estudio del subproceso de la elicitación, y sus
actividades fueron la base para el diseño de la metodología propuesta.
Se realizó un estudio de los estándares y modelos guía para procesos de
ingeniería de sistemas y de desarrollo de software, como son ISO/IEC 26702,
IEEE std. 1233, CMMI, ISO/IEC 15504 y RUP, como guía comparativa de las
actividades planteadas en la elicitación de requerimientos, los productos y las
técnicas.
Igualmente se realizó el estudio de la metodología de marco lógico, sus
etapas, fases, actividades y técnicas, enfatizando en las fases de identificación
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
198
y diseño, como base para la adaptación a la metodología propuesta para la
elicitación de requerimientos de software.
7.1.2. Valoración del problema
En el capítulo 3 se describen los fracasos en los proyectos de software y los
problemas existentes en el proceso de la elicitación de requerimientos, según
grupos de estudio especializados en obtener información de proyectos fallidos
de software y el combatir las causas de los fracasos, como es el Standish
Group. ESI y diferentes autores reconocidos en el área de la ingeniería de
requerimientos. Concluyendo los siguientes problemas:
- Adquirir el conocimiento de los usuarios y de otras fuentes
- Especificaciones y requisitos incompletos
- Falta de involucramiento e información por parte de los usuarios.
- Especificaciones y requisitos cambiantes
- Problemas de alcance
- Comprensión y entendimiento entre usuarios y desarrolladores
Los estudios realizados por el ESI (European Software Institute), detectó que
los ingenieros de software encuentran mayores dificultades durante la etapa de
ingeniería de requerimientos, que en el resto de las fases de desarrollo de
software.
Igualmente se concluyeron las siguientes dificultades en el proceso de la
elicitación de requerimientos:
- Conocimiento no disponible, en forma adecuada.
- Usuarios con ideas no claras de lo que quieren, y con dificultades para
describir su conocimiento el dominio.
- No entendimiento de terminología entre usuarios y analistas.
- Disponibilidad e intereses de los usuarios ante el nuevo sistema.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
199
Los autores estudiados también describen las fallas de identificar
correctamente los requerimientos del sistema pueden dar como resultado lo
siguiente:
- El sistema puede costar más de lo proyectado
- El sistema puede ser entregado después de lo pactado
- El sistema puede no cumplir con las expectativas de los usuarios, y
puede provocar que no usen el sistema.
- Una vez en producción, los costos de mantenimiento y mejora del
sistema pueden ser altos.
- El sistema puede ser poco confiable, teniendo la tendencia a fallos.
- La reputación del equipo de desarrollo.
7.1.3. Valoración de la solución
Con esta propuesta de metodología para la elicitación de requerimientos de
software basa en el marco lógico podemos citar:
• La metodología presenta un desarrollo por actividades incremental cíclico
y dinámico, en la que se pueden adicionar, modificar y reevaluar los
elementos identificados en cada una de estas actividades.
• Ya que en la elicitación de requerimientos se trabaja con un conjunto de
expertos en el dominio del problema, las técnicas de grupo planteadas en
esta metodología, proporcionan rapidez, y mecanismos de obtención y
negociación e integración de convergencia de opiniones de los
participantes involucrados.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
200
• El apoyo es significativo en el proceso de identificación, clasificación y
análisis de involucrados, con respecto a sus intereses y la negociación de
los requerimientos en el proceso de desarrollo de software.
• Se promueve la participación de las personas o grupos de involucrados,
en el que hay una discusión secuencial y consensos de las partes, en
todas las actividades de la metodología.
• Aborda problemas, necesidades, objetivos, acciones y requerimientos,
reales de los beneficiarios.
• El énfasis en el análisis inicial de los problemas (causas, efectos), y su
conversión en objetivos, hace que el enfoque de los objetivos a cumplir
sea más preciso, en este caso orientado a requerimientos de dominio,
negocio y usuario.
• Con la matriz de administración de la estructura analítica del proyecto, se
consolida el plan de desarrollo del proyecto de software a seguir,
contemplando los elementos identificados en el proceso de elicitación de
requerimientos de software, como son el fin, objetivo general, objetivos
específicos, requerimientos funcionales, componentes y actividades,
llevando un seguimiento y control con indicadores verificables, fuentes de
verificación y supuestos por cada actividad, para alcanzar el objetivo
principal o meta.
• El que la metodología utilice herramientas como plantillas y esquemas,
hace que el proceso sea entendible, documentado y controlado
constantemente.
• La matriz de administración de la estructura analítica del proyecto,
contempla los elementos identificados en el proceso de elicitación de
requerimientos de software, como son el fin, objetivo general, objetivos
específicos, requerimientos funcionales, componentes y actividades.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
201
7.1.4. Valoración del caso de estudio
La metodología propuesta se aplicó a un caso de estudio simulado, y se
pudo concluir lo siguiente:
• La metodología propuesta hace un valioso aporte en la identificación y
análisis de involucrados y participantes en el proyecto caso de estudio, a
tener en cuenta tanto para el desarrollo del proyecto como para
involucramiento en el proceso de elicitación de requerimientos de
software.
• La metodología propuesta aborda problemas, necesidades, objetivos,
acciones y requerimientos, reales de los beneficiarios del proyecto caso
de estudio, por su alto involucramiento y negociación en las actividades
de identificación del problema, identificación de objetivos y acciones para
el desarrollo del proyecto.
• La existencia de herramientas como plantillas y esquemas, hace que el
desarrollo del proyecto en la elicitación de requerimientos de software,
esté documentado y controlado, pudiendo realizar versionados de cada
uno.
• La matriz de administración de la estructura analítica del proyecto, apoya
en el proceso de seguimiento y control para el cumplimiento de los
requerimientos y objetivos del proyecto caso de estudio.
7.1.5. Respuesta a los interrogantes de investigación
Las respuestas a los interrogantes planteados en la sección 3.3 se pueden
resumir en lo siguiente:
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
202
En el capítulo 4 contempla el análisis del aporte que puede dar el marco
lógico al desarrollo de proyectos de software, como una herramienta que se
orienta a facilitar el proceso de conceptualización, diseño, ejecución y
evaluación de proyectos. Y Se pudo concluir que esta metodología puede
apoyar el proceso de elicitación de requerimientos de software, especialmente
en las fases de identificación y diseño, ya que están relacionadas directamente
con el diagnóstico, planteo de los objetivos, definición del alcance,
componentes y actividades base para el desarrollo de requerimientos de
software. Apoyando igualmente a la comunicación entre las partes interesadas
y la negociación.
También se realiza en el capítulo 4 el desarrollo de la metodología
propuesta, respondiendo así a la pregunta de si es posible adaptar la
metodología de marco lógico a la elicitación de requerimientos de software,
diferenciándola de la metodología de marco lógico, en que la metodología
propuesta está compuesta de 7 elementos los cuales son: conceptos, objetivos,
actividades, productos elicitados, técnicas, herramientas y roles y
responsabilidades. A su vez las actividades que contempla son 9, las cuales
son desarrolladas en forma cíclica incremental con la opción de regresar a la
anterior actividad si se hace necesario para la modificación o adición de nuevos
elementos necesarios para su desarrollo. El enfoque que se le da a estas
actividades es el desarrollo de la elicitación de requerimientos de software, y
por tal motivo se modifican y/o adicionan actividades hacia la identificación y
revisión de problemas, necesidades, objetivos, acciones, requerimientos
funcionales y no funcionales, abarcando también la estructura y administración
de estos requerimientos en el proyecto de software a desarrollar. Todo lo
anterior apoyado en un conjunto de técnicas y herramientas (esquemas y
plantillas), que permiten en forma documentada llevar un control de
versionados y aprobación por parte de los involucrados en el proyecto.
Adicionalmente se incluyen los roles participantes en el desarrollo del proyecto
y sus funciones en cada actividad de la metodología propuesta.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
203
7.2. Futuras líneas de investigación
Podemos citar como líneas de investigación futura las siguientes:
• Diseñar una evaluación en que se incluya la implementación de
indicadores para analizar el comportamiento de la metodología propuesta
en la elicitación de requerimientos de software en proyectos reales.
• Incluir en la metodología planteada, los demás procesos de la ingeniería
de requerimientos como son el análisis, especificación y validación.
• Analizar la posibilidad de aplicación de esta metodología como apoyo al
proceso de elicitación de requerimientos de software en las metodologías
ágiles.
• Plantear un modelo de madurez que contemple las áreas de proceso de
la metodología propuesta, las clasifique en categorías y enmarque en
niveles de madurez, incluyendo metas y prácticas específicas para cada
proceso.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
204
CAPITULO 8. BIBLIOGRAFIA
Astigarraga, E. Método DELPHI. Universidad de Deusto. Facultad de CC.EE. y Empresariales. E-20.080 Donostia - San Sebastian.
Bahamonde, J.M. & Rossel, R. (2003). Un Acercamiento a la Ingeniería de
Requerimientos. Universidad Técnica Federico Santa María. http://www.processimpact.com/goodies.shtml. Página web vigente al 09/09/2009.
Banco Interamericano de Desarrollo. BID. Curso Básico de Marco Lógico para
el Diseño y la Conceptualización de Proyectos, basado en un documento oficial de Banco Interamericano de Desarrollo.
Banco Interamericano de Desarrollo. BID. (1997). Evaluación: Una
herramienta de gestión para mejorar el desempeño de los proyectos. Browne, G.J. & Rogich, M.B. (2001). An empirical investigation of user
requirements elicitation: Comparing the effectiveness of prompting techniques. Journal of Management Information Systems.
Bruegge, B., & Dutoit, A. (2002). Ingeniería del software orientado a objetos.
Pearson Educación. México. Bustos, R. (2005). Algunas Herramientas para la intervención en conflictos
ambientales. Centro Nacional de educación ambiental. Camacho. H, Cámara. L., Cascante. R, & Sainz. H. (2001). Acciones de
Desarrollo y Cooperación A.D.C. El Enfoque del marco lógico: 10 casos prácticos, Cuaderno para la identificación y diseño de proyectos de desarrollo. ISBN: 84-87082-17/3. D.L.: M-41850-2001
Christel, M. G. & Kang, K. C. (1992). Issues in Requirements Elicitation.
Technical Report CMU/SEI-92-TR-12. ESC-TR-92-012. Requirements Engineering Project, Carnegie Mellon University. USA. http://www.sei.cmu.edu/reports/92tr012.pdf. Página web vigente al 17/04/2012.
Cid. M. A. (2006). Proyecto de investigación. Impacto de los sistemas de
administración de proyectos por resultados como herramienta de gestión de conocimiento usando el modelo de marco lógico.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
205
CIMAS. Observatorio Internacional de ciudadanía y medio ambiente sostenible. (2009). Metodologías participativas, manual. Madrid.
Dávila, N. D. (2001). Una guía para extraer, analizar, especificar y validar los
requerimientos de un proyecto. Tesis de licenciatura en análisis de sistemas. Universidad ort uruguay. Facultad de ingeniería. Ingeniería de requerimientos. http://webs.montevideo.com.uy/nicolasd. Página web vigente al 09/09/2009.
Real Academia Española. (2010). Diccionario de la Lengua Española.
Vigésima segunda edición. http://buscon.rae.es/draeI/. Página web vigente al 05/09/2011.
Dienel, P, & Harms, H. (2000). Repensar la Democracia. Los Núcleos de
Intervención Participativa. Barcelona, Ed. Del Serbal. Durán, A. & Bernárdez, B. (2000). Metodología para la Elicitación de Requisitos
de Sistemas Software. Versión 2.1. Departamento de Lenguajes y Sistemas Informáticos. Universidad de Sevilla.
Durán, A. & Bernárdez, B. (2002). Metodología para la Elicitación de Requisitos
de Sistemas Software. Versión 2.3. Departamento de Lenguajes y Sistemas Informáticos. Universidad de Sevilla. http://www.dsi.uclm.es/asignaturas/42541/pdf/metodologia_elicitacion.pdf. Página web vigente al 09/04/2012.
Emam, K.E., Drouin, J.N., & Melo, W. (2003). SPICE: The Theory and Practice
of Software Process Improvement and Capability Determination, IEEE Computer Society Press, 1998. Leffingwell, Dean, and Don Widrig. Managing Software Requirements: A Use Case Approach. Second edition. Addison- Wesley.
ESA Comité de Estandarización y Control de Software (BSSC). (2003). Guía
para la aplicación de Estándares de Ingeniería de Software ESA (Agencia Espacial Europea). Para proyectos de software pequeños. (Revisado 2003). . ESA-PSS-05-0. .European Space Agency / Agence Spatiale Européenne (Agencia Espacial Europea). 8-10, rue Mario -Nikis, 75738 PARIS CEDEX, Francia. BSSC(96) 2. Número 1.
European Software Institute. ESI. ESPITI. (1996). European User Survey
Results. Informe Técnico. ESI–1996– 95104. Gómez, M. & Sainz, H. (1999). El ciclo de gestión del proyecto de cooperación
al desarrollo: aplicación del marco lógico. CIDEAL, Madrid. Gutiérrez, M. (2001). Administración para la calidad. Conceptos Administrativos
del Control Total de Calidad. Editorial Limusa. Noriega Editores.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
206
Hadad, G., Doorn, J., Kaplan, G. (2009). Explicitar Requisitos del Software usando Escenarios. Departamento de Ingeniería e Investigaciones. Tecnológicas, UNLaM, Argentina. INTIA, Facultad de Ciencias Exactas, UNICEN, Argentina. http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER09/hadad.pdf. Página web vigente al 09/04/2012.
Haugland, C., Gjos, T., Hagen, S., Ronning, A., Samset, K., Sletten, E., Stoll, I.
& Strand, A. Enfoque del marco lógico como herramienta para planificacion y gestion de proyectos orientados por objetivos.
IEEE Computer Society. (2004). SWEBOK. Guide to the Software Engineering.
Body of Knowledge. Order Number C2330. ISBN 0-7695-2330-7. INTECO. Instituto Nacional de Tecnologías de la Comunicación. (2008). Guía
Avanzada de Gestión de requisitos. España. INTECO. Instituto Nacional de Tecnologías de la Comunicación. (2008). Guía
Práctica de Gestión de requisitos. España. ISO/IEC 15504-5. (E). (2006). International standard. Information technology -
Process Assessment - Part 5: An exemplar Process Assessment Model. Technologies de l'information - Évaluation des processus. First edition.
ISO/IEC 26702. (2007). IEEE Std 1220-2005. Systems engineering -
Application and management of the systems engineering process. First edition.
Jacobson, I., Booch, G. & Rumbaugh, G. (2000). El Proceso Unificado de
Desarrollo de Software. Madrid. Pearson Educación S.A. Kotonya, G. & Sommerville, I. (1998). Requirements engineering: processes
and techniques. UK. John Wiley & Sons. Pfleeger, S. (2002). Ingeniería del software. Teoría y Práctica. Primera edición.
Buenos Aires. Pearson education. Loucopoulos, P. & Karakostas, V. (1995). System Requirements Engineering.
McGraw-Hill International series in Software Engineering. ISBN 0-07-707843-8
Montalván, G. Curso de Marco Lógico. Curso 1. Programa de entrenamiento
para los Países de los Grupos C y D. (ATN/SF-7226-RG). Banco Interamericano de Desarrollo. BID.
Ortegón, E., Pacheco, J.P, & Prieto A. (2005). Metodología del marco lógico
para la planificación, el seguimiento y la evaluación de proyectos y programas. Instituto Latinoamericano y del Caribe de Planificación Económica y Social (ILPES). Área de proyectos y programación de
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
207
inversiones. Santiago de Chile. http://www.extension.uner.edu.ar/sites/default/files/manual%2042%20ILPES%20MML.pdf. Página web vigente al 09/08/2012.
Pressman R. (2010). Ingeniería del software. Un enfoque práctico. Editorial Mc
Graw Hill. Séptima edición. Rational Software Corporation. (2006). Rational Unified Process, Versión
2002.05.00. http://www.ts.mah.se/RUP/RationalUnifiedProcess. Página web vigente al 8/05/2012.
Saiedian, H., & Dale, R. (2000). Requirements engineering: making the
connection between the software developer and customer. Information and Software Technology 42 (2000) 419–428. Department of Computer Science, University of Nebraska at Omaha, Omaha, NE68182-0500, USA. http://www.clab.edc.uoc.gr/application/requirements_engineering.pdf. Página web vigente al 19/04/2012.
Sanchez, N. (2007). El marco lógico. Metodología para la planificación,
seguimiento y evaluación de proyectos. Visión gerencial. ISSN 1317-8822 . Año 6. N° 2. Julio - Diciembre 2007. Pág.: 328-343
Software Engineering Standards Committee of the IEEE Computer Society.
(1990). IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. (Revision and redesignation of IEEE Std 792-1983). IEEE-SA Standards Board. The Institute of Electrical and Electronics Engineers.
Software Engineering Standards Committee of the IEEE Computer Society.
(1998). IEEE Std 830. IEEE Recommended Practice for Software Requirements Specifications. IEEE-SA Standards Board. The Institute of Electrical and Electronics Engineers, Inc. ISBN 0-7381-0332-2. http://www.mug.org.ar/Descargas/Jornadas/default.aspx. Página web vigente al 09/10/2009.
Software Engineering Standards Committee of the IEEE Computer Society.
(1998). IEEE Std 1233. 1998. IEEE Guía para el desarrollo de Especificaciones de Requerimientos de Sistemas. (incluye IEEE Std 1233–1996. e IEEE Std 1233a-1998). IEEE-SA Standards Board. The Institute of Electrical and Electronics Engineers.
Software Engineering Institute, Carnegie Mellon University. (2010). CMMI® for
Development, Version 1.3. CMMI-DEV, V1.3. Improving processes for developing better products and services. TECHNICAL REPORT CMU/SEI-2010-TR-033. ESC-TR-2010-033. Software Engineering Process Management Program. http://www.sei.cmu.edu/reports/10tr033.pdf . Página web vigente al 21/04/2012.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
208
Sommerville, I. (2005). Ingeniería de software. 7 Edición. México: Addison –
Wesley. Sommerville, I. (2011). Ingeniería de software. 9 Edición. México. Pearson
Educación. Standish Group. The Chaos Report. (2004). http://blog.standishgroup.com/.
Página web vigente al 03/09/2011. Standish Group. The Chaos Report. (2009). http://blog.standishgroup.com/.
Página web vigente al 03/09/2011. Thayer, R. & Dorfam, M. (2000). Software Requirements Engineering. 2 ed. Los
Alamitos, California: IEEE Computer Science Press. Thayer, R. (1998). "Software Engineering Project management", IEEE
Computer Society. Villasante, T.R., Montañés, M., Martín, P. (2001). Prácticas locales de
creatividad social. El viejo topo. Madrid. Wiegers, K. (2003). Software Requirements. 2 ed. Washington: Microsoft Press.
ISBN 0-7356-1879-8. Página web vigente al 20/04/2012. Whitten. J, & Bentley. L. (2008). Análisis de sistemas: diseño y métodos.
Séptima edición. Mc Graw Hill. México. Whitten. J, Bentley. L, & Barlow. V. (2003). Análisis y Diseño de Sistemas de
Información. Tercera edición. México: Mc Graw Hill. Yourdon, E. (2000). Análisis Estructurado Moderno. México: Pearson. ISBN
968-880-330-0. ASISTENCIA A SEMINARIOS TALLER "Ingeniería de Requerimientos". MUG (Grupo de Usuarios de Microsoft). Lic. Marisa D. Panizzi – Lic. Oscar L. Bravo. (Ciudad de Buenos Aires, 15 de Octubre de 2009, Auditorio MUG, Rivadavia 1479 1º Piso - Oficina A)
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
209
ANEXOS
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
210
ANEXO I. Cuestionario modelo METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA
EN EL MARCO LOGICO EVALUADOR EXPERTO No. ____
I. ANALISIS DE LA METODOLOGIA CON RESPECTO A SU PRESENTACION
1. ¿Esta descrito claramente el objetivo de la metodología?
Rta. _____________________________________________________________________
2. ¿Se describe claramente los conceptos, método, las técnicas y las herramientas que
componen la metodología? Rta. _____________________________________________________________________
3. ¿Las actividades propuestas son coherentes con el objetivo de la metodología en la
elicitación de requerimientos de software? Rta. _____________________________________________________________________
4. ¿Se presenta en forma gráfica la estructura de la metodología?
Rta. _____________________________________________________________________
5. ¿Las actividades planteadas tienen un orden lógico e incremental?
Rta. _____________________________________________________________________
6. ¿Las actividades planteadas emplean técnicas y herramientas para su desarrollo?
Rta. _____________________________________________________________________
7. ¿En cada actividad se obtiene un producto que apoye el proceso de la elicitación de requerimientos de software? Rta. _____________________________________________________________________
8. ¿Las técnicas planteadas están acordes con el objetivo de la metodología?
Rta. _____________________________________________________________________
9. ¿Se indica en qué actividad emplear cada técnica?
Rta. _____________________________________________________________________
10. ¿Se describen claramente las técnicas planteadas?
Rta. _____________________________________________________________________
11. ¿Las herramientas planteadas (esquemas y plantillas) están acordes con el objetivo de la
metodología? Rta. _____________________________________________________________________
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
211
12. ¿Se indica en que actividad emplear cada herramienta (esquemas y plantillas)? Rta. _____________________________________________________________________
13. ¿Cada esquema y plantilla contiene un nomenclador que lo identifique?
Rta. _____________________________________________________________________
14. ¿Los esquemas y plantillas incluyen información de versionado para la gestión del control
de cambios? Rta. _____________________________________________________________________
15. ¿Se indican los roles de los miembros de desarrollo del proyecto?
Rta. _____________________________________________________________________
16. ¿Los roles están acordes con las actividades planteadas en la metodología?
Rta. _____________________________________________________________________
II. ANALISIS DE LA METODOLOGIA CON RESPECTO A LA ELICITACION DE
REQUERIMIENTOS DE SOFTWARE
17. ¿Ayuda la metodología a identificar/validar el problema del sistema actual?
Rta. _____________________________________________________________________ 18. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el problema?
Rta. _____________________________________________________________________
19. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el desarrollo
del proyecto?
Rta. _____________________________________________________________________ 20. ¿Ayuda la metodología a identificar los problemas de los involucrados?
Rta. _____________________________________________________________________
21. ¿La metodología propuesta incluye en el análisis del problema a los involucrados
relacionados con éste? Rta. _____________________________________________________________________
22. ¿Ayuda la metodología a identificar/validar el fin, objetivo general y específicos del sistema
a desarrollar? Rta. _____________________________________________________________________
23. ¿Ayuda la metodología a identificar los requerimientos funcionales y no funcionales del
sistema de software a desarrollar? Rta. _____________________________________________________________________
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
212
24. ¿Los requerimientos identificados están relacionados con el fin, objetivo general y específicos del sistema a desarrollar? Rta. _____________________________________________________________________
25. ¿Los requerimientos identificados son realistas / acordes con las necesidades del problema
y con las de los involucrados afectados? Rta. _____________________________________________________________________
26. ¿Ayuda la metodología a identificar por cada objetivo las actividades a desarrollar para su cumplimiento? Rta. _____________________________________________________________________
27. ¿Ayuda la metodología a realizar un seguimiento y control de las actividades planteadas
para el logro de los objetivos y cumplimiento de los requerimientos? Rta. _____________________________________________________________________
28. ¿Ayuda la metodología a organizar el proyecto en una estructura analítica viable?
Rta. _____________________________________________________________________
29. ¿Ayuda la metodologia a administrar la estructura analítica del proyecto, orientada al
cumplimiento de los objetivos y requerimientos del sistema de software a desarrollar? Rta. _____________________________________________________________________
30. ¿La metodología propuesta apoya el proceso de elicitación de requerimientos de software?
Rta. _____________________________________________________________________
III. ANALISIS DE LA METODOLOGIA CON RESPECTO A LOS USUARIOS DE LA
METODOLOGIA
31. ¿Los usuarios de la metodología podrían correr algún riesgo al adoptar la metodología?
Rta. _____________________________________________________________________
32. ¿Los usuarios de la metodología requerirán de algún soporte adicional para el uso de la metodología? Rta. _____________________________________________________________________
33. ¿La metodología propuesta demanda algún nivel de conocimiento técnico, habilidades y experiencia del usuario para su uso? Rta. _____________________________________________________________________
IV. OBSERVACIONES Y/O RECOMENDACIONES FINALES POR PARTE DEL
EVALUADOR EXPERTO
________________________________________________________________________________________________________________________________________________________
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
213
ANEXO II. Evaluación Experto No. 1
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA
EN EL MARCO LOGICO EVALUADOR EXPERTO No. __1__
I. ANALISIS DE LA METODOLOGIA CON RESPECTO A SU PRESENTACION
1. ¿Esta descrito claramente el objetivo de la metodología? Rta En el trabajo se describe el objetivo de la metodología de forma clara y concreta, así como la estructura de la metodología y la forma de implementarla.
2. ¿Se describe claramente los conceptos, método, las técnicas y las herramientas que
componen la metodología?
Rta La metodología de elicitación de requerimientos de software basada en el modelo de marco lógico que se define en el trabajo está debidamente estructurada a nivel conceptual y metodológico de tal forma que puede ser implementada.
3. ¿Las actividades propuestas son coherentes con el objetivo de la metodología en la
elicitación de requerimientos de software? Rta Las actividades propuestas para el desarrollo de este trabajo están articuladas con el objetivo de la metodología en la elicitación de requerimientos de software y en conjunto cumplen con el objetivo tanto del proyecto como de la metodología en sí.
4. ¿Se presenta en forma gráfica la estructura de la metodología?
Rta Si se diseñó un esquema que visualiza las 9 actividades centrales de la metodología propuesta y su ciclo de desarrollo debidamente diagramado.
5. ¿Las actividades planteadas tienen un orden lógico e incremental?
Rta Si, las actividades propuestas para la metodología guardan un orden y se desarrollan de forma cíclica, visualizando tanto los papeles de trabajo utilizados como los resultados esperados de cada actividad.
6. ¿Las actividades planteadas emplean técnicas y herramientas para su desarrollo?
Rta Si, cada actividad tiene formatos y papeles de trabajo o artefactos según lo define la autora.
7. ¿En cada actividad se obtiene un producto que apoye el proceso de la elicitación de requerimientos de software? Rta Si, cada actividad tiene resultados esperados y sus respectivos productos.
8. ¿Las técnicas planteadas están acordes con el objetivo de la metodología?
Rta Si, se realizó un análisis detallado a nivel de metodologías y en cuanto al marco lógico para llegar a la metodología planteada.
9. ¿Se indica en qué actividad emplear cada técnica?
Rta Si, cada actividad planteada define y describe las técnicas a utilizar para su desarrollo.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
214
10. ¿Se describen claramente las técnicas planteadas? Rta Si se han descrito las técnicas y se realizó un análisis detallado de uso en cada actividad.
11. ¿Las herramientas planteadas (esquemas y plantillas) están acordes con el objetivo de la
metodología? Rta Si, los artefactos y papeles de trabajo definidos e implementados en la metodología guardan coherencia con el objetivo de la metodología.
12. ¿Se indica en que actividad emplear cada herramienta (esquemas y plantillas)?
Rta Si, los artefactos y papeles de trabajo definidos e implementados en la metodología se relaciona su uso en cada actividad.
13. ¿Cada esquema y plantilla contiene un nomenclador que lo identifique?
Rta Si, se evidencia en el documento, aunque solo se usan las siglas, podría crearse un identificador que incluya la versión del esquema o plantilla.
14. ¿Los esquemas y plantillas incluyen información de versionado para la gestión del control
de cambios? Rta Si pero como una casilla, podría crearse dentro del código nomenclador.
15. ¿Se indican los roles de los miembros de desarrollo del proyecto?
Rta No, ya que solo se habla de analista de sistemas, pero no se identificó dentro del ciclo otros roles.
16. ¿Los roles están acordes con las actividades planteadas en la metodología?
Rta Si desde el rol analista, pero en cuanto a aprobaciones para continuar a etapas siguientes no hay definido roles de seguimiento o aprobación.
II. ANALISIS DE LA METODOLOGIA CON RESPECTO A LA ELICITACION DE
REQUERIMIENTOS DE SOFTWARE
17. ¿Ayuda la metodología a identificar/validar el problema del sistema actual?
Rta Si, la metodología propuesta permite analizar el sistema actual e identificar sus problemas o aspectos a mejorar.
18. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el problema?
Rta Si, ya que al documentar procesos y procedimientos a través de los diferentes formatos o plantillas es posible documentar la información de los involucrados.
19. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el desarrollo
del proyecto?
Rta Si, y de forma clara. 20. ¿Ayuda la metodología a identificar los problemas de los involucrados?
Rta Si,
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
215
21. ¿La metodología propuesta incluye en el análisis del problema a los involucrados
relacionados con éste? Rta Si, y aporta información en cuanto al rol que desempeñan.
22. ¿Ayuda la metodología a identificar/validar el fin, objetivo general y específicos del sistema
a desarrollar? Rta Si, la metodología permite identificar el objetivo del sistema e incluso los objetivos de sus subsistemas como tal y sus procesos.
23. ¿Ayuda la metodología a identificar los requerimientos funcionales y no funcionales del
sistema de software a desarrollar? Rta Si, aunque se debería crear dentro de los formatos o papeles del analista en las diferentes actividades espacios para describir y clasificar estos requerimientos.
24. ¿Los requerimientos identificados están relacionados con el fin, objetivo general y
específicos del sistema a desarrollar? Rta Si y se hacen de forma detallada a través de la implementación de la metodología.
25. ¿Los requerimientos identificados son realistas / acordes con las necesidades del problema
y con las de los involucrados afectados? Rta Sí, pero para ello es necesario que el analista de sistemas sea capacitado en cuanto a la metodología propuesta.
26. ¿Ayuda la metodología a identificar por cada objetivo las actividades a desarrollar para su cumplimiento? Rta Sí, pero el éxito de esta parte corresponde también en la capacitación de los analistas del sistema en la metodología.
27. ¿Ayuda la metodología a realizar un seguimiento y control de las actividades planteadas
para el logro de los objetivos y cumplimiento de los requerimientos? Rta Si, ya que se tiene claramente definido la secuencia del proceso, sus documentos de trabajo, formatos y plantillas así como los productos de cada actividad.
28. ¿Ayuda la metodología a organizar el proyecto en una estructura analítica viable?
Rta Si, por su diseño claro y estructurado y el uso del modelo de marco lógico.
29. ¿Ayuda la metodología a administrar la estructura analítica del proyecto, orientada al
cumplimiento de los objetivos y requerimientos del sistema de software a desarrollar? Rta Si, ya que tiene un ciclo de vida y permite documentar cada actividad, de tal forma que podamos documentar los requerimientos y desarrollar una solución.
30. ¿La metodología propuesta apoya el proceso de elicitación de requerimientos de software?
Rta Si, y lo mejor es que tomaron el modelo de marco lógico para apoyar este proceso.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
216
III. ANALISIS DE LA METODOLOGIA CON RESPECTO A LOS USUARIOS DE LA METODOLOGIA
31. ¿Los usuarios de la metodología podrían correr algún riesgo al adoptar la metodología?
Rta Responder esta pregunta con un conocimiento teórico de la misma no es posible. Obviamente toda tarea o conlleva riesgos pero se deben correr y la validación de esta metodología en un caso real ayuda a ajustarla.
32. ¿Los usuarios de la metodología requerirán de algún soporte adicional para el uso de la metodología? Rta No, pero en un futuro y en otro proyecto sería muy interesante crear el software que soportara esta metodología.
33. ¿La metodología propuesta demanda algún nivel de conocimiento técnico, habilidades y experiencia del usuario para su uso? Rta Claro, el analista o el equipo de analistas de sistemas que trabajen deben conocer muy bien la metodología y el modelo de marco lógico, adicionalmente debe conocer muy bien las técnicas y actividades de recolección y documentación de procesos.
IV. OBSERVACIONES Y/O RECOMENDACIONES FINALES POR PARTE DEL
EVALUADOR EXPERTO
El trabajo desarrollado es muy interesante y tomar el marco lógico para plantear un modelo de elicitación de requerimientos para el desarrollo de software es interesante, se ve que la autora hizo un muy buen análisis del modelo de marco lógico y logro proponer una metodología ágil y versátil para los fines planteados. Ing. Ariel Adolfo Rodríguez Hernández
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
217
ANEXO III. Evaluación Experto No. 2 METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA
EN EL MARCO LOGICO
EVALUADOR EXPERTO No. __2__
I. ANALISIS DE LA METODOLOGIA CON RESPECTO A SU PRESENTACION
1. ¿Esta descrito claramente el objetivo de la metodología?
Rta. El objetivo es muy claro
2. ¿Se describe claramente los conceptos, método, las técnicas y las herramientas que
componen la metodología? Rta La descripción es bastante clara.
3. ¿Las actividades propuestas son coherentes con el objetivo de la metodología en la
elicitación de requerimientos de software? Rta Si. Las actividades presentan coherencia con el objetivo de la metodología
4. ¿Se presenta en forma gráfica la estructura de la metodología?
Rta Si.
5. ¿Las actividades planteadas tienen un orden lógico e incremental?
Rta Si, la ejecución de cada una permite continuar de manera lógica y coherente con la siguiente.
6. ¿Las actividades planteadas emplean técnicas y herramientas para su desarrollo?
Rta Si
7. ¿En cada actividad se obtiene un producto que apoye el proceso de la elicitación de requerimientos de software? Rta Así es
8. ¿Las técnicas planteadas están acordes con el objetivo de la metodología?
Rta Totalmente
9. ¿Se indica en qué actividad emplear cada técnica?
Rta Si, es muy claro
10. ¿Se describen claramente las técnicas planteadas?
Rta Debería ampliarse la descripción de las mismas.
11. ¿Las herramientas planteadas (esquemas y plantillas) están acordes con el objetivo de la
metodología?
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
218
Rta Si, su diseño permite un fácil entendimiento y utilización
12. ¿Se indica en que actividad emplear cada herramienta (esquemas y plantillas)?
Rta Si
13. ¿Cada esquema y plantilla contiene un nomenclador que lo identifique?
Rta Si
14. ¿Los esquemas y plantillas incluyen información de versionado para la gestión del control
de cambios? Rta Si
15. ¿Se indican los roles de los miembros de desarrollo del proyecto?
Rta Si
16. ¿Los roles están acordes con las actividades planteadas en la metodología?
Rta Si
II. ANALISIS DE LA METODOLOGIA CON RESPECTO A LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE
17. ¿Ayuda la metodología a identificar/validar el problema del sistema actual?
Rta Si. De una forma muy clara
18. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el problema?
Rta Si
19. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el desarrollo
del proyecto?
Rta Si 20. ¿Ayuda la metodología a identificar los problemas de los involucrados?
Rta Si
21. ¿La metodología propuesta incluye en el análisis del problema a los involucrados
relacionados con éste? Rta SI
22. ¿Ayuda la metodología a identificar/validar el fin, objetivo general y específicos del sistema
a desarrollar? Rta Si
23. ¿Ayuda la metodología a identificar los requerimientos funcionales y no funcionales del
sistema de software a desarrollar?
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
219
Rta Los funcionales Si, los no funcionales no es muy claro
24. ¿Los requerimientos identificados están relacionados con el fin, objetivo general y específicos del sistema a desarrollar? Rta Si, totalmente
25. ¿Los requerimientos identificados son realistas / acordes con las necesidades del problema
y con las de los involucrados afectados? Rta Si_
26. ¿Ayuda la metodología a identificar por cada objetivo las actividades a desarrollar para su cumplimiento? Rta Si
27. ¿Ayuda la metodología a realizar un seguimiento y control de las actividades planteadas
para el logro de los objetivos y cumplimiento de los requerimientos? Rta Si
28. ¿Ayuda la metodología a organizar el proyecto en una estructura analítica viable?
Rta Si
29. ¿Ayuda la metodología a administrar la estructura analítica del proyecto, orientada al
cumplimiento de los objetivos y requerimientos del sistema de software a desarrollar? Rta Si
30. ¿La metodología propuesta apoya el proceso de elicitación de requerimientos de software?
Rta Si
III. ANALISIS DE LA METODOLOGIA CON RESPECTO A LOS USUARIOS DE LA
METODOLOGIA
31. ¿Los usuarios de la metodología podrían correr algún riesgo al adoptar la metodología?
Rta Creo que no tendrían ningún riesgo, por el contrario la metodología permite una fácil identificación de los elementos involucrados en la construcción de un sistema de información, permitiendo con ello obtener un producto que satisface al cliente.
32. ¿Los usuarios de la metodología requerirán de algún soporte adicional para el uso de la metodología? Rta Probablemente un conocimiento más profundo a cerca de las técnicas.
33. ¿La metodología propuesta demanda algún nivel de conocimiento técnico, habilidades y experiencia del usuario para su uso? Rta Si. A pesar que la metodología es muy clara y de fácil uso, las personas involucradas en este tipo de proyectos deben tener conocimientos de ingeniería de software.
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
220
IV. OBSERVACIONES Y/O RECOMENDACIONES FINALES POR PARTE DEL EVALUADOR EXPERTO
Felicito a la autora del presente trabajo, es muy interesante y útil para el ejercicio de la construcción de sistemas de información; presenta gran organización y facilidad en su aplicación. Existen algunos problemas de redacción, revisar. La numeración en algunos casos se repite por ejp. 2.1 En la actividad 4.1 página 69, sugiero que el objetivo sea redactado como tal, es decir, que inicie con un verbo en infinitivo; en general en los gráficos se presenta la misma situación Ing. Francisco Arnaldo Vargas Bermúdez
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
221
ANEXO IV. Evaluación Experto No. 3
METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA
EN EL MARCO LOGICO EVALUADOR EXPERTO No. _3__
I. ANALISIS DE LA METODOLOGIA CON RESPECTO A SU PRESENTACION
1. ¿Esta descrito claramente el objetivo de la metodología?
Rta _Si, es claro el planteamiento
2. ¿Se describe claramente los conceptos, método, las técnicas y las herramientas que
componen la metodología? Rta Si, son claras y bien descritas
3. ¿Las actividades propuestas son coherentes con el objetivo de la metodología en la
elicitación de requerimientos de software? Rta Si, son coherentes
4. ¿Se presenta en forma gráfica la estructura de la metodología?
Rta Si, se presenta un esquema claro
5. ¿Las actividades planteadas tienen un orden lógico e incremental?
Rta. Si, según otras metodologías existentes, ésta posee un proceso ordenado
6. ¿Las actividades planteadas emplean técnicas y herramientas para su desarrollo?
Rta. Si…
7. ¿En cada actividad se obtiene un producto que apoye el proceso de la elicitación de requerimientos de software? Rta. Si
8. ¿Las técnicas planteadas están acordes con el objetivo de la metodología?
Rta. Si son coherentes…
9. ¿Se indica en qué actividad emplear cada técnica?
Rta. Si, dentro del esquema y de manera textual
10. ¿Se describen claramente las técnicas planteadas?
Rta. Si
11. ¿Las herramientas planteadas (esquemas y plantillas) están acordes con el objetivo de la
metodología? Rta. Si, están acordes
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
222
12. ¿Se indica en que actividad emplear cada herramienta (esquemas y plantillas)? Rta. Si, se indica
13. ¿Cada esquema y plantilla contiene un nomenclador que lo identifique?
Rta. Si
14. ¿Los esquemas y plantillas incluyen información de versionado para la gestión del control
de cambios? Rta. Si
15. ¿Se indican los roles de los miembros de desarrollo del proyecto?
Rta. Si
16. ¿Los roles están acordes con las actividades planteadas en la metodología?
Rta. SI
II. ANALISIS DE LA METODOLOGIA CON RESPECTO A LA ELICITACION DE
REQUERIMIENTOS DE SOFTWARE
17. ¿Ayuda la metodología a identificar/validar el problema del sistema actual?
Rta. Claro que si 18. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el problema?
Rta. Si, de manera adecuada
19. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el desarrollo
del proyecto?
Rta. Si, cada Stakeholder 20. ¿Ayuda la metodología a identificar los problemas de los involucrados?
Rta. Si.
21. ¿La metodología propuesta incluye en el análisis del problema a los involucrados
relacionados con éste? Rta. Si
22. ¿Ayuda la metodología a identificar/validar el fin, objetivo general y específicos del sistema
a desarrollar? Rta. Si, además codifica cada uno de ellos
23. ¿Ayuda la metodología a identificar los requerimientos funcionales y no funcionales del
sistema de software a desarrollar? Rta. Si los identifica/revisa
METODOLOGÍA PARA LA ELICITACIÓN DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL MARCO LÓGICO LUZ ESTELA PINEDA F.
223
24. ¿Los requerimientos identificados están relacionados con el fin, objetivo general y específicos del sistema a desarrollar? Rta. Si..
25. ¿Los requerimientos identificados son realistas / acordes con las necesidades del problema
y con las de los involucrados afectados? Rta. Si
26. ¿Ayuda la metodología a identificar por cada objetivo las actividades a desarrollar para su cumplimiento? Rta. Si, además las codifica (A-1.1…..)
27. ¿Ayuda la metodología a realizar un seguimiento y control de las actividades planteadas
para el logro de los objetivos y cumplimiento de los requerimientos? Rta. Si..
28. ¿Ayuda la metodología a organizar el proyecto en una estructura analítica viable?
Rta. Si
29. ¿Ayuda la metodología a administrar la estructura analítica del proyecto, orientada al
cumplimiento de los objetivos y requerimientos del sistema de software a desarrollar? Rta. Si
30. ¿La metodología propuesta apoya el proceso de elicitación de requerimientos de software?
Rta. Si, lo apoya
III. ANALISIS DE LA METODOLOGIA CON RESPECTO A LOS USUARIOS DE LA METODOLOGIA
31. ¿Los usuarios de la metodología podrían correr algún riesgo al adoptar la metodología? Rta. Los normales en esta clase de propuesta
32. ¿Los usuarios de la metodología requerirán de algún soporte adicional para el uso de la metodología? Rta. No
33. ¿La metodología propuesta demanda algún nivel de conocimiento técnico, habilidades y experiencia del usuario para su uso? Rta. SI, de principios básicos de ingeniería de requisitos
IV. OBSERVACIONES Y/O RECOMENDACIONES FINALES POR PARTE DEL EVALUADOR EXPERTO
Se debe presentar como un anexo (en la medida de lo posible) una mini guía de la propuesta metodológica, esto con el fin de hacerla popular y reconocida de manera rápida. Ing. Mauro Callejas